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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This is to allow compiling composefs on machines having somewhat old
Linux kernel headers.
Signed-off-by: Rogerio Guerra Borin <rogerio.borin@toradex.com>
We've long struggled with semantics for `/var`. Our stance of
"/var should start out empty and be managed by the OS" is a strict
one, that pushes things closer to the original systemd upstream
ideal of the "OS state is in /usr".
However...well, a few things. First, we had some legacy bits
here which were always populating the deployment `/var`. I don't
think we need that if systemd is in use, so detect if the tree
has `usr/lib/tmpfiles.d`, and don't create that stuff at
`ostree admin stateroot-init` time if so.
Building on that then, we have the stateroot `var` starting out
actually empty.
When we do a deployment, if the stateroot `var` is empty,
make a copy (reflink if possible of course) of the commit's `/var`
into it.
This matches the semantics that Docker created with volumes,
and this is sufficiently simple and easy to explain that I think
it's closer to the right thing to do.
Crucially...it's just really handy to have some pre-existing
directories in `/var` in container images, because Docker (and podman/kube/etc)
don't run systemd and hence don't run `tmpfiles.d` on startup.
I really hit on the fact that we need `/var/tmp` in our container
images by default for example.
So there's still some overlap here with e.g. `/usr/lib/tmpfiles.d/var.conf`
as shipped by systemd, but that's fine - they don't actually conflict
per se.
The ordering of the includes apparently matters...and I didn't
actually check that the previous change enables composefs on c9s.
But I did now. For reals.
While we have the patient open, I switched to `AC_LANG_PROGRAM`
because I originally thought the bug had something to do with that.
As far as I understand, more cleanly separating the includes
from the injected body text is a useful thing in `AC_LANG_PROGRAM`.
As I (and others) will be backporting the fix in
de6fddc6ad
pretty far, I want a way for sysadmins and OS builders to
be able to reliably see when their version of ostree has this fix
(Because comparing version numbers isn't portable).
There's no additional dependencies, and it's a small amount
of new code.
The riskiest thing is the changes to ostree-prepare-root, but
I believe that things are in a good state now there.
Again, this just enables it at *build time* - it's still
off at runtime by default.
There's no reason to have these distinct really. If we're using
libsodium, we want it in the same places we're using openssl.
Prep for further refactoring.
See https://github.com/ostreedev/ostree/issues/1593
Basically this makes it easier for people packaging, as the trivial-httpd
is only for tests, and this way the binary will live with the tests.
Also at this point nothing should depend on `ostree trivial-httpd`.
With f461c02bb5 use of gpg_strerror_r
was added this symbol comes from libgpg-error however, therefore its
needed to add -lgpg-error to cmdline to resolve this symbol especially
with gold and lld linker. Fixes
aarch64-yoe-linux-ld.lld: error: undefined reference due to --no-allow-shlib-undefined: gpg_strerror_r
>>> referenced by ./.libs/libostree-1.so
Instead of using pkg-config, etc we just include composefs.
In the end the library is just 5 c source files, and it is set up
to be easy to use as a submodule.
For now, composefs support is disabled by default.
This supports checking out a commit into a tree which is then
converted into a composefs image containing fs-verity digests for all
the regular files, and payloads that are relative to a the
`repo/objects` directory of a bare ostree repo.
Some specal files are always created in the image. This ensures that
various directories (usr, etc, boot, var, sysroot) exists in the
created image, even if they were not in the source commit. These are
needed (as bindmount targets) if you want to boot from the image. In
the non-composefs case these are just created as needed in the checked
out deploydir, but we can't do that here.
This is all controlled by the new ex-integrity config section, which
has the following layout:
```
[ex-integrity]
fsverity=yes/no/maybe
composefs=yes/no/maybe
composefs-apply-sig=yes/no
composefs-add-metadata=yes/no
composefs-keyfiile=/a/path
composefs-certfile=/a/path
```
The `fsverity` key overrides the old `ex-fsverity` section if
specified. The default for all these is for the new behaviour to be
disabled. Additionally, enabling composefs implies fsverity defaults
to `maybe`, to avoid having to set both.
This leads to private symbols being exported.
Also specify the single C header, this relies on the gir_C_INCLUDES make variable,
which was introduced in gobject-introspection 1.51.5.
This tweaks autoconf logic in order to use pkg-config for gpgme
and gpg-error when available.
Recent versions of gpgme directly provide threaded support, and
gpg-error started shipping a .pc file. Thus on recent distributions
it is possible to directly use pkg-config for both. On older
environments, the legacy logic is kept in place.
