[gentoo-amd64] Re: kmix and qt-mt...

[Duncan]

BRM <bm_witness@×××××.com> posted
678360.27502.qm@×××××××××××××××××××××××.com, excerpted below, on  Mon, 29
Jun 2009 20:17:10 -0700:

> I am still trying to get my AMD64 box up and going - I've got it
> updated, and then kind of forgot about it again, so I'm going through it
> again. This time, I got it up - everything working with the new Xorg
> (1.5.x), and then sync'd to do get fully up to day. I've got 198
> packages to go, but it's dying on kmix.
>
> It seems to be something similar to this bug:
> http://bugs.gentoo.org/155537
>
> It keeps complaining about Qt not having library qt-mt. qt 3.3.8b-r1 is
> installed (according to emerge qt:3 --pretend, the only way I've been
> able to figure out what is at that slot)

qt-mt (the multi-thread library) is what most packages test to see if qt 
(:3) is installed.  As such, any If it's not seeing that, it's not seeing 
qt (:3), and it's a reasonably common error with a number of causes.

Below, you mention that you're updating to 3.5.10, presumably from 3.5.9 
(or possibly earlier).  If that is the case, presumably you've already 
merged kdelibs-3.5.10, and probably a number of others, without issue.  
Since kdelibs:3.5 and all the rest of the kde<whatever>:3.5 will depend 
on qt:3, almost certainly using the same basic qt-mt test, why it's 
failing on kmix specifically, I don't know... at least not without a 
configure and build log to try to decypher, likely with the 
configure.log, and configure script, as well.

> It seems there may be a mix between qt 4.4.2 and 4.5.1 (according to
> 'emerge --search qt') installed in the qt:4 slot, though running 'emerge
> qt:4 --pretend' yields warnings about all dependencies being hard
> masked. I don't have any use flags or anything in the mask files to
> unmask it - so I'm not sure how they got there.

In theory, qt:4 should be entirely independent of qt:3, but intertwining 
dependencies could possibly mix that up.

In any case, the mixed qt-4.4 and 4.5 WILL cause issues for any qt:4 
depending packages, so that does need resolved.  There has been a bit of 
experimentation getting the new dependencies working correctly, and the 
upgrade from qt-4.4 to qt-4.5 hasn't been the smoothest.

The recommended way to clean up the qt:4 problem is to try unmerging any 
qt-4.4 components, and then let portage sort it out, as it'll then pull 
in all 4.5 versions.  A slight variation on that, that should work, but 
may pull in a few extra bits of qt:4 you don't actually need, is to merge 
the qt:4 metapackage, which will pull in all the components, instead of 
letting the dependencies pull in the individual components.  You may 
still need to unmerge the qt-4.4 components manually, however.

Regardless of whether you let the individual components be remerged or 
you merge the metapackage, unless there's some other issues that come up, 
the qt-4.4 to 4.5 upgrade should be the last time this hassle comes up, 
as the 4.5 packages are now supposed to have the dependencies setup so if 
one gets upgraded they all do.  However, just for future reference, all 
qt:4 packages that you have merged should always stay at the same 
version.  Don't upgrade one, regardless of whether dependencies let you 
or not, without upgrading any others you have merged.  (Do note, however, 
the distinction between Gentoo revision upgrades, the -rX numbers, where 
they occur, and upstream versions.  It's OK to have qt-svg-4.5.1-r1 
together with qt-core-4.5.1, for instance, as the version numbers are 
both 4.5.1, only the Gentoo revision number differs, but it's not OK to 
have qt-svg-4.4.2 together with qt-core-4.5.1.)

> Any ideas on how to clean this up and get 3.5.10 up and working? (BTW,
> 3.5.10 installed just fine on my x86 32-bit laptop from which I am
> writing this.)

Here's what I'd do.  First, resolve the qt:4 issues as above.  It's 
possible that'll fix whatever, tho as I said, in theory they're separate 
and it shouldn't.  But since you need to do that anyway, and it should be 
pretty simple...

Next try remerging kdelibs:3.5, just in case.  If it still merges fine, 
you know for sure that the qt-mt detection in general is fine, it's just 
broken for kmix.  If it's broken too, then you have something on the 
system broken that has to be fixed or you're unlikely to get anything 
else kde:3.5 or indeed, anything depending on qt:3 at all, to merge.

Assuming kdelibs:3.5 remerges fine, next of course go back to the emerge 
-uD world, and see if it can manage kmix now.  If it can't, when it 
stops, use emerge --resume --skipfirst (no - between skip and first, I 
had one there, then checked the manpage, and it says --skipfirst, no 
dash), and it should continue past that package.  Since nothing else 
should really depend on it (save for kdemultimedia-meta, if you merged it 
instead of the individual packages), that should get you most of the 
rest, hopefully without additional problems.  If there are additional 
problems, do the same thing.

When it finishes that, so --resume has no more it can do, then go back 
and try the update once again.  I've found that often, there's complex 
build dependencies that aren't always perfectly specified in the 
ebuilds.  By doing what I can, then going back and trying again, often 
some or all of the ones I couldn't build the first time, now build 
without issue.  Continue with that update, doing the --resume --skipfirst 
if necessary until again there's no more packages it can do.

Repeat until all that are left are broken packages, or stuff that can be 
merged until the broken packages are fixed and merged.

If there's any packages left broken now, you know they're really broken, 
and it's time to look for fixes.  Repost the problem then, attaching the 
emerge log and the configure.log (if the package has one, portage should 
tell you about it and where it's located, or at least it seems to here).  
You can try posting it here, or file a bug directly (attaching those 
files either way), but in either case it's worth mentioning that you 
/had/ done the --resume --skipfirst thing, and portage did all it could, 
and the package is still broken, because that's important information 
that says it's not a simple screwed up dependency (tho it might still be 
a more complex missing dependency).  Also, with kde packages, mention 
whether kdelibs had completed successfully, and if most of the rest of 
kde updated successfully (where it's a general kde update, not just a 
single package), or not.  With this particular error, that's useful info 
since if the other packages using basically the same test built fine, 
it's gotta be something strange about this specific package.

If you notice, in the bug you mentioned, while it started with amarok, 
kdelibs wouldn't merge either.  The detection of qt-mt was simply broken 
for all kde packages at that point.  What's strange here is that 
apparently, kdelibs already updated, and merged just fine, since it's a 
dependency of kmix.  If it can remerge, then it's something strange with 
kmix.  If kdelibs:3.5 can't merge either now, then the qt-mt detection is 
broken in general, and that has to be fixed, somehow, before anything 
else depending on qt:3 can be expected to merge.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman