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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
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.
