Abstract: this MR aims at updating dead links in the buildout.cfg files. As a side effect, it updates some of the md5sum.

Context of the MR

I recently did a SlapOS installation without enabling the cache, and fixed the broken links in buildout.cfg files. At first, I was unsure if I should make a MR to submit the change to the main repository, because we almost always use the cache, anyway:

• it should not do any harm;
• if we have a problem with the cache one day, we will be able to deploy;
• most of the times updating the link also switches from HTTP to HTTPS, which brings an extra layer of security.

While updating the links, I realized some of the packages were also outdated. I updated them only if these three conditions were met:

• the previous link was dead;
• I could not find a link to the version we used to require;
• updating did not cause a problem when building SlapOS (essentially, there are only patch upgrades according to semver).

There were only a few packages meeting these three conditions, so it is not a huge matter.

Updating the hashes

For some packages, the only things required was to update the link, but sometimes I also had to update the md5sum field.

Hashes updated because of the update

The following hashes update are due to the package version change:

• component/subversion: patch update from version 1.14.1 to version 1.14.2
• component/perl-Image-ExifTool: update from 12.30 to 12.60
• component/libzmq: patch update from 4.1.4 to 4.1.6
• component/libjpeg: patch update from 9d to 9f

Hashes updated due to change in compression format

For fonts, the old website osdn.net is very slow, at least where I am (like 10 minutes for a 2 Mo download), so I updated the links to use the Debian repositories. The compression format used at OSDN was zip, but Debian uses gz, so three out of the four fonts in component/fonts had their hash updated due to that change in the compression format.

Specific notes

The case of libjpeg

This package is an exception to the rule: the old link was not dead, but I had to update the link in order to avoid duplicates in the cache (see discussion below). Also, checking the difference between the content of the cache and the new package shows that a few bytes were removed at the beginning of every file. These bytes are likely some kind of editor crap left by the author in the package now in our cache, which was then removed, maybe Byte-Order Marks. Anyway, they do not cause any problem and removing them seems harmless to me.

The case of libdmtx

For the update of component/libdmtx: the project has been moved to Github and the download link provided by the Github tag does not provide the ./configure command, so running ./autogen.sh is now required. This comes with some additionnal issues:

• the script requires m4, autoconf, automake, pkgconfig and libtool for configuration, so they were added as a dependency;
• aclocal (launched by autoconf) needs a flag to specify where pkgconfig and libtool are;
• the imagemagick-7.patch file cannot operate anymore on configure, since the file does not exist after download. I removed all of the parts which were linked to that file in the patch;
• finally, these updates lead to updates in both the hash of the package and the patch, so the md5sum were also updated.

Left to update

Tests are running on my branch to check everything is fine with the changes in this MR, but we still are left with some dead links. I did not fixed the following links because I could not find a newer source of truth which does not require changes in the way we compile them:

• component/kumo: Github's new link (warning: direct download link) does not provide the ./configure command, which would require to manually run ./bootstrap. I could not find the reason for this change, as it seems the same version is downloaded.
• eggs/pytracemalloc: currently installed from pip, it is not possible anymore for some obscure reasons (see the pip project page), so that requires a manual installation. I made a commit to fix it (d3628a84), and might open a PR later.