It turns out that checking for the last mount time of an ext4 file
system isn't a very reliable way to check whether the file system was
properly unmounted.
When creating that test in the first place (88530e02b6),
I was reluctant to inspect the file system when the VM is down and was
searching for a way to check for a clean unmount *after* the file system
was mounted again to make sure we don't need to create a 512 MB raw
image on the host.
Fortunately however, when converting from qcow2, qemu-img actually
writes a sparse file, so for most file systems (that is, file systems
supporting sparse files) this shouldn't waste a lot of disk space.
So when investigating the flakiness, I found that whenever the test is
failing, the unmount of /test-x-initrd-mount was done *before* the final
step during which systemd remounts+unmounts all the remaining file
systems.
I haven't investigated why this is the case, but the test is a
regression test for https://github.com/NixOS/nixpkgs/issues/35268, which
actually didn't unmount the file system *at* *all*, so really all we
need to take care here is whether the unmount has happened and not
*how*.
To make sure that checking the filesystem state is enough for this, I
temporarily replaced the $machine->shutdown call with $machine->crash
and verified that the file system state is "not clean".
Signed-off-by: aszlig <aszlig@nix.build>
Fixes: https://github.com/NixOS/nixpkgs/issues/67555
It currently lacks an emoji font-family which means it has to be
disabled for them to function [0]. Additionally it's fallen out of
necessity to ship custom font rendering settings (as far as I'm aware
of).
[0]: https://github.com/NixOS/nixpkgs/pull/67215
pyo3-pack has been renamed to maturin version 0.7.0. Other larger
changes are:
- Mixed rust/python layout
- Added PEP 517 support
- Support settings all applicable fields from the python core
metadata specification in Cargo.toml
Any system uid will do, so we let the system allocate
one for us. The 'mailman' group is gone entirely since
we don't need it. Users who wish to run the 'mailman'
administration utility can do so via 'sudo':
$ sudo -u mailman mailman info
Also, simplify the syntax of our user.users entry to
rely on an attribute set rather than a list.
I want to add that I'm personally not a fan of this and I think we
should eventually drop these aliases to closely match the eco-system
rather than relying on some ad-hoc names created years ago.