From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id YAVQO/VY5mZs1AAAqHPOHw:P1 (envelope-from ) for ; Sun, 15 Sep 2024 03:48:06 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id YAVQO/VY5mZs1AAAqHPOHw (envelope-from ) for ; Sun, 15 Sep 2024 05:48:06 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=retrospec.tv header.s=fm3 header.b=nzfte8+n; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="m Wq1lCL"; 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"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1726372085; 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=ex8dkWAZlvMAITRwHbuH00/7H1ruJ9I4Fu35mN3XyYI=; b=Uvalk5cdbLiGtF8mgxS4sYel5lj08aEarhQrYA7uKzGb6K++fliKTvsgygGYkA7NeLBROa Dr/nyWmtZmNCD+iA5K1j+QjkyTGWgR2IAaztaCcsZkzJDO3UASXlrMnKxg6WFRmdxHEeRN u1hmHLoO+B3+tomhkMATu3pXLzQdET+fmchEElhWl/RYE40//QZSEOSBST8/33mQ9UqoGt +L5sBFrzWpiswen6WFBcW0cK5QZ6bH0pVvk7iyYE27nJJNLQ14A1dCQml0rada+9vJYheq rf+0Mv6LmgIUp3gFay1GScRwbaZm2urdEX0T8LOjNnfafCQEqi7y6EuYwpWlPQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=retrospec.tv header.s=fm3 header.b=nzfte8+n; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="m Wq1lCL"; 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"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1726372085; a=rsa-sha256; cv=none; b=o/lznIxpwS6cZgendt+DZyW76BLWIX4vhbDqiWU0JbrAWw/vcq+ZNhYDy+M3yvP/Z4f+ZO eGT+H0v0fdOaawUCup+I0jl1eBCAYgOYLj2KCY8azjmIzE0jS15Qn/cueUxB1jltzltuOc fHwMJD94mSS19qLtHBn7DTDj5XXIiu+kywGg3I319mCYXQ5SCHhIQvXAV/C6hJLhL1aUR+ H9b5uRuNLgZgmpMyIf+sqGFCEfJL7jYzYgffKcaQt7izmrXAKtby3qtDg/RXzVOuX8eDsg 3mCpnSC7HGnfF515SzF+3rveox6J6TFazgjZ/Zi/k4KkKjwJWkK67jnZ58W6pw== 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 4A8B37450D for ; Sun, 15 Sep 2024 05:48:05 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1spgEL-0004l0-If; Sat, 14 Sep 2024 23:47:21 -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 ) id 1spgEJ-0004kX-K1 for guix-devel@gnu.org; Sat, 14 Sep 2024 23:47:19 -0400 Received: from fout1-smtp.messagingengine.com ([103.168.172.144]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1spgEH-00006r-F0 for guix-devel@gnu.org; Sat, 14 Sep 2024 23:47:19 -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: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudekuddgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepfhgfhffvvefuffgjkfggtgfgsehtqhertddtreej necuhfhrohhmpefkrghnucfguhhrvgcuoehirghnsehrvghtrhhoshhpvggtrdhtvheqne cuggftrfgrthhtvghrnhephfelvedtieeffffggeeivdeukedutedtveejfffhleeileef heeggfdugfeiuefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepihgrnhesrhgvthhrohhsphgvtgdrthhvpdhnsggprhgtphhtthhopeefpdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopehguhhigidquggvvhgvlhesghhnuhdroh hrghdprhgtphhtthhopeejvdeikeeiseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepmhgrgihimhdrtghouhhrnhhohigvrhesghhmrghilhdrtghomh X-ME-Proxy: 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@gmail.com> User-agent: mu4e 1.8.13; emacs 28.2 From: Ian Eure To: Maxim Cournoyer Cc: 72686@debbugs.gnu.org, guix-devel Subject: Re: bug#72686: Impossible to remove all offload machines Date: Sat, 14 Sep 2024 20:24:38 -0700 In-reply-to: <87zfoaqo7p.fsf@gmail.com> Message-ID: <87plp560ji.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.144; envelope-from=ian@retrospec.tv; helo=fout1-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-Queue-Id: 4A8B37450D X-Migadu-Scanner: mx11.migadu.com X-Spam-Score: -9.06 X-Migadu-Spam-Score: -9.06 X-TUID: l692xomjai1D Hi Maxim, Maxim Cournoyer writes: > Hi Ian, > > Ian Eure 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