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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- bump the requred minimum version of meson to 0.62.0,
- use install_symlink(), which is supported since meson-0.61.0,
- use more features provided by newer meson with careful
conditionalization.
Follow-up for 8442ac9c0264ac7beb5afd6c3bf922030a6edaf3.
Closes#35967.
Now our baseline of meson is 0.62, hence install_symlink() can be used.
Note, install_symlink() implies install_emptydir() for specified
install_dir. Hence, this also drops several unnecessary
install_emptydir() calls.
Note, the function currently does not support 'relative' and 'force' flags,
so several 'ln -frsT' inline calls cannot be replaced.
Then, we can drop ugly workaround in meson.build.
The .link file is not necessarily synced with 99-default.link.
Also, 99-default.link is not updated so frequently.
Let's manually sync it when necessary.
The commit 8442ac9c0264ac7beb5afd6c3bf922030a6edaf3 set
install_tag option to install_emptydir() calls, but it requires
meson-0.62.0. Hence, after the commit, we cannot build systemd
with older meson anymore. As using install_tag is quite useful
for building systemd package, let's bump the requirement of
meson version to 0.62.0.
Note, the current meson versions of major distributions are:
CentOS 9: 0.63.3
CentOS 10: 1.4.1
Fedora 40: 1.4.1
Fedora 41: 1.5.1
Ubuntu 20.04 LTS (focal): 0.53.2 -- EOL on 2025-04
Ubuntu 22.04 LTS (jammy): 0.61.2 -- EOL on 2027-04
Ubuntu 24.04 LTS (noble): 1.3.2
Ubuntu 24.10 (oracular): 1.5.2
Debian 11 (bullseye): 0.56.2 (1.0.0 in backports) -- EOL on 2024-08
Debian 12 (bookworm): 1.0.1 (1.5.1 in backports)
openSUSE Leap 15.6: 1.6.1
openSUSE Tumbleweed: 1.6.1
As the next version (v258) is not expected to be released before
the end of 2025-04, it is OK to cut the support of Ubuntu 20.04 LTS and
Debian 11. Also, our policy for support of distributions explicitly says
only latest Ubuntu LTS and non-LTS releases are supported.
Hence, we can also cut Ubuntu 22.04, even if it is not EOL.
Follow-up for 8442ac9c0264ac7beb5afd6c3bf922030a6edaf3.
Closes#35967.
Scripts used to detect files that should be in POTFILES.in, like
intltool-update -m used on https://l10n.gnome.org/module/systemd/,
falsely detect these files as containing translations. Avoid this
behavior by putting the files in POTFILES.skip.
For these objectives we ought to execve() at the end, i.e. if we
ever hit the return path something went wrong in do_reexecute().
Let's properly report that via retval.
Follow-up for aaa27e2e21c04339914f26b7125789087eb51166
The commit described about system potentially becoming undebuggable
after switching into broken root or whatnot. But notably we can never
activate emergency.target after do_reexecute() failure, since the Manager
has been destructed. Plus, for a normal reexecution the fallback shell logic
triggered on non-existent /sbin/init is kinda useful. Let's hence guard
the extra check behind switch-root.
Also, move the check below /run/nextroot/ detection.
Support including the data that was signed inside the PKCS#7 signature.
This creates a self-contained file where the signature of the data can
be verified without any other information, since the file contains the
data, signature, and certificate (which contains the public key used for
the signing).
One use case of this is IPE which requires a PKCS#7 signature that is
not "detached", i.e. includes the IPE configuration that has been
signed.
This also slightly adjusts the test case to use the x509 certificate
inside the PKCS#7 signature instead of supplying it externally during
verification.
if Lennart shall dogfood ParticleOS he needs acceptable tooling for
making his homed home dir accessible from his legacy fedora install, and
from local and remote particleos. Let's add explicit support for
scenarios like this:
1. add high level support for enrolling the account signing key from the
fedora install
2. add high level support for "adopting" a local but foreign .home file
on a system
3. add high level support for "registering" a remote user account on a
different system
(this lacks test cases and some docs, hence marked as wip)
Let's define a clean way how we can reestablish file watches in homed.
This is a relevant in case we overmount /home/ as a whole. It's very
useful for our testcase in particular.
When unregistering a home there's a chance this "reveals" another home
by the same name in /home/, hence immediately schedule a rescan, the
same way we already schedule it in on remove.
Also, drop the conditionalization when scheduling a rescan during
remove, for the same reasons: a remove might reveal another home, and we
cannot check for that ahead of time. Trying to check is kinda a
pointless optimization anyway, since this is not a frequent operation
and rescanning is not the end of the world.
Currently homed scans /home/ via inotify for new .home + .homedir/
popping up to register as local users. Let's also add an explicit way to
request this form of "adoption": a bus call that takes a path and that
makes a home dir activatable locally.
(Usecase: you cross boot between two systems – let's say your traditional
fedora and your ParticleOS – and want to use the same homedir from both:
simply mount the /home dir from the other somewhere, and then hit
"homectl adopt /somewhere/lennart.home" and you have the user locally
too).
Since this only covers user creation/registration for now, let's hide it
behind an env var. We might reconsider this eventually and make it a
proper switch one day, but who knows, it after all has this "debug tool"
wiff.
