Do you mean just dropping monitoring of pending package upgrades?
I agree that notifications for "there are pending upgrades" is pointless. But it'd be nice to be nagged for pending security upgrades.
Would that be an acceptable middle ground?

updated description to reflect the fact that mediawiki is now back into Debian proper, including stable (!)

(since quite a while, thanks to swh.loader.core)

I've marked this as dependent on T709 as I'd like to avoid re-documenting details that are already coming in the docstrings of D248, and instead just point to them if/when appropriate.

I've added some minor comments in-line.

I've re-looked at this after the switch to the Merkle AST, and it looks good to me.

right, we should make that JSON output a list of, rather than single dictionary

I've just added a webmaster@ email alias (via the gandi console) pointing to… you :-) @anlambert (via your Inria email address). You can use that for wordpress upgrade notifications.

And of course right now there are a bunch of pending Wordpress upgrades, including a major version upgrade of the Layers theme :-)

I really like this module, the API is very clean and what I'd like to use.

(no change or additional comment, just updating the review status to reflect the discussion)

The main thing we agreed upon when discussing F2F about all this yesterday is that we want to do rendering on the client side, leveraging the information our indexer have extracted from the blob if available.
We mentioned highlight.js, but it might make sense to check what github is using (if it's client side), given we already use it on the indexer.

Looks good as a fix T779.

Good call in pausing this to avoid uffizi hangs (assuming this was the cause).
We want the different object storage copies to converge, so I think waiting for the archiver to close the gap (possibly increasing resources to it if that helps) before restarting this is the right solution here.

when committing this, do not forget to mention T747 in the commit message (mentioning this just because it happened in other recently accepted diffs related to the vault)

This is now implemented by H22, e.g.:

git push  --force
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 281 bytes | 281.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: *** PUSH REJECTED BY COMMIT HOOK ***
remote: 
remote: This push was rejected by Herald push rule H22.
remote:     Change: branch/master
remote:       Rule: forbid dangerous changes to the master branch in any repository
remote:     Reason: dangerous changes to master branch are forbidden
remote: Transcript: https://forge.softwareheritage.org/herald/transcript/58415/
remote: 
To ssh://forge.softwareheritage.org/source/sandbox.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'ssh://git@forge.softwareheritage.org/source/sandbox.git'

while it works when force-pushing to branches other than master.

this has been fixed in rDOBJS350c2e7bc94e

I'm closing this "parent" task because the porting work from flask to django is now done.
Additional features (e.g., web-based browsing) are still TODO, but no longer related to switching stack.

AFAICT this is now done as part of the generalization of default icinga2 checks on all our machines. (Please reopen if it's not the case.)

looks like this is no longer of interest

fixed by @anlambert in 49bfa06aff5c8fc97ac5217a74991d9557726463

we're taking a different route for this now, based on @grouss WIP

we're taking a different route for this now, based on @grouss WIP