Created attachment 347128 [details] emerge --info =gnome-base/gnome-keyring-3.6.3 When emerging gnome-base/gnome-keyring-3.6.3, I get this portage warning: "Failed to set capabilities. Probable reason is missing kernel support. Your kernel must have <FS>_FS_SECURITY enabled (e.g. EXT4_FS_SECURITY) where <FS> is the filesystem to store //usr/bin/gnome-keyring-daemon" My kernel does have EXT4_FS_SECURITY enabled. The real problem here is that sys-libs/libcap is not installed, and gnome-keyring-3.6.3.ebuild does not pull it in as a dep (it pulls-in sys-libs/libcap-ng instead, which doesn't seem to help). After I emerged sys-libs/libcap manually and then re-emerged gnome-keyring, the warning was gone.
This dependency comes from the eclass.
(In reply to comment #1) > This dependency comes from the eclass. the gnome-keyring ebuild has a function called fcaps() which manually calls setcap without depending on the package that provides it, no eclass involved here.
ah right, I thought the change to use eclass was backported to 3.6, my bad.
Apply the same change done to 3.8, see bug #454908.
+ 10 May 2013; Gilles Dartiguelongue <eva@gentoo.org> + gnome-keyring-3.6.3.ebuild, metadata.xml: + Add longdescription, bug #463542. Use fcaps eclass instead of custom code, + bug #468258. + Thanks for reporting.
The USE flags are somewhat confusing though: $ equery uses gnome-base/gnome-keyring + + caps : Use Linux capabilities library to control privilege + + filecaps : Use Linux file capabilities to control privilege rather than set*id Looks like the exact same thing to me.
Yes, this was discussed on the mailing list when the eclass was introduced and I still can't make my head clear about this stuff for the few cases we have to handle. I just seems to match the explanation from vapier though.
https://bugs.gentoo.org/show_bug.cgi?id=454908#c8 The same for me, I don't fully understand the reasoning but, since I even don't know much about fcaps...
