png: Correct endianness for big-endian machines

libpng wants to receive samples in either RGB or RGBA order, whether
each sample is big-endian or not. This resolves test failures in
testsuite/gdk/memorytexture.c (and a lot of reftests) on s390x, and
probably the PowerPC family too.

Modifying the test to show the color in use and write out the PNG bytes
to a file, and running the memorytexture test on s390x, produces a PNG
that loads with the correct color values in GIMP (on an x86_64 machine),
which seems like evidence that this is the correct change and not just
compensating errors.

Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/4616
Signed-off-by: Simon McVittie <smcv@debian.org>
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4357

Gbp-Pq: Name png-Correct-endianness-for-big-endian-machines.patch

build: Tell glib-compile-resources to make symbols internal where possible

Partial solution to https://gitlab.gnome.org/GNOME/gtk/-/issues/4598

Signed-off-by: Simon McVittie <smcv@debian.org>
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4334

Gbp-Pq: Name build-Tell-glib-compile-resources-to-make-symbols-interna.patch

Make our stack noexec

The change to use ld and objcopy for resources
had some side-effects: it leaked a few symbols
and made our stack executable. We don't want that.

Use -z nonexecstack and --strip-all to avoid this.

Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/4598

Gbp-Pq: Name Make-our-stack-noexec.patch

gtk4 (4.6.0+ds1-4) unstable; urgency=medium

  * Release to unstable

[dgit import unpatched gtk4 4.6.0+ds1-4]

Import gtk4_4.6.0+ds1-4.debian.tar.xz

[dgit import tarball gtk4 4.6.0+ds1-4 gtk4_4.6.0+ds1-4.debian.tar.xz]

Import gtk4_4.6.0+ds1.orig.tar.xz

[dgit import orig gtk4_4.6.0+ds1.orig.tar.xz]