Source: schroot Version: 1.6.10-1+b1 Severity: wishlist Control: affects -1 + gnupg-agent dirmngr
As Tincho mentioned in https://bugs.debian.org/840883#20 , the lack of /run/user/$(id -u) can be problematic for processes interacting with per-user daemons or other per-user session mechanisms. At the moment, nothing exists at all in /run/user inside an schroot session. The two obvious options i see are: a) bind-mount the host's /run/user children, as Tincho suggests b) ephemerally create a new tmpfs for the schrooting user in /run/user/$(id -u) if it isn't already mounted. The problem with (a) is that the version and capabilities of the service (e.g. dbus, gpg-agent) using /run/user/NN/ sockets in the host may well differ from the version and capabilities needed by the clients running inside the chroot. So this bug report suggests a preference for (b), the more "isolated" approach. Upon disposal of the schroot, i'd expect the ephemerally-created tmpfs to be recursively deleted and then unmounted. There is a lengthy discussion over on gnupg-devel over whether software should be able to depend on having /run/user/$(id -u) available during its configuration, build and test. in https://lists.gnupg.org/pipermail/gnupg-devel/2017-March/032711.html, Werner Koch (GnuPG upstream) points out: > GnuPG's README now recommends the creation of /run/user. This suggests that any software that expects to run components of GnuPG during build or test (including GnuPG itself) is likely to have problems building or running tests within an schroot in the future until this issue is resolved. Regards, --dkg -- System Information: Debian Release: 9.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
