Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Testing repository should be disabled on Silverblue #549

Open
A6GibKm opened this issue Apr 5, 2024 · 10 comments
Open

Testing repository should be disabled on Silverblue #549

A6GibKm opened this issue Apr 5, 2024 · 10 comments
Labels
bug Something isn't working f40 Related to Fedora 40

Comments

@A6GibKm
Copy link

A6GibKm commented Apr 5, 2024

At the moment a fresh Silverblue image (fedora:fedora/40/x86_64/silverblue) will have the testing-updates repository enabled by default (as per its repo file at /etc/yum.repos.d/). On the other hand the base image is built from the updates repository.

A few days ago I got an update to gnome-console bumping it to 46.0 which requires vte291 0.76.0, since I get updates from updates-testing console was upgraded, but since vte291 is part of the base image it stayed at 0.74.0 (latest version on the base image), resulting in gnome-console not being able to start due to missing symbols.

Maybe I don't understand how my system got into this condition, but this is the most I was able to debug it.

@A6GibKm A6GibKm added the bug Something isn't working label Apr 5, 2024
@miabbott
Copy link
Member

miabbott commented Apr 5, 2024

Can you share the output of rpm-ostree status for your system?

I installed a F40 Silverblue on a VM and while I did find that the updates-testing repo was enabled, I didn't see gnome-console installed as part of the default set of packages. I'll guess you have gnome-console layered on your system?

Perhaps this is a result of moving from Rawhide -> F40 Beta -> F40 GA. Since Fedora 40 still hasn't be released yet, I could imagine that the updates-testing repo could be enabled during this transition period.

On the other hand, if gnome-console requires a newer version of vte291 and that version of vte291 is available via updates-testing, I would have guessed that the upgrade process would have pulled in the newer version.

Maybe you can try rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2024-6dfb994cf3 ?

@alternateved
Copy link

I had a similar case. Installed Silverblue F40 before it was in Beta, when it was already branched out from Rawhide. Then installed gnome-console with rpm-ostree install gnome-console. One of the latest updates broke gnome-console due to missing symbols.

What helped was installing update from https://bodhi.fedoraproject.org/updates/FEDORA-2024-6dfb994cf3.

@miabbott
Copy link
Member

miabbott commented Apr 5, 2024

Maybe you can try rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2024-6dfb994cf3 ?

This was successful for me. Booted into a new deployment and could use gnome-console fine.

@chrisawi
Copy link

chrisawi commented Apr 5, 2024

This particular issue was caused by a packaging bug in gnome-console: https://src.fedoraproject.org/rpms/gnome-console/c/ef40e412f150cb2d21ec257dd1c915ec85e87db4?branch=f40

It normally would have been held back until the base image updated.

I'm not sure if there's a good way to resolve the repo mismatch during this period where updates-testing is enabled by default. Would temporarily making silverblue an alias of testing/silverblue make sense? There wouldn't be any way to opt out though.

@miabbott
Copy link
Member

miabbott commented Apr 5, 2024

I'm not sure if there's a good way to resolve the repo mismatch during this period where updates-testing is enabled by default. Would temporarily making silverblue an alias of testing/silverblue make sense? There wouldn't be any way to opt out though.

IMO, I don't think it is worth the effort to make changes at the infrastructure level for this particular issue. The rpm-ostree override replace workaround seems sufficient enough.

@A6GibKm
Copy link
Author

A6GibKm commented Apr 5, 2024

I am not sure why this workaround should be applied every time one layered package gets updated. Why not just disable the testing repo? If users wanted those updates they would use the testing base image.

@mcatanzaro
Copy link

This particular issue was caused by a packaging bug in gnome-console

No, it seems like a bug that the gnome-console spec file have Requires on an arbitrary subset of the libraries that it builds against. It's not normal to add Requires for build dependencies. If you want it to be safe to install partial updates, then you need this draft RPM pull request.

I'd say this is squarely Silverblue's fault. Installing one package but not another from the same Fedora update is particularly egregious. I'm surprised you don't have a large number of similar bug reports....

@travier travier added the f40 Related to Fedora 40 label Apr 8, 2024
@travier
Copy link
Member

travier commented Apr 8, 2024

I'd say this is squarely Silverblue's fault. Installing one package but not another from the same Fedora update is particularly egregious. I'm surprised you don't have a large number of similar bug reports....

The testing repos are only enabled by default before the release so this does not impact users on stable releases. Beta releases also do not have the archive repo enabled yet, thus not offering "older" but matching package versions.

Package layering is always provided as a best effort as by definition we can not test all the arbitrary combinations that can be used.

@travier
Copy link
Member

travier commented Apr 8, 2024

All that being said, we do not have a way to distinguish builds happening with the testing repos enabled from the normal builds in Fedora infra right now as far as I know, so we can not selectively disable the testing repos only on those refs.

Maybe we should "force" disable them by default for all refs.

@travier
Copy link
Member

travier commented Apr 11, 2024

Tentative PR: https://pagure.io/workstation-ostree-config/pull-request/503

Maybe someone who knows more about pungi / the Fedora compose infra can help me figure out a better option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working f40 Related to Fedora 40
Projects
None yet
Development

No branches or pull requests

6 participants