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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We want to run the unit tests after a build, so do that.
Furthermore, this actually installs the binaries, which
means if we do it as part of a `Dockerfile` build, we
can use that image for further testing.
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
This has a bit of history, but essentially in 1c01141e, we made both
`upgrade` and `deploy` automatically exit 77 if there were no changes.
Then in c3f1e7c8, we only changed `upgrade` so that it became gated
behind `--upgrade-unchanged-exit-77`.
I think we should carry this forward into `deploy` as well. The way I
look at this is: the default UX shouldn't require users to care about
special exit codes. That's something scripts care about. In its vanilla
form, either a command should error out or succeed.
This patch tries to add some consistency by introducing a new
`--unchanged-exit-77` in both `deploy` and `upgrade` (where it just
replaces the previous switch). The naming here matches what `install`
has too.
So... this does break backwards compatibility for any scripts which
relied on that behaviour. Though the only app I know today which wants
deploy semantics and doesn't use the D-Bus API is Zincati, which
actually hit this issue. There's also RHCOS, though the `pivot` there
uses `rebase`, not `deploy`. So overall, I think this is worth breaking
now while we're still in a transitionary period in the downstreams?
Closes: #1906
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
This is an experiment in using Jenkins pipelines for our CI. See similar
initiatives in coreos-assembler[1] and fedora-coreos-config[2].
For now, this only does the following testing:
- checks commit for unintended submodule bumps
- checks the minimum Rust version
- builds RPMs
- builds FCOS (with the new RPMs both for executing the build
itself, as well as included in the built OS)
There are dummy placeholders for where we'd actually run the vmcheck
and the compose testsuites. Let's address those trickier parts as
follow-ups.
[1] https://github.com/coreos/coreos-assembler/pull/667
[2] https://github.com/coreos/fedora-coreos-config/pull/131Closes: #1899
Approved by: cgwalters
Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.
Closes: #1903
Approved by: jlebon
`umask` is one of those really evil Unix things...it's pretty
crazy actually there's still no threadsafe way to "`mkdir` ignoring umask".
This surfaced in someone using coreos-assembler with a working
directory of mode `0750` and having that surface in the target
rootfs.
Ref: https://github.com/coreos/fedora-coreos-tracker/issues/272Closes: #1902
Approved by: jlebon
This is one of the tests right now that assumes it's running on f29.
We might be sort of in this awkward dual path for a while where we want
tests to run on both f29 (i.e. FAH) and f30 (i.e. FCOS).
Closes: #1900
Approved by: cgwalters
From Rust v1.37, `cargo vendor` is now baked. Stop building it, and
tweak the vendoring script to adapt to the new UX.
Closes: #1900
Approved by: cgwalters
So this is a somewhat significant change, but I'd like to try having the
canonical spec file upstream. A few reasons for this:
1. We integrate tightly with the distros we're destined for, and so
we're in a pretty good position for knowing how the software should
be packaged.
2. We can atomically change packaging along with the rest of the code.
This has important ramifications, including that it'll be easier to
integrate with continuous build services like Packit, but releases
will also be less fraught with last-minute packaging fixes.
3. I'm playing with Jenkins pipelines and there I'd like to make RPMs
the "artifact" that gets moved down the pipeline into later stages
(e.g. `cosa build`). We could even eventually make it an actual
external artifact so that anyone can easily download RPMs from any
random PR for testing. (And in fact, with a thin yumrepo layer on
top, it could be used to replace Packit/rdgo entirely).
Not that this approach doesn't have issues as well (e.g. on the dist-git
side, we'll need some minimal tooling to merge in the changelog), though
I think it's worth trying out.
Closes: #1900
Approved by: cgwalters
This is a bit of a hack, but does the trick now. Eventually, we'll need
to either bump rdgo to f30, or set up continuous builds some other way
(e.g. Packit or Jenkins pipelines).
Closes: #1900
Approved by: cgwalters
Jenkins' `checkout scm` gives us the exact commit that we're testing.
Allow passing that to the submodule commit message checker so it doesn't
use `HEAD` (which is likely GitHub's merge commit).
Closes: #1900
Approved by: cgwalters
The command isn't interesting right now (the YAML treefile stuff mostly obsoletes it)
and the CI context costs money/time.
Closes: #1898
Approved by: jlebon
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
Point at FCOS and not Project Atomic. Add an inline "Why"
section since people will want to know that right away.
(An great thing about Github is the prevalence it gives to `README.md`;
projects should use that as an "elevator pitch")
Drop outdated bits in `background.md`.
Closes: #1895
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.
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
