GNU logs - #72686, boring messages

Message sent to bug-guix@HIDDEN:

Subject: bug#72686: Impossible to remove all offload machines
Resent-From: Ian Eure <ian@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sat, 17 Aug 2024 16:46:02 +0000
Resent-Message-ID: <handler.72686.B.172391311024671 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 72686 <at> debbugs.gnu.org
Cc: guix-devel <guix-devel@HIDDEN>
Feedback-ID: id9014242:Fastmail
User-agent: mu4e 1.8.13; emacs 28.2
From: Ian Eure <ian@HIDDEN>
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-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

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Ian Eure <ian@HIDDEN>
Subject: bug#72686: Acknowledgement (Impossible to remove all offload
 machines)
Message-ID: <handler.72686.B.172391311024671.ack <at> debbugs.gnu.org>
References: <87plq75cbc.fsf@meson>
X-Gnu-PR-Message: ack 72686
X-Gnu-PR-Package: guix
Reply-To: 72686 <at> debbugs.gnu.org
Date: Sat, 17 Aug 2024 16:46:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guix@HIDDEN

If you wish to submit further information on this problem, please
send it to 72686 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
72686: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D72686
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guix@HIDDEN:

Subject: bug#72686: Impossible to remove all offload machines
Resent-From: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sat, 14 Sep 2024 14:58:01 +0000
Resent-Message-ID: <handler.72686.B72686.172632582313519 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Ian Eure <ian@HIDDEN>
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org
From: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
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
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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

Message sent to bug-guix@HIDDEN:

Subject: bug#72686: Impossible to remove all offload machines
Resent-From: Ian Eure <ian@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sun, 15 Sep 2024 03:48:02 +0000
Resent-Message-ID: <handler.72686.B72686.172637205818856 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org
Feedback-ID: id9014242:Fastmail
References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@HIDDEN>
User-agent: mu4e 1.8.13; emacs 28.2
From: Ian Eure <ian@HIDDEN>
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
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72686: Impossible to remove all offload machines
Resent-From: Ian Eure <ian@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sun, 15 Sep 2024 03:56:01 +0000
Resent-Message-ID: <handler.72686.B72686.172637252820732 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72686
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org
Received: via spool by 72686-submit <at> debbugs.gnu.org id=B72686.172637252820732
          (code B ref 72686); Sun, 15 Sep 2024 03:56:01 +0000
Received: (at 72686) by debbugs.gnu.org; 15 Sep 2024 03:55:28 +0000
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>
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-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

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72686: Impossible to remove all offload machines
Resent-From: Tomas Volf <~@wolfsden.cz>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sun, 15 Sep 2024 19:07:01 +0000
Resent-Message-ID: <handler.72686.B72686.172642719326350 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72686
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Ian Eure <ian@HIDDEN>
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Received: via spool by 72686-submit <at> debbugs.gnu.org id=B72686.172642719326350
          (code B ref 72686); Sun, 15 Sep 2024 19:07:01 +0000
Received: (at 72686) by debbugs.gnu.org; 15 Sep 2024 19:06:33 +0000
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>
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-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-----
--=-=-=--

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72686: Impossible to remove all offload machines
Resent-From: Ian Eure <ian@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 19 Sep 2024 00:37:02 +0000
Resent-Message-ID: <handler.72686.B72686.172670620227505 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72686
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Tomas Volf <~@wolfsden.cz>
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Received: via spool by 72686-submit <at> debbugs.gnu.org id=B72686.172670620227505
          (code B ref 72686); Thu, 19 Sep 2024 00:37:02 +0000
Received: (at 72686) by debbugs.gnu.org; 19 Sep 2024 00:36:42 +0000
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>
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-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

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72686: Impossible to remove all offload machines
Resent-From: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sun, 22 Sep 2024 02:29:01 +0000
Resent-Message-ID: <handler.72686.B72686.172697209532033 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72686
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Ian Eure <ian@HIDDEN>
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org
Received: via spool by 72686-submit <at> debbugs.gnu.org id=B72686.172697209532033
          (code B ref 72686); Sun, 22 Sep 2024 02:29:01 +0000
Received: (at 72686) by debbugs.gnu.org; 22 Sep 2024 02:28:15 +0000
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>
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-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

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72686: Impossible to remove all offload machines
Resent-From: Ian Eure <ian@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sun, 01 Dec 2024 19:06:01 +0000
Resent-Message-ID: <handler.72686.B72686.173307994910010 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72686
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org
Received: via spool by 72686-submit <at> debbugs.gnu.org id=B72686.173307994910010
          (code B ref 72686); Sun, 01 Dec 2024 19:06:01 +0000
Received: (at 72686) by debbugs.gnu.org; 1 Dec 2024 19:05:49 +0000
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>
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-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

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72686: Impossible to remove all offload machines
Resent-From: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 02 Jan 2025 15:03:02 +0000
Resent-Message-ID: <handler.72686.B72686.173583014921428 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72686
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Ian Eure <ian@HIDDEN>
Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org
Received: via spool by 72686-submit <at> debbugs.gnu.org id=B72686.173583014921428
          (code B ref 72686); Thu, 02 Jan 2025 15:03:02 +0000
Received: (at 72686) by debbugs.gnu.org; 2 Jan 2025 15:02:29 +0000
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>
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-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

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.