Please ~re-keyword gtk+-3.2.1 for USE="colord packagekit". For colord on arm, x86-fbsd, x86-freebsd, amd64-linux, x86-linux, x86-solaris: >=x11-misc/colord-0.1.13 will be a required dependency for several core gnome-3.2 packages. Therefore, if you can't keyword x11-misc/colord, please say so; perhaps the gnome team will be able to patch some things to make it optional. For colord on other arches: feel free to package.use.mask it if it doesn't work. For packagekit: if app-admin/packagekit-base doesn't work, please use.mask (not package.use.mask) the packagekit flag. At least 6 packages with "packagekit? ( app-admin/packagekit-base )" in RDEPEND will be arriving in portage with gnome-3.2.
Marked ~hppa.
Update: On advice from other gnome team members, I have use.masked "colord" on alpha, arm, ia64, ppc, ppc64, and sparc and "packagekit" on alpha, ia64, ppc, ppc64, and sparc, restored all keywords to gtk+-3.2.1, and unmasked gtk+-3.2.1. Also, colord in gnome-3.2 will now be optional (controlled by USE=colord, which will be in make.defaults for the gnome target). alpha, arm, ia64, ppc, ppc64, and sparc: please test x11-misc/colord and app-admin/packagekit-base, and if they work, keyword them and remove the flags from use.mask. Unstable and dev arches (mips, sh, x86-fbsd, x86-freebsd, x86-interix, amd64-linux, x86-linux, ppc-macos, x86-macos, sparc-solaris, sparc64-solaris, x64-solaris, x86-solaris): gtk+[colord,packagekit] has unsatisfied dependencies on your arches, but since repoman doesn't complain, I am leaving it up to you to deal with the situation in whatever manner is appropriate :)
colord has a new version to 0.1.14
(In reply to comment #3) > colord has a new version to 0.1.14 Version 0.1.5 ~~~~~~~~~~~~~ Released: 2011-11-01
~arm keyword added to colord and use.mask removed.
Created attachment 292987 [details] files/colord-0.1.14-libusb.patch I was able to build colord on Gentoo/FreeBSD-8.2 with this patch and some fix to ebuild. Ebuild fix is to add USB_CFLAGS and USB_LIBS to econf argument to workaround pkg-config libusb-1.0 check. (FreeBSD system package >=sys-freebsd/freebsd-lib-8.0[usb] is compatible with libusb, so we don't need it on FreeBSD) and this attached patch replace "#include <libusb-1.0/libusb.h>" with "#include <libusb.h>" since FreeBSD libusb.h is placed at /usr/include/libusb.h. OTOH, on Linux, it should be compiled with "-I/usr/include/libusb-1.0" (= `pkg-config --cflags libusb-1.0`), so this change may work both on Linux and FreeBSD. If you are interested, please test this patch on Linux. Anyway, I'll send this patch to upstream.
(In reply to comment #6) I have added freebsd dependencies, a fix for the <libusb.h> issue, and USB_CFLAGS/USB_LIBS to colord-0.1.14-r1. Please test and keyword it on freebsd if it works. >*colord-0.1.14-r1 (25 Nov 2011) > > 25 Nov 2011; Alexandre Rostovtsev <tetromino@gentoo.org> > -colord-0.1.12.ebuild, -colord-0.1.13.ebuild, +colord-0.1.14-r1.ebuild, > +files/colord-0.1.14-sql-injections.patch, > +files/colord-0.1.14-sql-injections-2.patch: > Add patches to fix SQL injections (bug #391879, thanks to Agostino Sarubbo for > reporting). Allow building against freebsd's libusb (bug #387959, thanks to > Naohiro Aota). Drop old versions.
Note: >=x11-misc/colord-0.1.15 has a new, optional dependency on dev-libs/libgusb (controlled by the gusb USE flag); see bug #392057 @bsd: According to Naohiro Aota's testing, libgusb is unlikely to work on non-Linux architectures, so if/when you keyword colord, you will probably want to package.use.mask colord[gusb].
Hmmm, this package is unlikely to be useful for prefix, is it?
(In reply to comment #9) > Hmmm, this package is unlikely to be useful for prefix, is it? Colord will be useful for prefix if prefix supports cups or sane, or using libusb to access local USB devices such as colorimeters. Packagekit is likely to be about as useful for prefix as it is for ordinary gentoo setups (i.e. it holds great promise for the future, but at the moment is limited, very slow, and somewhat buggy).
Prefix users often don't have root-powers. Sounds as if this thing interfaces with the system in a way that needs root, or doesn't it?
(In reply to comment #11) > Prefix users often don't have root-powers. Sounds as if this thing interfaces > with the system in a way that needs root, or doesn't it? I believe that colord does not need root privileges. It does not run as root even on normal Gentoo setups. The only thing it strictly requires is the ability to be launched as a dbus system service. Note that the current colord ebuild creates a new user and group to run as, passes "--with-daemon-user=colord" to configure, installs certain directories as owned by colord:colord, and uses at_console dbus policy. I am guessing that for prefix installations without root access, these things may have to be appropriately adjusted.
(In reply to comment #7) > I have added freebsd dependencies, a fix for the <libusb.h> issue, and > USB_CFLAGS/USB_LIBS to colord-0.1.14-r1. Please test and keyword it on freebsd > if it works. Unfortunately, it failed to build on FreeBSD. I've modified the ebuild to "export USB_CFLAGS" and "export USB_LIBS" and it built well.
(In reply to comment #13) > Unfortunately, it failed to build on FreeBSD. I've modified the ebuild > to "export USB_CFLAGS" and "export USB_LIBS" and it built well. Thanks, should be fixed now.
Marked ~x86-fbsd.
~ppc done
~ppc64 done
Added ~mips.
Added ~alpha
Repoman is complaining after some keywording done here: (In reply to comment #16) > ~ppc done app-admin/packagekit-base/packagekit-base-0.7.4.ebuild: RDEPEND: ~ppc(default/linux/powerpc/ppc32/10.0) ['>=sys-apps/entropy-1.0_rc27'] (In reply to comment #17) > ~ppc64 done app-admin/packagekit-base/packagekit-base-0.6.22.ebuild: RDEPEND: ~ppc64(default/linux/powerpc/ppc64/10.0/64bit-userland) ['>=sys-apps/entropy-1.0_rc27']
ppc/ppc64 done
ia64 done
Please don't touch entropy ebuilds without contacting me first! Anything you touch in there will go away next time I merge the ebuilds from the "sabayon" overlay. Please see my pkg policy: http://dev.gentoo.org/~lxnay/ Also, who tested entropy on ia64 and ppc?
arch teams, ping!
ping!
I guess remaining will pass