From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: successful installation, but problems updating Date: Fri, 10 Nov 2017 15:30:22 -0800 Message-ID: <8760ahpv8x.fsf@gmail.com> References: <20171106091656.6e775deb@graviton.instanton> <20171106111829.1e07b138@hitpoints.browniehive.net> <87fu9mptdl.fsf@gmail.com> <20171110162818.GA11031@jasmine.lan> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60646) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDIkp-00020I-8o for help-guix@gnu.org; Fri, 10 Nov 2017 18:30:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eDIkm-0003zj-4y for help-guix@gnu.org; Fri, 10 Nov 2017 18:30:31 -0500 Received: from mail-pg0-x22c.google.com ([2607:f8b0:400e:c05::22c]:48545) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eDIkl-0003zO-Uo for help-guix@gnu.org; Fri, 10 Nov 2017 18:30:28 -0500 Received: by mail-pg0-x22c.google.com with SMTP id s11so3023799pgc.5 for ; Fri, 10 Nov 2017 15:30:27 -0800 (PST) In-Reply-To: <20171110162818.GA11031@jasmine.lan> (Leo Famulari's message of "Fri, 10 Nov 2017 11:28:18 -0500") 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: Leo Famulari Cc: "help-guix@gnu.org" --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Leo, Leo Famulari writes: > Substition is considered to fail when Guix is expecting a substitute but > the server returns 404, 504, or some other unexpected problem occurs. It > is not considered to fail if the server initially reports that no > substitute is available. Thank you for the clarification. This is what I did not understand. I read the manual and got the impression that when --fallback has not been given, if a given substitute cannot be found (regardless of whether or not a substitute server claimed to provide one), then Guix will not build it. I see now that my understanding was mistaken. I've attached a patch which tries to clarify this in the manual. What do you think of it? =2D-=20 Chris --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-doc-Clarify-the-fallback-option.patch Content-Transfer-Encoding: quoted-printable From=20ce8c53bffa2f79f680f9b27bcb494a4fadb4038c Mon Sep 17 00:00:00 2001 From: Chris Marusich Date: Fri, 10 Nov 2017 15:19:16 -0800 Subject: [PATCH] doc: Clarify the --fallback option. * doc/guix.texi (Common Build Options): Describe --fallback in more detail. In particular, call out the fact that local builds can still happen even when --fallback is omitted. =2D-- doc/guix.texi | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/doc/guix.texi b/doc/guix.texi index b7f4f88f9..40705c4b8 100644 =2D-- a/doc/guix.texi +++ b/doc/guix.texi @@ -5159,7 +5159,13 @@ Do not build the derivations. =20 @item --fallback When substituting a pre-built binary fails, fall back to building =2Dpackages locally. +locally. This affects behavior only when substitutes are enabled and +Guix is building a derivation for which a substitute is known. When +@code{--fallback} is omitted, the build will fail if substitution fails. +However, when @code{--fallback} is given, Guix will try to build the +derivation locally if substitution fails. When substitutes are not +enabled or Guix is building a derivation for which a substitute is not +known, a local build will always be performed. =20 @item --substitute-urls=3D@var{urls} @anchor{client-substitute-urls} =2D-=20 2.14.2 --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAloGNo4ACgkQ3UCaFdgi Rp1aZhAAupC07V/8YOzlYLu9upslA01OURBGrX8bTCbVA6XejTwMpjWAyDvt6gsn pEmvjCnEs3/BhObHP1mIl3icyPZuX5mVYkwY61emBGvO+Ir8Jtl0c3AMZsbxiRLG aMab7mHyl0VOmBtqMFnpy94u3MumnA5nQBRx6zsm+bgMVohheMm9zfbsWNm1CRJK g5cqBR5/Q06OZJM7Ay0Bei0M9wAhtQeTQ6+52aDAZxWZl9W9Gj97VJ76Otg5HlR+ +mYxuCVR3pP/HQ7kbcfV6RQ5JFgis7QU0nnFDBtdjilhffi10VMFnfG1T4ccDaqD 2cQyHvuHdkMk6IhiYM9PsX5trj4aU4/srcoZVD3rUNlmllj35kDdrox3KlLtIybu uS8Z4HqsevgWMAvuasbInEz1xIeESPorMiiycKqGxEBoSbR9LNV7j2PdDvMuPJz2 ZsRcctki9KoABfobIDq4nqkahWhPHbbPOAjXNPDi3oxmFmAUXDLK/Ka6Q3+Rtkyp 2lVWw9zy/N/eVs6OT2O7w75VS2BCMETKZF1Utm5LolZ7ZKtjoknSu1GfzkSt+5g+ nfCjRFgIYg71Vsg18hZ76H9uN9oAsXOz2/7JcNy88psq+h+dlA0YGveYmT4ugblC qUIObZG2lFts//38UbjXxMe1O+yxDmLIXOXWPzC3xeipwM1BKxk= =iMDj -----END PGP SIGNATURE----- --==-=-=--