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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
I have multiple outstanding PRs that use it and they conflict on
this, so let's just upstream it now.
It helps avoid some use of `unsafe` talking to libc directly.
This is an exact copy of https://github.com/ostreedev/ostree/pull/1906
for now. From that commit message:
I'd like to add OpenShift's prow to this repository. Let's start
by adding a Dockerfile - it doesn't really do anything besides build.
However...I've lately been thinking about e.g. shipping the ostree tests
as an image, and then e.g. we could test FCOS by running that container
(which would orchestrate the host's ostree).
Anyways, not doing that right now but this is a start.
I was debugging a failure in cosa when running in unprivileged podman,
with this patch the error is:
`error: Importing package 'alternatives': Writing tmpfiles mtree: llistxattr: Is a directory`
And that finally made it obvious to me that the problem is not using
tmpfs for `/tmp` (well, this is a bug in fuse-overlayfs).
Anyways, let's prefix errors some more on general principle.
Closes: #1889
Approved by: rfairley
Since we have to pull it anyways to do a build, let's use it
as a buildroot. This should fix CI which broke because we were
doing a f29 build but cosa is f30, and libostree differed.
I wanted to use this in another project, and I don't think
we're the only ones. I extracted the code, added better docs
and tests, and published to crates.io:
https://crates.io/crates/openat-ext
When hoisting deploy flags from the option dict, we want the default
values to take effect *only if* the option wasn't specified in the dict.
Instead, because we initialized the return value with the default flags,
the option set couldn't override a flag which was part of the defaults
(IOW, a flag that's on by default couldn't be turned off through the
options dict).
Came upon this issue by trying to use the older `Deploy()` and
`Rebase()` D-Bus APIs which pass default values like `ALLOW_DOWNGRADE`,
but the option dict specifies `allow-downgrade=false`. (We could say,
"you should use the newer `UpdateDeployment()` API", but the cat is
mostly out of the bag at this point on options that get shoved into the
dict and take effect on both APIs).
In FCOS, we want to make sure that Zincati is always deploying a newer
tree to prevent downgrade attacks in certain threat models.
For completeness, also add the option to `rebase`.
* treefile: Rework test helper
Have each test clearly hold its tempdir; this way we can have a simple
helper function rather than a struct with an unreferenced parameter.
Also use `utils::write_file`.
Prep for further test work.
* treefile: Add a basic test for includes
Prep for adding an arch include test.
* treefile: Support `arch-include`
A long time ago we added architecture-specific package lists
via e.g. `packages-ppc64le`. Much more recently we added
support for having the `include` key be a list - multiple includes.
By combining these two and supporting architecture-conditional includes,
we've effectively added architecture-conditionals to *all* keys.
Notably we want this for Fedora CoreOS today which is using
`remove-from-packages` on `grub2-tools` which isn't present on
s390x.
* ci: Bump cosa build timeout
Looks like another OpenStack perf regression.
Currently [zincati](https://github.com/coreos/zincati/) executes
`rpm-ostree deploy` via the CLI - that just shows up as `cli` as
an agent. This makes it easier to highlight the fact that it's
actually zincati driving things.
Closes: #1880
Approved by: lucab
Use g_shell_quote to quote the value set for OSTREE_VERSION in
/etc/os-release as this is an arbitrary string set at compose time that
may contain whitespace or other special characters.
This edge case was found in [0] as the compose are built with the
following command:
$ rpm-ostree compose tree \
--repo="repo" \
--cachedir="cache" \
--add-metadata-string="version=Kinoite 30.23" \
"fedora-kinoite.yaml"
[0] https://discussion.fedoraproject.org/t/kinoite-a-kde-and-now-xfce-version-of-fedora-silverblue/147/95
Signed-off-by: Timothée Ravier <tim@siosm.fr>
Closes: #1873
Approved by: jlebon
I think we're in a good position now for FCOS enablement, and there are
a bunch of fixes we should get out, such as the zstd one.
Closes: #1875
Approved by: cgwalters
This may seem like a backflip on #1829, but there's a common theme here:
in a promotion workflow, the parent (or lack of parent) of a commit is
an important parameter, so we need full flexibility in configuring it.
But again, like #1829, we still want e.g. change detection, versioning,
and various optimizations to happen on whatever the latest commit on
that ref is in the build repo.
Closes: #1871
Approved by: cgwalters
I'm working on having Silverblue inherit from Fedora CoreOS. But
conceptually it also inherits from (parts of) Workstation.
It is just easier if we support multiple inheritance, then I don't
need to think too hard about how to make it a single inheritance chain.
Closes: #1870
Approved by: jlebon
We had essentially the same test in the `lockfile` and `treefile`
modules. Just dedupe those and move it to `utils`.
Closes: #1867
Approved by: cgwalters
When manually writing lockfile overrides (see previous commit), it's
sometimes easier to not have to specify the SHA256 of the package. For
example, in FCOS, all packages on development and production streams
will be sourced uniquely from coreos-pool, so there's no question of
where the package will come from. It's of course also easier in the
context of local development.
Another motivation for this though is a subtle interaction between
Fedora infra and the way we'd like to implement lockfile management: we
want the override process to be PR-based, with a privileged bot in the
backend tagging new overrides into the pool as necessary on merge.
However, packages built in Koji are initially unsigned, and so we can't
actually *know* what the SHA256 of the package will be until it's signed
and tagged into the pool by the bot.
Closes: #1867
Approved by: cgwalters
Teach `rpm-ostree compose tree` to accept multiple `--ex-lockfile`
arguments. In this case, later lockfiles can override the NEVRA for
packages specified in previous lockfiles.
This will be used in the FCOS pipeline, where we want to be able to have
a shared "base lockfile" and then stream-specific "override lockfiles".
I contemplated making this an `include: ...` key instead similar to the
manifests, but I'm not sure that paradigm fits as nicely for lockfiles.
Making it separate switches instead also makes it trivial to implement
in cosa.
(And of course, this is all still prefixed with `--ex` which means we
are at liberty of changing this interface later on after gaining some
experience with it).
Closes: #1867
Approved by: cgwalters
There are two reasons for this:
1. I'd like to add overrides semantics to lockfiles, and keying by the
package name only makes this much easier.
2. I'd like to make the digest optional, and keeping it as a tuple makes
this awkward.
A map seems natural too since it makes it more clear that we don't
expect multiple specifications for the same package name.
Another tiny advantage is that it's easier to process with e.g. `jq`.
Closes: #1867
Approved by: cgwalters
I wanted to modify the lockfile specification, but then remembered that
it currently lives in two places right now: once on the Rust side where
it's deserialized, and once more on the C side where it's serialized.
If we could write the lockfile from the Rust side, then we wouldn't have
to deal with the `GVariantBuild` and `json-glib` goop, and instead
we could consistently use serde against the same struct for both
serialization and deserialization.
But there isn't an easy way to do this given that the state to be
serialized is intrinsically linked to libdnf.
So this patch takes the next step in our oxidation process by adding a
minimal `libdnf_sys` module which allows us to call `libdnf` functions
from Rust. This is not the prettiest code I've written, and there's
definitely some polishing that could be done. But I think overall it's a
move in the right general direction: as we oxidize more things, we'll at
some point *have* to integrate more tightly with the C side in a
bidirectional way, instead of the "one-way" approach we've been using so
far.
For this patch specifically, in exchange we get a unique source of truth
for the lockfile spec, just like the treefile, and we drop a lot of C
code in the process.
Closes: #1867
Approved by: cgwalters
Let's just make it really obvious that this is the function that reads
the lockfile.
Prep for also having a symmetric `ror_lockfile_write` function.
Closes: #1867
Approved by: cgwalters
Tried a `--unified-core` build of Silverblue and it blew up on this.
Just copy-pasting the comment in the code:
34927af202
From a read of that script, none of it is necessary for rpm-ostree. It's about working around
bugs from a traditional RPM in-place update, but rpm-ostree always starts from a clean
filesystem checkout.
Closes: #1869
Approved by: jlebon
Move hashing to the Rust side so that we can easily hash over the final
set of inputs after parsing. This means that we now hash over all the
externals, like `add-files` references, any `postprocess-script` script,
and `passwd` and `group` files.
The original motivation for this was that hashing over a reserialized
version of the treefile was not deterministic now that treefiles include
hash tables (i.e. `add-commit-metadata`). So I initially included each
individual treefile as part of the hash.
I realized afterwards that just switching to `BTreeMap` fixes this, so
we can keep hashing only the final flattened reserialized treefile so we
ignore comments and whitespace too. But since I already wrote the patch,
and it fixes a real issue today... here we are.
One notable change though is that we now hash the treefile in non-pretty
mode to increase the chances that the serialized form remains stable.
Ironically, this change is likely to cause a no-op commit once it gets
to pipelines which iterate quickly. All for the greater good though.
Closes: #1865
Approved by: cgwalters
We were hitting the classic "negative test passes for the wrong reason".
It was failing not because it didn't have a parent, but because we
didn't pass `--repo`. Fix this and also explicitly check for the error
message we expect.
Closes: #1865
Approved by: cgwalters
Add support for a new `add-commit-metadata` key in the treefile so that
we can directly specify commit metadata we want to inject from there.
This will be useful in Fedora CoreOS, where we'll have separate
treefiles for each streams, each with stream-specific metadata values
required.
Closes: #1865
Approved by: cgwalters
Move up the setting of the treefile JSON object to right after parsing,
and move down the populating of the metadata hash table to after setting
the treefile JSON object. This is pure code block moves; there's no
functional change otherwise.
Prep for future patch.
Closes: #1865
Approved by: cgwalters
Split out from `rpmostree_composeutil_read_json_metadata_from_file` the
part that actually converts to `GVariant` and inserts into the hash
table.
Closes: #1865
Approved by: cgwalters
Instead of relying on `rpmostree_composeutil_read_json_metadata` to
initialize the metadata hash table, initialize it explicitly in
`context_new()` function and only call the util function if we were
passed a file with `--add-metadata-from-json`.
Accordingly rename the function
`rpmostree_composeutil_read_json_metadata_from_file`.
Closes: #1865
Approved by: cgwalters
Besides allowing ${releasever}, only do the substitution as the final
pass after merging the treefiles for all the keys (currently ${basearch}
and ${releasever}) instead of doing it per parse. This way we have the
expected semantics where one could do:
```
include: "fedora-coreos.yaml"
releasever: "42"
```
and have that releasever used.
Fixes#1809
Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com>
Closes: #1848
Approved by: cgwalters
The same way we abbreviate ReplacedBasePackages when there are matching
EVR diffs, let's do something similar for RemovedBasePackages for
matching EVRs.
Solves #1784
Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com>
Closes: #1852
Approved by: jlebon
Using glib_json to parse the lockfile yields some oddities like
everything being wrapped in a GVariant. Let's leave the parsing to serde
in the Rust side of things. Hopefully that'll make the lockfile easier
to extend in the future.
Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com>
Closes: #1851
Approved by: jlebon
And render it in status, so if the daemon is doing something
we know who started it. I'm doing this specifically because
gnome-software defaults to running `RefreshMd` but it's not
obvious that is happening.
Closes: #1859
Approved by: jlebon
This has been dead code since we merged the pkgcache into the main
repo. I noticed that the daemon is holding open two instances
of the system repo and came across this while trying to figure out
why.
Closes: #1853
Approved by: jlebon
I was reading this code for a different bug and noticed that
the dict wasn't always initialized if we happened to exit early
due to error.
Closes: #1856
Approved by: jlebon
Drop the use of Ansible everywhere. In the few cases where we really
Python, just spawn a container instead.
This is required to be able to hack on Fedora CoreOS.
Closes: #1850
Approved by: jlebon
The use case for `ostree-layers` is to support injecting non-RPM
content in a more flexible way than can be done with `add-files`,
and also without dropping all the way to split composes.
This starts with support on the `compose tree` side but down the
line I'd like to make it more convenient to do *client* side too.
For `ostree-override-layers` this is mainly a development thing
for tools like coreos-assembler. Rather than building an RPM
we just `make install DESTDIR` then commit and add to
`ostree-override-layers`.
Closes: #1830
Approved by: jlebon
One problem with how we use lockfiles right now is that we don't enforce
them for dependencies. That is, if `foo` requires `bar`, but only `foo`
is in the manifest, then while `foo` will be locked, `bar` will never
be checked against the lockfile because it was never explicitly
requested.
Higher-level though, I don't like how indirect the locking here feels.
See some comments about that in:
https://github.com/projectatomic/rpm-ostree/pull/1745#discussion_r288772527https://github.com/projectatomic/rpm-ostree/pull/1745#discussion_r289419017
Essentially, the manifest is an input file of patterns, and all we
really know from the lockfile output is that the set of packages in
there satisfies this input in some way. But:
1. there are multiple ways to satisfy the same input (hence why hints
like `SOLVER_FAVOR` exist)
2. the solution is dependent on how the solver is implemented (i.e.
different libsolv versions might yield different solutions)
3. the solution is dependent on flags fed to the solver (i.e. different
libdnf versions might yield different solutions)
So any attempt at cross-checking between the input file and the lockfile
is going to be very hard. Using a stricter mode as I suggested in #1745
of only allowing pure pkgnames or NEVRAs would help, but it wouldn't
address the dependency issue. (Though I'm still thinking about possibly
doing this anyway.)
The solution I propose here is instead to take the nuclear approach: we
completely exclude from the sack all packages of the same name as
packages in our lockfiles, but which do not match the NEVRA. Therefore,
any possible solution has to also satisfy our lockfile (or error out).
Closes: #1849
Approved by: cgwalters
Fixes#1670
This patch introduces a new `compose tree
--ex-write-lockfile-to=manifest.lock` argument and a new `compose tree
--ex-lockfile=manifest.lock` to read it back for subsequent invocations.
Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com>
Closes: #1745
Approved by: jlebon
Of course, update agents driving rpm-ostree know exactly to which commit
they want the system to upgrade, so `upgrade --lock-finalization` is not
helpful. Teach `deploy` the `--lock-finalization` switch too.
Closes: #1846
Approved by: lucab
Had to track down via strace that it was this that was failing
in my toolbox container.
Really need to merge the unified-core-only PR.
Closes: #1845
Approved by: jlebon
The `old` and `new` naming is odd. It implies a temporal relationship
between the two commits. Just rename those to the more apt "from" and
"to".
The difference is mostly cosmetic, but I didn't want to inherit this in
the new JSON interface. It does technically breaks the `diff` output
which is a somewhat machine-compatible interface, though the "ostree
diff commit" headers have been pretty freeform anyway, so I doubt anyone
is actually trying to read those.
Closes: #1844
Approved by: cgwalters
