From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Sassmannshausen Subject: bug#26608: bug#22629: =?UTF-8?Q?=E2=80=9CStable=E2=80=9D?= branch Date: Tue, 04 Sep 2018 10:02:31 +0200 Message-ID: <87pnxtu1uw.fsf@pompo.co> 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> <87r2iau0wz.fsf@pompo.co> <87zhwywe8v.fsf@gnu.org> Reply-To: alex@pompo.co Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fx6Ij-0007uZ-KT for bug-guix@gnu.org; Tue, 04 Sep 2018 04:03:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fx6Ig-000790-KC for bug-guix@gnu.org; Tue, 04 Sep 2018 04:03:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:39975) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fx6Ig-00078w-G8 for bug-guix@gnu.org; Tue, 04 Sep 2018 04:03:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fx6Ig-0007ap-9a for bug-guix@gnu.org; Tue, 04 Sep 2018 04:03:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <87zhwywe8v.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 26608@debbugs.gnu.org, 22629@debbugs.gnu.org, 32022@debbugs.gnu.org Ludovic Court=C3=A8s writes: > Hi Alex, > > Alex Sassmannshausen skribis: > >> Ludovic Court=C3=A8s writes: > > [...] > >>> 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 ag= ain to >> the power of Guix that this kind of solution could be feasible! > > Just to be clear: I don=E2=80=99t think this would be a substitute for a > =E2=80=9Cstable=E2=80=9D branch; rather, I view as a way to have user-def= ined policies > such as =E2=80=9Cpull up to the latest commit for which there=E2=80=99s a= substitute for > IceCat.=E2=80=9D Ah, I understand now. So the example you provided is a user-defined policy to install the latest version of Guix that is downloadable using substitutes (if guix publish has published those already). As you say, in a similar vein, the end user could for themselves define a policy that searches for a commit containing a specific successful build, or a set of specific successful builds. >> 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?) > > On every invocation of =E2=80=98guix pull=E2=80=99 only. That makes sense, and is way better than I feared :-) >> 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. > > As I imagine it, the cost would be a few HTTP queries to the Cuirass > API. I should try to come up with an example to better explain what I > had in mind! Your example helps visualize this, thanks. Your example depends on there being a jobset that comprises the set of packages you are interested in testing. I imagine it is possible to do the same for an individual package / job. The situation would be different if the end user wanted to perform a similar operation for an arbitrary set of packages on their end. It would probably involve something like this (probably naive): (define (latest-commit-successfully-built-pkg pkg) "Return the latest commit for the pkg for which substitutes are (potentially) available." ;; Like your version, but magically performs query ;; for pkg, not the guix-modular-master evaluation (let* ((evaluations (latest-evaluations pkg)) (candidates (filter-map (lambda (json) (match (hash-ref json "checkouts") ((checkout) (cons (hash-ref json "id") (hash-ref checkout "commit"))) (_ #f))) evaluations))) (map (match-lambda ((evaluation . commit) (and (evaluation-complete? evaluation) commit))) candidates))) (any (match-lambda ((evaluation . commit) commit) (apply lset-intersection equal? ;; Like latest-commit-successfully-built, but takes an ;; individual package name for which we return the ;; commit (map latest-commit-successfully-built-pkg %set-of-packages)))) Obviously the larger the set, the more requests are required, and the lower the chance of a commit being available / a downgrade occuring >> 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. > > That=E2=80=99s probably true, and I agree it=E2=80=99s problematic. > > What I typically do is =E2=80=9Cguix pull && guix package -n -u=E2=80=9D.= Then I look > at things that would be built; if, say, LibreOffice is among them, I > wait for a little while and try again later, until I can get enough > substitutes. That usually works okay, but it fails if it turns out that > one of the dependencies fails to build: substitutes never become > available in that case. Interesting. Do you think this kind of thing might be useful to have in the Guix manual? Like, in a section about a "typical" desktop end-user might manage their system day to day? Alex