1 |
Since I had just gotten it all sync'd up before trying to update to 3.5.10, I believe it was successfully running on 3.5.9. |
2 |
I tried a couple things last night, and it won't install kdelibs due to dependencies (kdebase-startkde), which won't compile without Qt either... |
3 |
|
4 |
So I'm guessing something is royally screwed. Any how...I won't have more time to look at it until this weekend. |
5 |
|
6 |
Could it be an issue with going from the monolithic builds to the split builds? |
7 |
The original system install is old enough it might have had the monolithic build of KDE - might, I really don't know off the top of my head. |
8 |
|
9 |
Any how...will post more this weekend if I can spare the time to get a bit more dirty on it... |
10 |
|
11 |
Ben |
12 |
|
13 |
|
14 |
----- Original Message ---- |
15 |
From: Duncan <1i5t5.duncan@×××.net> |
16 |
To: gentoo-amd64@l.g.o |
17 |
Sent: Tuesday, June 30, 2009 1:03:06 AM |
18 |
Subject: [gentoo-amd64] Re: kmix and qt-mt... |
19 |
|
20 |
BRM <bm_witness@×××××.com> posted |
21 |
678360.27502.qm@×××××××××××××××××××××××.com, excerpted below, on Mon, 29 |
22 |
Jun 2009 20:17:10 -0700: |
23 |
|
24 |
> I am still trying to get my AMD64 box up and going - I've got it |
25 |
> updated, and then kind of forgot about it again, so I'm going through it |
26 |
> again. This time, I got it up - everything working with the new Xorg |
27 |
> (1.5.x), and then sync'd to do get fully up to day. I've got 198 |
28 |
> packages to go, but it's dying on kmix. |
29 |
> |
30 |
> It seems to be something similar to this bug: |
31 |
> http://bugs.gentoo.org/155537 |
32 |
> |
33 |
> It keeps complaining about Qt not having library qt-mt. qt 3.3.8b-r1 is |
34 |
> installed (according to emerge qt:3 --pretend, the only way I've been |
35 |
> able to figure out what is at that slot) |
36 |
|
37 |
qt-mt (the multi-thread library) is what most packages test to see if qt |
38 |
(:3) is installed. As such, any If it's not seeing that, it's not seeing |
39 |
qt (:3), and it's a reasonably common error with a number of causes. |
40 |
|
41 |
Below, you mention that you're updating to 3.5.10, presumably from 3.5.9 |
42 |
(or possibly earlier). If that is the case, presumably you've already |
43 |
merged kdelibs-3.5.10, and probably a number of others, without issue. |
44 |
Since kdelibs:3.5 and all the rest of the kde<whatever>:3.5 will depend |
45 |
on qt:3, almost certainly using the same basic qt-mt test, why it's |
46 |
failing on kmix specifically, I don't know... at least not without a |
47 |
configure and build log to try to decypher, likely with the |
48 |
configure.log, and configure script, as well. |
49 |
|
50 |
> It seems there may be a mix between qt 4.4.2 and 4.5.1 (according to |
51 |
> 'emerge --search qt') installed in the qt:4 slot, though running 'emerge |
52 |
> qt:4 --pretend' yields warnings about all dependencies being hard |
53 |
> masked. I don't have any use flags or anything in the mask files to |
54 |
> unmask it - so I'm not sure how they got there. |
55 |
|
56 |
In theory, qt:4 should be entirely independent of qt:3, but intertwining |
57 |
dependencies could possibly mix that up. |
58 |
|
59 |
In any case, the mixed qt-4.4 and 4.5 WILL cause issues for any qt:4 |
60 |
depending packages, so that does need resolved. There has been a bit of |
61 |
experimentation getting the new dependencies working correctly, and the |
62 |
upgrade from qt-4.4 to qt-4.5 hasn't been the smoothest. |
63 |
|
64 |
The recommended way to clean up the qt:4 problem is to try unmerging any |
65 |
qt-4.4 components, and then let portage sort it out, as it'll then pull |
66 |
in all 4.5 versions. A slight variation on that, that should work, but |
67 |
may pull in a few extra bits of qt:4 you don't actually need, is to merge |
68 |
the qt:4 metapackage, which will pull in all the components, instead of |
69 |
letting the dependencies pull in the individual components. You may |
70 |
still need to unmerge the qt-4.4 components manually, however. |
71 |
|
72 |
Regardless of whether you let the individual components be remerged or |
73 |
you merge the metapackage, unless there's some other issues that come up, |
74 |
the qt-4.4 to 4.5 upgrade should be the last time this hassle comes up, |
75 |
as the 4.5 packages are now supposed to have the dependencies setup so if |
76 |
one gets upgraded they all do. However, just for future reference, all |
77 |
qt:4 packages that you have merged should always stay at the same |
78 |
version. Don't upgrade one, regardless of whether dependencies let you |
79 |
or not, without upgrading any others you have merged. (Do note, however, |
80 |
the distinction between Gentoo revision upgrades, the -rX numbers, where |
81 |
they occur, and upstream versions. It's OK to have qt-svg-4.5.1-r1 |
82 |
together with qt-core-4.5.1, for instance, as the version numbers are |
83 |
both 4.5.1, only the Gentoo revision number differs, but it's not OK to |
84 |
have qt-svg-4.4.2 together with qt-core-4.5.1.) |
85 |
|
86 |
> Any ideas on how to clean this up and get 3.5.10 up and working? (BTW, |
87 |
> 3.5.10 installed just fine on my x86 32-bit laptop from which I am |
88 |
> writing this.) |
89 |
|
90 |
Here's what I'd do. First, resolve the qt:4 issues as above. It's |
91 |
possible that'll fix whatever, tho as I said, in theory they're separate |
92 |
and it shouldn't. But since you need to do that anyway, and it should be |
93 |
pretty simple... |
94 |
|
95 |
Next try remerging kdelibs:3.5, just in case. If it still merges fine, |
96 |
you know for sure that the qt-mt detection in general is fine, it's just |
97 |
broken for kmix. If it's broken too, then you have something on the |
98 |
system broken that has to be fixed or you're unlikely to get anything |
99 |
else kde:3.5 or indeed, anything depending on qt:3 at all, to merge. |
100 |
|
101 |
Assuming kdelibs:3.5 remerges fine, next of course go back to the emerge |
102 |
-uD world, and see if it can manage kmix now. If it can't, when it |
103 |
stops, use emerge --resume --skipfirst (no - between skip and first, I |
104 |
had one there, then checked the manpage, and it says --skipfirst, no |
105 |
dash), and it should continue past that package. Since nothing else |
106 |
should really depend on it (save for kdemultimedia-meta, if you merged it |
107 |
instead of the individual packages), that should get you most of the |
108 |
rest, hopefully without additional problems. If there are additional |
109 |
problems, do the same thing. |
110 |
|
111 |
When it finishes that, so --resume has no more it can do, then go back |
112 |
and try the update once again. I've found that often, there's complex |
113 |
build dependencies that aren't always perfectly specified in the |
114 |
ebuilds. By doing what I can, then going back and trying again, often |
115 |
some or all of the ones I couldn't build the first time, now build |
116 |
without issue. Continue with that update, doing the --resume --skipfirst |
117 |
if necessary until again there's no more packages it can do. |
118 |
|
119 |
Repeat until all that are left are broken packages, or stuff that can be |
120 |
merged until the broken packages are fixed and merged. |
121 |
|
122 |
If there's any packages left broken now, you know they're really broken, |
123 |
and it's time to look for fixes. Repost the problem then, attaching the |
124 |
emerge log and the configure.log (if the package has one, portage should |
125 |
tell you about it and where it's located, or at least it seems to here). |
126 |
You can try posting it here, or file a bug directly (attaching those |
127 |
files either way), but in either case it's worth mentioning that you |
128 |
/had/ done the --resume --skipfirst thing, and portage did all it could, |
129 |
and the package is still broken, because that's important information |
130 |
that says it's not a simple screwed up dependency (tho it might still be |
131 |
a more complex missing dependency). Also, with kde packages, mention |
132 |
whether kdelibs had completed successfully, and if most of the rest of |
133 |
kde updated successfully (where it's a general kde update, not just a |
134 |
single package), or not. With this particular error, that's useful info |
135 |
since if the other packages using basically the same test built fine, |
136 |
it's gotta be something strange about this specific package. |
137 |
|
138 |
If you notice, in the bug you mentioned, while it started with amarok, |
139 |
kdelibs wouldn't merge either. The detection of qt-mt was simply broken |
140 |
for all kde packages at that point. What's strange here is that |
141 |
apparently, kdelibs already updated, and merged just fine, since it's a |
142 |
dependency of kmix. If it can remerge, then it's something strange with |
143 |
kmix. If kdelibs:3.5 can't merge either now, then the qt-mt detection is |
144 |
broken in general, and that has to be fixed, somehow, before anything |
145 |
else depending on qt:3 can be expected to merge. |
146 |
|
147 |
-- |
148 |
Duncan - List replies preferred. No HTML msgs. |
149 |
"Every nonfree program has a lord, a master -- |
150 |
and if you use the program, he is your master." Richard Stallman |