From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id iGJ+DzurumWsNQEAqHPOHw:P1 (envelope-from ) for ; Wed, 31 Jan 2024 21:19:07 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id iGJ+DzurumWsNQEAqHPOHw (envelope-from ) for ; Wed, 31 Jan 2024 21:19:07 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1706732347; 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; bh=fUbzr8YmFUNPAtMl+EHvPvRcpGch4N6zzMtv0uS/GTY=; b=ARJ55a1hvDcS/2odzLt+674QJjUvoiU8cKh9rAhgitCNwkvpmCgT2ypIPqO5P5cYZuoK4K nboY4nkM4kpXmoKLqozZW1hCiLW5S/BCmzAYIqFicjORW96VvgtxDJVNwr5RON3TLB/6MI kReZdWLk5W/9aYpt46SrMfdNQvl9VOkjBgYNijZqHZMVD7LM8aMSdmxmxaDAX+YOaNLkqu ocLj0sHPe9VFaseo2x5XHLcRs/jxvQ7KC4r9O5tv0uYsaQUjA9HEu4FpUMmUjWCtitHIsD f0v8VO1tRbcMxlMQ9Zsc0iHll+vHpVLuoXLewu+nTk3/eU8bKBH8AqSf4vYtjw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1706732347; a=rsa-sha256; cv=none; b=j8TOTZuTkdapPIUtnPn0PoJMNUmnHhRe64ttaRlq24SXbFQrGCevkcTR85Bvhz8Jawt8NI isM+ppusMgfSUw6CBuvfzYFmHeifY5r3P4k0RMh8/gs8VEBeC7Ge4iczTHmkYR5YWjaHIN xNQWHQ8j/QWtn4WAofPcnhs3RU3TLcN5CkS3dfSXvC76KKvbzAUYQWCvg0ZhwalU/w7HUE PUrLbmpZn/ViMb+dqMYWepu6r/KACFLlBOjQAOdGnJCNRMhPJcfZbJJI0Y4F+7TtefDxoI UD1lYd5RU4ILhracwF5nNYULCZy/NKRwC393jTyLTYGLoyM8p3iFmOV+pOfXPg== 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 DE02045B0D for ; Wed, 31 Jan 2024 21:19:06 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rVH2b-0004WS-0u; Wed, 31 Jan 2024 15:18:37 -0500 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 1rVH2V-0004VW-Tq for guix-devel@gnu.org; Wed, 31 Jan 2024 15:18:31 -0500 Received: from hera.aquilenet.fr ([185.233.100.1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rVH2U-0006FS-1b for guix-devel@gnu.org; Wed, 31 Jan 2024 15:18:31 -0500 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id D580013B7; Wed, 31 Jan 2024 21:18:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at hera.aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cL3ryvArrcs5; Wed, 31 Jan 2024 21:18:25 +0100 (CET) Received: from jurong (unknown [195.25.40.51]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 3E94B361; Wed, 31 Jan 2024 21:18:25 +0100 (CET) Date: Wed, 31 Jan 2024 21:18:23 +0100 From: Andreas Enge To: Josselin Poiret Cc: guix-devel@gnu.org Subject: Re: Core-updates coordination and plans Message-ID: References: <87h6itzc4a.fsf@jpoiret.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87h6itzc4a.fsf@jpoiret.xyz> Received-SPF: pass client-ip=185.233.100.1; envelope-from=andreas@enge.fr; helo=hera.aquilenet.fr X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -4.01 X-Migadu-Queue-Id: DE02045B0D X-Spam-Score: -4.01 X-Migadu-Scanner: mx11.migadu.com X-TUID: C0yN66qaJJx6 Hello, Am Wed, Jan 31, 2024 at 05:44:21PM +0100 schrieb Josselin Poiret: > One conundrum we have for now: glibc 2.38 has a couple of new CVEs, and > we have three options: > 1) change glibc to track the 2.38 release branch → world rebuild. > 2) graft glibc → bad user experience (and we're not supposed to graft > outside of master). > 3) switch to 2.39 → world rebuild + possibly more work fixing new build > failures. I would go for whatever fixes the security problems (obviously) and leads to a faster merge. Probably 1), which, if I understand correctly, means using a newer point release or git commit of glibc-2.38 that fixes the CVEs and has a low chance of fundamentally breaking things. Then in the spirit of feature branches, we could have a feature branch "core-team" (not "core-updates"!; well, I do not care about the names, but about the mental idea we attach to them) updating glibc. 2.39 might delay the merge for more months if things do not go well, but you are probably better placed to judge how big the risks are of a lot of breakage. I am also not that worried about world-rebuilds: We should be able to do a world-rebuild not once or twice a year, but at least every month, say, or maybe every week. If this is not the case currently, it is an infra- structure problem that we should try to address. (Relatedly, we should ungraft more often; there are now packages with over 100 grafts, and in updating the system behind a fast internet line, grafting ends up taking a non-negligible proportion of the total time, even on an SSD.) In any case, thanks for your work on getting things in shape! Andreas