guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#73301] [PATCH 3/4] gnu: gtk: Update to 4.16.1.


From: Liliana Marie Prikler
Subject: [bug#73301] [PATCH 3/4] gnu: gtk: Update to 4.16.1.
Date: Sun, 22 Sep 2024 07:59:34 +0200
User-agent: Evolution 3.48.4

Am Sonntag, dem 22.09.2024 um 11:47 +0900 schrieb Maxim Cournoyer:
> > +                ;; XXX: Figure out why this fails and report
> > upstream.
> > +                ((".*'memorytexture',.*") ""))
> 
> Is the above comment just for 'memorytexture' test?  I've learnt to
> be very explicit in my comments, as when new tests gets disabled,
> it's how to track what is being commented about.
Yes, that's "this" as in "this test".

> (also, I doubt someone will come back to the investigation later, so
> this is technical debt on our side -- I'd favor a minimal
> investigation with a report upstream if none exist so far).
Sure, but let's not forget that there are webkitgtk rebuilds etc.
stalling further upgrades while we investigate.  I think it's fair to
postpone this a little as long as it hits master clean later.

> >                (substitute* "testsuite/reftests/meson.build"
> > -                (("[ \t]*'label-wrap-justify.ui',") "")
> > -                ;; The inscription-markup.ui fails due to
> > /etc/machine-id
> > -                ;; related warnings (see:
> > -                ;;
> > https://gitlab.gnome.org/GNOME/gtk/-/issues/5169).
> > -                (("[ \t]*'inscription-markup.ui',") ""))
> > +                (("[ \t]*'label-wrap-justify.ui',") ""))
> 
> There's no more comment about why this new test fails.  Is it known
> upstream?
This is not a new test failing, it is an old, uncommented test.

> >                ;; These tests fail on an Apple M1 (aarch64) with
> > the following errors:
> >                ;; - MESA: error: ZINK: failed to choose pdev
> >                ;; - libEGL warning: egl: failed to create dri2
> > screen
> > @@ -1391,7 +1373,7 @@ (define-public gtk
> >             vulkan-headers
> >             vulkan-loader                ;for vulkan graphics API
> > support
> >             wayland                      ;for wayland display-
> > backend
> > -           wayland-protocols))
> > +           wayland-protocols-next))
> 
> Instead of using -next things, perhaps we should byte the bullet and
> update them in this iteration too?
> 
> Using various variants of system means the system closure will be
> higher, may cause problems down the line (if the same process
> attempts to load two variants library in memory, that would cause
> issues).
I mean, we could, but I'm hesitant to be the one making this decision
not just for gtk, but mesa as well.  I do wish more folk were to chime
in on the state of gnome-team…

Cheers

reply via email to

[Prev in Thread] Current Thread [Next in Thread]