Summary: | =app-emulation/xen-tools-3.4.2 fails to emerge | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Elijah "Armageddon" El Lazkani (amd64 AT) <ThyArmageddon+Gentoo> |
Component: | [OLD] Unspecified | Assignee: | Alexey Shvetsov <alexxy> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | a.m, gentoo, luc_pierard_de_maujouy |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | full build log |
Description
Elijah "Armageddon" El Lazkani (amd64 AT)
2011-08-19 01:37:46 UTC
xen use flag has been masked to app-emulation/libvirt to hide the problem from stable tree *** Bug 381371 has been marked as a duplicate of this bug. *** the problem was too fold, related to system headers and a rogue #define WRITE. Fixed, the revised version -r1 will be in the tree within a day or so *** Bug 385615 has been marked as a duplicate of this bug. *** Wow! I'm amazed... If there is now a problem with xen-tools-3.4.2 as "a dependency for =app-emulation/libvirt-0.9.3-r1[xen]" (direct quote from comment#1) and the stable tree needs to be protected, then *why* (oh, why?) does this app-emulation/libvirt xen get entered in package.use.mask instead of this =app-emulation/libvirt-0.9.3-r1 xen ?!?? Is there a good reason for inconveniencing those not going with the stable versions? (I'm talking about e.g. libvirt-0.9.6 with xen-tools-4.1.1-r5, which build fine.) And worse, why do bugs where people complain about this nonsense get marked as duplicates? RESOLVED as FIXED? BTW, is there an easy way to permanently disable such overly generous masking? So far I've tried /etc/portage/package.use.{mask,force} without any luck. Is it time yet for a package.use.unmask? *** Bug 388001 has been marked as a duplicate of this bug. *** |