IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
If we're not debugging tests, there's no point in persisting the journal,
so let's use the volatile journal storage mode in that case to avoid doing
unnecessary work.
We don't disable journal storage alltogether since various tests check
that stuff is written to the journal.
Unfortunately the current mkosi partitioning setup is a bit too
avant-garde for the integration tests. Both in that distributions
aren't ready for it yet (some more than others), and that software
which we depend on in the integration tests isn't ready for it yet
(e.g. libselinux does not read its configuration from /usr).
Let's switch back to a more boring partioning setup by default but
keep the fancy stuff around as a mkosi profile. This means that it
can still be used for manually testing stuff by running
"mkosi --profile particle -f qemu".
Dependencies in .SRCINFO can be versioned. Let's make sure we ignore
any specified versions when grepping it for dependencies. Also update
the arch submodule to the latest to make sure the change works.
TEST-17-UDEV expects to find scsi_debug and TEST-84-STORAGETM expects to
find nvmet-tcp.
This isn't ideal as it adds firmware, microcode and other drivers to the
initramfs, but there's no linux-modules-extra virtual package
to just include the extra modules.
This commit adds definitions to build the minimal_0 and minimal_1
images with mkosi and includes them into the system image. We also
move the building of the various app-xxx and similar images that are
extremely minimal into the tests itself by moving the related logic
from install_verity_minimal() into a new function
install_extension_images() in util.sh. Because the mkosi /usr is
read-only, we now place the extension images in /tmp instead of
/usr/share.
Co-authored-by: Richard Maw <richard.maw@codethink.co.uk>
Co-authored-by: sam-leonard-ct <sam.leonard@codethink.co.uk>
We do the image build and run the tests in a btrfs loopback so we
can make use of btrfs subvolumes and COW to keep the disk space
requirements to a minimum and speed up the ephemeral copies we make
of the image to run the tests.
We also switch to building debug packages and publishing the built
packages as artifacts.
Building debug packages on ubuntu requires the "debug" option to be
specified explicitly. Debug packages on Ubuntu have the .ddeb extension,
so let's make sure we handle that by copying the .ddeb packages in the
build script as well.
-ffile-prefix-map= implies -fmacro-prefix-map= which is incompatible
with our definition of PROJECT_FILE.
See https://github.com/systemd/systemd/issues/32417.
-fdebug-prefix-map= only affects debuginfo without affecting macros.
isc-dhcp-server does not ship units, only sysv scripts, so the mkosi
presets that disable it have no effect. The generated unit is started on
each boot and fails, causing delays and noise.
Mask it so that the generated unit is overridden. It is installed only
to bring in binaries used by the networkd tests anyway.
These don't get pulled in automatically and there doesn't seem to
be a "system-users" package so install the ones we need for the
integration tests manually.
CentOS does not ship these sysusers dropins which set up basic system
users and groups. Until we can move to CentOS Stream 10, let's add the
dropins ourselves to make sure the base system users/groups are available
on CentOS.
The Arch Linux PKGBUILD does not (yet) have versioned dependencies
between the systemd packages, causing systemd-libs to not get updated
to 256-devel if systemd 256-devel is installed. Let's explicitly install
the newer version of systemd-libs as well for now until this problem is
fixed.
This introduces dependencies on various environment variables set
by rpmbuild which will not be set when rerunning meson inside the
VM/container so let's disable package notes to avoid these dependencies,
as the package notes aren't terribly useful in this scenario anyway.
CentOS/Fedora use annobin which will complain if FORTIFY_SOURCE=0
is used so we disable those checks to avoid the warnings.
We also make sure that when we query the compilation flags so we can
add more, we set _fortify_level=0 and undefine _lto_flags so that we
don't get those flags in the result.
When we're building debuginfo packages, the original binaries and
libraries are stripped so make sure we install the debuginfo
packages to make sure debugging in the container/VM still works.
This doesn't actually work because the opensuse spec doesn't allow
adding extra build flags, but I'm working on fixing that, so let's
already set things up for later.
-Og still causes a lot of "<optimized out>" in GDB so let's use -O0
instead and disable FORTIFY_SOURCE as it doesn't work without
optimizations enabled.
This makes sure that the debuginfo files contain source files pointing
to the source files shipped by the debugsource package.
Normally this should be done automatically by rpm invoking debugedit
but for some unknown reason debugedit refuses to rewrite the source
files in our binaries.
Given that debugedit is completely undebugable (does not generate any
logs at all, and its source code is ridiculously obtuse), let's set
-ffile-prefix-map= when building instead which achieves the same
effect.
This allows building debug packages by setting WITH_DEBUG=1. This
slows down the build a lot so it's opt in. We don't yet install
these but can do so in a future commit.
The entire build environment is ephemeral anyway so everything is
cleaned regardless. By specifying --noclean, we make debugging
easier as the rpm build root can be inspected when using --debug-shell.
- We have ssh-generator now, so need for mkosi's Ssh= option anymore.
- By enabling RuntimeBuildSources= by default, we don't need the gdb
config file in the image anymore, since the build and source
directories will be mounted at the expected locations.
