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 ALf7GmbyRF+DOQAA0tVLHw (envelope-from ) for ; Tue, 25 Aug 2020 11:13:42 +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 OI+pFmbyRF9ZIAAAbx9fmQ (envelope-from ) for ; Tue, 25 Aug 2020 11:13:42 +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 E49E59402A2 for ; Tue, 25 Aug 2020 11:13:41 +0000 (UTC) Received: from localhost ([::1]:56364 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kAWtY-000255-ME for larch@yhetil.org; Tue, 25 Aug 2020 07:13:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40606) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kAWt4-0001iS-8O for guix-devel@gnu.org; Tue, 25 Aug 2020 07:13:10 -0400 Received: from fsfla.org ([2001:aa8:ffed:f5f3::140]:49668) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kAWt1-0004OW-7s for guix-devel@gnu.org; Tue, 25 Aug 2020 07:13:09 -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 0EBDE1E066C; Tue, 25 Aug 2020 11:13:00 +0000 (UTC) Received: from livre.home (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 07PBCksm151346 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Aug 2020 08:12:46 -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> <87bliz4b00.fsf@netris.org> Date: Tue, 25 Aug 2020 08:12:46 -0300 In-Reply-To: <87bliz4b00.fsf@netris.org> (Mark H. Weaver's message of "Tue, 25 Aug 2020 00:14:44 -0400") 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=2001:aa8:ffed:f5f3::140; envelope-from=lxoliva@fsfla.org; helo=fsfla.org X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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: s9eyT/IHF4ny Hello, Mark, On Aug 25, 2020, Mark H Weaver wrote: > Alexandre Oliva wrote: >> On Aug 15, 2020, Mark H Weaver wrote: >> >>> If I were to implement this, what would you suggest I do if the patches >>> fail to apply >> >> Look at the conflict presented by the rebase, and resolve the likely >> freedom issue introduced at that point. >> >>> if the result fails to match the next Linux-libre release? >> >> Identify the intervening commit where code that got cleaned up >> differently was introduced or removed and make the change to the >> deblobbing at that point; rinse and repeat. > In other words, your proposed approach cannot be done automatically in > the general case. Do you see how this is a problem? Remember a few emails ago when *you* argued that the changes to the deblobbing scripts were so infrequent that it would do no harm to use the scripts for an earlier release, without waiting for us to check that they work for a newer one? How come now the very same circumstances have become so frequent as to be a problem? You see, the cases in which there would be patch conflicts and need for manual resolution are those in which the cleanups made by older scripts are no longer enough to clean up subsequent trees. Most of these are cases in which manual intervention is required to adjust the scripts. But you wish to use the scripts to clean up intervening commits that it was never tested to work on and that it may actually fail on, leaving non-FSDG bits in place, *instead* of using a procedure that will reliably tell you about the IYO rare cases in which manual intervention is required. You dismiss our automated and manual verifications, you used to use outdated scripts, but you can't be bothered to run a simple procedure to check that there aren't freedom issues introduced in an upstream stable release, and to make the required manual adjustments to keep the builds FSDG-compliant? Heck, I'll be glad to publish, upon request, in the Linux-libre git repo, a verified-FSDG incremental stable release branch, i.e., a branch starting from one release and ending at a tree identical to that of a subsequent release in the same stable branch. Then you can point users at that branch for bisecting within that range. Should that be as seamless as I expect it to be, I might even start doing that regularly, for all stable releases, as an incremental step towards the git repo with the cleaned-up commit history of Linux development. > If a Guix user reports that one of their devices stopped working in > Linux-libre-5.4.34, I'd like to enable them to easily build deblobbed > kernels at intermediate commits on the upstream stable/linux-5.4.y > branch. That amounts to referring users to a non-Free source repo; that's not desirable per the FSDG. If we want to enable them to bisect for us, we should offer them our own cleaned-up history. > With the present approach, I can provide a simple Guix recipe > to do this automatically. ... and quite prone to misuse due to unreasonable expectations that our scripts can't live up to. > With your proposed approach, the user may > need to manually resolve merge conflicts and so on. Not all Guix users > will have the skills or motivation to do this. *We*, not the users, should get to prepare the cleaned-up repo and fix the conflicts, if we wish them to bisect for us. > Even _I_ would not want to do this, because it would mean doing > unnecessary labor. It would be unnecessary if we had magic scripts that worked reliably no matter what you threw at them. This is not the case, and your expectation that it is makes you perceive that as unnecessary labor. That we do only part of that labor, checking only actual releases rather than all intervening commits, might have been enough of a hint that it takes actual labor to get what you expect to get with zero effort. > I would much rather have my computer do this job > while I do something else, even if it takes longer. It can do much of it, but not all of it as you expect. You're unfortunately objecting to the manual labor in the very cases in which your computer is unable to do it :-/ -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer