In D8878#230887, @vlorentz wrote:

thanks!

Is it visible on the Downloads page even if someone else requested the cooking?

In D8879#230885, @vlorentz wrote:

Why not urlencode? Couldn't this be an issue with other characters?

Nice catch, fixed in D8878.

Remove cypress upgrade, the hanging bug appeared again after a couple of job executions (sigh)

Trigger new build

Add commit fixing a flaky cypress test

Update commit message

Final update:

• package.json: Revert cypress upgrade to 11.x again
• cypress: Increase sqlite3 busy timeout

Update

Update

Try to enable electron and chromium logging

Update

Try to disable GPU use with electron

Update

Remove use of custom docker image

Try to use chromium to run cypress tests

Cypress tests still hanging, trying another base docker image

Update

Update

Update

Update

Add libpq-dev and libcmph-dev to docker image

Update

Upgrade pip in docker image

Add postgres to docker image

Add git in docker image

Experiment with other docker image for running cypress tests

Rebase and remove unused fields in dicts sent to rpm loader.

Fixed and deployed.

In D8379#230308, @franckbret wrote:

@anlambert hi, can we merge this one?

Rebase

Rebase

Looks good to me, thanks !

@KShivendu , before landing this please fix the year in some license headers and update tests to match fedora lister output.

@KShivendu , we are almost in a landable state for the RPM loader.

Update commit message

The issue comes from the fact that the webapp gets the release names from the release objects of our data model and not
from the branch names targeting releases in associated snapshot object.

In D8386#229912, @olasd wrote:

In D8386#229890, @anlambert wrote:

In D8386#229882, @olasd wrote:

In D8386#229677, @KShivendu wrote:

@anlambert

I noticed that https://archive.softwareheritage.org/browse/origin/directory/?origin_url=deb://Ubuntu/packages/nginx has duplicate branch names, which is very confusing. In fact, even the default branch is repeated twice and I see two check marks. If we use branch names like 0.3.9-15.fc26, won't the same happen with Fedora listers? It doesn't seem to differentiate between the editions. (or does it?)

This seems like a misfeature in the webapp:

https://archive.softwareheritage.org/api/1/snapshot/158a3f36b0bd3da461fb7458de44cfa2c94e4270/

The snapshot has multiple branches, with the same version suffix, pointing at the same objects (because the exact same version of the package is present in multiple Ubuntu suites).

I'm not 100% sure how we should be fixing that, but that bug shouldn't prevent you from giving the fedora snapshots the "semantically correct" structure.

I also noticed that yesterday evening and I was also wondering what is the best way to fix that. I see two possible options:

1. We change the names of the keys in snapshot branches dictionary in order to use the intrinsic version of a debian package instead of its extrinsic one (meaning releases/bionic-security/main/1.14.0-0ubuntu1.10 should rather be releases/1.14.0-0ubuntu1.10)
2. We update the webapp to filter duplicated releases before display as the release name is used instead of the snapshot branches key associated to the release

I would rather go for the second one as keeping the debian/ubuntu suites and components in keys of snapshot branches dictionary seems of interest.
We could do the same for the fedora case as based on my tests it is quite common that extrinsic versions in the form [0-9].[0-9].[0-9]-[0-9].fc[0-9]+
target the same intrinsic version [0-9].[0-9].[0-9]-[0-9].

We should move this branch (ha) of discussion to a separate task. I would really want us to keep (and display) the information about what suites have been detected to contain what package.

How does the webapp get the release name showed in the menu? From the release object, or from the branch name?

I think it would make sense to display the branch name after the release name, if it didn't match the usual refs/tags/$(release name) pattern

Nice catch !

Looks good to me, thanks !