From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:5f26::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id SMojENSLm2WNmAAAkFu2QA (envelope-from ) for ; Mon, 08 Jan 2024 06:44:52 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id GEnSCNSLm2WUrwAAqHPOHw (envelope-from ) for ; Mon, 08 Jan 2024 06:44:52 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=LOzvZPyV; 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=pass (policy=quarantine) header.from=protonmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1704692692; 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:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=FmbHdjQTlWnsPZlbuIViSeMT6WDyMxzUSLrpaXZpi5U=; b=EJfRaYjWf83VwocbDx8nFNr8RV0qzphADEDBh6YhoJTMU+RYqo+4KubY5FLvshU7sEAo2l BdF+GeNjxNucSQd46huhPMxUdWHIhweQROA4cAdO8yPRFBNmBJTXMpr4Hu05+MkK6eNH1X x9MWZesXax2AC16OZLC+7basCG5oHKvZCOuTUyoYAqHsWcAaYich0i4iNioP4AxESBle4r P2cax1qyPknvN/aV7SCciKWpJcWmYLUJht2nrCY4AblDlm8QB4KRGr+OuXiqRGUaCBDDOt jT928XOmFqUnkCOpF6TKDj1rWwHaCEqIvwExRihGrC/13FXs6ZyhhjSPzqWUqA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=LOzvZPyV; 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=pass (policy=quarantine) header.from=protonmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1704692692; a=rsa-sha256; cv=none; b=RvF1xxMzQF64MsWM4DTt0Op5SOyIwUDogwjIoXt/PlK8Az9T/AQrobB7+nqxma1Pw9rI17 5eLaNx778gMmWyug4b/VyB3ujspKvgMCUr9Gnu5SfEBTOeXZeUiCWhG8+82jfDmvZu9Io/ 3MyToypq4NMqgt1RTdVOcVPVI2JwroAscT/iUpf5fXudr0Qg7sNTmBuIB+z99QUSeRFjVP eKa9hJQ7h95wx+xseCWh3AjqroTdoJn0avU/Ml1BG34sgrpBFaiKmxk2mm11Z/f287EcQy zDmTzCamx2NPo3bkNZsM5sm57GFXIW0FUXLe7sITYZgSOyaiqSDmoyY+aNhAiA== 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 AC9516384B for ; Mon, 8 Jan 2024 06:44:51 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rMiQm-0006En-Vv; Mon, 08 Jan 2024 00:44:13 -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 1rMiQl-0006Dn-M3 for guix-devel@gnu.org; Mon, 08 Jan 2024 00:44:11 -0500 Received: from mail-40133.protonmail.ch ([185.70.40.133]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rMiQj-0004id-9S for guix-devel@gnu.org; Mon, 08 Jan 2024 00:44:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1704692644; x=1704951844; bh=FmbHdjQTlWnsPZlbuIViSeMT6WDyMxzUSLrpaXZpi5U=; h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=LOzvZPyVLp+LYqJCyUVMYebn3UiSX0x8tHTVbK5Xc9ZkVJ5o1V+XDIpA8IwIjU8k2 z8kEzbLzeBDKfVwBBaUBshIOdWZ3pqTJNDPPGTyWvX58b3o0Npvb/23nD/QtiNcMUg YrLkTkkWyGYNQeRSCHWYsVf/4oXhfOL9yjVDGnxkystdTPL4QezRsURTn3dHBtdzti jgTN7ekxTV7Xxcst56Jt8R7PPfk4PZHT7SQ+Ttjzf3gQuU4mmPdPmS7UNSqVyjz7l+ QmHaT5WjHhb04usMEzpoS9qgLCC0yZqBPZBbh/jEdZYMFLUgme7hQBcR4XMfgp+l+4 pff72t6nCYcdg== Date: Mon, 08 Jan 2024 05:43:40 +0000 To: guix-devel From: John Kehayias Cc: Efraim Flashner , Kaelyn , Maxim Cournoyer , Liliana Marie Prikler , Vivien Kraus , 67875@debbugs.gnu.org Subject: Re: xwayland security updates, to mesa- or core-updates or ? Message-ID: <87mstg1it6.fsf@protonmail.com> Feedback-ID: 7805494:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.133; envelope-from=john.kehayias@protonmail.com; helo=mail-40133.protonmail.ch X-Spam_score_int: -30 X-Spam_score: -3.1 X-Spam_bar: --- X-Spam_report: (-3.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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -3.99 X-Spam-Score: -3.99 X-Migadu-Queue-Id: AC9516384B X-TUID: lLGmtlheu3eL Hi all, Forgive the top post and please see below/previous messages for previous updates. TL;DR: I plan to merge mesa-updates into master today-ish (well, tomorrow for me at this point). I've been checking in with Efraim who's been very helpful at trying to nudge along substitute coverage on non-x86_64 platforms. Unfortunately looks like we have plateaued a bit on, e.g., aarch64. We haven't been getting stats from QA for this round, and Berlin looks good for what it covers (x86) but other architectures are down from what we can tell. I don't think there are any fundamental failures at this point but just lots of "missing derivation" errors (I've restarted so many manually for x86_64/i686) and builds not completing without restarts. Or unknown reasons. Given the few weeks I've given this and the risk of just perpetually doing rebuilds to keep catching up (with then more updates to push) I think it would be best to merge to master. Mesa and other bits will continue to move forward as well, so I think it is time so we can be somewhat timely. I'd rather not without complete substitute coverage, but given recent build farm difficulties, and the tools we do have for users (pinning, weather checks, etc.) I think it is best to call this branch so we can move on. Gnome has some updates that will need (re)building as well as trying to move forward with core-updates now too. This is a case where having some better sense of our users and actual substitute needs/wants would be helpful (yes, Guix survey!) as well as recognizing our current infrastructure limits. Here's another vote for prioritizing infrastructure and making sure QA lives and expands. Feel free to object to this merge timing, though with the relative silence in each previous message I take it I can make a call here. Thanks everyone and hope 2024 is off to a good start! Enjoy the new mesa with curl and xwayland security updates (no new grafts!). John On Thu, Jan 04, 2024 at 12:09 AM, John Kehayias wrote: > Hi Efraim and guix-devel > > On Mon, Dec 25, 2023 at 08:44 AM, Efraim Flashner wrote: > >> On Fri, Dec 22, 2023 at 09:19:27AM +0200, Efraim Flashner wrote: >>> On Thu, Dec 21, 2023 at 09:18:50PM +0000, John Kehayias wrote: >>> > Hi all, >>> > >>> > On Mon, Dec 18, 2023 at 12:57 AM, John Kehayias wrote: >>> > > [snip] >>> > >>> > I haven't seen QA process this branch, so I'm just going with what I >>> > see on Berlin. From the branches overview it shows about 61% last I >>> > saw, compared to 72% for master. Unfortunately, non x86 architectures >>> > are usually better covered by Bordeaux, but I don't know where to get >>> > a sense of that coverage. For what it is worth, Efraim has manually >>> > built xorgproto and mesa at least on powerpc64le, riscv64, without >>> > issues. >>> >>> I had berlin build for powerpc64le and that went without any problems. >>> Locally I built for riscv64 and powerpc and those both built fine. I >>> ran into an issue locally with curl on aarch64 and test 1477(?) which i= s >>> weird since it's supposed to be skipped but I'm sending it through >>> again. Haven't started armhf yet. >>> >>> > Coverage on x86_64 and i686 seems good from what I can tell. I also >>> > don't think there are any other branches ready to merge, and would >>> > like to give them time to rebuild once these changes hit. >>> > >>> > Any thoughts on when to merge? >>> > >>> > Thanks everyone! >>> > John >> > > Coming back to this point, seems Berlin is doing better with building > but I don't see mesa-updates on QA so I'm not sure about non > x86_64/i686-linux coverage. Anyone have any thoughts? > > I don't know that I've seen real new failures, as still lots of > "missing derivation" or other transient issues that resolve on forcing > a rebuild. > > I don't want to merge to master and have issues with substitute > coverage, but do have to call it at some point or will end up keep > scheduling/waiting for rebuilds to happen anyway. > > Thoughts? > >> I've been having trouble with curl on aarch64 again. Looking at this >> snippet from the build log: >> >> test 1477...[Verify that error codes in headers and libcurl-errors.3 are= in sync] >> >> 1477: stdout FAILED: >> --- log/1/check-expected 2023-12-22 10:53:51.658667071 +0000 >> +++ log/1/check-generated 2023-12-22 10:53:51.658667071 +0000 >> @@ -1 +0,0 @@ >> -Result[LF] >> >> - abort tests >> test 1475...[-f and 416 with Content-Range: */size] >> --pd---e--- OK (1247 out of 1472, remaining: 00:45, took 5.310s, duratio= n: 04:11) >> test 1474...[HTTP PUT with Expect: 100-continue and 417 response during = upload] >> --pd---e--- OK (1246 out of 1472, remaining: 00:48, took 22.794s, durati= on: 04:29) >> Warning: test1474 result is ignored, but passed! >> ... >> TESTFAIL: These test cases failed: 1477 >> >> It looks like 1474 is passing locally and the ~1474 is telling the test >> suite to ignore the result. If that's how ~ is interpreted then >> I'd suggest that 1477 is failing hard enough that it's taking the test >> suite with it, not merely ignoring the result. I'll continue poking it >> but right now I'm starting to like the hurd plan of disabling the test >> instead of merely ignoring the result. > > Thanks for looking at this Efraim. Looks like a good chunk of the curl > rebuilds did get through, did it look okay on aarch64 and anywhere > else you checked? > > John