| Message ID | b7mBizOZJkf44eBGpH-Gzb7je_BHGFlA521YaWjMGr5I0tVTncSkbNuz94XC08JB8VWVsad17wBOkWuY3CDyBnLRFLNhRd7ufpRiEaO2E_o=@elenq.tech |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#54066] : Update mesa to 21.3.6 (fixup release) | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | fail | View Laminar job |
| cbaines/issue | success | View issue |
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?
------- 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?
Hi, I updated Mesa to 21.3.8 on ‘staging’ in commit d0951c288b97db42c470506ec62f4e14a76774b1. Sorry that it took so long! Ludo’.
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)
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