2.1.19 testing failures on the debian build daemons

Werner Koch wk at gnupg.org
Thu Mar 23 08:10:53 CET 2017


On Wed, 22 Mar 2017 19:35, dkg at fifthhorseman.net said:

> I've started the process of proposing such a change for schroot in
> particular (https://bugs.debian.org/858466), but there are many other
> similar systems that might be relevant.

Right, but they always had that problem with GnuPG 2.  Except for the
bug in 2.1.19 which broke things.

> In the meantime, do we want to say that all of those build environments
> that don't create /run/user/$(id -u) are not approved for building
> GnuPG?  or do we want to try to make it work?

This is the case only iff they are testing GnuPG in a directory with a
too long name or on a remote file system.  We have been living with this
limitation for a long time.  The wrokaround was either to switch to /tmp
or to disable the tests.

What about testing in configure for /run/user and printing a warning if
that does not exist?  This would only benefit the gnupg build process
and not other software but this should help to rise awareness.

> I think we're talking about any software build/test process that might
> invoke GnuPG at some point.  right?

Do we have an actual case here?

> Is this documented somewhere for software that depends on GnuPG?  The

Let me add this as a hint to the debugging section of the GnUPG manual.

> use of a statically-named /tmp/$mydir doesn't seem safe, since someone

I am sure you know hot to create an custum value for this.

> And what should we do for software that depends on GnuPG but doesn't
> know it?  For example, software that relies on a PAM stack which might
> include some gpg-related PAM module, or software that links to a library

/run/user is better than the other solutions.  IIRC we had more support
requests due to remote file systems than due to too long directory
names.

I mentioned it in some other mail: I would agree to try creating sub
directories below /run/user/$UID/gnupg instead of relying on
--create-socketdir.  In case we ever run into problems with that we can
add a configure options to disable this auto-creation.


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170323/5aa3e2c2/attachment.sig>


More information about the Gnupg-devel mailing list