From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id 8JGoDGoHTmf5vQAAqHPOHw:P1 (envelope-from ) for ; Mon, 02 Dec 2024 19:15:54 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 8JGoDGoHTmf5vQAAqHPOHw (envelope-from ) for ; Mon, 02 Dec 2024 20:15:54 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="JLJ+2DY/"; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1733166953; a=rsa-sha256; cv=none; b=s7ap4kFZ/L7wP/14fVcdOZUmhvUjzQRJyYrENrKlxLcIw4mjRNPdw9jq1Y1tLZRgnKCHD6 gk+eJ4mLqREb/fUNQCo6D1ocGOYguXU1Xc1JEWxiEXMLmNQNzBpP9pcKY+my6XdCf99ROa 46mkavq9RAawcbnFXdz4VZQDYZbM9PNr44CwuV0UYYRWYrhvjLnwU6KmsidDJjL1CAvWnA 3GI22OH1LlmTCjtHAgZR27a6OtoY/d+IoptU1QIlvCkmmk0KS4RRi+lBfUJgIBHMJYrFvN mn/UELolBmQb4FUvjIcCctDwjxkU261HbBfp0SGdmyPjgIuftMp4vvnJV67qNw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="JLJ+2DY/"; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1733166953; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=eIkJAye41EJMQWQuvLw+lf2CRDAEP5L5NSlQ+P6aGM8=; b=YZNmtXGaScxejLAepxX8q0Ml0qw5W+WbZMMbm+c5qjiFij2/9LWnKyjrE+My/sIAU/rIgA 2ps4lEC/tWpHtU9x43vte0Aidf53/WnL5uBSvWnN49icIt5XRvp6vW3wjmwIDCGU2YwDZO pSsP+z85WBJbyzRh6CK/IIILom4g7oo8UWR+0nSBs85Wo8aw1kq8BmFTk/XD+l9q/AIYjU uxDTySpkTw7TcnOWxhpSM1FaL4Sc21jYIWkYoHxAbwywQCmIHIGoae/eNjw9a40wO671eo VYat7yCZCrf5UzsuSqupUbc5o9T2zPxdU6L2dm2xNbh9I5xImNzTGXfAhA1jAg== 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 B341A1B9E7 for ; Mon, 02 Dec 2024 20:15:53 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tIBst-0002Qr-Ks; Mon, 02 Dec 2024 14:15:04 -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 1tIBsr-0002Q5-2R for guix-devel@gnu.org; Mon, 02 Dec 2024 14:15:01 -0500 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tIBsp-0006yz-69; Mon, 02 Dec 2024 14:15:00 -0500 Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-434a2f3bae4so43782985e9.3; Mon, 02 Dec 2024 11:14:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733166896; x=1733771696; darn=gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=eIkJAye41EJMQWQuvLw+lf2CRDAEP5L5NSlQ+P6aGM8=; b=JLJ+2DY/G9VbiMk5vDpnwUHE98hcr/Jdk4LATInjLuLMBQSDGF/KYADy/1hAUScamW rINb3JcGNSITl1+Twzx/7Z2l2/cJUFDWbcFqhXLAapw/YjBE1JqY6dCac6C7GFjuXa3J yoENnXoh2w40FrGPHyydOXovXLgSJHSUExeOEF0fGMr67TQa9ykbZCHDiArph9mzxr7T 19bMlpc+7tidz6rsmI7IFtmd96NR2pSwnLrQGhVuBre8nSiACiWAZyd6Rpf0zqKhqgEe k7kt0exgEYep9QKH412wCB6RhOtpuocd0MYS3WhM/0216zQFr56hPH0AYiM/l6Oi6mp6 hThg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733166896; x=1733771696; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:to:from:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=eIkJAye41EJMQWQuvLw+lf2CRDAEP5L5NSlQ+P6aGM8=; b=mUWsU+rJbZRcc8ocWdzJmcCbQlCtnQ5HsPeXHGAV7qQbVbzVmgNAUWCgMWyZmXiZMz o8N1RaLvfWkVsM81f4axetKL2ninTV4QSmDoOOb6jyHKKmFka62jelyRogyb31n3S5ll SmiGwvKGYGf7mSTep5Hgif4b6skMTX6YJTWmbg//ualpZwqa57g+df2e421ak6i/VLCv 2I0Z1KovFFOIA8vGAY2O7q1UXiWHrUmJ+qNvElbSj/IfXnGXL13AS6XACMg0RJO2oLpD f8bO4IEGufNyTq1YUSc58ey8O8NCOj8qOMMGRFJseP/L5IDtKFiQWkWmZXNe3EEQ7Tn/ K7Mw== X-Forwarded-Encrypted: i=1; AJvYcCWU2SpztQExq7MGBk7L0hJ80ZIEYNhGTGcA/bBTywVQaUt/749QSY5FunCyywAFea7ilLk4izqE8a00@gnu.org X-Gm-Message-State: AOJu0YySvwL9tjpJ0Tl2EXBi72uLZrFuLg8ZipFwxD6V4Lseg54uXhG/ tj+IwdBaHSdrAgdExB0wDShooDwEJ2aWstqSrdJRAUcwMCAiGUt5mSEHmQ== X-Gm-Gg: ASbGncvD6e9Yub1Bl4jJPFxw2UXz1gwAEbB6QyCCu2MU0TDQnAUT+/JNUSybbuqqogG 2/RAKn+MJEBEpXzBF9mgjagarmRh1K0YYar1FQTLD4ziusff0oPGqxz9/Pek6qjopWcmWwk09Dk la0fcAAGn1yyUJ0MoPQnT1+Aj3ScTKNJF3/uPR5tPMSRa2B28lQRQGBY62MnuOSFRf68E+jYVuB 1DJbtRqm8PzALMPI/NfAr8EN/lYFbralCTtTKySeZAit0eMC6dkUG/F4VgEneQj04CJkErG48H1 ENsi9r1dQjQVuEToRBiJR4T59evByUZirXY= X-Google-Smtp-Source: AGHT+IEbeLmT4YFpWCNM2Alg7eabOXP4AjELOMLttyRR2gzHcy4FMo1695QswKnWc/bN4yL3+BYfjQ== X-Received: by 2002:a05:600c:3b88:b0:434:a765:7f9c with SMTP id 5b1f17b1804b1-434a9db839emr220967025e9.6.1733166895600; Mon, 02 Dec 2024 11:14:55 -0800 (PST) Received: from lili (roam-nat-fw-prg-194-254-61-46.net.univ-paris-diderot.fr. [194.254.61.46]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-385e19104a0sm8815549f8f.32.2024.12.02.11.14.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 11:14:54 -0800 (PST) From: Simon Tournier To: Ludovic =?utf-8?Q?Court=C3=A8s?= , guix-devel Subject: Re: Automatically testing package updates In-Reply-To: <87iks2urmd.fsf@gnu.org> References: <87iks2urmd.fsf@gnu.org> Date: Mon, 02 Dec 2024 15:50:53 +0100 Message-ID: <87y10ynnoy.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::32a; envelope-from=zimon.toutoune@gmail.com; helo=mail-wm1-x32a.google.com X-Spam_score_int: -4 X-Spam_score: -0.5 X-Spam_bar: / X-Spam_report: (-0.5 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -9.15 X-Spam-Score: -9.15 X-Migadu-Queue-Id: B341A1B9E7 X-Migadu-Scanner: mx10.migadu.com X-TUID: gjQVit9VVQ5R Hi, That=E2=80=99s cool! Here, I share a =E2=80=9Crandom thought=E2=80=9D. :-) > This manifest is just an example. We could come up with manifests > targeting package collections like CRAN packages, astronomy packages, > and so on. Discussing on Mastodon, Konrad emitted this idea [1]: Just an idea from someone mostly ignorant about how the build farms work: could package builds be done lazily? E.g. the build farm tracks requests for yet-unbuilt packages, and builds those that have been requested ten times or so. I know it=E2=80=99s not possible considering the current way substitutes are designed. The idea is still appealing; especially when using =E2=80=9Cguix time-machi= ne=E2=80=9D. Currently and considering patch#74542 [2], the build farm will try to build all the updates by upstream for some =E2=80=9Cdefined=E2=80=9D packag= es even if these updates would never reach any branch or worse never land to master. If I understand correctly, the idea behind is to ease updates and/or reviewing. Yeah it should help. :-) Consider Blender: many of all the updates are trivial updates. But on my relatively new laptop, it takes around 15 minutes to build. It=E2=80=99= s not nothing and it might be a strong refrain [3] for updating and/or reviewing the update. Here is the past rate of the updates: 5905b47287 gnu: blender: Update to 3.6.13. Sat Jul 6 00:52:44 2024 -0300 ebaf658acd gnu: blender: Update to 3.6.10. Sat Apr 6 08:40:56 2024 -0300 e8d163b49a gnu: blender: Update to 3.3.5. Fri Apr 14 15:11:51 2023 -0400 eb169d36e5 gnu: blender: Update to 3.3.5. Fri Mar 31 13:29:29 2023 -0400 45fe602602 gnu: blender: Update to 3.3.1. Sat Nov 19 19:54:14 2022 +0100 f05f831f66 gnu: blender: Update to 3.0.1. Wed Feb 9 16:06:28 2022 +0100 48d38125c2 gnu: blender: Update to 2.93.6. Sun Nov 21 18:37:50 2021 +01= 00 The idea of the manifest, if I understand correctly what=E2=80=99s behind, = is to ease that, then for example the versions 3.6.11 and 3.6.12 would have been built by removing the constraint on having the capacity to locally build. That=E2=80=99s said, it appears to me a bazooka: build all just in case. Because it=E2=80=99s not sure at all that someone=E2=84=A2 would be motivat= ed to commit the Blender=E2=80=99s updates of 3.6.11 and 3.6.12; if we had the manifest discussed before. :-) Back to Konrad=E2=80=99s idea! Consider that if instead of building all we would potentially need, we only build what we really need. That=E2=80=99s what QA tries to do: build = all the patches. However, sometimes QA is lagging [4] or the number of dependencies is too high. Let put more <3 in QA! Still. Now, consider the case where we use "guix time-machine". Today, the substitutes availability depends on the weather. ;-) Well, sometimes substitutes are still available, sometimes not; it depends on the cache policy. Indeed, we cannot store all binaries forever. Therefore, consider the feature: When using "guix time-machine" on a restricted set of channels, and so using specific revisions defined by the channels, if the content-addressed item is not available, then it would be possible to queue one or more or none transformations for some packages from one specific revision of some channels we care. This feature solves two problems at once: 1. avoid the bazooka but still help by easing the reviewing of updates and 2. provide substitutes for past revisions. However, this needs to adapt how the mechanism for substituting works, right? The question seems: Is it doable or already doomed by current design? In other words, would it require too much work? Cheers, simon 1: https://social.sciences.re/@khinsen@scholar.social/113550338572274110 2: [bug#74542] [PATCH 11/11] etc: Add upgrade manifest. Ludovic Court=C3=A8s Tue, 26 Nov 2024 11:33:50 +0100 id:c55d9c57d99b50436c3afa607beaf62ae46d3c40.1732615193.git.ludo@gnu.org https://issues.guix.gnu.org/74542 https://issues.guix.gnu.org/msgid/c55d9c57d99b50436c3afa607beaf62ae46d3c40.= 1732615193.git.ludo@gnu.org https://yhetil.org/guix/c55d9c57d99b50436c3afa607beaf62ae46d3c40.1732615193= .git.ludo@gnu.org 3: Public guix offload server Arun Isaac Thu, 21 Oct 2021 02:23:49 +0530 id:878rynh0yq.fsf@systemreboot.net https://lists.gnu.org/archive/html/guix-devel/2021-10 https://yhetil.org/guix/878rynh0yq.fsf@systemreboot.net 4: https://social.sciences.re/@civodul@toot.aquilenet.fr/113549606095407968