Daan De Meyer [Fri, 15 Jan 2021 19:51:42 +0000 (20:51 +0100)]
mkosi: Allow setting version-tag option via VERSION_TAG env variable
With https://github.com/systemd/mkosi/pull/630, we can set environment
variables for the build script in mkosi. Let's modify the build script
so we can set the version-tag option via an environment variable of the
same name. The default is the empty string which causes meson to fall
back to the default behavior (git version).
This variable (a.k.a. rootlibexecdir), was exposed through the .pc file, but
not as rpm macro.
The .pc file must be located in the package that provides libraries, which
pulls in a lot of dependencies. In Fedora, the macros are split out to a
separate package so that other packages which need to refer to some systemd
path but don't otherwise require it, can only pull in the (much smaller and
dependency-less) macros package. zram-generator uses the path to specify the
location of systemd-makefs, so by using the rpm macro we'll be able to use
a much smaller buildroot.
fs-util: make laccess() macro follow our usual error propagation
Functions defined by us are supposed to return negative errno-style
errors on errors. laccess() is for access() what lstat() is for stat(),
but defined by us as a macro. This led to some confusion regarding error
handling.
Let's return a negative errno code just in case. This means callers can
it use either way: like access(), i.e. checking for a negative return
value + looking at errno, or like our own code, i.e. using the negative
errno code it returns.
Getting the numbers right for all architectures has proven to be a
constant chore. Let's autogenerate the header from the tables that
were imported in one of the previous commits.
Fixes #18074. (Hopefully. I cannot verify this on all architectures.)
To update the lists, or to update the header after template changes:
ninja -C build update-syscall-tables update-syscall-header
Note: the generated file is saved in git. Initially I wanted to only
store the tables in git, and generate the header during each build.
Generation is quick enough, but the header is used in many many
places (wherever missing_syscall.h is included, directly or indirectly),
which means that we would need to declare the dependency in meson, so
the header would be generated early enough. This turned out to be very
noisy. Storing the generated header in version control avoids the hassle.
systemctl: avoid warning about signed-unsigned compare on 32 bits
../src/systemctl/systemctl-list-units.c: In function ‘output_units_list’:
../src/systemctl/systemctl-list-units.c:112:75: warning: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Wsign-compare]
112 | for (const UnitInfo *u = unit_infos; unit_infos && u - unit_infos < c; u++) {
| ^
The pointer difference is signed. I don't know why gcc warns on 32bits, but
not otherwise.
Gaël PORTAY [Thu, 31 Dec 2020 11:25:17 +0000 (06:25 -0500)]
veritysetup: remove unused globals
This removes the three global variables arg_root_hash, arg_data_what and
arg_hash_what which were presents since the beginning but were never
being used.
Gaël PORTAY [Sat, 14 Nov 2020 14:21:39 +0000 (09:21 -0500)]
veritysetup-generator: add support for veritytab
This adds the support for veritytab.
The veritytab file contains at most five fields, the first four are
mandatory, the last one is optional:
- The first field contains the name of the resulting verity volume; its
block device is set up /dev/mapper/</filename>.
- The second field contains a path to the underlying block data device,
or a specification of a block device via UUID= followed by the UUID.
- The third field contains a path to the underlying block hash device,
or a specification of a block device via UUID= followed by the UUID.
- The fourth field is the roothash in hexadecimal.
- The fifth field, if present, is a comma-delimited list of options.
The following options are recognized only: ignore-corruption,
restart-on-corruption, panic-on-corruption, ignore-zero-blocks,
check-at-most-once and root-hash-signature. The others options will
be implemented later.
Also, this adds support for the new kernel verity command line boolean
option "veritytab" which enables the read for veritytab, and the new
environment variable SYSTEMD_VERITYTAB which sets the path to the file
veritytab to read.