[bug#51554] [PATCH] gnu: libva: Update to 2.13.0

[bug#51554] [PATCH] gnu: libva: Update to 2.13.0

[Josselin Poiret via Guix-patches via]

* gnu/packages/video.scm (libva): Update it.
---
 gnu/packages/video.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/video.scm b/gnu/packages/video.scm
index d4d9eed68d..7f86dcc10c 100644
--- a/gnu/packages/video.scm
+++ b/gnu/packages/video.scm
@@ -1425,14 +1425,14 @@ (define-public libmatroska
 (define-public libva
   (package
     (name "libva")
-    (version "2.10.0")
+    (version "2.13.0")
     (source
      (origin
        (method url-fetch)
        (uri (string-append "https://github.com/intel/libva/releases/download/"
                            version "/libva-" version ".tar.bz2"))
        (sha256
-        (base32 "0dh2zjn6wi74ga75r6pbrrj8hjm213zyxvn9bv78z0fra1dy70gs"))))
+        (base32 "0q6l193x9whd80sjd5mx8cb7c0fcljb19nhfpla5h49nkzrq7lzs"))))
     (build-system gnu-build-system)
     (native-inputs
      `(("pkg-config" ,pkg-config)))
-- 
2.33.1

[bug#51554] [PATCH] gnu: libva: Update to 2.13.0

[Ludovic Courtès]

Hi,

Josselin Poiret <dev@jpoiret.xyz> skribis:

> * gnu/packages/video.scm (libva): Update it.

For the record, this entails lots of rebuilds, contrary to what one
might think:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix refresh -l -e '(force (@@ (gnu packages gl) libva-without-mesa))' 
Building the following 1478 packages would ensure 2711 dependent packages are rebuilt: […]
--8<---------------cut here---------------end--------------->8---

I suppose this could go to ‘core-updates’.

Alternatively, we could keep ‘libva-without-mesa’ at its current version
and only upgrade ‘libva’; that could be done on master.

Thoughts?

Thanks,
Ludo’.

[bug#51554] [PATCH] gnu: libva: Update to 2.13.0

[Josselin Poiret via Guix-patches via]

Ludovic Courtès <ludo@gnu.org> writes:
> For the record, this entails lots of rebuilds, contrary to what one
> might think:
>
> --8<---------------cut here---------------start------------->8---
> $ ./pre-inst-env guix refresh -l -e '(force (@@ (gnu packages gl) libva-without-mesa))' 
> Building the following 1478 packages would ensure 2711 dependent packages are rebuilt: […]
> --8<---------------cut here---------------end--------------->8---
>
> I suppose this could go to ‘core-updates’.

My bad, I completely missed this.  I initially wanted to upgrade libva
because the older version doesn't work on core-updates-frozen with
Wayland compositors, so I think it should ideally belong there if
possible to avoid having broken hardware acceleration for a while when
that branch is merged.  If it does indeed lead to too many rebuilds,
then maybe it could go onto core-updates-frozen-batched-changes, but
then that'd delay its merging again.  I'm not too sure between those,
but I think it should be one of them.

Best,
Josselin Poiret

bug#51554: [PATCH] gnu: libva: Update to 2.13.0

[Maxim Cournoyer]

Hello,

Josselin Poiret <dev@jpoiret.xyz> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>> For the record, this entails lots of rebuilds, contrary to what one
>> might think:
>>
>> --8<---------------cut here---------------start------------->8---
>> $ ./pre-inst-env guix refresh -l -e '(force (@@ (gnu packages gl) libva-without-mesa))' 
>> Building the following 1478 packages would ensure 2711 dependent packages are rebuilt: […]
>> --8<---------------cut here---------------end--------------->8---
>>
>> I suppose this could go to ‘core-updates’.
>
> My bad, I completely missed this.  I initially wanted to upgrade libva
> because the older version doesn't work on core-updates-frozen with
> Wayland compositors, so I think it should ideally belong there if
> possible to avoid having broken hardware acceleration for a while when
> that branch is merged.  If it does indeed lead to too many rebuilds,
> then maybe it could go onto core-updates-frozen-batched-changes, but
> then that'd delay its merging again.  I'm not too sure between those,
> but I think it should be one of them.

I had totally missed that for the batched branch.

Too bad.  I know Ludovic had concerns about a ~3K rebuilds; that's a lot
but currently only x86_64 and i686 are in a state of building the world
it seems, so that's about 6K packages.

I've bunched this with glib-networking, another similar sized rebuild,
manually built most of the dependents on berlin for x86_64, and pushed
as 0a787e67ecd0fab42c7ddfec639b53d58c15af6e.

Closing.

Maxim