From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37477) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eRzQN-0001ao-5x for guix-patches@gnu.org; Thu, 21 Dec 2017 06:54:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eRzQI-0004sU-6m for guix-patches@gnu.org; Thu, 21 Dec 2017 06:54:07 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:36669) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eRzQI-0004sL-2r for guix-patches@gnu.org; Thu, 21 Dec 2017 06:54:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eRzQH-0001P3-PT for guix-patches@gnu.org; Thu, 21 Dec 2017 06:54:01 -0500 Subject: [bug#29784] [PATCH 2/2] gnu: Add python-activepapers Resent-Message-ID: From: Konrad Hinsen In-Reply-To: <87zi6c8kui.fsf@gnu.org> References: <87zi6c8kui.fsf@gnu.org> Date: Thu, 21 Dec 2017 12:52:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 29784@debbugs.gnu.org Hi Ludo, > Below are some suggestions: avoid non-top-level =E2=80=98use-modules=E2= =80=99 form, and > use =E2=80=98invoke=E2=80=99 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=E2=80=99m 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=3D2, nothing gets rebuilt at all. Konrad.