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. 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...
So I'm guessing something is royally screwed. Any how...I won't have more time to look at it until this weekend. Could it be an issue with going from the monolithic builds to the split builds? 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. Any how...will post more this weekend if I can spare the time to get a bit more dirty on it... Ben ----- Original Message ---- From: Duncan <1i5t5.dun...@cox.net> To: gentoo-amd64@lists.gentoo.org Sent: Tuesday, June 30, 2009 1:03:06 AM Subject: [gentoo-amd64] Re: kmix and qt-mt... BRM <bm_witn...@yahoo.com> posted 678360.27502...@web65415.mail.ac4.yahoo.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
