Allow --rerun-build-scripts in combination with none output
To make the logic work without being able to check if the output
exists or not, we simply never write the history if --rerun-build-scripts
if specified with the none output format.
It wants a date in the format Y-m-d H:M:S rather than unix seconds.
Also if SOURCE_DATE_EPOCH is not defined, use actual epoch, as the
timestamps must match when creating the signature and when attaching
it
DEBUG is very generic and can picked up by anything, but sometimes
with drastically different meanings to what is supposed to be in the
environment variable value.
For example the xfstests configure script expects DEBUG to contain
compiler options, which makes it break in extremely hard to debug
ways if we set DEBUG ourselves to a boolean value.
Changing the working directory to mkosi/ is not intuitive. We want
to parse configuration from there, but the working directory should
not change (e.g. you don't want mkosi sandbox to execute inside the
mkosi/ subdirectory when invoked in the top level directory).
Use mkosi/ subdirectory if no configuration exists in cwd
In systemd we've ended up with a large amount of mkosi specific
files and directories in the top level of the repository. Let's allow
moving these to a mkosi/ directory by transparently picking this up.
Don't allow configuring distribution, release and mirror in tools tree config
config_default_repository_key_check() depends on ToolsTreeDistribution=
to select the right default. If the tools tree distribution is configured
in mkosi.tools.conf, we're unable to select the right default for
RepositoryKeyCheck= for the main image. Until we figure out a decent solution
for this, let's insist that the tools tree distribution is configured via
ToolsTreeDistribution=.
Similarly, selecting the default tools tree mirror depends on the selected
target distribution and mirror, so we insist on configuring the tools tree
mirror and release via ToolsTreeMirror= and ToolsTreeRelease= for now.
Currently we assume fetching is not required if the host distribution
is not ubuntu, but this is wrong. If the host distribution is not ubuntu
but a ubuntu tools tree is used to build rpm based or Arch images, then
we still need key fetching.
Additionally, make RepositoryKeyFetch= a universal setting so that the
tools tree can have it enabled without enabling it for the main and subimages.
We then also drop the condition from config_default_repository_key_fetch()
that checks whether we need key fetching to build the tools tree distribution
because this will be determined automatically now when parsing the tools tree
config.
initrd: Copy Arch Linux keyring from host when running as root
When running as root, we run with --cache-only=metadata, which means
we won't try to sync the keyring, so let's reuse the one from the host
to make sure that a keyring is available.
Daan De Meyer [Mon, 31 Mar 2025 12:37:27 +0000 (14:37 +0200)]
Allow adding extra tools tree configuration via mkosi.tools.conf
Instead of adding ever more ToolsTreeXXX= settings, let's allow
adding extra tools tree configuration via mkosi.tools.conf which can
be either a file or a directory containing extra configuration for the
default tools tree.
Daan De Meyer [Mon, 31 Mar 2025 08:46:41 +0000 (10:46 +0200)]
Switch tools tree parsing to ParseContext
Default tools tree configuration currently depends on manually plumbing
through settings from the main configuration to the tools tree configuration.
This has already bitten us a few times where we forgot to add the necessary
plumbing when adding a new setting.
Instead, let's improve by encoding in the settings themselves whether they
apply to the tools tree or not. We call settings that apply to the tools tree
and all subimages "multiversal" settings (one step bigger than "universal"
settings).
For the tools tree specific settings (e.g. ToolsTreeDistribution= and friends),
we simply copy the fields from the main image configuration namespace to the tools
tree configuration namespace.
Additionally, we restrict which settings can be applied to the tools tree by
a new "tools" field for each setting which has to be set to True to make a setting
configurable in the default tools tree configuration.
Finally, we stop storing the tools tree specific settings in the main image config,
and instead store the tools tree configuration separately in the history JSON and
summary. This will allow us to add more ways to configure the default tools tree in
the future as well.
Daan De Meyer [Sun, 30 Mar 2025 19:42:03 +0000 (21:42 +0200)]
config: Use dicts everywhere in favor of argparse.Namespace()
These behave the same, except that argparse.Namespace() allows dot
based accessed to its keys and dict does not. Dot based access suggests
to the reader that a typed property is being accessed that definitely
exists, whereas that's anything but guaranteed when using argparse.Namespace().
Let's switch to using dicts everywhere so that whenever we access a
property, we do so in a way that suggests to the reader that we're doing
an untyped access into a dictionary.
Daan De Meyer [Sun, 30 Mar 2025 15:10:00 +0000 (17:10 +0200)]
Disable selinux relabeling by default for directory images
For directory images it's more likely to not want these selinux
relabeled, so let's default to that. Also drop the explicitly selinux
relabeling disablement from mkosi-tools.
Daan De Meyer [Sun, 30 Mar 2025 15:02:00 +0000 (17:02 +0200)]
mkosi-tools: Stop removing BuildSources=
Tools tree prepare scripts are now a thing so it's possible to require
build sources for the default tools tree so let's stop removing them
unconditionally.
Daan De Meyer [Sat, 29 Mar 2025 12:06:29 +0000 (13:06 +0100)]
Introduce 'main' setting scope
There's a bunch of settings that aren't universal but also don't make
sense to be configured in subimages, so let's add a new 'main' setting
scope that disallows configuring these settings in subimages without
passing them to subimages.
Daan De Meyer [Fri, 28 Mar 2025 09:19:29 +0000 (10:19 +0100)]
Allow combining --force and --rerun-build-scripts
Until now we didn't allow this, but it turns out there's actually
a use case for this, build the image if it doesn't exist yet, reuse
the existing image otherwise.
mkosi-initrd: fix misleading "mkosi not found" error message
There is a special handling when a script under /work fails with 127, which is
also reached when mkosi is called within mkosi-initrd.
```
‣ Running finalize script /etc/mkosi-initrd/mkosi.finalize…
/work/finalize: line 5: strip: command not found
‣ /work/finalize failed with non-zero exit code 127
‣ (Maybe a program was not found or the script interpreter (e.g. bash) is not installed?)
‣ mkosi not found.
```
Daan De Meyer [Thu, 27 Mar 2025 16:27:02 +0000 (17:27 +0100)]
pacman: Always bind mount /var/lib/pacman/local from sandbox
We want any writes to /var/lib/pacman/local to go to any configured
overlayfs on /buildroot, instead of going directly to the
/var/lib/pacman/local directory which might be a lowerdir in the
overlayfs if one is used. Let's implement this by simply specifying
a path relative to the sandbox instead of specifying the path on the
host.
Daan De Meyer [Thu, 27 Mar 2025 10:43:23 +0000 (11:43 +0100)]
config: Cache lookups of fields
We were calling inspect.signature() > 4000 times because it was evaluated
over and over again in the list comprehensions. Move the fields lookup into
a cached classmethod where possible to make sure we only do it once.
This reduces the time needed to parse the systemd config from history from
1.18s => 188ms on my machine.
Daan De Meyer [Tue, 25 Mar 2025 21:13:42 +0000 (22:13 +0100)]
Don't cache the package manager used in the tools tree cache manifest
Doing this causes issues when using mkosi sandbox as have_cache(tools)
will be different inside and outside of the sandbox when building Fedora
and only dnf is available outside the sandbox but dnf5 is available inside
the sandbox. Since we don't need to cache the package manager used anyway
when building the default tools tree because we don't cache the package
manager metadata either, don't cache it to avoid this problem.
Daan De Meyer [Tue, 25 Mar 2025 19:28:51 +0000 (20:28 +0100)]
Implement ToolsTreeSyncScripts=
In systemd, we have prepare scripts for the build image to install
all the build dependencies of the corresponding distribution's systemd
packaging spec. The distribution packaging spec is checked out by a sync
script.
We also need the systemd build dependencies installed in the default tools
tree in systemd, so that we can build all the systemd tools required to build
the image in the tools tree as well to later be used to build the image. Currently
we list the the required dependencies manually as packages since we can't reuse
the prepare script from the build image as the sync scripts run after the default
tools tree has been built which means we can't depend on the packaging specs
being available when building the default tools tree.
Let's fix the issue by introducing ToolsTreeSyncScripts= to define sync scripts
to run before building the default tools tree.
Daan De Meyer [Tue, 25 Mar 2025 15:42:38 +0000 (16:42 +0100)]
Drop logic for using /root/.cache
Let's just have root use the cache in /var/cache/mkosi to avoid accidentally
leaking files into /root/.cache accidentally where it's much less likely that
they'll ever get cleaned up.
Daan De Meyer [Tue, 25 Mar 2025 13:41:26 +0000 (14:41 +0100)]
Make sure tools tree recorded in history doesn't change when in sandbox
Currently, when in the sandbox, the tools tree will always be recorded
as "null" in the history. This causes problems if an image build is done
inside of mkosi sandbox and mkosi is later invoked outside of the sandbox
as the history will say no tools tree was used and so the tools tree won't
be used, even if we're running outside of the sandbox.
To fix the issue, let's make sure we always record the proper tools tree,
but let's not make use of it in the sandbox by moving the sandbox check to
the Config object's tools() method.
We also simplify all the tools tree related checks in run_verb() and add a
check to make sure we don't try to rebuild the default tools tree when in
"mkosi sandbox" as that can't ever work.
Daan De Meyer [Tue, 25 Mar 2025 14:20:12 +0000 (15:20 +0100)]
Store default tools tree outside of output directory
A common workflow is to build the same image multiple times with
slightly different settings, using a different output directory for
each build. By storing the default tools tree inside the configured
output directory, we end up rebuilding the tools tree for every single
one of these builds, even though in almost all cases the tools tree for
each image will be identical.
Let's address this issue by not storing the default tools tree in the
configured output directory but instead storing it in the current working
directory.
Daan De Meyer [Mon, 24 Mar 2025 10:52:39 +0000 (11:52 +0100)]
tools: Add "devel" profile
This profile contains tools required to build C/C++ projects. This is
useful to use mkosi sandbox to quickly build one off projects without
having to list a bunch of basic packages over and over again.
Daan De Meyer [Mon, 24 Mar 2025 09:31:43 +0000 (10:31 +0100)]
Always cache the default tools tree
For the default tools tree, the cached image and the final image
are the same for all intents and purposes, so let's stop storing both
a cached image and a final image for the default tools tree and instead
only store the final image and use it as the cached image by always
writing a cache manifest next to it.
At the same time always use the name mkosi.tools to reduce the chance
of conflicts as "tools" is an incredibly common directory name.
Daan De Meyer [Sat, 22 Mar 2025 12:07:19 +0000 (13:07 +0100)]
run: Bind mount entire /home into relaxed sandbox
Let's simplify things and make the entirety of /home available. The
relaxed sandbox is not about security, and permissions already make sure
only the user's own home can be accessed.
Daan De Meyer [Sat, 22 Mar 2025 11:23:37 +0000 (12:23 +0100)]
Make sync script sandbox more relaxed
Let's simplify and mount in the entirety of /home, /run and the
invoking user's environment to make stuff just work more often than
not and avoid too many implementation details of specific tools leaking
into mkosi itself.