I noticed that our coverage reports miss some files completely - this
happens when the test doesn't touch the code in them at all, so the
generated coverage data (and resulting reports) have no information
about them. Let's fix this by doing an initial zero coverage capture
that contains a zeroed counter for every instrumented line in every
file, so when we later merge it with a capture from the test, it shows up
with a missing coverage instead of not showing at all.
We need to expand the subshell expression during the `bash -c`
invocation, not before, to take the desired effect, as now it expands to:
timeout 30 bash -c 'while [[ 0 -eq 0 ]]; do sleep 1; done'
instead of the expected:
timeout 30 bash -c 'while [[ $(coredumpctl list -q --no-legend 770 | wc -l) -eq 0 ]]; do sleep 1; done'
Follow-up to aadbd81f7f.
testdata/ is shared by both the unit tests and the integration tests. Hence it
makes sense to place them right under /usr/lib/systemd/tests/ while the tests
themself are located under dedicated sub-directories:
/usr/lib/systemd/tests/
├── integration-tests
├── testdata
└── unit-tests
├── testdata -> ../testdata
However the unit tests implemented as shell scripts (such as
test-fstab-generator.sh) expect to find testdata/ where the scripts are
installed, ie they do something like:
src="$(dirname "$0")/testdata/test-fstab-generator"
This patch installs a symlink in 'unitestsdir' named "testdata" and that points
to whatever value 'testdata_dir' is set.
/usr/lib/systemd/tests may contain more than the unit tests. For example on
SUSE we also install the integration tests there.
Putting the unit tests in a dedicated directory named 'unit-tests' makes the
layout cleaner.
Note that `run-unit-tests.py` has not been moved so we don't need to adjust
(Fedora) packaging and users also don't need to descend into the subdirectory.
The test files are /proc//auxv files copies from various architecutres
signified by the file name suffix.
Those tests are fairly simple, but when we run them on n architectures, we do
~n² cross-arch tests.
The nvme by-id symlink changes to the latest namespace when a new namespace gets
added, for example by connecting multiple NVMe/TCP host controllers via nvme
connect-all.
That is incorrect for persistent device links.
The persistent symbolic device link should continue to point to the same NVMe
namespace throughout the lifetime of the current boot.
Therefore the namespace id needs to be added to the link name.
Fix check for conflicting and duplicate expressions of types that
support alternative patterns.
Fixes: 3ec58d0cd8 ("udev-rules: check for conflicting and duplicate expressions")
For some unknown reasons, the temporary directory created by the test
below is not removed:
```
# Test the case that a valid symlink is in the path.
label = 'valid_symlink-deep'
test_content('f= {} - - - - ' + label, label, user=user, subpath='/deep/1/2', path_cb=valid_symlink)
```
To keep /tmp clean, let's create the global temprary directory.
Log an error when a rule line contains conflicting match expressions, e.g.
NAME=="value", NAME!="value"
Log a warning when a rule line contains duplicate expressions, e.g.
NAME=="value", NAME=="value"
The interface requires services to write to the cgroup file to activate notifications,
but with ProtectControlGroups=yes we make it read-only. Add a writable bind mount.
Follow-up for 6bb0084204
Let image_install figures the binary paths out itself as not all distributions
ship the mkfs.* tools in the same location. For example openSUSE ships
mksquashfs in /usr/bin/.
When a rules contains several LABEL tokens, the parser used to silently
discard all of them besides the last one without any diagnostics at all.
It's time to break the vow of silence and let the parser issue a warning.
When udevadm verify is invoked without positional arguments, that is,
when no udev rules files are specified, load all rules files from the system
like the udev daemon does, and verify them.
On Debian the test fails because /run is noexec. Simply create the
script in /tmp (and use a BindPath=), as other tests are doing.
Follow-up for 3b7101183c
This drops all mentions of gnu-efi and its manual build machinery. A
future commit will bring bootloader builds back. A new bootloader meson
option is now used to control whether to build sd-boot and its userspace
tooling.
Frantisek Sumsal
Yu Watanabe
Franck Bui
Zbigniew Jędrzejewski-Szmek
Mike Yuan
Thomas Blume
Dmitry V. Levin
Daan De Meyer
Luca Boccassi
Jan Janssen