Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#64195 - Corrupted packages in Arch Linux Archive

Attached to Project: Arch Linux
Opened by David (dlo9) - Sunday, 20 October 2019, 21:01 GMT
Last edited by Florian Pritz (bluewind) - Sunday, 07 May 2023, 09:19 GMT
Task Type Bug Report
Category Mirrors
Status Assigned
Assigned To Jelle van der Waa (jelly)
Sven-Hendrik Haase (Svenstaro)
freswa (frederik)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


This bug has the same fact pattern as in bug #64145 ( -- that is, there are some corrupted packages in the Arch Linux Archive (ALA).

These are the packages:

Here are details for each package from the ALA and various mirrors (columns are MD5, local filename, package size, URL). In each case, the ALA package is corrupted under dates snapshots and packages/<letter>/<pkg name> paths, but not under the `last` snapshot path, which appears to be an up-to-date mirror.

987a76296083b7e23d8ef1e8cec6f556 python2-zbar.ala 170776
7d978e5a6f684f84dbf5836201dd9bb7 python2-zbar.ala_last 170572
987a76296083b7e23d8ef1e8cec6f556 python2-zbar.ala_dated 170776
7d978e5a6f684f84dbf5836201dd9bb7 python2-zbar.ala_mirror 170572 rsync://
7d978e5a6f684f84dbf5836201dd9bb7 python2-zbar.mirror 170572

d03315706432b60853d0422ef758e0ea virglrenderer.ala 195888
60032fcdc0122783c4335994fda54704 virglrenderer.ala_last 195752
d03315706432b60853d0422ef758e0ea virglrenderer.ala_dated 195888
60032fcdc0122783c4335994fda54704 virglrenderer.ala_mirror 195752 rsync://
60032fcdc0122783c4335994fda54704 virglrenderer.mirror 195752

88f06aed75e988d02b5fe0608dd2d9cb zbar-gtk.ala 17940
e9446b0000544fd39a8d999fc75c0d45 zbar-gtk.ala_last 17920
88f06aed75e988d02b5fe0608dd2d9cb zbar-gtk.ala_dated 17940
e9446b0000544fd39a8d999fc75c0d45 zbar-gtk.ala_mirror 17920 rsync://
e9446b0000544fd39a8d999fc75c0d45 zbar-gtk.mirror 17920

79b050d88ccb543bf9ad7f84dfebf74a zbar-qt.ala 57220
261c8b501a6cb8b80c58c16c32998617 zbar-qt.ala_last 55540
79b050d88ccb543bf9ad7f84dfebf74a zbar-qt.ala_dated 57220
261c8b501a6cb8b80c58c16c32998617 zbar-qt.ala_mirror 55540 rsync://
261c8b501a6cb8b80c58c16c32998617 zbar-qt.mirror 55540
This task depends upon

Comment by Florian Pritz (bluewind) - Friday, 25 October 2019, 11:18 GMT
The URLs with the broken checksum are redirected to The repos/last/ URL does not match the regex[1] we use for the redirect and is thus served by our server directly.


The script that uploads files to is located here[2] and you are welcome to adapt it to include the filesize/modification time to detect changed files and reupload them.


I have removed the 4 packages in question from the database kept by the uploader so that they have been reuploaded now. I will keep this bug open if you or someone else wishes to improve the uploader script, but the 4 packages should be fixed now.
Comment by David (dlo9) - Sunday, 27 October 2019, 21:41 GMT
Thanks! I'll take a look at the script in the coming weeks when I find the time if no one else has made the changes by then.
Comment by Eli Schwartz (eschwartz) - Wednesday, 30 October 2019, 01:21 GMT
What I do not understand is, how can the files be getting updated at all? The archive should not allow this.

Were these packages rebuilt and db-updated without a pkgrel bump? This is the same issue as a recent mesa issue. Packagers should not be recreating a package, since it breaks pacman's download cache as well. It also causes downstream projects, such as Parabola which syncs our repos but drops some packages and rebuilds some others to remove 'libre' issues, to see outdated versions of the package (they sync the first one, but don't notice the file has changed in-place) to continue serving the old version -- and in the case of mesa, that replaced version contained a bunch of bugfixes and a different filelist.

"detecting changed files and reuploading them" is just replacing one form of brokenness with another, if we treat both of those files the same then one or the other $repo.db is going to always be wrong, and re-uploading the file just changes which .db is the corrupt one.

Before the uploader, we never noticed this due to I suspect the fact that only identical files were hardlinked, so the repository paths were always correct due to serving different files (the correct one for each date). The new redirection logic just matches filenames without directory paths...