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 yJWkFnFFQ1/KAgAA0tVLHw (envelope-from ) for ; Mon, 24 Aug 2020 04:43:29 +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 ODtSEnFFQ18zTQAAbx9fmQ (envelope-from ) for ; Mon, 24 Aug 2020 04:43:29 +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 BC1F1940602 for ; Mon, 24 Aug 2020 04:43:28 +0000 (UTC) Received: from localhost ([::1]:45924 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kA4KN-00066x-NB for larch@yhetil.org; Mon, 24 Aug 2020 00:43:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44616) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kA4K8-00065t-Ju for guix-devel@gnu.org; Mon, 24 Aug 2020 00:43:12 -0400 Received: from fsfla.org ([217.69.89.140]:48510) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kA4K5-0004G0-6z for guix-devel@gnu.org; Mon, 24 Aug 2020 00:43:12 -0400 Received: from free.home (unknown [201.82.51.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by fsfla.org (Postfix) with ESMTPSA id 6059D1DEFA9; Mon, 24 Aug 2020 04:43:06 +0000 (UTC) Received: from livre.home (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 07O4guON118665 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Aug 2020 01:42:56 -0300 From: Alexandre Oliva To: Mark H Weaver Subject: Re: Linux-libre 5.8 and beyond Organization: Free thinker, not speaking for FSF Latin America References: <87d03vv0nm.fsf@netris.org> <875z9kv41h.fsf@netris.org> Date: Mon, 24 Aug 2020 01:42:56 -0300 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 Received-SPF: none client-ip=217.69.89.140; envelope-from=lxoliva@fsfla.org; helo=fsfla.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/23 23:45:31 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org, Jason Self Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: bGy1vD5bSHMe Hello, Mark, On Aug 15, 2020, Mark H Weaver wrote: > I was talking about my hope to enable users, *on their own > machines* and using *their own private build recipes*, to make a > best-effort deblobbing of a non-standard kernel variant that they need > to use for whatever reason. A non-free kernel, standard or not, shouldn't really be in scope for a FSDG distro, IMHO. Even the pointer to the non-Free releases used as a starting point for build recipes comes across as undesirable to me, more so when there's an expectation (and such a high concern) for enabling users to use them, with a near-certainty that this will likely go silently wrong freedom-wise. > If they aren't provided with that option, > the obvious alternative (which I expect 99% of such users would do > anyway) is to simply run a fully-blobbed kernel instead. I'm surprised that they'd prefer to run deblobbing and checking at each point of a bisection, over applying the deblobbing changes as a patch, or even starting from a Free release, rebasing a set of changes to test onto it, and quickly building and bisecting that. That's what I would rather do. But then, I probably wouldn't be using the guix build recipe and default kernel config for the bisection, but rather a smaller config built within the bisect tree. > Alexandre Oliva wrote: >> I'm sure that's not what you intend, but this arrangement, plus your >> mention of hurriedly getting releases out, adds up to an incentive to >> disable the deblobbing so as to get a faster build. > I don't understand how you reached this conclusion. As far as I can > tell, changing Guix to run the deblob scripts made *no* difference to > what someone would have to do to ask Guix to build fully-blobbed > kernel. One of the issues, as you'd pointed out, was time pressure to get a build completed. If someone is under such pressure, and knows that deblobbing will take 30 minutes, and that verifying the deblobbed tree will take another 30 minutes (or 24 hours, if using the wrong tool for the job), one might disable the cleaning up rather than figuring out how to get the recipe to use an already cleaned and verified release. > In particular, if I can easily run an > automated process on my own machine instead of relying on some other > system to provide pre-generated outputs for me, then I prefer to do it > myself. That's at odds with the time pressure you mentioned before. Now, let me get something straight. You seem to have got the idea that I oppose verification of our releases. That's very very wrong. I welcome verification. I just don't see that this belongs in the guix build process. I get it that guix packages several projects that need cleaning up. IMHO, guix build recipes should NOT point at such upstream projects along with the cleaning up recipes. This should be part of a separate recipe, namely, that of packaging/verifying/blessing *sources* for use in guix. Once the sources are packaged (in a verifiable/reproducible way), they should be made available by the distro to users. These are the corresponding sources that we expect every distro to offer. It's not just about builders getting those sources, verifying them (or not) and making binaries out of them. Any user ought to be entitled to request corresponding sources to binaries provided by guix, and guix should be able to provide them without requiring users to run potentially complex procedures that might even end up producing different results, depending on platform-specific bugs, versions of tools, not to mention the various other potential sources of non-reproducible sources and binaries. Even if the procedures are meant to be reproducible, you'll only know they aren't when you manage to trace a difference in a packaged binary back to a difference in sources, when you can no longer reproduce the sources used before. Archiving the sources proper, for verification and for distribution to users as corresponding sources, would avoid surprises of non-reproducible procedures being found out long after the fact, just when corresponding sources are requested and can't be provided any more. I'm ambivalent as to whether patches that guix wishes to apply should be applied as part of source packaging, or have the patches made available separately. I can see arguments both ways. On the one hand, applying patches, as reproducible as it normally is, might be subject to occasional variations, especially when the line numbers or the contexts in the patch are inexact. On the other, these cases are extremely rare, and being able to reuse a base tarball while trying out some patches, without having to repackage a base tarball, and having patches conspicuously presented to builders and users, separately from an upstream base release, is desirable when the patches are not meant to address freedom issues (those that do address freedom issues had better be applied by other means during source packaging, to avoid publishing reversible patches that could be used to reintroduce the freedom issues). This suggests there could be support for patches in both source preparation recipes, and in build recipes. For projects that need cleaning up, the source packaging recipe could apply any needed cleaning up. For projects like GNU Linux-libre, that are already cleaned up, or most other packages that don't need any cleaning up whatsoever, the source preparation recipe could be as simple as downloading the sources, as well as any signatures thereof, checking that they match, and recording the checksums of the sources to be used for binary building. Source preparation might also offer a verify mode, that would *also* fetch the sources from a corresponding release of the project that needs cleaning up, perform the cleaning up and compare the results, but I'd much rather links to the corresponding projects that need cleaning up be pushed out of FSDG-compliant distros. Maintainers of such packages could and probably should run such verification themselves, without exposing every builder to the non-Free pointers and code. I urge guix to address the problem of build recipes pointing to non-Free packages and getting builders to download non-Free Software onto their machines. It would probably be wise to discuss more broadly how FSDG distros can document and share their cleaning up procedures, so that builders and users can double-check them if they wish to, and so that other FSDG distros can cooperate and reuse. Clearly we don't wish distro maintainers to keep these private to themselves, but we surely don't want links to sources containing unacceptable sources to be conspicuous in the distro either, let alone being used when Free sources are or could be readily available. Now, I wonder... If sources for projects other than Linux-libre and GNUzilla need cleaning up, perhaps it would make sense for our community, e.g. GNU, to undertake the source cleaning up, releasing clean sources for all interested distros and users to get to. Perhaps we could encourage maintainers of the such packages in the various Free distros to share and divide the workload of maintaining them and the cleaning up recipes, for everyone's benefit. Then guix could just point at the clean sources released by this project, instead of going through the significant change of introducing separate 'prepare sources' recipes to avoid pointing users at non-Free sources through build recipes. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer