<term><cmdsynopsis> is not valid, causing the command to not be rendered
correctly.
Create one <variablelist> per <cmdsynopsis>. Inelegant but maintains
desired formatting.
Closes#2581
We want to parse a new "bls-append-except-default" key from ostree config. The
key-value pairs specified by this key will be added to the generated
BLS fragments of non-default deployments. They must follow the format
"key1,value1;key2,value2" and so on.
This change will allow us to land GRUB password support in FCOS.
Relevant: https://github.com/coreos/fedora-coreos-tracker/issues/134
There's a pile of new warnings in GCC 12 from F36, I dug into
them but most of them seem inscrutable - I am not seeing the bugs.
For now to unblock further work, stop using this flag.
I'm aiming to do some more work on the Rust side around `fsck`
like functionality, and this is a useful primitive. There isn't
a great Rust crate for xattrs, and I think it's better to share this
code.
It's really tempting to remove `make syntax-check`, it has very
very rarely found any real problems.
But anyways, just exclude all the binding code because it trips
up random problems we simply don't care about like mentions of
`O_NDELAY` in the `GLib-2.0.gir`.
Fix up the paths for the crates now that the Rust bindings are in
`rust/`.
We can't today include the test suite because it depends on `ostree-rs-ext`
which would make everything circular.
(Building that now requires a separate `cd tests/inst && cargo build`)
I want to write APIs that *require* the caller to have set up
an ostree transaction. It's natural to require passing a guard
to do so. But then we want an accessor for the repo.
The underlying `ostree_repo_load_file()` API has the caller pass
`NULL` for output arguments it doesn't want. This isn't sanely
bindable in Rust - what the generator does is always request
all values, but maps them all to `Option<T>`.
The main cases are where a user wants either metadata, or both
metadata and content. This API gives just metadata; it's a
bit more efficient as we don't need to open the file, and doesn't
require the caller to `unwrap()`.
Today we hardcode `/bin/bash` in
2088d24884/src/cmd-build (L405)
But that breaks the concept of a bidirectional bridge between
container image and ostree commit because this little bit of
knowledge is encoded at the buildsystem side.
This metadata key is intended to be written into an ostree commit,
and then we will use it automatically in `container encapsulate`.
The "source of truth" for this key will hence be able live in the same
place that's generating the ostree commit.
The more "proper" place for this is probably alongside the other
constants in the libostree core C code. But that's tedious and
slow to release. And Rust is the future. And we've been slowly
adding more "core ostree" functionality here.
Huijing Hei
Colin Walters
Dusty Mabe
Nikita Dubrovskii
Yosuke Matsumura
Saqib Ali
Joseph Marrero Corchado
Luca Bruno
dependabot[bot]