Too many redirects when accessing 'rename'

[jfsp]

When the 'rename' man page is searched for on https://manpages.debian.org/ the site generates too many redirects resulting in an error in the browser (see attached screenshot for Chrome).

Direct access to the rename manpage works for some releases. E.g. for unstable the URL https://manpages.debian.org/unstable/rename/rename.1.en.html provides the proper manpage

To reproduce:

• Go to https://manpages.debian.org/
• Write 'rename' in the form (Directly Jump to manpage)
• Browser loads https://manpages.debian.org/jump?q=rename, followed by https://manpages.debian.org/buster/rename/rename.1.en.html, followed by https://dyn.manpages.debian.org/buster/rename/rename.1.en.html and so on (total of 105 requests) Note: Details in attached HAR file generated using Chrome's developer tools
• Browser stops and presents the error

rename-redirects-truffelsearch-chromewebdata.zip

[stapelberg]

The redirect is most likely a result of the file not being found. This is due to the setup across multiple virtual hosts (and actual hosts) we use in the debain.org instance.

The rename manpage works fine in my personal instance.

I can log into manziarly later and see whether the file is missing, or just not synced correctly onto the static mirror infrastructure, but feel free to race me to it.

[jfsp]

Thanks for the quick response. As I work until late I will probably not be able to race you to this issue :)

[stapelberg]

So the rename manpage comes in via piuparts and is a link to file-rename.1p:

stapelberg@manziarly:~$ grep -e 'packages from suite\|buster/rename' dm-full.log
2019/10/22 06:54:49 globalview.go:266: Adding 16749 packages from suite "buster"
2019/10/22 06:54:53 globalview.go:283: key="buster/rename", link={/usr/bin/rename /usr/bin/file-rename}, latest = &{main pool/main/r/rename/rename_1.10-1_all.deb rename rename [libfile-rename-perl ] 1.10-1 buster}
2019/10/22 06:54:53 globalview.go:283: key="buster/rename", link={/usr/share/man/man1/rename.1.gz /usr/share/man/man1/file-rename.1p.gz}, latest = &{main pool/main/r/rename/rename_1.10-1_all.deb rename rename [libfile-rename-perl ] 1.10-1 buster}
2019/10/22 06:54:53 globalview.go:292: package "buster/rename" has errors: [Trying to interpret path "usr/bin/rename": Cannot parse language "usr": language: subtag "usr" is well-formed but unknown]

Looking at what’s on disk, this particular link is missing:

stapelberg@manziarly:~$ ls -l /srv/manpages.debian.org/www/buster/rename/
total 56
-rw-r--r-- 1 manpages manpages 2898 Sep 30  2018 file-rename.1p.en.gz
-rw-r--r-- 1 manpages manpages 6417 Oct 22 07:40 file-rename.1p.en.html.gz
-rw-r--r-- 1 manpages manpages 3114 Sep 30  2018 File::Rename.3pm.en.gz
-rw-r--r-- 1 manpages manpages 6628 Oct 22 07:40 File::Rename.3pm.en.html.gz
-rw-r--r-- 1 manpages manpages 2332 Sep 30  2018 File::Rename::Options.3pm.en.gz
-rw-r--r-- 1 manpages manpages 5859 Oct 22 07:40 File::Rename::Options.3pm.en.html.gz
-rw-r--r-- 1 manpages manpages 4500 Oct 22 07:40 index.html.gz
lrwxrwxrwx 1 manpages manpages   20 Sep 30  2018 prename.1p.en.gz -> file-rename.1p.en.gz
-rw-r--r-- 1 manpages manpages 6412 Oct 22 07:40 prename.1p.en.html.gz
-rw-r--r-- 1 manpages manpages    6 Jul  7 00:18 VERSION

I think the immediate fix is to invalidate the rename package entirely, so that it will be re-extracted, the correct links will be created, and it will be re-rendered:

stapelberg@manziarly:~$ sudo -u manpages rm -rf /srv/manpages.debian.org/www/buster/rename/

Given that there were no changes to rename in quite a while (as per https://tracker.debian.org/pkg/rename), I wonder if we just never invalidated all packages after adding link support via piuparts.

Perhaps the code should be changed to always verify the existance of all links.

[stapelberg]

This is now fixed, and the fixed version is deployed on manziarly.

The rename manpage itself has been regenerated already and is available, and the next iteration should fix any other packages whose links might be missing.