Current emerging eudev breaks the tree dependencies: [blocks B ] sys-fs/udev ("sys-fs/udev" is blocking sys-fs/eudev-0) [blocks B ] sys-apps/kmod ("sys-apps/kmod" is blocking sys-apps/module-init-tools-3.16-r2) [blocks B ] sys-apps/module-init-tools ("sys-apps/module-init-tools" is blocking sys-apps/kmod-12-r1) This is fixed by marking sys-fs/eudev-1_beta1-r2 stable. Target archesare: alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86 eudev-1_beta1 has been out since Dec 9 and only the ebuild has been rev-bumped to address some small issues (fix blockers and add dependencies --- see ChangeLog). There are two bugs out against it but one is probably invalid and the other is not appropriate for 1_beta1 and the new behavior is targetted for 1_beta2. So it is clear for stabilizatons: INVALID -> bug #453318 IN_PROGRESS ofr 1_beta2 -> bug #452686
The dependency of eudev is || ( ) in the virtual. The tree is not broken. You must be reading the output wrong. With that said, if eudev is ready to stabilize, then why not.
It isn't keyworded for HPPA. If you want that, file a keyword request and don't hope for rapid stabilisation.
(In reply to comment #2) > It isn't keyworded for HPPA. If you want that, file a keyword request and > don't hope for rapid stabilisation. The reason for that is when I saw this bug I wondered why the hell eudev was marked stable on alpha, and I found out that they just copied all the udev keywords as-is. Sigh. So I removed them.
amd64 stable
x86 stable
closing the bug now -- thanks for the stable keywords, but I couldn't reproduce this on any system that didn't have some funky version-specific local keywording on the virtuals. Also, eudev-0 (the original "cause") is no longer in the tree, so there's no need to stable-keyword any further. Dropping other arches from CC list
..after talking with ago, decided to revert stable keywords too -- it'll be easier to ensure all users obtain fixes from revbumped ebuilds if we just have ~arch keywords right now.
