Saturday, 8 March 2014

Re: Launchpad buildds and capabilities

On Sat, Mar 08, 2014 at 07:09:39PM +0400, Dmitry Shachnev wrote:
> I am maintaining python-secretstorage package, and I would like to run
> gnome-keyring-daemon as part of the build process, to run the testsuite.
> However, I noticed that gnome-keyring-daemon fails to start in Launchpad
> buildd environment:

> gnome-keyring-daemon: error getting process capabilities, aborting

> This error message means that capng_have_capabilities() returns CAPNG_FAIL,
> which it turn likely means that the kernel has capabilities support disabled
> or broken.

> Is there any known workaround for that? Or, maybe, this can be fixed on
> Launchpad side?

> Note: I tried with PPA builders (elnath, marid and peryton to be specific),
> but I assume the archive builders behavior will be the same.

While Dimitri's recommendation to use DEP8 testing is a useful one, I think
this is probably a problem specific to the PPAs, which are still running an
older host kernel (despite obviously running current trusty userspace in the
build chroot). I suspect an incompatibility in libcap-ng, hinted at by this
note in the capget(2) manpage:

Kernels prior to 2.6.25 prefer 32-bit capabilities with version
_LINUX_CAPABILITY_VERSION_1, and kernels 2.6.25+ prefer 64-bit capabil‐
ities with version _LINUX_CAPABILITY_VERSION_2. Note, 64-bit capabili‐
ties use datap[0] and datap[1], whereas 32-bit capabilities use only
datap[0].

As the ppa host kernel is still < 2.6.25, I suspect you're seeing a problem
there that will *not* manifest on the distro builders (and which would stop
being an issue on the PPAs once we're able to upgrade their kernels).

You could help isolate whether this is a recent kernel/userspace
compatibility regression by trying to build in your ppa for releases prior
to saucy, which would have a different version of libcap-ng. The libcap-ng
code appears to *intend* to remain compatible with earlier kernels, so
upstream might welcome a report of the problem so they can either fix the
incompatibility, or stop trying to be compatible and drop the broken code.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
[email protected] [email protected]