From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 30 11:27:56 2021 Received: (at 51307) by debbugs.gnu.org; 30 Oct 2021 15:27:56 +0000 Received: from localhost ([127.0.0.1]:58167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mgqGx-00050m-P4 for submit@debbugs.gnu.org; Sat, 30 Oct 2021 11:27:56 -0400 Received: from mail-wm1-f47.google.com ([209.85.128.47]:51075) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mgqGv-00050J-Gm for 51307@debbugs.gnu.org; Sat, 30 Oct 2021 11:27:53 -0400 Received: by mail-wm1-f47.google.com with SMTP id 133so1110163wme.0 for <51307@debbugs.gnu.org>; Sat, 30 Oct 2021 08:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=v+Ibs/l/f+XV1/PwBR1Z0B0FiXxQDSMX9HEqpW8qAgc=; b=CY6C5gkiqVn9NOfEhtICrlkAzVGL/BbmlgKFTFp1jR+1md/YL22NDK5DTzoZtsVILd Tnnc7vXrHIUzmt8CHJ5vsT7vN/spN1dF6RXZFPYiqrgx77yF+a5+T8D4RBw3PpV72r9h Qjiy9PIFxqmKbEVDR7W/VHp5qCOCjj2YMuPhxlM2C+YfYxEx7GAzsjD3A+uTbE55jKtt NkU1PtlVoykAXHMbIqowq/r1WJeG+kqnrJyxBS974kHjHMq0amXbzNPgzBL96kszzkkn hwfN8VGnqd/joJmRdwnInDCdCJN1v7nTAvX0qizUAHddsA8KG04oZSwhcldQQ3ZrBTV/ 3AlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=v+Ibs/l/f+XV1/PwBR1Z0B0FiXxQDSMX9HEqpW8qAgc=; b=qouKNO0TmkzXMrl7BzzcORf6rPgdf394EJ7JzcLrut/5ICIv57KHys1CXwr0k3wIp3 MsyBHV9fcmRMRf7LPslSLhOIEuop8FfP0dVFlyG7mzixJ0On5Km40a9w6mMs0sQggERw 2GLSxsPxoozTrt4YaacSVFOGNQC4BDSQjtJDKVbyKSXLmjJ/RKTU/zNavD4fRUE1Bwje aON4Dn2KXKNARu6o2EJdgbi/DMsRu+WzUJdFPpFJp6Lzc3hhgOgkZMc5uj/zYzEWuDlV gHJKLT9bmscv/Ntc+yLrwB+f0ZGJg+6yauDkyz0P7rcetxOoH3Bf+Ei1jcubI8869KNx WXRA== X-Gm-Message-State: AOAM53340LYTaLmYgi7HHAvuOZ6l0TXi9DRg+7gU6mlJSMVTJbZUIc6/ Enj41ts93dfzHtAs9wl17xn56UF+tQ4= X-Google-Smtp-Source: ABdhPJxEYIVjmwjpA7Psrdh0FJf2pJZoYboQPK0AgdYyu0LO+k11DYKOnDgsqLxCsjoZzmJDhs0fcQ== X-Received: by 2002:a1c:9851:: with SMTP id a78mr6600128wme.116.1635607667595; Sat, 30 Oct 2021 08:27:47 -0700 (PDT) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id n9sm8173586wmq.6.2021.10.30.08.27.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 Oct 2021 08:27:47 -0700 (PDT) From: zimoun To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#51307: [PATCH 0/2] guix hash: eases conversion In-Reply-To: <87wnlusgwy.fsf@gnu.org> References: <20211020165020.3358311-1-zimon.toutoune@gmail.com> <87wnlusgwy.fsf@gnu.org> Date: Sat, 30 Oct 2021 17:19:56 +0200 Message-ID: <86tugyleub.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 51307 Cc: 51307@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Ludo, On Sat, 30 Oct 2021 at 16:53, Ludovic Court=C3=A8s wrote: > zimoun skribis: > >> 2. Using the option recursive changes the result for tarball, as with: >> >> $ guix hash $(guix build hello -S) >> 0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i >> >> $ guix hash $(guix build hello -S) --recursive >> 1qx3qqk86vgdvpqkhpgzq3gfcxmys29wzfizjb9asn4crbn503x9 >> >> And I am not able to imagine a case. To me, it should be a fixed-po= int. >> That=E2=80=99s what the first patch correct. > > That=E2=80=99s expected: =E2=80=98--recursive=E2=80=99 uses a different c= omputation method, > including file metadata (technically, it serializes the file as a nar > and computes the hash of the nar). Yes, but that=E2=80=99s odd. It should be the same computation method for tarballs. Nothing is recursive for a tarball therefore, the option should be skipped. This proposal is perhaps not the best approach although I lacked of imagination about corner cases. >> Then, working on Disarchive which uses base16 as encoding, it is annoying >> twice, >> >> a) because it requires to download when all the sources >> b) because it sometimes requires to apply patches >> >> Compare, >> >> $ guix hash $(guix build ceph -S) >> 0ppd362s177cc47g75v0k27j7aaf27qc31cbbh0j2g30wmhl8gj7 >> >> with the checksum in the package definition: >> 0lmdri415hqczc9565s5m5568pnj97ipqxgnw6085kps0flwq5zh. >> >> With the second patch, it becomes easy to convert the checksum from upst= ream: >> >> $ ./pre-inst-env guix hash ceph -f base16 >> f017cca903face8280e1f6757ce349d25e644aa945175312fb0cc31248ccad52 >> >> and nothing is downloaded. Get the checksum of what Guix really builds = is >> done via the current way, for instance, >> >> $ guix hash $(guix build ceph -S) -f base16 >> 473e4461e5603c21015c8b85c1f0114ea9238f986097f30e61ec9ca08519ed5e >> >> and the second patch allows to convert the checksum from the package >> definition (without downloading). > > Ah yes, got it. (I should read messages in the right order, oops!) > > An obvious problem with the interface you propose is that it=E2=80=99s > ambiguous: are you printing the hash of the =E2=80=98ceph=E2=80=99 packag= e, or computing > that of the =E2=80=98ceph=E2=80=99 file? I=E2=80=99m sure the Zen of Pyt= hon has something on > ambiguity. ;-) The patch is printing the hash of upstream and it is the only hash which matters =E2=80=93 speaking both about packaging and about Disarchive. Therefore, there is no ambiguity here. Better said, the ambiguity is from =E2=80=9Cguix build --source=E2=80=9D where it is not predictable befo= rehand what it will return. For instance, can you guess what =E2=80=9Cguix build -S graphviz=E2=80=9D r= eturns? ;-) And can you guess the hash? > Do you think there=E2=80=99s another place where we could provide helpers= for > the die-hard Disarchive hackers among us? Maybe we could get =E2=80=98gu= ix lint > -c archival=E2=80=99 to print Disarchive URLs upon failure, and that=E2= =80=99d already > help? To me, =E2=80=9Cguix hash=E2=80=9D is about hashing therefore it appears to= me the right place for getting the hash of something. For instance, I do not find =E2=80=9Cguix lint -c archival=E2=80=9D the right place for sending a reque= st and saving to SWH; as olasd said at the time, IIRC. :-) However, the good is that =E2=80=9Cguix lint =E2=80=9D just works (for archiving). :-) Last, I do not want Diarchive URLs upon failure, I would like hashes and upstream URLs on request. :-) Well, I do not know. What could be better? Another subcommand =E2=80=9Cgu= ix archival=E2=80=9D doing all these plumbings: save, display hashes, upstream= URL, disarchive URL, etc. WDYT? Cheers, simon