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