From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.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 mHVjG81a5mYn5wAA62LTzQ:P1 (envelope-from ) for ; Sun, 15 Sep 2024 03:55:57 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id mHVjG81a5mYn5wAA62LTzQ (envelope-from ) for ; Sun, 15 Sep 2024 05:55:57 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=retrospec.tv header.s=fm3 header.b=sc8CeMOY; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="G VkzdSl"; 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=1726372557; 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=1h/utW6wOkJRqw8Bizf49QhCORehXJtr6R9EJuGZni4=; b=ZEejtAbgGNORuHZuGGN8BeIBkhk48Bot/eZ0HrX/6OQWMKwTXVsY0tG15VAUDwmRgmIUgy jaoOOv7NzkGe8M5YywqZWAsbgbDtvpPLi8lGs+j63++5JV3N5dUUNkgUVRwcg4UXVFNGOg /P0ZhbBaZsUP9taDi91tpmtzMVFf+Fd0eVTmbVEJiLf8XYmq9f28h0Xq544cOc+3E7yTfb PEHJfIiYER9t0DppYTvNNTLzJ3l5sXsMAabjl6JVsrRFDuz8L6yLbHaq2s9RcFfAa9BExf 4PFhUFphisKBmnw1Cl6/dzKScfHVHuctqpQiHLLYf8MQrFzW9fzX3mU2COAirQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1726372557; a=rsa-sha256; cv=none; b=V3JQCrxsjuZgDskOInLMabJHAcvtjFGGcYuK45UerQBleW51Bzh2iFojEcN4h3+69w5Pwh QKo4W8mgw5zjIUMonklu+vZr2G+ax6AMi8kjqQlAowoRHU3nN7spuNrpkycQ5w8qIs8zag fAxl5My7OFR00UHe+YWd7N3wcmRULLpx2lhwb45pCxKLA1YyWZVEvHl8Mw+6PuZwydS68d iG93BOt/53oDpCzFQ9yEvlo72SOVb97GiHx1bpgd1TwPodvLAJ205ipcstfNxHLirff9Bg n7hu42Hxwt55S42r1TQKQnNXpWyYqypZp00Ru0dylE/itNpPF/BFpIYSiDUq9A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=retrospec.tv header.s=fm3 header.b=sc8CeMOY; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="G VkzdSl"; 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 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 1970912AA3 for ; Sun, 15 Sep 2024 05:55:57 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1spgME-0005W1-Bs; Sat, 14 Sep 2024 23:55:30 -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 1spgMB-0005Vp-C1 for guix-devel@gnu.org; Sat, 14 Sep 2024 23:55:27 -0400 Received: from fout2-smtp.messagingengine.com ([103.168.172.145]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1spgM6-0000nm-O4 for guix-devel@gnu.org; Sat, 14 Sep 2024 23:55:25 -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: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudekuddgjeejucetufdoteggodetrfdotf 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:55:08 -0400 (EDT) References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@gmail.com> <87plp560ji.fsf@meson> 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: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 Received-SPF: pass client-ip=103.168.172.145; envelope-from=ian@retrospec.tv; helo=fout2-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-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -9.69 X-Migadu-Queue-Id: 1970912AA3 X-Spam-Score: -9.69 X-TUID: gYjZi6t2rS8X Hi Maxim, Ian Eure writes: > 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 >>> 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