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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Let's try to do regular-ish bumps again. Both for fixes and features,
but also so we eat regressions as they come rather than all at once when
we actually need something new there really fast.
Update submodule: libdnf
There's a lot going on here, but essentially:
1. We change the `vmcheck` model so that it always operates on an
immutable base image. It takes that image and dynamically launches a
separate VM for each test using `kola spawn`. This means we can drop
a lot of hacks around re-using the same VMs.
2. Following from 1., `vmoverlay` now takes as input a base image,
overlays the built rpm-ostree bits, then creates a new base image. Of
course, we don't have to do this in CI, because we build FCOS with
the freshly built RPMs (so it uses `SKIP_VMOVERLAY=1`). `vmoverlay`
then will be more for the developer case where one doesn't want to
iterate via `cosa build` to test rpm-ostree changes. I say "will"
because the functionality doesn't exist yet; I'd like to enhance
`cosa dev-overlay` to do this. (Note `vmsync` should still works just
as before too.)
3. `vmcheck` can be run without building the tree first, as
`tests/vmcheck.sh`. The `make vmcheck` target still exists though for
finger compatibility and better meshing with `vmoverlay` in the
developer case.
What's really nice about using kola spawn is that it takes care of a lot
of things for us, such as the qemu command, journal and console
gathering, and SSH.
Similarly to the compose testsuites, we're using parallel here to run
multiple vmcheck tests at once. (On developer laptops, we cap
parallelism at `$(nproc) - 1`).
This is a hack to allow using `inject-pkglist` without having to build
the tree first.
Higher-level, I think we can split this back out again if we have a
`-tests` subpackage where we ship the vmcheck testsuite.
That way, anyone can easily download the latest built RPMs from master
or a specific PR. This isn't a replacement for automated builds in Koji
though since it's not multi-arch.
Also fetch the tags so that the NEVRA derived from `git describe` is
nicer.
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
Rather than giving dracut `cap_mknod` which won't work in
unprivileged scenarios, append a tiny static pre-generated CPIO
blob with `/dev/random` and `/dev/urandom` to the output of
dracut.
This is a hack until dracut does this itself. But the problem
is patches to dracut will take eleven billion years to ship
in RHCOS.
Closes: https://github.com/coreos/rpm-ostree/issues/1950
A lot of history with this. But essentially, dracut tries to `mknod` a
few character devices like `/dev/random` and `/dev/urandom` and fails.
We originally blocked `cap_mknod` because, well, `%post` scripts don't
really need to do that, and it would get wiped anyway. But there is a
use case for dracut's CPIO: we want `/dev/*random` to be available in
early boot *before* systemd even mounts `devtmpfs` because libgcrypt as
part of its constructor-time selftests in FIPS mode wants to read from
there.
For more fun, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1778940https://bugzilla.redhat.com/show_bug.cgi?id=1401444https://bugzilla.redhat.com/show_bug.cgi?id=1380866
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
As mentioned in the comment block:
```
If there's an HMAC file, fix the path to the kernel in it to be
relative. Right now, the kernel spec encodes `/boot/vmlinux-$kver`,
which of course not going to work for us. We should work towards making
this change directly into the kernel spec.
```
For background, see this comment and following:
https://github.com/ostreedev/ostree/pull/1962#issuecomment-547488164
It's much easier to mess up with the latter than the former when
building filenames. There's a bunch more all over the codebase; just did
this bit to be consistent with the next commit which also uses it.
I don't understand why this doesn't happen in more places;
it may have to do with the depth of the call chain?
Anyways, add some more asserts that values aren't NULL.
We don't *actually* use this ourself, but librepo does, and libdnf gets confused
if librepo doesn't support it. This is the case in RHEL8 currently.
Basically what breaks is trying to use the Fedora EPEL repo (has zchunk metadata)
on RHEL CoreOS. And we have a test in kola that does this today.
Don't just filter down packages by NEVRA, but also filter out those that
don't match the checksum too. We were enforcing checksum matches already
before this, but only *after* depsolving and simply erroring out if they
didn't match.
However, because of how RPM signing is implemented in Fedora, it is
possible to have the same NEVRA in two different repos, each with two
different hashes. E.g. right now for example, `efivar-libs` wasn't
rebuilt for f31, and so f31 is just shipping the f30 RPM, but signed
with the f31 key. And of course, we also had the f30 version in the
pool.
This patch allows us to transition over to the f31 version with
everything else by not getting thrown off by the f30 version already in
the pool. (Still need to investigate how the pool will deal with this.)
This was useful in combination with Homu since it only had to watch one
context. Since we're not using Homu anymore (and Tide instead looks at
all statuses by default), let's just drop it. This brings down the
number of statuses on PRs by one more (and so one less context to
override when needed).
Relatedly, also just test on `master` now.
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.
Jenkins is tricky: it does an initial checkout, merges the PR head into
the target branch, then creates the pod. Once in the pod, we do a
`checkout scm` which *also* merges the PR head into the target branch.
However, the `change.GIT_COMMIT` variable we get from that is set to the
SHA of the first merge, not the second one. Which... yeah is super
confusing since we explicitly assign `change` from that `checkout scm`
operation. So that's probably a valid bug.
This was then throwing off `ci-commitmessage-submodules.sh` since it
didn't find the merge commit in the graph.
Anyway, not going to spend more time on this. Let's just not pass any
commit at all. The git range `origin/master..HEAD` already does what we
want (go through all the commits in HEAD *not* in master).
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
