Subject: [bug#29784] [PATCH 2/2] gnu: Add python-activepapers

From: Konrad Hinsen <[email-masked]>
Date: Thu, 21 Dec 2017 12:52:51 +0100

Hi Ludo,

> Below are some suggestions: avoid non-top-level ‘use-modules’ form, and
> use ‘invoke’ as discussed recently on guix-devel.

Fine with me! I looked for inspiration in other package definitions, but
probably not the best/most recent ones.

> I’m getting a hash mismatch on the source:

>   expected: 02bpx36ixwag1g958plgjwpxaiadsj4669gsnxc8hb5aw2jplnr5
>   actual:   12wkhjh90ffipjzv10swndp2xv9hd7xrxvg6v0n4n3i411pj4xb8
> --8<---------------cut here---------------end--------------->8---
>
> Could you check if something is amiss?

I figured out there the mismatch comes from, but I have no idea how I
could (and still can) build python-activepapers on my machine, using
precisely the definition I submitted.

I had used a local file (URI of type file:///) for testing, and that's
where the SHA256 in the package definition comes from. Then I uploaded
the working version to PyPI, but from a different machine. I rebuilt the
tarball on that machine, from identical source code, but Python's
setuptools does not care about reproducible builds, so the file I
uploaded has a different hash.

Next I changed the URI in the package definition to (pypi-uri), but
didn't think about verifying (and updating) the hash. I did, however,
re-build the package (two rounds), and that worked fine. I just did it
again, it still builds.

This looks like Guix still uses the tarball in the store, in spite of
the fact that I updated the URI in the package definition. In fact,
nothing is built at all, "guix build" merely shows the store path of the
already existing build. Even when I add --round=2, nothing gets rebuilt
at all.

Konrad.