Created attachment 278395 [details] emerge --info for problem binary slave PC The instant problem is that I'm having a number of KDE based binary package ebuilds fail. These all fail with the same message. Example: # emerge -gK konversation Calculating dependencies... done! >>> Emerging binary (1 of 1) net-irc/konversation-1.3.1 * konversation-1.3.1.tbz2 MD5 SHA1 size ;-) ... [ ok ] >>> Extracting info * Package: net-irc/konversation-1.3.1 * Repository: gentoo * USE: amd64 crypt multilib kernel_linux elibc_glibc handbook userland_GNU * FEATURES: preserve-libs sandbox * ERROR: net-irc/konversation-1.3.1 failed (setup phase): * Failed to determine KDEDIR! Notes: 1) So far, this error does not happen consistently between otherwise identical PCs. Most of the other binary package based PCs behave as expected. 2) On the PC where this happens, it happens for the same packages the same way all the time. 3) I can work around the problem by performing a local source and compile emerge. These are successful every time. 4) If I perform the work around then try to re-install the package using the binary option '-g' flag, the emerge fails on the same KDEDIR issue. kde-base packages where I've had this fail message include: polkit-kde-agent polkit-kde-kcmodules plasma-runtime thumbnailers kdontchangethehostname kcontrol kdm independent kde packages where I've had this fail message include: krename ktorrent konversation I initially posted a write-up in the gentoo forums here: http://forums.gentoo.org/viewtopic-p-6736910.html#6736910 While the work around defeats the purpose of working with binary packages, I'm not prevented in keeping all of my systems up-to-date. I'm not a programmer but I'll be happy to make reasonable efforts under someone's guidance to collect more information. Feel free to contact me here or PM me in the forums.
Created attachment 278397 [details] emerge --info for binary host PC
Well, it's not bug 366939, since you're using latest portage. So, apparently there's something going wrong with the kde ebuild/eclass.
What KDE packages and versions? Are you sure you're not trying to merge a binary package built before the slot move in a box where you have already updated your system and go the slot move that was done a few days ago to all KDE packages?
(In reply to comment #3) > What KDE packages and versions? > Are you sure you're not trying to merge a binary package built before the slot > move in a box where you have already updated your system and go the slot move > that was done a few days ago to all KDE packages? Regular world update which included KDE-4.6.3 to KDE-4.6.4. The thread I originally started in the forums (linked above) has quite a bit more information. I'd like to repeat that I performed the identical process on other (what are functionally identical) boxes without a problem. If you have any commands you'd like me to run to gather more information, I'll be happy to do so. I didn't see any other posts in the forums nor here which were similar w/regards to KDEDIR other than it might be of use to have the 'die' command print the value of KDEDIR upon exit {if possible}.
(In reply to comment #3) > What KDE packages and versions? > Are you sure you're not trying to merge a binary package built before the slot > move in a box where you have already updated your system and go the slot move > that was done a few days ago to all KDE packages? I just realized I'm not actually understanding your question. Are you asking if I had done some partial emerges before starting over again with a world update? If so, the answer is no.
(In reply to comment #2) > Well, it's not bug 366939, since you're using latest portage. So, apparently > there's something going wrong with the kde ebuild/eclass. {laughs} Um .. yes. I was the original reporter for that bug. This is something completely different. BTW - I never did say 'thank you' for that bug fix. I did then and still do appreciate it.
(In reply to comment #0) > * ERROR: net-irc/konversation-1.3.1 failed (setup phase): > * Failed to determine KDEDIR! The konversation-1.3.1 seems to inherit kde4-base_pkg_setup: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kde4-base.eclass?view=log I don't see any "Failed to determine KDEDIR!" die message in the latest version of kde4-base_pkg_setup in kde4-base.eclass, so it seems like the problem has already been fixed. However, you'll have to rebuild you binary packages in order to get the eclass changes.
I've finally figured out how to correctly work around this problem manually. It is some kind of 'out of compilation order' issue between binary packages and their binary dependencies as they are installed on a binary package consumer. On the binary PC, I got the following message: # emerge -g k3b Calculating dependencies... done! >>> Emerging binary (1 of 1) app-cdr/k3b-2.0.2-r1 * k3b-2.0.2-r1.tbz2 MD5 SHA1 size ;-) ... [ ok ] >>> Extracting info * ERROR: app-cdr/k3b-2.0.2-r1 failed (setup phase): * Failed to determine KDEDIR! * * Call stack: * ebuild.sh, line 56: Called pkg_setup * environment, line 3530: Called kde4-base_pkg_setup * environment, line 2838: Called die * The specific snippet of code: * [[ -z ${KDEDIR} ]] && die "Failed to determine KDEDIR!"; Earlier, on the same machine, I had noticed that "emerge -p --depclean" had flagged 'emovix' for deletion. media-video/emovix selected: 0.9.0 protected: none omitted: none On the binary package generator/host, I checked to see what depended on 'emovix' and discovered that 'k3b' needed 'emovix' if USE='emovix' was set. I promptly recompiled 'emovix' and 'k3b' on the binary host PC using the command: emerge emovix && emerge k3b .. >>> Emerging (1 of 1) media-video/emovix-0.9.0 * emovix-0.9.0.tar.gz RMD160 SHA1 SHA256 size ;-) ... .. >>> Emerging (1 of 1) app-cdr/k3b-2.0.2-r1 * k3b-2.0.2.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... I brought the newly re-compiled, same version binary packages back to the binary consumer PC and re-installed them with this command: emerge -g emovix && emerge -g k3b .. >>> Emerging binary (1 of 1) media-video/emovix-0.9.0 * emovix-0.9.0.tbz2 MD5 SHA1 size ;-) ... [ ok ] >>> Extracting info >>> Extracting media-video/emovix-0.9.0 >>> Installing (1 of 1) media-video/emovix-0.9.0 .. >>> Emerging binary (1 of 1) app-cdr/k3b-2.0.2-r1 * k3b-2.0.2-r1.tbz2 MD5 SHA1 size ;-) ... [ ok ] >>> Extracting info >>> Extracting app-cdr/k3b-2.0.2-r1 >>> Installing (1 of 1) app-cdr/k3b-2.0.2-r1 When I had originally tried to emerge 'k3b' as part of my latest global update, the system determined (correctly) that 'emovix' did not require an update. See this eix query: # eix media-video/emovix [I] media-video/emovix Available versions: 0.9.0{tbz2} {win32codecs} Installed versions: 0.9.0{tbz2}(05:33:20 PM 10/25/2010)(-win32codecs) Homepage: http://movix.sourceforge.net Description: Micro Linux distro to boot from a CD and play every video file localized in the CD root. Note the last time I had compiled 'emovix' was Oct 25, 2010. While the 'emovix' version hasn't changed, I'd suggest that some of the stored paths in the binary 'emovix' object were no longer valid or compatible with the new 'k3b' binary even though 'emovix' had otherwise not changed. This is a pure guess on my part. I believe the reason for KDE based packages which are not installed through a *-meta package object were such a problem is the potential for old, otherwise valid dependencies built with old paths and not requiring a package update themselves is high. Given the KDE slot simplification, this possibility makes sense. Once again, this is a pure guess on my part. Note 1: I have been able to successfully eliminate the KDEDIR message in all cases by ensuring that older dependencies are re-compiled and rebuilt on the binary host and that they are re-installed prior to their respective main binary packages. Note 2: I believe this issue is limited to ONLY binary package installations. I've not seen this on any of the PCs I maintain where with re-compilation in place upgrades.
(In reply to comment #7) > (In reply to comment #0) > > * ERROR: net-irc/konversation-1.3.1 failed (setup phase): > > * Failed to determine KDEDIR! > > The konversation-1.3.1 seems to inherit kde4-base_pkg_setup: > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kde4-base.eclass?view=log > > I don't see any "Failed to determine KDEDIR!" die message in the latest version > of kde4-base_pkg_setup in kde4-base.eclass, so it seems like the problem has > already been fixed. However, you'll have to rebuild you binary packages in > order to get the eclass changes. I'm sorry, I didn't see your reply before I posted comment #8. I'm assuming that the key is rebuilding all pertinent binary packages. So I don't know if my guesses are any near applicable. I don't really know what everything is that gets stored in the binary versions of the packages. I do suspect however, that if I had recompiled all dependencies at the time before installing the main packages, that this would have worked without the eclass change. Something to think about anyway. Thank you very much for your help. Please feel free to close. I believe the problem is resolved.
Hi Guy, thanks a lot for your efforts. I'm sorry, we usually dont test binary packages at all... I have a suspicion that this may be related to the big slotmove (4.X to 4) of all kde packages, which happened sometime around these versions. However I dont have any proof or details to support that. > > Thank you very much for your help. Please feel free to close. I believe the > problem is resolved. OK, I'll resolve it. Feel free to reopen if the problem reoccurs, or to add new info.
