ok, here are the building blocks I've prepared to resolve this task, as a step by step recipe:

For info: it looks like the fix for T755, which is now deployed on pergamon, requires the version of monitoring-plugins-basic that is on Debian Stretch; previous versions do not have the --only-critical flag.
So, until this is fixed, pending package upgrades on all workers have status "unknown". (Which isn't a big deal.)

FTR, the query I've used to generate the stats is:

can we first check if we agree on the proposal above between us?
then, sure, @anlambert can get Fred in the loop before implementing this

In T810#14672, @ardumont wrote:

I did have sphinxcontrib-httpdomain-1.5.0 installed...
Removing it, i now reproduced the error:

In T810#14667, @ardumont wrote:

The initial sphinx output is misleading. Even though i don't reproduce the error, on my side (cf. P184), the sphinx message output seems to be scrambled when reaching swh-deposit.

here is the traceback

and here's the actual disk usage (!= compressed size)

/srv/softwareheritage/scratch/lists $ xzcat oversize-contents.txt.xz | while read id ; do du $(swh-ls-obj $id) ; done | cut -f 1 | paste -sd+ | bc
16847900696

those are KB, so the total disk usage is ~15.5 TB (not bad!)

D258 should take care of this, we'll see for real when it's deployed.

Assuming it works, this should give quite a blow to T755.
Relevant doc is at https://www.icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#apt

as a datapoint, at the time of writing the total (uncompressed) size occupied by content objects that are larger than our current limit is as follows:

In D255#5235, @ardumont wrote:

Shouldn't we have a tool to update this regularly based on the different metadata we already have spread across the repository (setup.py, debian/control, debian/copyright, debian/changelog, git tag, etc...)?