This seems to be a bug that is hard to squash. It has occurred previously, and now in updates-testing for Fedora 34 it shows again. Example:
updates-testing
dnf download rpm
gets me rpm-4.16.1.3-1.fc34.x86_64.rpm as expected. But
rpm-4.16.1.3-1.fc34.x86_64.rpm
dnf download --source rpm
gives me an error message instead:
No package rpm-4.16.1.3-1.fc34.src available. Exiting due to strict setting. Error: No package rpm-4.16.1.3-1.fc34.src available.
Looking a little closer, the first URL in the metalink for me is https://ftp.lysator.liu.se/pub/fedora/linux/updates/testing/34/Everything/source/tree/repodata/repomd.xml. That tree does contain repository metadata files, but the Packages directory is empty. Rather, the source packages can be found under SRPMS rather than source. It is the same for the next few mirrors, so I guess it is a general pattern.
https://ftp.lysator.liu.se/pub/fedora/linux/updates/testing/34/Everything/source/tree/repodata/repomd.xml
Packages
SRPMS
source
The sources for the fedora repository on the other hand can be downloaded fine.
fedora
Metadata Update from @humaton: - Issue tagged with: low-trouble, medium-gain, ops
@adrian Can you fix MM to use SRPMS/ dirs for source rpms in updates and updates-testing repo and leave the fedora repo as is?
SRPMS/
updates
@mohanboddu If you remove the wrong directory source/ and make sure fullfiletimelist-fedora is updated it is easily fixable.
source/
fullfiletimelist-fedora
Or should we change this line to
destarch = 'source/tree' if arch == 'source' else arch
?
This should make it same everywhere, sources syncing to source/tree.
source/tree
I like SRPMS/ better than source/tree. But whatever it is, important is that it does not change.
Once mirrormanager found and created a repository (repodata/repomd.xml) moving it, like this ticket is about, requires manual intervention.
repodata/repomd.xml
I do too, but I like consistency more :grin:
So, this has happened before. What caused it this time? I thought we fixed everything to be the same?
Whats re-adding things?
Metadata Update from @smooge: - Issue priority set to: Waiting on Assignee (was: Needs Review)
For information: the problem still remains after GA yesterday, now also for the updates repository.
Hi,
This still persist today. Someone mentioned some manual intervention is needed to fix this ticket, what needs to be done exactly ?
Cheers, Romain
So, we discussed this at a recent releng meeting.
We decided that we would use source as thats what all the releases/rawhide uses. So we just need to fix updates.
I think @mohanboddu was going to look at adjusting this? we have to be carefull and keep mirrormanager in sync tho.
As soon as the wrong directory is deleted and fullfiletimelist-fedora is updated I can make the changes to MirrorManager.
So, what we need to do is:
Also see #10017 for similar problems.
Fixed in #10017
Metadata Update from @mohanboddu: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.