On Thu, 28 Apr 2022 at 14:02:46 +0100, Julian Gilbey wrote:
> On Thu, Apr 28, 2022 at 10:16:30AM +0100, Simon McVittie wrote:
> > According to the autopkgtest spec[1],
> >
> > Tests can expect that the $HOME environment variable to be set to
> > a directory that exists and is writeable by the user running the test.
>
> That's interesting; I don't find any code that sets HOME in
> autopkgtest.
The purpose of autopkgtest is to run the tests in a realistic environment
that resembles a real Debian desktop or server, but it doesn't know much
about how the testbed system is set up, so it relies on the virtualization
backend or the testbed itself to set HOME appropriately. Ideally, it
should be logging into a fully-working Debian system (perhaps under qemu
or lxc, or even on real hardware via ssh) and running tests there.
As I said on #986665, this seems like either a bug in
autopkgtest-virt-schroot, or misconfiguration in how you and Laurent
are configuring it (the schroot profile that you're telling it to use).
> Now I understand that better, it seems that changing the autopkgtest
> spec to say something more like the following, if it's true:
>
> The HOME environment variable is inherited from the calling
> process. It is up to the container manager to ensure that this
> directory exists and is writeable by the user running the test.
No, that would be wrong for the lxc, qemu and ssh backends, which all
rely on an ordinary user with a home directory existing inside the
testbed system, and don't inherit anything from the caller.
> (Incidentally, given that
> typically XDG_RUNTIME_DIR is in the ephemeral /run filesystem, writing
> to it would not violate policy 4.9.)
Policy ยง4.9 says that "Required targets must not attempt to write outside
of the unpacked source package tree", then makes a few exceptions for
locations like /tmp. /run is not one of those locations, so writing to
/run is not allowed.
> I wonder whether autopkgtest
> could consider setting up a temporary directory for this purpose like
> dh_auto_test does, rather than using the heavy machinery of
> libpam-systemd?
No, I don't think it should. The purpose of autopkgtest is to run the
tests in a realistic environment that resembles a real Debian desktop
or server. If real Debian systems are going to use libpam-systemd (which
they often do), then autopkgtest should make it possible to assert that
the overall system works, by connecting to a full-system container
(lxc, systemd-nspawn) or a virtual or real machine (qemu, ssh) and using
it as-is.
In particular, it would make sense to write an autopkgtest that looks
like this pseudocode:
Restrictions: isolation-container
Depends: dbus-user-session, gnome-keyring
connect to org.gnome.keyring via D-Bus session bus
send a command to org.gnome.keyring
assert success
as an integration test that simulates gnome-keyring being installed
on an ordinary desktop system, and asserts that it is started either
on-demand or as a side-effect of logging in. (Replace gnome-keyring
with any service of your choice - dconf, Tracker, Telepathy, AT-SPI,
PulseAudio, Pipewire, anything like that.)
That's not going to work with a mock XDG_RUNTIME_DIR, because the D-Bus
session bus that was run by dbus-user-session is listening on a socket in
the "real" XDG_RUNTIME_DIR provided by libpam-systemd, not the mock
XDG_RUNTIME_DIR that you propose autopkgtest should provide.
Making the test script set up a mock XDG_RUNTIME_DIR and a mock
session bus would be a less useful test, because that only proves that
gnome-keyring can work if you set up a mock environment by hand, and says
nothing about whether gnome-keyring genuinely works on a normal system.
Running gnome-keyring-daemon by hand would also be a less useful test,
because if its maintainer had broken the D-Bus/systemd integration
necessary to start it on real, production systems, then the test would
not detect that (it would still succeed).
smcv
