what kind of inventory we want to do with this? hardware? software? both?

LGTM

This comes from a discussion between myself and @vlorentz . To summarize my position: I would like to be able to tell downstream users "the keys we use in our metadata are (a subset of) the codemeta ones". AFAICT that means that they should be able to look them up here: https://codemeta.github.io/terms/ . As such, we should not use keys like schema:author, but simply author; similarly we should not use codemeta:issueTracker but simply issueTracker.

I've attached here T917, which was just a specific instance of this.

In D668#14656, @douardda wrote:

In fact, there are other place(s) where we can find kind of partial glossaries, especially https://docs.softwareheritage.org/devel/swh-model/data-model.html#software-artifacts . Not sure how to deal with this later one however. It makes sense to keep these definitions explicitly in this document, IMHO.

Regarding the glossary, we also had https://wiki.softwareheritage.org/wiki/Glossary ; once this is pushed the wiki glossary should be deprecated/deleted in favor of the docs.s.o one. In the meanwhile there might be entries there that are missing here (I haven't checked, but wanted to mention potentially useful previous work :-))

Would removing your 3rd requirement (per-package indexes) simplify things? I don't see that as a goal at all, just what happens by default with the minimalistic sphinx setup we used back in the days. I'd be much happier if we could have a single index / navigation bar, where the doc of all modules appear.

Thanks for filing this @moranegg !

The simplest solution would be to check if the computed timezone offset lies in the adequate bounds [UTC−14:00, UTC+14:00] and set it to 0 if not.

@ftigeot thanks for checking!
Please file tasks for changing the failing batteries (priority high) and automate the monitoring of failing batteries so that in the future we will be automatically notified of future similar failures (priority normal).

@anlambert: let's do this. Green light, go ahead!

In T1219#24586, @vlorentz wrote:

Resolved by D622.

thanks! can you ping me when this fix (T1304) is deployed?

thanks! can you ping me when this fix (T1303) is deployed?

Oh, silly me, I commented without checking that first.
Fine by me then :) Thanks!

I've tried this before too, but we can't do that yet, because the version of msgpack we use in Debian stable doesn't yet have raw=False.

In T1304#24431, @anlambert wrote:

This seems due to releases pointing to missing revisions in the archive, see for instance http://localhost:5004/api/1/release/21d03ad29cfa315d8b7e5d7577964fbc21797f74/

In T1249#24433, @douardda wrote:

I suggest to call it good as is, and set a proper solution up if and only if it really obviously cause problems...

(I also note that the search results page treat both cases similarly: showing an X for both kind of origins. Good!)

To elaborate, the user-visible result should be the same of origins that haven't been visited yet, e.g.:

In D592#11583, @olasd wrote:

I don't quite understand what the "fs" marks are supposed to convey, but they're carried over from nose without change, so *shrug*.