diff mbox series

[bug#54066] : Update mesa to 21.3.6 (fixup release)

Message ID b7mBizOZJkf44eBGpH-Gzb7je_BHGFlA521YaWjMGr5I0tVTncSkbNuz94XC08JB8VWVsad17wBOkWuY3CDyBnLRFLNhRd7ufpRiEaO2E_o=@elenq.tech
State New
Headers
Series [bug#54066] : Update mesa to 21.3.6 (fixup release) |

Commit Message

Ekaitz Zarraga Feb. 19, 2022, 4:45 p.m. UTC 
From a8dbe13a127cd29c87f9ab70c421661e393d53b6 Mon Sep 17 00:00:00 2001
From: Ekaitz Zarraga <ekaitz@elenq.tech>
Date: Sat, 19 Feb 2022 17:43:46 +0100
Subject: [PATCH] gnu: mesa: Update to 21.3.6.

* gnu/packages/gl.scm (mesa): Update to 21.3.6.
---
 gnu/packages/gl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--
2.34.0

Comments

John Kehayias Feb. 22, 2022, 7:50 p.m. UTC | #1 
Thanks for the patch! I had just done a similar one locally and confirm that everything built fine on x86-64.

The last mesa update was part of core-updates(-frozen), but I heard in the past it went into staging. These days, at least, mesa moves quickly, updating every few weeks (the last few all 2 weeks or so apart).

So, I'd like to propose we set up a branch on the CI to build this mesa update to then push to master once we confirm no big breakage in building. Then we would have substitutes right away, which I think would be one of the big concerns with updating something like mesa (again, since this is a set of minor bugfix releases).

We could batch a few other changes to deploy at the same time, maybe the recent security grafts?

It would be great to leverage that CI to move quickly on updates like mesa which won't (we'll check!) be introducing breaking changes, merely lots of rebuilds. Likewise with grafts->updates, though I'm less familiar with what to look out for there. I suppose this is sort of the staging branch idea, but maybe a smaller scale and quicker. Mesa, for instance, would likely have a new version(s) if this is stretched over a month or two.

WDYT?
John Kehayias March 3, 2022, 4:05 p.m. UTC | #2 
------- Original Message -------

On Tuesday, February 22nd, 2022 at 2:50 PM, John Kehayias wrote:

...
> It would be great to leverage that CI to move quickly on updates like mesa which won't (we'll check!) be introducing breaking changes, merely lots of rebuilds. Likewise with grafts->updates, though I'm less familiar with what to look out for there. I suppose this is sort of the staging branch idea, but maybe a smaller scale and quicker. Mesa, for instance, would likely have a new version(s) if this is stretched over a month or two.
>

Indeed, just after this message Mesa released 21.3.7.

Any support for a quick staging type branch to build changes, check for any major build failures, and then push to master with the substitutes?
Ludovic Courtès May 15, 2022, 2:03 p.m. UTC | #3 
Hi,

I updated Mesa to 21.3.8 on ‘staging’ in commit
d0951c288b97db42c470506ec62f4e14a76774b1.

Sorry that it took so long!

Ludo’.
diff mbox series

Patch

diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
index 0ff39dc24d..470c9094c7 100644
--- a/gnu/packages/gl.scm
+++ b/gnu/packages/gl.scm
@@ -260,7 +260,7 @@  (define libva-without-mesa
 (define-public mesa
   (package
     (name "mesa")
-    (version "21.3.2")
+    (version "21.3.6")
     (source
       (origin
         (method url-fetch)
@@ -272,7 +272,7 @@  (define-public mesa
                                   version "/mesa-" version ".tar.xz")))
         (sha256
          (base32
-          "1g96y59bw10ml8h4jl259g41jdmf5ww3jbwqpz1sprq7hgxvmrz2"))
+          "0dk717mrp59i6wgf5nir7126hmjw48jw1z15s10smsa6slgpdfwn"))
         (patches
          (search-patches "mesa-skip-tests.patch"))))
     (build-system meson-build-system)