Yes, we need a "phototheque" :-)

Yes, these reports must go in the publications page, @anlambert may you add this item too?
The bib snippet is in @moranegg's comment above.

This is now fully implemented in https://forge.softwareheritage.org/source/swh-graph/browse/master/tools/swh-graph-lookup/swh-graph-lookup.py

The guided tour is now in production, so this task could be closed.

In T4549#91850, @vlorentz wrote:

Hmm, strangely, file/dir names are missing from the response even when omitting the mask when querying the graph server on granet; but based on the .proto file, they should be available via the successor field of Node.

Here is a dump of my design notes on this task.

Polished up and shared the tool built to produce the refined list priority.list.github.
It is now available at https://github.com/rdicosmo/swh-check-repositories

@ardumont here is the subset of the repositories on GitHub, ordered by number of stars, that are:

• still on GitHub
• not a fork

In T4400#88794, @ardumont wrote:

I took the opportunity to retrieve large origins [7] out of the sentry issue listing [6] (cf. description) [8].
And schedule those in the large queues after the one scheduled out of the scanoss exchange.

If it's considered useless at some point, feel free to dismiss them (by purging the queue).

[7] 28310 unique origins ->

loader-git.pack-file-too-big-issue-5823.urls.txt.gz288 KBDownload

[8] command used to create the listing out of sentry, in a venv (snippets repository) in worker1.staging:

(sentry-U52ipwI-) ardumont@worker1:~/snippets/ardumont/sentry% python -m list-urls-from-issue --project-name swh-loader-git --event-id 5823 | tee loader-git.pack-file-too-big-issue-5823.urls.txt
...

As of version 0.5.1, the updateswh extension is now stable, and released, with development on https://github.com/rdicosmo/updateswh, and landing page on https://www.softwareheritage.org/browser-extensions/

Ongoing on https://github.com/rdicosmo/updateswh, landing page is on https://www.softwareheritage.org/browser-extensions/

Nice catch.... actually, the GitLab API uses the project slug (e.g.: checkscale-gitlab/git-wtf) without the .git, we should make sure we can handle this same slug

Is this fixed now, or is the issue still open?

In T3230#83166, @VickyMerzOwn wrote:

Hey, I would like to work on this issue.

Sometimes these variants site side by side with the plain text ones

I didn't understand what site here means.