From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 03 10:11:07 2018 Received: (at 26608) by debbugs.gnu.org; 3 Sep 2018 14:11:07 +0000 Received: from localhost ([127.0.0.1]:44443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fwpZK-0003e8-Nr for submit@debbugs.gnu.org; Mon, 03 Sep 2018 10:11:06 -0400 Received: from [82.153.16.8] (port=47017 helo=ronja.pompo.co) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fwpZH-0003dC-9s; Mon, 03 Sep 2018 10:11:04 -0400 Received: from rosser (vodsl-8997.vo.lu [85.93.202.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ronja.pompo.co (Postfix) with ESMTPSA id 3C8A7402FA; Mon, 3 Sep 2018 14:10:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pompo.co; s=mail; t=1535983857; bh=3zF55RApxQW/X+upZzku+GEwteudvedpfMUF3yyndPY=; h=References:From:To:Cc:Subject:Reply-To:In-reply-to:Date:From; b=dGcGBQplM2cxJPiAJ65dE/mruEa2WYSs6OJFynsAs7kJeVQQNS6E97m2z/Lv683eC wcklV4yzz6f7FBGTEXaOYhia3HCwyO89s8HvlKRU+2kverTnV0NTrQNs4SjFvYt6BP 9aV680wXUDZ/bWLN93x9gpmNQZTW8r+/IDw7eoss= References: <87vb5vsffd.fsf@gnu.org> <87pny2iks2.fsf@gnu.org> <877ekagtg9.fsf@netris.org> <87zhx5msfl.fsf@pompo.co> <87lg8pccys.fsf_-_@netris.org> <87zhx59gh3.fsf@elephly.net> <875zzs9wzl.fsf@netris.org> <874lfcxd2v.fsf_-_@gnu.org> <87wos8lzcj.fsf@pompo.co> <878t4nqzqv.fsf@gnu.org> User-agent: mu4e 1.0; emacs 26.1 From: Alex Sassmannshausen To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#22629: =?utf-8?B?4oCcU3RhYmxl4oCd?= branch In-reply-to: <878t4nqzqv.fsf@gnu.org> Date: Mon, 03 Sep 2018 16:10:36 +0200 Message-ID: <87r2iau0wz.fsf@pompo.co> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Ludo, Ludovic Courtès writes: > Hi Alex, > > (Cc’ing and , > which are related.) > > Alex Sassmannshausen skribis: > >> I don't know if this is what Konrad desires, but from my perspective, a >> desirable part of the definition of stable would be a that the build >> farms have produced a set of binaries/substitutes for a given Guix >> revision that is "good enough". > > I just had a bright idea (yes!): this can be addressed by writing > something like this in ~/.config/guix/channels.scm: > > (map latest-commit-with-substitutes-available > %default-channels) > > The hypothetical ‘latest-commit-with-substitutes-available’ would use > (git) and (guix ci) to find the latest commit for which substitutes of > interest are available, and would return: > > (channel > ;; … > (commit "cabbag3")) ;the ideal commit [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Debbugs-Envelope-To: 26608 Cc: 26608@debbugs.gnu.org, Konrad Hinsen , 22629@debbugs.gnu.org, 32022@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: , Reply-To: alex@pompo.co Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Hi Ludo, Ludovic Court=C3=A8s writes: > Hi Alex, > > (Cc=E2=80=99ing and , > which are related.) > > Alex Sassmannshausen skribis: > >> I don't know if this is what Konrad desires, but from my perspective, a >> desirable part of the definition of stable would be a that the build >> farms have produced a set of binaries/substitutes for a given Guix >> revision that is "good enough". > > I just had a bright idea (yes!): this can be addressed by writing > something like this in ~/.config/guix/channels.scm: > > (map latest-commit-with-substitutes-available > %default-channels) > > The hypothetical =E2=80=98latest-commit-with-substitutes-available=E2=80= =99 would use > (git) and (guix ci) to find the latest commit for which substitutes of > interest are available, and would return: > > (channel > ;; =E2=80=A6 > (commit "cabbag3")) ;the ideal commit This sounds incredibly interesting =E2=80=94 and it is testament once again= to the power of Guix that this kind of solution could be feasible! Thinking this through in my head somewhat, I had the following thoughts: - This procedure is invoked client side, where the channel is defined - That means the git searching is done client side, on every invocation of guix (I guess this might be cacheable?) - So the downside vis-a-vis a maintained "stable branch" would be a price in performance as experienced by the end user - The upside of course would be automatic curation of a stable branch that saves a ton of volunteer effort and work I have no idea what the performance cost would be. I guess you would use "guix weather" to turn the set of requested packages into a manifest which can then be checked with it. So the cost would be one of the following scenarios: Option a) - fetch set of packages in a given commit - query guix weather for 100% substitutes - iterate until a match - then perform the appropriate guix pull Option b) - perform a guix pull to the latest commit - query guix weather for 100% substitutes - until success, step back one step at a time through guix pull (because of the cost of guix pull this seems unfeasible) Option c) Implement some form of substitute cache set querying on build farms, as part of guix weather, so the 100% match is done on the build farm instead of the client. Dunno. There may be some things that already exist in Guix land that I'm missing. It's a super exciting approach for sure. > This has to be done with great care to prevent a downgrade attack and to > make sure the user doesn=E2=80=99t miss out on security updates, but mayb= e we > could provide a procedure that makes reasonable choices. Right =E2=80=94 so at the very least it would have to prevent us going "bac= k in time" from the guix pull commit we are currently at. The question of security updates is tricky at the moment already =E2=80=94 I would hazard a guess that many people bail out of upgrading when they can't get substitutes for their entire profile / system right now, which means they are not getting security upgrades for package (a) when a substitute for (b) fails. Thanks for your thoughts =E2=80=94 super intriguing! Alex