I encounter the following issue: >>> Emerging binary (1 of 190) sys-auth/polkit-kde-agent-0.99.0 >>> Failed to emerge sys-auth/polkit-kde-agent-0.99.0, Log file: >>> '/var/tmp/portage/sys-auth/polkit-kde-agent-0.99.0/temp/build.log' >>> Extracting info * Package: sys-auth/polkit-kde-agent-0.99.0 * Repository: gentoo * USE: linguas_de * FEATURES: sandbox * ERROR: sys-auth/polkit-kde-agent-0.99.0 failed (setup phase): * Failed to determine KDEDIR! * * Call stack: * ebuild.sh, line 56: Called pkg_setup * environment, line 3814: Called kde4-base_pkg_setup * environment, line 3134: Called die * The specific snippet of code: * [[ -z ${KDEDIR} ]] && die "Failed to determine KDEDIR!"; After I have rebuilt all packages on the binhost, I got this outcome: [blocks B ] kde-base/kde-l10n:4 ("kde-base/kde-l10n:4" is blocking kde-base/kdepim-l10n-4.4.11.1-r1) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (kde-base/kdepim-l10n-4.4.11.1-r1::gentoo, installed) pulled in by >=kde-base/kdepim-l10n-4.4.11.1[-aqua,-kdeprefix] required by (kde-base/kdepim-meta-4.4.11.1::gentoo, installed) (kde-base/kde-l10n-4.6.5-r1::gentoo, binary scheduled for merge) pulled in by >=kde-base/kde-l10n-4.4.11.1[-aqua,-kdeprefix] required by (kde-base/kdepim-meta-4.4.11.1::gentoo, installed) >=kde-base/kde-l10n-4.4:4[-aqua,linguas_de(+)] required by (app-cdr/k3b-2.0.2-r1::gentoo, binary scheduled for merge) >=kde-base/kde-l10n-4.4[-aqua,linguas_de(+)] required by (net-wireless/bluedevil-1.1-r2::gentoo, installed) =kde-base/kde-l10n-4* required by (bbs1-meta/kde-4-r201008271134::bbs1, installed) Deleting the offending packages by emerge -C does not change anything. I am maintaining about 80 boxes in a school environment by binary installs. These got installed as purely binary systems, there is no portage installed locally at all. Ebuilds on the BINHOST are working fine. I see this problem since June and hoped it would go away eventually. (Delaying updates was no problem during summer hollydays) Reproducible: Always Steps to Reproduce: 1. emerge a kde-component on a BINHOST as binary package 2. Install this binary package on a client machine 3. Actual Results: Updating my boxes does not work Expected Results: Binary updates should install I am maintaining about 80 boxes in a school environment by binary installs. The boxes got installed as purely binary systems, there is no portage installed locally at all. Ebuilds on the BINHOST are working fine. I see this problem since June and hoped it would go away eventually. Delaying updates was no problem during summer holidays but all maintenance of the boxes gets done by a system of scripts which do reconfiguring and install of new software too. All maintenance work is stalled by the problem by now.
Ewww... this is still fallout of the big slotmove. Problem 1 (Failed to determine KDEDIR!) cannot happen anymore because the code does not exist anymore since June. (Sounds familiar?) Problem 2... portage translates the add_blocker command in the kdepim-l10n-4.4.11.1-r1 ebuild correctly to "!<=kde-base/kde-l10n-4.5.50:4" As I'm not an expert for binpackages... what software do you use to actually install the packages then? Smells a bit like a bug there...
(In reply to comment #1) > As I'm not an expert for binpackages... what software do you use to actually > install the packages then? Smells a bit like a bug there... Basically it's just "emerge -Dugq world" called from a shell-script.
@portage: any idea? How is the dependency metadata handled on hosts with pure binary install? This smells a bit like something was not updated when the KDE eclasses changed.
(In reply to comment #3) > @portage: any idea? Given that the "Failed to determine KDEDIR!" die thing has since been removed from the eclass, I'd suggest to rebuild the binary packages with the latest version of the eclass. There's nothing portage can do about broken code inside the binary package's environment.bz2, since it's just bash code that's there to be executed (it can call die if it wants to, and portage doesn't have any control over that). > How is the dependency metadata handled on hosts with pure binary install? See the xpak man page. The metadata (including environment.bz2) is stored in an xpak segment that's appended to the end of the tbz2 file. > This > smells a bit like something was not updated when the KDE eclasses changed. Well, the bug in an old version of the eclass that's long gone. That doesn't stop you from trying to install binary packages built with the old version of the eclass though (well, the die in kde4-base_pkg_setup might stop you, hehe).
All right. It took some days to recompile the whole system. Got some other problems on the way but now I am done. You are right. Due to my limited knowledge of the whole process I had deleted the distribution directory not /usr/portage/packages. As a result not all packages got recompiled. I can't say all is working fine now, unfortunately it's not. But at least the reported problem is gone. Thank you for your advice.
(In reply to comment #5) > All right. It took some days to recompile the whole system. Got some other > problems on the way but now I am done. > You are right. Due to my limited knowledge of the whole process I had deleted > the distribution directory not /usr/portage/packages. As a result not all > packages got recompiled. I can't say all is working fine now, unfortunately > it's not. But at least the reported problem is gone. Thank you for your > advice. OK, good luck... unfortunately the binpackages are not the best-tested feature. I'm going to close this report, but please feel free to file separate ones for other problems that you encounter.
