Re-review F45 Change: RelocateRpmRepoConfigsToUsr

gotmax23 commented

2026-08-11 22:11:16 +00:00

Owner

(in the spirit of avoiding ticket necromancy, I've made a new ticket and put it on next week's agenda)

Originally posted by @adamwill in #3606 (comment)

Did anyone ever check everything that depends on python3-dnf - i.e. the DNF 4 Python bindings - to see how they would be affected by this?

[adamw@toolbx fedora-toolbox-44 os-autoinst-distri-fedora (dnf-repo-dir-discover *%)]$ sudo dnf --releasever=rawhide repoquery --whatrequires python3-dnf
...
copr-builder-0:1.8-4.fc45.x86_64
dnf-bootc-0:4.24.0-5.fc45.noarch
dnf-plugin-diff-0:2.1-3.fc45.x86_64
dnf-utils-0:4.10.1-11.fc45.noarch
etckeeper-dnf-0:1.18.22-9.fc45.noarch
fedora-easy-karma-0:1.0-1.fc45.noarch
fedora-review-0:0.11.0-6.fc45.noarch
fedrq-0:1.7.0-2.fc45.noarch
kiwi-systemdeps-core-0:10.3.0-4.fc45.x86_64
mock-core-configs-0:44.4-2.fc45.noarch
modulemd-tools-0:0.16-16.fc45.noarch
needrestart-0:3.8-10.fc45.noarch
osbuild-tools-0:187-3.fc45.x86_64
osbuild-tools-0:189-1.fc45.x86_64
pungi-0:4.13.0-3.fc45.noarch
python3-coprtree-0:0.1.2-1.fc45.noarch
python3-dnf-plugin-cow-0:0.0.4-17.fc45.noarch
python3-dnf-plugin-flunk_dependent_remove-0:1.0-25.fc45.noarch
python3-dnf-plugin-perfmetrics-0:1.0-23.fc45.noarch
python3-dnf-plugins-core-0:4.10.1-11.fc45.noarch
python3-dnf-plugins-extras-common-0:4.1.2-13.fc45.noarch
python3-imgcreate-1:31.0-23.fc45.x86_64
python3-libreport-0:2.17.15-13.fc45.x86_64
retrace-server-0:1.24.2-17.fc45.noarch
subscription-manager-0:1.30.14-5.fc45.x86_64
system-config-language-0:3.5.1-3.fc45.noarch

There are several important things in there: fedora-easy-karma, fedora-review, fedrq, kiwi, osbuild, pungi, mock...any of those that rely on the system repository definitions is now likely broken. I'm quite worried this change was not sufficiently reviewed.

(in the spirit of avoiding ticket necromancy, I've made a new ticket and put it on next week's agenda) _Originally posted by @adamwill in https://forge.fedoraproject.org/fesco/tickets/issues/3606#issuecomment-1263807_ Did anyone ever check everything that depends on python3-dnf - i.e. the DNF 4 Python bindings - to see how they would be affected by this? ``` [adamw@toolbx fedora-toolbox-44 os-autoinst-distri-fedora (dnf-repo-dir-discover *%)]$ sudo dnf --releasever=rawhide repoquery --whatrequires python3-dnf ... copr-builder-0:1.8-4.fc45.x86_64 dnf-bootc-0:4.24.0-5.fc45.noarch dnf-plugin-diff-0:2.1-3.fc45.x86_64 dnf-utils-0:4.10.1-11.fc45.noarch etckeeper-dnf-0:1.18.22-9.fc45.noarch fedora-easy-karma-0:1.0-1.fc45.noarch fedora-review-0:0.11.0-6.fc45.noarch fedrq-0:1.7.0-2.fc45.noarch kiwi-systemdeps-core-0:10.3.0-4.fc45.x86_64 mock-core-configs-0:44.4-2.fc45.noarch modulemd-tools-0:0.16-16.fc45.noarch needrestart-0:3.8-10.fc45.noarch osbuild-tools-0:187-3.fc45.x86_64 osbuild-tools-0:189-1.fc45.x86_64 pungi-0:4.13.0-3.fc45.noarch python3-coprtree-0:0.1.2-1.fc45.noarch python3-dnf-plugin-cow-0:0.0.4-17.fc45.noarch python3-dnf-plugin-flunk_dependent_remove-0:1.0-25.fc45.noarch python3-dnf-plugin-perfmetrics-0:1.0-23.fc45.noarch python3-dnf-plugins-core-0:4.10.1-11.fc45.noarch python3-dnf-plugins-extras-common-0:4.1.2-13.fc45.noarch python3-imgcreate-1:31.0-23.fc45.x86_64 python3-libreport-0:2.17.15-13.fc45.x86_64 retrace-server-0:1.24.2-17.fc45.noarch subscription-manager-0:1.30.14-5.fc45.x86_64 system-config-language-0:3.5.1-3.fc45.noarch ``` There are several important things in there: fedora-easy-karma, fedora-review, fedrq, kiwi, osbuild, pungi, mock...any of those that rely on the system repository definitions is now likely broken. I'm quite worried this change was not sufficiently reviewed.

gotmax23 added the

meeting

label

2026-08-11 22:11:36 +00:00

gotmax23 commented

2026-08-11 22:31:41 +00:00

Author

Owner

Additional details about some packages in the above list:

I quickly checked fedora-easy-karma. It seems to only use the dnf (dnf4) API to query for already-installed packages in @system. This should be unaffected.
fedrq is not affected. It supports both libdnf5 and dnf Python API backends.
mock-core-configs is likely not affected. It has a boolean dependency that supports either dnf5 or python3-dnf.
osbuild was already ported to libdnf5 AFAIK. It seems only osbuild-mpp in the osbuild-tools subpackage unconditionally imports dnf but still defaults to using libdnf5.
Some of these packages are dnf4 CLI plugins. As far as I understand, it's already known that this Change means the dnf4 CLI (and the old dnf Python API) won't be able to read system repositories anymore, but dnf4 is considered deprecated in favor of dnf5. It would be really nice to have a compat mechanism here while we still have python3-dnf around.
Not sure about modulemd-tools but we don't have Modularity anymore.
I'm not sure about fedora-review. I thought there were efforts to fully port it to dnf5, but I'm not sure if those were completed. I recall there was some shelling out to /usr/bin/dnf-3.
Not sure about retrace-server. Isn't that tied to the ABRT server stuff that is going away?
pungi still uses the old dnf Python API, but it does not call read_all_repos() anywhere, so that shouldn't be affected either.

Additional details about some packages in the above list: - I quickly checked fedora-easy-karma. It seems to only use the dnf (dnf4) API to query for already-installed packages in `@system`. This should be unaffected. - fedrq is not affected. It supports both libdnf5 and dnf Python API backends. - mock-core-configs is likely not affected. It has a boolean dependency that supports either dnf5 or python3-dnf. - osbuild was already ported to libdnf5 AFAIK. It seems only osbuild-mpp in the osbuild-tools subpackage unconditionally imports `dnf` but still defaults to using `libdnf5`. - Some of these packages are `dnf4` CLI plugins. As far as I understand, it's already known that this Change means the `dnf4` CLI (and the old dnf Python API) won't be able to read system repositories anymore, but dnf4 is considered deprecated in favor of dnf5. It would be really nice to have a compat mechanism here while we still have python3-dnf around. - Not sure about modulemd-tools but we don't have Modularity anymore. - I'm not sure about `fedora-review`. I thought there were efforts to fully port it to dnf5, but I'm not sure if those were completed. I recall there was some shelling out to /usr/bin/dnf-3. - Not sure about retrace-server. Isn't that tied to the ABRT server stuff that is going away? - pungi still uses the old dnf Python API, but it does not call `read_all_repos()` anywhere, so that shouldn't be affected either.

gotmax23 commented

2026-08-11 22:42:30 +00:00

Author

Owner

I'm not sure about fedora-review. I thought there were efforts to fully port it to dnf5, but I'm not sure if those were completed. I recall there was some shelling out to /usr/bin/dnf-3.

It looks like there are some outdated comments about needing dnf-3, but it is not actually used anymore.

> I'm not sure about fedora-review. I thought there were efforts to fully port it to dnf5, but I'm not sure if those were completed. I recall there was some shelling out to /usr/bin/dnf-3. It looks like there are some outdated comments about needing dnf-3, but it is not actually used anymore.

ngompa commented

2026-08-11 22:47:28 +00:00

Owner

fedora-review does not read system repositories. It uses mock and reads installed packages.

`fedora-review` does not read system repositories. It uses mock and reads installed packages.

adamwill commented

2026-08-11 22:58:14 +00:00

Note this change is currently live in newly-branched F45 and Rawhide, because @ngompa landed it earlier today and then builds that included it were pushed through as part of branching (test failures on the F45 update were incorrectly waived, F46 update was not gated because the F46 release was created wrong in Bodhi and so it had no critical path definition for a while).

yselkowitz commented

2026-08-11 23:03:00 +00:00

Not only dnf4 is affected; ELN post-branching compose failed due to this change too: https://koji.fedoraproject.org/koji/taskinfo?taskID=148984307

2026-08-11 22:40:28,085: template command error in runtime-postinstall.tmpl:
2026-08-11 22:40:28,085:   move etc/yum.repos.d etc/anaconda.repos.d
2026-08-11 22:40:28,097:   FileNotFoundError: [Errno 2] No such file or directory: '/var/tmp/lorax/lorax.fdm_aloy/installtree/etc/yum.repos.d' -> '/var/tmp/lorax/lorax.fdm_aloy/installtree/etc/anaconda.repos.d'

Both lorax-templates-generic and lorax-templates-rhel would be affected.

Not only dnf4 is affected; ELN post-branching compose failed due to this change too: https://koji.fedoraproject.org/koji/taskinfo?taskID=148984307 ``` 2026-08-11 22:40:28,085: template command error in runtime-postinstall.tmpl: 2026-08-11 22:40:28,085: move etc/yum.repos.d etc/anaconda.repos.d 2026-08-11 22:40:28,097: FileNotFoundError: [Errno 2] No such file or directory: '/var/tmp/lorax/lorax.fdm_aloy/installtree/etc/yum.repos.d' -> '/var/tmp/lorax/lorax.fdm_aloy/installtree/etc/anaconda.repos.d' ``` Both lorax-templates-generic and lorax-templates-rhel would be affected.

gotmax23 commented

2026-08-11 23:15:31 +00:00

Author

Owner

Container image composes are failing due to

 	# https://bugzilla.redhat.com/show_bug.cgi?id=1400682
 	echo "Import RPM GPG key"
 	releasever=$(rpm --eval '%{?fedora}')
 	# When building ELN containers, we don't have the %{fedora} macro
 	if [ -z $releasever ]; then
 		releasever=eln
 	fi
 	rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-primary

(keys are no longer in /etc/pki/rpm-gpg).

Container image composes are failing due to https://forge.fedoraproject.org/releng/kiwi-descriptions/src/commit/6ecf2b2f21e4063df705ac7e8b385a2a50c1f89f/config.sh#L254-L263 (keys are no longer in /etc/pki/rpm-gpg).

adamwill commented

2026-08-12 01:24:57 +00:00

I've fixed the kiwi-descriptions thing in rawhide and f45 branches.

supakeen commented

2026-08-12 05:30:58 +00:00

Owner

osbuild was already ported to libdnf5 AFAIK. It seems only osbuild-mpp in the osbuild-tools subpackage unconditionally imports dnf but still defaults to using libdnf5.

AFAIK we default to dnf5 on Fedora (but can conditionally switch to the dnf4 API) so we 'should be OK' in Fedora-land at least that was my assumption when I read the change. I'll go over if anything broke.

We have a lot of tests related to these paths but it seems most of those are related to reading RHSM secrets which should still be written to /etc by subman and we use these paths to write custom repositories for users but that's still correct.

> osbuild was already ported to libdnf5 AFAIK. It seems only osbuild-mpp in the osbuild-tools subpackage unconditionally imports dnf but still defaults to using libdnf5. AFAIK we default to dnf5 on Fedora (but can conditionally switch to the dnf4 API) so we 'should be OK' in Fedora-land at least that was my assumption when I read the change. I'll go over if anything broke. We have a lot of tests related to these paths but it seems most of those are related to reading RHSM secrets which should still be written to `/etc` by subman and we use these paths to write custom repositories for users but that's still correct.

adamwill commented

2026-08-12 05:53:46 +00:00

we have also found this bit in lorax which is now broken; installer images now have an empty /etc/anaconda.repos.d and the fedora repo definitions are in /usr/share/dnf5/repos.d. corresponding anaconda bit is here:

DNF_REPO_DIRS = [
    '/etc/yum.repos.d',
    '/etc/anaconda.repos.d'
]

that's used as the reposdir for the installer's DNF 5 base object config, here.

There's also another bit of anaconda that hardcodes /etc/yum.repos.d as the location to write repo config files on the installed system, whenever the installer does that for any reason (I don't know offhand when it does this exactly, haven't followed out all the codepaths yet). I suppose that might actually be OK if that location is still read from, just not used as the location for our own configs any more?

On the whole, this probably needed to be landed and the kinks worked out sooner. Or at least not while we're trying to branch. We might have to revert it. If we do we should also revert the kiwi-descriptions change.

we have also found [this bit in lorax](https://github.com/weldr/lorax/blob/8735df380bb7604b4bcabcbcc423da0a349c9ff5/share/templates.d/99-generic/runtime-postinstall.tmpl#L15) which is now broken; installer images now have an empty `/etc/anaconda.repos.d` and the fedora repo definitions are in `/usr/share/dnf5/repos.d`. corresponding anaconda bit is [here](https://github.com/rhinstaller/anaconda/blob/728dd627bb077b8432918915383636a123fc2152/pyanaconda/modules/payloads/constants.py#L48): ``` DNF_REPO_DIRS = [ '/etc/yum.repos.d', '/etc/anaconda.repos.d' ] ``` that's used as the `reposdir` for the installer's DNF 5 base object config, [here](https://github.com/rhinstaller/anaconda/blob/728dd627bb077b8432918915383636a123fc2152/pyanaconda/modules/payloads/payload/dnf/dnf_manager.py#L150). There's also another bit of anaconda that [hardcodes /etc/yum.repos.d](https://github.com/rhinstaller/anaconda/blob/728dd627bb077b8432918915383636a123fc2152/pyanaconda/modules/payloads/payload/dnf/installation.py#L350) as the location to write repo config files on the installed system, whenever the installer does that for any reason (I don't know offhand when it does this exactly, haven't followed out all the codepaths yet). I suppose that might actually be OK if that location is still *read from*, just not used as the location for our own configs any more? On the whole, this probably needed to be landed and the kinks worked out sooner. Or at least not while we're trying to branch. We might have to revert it. If we do we should also revert the kiwi-descriptions change.

zbyszek commented

2026-08-12 09:04:12 +00:00

Owner

Can we fix Lorax and Anaconda instead? In Ananconda, the list can be trivially extended with the new location. In Lorax, the strange logic might need more work, but since it's been identified, the fix shouldn't be that hard. Maybe just make it conditional on the existence of the new path?

ngompa commented

2026-08-12 14:03:57 +00:00

Owner

Non-packaged repo config files must stay in /etc/yum.repos.d. Anaconda should not change where it writes new repo files. If repos are being copied then it just needs another lookup directory.

Non-packaged repo config files _must_ stay in `/etc/yum.repos.d`. Anaconda should not change where it writes new repo files. If repos are being _copied_ then it just needs another lookup directory.

adamwill commented

2026-08-12 16:12:09 +00:00

well the thing is it's not clear what repo files it's writing. The ones it writes might be considered "pre-packaged" in some sense as they're written by the installer, it really depends on the details I think.

At least some paths seem to be that it will write through repos from kickstarts(?) and interactive installation source configuration(?), which I guess probably make more sense in /etc. But I don't know if there are other paths.

@zbyszek sure, we can, but this is substantially complicating things during gating, because we're trying to fix this in-flight in order to really complete the gating process and have working composes of branched-45 and rawhide-46. It would have been a lot less messy to do these two things separately. There's the risk that we fix lorax and anaconda and find more stuff after that, and this just keeps dragging out. But for now we will try that.

well the thing is it's not clear what repo files it's writing. The ones it writes might be considered "pre-packaged" in some sense as they're written by the installer, it really depends on the details I think. At least some paths seem to be that it will write through repos from kickstarts(?) and interactive installation source configuration(?), which I guess probably make more sense in `/etc`. But I don't know if there are other paths. @zbyszek sure, we *can*, but this is substantially complicating things during gating, because we're trying to fix this in-flight in order to really complete the gating process and have working composes of branched-45 and rawhide-46. It would have been a lot less messy to do these two things separately. There's the risk that we fix lorax and anaconda and find more stuff after that, and this just keeps dragging out. But for now we will try that.

ngompa commented

2026-08-12 16:31:58 +00:00

Owner

@adamwill wrote in #3676 (comment):

well the thing is it's not clear what repo files it's writing. The ones it writes might be considered "pre-packaged" in some sense as they're written by the installer, it really depends on the details I think.

At least some paths seem to be that it will write through repos from kickstarts(?) and interactive installation source configuration(?), which I guess probably make more sense in /etc. But I don't know if there are other paths.

At least in that example, it's writing fresh repo config files into /etc, which is perfectly fine. The tricky thing is if it's modifying repo files in place, that would have to move to override.d files in /etc to set overrides from base configuration.

@adamwill wrote in https://forge.fedoraproject.org/fesco/tickets/issues/3676#issuecomment-1338396: > well the thing is it's not clear what repo files it's writing. The ones it writes might be considered "pre-packaged" in some sense as they're written by the installer, it really depends on the details I think. > > At least some paths seem to be that it will write through repos from kickstarts(?) and interactive installation source configuration(?), which I guess probably make more sense in `/etc`. But I don't know if there are other paths. > At least in that example, it's writing fresh repo config files into `/etc`, which is perfectly fine. The tricky thing is if it's modifying repo files in place, that would have to move to override.d files in `/etc` to set overrides from base configuration.

yselkowitz referenced this issue from releng/compose-tracker-issues

2026-08-12 19:23:18 +00:00

Fedora-eln-20260811.n.3 DOOMED #9504

yselkowitz referenced this issue from releng/compose-tracker-issues

2026-08-12 19:23:28 +00:00

Fedora-eln-20260812.n.0 DOOMED #9506

yselkowitz referenced this issue from releng/compose-tracker-issues

2026-08-12 19:24:20 +00:00

Fedora-eln-20260812.n.1 DOOMED #9507

gotmax23 commented

2026-08-14 19:51:39 +00:00

Author

Owner

Okay, here's where we are now:

Issues in OpenQA tests, anaconda, lorax, and container image kiwi builds have been fixed.
/usr/bin/dnf-3 and /usr/bin/dnf4 still can't read system repositories anymore. I believe the issues with dnf4 compatibility were already on the table when this Change was originally discussed, so I don't think it makes sense to relitigate them unless something else significant is known to be broken since it still relies on the dnf4 CLI.
Tools that use the old dnf Python API and call base.read_all_repos() to read system repositories will no longer work. I did not identify any API user in the list @adamwill provided that does this. Nothing in releng scripts either. There could of course be other usages we don't know about.

Am I missing anything? It was nonideal that this happened right before/during branching, but it seems like we're in an okay shape to keep this in F45?

I guess I'll also note that all of the yum compatibility commands in dnf-utils are potentially affected by this.

$ rpm -ql dnf-utils | grep /usr/bin | xargs -n1 basename
debuginfo-install
find-repos-of-install
needs-restarting
package-cleanup
repo-graph
repoclosure
repodiff
repomanage
repoquery
reposync
repotrack
yum-builddep
yum-config-manager
yum-groups-manager
yumdownloader

Is it likely that users are still relying on those or were they automatically Obsoleted when dnf5 became the default?

Okay, here's where we are now: - Issues in OpenQA tests, anaconda, lorax, and container image kiwi builds have been fixed. - `/usr/bin/dnf-3` and `/usr/bin/dnf4` still can't read system repositories anymore. I believe the issues with dnf4 compatibility were already on the table when this Change was originally discussed, so I don't think it makes sense to relitigate them unless something else significant is known to be broken since it still relies on the dnf4 CLI. - Tools that use the old dnf Python API and call `base.read_all_repos()` to read system repositories will no longer work. I did not identify any API user in the list @adamwill provided that does this. Nothing in releng scripts either. There could of course be other usages we don't know about. Am I missing anything? It was nonideal that this happened right before/during branching, but it seems like we're in an okay shape to keep this in F45? --- I guess I'll also note that all of the yum compatibility commands in dnf-utils are potentially affected by this. ``` $ rpm -ql dnf-utils | grep /usr/bin | xargs -n1 basename debuginfo-install find-repos-of-install needs-restarting package-cleanup repo-graph repoclosure repodiff repomanage repoquery reposync repotrack yum-builddep yum-config-manager yum-groups-manager yumdownloader ``` Is it likely that users are still relying on those or were they automatically Obsoleted when dnf5 became the default?

ngompa commented

2026-08-17 20:25:57 +00:00

Owner

They were supposed to be obsoleted, if not, that needs fixing.

gotmax23 commented

2026-08-17 20:38:06 +00:00

Author

Owner

I still have dnf-utils installed on my system that's been running since before dnf5 was made default, but I don't remember if I took special action to keep it around. dnf-utils is still in rawhide right now.

$ fedrq pkgs dnf-utils
dnf-utils-4.10.1-11.fc45.noarch
$ fedrq whatobsoletes dnf-utils
$ dnf repoquery --repo=rawhide --whatobsoletes dnf-utils
(no output)

I still have dnf-utils installed on my system that's been running since before dnf5 was made default, but I don't remember if I took special action to keep it around. dnf-utils is still in rawhide right now. ``` $ fedrq pkgs dnf-utils dnf-utils-4.10.1-11.fc45.noarch $ fedrq whatobsoletes dnf-utils $ dnf repoquery --repo=rawhide --whatobsoletes dnf-utils (no output) ```

adamwill commented

2026-08-17 23:57:07 +00:00

It looks like this change has played a lot of havoc with (rpm-)ostree. Both overlay and rebase tests are currently failing in ways that suggest this change is the cause. CC @walters . Filed https://github.com/coreos/rpm-ostree/issues/5623

It looks like this change has played a lot of havoc with (rpm-)ostree. Both [overlay](https://openqa.fedoraproject.org/tests/5147280) and [rebase](https://openqa.fedoraproject.org/tests/5147279) tests are currently failing in ways that suggest this change is the cause. CC @walters . Filed https://github.com/coreos/rpm-ostree/issues/5623

yselkowitz commented

2026-08-18 01:27:49 +00:00

That makes sense given that rpm-ostree bundles libdnf.

gotmax23 commented

2026-08-18 19:45:38 +00:00

Author

Owner

This was discussed in today's meeting (meeting log).

ACTION: Simon de Vlieger to reach out to rpm-ostree related people to make them (more) aware
AGREED: Give until Friday for rpm-ostree to be fixed. Otherwise, revert this Change in f45 (+6, 0, -0)

This was discussed in today's meeting ([meeting log](https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-08-18/fesco.2026-08-18-17.00.log.html)). * ACTION: Simon de Vlieger to reach out to rpm-ostree related people to make them (more) aware * AGREED: Give until Friday for rpm-ostree to be fixed. Otherwise, revert this Change in f45 (+6, 0, -0)

supakeen commented

2026-08-19 05:12:26 +00:00

Owner

I've reached out to @jmarrero (rpm-ostree's upstream maintainer) and they've said they'll be looking into this.

I've reached out to @jmarrero (`rpm-ostree`'s upstream maintainer) and they've said they'll be looking into this.

adamwill commented

2026-08-19 22:04:06 +00:00

jmarrero has proposed a fix now. I'm currently testing it.

jmarrero has proposed a [fix](https://github.com/coreos/rpm-ostree/pull/5624) now. I'm currently testing it.

adamwill commented

2026-08-20 19:48:14 +00:00

rpm-ostree fixes are looking good, but now I found a bunch of hardcoded references to the old locations in two coreos projects:

CC @dustymabe .

rpm-ostree fixes are looking good, but now I found a bunch of hardcoded references to the old locations in two coreos projects: * https://github.com/coreos/fedora-coreos-config/issues/4313 * https://github.com/coreos/fedora-coreos-pipeline/issues/1382 CC @dustymabe .

adamwill commented

2026-08-20 19:50:17 +00:00

I'll note that at this point, this claim in the Change under "Scope":

"Other developers: N/A (not needed for this Change)"

has obviously proved to not be correct.

I'll note that at this point, this claim in the Change under "Scope": "Other developers: N/A (not needed for this Change)" has obviously proved to not be correct.

👍 1

dustymabe commented

2026-08-21 02:53:48 +00:00

I'll try to look at the two coreos issues you opened tomorrow.

Thank you @adamwill

I'll try to look at the two coreos issues you opened tomorrow. Thank you @adamwill

zbyszek commented

2026-08-25 09:29:20 +00:00

Owner

https://github.com/coreos/fedora-coreos-config/pull/4318 was merged 12 h ago.
https://github.com/coreos/fedora-coreos-tracker/issues/2172 is still open.
I think things are progressing, but not 100% done yet. @dustymabe could you give a short summary here?

https://github.com/coreos/fedora-coreos-config/pull/4318 was merged 12 h ago. https://github.com/coreos/fedora-coreos-tracker/issues/2172 is still open. I think things are progressing, but not 100% done yet. @dustymabe could you give a short summary here?

dustymabe commented

2026-08-25 17:08:58 +00:00

We're still working through some issues related to the change, but I haven't encountered anything yet that we haven't been able to workaround.

I'm actively trying to get new rawhide and f45 based CoreOS and bootc images produced.

quay.io/bootc-devel/fedora-bootc-45-standard:latest exists now and quay.io/bootc-devel/fedora-bootc-rawhide-standard is F46.

I'm working through getting CoreOS (downstream of the bootc images mentioned above) updated today.

We're still working through some issues related to the change, but I haven't encountered anything yet that we haven't been able to workaround. I'm actively trying to get new rawhide and f45 based CoreOS and bootc images produced. `quay.io/bootc-devel/fedora-bootc-45-standard:latest` exists now and `quay.io/bootc-devel/fedora-bootc-rawhide-standard` is F46. I'm working through getting CoreOS (downstream of the bootc images mentioned above) updated today.

zbyszek commented

2026-08-25 19:03:08 +00:00

Owner

We discussed this during the meeting today. The conclusion is that it looks good and the ticket can be closed.

zbyszek

2026-08-25 19:03:08 +00:00

closed this issue
removed the
meeting
label

Rows
Columns

Re-review F45 Change: RelocateRpmRepoConfigsToUsr #3676