At this point it just pulls the first field off the version string
which should be good enough. Only Fedora uses $releasever in yum repos
and the major version number works there.
There was only one case where this was being used and it was simple
to convert that into just a check against the stream name. Let's
drop it here to simplify and accelerate our draining of "variable"
information out of the manifests.
The koji repo reflects all the latest packages built for riscv.
The fedora-riscv repo isn't updated frequently so let's include
the koji repo so we can get all the latest packages.
There is an effort to build all of Fedora using the RISCV architecture.
This comment adds the yum repo files and also conditionalizes some
manifest items to make it possible to build for `riscv64`.
There are still some other pieces that need to land before builds
will succeed (like bootupd support for riscv64), but this is a start
in the right direction.
xref: https://github.com/coreos/fedora-coreos-tracker/issues/1931
Now that rpm-ostree supports templating more fields, we can drain the
manifest even more and keep all the common templatable cruft in
`fedora-coreos.yaml`.
Currently, we have to manually check if fast-tracked packages have made
it into the Fedora repos and drop them. This GitHub Action automates
this process.
It also formalizes the process of pinning packages a bit by adding
guidelines for metadata keys overrides should use to be more explicit.
This code was originally introduced in 0352445.
We need to move it out of manifest.yaml because that file doesn't get
synced across branches. We want it to get synced everywhere.
In Fedora 33 systemd-networkd will be broken out into a subpackage and
we won't need to explicitly remove the files from the package. To
prepare for that let's move the `remove-from-packages` bit into the
manifest.yaml which doesn't get synced across branches with config-bot.
This will allow testing-devel, testing, and stable to keep removing
the networkd bits until they move to Fedora 33, while at the same time
allowing next-devel and next to not have the remove-from-packages bit.
In order to make chrony use NTP settings from DHCP (https://github.com/coreos/fedora-coreos-config/pull/412),
we need to chmod the following files to unset the writable permissions. Git tracks only the executable bit
of the permissions so when the files get pulled locally they could have the group write bit set. When that
happens we get an error like: `Cannot execute '/etc/NetworkManager/dispatcher.d/20-coreos-chrony-dhcp': writable by group or other`
We'd like to make the next `testing` release be f32-based now that it's
been in `next` for two releases. To do that, we should have it bake in
`testing-devel` a bit ahead of release.
The pool repo isn't semantically an ordinary like the others. It
contains past and present locked packages used in any Fedora CoreOS
stream. Mark it as a lockfile repo instead to tell rpm-ostree to only
use this repo for fetching locked packages and never to try to freely
depsolve with it on.
Pretty straight-forward. The one tricky bit is that we need to
temporarily use the `fedora-next` repos since the repo structure still
uses `development/` for now. We'll switch those over at GA.
We're currently releasing AMIs with a description field of the form
"Fedora CoreOS base image <version>". Let's include the stream name in
the rojig summary for each stream.
Copy over the license and name fields because that appears to be
required.
Now that we've completely switched over to lockfiles, we need to
describe the procedure for adding new packages to the OS.
Also add back the Bodhi repos to make the task easier. Otherwise, we'd
get a bootstrapping problem: we can't add packages not tagged in
coreos-pool, but the tagger won't tag a package that's not added.
But also, we really want those repos there by default so that the local
dev case of pulling in all new packages can just be
`cosa fetch --update-lockfile`.
Make `manifest.yaml` be the "stream identity". I.e. this is the thing
that will *not* change from merges across branches. Crucially, it
includes the `ref` and the `repos`.
