If I run e.g.
links https://packages.debian.org/bash

I get:
   JavaScript is disabled in your browser.

   Please enable JavaScript to proceed.

   A required part of this site couldn’t load. This may be due to a browser extension, network issues, or browser settings. Please check your connection, disable any ad blockers, or try using a different browser.

Of course, links does not understand javascript.

I did this because some of the scripts for manpages-l10n[1] time out/fail
currently and I'm checking why.

Please re-enable access without Javascript required so that (Debian)
infrastructure continues to work.

Thanks!

Greetings

          Helge

[1] Manpages-l10n downloads lots of packages from e.g. Debian to extract
    the manual pages to translate.

Hi,

Am 19. April 2026 10:33:12 MESZ schrieb Helge Kreutzmann <debian@helgefjell.de>:

I'm unable to reproduce this with different browsers.

Maybe you should be more verbose about these scripts. Such as a salsa URL?
Are you sure, these scripts are accessing packages.debian.org? I guess not.

Which error messages do you see from these scripts?

Otherwise, I fear noone can do anything on this bug...


Holger

Hello Holger,
thanks for handling this issue.

Am Sun, Apr 19, 2026 at 11:14:20PM +0200 schrieb Holger Wansing:

I suspect this to be some kind of load balancing. It works
(sometimes), but then again not. Also I built in some kind of retry
mechanism in the scripts, sometimes they work on the first try,
sometimes they need (lots of) retries.

https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/blob/master/upstream/debian-unstable/update-manpages.sh

Best to clone manpages-l10n, (its a few GB currently)
cd upstream/debian-unstable/
and run
script -c ./update-manpages.sh

When you see a single ".", the access succeeded on first try, When you
see multiple ".", then the script needed to retry many times.

Yesterday, it was very bad, then I saw lots of dots and the script
took very long to get all packages. I *assume* that this was caused by
some rate limiting, showing the java script page for my IP (and hence
in other browsers on this machine as well).

I now let it run through, and it showed no problem. I will run it
twice more and report if that changes something.

Do you have some anti-DDOS or rate-limiting in place for debian.org?
If you look at the script, the core call is:
wget --quiet -O - "http://packages.debian.org/sid/amd64/$package/download"

where $package stores the Debian package in question (the script
iterates over all supported packages).

Currently a ".". If you need something else, I could of course try to
somehow store it (its a shell script, after all, but storing error
messages might be tricky, since pipes are involved).

Sure, I'm trying to provide all the information you need which you can
then link to the infrastructure knowledge of hosting Debians pages.

Greetings

            Helge

Hi,

Am 20. April 2026 18:23:28 MESZ schrieb Helge Kreutzmann <debian@helgefjell.de>:

I noticed that packages.d.o is somewhat unstable sometimes (I remember error messages like "no healthy backend available" or similar).
Not sure what to do against this though (or if this has already been addressed?).

Since several weeks (months?) Debian uses some mechanism to deal with issues like
<https://thelibre.news/foss-infrastructure-is-under-attack-by-ai-companies/>
Maybe this is your problem?
I was unable to find the name of the tool, though...

Hmm, I wonder if packages.d.o is the best service to use for such script runs.
Wouldn't it be more reasonable to pull the packages from a mirror?

That way, you would not rely on a single service/machine; using deb.debian.org would allow to use the CDN (content delivery network) service with its built-in capabilities, to use the best available mirror, or skip a mirror if it's down and choose another one automatically...
And load-balancing (on the mirror side) would also be included.


Holger

Hello Holger,
Am Mon, Apr 20, 2026 at 10:15:31PM +0200 schrieb Holger Wansing:

Yes, I'm assuming we are running into such kind of tools[1]. Maybe you can
forward to a person running / operating this tool from the Debian
side, maybe some kind of "cookie" or such could allow access for
legitimate users.

We pull the actual packages from a mirror, this call just is the
beginning of the extraction of the package version, then the script
automatically builds the download link from a mirror, and that part
(the actual download) did not show any problems so far.

(And before you ask - I'm upstream in this role, my co-maintainer does
not use Debian and runs these scripts as well, so local data is not
possible).

Currently the mirror is hard coded, as this did not cause any
problems yet. If so, we could make it dynamic, but since the sript
only runs maybe once or twice a month, this did not cause any concerns
on our side yet.

Thanks

Greetings

               Helge

[1] Actually, for some sites I see a short "verified" when reloading,
    but I'm not sure I saw this on p.d.o.

Hi,

Am 21. April 2026 16:45:19 MESZ schrieb Helge Kreutzmann <debian@helgefjell.de>:

I guess you need to contact DSA for this.

So it's just to determine the version number of the package in unstable?
If yes, rmadison (from devscripts) could also be a very lightweight alternative to achieve this:

`rmadison --arch=source --suite=unstable bash | awk '{print $3}' | tail -n 1`

If this means, that packages not only from Debian are used, so that you need a solution which works for several distros, then rmadison is of no use probably, since it's Debian-only.


Holger

Hello Holger,
Am Tue, Apr 21, 2026 at 08:06:02PM +0200 schrieb Holger Wansing:

Where do I need to reassign this bug report, then? Or should I keep it
here, for now?

Greetings

          Helge

Am 21. April 2026 20:19:56 MESZ schrieb Helge Kreutzmann <debian@helgefjell.de>:

I don't see a better package to assign this to.
Best write on debian-admin@lists.debian.org and point them to this bug.


Holger