-
Notifications
You must be signed in to change notification settings - Fork 12
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
RuntimeError: DNF error: Problems in request: #67
Comments
The error is that dnf doesn't find the requested packages in the provided repo. That's strange, as Fedora does package all of them. I tried replicating this locally, but it does work for me. This is quite possibly caused by the metalink. Maybe it's getting resolved to a mirror that is out dated. Does it happen consistently over time? In general, metalinks are only good for experimenting and playing around with the tool. It seems to me that's what you are doing here, given the |
Yes. I did a test right now and got the same error |
Are you saying that such an issue could be resolved if I specify the fedora version to be used from this command |
Here is a new test which is failing too using fedora:40
|
Nope, I meant replacing the metalink option in the repo file with a baseurl. The URLs I provided would work for 41 and Rawhide, but I don't have one for 40. Alternatively you could put this into the input yaml file (instead of the current section): contentOrigin:
repos:
- repoid: fedora
baseurl: https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-41/compose/Everything/$basearch/os |
That works using the following config
|
Hmmmm. I got another problem during image build as cachi2 reports such an error
|
The URL for Fedora 40 repo points to the gold compose used at GA time back in April. It contains |
Maybe it's not a bug in the tool. It seems that the problem is using the bare The prefetch and build works for me with your yaml and this containerfile:
|
That fails when Tekton prefetch pod download the bits using fedora:40 too
|
If user specifies a base image with no registry information, things may seem to work as skopeo will use some default value. But it may lead to confusing breakage later if the build system picks a different registry. For example, right now using `fedora` as image spec will make skopeo download `docker.io/library/fedora:40`, but podman uses `registry.fedoraproject.org/fedora:40`. There's no good way to automatically fix it, so let's print a big warning at least. Relates: #67
Great to hear that. To summarize, we have found two potential issues here:
|
If user specifies a base image with no registry information, things may seem to work as skopeo will use some default value. But it may lead to confusing breakage later if the build system picks a different registry. For example, right now using `fedora` as image spec will make skopeo download `docker.io/library/fedora:40`, but podman uses `registry.fedoraproject.org/fedora:40`. There's no good way to automatically fix it, so let's print a big warning at least. Relates: #67
Issue
When we try to grab the urls of RPMs for fedora, we got such an error
Command executed
Repo File
fedora.repo
The text was updated successfully, but these errors were encountered: