Hello,

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

> We have an empty Disarchive spec here:
>
>   https://disarchive.ngyro.com/sha256/d59726f34f7852a081fbd3defd1ab2136f174110fc2e0c8d10bb122173fa9ed8
>   https://disarchive.guix.gnu.org/sha256/d59726f34f7852a081fbd3defd1ab2136f174110fc2e0c8d10bb122173fa9ed8
>
> Thoughts?

This is due to a bug that is fixed as of Disarchive 0.6.0 (see the NEWS
file or commit c669e1c for details).  This bug interacted badly with the
PoG code resulting in a handful of corrupt Disarchive specifications.

I found four corrupt specifications in the set that we synchronized:

    • 095f4b5 isl-0.11.1.tar.bz2
    • 6b8b0fd isl-0.18.tar.bz2
    • 881f238 libass-0.14.0.tar.xz
    • d59726f isl-0.19.tar.bz2

The three isl ones are due to a typo in the Guix source.  The libass one
likely comes from when I was testing XZ support.

I have three more corrupt bzip2 specifications from the set that we have
not yet synchronized:

    • 3f66bce mingw-w64-v11.0.1.tar.bz2
    • 0cd846c nsis-3.09-src.tar.bz2
    • bd0ea16 mingw-w64-v11.0.0.tar.bz2

They are likely due to testing bzip2 support.

Of all of these, Disarchive can only produce specifications for the isl
sources.  I’ve attached their specifications; they should replace the
corrupt ones.  The corrupt libass specification should be deleted.

If possible, could you run something like

    find . -exec zgrep -H -F '(version 0) #f' '{}' ';'

over the specifications at disarchive.guix.gnu.org?  If there are more
broken specifications (unlikely but possible) we should fix them.  Just
post the hashes (i.e. filenames) of any that you find, and I can
investigate further.


-- Tim