From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id kFl9KkYXAGVghwAAauVa8A:P1 (envelope-from ) for ; Tue, 12 Sep 2023 09:46:14 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id kFl9KkYXAGVghwAAauVa8A (envelope-from ) for ; Tue, 12 Sep 2023 09:46:14 +0200 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 69F35451AE for ; Tue, 12 Sep 2023 09:46:14 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20221208 header.b=AC1BDn4M; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none) ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694504774; a=rsa-sha256; cv=none; b=ZkgiwusVosGK2YGMgDIoY5uIL9yK+AM8J9hSBCdl9DkM3MZHQgs06lob74wCxjC21QEmKO K6KNKN5xRQXNv6s6g9BIU1cShHKGznIwdOcui2rHgLTWm70CSvd4UJuZdJgDoOYEwbnMIv OkleNzpf08I7ft2KW2s3yEefZiaCWTtt8X/+KcoJoX2H+iimdTxbLyqltE/9Xz6v0X1jQl hUH3PO8c7JCs4WE9yvP2Bet0jiIe8FVVSOXSHlJZicWrlGD+MGYp7rg8zemSwcSQM6ghiG bYYy93h6zb/ma3Qf6F8YnCQrA9uJGUFErmWZNU2zNg2ppgxBAqxW6Ze2JV/Ozw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1694504774; 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:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=Yz3XBZRTcACWM401PgmPn0WYMjhUuP9zSKJqioifCu8=; b=Qvooyr479PvdsqeQGaxUdss3cjnyI0cpfD5BQoyVdzIk1E5qWtdDYcKqQd6c2twSguznKO BJ/sCt8fsZoIsJenzDiuw9mGpI/30sgL4Mukenc0gP65FSsNpLojPyjGx4bbP5TTEALbY/ 0CkcW5oN1YLzWECHc1dhETCNfZzFZBx+6ETtpONvkgRvq9AobjTajnzeDSpeC9P2haWR3M CsLb7gS/yanMjzhazBl6zcUbstxlqtrQuw8jlev4ODxTWH4b3SXDfpqRvJA2rY7VcwfZNT wH1H975DOwXFa05B/SeCf8+slxdWSJNKCVk+Zh5EUuQtuaogdQkPH3dNTD4f3Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20221208 header.b=AC1BDn4M; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qfy67-0006xL-9n; Tue, 12 Sep 2023 03:46:11 -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 1qfy5u-0006qX-Sa for bug-guix@gnu.org; Tue, 12 Sep 2023 03:45:59 -0400 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qfy5u-0006o0-HX for bug-guix@gnu.org; Tue, 12 Sep 2023 03:45:58 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qfy5y-0006tj-Hx for bug-guix@gnu.org; Tue, 12 Sep 2023 03:46:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that) Resent-From: Simon Tournier Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 12 Sep 2023 07:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65391 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: "Dr. Arne Babenhauserheide" Cc: Maxim Cournoyer , 65391@debbugs.gnu.org, maximedevos@telenet.be, iyzsong@envs.net, mirai@makinata.eu, atai@atai.org, raingloom@riseup.net Received: via spool by 65391-submit@debbugs.gnu.org id=B65391.169450471226448 (code B ref 65391); Tue, 12 Sep 2023 07:46:02 +0000 Received: (at 65391) by debbugs.gnu.org; 12 Sep 2023 07:45:12 +0000 Received: from localhost ([127.0.0.1]:55997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qfy5A-0006sV-05 for submit@debbugs.gnu.org; Tue, 12 Sep 2023 03:45:12 -0400 Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]:38131) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qfy58-0006sE-3p for 65391@debbugs.gnu.org; Tue, 12 Sep 2023 03:45:11 -0400 Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-401ce65dfc4so16383885e9.0 for <65391@debbugs.gnu.org>; Tue, 12 Sep 2023 00:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694504699; x=1695109499; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=Yz3XBZRTcACWM401PgmPn0WYMjhUuP9zSKJqioifCu8=; b=AC1BDn4MIsNSCRUFxbN75MAr/6OkZ869qH0XMrBoWt0fnJEvHOZe2NzVIPADLCe9Px jJivKKrwJu75wJiitk/uO4KEsWZdlAcN6mik/p3lgUyc6WUUkWiJ9hhN79/YWZGXW1UW 797PqIAX9g+o5IwVir90jo9uLHbohI4N/CZkoE/dWjVt+BC0RB9dVJgb+J3dSq9h0tFI dFNmgxVazyPuE6lh0hY2n3mj8XW2cYfD4Xb9JpJogrTD4e+MsfNkE8D6wexruE5NwdIu nwv4R5UPQQ640MpoxO+GV4YPD+H4ubOqXVYeHkaYBjPY/1pJ0Jj1z28PO+0myJoYJ8XC XprA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694504699; x=1695109499; h=content-transfer-encoding:mime-version: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=Yz3XBZRTcACWM401PgmPn0WYMjhUuP9zSKJqioifCu8=; b=W5Md7cZU+0gWkQVWEa2TgqAfzU1zzpxsaRCpfRvmqX69BYLpqybKUqvTfmEWw8+7O9 Oza2AN91NJhpe8nfVHSC8gmae+9/ewFVLKHqydcvccl+PxfEAHJphbqOCacEjWcJwXYW hLaDhJo7gjzOCTJtI5zJ/Hw4sk6Pywty54ahz2cKxNN83sfxm4CbHQtiXIAhFVVXvadB TGRm+L9Pdeyj4c+zNX45MVdaC5YQNFVedFrr30SmNnggz+9I1AEo07bV2cWZc+sCf3jl LLXULfkkHFwWy+aGvcqzVXCA39WudfAfNnPT6Mk2eZTuM9MMqDgLbqGK5YaXlRMgMM00 hg7w== X-Gm-Message-State: AOJu0YxpITtzZLMXUValBsYikB0d0Rr70MShbcARN7i6mQuglIX/pPWI 9CMtSQChpwSOdFNdSSoul4o= X-Google-Smtp-Source: AGHT+IGh9cZTbXPcc2JEHgQoA+SQUR3E7fuebx+Zq+R6pWho1qTsEpvnZBWiPBuRdG6l4KvChJhISQ== X-Received: by 2002:a05:6000:154e:b0:31f:85dc:110c with SMTP id 14-20020a056000154e00b0031f85dc110cmr8878650wry.0.1694504699207; Tue, 12 Sep 2023 00:44:59 -0700 (PDT) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id d8-20020adf9c88000000b0031ad5fb5a0fsm5700071wre.58.2023.09.12.00.44.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Sep 2023 00:44:58 -0700 (PDT) From: Simon Tournier In-Reply-To: <87v8cg7068.fsf@web.de> References: <295ef8c8-574a-4169-98f3-6d9aaeb773f1@telenet.be> <6a62aced-9138-0496-fb01-d5d8e89ba8d6@telenet.be> <87h6ohc3gk.fsf@gmail.com> <87zg296z7y.fsf@gmail.com> <871qfkg65s.fsf@web.de> <87pm2ukxn5.fsf@gmail.com> <874jk183wx.fsf@web.de> <87fs3kizd9.fsf@gmail.com> <87v8cg7068.fsf@web.de> Date: Tue, 12 Sep 2023 02:39:42 +0200 Message-ID: <86r0n4xm0h.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: bug-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -3.62 X-Spam-Score: -3.62 X-Migadu-Queue-Id: 69F35451AE X-Migadu-Scanner: mx2.migadu.com X-TUID: A1ho1oBizZyh Hi Arne, On Tue, 12 Sep 2023 at 01:12, "Dr. Arne Babenhauserheide" = wrote: > I=E2=80=99m skipping a lot to get only to the most important points (save= time > for us all). Good initiative, let me do the same. :-) > That=E2=80=99s why I wrote the following: > >> If we had a way to have placeholder packages (similar to the renamings) >> that emit warnings for missing packages but do not break the build, that >> would reduce the damage done by removing a package. But I think such a >> mechanism must be in place and tested before adding a rule to remove >> packages. > > This would cause us to collect a slowly growing list of removed packages > that will be ignored (except for the warning) in manifests. > > That way we would avoid breaking the setup when removing a package. > > (define-public-removed the-package-variable > (removed-package > (name "the-package-name") > (reason-for-removal "upstream stopped working a decade ago"))) > Here you are defining a policy: 1. set a rule for replacing the package by =E2=80=99removed-package=E2=80= =99 2. set a rule for effectively removing this package Somehow you are discussing to have a rule to deal with the broken packages. A policy, no? :-) Having a rule to deal with the regular broken packages appears to m= e a good thing and very helpful to keep Guix reliable. Therefore, we agree that making a policy for dealing with broken packages is worth and it would help to have a better Guix. It appears to me better to know what I can expect as an user than to have some surprise after each =E2=80=9Cguix pull=E2=80=9D. I have in mind = the sudden removal of Python 2 packages for instance. With such policy, it would have been smoother, IMHO. That=E2=80=99s said, two minor points that does not matter much. :-) I do not understand your explanations with the manifest because I do not see the difference if one element of your manifest is broken or if this very same element is removed. For the both cases, your manifest is broken, no? From the point of view of the profile generation, broken or removed does not change the result, isn=E2=80=99t it? Broken or removed on= ly changes the process for investigating and try to fix, no? The only case where it could matter is if your manifest relies on package variant. That case, if the package becomes broken, the variant could not be. Well, if that=E2=80=99s the case, I would suggest that you maintain these packages using a plain copy of the inherited package. Because a perfectly working update could break your variant. I mean, if your manifest relies on package variant, then this manifest is highly dependant on the changes whatever the status of the package. In all cases, I share your concerns, and as you, I am time to time bitten by stuff that break. If I am honest, I barely update my base system. Before an update, I carefully check a commit using =E2=80=9Cguix time-machine=E2=80=9D and test that my config works. Somehow I often use t= he command-line =E2=80=9Cguix time-machine -- shell -m=E2=80=9D. On a side note, I am not convinced we will have the resource to change the package definition as your proposing. That=E2=80=99s another story and= it appears to me the part of the discussion for a policy (strategy) for removing packages. I guess. :-) That=E2=80=99s long enough. ;-) Cheers, simon