From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id AB1/LLDgumJUbAAAbAwnHQ (envelope-from ) for ; Tue, 28 Jun 2022 13:06:24 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id uHhILLDgumLpcgAAauVa8A (envelope-from ) for ; Tue, 28 Jun 2022 13:06:24 +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 6587C3A746 for ; Tue, 28 Jun 2022 13:06:24 +0200 (CEST) Received: from localhost ([::1]:49052 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o6931-00013C-Cx for larch@yhetil.org; Tue, 28 Jun 2022 07:06:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38350) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o692g-0000zS-Ck for guix-devel@gnu.org; Tue, 28 Jun 2022 07:06:02 -0400 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:52054) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o692Q-0000Pv-VI; Tue, 28 Jun 2022 07:06:01 -0400 Received: by mail-wm1-x330.google.com with SMTP id m184so7110895wme.1; Tue, 28 Jun 2022 04:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=4O4Tmqb7nfYK+IbQ9/wFgtSPTq3SntQwTW9VeEZO24g=; b=gf4k3+mdfAKxiYFH3CztD6RGy4lS4KIwIIgLzsnByHoQAAKim9MdVso/qe2BEplss0 DRGOticPDlpX3QC09ObWcrp3JmdGvuP3Q7e5YgYYZa2F+p/n7M6ZQng0PRTAsYxjjYDO 8SCwznYws7YhuUq3Jr6AvE84NfykwbPgQu4cOc9QXuL+0agmuKRpkJZyreWnv575Eync 29Z40hOlp2c/GilmGyzHNlq4yZQN016qz6Ch5hee0Mf+Xd2/7ZWIGvoKjkeur8ynBy33 fIdx3CND1aF0bhG5iOdjMVNXrFk5ZLmsqOzFmKT/R0eqR7vaW4mRj0Y1389DFHI6cFmU w3SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=4O4Tmqb7nfYK+IbQ9/wFgtSPTq3SntQwTW9VeEZO24g=; b=jgQcd8/5SmJzGayM8Nwg448IyALqhABTTfHRUS7I8cGKaCin8+HfYKH7pG+/icvk8q ghjLwzbpOspnuiEK33aWgiB1LsJ8TfnMbYD6hNe0wOFMoCFXSs0F8vIf26LEl1Xk0Fkf A1GmBJgooom5y4v7MhitCC8DvZC4zi8Bar9rz0wJcD1p/gxI2dQgKCqRGAw7eTsK8ut8 /Uu/Gx4KB8OZ9Mq7KsvEsc6qzvYecuRyJ85qE7MerXdAMXBYVk4t/TtR8wuhSlz6/Jgo lFYuZgTqezfehxT6S2jggA8RHUMgfH++ZhtKm99+u+b4zd9wRsNXxOtdsnMJ/Wl0GSFx xAEQ== X-Gm-Message-State: AJIora+SCvJQGULqLQQtSC25WZxZ83Wf/UqMc3zqkqmHSOYdIOdxvrVD TzO4dd+pgGLkZISVz0xz3/ir8hUXPijfJw== X-Google-Smtp-Source: AGRyM1uYcocAWxTDkXb5FVmSHqmwP7HUPdOrec3hnlkcrnQlrrNHkQ3YIaFWg7bX1oD/Xim/wuX6FQ== X-Received: by 2002:a05:600c:2246:b0:3a0:4d14:e9ca with SMTP id a6-20020a05600c224600b003a04d14e9camr8416516wmm.25.1656414343646; Tue, 28 Jun 2022 04:05:43 -0700 (PDT) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id h5-20020a5d4305000000b00210bac248c8sm13348355wrq.11.2022.06.28.04.05.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jun 2022 04:05:43 -0700 (PDT) From: zimoun To: Maxime Devos , Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: Tobias Kortkamp , guix-devel@gnu.org Subject: Re: Dealing with upstream issues In-Reply-To: <6d2b1052b3e63a67c42c4e6ce431b3f1bb4b4605.camel@telenet.be> References: <6d31ff958ec0c75cbba8324a275315d195a54902.1653045472.git.tobias.kortkamp@gmail.com> <87sfntu6ft.fsf@gnu.org> <87r13aifi3.fsf_-_@gnu.org> <6d2b1052b3e63a67c42c4e6ce431b3f1bb4b4605.camel@telenet.be> Date: Tue, 28 Jun 2022 13:01:45 +0200 Message-ID: <865yklf3vq.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::330; envelope-from=zimon.toutoune@gmail.com; helo=mail-wm1-x330.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01 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" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1656414384; 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=4O4Tmqb7nfYK+IbQ9/wFgtSPTq3SntQwTW9VeEZO24g=; b=COKOTByGOAWqJh8phVPprYWrBXRZjGLR1S4Gaw7+ujMS3/2sowpK/1ZZG6QrpbB7deY1jS Nl5bC5dp2HtS24KMhayUfMAfoSpGqNnncCZrK8AJNWQQnMitt7mNElcvmMS/K6mK+gLIMh C6u8LITVrkxVL9Oh7bzp9+pMwuh4Np+5PpT7anuwJcuTlpiF7515y7K36fqNCkFkE2ux4N 55+YrIebJKuAbTEEVetQzlYvTcKMhCVTnoZqodpdD4CLfZsYqvJJAfgzWeGmwHIPdsvSlo IIOGsILPPRhyvmGO3SYZv6Fbtu/p8/Q04537XgUZ0jWtuOmwy+hX63nJX1d8pg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1656414384; a=rsa-sha256; cv=none; b=E0K7oebMmj1cnHxoi0ppNxx/5E4zoX7u3C56u1mi2PydRCuSK/hnT0b3JWdy/Y6ZALBTvI NWcG5IHyBcOXRc4HCpiAVhEa8fbX14AlC8vpv7Xh+uAt2OdRgBvqExOtbodm2SqD28ZNGe ebeu8/vkhDbIFSUTmgRd+ueMJ6BmOUdcOu07EwOpeDu7QflTIIy6ZWRYpcBv0OTAstCKlc UdIbaqAWZu24uG/LJWE6TXz0ZmbAtMrxjNaFRjErOpzh3/hL4h5TQwf/GazzSVq7E7D1NX C3CDj3Kmxr8G3UXOCgT3prpbnLhn+dUxvG8bBXl+G5SzQCIZzZ/scUQUJHuDjw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=gf4k3+md; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Spam-Score: -4.25 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=gf4k3+md; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Queue-Id: 6587C3A746 X-Spam-Score: -4.25 X-Migadu-Scanner: scn0.migadu.com X-TUID: JzjHzXhRNolE Hi Maxime, I am confused by your replies in the thread. Maybe, I miss the topic of the comment by Ludo. Well, from my understanding, the question is: should a perfectly working and fine submission be delayed because unrelated-to-Guix issues are in upstream code? Ludo said these unrelated-to-Guix issues are not blocker, from my understandings. And I agree. Do you disagree? Reading you, I am missing what you are suggesting. You are commenting on =E2=80=9Cstandard=E2=80=9D which somehow asks about e= xplicit criteria. And, you are implicitly commenting on blocking while issues from upstream are not fixed. Instead of trying to deduce myself (and probably the wrong way), could you please explicitly write down your arguments? Do you think that patch#55541 should be delayed while upstream is not supported by cross-compilation? I agree that fixing as much as possible and earlier is the best. However, there is a tension between being perfect and doing with the resources at hand. For sure, it would be better if submitter also report (or fix) upstream some issues, but I am not convinced the Guix project should make this as mandatory requirements for inclusion of submitted packages in Guix. Do you think that patch#55541 should be delayed while submitter has not open an upstream issue? Last, I miss these comments about old bugs and what you are implicitly suggesting with them. Are you suggesting that old unsolved bugs are closed without valid motivation? >> Old unsolved bugs are still open > > Sometimes they aren't: > * https://issues.guix.gnu.org/45828 Closed because: This can happen if guix-daemon was restarted but =E2=80=98guix publ= ish=E2=80=99 wasn=E2=80=99t: =E2=80=98guix publish=E2=80=99 opens only one connection to the sto= re at startup time, and then never tries to re-open it. There was an old bug on this t= opic: https://issues.guix.gnu.org/26705 Back then I marked it as =E2=80=98wontfix=E2=80=99 because: 1. Losing a connection to the daemon Does Not Happen=E2=84=A2 in = normal conditions. Namely, upon =E2=80=98herd restart guix-daemon=E2= =80=99, =E2=80=98guix publish=E2=80=99 is automatically restarted. One situation wh= ere =E2=80=98guix publish=E2=80=99 is not restarted is if one does =E2=80=9Ckill= all guix-daemon=E2=80=9D or similar. (Perhaps that=E2=80=99s something to fix in the Shep= herd?) > * https://issues.guix.gnu.org/26705 Closed because: For now I=E2=80=99m closing this bug as =E2=80=9Cwontfix=E2=80=9D b= ecause I=E2=80=99ve never seen any occurrence of #2, and because #1 cannot happen on GuixSD (if =E2=80= =98guix-daemon=E2=80=99 is restarted, the shepherd will also restart =E2=80=98guix-publish= =E2=80=99. > * https://issues.guix.gnu.org/25719 (exception handling hasn't been clean= ed up before closing) Closed because: I haven't seen this particular exception in a long time. I cannot = tell whether the actual usability has been fixed, though--it could be that only = the servers are more reliable and this code path is thus not currently being en= tered. > * https://issues.guix.gnu.org/44199 (it's a WIP, not completed yet, but s= till closed!) This history is: Maxime Devos wrote on 24 Oct 2020 21:47 zimoun wrote on 27 Oct 2020 14:39 Maxime Devos wrote on 27 Oct 2020 19:50 Maxime Devos wrote on 1 Nov 2020 01:05 Ludovic Court=C3=A8s wrote on 15 Nov 2020 22:13 > This patch defines a `gnunet-fetch' method, allowing for download= ing > files from GNUnet by their GNUnet chk-URI. While I think this is a laudable goal, I=E2=80=99m reluctant to inc= luding GNUnet support just yet because, as stated in recent release announcements, GNUnet is still in flux and not considered =E2=80=9Cproduction read= y=E2=80=9D. So I think we should keep it around and revisit this issue when GNU= net is considered =E2=80=9Cstable=E2=80=9D. WDYT? zimoun wrote on 16 Nov 2020 01:35 Maxime Devos wrote on 18 Nov 2020 20:14 > So I think we should keep it around and revisit this issue when > GNUnet > is considered =E2=80=9Cstable=E2=80=9D. WDYT? Sounds reasonable to me. There are also a lot of missing parts: a service definition for Guix System, findings substitutes, finding sources by hash (the one Guix uses, not the GNUnet hash) ..., so it isn't like my rudimentary patch was usable on large scale anyway. Ludovic Court=C3=A8s wrote on 18 Nov 2020 23:12 tags 44199 wontfix close 44199 quit Therefore, if you have more details for one of these reports, feel free to comment, provide more info or fix; for sure it will help. Cheers, simon