RepoMan scours the neighborhood... RDEPEND.bad 34 sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~alpha(default/linux/alpha/10.0/server) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~alpha(default/linux/alpha/10.0/developer) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~alpha(default/linux/alpha/10.0/desktop/kde) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~alpha(default/linux/alpha/10.0/desktop/gnome) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~alpha(default/linux/alpha/10.0/desktop) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~alpha(default/linux/alpha/10.0) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~hppa(default/linux/hppa/10.0) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ia64(default/linux/ia64/10.0/server) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ia64(default/linux/ia64/10.0/developer) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ia64(default/linux/ia64/10.0/desktop/kde) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ia64(default/linux/ia64/10.0/desktop/gnome) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ia64(default/linux/ia64/10.0/desktop) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ia64(default/linux/ia64/10.0) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ppc(default/linux/powerpc/ppc64/10.0/32bit-userland/developer) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ppc(default/linux/powerpc/ppc64/10.0/32bit-userland/desktop/kde) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ppc(default/linux/powerpc/ppc64/10.0/32bit-userland/desktop/gnome) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ppc(default/linux/powerpc/ppc64/10.0/32bit-userland/desktop) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ppc(default/linux/powerpc/ppc64/10.0/32bit-userland) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ppc(default/linux/powerpc/ppc32/10.0/developer) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ppc(default/linux/powerpc/ppc32/10.0/desktop/kde) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ppc(default/linux/powerpc/ppc32/10.0/desktop/gnome) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ppc(default/linux/powerpc/ppc32/10.0/desktop) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ppc(default/linux/powerpc/ppc32/10.0) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ppc64(default/linux/powerpc/ppc64/10.0/64bit-userland/developer) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ppc64(default/linux/powerpc/ppc64/10.0/64bit-userland/desktop/kde) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ppc64(default/linux/powerpc/ppc64/10.0/64bit-userland/desktop/gnome) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ppc64(default/linux/powerpc/ppc64/10.0/64bit-userland/desktop) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~ppc64(default/linux/powerpc/ppc64/10.0/64bit-userland) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~sparc(default/linux/sparc/10.0/server) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~sparc(default/linux/sparc/10.0/developer) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~sparc(default/linux/sparc/10.0/desktop/kde) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~sparc(default/linux/sparc/10.0/desktop/gnome) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~sparc(default/linux/sparc/10.0/desktop) ['>=sys-apps/gptfdisk-0.8'] sys-fs/udisks/udisks-1.94.0-r1.ebuild: ~sparc(default/linux/sparc/10.0) ['>=sys-apps/gptfdisk-0.8']
This is probably not going to work for HPPA. Even a simple command displays a profound lack of HPPA-specifics in the code: elmer ~ # sgdisk -D /dev/sdb *************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format. *************************************************************** Exact type match not found for type code F000; assigning type code for 'Linux filesystem' 1 elmer ~ # fdisk -l /dev/sdb Disk /dev/sdb: 18.2 GB, 18209320960 bytes 255 heads, 63 sectors/track, 2213 cylinders, total 35565080 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdb1 63 48194 24066 f0 Linux/PA-RISC boot /dev/sdb2 48195 257039 104422+ 83 Linux /dev/sdb3 257040 1269134 506047+ 82 Linux swap / Solaris /dev/sdb4 1269135 35551844 17141355 83 Linux elmer ~ # sgdisk --attributes 1:show /dev/sdb *************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format. *************************************************************** Exact type match not found for type code F000; assigning type code for 'Linux filesystem' Here, sdb1 is a HPPA specific boot partition where the Initial Program Loader (IPL) is stored by sys-boot/palo, and where the HPPA firmware can recognise and find that IPL (see [1] for information about the F0 partition type) so that the bootstrap process can start. and since HPPA systems are not known to support booting from GPT, "dos" is the only option, so the code that runs the sgdisk command would (hopefully!) never be executed. I even doubt the bitmasking in the flags works on big-endian systems, but I haven't checked that. Thus, I have strong reservations about marking sys-apps/gptdisk for HPPA - providing a USE flag to disable this dependency would be more useful to us. [1] http://www.gentoo.org/doc/en/handbook/handbook-hppa.xml?part=1&chap=4#doc_chap3
(In reply to comment #1) > This is probably not going to work for HPPA. Even a simple command displays > a profound lack of HPPA-specifics in the code: I've made this optional with USE=gptfdisk so you can mask it in HPPA's profile if it's not working. It's not really optional dependency, but leaving it out just means small piece of functionality is removed, so keywording udisks still makes sense. :)
ppc* done, and others will have to remove package.use.mask entry for USE="udisks" and gnome-base/gvfs in their profiles expect more to be masked as time goes by :/
(In reply to comment #2) > (In reply to comment #1) > > This is probably not going to work for HPPA. Even a simple command displays > > a profound lack of HPPA-specifics in the code: > > I've made this optional with USE=gptfdisk so you can mask it in HPPA's > profile if it's not working. > It's not really optional dependency, but leaving it out just means small > piece of functionality is removed, so keywording udisks still makes sense. :) Since udisks will never find a working GPT on an HPPA system, this probably won't turn ugly. I still cannot rekeyword udisks, since it now depends on virtual/acl, which was dropped for bug #212517.
(In reply to comment #4) > (In reply to comment #2) > > (In reply to comment #1) > > > This is probably not going to work for HPPA. Even a simple command displays > > > a profound lack of HPPA-specifics in the code: > > > > I've made this optional with USE=gptfdisk so you can mask it in HPPA's > > profile if it's not working. > > It's not really optional dependency, but leaving it out just means small > > piece of functionality is removed, so keywording udisks still makes sense. :) > > Since udisks will never find a working GPT on an HPPA system, this probably > won't turn ugly. > > I still cannot rekeyword udisks, since it now depends on virtual/acl, which > was dropped for bug #212517. ACL support is mandatory for setting /run/media/$user permissions and we have gone through trying to optionalize it without success, upstream rather made it even more hardcoded dependency: http://bugs.gentoo.org/412377 https://bugs.freedesktop.org/show_bug.cgi?id=48842 UDisks2 won't work for HPPA then. Please convince upstream to optionalize ACL, or drop keywording also from the obsolete sys-fs/udisks:0, please. Thanks, Samuli
Latest sys-auth/polkit, sys-fs/udisks, and bug 420997 before as a dependency
HPPA keywording dropped. It seems nothing needed it anyway.
ia64 done
get at least 2.0.91 (current stable)
Removing alpha@ and sparc@ from CC list because of: 23 Feb 2013; Agostino Sarubbo <ago@gentoo.org> udisks-1.0.4-r4.ebuild, udisks-2.0.91.ebuild: Stable for alpha, wrt bug #427550 So now only sh@ is missing.
sh done
