what values should we give to the new provider-url argument in the current icinga checks for staging and production? (the web-url one is easier :P)

kthxbye

I think this all looks good, thank you! Obviously, the consistency with other RPCs is much appreciated.

Great, thanks!

I really wish this had some kind of encapsulation/separator, but I guess with using raw bytes that's not really practical...

So, this is all matching the currently deployed version of swh-deposit, correct?

Cool, thanks (see inline comment).

@vlorentz looks like you didn't push the right commit in this diff update

Great, thanks.

Thanks

Does the get_stream method guarantee the size of the received chunks? By default I would assume that it chunks contents using the passed size as a maximum.

Thanks, that's been an itch previously.

Looks useful, thanks.

Cool, thanks

"If needed, for special cases like unprivileged containers, sandboxing can be disabled on opam init with the --disable-sandboxing flag (only for non-initialised opam)".

Appease the sphinx deities

Deferred auto_now fields don't get updated, apparently.

hello? is it me you're looking for?

Harden against the race condition @vlorentz noticed

In D7090#184589, @vlorentz wrote:

I just checked, and the update is racy. (on postgresql only; it's not on sqlite since sqlite does not allow this kind of concurrency, at least not by default)

In D7090#184589, @vlorentz wrote:

By the way, I just realized the time filter is only on the filter_to_disable query, not on filter_to_update. How come?

In D7090#184519, @vlorentz wrote:

Shouldn't storage_db.cursor() be used as a context manager to make sure transactions committed/rolledback appropriately?

Apply comments from @vlorentz

I see you have to always ignore the typing when manipulating self._state.revs_to_visit, would it make more sense to make it an attribute of the child classes directly?

On top of the role, we need to store a mapping (I assume, in the swh-deposit database?) of which clients the moderator is allowed to view. Since we'll have to handle this information, is a new keycloak role *also* needed?

Thanks

Looks like at least some parts of staging don't have access to sentry anymore; on storage1, for instance, https connections to sentry.softwareheritage.org just hang.

Nice, thanks!

I'm not sure I like this change. What is the advantage of this over keeping an insert into dbversion ... statement in the SQL files, which would be used when the database is initialized?

Thanks, this looks like a good step forward!

Cheers!

In favor of D7057

In D7051#183460, @ardumont wrote:

Am I right in understanding that there will be a process in which users ask for some
changes (about their display name) and then we are modifying (in db) the new displayname
field in the Person table [1]? And then the reading part will simply use that
displayname (if present) over the fields we used to use for display.

• (fallout of D7053) Make test_release_add_get_arbitrary non-flaky
• add suggested comments for NULL name/email
• add tests for revision_log

Meh, but I guess there's no real way around it...

Add tests + rebase on D7053

I've thought of mentioning here a couple of issues that I've seen come up again over the past few days:

In D7039#183041, @douardda wrote:

In D7039#183023, @olasd wrote:

Thanks.

--build-dep-resolver=aptitude should only be used when building with an extra-repository which has a non-default priority, that is only when using a -backports suite (so only for the bullseye and buster instructions). It should probably be documented in the list of "useful options" rather than as the default.

But does it hurt to use it by default?

In T3887#77951, @zack wrote:

Do you foresee any issue in adding extra_headers to releases as well, other than "someone should do it"?

Now that I've written it out loud, of course, Releases don't have extra_headers so the package loaders can't make use of this workaround/hack for now.

From merged tasks, this would also be useful for some package loaders, e.g. npm, that support multiple authors in their packaging metadata.

Practically, we could be storing the metadata on additional authors *now* in the extra_headers field (make them a bunch of (b'author', b'XXX <yyy@zzz.ttt>') entries). Of course, that doesn't solve the question of presenting the information.

Is this information fully intrinsic, or can it be modified without the revision id changing ?