We switched rawhide over to the buildah path in the pipeline, but we
want anyone/anything building rawhide to do the same. cosa recently
learned to read `metadata.build_with_buildah` for this.
Make use of it.
The fedora-rawhide-nodebug-kernel repo was added in [1]
and is what we'll be using exclusively for our rawhide
kernels in the future because we've wasted too much time
with debug kernels.
[1] https://github.com/coreos/fedora-coreos-config/pull/1932
The cliwrap code has existed for a long, long time. However,
things change now with the advent of ostree-native containers.
I think it Just Makes Sense to enable `yum install foo` inside
an ostree container, which the code now does when this flag is enabled.
This will *also* cause the cliwrap code to appear on the host, but
I think that's less confusing than not doing so.
The cliwrap code has existed for a long, long time. However,
things change now with the advent of ostree-native containers.
I think it Just Makes Sense to enable `yum install foo` inside
an ostree container, which the code now does when this flag is enabled.
This will *also* cause the cliwrap code to appear on the host, but
I think that's less confusing than not doing so.
aardvark-dns, which provides name resolution based on container name,
is recommended by netavark but not required. We need to name is so
it gets pulled in.
The ownership of nsswitch.conf has moved to authselect in F36+
and right now the file is created by running authselect in a
%posttrans, which fails. We need to work around this problem.
This workaround is twofold:
- Manually input nsswitch.conf during the build process so
that rpm-ostree won't fail when it tries to inject altfiles.
- Run `authselect` on first boot to create all the files it needs
and re-add altfiles entries to newly created nsswitch.conf.
Workaround for https://github.com/coreos/fedora-coreos-tracker/issues/1051
This is forked and adapted from testing-devel:
- drop lockfiles, this is a mechanical stream
- bump releasever to 34
- switch to using the rawhide repo
- substitute `testing-devel` to `rawhide` in `manifest.yaml`
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`.
