From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id yBClHauzTGc1LAAAqHPOHw:P1 (envelope-from ) for ; Sun, 01 Dec 2024 19:06:19 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id yBClHauzTGc1LAAAqHPOHw (envelope-from ) for ; Sun, 01 Dec 2024 20:06:19 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=retrospec.tv header.s=fm3 header.b=GtHhojuq; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="b 7GmTiW"; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1733079979; a=rsa-sha256; cv=none; b=qZ8iNMQO0aFrgFCthUAqzQshaYhE1laeGGgNUu/xNYqAA2sFvSTe24jCL7RXqyAggwXgCP i05J9SRcMTJSdKEB6Sh+lyG8b4lc04A97/dA16v+UeaqDqAGTC98mBnPsEhQrmDQ3weM1s 1+i4c+5uVysIg2cRLuZMS9dusKJsl4a9vuvRhJsSZ9hw8Yp6zYUnnRMlGTNffJNu1eK0+L /Ati+UknnL38VHiNKs+xpe+zfPHjOr/G7UEOyxH0P2khSayQqrmirmZpCwcQzLmXintGHQ edOfirFoAmC27GZTbkysVIb4rQMZyCXXF2RNFGzhdX/weG+FV+qXlZCu6QBbHA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=retrospec.tv header.s=fm3 header.b=GtHhojuq; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="b 7GmTiW"; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1733079979; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=oQK/Zd7YVv2wFjXmRDDo6rYnWy/f47rdttwig6JaCx8=; b=pK9KI76FpO4qWiYhAibAxqdLEI2DvIv8gz3bLSvsPRV0KwwK+SHkIWbyaVhJBziTTO+9Yw OHUlB5QwZhpiIJaX1NRW2Zae/kKYihu1PBBSVhrmLhDReX6j2TlZ3gy2MJ1ocRgtpGrviP PdmwuQAgAN6mxi7+xH92+xU47qO1aZmk5jGXXBmaNgNa05fZcrUQYaNJ+wZe7m9+3qeBYY Dby7V8jFB3k8ALB63bs2IuHLeK0zLqROuvaI9w7nRccYjX0PcCaykRQL11GzS0EXn3BxmF N/O4oU/SZwmHSOqBwdz8AZKZlQ4vnx4L2LtdeyoIu463xT6+X8fUkQgq0je67Q== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3C67318F5C for ; Sun, 01 Dec 2024 20:06:19 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tHpGN-0002oB-UN; Sun, 01 Dec 2024 14:05:47 -0500 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 ) id 1tHpGL-0002nq-KR for guix-devel@gnu.org; Sun, 01 Dec 2024 14:05:45 -0500 Received: from fhigh-a8-smtp.messagingengine.com ([103.168.172.159]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tHpGJ-00053r-B9 for guix-devel@gnu.org; Sun, 01 Dec 2024 14:05:45 -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: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrheejgdduudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvvefujghffgffkfggtgfgsehtqhertddtreej necuhfhrohhmpefkrghnucfguhhrvgcuoehirghnsehrvghtrhhoshhpvggtrdhtvheqne cuggftrfgrthhtvghrnhepveeuleeugedujeeukefhhffhlefgjeehfeffhefgffelkeev keeutdegkeelgeffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepihgrnhesrhgvthhrohhsphgvtgdrthhvpdhnsggprhgtphhtthhopeefpdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopehguhhigidquggvvhgvlhesghhnuhdroh hrghdprhgtphhtthhopeejvdeikeeiseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepmhgrgihimhdrtghouhhrnhhohigvrhesghhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: id9014242:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 1 Dec 2024 14:05:39 -0500 (EST) From: Ian Eure To: Maxim Cournoyer Cc: 72686@debbugs.gnu.org, guix-devel Subject: Re: bug#72686: Impossible to remove all offload machines In-Reply-To: <87setsmnj2.fsf@gmail.com> (Maxim Cournoyer's message of "Sun, 22 Sep 2024 11:26:41 +0900") References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@gmail.com> <87plp560ji.fsf@meson> <87setsmnj2.fsf@gmail.com> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Sun, 01 Dec 2024 11:05:37 -0800 Message-ID: <87ldwzmdfi.fsf@retrospec.tv> 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.159; envelope-from=ian@retrospec.tv; helo=fhigh-a8-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_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -2.40 X-Spam-Score: -2.40 X-Migadu-Queue-Id: 3C67318F5C X-Migadu-Scanner: mx12.migadu.com X-TUID: /Oz7y6y5TRQT Hi Maxim, Maxim Cournoyer writes: > Hi Ian, > > Ian Eure 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