From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id kIE2EvwUMl+7DwAA0tVLHw (envelope-from ) for ; Tue, 11 Aug 2020 03:48:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id aaXXDfwUMl+nFAAAbx9fmQ (envelope-from ) for ; Tue, 11 Aug 2020 03:48:12 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id B03FF94005D for ; Tue, 11 Aug 2020 03:48:11 +0000 (UTC) Received: from localhost ([::1]:34942 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k5LGj-0003tO-19 for larch@yhetil.org; Mon, 10 Aug 2020 23:48:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48520) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k5LGc-0003tF-PK for bug-guix@gnu.org; Mon, 10 Aug 2020 23:48:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:54851) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k5LGc-0003dr-GK for bug-guix@gnu.org; Mon, 10 Aug 2020 23:48:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1k5LGc-0004ik-E8 for bug-guix@gnu.org; Mon, 10 Aug 2020 23:48:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#42789: Linux-libre 5.8 and beyond Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 11 Aug 2020 03:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42789 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Leo Famulari Received: via spool by 42789-submit@debbugs.gnu.org id=B42789.159711766018116 (code B ref 42789); Tue, 11 Aug 2020 03:48:02 +0000 Received: (at 42789) by debbugs.gnu.org; 11 Aug 2020 03:47:40 +0000 Received: from localhost ([127.0.0.1]:38164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k5LGG-0004i8-87 for submit@debbugs.gnu.org; Mon, 10 Aug 2020 23:47:40 -0400 Received: from world.peace.net ([64.112.178.59]:55154) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k5LGE-0004hu-Af for 42789@debbugs.gnu.org; Mon, 10 Aug 2020 23:47:39 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k5LG5-000647-IF; Mon, 10 Aug 2020 23:47:29 -0400 From: Mark H Weaver In-Reply-To: <20200810015931.GA24189@jasmine.lan> References: <87lfio4hs4.fsf@netris.org> <87v9hscwm7.fsf@ponder> <877du7adz6.fsf@ponder> <87imdr4g60.fsf@netris.org> <20200810015931.GA24189@jasmine.lan> Date: Mon, 10 Aug 2020 23:46:34 -0400 Message-ID: <871rkdj13e.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.0 (-) X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Vagrant Cascadian , 42789@debbugs.gnu.org Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: QGUQ6YLjGUo+ Hi Leo, Leo Famulari wrote: > On Sun, Aug 09, 2020 at 06:17:48PM -0400, Mark H Weaver wrote: >> If the file name and hash matches a previously downloaded file in your >> store, the guix daemon uses that one and skips the download, regardless >> of the URL. That's why no error was reported. There's no version >> number in the file name of the 'deblob-check' file. > > We should try to make these files include the version number to avoid > this kind of mistake in the future. That's a good idea. In a later message you posted a proposed patch: > From e9ca6405e351baf4356a7300aa252d25056a322c Mon Sep 17 00:00:00 2001 > From: Leo Famulari > Date: Mon, 10 Aug 2020 12:40:49 -0400 > Subject: [PATCH] gnu: Use a descriptive file-name for linux-libre > 'deblob-check' scripts. > > Fixes . > > * gnu/packages/linux.scm (linux-libre-deblob-scripts): Use file-name for > the deblob-check script. > --- > gnu/packages/linux.scm | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm > index a2d6d384ee..9d553e7772 100644 > --- a/gnu/packages/linux.scm > +++ b/gnu/packages/linux.scm > @@ -200,6 +200,7 @@ defconfig. Return the appropriate make target if applicable, otherwise return > (uri (string-append "https://linux-libre.fsfla.org" > "/pub/linux-libre/releases/" version "-gnu/" > "deblob-check")) > + (file-name (string-append "linux-libre-" version "-deblob-check")) > (sha256 deblob-check-hash)))) > > (define deblob-scripts-5.8 If we're going to prefix "linux-libre-" to the name, which I agree is a good idea, maybe we should add the same prefix to the other 'deblob' script, for consistency. Also for consistency, I think the version number should be at the end, after "deblob-check", as is the case for the other deblob script. There's also the question of whether the micro version number should be included in the file name. In practice, these deblob scripts almost never change from one micro version to the next. Also, I suspect (although I've not yet confirmed it) that these deblob scripts likely work for older kernels in the same stable series. For those reasons, at present the micro version number appears only in the URLs, and not in either the file names or in the version number as recorded in the first element of the triplet returned by 'linux-libre-deblob-scripts'. I'd personally be inclined to keep it that way, although I don't feel strongly about it. What do you think? Thanks, Mark