From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id eEcvB3yBA2YvcAEA62LTzQ:P1 (envelope-from ) for ; Wed, 27 Mar 2024 03:16:28 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id eEcvB3yBA2YvcAEA62LTzQ (envelope-from ) for ; Wed, 27 Mar 2024 03:16:28 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20230601 header.b=LnhavC5Q; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1711505787; a=rsa-sha256; cv=none; b=EcvLDCPmkgvchqh/u+AUMLq50Vshs6c6X6XGD6WZYTTxG7KuSTsccXJX00xTyMyL4+bymP q3ek1aUAmdU5Yv34lUbw2He8vuYVuyCr0w6zmJUWn5VKIkKx6nllV5qLnoOjd43AA1E92P HHa+71BBzJfX7cG6eh4WBy/hjy8tZvJQKDigEXbc8O3Pbdiu8uQvq4d4gx6dZGAyZJkRRs ykwD/m9pv+B47SylUqWi+z3NKVm9M2Q2B/dIGIp3tOIffBOCcYEW5j4uDKN4+ftK0AK7Dn vJH9Ep/mgaQAnt0noU7V6wF0k+aTz0Gc2ADkf6pHZljLMVsiwFsB75H0OApuHQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20230601 header.b=LnhavC5Q; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1711505787; 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:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=+YnyM5OQcG2hKU8ZricNGXDHjbhR13qTjUCM23XXg34=; b=a1l3siv89M1rJuqsJ3FqOZImEodRApXNPgYSUF8r3n06uB3zTk116DaTIjNmR4iW/UsLYJ 9mmmp8IuXt4dHlT9OVYGy8kfdTxGGnP6V5lToBrQBhP0bmxbt9NdyUXtlXNYdH1VaDLgyN fX1kIqBxwciF6m4hFL0273mFBGLMyuMl9Bq8MhLEUVyRbDxY7zsfWEojT/x8DcNVzlhskK R7mS+uGFh97Maw6T4KwBZF+3YqONGxYg1GCSq8NarzZBcVtGSYLloQZzOHsL/oqEzTY6Is wcCJMRAxYGR2eZJlEP3Vdj/OHhuT+mjuSsdwAQaLN3ZE5OcQoZo47yXC/BwWNg== 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 C41A3278A3 for ; Wed, 27 Mar 2024 03:16:27 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rpIpg-0000Br-Aa; Tue, 26 Mar 2024 22:16:04 -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 1rpIpe-0000Bi-NQ for guix-patches@gnu.org; Tue, 26 Mar 2024 22:16:02 -0400 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rpIpe-0003jf-BI for guix-patches@gnu.org; Tue, 26 Mar 2024 22:16:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rpIpd-00087Z-Ne for guix-patches@gnu.org; Tue, 26 Mar 2024 22:16:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#69637] [PATCH mesa-updates v2 0/5] gnu: mesa: Update to 24.0.3. Resent-From: aurtzy Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 27 Mar 2024 02:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69637 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: John Kehayias Cc: 69637@debbugs.gnu.org, efraim@flashner.co.il Received: via spool by 69637-submit@debbugs.gnu.org id=B69637.171150570430978 (code B ref 69637); Wed, 27 Mar 2024 02:16:01 +0000 Received: (at 69637) by debbugs.gnu.org; 27 Mar 2024 02:15:04 +0000 Received: from localhost ([127.0.0.1]:35482 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rpIoh-00083a-FQ for submit@debbugs.gnu.org; Tue, 26 Mar 2024 22:15:04 -0400 Received: from mail-qk1-x72f.google.com ([2607:f8b0:4864:20::72f]:44175) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rpIob-00082J-Tr for 69637@debbugs.gnu.org; Tue, 26 Mar 2024 22:15:01 -0400 Received: by mail-qk1-x72f.google.com with SMTP id af79cd13be357-788598094c4so293566085a.0 for <69637@debbugs.gnu.org>; Tue, 26 Mar 2024 19:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711505692; x=1712110492; darn=debbugs.gnu.org; h=in-reply-to:content-language:references:cc:to:subject:from :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=+YnyM5OQcG2hKU8ZricNGXDHjbhR13qTjUCM23XXg34=; b=LnhavC5Q2ToOrCB0BH9KEwBuTiGRQPz3pn/zkIvANtSiebLUEhWluccnrCebOcM0hZ jQIz+C8fL7dUEnbki5FjK0zBQD2cToMCrTkpNW2fYTHDOif8j8tUsEHI46cIIXHcXdke 7VTW4u+3dgf4fEnDakKa5YIe/ooZdBm/03Fpf51As77W/DcmTU1C0967e0vSnKTt1hqz gQ7ZFp0BjxLjyALF9xSLelFfm3CVbf1Rlnq/sWdQoxCLOSDL5Avoz4ZTApppBF3Uzsc0 cidSZLb0Y8EvR0qvbWzRA1Sy7agcePndn2jHzS2Vs7pfCOj0A5E3z3tibstw1i485VM6 e0vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711505692; x=1712110492; h=in-reply-to:content-language:references:cc:to:subject:from :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=+YnyM5OQcG2hKU8ZricNGXDHjbhR13qTjUCM23XXg34=; b=S+PyXRzfh/+DvTtdPun2o5B75MZ4xoD922HjrG8utmxp1Lv85H/dOqcPz3tmAy39lx NUJ9C6tBokiFjvB1RTB1UF3d9SLTWtglFlU6pAfu24ZH0sVCRMKRrje7JP7m1d3DJacf plsAXtuVTRkYCahHzLhWnYwzyCyb8sv254aPKLgzv33iW2EosLEbaWEdtcfLH42zImv+ m2P5gGBVSwZ5WcObPZI4q9Kb1P9GL0K2W4jU1m+5E/Ho08xpnDJ4+nnKGdGMtv6OmSAw 4VKkseCOewRGptwkakhT0yTzKmrk1coYKLKQuMxCnLzk8AF/fXDCfD8A2yJ33WXAeRNn rj0g== X-Gm-Message-State: AOJu0YyZyDNAOJ1X9rBe6djSsFJ6JR3cOdvBY8cEttEbbGZ8zgkbEgL9 /m8mb/6/KfcyD6WnNWL9labwqTtbSEFnvwcl26wfF9DxAc/cWmLe X-Google-Smtp-Source: AGHT+IFTBm+a55zXaFrdF8y/MUT+znBBaufcgJw5sT9n0a5fwLNkWNHzgfUgAljm3d2l9E4lv19weA== X-Received: by 2002:a05:620a:108b:b0:78a:2b1b:e56b with SMTP id g11-20020a05620a108b00b0078a2b1be56bmr4785986qkk.68.1711505692151; Tue, 26 Mar 2024 19:14:52 -0700 (PDT) Received: from [192.168.1.87] (ool-18bb63f6.dyn.optonline.net. [24.187.99.246]) by smtp.gmail.com with ESMTPSA id a27-20020a05620a067b00b0078a315d9ed4sm3525406qkh.92.2024.03.26.19.14.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Mar 2024 19:14:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------vEvVLxLF9Q64DIM2u72DgYoV" Message-ID: <88a7c961-6a3c-4700-8da1-f7dcb5127489@gmail.com> Date: Tue, 26 Mar 2024 22:14:50 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: aurtzy References: <87sf0fnloc.fsf@protonmail.com> Content-Language: en-US In-Reply-To: <87sf0fnloc.fsf@protonmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Spam-Score: 2.67 X-Migadu-Queue-Id: C41A3278A3 X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: 2.67 X-TUID: mM1uHkRI9UnD This is a multi-part message in MIME format. --------------vEvVLxLF9Q64DIM2u72DgYoV Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/24/24 21:29, John Kehayias wrote: > Hi aurtzy and Efraim, > > On Fri, Mar 22, 2024 at 03:24 AM, aurtzy wrote: > >> New patchset coming in. Mesa has been updated to 24.0.3, and I've added TODO >> comments for future work as suggested. >> > Thanks! Happy to help! >>> I would like to get the build farm cranking on the updates I have >>> queued for mesa-updates (cairo, libdrm, mesa, vulkan). We could also >>> do just the version update of mesa to start, or just NVK on x86_64, >>> leaving future changes for the next round. I don't have a preference >>> myself, other than wanting to get this branch moving with these >>> updates. >> NVK on 24.0.3 is also still considered experimental, so if that's a concern we >> could save this work for 24.1 when it's planned to move out of this stage. >> > Right, I forgot about that. I also remember that it depends (or is > helped by) some changes in recent kernels, 6.7 and/or 6.8 if I remember. 6.6 appears to be the minimum required according to mesa docs, if that changes anything: https://docs.mesa3d.org/drivers/nvk.html#kernel-requirements > So, maybe we can take this approach: > > 1. Make the update just to 24.0.3 for mesa (does that require newer > meson?) The meson 1.3 requirement is only for NVK; mesa 24.0.3 without NVK can build with the current meson. > 2. Add any rust packages as needed to master > > 3. Either add a mesa-next (to master?) or followup on mesa-updates after > it gets merged to master with a mesa based on 24.1 (as soon as it is > tagged) with NVK enabled. This will let us at least get mesa built and > make for a headstart come 24.0.1. > > With 24.1 soon ("this quarter"?) and how long it can take us to build on > non-x86 architectures, it would be nice to have that go quickly. Since > I'll be including cairo, libdrm, and vulkan updates (at least) this > round, I anticipate it taking a bit. > > Does that sound okay? It'll give some time to test things and clean > up/find alternatives as Efraim suggested. > > I'm also not opposed to just enabling NVK now. In that case, we should > have one commit to just update mesa and another to enable NVK. Looks like 24.1 stable should be releasing May-June: https://docs.mesa3d.org/release-calendar.html This approach sounds fine to me. I don't mind holding back the NVK-related changes for more testing and improvement. >>> I also tried a couple of different options. The one that I most want >>> involved using with-output-to-file to rewrite the wrap file and >>> replacing all the fields. I borrowed the file-sha256 function from >>> guix/build/cargo-utils.scm to get the source_hash. In the end I wasn't >>> able to get the gexp and un-gexp bits working to actually get the file >>> written. >>> >>> When I kept a failed build I saw that the 'directory' field is the >>> directory into which meson writes the meson.build file, which is why >>> using a different version of the rust crate caused problems with >>> src/lib.rs not existing. I suppose we could start from your patch and >>> then, after running substitute, extract the tarball into either a >>> hardcoded path (determined after manually reading the sources) or we can >>> extract the 'directory' field by reading the sources and then untar the >>> source there. >> Noted, thanks Efraim! I'll keep looking into this. >> > Thanks both of you! I would like to start pushing patches and building > everything in the next few days, especially as some have sat for a while > and it will take time to build. > > John Cheers, aurtzy --------------vEvVLxLF9Q64DIM2u72DgYoV Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 3/24/24 21:29, John Kehayias wrote:
Hi aurtzy and Efraim,

On Fri, Mar 22, 2024 at 03:24 AM, aurtzy wrote:


New patchset coming in.  Mesa has been updated to 24.0.3, and I've added TODO
comments for future work as suggested.


Thanks!
Happy to help! 
I would like to get the build farm cranking on the updates I have
queued for mesa-updates (cairo, libdrm, mesa, vulkan). We could also
do just the version update of mesa to start, or just NVK on x86_64,
leaving future changes for the next round. I don't have a preference
myself, other than wanting to get this branch moving with these
updates.

NVK on 24.0.3 is also still considered experimental, so if that's a concern we
could save this work for 24.1 when it's planned to move out of this stage.


Right, I forgot about that. I also remember that it depends (or is
helped by) some changes in recent kernels, 6.7 and/or 6.8 if I remember.

6.6 appears to be the minimum required according to mesa docs, if that changes anything: https://docs.mesa3d.org/drivers/nvk.html#kernel-requirements 

So, maybe we can take this approach:

1. Make the update just to 24.0.3 for mesa (does that require newer
meson?)
The meson 1.3 requirement is only for NVK; mesa 24.0.3 without NVK can build with the current meson.
2. Add any rust packages as needed to master

3. Either add a mesa-next (to master?) or followup on mesa-updates after
it gets merged to master with a mesa based on 24.1 (as soon as it is
tagged) with NVK enabled. This will let us at least get mesa built and
make for a headstart come 24.0.1.

With 24.1 soon ("this quarter"?) and how long it can take us to build on
non-x86 architectures, it would be nice to have that go quickly. Since
I'll be including cairo, libdrm, and vulkan updates (at least) this
round, I anticipate it taking a bit.

Does that sound okay? It'll give some time to test things and clean
up/find alternatives as Efraim suggested.

I'm also not opposed to just enabling NVK now. In that case, we should
have one commit to just update mesa and another to enable NVK.

Looks like 24.1 stable should be releasing May-June: https://docs.mesa3d.org/release-calendar.html

This approach sounds fine to me. I don't mind holding back the NVK-related changes for more testing and improvement. 

I also tried a couple of different options. The one that I most want
involved using with-output-to-file to rewrite the wrap file and
replacing all the fields. I borrowed the file-sha256 function from
guix/build/cargo-utils.scm to get the source_hash.  In the end I wasn't
able to get the gexp and un-gexp bits working to actually get the file
written.

When I kept a failed build I saw that the 'directory' field is the
directory into which meson writes the meson.build file, which is why
using a different version of the rust crate caused problems with
src/lib.rs not existing.  I suppose we could start from your patch and
then, after running substitute, extract the tarball into either a
hardcoded path (determined after manually reading the sources) or we can
extract the 'directory' field by reading the sources and then untar the
source there.

Noted, thanks Efraim!  I'll keep looking into this.


Thanks both of you! I would like to start pushing patches and building
everything in the next few days, especially as some have sat for a while
and it will take time to build.

John

Cheers,

aurtzy

--------------vEvVLxLF9Q64DIM2u72DgYoV--