These are used via dlopen only if available by some tools like
systemd-cryptsetup, systemd-cryptenroll and systemd-repart,
with graceful fallbacks if they are not found.
Build-depend on them so that the features get compiled in
(apart from stage1 builds), and add appropriate Suggests.
Closes: #991129#1003383
After splitting out the standalone binaries for sysusers and tmpfiles
into separate packages (which conflict with the main systemd package),
we can no longer use the '@' notation in the upstream test.
This reverts commit 5eeeb1b562 and also
adds systemd-tests and systemd-timesyncd to the upstream test
dependencies.
A lot of the dependencies are not needed but were originally added to
avoid a testbed reset and make it possible to reuse the testbed of the
upstream test. This turned out to be a maintenance problem and the
dependencies were not updated accordingly. Instead of trying to keep the
two tests in sync, trim down the boot-smoke dependencies to its bare
minimum.
Without `--plain` `systemctl` prints a circle (●) in the first column
for each failed service, which with the current code interferes with
attempted journal listing for each such service:
```
test_no_failed (__main__.ServicesTest)
No failed units ... -------- journal for failed service ● -----------
Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?).
-- Journal begins at Sun 2021-04-25 03:05:23 UTC, ends at Sun 2021-04-25 09:00:32 UTC. --
-- No entries --
FAIL
```
With the change to just call the upstream script to run the integration
tests, the packages to test need to be installed so the test-function
script can list out the files each package contains, and copy those files
into each nspawn and/or qemu testbed. Without all packages installed,
some tests fail; specifically TEST-30 currently requires systemd-timesyncd
which was not previously installed for the 'upstream' test suite.
This changes the control file to just install all binary packages, using
the '@' notation.
This applies an (upstreamed) patch to permit systemd-localed to run
locale-gen to generate missing locale when requested to switch the
system locale.
This makes localectl usable on Debian for changing locale without
breaking system localization or even prevent certain applications from
running at all after switching to a non-generated locale.
We are not really interested in the return code and error messages from
dbus-monitor after killing it, so ignore them to avoid undesired
autopkgtest failures.
Follow-up for commit 3de342799c.
Unconditionally back up/restore locale configuration files and generate
en_US.UTF-8. Previously the test failed in environments which have some
locale other than en_US.UTF-8 in /etc/default/locale.
Also fix the assertion of /etc/locale.conf not being present after
localectl. This only applies to Debian/Ubuntu tests, not upstream ones
(see Use-Debian-specific-config-files.patch)
Some kernels in Ubuntu (e.g. linux-kvm) do not enable CONFIG_PM, which
results in stderr output when the logind test tries to grep the power
state file, causing the test to fail. The test already handles skipping
the test if suspend isn't supported, so just use -s to suppress grep
from printing to stderr if the file doesn't exist.
Currently, the 'upstream' test runs all upstream-provided tests at tests/TEST-*,
except for any that are in a hardcoded list contained in this test.
Any change to the hardcoded blacklist involves patching the debian repo, which is
not an ideal way for upstream systemd to manage a hopefully temporary blacklist of
problematic tests.
There was discussion around making the blacklist entirely provided by an upstream
env var, configured in the upstream webhooks that control the Ubuntu CI tests,
but that results in 2 problems; 1) Debian would no longer be able to easily
control its own blacklist, and 2) upstream would only have an all-or-none control
over the blacklist, meaning that it could only enable or disable any specific
test for all PRs; it could not enable a test for only a specific PR that was
attempting to fix the flaky test (for example).
This approach moves blacklist control into the systemd tests themselves, by changing
the 'upstream' test to look for a file in the test directory, and skipping the test
if such file is found. This way, Debian (and Ubuntu and other Debian derivatives)
can continue to manage their own blacklist, but also upstream can control
the blacklist for individual tests on a per-PR basis.
For example, if upstream has the file 'tests/TEST-01-BASIC/blacklist-ubuntu-ci'
in its repo, Ubuntu CI will skip this test for all PRs opened. Then, a PR can
be opened that both fixes the test, as well as removes this file. The Ubuntu CI
will then run the test, but only for the PR that attempts to fix it. Once that
PR is merged, all future tests will then run the fixed test.
The specific naming of the per-test blacklist file, for tests run from the
upstream repo, is either "blacklist-ubuntu-ci" to completely blacklist the test
on all archs, or "blacklist-ubuntu-ci-$DPKGARCH" to blacklist the test only
for a specific arch, for example "blacklist-ubuntu-ci-amd64". For tests run
from Debian (or Ubuntu), which are run without the TEST_UPSTREAM param set,
the blacklist filename is 'blacklist-upstream-ci[-$DPKGARCH]'.
Note that the $DPKGARCH is specified as the value returned by
'dpkg --print-architecture', not the value returned from 'uname -m' (e.g.
to blacklist a test for intel 64-bit, 'amd64' should be used, not 'x86_64').
This naming matches the title of the ubuntu tests, such as 'bionic-amd64',
'bionic-arm64', etc.
polkit.service is started on-demand via D-Bus activation. This means it
is not a good indicator if a boot was successful. Instead check if
NetworkManager is running as it is started via multi-user.target.
Closes: #934992
The check for is-system-running handles verifying that systemd completes
all its jobs during startup, making this test redundant. Also, since the
testbed can (and does) start more jobs after is-system-running, this test
can provide a false negative if any of those jobs continue running after
this check's timeout.
There is currently no delay to wait for is-system-running to reach running
or degraded, so it's very possible for there to be running jobs. This adds
a delay until is-system-running is 'running' or 'degraded', and gathers
extra artifacts if the system is 'degraded'.
Additional details are in this Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825997
Note that bug description states:
"This patch is not required for debian, because debian's boot-smoke does
not include the wait for systemctl is-system-running", however this patch
adds that wait, because without it, the check for running jobs can easily
fail, if the system isn't fully running yet.
