Received: (at 72686) by debbugs.gnu.org; 2 Jan 2025 15:02:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 02 10:02:29 2025 Received: from localhost ([127.0.0.1]:46064 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tTMiS-0005ZX-Pr for submit <at> debbugs.gnu.org; Thu, 02 Jan 2025 10:02:29 -0500 Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]:48456) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <maxim.cournoyer@HIDDEN>) id 1tTMiQ-0005ZJ-SK for 72686 <at> debbugs.gnu.org; Thu, 02 Jan 2025 10:02:27 -0500 Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-21a1e6fd923so112758155ad.1 for <72686 <at> debbugs.gnu.org>; Thu, 02 Jan 2025 07:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735830140; x=1736434940; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=CNQjrJkzX1FuBu3p5939S8w4U/LL+jZIjjl3judO9/w=; b=fhA9h8Qaw7yQhPQoNfRFDdrJEVkOfee04I1WVEkuhQcOWD2Mavi5XXd5KFNKOUTa+F f9C2JWSh22eUUSo/n7f8cc4C1GJO7gkEE78EnBKbzGfeZAfdYH4ZFzF4huMyaKGdQSvZ cQut9571TBiupxVgO1wcGDAiwjOf2zwc5mOehfmWxdTRsm+J0g6D8ZQno8sd9qrCfwHW jd3HlcIGVEVL2tW9CG0DAEjWu4oruIGFq6MlgtfTfzvTbshEJa8+fMF8AZFX8dD5Z+55 C9A60M7XrvCgCkJ3cLB+BjiGKSEnJ3YplY182cs8ONIL+A9yLHYacxUaXpk0TIwDvN6c s1GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735830140; x=1736434940; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=CNQjrJkzX1FuBu3p5939S8w4U/LL+jZIjjl3judO9/w=; b=jueWpTi+XRU+H4GMHaGKP+YaiPV1A6IcZyoM6BO+4PhQDMRnmwgM9j4S275FV0P1NR UVxGZbiwyMnPDUwGBiC38r98i3rr6IaTvSl3Ic24xuoYYI6CyQgFb5hvk1Jkan9TEbHP UUtg0EjrTLRHCi1nYPX15jKtFGkcB4wp8veBmn0AeX/MK2cn0ulkpI8gvOCcFQWJS12S Y+UXjwthNzxxpyVN1gHNq65tUBoALQuQCCXL0Zd1LVAZgDAotJA3v+QBR94KMHRecqh7 NdFw/JaFBjryiZZBP27Un9M9mqbKK4QQtYcojziupau4HYOooeLRxd2QRLi3ITxjlT7e gHHA== X-Forwarded-Encrypted: i=1; AJvYcCUbKBTtQ6fYMvQRoIsGrsNozhEOC1Dg7uw1TXrdVkCORyNoCPBO5G6qJj1G8Z9tztSLRLLDng==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyN2WEyi3Aj6W+YZ7oM98UO1BSwDdo/otwaqTxLNosO4sm1BC42 JLO/57bz0rEjqt/nvOXhFoz52v0pB/TEXzpd1QKOgJbk0xmh+X39+r5mZukf X-Gm-Gg: ASbGnctEiFxFZ8y/o+Cyche0aGY/1f11EnR/mWf8srdUQ2aVHVYUu/XdHzgBZEF7UJf sWX7N46nKgM2bswbBNAZcRMyNAw+AEtlfnprvsSu7O3vG5qgJU4KzlT1rojGEmkq+XvTai53JYj W8WgO2lP0MpMnJPS/tVWFFqiD2GQDvlQ0VBiQTy7LG0a/UcNBqqBS18uPyE8t6pwZWvWPNa/3YD MBXShkz4oo6n9h1fWxSpA55dOsbtPCKb25m0nUHOtQQGxb3DGWW0A== X-Google-Smtp-Source: AGHT+IHUe2+DNgGP2wPqeDm/7v7017cKSlOwqaDaaDx8uVucGSG8qz/JPBMvEbo2d2o8Fvx64dMxZg== X-Received: by 2002:a05:6a21:339e:b0:1e1:c1a7:67ef with SMTP id adf61e73a8af0-1e5e07ef6b2mr74687361637.30.1735830140100; Thu, 02 Jan 2025 07:02:20 -0800 (PST) Received: from terra ([2405:6586:be0:0:c8ff:1707:9b9:af89]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72aad83616asm24472616b3a.76.2025.01.02.07.02.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jan 2025 07:02:19 -0800 (PST) From: Maxim Cournoyer <maxim.cournoyer@HIDDEN> To: Ian Eure <ian@HIDDEN> Subject: Re: bug#72686: Impossible to remove all offload machines In-Reply-To: <87ldwzmdfi.fsf@HIDDEN> (Ian Eure's message of "Sun, 01 Dec 2024 11:05:37 -0800") References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@HIDDEN> <87plp560ji.fsf@meson> <87setsmnj2.fsf@HIDDEN> <87ldwzmdfi.fsf@HIDDEN> Date: Fri, 03 Jan 2025 00:02:09 +0900 Message-ID: <87wmfd45u6.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 72686 Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hi Ian, Ian Eure <ian@HIDDEN> writes: [...] > Apologies for the silence, life stuff has been eating most of my free > time, but I have a bit of bandwidth to spend on this problem again. As you can see, you are not alone :-). > I took a swing at this, it wasn=E2=80=99t as difficult as I expected. Whi= le > this approach gives a smooth upgrade path for those who=E2=80=99ve config= ured > channels in a stateful way switching to declarative configuration, > it=E2=80=99s possibly bumpy for those already using a declarative config.= If > a machine with declarative channels is reconfigured, the channels will > be duplicated from /etc/guix/channels.scm to > /etc/guix/channels-declarative.scm. Using `delete-duplicates' on the > merged channels should avoid major problems, but I think it still > needs a loud entry in news and manual action (deleting > /etc/guix/channels.scm) to upgrade. Given that both approaches will > require manual action, I=E2=80=99m a bit inclined to go with the simpler,= and > take over the existing file. That said, I think the failure mode of > the simpler approach (stomping on channels a user may have configured) > is undeniably worse than potentially duplicating channels or > continuing to pull in old ones unexpectedly. Do either of you have a > strong opinion or more information which would help guide this > decision? I still like the option to leave a handcrafted channels.scm alone; I don't think this imperative variant will be obsolete in the future; it's still useful to experiment quickly, avoiding costly reconfigure just to change some bits about a new offload machine. > The root issue at work behind all these problems is that activation > code only sees the desired target config, rather than the current and > target configs. Comparing the current and target configs would allow > the code to more precisely compute the needd change to move from one > state to the next. I think that could be a good change to make, > though it=E2=80=99s obviously going to be much more involved, and IMO will > require discussion outside the scope of this specific bug. The activation is just a script, so if it's useful to check the current value, it should be OK to do so. > I have a draft patch series I hope to send up soon, but need to get > Guix System up in a VM to test first. It does separate declarative > channels into their own config, but doesn=E2=80=99t do the same for build > machines. While I think many fewer users configure build machines > than channels, it=E2=80=99s probably a good idea to use the same approach= for > both channels and machines. Yes, it'd be nice to have a uniform approach. The acl file could benefit from the same treatment, I believe (that, and 'guix authorize' should validate that we're not adding the same key multiple times -- warn something along "key XXXX is already authorized". --=20 Thanks, Maxim
bug-guix@HIDDEN
:bug#72686
; Package guix
.
Full text available.Received: (at 72686) by debbugs.gnu.org; 1 Dec 2024 19:05:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 01 14:05:49 2024 Received: from localhost ([127.0.0.1]:53092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tHpGP-0002bM-6h for submit <at> debbugs.gnu.org; Sun, 01 Dec 2024 14:05:49 -0500 Received: from fhigh-a8-smtp.messagingengine.com ([103.168.172.159]:37371) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <ian@HIDDEN>) id 1tHpGM-0002b3-Ex for 72686 <at> debbugs.gnu.org; Sun, 01 Dec 2024 14:05:47 -0500 Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id D4E3D11400BE; Sun, 1 Dec 2024 14:05:40 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Sun, 01 Dec 2024 14:05:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1733079940; x=1733166340; bh=oQK/Zd7YVv2wFjXmRDDo6rYnWy/f47rdttwig6JaCx8=; b= GtHhojuqbjDe/XyC0MrBpsSIcV4ersYXIjDV0/qOomuzubYr0ilI8Oya7NqHKabP 4NMwuOCdPxqQ2j6saCoA4R3OjRXj+lEZ0blffi+9NJJM7gKtVKkZCCYkfrhlEpS1 7dsP7IOpAbB+jeWP5xRFxz9CdCqVAU8O/kUVt6TgLd1iqgG0IC26OavzHIOl1cts UzYVd+bI/VGdhXUdSR81gWLlX2bjV3TI3EuAresZa2qo6OG031H/nnoYuXTzDxHr t9o05CWcoqBcCFwdenstH0uKfCNYBh0/flfHHxe8Mjdg0CUU3s9A3pK0Y9D/BuVB xz5JLvtcQoYHEN5pZuTJfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1733079940; x= 1733166340; bh=oQK/Zd7YVv2wFjXmRDDo6rYnWy/f47rdttwig6JaCx8=; b=b 7GmTiWtbNFc/XA7XmtJVdxJo6O2Vxx3a/tNj+1DKeXZZvhLOaZccFnP3RXFXy+XB BTvSkGqcoPepJxDUfNzAXepir546a6uz3aM54D6jR3UVBHZ5fkbCEBtqoiL7PDBE jZNBzdhxguqJnh3d+gzSmPaZEaybtTbfEXg7L+wvH/RY88jRR3RGhkRomljqw3ts FyHk3+c+U2tAOWxLpD4wTecggEo5yPcgWrZWAldq8GShkFTygNLBtnZUE9VfEW9X aWnkjy0y5mrGhbDo1pHMne37mHAcceK6kSGG8bH3k9fWU9wm2YNHl00xJxqlOv7A /v16tsSD1y3DinDtOXLbg== X-ME-Sender: <xms:hLNMZ6wpTdvscVPpHolsrHc6HLQzKtKSX-JCxW7rOsyeztm_zq212Q> <xme:hLNMZ2Ri0Y3srB4DnExpF-N_mNiDizvBV90heHDJm3lN6tITV0aVCa2nzeRRDPWdF uadiLK_ZovaZFwTBw> X-ME-Received: <xmr:hLNMZ8UUHeQY8PFxEJ4k4vo8a-yzZpiiNRv67H8HMYsgHO4zegw-Yid8ydgG7itnMx32AEXluhzeBnxXSvsZ2Z082gZk2u-DoQoCwzU> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrheejgdduudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvvefujghffgffkfggtgfgsehtqhertddtreej necuhfhrohhmpefkrghnucfguhhrvgcuoehirghnsehrvghtrhhoshhpvggtrdhtvheqne cuggftrfgrthhtvghrnhepveeuleeugedujeeukefhhffhlefgjeehfeffhefgffelkeev keeutdegkeelgeffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepihgrnhesrhgvthhrohhsphgvtgdrthhvpdhnsggprhgtphhtthhopeefpdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopehguhhigidquggvvhgvlhesghhnuhdroh hrghdprhgtphhtthhopeejvdeikeeiseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepmhgrgihimhdrtghouhhrnhhohigvrhesghhmrghilhdrtghomh X-ME-Proxy: <xmx:hLNMZwhCioEue_SkFzjUJpEFxYCKArP_Hgc2dVwuuXnUeC8dXiC0_g> <xmx:hLNMZ8AR1WpNiIAiFCxW06jiDSLJnJ86rrUCeFRqtJXcPM3Zvvvhkw> <xmx:hLNMZxKrkUg3q9zf1Z8tahgh9q1Fp_tawvg2QVd9uhN5VlboBCR0MA> <xmx:hLNMZzCU7YhNcHwU_Ar2-87HvuBgRQuT_8_f1swhszsbHLLvCn4uPA> <xmx:hLNMZ_OgSaFuU9j9OeCnK0qjOj3DguooB-HkzYiNuyejJ_lTsVdc1-74> Feedback-ID: id9014242:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 1 Dec 2024 14:05:39 -0500 (EST) From: Ian Eure <ian@HIDDEN> To: Maxim Cournoyer <maxim.cournoyer@HIDDEN> Subject: Re: bug#72686: Impossible to remove all offload machines In-Reply-To: <87setsmnj2.fsf@HIDDEN> (Maxim Cournoyer's message of "Sun, 22 Sep 2024 11:26:41 +0900") References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@HIDDEN> <87plp560ji.fsf@meson> <87setsmnj2.fsf@HIDDEN> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Sun, 01 Dec 2024 11:05:37 -0800 Message-ID: <87ldwzmdfi.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 72686 Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Hi Maxim, Maxim Cournoyer <maxim.cournoyer@HIDDEN> writes: > Hi Ian, > > Ian Eure <ian@HIDDEN> writes: > > [...] > >> The only other option I can see would be to keep the existing >> filenames for user configuration, and declaritively manage=20 >> different >> files -- like declaritive-channels.scm. This comes with its=20 >> own set >> of problems, like needing to update the Guix daemon to read and >> combine multiple files; and the inability to know whether a=20 >> given >> `channels.scm' is declaritively- or manually-managed means a=20 >> bumpy >> upgrade path (ex. should this preexisting channels.scm file be=20 >> left >> as-is, or renamed to the new name?) > > I'd think that be a great option to pursue, although it's more=20 > work more > thoughts. Perhaps it could work along these lines=20 > (brainstorming) > > I like the idea to leave the original, potentially manually=20 > written file > in place and complement it with a declarative counterpart. The=20 > same > would also have benefited /etc/guix/acl, which suffers from the=20 > same > ambiguity. > Apologies for the silence, life stuff has been eating most of my=20 free time, but I have a bit of bandwidth to spend on this problem=20 again. I took a swing at this, it wasn=E2=80=99t as difficult as I expected.=20 While this approach gives a smooth upgrade path for those who=E2=80=99ve=20 configured channels in a stateful way switching to declarative=20 configuration, it=E2=80=99s possibly bumpy for those already using a=20 declarative config. If a machine with declarative channels is=20 reconfigured, the channels will be duplicated from=20 /etc/guix/channels.scm to /etc/guix/channels-declarative.scm.=20 Using `delete-duplicates' on the merged channels should avoid=20 major problems, but I think it still needs a loud entry in news=20 and manual action (deleting /etc/guix/channels.scm) to upgrade.=20 Given that both approaches will require manual action, I=E2=80=99m a bit=20 inclined to go with the simpler, and take over the existing file.=20 That said, I think the failure mode of the simpler approach=20 (stomping on channels a user may have configured) is undeniably=20 worse than potentially duplicating channels or continuing to pull=20 in old ones unexpectedly. Do either of you have a strong opinion=20 or more information which would help guide this decision? The root issue at work behind all these problems is that=20 activation code only sees the desired target config, rather than=20 the current and target configs. Comparing the current and target=20 configs would allow the code to more precisely compute the needd=20 change to move from one state to the next. I think that could be=20 a good change to make, though it=E2=80=99s obviously going to be much more= =20 involved, and IMO will require discussion outside the scope of=20 this specific bug. I have a draft patch series I hope to send up soon, but need to=20 get Guix System up in a VM to test first. It does separate=20 declarative channels into their own config, but doesn=E2=80=99t do the=20 same for build machines. While I think many fewer users configure=20 build machines than channels, it=E2=80=99s probably a good idea to use the= =20 same approach for both channels and machines. =E2=80=94 Ian
bug-guix@HIDDEN
:bug#72686
; Package guix
.
Full text available.Received: (at 72686) by debbugs.gnu.org; 22 Sep 2024 02:28:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 21 22:28:15 2024 Received: from localhost ([127.0.0.1]:40523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ssCKc-0008Ka-R5 for submit <at> debbugs.gnu.org; Sat, 21 Sep 2024 22:28:15 -0400 Received: from mail-pg1-f171.google.com ([209.85.215.171]:44204) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <maxim.cournoyer@HIDDEN>) id 1ssCKZ-0008KH-Bo for 72686 <at> debbugs.gnu.org; Sat, 21 Sep 2024 22:28:12 -0400 Received: by mail-pg1-f171.google.com with SMTP id 41be03b00d2f7-7cd8803fe0aso2240805a12.0 for <72686 <at> debbugs.gnu.org>; Sat, 21 Sep 2024 19:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726972004; x=1727576804; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=N9SI7Pg3yuBMQZltor4SApxphSNkR+P3T3paxX3Njko=; b=TAkRQnIlvvdz4DL/Wv1lo8vS+tas6kVM0+ir5Rc4C9Bi1p8uPkiql63+wK4lFB8KgD Wt29n6bJSX+PBo3+h6VqaCcCxBgXTyFHTEzFnogglkYfuOvi3bQK2LelrKToG8AR1Q+U j2aN/csew55JMjVdvg3q8QqkyzBz8bpfoRE96pTInOjjwdoyku/5JAyeVEDTCKPf3oEH EX2cOg6DgRd0LNMZD/x1C3B2Xa7/N82UQheHruw2YEWeU/UEtpVenIwmOqt3qxjBpsap 5PVvL4QR0fZIlx+US/gnFxMQcqnbe3pKioEQiV+Vk0/nScM9rSjVNfKdQQJPb/TbDSht M6Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726972004; x=1727576804; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=N9SI7Pg3yuBMQZltor4SApxphSNkR+P3T3paxX3Njko=; b=tnJmgCz0iT0vCWYzb19zfGN3QuYUS7sDw9uutKH0vQn9qSHx5fkml5sv//aD1cxjJm rLfvPQncMA+VT2ahqO/S4vXSEgvoSyD/imhOw1NIzaV1QCYKste9blF+AU+NYvYddKFX IdgfSI1iEzdRD3jN5VaG6HLT81Gda3QDzLms/9r9IbVupCH5p+jCMsVuV7cinir8y5x7 exAFt9bkC7bWgUEX3pCmKfxdtcEFn1n9EuG4wTLafxU1Znxp25pCFgIww77pFBZFXn0w ZTfxLDzBNFdLrub3mc8zaYyZ4Uxl0avGTrm0BFFXVJCZtl2K0nVfgHU8Q9++tREsta1B nsig== X-Gm-Message-State: AOJu0YxOr3Jt3WFmis5lmC2OrHUB1sbBVnr5b//WMJGGu4ShgY97sqt3 /FeRxxiRuXT96Bzn8tq8c2+VAqrmORCz0boJQBLQeEFMsCNkMTgz X-Google-Smtp-Source: AGHT+IHa/UCwsnxGYYmcN4T5A+bztsBs6rDqv2YAEMAEuinCPrmUH3mO/nFVyKXi6MyHAWFYnqFjAg== X-Received: by 2002:a05:6a20:b598:b0:1d2:eb9d:997d with SMTP id adf61e73a8af0-1d30a8ecd52mr9806089637.7.1726972004253; Sat, 21 Sep 2024 19:26:44 -0700 (PDT) Received: from hurd ([2405:6586:be0:0:c8ff:1707:9b9:af89]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7e69dfadd9esm139012a12.12.2024.09.21.19.26.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 21 Sep 2024 19:26:43 -0700 (PDT) From: Maxim Cournoyer <maxim.cournoyer@HIDDEN> To: Ian Eure <ian@HIDDEN> Subject: Re: bug#72686: Impossible to remove all offload machines In-Reply-To: <87plp560ji.fsf@meson> (Ian Eure's message of "Sat, 14 Sep 2024 20:24:38 -0700") References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@HIDDEN> <87plp560ji.fsf@meson> Date: Sun, 22 Sep 2024 11:26:41 +0900 Message-ID: <87setsmnj2.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 72686 Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hi Ian, Ian Eure <ian@HIDDEN> writes: [...] > The only other option I can see would be to keep the existing > filenames for user configuration, and declaritively manage different > files -- like declaritive-channels.scm. This comes with its own set > of problems, like needing to update the Guix daemon to read and > combine multiple files; and the inability to know whether a given > `channels.scm' is declaritively- or manually-managed means a bumpy > upgrade path (ex. should this preexisting channels.scm file be left > as-is, or renamed to the new name?) I'd think that be a great option to pursue, although it's more work more thoughts. Perhaps it could work along these lines (brainstorming) I like the idea to leave the original, potentially manually written file in place and complement it with a declarative counterpart. The same would also have benefited /etc/guix/acl, which suffers from the same ambiguity. -- Thanks, Maxim
bug-guix@HIDDEN
:bug#72686
; Package guix
.
Full text available.Received: (at 72686) by debbugs.gnu.org; 19 Sep 2024 00:36:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 18 20:36:42 2024 Received: from localhost ([127.0.0.1]:59414 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sr5A2-00079Z-Hh for submit <at> debbugs.gnu.org; Wed, 18 Sep 2024 20:36:42 -0400 Received: from fhigh7-smtp.messagingengine.com ([103.168.172.158]:57101) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <ian@HIDDEN>) id 1sr59z-00079E-3p for 72686 <at> debbugs.gnu.org; Wed, 18 Sep 2024 20:36:41 -0400 Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfhigh.phl.internal (Postfix) with ESMTP id 8D40211400E7; Wed, 18 Sep 2024 20:36:16 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Wed, 18 Sep 2024 20:36:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1726706176; x=1726792576; bh=uDcwwBBu9Ktphl9tHxzUg+qetd5ryO3lBCvoPSf5V5o=; b= UT5ImNIH3zDCveVaLwhK5J2MYSVVgbgIY8nA+GxC5VojYF4Q85AKobv00dpyV2Zm vlhuMpnpYrDdgvMChAWLtRJnESpoJ7ANlZOgoL5KcpcE4YpiAnNDtldpuDgp0Z0X tTl+BsgIAvbLrYFLk2ruRCHePoI74pHSPhDXw5OahsE3ropNjMGqfYva8aTo2Wpc HudrtVF6QRipyVkAag60PLBC4e0GC7rSgGf4XplkL8FXOftSZTdXsuICp4aDJ07o jAr6dKsIBjrEMKjINbX828Q1/9bIW5fIuROdPoAhjDUbyrx6tCDFiI9mLJ9Ji3ZD S2b5pqyIza1J3URVw/yhNQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1726706176; x= 1726792576; bh=uDcwwBBu9Ktphl9tHxzUg+qetd5ryO3lBCvoPSf5V5o=; b=n J9EWPV/1y7K2CKkMChiaQjdWziJU3HOP0HwNYGptxsqPh4XeUlWg/az1ggfvVwzS P1VRJNMvmV3NBPM9dijDpTgbT/3rEGG36U4N3H5O94b+7vfrNIafOlVoaHuplCfd JOyk8cCqojjmf8NlaFMrzrSk1Y7ckB8Fe4Y9slCivT1nh1nlONT/SiCFwmP7oru3 SazsDjG6LlA5B5NO5cp+j5JdF93rAirPBnP2tp3EepZXFCeIs9C1Owg6Ygmf0Co/ djgHWKhlq7RvDUBC4aK2bB33W8hZ16iEQZGiEf5TG2+Dd6gFQNxHSSxopS3UZzAS YjNetWteiw4fClygVJgsA== X-ME-Sender: <xms:_3HrZnp9MiUEn7-Fk3vpvEdu9gD00-Z-ZKv08G1ZJkkWqeLOJ9-HCg> <xme:_3HrZholqfPt0-9fqyIGU3LsG_KgXIuTFNkscAJqMJ__PWUMzuBmI2JpSrGBgRIhl Xp-OCFPFrz-YPxF8Q> X-ME-Received: <xmr:_3HrZkOAsm1GWc0ZO06H5KAG4XK3deEWm3SOAPN_WkX7nfqk0ukK0YOFUgN69AolK-Igm7jJHsRzuownMWAn2qroTUL0DLa5A4g> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeltddgfeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepfhgfhffvvefuffgjkfggtgfgsehtqhertddtreej necuhfhrohhmpefkrghnucfguhhrvgcuoehirghnsehrvghtrhhoshhpvggtrdhtvheqne cuggftrfgrthhtvghrnhephfelvedtieeffffggeeivdeukedutedtveejfffhleeileef heeggfdugfeiuefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepihgrnhesrhgvthhrohhsphgvtgdrthhvpdhnsggprhgtphhtthhopeegpdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopehguhhigidquggvvhgvlhesghhnuhdroh hrghdprhgtphhtthhopeejvdeikeeiseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepmhgrgihimhdrtghouhhrnhhohigvrhesghhmrghilhdrtghomhdprhgtphhtth hopeimseifohhlfhhsuggvnhdrtgii X-ME-Proxy: <xmx:_3HrZq465LCqH4VNIPw9EtsGK1ScJjodK2MHzwUfzDoGbdsenlmrfg> <xmx:_3HrZm4UkZZ7HOU1NI3NyTB5FNkPSLGRmLZi1spgmf28cwx1U2FvGA> <xmx:_3HrZigjby48bvXDEFsdCziXVm-lCHrZ_D5eSUtTolhFpZsTI7ai1g> <xmx:_3HrZo55ZSo83zIFHD8ICIav34JeWQ5IJLi8qbjzZOWvHGbtgsFOnA> <xmx:AHLrZh1sC5asGCacvFeq-JtBIFw9YFwGW2UT7f-WnO8IiUXHhw2t2lcf> Feedback-ID: id9014242:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 18 Sep 2024 20:36:14 -0400 (EDT) References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@HIDDEN> <87plp560ji.fsf@meson> <87ldzt606c.fsf@meson> <875xqwivoa.fsf@HIDDEN> User-agent: mu4e 1.8.13; emacs 28.2 From: Ian Eure <ian@HIDDEN> To: Tomas Volf <~@wolfsden.cz> Subject: Re: bug#72686: Impossible to remove all offload machines Date: Wed, 18 Sep 2024 17:35:30 -0700 In-reply-to: <875xqwivoa.fsf@HIDDEN> Message-ID: <874j6c5vk3.fsf@meson> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 72686 Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Tomas Volf <~@wolfsden.cz> writes: > [[PGP Signed Part:Undecided]] > > Hello, > > Ian Eure <ian@HIDDEN> writes: > >> Disregard this, I continued thinking after sending the email=20 >> (as one does) and >> realized that any managed file will be a link into the store --=20 >> so if the system >> is reconfigured with no build-machines or channels *and* the=20 >> corresponding file >> is a store link, it should be removed; otherwise, it should=20 >> remain untouched. I >> can work with this. > > Will this correctly handle cases where user is managing the file=20 > using > for example extra-special-file? > No, it wouldn=E2=80=99t. > I wonder whether fat-warning approach would not be better. > I think I agree. =E2=80=94 Ian
bug-guix@HIDDEN
:bug#72686
; Package guix
.
Full text available.Received: (at 72686) by debbugs.gnu.org; 15 Sep 2024 19:06:33 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 15 15:06:33 2024 Received: from localhost ([127.0.0.1]:50517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1spuZt-0006qw-2x for submit <at> debbugs.gnu.org; Sun, 15 Sep 2024 15:06:33 -0400 Received: from wolfsden.cz ([37.205.8.62]:52570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <~@wolfsden.cz>) id 1spuZo-0006qj-Rn for 72686 <at> debbugs.gnu.org; Sun, 15 Sep 2024 15:06:31 -0400 Received: by wolfsden.cz (Postfix, from userid 104) id DF3BF3199FC; Sun, 15 Sep 2024 19:06:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail; t=1726427174; bh=b1VriMQo7jgvjQv3yjTx12TWDLIp9gFgmi2KB2BvyLY=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=e7ffUgl28HU73x8s7yBzeGLbOxqZ9I1hSRXMicoKc4UkonSiPeZGFYJ4cXkeZdl3V p7Z8DdrY/jV2a7FjgS7aY8plOC4Z03x5C3MRSNH2oqbIt6z2LMVQeFtqp2FRXzzmCs u0Sx6koL9FTCbBOj17vVymadq2lLWuOSu6I6MfuEapcSZr6/iClZx765aNzHqZH1H3 HwsBN+e1efSfU5xKiFnctUI05HLICsLGc+00aULSCjo+euVSRWNNijn3RJ84GjJQ9x i7zwrPyNHaQ2KrJjvBO9w1s1A9JHFlGD9tYFVJBh+IRwSVQwMbnciXlB3pE0mKttkL FnXpjfdeB/QS1z4HCARLj/RhDhQA8LsWW77dNKqECCqteu3wn5AgaKXuLTW+w3gFxq LUMhwdnE5YsfvnHkm6UdL6cchSEjLnicpYv8Us9SS3Ro3dCJgWB0mHuGFzDcYJikCh nWcmvUTr6pIBW1fk83qfMNAMkkT+2A2phtuLcKxHxAqZ4sLTAKK3fdcrvx+7E6yA5B HSdagVS7R8DnLrH5nkuNhKCBaG0x+8MyVgD5IL39UcNqHf2z7ohbGmVTm0OyCEwftz vpzPPp8fqddPUFzPFGWcGhiHr6OBgqHM7EbaxoR163VT18NP/hdQlJN08q3c6B21e1 G8LXWwyX9IJPxD05+uq4P0D4= X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on wolfsden X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from localhost (unknown [128.0.188.242]) by wolfsden.cz (Postfix) with ESMTPSA id 1D1A7319ED9; Sun, 15 Sep 2024 19:06:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail; t=1726427174; bh=b1VriMQo7jgvjQv3yjTx12TWDLIp9gFgmi2KB2BvyLY=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=e7ffUgl28HU73x8s7yBzeGLbOxqZ9I1hSRXMicoKc4UkonSiPeZGFYJ4cXkeZdl3V p7Z8DdrY/jV2a7FjgS7aY8plOC4Z03x5C3MRSNH2oqbIt6z2LMVQeFtqp2FRXzzmCs u0Sx6koL9FTCbBOj17vVymadq2lLWuOSu6I6MfuEapcSZr6/iClZx765aNzHqZH1H3 HwsBN+e1efSfU5xKiFnctUI05HLICsLGc+00aULSCjo+euVSRWNNijn3RJ84GjJQ9x i7zwrPyNHaQ2KrJjvBO9w1s1A9JHFlGD9tYFVJBh+IRwSVQwMbnciXlB3pE0mKttkL FnXpjfdeB/QS1z4HCARLj/RhDhQA8LsWW77dNKqECCqteu3wn5AgaKXuLTW+w3gFxq LUMhwdnE5YsfvnHkm6UdL6cchSEjLnicpYv8Us9SS3Ro3dCJgWB0mHuGFzDcYJikCh nWcmvUTr6pIBW1fk83qfMNAMkkT+2A2phtuLcKxHxAqZ4sLTAKK3fdcrvx+7E6yA5B HSdagVS7R8DnLrH5nkuNhKCBaG0x+8MyVgD5IL39UcNqHf2z7ohbGmVTm0OyCEwftz vpzPPp8fqddPUFzPFGWcGhiHr6OBgqHM7EbaxoR163VT18NP/hdQlJN08q3c6B21e1 G8LXWwyX9IJPxD05+uq4P0D4= From: Tomas Volf <~@wolfsden.cz> To: Ian Eure <ian@HIDDEN> Subject: Re: bug#72686: Impossible to remove all offload machines In-Reply-To: <87ldzt606c.fsf@meson> (Ian Eure's message of "Sat, 14 Sep 2024 20:53:22 -0700") References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@HIDDEN> <87plp560ji.fsf@meson> <87ldzt606c.fsf@meson> Mail-Followup-To: Ian Eure <ian@HIDDEN>, Maxim Cournoyer <maxim.cournoyer@HIDDEN>, 72686 <at> debbugs.gnu.org, guix-devel <guix-devel@HIDDEN> Date: Sun, 15 Sep 2024 21:06:13 +0200 Message-ID: <875xqwivoa.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 72686 Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello, Ian Eure <ian@HIDDEN> writes: > Disregard this, I continued thinking after sending the email (as one does= ) and > realized that any managed file will be a link into the store -- so if the= system > is reconfigured with no build-machines or channels *and* the correspondin= g file > is a store link, it should be removed; otherwise, it should remain untouc= hed. I > can work with this. Will this correctly handle cases where user is managing the file using for example extra-special-file? I wonder whether fat-warning approach would not be better. Tomas =2D-=20 There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJCBAEBCgAsFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmbnMCUOHH5Ad29sZnNk ZW4uY3oACgkQL7/ufbZ/wamhkw//YdqItJFnhZlRT59t2Ys/apMiyuGuJJml5Gan aMtkn5FFVZQQIU4l6l7RQS/6+N2RJDZ0WtFXpy+c6AZc/y2xA9ib9IIVCpQoTdyK o7yoRXhZfDyNAGrgyCvKywzbUBEqQ9hOuE3CY4uHZvZ7YcpeenA0w13lWk1j0UzY H+1bY/7bS3nXYwx43DKFL3uwwPD6/Kwom6JROO7YoJ6QAh2ppwCsYZqqHc+4Eixb VJM9bowK1hBexviDw3Pg7CA53JurFQQk5UneReempbx/gTOMzrf/T1Ye46Utf0Ys iqajy3rZ4wSfc4tAJRH6Yt/VRvDowWQ9FsV+KyoaseBEm9v9l0kK8EBNHB5kkEQw 327PwJ4eafOgQ+2nwSOccGZIvYiX12hsFm5/uKWw6dwEAY+tWMUlKeT9wbqB9ya6 FhimFHMQw7RjdJ7SRYbuh9KrNUCTI43vI+HsHD1RkovpeeCrlq0e9sPPJgl3LITG XHg6KPt1XUVj9zyEf+BmQaJ6qdS1376NcD79DQ7XWtjMEFj8jvmUmM9fIXCJqwj+ QwvWZ0tU4wPJ5mqhMTzWUsuDBykrEOLYkx89oSBj5C3w9z4zFDy4q+Ki7pH2h2lF X47xWgvCqbo64YJhEPIP0SETkIgVLFn9bbuRY73l/GZ6INSgcF4FQWrNWLxpagD5 DH4XWdQ= =cMRi -----END PGP SIGNATURE----- --=-=-=--
bug-guix@HIDDEN
:bug#72686
; Package guix
.
Full text available.Received: (at 72686) by debbugs.gnu.org; 15 Sep 2024 03:55:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 14 23:55:28 2024 Received: from localhost ([127.0.0.1]:48089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1spgMB-0005OK-WE for submit <at> debbugs.gnu.org; Sat, 14 Sep 2024 23:55:28 -0400 Received: from fout2-smtp.messagingengine.com ([103.168.172.145]:52919) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <ian@HIDDEN>) id 1spgMA-0005O3-MK for 72686 <at> debbugs.gnu.org; Sat, 14 Sep 2024 23:55:27 -0400 Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfout.phl.internal (Postfix) with ESMTP id 24B5D138028B; Sat, 14 Sep 2024 23:55:10 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Sat, 14 Sep 2024 23:55:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1726372510; x=1726458910; bh=1h/utW6wOkJRqw8Bizf49QhCORehXJtr6R9EJuGZni4=; b= sc8CeMOYdJxf+YPFs0f+XSNOJsVKtcia/SJ1Y8qwC9AN/qhDgv4+tIoBEB5053hu 0lUD1LRSOiX+UqfI2zGtl0nsgZaRhAnZO7mUIhnLHSFiNTq2GQXfybZUqWQINRGv UbHKCFanbzZOgfEdQ1syVzYr6COT1TnZjPscEvZbd5ZgexO52DbkeBwdy8JbOd6Z I3oWWt6F7oouhfRkdSYusfVK7DBRpSBM5nupOM2wvFJ2svpoQZWqOqIzfJoL9lt2 eKXCCZ5R7hgXT/YhpJGZ3ZBDKkZVnUaLEIXQN3FUgLeBb6Z7m92DXmBSG13zArhx JRQZBPmbRnsPFGQ3oEyftQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1726372510; x= 1726458910; bh=1h/utW6wOkJRqw8Bizf49QhCORehXJtr6R9EJuGZni4=; b=G VkzdSlsAKrPVIDasMzSTgs2fCea2apJBeQw9lBjmYIkkAtl3NHstJBizKhUAGVfE GILMn8pT9ZsrkEeHE6c94THUPR/PsBqgNWRddxtOM+iFXh7eMOpWPz/pGpbTqxM2 ObwLRcnfJB1KVN5RGsgVWOVP1EC2VXEsX48LVFjfxBel0yS6/CmyjsjfDq4fXl1c sD5rf4EGxoVlen90nPPB6TzmJC6M0Qf9T9qFhZIhnSxOsnFUAnNwigjqvILF2ltm yc2/yzT6n/LEOcIvlzyjOsZkrcp2Q6KEyiGz+u6I2t6ci+4312izoMobOb5Ua8D0 sDGa+FgX97um4RNQsTXGA== X-ME-Sender: <xms:nVrmZimNPuwl6IOAVCR4J0h2fJt6Nl28U4Xbh84maX8kwDTgcn17cQ> <xme:nVrmZp0MN8H2KyDOog5EdgV2HpHB1yOvWn81RTBNGN0Ds_mc1AAFw6b8GLtxu8uXc 7YKnXX0xDTkqlXkXg> X-ME-Received: <xmr:nVrmZgrF4XduFNPm7Rv_APyytsB6l3w4nZmllZHmNL6m80D2GNhJg85NwwoXxSqGk63_z7UugpcAmsUNVJYsS2XIA-qmKEvfWl5V3Q> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudekuddgjeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepfhgfhffvvefuffgjkfggtgfgsehtqhertddtreej necuhfhrohhmpefkrghnucfguhhrvgcuoehirghnsehrvghtrhhoshhpvggtrdhtvheqne cuggftrfgrthhtvghrnhephfelvedtieeffffggeeivdeukedutedtveejfffhleeileef heeggfdugfeiuefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepihgrnhesrhgvthhrohhsphgvtgdrthhvpdhnsggprhgtphhtthhopeefpdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopehguhhigidquggvvhgvlhesghhnuhdroh hrghdprhgtphhtthhopeejvdeikeeiseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepmhgrgihimhdrtghouhhrnhhohigvrhesghhmrghilhdrtghomh X-ME-Proxy: <xmx:nVrmZmlNQ3jqV9yIDnVS_qrXCoN6HiPs6WHUVhTE5vAdXPCsellQ3Q> <xmx:nVrmZg0QRFMQeMi_FWj5mFC-cY1FGxVY2rcWEQAUMnwMbDtcWQtACA> <xmx:nVrmZtsfSS0wG_Otcpjos6iLvz_adi8bTYuMGUZTjYBYcBDU-hcpqQ> <xmx:nVrmZsXjQrXN-deu7lMRBAjLkxSYriEUQYHhc2jOYMSGzfatj9ZUFA> <xmx:nlrmZtyFhcZ4Rz7NrbwW1kRxQeMIdB_WmoKECUX2qDivUtUq_5rxcGJV> Feedback-ID: id9014242:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 14 Sep 2024 23:55:08 -0400 (EDT) References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@HIDDEN> <87plp560ji.fsf@meson> User-agent: mu4e 1.8.13; emacs 28.2 From: Ian Eure <ian@HIDDEN> To: Maxim Cournoyer <maxim.cournoyer@HIDDEN> Subject: Re: bug#72686: Impossible to remove all offload machines Date: Sat, 14 Sep 2024 20:53:22 -0700 In-reply-to: <87plp560ji.fsf@meson> Message-ID: <87ldzt606c.fsf@meson> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 72686 Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Hi Maxim, Ian Eure <ian@HIDDEN> writes: > Hi Maxim, > > Maxim Cournoyer <maxim.cournoyer@HIDDEN> writes: > >> Hi Ian, >> >> Ian Eure <ian@HIDDEN> writes: >> >>> Ran into this issue last week. If you: >>> >>> - Configure some offload build machines in your=20 >>> operating-system >>> configuration. >>> - Reconfigure your system. >>> - Remove all offload build machines. >>> - Reconfigure your system again. >>> >>> ...then various guix operations will still try to connect to >>> offload >>> machines, even if you reboot the affected client. >>> >>> This is caused by a bug in the `guix-activation' procedure: >>> >>> ;; ... and /etc/guix/machines.scm. >>> #$(if (null? (guix-configuration-build-machines config)) >>> #~#f >>> (guix-machines-files-installation >>> #~(list #$@(guix-configuration-build-machines >>> config)))) >>> >>> If there are no build machines defined in the configuration,=20 >>> no >>> operation is performed (#f is returned), which leaves the=20 >>> previous >>> generation=E2=80=99s /etc/guix/machines.scm in place. >>> >>> The same issue appears to affect channels: >>> >>> ;; ... and /etc/guix/channels.scm... >>> #$(and channels (install-channels-file channels)) >> >> Interesting! >> >>> I=E2=80=99d be happy to take a stab at fixing this, but I=E2=80=99m not= =20 >>> certain >>> what >>> direction to go, or how much to refactor to get there. Should=20 >>> the >>> channels/machines files be removed (ignoring errors if they=20 >>> don=E2=80=99t >>> exist)? Should empty files be installed? Should that happen >>> inline >>> in `guix-activation', or in another procedure? Should the=20 >>> filenames >>> be >>> extracted to %variables to avoid duplicating between the two=20 >>> places >>> they=E2=80=99ll be used? >>> >>> If someone would like to provide answered, I would contribute=20 >>> a >>> patch. >> >> I guess the simplest would be to attempt to remove the files=20 >> when >> there >> are no offload machines or channels, in this already existing >> activation >> procedure. Extracting the file names to %variables sounds >> preferable >> yes, if there's a logical place to store them that is easily=20 >> shared. >> > > As I was putting together a patch for this, I realized there=E2=80=99s a > problem: if a user is *manually* managing either > /etc/guix/machines.scm or channels.scm, these files would be=20 > deleted, > which likely isn=E2=80=99t what they want. The current code lets users=20 > choose > to manage these files manually or declaritively, and there=E2=80=99s no=20 > way to > know if the files on disk are the result of a previous system > generation or a user=E2=80=99s creation. Since the channel management=20 > is a > relatively new feature, I suspect there are quite a few folks=20 > with > manually-managed channels that this would negatively impact. I=20 > know > there was some disruption just moving to declaritive management=20 > of > channels (but I can=E2=80=99t find the thread/s at the moment). > > I don=E2=80=99t see an elegant technical solution to this. I think the=20 > best > option is probably to say that those files should *always* be=20 > managed > through operating-system, and put a fat warning in the channel=20 > news to > update your config if they=E2=80=99re still handled manually. > > The only other option I can see would be to keep the existing > filenames for user configuration, and declaritively manage=20 > different > files -- like declaritive-channels.scm. This comes with its own=20 > set > of problems, like needing to update the Guix daemon to read and > combine multiple files; and the inability to know whether a=20 > given > `channels.scm' is declaritively- or manually-managed means a=20 > bumpy > upgrade path (ex. should this preexisting channels.scm file be=20 > left > as-is, or renamed to the new name?) > > I=E2=80=99m inclined to go with the fat-warning option, but am also=20 > thinking > this likely needs some guix-devel discussion. > > What do you think? > Disregard this, I continued thinking after sending the email (as=20 one does) and realized that any managed file will be a link into=20 the store -- so if the system is reconfigured with no=20 build-machines or channels *and* the corresponding file is a store=20 link, it should be removed; otherwise, it should remain untouched.=20 I can work with this. Thanks, =E2=80=94 Ian
bug-guix@HIDDEN
:bug#72686
; Package guix
.
Full text available.Received: (at 72686) by debbugs.gnu.org; 15 Sep 2024 03:47:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 14 23:47:38 2024 Received: from localhost ([127.0.0.1]:48083 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1spgEb-0004u3-Pj for submit <at> debbugs.gnu.org; Sat, 14 Sep 2024 23:47:38 -0400 Received: from fout1-smtp.messagingengine.com ([103.168.172.144]:33217) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <ian@HIDDEN>) id 1spgEX-0004tj-F2 for 72686 <at> debbugs.gnu.org; Sat, 14 Sep 2024 23:47:35 -0400 Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfout.phl.internal (Postfix) with ESMTP id 181EC1380298; Sat, 14 Sep 2024 23:47:16 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Sat, 14 Sep 2024 23:47:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1726372036; x=1726458436; bh=ex8dkWAZlvMAITRwHbuH00/7H1ruJ9I4Fu35mN3XyYI=; b= nzfte8+nKUILLrVicxnBcoICDsYWF9SPAbybtQWYcZp725Y+zfMjQgSI1ikILlRA RjAPd0qB2ZW6ggSBaBsnyzT7FrcssZsx1yr1DIaEqkejuFs17ZglexwZBDyYTcDe jERsuTR6QQeCFOQ+6mS6S4yze0l27X7yHUoHcp31BhhygwHhIGAX0v5PCl+cXHwm LuY10qxJrW4LqOKAXop9iz/l+h/i40ZpcWNvFjv4tiHMVqObb9IqLCwOaIrtdT3u zVB5+3+zuQvjYwy8OqoK7HfnZkTWWHkDrGYcRzcQLAr9PCEfOn5eXyKWf6CYIsCx lm1B++X1TvwoH+g8Pt/tOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1726372036; x= 1726458436; bh=ex8dkWAZlvMAITRwHbuH00/7H1ruJ9I4Fu35mN3XyYI=; b=m Wq1lCLgiuyYQz5LSlcZ53jE6fKGnNzFrYzdlT9LLTD15txSzfCh/cO3M7INTvP5r q94ad8TDWNal2XUptaCFdmQz1oTneSripwg5DrUS86+f/FB3hBgqtv9TUyQY/pzA rYqr8z/5odAf0T0OY8M8rkak7GKqB2J79GbEuMnlvfvR9Mpu8qCTfmYfzEfW8h+/ 7WlMHVZTwg0rnlt3LYpP91UuWgfN0FK6kWKWJqulPhjo+01kWHKe9Hfp4Jp8hiRj Skm38UoFUX4rKoeubp8xH7rOjCGWtTX8B0Hi7U3zNJXZ9Qi6meUIxUtfyw1C9veK 6/ze/MRsGj82bIL+seoeQ== X-ME-Sender: <xms:w1jmZvXi4cEM-pz3gCvgfW3Hx4JoKCGZgNQ33QlBZ47Bfqc1q7S4eQ> <xme:w1jmZnnc53Z9cQ6LuYmKZQ-E9Ijkdi6omfgi6jQF8dOXkDsKR8WZbGmj8RVhIENO9 sgSpC-UooEKvJpaHg> X-ME-Received: <xmr:w1jmZrbtuRXt77XKudI2uu4rdv2F_H1UEY73lNSV6ZSe2vLrUgzb-gXlXm3VG0R5-eGHCiJ1t63q07uqGorQ86XhfUC6JyLhc6gaug> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudekuddgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepfhgfhffvvefuffgjkfggtgfgsehtqhertddtreej necuhfhrohhmpefkrghnucfguhhrvgcuoehirghnsehrvghtrhhoshhpvggtrdhtvheqne cuggftrfgrthhtvghrnhephfelvedtieeffffggeeivdeukedutedtveejfffhleeileef heeggfdugfeiuefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepihgrnhesrhgvthhrohhsphgvtgdrthhvpdhnsggprhgtphhtthhopeefpdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopehguhhigidquggvvhgvlhesghhnuhdroh hrghdprhgtphhtthhopeejvdeikeeiseguvggssghughhsrdhgnhhurdhorhhgpdhrtghp thhtohepmhgrgihimhdrtghouhhrnhhohigvrhesghhmrghilhdrtghomh X-ME-Proxy: <xmx:w1jmZqUmZ4hDPDrliQFJFIWohQ5xJZ06uuGn6rDAETYehtYpG2aEMQ> <xmx:w1jmZpl2A7Nk_H_lgnWFbJq8qbUlTlic8zIeYGU237imObYJ-tqGGw> <xmx:w1jmZneR-dgaGTYJcELosOxCO-iUI6BT_OfoDdzpKyUoeOsa2jQd-w> <xmx:w1jmZjFrRVne1yChuAMkcAuR67oeayOKOi7wBX_SYgfXsKXIa8tHiQ> <xmx:xFjmZvgOYM7Mfj-spReKfemB0JgsfovWpn4cVSI0mREL-glVxzDLzuMp> Feedback-ID: id9014242:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 14 Sep 2024 23:47:14 -0400 (EDT) References: <87plq75cbc.fsf@meson> <87zfoaqo7p.fsf@HIDDEN> User-agent: mu4e 1.8.13; emacs 28.2 From: Ian Eure <ian@HIDDEN> To: Maxim Cournoyer <maxim.cournoyer@HIDDEN> Subject: Re: bug#72686: Impossible to remove all offload machines Date: Sat, 14 Sep 2024 20:24:38 -0700 In-reply-to: <87zfoaqo7p.fsf@HIDDEN> Message-ID: <87plp560ji.fsf@meson> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 72686 Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Hi Maxim, Maxim Cournoyer <maxim.cournoyer@HIDDEN> writes: > Hi Ian, > > Ian Eure <ian@HIDDEN> writes: > >> Ran into this issue last week. If you: >> >> - Configure some offload build machines in your=20 >> operating-system >> configuration. >> - Reconfigure your system. >> - Remove all offload build machines. >> - Reconfigure your system again. >> >> ...then various guix operations will still try to connect to=20 >> offload >> machines, even if you reboot the affected client. >> >> This is caused by a bug in the `guix-activation' procedure: >> >> ;; ... and /etc/guix/machines.scm. >> #$(if (null? (guix-configuration-build-machines config)) >> #~#f >> (guix-machines-files-installation >> #~(list #$@(guix-configuration-build-machines >> config)))) >> >> If there are no build machines defined in the configuration, no >> operation is performed (#f is returned), which leaves the=20 >> previous >> generation=E2=80=99s /etc/guix/machines.scm in place. >> >> The same issue appears to affect channels: >> >> ;; ... and /etc/guix/channels.scm... >> #$(and channels (install-channels-file channels)) > > Interesting! > >> I=E2=80=99d be happy to take a stab at fixing this, but I=E2=80=99m not = certain=20 >> what >> direction to go, or how much to refactor to get there. Should=20 >> the >> channels/machines files be removed (ignoring errors if they=20 >> don=E2=80=99t >> exist)? Should empty files be installed? Should that happen=20 >> inline >> in `guix-activation', or in another procedure? Should the=20 >> filenames be >> extracted to %variables to avoid duplicating between the two=20 >> places >> they=E2=80=99ll be used? >> >> If someone would like to provide answered, I would contribute a=20 >> patch. > > I guess the simplest would be to attempt to remove the files=20 > when there > are no offload machines or channels, in this already existing=20 > activation > procedure. Extracting the file names to %variables sounds=20 > preferable > yes, if there's a logical place to store them that is easily=20 > shared. > As I was putting together a patch for this, I realized there=E2=80=99s a=20 problem: if a user is *manually* managing either=20 /etc/guix/machines.scm or channels.scm, these files would be=20 deleted, which likely isn=E2=80=99t what they want. The current code lets= =20 users choose to manage these files manually or declaritively, and=20 there=E2=80=99s no way to know if the files on disk are the result of a=20 previous system generation or a user=E2=80=99s creation. Since the=20 channel management is a relatively new feature, I suspect there=20 are quite a few folks with manually-managed channels that this=20 would negatively impact. I know there was some disruption just=20 moving to declaritive management of channels (but I can=E2=80=99t find the= =20 thread/s at the moment). I don=E2=80=99t see an elegant technical solution to this. I think the=20 best option is probably to say that those files should *always* be=20 managed through operating-system, and put a fat warning in the=20 channel news to update your config if they=E2=80=99re still handled=20 manually. The only other option I can see would be to keep the existing=20 filenames for user configuration, and declaritively manage=20 different files -- like declaritive-channels.scm. This comes with=20 its own set of problems, like needing to update the Guix daemon to=20 read and combine multiple files; and the inability to know whether=20 a given `channels.scm' is declaritively- or manually-managed means=20 a bumpy upgrade path (ex. should this preexisting channels.scm=20 file be left as-is, or renamed to the new name?) I=E2=80=99m inclined to go with the fat-warning option, but am also=20 thinking this likely needs some guix-devel discussion. What do you think? Thanks, =E2=80=94 Ian
bug-guix@HIDDEN
:bug#72686
; Package guix
.
Full text available.Received: (at 72686) by debbugs.gnu.org; 14 Sep 2024 14:57:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 14 10:57:03 2024 Received: from localhost ([127.0.0.1]:47585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1spUCs-0003Vy-Jw for submit <at> debbugs.gnu.org; Sat, 14 Sep 2024 10:57:03 -0400 Received: from mail-pf1-f177.google.com ([209.85.210.177]:51666) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <maxim.cournoyer@HIDDEN>) id 1spUCo-0003VO-N8 for 72686 <at> debbugs.gnu.org; Sat, 14 Sep 2024 10:57:00 -0400 Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-7191901abd6so1271988b3a.3 for <72686 <at> debbugs.gnu.org>; Sat, 14 Sep 2024 07:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726325742; x=1726930542; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=K+WpZdM/apDQ8ZhEEhwOe2mc5PZ2aE3IB0tEzWfVggc=; b=ACf+GakCpknl85i7OpdE4Yk4nQpDA3KJKo2cnY1o6wFy7xrvNMWR+cFLLnzPKp1YHP 4VniBcCbAEvb6an25sggNPdWKA4k8TGFTks2WCkkD1AU48HmJhOhp4/uQ5h+HB2anj94 cG8e+9VC507YeM7FJQXUsCcW4c2T3ys9MyV22lptiM/bK2+EBMcgH+W6BDu3F0GNaH0R DmNKQvhliQ335FxFgIw4ERl1nes4niPSeEVsmWVAVqWGlOOdCkNXs98uh4NDwf5w4Qdc 559eAKikOYdkpY6rli+r0gYoaQOAuqdaY64eJkgrptF89DxXU9bwDxoVVXaaehC9J/bt 2+Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726325742; x=1726930542; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=K+WpZdM/apDQ8ZhEEhwOe2mc5PZ2aE3IB0tEzWfVggc=; b=ZeLOPFe899Nd1ZsJc0R3dGcACAKnXtYaFi31o+L994oGqd50bCKMePj4lRQ5Ghh4VX Xs5mw0g6Wkl0HePt5uM5rcKIhkRZ7mGf1hWVPXoVZ0HzS3F4DRZfjvPpj9+9XjgOHnl9 WGF89dG/fSa/0bukZgGd3j6bo3ATizH4m+qi3QeGxtKlus9NRGMW962umkKD81PbkKBR ElV50VicUw9LyEqXOVqeZPpbfVlz9loqXErOvP7LRlK6NpEPszxQBmV8x/J2f4rj+Hr1 jwJYY5Ch34ue8iEMCkuKfOnMwLE85SuabPDuDCkOdlr04OvuMOS/h1p1U6Q9CpsF329q 2HXw== X-Gm-Message-State: AOJu0YwlTAarInyycY879dZkwsXvtkfsrwdN19+14XY5hzLTEsOg4C0l C6KZlMsq82+m1UYVv+ryLnt4zyv1PTNsOxe6vfBxcysL5fr6KT+p X-Google-Smtp-Source: AGHT+IHQaWOqmdFBOc7kpcoAyUFDBrPzXUWPCDF3EZ/wVfzlbL/ZTZfwdpAojjvs2umHgaECSmN+TA== X-Received: by 2002:a05:6a20:c6ce:b0:1cf:4fa8:49f2 with SMTP id adf61e73a8af0-1d112eb2521mr8749513637.49.1726325742062; Sat, 14 Sep 2024 07:55:42 -0700 (PDT) Received: from hurd ([2405:6586:be0:0:c8ff:1707:9b9:af89]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71944a9cac0sm1078039b3a.43.2024.09.14.07.55.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Sep 2024 07:55:41 -0700 (PDT) From: Maxim Cournoyer <maxim.cournoyer@HIDDEN> To: Ian Eure <ian@HIDDEN> Subject: Re: bug#72686: Impossible to remove all offload machines In-Reply-To: <87plq75cbc.fsf@meson> (Ian Eure's message of "Sat, 17 Aug 2024 09:40:29 -0700") References: <87plq75cbc.fsf@meson> Date: Sat, 14 Sep 2024 23:55:38 +0900 Message-ID: <87zfoaqo7p.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 72686 Cc: guix-devel <guix-devel@HIDDEN>, 72686 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hi Ian, Ian Eure <ian@HIDDEN> writes: > Ran into this issue last week. If you: > > - Configure some offload build machines in your operating-system > configuration. > - Reconfigure your system. > - Remove all offload build machines. > - Reconfigure your system again. > > ...then various guix operations will still try to connect to offload > machines, even if you reboot the affected client. > > This is caused by a bug in the `guix-activation' procedure: > > ;; ... and /etc/guix/machines.scm. > #$(if (null? (guix-configuration-build-machines config)) > #~#f > (guix-machines-files-installation > #~(list #$@(guix-configuration-build-machines > config)))) > > If there are no build machines defined in the configuration, no > operation is performed (#f is returned), which leaves the previous > generation=E2=80=99s /etc/guix/machines.scm in place. > > The same issue appears to affect channels: > > ;; ... and /etc/guix/channels.scm... > #$(and channels (install-channels-file channels)) Interesting! > I=E2=80=99d be happy to take a stab at fixing this, but I=E2=80=99m not c= ertain what > direction to go, or how much to refactor to get there. Should the > channels/machines files be removed (ignoring errors if they don=E2=80=99t > exist)? Should empty files be installed? Should that happen inline > in `guix-activation', or in another procedure? Should the filenames be > extracted to %variables to avoid duplicating between the two places > they=E2=80=99ll be used? > > If someone would like to provide answered, I would contribute a patch. I guess the simplest would be to attempt to remove the files when there are no offload machines or channels, in this already existing activation procedure. Extracting the file names to %variables sounds preferable yes, if there's a logical place to store them that is easily shared. A patch would be dandy! --=20 Thanks, Maxim
bug-guix@HIDDEN
:bug#72686
; Package guix
.
Full text available.Received: (at submit) by debbugs.gnu.org; 17 Aug 2024 16:45:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 17 12:45:10 2024 Received: from localhost ([127.0.0.1]:54883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sfMY9-0006Pr-LC for submit <at> debbugs.gnu.org; Sat, 17 Aug 2024 12:45:09 -0400 Received: from lists.gnu.org ([209.51.188.17]:35804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <ian@HIDDEN>) id 1sfMY7-0006Pj-EQ for submit <at> debbugs.gnu.org; Sat, 17 Aug 2024 12:45:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <ian@HIDDEN>) id 1sfMXT-0003mT-Kk; Sat, 17 Aug 2024 12:44:27 -0400 Received: from fhigh5-smtp.messagingengine.com ([103.168.172.156]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <ian@HIDDEN>) id 1sfMXR-00043W-Nc; Sat, 17 Aug 2024 12:44:27 -0400 Received: from phl-compute-06.internal (phl-compute-06.nyi.internal [10.202.2.46]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 1D3E61150836; Sat, 17 Aug 2024 12:44:23 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Sat, 17 Aug 2024 12:44:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:message-id:mime-version:reply-to :subject:subject:to:to; s=fm2; t=1723913063; x=1723999463; bh=uB 0OgJJey95VxLTIWfMpWol+eMVmioWuFS7+777E324=; b=GUlqBgFO1CxrUETz17 iadRq4Vl6RSNM96fCTXiZWM79NBtfV9NVyvrXCvBYG0Gr4RbmS+F0LVAZDXYJnrD X+Us94pFvhZ3A1Ufl04xfe+qYK7/9N38aSnB4R6YtxEp8W9UjXOApzncl0d2cBJM gnHjtUv0sn1v50l3yiF3LQ/shBxzaJKHuabQdgsbauBTmxfhZzN7jDAXdqXYn8WP uIlcNc71KxjDgFkYd1Yygfncmfpoyz38Da9KVt5RP5yRjlLcVcaN58nSy53kiscO yAHa4PXmgJWgtKLSL1v1HG3gcddCpNjxgJj+CgE68pCV1/KXWYilMVR1hAkIT0eX 84og== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1723913063; x=1723999463; bh=uB0OgJJey95Vx LTIWfMpWol+eMVmioWuFS7+777E324=; b=jIMZjgxIUapL8JqGLUV/aq/L2UXgp wy0Q3t8u0zk5XUFom0wQQmRjf1eyAP4ZDvQbRoMZfg0OfFipoHTVnUXFfYYHBDFu /nFmIjBogID2c68QG9LotN8Bj7OwQjsvgDOcOHcGM/8CGISNFo2fOUXCiVsJL/rS sIPITkO/inpni4e727g5Vr0rYe7E3UNVhJnpWHE3kQ0xAsERkdkRT4m0RgrNVHlf PUUGpAx2NF+HbhZS9QTKBlmyEwqONI/x59cwcu4gpR9BXizlsb2WLUfgFfXXpeKf 3C1BrlUl47Ym1g4Pb/i12xhze//utvb42sH/4jLzSjWamEVBtVP9cOf6w== X-ME-Sender: <xms:ZtPAZgBxRKWXCO4rEZOThvKAz2PBSO84u4tWdaDdPunTqbmepaxMjg> <xme:ZtPAZig5oE-fOozo_OUP41hALPi2HLjzOmZ8RSJss3vtlF0zWeK3_gYx_2javlRjr SjKLp1ZZyVhDADMMw> X-ME-Received: <xmr:ZtPAZjme0jJKYFi5QsvdRp3YX3u7-CkvVwMNqPx_0Btvef-vWgQDpJLQnD_9VJ5krzyqcVBvd86Po8rXjWHh_iHnJLsCT9pKO_A> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddutddguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfgfhvf evufffkfggtgfgsehtqhertddtreejnecuhfhrohhmpefkrghnucfguhhrvgcuoehirghn sehrvghtrhhoshhpvggtrdhtvheqnecuggftrfgrthhtvghrnhepieevveelvdevveetke efkeeggfeftddtvdevuefgueeftdefgefhieduheeuveeinecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepihgrnhesrhgvthhrohhsphgvtgdrth hvpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehg uhhigidquggvvhgvlhesghhnuhdrohhrghdprhgtphhtthhopegsuhhgqdhguhhigiesgh hnuhdrohhrgh X-ME-Proxy: <xmx:ZtPAZmwARG10TPshYySBAfuJcbmHRw5ZdrcQFM-mI26DX3aOyfhNrg> <xmx:ZtPAZlT6KObK7J0WgFEdwHwVdRBi_jx5lEzmyBHFnxW1MR59qvBL8A> <xmx:ZtPAZhaqsO4vvKfmGOxZCKhh6r8dUSDUNgPnLTlrN4UpjoKN6OBArw> <xmx:ZtPAZuTA7awLlLyePsZw0BWKqAHoCRvJr0n3c-zJrEHsiiAyveEzyQ> <xmx:Z9PAZgd-sTVyxCwOFm-VNLEjwM5vSOFybhVLqM3KvnGOQ5Vc-bBlmpCJ> Feedback-ID: id9014242:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 17 Aug 2024 12:44:22 -0400 (EDT) User-agent: mu4e 1.8.13; emacs 28.2 From: Ian Eure <ian@HIDDEN> To: bug-guix@HIDDEN Subject: Impossible to remove all offload machines Date: Sat, 17 Aug 2024 09:40:29 -0700 Message-ID: <87plq75cbc.fsf@meson> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=103.168.172.156; envelope-from=ian@HIDDEN; helo=fhigh5-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit Cc: guix-devel <guix-devel@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.6 (--) Ran into this issue last week. If you: - Configure some offload build machines in your operating-system configuration. - Reconfigure your system. - Remove all offload build machines. - Reconfigure your system again. ...then various guix operations will still try to connect to=20 offload machines, even if you reboot the affected client. This is caused by a bug in the `guix-activation' procedure: ;; ... and /etc/guix/machines.scm. #$(if (null? (guix-configuration-build-machines config)) #~#f (guix-machines-files-installation #~(list #$@(guix-configuration-build-machines config)))) If there are no build machines defined in the configuration, no operation is performed (#f is returned), which leaves the previous generation=E2=80=99s /etc/guix/machines.scm in place. The same issue appears to affect channels: ;; ... and /etc/guix/channels.scm... #$(and channels (install-channels-file channels)) I=E2=80=99d be happy to take a stab at fixing this, but I=E2=80=99m not cer= tain=20 what direction to go, or how much to refactor to get there. Should the channels/machines files be removed (ignoring errors if they don=E2=80=99t exist)? Should empty files be installed? Should that happen=20 inline in `guix-activation', or in another procedure? Should the=20 filenames be extracted to %variables to avoid duplicating between the two=20 places they=E2=80=99ll be used? If someone would like to provide answered, I would contribute a=20 patch. Thanks, =E2=80=94 Ian
Ian Eure <ian@HIDDEN>
:bug-guix@HIDDEN
.
Full text available.bug-guix@HIDDEN
:bug#72686
; Package guix
.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.