2.1.19 testing failures on the debian build daemons

[Daniel Kahn Gillmor]

On Tue 2017-03-21 17:37:37 -0400, Werner Koch wrote:
> On Tue, 21 Mar 2017 21:52, kristian.fiskerstrand at sumptuouscapital.com
> said:
>
>> Throw an error and point to part of documentation for how to use
>> %Assuan% socket= redirection?
>
> I like to remove this hack in 2.3 - it requires too much admin work and
> thus it is easier to simply create /run/user, for example in rc.local:
>
> --8<---------------cut here---------------start------------->8---
> [ ! -d /run/user ] && mkdir /run/user
> awk -F: </etc/passwd '$3 >= 1000 && $3 < 65000 {print $3}' \
>   | ( while read uid rest; do
>         if [ ! -d "/run/user/$uid" ]; then
> 	  mkdir /run/user/$uid
> 	  chown $uid /run/user/$uid
> 	  chmod 700 /run/user/$uid
> 	fi
>       done )
> --8<---------------cut here---------------end--------------->8---

Putting this in rc.local won't fix the situation where there's a chroot
(which is the case for many debian build daemons, and probably other
targeted/minimalist build environments)

> BTW, the use of /tmp is just fine as long as you create a sub directory.
> This is how X has always worked.  In fact, the test suite does just
> this.

The trouble with /tmp is figuring out which directory to use.  If
$GNUPGHOME itself is in /tmp, that's one thing -- the env var itself
points to a location that needs to be owned by the user.

But if GNUPGHOME is unset, or if it is not itself in /tmp, how are the
daemons and their client supposed to agree on a rendevous point in /tmp
?

> Note also that the socket file system problem exists on many NFS or
> Samba mounted home directories.  Not just on FAT file systems.

sure, that's what i described as point (b):

>>>  b) $GNUPGHOME/S.gpg-agent : this might be on a remote filesystem or a
>>>     filesystem that cannot support unix-domain sockets (e.g. fat32 on a
>>>     thumbdrive)

Regards,

        --dkg