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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
The cmp in ExecStartPost= was actually failing – ExecStartPost= has the
same StandardOutput as the rest of the service, so the output file is
truncated before cmp can compare it with the expected output – but the
test still passed because test_exec_standardoutput_truncate() calls
test(), which only checks the main result, rather than test_service(),
which checks the result of the whole service. Fix the test by merging
the ExecStartPost= into the ExecStart= – the cmp has to be part of the
same command line as the cat so that the file is not truncated between
the two processes.
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.
vcs_tag() is slow. When the version-tag meson option is set,
we can use configure_file() directly to speed up incremental
builds.
Before (with version-tag set to v247):
```
‣ Running build script...
[1/418] Generating version.h with a custom command
real 0m0.521s
user 0m0.229s
sys 0m0.067s
```
After (with version-tag set to v247):
```
‣ Running build script...
ninja: no work to do.
real 0m0.094s
user 0m0.048s
sys 0m0.022s
```
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.
../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.
gcc-10.2.1-9.fc33.x86_64, -m32
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.
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.
