- Dec 09, 2021
-
-
Jenkins for Software Heritage authored
-
Jenkins for Software Heritage authored
Update to upstream version '2.1.1' with Debian dir a786cf0f42e66c49ce8e9b19bac3de0246775840
-
Jenkins for Software Heritage authored
-
Jenkins for Software Heritage authored
Update to upstream version '2.1.0' with Debian dir eb38b742df07e370b2cad77663eeabd3c0a6d722
- Dec 08, 2021
-
-
vlorentz authored
This solves two problems: 1. if the URL changes but the content doesn't, then the new snapshot would keep using the release with the old URL in its name. 2. if there are two URLs pointing to the same content, the base loader would crash because it cannot know which one to pick.
-
vlorentz authored
-
vlorentz authored
instead of just its netloc, as it is possibly to have multiple maven instances hosted under the same domain but at different paths. The code is also simpler this way.
-
- Dec 07, 2021
-
-
Jenkins for Software Heritage authored
-
Jenkins for Software Heritage authored
Update to upstream version '2.0.0' with Debian dir d438110f17cfb1081789abeec22d514580f875e5
-
vlorentz authored
Snapshots should only record versions that currently exist; even if they used to exist in a previous visits. If readers of the archive want to access deleted versions, than can look up older snapshots.
-
vlorentz authored
-
vlorentz authored
We don't need it to be ordered; and '.keys()' is redundant.
-
vlorentz authored
-
vlorentz authored
-
vlorentz authored
-
vlorentz authored
It was copied from the Archive Loader, but is not needed here.
-
vlorentz authored
Use only the intrinsic version (eg. 1.0.0) instead of the extrinsic version (eg. stretch/contrib/1.0.0). Releases should only contain data from DSC, not external 'pointers' to them. Additionally, having extrinsic data in releases means the same dsc-sha256 extid can point to different releases, which meant the loader may reuse a release mentioning a specific suite as a release in a different suite. With this commit, this won't be a problem anymore, as releases won't mention the suite at all, so suites can safely share extids.
-
Antoine Lambert authored
-
Jenkins for Software Heritage authored
-
vlorentz authored
'version' was documented as the intrinsic version (eg. '0.7.2-3') and 'full_version' as the one containing the suite name (eg. 'stretch/contrib/0.7.2-3'). In practice, it was the opposite, except in a few incorrect test. This commit fixes said tests, and renamed 'full_version' to 'intrinsic_version'. This is only a refactoring, the behavior is unchanged for now; but a future commit will remove the 'version' (which is extrinsic) from the release name (which should contain only data intrinsic to the DSC).
-
Jenkins for Software Heritage authored
Update to upstream version '1.3.0' with Debian dir fe23ecbce454661586c67881705b3115a7c3240f
- Dec 06, 2021
-
-
Antoine Lambert authored
In order to check successful download of a package file, the debian loader will compare sha256 or sha1 checksum of the file with the one located in debian dsc file. However for old debian-based distributions (some ubuntu old releases for instance) the only available checksum in the dsc file is a md5 sum. So add a fallback to use md5 sum to check successful download when sha* checksum is missing in the dsc file. Related to T2400
-
Boris Baldassari authored
The maven loader loads jar and zip files as Maven artefacts into the software heritage archive. Note: Supersedes D6158 and addresses the review done in that diff. Related to T1724
-
- Dec 03, 2021