package layering fails on f32 base with modular packages #525
Comments
|
It turns out this has nothing to do with the rebase. If you start from a fresh install of If you edit Maybe we should stop enabling the modular repos when we build FCOS? Here's the diff I get when I disable those repos and do a --- ./manifest-lock.x86_64.json 2020-06-06 23:48:24.696660245 -0400
+++ /var/b/shared/assembler/fedora/lockme 2020-06-07 00:07:59.305425327 -0400
@@ -70,7 +70,7 @@
"evra": "1.0.8-2.fc32.x86_64"
},
"c-ares": {
- "evra": "1.16.0-1.module_f32+8723+aeaf79ed.x86_64"
+ "evra": "1.15.0-5.fc32.x86_64"
},
"ca-certificates": {
"evra": "2020.2.40-3.fc32.noarch"
@@ -234,9 +234,6 @@
"expat": {
"evra": "2.2.8-2.fc32.x86_64"
},
- "fedora-coreos-pinger": {
- "evra": "0.0.4-1.module_f32+6507+a4e4adf6.x86_64"
- },
"fedora-gpg-keys": {
"evra": "32-2.noarch"
},
@@ -889,7 +886,7 @@
"evra": "2:1.9.3-1.fc32.x86_64"
},
"policycoreutils": {
- "evra": "3.0-2.module_f32+7989+651e8914.x86_64"
+ "evra": "3.0-2.fc32.x86_64"
},
"polkit": {
"evra": "0.116-7.fc32.x86_64"
@@ -1088,7 +1085,7 @@
}
},
"metadata": {
- "generated": "2020-06-06T21:07:37Z",
+ "generated": "2020-06-07T04:07:55Z",
"rpmmd_repos": {
"fedora": {
"generated": "2020-04-22T22:22:36Z"
@@ -1096,14 +1093,8 @@
"fedora-coreos-pool": {
"generated": "2020-06-05T21:39:01Z"
},
- "fedora-modular": {
- "generated": "2020-04-22T21:03:13Z"
- },
"fedora-updates": {
"generated": "2020-06-05T01:26:33Z"
- },
- "fedora-updates-modular": {
- "generated": "2020-06-05T04:14:06Z"
}
}
}I'm guessing |
dustymabe
changed the title
|
btw thanks @grantral for taking part in the test day! |
lucab
added
component/rpm-ostree
fedora-test-day
Yeah... a lot of backstory here. It essentially comes down to rpm-ostree not being modularity aware (coreos/rpm-ostree#1435, which is blocked on rpm-software-management/libdnf#874). If we can stop using modular repos now that the Rust packages are in the regular repos again, sure. Otherwise I think we could tweak rpm-ostree to work in this case by adding more hacks on top of the existing hacks. |
|
@dustymabe I'm not entirely sure the procedure to get pinger into default repos but I can create a card for it and work on that |
|
Yes, to fix this immediately we can rebuild https://src.fedoraproject.org/rpms/fedora-coreos-pinger at the current upstream version. Updating the release number https://src.fedoraproject.org/rpms/rust-fedora-coreos-pinger/blob/master/f/rust-fedora-coreos-pinger.spec#_9, rebuilding with @zonggen, let's coordinate tomorrow - can help if any issues come up. Sorry to have seen this notification late today. |
|
Turns out we do have a build not using modular repos for |
Creating a bodhi update for this, Bodhi did not find the build, I think due to it having an |
Fasttrack the non-modular fedora-coreos-pinger build, removing our dependency on modular content. Part of fixing coreos/fedora-coreos-tracker#525.
Remove modular repos, as we no longer require sourcing modular content. Fixes: coreos/fedora-coreos-tracker#525
Fast-track the non-modular fedora-coreos-pinger build, removing our dependency on modular content. Part of fixing coreos/fedora-coreos-tracker#525. No Bodhi update is added yet due to the migration currently active in Fedora, but should be added as soon as possible.
Remove modular repos, as we no longer require sourcing modular content. Fixes: coreos/fedora-coreos-tracker#525
Remove modular repos, as we no longer require sourcing modular content. Fixes: coreos/fedora-coreos-tracker#525
While investigating coreos/fedora-coreos-tracker#525, I realized that libsolv does have a flag which allows us to express that our base packages shouldn't be upgraded: `SOLVER_LOCK`. This then lets us not have to sanity-check the solution post-solve for "forbidden replacements", and lets libsolv/libdnf print exactly what the conflict is.
I retract this statement. When trying So we have |
Remove modular repos from the list in this file, as we no longer require sourcing modular content. Part of: coreos/fedora-coreos-tracker#525
Add the recent non-modular fedora-coreos-pinger build to overides, removing our dependency on modular content. Part of fixing coreos/fedora-coreos-tracker#525. Overriding is necessary as there is no Bodhi update yet. The Bodhi update is pending a Fedora admin building with the side tag to make the package available in F32. Permissions for us to create the side tag are also pending, see: https://pagure.io/releng/issue/9229. Once either of the two pending above are completed, we'll be able to create and add the Bodhi update here (see TODO in the manifest).
Remove modular repos from the list in this file, as we no longer require sourcing modular content. Part of: coreos/fedora-coreos-tracker#525
Add the recent non-modular fedora-coreos-pinger build to overides, removing our dependency on modular content. Part of fixing coreos/fedora-coreos-tracker#525. Overriding is necessary as there is no Bodhi update yet. The Bodhi update is pending a Fedora admin building with the side tag to make the package available in F32. Permissions for us to create the side tag are also pending, see: https://pagure.io/releng/issue/9229. Once either of the two pending above are completed, we'll be able to create and add the Bodhi update here (see TODO in the manifest).
Remove modular repos from the list in this file, as we no longer require sourcing modular content. Part of: coreos/fedora-coreos-tracker#525
Add the recent non-modular fedora-coreos-pinger build to overides, removing our dependency on modular content. Part of fixing coreos/fedora-coreos-tracker#525. Overriding is necessary as there is no Bodhi update yet. The Bodhi update is pending a Fedora admin building with the side tag to make the package available in F32. Permissions for us to create the side tag are also pending, see: https://pagure.io/releng/issue/9229. Once either of the two pending above are completed, we'll be able to create and add the Bodhi update here (see TODO in the manifest).
Add the recent non-modular fedora-coreos-pinger build to overides, removing our dependency on modular content. Part of fixing coreos/fedora-coreos-tracker#525. Overriding is necessary as there is no Bodhi update yet. The Bodhi update is pending a Fedora admin building with the side tag to make the package available in F32. Permissions for us to create the side tag are also pending, see: https://pagure.io/releng/issue/9229. Once either of the two pending above are completed, we'll be able to create and add the Bodhi update here (see TODO in the manifest). (cherry picked from commit af7003d)
dustymabe
added
the
status/pending-testing-release
|
The fix for this went into testing stream release The fix for this went into stable stream release |
dustymabe
removed
the
status/pending-testing-release
Remove modular repos from the list in this file, as we no longer require sourcing modular content. Part of: coreos/fedora-coreos-tracker#525 (cherry picked from commit 74c98c2)
Remove modular repos from the list in this file, as we no longer require sourcing modular content. Part of: coreos/fedora-coreos-tracker#525 (cherry picked from commit 74c98c2)
Remove modular repos from the list in this file, as we no longer require sourcing modular content. Part of: coreos/fedora-coreos-tracker#525 (cherry picked from commit 74c98c2)
For the Fedora CoreOS extensions work, when layering packages, we need to be able to tell libsolv to pick the packages which will go with the base packages. IOW, it needs to know that the base packages shouldn't be uninstalled. While investigating coreos/fedora-coreos-tracker#525, I realized that libsolv does have a flag which allows us to express this: `SOLVER_LOCK`. This then allows libsolv to choose the right package for us (if found). And in the case where it can't find a matching package, libsolv itself will print exactly what the conflict is, allowing us to avoid sanity-checking the solution post-solve for "forbidden replacements". Update submodule: libdnf
For the Fedora CoreOS extensions work, when layering packages, we need to be able to tell libsolv to pick the packages which will go with the base packages. IOW, it needs to know that the base packages shouldn't be uninstalled. While investigating coreos/fedora-coreos-tracker#525, I realized that libsolv does have a flag which allows us to express this: `SOLVER_LOCK`. This then allows libsolv to choose the right package for us (if found). And in the case where it can't find a matching package, libsolv itself will print exactly what the conflict is, which is more informative than the "forbidden replacements" error we currently print out. Update submodule: libdnf
For the Fedora CoreOS extensions work, when layering packages, we need to be able to tell libsolv to pick the packages which will go with the base packages. IOW, it needs to know that the base packages shouldn't be uninstalled. While investigating coreos/fedora-coreos-tracker#525, I realized that libsolv does have a flag which allows us to express this: `SOLVER_LOCK`. This then allows libsolv to choose the right package for us (if found). And in the case where it can't find a matching package, libsolv itself will print exactly what the conflict is, which is more informative than the "forbidden replacements" error we currently print out. Update submodule: libdnf
Steps to reproduce
$ sudo rpm-ostree install buildah -r$ sudo rpm-ostree install flatpak -r$ sudo rpm-ostree rebase fedora/x86_64/coreos/next -rExpected behaviour
The system successfully reboots and runs on the next stream.
Actual behaviour
System configuration
Ignition config
rpm-ostree status
Notes
rpm-ostreesuggests usingrpm-ostree up, but this command does not exist;rpm-ostree upResolving dependencies... doneis merged.The text was updated successfully, but these errors were encountered: