From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: Re: successful installation, but problems updating Date: Sat, 11 Nov 2017 23:45:20 -0500 Message-ID: <20171112044520.GA29037@jasmine.lan> References: <20171106091656.6e775deb@graviton.instanton> <20171106111829.1e07b138@hitpoints.browniehive.net> <87fu9mptdl.fsf@gmail.com> <20171110162818.GA11031@jasmine.lan> <8760ahpv8x.fsf@gmail.com> <86bmk8rfz9.fsf@gmail.com> <20171112012904.GC13886@jasmine.lan> <86o9o8p3r9.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57393) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDk9c-00065H-MU for help-guix@gnu.org; Sat, 11 Nov 2017 23:45:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eDk9Z-0007BQ-Ic for help-guix@gnu.org; Sat, 11 Nov 2017 23:45:56 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:56507) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eDk9Z-0007B9-DK for help-guix@gnu.org; Sat, 11 Nov 2017 23:45:53 -0500 Content-Disposition: inline In-Reply-To: <86o9o8p3r9.fsf@gmail.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: myglc2 Cc: "help-guix@gnu.org" --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 11, 2017 at 10:36:26PM -0500, myglc2 wrote: > Yes, but ... the average bear using GuixSD, having internalized Guix' > assurances that substitutes are reliably the same as what they could > build-from-source locally, naturally assumes that substitutes will be > used. >=20 > Unfortunately the current "hot rolling" of updates into origin/master > means that hydra has no way to get reliably "100% ahead" of users who > update frequently. Further hydra does not keep a "deep set" of previous > builds, so a user may well find themselves building old stuff. This > treats our users to a baffling, herky-jerky experience, with local > builds seeming to occur at random.=20 >=20 > With improvements to the way changes are rolled in and to hydra, et al., > the "substitution fraction" that users experiences should increase, but > will most likely never reach 100% and will remain variable. So a user > coming from something like debian encounters a different user experience > that may well be disconcerting. This makes it important to find a way of > explaining substitutes, what is happening, and what to expect, so that > our users will feel be confident that everything is OK. >=20 > Personally I prefer herky-jerky + "total source artistic control" + > reliable roll-back to speedy binary-only update + unknown provenance + > no roll back. In other words, "I drank the kool aid". I also have a > couple speedy servers so the GuixSD builds don't interrupt my work flow. >=20 > But I feel for the noobs on IRC whose machines have been kidnapped by > GuixSD for huge, unpredictable, chunks of time. All good points! Maintaining the build farm is one of really hard parts of developing Guix, from what I've seen. I'm hopeful that we will improve it in the next year. > >> +When substitutes are enabled (the default) and a substitute is not > >> +available the build will take place locally. If a substitute is > >> +available but substitution fails, e.g., the substitute server returns > >> +404, 504, times out, or some other unexpected problem occurs, guix st= ops > >> +and reports an error unless --fallback or --keep-going options are > >> +specified. > > > > To clarify, the default status of substitutes is different for Guix > > (default disabled) and GuixSD (default enabled). >=20 > Oh, WOW! Does the doc say that? Yes, the installation instructions for Guix mention authorizing the substitute signing key in step 7 [0]. So, I think it's clear that they are not enabled otherwise. > And, why is it different? I don't know if there is a design choice here, but the steps required to authorize substitutes for Guix on another distro require root. So, we can't make it "just work" without the user elevating their privileges. It's not the only part of our installation guide that requires root, however. On GuixSD, we can control the entire system during installation, so we enable substitutes by default. [0] https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html= #Binary-Installation --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAloH0d0ACgkQJkb6MLrK fwjy6Q/+OhoAToGyE1UHkLLxDyplrc5rLoScMnsQfzPmXwi2S2idrYB58V2lUemq ri/4pgnSAp8a4vg9IgpKv+tkyzl+MWEtEqttUISrHGQR9HX7p/UF7rcLfvMjSrBp LaHuQClcho6KG7ttRD9BnLSApmDwBgI4Zj9uKThzJk7kSFmXwdpG1D6qcitNink3 fwdTHY2Famfk2fQ/2MuvVoxDZrOUmem2C70kjjGXmtvO0BtL3UoHkXKXZgLi6iak +em0NnywEd+JuhlUqU+cVGjWMJzSV8yo7TJNf1oC9u/eAwb1flWFPbXQCrDzNH6O QC5PDRHpb/A+ex6FEYw8pvH8BDe/LDhNFuSV4nMVvI9ta2R6oj9FTyrR4VKVbM7p bJCe7anxwVVcRHDM2OIRG0hQ65XXF4/epRbcHF2tyZElkb4Be79HUyH1h6rp2Kdd OX9LYIWQ5zPXXrdE3elXrL/k//E/gkHAINyhByUbzoBOKMMfwWK5rM5Q0CBzBXjI 3z/2rLZbcJEzI2JXjwEpzJ3YQeZ1fYHJCdVC6D3adjQvEN12kH9Enwbn0BC8352x KlmITsJXPnB6vb7sme0g0j8SjzF6iKxs50x2UlfaoTfrcekAMmgSj4SK6sNKipwT abSnUFO+MlJcets/db6gSfeK6VhupA+igVOtRhc/a6bs1PwM5tA= =Mip9 -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH--