Learn more about these different git repos.
Other Git URLs
We have a 'empty-repo' directory that we point new-updates-sync to for repos we are not currently updating. Like the updates repo for a branched compose.
However, this repo is NOT the same as the final repos we push, so mirrormanager mis-detects things and we have to manually fix them every cycle after release.
See: https://pagure.io/fedora-infrastructure/issue/8874 for background.
We need to look at the current updates/updates-testing repos and make a empty repo that matches the exact same directory structure.
We need this before f33 branching.
I think removing https://kojipkgs.fedoraproject.org/compose/updates/empty-repo/compose/Everything/$arch/os/Packages/ should fix this.
https://kojipkgs.fedoraproject.org/compose/updates/empty-repo/compose/Everything/$arch/os/Packages/
Any thoughts?
@mohanboddu Did you have a look at https://pagure.io/fedora-infrastructure/issue/8874. I listed a couple of changes there which need to happen.
It is important to have empty repositories so that MM can detect it and even if, for example, updates-released-f33, has no content, the user still gets a valid answer for that repository. This means from MM points of view we only need the populated repodata directories at the right location. Everything else is not important for MM to correctly detect a release right after branching. I do not know, however, if the empty repository has other use cases
https://pagure.io/fedora-infrastructure/issue/8874#comment-645177 - we should use x86_64 as a reference and clean up the others.
From https://pagure.io/fedora-infrastructure/issue/8874#comment-645177
For both trees we should do mv source/tree SRPMS. That is definitely wrong.
We dont need to worry about this as its handled by new-updates-sync - link
I think we should also remove ppc64le/os/Packages/debug and ppc64le/os/Packages/os.
Done
$ sudo rm -rv empty-repo/compose/Everything/ppc64le/os/Packages/*
It also seems that all debug directory trees are wrong. The empty repositories always have <arch>/debug/tree but we actually always have debug in <arch>/debug/Packages and <arch>/debug/repodata. On the master mirror this is all gone and correct, but there is still the chance that MM detected some of them incorrectly, when they initially were being pushed out. Lot of things to clean up, not sure I caught all of them. I am also confused about the os in the path in the empty repositories. os does not appear in the updates tree.
No need to worry about this as well, its handled by new-updates-sync - link: look at all the sync destinations, its created this way because thats how pungi started generating repos.
ppc64le also has subdirectories in drpms which x86_64 does not have. s390x does not have any drpms directories. We do not see many problems with x86_64 empty tree maybe use that as an example for all the others.
$ sudo rm -rv empty-repo/compose/Everything/ppc64le/os/drpms/*
I think we should be good now.
Cool. Let's wait for F33 to see if everything works as expected.
So I see:
empty-repo/compose/Everything ├── aarch64 │ ├── debug │ └── os ├── armhfp │ ├── debug │ └── os ├── i386 │ ├── debug │ └── os ├── ppc64 │ ├── debug │ └── os ├── ppc64le │ ├── debug │ └── os ├── s390x │ ├── debug │ └── os ├── source │ └── tree └── x86_64 ├── debug └── os
/pub/fedora/linux/updates/32/Everything/ ├── aarch64 │ ├── debug │ ├── drpms │ ├── Packages │ └── repodata ├── armhfp │ ├── debug │ ├── drpms │ ├── Packages │ └── repodata ├── source │ └── tree ├── SRPMS │ ├── Packages │ └── repodata └── x86_64 ├── debug ├── drpms ├── Packages └── repodata
So, there's an extra 'os' level there? Is that due to new-updates-sync moving from one to the other? Can we adjust it so they are they same?
And source we have both on the master mirror, but only one in empty-repo. One is a leftover from the old empty repo perhaps?
source needs to be deleted from the master mirror. There is still a ticket open (https://pagure.io/fedora-infrastructure/issue/8875) which needs this to be removed.
I didn't run the following yet, just wanted to check before start removing things on master mirror
$ sudo -u ftpsync rm -rv /pub/fedora/linux/updates/32/Everything/source $ sudo -u ftpsync rm -rv /pub/fedora/linux/updates/32/Modular/source $ sudo -u ftpsync rm -rv /pub/fedora/linux/updates/31/Everything/source $ sudo -u ftpsync rm -rv /pub/fedora/linux/updates/31/Modular/source $ sudo -u ftpsync rm -rv /pub/fedora/linux/updates/30/Everything/source $ sudo -u ftpsync rm -rv /pub/fedora/linux/updates/30/Modular/source
If this looks good, I will run the commands.
FYI, there is no data I can see in source/tree:
$ ls /pub/fedora/linux/updates/3*/*/source/tree/*/ /pub/fedora/linux/updates/30/Everything/source/tree/Packages/: /pub/fedora/linux/updates/30/Everything/source/tree/repodata/: 19699a08b0728d8fcb697ee242e809d5531825194b41494bb28b60e8d04187e3-primary.sqlite.bz2 1cb61ea996355add02b1426ed4c1780ea75ce0c04c5d1107c025c3fbd7d8bcae-primary.xml.gz 878c2f1defc6fd1f9553a7fe0230eb31b65d13ce6045bb841aec881f4035e1b9-filelists.sqlite.bz2 95a4415d859d7120efb6b3cf964c07bebbff9a5275ca673e6e74a97bcbfb2a5f-filelists.xml.gz ef3e20691954c3d1318ec3071a982da339f4ed76967ded668b795c9e070aaab6-other.xml.gz f660753fbf07e6546e6ae7cc46cf1c6ce42444cddba666228e239c26da78d966-other.sqlite.bz2 repomd.xml /pub/fedora/linux/updates/30/Modular/source/tree/Packages/: /pub/fedora/linux/updates/30/Modular/source/tree/repodata/: 19699a08b0728d8fcb697ee242e809d5531825194b41494bb28b60e8d04187e3-primary.sqlite.bz2 1cb61ea996355add02b1426ed4c1780ea75ce0c04c5d1107c025c3fbd7d8bcae-primary.xml.gz 878c2f1defc6fd1f9553a7fe0230eb31b65d13ce6045bb841aec881f4035e1b9-filelists.sqlite.bz2 95a4415d859d7120efb6b3cf964c07bebbff9a5275ca673e6e74a97bcbfb2a5f-filelists.xml.gz ef3e20691954c3d1318ec3071a982da339f4ed76967ded668b795c9e070aaab6-other.xml.gz f660753fbf07e6546e6ae7cc46cf1c6ce42444cddba666228e239c26da78d966-other.sqlite.bz2 repomd.xml /pub/fedora/linux/updates/32/Everything/source/tree/Packages/: /pub/fedora/linux/updates/32/Everything/source/tree/repodata/: 19699a08b0728d8fcb697ee242e809d5531825194b41494bb28b60e8d04187e3-primary.sqlite.bz2 1cb61ea996355add02b1426ed4c1780ea75ce0c04c5d1107c025c3fbd7d8bcae-primary.xml.gz 878c2f1defc6fd1f9553a7fe0230eb31b65d13ce6045bb841aec881f4035e1b9-filelists.sqlite.bz2 95a4415d859d7120efb6b3cf964c07bebbff9a5275ca673e6e74a97bcbfb2a5f-filelists.xml.gz ef3e20691954c3d1318ec3071a982da339f4ed76967ded668b795c9e070aaab6-other.xml.gz f660753fbf07e6546e6ae7cc46cf1c6ce42444cddba666228e239c26da78d966-other.sqlite.bz2 repomd.xml /pub/fedora/linux/updates/32/Modular/source/tree/Packages/: /pub/fedora/linux/updates/32/Modular/source/tree/repodata/: 19699a08b0728d8fcb697ee242e809d5531825194b41494bb28b60e8d04187e3-primary.sqlite.bz2 1cb61ea996355add02b1426ed4c1780ea75ce0c04c5d1107c025c3fbd7d8bcae-primary.xml.gz 878c2f1defc6fd1f9553a7fe0230eb31b65d13ce6045bb841aec881f4035e1b9-filelists.sqlite.bz2 95a4415d859d7120efb6b3cf964c07bebbff9a5275ca673e6e74a97bcbfb2a5f-filelists.xml.gz ef3e20691954c3d1318ec3071a982da339f4ed76967ded668b795c9e070aaab6-other.xml.gz f660753fbf07e6546e6ae7cc46cf1c6ce42444cddba666228e239c26da78d966-other.sqlite.bz2 repomd.xml
@adrian Can you check and fix https://bugzilla.redhat.com/show_bug.cgi?id=1830550 before we start removing source dir?
source
https://bugzilla.redhat.com/show_bug.cgi?id=1830550 is the same as https://pagure.io/fedora-infrastructure/issue/8875
The wrong source directories need to be removed and fullfiletimelist-fedora updated. Only then can MM detect it correctly.
This should be fixed now.
Metadata Update from @mohanboddu: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
I can not re-open, but there is still a source directory in /srv/pub/fedora/linux/updates/testing/32/Modular/. Please also remove that.
/srv/pub/fedora/linux/updates/testing/32/Modular/
See https://pagure.io/releng/issue/9438 for further wrong directory on the current master mirror which need to be removed.
Additional repository layout differences mentioned here: https://pagure.io/releng/issue/9439
Login to comment on this ticket.