@rdicosmo:
https://archive.softwareheritage.org/browse/revision/cccf789c12617208fe188ad3dbc2746d4c884ab7/?origin_type=deposit&origin_url=https://hal.archives-ouvertes.fr/hal-01831369
on trouve un fichier .tar.gz et non pas le contenu du .tar.gz proprement traite.
@morane, @ardumont: ce n'est pas encore regle cote HAL cette histoire de double conteneur, vous pouvez regarder?

@ardumont:
Rien n'est possible cote swh:

• pas d'acces a leur infra (Bruno)
• pas d'acces a leur code pour aider a identifier le soucis (Bruno)

@ardumont:
Je parlais du point de vue d'infra hal.
En prenant un peu de recul et reduisant la contrainte, je me suis rappelle d'une chose.
Nous avions discute cote swh de refuser les depots dont l'archive est mal formee (ce depot ici qualifiant). [1]

Cela n'apportera rien au probleme en cours ici, la suggestion d'un nouveau depot avec archive zip de roberto est tjs valide.

Toutefois, cela permettra de:

• reduire la frequence de ces depots (et ne pas "polluer" l'archive)
• mettre en evidence le probleme [2]

[1] https://forge.softwareheritage.org/T1123, https://forge.softwareheritage.org/T1122

[2] Pour information, j'ai rajoute pour faciliter les echanges avec Jozefina, l'acces aux verifications en echec quand le depot est rejete.
Et cette information se voit par l'api du statut du deposit (qui est reference cote hal en cas d'echec).
En ajoutant le check d'archive mal formee, cela apparaitra.

@rdicosmo:
Ok, cela me semble un bon plan