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 ms9.migadu.com with LMTPS id uO/2JIAxWWTvXAAASxT56A (envelope-from ) for ; Mon, 08 May 2023 19:29:36 +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 ENHWJIAxWWQfJQEAauVa8A (envelope-from ) for ; Mon, 08 May 2023 19:29:36 +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 40D983C456 for ; Mon, 8 May 2023 19:29:36 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pw4fu-00083g-Bz; Mon, 08 May 2023 13:29:26 -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 1pw4fr-00083A-A4 for guix-devel@gnu.org; Mon, 08 May 2023 13:29:23 -0400 Received: from mira.cbaines.net ([212.71.252.8]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pw4fp-0004bP-4y for guix-devel@gnu.org; Mon, 08 May 2023 13:29:23 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:54d1:d5d4:280e:f699]) by mira.cbaines.net (Postfix) with ESMTPSA id ECE9027BBE9; Mon, 8 May 2023 18:29:18 +0100 (BST) Received: from felis (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 882f226e; Mon, 8 May 2023 17:29:16 +0000 (UTC) References: <168347913021.32190.10808857919894440138@vcs2.savannah.gnu.org> <20230507170531.26A00C22F14@vcs2.savannah.gnu.org> <87r0rrzjbr.fsf@cbaines.net> <87jzxjvxeg.fsf@gmail.com> <87ild3yltb.fsf@cbaines.net> <87v8h2vpdq.fsf@gmail.com> User-agent: mu4e 1.8.13; emacs 28.2 From: Christopher Baines To: Maxim Cournoyer Cc: guix-devel@gnu.org Subject: Re: 04/09: gnu: mesa: Update to 23.0.3. Date: Mon, 08 May 2023 17:39:47 +0100 In-reply-to: <87v8h2vpdq.fsf@gmail.com> Message-ID: <87bkiuzq8l.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=212.71.252.8; envelope-from=mail@cbaines.net; helo=mira.cbaines.net 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 ARC-Seal: i=1; s=key1; d=yhetil.org; t=1683566976; a=rsa-sha256; cv=none; b=ryBj/t9qculB151YioGeypg7glvpsbh4smC1CVAsfBlMj0sTsL+R80IXqfX/1AzsOim4j3 k0odcdcw8JqWMm6TF1Sda1a2urSHkMGoYHYk9m4OW1iSnWgn68fK5DZIMrp0deW7n1xuxR NdgGISxK0MWfw3gKV+VXBt80eAyIPS1ws65/uKscfBJhkZ475AJpGJN1GJzjqvgZsAufmS FDBwdDsQK0sL/xAgdMuYQwdvTZ7LcIInoDOnKNSEtfysTA/ORNjbskhsQZtheKcnJw2uTz gXRk6jf17yrUwPxDCaKLKPgLFerxTS7I/t83cmh/cyZgtOjjM1b/lItC6v2fLA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1683566976; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=AFbknVsFO3rlaAC7hlmlcmD8dMB+eCokkquIHn7sjLQ=; b=J+wWptiSKEli6tjO6kdyKpXLSpMZelebO0KuB5IWhjOrho0IdUTPRJFtAxgzUa5q7duIU2 NzNDwu6kwZ+J8hPYsPBeRqv0Qbz5LOnYc9riOE0dUHmIK62MxWFXmveYxDlDG6Su+hlHrD X04tgw7NjDy4yWftzwwv5ebR3DFDN4QiPX6lqhrcpRt09VKzIc0PBWnGhrpSEJSMq1ADA0 pHvLQLg+mODU+IRIArV1TzNLK4tl34FawsxsPSio5tqRFyYU0Py/0q/92ltr0UPAktkVDd +WD0I5E8Fe31wr6KmuGlfSV8vjy6jZXf3lI0snRukskdPtYoX3pK9QmS+lAIgg== X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=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" X-Migadu-Spam-Score: -3.59 X-Spam-Score: -3.59 X-Migadu-Queue-Id: 40D983C456 X-TUID: 1Ne2lJs34iJf --=-=-= Content-Type: text/plain Maxim Cournoyer writes: >>> Seeing the build machines were idling in the European night, I figured I >>> could get away with it for this time. >> >> Some build machines may have been idle, but I'm not sure what you mean >> by "get away with it"? > > I meant that I believed there was enough capacity to process the 4K > rebuilds (per architecture) in a way that wouldn't negatively affect > users too much. That may well be the case, but I see problems using this as justification for similar actions in the future. Even if it's unlikely that people use mesa or it's dependencies on systems other than x86_64-linux and i686-linux, this still adds to the backlog of builds for other architectures. Also, while the berlin build farm may be able to build things very quickly for these systems, I think it's good to try and reduce the churn where possible by batching together changes (aka staging/core-updates). Not doing so and just pushing when the build farm can cope will generate more data to store, more for users to download and more to build for people who don't use substitutes. >> While the berlin bulid farm has managed to catch back up for >> x86_64-linux and i686-linux within 24 hours, I think these changes >> impact other systems as well. >> >> Also, the bordeaux build farm has a lot fewer machines to do these >> builds, so while the substitute availability had caught up (and >> surpassed ci.guix.gnu.org for x86_64-linux) prior to these changes, it's >> going to be several days at least I think before substitute availability >> is looking good again. >> >> I was watching the substitute availability recover after the >> core-updates merge as I'd like to re-enable testing patches on the >> qa-frontpage, but now that'll have to wait some more for all these new >> builds to complete. > > Hm, sorry about that. Cuirass seems to have mostly caught up already > (was 64% before, 62% now for the master specification). I think this is a problematic metric to use. Cuirass should be building for aarch64-linux, but substitute availability sits below 20% for that system. Even though the bordeaux build farm has less machines, it has 70%+ substitute availability. So for aarch64-linux for the berlin build farm, I think these builds have just been added to the long backlog. This metric doesn't articulate how the situation has got worse in this way. (also, I don't know what this number means, but if it's something like substitute availability, ~60% seems pretty bad) >>> But the situation will repeat; I'd like to push some xorg updates that >>> fix a CVE; we'll nead a 'xorg-team' branch or similar. Should we create >>> these branches from the maintenance repository (permanent branches) ? >> >> I don't really understand the question, surely the branches would be in >> the guix Git repository? > > Yes, the branch would be in the Guix repository, but I meant regarding > the Cuirass specifications affecting which branches it builds; sorry for > being unclear. No problem, this is something that needs looking at. On the berlin build farm side, yes, configuring Cuirass to look at the branches is one thing, but there's also bigger issues, e.g. the lack of substitutes for aarch64-linux and armhf-linux (and thus delays in testing/merging branches due to this). On the bordeaux build farm side, there's also a "how to start and stop building a branch issue". Currently it's a code change in the qa-frontpage (plus reconfiguring bayfront and restarting the service), but it would be good to make this easier too. Plus, like the berlin build farm, there's also issues getting things built fast enough. >> Anyway, package replacements+grafts can be used for security issues so >> that shouldn't need to be on a branch as it won't involve lots of >> rebuilds. > > For this case I think so yes, since it's a patch-level update that > should be safe. > >> When it comes to handling changes involving lots of rebuilds though, I >> think that this has been and continues to be difficult, but in my mind >> that's a reason to slow down and try and work on tooling and processes >> to help. > > One of the things that has been bothered me has been the lack of > documentation/tooling to recreate TLS user certificates for Cuirass so > that I can configure branches via its web interface again, or retry > failed builds. I'm currently working on documenting (in Cuirass's > manual) a script Ricardo's made for that task. > > But building lots of packages will still require a lot of processing > power, probably more so when it happens in focused team branches > compared to grouped together as it used to be the case for > e.g. core-updates. I agree. I'm still not really sold on the idea of team specific branches for this reason. Anyway, I think there's still tooling to build (e.g. analyzing the overlap for builds between two changes) and more thinking to do about processes for this. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmRZMWpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XcnVg//XtfUAq6YhKaTqwFe2JaUtFUXFsnGOuOu ZRZNfT56Eg87kPa4UxAFGFMs4DwcCEBa680xjzkc3AVBFcnZ3+YsOn7CWiDITo+2 a3Q7h/azvxA+lcql/Q5OvNowfVZcZPRetqoqCsk1PaEYANGDo2HIYmLbkpsCxO+7 7b5EKeFoXGJp8+rPTzX9BN3B/6VELiGYCvWhRbb6tX0cZkvXbHhtMNWwC+AQjz8p eLTf/pbrugVYhVFEpnECXtKkntqc4FxVZfDGkxNMT2OuyNBhdXDbejxBytG08WI6 paxD95Wmqr1+dgmZqgwxaMA6i0ZnpH2OA0Ak7vlIGDUNqfHNnMTEdx0OdQgn9PrZ V7Y696MhpaHQuhRGEl1CRRYB+9DT0g70//B/H/3NZ8gcp7yTnMFBJRMxMBoKAnOv i46TL+kCPpyXUfJGCRQ1WcwHStv/4hFyGpj5fy+g2HTWxbMFrWldYKxy04bOA9Y+ CBU4PkLQVlyR9XFRxo2S/4t/X6CDxOrfAw9R9VXSQsAoOCwFQ5334YojPUTxD1nv Dh9YEZPOEAzbyb0gfkuChnMmNxMf9d8/B3g1Y0zZfQdb4xEVmT82OvCXrit8xUFG o5cFVM3ifFDksy5i0RWgpFY7fqfxugKt0xJ8reAjbbpX1gxQeZV6mKzid3fvPVqq kEu2V4UKN4Q= =dkww -----END PGP SIGNATURE----- --=-=-=--