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 previously ran out of steam in the switch and wanted to
get the PR out for feedback before continuing, but it turns
out I basically stopped 2 meters from the finish line. Completing
the switch from `failure` → `anyhow` was quite easy.
The failure crate isn't actively developed anymore. The
main benefit of `anyhow` is it uses the standard error type.
More info:
https://docs.rs/crate/anyhow/1.0.28
Start the porting process.
Note that the `envsubst` crate has a public dependency on
`failure`, so we need to start mapping its errors.
The ostree test suite was creating deployments manually
(skipping the rpm-ostree upgrader layer which would write history)
and then calling `rpm-ostree cleanup` which tried to open the
history dir and failed.
Just return early if there's no history directory when we're
asked to clean up.
In FCOS we have a kola test that basically does `rpm -q python`.
It's...a bit silly to spawn a whole VM for this. Ensuring that
some specific packages don't get included has come up in a few
cases.
I think FCOS/RHCOS at least will want to blacklist `dnf` for example.
And as noted above, FCOS could blacklist `python`.
One major benefit of doing this inside rpm-ostree is that one
gets the full "libsolv error message experience" when dependency
resolution fails, e.g. blacklisting `glibc` I get:
```
Problem 79: conflicting requests
- package coreos-installer-systemd-0.1.2-1.fc31.x86_64 requires coreos-installer = 0.1.2-1.fc31, but none of the providers can be installed
- package coreos-installer-0.1.2-1.fc31.x86_64 requires rtld(GNU_HASH), but none of the providers can be installed
- package glibc-2.30-10.fc31.x86_64 is filtered out by exclude filtering
- package glibc-2.30-7.fc31.x86_64 is filtered out by exclude filtering
- package glibc-2.30-8.fc31.x86_64 is filtered out by exclude filtering
- package glibc-2.30-5.fc31.i686 is filtered out by exclude filtering
- package glibc-2.30-5.fc31.x86_64 is filtered out by exclude filtering
- package glibc-2.30-10.fc31.i686 is filtered out by exclude filtering
```
This makes it easier to flatten a treefile. To do this, we make having a
workdir optional on the Rust side, and on the C side, just move
`--print-only` handling up front.
The parent of a `Path` of `"foobar"` is actually `""`, because
`parent()` wants to return a slice of its buffer:
https://github.com/rust-lang/rust/issues/36861
Just do a trivial wrapper around it to correctly return `"."` instead.
Hit this when trying to pass a treefile in the working directory.
This allows replacing the `.` in automatic version increments
with whatever one wants (as long as it's a single ASCII character)
right now.
The specific motivation here is for at least RHEL CoreOS to use
`version-suffix: "-"` so that its versions can become valid
semantic versions.
Related: https://github.com/coreos/rpm-ostree/issues/1954
E.g. the generation timestamp, repos that were enabled, and their
generation timestamps.
This is just generally useful, though I'd like to make use specifically
of the new `metadata.generated` key in FCOS to drive versioning:
https://github.com/coreos/fedora-coreos-releng-automation/pull/50
All this does is put the immutable bit on the target directory.
The intention is to replace this bit to start:
8b205bfbb9/src/create_disk.sh (L229)
However, the real goal here is to add code in this file
to handle redeploying the rootfs for Fedora CoreOS which
combines OSTree+Ignition:
https://github.com/coreos/fedora-coreos-tracker/issues/94
Basically doing this in proper Rust is going to be a lot
nicer than shell script in dracut modules. Among other
details, coreutils `mv` doesn't seem to do the right thing
for SELinux labels when policy isn't loaded.
This is the rpm-ostree equivalent of `dnf history`. As opposed to the
history of the refspec (i.e. `ostree log`), this shows the history of
the system, i.e. the refspecs the host deployed, checksums, versions,
layered packages, etc... The amount of details remembered is similar to
what shows up in `status`.
There's definitely some further enhancements possible (e.g. printing
package diffs, displaying rollbacks), though this seems in good enough
shape as a first cut.
Closes: #1489Closes: #1813
Approved by: cgwalters
We were merging some keys with list values by overriding the full list
instead of appending. Fix those.
Also add some missing keys we weren't merging at all.
Closes: #1908
Approved by: cgwalters
We have contacted all contributors to the code in `rust/` and
that code is now all relicensed under the "standard Rust license"
of `Apache 2.0 OR MIT`.
[Due to an accident](https://github.com/projectatomic/rpm-ostree/issues/1890),
some GPLv2+ code was imported in the C side, and we're unlikely to
easily change that now. Make this more official by adding the GPLv2.
I'd like to go through the C code and add SPDX and possibly investigate
relicensing some of the GPLv2+ code to LGPLv2+ but, not right now.
For a bit more about Rust and SPDX, see [this issue](https://github.com/rust-lang/cargo/issues/2039).
Closes: https://github.com/projectatomic/rpm-ostree/issues/1890Closes: #1897
Approved by: jlebon
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.
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
* 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.
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
