From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 29 06:56:43 2022 Received: (at 42162) by debbugs.gnu.org; 29 Sep 2022 10:56:43 +0000 Received: from localhost ([127.0.0.1]:36178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1odrDa-0002Wk-4V for submit@debbugs.gnu.org; Thu, 29 Sep 2022 06:56:43 -0400 Received: from mail-wm1-f41.google.com ([209.85.128.41]:33553) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1odrDN-0002VU-6z for 42162@debbugs.gnu.org; Thu, 29 Sep 2022 06:56:29 -0400 Received: by mail-wm1-f41.google.com with SMTP id ay7-20020a05600c1e0700b003b49861bf48so3624680wmb.0 for <42162@debbugs.gnu.org>; Thu, 29 Sep 2022 03:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=hA7w8HF83FTq6pzoqhRkdgr9aPXopNb3JJvRUHMg/N4=; b=WlM38GCKbFkkLgThd6ztyJSljFX1An+PBaYi1AcdeDcRgD2Y3wwh4S6xb09TKofI0Z Pf2Y95lhD5WQCqE36FVR4m2kRQ/Iqt3UZ7P+Z9UdFnM7ZIXn/Z17ntar9gQ7BuMQ7ROT PjGvzelfBS3CwQzteAvEPXiXbyDNkuNH+Xh3T/vLPh6l0cDCS6BB9xdwwlsqCkaGCeOF Fxrc6OjxhzNfEy0jQ7pqZ+h/Sve+Wb621E1werz4cUbjbcd0ptzBu5KglblFtu4VzEXy N6asOX1fs1Q1Hu2wV/nPlr2HkeI+7XyDlg+FSC6bzmgfn7rPrLvzynF3Cbc8Jhm+6Cx3 zCEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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; bh=hA7w8HF83FTq6pzoqhRkdgr9aPXopNb3JJvRUHMg/N4=; b=NlhgTD12Nz5w/lPuMX16DqH/OtShY5oPT/o88Dc42mESRMKMm6bh2MltrBB5iuqkgM ucnUOgS3gLY58VP6TO86YMhmFYV0e0vOeAM9d8o/ckXcXKR3LiiaC7qhJe7A7Z5W4Bef CGUENBaWJV+nouWFtpnC2xFCMjlLiruUn52kOIOJaTUuU3oFOrmKHEAQImU6hxiJboP9 6uUTBkSGNnLa6aWLPS7AvnabVoA8nff1P7hiomPztQ2iytWR1teBdwQTSmKpHjqkAeo7 m3+169z6l/aAaXyA0UKK/taXp5hrfqTo9zCM/T+T5odCglFUlIYJROAPeCECrmIlSQZX T5HQ== X-Gm-Message-State: ACrzQf2s3Hmdbb/GfdsJ8hkK2W5pNJG3Q3m/Nrh1GBsU/QrQhkkZuIfY RaWQMFhNsGfOPlPCOx0cdJU= X-Google-Smtp-Source: AMsMyM6l09FZ2/9bcM3waL7Gh6+r1lzzMP89K8sBDjpYZc/uhYagKE5Lvf9exJfllgbiGcwdqywO0w== X-Received: by 2002:a05:600c:3585:b0:3b4:a308:1581 with SMTP id p5-20020a05600c358500b003b4a3081581mr10425885wmq.77.1664448979497; Thu, 29 Sep 2022 03:56:19 -0700 (PDT) Received: from pfiuh07 ([193.48.40.241]) by smtp.gmail.com with ESMTPSA id i7-20020a5d5227000000b0022abcc1e3cesm6792650wra.116.2022.09.29.03.56.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Sep 2022 03:56:18 -0700 (PDT) From: zimoun To: Maxim Cournoyer , Ludovic =?utf-8?Q?Court?= =?utf-8?Q?=C3=A8s?= Subject: Re: bug#42162: gforge.inria.fr to be taken off-line in Dec. 2020 In-Reply-To: <87o7uzow93.fsf_-_@gmail.com> References: <87mu4iv0gc.fsf@inria.fr> <86h7uq8fmk.fsf@gmail.com> <87d05etero.fsf@gnu.org> <87r1tit5j6.fsf_-_@gnu.org> <875za4ykej.fsf@ngyro.com> <87bljvu4p4.fsf@gnu.org> <87d047u0l3.fsf@ngyro.com> <87wo2dnhgb.fsf@gnu.org> <874kpgudic.fsf@ngyro.com> <87pn4ucy94.fsf@gnu.org> <87y2jint6k.fsf@ngyro.com> <87eel983u0.fsf@gnu.org> <87o7uzow93.fsf_-_@gmail.com> Date: Thu, 29 Sep 2022 12:56:11 +0200 Message-ID: <87edvu30vo.fsf@gmail.com> 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: 42162 Cc: 42162@debbugs.gnu.org, Timothy Sample X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Maxim, On Wed, 28 Sep 2022 at 20:32, Maxim Cournoyer w= rote: > Can this issue be closed? This =E2=80=9Cmeta=E2=80=9D bug raises 2 levels of issues for long-term: 1. save the source code, 2. save the current binary substitutes. For #1, we have now a roadmap to tackle this via Disarchive or sources.json and SWH [1,2]. Therefore, this point of the =E2=80=9Cmeta=E2= =80=9D bug can be closed. However, about #2, we do not have a roadmap, AFAIK. For instance =C2=ABSubstitute retention=C2=BB [3] is still an issue. The recent outage = of Berlin exemplifies the potential problems. (Note that because of energy troubles in Europe, I do not exclude some potential short blackout or power outage for short period of time of the Berlin server.) Why kept binary substitutes? For instance, it is not possible to rebuild some packages on modern CPU; see OpenBLAS [4]. Therefore, waiting a better solution, it appears to me a pragmatic solution to keep as much substitutes as we are able to. We do not have a clear policy between Berlin and Bordeaux. 1: 2: 3: 4: > Otherwise, what remains to be acted upon? The next action for this #2 is to address what I sent on guix-sysadmin about duplicating the storage of binary substitutes in some machine offered by INRAe / Univ. of Montpellier. And we need to draw a roadmap to tackle this #2. Then, this =E2=80=9Cmeta= =E2=80=9D bug could be closed, IMHO. Cheers, simon