GNU bug report logs - #72686
Impossible to remove all offload machines

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: guix; Reported by: Ian Eure <ian@HIDDEN>; dated Sat, 17 Aug 2024 16:46:02 UTC; Maintainer for guix is bug-guix@HIDDEN.

Message received at 72686 <at> debbugs.gnu.org:


Received: (at 72686) by debbugs.gnu.org; 2 Jan 2025 15:02:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 02 10:02:29 2025
Received: from localhost ([127.0.0.1]:46064 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tTMiS-0005ZX-Pr
	for submit <at> debbugs.gnu.org; Thu, 02 Jan 2025 10:02:29 -0500
Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]:48456)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <maxim.cournoyer@HIDDEN>)
 id 1tTMiQ-0005ZJ-SK
 for 72686 <at> debbugs.gnu.org; Thu, 02 Jan 2025 10:02:27 -0500
Received: by mail-pl1-x629.google.com with SMTP id
 d9443c01a7336-21a1e6fd923so112758155ad.1
 for <72686 <at> debbugs.gnu.org>; Thu, 02 Jan 2025 07:02:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1735830140; x=1736434940; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=CNQjrJkzX1FuBu3p5939S8w4U/LL+jZIjjl3judO9/w=;
 b=fhA9h8Qaw7yQhPQoNfRFDdrJEVkOfee04I1WVEkuhQcOWD2Mavi5XXd5KFNKOUTa+F
 f9C2JWSh22eUUSo/n7f8cc4C1GJO7gkEE78EnBKbzGfeZAfdYH4ZFzF4huMyaKGdQSvZ
 cQut9571TBiupxVgO1wcGDAiwjOf2zwc5mOehfmWxdTRsm+J0g6D8ZQno8sd9qrCfwHW
 jd3HlcIGVEVL2tW9CG0DAEjWu4oruIGFq6MlgtfTfzvTbshEJa8+fMF8AZFX8dD5Z+55
 C9A60M7XrvCgCkJ3cLB+BjiGKSEnJ3YplY182cs8ONIL+A9yLHYacxUaXpk0TIwDvN6c
 s1GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1735830140; x=1736434940;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=CNQjrJkzX1FuBu3p5939S8w4U/LL+jZIjjl3judO9/w=;
 b=jueWpTi+XRU+H4GMHaGKP+YaiPV1A6IcZyoM6BO+4PhQDMRnmwgM9j4S275FV0P1NR
 UVxGZbiwyMnPDUwGBiC38r98i3rr6IaTvSl3Ic24xuoYYI6CyQgFb5hvk1Jkan9TEbHP
 UUtg0EjrTLRHCi1nYPX15jKtFGkcB4wp8veBmn0AeX/MK2cn0ulkpI8gvOCcFQWJS12S
 Y+UXjwthNzxxpyVN1gHNq65tUBoALQuQCCXL0Zd1LVAZgDAotJA3v+QBR94KMHRecqh7
 NdFw/JaFBjryiZZBP27Un9M9mqbKK4QQtYcojziupau4HYOooeLRxd2QRLi3ITxjlT7e
 gHHA==
X-Forwarded-Encrypted: i=1;
 AJvYcCUbKBTtQ6fYMvQRoIsGrsNozhEOC1Dg7uw1TXrdVkCORyNoCPBO5G6qJj1G8Z9tztSLRLLDng==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyN2WEyi3Aj6W+YZ7oM98UO1BSwDdo/otwaqTxLNosO4sm1BC42
 JLO/57bz0rEjqt/nvOXhFoz52v0pB/TEXzpd1QKOgJbk0xmh+X39+r5mZukf
X-Gm-Gg: ASbGnctEiFxFZ8y/o+Cyche0aGY/1f11EnR/mWf8srdUQ2aVHVYUu/XdHzgBZEF7UJf
 sWX7N46nKgM2bswbBNAZcRMyNAw+AEtlfnprvsSu7O3vG5qgJU4KzlT1rojGEmkq+XvTai53JYj
 W8WgO2lP0MpMnJPS/tVWFFqiD2GQDvlQ0VBiQTy7LG0a/UcNBqqBS18uPyE8t6pwZWvWPNa/3YD
 MBXShkz4oo6n9h1fWxSpA55dOsbtPCKb25m0nUHOtQQGxb3DGWW0A==
X-Google-Smtp-Source: AGHT+IHUe2+DNgGP2wPqeDm/7v7017cKSlOwqaDaaDx8uVucGSG8qz/JPBMvEbo2d2o8Fvx64dMxZg==
X-Received: by 2002:a05:6a21:339e:b0:1e1:c1a7:67ef with SMTP id
 adf61e73a8af0-1e5e07ef6b2mr74687361637.30.1735830140100; 
 Thu, 02 Jan 2025 07:02:20 -0800 (PST)
Received: from terra ([2405:6586:be0:0:c8ff:1707:9b9:af89])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-72aad83616asm24472616b3a.76.2025.01.02.07.02.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 02 Jan 2025 07:02:19 -0800 (PST)
From: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
To: Ian Eure <ian@HIDDEN>
Subject: Re: bug#72686: Impossible to remove all offload machines
In-Reply-To: <87ldwzmdfi.fsf@HIDDEN> (Ian Eure's message of "Sun, 01 Dec
 2024 11:05:37 -0800")
References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@HIDDEN>
 <87plp560ji.fsf@meson> <87setsmnj2.fsf@HIDDEN>
 <87ldwzmdfi.fsf@HIDDEN>
Date: Fri, 03 Jan 2025 00:02:09 +0900
Message-ID: <87wmfd45u6.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 72686
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Ian,

Ian Eure <ian@HIDDEN> writes:

[...]

> Apologies for the silence, life stuff has been eating most of my free
> time, but I have a bit of bandwidth to spend on this problem again.

As you can see, you are not alone :-).

> I took a swing at this, it wasn=E2=80=99t as difficult as I expected. Whi=
le
> this approach gives a smooth upgrade path for those who=E2=80=99ve config=
ured
> channels in a stateful way switching to declarative configuration,
> it=E2=80=99s possibly bumpy for those already using a declarative config.=
  If
> a machine with declarative channels is reconfigured, the channels will
> be duplicated from /etc/guix/channels.scm to
> /etc/guix/channels-declarative.scm. Using `delete-duplicates' on the
> merged channels should avoid major problems, but I think it still
> needs a loud entry in news and manual action (deleting
> /etc/guix/channels.scm) to upgrade. Given that both approaches will
> require manual action, I=E2=80=99m a bit inclined to go with the simpler,=
 and
> take over the existing file. That said, I think the failure mode of
> the simpler approach (stomping on channels a user may have configured)
> is undeniably worse than potentially duplicating channels or
> continuing to pull in old ones unexpectedly.  Do either of you have a
> strong opinion or more information which would help guide this
> decision?

I still like the option to leave a handcrafted channels.scm alone; I
don't think this imperative variant will be obsolete in the future; it's
still useful to experiment quickly, avoiding costly reconfigure just to
change some bits about a new offload machine.

> The root issue at work behind all these problems is that activation
> code only sees the desired target config, rather than the current and
> target configs.  Comparing the current and target configs would allow
> the code to more precisely compute the needd change to move from one
> state to the next.  I think that could be a good change to make,
> though it=E2=80=99s obviously going to be much more involved, and IMO will
> require discussion outside the scope of this specific bug.

The activation is just a script, so if it's useful to check
the current value, it should be OK to do so.

> I have a draft patch series I hope to send up soon, but need to get
> Guix System up in a VM to test first.  It does separate declarative
> channels into their own config, but doesn=E2=80=99t do the same for build
> machines.  While I think many fewer users configure build machines
> than channels, it=E2=80=99s probably a good idea to use the same approach=
 for
> both channels and machines.

Yes, it'd be nice to have a uniform approach.  The acl file could
benefit from the same treatment, I believe (that, and 'guix authorize'
should validate that we're not adding the same key multiple times --
warn something along "key XXXX is already authorized".

--=20
Thanks,
Maxim




Information forwarded to bug-guix@HIDDEN:
bug#72686; Package guix. Full text available.

Message received at 72686 <at> debbugs.gnu.org:


Received: (at 72686) by debbugs.gnu.org; 1 Dec 2024 19:05:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 01 14:05:49 2024
Received: from localhost ([127.0.0.1]:53092 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tHpGP-0002bM-6h
	for submit <at> debbugs.gnu.org; Sun, 01 Dec 2024 14:05:49 -0500
Received: from fhigh-a8-smtp.messagingengine.com ([103.168.172.159]:37371)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ian@HIDDEN>) id 1tHpGM-0002b3-Ex
 for 72686 <at> debbugs.gnu.org; Sun, 01 Dec 2024 14:05:47 -0500
Received: from phl-compute-02.internal (phl-compute-02.phl.internal
 [10.202.2.42])
 by mailfhigh.phl.internal (Postfix) with ESMTP id D4E3D11400BE;
 Sun,  1 Dec 2024 14:05:40 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-02.internal (MEProxy); Sun, 01 Dec 2024 14:05:40 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h=
 cc:cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to; s=fm3; t=1733079940;
 x=1733166340; bh=oQK/Zd7YVv2wFjXmRDDo6rYnWy/f47rdttwig6JaCx8=; b=
 GtHhojuqbjDe/XyC0MrBpsSIcV4ersYXIjDV0/qOomuzubYr0ilI8Oya7NqHKabP
 4NMwuOCdPxqQ2j6saCoA4R3OjRXj+lEZ0blffi+9NJJM7gKtVKkZCCYkfrhlEpS1
 7dsP7IOpAbB+jeWP5xRFxz9CdCqVAU8O/kUVt6TgLd1iqgG0IC26OavzHIOl1cts
 UzYVd+bI/VGdhXUdSR81gWLlX2bjV3TI3EuAresZa2qo6OG031H/nnoYuXTzDxHr
 t9o05CWcoqBcCFwdenstH0uKfCNYBh0/flfHHxe8Mjdg0CUU3s9A3pK0Y9D/BuVB
 xz5JLvtcQoYHEN5pZuTJfQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1733079940; x=
 1733166340; bh=oQK/Zd7YVv2wFjXmRDDo6rYnWy/f47rdttwig6JaCx8=; b=b
 7GmTiWtbNFc/XA7XmtJVdxJo6O2Vxx3a/tNj+1DKeXZZvhLOaZccFnP3RXFXy+XB
 BTvSkGqcoPepJxDUfNzAXepir546a6uz3aM54D6jR3UVBHZ5fkbCEBtqoiL7PDBE
 jZNBzdhxguqJnh3d+gzSmPaZEaybtTbfEXg7L+wvH/RY88jRR3RGhkRomljqw3ts
 FyHk3+c+U2tAOWxLpD4wTecggEo5yPcgWrZWAldq8GShkFTygNLBtnZUE9VfEW9X
 aWnkjy0y5mrGhbDo1pHMne37mHAcceK6kSGG8bH3k9fWU9wm2YNHl00xJxqlOv7A
 /v16tsSD1y3DinDtOXLbg==
X-ME-Sender: <xms:hLNMZ6wpTdvscVPpHolsrHc6HLQzKtKSX-JCxW7rOsyeztm_zq212Q>
 <xme:hLNMZ2Ri0Y3srB4DnExpF-N_mNiDizvBV90heHDJm3lN6tITV0aVCa2nzeRRDPWdF
 uadiLK_ZovaZFwTBw>
X-ME-Received: <xmr:hLNMZ8UUHeQY8PFxEJ4k4vo8a-yzZpiiNRv67H8HMYsgHO4zegw-Yid8ydgG7itnMx32AEXluhzeBnxXSvsZ2Z082gZk2u-DoQoCwzU>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrheejgdduudekucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurhephffvvefujghffgffkfggtgfgsehtqhertddtreej
 necuhfhrohhmpefkrghnucfguhhrvgcuoehirghnsehrvghtrhhoshhpvggtrdhtvheqne
 cuggftrfgrthhtvghrnhepveeuleeugedujeeukefhhffhlefgjeehfeffhefgffelkeev
 keeutdegkeelgeffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh
 hfrhhomhepihgrnhesrhgvthhrohhsphgvtgdrthhvpdhnsggprhgtphhtthhopeefpdhm
 ohguvgepshhmthhpohhuthdprhgtphhtthhopehguhhigidquggvvhgvlhesghhnuhdroh
 hrghdprhgtphhtthhopeejvdeikeeiseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp
 thhtohepmhgrgihimhdrtghouhhrnhhohigvrhesghhmrghilhdrtghomh
X-ME-Proxy: <xmx:hLNMZwhCioEue_SkFzjUJpEFxYCKArP_Hgc2dVwuuXnUeC8dXiC0_g>
 <xmx:hLNMZ8AR1WpNiIAiFCxW06jiDSLJnJ86rrUCeFRqtJXcPM3Zvvvhkw>
 <xmx:hLNMZxKrkUg3q9zf1Z8tahgh9q1Fp_tawvg2QVd9uhN5VlboBCR0MA>
 <xmx:hLNMZzCU7YhNcHwU_Ar2-87HvuBgRQuT_8_f1swhszsbHLLvCn4uPA>
 <xmx:hLNMZ_OgSaFuU9j9OeCnK0qjOj3DguooB-HkzYiNuyejJ_lTsVdc1-74>
Feedback-ID: id9014242:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 1 Dec 2024 14:05:39 -0500 (EST)
From: Ian Eure <ian@HIDDEN>
To: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Subject: Re: bug#72686: Impossible to remove all offload machines
In-Reply-To: <87setsmnj2.fsf@HIDDEN> (Maxim Cournoyer's message of "Sun, 22
 Sep 2024 11:26:41 +0900")
References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@HIDDEN>
 <87plp560ji.fsf@meson> <87setsmnj2.fsf@HIDDEN>
User-Agent: mu4e 1.12.7; emacs 29.4
Date: Sun, 01 Dec 2024 11:05:37 -0800
Message-ID: <87ldwzmdfi.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 72686
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@HIDDEN> writes:

> Hi Ian,
>
> Ian Eure <ian@HIDDEN> writes:
>
> [...]
>
>> The only other option I can see would be to keep the existing
>> filenames for user configuration, and declaritively manage=20
>> different
>> files -- like declaritive-channels.scm.  This comes with its=20
>> own set
>> of problems, like needing to update the Guix daemon to read and
>> combine multiple files; and the inability to know whether a=20
>> given
>> `channels.scm' is declaritively- or manually-managed means a=20
>> bumpy
>> upgrade path (ex. should this preexisting channels.scm file be=20
>> left
>> as-is, or renamed to the new name?)
>
> I'd think that be a great option to pursue, although it's more=20
> work more
> thoughts.  Perhaps it could work along these lines=20
> (brainstorming)
>
> I like the idea to leave the original, potentially manually=20
> written file
> in place and complement it with a declarative counterpart.  The=20
> same
> would also have benefited /etc/guix/acl, which suffers from the=20
> same
> ambiguity.
>

Apologies for the silence, life stuff has been eating most of my=20
free time, but I have a bit of bandwidth to spend on this problem=20
again.

I took a swing at this, it wasn=E2=80=99t as difficult as I expected.=20
While this approach gives a smooth upgrade path for those who=E2=80=99ve=20
configured channels in a stateful way switching to declarative=20
configuration, it=E2=80=99s possibly bumpy for those already using a=20
declarative config.  If a machine with declarative channels is=20
reconfigured, the channels will be duplicated from=20
/etc/guix/channels.scm to /etc/guix/channels-declarative.scm.=20
Using `delete-duplicates' on the merged channels should avoid=20
major problems, but I think it still needs a loud entry in news=20
and manual action (deleting /etc/guix/channels.scm) to upgrade.=20
Given that both approaches will require manual action, I=E2=80=99m a bit=20
inclined to go with the simpler, and take over the existing file.=20
That said, I think the failure mode of the simpler approach=20
(stomping on channels a user may have configured) is undeniably=20
worse than potentially duplicating channels or continuing to pull=20
in old ones unexpectedly.  Do either of you have a strong opinion=20
or more information which would help guide this decision?

The root issue at work behind all these problems is that=20
activation code only sees the desired target config, rather than=20
the current and target configs.  Comparing the current and target=20
configs would allow the code to more precisely compute the needd=20
change to move from one state to the next.  I think that could be=20
a good change to make, though it=E2=80=99s obviously going to be much more=
=20
involved, and IMO will require discussion outside the scope of=20
this specific bug.

I have a draft patch series I hope to send up soon, but need to=20
get Guix System up in a VM to test first.  It does separate=20
declarative channels into their own config, but doesn=E2=80=99t do the=20
same for build machines.  While I think many fewer users configure=20
build machines than channels, it=E2=80=99s probably a good idea to use the=
=20
same approach for both channels and machines.

  =E2=80=94 Ian




Information forwarded to bug-guix@HIDDEN:
bug#72686; Package guix. Full text available.

Message received at 72686 <at> debbugs.gnu.org:


Received: (at 72686) by debbugs.gnu.org; 22 Sep 2024 02:28:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 21 22:28:15 2024
Received: from localhost ([127.0.0.1]:40523 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ssCKc-0008Ka-R5
	for submit <at> debbugs.gnu.org; Sat, 21 Sep 2024 22:28:15 -0400
Received: from mail-pg1-f171.google.com ([209.85.215.171]:44204)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maxim.cournoyer@HIDDEN>) id 1ssCKZ-0008KH-Bo
 for 72686 <at> debbugs.gnu.org; Sat, 21 Sep 2024 22:28:12 -0400
Received: by mail-pg1-f171.google.com with SMTP id
 41be03b00d2f7-7cd8803fe0aso2240805a12.0
 for <72686 <at> debbugs.gnu.org>; Sat, 21 Sep 2024 19:27:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1726972004; x=1727576804; darn=debbugs.gnu.org;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=N9SI7Pg3yuBMQZltor4SApxphSNkR+P3T3paxX3Njko=;
 b=TAkRQnIlvvdz4DL/Wv1lo8vS+tas6kVM0+ir5Rc4C9Bi1p8uPkiql63+wK4lFB8KgD
 Wt29n6bJSX+PBo3+h6VqaCcCxBgXTyFHTEzFnogglkYfuOvi3bQK2LelrKToG8AR1Q+U
 j2aN/csew55JMjVdvg3q8QqkyzBz8bpfoRE96pTInOjjwdoyku/5JAyeVEDTCKPf3oEH
 EX2cOg6DgRd0LNMZD/x1C3B2Xa7/N82UQheHruw2YEWeU/UEtpVenIwmOqt3qxjBpsap
 5PVvL4QR0fZIlx+US/gnFxMQcqnbe3pKioEQiV+Vk0/nScM9rSjVNfKdQQJPb/TbDSht
 M6Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1726972004; x=1727576804;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=N9SI7Pg3yuBMQZltor4SApxphSNkR+P3T3paxX3Njko=;
 b=tnJmgCz0iT0vCWYzb19zfGN3QuYUS7sDw9uutKH0vQn9qSHx5fkml5sv//aD1cxjJm
 rLfvPQncMA+VT2ahqO/S4vXSEgvoSyD/imhOw1NIzaV1QCYKste9blF+AU+NYvYddKFX
 IdgfSI1iEzdRD3jN5VaG6HLT81Gda3QDzLms/9r9IbVupCH5p+jCMsVuV7cinir8y5x7
 exAFt9bkC7bWgUEX3pCmKfxdtcEFn1n9EuG4wTLafxU1Znxp25pCFgIww77pFBZFXn0w
 ZTfxLDzBNFdLrub3mc8zaYyZ4Uxl0avGTrm0BFFXVJCZtl2K0nVfgHU8Q9++tREsta1B
 nsig==
X-Gm-Message-State: AOJu0YxOr3Jt3WFmis5lmC2OrHUB1sbBVnr5b//WMJGGu4ShgY97sqt3
 /FeRxxiRuXT96Bzn8tq8c2+VAqrmORCz0boJQBLQeEFMsCNkMTgz
X-Google-Smtp-Source: AGHT+IHa/UCwsnxGYYmcN4T5A+bztsBs6rDqv2YAEMAEuinCPrmUH3mO/nFVyKXi6MyHAWFYnqFjAg==
X-Received: by 2002:a05:6a20:b598:b0:1d2:eb9d:997d with SMTP id
 adf61e73a8af0-1d30a8ecd52mr9806089637.7.1726972004253; 
 Sat, 21 Sep 2024 19:26:44 -0700 (PDT)
Received: from hurd ([2405:6586:be0:0:c8ff:1707:9b9:af89])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-7e69dfadd9esm139012a12.12.2024.09.21.19.26.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 21 Sep 2024 19:26:43 -0700 (PDT)
From: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
To: Ian Eure <ian@HIDDEN>
Subject: Re: bug#72686: Impossible to remove all offload machines
In-Reply-To: <87plp560ji.fsf@meson> (Ian Eure's message of "Sat, 14 Sep 2024
 20:24:38 -0700")
References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@HIDDEN>
 <87plp560ji.fsf@meson>
Date: Sun, 22 Sep 2024 11:26:41 +0900
Message-ID: <87setsmnj2.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 72686
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Ian,

Ian Eure <ian@HIDDEN> writes:

[...]

> The only other option I can see would be to keep the existing
> filenames for user configuration, and declaritively manage different
> files -- like declaritive-channels.scm.  This comes with its own set
> of problems, like needing to update the Guix daemon to read and
> combine multiple files; and the inability to know whether a given
> `channels.scm' is declaritively- or manually-managed means a bumpy
> upgrade path (ex. should this preexisting channels.scm file be left
> as-is, or renamed to the new name?)

I'd think that be a great option to pursue, although it's more work more
thoughts.  Perhaps it could work along these lines (brainstorming)

I like the idea to leave the original, potentially manually written file
in place and complement it with a declarative counterpart.  The same
would also have benefited /etc/guix/acl, which suffers from the same
ambiguity.

-- 
Thanks,
Maxim




Information forwarded to bug-guix@HIDDEN:
bug#72686; Package guix. Full text available.

Message received at 72686 <at> debbugs.gnu.org:


Received: (at 72686) by debbugs.gnu.org; 19 Sep 2024 00:36:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 18 20:36:42 2024
Received: from localhost ([127.0.0.1]:59414 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sr5A2-00079Z-Hh
	for submit <at> debbugs.gnu.org; Wed, 18 Sep 2024 20:36:42 -0400
Received: from fhigh7-smtp.messagingengine.com ([103.168.172.158]:57101)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ian@HIDDEN>) id 1sr59z-00079E-3p
 for 72686 <at> debbugs.gnu.org; Wed, 18 Sep 2024 20:36:41 -0400
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 8D40211400E7;
 Wed, 18 Sep 2024 20:36:16 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-11.internal (MEProxy); Wed, 18 Sep 2024 20:36:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h=
 cc:cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to; s=fm3; t=1726706176;
 x=1726792576; bh=uDcwwBBu9Ktphl9tHxzUg+qetd5ryO3lBCvoPSf5V5o=; b=
 UT5ImNIH3zDCveVaLwhK5J2MYSVVgbgIY8nA+GxC5VojYF4Q85AKobv00dpyV2Zm
 vlhuMpnpYrDdgvMChAWLtRJnESpoJ7ANlZOgoL5KcpcE4YpiAnNDtldpuDgp0Z0X
 tTl+BsgIAvbLrYFLk2ruRCHePoI74pHSPhDXw5OahsE3ropNjMGqfYva8aTo2Wpc
 HudrtVF6QRipyVkAag60PLBC4e0GC7rSgGf4XplkL8FXOftSZTdXsuICp4aDJ07o
 jAr6dKsIBjrEMKjINbX828Q1/9bIW5fIuROdPoAhjDUbyrx6tCDFiI9mLJ9Ji3ZD
 S2b5pqyIza1J3URVw/yhNQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1726706176; x=
 1726792576; bh=uDcwwBBu9Ktphl9tHxzUg+qetd5ryO3lBCvoPSf5V5o=; b=n
 J9EWPV/1y7K2CKkMChiaQjdWziJU3HOP0HwNYGptxsqPh4XeUlWg/az1ggfvVwzS
 P1VRJNMvmV3NBPM9dijDpTgbT/3rEGG36U4N3H5O94b+7vfrNIafOlVoaHuplCfd
 JOyk8cCqojjmf8NlaFMrzrSk1Y7ckB8Fe4Y9slCivT1nh1nlONT/SiCFwmP7oru3
 SazsDjG6LlA5B5NO5cp+j5JdF93rAirPBnP2tp3EepZXFCeIs9C1Owg6Ygmf0Co/
 djgHWKhlq7RvDUBC4aK2bB33W8hZ16iEQZGiEf5TG2+Dd6gFQNxHSSxopS3UZzAS
 YjNetWteiw4fClygVJgsA==
X-ME-Sender: <xms:_3HrZnp9MiUEn7-Fk3vpvEdu9gD00-Z-ZKv08G1ZJkkWqeLOJ9-HCg>
 <xme:_3HrZholqfPt0-9fqyIGU3LsG_KgXIuTFNkscAJqMJ__PWUMzuBmI2JpSrGBgRIhl
 Xp-OCFPFrz-YPxF8Q>
X-ME-Received: <xmr:_3HrZkOAsm1GWc0ZO06H5KAG4XK3deEWm3SOAPN_WkX7nfqk0ukK0YOFUgN69AolK-Igm7jJHsRzuownMWAn2qroTUL0DLa5A4g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeltddgfeekucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurhepfhgfhffvvefuffgjkfggtgfgsehtqhertddtreej
 necuhfhrohhmpefkrghnucfguhhrvgcuoehirghnsehrvghtrhhoshhpvggtrdhtvheqne
 cuggftrfgrthhtvghrnhephfelvedtieeffffggeeivdeukedutedtveejfffhleeileef
 heeggfdugfeiuefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh
 hfrhhomhepihgrnhesrhgvthhrohhsphgvtgdrthhvpdhnsggprhgtphhtthhopeegpdhm
 ohguvgepshhmthhpohhuthdprhgtphhtthhopehguhhigidquggvvhgvlhesghhnuhdroh
 hrghdprhgtphhtthhopeejvdeikeeiseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp
 thhtohepmhgrgihimhdrtghouhhrnhhohigvrhesghhmrghilhdrtghomhdprhgtphhtth
 hopeimseifohhlfhhsuggvnhdrtgii
X-ME-Proxy: <xmx:_3HrZq465LCqH4VNIPw9EtsGK1ScJjodK2MHzwUfzDoGbdsenlmrfg>
 <xmx:_3HrZm4UkZZ7HOU1NI3NyTB5FNkPSLGRmLZi1spgmf28cwx1U2FvGA>
 <xmx:_3HrZigjby48bvXDEFsdCziXVm-lCHrZ_D5eSUtTolhFpZsTI7ai1g>
 <xmx:_3HrZo55ZSo83zIFHD8ICIav34JeWQ5IJLi8qbjzZOWvHGbtgsFOnA>
 <xmx:AHLrZh1sC5asGCacvFeq-JtBIFw9YFwGW2UT7f-WnO8IiUXHhw2t2lcf>
Feedback-ID: id9014242:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 18 Sep 2024 20:36:14 -0400 (EDT)
References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@HIDDEN>
 <87plp560ji.fsf@meson> <87ldzt606c.fsf@meson> <875xqwivoa.fsf@HIDDEN>
User-agent: mu4e 1.8.13; emacs 28.2
From: Ian Eure <ian@HIDDEN>
To: Tomas Volf <~@wolfsden.cz>
Subject: Re: bug#72686: Impossible to remove all offload machines
Date: Wed, 18 Sep 2024 17:35:30 -0700
In-reply-to: <875xqwivoa.fsf@HIDDEN>
Message-ID: <874j6c5vk3.fsf@meson>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 72686
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org,
 Maxim Cournoyer <maxim.cournoyer@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)


Tomas Volf <~@wolfsden.cz> writes:

> [[PGP Signed Part:Undecided]]
>
> Hello,
>
> Ian Eure <ian@HIDDEN> writes:
>
>> Disregard this, I continued thinking after sending the email=20
>> (as one does) and
>> realized that any managed file will be a link into the store --=20
>> so if the system
>> is reconfigured with no build-machines or channels *and* the=20
>> corresponding file
>> is a store link, it should be removed; otherwise, it should=20
>> remain untouched. I
>> can work with this.
>
> Will this correctly handle cases where user is managing the file=20
> using
> for example extra-special-file?
>

No, it wouldn=E2=80=99t.


> I wonder whether fat-warning approach would not be better.
>

I think I agree.

  =E2=80=94 Ian




Information forwarded to bug-guix@HIDDEN:
bug#72686; Package guix. Full text available.

Message received at 72686 <at> debbugs.gnu.org:


Received: (at 72686) by debbugs.gnu.org; 15 Sep 2024 19:06:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 15 15:06:33 2024
Received: from localhost ([127.0.0.1]:50517 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1spuZt-0006qw-2x
	for submit <at> debbugs.gnu.org; Sun, 15 Sep 2024 15:06:33 -0400
Received: from wolfsden.cz ([37.205.8.62]:52570)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <~@wolfsden.cz>) id 1spuZo-0006qj-Rn
 for 72686 <at> debbugs.gnu.org; Sun, 15 Sep 2024 15:06:31 -0400
Received: by wolfsden.cz (Postfix, from userid 104)
 id DF3BF3199FC; Sun, 15 Sep 2024 19:06:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail;
 t=1726427174; bh=b1VriMQo7jgvjQv3yjTx12TWDLIp9gFgmi2KB2BvyLY=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=e7ffUgl28HU73x8s7yBzeGLbOxqZ9I1hSRXMicoKc4UkonSiPeZGFYJ4cXkeZdl3V
 p7Z8DdrY/jV2a7FjgS7aY8plOC4Z03x5C3MRSNH2oqbIt6z2LMVQeFtqp2FRXzzmCs
 u0Sx6koL9FTCbBOj17vVymadq2lLWuOSu6I6MfuEapcSZr6/iClZx765aNzHqZH1H3
 HwsBN+e1efSfU5xKiFnctUI05HLICsLGc+00aULSCjo+euVSRWNNijn3RJ84GjJQ9x
 i7zwrPyNHaQ2KrJjvBO9w1s1A9JHFlGD9tYFVJBh+IRwSVQwMbnciXlB3pE0mKttkL
 FnXpjfdeB/QS1z4HCARLj/RhDhQA8LsWW77dNKqECCqteu3wn5AgaKXuLTW+w3gFxq
 LUMhwdnE5YsfvnHkm6UdL6cchSEjLnicpYv8Us9SS3Ro3dCJgWB0mHuGFzDcYJikCh
 nWcmvUTr6pIBW1fk83qfMNAMkkT+2A2phtuLcKxHxAqZ4sLTAKK3fdcrvx+7E6yA5B
 HSdagVS7R8DnLrH5nkuNhKCBaG0x+8MyVgD5IL39UcNqHf2z7ohbGmVTm0OyCEwftz
 vpzPPp8fqddPUFzPFGWcGhiHr6OBgqHM7EbaxoR163VT18NP/hdQlJN08q3c6B21e1
 G8LXWwyX9IJPxD05+uq4P0D4=
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on wolfsden
X-Spam-Level: 
X-Spam-Status: No, score=-3.1 required=5.0 tests=ALL_TRUSTED,BAYES_00,
 DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,URIBL_BLOCKED
 autolearn=ham autolearn_force=no version=3.4.6
Received: from localhost (unknown [128.0.188.242])
 by wolfsden.cz (Postfix) with ESMTPSA id 1D1A7319ED9;
 Sun, 15 Sep 2024 19:06:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail;
 t=1726427174; bh=b1VriMQo7jgvjQv3yjTx12TWDLIp9gFgmi2KB2BvyLY=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=e7ffUgl28HU73x8s7yBzeGLbOxqZ9I1hSRXMicoKc4UkonSiPeZGFYJ4cXkeZdl3V
 p7Z8DdrY/jV2a7FjgS7aY8plOC4Z03x5C3MRSNH2oqbIt6z2LMVQeFtqp2FRXzzmCs
 u0Sx6koL9FTCbBOj17vVymadq2lLWuOSu6I6MfuEapcSZr6/iClZx765aNzHqZH1H3
 HwsBN+e1efSfU5xKiFnctUI05HLICsLGc+00aULSCjo+euVSRWNNijn3RJ84GjJQ9x
 i7zwrPyNHaQ2KrJjvBO9w1s1A9JHFlGD9tYFVJBh+IRwSVQwMbnciXlB3pE0mKttkL
 FnXpjfdeB/QS1z4HCARLj/RhDhQA8LsWW77dNKqECCqteu3wn5AgaKXuLTW+w3gFxq
 LUMhwdnE5YsfvnHkm6UdL6cchSEjLnicpYv8Us9SS3Ro3dCJgWB0mHuGFzDcYJikCh
 nWcmvUTr6pIBW1fk83qfMNAMkkT+2A2phtuLcKxHxAqZ4sLTAKK3fdcrvx+7E6yA5B
 HSdagVS7R8DnLrH5nkuNhKCBaG0x+8MyVgD5IL39UcNqHf2z7ohbGmVTm0OyCEwftz
 vpzPPp8fqddPUFzPFGWcGhiHr6OBgqHM7EbaxoR163VT18NP/hdQlJN08q3c6B21e1
 G8LXWwyX9IJPxD05+uq4P0D4=
From: Tomas Volf <~@wolfsden.cz>
To: Ian Eure <ian@HIDDEN>
Subject: Re: bug#72686: Impossible to remove all offload machines
In-Reply-To: <87ldzt606c.fsf@meson> (Ian Eure's message of "Sat, 14 Sep 2024
 20:53:22 -0700")
References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@HIDDEN>
 <87plp560ji.fsf@meson> <87ldzt606c.fsf@meson>
Mail-Followup-To: Ian Eure <ian@HIDDEN>, Maxim Cournoyer
 <maxim.cournoyer@HIDDEN>, 72686 <at> debbugs.gnu.org, guix-devel
 <guix-devel@HIDDEN>
Date: Sun, 15 Sep 2024 21:06:13 +0200
Message-ID: <875xqwivoa.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 72686
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org,
 Maxim Cournoyer <maxim.cournoyer@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Hello,

Ian Eure <ian@HIDDEN> writes:

> Disregard this, I continued thinking after sending the email (as one does=
) and
> realized that any managed file will be a link into the store -- so if the=
 system
> is reconfigured with no build-machines or channels *and* the correspondin=
g file
> is a store link, it should be removed; otherwise, it should remain untouc=
hed. I
> can work with this.

Will this correctly handle cases where user is managing the file using
for example extra-special-file?

I wonder whether fat-warning approach would not be better.

Tomas

=2D-=20
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJCBAEBCgAsFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmbnMCUOHH5Ad29sZnNk
ZW4uY3oACgkQL7/ufbZ/wamhkw//YdqItJFnhZlRT59t2Ys/apMiyuGuJJml5Gan
aMtkn5FFVZQQIU4l6l7RQS/6+N2RJDZ0WtFXpy+c6AZc/y2xA9ib9IIVCpQoTdyK
o7yoRXhZfDyNAGrgyCvKywzbUBEqQ9hOuE3CY4uHZvZ7YcpeenA0w13lWk1j0UzY
H+1bY/7bS3nXYwx43DKFL3uwwPD6/Kwom6JROO7YoJ6QAh2ppwCsYZqqHc+4Eixb
VJM9bowK1hBexviDw3Pg7CA53JurFQQk5UneReempbx/gTOMzrf/T1Ye46Utf0Ys
iqajy3rZ4wSfc4tAJRH6Yt/VRvDowWQ9FsV+KyoaseBEm9v9l0kK8EBNHB5kkEQw
327PwJ4eafOgQ+2nwSOccGZIvYiX12hsFm5/uKWw6dwEAY+tWMUlKeT9wbqB9ya6
FhimFHMQw7RjdJ7SRYbuh9KrNUCTI43vI+HsHD1RkovpeeCrlq0e9sPPJgl3LITG
XHg6KPt1XUVj9zyEf+BmQaJ6qdS1376NcD79DQ7XWtjMEFj8jvmUmM9fIXCJqwj+
QwvWZ0tU4wPJ5mqhMTzWUsuDBykrEOLYkx89oSBj5C3w9z4zFDy4q+Ki7pH2h2lF
X47xWgvCqbo64YJhEPIP0SETkIgVLFn9bbuRY73l/GZ6INSgcF4FQWrNWLxpagD5
DH4XWdQ=
=cMRi
-----END PGP SIGNATURE-----
--=-=-=--




Information forwarded to bug-guix@HIDDEN:
bug#72686; Package guix. Full text available.

Message received at 72686 <at> debbugs.gnu.org:


Received: (at 72686) by debbugs.gnu.org; 15 Sep 2024 03:55:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 14 23:55:28 2024
Received: from localhost ([127.0.0.1]:48089 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1spgMB-0005OK-WE
	for submit <at> debbugs.gnu.org; Sat, 14 Sep 2024 23:55:28 -0400
Received: from fout2-smtp.messagingengine.com ([103.168.172.145]:52919)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ian@HIDDEN>) id 1spgMA-0005O3-MK
 for 72686 <at> debbugs.gnu.org; Sat, 14 Sep 2024 23:55:27 -0400
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfout.phl.internal (Postfix) with ESMTP id 24B5D138028B;
 Sat, 14 Sep 2024 23:55:10 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-11.internal (MEProxy); Sat, 14 Sep 2024 23:55:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h=
 cc:cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to; s=fm3; t=1726372510;
 x=1726458910; bh=1h/utW6wOkJRqw8Bizf49QhCORehXJtr6R9EJuGZni4=; b=
 sc8CeMOYdJxf+YPFs0f+XSNOJsVKtcia/SJ1Y8qwC9AN/qhDgv4+tIoBEB5053hu
 0lUD1LRSOiX+UqfI2zGtl0nsgZaRhAnZO7mUIhnLHSFiNTq2GQXfybZUqWQINRGv
 UbHKCFanbzZOgfEdQ1syVzYr6COT1TnZjPscEvZbd5ZgexO52DbkeBwdy8JbOd6Z
 I3oWWt6F7oouhfRkdSYusfVK7DBRpSBM5nupOM2wvFJ2svpoQZWqOqIzfJoL9lt2
 eKXCCZ5R7hgXT/YhpJGZ3ZBDKkZVnUaLEIXQN3FUgLeBb6Z7m92DXmBSG13zArhx
 JRQZBPmbRnsPFGQ3oEyftQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1726372510; x=
 1726458910; bh=1h/utW6wOkJRqw8Bizf49QhCORehXJtr6R9EJuGZni4=; b=G
 VkzdSlsAKrPVIDasMzSTgs2fCea2apJBeQw9lBjmYIkkAtl3NHstJBizKhUAGVfE
 GILMn8pT9ZsrkEeHE6c94THUPR/PsBqgNWRddxtOM+iFXh7eMOpWPz/pGpbTqxM2
 ObwLRcnfJB1KVN5RGsgVWOVP1EC2VXEsX48LVFjfxBel0yS6/CmyjsjfDq4fXl1c
 sD5rf4EGxoVlen90nPPB6TzmJC6M0Qf9T9qFhZIhnSxOsnFUAnNwigjqvILF2ltm
 yc2/yzT6n/LEOcIvlzyjOsZkrcp2Q6KEyiGz+u6I2t6ci+4312izoMobOb5Ua8D0
 sDGa+FgX97um4RNQsTXGA==
X-ME-Sender: <xms:nVrmZimNPuwl6IOAVCR4J0h2fJt6Nl28U4Xbh84maX8kwDTgcn17cQ>
 <xme:nVrmZp0MN8H2KyDOog5EdgV2HpHB1yOvWn81RTBNGN0Ds_mc1AAFw6b8GLtxu8uXc
 7YKnXX0xDTkqlXkXg>
X-ME-Received: <xmr:nVrmZgrF4XduFNPm7Rv_APyytsB6l3w4nZmllZHmNL6m80D2GNhJg85NwwoXxSqGk63_z7UugpcAmsUNVJYsS2XIA-qmKEvfWl5V3Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudekuddgjeejucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurhepfhgfhffvvefuffgjkfggtgfgsehtqhertddtreej
 necuhfhrohhmpefkrghnucfguhhrvgcuoehirghnsehrvghtrhhoshhpvggtrdhtvheqne
 cuggftrfgrthhtvghrnhephfelvedtieeffffggeeivdeukedutedtveejfffhleeileef
 heeggfdugfeiuefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh
 hfrhhomhepihgrnhesrhgvthhrohhsphgvtgdrthhvpdhnsggprhgtphhtthhopeefpdhm
 ohguvgepshhmthhpohhuthdprhgtphhtthhopehguhhigidquggvvhgvlhesghhnuhdroh
 hrghdprhgtphhtthhopeejvdeikeeiseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp
 thhtohepmhgrgihimhdrtghouhhrnhhohigvrhesghhmrghilhdrtghomh
X-ME-Proxy: <xmx:nVrmZmlNQ3jqV9yIDnVS_qrXCoN6HiPs6WHUVhTE5vAdXPCsellQ3Q>
 <xmx:nVrmZg0QRFMQeMi_FWj5mFC-cY1FGxVY2rcWEQAUMnwMbDtcWQtACA>
 <xmx:nVrmZtsfSS0wG_Otcpjos6iLvz_adi8bTYuMGUZTjYBYcBDU-hcpqQ>
 <xmx:nVrmZsXjQrXN-deu7lMRBAjLkxSYriEUQYHhc2jOYMSGzfatj9ZUFA>
 <xmx:nlrmZtyFhcZ4Rz7NrbwW1kRxQeMIdB_WmoKECUX2qDivUtUq_5rxcGJV>
Feedback-ID: id9014242:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat,
 14 Sep 2024 23:55:08 -0400 (EDT)
References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@HIDDEN>
 <87plp560ji.fsf@meson>
User-agent: mu4e 1.8.13; emacs 28.2
From: Ian Eure <ian@HIDDEN>
To: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Subject: Re: bug#72686: Impossible to remove all offload machines
Date: Sat, 14 Sep 2024 20:53:22 -0700
In-reply-to: <87plp560ji.fsf@meson>
Message-ID: <87ldzt606c.fsf@meson>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 72686
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Hi Maxim,

Ian Eure <ian@HIDDEN> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@HIDDEN> writes:
>
>> Hi Ian,
>>
>> Ian Eure <ian@HIDDEN> writes:
>>
>>> Ran into this issue last week.  If you:
>>>
>>> - Configure some offload build machines in your=20
>>> operating-system
>>>  configuration.
>>> - Reconfigure your system.
>>> - Remove all offload build machines.
>>> - Reconfigure your system again.
>>>
>>> ...then various guix operations will still try to connect to
>>> offload
>>> machines, even if you reboot the affected client.
>>>
>>> This is caused by a bug in the `guix-activation' procedure:
>>>
>>>   ;; ... and /etc/guix/machines.scm.
>>>   #$(if (null? (guix-configuration-build-machines config))
>>>         #~#f
>>>         (guix-machines-files-installation
>>>          #~(list #$@(guix-configuration-build-machines
>>>           config))))
>>>
>>> If there are no build machines defined in the configuration,=20
>>> no
>>> operation is performed (#f is returned), which leaves the=20
>>> previous
>>> generation=E2=80=99s /etc/guix/machines.scm in place.
>>>
>>> The same issue appears to affect channels:
>>>
>>>   ;; ... and /etc/guix/channels.scm...
>>>   #$(and channels (install-channels-file channels))
>>
>> Interesting!
>>
>>> I=E2=80=99d be happy to take a stab at fixing this, but I=E2=80=99m not=
=20
>>> certain
>>> what
>>> direction to go, or how much to refactor to get there. Should=20
>>> the
>>> channels/machines files be removed (ignoring errors if they=20
>>> don=E2=80=99t
>>> exist)?  Should empty files be installed?  Should that happen
>>> inline
>>> in `guix-activation', or in another procedure? Should the=20
>>> filenames
>>> be
>>> extracted to %variables to avoid duplicating between the two=20
>>> places
>>> they=E2=80=99ll be used?
>>>
>>> If someone would like to provide answered, I would contribute=20
>>> a
>>> patch.
>>
>> I guess the simplest would be to attempt to remove the files=20
>> when
>> there
>> are no offload machines or channels, in this already existing
>> activation
>> procedure.  Extracting the file names to %variables sounds
>> preferable
>> yes, if there's a logical place to store them that is easily=20
>> shared.
>>
>
> As I was putting together a patch for this, I realized there=E2=80=99s a
> problem: if a user is *manually* managing either
> /etc/guix/machines.scm or channels.scm, these files would be=20
> deleted,
> which likely isn=E2=80=99t what they want.  The current code lets users=20
> choose
> to manage these files manually or declaritively, and there=E2=80=99s no=20
> way to
> know if the files on disk are the result of a previous system
> generation or a user=E2=80=99s creation.  Since the channel management=20
> is a
> relatively new feature, I suspect there are quite a few folks=20
> with
> manually-managed channels that this would negatively impact.  I=20
> know
> there was some disruption just moving to declaritive management=20
> of
> channels (but I can=E2=80=99t find the thread/s at the moment).
>
> I don=E2=80=99t see an elegant technical solution to this.  I think the=20
> best
> option is probably to say that those files should *always* be=20
> managed
> through operating-system, and put a fat warning in the channel=20
> news to
> update your config if they=E2=80=99re still handled manually.
>
> The only other option I can see would be to keep the existing
> filenames for user configuration, and declaritively manage=20
> different
> files -- like declaritive-channels.scm.  This comes with its own=20
> set
> of problems, like needing to update the Guix daemon to read and
> combine multiple files; and the inability to know whether a=20
> given
> `channels.scm' is declaritively- or manually-managed means a=20
> bumpy
> upgrade path (ex. should this preexisting channels.scm file be=20
> left
> as-is, or renamed to the new name?)
>
> I=E2=80=99m inclined to go with the fat-warning option, but am also=20
> thinking
> this likely needs some guix-devel discussion.
>
> What do you think?
>

Disregard this, I continued thinking after sending the email (as=20
one does) and realized that any managed file will be a link into=20
the store -- so if the system is reconfigured with no=20
build-machines or channels *and* the corresponding file is a store=20
link, it should be removed; otherwise, it should remain untouched.=20
I can work with this.

Thanks,

  =E2=80=94 Ian




Information forwarded to bug-guix@HIDDEN:
bug#72686; Package guix. Full text available.

Message received at 72686 <at> debbugs.gnu.org:


Received: (at 72686) by debbugs.gnu.org; 15 Sep 2024 03:47:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 14 23:47:38 2024
Received: from localhost ([127.0.0.1]:48083 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1spgEb-0004u3-Pj
	for submit <at> debbugs.gnu.org; Sat, 14 Sep 2024 23:47:38 -0400
Received: from fout1-smtp.messagingengine.com ([103.168.172.144]:33217)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ian@HIDDEN>) id 1spgEX-0004tj-F2
 for 72686 <at> debbugs.gnu.org; Sat, 14 Sep 2024 23:47:35 -0400
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfout.phl.internal (Postfix) with ESMTP id 181EC1380298;
 Sat, 14 Sep 2024 23:47:16 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-11.internal (MEProxy); Sat, 14 Sep 2024 23:47:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h=
 cc:cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to; s=fm3; t=1726372036;
 x=1726458436; bh=ex8dkWAZlvMAITRwHbuH00/7H1ruJ9I4Fu35mN3XyYI=; b=
 nzfte8+nKUILLrVicxnBcoICDsYWF9SPAbybtQWYcZp725Y+zfMjQgSI1ikILlRA
 RjAPd0qB2ZW6ggSBaBsnyzT7FrcssZsx1yr1DIaEqkejuFs17ZglexwZBDyYTcDe
 jERsuTR6QQeCFOQ+6mS6S4yze0l27X7yHUoHcp31BhhygwHhIGAX0v5PCl+cXHwm
 LuY10qxJrW4LqOKAXop9iz/l+h/i40ZpcWNvFjv4tiHMVqObb9IqLCwOaIrtdT3u
 zVB5+3+zuQvjYwy8OqoK7HfnZkTWWHkDrGYcRzcQLAr9PCEfOn5eXyKWf6CYIsCx
 lm1B++X1TvwoH+g8Pt/tOg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1726372036; x=
 1726458436; bh=ex8dkWAZlvMAITRwHbuH00/7H1ruJ9I4Fu35mN3XyYI=; b=m
 Wq1lCLgiuyYQz5LSlcZ53jE6fKGnNzFrYzdlT9LLTD15txSzfCh/cO3M7INTvP5r
 q94ad8TDWNal2XUptaCFdmQz1oTneSripwg5DrUS86+f/FB3hBgqtv9TUyQY/pzA
 rYqr8z/5odAf0T0OY8M8rkak7GKqB2J79GbEuMnlvfvR9Mpu8qCTfmYfzEfW8h+/
 7WlMHVZTwg0rnlt3LYpP91UuWgfN0FK6kWKWJqulPhjo+01kWHKe9Hfp4Jp8hiRj
 Skm38UoFUX4rKoeubp8xH7rOjCGWtTX8B0Hi7U3zNJXZ9Qi6meUIxUtfyw1C9veK
 6/ze/MRsGj82bIL+seoeQ==
X-ME-Sender: <xms:w1jmZvXi4cEM-pz3gCvgfW3Hx4JoKCGZgNQ33QlBZ47Bfqc1q7S4eQ>
 <xme:w1jmZnnc53Z9cQ6LuYmKZQ-E9Ijkdi6omfgi6jQF8dOXkDsKR8WZbGmj8RVhIENO9
 sgSpC-UooEKvJpaHg>
X-ME-Received: <xmr:w1jmZrbtuRXt77XKudI2uu4rdv2F_H1UEY73lNSV6ZSe2vLrUgzb-gXlXm3VG0R5-eGHCiJ1t63q07uqGorQ86XhfUC6JyLhc6gaug>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudekuddgjeeiucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurhepfhgfhffvvefuffgjkfggtgfgsehtqhertddtreej
 necuhfhrohhmpefkrghnucfguhhrvgcuoehirghnsehrvghtrhhoshhpvggtrdhtvheqne
 cuggftrfgrthhtvghrnhephfelvedtieeffffggeeivdeukedutedtveejfffhleeileef
 heeggfdugfeiuefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh
 hfrhhomhepihgrnhesrhgvthhrohhsphgvtgdrthhvpdhnsggprhgtphhtthhopeefpdhm
 ohguvgepshhmthhpohhuthdprhgtphhtthhopehguhhigidquggvvhgvlhesghhnuhdroh
 hrghdprhgtphhtthhopeejvdeikeeiseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp
 thhtohepmhgrgihimhdrtghouhhrnhhohigvrhesghhmrghilhdrtghomh
X-ME-Proxy: <xmx:w1jmZqUmZ4hDPDrliQFJFIWohQ5xJZ06uuGn6rDAETYehtYpG2aEMQ>
 <xmx:w1jmZpl2A7Nk_H_lgnWFbJq8qbUlTlic8zIeYGU237imObYJ-tqGGw>
 <xmx:w1jmZneR-dgaGTYJcELosOxCO-iUI6BT_OfoDdzpKyUoeOsa2jQd-w>
 <xmx:w1jmZjFrRVne1yChuAMkcAuR67oeayOKOi7wBX_SYgfXsKXIa8tHiQ>
 <xmx:xFjmZvgOYM7Mfj-spReKfemB0JgsfovWpn4cVSI0mREL-glVxzDLzuMp>
Feedback-ID: id9014242:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat,
 14 Sep 2024 23:47:14 -0400 (EDT)
References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@HIDDEN>
User-agent: mu4e 1.8.13; emacs 28.2
From: Ian Eure <ian@HIDDEN>
To: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Subject: Re: bug#72686: Impossible to remove all offload machines
Date: Sat, 14 Sep 2024 20:24:38 -0700
In-reply-to: <87zfoaqo7p.fsf@HIDDEN>
Message-ID: <87plp560ji.fsf@meson>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 72686
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@HIDDEN> writes:

> Hi Ian,
>
> Ian Eure <ian@HIDDEN> writes:
>
>> Ran into this issue last week.  If you:
>>
>> - Configure some offload build machines in your=20
>> operating-system
>>  configuration.
>> - Reconfigure your system.
>> - Remove all offload build machines.
>> - Reconfigure your system again.
>>
>> ...then various guix operations will still try to connect to=20
>> offload
>> machines, even if you reboot the affected client.
>>
>> This is caused by a bug in the `guix-activation' procedure:
>>
>>   ;; ... and /etc/guix/machines.scm.
>>   #$(if (null? (guix-configuration-build-machines config))
>>         #~#f
>>         (guix-machines-files-installation
>>          #~(list #$@(guix-configuration-build-machines
>>           config))))
>>
>> If there are no build machines defined in the configuration, no
>> operation is performed (#f is returned), which leaves the=20
>> previous
>> generation=E2=80=99s /etc/guix/machines.scm in place.
>>
>> The same issue appears to affect channels:
>>
>>   ;; ... and /etc/guix/channels.scm...
>>   #$(and channels (install-channels-file channels))
>
> Interesting!
>
>> I=E2=80=99d be happy to take a stab at fixing this, but I=E2=80=99m not =
certain=20
>> what
>> direction to go, or how much to refactor to get there. Should=20
>> the
>> channels/machines files be removed (ignoring errors if they=20
>> don=E2=80=99t
>> exist)?  Should empty files be installed?  Should that happen=20
>> inline
>> in `guix-activation', or in another procedure? Should the=20
>> filenames be
>> extracted to %variables to avoid duplicating between the two=20
>> places
>> they=E2=80=99ll be used?
>>
>> If someone would like to provide answered, I would contribute a=20
>> patch.
>
> I guess the simplest would be to attempt to remove the files=20
> when there
> are no offload machines or channels, in this already existing=20
> activation
> procedure.  Extracting the file names to %variables sounds=20
> preferable
> yes, if there's a logical place to store them that is easily=20
> shared.
>

As I was putting together a patch for this, I realized there=E2=80=99s a=20
problem: if a user is *manually* managing either=20
/etc/guix/machines.scm or channels.scm, these files would be=20
deleted, which likely isn=E2=80=99t what they want.  The current code lets=
=20
users choose to manage these files manually or declaritively, and=20
there=E2=80=99s no way to know if the files on disk are the result of a=20
previous system generation or a user=E2=80=99s creation.  Since the=20
channel management is a relatively new feature, I suspect there=20
are quite a few folks with manually-managed channels that this=20
would negatively impact.  I know there was some disruption just=20
moving to declaritive management of channels (but I can=E2=80=99t find the=
=20
thread/s at the moment).

I don=E2=80=99t see an elegant technical solution to this.  I think the=20
best option is probably to say that those files should *always* be=20
managed through operating-system, and put a fat warning in the=20
channel news to update your config if they=E2=80=99re still handled=20
manually.

The only other option I can see would be to keep the existing=20
filenames for user configuration, and declaritively manage=20
different files -- like declaritive-channels.scm.  This comes with=20
its own set of problems, like needing to update the Guix daemon to=20
read and combine multiple files; and the inability to know whether=20
a given `channels.scm' is declaritively- or manually-managed means=20
a bumpy upgrade path (ex. should this preexisting channels.scm=20
file be left as-is, or renamed to the new name?)

I=E2=80=99m inclined to go with the fat-warning option, but am also=20
thinking this likely needs some guix-devel discussion.

What do you think?

Thanks,

  =E2=80=94 Ian




Information forwarded to bug-guix@HIDDEN:
bug#72686; Package guix. Full text available.

Message received at 72686 <at> debbugs.gnu.org:


Received: (at 72686) by debbugs.gnu.org; 14 Sep 2024 14:57:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 14 10:57:03 2024
Received: from localhost ([127.0.0.1]:47585 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1spUCs-0003Vy-Jw
	for submit <at> debbugs.gnu.org; Sat, 14 Sep 2024 10:57:03 -0400
Received: from mail-pf1-f177.google.com ([209.85.210.177]:51666)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maxim.cournoyer@HIDDEN>) id 1spUCo-0003VO-N8
 for 72686 <at> debbugs.gnu.org; Sat, 14 Sep 2024 10:57:00 -0400
Received: by mail-pf1-f177.google.com with SMTP id
 d2e1a72fcca58-7191901abd6so1271988b3a.3
 for <72686 <at> debbugs.gnu.org>; Sat, 14 Sep 2024 07:56:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1726325742; x=1726930542; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=K+WpZdM/apDQ8ZhEEhwOe2mc5PZ2aE3IB0tEzWfVggc=;
 b=ACf+GakCpknl85i7OpdE4Yk4nQpDA3KJKo2cnY1o6wFy7xrvNMWR+cFLLnzPKp1YHP
 4VniBcCbAEvb6an25sggNPdWKA4k8TGFTks2WCkkD1AU48HmJhOhp4/uQ5h+HB2anj94
 cG8e+9VC507YeM7FJQXUsCcW4c2T3ys9MyV22lptiM/bK2+EBMcgH+W6BDu3F0GNaH0R
 DmNKQvhliQ335FxFgIw4ERl1nes4niPSeEVsmWVAVqWGlOOdCkNXs98uh4NDwf5w4Qdc
 559eAKikOYdkpY6rli+r0gYoaQOAuqdaY64eJkgrptF89DxXU9bwDxoVVXaaehC9J/bt
 2+Bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1726325742; x=1726930542;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=K+WpZdM/apDQ8ZhEEhwOe2mc5PZ2aE3IB0tEzWfVggc=;
 b=ZeLOPFe899Nd1ZsJc0R3dGcACAKnXtYaFi31o+L994oGqd50bCKMePj4lRQ5Ghh4VX
 Xs5mw0g6Wkl0HePt5uM5rcKIhkRZ7mGf1hWVPXoVZ0HzS3F4DRZfjvPpj9+9XjgOHnl9
 WGF89dG/fSa/0bukZgGd3j6bo3ATizH4m+qi3QeGxtKlus9NRGMW962umkKD81PbkKBR
 ElV50VicUw9LyEqXOVqeZPpbfVlz9loqXErOvP7LRlK6NpEPszxQBmV8x/J2f4rj+Hr1
 jwJYY5Ch34ue8iEMCkuKfOnMwLE85SuabPDuDCkOdlr04OvuMOS/h1p1U6Q9CpsF329q
 2HXw==
X-Gm-Message-State: AOJu0YwlTAarInyycY879dZkwsXvtkfsrwdN19+14XY5hzLTEsOg4C0l
 C6KZlMsq82+m1UYVv+ryLnt4zyv1PTNsOxe6vfBxcysL5fr6KT+p
X-Google-Smtp-Source: AGHT+IHQaWOqmdFBOc7kpcoAyUFDBrPzXUWPCDF3EZ/wVfzlbL/ZTZfwdpAojjvs2umHgaECSmN+TA==
X-Received: by 2002:a05:6a20:c6ce:b0:1cf:4fa8:49f2 with SMTP id
 adf61e73a8af0-1d112eb2521mr8749513637.49.1726325742062; 
 Sat, 14 Sep 2024 07:55:42 -0700 (PDT)
Received: from hurd ([2405:6586:be0:0:c8ff:1707:9b9:af89])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-71944a9cac0sm1078039b3a.43.2024.09.14.07.55.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 14 Sep 2024 07:55:41 -0700 (PDT)
From: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
To: Ian Eure <ian@HIDDEN>
Subject: Re: bug#72686: Impossible to remove all offload machines
In-Reply-To: <87plq75cbc.fsf@meson> (Ian Eure's message of "Sat, 17 Aug 2024
 09:40:29 -0700")
References: <87plq75cbc.fsf@meson>
Date: Sat, 14 Sep 2024 23:55:38 +0900
Message-ID: <87zfoaqo7p.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 72686
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Ian,

Ian Eure <ian@HIDDEN> writes:

> Ran into this issue last week.  If you:
>
> - Configure some offload build machines in your operating-system
>  configuration.
> - Reconfigure your system.
> - Remove all offload build machines.
> - Reconfigure your system again.
>
> ...then various guix operations will still try to connect to offload
> machines, even if you reboot the affected client.
>
> This is caused by a bug in the `guix-activation' procedure:
>
>   ;; ... and /etc/guix/machines.scm.
>   #$(if (null? (guix-configuration-build-machines config))
>         #~#f
>         (guix-machines-files-installation
>          #~(list #$@(guix-configuration-build-machines
>           config))))
>
> If there are no build machines defined in the configuration, no
> operation is performed (#f is returned), which leaves the previous
> generation=E2=80=99s /etc/guix/machines.scm in place.
>
> The same issue appears to affect channels:
>
>   ;; ... and /etc/guix/channels.scm...
>   #$(and channels (install-channels-file channels))

Interesting!

> I=E2=80=99d be happy to take a stab at fixing this, but I=E2=80=99m not c=
ertain what
> direction to go, or how much to refactor to get there. Should the
> channels/machines files be removed (ignoring errors if they don=E2=80=99t
> exist)?  Should empty files be installed?  Should that happen inline
> in `guix-activation', or in another procedure? Should the filenames be
> extracted to %variables to avoid duplicating between the two places
> they=E2=80=99ll be used?
>
> If someone would like to provide answered, I would contribute a patch.

I guess the simplest would be to attempt to remove the files when there
are no offload machines or channels, in this already existing activation
procedure.  Extracting the file names to %variables sounds preferable
yes, if there's a logical place to store them that is easily shared.

A patch would be dandy!

--=20
Thanks,
Maxim




Information forwarded to bug-guix@HIDDEN:
bug#72686; Package guix. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 17 Aug 2024 16:45:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 17 12:45:10 2024
Received: from localhost ([127.0.0.1]:54883 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sfMY9-0006Pr-LC
	for submit <at> debbugs.gnu.org; Sat, 17 Aug 2024 12:45:09 -0400
Received: from lists.gnu.org ([209.51.188.17]:35804)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ian@HIDDEN>) id 1sfMY7-0006Pj-EQ
 for submit <at> debbugs.gnu.org; Sat, 17 Aug 2024 12:45:08 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ian@HIDDEN>)
 id 1sfMXT-0003mT-Kk; Sat, 17 Aug 2024 12:44:27 -0400
Received: from fhigh5-smtp.messagingengine.com ([103.168.172.156])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ian@HIDDEN>)
 id 1sfMXR-00043W-Nc; Sat, 17 Aug 2024 12:44:27 -0400
Received: from phl-compute-06.internal (phl-compute-06.nyi.internal
 [10.202.2.46])
 by mailfhigh.nyi.internal (Postfix) with ESMTP id 1D3E61150836;
 Sat, 17 Aug 2024 12:44:23 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-06.internal (MEProxy); Sat, 17 Aug 2024 12:44:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h=
 cc:cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:message-id:mime-version:reply-to
 :subject:subject:to:to; s=fm2; t=1723913063; x=1723999463; bh=uB
 0OgJJey95VxLTIWfMpWol+eMVmioWuFS7+777E324=; b=GUlqBgFO1CxrUETz17
 iadRq4Vl6RSNM96fCTXiZWM79NBtfV9NVyvrXCvBYG0Gr4RbmS+F0LVAZDXYJnrD
 X+Us94pFvhZ3A1Ufl04xfe+qYK7/9N38aSnB4R6YtxEp8W9UjXOApzncl0d2cBJM
 gnHjtUv0sn1v50l3yiF3LQ/shBxzaJKHuabQdgsbauBTmxfhZzN7jDAXdqXYn8WP
 uIlcNc71KxjDgFkYd1Yygfncmfpoyz38Da9KVt5RP5yRjlLcVcaN58nSy53kiscO
 yAHa4PXmgJWgtKLSL1v1HG3gcddCpNjxgJj+CgE68pCV1/KXWYilMVR1hAkIT0eX
 84og==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:message-id:mime-version:reply-to:subject
 :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm3; t=1723913063; x=1723999463; bh=uB0OgJJey95Vx
 LTIWfMpWol+eMVmioWuFS7+777E324=; b=jIMZjgxIUapL8JqGLUV/aq/L2UXgp
 wy0Q3t8u0zk5XUFom0wQQmRjf1eyAP4ZDvQbRoMZfg0OfFipoHTVnUXFfYYHBDFu
 /nFmIjBogID2c68QG9LotN8Bj7OwQjsvgDOcOHcGM/8CGISNFo2fOUXCiVsJL/rS
 sIPITkO/inpni4e727g5Vr0rYe7E3UNVhJnpWHE3kQ0xAsERkdkRT4m0RgrNVHlf
 PUUGpAx2NF+HbhZS9QTKBlmyEwqONI/x59cwcu4gpR9BXizlsb2WLUfgFfXXpeKf
 3C1BrlUl47Ym1g4Pb/i12xhze//utvb42sH/4jLzSjWamEVBtVP9cOf6w==
X-ME-Sender: <xms:ZtPAZgBxRKWXCO4rEZOThvKAz2PBSO84u4tWdaDdPunTqbmepaxMjg>
 <xme:ZtPAZig5oE-fOozo_OUP41hALPi2HLjzOmZ8RSJss3vtlF0zWeK3_gYx_2javlRjr
 SjKLp1ZZyVhDADMMw>
X-ME-Received: <xmr:ZtPAZjme0jJKYFi5QsvdRp3YX3u7-CkvVwMNqPx_0Btvef-vWgQDpJLQnD_9VJ5krzyqcVBvd86Po8rXjWHh_iHnJLsCT9pKO_A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddutddguddthecutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
 uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfgfhvf
 evufffkfggtgfgsehtqhertddtreejnecuhfhrohhmpefkrghnucfguhhrvgcuoehirghn
 sehrvghtrhhoshhpvggtrdhtvheqnecuggftrfgrthhtvghrnhepieevveelvdevveetke
 efkeeggfeftddtvdevuefgueeftdefgefhieduheeuveeinecuvehluhhsthgvrhfuihii
 vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepihgrnhesrhgvthhrohhsphgvtgdrth
 hvpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehg
 uhhigidquggvvhgvlhesghhnuhdrohhrghdprhgtphhtthhopegsuhhgqdhguhhigiesgh
 hnuhdrohhrgh
X-ME-Proxy: <xmx:ZtPAZmwARG10TPshYySBAfuJcbmHRw5ZdrcQFM-mI26DX3aOyfhNrg>
 <xmx:ZtPAZlT6KObK7J0WgFEdwHwVdRBi_jx5lEzmyBHFnxW1MR59qvBL8A>
 <xmx:ZtPAZhaqsO4vvKfmGOxZCKhh6r8dUSDUNgPnLTlrN4UpjoKN6OBArw>
 <xmx:ZtPAZuTA7awLlLyePsZw0BWKqAHoCRvJr0n3c-zJrEHsiiAyveEzyQ>
 <xmx:Z9PAZgd-sTVyxCwOFm-VNLEjwM5vSOFybhVLqM3KvnGOQ5Vc-bBlmpCJ>
Feedback-ID: id9014242:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat,
 17 Aug 2024 12:44:22 -0400 (EDT)
User-agent: mu4e 1.8.13; emacs 28.2
From: Ian Eure <ian@HIDDEN>
To: bug-guix@HIDDEN
Subject: Impossible to remove all offload machines
Date: Sat, 17 Aug 2024 09:40:29 -0700
Message-ID: <87plq75cbc.fsf@meson>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=103.168.172.156; envelope-from=ian@HIDDEN;
 helo=fhigh5-smtp.messagingengine.com
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.6 (-)
X-Debbugs-Envelope-To: submit
Cc: guix-devel <guix-devel@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.6 (--)

Ran into this issue last week.  If you:

- Configure some offload build machines in your operating-system
  configuration.
- Reconfigure your system.
- Remove all offload build machines.
- Reconfigure your system again.

...then various guix operations will still try to connect to=20
offload machines, even if you reboot the affected client.

This is caused by a bug in the `guix-activation' procedure:

   ;; ... and /etc/guix/machines.scm.
   #$(if (null? (guix-configuration-build-machines config))
         #~#f
         (guix-machines-files-installation
          #~(list #$@(guix-configuration-build-machines
           config))))

If there are no build machines defined in the configuration, no
operation is performed (#f is returned), which leaves the previous
generation=E2=80=99s /etc/guix/machines.scm in place.

The same issue appears to affect channels:

   ;; ... and /etc/guix/channels.scm...
   #$(and channels (install-channels-file channels))

I=E2=80=99d be happy to take a stab at fixing this, but I=E2=80=99m not cer=
tain=20
what
direction to go, or how much to refactor to get there. Should the
channels/machines files be removed (ignoring errors if they don=E2=80=99t
exist)?  Should empty files be installed?  Should that happen=20
inline
in `guix-activation', or in another procedure? Should the=20
filenames be
extracted to %variables to avoid duplicating between the two=20
places
they=E2=80=99ll be used?

If someone would like to provide answered, I would contribute a=20
patch.

Thanks,

 =E2=80=94 Ian




Acknowledgement sent to Ian Eure <ian@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-guix@HIDDEN. Full text available.
Report forwarded to bug-guix@HIDDEN:
bug#72686; Package guix. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Sun, 12 Jan 2025 05:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.