Re: Bug#1081275: gtk4: gdk/memorytexture test failing in r16g16b16-float/ngl on mips64el only

[Simon McVittie]

On Tue, 10 Sep 2024 at 10:13:30 +0100, Simon McVittie wrote:
> I'm going to mark the 16-bit half-float
> tests to be skipped on mips64el and downgrade the severity of this bug to
> important. Anyone else is very welcome to investigate further.

Done in 4.16.0+ds-2. It's still a bug, just not RC any more.

To reproduce the bug, revert
debian/patches/workarounds/memorytexture-test-Ignore-failures-with-FP-softpipe-ngl-o.patch
and rebuild.

smcv

Bug#1081275: gtk4: gdk/memorytexture test failing in r16g16b16-float/ngl on mips64el only

[Simon McVittie]

Source: gtk4
Version: 4.15.6+ds-1
Severity: serious
Tags: experimental ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: m...@packages.debian.org, debian-m...@lists.debian.org
User: debian-m...@lists.debian.org
Usertags: mips64el
Control: block 1079548 by -1

After upgrading some lower-level component (my guess would be Mesa
24.1.x -> 24.2.x but I could be wrong), I'm seeing one test-case failing
in the memorytexture executable, in a gtk4 version where it previously
passed.

In different builds with different GTK4 versions, I'm variously seeing

# (0 0): 0.600098 1.00 0.199951 != 89920.00 89920.00 89920.00
# (1 0): 0.600098 1.00 0.199951 != 89920.00 89920.00 89920.00
# (2 0): 0.600098 1.00 0.199951 != 89920.00 89920.00 89920.00
...
# (109 271): 0.600098 1.00 0.199951 != 89920.00 89920.00 
89920.00
# (110 271): 0.600098 1.00 0.199951 != 89920.00 89920.00 
89920.00
# (111 271): 0.600098 1.00 0.199951 != 89920.00 89920.00 
89920.00
not ok 455 /memorytexture/download_random/r16g16b16-float/ngl

or

# (0 0): 0.00 1.00 0.199951 != -71104.00 1.00 0.199951
not ok 125 /memorytexture/download_1x1/r16g16b16-float/ngl

or

# r16g16b16-float (0 0): 0.533203 0.133301 0.533203 != 98240.00 -137.875000 
87.125000
not ok 125 /memorytexture/download_1x1/r16g16b16-float/ngl

In each case the left side of the "!=" is the pixel we expected to see,
and the right side is what we got.

The common factors are that this is using a 16 bits per channel half-float
texture format in conjunction with the NGL ("new" OpenGL) renderer. The
same test-case with the GL ("old" OpenGL) renderer is still working.
Unlike other bugs that have been seen on architectures where we use the
softpipe Mesa driver, this one seems to be specific to mips64el and does
not affect riscv64.

4.14.x in testing/unstable does not seem to be affected, but we are overdue
for uploading 4.15.x/4.16.x to unstable, which is blocking a lot of GNOME
libraries and applications.

I do not have any mips hardware or much remaining patience for
architecture-specific issues, so I'm going to mark the 16-bit half-float
tests to be skipped on mips64el and downgrade the severity of this bug to
important. Anyone else is very welcome to investigate further.

We could potentially mitigate any user-visible impact of this by forcing
use of GTK's "old" OpenGL renderer on mips64el, although that might
cause brokenness elsewhere (the "new" renderer is the default if Vulkan
is not available, and I suspect that the "old" renderer is essentially
unmaintained upstream).

smcv

Bug#1080477: gtk4: FTBFS on mips64el with Mesa 24.2.x: GALLIUM_DRIVER=softpipe no longer works

[Simon McVittie]

Source: gtk4
Version: 4.14.4+ds-8
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: m...@packages.debian.org, debian-m...@lists.debian.org, 
debian-powe...@lists.debian.org, debian-sp...@lists.debian.org
User: debian-m...@lists.debian.org
Usertags: mips64el

src:gtk4 uses GALLIUM_DRIVER=softpipe on mips*, powerpc and sparc* to work
around #1010838. Mesa 24.2.x is no longer built with softpipe enabled,
so this makes the softpipe driver fail to load and as a result makes (E)GL
initialization fail, breaking the test suite on these architectures, for
example:

> test: gtk:gsk / normalize
> ...
> not ok /node/normalize/color - 
> ERROR:../../../testsuite/gsk/normalize.c:18:test_normalize: assertion failed 
> (error == NULL): Could not initialize EGL display (gdk-gl-error-quark, 0)

Affected tests are

* gtk:gsk / normalize (run twice, for X11 and Wayland)
* gtk:gsk / misc (run twice, ditto)
* gtk:tools / validate (only run once, for Wayland)

I have only verified this on mips64el, but it probably affects the powerpc
and sparc64 -ports architectures equally.

My preferred solution for this would be for Mesa to re-enable softpipe,
at least on the affected architectures (I've opened a src:mesa bug #1080475
requesting that). If we stop using softpipe in gtk4 before Mesa 24.2.x
migrates to testing, then we will likely get a different failure mode
with the Mesa from testing: #1010838.

I'm doing a gtk4 build on the mips64el porterbox eberlin to assess whether
we can use the new ORCJIT llvmpipe and remove the workaround for #1010838,
but it's taking a while (mips64el machines are not fast). So far it's
looking as though we will still get quite a lot of test failures.

smcv

Bug#1080475: mesa: please re-enable softpipe, at least on architectures where llvmpipe is not yet mature

[Simon McVittie]

Source: mesa
Severity: important
Justification: causes FTBFS in at least src:gtk4
Tags: ftbfs
X-Debbugs-Cc: g...@packages.debian.org, debian-ri...@packages.debian.org, 
debian-loonga...@packages.debian.org, debian-m...@packages.debian.org
User: debian-m...@packages.debian.org
Usertags: mips64el
User: debian-ri...@packages.debian.org
Usertags: riscv64

Historically, Mesa's llvmpipe used LLVM MCJIT, which supports a limited
range of architectures and will not add more, and this resulted in
several architectures having either a broken llvmpipe or no llvmpipe
support at all.

With the recent upload of Mesa 24.2.x to unstable, llvmpipe now uses
ORCJIT for architectures where MCJIT is unavailable. However, the ORCJIT
version of llvmpipe doesn't seem to be particularly mature yet (perhaps
unsurprisingly, it's very new!) and is crashing under some circumstances
on at least riscv64: #1080435.

If softpipe was still enabled on at least the affected architectures,
then packages' test suites would be able to force its use via
GALLIUM_DRIVER=softpipe in the environment if necessary. At the
moment src:gtk4 does this on mips*, plus the powerpc and sparc* -ports
architectures, to avoid #1010838; the removal of the softpipe driver
means that this makes GL initialization fail, causing test failures and
a FTBFS (I'll report this as a separate RC bug in src:gtk4). I had hoped
to do the same for riscv64 to work around #1080435, but in fact this is
not possible for the same reason.

While it's more important on the ORCJIT architectures, also enabling
softpipe on more mainstream architectures like x86 would make it easier
for maintainers to compare llvmpipe with softpipe (without having to
build their package on porterboxes that are often very slow), and easier
to get a consistent test result for all architectures.

For what it's worth, the upstream default (with -Dgallium-drivers=auto)
is to enable softpipe on all architectures. In the Debian
packaging, I believe this would be most easily done by reverting
1ba4b2499e875266f6fbd7ba20068fb569986286 "rules: Build softpipe or
llvmpipe depending on the arch, not both.".

Thanks,
smcv

Bug#1080435: mesa: 24.2.x regression on riscv64: JIT session error, Failed to materialize symbols

[Simon McVittie]

Source: mesa
Version: 24.2.1-3
Severity: important
Justification: FTBFS in previously working package
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org, g...@packages.debian.org, 
llvm-toolchain...@packages.debian.org
Control: affects -1 + src:gtk4

gtk4 previously passed most of its build-time tests on riscv64, but it's
now failing on the riscv64 porterbox ricci. I initially thought this was a
regression in 4.15.x (in experimental) but in fact I can reproduce the
failure in the previously-working version in unstable. I think this might
be related to the addition of ORC JIT support in the new Mesa.

Steps to reproduce:
* set up a chroot with gtk4 build-dependencies
* build gtk4 (it will fail build-time tests)
* To run one of the affected tests:
  schroot -c $chroot -r -- \
  env GDK_DEBUG=opengl,vulkan,gl-debug GDK_BACKEND=x11 \
  xvfb-run -a \
  debian/build/deb/testsuite/gdk/memorytexture --tap -k

Expected result: test passes

Actual result:
> JIT session error: No HI20 PCREL relocation type be found for LO12 PCREL 
> relocation type
> Failed to materialize symbols: { (fs681_variant0_14, { fs_variant_linear2, 
> fs_variant_partial }) }
and the program exits with status 1.

You can run the same command and add "-l" to get a list of test-cases,
then run with e.g.
"-p /memorytexture/download_1x1/b8g8r8a8-premultiplied/local" to run a
single test-case. On a riscv64 machine with no access to a GPU, or with
LIBGL_ALWAYS_SOFTWARE=1, you should see that:

* /memorytexture/download_1x1/b8g8r8a8-premultiplied/local succeeds
  (this is a trivial case that doesn't touch OpenGL/Vulkan)
* /memorytexture/download_1x1/b8g8r8a8-premultiplied/gl, the "old GL"
  renderer, fails. This can use either OpenGL ES (default) or
  "desktop" OpenGL (add gl-prefer-gl to GDK_DEBUG).
* /memorytexture/download_1x1/b8g8r8a8-premultiplied/gl-released and
  /memorytexture/download_1x1/b8g8r8a8-premultiplied/gl-native, variations
  on the "old GL" renderer with different call patterns (I don't know the
  specifics), also fail.
* /memorytexture/download_1x1/b8g8r8a8-premultiplied/ngl, the "new GL"
  renderer, succeeds when using OpenGL ES, but fails when using "desktop"
  OpenGL (GDK_DEBUG="...,gl-prefer-gl")
* /memorytexture/download_1x1/b8g8r8a8-premultiplied/vulkan is skipped
  because GTK recognises that there is no real GPU.

Sorry, I don't know the specifics of what is "new" about the ngl renderer,
or really much about GL at all: please consult the gtk4 source code
for details.

testsuite/gdk/memorytexture is probably a good simple test to work with:
it copies textures to and from (the software emulation of) GPU memory,
and doesn't need many special environment variables set.

I'm also seeing test failures in testsuite/gsk/scaling, and in several
"reftests" (which render the same content two ways, one simple/hard-coded
and one more complicated, and assert that the rendering is the same).
Exact commands can be found in the build log.

Note that on a porterbox with no graphical desktop session running,
any command that includes "GDK_BACKEND=x11" will need to be run wrapped
in `xvfb-run -a`, and any command that includes "GDK_BACKEND=wayland"
will need to be run wrapped in `debian/tests/run-with-display wayland`,
and commands that do not set GDK_BACKEND should be runnable with either
sort of display.

riscv64 users: With the new Mesa, does GL software rendering work in
practice on riscv64 machines that have a real GUI? It's difficult for me
to assess the severity of this problem from a build log.

If the ORCJIT-based llvmpipe isn't reliable, a possible workaround would
be for riscv64 Mesa builds to provide softpipe instead, or to provide both
so that it can be switched at runtime with e.g. GALLIUM_DRIVER=softpipe.

smcv

-- Package-specific info:
glxinfo:

glxinfo is not available (missing mesa-utils package).

/usr/share/bug/xserver-xorg-core/script not available

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: riscv64

Kernel: Linux 6.10.6-riscv64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages mesa-libgallium depends on:
ii  libc6   2.40-2
ii  libdrm-amdgpu1  2.4.122-1
ii  libdrm-radeon1  2.4.122-1
ii  libdrm2 2.4.122-1
ii  libelf1t64  0.191-2
ii  libexpat1   2.6.2-2
ii  libgcc-s1   14.2.0-3
ii  libglapi-mesa   24.2.1-3
ii  libllvm18   1:18.1.8-9
ii  libsensors5 1:3.6.0-10
ii  libstdc++6  14.2.0-3
ii  libxcb-dri3-0   1.17.0-2
ii  libzstd11.5.6+dfsg-1
ii  zlib1g  1:1.3.dfsg+really1.3.1-1

mesa-libgallium recommends no packages.

mesa-libgallium suggests no packages.

-- no debconf information

Bug#1076825: mesa: new upstream rc 24.2.0~rc1 is likely to need NEW processing

[Simon McVittie]

On Tue, 23 Jul 2024 at 20:06:46 +0100, Simon McVittie wrote:
> I needed this version for a work project, so I did some draft packaging
> where libgallium.so is a new binary package mesa-libgallium,
> which libglx-mesa0, libegl-mesa0 and libgbm1 all depend on.

https://salsa.debian.org/xorg-team/lib/mesa/-/merge_requests/44 is a newer
version of that draft packaging, which updates to 24.2.0~rc2 (in which
libgallium.so has been renamed at my suggestion, to make its loading
somewhat more robust).

smcv

Re: Bug#1058687: gnome-shell: ftbfs on riscv64 due to tests failed

[Simon McVittie]

On Wed, 24 Jul 2024 at 18:35:54 +0800, Bo YU wrote:
> The good news is that llvmpipe support riscv64 with orcjit has been
> merged[0]!
> 
> [0]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26018

That's great news. I hope that this can be extended to other problematic
architectures like mips64el in future.

> New upstream release fixed the issue see[0]:
> https://buildd.debian.org/status/logs.php?pkg=gnome-shell&arch=riscv64

No, the new upstream release works around the issue, allowing it to be
downgraded from RC. The test suite is run with `--no-suite shell`,
first on mips* and then on all architectures.

The fact that a package does not FTBFS does not necessarily imply that
its tests pass: sometimes we are forced to disable failing tests because
Debian's policy around release architectures means that the alternative
would be removing GNOME from Debian, which would be a disservice to
our users.

smcv

Bug#1076825: mesa: new upstream rc 24.2.0~rc1 is likely to need NEW processing

[Simon McVittie]

Source: mesa
Version: 24.1.3-2
Severity: wishlist
Tags: trixie sid patch

A new upstream release candidate is available, 24.2.0~rc1.

This adds a new private library libgallium.so which is a new dependency
for libGLX_mesa.so.0, libEGL_mesa.so.0 and libgbm.so.1, and therefore
is likely to need a new binary package and NEW processing. It would
probably be useful to get an experimental upload of this into the queue
before it becomes time-sensitive.

I needed this version for a work project, so I did some draft packaging
where libgallium.so is a new binary package mesa-libgallium,
which libglx-mesa0, libegl-mesa0 and libgbm1 all depend on. Please see

which has more information about the handling and potential future changes
of libgallium. The name "mesa-libgallium" is a matter of taste, please
feel free to change it if something else seems more appropriate.

The Mesa maintainers are welcome to make use of the referenced branch in
my MR if it would be useful to you.

Thanks,
smcv

Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore

[Simon McVittie]

On Mon, 10 Jun 2024 at 12:35:25 +0200, gru...@laposte.net wrote:
> Among GNOME settings, I have three choices available:
> Français
> Français Azerty
> Français Azerty (AFNOR)

There should be a lot more than that. I don't speak French, but in an
English-language GNOME installation on Debian 12, if I click on "Other"
and search for French, choices available to me include:

* French (alt.)
* French (alt., Latin-9 only)
* French (alt., no dead keys)
* French (legacy, alt.)
* French (legacy, alt., no dead keys)
* French (no dead keys)

... and many more. Many of these are AZERTY layouts even though their
names don't specifically say so.

Based on the information in /usr/share/X11/xkb/symbols/fr, it seems that
"French (legacy, alt.)" should be an AZERTY layout where AltGr+[7] is a
"dead_grave" dead key.

If I'm reading the translation files correctly, the French translation
of "French (legacy, alt.)" might be "Français (obsolète, variante)".

I am not a French speaker and I am not familiar with the history
of French keyboard layouts, so I cannot say whether you are right
or wrong to expect that AltGr+[7] should be a dead key. Perhaps
 would be able to clarify
whether there is a bug in xkb-data or not.

Based on the information available in this bug report, I'm confident that
GLib is now doing the right thing, so this is not a GLib bug.

> Français
> Français Azerty
> don't fire dead keys on the first row of keys
> but
> Français Azerty (AFNOR)
> does. Strange...

If you think this is a regression when compared with older versions of
Debian, then the xkb-data maintainers will need to know the answer to
this question:

What was the most recent date when your keyboard had the behaviour
that you expected, and what version of Debian were you running at
that time?

Thanks,
smcv

Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore

[Simon McVittie]

On Mon, 10 Jun 2024 at 05:48:44 +0200, gru...@laposte.net wrote:
> I did a
> $ sudo dpkg-reconfigure keyboard-configuration

This changes the keyboard layout that is used for the login screen, and
for any session that does not have its own, separate configuration.
It does not change the keyboard layout for sessions that have already
saved their own session-specific configuration.

> $ dconf dump /org/gnome/desktop/input-sources/
> [/]
> show-all-sources=false
> sources=[('xkb', 'fr+azerty')]
> xkb-options=['lv3:ralt_switch']

Your personal GNOME configuration is still using fr+azerty. If you want
a different layout while you are logged in to GNOME, you will need to
reconfigure that in the Settings application (gnome-control-center).

If you want to reset the layout used within GNOME to match the layout
used by the login screen, you can run

dconf reset /org/gnome/desktop/input-sources/sources

and then log out and back in.

> On logscreen then, and still now, I have the french keyboard
> BUT with the ! (exclamation mark) replaced by the ; (semicolon)

That's the AFNOR layout that you selected. Several other punctuation marks
are in different places in the AFNOR layout: see 
for details.

If you don't want the punctuation to move around in this way, then you
should not select the AFNOR variant.

https://norme-azerty.fr/ shows "AZERTY traditionnel" which is something
similar to the layout you were previously using, and
"Nouvel AZERTY" which is the layout that is labelled as AFNOR in Debian.

smcv

Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore

[Simon McVittie]

Control: reassign -1 xkb-data 2.35.1-1

On Sun, 09 Jun 2024 at 23:13:32 +0200, gru...@laposte.net wrote:
> XKBMODEL="pc105"
> XKBLAYOUT="fr"
> XKBVARIANT="azerty"
(and)
> $ dconf dump /org/gnome/desktop/input-sources/
> [/]
> show-all-sources=false
> sources=[('xkb', 'fr+azerty')]
> xkb-options=['lv3:ralt_switch']

It seems that instead of the "default" French keyboard, you're using a
French keyboard variant named "azerty". This confuses me, because I
thought the "default" French keyboard layout is already an AZERTY
layout, so specifying AZERTY seems redundant... but the two layouts
seem to be maybe different?

What was the most recent date when your keyboard had the behaviour
that you expected, and what version of Debian were you running at
that time?

> What I notice, is that when I type the backtick character, even on a terminal,
> it doesn't wait without displaying nothing (like previous versions of Debian
> did) or doesn't wait showing the backtick underlined
> like it does when I use the ^ dead key.

That's the expected behaviour on keyboard layouts where the backtick is
just a backtick and not a dead key, like my UK English. In these layouts,
the data file defining the keyboard layout would say "grave".

The behaviour you were hoping for (waits while displaying an underlined
backtick/accent) is what is expected in keyboard layouts where the
backtick is defined to be a dead key, like German. In these layouts, the
data file defining the keyboard layout would say "dead_grave".

Some French keyboard layouts have AltGr+[7] as a backtick ("grave"), like
it is for the similarly labelled key in UK English. Others have AltGr+[7]
as a dead key ("dead_grave"), like it for the similarly labelled key in
German. So, it matters which exact variant you have selected.

It seems that your keyboard layout is one of the variants with "grave"
but you were expecting that it should have "dead_grave". This could
be because your configuration has changed, or because your configured
variant has stayed the same but its meaning has changed. I don't know
what component that would be a bug in, but it isn't GLib that controls
this, so it seems very unlikely to be a GLib regression.

The "default" French keyboard layout is probably labelled in the UI as
just "Français" or similar, with no other information. In that layout,
as far as I can see from /usr/share/X11/xkb/symbols/fr, the symbol you
get from typing AltGr+[7] is "grave", so it is intentionally not a dead
key (same as the backtick on a UK English keyboard).

But, there are several different layouts listed in
/usr/share/X11/xkb/symbols/fr. Some of them have AltGr+[7] mapped to
"dead_grave", which *is* a dead key (same as the backtick on a German
keyboard). The ones I can find that have that behaviour are
identified as "French (legacy, alt.)" and "French (Breton)" (but Breton
is not an AZERTY layout so probably you don't want that one).

"French (legacy, alt.)" might be identified as "Français (obsolète,
variante)" with French language settings.

Your current configuration with XKBVARIANT="azerty" and
sources=[('xkb', 'fr+azerty')] should mean that you are using the
"azerty" variant (lines 1059 to 1141 in /usr/share/X11/xkb/symbols/fr
from xkb-data version /usr/share/X11/xkb/symbols/fr) and in that variant,
as far as I can see, AltGr+[7] is not intended to be a dead key.

There is also a variant "French (AZERTY, AFNOR)" which moves the
"dead_grave" dead key from AltGr+[7] to AltGr+[3], while providing
it as a dead key.

If the French-speaking community considers the layouts in
/usr/share/X11/xkb/symbols/fr to be wrong, then that would be something
that would need to be fixed in xkb-data (part of xkeyboard-config).
I don't know whether what you expected is the same as what the
French-speaking community would expect.

> When I'm using the ` dead key, I :
> 1. type ` and see on screen:  ` immediately, and with no underline
> 2. the terminal or editor doesn't wait for me to type another character
> especially.
> 3. I type any other character.  `z, `a...
> In fact, ` isn't considered as a dead char at all.

All of this is consistent with your [`] behaving as an ordinary backtick
key (not a dead key), like the one on a UK English keyboard.

> interesting! while the ^ key right to the P on the french keyboard, provides a
> ^ that is a dead char and returns an ê
> the ^ given by a e isn't a dead char!

That's what /usr/share/X11/xkb/symbols/fr says. I don't know whether that's
what a typical French keyboard user would expect, but it's what the xkb
data says should happen; so if this is wrong behaviour, that would be an
xkb-data bug.

> It's the top row of keys of a 102 or 105 keyboard that would not fire dead 
> keys
> anymore?

I don't know whether it's as consistent as that: like I said, it depends
which exact variant is configured.

I didn't know anything about French keyboard layouts until today,
and /usr/share/X11/xkb/symbols/fr has all the information that I'm
referring to, so

Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore

[Simon McVittie]

On Sun, 09 Jun 2024 at 18:16:01 +0100, Simon McVittie wrote:
> However, the French layout in /usr/share/X11/xkb/symbols/fr says that
> pressing the 7 key (with AltGr held) sends "grave" like my UK English
> layout, and not "dead_grave" like the German layout. So if that previously
> participated in dead-key sequences, I don't understand why...

Were you perhaps using the "latin9" or "French (legacy, alt.)" keyboard
layout before? Unlike the default French keyboard layout, the latin9 layout
*does* map AltGr+[7] to "dead_grave", a dead key.

I don't know the name of that keyboard layout in French - it might be
"Français (obsolète, variante)". Perhaps a French-speaking developer
could help here?

What is the output of these commands?

cat /etc/default/keyboard

and

dconf dump /org/gnome/desktop/input-sources/

Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore

[Simon McVittie]

ibus and xkeyboard-config maintainers and debian-l10n-french cc'd in
the hope that someone understands what is happening here, because I dont
think this is actually a libglib2.0-0 bug.

On Sun, 09 Jun 2024 at 17:23:27 +0200, gru...@laposte.net wrote:
> When you did the fix that repaired most of the #1070745, didn't you
> forget to enable/check the rules for keyboards having backtick for
> grave accent?

That's not how #1070745 was fixed: I didn't change the rules for any
specific keyboard layout. The bug that caused #1070745 was that a
security fix in GLib broke the communication between applications and
ibus, so *all* dead keys stopped working (and so did everything else
that goes via ibus, like Compose key combinations). I fixed #1070745 by
making GLib's security checks less strict, so that ibus could work again.

In the bug you've reported, the dead-keys feature does work in general
(I know this because you say you can still type [^],[e] and get ê),
so ibus must be *mostly* working - but there must be a more specific problem
that affects the [`],Shift+[A] sequence, at least with your settings.

Please look at /var/log/apt/history.log. What other packages did you update
at around the time that this stopped working for you? Is there a
recently-updated package that you can downgrade that gives you the old
behaviour back?

> With most keyboards, most languages, `A doesn't give À
> But with some, like the French one that has the backtick for grave accent 
> too, it should return À

Yes: on many keyboard layouts that have a key marked [`], it's expected
to be only a backtick symbol, and doesn't act as a dead key. The German
layout that I tested is unusual in having [`] available as a dead key
which can be combined with letters to get an accented letter.

On my UK English keyboard layout /usr/share/X11/xkb/symbols/gb, the key
marked [`] sends xkb symbol "grave", which is not a dead key. US English
/usr/share/X11/xkb/symbols/us is similar.

On the German layout that I tested, /usr/share/X11/xkb/symbols/de,
the key to the left of Backspace (with Shift held) sends xkb symbol
"dead_grave", which *is* a dead key.

However, the French layout in /usr/share/X11/xkb/symbols/fr says that
pressing the 7 key (with AltGr held) sends "grave" like my UK English
layout, and not "dead_grave" like the German layout. So if that previously
participated in dead-key sequences, I don't understand why...

According to the same file, if you press AltGr + [*] (the key printed with
* and µ, between Shift and $) then *that* should send "dead_grave", which
is a dead key that can be followed by a letter to get a grave accent.

> => Please note that ^e gives ê correctly
> but `A doesn't

What about [`],[e], or [`],[a], or other sequences involving the dead-key
grave accent?

Or, the other way around: do you expect [^],Shift+[e] to give you Ê,
and if yes, what does it actually do?

Or similar sequences?

When you say you are typing ` followed by A, what exact keys are you
pressing? You say that ` is on the 7 key, but based on the diagram you
linked, pressing the 7 key without Shift should be è.

I think when you say you type `A and expect to get À, what you are
typing is actually: AltGr + [7], Shift + [A]. Is that correct?
Or if not, what?

Similarly, when you say you are typing ^ followed by e, what exact
keys are you pressing? Is it the key between P and $, followed by [E]?
Or is it AltGr+[9] followed by [E]?

If I'm reading correctly, the key between P and $ is expected to be a
"dead_circumflex" (which is part of dead-key sequences) but AltGr+[9]
is meant to be an "asciicircum" which is not a dead key.

smcv

Bug#1038447: librsvg: FTBFS on big-endian architectures: multiple test regressions since September 2022

[Simon McVittie]

Control: tags -1 + fixed-upstream
Control: block -1 by 1061616
Control: retitle 1061616 pixman: New upstream version 0.43.4

On Mon, 29 Jan 2024 at 10:23:45 +, Simon McVittie wrote:
> On Mon, 29 Jan 2024 at 05:13:59 +, Gayathri Berli wrote:
> > we found out that while
> > upgrading libpixman (libpixman-1-0:s390x) package from version 0.40.0-1 to
> > version 0.42.2-1, the test suites failed in the librsvg.
...
> > There is one open issues in pixman regarding to this commit changes which
> > effecting the big-endian systems.

I've been told in private email that
https://gitlab.freedesktop.org/pixman/pixman/-/issues/78 was fixed in the
recent pixman 0.43.4 release.

As noted in https://bugs.debian.org/1061616, pixman upstream has stopped
using the odd/even minor version convention (as seen in GLib, dbus,
Flatpak, SDL, etc.) and switched to a versioning scheme where odd and
even minor versions are interchangeable, so 0.43.x is a stable relase
series even though 0.41.x was not.

pixman maintainers: please upgrade to 0.43.4 when it will not disrupt
the ongoing 64-bit time_t transition.

Thanks,
smcv

Bug#1065816: weston: Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>= 0.7.0'

[Simon McVittie]

Control: block 1036884 by -1

On Sun, 10 Mar 2024 at 10:37:51 +0100, Aurelien Jarno wrote:
> weston fails to build in unstable since the upload of neatvnc in version
> 8.0. From my build log on amd64:
...
> | Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>= 
> 0.7.0'

This is important for the 64-bit time_t transition, because weston is
part of that transition, and also because packages like gtk4 use weston in
headless mode to test their Wayland backends. This could be mitigated by
temporarily making gtk4 skip its Wayland tests on 32-bit architectures,
but with gtk4 hat on, I would not be comfortable with doing that in
the long term, because in practice it seems to be inevitable that
functionality that isn't tested doesn't actually work.

Looking at the recent neatvnc upload, I was surprised to see that its
former maintainer updated it to a new upstream release in the same upload
as orphaning it (#1065738), and also updated the closely-related wayvnc
package to a new upstream release that matches neatvnc.

I also noticed that neatvnc 0.8.0 has an ABI break without bumping the
SONAME (#1065824), although that might be ignorable since nothing in
Debian seems to use the affected symbol.

I think the options here in the short term are:

1. adapt weston to support neatvnc 0.8.0, if it's straightforward to do so;
2. revert neatvnc to 0.8.0+really0.7.1+dfsg and wayvnc to 0.8.0+really0.7.2,
   and revisit this later, when we are *not* in the middle of a transition
   that touches thousands of packages;
3. temporarily disable the VNC backend in weston, and revisit this later

I would personally be very tempted by (2.) since it seems like the option
with least risk of regressions when compared with what's currently in
trixie, but I have no particular knowledge of these packages, so it
would be better if the maintainers of weston and/or wayvnc could adopt
neatvnc and handle this in whatever way they prefer. If this situation
is not resolved then I might do the revert (2.), by QA-uploading neatvnc
and NMU'ing wayvnc.

Thanks,
smcv

Bug#1065824: libneatvnc0: ABI break in 0.8.0 without SONAME bump

[Simon McVittie]

Package: libneatvnc0
Version: 0.8.0+dfsg-1
Severity: important
Justification: Policy 8.6.2
Tags: upstream
X-Debbugs-Cc: wes...@packages.debian.org, way...@packages.debian.org

libneatvnc 0.8.0 removes a public function from its API/ABI:

│ -const char* nvnc_client_get_hostname(const struct nvnc_client* client);
│ +int nvnc_client_get_address(const struct nvnc_client* client,
│ + struct sockaddr* restrict addr, socklen_t* restrict addrlen);

>From codesearch.debian.net, it seems that nothing in Debian actually calls
nvnc_client_get_hostname(), so perhaps this is non-RC. Normally I'd be
saying this is a decision for its maintainer, but it was recently orphaned
(in the same upload that updated it to this new upstream version, which
seems an unusual choice), so now it's a decision for whoever takes over
maintenance.

If important packages like weston are going to have dependencies on
neatvnc, then I think it would be helpful for whoever takes over this
package to teach its upstream about the two options for ABI stability
(briefly: either don't break ABI, or do break ABI but at the same time
also bump the SONAME).

smcv

Re: Bug#1064704: gtk4: FTBFS: one run of gtk:tools / validate test failed

[Simon McVittie]

Control: tags -1 + confirmed

Context for Mesa maintainers: gtk4 passed its build-time tests on
2024-01-29, but is now failing in a test rebuild. I can reproduce this,
and I think it's a regression triggered by Mesa changes (see also
https://gitlab.freedesktop.org/mesa/mesa/-/issues/10293 upstream).

On Sun, 25 Feb 2024 at 20:37:28 +0100, Lucas Nussbaum wrote:
> > 1332/1515 gtk:tools / validate  
> > FAIL
> > 2.07s   0/9 subtests passed
> > >>> GDK_BACKEND=x11 G_ENABLE_DIAGNOSTIC=0 
> > >>> GTK_QUERY_SETTINGS=/<>/debian/build/deb/tools/gtk4-query-settings
> > >>>  MALLOC_PERTURB_=208 
> > >>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
> > >>> GTK_A11Y=test GDK_DEBUG=default-settings GTK_CSD=1 
> > >>> GTK_BUILDER_TOOL=/<>/debian/build/deb/tools/gtk4-builder-tool
> > >>>  GSETTINGS_SCHEMA_DIR=/<>/debian/build/deb/gtk 
> > >>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
> > >>>  
> > >>> TEST_RESULT_DIR=/<>/debian/build/deb/testsuite/tools/output
> > >>>  GSETTINGS_BACKEND=memory 
> > >>> G_TEST_BUILDDIR=/<>/debian/build/deb/testsuite/tools 
> > >>> G_TEST_SRCDIR=/<>/testsuite/tools TEST_OUTPUT_SUBDIR=x11 
> > >>> /usr/bin/bash validate

Unfortunately, the only log output for this was:

1..9
not ok 1 invalid1
not ok 2 invalid2
not ok 3 invalid3
not ok 4 invalid4
not ok 5 invalid5
not ok 6 valid1
not ok 7 valid2
not ok 8 valid3
not ok 9 valid4

I notice that many tests have this stderr output:

> MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
> libEGL warning: egl: failed to create dri2 screen
> MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
> glx: failed to create drisw screen
> failed to load driver: zink

Looking at the implementation of the testsuite/tools/validate test,
the way it works is: run GTK's validator against a valid or invalid
input, compare the resulting stderr with what was expected, and fail if
they differ. I think the reason why it's failing is that it's seeing this
extra stderr from Zink.

Obviously, this is quite fragile, because anything that emits a diagnostic
message can break it; but I also don't see any way for GTK upstream to get
the behaviour they want ("assert that the validator produces the messages
that we think it should") without that fragility.

Could this output to stderr in Zink perhaps be reconsidered upstream?

smcv

Bug#1061768: vulkan-loader: new upstream release 1.3.275.0

[Simon McVittie]

Source: vulkan-loader
Version: 1.3.268.0-1
Severity: wishlist

A new upstream release vulkan-sdk-1.3.275.0 is available.

smcv

Re: Bug#1038447: librsvg: FTBFS on big-endian architectures: multiple test regressions since September 2022

[Simon McVittie]

Control: reassign -1 libpixman-1-0 0.42.2-1
Control: affects -1 + librsvg
Control: tags -1 + upstream
Control: forwarded -1 https://gitlab.freedesktop.org/pixman/pixman/-/issues/78

On Mon, 29 Jan 2024 at 05:13:59 +, Gayathri Berli wrote:
> After a lot of debugging, by upgrading librsvg and its dependency packages one
> after another like libcairo, libpixman and libpango, we found out that while
> upgrading libpixman (libpixman-1-0:s390x) package from version 0.40.0-1 to
> version 0.42.2-1, the test suites failed in the librsvg.
> 
> I built these packages ( i.e. cairo, pixman & pango) manually from their
> respective sources by resolving all the version dependencies and ran the
> librsvg tests to make sure that the test suites failed while upgrading pixman
> package from 0.40.0-1 to version 0.42.2-1..
> 
> By doing git-bisect on pixman package commits, I figured out the below
> mentioned commit which has changes w.r.t. big-endian architectures, introduced
> the regression.. But I checked the main line repo of pixman and I see that the
> test suites are passing. I will check further on this and post my updates...!
> 
> commit b4a105d77232a87304b7b621e2f99e699a8eebd3
> Author: Jocelyn Falempe <[1]jfale...@redhat.com>
> Date:   Wed Jun 29 10:55:43 2022 +0200
> 
> Fix inverted colors on big endian system
> 
> bits_image_fetch_separable_convolution_affine() didn't take care
> of big endian system
> 
> Signed-off-by: Jocelyn Falempe <[2]jfale...@redhat.com>
> 
>  There is one open issues in pixman regarding to this commit changes which
> effecting the big-endian systems.
> 
> [3]https://gitlab.freedesktop.org/pixman/pixman/-/issues/78
> 
> [4]https://gitlab.freedesktop.org/pixman/pixman/-/issues/72

Thanks, reassigning the Debian bug from librsvg to pixman.

smcv

Bug#1060779: src:mesa: fails to migrate to testing for too long: unavailable Build-Depends on mips64el

[Simon McVittie]

On Sun, 14 Jan 2024 at 08:39:52 +0100, Paul Gevers wrote:
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:mesa has been trying to migrate for 31 days [2].
> Hence, I am filing this bug. The version in unstable build depends on
> binaries from llvm-toolchain-17, which haven't been built on mips64el yet
> (reported in bug 1056116).

Adding mips64el porting team to Cc for visibility.

Mesa could probably work around this by disabling the LLVM parts on
mips64el (removing mips64 from LLVM_ARCHS in d/rules and from various
lists of LLVM-capable architectures in d/control).

The cost would be that most mips64el users would have to use slow
fallback software rendering, because disabling LLVM support would
disable llvmpipe (which it seems doesn't actually work properly
on mips* in any case) but also the AMD driver (which is what
graphical MIPS users rely on in practice, according to discussion on
https://salsa.debian.org/gnome-team/gnome-shell/-/merge_requests/71).

That's a high cost for mips64el users, but the alternative seems to be
letting mips64el hold back all of our other architectures, and I don't
think that's really viable.

Thanks,
smcv

Bug#1060849: mesa: FTBFS on armel: static assertion failed: "vn_ring_shared requires lock-free 32-bit atomic_uint"

[Simon McVittie]

Source: mesa
Version: 23.3.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-...@lists.debian.org
User: debian-...@lists.debian.org
Usertags: armel
Control: block 1060779 by -1

The armel baseline does not have lock-free atomic operation opcodes. The
result is a build failure:

https://buildd.debian.org/status/fetch.php?pkg=mesa&arch=armel&ver=23.3.3-1&stamp=1705055313&raw=0
> In file included from ../src/util/u_math.h:43,
>  from ../src/virtio/vulkan/vn_common.h:35,
>  from ../src/virtio/vulkan/vn_buffer.h:14,
>  from ../src/virtio/vulkan/vn_buffer.c:11:
> ../src/virtio/vulkan/vn_ring.h:40:1: error: static assertion failed: 
> "vn_ring_shared requires lock-free 32-bit atomic_uint"
>40 | static_assert(ATOMIC_INT_LOCK_FREE == 2 && sizeof(atomic_uint) == 4,

Could this perhaps be solved by disabling the virtio driver on armel?

Thanks,
smcv

Re: Bug#1058687: gnome-shell: ftbfs on riscv64 due to tests failed

[Simon McVittie]

(cc -= release team, += Mesa)

On Fri, 15 Dec 2023 at 18:52:58 +0100, Aurelien Jarno wrote:
> On 2023-12-15 11:11, Simon McVittie wrote:
> > On Thu, 14 Dec 2023 at 21:59:19 +0800, Bo YU wrote:
> > > 10/12 gnome-shell:shell / perf-basic  FAIL   
> > > 189.57s   exit status 1
> > > 11/12 gnome-shell:shell / perf-closeWithActiveWindows FAIL
> > > 76.88s   exit status 1
> > > 12/12 gnome-shell:shell / perf-headlessStart  FAIL   
> > > 100.23s   exit status 1
> > 
> > It seems likely that this is a bug in Mesa or LLVM (specifically, Mesa's
> > software rendering drivers) rather than a bug in GNOME Shell.
...
> > I notice from the Mesa changelog that recent uploads of Mesa enabled
> > LLVM JIT on riscv64. Does that solve this bug?
> 
> No it doesn't, and actually made things worse, many packages like gtk4
> will now FTBFS. I reported the issue as #1058759.

That's unfortunate, and I hope that can be resolved soon.

> Work to support orcjit in
> mesa is be done by the riscv community and will eventually benefit
> all architectures when mcjit support gets removed from LLVM.

That's great to hear, and sounds like a much more sustainable thing for
the longer term.

> Alternatively it softpipe should be
> improved to provide an exact same rendering as llvmpipe.

Some of the bugs I've seen involving mips64el have been "this reftest is
misrendered by softpipe", and I'm willing to disable those on softpipe
architectures, especially if a porter for the relevant architecture can
confirm that on real hardware, everything is fine.

The ones I'm more concerned about are the bugs of the form "this test-case
crashes when using softpipe", and as far as I can tell, the gnome-shell
test failures under discussion in this particular bug report are in
that category: with softpipe, the Shell doesn't render the wrong pixels
successfully, it just doesn't work at all. But maybe I'm reading the
log wrong?

smcv

Bug#1053864: libdrm-amdgpu1: gpu crash on graphics start with Radeon 760M (both sway and gdm3)

[Simon Heath]

Oop, my bad.  I was wondering why I hadn't seen it go through on the bug 
report...


The issue is still present in apt package linux-image-6.5.0-3 (Kernel 
6.5.8-1) , and linux-image-6.5.0-4 (kernel 6.5.10-1). Same messages, as 
far as I can see, but here's the dmesg output from the 6.5.10-1 kernel 
in case there's something subtly different.


Thanks,
Simon





[    7.490078] ucsi_acpi USBC000:00: ucsi_handle_connector_change: 
GET_CONNECTOR_STATUS failed (-5)

[    7.605873] ucsi_acpi USBC000:00: possible UCSI driver bug 1
[    7.605903] ucsi_acpi USBC000:00: ucsi_handle_connector_change: 
GET_CONNECTOR_STATUS failed (-22)
[   13.555707] pipewire[1065]: memfd_create() called without MFD_EXEC or 
MFD_NOEXEC_SEAL set
[   23.808871] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 
timeout, signaled seq=23, emitted seq=25
[   23.809320] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process 
information: process  pid 0 thread  pid 0

[   23.809592] amdgpu :c1:00.0: amdgpu: GPU reset begin!
[   23.990678] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   23.990842] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   24.124228] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   24.124374] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   24.257754] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   24.257918] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   24.391326] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   24.391555] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   24.525068] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   24.525211] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   24.658617] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   24.658758] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   24.792155] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   24.792326] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   24.925815] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   24.925961] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[   25.059344] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   25.059488] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue

[   25.061023] amdgpu :c1:00.0: amdgpu: MODE2 reset
[   25.090107] amdgpu :c1:00.0: amdgpu: GPU reset succeeded, trying 
to resume
[   25.090767] [drm] PCIE GART of 512M enabled (table at 
0x00801FD0).

[   25.090889] amdgpu :c1:00.0: amdgpu: SMU is resuming...
[   25.092526] amdgpu :c1:00.0: amdgpu: SMU is resumed successfully!
[   25.094267] [drm] DMUB hardware initialized: version=0x08000E00
[   25.101834] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:264
[   25.104428] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:272
[   25.107025] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:280
[   25.109617] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:288
[   25.117187] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:264
[   25.119782] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:272
[   25.122380] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:280
[   25.124993] [drm] REG_WAIT timeout 1us * 1000 tries - 
dcn314_dsc_pg_control line:288

[   25.534004] [drm] kiq ring mec 3 pipe 1 q 0
[   25.536314] [drm] VCN decode and encode initialized 
successfully(under DPG Mode).
[   25.536470] amdgpu :c1:00.0: [drm:jpeg_v4_0_hw_init [amdgpu]] 
JPEG decode initialized successfully.
[   25.537196] amdgpu :c1:00.0: amdgpu: ring gfx_0.0.0 uses VM inv 
eng 0 on hub 0
[   25.537200] amdgpu :c1:00.0: amdgpu: ring comp_1.0.0 uses VM inv 
eng 1 on hub 0
[   25.537202] amdgpu :c1:00.0: amdgpu: ring comp_1.1.0 uses VM inv 
eng 4 on hub 0
[   25.537204] amdgpu :c1:00.0: amdgpu: ring comp_1.2.0 uses VM inv 
eng 6 on hub 0
[   25.537206] amdgpu :c1:00.0: amdgpu: ring comp_1.3.0 uses VM inv 
eng 7 on hub 0
[   25.537208] amdgpu :c1:00.0: amdgpu: ring comp_1.0.1 uses VM inv 
eng 8 on hub 0
[   25.537210] amdgpu :c1:00.0: amdgpu: ring comp_1.1.1 uses VM inv 
eng 9 on hub 

Bug#1053864: libdrm-amdgpu1: gpu crash on graphics start with Radeon 760M (both sway and gdm3)

[Simon Heath]

mdgpu :c1:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 
on hub 0
[   28.331977] amdgpu :c1:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 
on hub 0
[   28.331979] amdgpu :c1:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 
on hub 0
[   28.331981] amdgpu :c1:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 
on hub 0
[   28.331983] amdgpu :c1:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 
on hub 0
[   28.331985] amdgpu :c1:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on 
hub 0
[   28.331987] amdgpu :c1:00.0: amdgpu: ring vcn_unified_0 uses VM inv eng 
0 on hub 8
[   28.331990] amdgpu :c1:00.0: amdgpu: ring jpeg_dec uses VM inv eng 1 on 
hub 8
[   28.331992] amdgpu :c1:00.0: amdgpu: ring mes_kiq_3.1.0 uses VM inv eng 
13 on hub 0
[   28.334786] amdgpu :c1:00.0: amdgpu: recover vram bo from shadow start
[   28.334791] amdgpu :c1:00.0: amdgpu: recover vram bo from shadow done
[   28.334933] [drm] Skip scheduling IBs!
[   28.334955] [drm] Skip scheduling IBs!
[   28.334964] [drm] Skip scheduling IBs!
[   28.334971] [drm] Skip scheduling IBs!
[   28.334979] [drm] Skip scheduling IBs!
[   28.334987] [drm] Skip scheduling IBs!
[   28.334995] [drm] Skip scheduling IBs!
[   28.335006] [drm] Skip scheduling IBs!
[   28.335014] [drm] Skip scheduling IBs!
[   28.335070] [drm] Skip scheduling IBs!
[   28.335079] [drm] Skip scheduling IBs!
[   28.335085] [drm] Skip scheduling IBs!
[   28.336265] [drm] ring gfx_32776.1.1 was added
[   28.337256] [drm] ring compute_32776.2.2 was added
[   28.338182] [drm] ring sdma_32776.3.3 was added
[   28.338234] [drm] ring gfx_32776.1.1 ib test pass
[   28.338272] [drm] ring compute_32776.2.2 ib test pass
[   28.338470] [drm] ring sdma_32776.3.3 ib test pass
[   28.339726] amdgpu :c1:00.0: amdgpu: GPU reset(1) succeeded!
[   28.518882] [drm] Skip scheduling IBs!
[   28.518892] [drm] Skip scheduling IBs!
[   28.518897] [drm] Skip scheduling IBs!
[   28.520085] [drm] Skip scheduling IBs!
[   28.521361] [drm] Skip scheduling IBs!
[   28.541083] [drm] Skip scheduling IBs!
[   28.541114] [drm] Skip scheduling IBs!
[   28.541143] [drm] Skip scheduling IBs!
[   28.541159] [drm] Skip scheduling IBs!
[   28.541173] [drm] Skip scheduling IBs!
[   28.541193] [drm] Skip scheduling IBs!
[   28.541215] [drm] Skip scheduling IBs!
[   28.541219] [drm] Skip scheduling IBs!
[   28.541239] [drm] Skip scheduling IBs!


I also get the following errors in dmesg from time to time, but they have no 
visible impact so far:

[ 1046.269344] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* 
wait_for_completion_timeout timeout!
[ 1056.509203] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* 
wait_for_completion_timeout timeout!
[ 1066.749132] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* 
wait_for_completion_timeout timeout!
[ 1076.988590] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* 
wait_for_completion_timeout timeout!
[ 1087.228896] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* 
wait_for_completion_timeout timeout!
[ 1094.983205] i2c_hid_acpi i2c-FRMW0005:00: i2c_hid_get_input: incomplete 
report (7/65535)
[ 1097.468792] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* 
wait_for_completion_timeout timeout!
[ 1107.708726] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* 
wait_for_completion_timeout timeout!
[ 1117.948141] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* 
wait_for_completion_timeout timeout!
[ 1128.188485] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* 
wait_for_completion_timeout timeout!
[ 1138.428402] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* 
wait_for_completion_timeout timeout!
[ 1148.668306] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* 
wait_for_completion_timeout timeout!
[ 1158.908169] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* 
wait_for_completion_timeout timeout!
[ 1169.147619] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* 
wait_for_completion_timeout timeout!
[ 1179.387933] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* 
wait_for_completion_timeout timeout!


Thank you, hopefully this info is useful to someone!

Simon Heath


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libdrm-amdgpu1 depends on:
ii  libc62.37-12
ii  libdrm2  2.4.115-1

libdrm-amdgpu1 recommends no packages.

libdrm-amdgpu1 suggests no packages.

-- no debconf information

Bug#1052464: x11-apps: [xwd] cannot capture Steam windows

[Simon Richter]

Package: x11-apps
Version: 7.7+9
Severity: normal
Tags: upstream

Hi,

Using

xwd -out steam.xwd

and clicking on any window opened by Steam gives

X Error of failed request:  BadColor (invalid Colormap parameter)
  Major opcode of failed request:  91 (X_QueryColors)
  Resource id in failed request:  0x0
  Serial number of failed request:  271
  Current serial number in output stream:  271

The resulting file is empty. This also happens when -icmap is specified.

   Simon

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages x11-apps depends on:
ii  libc62.36-9+deb12u1
ii  libpng16-16  1.6.39-2
ii  libsm6   2:1.2.3-1
ii  libx11-6 2:1.8.4-2+deb12u1
ii  libx11-xcb1  2:1.8.4-2+deb12u1
ii  libxaw7  2:1.0.14-1
ii  libxcb-damage0   1.15-1
ii  libxcb-present0  1.15-1
ii  libxcb-xfixes0   1.15-1
ii  libxcb1  1.15-1
ii  libxcursor1  1:1.2.1-1
ii  libxext6 2:1.3.4-1+b1
ii  libxft2  2.3.6-1
ii  libxi6   2:1.8-1+b1
ii  libxkbfile1  1:1.1.0-1
ii  libxmu6  2:1.1.3-3
ii  libxmuu1 2:1.1.3-3
ii  libxrender1  1:0.9.10-1.1
ii  libxt6   1:1.2.1-1.1
ii  man-db   2.11.2-2

Versions of packages x11-apps recommends:
ii  xbitmaps  1.1.1-2.2

Versions of packages x11-apps suggests:
ii  mesa-utils  8.5.0-1

-- no debconf information

Re: Bug#1050071: llvm-defaults: move to 16

[Simon McVittie]

On Mon, 11 Sep 2023 at 19:46:07 +0300, Timo Aaltonen wrote:
> Simon McVittie kirjoitti 11.9.2023 klo 12.36:
> > I've opened a Mesa bug at wishlist severity suggesting a move to version
> > 16, and set it to block the bug for llvm-toolchain-15 removal (#1050070).
> 
> The remaining blocker for this is that using llvm-16 requires a newer
> bindgen, and the latest upstream version split the cli separate, so that
> needs to be packaged (has been done AIUI) and processed through NEW first,
> see:
> 
> https://salsa.debian.org/rust-team/debcargo-conf/-/issues/50

Does this block a general swap of the defaults from 14 to 16, or is it
just a blocker for Mesa moving to 16 as a result of something Mesa-specific?

Is there / does there need to be a transition tracking bug for this?

Perhaps to avoid the trip through NEW it would be pragmatic to make
rust-bindgen be temporarily or permanently a multiple-upstream-tarball
binary package that combines the upstream projects bindgen and
bindgen-cli, avoiding needing to wait for NEW on the critical path?

Thanks,
smcv

Re: Bug#1050071: llvm-defaults: move to 16

[Simon McVittie]

On Sat, 19 Aug 2023 at 10:39:44 +0200, Sylvestre Ledru wrote:
> llvm-defaults has been pointing to 16 in experimental for quite sometime.
> Opening this transition to make sure it is on your radar! :)
> 
> I opened bug #1050070 & #1050069 for future removals.

Mesa is a significant user of LLVM, and hard-codes its own non-default
version of LLVM which often runs ahead of the default (currently 15).
It seems to be relatively common for a LLVM version upgrade to cause
regressions or uninstallability on at least one architecture, and also
relatively common for a LLVM version upgrade to be necessary to unblock
features or bug fixes in Mesa, which I assume is why the Mesa maintainers
have felt the need to control this themselves.

Should Mesa try moving to -16 *before* the default changes? It would
seem unhelpful to move the rest of the distribution to a version that
Mesa can't use for whatever reason.

I've opened a Mesa bug at wishlist severity suggesting a move to version
16, and set it to block the bug for llvm-toolchain-15 removal (#1050070).

smcv

Bug#1051680: mesa: switch LLVM major version to 16

[Simon McVittie]

Source: mesa
Version: 23.1.6-1
Severity: wishlist
X-Debbugs-Cc: llvm-toolchain...@packages.debian.org
Control: block 1050070 by -1

According to #1050071, #1050070 and #1050069, the LLVM maintainers want
to switch the default LLVM major version from 14 to 16, and remove versions
14 and 15.

Mesa currently uses LLVM 15 rather than the default 14. Should it move
to 16 in testing/unstable, ahead of the default changing?

smcv

Bug#1051021: twm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: twm
Version: 1:1.0.10-1
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, TWM behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/twm.desktop
which can be selected on entry to a display manager such as lightdm.
If it's going to register as a desktop environment, then it should behave
like a desktop environment in other ways, such as choosing an
XDG_CURRENT_DESKTOP identifier.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/twm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, TWM doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow TWM to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg twm
* reboot
* Log in as the user account, selecting "TWM" from the menu of
  possible X11 sessions
* Open an xterm and run:
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. TWM seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=TWM

would seem appropriate.

This would allow the TWM session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/twm-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of TWM who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/twm.desktop, most likely just "TWM":

DesktopNames=TWM;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/twm-portals.conf
with whatever portal backends are desired for an TWM session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1050956: weston: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: weston
Version: 12.0.1-1
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

In addition to being available as a compositor that is part of
a more comprehensive desktop environment, weston behaves like
a small desktop environment in its own right, by providing a
/usr/share/wayland-sessions/weston.desktop which can be selected on
entry to a display manager such as gdm3.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/weston-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, weston doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other equally simple session.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow weston to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists and has a password
* apt install gdm3 weston
* reboot
* Log in as the user account, selecting Weston from the menu of
  possible X11/Wayland sessions before entering the password
* Open a terminal and run:
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`echo $XDG_CURRENT_DESKTOP`, because xdg-desktop-portal will typically be
run as a systemd user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. For Weston on its own
as a simple desktop environment,

XDG_CURRENT_DESKTOP=Weston

would seem appropriate?

This would allow the Weston session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/weston-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of Weston who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/wayland-sessions/weston.desktop, most likely just "Weston":

DesktopNames=Weston;

And then create a /usr/share/xdg-desktop-portal/weston-portals.conf
with whatever portal backends are desired for a Weston session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1049404: mesa: gnome-shell crashes when using llvmpipe on mips64el

[Simon McVittie]

Source: mesa
Version: 23.1.4-1
Severity: normal
X-Debbugs-Cc: debian-m...@lists.debian.org, wzss...@gmail.com
User: debian-m...@lists.debian.org
Usertags: mips64el mipsel

gnome-shell (>= 44) fails its build-time tests on the mips64el porterbox
'eller', using llvmpipe for 3D graphics. I don't know whether a simpler
accelerated 3D application would reproduce the same crash.

According to mips porter YunQiang Su, the same version of
gnome-shell works well on an AMD GPU, so this is an llvmpipe-specific
bug. Unfortunately, llvmpipe is the only thing we have available for
smoke-testing on buildds and other infrastructure.

To reproduce this with a current version of gnome-shell, it will be
necessary to remove this workaround from debian/rules:

ifneq ($(filter mips%,$(DEB_HOST_ARCH_CPU)),)
# gnome-shell on mips(64)el works on a real GPU (in practice usually an
# AMD GPU), but crashes when using llvmpipe or softpipe, which is all that
# is available on the buildds, so we only run the unit tests at build time
# and skip the tests that would run the whole Shell. See discussion in
# https://salsa.debian.org/gnome-team/gnome-shell/-/merge_requests/71
meson_test_options += --no-suite shell
endif

This might have the same root cause as some or all of #868745, #935884,
#1010838, #993550, #1003348.

YunQiang Su writes:
> on MIPS with MSA, mesa try to use it, and trigger some
> problems. It is still the bug of LLVM. So maybe we should
> revert the changes to mesa before LLVM MSA JIT is fixed.
> https://gitlab.freedesktop.org/mesa/mesa/-/commit/88b234d7a7cd71fcb4955428010f238ec9530431

There is further discussion on
.
(Note that there is also discussion there of a different failure with the
softpipe renderer, which is out of scope for this bug report.)

I do not intend to work on this myself: I do not have any mips hardware,
any particular interest in mips, or any Mesa or LLVM expertise.

Thanks,
smcv

Bug#1037407: weston: build-depends on transitional package libgdk-pixbuf2.0-dev

[Simon McVittie]

Control: tags -1 + patch

On Mon, 12 Jun 2023 at 11:59:17 +0100, Simon McVittie wrote:
> If this package only requires functionality from gdk-pixbuf-2.0.pc
> and , please update the build-dependency to
> libgdk-pixbuf-2.0-dev.

Please consider the attached patch, also available at
<https://salsa.debian.org/xorg-team/wayland/weston/-/merge_requests/8>.
I have confirmed (using diffoscope) that this change does not have any
effect on the built binary packages.

smcv

Bug#1039922: mesa breaks gtk4 autopkgtest: panel surface gone

[Simon McVittie]

Control: reassign -1 src:mesa 23.1.2-1
Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/-/issues/9199

On Wed, 05 Jul 2023 at 14:47:11 +0300, Timo Aaltonen wrote:
> I filed this upstream a while ago and bisected the regressing commit
> now:
> 
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/9199
> 
> but it's not possible to revert just that, would need to revert 17 commits
> in total.

It seems this is being treated as a mesa regression, so assigning it to
mesa only and not mesa|gtk4.

smcv

Bug#1039922: mesa breaks gtk4 autopkgtest: panel surface gone

[Simon McVittie]

I think the problem here is more likely to be this bit:

On Thu, 29 Jun 2023 at 16:21:36 +0200, Paul Gevers wrote:
> 228s libEGL warning: failed to get driver name for fd 0
> 228s 228s libEGL warning: MESA-LOADER: failed to retrieve device information
> 228s 228s libEGL warning: failed to get driver name for fd 0
> 228s 230s [02:18:06.642] caught signal 15

and "panel surface gone" seems more likely to be a symptom of that
than the cause?

GTK's test suite is relying on being able to do EGL under Wayland on a
headless machine, at least via llvmpipe.

smcv

Bug#1037407: weston: build-depends on transitional package libgdk-pixbuf2.0-dev

[Simon McVittie]

Source: weston
Version: 10.0.1-1
Severity: important
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: split-gdk-pixbuf
Control: found -1 11.0.0-2

This package Build-Depends on libgdk-pixbuf2.0-dev.

In Debian 11, libgdk-pixbuf2.0-dev was split into two packages:

- libgdk-pixbuf-2.0-dev contains the supported gdk-pixbuf-2.0 library

- libgdk-pixbuf-xlib-2.0-dev contains the deprecated, unmaintained
  Xlib integration layer, gdk-pixbuf-xlib-2.0

If this package only requires functionality from gdk-pixbuf-2.0.pc
and , please update the build-dependency to
libgdk-pixbuf-2.0-dev.

If it also requires the Xlib integration gdk-pixbuf-xlib-2.0.pc and
 (unlikely), then you can also build-depend on
libgdk-pixbuf-xlib-2.0-dev until the package can be updated to remove
that requirement.

libgdk-pixbuf-2.0-dev was present in both Debian 11 and Debian 12, so
it is not necessary to have a "| libgdk-pixbuf2.0-dev" alternative
dependency, even for packages that are expected to be backported.

We should remove the libgdk-pixbuf2.0-dev transitional package during
the Debian 13 'trixie' cycle, so this bug is likely to become RC later.

Thanks,
smcv

Re: Bug#1032999: unblock: mesa/22.3.6-1

[Simon McVittie]

On Wed, 15 Mar 2023 at 14:40:27 +, Simon McVittie wrote:
>   [x] attach debdiff against the package in testing

Sorry, here's the debdiff, filtered to exclude .pick_status.json (which is
used upstream to track which changes should/should not be backported).

smcv


mesa_22.3.6-1-debdiff.diff.gz
Description: application/gzip

Bug#1032999: unblock: mesa/22.3.6-1

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: m...@packages.debian.org
Control: affects -1 + src:mesa
Control: block -1 by 1032887

Please consider unblocking package mesa.

[ Reason ]
New upstream bugfix release, fixing #1029731 (RC) and many more.

[ Impact ]
If not accepted, bookworm will ship with various avoidable crashes and
hangs in the graphics driver stack.

[ Tests ]
Has been in unstable for 17 days, currently no RC bugs.

[ Risks ]
I'll leave this for the Mesa maintainers to answer...

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [ ] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
I am not a maintainer of this package, just an interested user.

This can't migrate until llvm-toolchain-15 does (see #1032887, which I
believe is only waiting for a maintainer re-upload with build artifacts
excluded).

unblock mesa/22.3.6-1

Bug#1031230: spirv-tools: autopkgtest regression for glslang: undefined reference to spvtools::CreateAggressiveDCEPass etc.

[Simon McVittie]

Package: spirv-tools
Version: 2023.1-1
Severity: serious
Justification: https://release.debian.org/testing/rc_policy.txt 6a
User: debian...@lists.debian.org
Usertags: regression
X-Debbugs-Cc: debian...@lists.debian.org
Control: affects -1 + src:glslang

The test-case debian/tests/glslang-dev that I contributed
in glslang_11.1.0-4 has started failing with the upload of
spirv-tools_2023.1-1, or possibly 2022.4+1.3.236.0-1:

> + pkg-config --cflags --libs glslang
> + g++ -std=c++11 -o trivial trivial.cpp -lglslang -lMachineIndependent 
> -lOSDependent -lHLSL -lOGLCompiler -lGenericCodeGen -lSPVRemapper -lpthread
> + test -x trivial
> + ./trivial
> + pkg-config --cflags --libs spirv
> + g++ -std=c++11 -o spirv spirv.cpp -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools 
> -lSPIRV-Tools-link -lglslang -lMachineIndependent -lOSDependent -lHLSL 
> -lOGLCompiler -lGenericCodeGen -lSPVRemapper -lpthread
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libSPIRV.a(SpvTools.cpp.o):
>  in function `glslang::SpirvToolsTransform(glslang::TIntermediate const&, 
> std::vector >&, 
> spv::SpvBuildLogger*, glslang::SpvOptions const*)':
> (.text+0x689): undefined reference to 
> `spvtools::CreateAggressiveDCEPass(bool, bool)'
> /usr/bin/ld: (.text+0x6de): undefined reference to 
> `spvtools::CreateAggressiveDCEPass(bool, bool)'
> /usr/bin/ld: (.text+0x784): undefined reference to 
> `spvtools::CreateAggressiveDCEPass(bool, bool)'
> /usr/bin/ld: (.text+0x7ff): undefined reference to 
> `spvtools::CreateAggressiveDCEPass(bool, bool)'
> /usr/bin/ld: (.text+0x8ef): undefined reference to 
> `spvtools::CreateEliminateDeadInputComponentsSafePass()'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libSPIRV.a(SpvTools.cpp.o):
>  in function `glslang::SpirvToolsAnalyzeDeadOutputStores(spv_target_env, 
> std::vector >&, 
> std::unordered_set, 
> std::equal_to, std::allocator >*, 
> std::unordered_set, 
> std::equal_to, std::allocator >*, 
> spv::SpvBuildLogger*)':
> (.text+0x9b1): undefined reference to 
> `spvtools::CreateAnalyzeLiveInputPass(std::unordered_set std::hash, std::equal_to, std::allocator int> >*, std::unordered_set, 
> std::equal_to, std::allocator >*)'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libSPIRV.a(SpvTools.cpp.o):
>  in function `glslang::SpirvToolsEliminateDeadOutputStores(spv_target_env, 
> std::vector >&, 
> std::unordered_set, 
> std::equal_to, std::allocator >*, 
> std::unordered_set, 
> std::equal_to, std::allocator >*, 
> spv::SpvBuildLogger*)':
> (.text+0xae1): undefined reference to 
> `spvtools::CreateEliminateDeadOutputStoresPass(std::unordered_set int, std::hash, std::equal_to, 
> std::allocator >*, std::unordered_set std::hash, std::equal_to, std::allocator int> >*)'
> /usr/bin/ld: (.text+0xb03): undefined reference to 
> `spvtools::CreateAggressiveDCEPass(bool, bool)'
> /usr/bin/ld: (.text+0xb1e): undefined reference to 
> `spvtools::CreateEliminateDeadOutputComponentsPass()'
> /usr/bin/ld: (.text+0xb40): undefined reference to 
> `spvtools::CreateAggressiveDCEPass(bool, bool)'
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libSPIRV.a(SpvTools.cpp.o):
>  in function `glslang::SpirvToolsEliminateDeadInputComponents(spv_target_env, 
> std::vector >&, 
> spv::SpvBuildLogger*)':
> (.text+0xc80): undefined reference to 
> `spvtools::CreateAggressiveDCEPass(bool, bool)'

I think probably this means that SPIRV-Tools.pc is missing some libraries,
similar to #951988 but for spirv-tools rather than glslang?

Adding an autopkgtest to spirv-tools and running it before upload might
be a helpful way to catch similar issues.

smcv

Bug#965901: xfonts-encodings: diff for NMU version 1:1.0.4-2.2

[Simon McVittie]

Control: tags 965901 + pending

I've prepared an NMU for xfonts-encodings (versioned as 1:1.0.4-2.2) with
the attached diff, also available at
<https://salsa.debian.org/xorg-team/font/xfonts-encodings/-/merge_requests/2>.

Since this only contains changes that were already merged into the
maintainers' VCS months ago, I'm going to upload a NMU without further
delay.

Thanks,
smcv
diffstat for xfonts-encodings_1.0.4-2.1 xfonts-encodings_1.0.4-2.2

 .gitignore  |   80 
 debian/compat   |1 
 xfonts-encodings-1.0.4/debian/changelog |   17 ++
 xfonts-encodings-1.0.4/debian/control   |7 +-
 xfonts-encodings-1.0.4/debian/copyright |2 
 xfonts-encodings-1.0.4/debian/rules |9 ++-
 xfonts-encodings-1.0.4/debian/watch |2 
 7 files changed, 110 insertions(+), 8 deletions(-)

diff -u xfonts-encodings-1.0.4/debian/changelog xfonts-encodings-1.0.4/debian/changelog
--- xfonts-encodings-1.0.4/debian/changelog
+++ xfonts-encodings-1.0.4/debian/changelog
@@ -1,3 +1,20 @@
+xfonts-encodings (1:1.0.4-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload, incorporating changes from the maintainers'
+packaging repository
+
+  [ Julien Cristau ]
+  * Switch Vcs-* control fields to https.
+  * Switch xorg.freedesktop.org URLs in packaging to https.
+
+  [ Simon McVittie ]
+  * d/control: Update Vcs-* for migration to salsa.debian.org
+  * Use recommended debhelper compat level 13 (Closes: #965901)
+  * d/rules: Add missing targets build-arch, build-indep (Policy §4.9)
+  * d/control: Declare that the build does not require (fake)root
+
+ -- Simon McVittie   Sun, 15 Jan 2023 14:14:38 +
+
 xfonts-encodings (1:1.0.4-2.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
reverted:
--- xfonts-encodings-1.0.4/debian/compat
+++ xfonts-encodings-1.0.4.orig/debian/compat
@@ -1 +0,0 @@
-5
diff -u xfonts-encodings-1.0.4/debian/control xfonts-encodings-1.0.4/debian/control
--- xfonts-encodings-1.0.4/debian/control
+++ xfonts-encodings-1.0.4/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian X Strike Force 
 Build-Depends:
- debhelper (>= 5.0.0),
+ debhelper-compat (= 13),
 Build-Depends-Indep:
  pkg-config,
  xfonts-utils (>= 1:7.6~),
@@ -11,8 +11,9 @@
  automake,
  xutils-dev (>= 1:7.5+1),
 Standards-Version: 3.8.3
-Vcs-Git: git://git.debian.org/git/pkg-xorg/font/xfonts-encodings.git
-Vcs-Browser: http://git.debian.org/?p=pkg-xorg/font/xfonts-encodings.git
+Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-encodings.git
+Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-encodings
+Rules-Requires-Root: no
 
 Package: xfonts-encodings
 Architecture: all
diff -u xfonts-encodings-1.0.4/debian/copyright xfonts-encodings-1.0.4/debian/copyright
--- xfonts-encodings-1.0.4/debian/copyright
+++ xfonts-encodings-1.0.4/debian/copyright
@@ -1,5 +1,5 @@
 This package contains the encodings tarball downloaded from
-http://xorg.freedesktop.org/releases/individual/font/
+https://xorg.freedesktop.org/releases/individual/font/
 
 The XFree86/Xorg encoding files are in the public domain.
 
diff -u xfonts-encodings-1.0.4/debian/rules xfonts-encodings-1.0.4/debian/rules
--- xfonts-encodings-1.0.4/debian/rules
+++ xfonts-encodings-1.0.4/debian/rules
@@ -34,6 +34,7 @@
 
 
 build: build-stamp
+build-indep: build-stamp
 build-stamp:
 	dh_testdir
 	autoreconf -vfi
@@ -45,6 +46,9 @@
 	cd build && $(MAKE)
 	>$@
 
+build-arch:
+# Nothing to do
+
 clean: xsfclean
 	dh_testdir
 	dh_testroot
@@ -63,7 +67,7 @@
 install: build
 	dh_testdir
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	dh_installdirs
 	cd build && $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
 
@@ -77,7 +81,8 @@
 	dh_testroot
 
 	dh_installdocs
-	dh_install --sourcedir=debian/tmp --list-missing
+	dh_install --sourcedir=debian/tmp
+	dh_missing --list-missing
 	dh_installchangelogs
 	dh_link
 	dh_strip
diff -u xfonts-encodings-1.0.4/debian/watch xfonts-encodings-1.0.4/debian/watch
--- xfonts-encodings-1.0.4/debian/watch
+++ xfonts-encodings-1.0.4/debian/watch
@@ -1,3 +1,3 @@
 #git=git://anongit.freedesktop.org/xorg/font/encodings
 version=3
-http://xorg.freedesktop.org/releases/individual/font/ encodings-(.*)\.tar\.gz
+https://xorg.freedesktop.org/releases/individual/font/ encodings-(.*)\.tar\.gz
only in patch2:
unchanged:
--- xfonts-encodings-1.0.4.orig/.gitignore
+++ xfonts-encodings-1.0.4/.gitignore
@@ -0,0 +1,80 @@
+#
+#		X.Org module default exclusion patterns
+#		The next section if for module specific patterns
+#
+#	Do not edit the following section
+# 	GNU Build System (Autotools)
+aclocal.m4
+autom4te.cache/
+autoscan.log
+ChangeLog
+compile
+config.guess
+config.h
+config.h.in
+config.log
+config-ml.in
+config.py
+config.status
+config.status.lineno
+config.sub
+configure
+configure.scan
+depcomp
+.deps/
+INSTALL
+install-sh
+.libs/
+libtool
+libtool.m

Bug#965894: xfonts-scalable: diff for NMU version 1:1.0.3-1.3

[Simon McVittie]

Control: tags 965894 + pending

I've prepared an NMU for xfonts-scalable (versioned as 1:1.0.3-1.3) with
the attached diff, also available at
<https://salsa.debian.org/xorg-team/font/xfonts-scalable/-/merge_requests/2>.

Since this only contains changes that were already merged into the
maintainers' VCS months ago, I'm going to upload a NMU without further
delay.

Thanks,
smcv
diffstat for xfonts-scalable_1.0.3-1.2 xfonts-scalable_1.0.3-1.3

 .gitignore |   78 +
 debian/compat  |1 
 xfonts-scalable-1.0.3/debian/changelog |   18 +++
 xfonts-scalable-1.0.3/debian/control   |6 +-
 xfonts-scalable-1.0.3/debian/rules |9 ++-
 xfonts-scalable-1.0.3/debian/watch |3 -
 6 files changed, 109 insertions(+), 6 deletions(-)

diff -u xfonts-scalable-1.0.3/debian/changelog xfonts-scalable-1.0.3/debian/changelog
--- xfonts-scalable-1.0.3/debian/changelog
+++ xfonts-scalable-1.0.3/debian/changelog
@@ -1,3 +1,21 @@
+xfonts-scalable (1:1.0.3-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload, incorporating changes from the maintainers'
+packaging repository
+
+  [ Julien Cristau ]
+  * Remove Cyril and David from Uploaders.
+  * Add Vcs-* control fields.
+  * Use https URL in debian/watch.
+
+  [ Simon McVittie ]
+  * d/control: Update Vcs-* for migration to salsa.debian.org
+  * Use recommended debhelper compat level 13 (Closes: #965894)
+  * d/rules: Add missing build-arch, build-indep targets (Policy §4.9)
+  * d/control: Declare that the build does not require (fake)root
+
+ -- Simon McVittie   Sun, 15 Jan 2023 14:18:32 +
+
 xfonts-scalable (1:1.0.3-1.2) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
reverted:
--- xfonts-scalable-1.0.3/debian/compat
+++ xfonts-scalable-1.0.3.orig/debian/compat
@@ -1 +0,0 @@
-5
diff -u xfonts-scalable-1.0.3/debian/control xfonts-scalable-1.0.3/debian/control
--- xfonts-scalable-1.0.3/debian/control
+++ xfonts-scalable-1.0.3/debian/control
@@ -2,15 +2,17 @@
 Section: fonts
 Priority: optional
 Maintainer: Debian X Strike Force 
-Uploaders: David Nusinow , Cyril Brulebois 
 Build-Depends:
- debhelper (>= 5.0.31),
+ debhelper-compat (= 13),
  xfonts-utils (>= 1:7.6~),
  automake,
  autoconf,
  xutils-dev (>= 1:7.5+1),
  pkg-config,
 Standards-Version: 3.8.3
+Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-scalable.git
+Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-scalable
+Rules-Requires-Root: no
 
 Package: xfonts-scalable
 Architecture: all
diff -u xfonts-scalable-1.0.3/debian/rules xfonts-scalable-1.0.3/debian/rules
--- xfonts-scalable-1.0.3/debian/rules
+++ xfonts-scalable-1.0.3/debian/rules
@@ -34,6 +34,7 @@
 
 
 build: build-stamp
+build-indep: build-stamp
 build-stamp: $(STAMP_DIR)/prepare
 	dh_testdir
 	autoreconf -vfi
@@ -45,6 +46,9 @@
 	cd build && $(MAKE)
 	>$@
 
+build-arch:
+# Nothing to do
+
 clean: xsfclean
 	dh_testdir
 	dh_testroot
@@ -64,7 +68,7 @@
 install: build
 	dh_testdir
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	dh_installdirs
 
 	cd build && $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
@@ -81,7 +85,8 @@
 	dh_testroot
 
 	dh_installdocs
-	dh_install --sourcedir=debian/tmp --fail-missing --exclude=fonts.dir --exclude=fonts.scale
+	dh_install --sourcedir=debian/tmp --exclude=fonts.dir --exclude=fonts.scale
+	dh_missing --fail-missing --exclude=fonts.dir --exclude=fonts.scale
 	dh_installxfonts
 	dh_installchangelogs
 	dh_compress
diff -u xfonts-scalable-1.0.3/debian/watch xfonts-scalable-1.0.3/debian/watch
--- xfonts-scalable-1.0.3/debian/watch
+++ xfonts-scalable-1.0.3/debian/watch
@@ -1,2 +1,3 @@
+#git=git://anongit.freedesktop.org/xorg/font/bitstream-type1
 version=3
-http://xorg.freedesktop.org/releases/individual/font/ font-bitstream-type1-(.*)\.tar\.gz
+https://xorg.freedesktop.org/releases/individual/font/ font-bitstream-type1-(.*)\.tar\.gz
only in patch2:
unchanged:
--- xfonts-scalable-1.0.3.orig/.gitignore
+++ xfonts-scalable-1.0.3/.gitignore
@@ -0,0 +1,78 @@
+#
+#		X.Org module default exclusion patterns
+#		The next section if for module specific patterns
+#
+#	Do not edit the following section
+# 	GNU Build System (Autotools)
+aclocal.m4
+autom4te.cache/
+autoscan.log
+ChangeLog
+compile
+config.guess
+config.h
+config.h.in
+config.log
+config-ml.in
+config.py
+config.status
+config.status.lineno
+config.sub
+configure
+configure.scan
+depcomp
+.deps/
+INSTALL
+install-sh
+.libs/
+libtool
+libtool.m4
+ltmain.sh
+lt~obsolete.m4
+ltoptions.m4
+ltsugar.m4
+ltversion.m4
+Makefile
+Makefile.in
+mdate-sh
+missing
+mkinstalldirs
+*.pc
+py-compile
+stamp-h?
+symlink-tree
+texinfo.tex
+ylwrap
+
+#	Do not edit the following section
+# 	Edit Compile Debug Document Distribute
+*~
+*.[0-9]
+*.[0-9]x
+*.bak
+*.bin
+core
+*.dll
+*.exe
+*-ISO*.bdf
+*-JIS*.bdf
+*-KOI8*.bdf
+*.kld
+*.ko
+*.ko.cmd
+*.lai
+*.l[oa]
+*.[oa]
+*.ob

Bug#1028967: xfonts-base: diff for NMU version 1:1.0.5+nmu1

[Simon McVittie]

Package: xfonts-base
Version: 1:1.0.5
Severity: normal
Tags: patch pending

I've prepared an NMU for xfonts-base (versioned as 1:1.0.5+nmu1). Because
all of the changes were already accepted into the maintainers' VCS,
I uploaded directly to unstable.

The attached diff is also available as
<https://salsa.debian.org/xorg-team/font/xfonts-base/-/merge_requests/3>
or from dgit, if you would prefer to receive it that way.

Thanks,
smcv
diffstat for xfonts-base-1.0.5 xfonts-base-1.0.5+nmu1

 changelog |   19 +++
 control   |7 ---
 rules |   10 +-
 3 files changed, 32 insertions(+), 4 deletions(-)

diff -Nru xfonts-base-1.0.5/debian/changelog xfonts-base-1.0.5+nmu1/debian/changelog
--- xfonts-base-1.0.5/debian/changelog	2019-02-21 13:50:43.0 +
+++ xfonts-base-1.0.5+nmu1/debian/changelog	2023-01-15 13:47:44.0 +
@@ -1,3 +1,22 @@
+xfonts-base (1:1.0.5+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload, incorporating changes from the maintainers'
+packaging repository
+
+  [ Simon McVittie ]
+  * d/rules: Add missing build-arch, build-indep targets (Policy §4.9)
+(Closes: #999177)
+  * d/control: Declare that the build does not require (fake)root
+  * d/rules: Use dh_update_autotools_config to update config.guess,
+config.sub (Closes: #856271)
+
+  [ Debian Janitor ]
+  * Remove constraints unnecessary since buster (oldstable):
++ Build-Depends-Indep: Drop versioned constraint on xfonts-utils and
+  xutils-dev.
+
+ -- Simon McVittie   Sun, 15 Jan 2023 13:47:44 +
+
 xfonts-base (1:1.0.5) unstable; urgency=medium
 
   * Add Vcs-* control fields.
diff -Nru xfonts-base-1.0.5/debian/control xfonts-base-1.0.5+nmu1/debian/control
--- xfonts-base-1.0.5/debian/control	2019-02-21 13:49:21.0 +
+++ xfonts-base-1.0.5+nmu1/debian/control	2023-01-15 13:47:44.0 +
@@ -3,14 +3,15 @@
 Priority: optional
 Maintainer: Debian X Strike Force 
 Build-Depends:
- debhelper (>= 7),
+ debhelper (>= 10.8),
 Build-Depends-Indep:
  pkg-config,
- xfonts-utils (>= 1:7.5),
- xutils-dev (>= 1:7.5+4),
+ xfonts-utils,
+ xutils-dev,
 Standards-Version: 3.8.3
 Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-base.git
 Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-base
+Rules-Requires-Root: no
 
 Package: xfonts-base
 Architecture: all
diff -Nru xfonts-base-1.0.5/debian/rules xfonts-base-1.0.5+nmu1/debian/rules
--- xfonts-base-1.0.5/debian/rules	2019-02-21 13:48:02.0 +
+++ xfonts-base-1.0.5+nmu1/debian/rules	2023-01-15 13:47:44.0 +
@@ -45,8 +45,12 @@
 	confflags += --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
 endif
 
-$(STAMP_DIR)/build-%:
+$(STAMP_DIR)/prepare:
 	mkdir -p $(STAMP_DIR)
+	dh_update_autotools_config
+	>$@
+
+$(STAMP_DIR)/build-%: $(STAMP_DIR)/prepare
 	mkdir -p $*-build
 	cd $*-build && \
 	../$*/configure \
@@ -60,9 +64,13 @@
 
 
 build: build-stamp
+build-indep: build-stamp
 build-stamp: $(addprefix $(STAMP_DIR)/build-,$(SUBDIRS))
 	>$@
 
+build-arch:
+# Nothing to do.
+
 clean:
 	dh_testdir
 	rm -f config.cache config.log config.status

Re: Bug#1026445: mutter: test failure on armhf and sometimes armel: ../../src/xcb_io.c:626: _XAllocID: Assertion `ret != inval_id' failed

[Simon McVittie]

Control: severity -1 important

On Tue, 20 Dec 2022 at 11:47:10 +, Simon McVittie wrote:
> Recent uploads of mutter have had a FTBFS on armhf and sometimes armel,
> with this test failure in "mutter:core+mutter/wayland / xwayland"

In 43.2-4 I've downgraded failures in this test to be non-fatal,
reducing the severity of this issue.

> The same test failure has not been seen on arm64 or on non-ARM
> architectures, for whatever reason (in particular, other slower
> architectures like riscv64 and mips*el don't seem to have this
> problem).

This is probably because d/rules in mutter explicitly skips the
tests on riscv64 and mips*el. I'd prefer to re-enable the tests on
all architectures (even if all failures are ignored on some of them)
now that it's using Meson, in which all tests have a finite timeout,
but that will probably need to happen via experimental in order to avoid
disrupting migration.

One important and possibly relevant difference between 32-bit ARM and
arm64 is that on 32-bit ARM, we explicitly set the default driver in
mutter's fork of cogl to be OpenGL|ES 2 instead of OpenGL 3, using
non-upstreamed patches. I'd like to be able to stop applying those
patches, but that will need input from users of proprietary GPU drivers
on ARM.

smcv

Bug#1026445: mutter: test failure on armhf and sometimes armel: ../../src/xcb_io.c:626: _XAllocID: Assertion `ret != inval_id' failed

[Simon McVittie]

Source: mutter
Version: 43.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: lib...@packages.debian.org, debian-...@lists.debian.org
User: debian-...@lists.debian.org
Usertags: armel armhf

Recent uploads of mutter have had a FTBFS on armhf and sometimes armel,
with this test failure in "mutter:core+mutter/wayland / xwayland":

> Starting D-Bus daemons (session & system)...
> Launching required services...
> Starting mocked services...
> Running test case...
> # random seed: R02Sbd5b457b9c18c15b967e5a1eb0e1b2ed
> # libmutter-MESSAGE: Running Mutter Test (using mutter 43.2) as a Wayland 
> display server
> libmutter-Message: 22:46:22.853: Running Mutter Test (using mutter 43.2) as a 
> Wayland display server
> # GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation 
> memory (GMemorySettingsBackend) for ‘gsettings-backend’
> # libmutter-MESSAGE: Created surfaceless renderer without GPU
> libmutter-Message: 22:46:23.040: Created surfaceless renderer without GPU
> # GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation 
> local (GLocalVfs) for ‘gio-vfs’
> # libmutter-MESSAGE: Disabling DMA buffer screen sharing (not hardware 
> accelerated)
> libmutter-Message: 22:46:23.127: Disabling DMA buffer screen sharing (not 
> hardware accelerated)
> # libmutter-MESSAGE: Disabling DMA buffer screen sharing (implicit modifiers 
> not supported)
> libmutter-Message: 22:46:23.127: Disabling DMA buffer screen sharing 
> (implicit modifiers not supported)
> # libmutter-DEBUG: WL: loaded 
> libnvidia-egl-wayland.so.1:wl_eglstream_controller.
> # libmutter-MESSAGE: Using public X11 display :512, (using :513 for managed 
> services)
> libmutter-Message: 22:46:23.129: Using public X11 display :512, (using :513 
> for managed services)
> # libmutter-MESSAGE: Using Wayland display name 'mutter-test-display'
> libmutter-Message: 22:46:23.129: Using Wayland display name 
> 'mutter-test-display'
> Window manager warning: Failed to set environment variable 
> GNOME_SETUP_DISPLAY for gnome-session: 
> GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name 
> "org.gnome.SessionManager" does not exist
> Window manager warning: Failed to set environment variable DISPLAY for 
> gnome-session: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name 
> "org.gnome.SessionManager" does not exist
> Window manager warning: Failed to set environment variable XAUTHORITY for 
> gnome-session: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name 
> "org.gnome.SessionManager" does not exist
> Window manager warning: Failed to set environment variable WAYLAND_DISPLAY 
> for gnome-session: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: 
> Name "org.gnome.SessionManager" does not exist
> 1..2
> # Start of backends tests
> # Start of xwayland tests
> # Start of restart tests
> # libmutter-INFO: Acquired name org.gnome.Mutter.InputMapping
> # libmutter-INFO: Acquired name org.gnome.Mutter.ScreenCast
> # libmutter-INFO: Acquired name org.gnome.Mutter.RemoteDesktop
> (WW) Option "-listen" for file descriptors is deprecated
> Please use "-listenfd" instead.
> (WW) Option "-listen" for file descriptors is deprecated
> Please use "-listenfd" instead.
> Failed to initialize glamor, falling back to sw
> # GLib-DEBUG: unsetenv() is not thread-safe and should not be used after 
> threads are created
> # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
> after threads are created
> # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
> after threads are created
> # GLib-DEBUG: unsetenv() is not thread-safe and should not be used after 
> threads are created
> # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
> after threads are created
> # libmutter-MESSAGE: Using public X11 display :512, (using :513 for managed 
> services)
> libmutter-Message: 22:46:23.782: Using public X11 display :512, (using :513 
> for managed services)
> ok 1 /backends/xwayland/restart/selection
> # End of restart tests
> # Start of crash tests
> # libmutter-test-DEBUG: Test client process (null) exited with exit status 1
> (WW) Option "-listen" for file descriptors is deprecated
> Please use "-listenfd" instead.
> (WW) Option "-listen" for file descriptors is deprecated
> Please use "-listenfd" instead.
> Failed to initialize glamor, falling back to sw
> # GLib-DEBUG: unsetenv() is not thread-safe and should not be used after 
> threads are created
> # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
> after threads are created
> # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
> after threads are created
> # GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used 
> after threads are created
> mutter-xwayland: ../../src/xcb_io.c:626: _XAllocID: Assertion `ret != 
> inval_id' failed.

This appears to be an assertion

Re: Bug#1025213: gnome-shell: Flickering and mangled screens on wayland if dri driver not available

[Simon McVittie]

Control: reassign -1 src:mesa 22.2.4-1
Control: severity -1 normal

>From what you've said about the various different drivers in use in
different modes, this looks like a Mesa issue more than a gnome-shell
issue, so I'm reassigning this. It also seems to be hardware-specific
and has a straightforward workaround (using gnome-shell in Xorg mode),
so I'm setting the severity accordingly (Mesa maintainers: this is a
guess, please increase or decrease as you wish).

This is certainly not a Debian Policy section 3.8 violation, because
Policy §3.8 refers to a specific technical feature, the "Essential: yes"
field, and gnome-shell is not an "Essential: yes" package.

On Thu, 01 Dec 2022 at 15:46:07 +0100, Gert van de Kraats wrote:
> my 32-bit Dell-laptop

There are many 32-bit Dell laptops in the world. Which model is this
and which CPU and GPU does it have? Please try running

reportbug --template libgl1-mesa-dri

and send the result to the bug address 1025...@bugs.debian.org so that
the Mesa maintainers have the necessary context.

smcv

Bug#1025312: libgl1-mesa-dri: multiple packages FTBFS and have autopkgtest regressions running test programs under Xvfb

[Simon McVittie]

Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/-/issues/7819

On Fri, 02 Dec 2022 at 12:24:00 +, Simon McVittie wrote:
> - Install a VM/chroot/container with Debian testing
> - Install the dependencies of gtk+3.0's autopkgtests
>   (adwaita-icon-theme-full at-spi2-core dbus-daemon gnome-desktop-testing
>gtk-3-examples librsvg2-common xauth xvfb)
> - xvfb-run -e /dev/stderr -a /usr/libexec/installed-tests/gtk+/builder

I think this is happening because when Xvfb calls driCreateNewScreen2(),
it ends up trying to use the D3D12 driver, which fails to load, but then
tries to dlclose() a NULL handle during teardown.

Workaround: run tests with LIBGL_ALWAYS_SOFTWARE=1 in the environment,
which causes Mesa to skip the D3D12 driver.

Backtrace from the above:

#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x7f2028fcad2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x7f2028f7bef2 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x7f2028f66472 in __GI_abort () at ./stdlib/abort.c:79
#4  0x559b7c293f1a in OsAbort () at ../../../../os/utils.c:1352
#5  0x559b7c299083 in AbortServer () at ../../../../os/log.c:879
#6  0x559b7c29a0b5 in FatalError (f=f@entry=0x559b7c2b1710 "Caught signal 
%d (%s). Server aborting\n") at ../../../../os/log.c:1017
#7  0x559b7c291298 in OsSigHandler (unused=, sip=, signo=11) at ../../../../os/osinit.c:156
#8  OsSigHandler (signo=11, sip=, unused=) at 
../../../../os/osinit.c:110
#9  
#10 _dl_close (_map=0x0) at ./elf/dl-close.c:795
#11 0x7f202908ee9a in __GI__dl_catch_exception 
(exception=exception@entry=0x7ffd2818c640, operate=, 
args=) at ./elf/dl-error-skeleton.c:208
#12 0x7f202908ef4f in __GI__dl_catch_error (objname=0x7ffd2818c698, 
errstring=0x7ffd2818c6a0, mallocedp=0x7ffd2818c697, operate=, 
args=) at ./elf/dl-error-skeleton.c:227
#13 0x7f2028fc4dc7 in _dlerror_run (operate=, 
args=) at ./dlfcn/dlerror.c:138
#14 0x7f2028fc4b26 in __dlclose (handle=) at 
./dlfcn/dlclose.c:31
#15 0x7f20274e7f44 in d3d12_destroy_screen (screen=0x559b7d60ab10) at 
../src/gallium/drivers/d3d12/d3d12_screen.cpp:744
#16 0x7f20274e7190 in d3d12_create_dxcore_screen 
(winsys=winsys@entry=0x559b7d609ee0, adapter_luid=adapter_luid@entry=0x0) at 
../src/gallium/drivers/d3d12/d3d12_dxcore_screen.cpp:236
#17 0x7f2026aaa179 in sw_screen_create_named (driver=0x7f2027ac30f1 
"d3d12", config=0x7ffd2818c7e0, winsys=0x559b7d609ee0) at 
../src/gallium/auxiliary/target-helpers/sw_helper.h:70
#18 sw_screen_create_vk (winsys=0x559b7d609ee0, config=0x7ffd2818c7e0, 
sw_vk=) at 
../src/gallium/auxiliary/target-helpers/sw_helper.h:102
#19 0x7f20270b5156 in pipe_loader_sw_create_screen (dev=0x559b7d609e70, 
config=, sw_vk=) at 
../src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c:425
#20 0x7f20270b50c4 in pipe_loader_create_screen_vk (dev=0x559b7d609e70, 
sw_vk=sw_vk@entry=false) at 
../src/gallium/auxiliary/pipe-loader/pipe_loader.c:175
#21 0x7f20270b50f7 in pipe_loader_create_screen (dev=) at 
../src/gallium/auxiliary/pipe-loader/pipe_loader.c:181
#22 0x7f202634 in drisw_init_screen (sPriv=0x559b7d606e20) at 
../src/gallium/frontends/dri/drisw.c:578
#23 0x7f2026ab44b5 in driCreateNewScreen2 (scrn=0, fd=, 
extensions=, driver_extensions=, 
driver_configs=0x559b7d586200, data=0x559b7d586160) at 
../src/gallium/frontends/dri/dri_util.c:143
#24 0x559b7c18d7e7 in __glXDRIscreenProbe (pScreen=0x559b7d56f8a0) at 
../../../../glx/glxdriswrast.c:448
#25 0x559b7c18c5ef in xorgGlxServerInit (pcbl=, 
param=, ext=) at ../../../../glx/glxext.c:550
#26 xorgGlxServerInit (pcbl=, param=, 
ext=) at ../../../../glx/glxext.c:525
#27 0x559b7c23cb64 in _CallCallbacks (pcbl=pcbl@entry=0x559b7c301168 
, call_data=call_data@entry=0x559b7d585580) at 
../../../../dix/dixutils.c:743
#28 0x559b7c1adc7f in CallCallbacks (call_data=0x559b7d585580, 
pcbl=0x559b7c301168 ) at 
../../../../include/callback.h:83
#29 GlxExtensionInit () at ../../../../glx/vndext.c:244
#30 0x559b7c14e919 in InitExtensions (argc=argc@entry=9, 
argv=argv@entry=0x7ffd2818d508) at ../../../../../mi/miinitext.c:272
#31 0x559b7c23b628 in dix_main (argc=9, argv=, 
envp=) at ../../../../dix/main.c:194
#32 0x7f2028f6718a in __libc_start_call_main 
(main=main@entry=0x559b7c14c8f0 , argc=argc@entry=9, 
argv=argv@entry=0x7ffd2818d508) at ../sysdeps/nptl/libc_start_call_main.h:58
#33 0x7f2028f67245 in __libc_start_main_impl (main=0x559b7c14c8f0 , 
argc=9, argv=0x7ffd2818d508, init=, fini=, 
rtld_fini=, stack_end=0x7ffd2818d4f8) at ../csu/libc-start.c:381
#34 0x559b7c14c921 in _start ()
(gdb) frame 15
(gdb) p screen->d3d12_mod
$1 = (util_dl_library *) 0x0

Bug#1025312: libgl1-mesa-dri: multiple packages FTBFS and have autopkgtest regressions running test programs under Xvfb

[Simon McVittie]

Package: libgl1-mesa-dri
Version: 22.3.0-1
Severity: serious
Justification: FTBFS and autopkgtest regression in affected packages

To reproduce:

- Install a minimal amd64 VM with Debian testing and mesa_22.2.4-1
- apt --no-install-recommends build-dep gtk+3.0
- Build source package gtk+3.0_3.24.35-1 (it succeeds)
- Upgrade all packages except the ones from src:mesa to sid
- Build source package gtk+3.0_3.24.35-1 (it succeeds)
- Upgrade binary packages from src:mesa
- Build source package gtk+3.0_3.24.35-1

or alternatively:

- Install a chroot/container with Debian testing
- Run the autopkgtests for gtk+3.0 (it succeeds)
- Upgrade binary packages from src:mesa to 22.3.0-1
- Run the autopkgtests for gtk+3.0

or more minimally:

- Install a VM/chroot/container with Debian testing
- Install the dependencies of gtk+3.0's autopkgtests
  (adwaita-icon-theme-full at-spi2-core dbus-daemon gnome-desktop-testing
   gtk-3-examples librsvg2-common xauth xvfb)
- xvfb-run -e /dev/stderr -a /usr/libexec/installed-tests/gtk+/builder

Expected result: successful build from source, or successful autopkgtest

Actual result: FTBFS or failing autopkgtest; the test programs are unable
to connect to the Xvfb server.

The autopkgtests for clutter-1.0, cogl, gtk4, juce, kodi, muffin, mutter,
njplot, openscad and pyopengl show similar symptoms, affecting at least
amd64 and arm64.

The kodi autopkgtest shows this backtrace which might be helpful:

autopkgtest [17:19:52]: test gui: [---
(EE)
(EE) Backtrace:
(EE) 0: Xvfb (OsLookupColor+0x139) [0x562b8573d239]
(EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7fee8f45af90]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 2: /lib64/ld-linux-x86-64.so.2 (?+0x0) [0x7fee8fdbe029]
(EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_exception+0x7a) 
[0x7fee8f56de9a]
(EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_error+0x2f) [0x7fee8f56df4f]
(EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (dlerror+0x297) [0x7fee8f4a3dc7]
(EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (dlclose+0x36) [0x7fee8f4a3b26]
(EE) 7: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so 
(nouveau_drm_screen_create+0x1d50f4) [0x7fee8d70ff44]
(EE) 8: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so 
(nouveau_drm_screen_create+0x1d4340) [0x7fee8d70f190]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 9: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (?+0x0) [0x7fee8ccd2179]
(EE) 10: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so 
(__driDriverGetExtensions_d3d12+0x60ae16) [0x7fee8d2dd156]
(EE) 11: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so 
(__driDriverGetExtensions_d3d12+0x60ad84) [0x7fee8d2dd0c4]
(EE) 12: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so 
(__driDriverGetExtensions_d3d12+0x6f4) [0x7fee8ccd2a34]
(EE) 13: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so 
(__driDriverGetExtensions_d3d12+0xa175) [0x7fee8ccdc4b5]
(EE) 14: Xvfb (ht_dump_contents+0x81a7) [0x562b856397e7]
(EE) 15: Xvfb (ht_dump_contents+0x6faf) [0x562b856385ef]
(EE) 16: Xvfb (_CallCallbacks+0x34) [0x562b856e8b64]
(EE) 17: Xvfb (ht_dump_contents+0x2863f) [0x562b85659c7f]
(EE) 18: Xvfb (InitExtensions+0x89) [0x562b855fa919]
(EE) 19: Xvfb (InitFonts+0x1e8) [0x562b856e7628]
(EE) 20: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) 
[0x7fee8f44618a]
(EE) 21: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) 
[0x7fee8f446245]
(EE) 22: Xvfb (_start+0x21) [0x562b855f8921]
(EE)
(EE) Segmentation fault at address 0x337
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
xvfb-run: error: Xvfb failed to start

I get a similar backtrace when I try to run

xvfb-run -e /dev/stderr -a /usr/libexec/installed-tests/gtk+/builder

in a qemu VM.

smcv

Re: Bug#1025213: gnome-shell: Flickering and mangled screens on wayland if dri driver not available

[Simon McVittie]

On Thu, 01 Dec 2022 at 01:11:15 +0100, Gert van de Kraats wrote:
> Recently a general upgrade was executed with gnome-shell
> upgrading from version 43.0-2 to 43.1-2.

Are you sure that the root cause was this gnome-shell upgrade, and not
an upgrade of the mesa packages that may have happened at the same time?

Does downgrading gnome-shell (and the mutter library that it depends on)
back to 43.0 resolve this? If not, then it is likely that there is no
gnome-shell change that will fix it.

Alternatively, does downgrading the Mesa packages (libgl1-mesa-dri and
related packages) to the version from Debian 11 (20.3.5-1) resolve this?

> Some user-friendly person has decided to stop support for the i915 dri
> driver.
> As a "service" the mesa-upgrade at Debian also automatically deletes this
> driver.

The old i915 driver was removed from the main mesa packaging and is now
in a separate driver collection, mesa-amber, consisting of drivers for
older hardware that are no longer actively maintained. The Mesa team
packaged mesa-amber () and it was in
the NEW queue for a while, but it seems to have disappeared. I'm not
sure what its status was, perhaps the archive administrators rejected it?

What CPU and GPU are you running this on? I see you're using an i686
kernel: is it a 32-bit system?

i686 (32-bit PC) systems are increasingly difficult to support or
test on, so it is looking as though Debian 12 is likely to be the last
version that can be installed on i686 hardware. It might be safer to
stick to Debian 11 on hardware this old, or upgrade to newer hardware
(second-hand 64-bit PCs are widely available, and any good-quality laptop
from the last 10 years would probably improve both performance and power
consumption compared with a 32-bit system, especially if it is a desktop).

If your GPU is old enough to be unsupported by the crocus and iris drivers
(which are the replacement for i915 for newer Intel GPUs), then your CPU
is probably also rather old, which can cause problems for the llvmpipe
(swrast) driver: that driver does some basic rendering on the CPU, but
to do that at an acceptable speed, it tries to make use of non-baseline
CPU extensions.

> Also if "Gnome on Xorg" is started there is no flickering problem.
> In that case swrast is used for software rendering.

If your GPU is too old for the drivers available in mesa, and the mesa-amber
drivers are not installed, then the intended fallback is llvmpipe
(swrast_dri.so). I would have expected that it would be used for both Xorg
and Wayland. However, GNOME in Wayland mode might have higher requirements
for the quality of the drivers than GNOME in Xorg mode, or just different
behaviour, resulting in flickering in Wayland mode but not in Xorg mode.

> I do not know which method gnome with wayland is using, but it is not
> swrast.

Do you have evidence that it is not using swrast? If yes, what?

smcv

Bug#1022169: llvm-toolchain-15: FTBFS on mips*el: static assertion failed: struct_kernel_stat_sz == sizeof(stat)

[Simon McVittie]

Source: llvm-toolchain-15
Version: 1:15.0.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source, making mesa unbuildable
User: debian-m...@lists.debian.org
Usertags: mipsel mips64el
X-Debbugs-Cc: debian-m...@lists.debian.org, m...@packages.debian.org
Control: affects -1 + src:mesa

Quoting from mips64el buildd logs, but mipsel has a similar failure:

> /<>/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_linux.cpp:67:1:
>  error: static assertion failed due to requirement 'struct_kernel_stat_sz == 
> sizeof(stat)':
> COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct stat));

Strictly speaking this is not a regression because llvm-toolchain-15 was
never built successfully on mips*el, but I think it should be treated as
RC anyway, because older llvm-toolchain-* were buildable on mips*el (and
mesa is already using llvm-toolchain-15, making it a key package).

smcv

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'oldstable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1021201: vulkan-loader: new upstream stable point release 1.3.224.1

[Simon McVittie]

Source: vulkan-loader
Version: 1.3.224.0-1
Severity: wishlist

vulkan-loader is currently at upstream version 1.3.224.0, but upstream's
sdk-1.3.224 stable branch now has a 1.3.224.1 point release with these
release notes:

> Enable layer interception of unknown functions
>
> Re-add previously reverted behavior that allows layers to setup
> dispatch chains for unknown physical device and device functions during
> vkCreateInstance. Previously, functions not known to the loader could
> not be queried by a layer during vkCreateInstance (when dispatch tables
> should be setup). The change adds support for unknown functions in the
> trampolines of vkGetInstanceProcAddr and vkGetPhysicalDeviceProcAddr.

If I'm reading correctly, this is a backport of part of
https://github.com/KhronosGroup/Vulkan-Loader/pull/999,
which seems to be a fix for bugs seen with the RenderDoc and
GFXReconstruct development tools.

smcv

Re: RFP: mesa for bullseye-backports

[Simon McVittie]

On Sun, 02 Oct 2022 at 17:38:12 -0700, Alex Relis wrote:
> I think it would be a good idea to bring a newer version of mesa to Debian
> Bullseye by bringing it to bullseye-backports. Here are some reasons why:
> 
> 1. It reduces friction when running Debian Stable on newer hardware:
> bullseye-backports already has linux-image-amd64 and nvidia-driver; adding a
> newer mesa will just make using newer hardware that much more easier while
> still having a nice stable base.
> 2. It's for the gamers: because steam still calls the system installed
> version of mesa, having the option to install a newer version tends to make
> games run better/fewer issues.
> 3. It has been done in the past: mesa has been in stretch-backports and
> buster-backports, so maybe a maintainer with experience can have a look at
> it when they get the chance.
> 
> Anyways, thanks for taking the time to read this and hope it one day gets
> implemented.

Cc'ing the mesa maintainers (full request quoted) in case none of them are
following the backports list.

Expanding on point 2 a bit, the version of DXVK that is included in
"Proton - experimental" requires an extension that is not in Debian 11's
Mesa, so it needs Mesa 22 or later (or the NVIDIA proprietary driver 510.47
or later, for people who use that). Reference:
https://github.com/ValveSoftware/Proton/wiki/Changelog

I suspect that this new requirement will go into one of the "stable"
versions of Proton at some point, at which point Debian 11 users will be
unable to use the current version of Proton without Mesa backports.

smcv

Re: Bug#993550: gtk4: gsk repeat, repeat-negative-coords tests fail with ngl renderer on mips*el

[Simon McVittie]

Control: reassign -1 src:mesa
Control: affects -1 + src:gtk4

On Fri, 03 Sep 2021 at 00:19:29 +0100, Simon McVittie wrote:
> GTK 4 has a new scene-graph-based rendering model, "GSK", with an OpenGL
> preferred implementation and a Cairo fallback. Its regression tests draw
> various combinations of "render nodes" and check the results against
> reference PNG images.
> 
> When using the "new" OpenGL renderer, "ngl", there's a weird rendering
> glitch on mips*el on two tests involving repeating a pattern: the top
> left pixel in each 2x2 block is darker than the other three.
> For more details and comparison images:
> https://gitlab.gnome.org/GNOME/gtk/-/issues/4228
> 
> Is there anything unusual about the OpenGL implementation on mips*el
> that would cause this sort of thing? It seems to be using Mesa swrast_dri.so
> (which I think is llvmpipe?), the same as any other machine without a GPU.

This seems likely to be a mips*-specific bug in Mesa's llvmpipe or some
dependency of llvmpipe (maybe LLVM?), rather than directly a GTK bug: I
can avoid the test failure by running tests with GALLIUM_DRIVER=softpipe
and LIBGL_ALWAYS_SOFTWARE=true in the environment.

I've set up the GTK build to use GALLIUM_DRIVER=softpipe and
LIBGL_ALWAYS_SOFTWARE=true for build-time tests, and I don't intend to
investigate this further from GTK's point of view. Investigation by the
mips porting team would be appreciated.

smcv

Re: Bug#1003348: gtk4: Background blend mode clip interaction not working as intended on mips*el

[Simon McVittie]

Control: reassign -1 src:mesa
Control: affects -1 + src:gtk4

On Sat, 08 Jan 2022 at 18:35:20 +, Simon McVittie wrote:
> Similar to #993550, GTK 4 has a new test failure on mips*el.
> Please see https://gitlab.gnome.org/GNOME/gtk/-/issues/4618 for details.

This seems likely to be a mips*-specific bug in Mesa's llvmpipe or some
dependency of llvmpipe (maybe LLVM?), rather than directly a GTK bug: I
can avoid the test failure by running tests with GALLIUM_DRIVER=softpipe
and LIBGL_ALWAYS_SOFTWARE=true in the environment.

I've set up the GTK build to use GALLIUM_DRIVER=softpipe and
LIBGL_ALWAYS_SOFTWARE=true for build-time tests, and I don't intend to
investigate this further from GTK's point of view. Investigation by the
mips porting team would be appreciated.

smcv

Bug#1015039: gtk4 memorytexture test-case regresses with Mesa 22.1

[Simon McVittie]

Control: tags -1 + patch

On Tue, 19 Jul 2022 at 11:56:43 +0100, Simon McVittie wrote:
> A straightforward revert of 6bbbe15a applies cleanly to 22.1.x and
> appears to solve this.

Alternatively, upstream merge request
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17702 is waiting
for review, and a backport of it to 22.1.3 also appears to solve this
(see attached).

Because this is a RC bug (it caused FTBFS in gtk4, and apparently also
cases rendering errors in real-world use of gtk4 on llvmpipe), Mesa 22.1
will not migrate to testing until this is solved somehow or downgraded.

Please consider either reverting 6bbbe15a (the conservative approach)
or applying !17702.

Thanks,
smcv
>From 235c8f728eef3fc2bbc97cfe0be007dda0b0d96d Mon Sep 17 00:00:00 2001
From: Dave Airlie 
Date: Fri, 22 Jul 2022 11:12:58 +1000
Subject: [PATCH 1/3] llvmpipe: make last_fence a screen/rast object not a
 context one.

When a flush happens the per-context setup is used to hold the fence
for the last scene sent to the rasterizer. However when multiple
contexts are in use, this fence won't get returned to be blocked on.

Instead move the last fence to the rasterizer object, and return
that instead as it should be valid across contexts.

Fixes gtk4 bugs on llvmpipe since overlapping vertex/fragment.

Fixes: 6bbbe15a783a ("Reinstate: llvmpipe: allow vertex processing and fragment processing in parallel")
Origin: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17702
---
 src/gallium/drivers/llvmpipe/lp_flush.c   | 12 ++---
 src/gallium/drivers/llvmpipe/lp_rast.c| 14 +-
 src/gallium/drivers/llvmpipe/lp_rast.h|  3 ++-
 src/gallium/drivers/llvmpipe/lp_rast_priv.h   |  2 ++
 src/gallium/drivers/llvmpipe/lp_setup.c   | 26 +--
 src/gallium/drivers/llvmpipe/lp_setup.h   |  1 -
 .../drivers/llvmpipe/lp_setup_context.h   |  1 -
 7 files changed, 33 insertions(+), 26 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_flush.c b/src/gallium/drivers/llvmpipe/lp_flush.c
index c231f334eaf..c72944232e7 100644
--- a/src/gallium/drivers/llvmpipe/lp_flush.c
+++ b/src/gallium/drivers/llvmpipe/lp_flush.c
@@ -38,7 +38,9 @@
 #include "lp_flush.h"
 #include "lp_context.h"
 #include "lp_setup.h"
-
+#include "lp_fence.h"
+#include "lp_screen.h"
+#include "lp_rast.h"
 
 /**
  * \param fence  if non-null, returns pointer to a fence which can be waited on
@@ -49,11 +51,15 @@ llvmpipe_flush( struct pipe_context *pipe,
 const char *reason)
 {
struct llvmpipe_context *llvmpipe = llvmpipe_context(pipe);
-
+   struct llvmpipe_screen *screen = llvmpipe_screen(pipe->screen);
draw_flush(llvmpipe->draw);
 
/* ask the setup module to flush */
-   lp_setup_flush(llvmpipe->setup, fence, reason);
+   lp_setup_flush(llvmpipe->setup, reason);
+
+   lp_rast_fence(screen->rast, (struct lp_fence **)fence);
+   if (fence && (!*fence))
+  *fence = (struct pipe_fence_handle *)lp_fence_create(0);
 
/* Enable to dump BMPs of the color/depth buffers each frame */
if (0) {
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c b/src/gallium/drivers/llvmpipe/lp_rast.c
index e27d78a3432..6cdaa51b62d 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -47,6 +47,7 @@
 #include "gallivm/lp_bld_format.h"
 #include "gallivm/lp_bld_debug.h"
 #include "lp_scene.h"
+#include "lp_screen.h"
 #include "lp_tex_sample.h"
 
 
@@ -1128,6 +1129,10 @@ lp_rast_queue_scene( struct lp_rasterizer *rast,
 {
LP_DBG(DEBUG_SETUP, "%s\n", __FUNCTION__);
 
+   lp_fence_reference(&rast->last_fence, scene->fence);
+   if (rast->last_fence)
+  rast->last_fence->issued = TRUE;
+
if (rast->num_threads == 0) {
   /* no threading */
   unsigned fpstate = util_fpstate_get();
@@ -1384,6 +1389,8 @@ void lp_rast_destroy( struct lp_rasterizer *rast )
   align_free(rast->tasks[i].thread_data.cache);
}
 
+   lp_fence_reference(&rast->last_fence, NULL);
+
/* for synchronizing rasterization threads */
if (rast->num_threads > 0) {
   util_barrier_destroy( &rast->barrier );
@@ -1394,4 +1401,9 @@ void lp_rast_destroy( struct lp_rasterizer *rast )
FREE(rast);
 }
 
-
+void lp_rast_fence(struct lp_rasterizer *rast,
+   struct lp_fence **fence)
+{
+   if (fence)
+  lp_fence_reference((struct lp_fence **)fence, rast->last_fence);
+}
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.h b/src/gallium/drivers/llvmpipe/lp_rast.h
index 14a2710f7f5..1756345737f 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.h
+++ b/src/gallium/drivers/llvmpipe/lp_rast.h
@@ -388,5 +388,6 @@ lp_debug_draw_bins_by_cmd_length( struct lp_scene *scene );
 void
 lp_debug_draw_bins_by_coverage( struct lp_scene *sc

Bug#965901: xfonts-encodings: fix FTBFS and missing build-* targets

[Simon McVittie]

On Thu, 21 Jul 2022 at 13:30:19 +0100, Simon McVittie wrote:
> I've prepared merge requests for all the xfonts-* packages (except
> xfonts-utils which contains utilities rather than fonts)

Diffs for -encodings attached. There was no bug report for the missing
build-* targets, but they're also a RC bug.

smcv
>From 18a02f6b69f7b4b5ba9d86933f142ea9d58e3c38 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:52:34 +0100
Subject: [PATCH 1/5] d/control: Update Vcs-* for migration to salsa.debian.org

---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 4244874..e7efb58 100644
--- a/debian/control
+++ b/debian/control
@@ -11,8 +11,8 @@ Build-Depends-Indep:
  automake,
  xutils-dev (>= 1:7.5+1),
 Standards-Version: 3.8.3
-Vcs-Git: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-encodings.git
-Vcs-Browser: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-encodings.git
+Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-encodings.git
+Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-encodings
 
 Package: xfonts-encodings
 Architecture: all
-- 
2.36.1

>From df31d46de9bfc95235ddf7eacffd18297df8e1e2 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:54:21 +0100
Subject: [PATCH 2/5] Use recommended debhelper compat level 13

Compat levels 5 and 6 can no longer be built in bookworm.

- d/rules: Replace deprecated dh_clean -k with dh_prep
- d/rules: Replace deprecated dh_install --list-missing with
  dh_missing --list-missing

According to diffoscope, the only change to the resulting binary package
is that this compat level adds the upstream changelog.

Closes: #965901
---
 debian/compat  | 1 -
 debian/control | 2 +-
 debian/rules   | 5 +++--
 3 files changed, 4 insertions(+), 4 deletions(-)
 delete mode 100644 debian/compat

diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index 7ed6ff8..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-5
diff --git a/debian/control b/debian/control
index e7efb58..8b96496 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: x11
 Priority: optional
 Maintainer: Debian X Strike Force 
 Build-Depends:
- debhelper (>= 5.0.0),
+ debhelper-compat (= 13),
 Build-Depends-Indep:
  pkg-config,
  xfonts-utils (>= 1:7.6~),
diff --git a/debian/rules b/debian/rules
index 8e65d61..6c5b69e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -63,7 +63,7 @@ clean: xsfclean
 install: build
 	dh_testdir
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	dh_installdirs
 	cd build && $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
 
@@ -77,7 +77,8 @@ binary-indep: build install
 	dh_testroot
 
 	dh_installdocs
-	dh_install --sourcedir=debian/tmp --list-missing
+	dh_install --sourcedir=debian/tmp
+	dh_missing --list-missing
 	dh_installchangelogs
 	dh_link
 	dh_strip
-- 
2.36.1

>From 08d314fe524135feadfd07112cc16128c358d16f Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:03:13 +0100
Subject: [PATCH 3/5] =?UTF-8?q?d/rules:=20Add=20missing=20targets=20build-?=
 =?UTF-8?q?arch,=20build-indep=20(Policy=20=C2=A74.9)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This resolves the equivalent of #999177 for this package.

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index 6c5b69e..c91421c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,6 +34,7 @@ endif
 
 
 build: build-stamp
+build-indep: build-stamp
 build-stamp:
 	dh_testdir
 	autoreconf -vfi
@@ -45,6 +46,9 @@ build-stamp:
 	cd build && $(MAKE)
 	>$@
 
+build-arch:
+# Nothing to do
+
 clean: xsfclean
 	dh_testdir
 	dh_testroot
-- 
2.36.1

>From 85bea910a02802776ea51ef59b566a8c20b78cdc Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:04:08 +0100
Subject: [PATCH 4/5] d/control: Declare that the build does not require
 (fake)root

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 8b96496..175e83c 100644
--- a/debian/control
+++ b/debian/control
@@ -13,6 +13,7 @@ Build-Depends-Indep:
 Standards-Version: 3.8.3
 Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-encodings.git
 Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-encodings
+Rules-Requires-Root: no
 
 Package: xfonts-encodings
 Architecture: all
-- 
2.36.1

>From 9f73254a4913ef561232802807903716463c9182 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:22:48 +0100
Subject: [PATCH 5/5] Update changelog

---
 debian/changelog | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 

Bug#965894: xfonts-scalable: fix FTBFS and missing required debian/rules targets

[Simon McVittie]

On Thu, 21 Jul 2022 at 13:30:19 +0100, Simon McVittie wrote:
> I've prepared merge requests for all the xfonts-* packages (except
> xfonts-utils which contains utilities rather than fonts)

Diffs for -scalable attached. As with -encodings, the missing build-arch
and build-indep targets are a second RC bug, but I'm not going to spend
time reporting a second RC bug and getting a second bug number just so
I can propose a patch to close it.

smcv
>From d8ae598f46674b56152f2a9347bf7712359648aa Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:57:08 +0100
Subject: [PATCH 1/5] d/control: Update Vcs-* for migration to salsa.debian.org

---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 553de3b..5ffb6d3 100644
--- a/debian/control
+++ b/debian/control
@@ -10,8 +10,8 @@ Build-Depends:
  xutils-dev (>= 1:7.5+1),
  pkg-config,
 Standards-Version: 3.8.3
-Vcs-Git: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-scalable.git
-Vcs-Browser: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-scalable.git
+Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-scalable.git
+Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-scalable
 
 Package: xfonts-scalable
 Architecture: all
-- 
2.36.1

>From 020b14f4ce6c9add3e4a7d71578771c66547656e Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:05:23 +0100
Subject: [PATCH 2/5] Use recommended debhelper compat level 13

Compat levels 5 and 6 can no longer be built in bookworm.

- d/rules: Replace deprecated dh_clean -k with dh_prep
- d/rules: Replace deprecated dh_install --list-missing with
  dh_missing --list-missing

According to diffoscope, the only change to the resulting binary package
is that this compat level adds the upstream changelog.

Closes: #965894
---
 debian/compat  | 1 -
 debian/control | 2 +-
 debian/rules   | 5 +++--
 3 files changed, 4 insertions(+), 4 deletions(-)
 delete mode 100644 debian/compat

diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index 7ed6ff8..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-5
diff --git a/debian/control b/debian/control
index 5ffb6d3..580c43a 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: fonts
 Priority: optional
 Maintainer: Debian X Strike Force 
 Build-Depends:
- debhelper (>= 5.0.31),
+ debhelper-compat (= 13),
  xfonts-utils (>= 1:7.6~),
  automake,
  autoconf,
diff --git a/debian/rules b/debian/rules
index 478acb1..dc614d7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -64,7 +64,7 @@ clean: xsfclean
 install: build
 	dh_testdir
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	dh_installdirs
 
 	cd build && $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
@@ -81,7 +81,8 @@ binary-indep: build install
 	dh_testroot
 
 	dh_installdocs
-	dh_install --sourcedir=debian/tmp --fail-missing --exclude=fonts.dir --exclude=fonts.scale
+	dh_install --sourcedir=debian/tmp --exclude=fonts.dir --exclude=fonts.scale
+	dh_missing --fail-missing --exclude=fonts.dir --exclude=fonts.scale
 	dh_installxfonts
 	dh_installchangelogs
 	dh_compress
-- 
2.36.1

>From 1a905ea923b52829645dfa4244542b8723b88d20 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:08:00 +0100
Subject: [PATCH 3/5] =?UTF-8?q?d/rules:=20Add=20missing=20build-arch,=20bu?=
 =?UTF-8?q?ild-indep=20targets=20(Policy=20=C2=A74.9)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This resolves the equivalent of #999177 for this package.

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index dc614d7..81005dc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,6 +34,7 @@ endif
 
 
 build: build-stamp
+build-indep: build-stamp
 build-stamp: $(STAMP_DIR)/prepare
 	dh_testdir
 	autoreconf -vfi
@@ -45,6 +46,9 @@ build-stamp: $(STAMP_DIR)/prepare
 	cd build && $(MAKE)
 	>$@
 
+build-arch:
+# Nothing to do
+
 clean: xsfclean
 	dh_testdir
 	dh_testroot
-- 
2.36.1

>From 8e6373344b0cf78e807c2fd52dba66e2524ce523 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:08:23 +0100
Subject: [PATCH 4/5] d/control: Declare that the build does not require
 (fake)root

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 580c43a..f5a92b9 100644
--- a/debian/control
+++ b/debian/control
@@ -12,6 +12,7 @@ Build-Depends:
 Standards-Version: 3.8.3
 Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-scalable.git
 Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-scalable
+Rules-Requires-Root: no
 
 Package: xfonts-scalable
 Architecture: all
-- 
2.36.1

>From 5410658a402f6825a9

Bug#976571: Bug#999152: xfonts-100dpi: missing required debian/rules targets build-arch and/or build-indep

[Simon McVittie]

On Thu, 21 Jul 2022 at 13:30:19 +0100, Simon McVittie wrote:
> I've prepared merge requests for all the xfonts-* packages (except
> xfonts-utils which contains utilities rather than fonts)

-100dpi diffs attached.

smcv
>From bf4eb2eac34232a1ccf3ee994b48760a8f2c49ed Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:30:03 +0100
Subject: [PATCH 1/4] =?UTF-8?q?d/rules:=20Add=20missing=20build-arch,=20bu?=
 =?UTF-8?q?ild-indep=20targets=20(Policy=20=C2=A74.9)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Closes: #999152
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index 6789d06..be92b35 100755
--- a/debian/rules
+++ b/debian/rules
@@ -48,9 +48,13 @@ $(STAMP_DIR)/build-%:
 	>$@
 
 build: build-stamp
+build-indep: build-stamp
 build-stamp: $(addprefix $(STAMP_DIR)/build-,$(SUBDIRS))
 	>$@
 
+build-arch:
+# Nothing to do
+
 clean:
 	dh_testdir
 	rm -f config.cache config.log config.status
-- 
2.36.1

>From eb1382d7797ab31de5846fdf258ff9d8d49b9ea7 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:30:42 +0100
Subject: [PATCH 2/4] d/control: Declare that the build does not require
 (fake)root

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index fbce30a..2ca266d 100644
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,7 @@ Build-Depends: debhelper (>= 7), pkg-config, xfonts-utils (>= 1:7.5)
 Standards-Version: 3.8.3
 Vcs-Git: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-100dpi.git
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-xorg/font/xfonts-100dpi.git
+Rules-Requires-Root: no
 
 Package: xfonts-100dpi
 Architecture: all
-- 
2.36.1

>From 308ddf0a66269751ea07e5f92125af8182479c7f Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:31:23 +0100
Subject: [PATCH 3/4] Use dh_update_autotools_config to update config.guess,
 config.sub

The originals will be put back automatically by dh_clean.

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Closes: #976571
---
 debian/control | 2 +-
 debian/rules   | 6 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 2ca266d..8feb4de 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: xfonts-100dpi
 Section: fonts
 Priority: optional
 Maintainer: Debian X Strike Force 
-Build-Depends: debhelper (>= 7), pkg-config, xfonts-utils (>= 1:7.5)
+Build-Depends: debhelper (>= 10.8), pkg-config, xfonts-utils (>= 1:7.5)
 Standards-Version: 3.8.3
 Vcs-Git: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-100dpi.git
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-xorg/font/xfonts-100dpi.git
diff --git a/debian/rules b/debian/rules
index be92b35..324aeac 100755
--- a/debian/rules
+++ b/debian/rules
@@ -35,8 +35,12 @@ else
 	confflags += --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
 endif
 
-$(STAMP_DIR)/build-%:
+$(STAMP_DIR)/prepare:
 	mkdir -p $(STAMP_DIR)
+	dh_update_autotools_config
+	>$@
+
+$(STAMP_DIR)/build-%: $(STAMP_DIR)/prepare
 	mkdir -p $*-build
 	cd $*-build && \
 	../$*/configure \
-- 
2.36.1

>From 11e7a5f7bef7f5586c6ac6f389d32fed94bc04e2 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:20:03 +0100
Subject: [PATCH 4/4] Update changelog

---
 debian/changelog | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 5b66d9e..372c2ef 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,17 @@
 xfonts-100dpi (1:1.0.5) UNRELEASED; urgency=medium
 
+  [ Julien Cristau ]
   * Add Vcs-* control fields.
   * Use https for xorg.freedesktop.org URLs in packaging.
 
- -- Julien Cristau   Mon, 02 Feb 2015 21:07:25 +0100
+  [ Simon McVittie ]
+  * d/rules: Add missing build-arch, build-indep targets (Policy §4.9)
+(Closes: #999152)
+  * d/control: Declare that the build does not require (fake)root
+  * Use dh_update_autotools_config to update config.guess, config.sub
+(Closes: #976571)
+
+ -- Simon McVittie   Thu, 21 Jul 2022 11:19:37 +0100
 
 xfonts-100dpi (1:1.0.4+nmu1) unstable; urgency=medium
 
-- 
2.36.1

Bug#976471: Bug#998997: xfonts-75dpi: missing required debian/rules targets build-arch and/or build-indep

[Simon McVittie]

On Thu, 21 Jul 2022 at 13:30:19 +0100, Simon McVittie wrote:
> I've prepared merge requests for all the xfonts-* packages (except
> xfonts-utils which contains utilities rather than fonts)

Diffs for -75dpi attached.

smcv
>From 1f5a1270c484a8e7b6a1ac4be8c09379de97613b Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:02:26 +0100
Subject: [PATCH 1/5] d/control: Update Vcs-* for migration to salsa.debian.org

---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 43767b9..ed02504 100644
--- a/debian/control
+++ b/debian/control
@@ -7,8 +7,8 @@ Build-Depends:
  pkg-config,
  xfonts-utils (>= 1:7.5),
 Standards-Version: 3.8.3
-Vcs-Git: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-75dpi.git
-Vcs-Browser: https://anonscm.debian.org/cgit/pkg-xorg/font/xfonts-75dpi.git
+Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-75dpi.git
+Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-75dpi
 
 Package: xfonts-75dpi
 Architecture: all
-- 
2.36.1

>From d2253649ad53e5d2382d481dc463a5d930f30b08 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:18:18 +0100
Subject: [PATCH 2/5] =?UTF-8?q?d/rules:=20Add=20missing=20build-arch,=20bu?=
 =?UTF-8?q?ild-indep=20targets=20(Policy=20=C2=A74.9)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Closes: #998997
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index ef5f2f4..ce29bc9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -48,9 +48,13 @@ $(STAMP_DIR)/build-%:
 	>$@
 
 build: build-stamp
+build-indep: build-stamp
 build-stamp: $(addprefix $(STAMP_DIR)/build-,$(SUBDIRS))
 	>$@
 
+build-arch:
+# Nothing to do.
+
 clean:
 	dh_testdir
 	rm -f config.cache config.log config.status
-- 
2.36.1

>From 27e43c27acefcf2c9e8e5a9d44f6a5b903564b8b Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:18:41 +0100
Subject: [PATCH 3/5] d/control: Declare that the build does not require
 (fake)root

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index ed02504..a3cd302 100644
--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,7 @@ Build-Depends:
 Standards-Version: 3.8.3
 Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-75dpi.git
 Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-75dpi
+Rules-Requires-Root: no
 
 Package: xfonts-75dpi
 Architecture: all
-- 
2.36.1

>From d0e24c3c6238094c8f2ecb7c874ad38f3caebd06 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:19:32 +0100
Subject: [PATCH 4/5] d/rules: Use dh_update_autotools_config to update
 config.guess, config.sub

The originals will be put back automatically by dh_clean.

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Closes: #976471
---
 debian/rules | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index ce29bc9..1fd4653 100755
--- a/debian/rules
+++ b/debian/rules
@@ -35,8 +35,12 @@ else
 	confflags += --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
 endif
 
-$(STAMP_DIR)/build-%:
+$(STAMP_DIR)/prepare:
 	mkdir -p $(STAMP_DIR)
+	dh_update_autotools_config
+	>$@
+
+$(STAMP_DIR)/build-%: $(STAMP_DIR)/prepare
 	mkdir -p $*-build
 	cd $*-build && \
 	../$*/configure \
-- 
2.36.1

>From e5390c3fe040f36be2ebecf0871f885076597c2a Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:18:40 +0100
Subject: [PATCH 5/5] Update changelog

---
 debian/changelog | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 19903bf..81b4358 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,18 @@
 xfonts-75dpi (1:1.0.5) UNRELEASED; urgency=medium
 
+  [ Julien Cristau ]
   * Update Vcs-Git URL to https.
   * Switch xorg.freedesktop.org URLs in packaging to https.
 
- -- Julien Cristau   Sun, 21 Aug 2016 19:10:17 +0200
+  [ Simon McVittie ]
+  * d/control: Update Vcs-* for migration to salsa.debian.org
+  * d/rules: Add missing build-arch, build-indep targets (Policy §4.9)
+(Closes: #998997)
+  * d/control: Declare that the build does not require (fake)root
+  * d/rules: Use dh_update_autotools_config to update config.guess,
+config.sub (Closes: #976471)
+
+ -- Simon McVittie   Thu, 21 Jul 2022 11:18:20 +0100
 
 xfonts-75dpi (1:1.0.4+nmu1) unstable; urgency=medium
 
-- 
2.36.1

Bug#999227: xfonts-cyrillic: missing required debian/rules targets build-arch and/or build-indep

[Simon McVittie]

On Thu, 21 Jul 2022 at 13:30:19 +0100, Simon McVittie wrote:
> I've prepared merge requests for all the xfonts-* packages (except
> xfonts-utils which contains utilities rather than fonts) fixing the
> missing targets required by Policy §4.9

Here are diffs for xfonts-cyrillic as requested.

Because the reproducible builds NMU for xfonts-cyrillic was
mistakenly versioned like a maintainer/QA upload, the changelog
entry assumes that the NMU will be merged, since that seems like
the easiest way to avoid reusing a version number. Please see the MR
https://salsa.debian.org/xorg-team/font/xfonts-cyrillic/-/merge_requests/1
or fetch the qa branch from
https://salsa.debian.org/smcv/xfonts-cyrillic-qa.git for the actual merge
(since a merge as a proper git merge is not easily representable in
diffs), or resolve the changelogs in whatever way you see fit.

smcv
>From 41daa3f4c18e432827d67b771b8f9c5c1f9c624a Mon Sep 17 00:00:00 2001
From: Holger Levsen 
Date: Fri, 1 Jan 2021 17:23:03 +0100
Subject: [PATCH 1/6] Import Debian version 1.0.5

xfonts-cyrillic (1:1.0.5) unstable; urgency=medium
.
  * Non maintainer upload by the Reproducible Builds team.
  * No source change upload to rebuild on buildd with .buildinfo files.
---
 debian/changelog | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 1f51b52..b8f7d69 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+xfonts-cyrillic (1:1.0.5) unstable; urgency=medium
+
+  * Non maintainer upload by the Reproducible Builds team.
+  * No source change upload to rebuild on buildd with .buildinfo files.
+
+ -- Holger Levsen   Fri, 01 Jan 2021 17:23:03 +0100
+
 xfonts-cyrillic (1:1.0.4) unstable; urgency=medium
 
   * Get rid of debian/xsfbs/.
-- 
2.36.1

>From bd08f1035f774974d2005e1182be680155c2b4ea Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:36:27 +0100
Subject: [PATCH 2/6] d/control: Update Vcs-* for migration to salsa.debian.org

---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 6164ab6..62b7df3 100644
--- a/debian/control
+++ b/debian/control
@@ -7,8 +7,8 @@ Build-Depends:
  xfonts-utils (>= 1:7.5),
  pkg-config,
 Standards-Version: 3.8.3
-Vcs-Git: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-cyrillic.git
-Vcs-Browser: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-cyrillic.git
+Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-cyrillic.git
+Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-cyrillic
 
 Package: xfonts-cyrillic
 Architecture: all
-- 
2.36.1

>From 4b2f9a5f220307fe94177f563af7ae7bfdba81d7 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:34:58 +0100
Subject: [PATCH 3/6] =?UTF-8?q?d/rules:=20Add=20missing=20build-arch,=20bu?=
 =?UTF-8?q?ild-indep=20targets=20(Policy=20=C2=A74.9)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Closes: #999227
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index cbfa1f4..907896d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -48,9 +48,13 @@ $(STAMP_DIR)/build-%:
 	>$@
 
 build: build-stamp
+build-indep: build-stamp
 build-stamp: $(addprefix $(STAMP_DIR)/build-,$(SUBDIRS))
 	>$@
 
+build-arch:
+# Nothing to do
+
 clean:
 	dh_testdir
 	rm -f config.cache config.log config.status
-- 
2.36.1

>From 29cffc196b0dd0846c2186a38d512c45f70e18aa Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:36:52 +0100
Subject: [PATCH 4/6] d/control: Declare that the build does not require
 (fake)root

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 62b7df3..0da8a6b 100644
--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,7 @@ Build-Depends:
 Standards-Version: 3.8.3
 Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-cyrillic.git
 Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-cyrillic
+Rules-Requires-Root: no
 
 Package: xfonts-cyrillic
 Architecture: all
-- 
2.36.1

>From 1b9d9460084ab69873a4dda5d5dc7d343b065232 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:38:10 +0100
Subject: [PATCH 5/6] d/rules: Use dh_update_autotools_config to update
 config.guess, config.sub

The originals will be put back automatically by dh_clean.

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Fixes the equivalent of #856271, #976471, #976571 for this package.
---
 debian/control | 2 +-
 debian/rules   | 6 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 0da8a6b..18deb4f 100644
--- a/debian/con

Bug#856271: Bug#999177: xfonts-*: missing required debian/rules targets build-arch and/or build-indep

[Simon McVittie]

On Thu, 21 Jul 2022 at 16:35:31 +, Thorsten Glaser wrote:
> Simon McVittie dixit:
> 
> >I've prepared merge requests for all the xfonts-* packages (except
>
> IMHO, things like this ought to be sent as diffs attached to
> the bugreport(s) in question.

If that's what you want, here are diffs (these are only the xfonts-base
subset, the remarkably similar diffs for the other packages will follow
when I get round to it).

Not all of the things I've fixed have bug reports on all the packages.

> Probably somewhat offtopic, but… Salsa isn’t an appropriate tool
> Or how would someone be able to review the diff like
> *that* (see attached screenshot)?

I had assumed that a team that has put repositories on Salsa is able to
receive commits from it. Each Gitlab MR can be fetched as a git branch,
if you prefer to use the CLI for review:

[remote "merge-requests"]
url = https://salsa.debian.org/xorg-team/font/xfonts-base.git
fetch = +refs/merge-requests/*/head:refs/remotes/merge-requests/*

Or if you want to try the web UI, closing the file list/search on the
left should give the content of the diff enough space to not wrap.

smcv
>From 0ecb409ab80272e5a8203ec93a4225b9e3a3d970 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 09:47:34 +0100
Subject: [PATCH 1/4] =?UTF-8?q?d/rules:=20Add=20missing=20build-arch,=20bu?=
 =?UTF-8?q?ild-indep=20targets=20(Policy=20=C2=A74.9)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Closes: #999177
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index d73519e..99f313b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -60,9 +60,13 @@ $(STAMP_DIR)/build-%:
 
 
 build: build-stamp
+build-indep: build-stamp
 build-stamp: $(addprefix $(STAMP_DIR)/build-,$(SUBDIRS))
 	>$@
 
+build-arch:
+# Nothing to do.
+
 clean:
 	dh_testdir
 	rm -f config.cache config.log config.status
-- 
2.36.1

>From a9dfb137281b58e92298403ef7a07f392b7ba2ab Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 09:52:36 +0100
Subject: [PATCH 2/4] d/control: Declare that the build does not require
 (fake)root

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 856a54b..b0a9ff5 100644
--- a/debian/control
+++ b/debian/control
@@ -11,6 +11,7 @@ Build-Depends-Indep:
 Standards-Version: 3.8.3
 Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-base.git
 Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-base
+Rules-Requires-Root: no
 
 Package: xfonts-base
 Architecture: all
-- 
2.36.1

>From 7b7691843c453886803a4a1fe1a5fa497a33e9d4 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:15:54 +0100
Subject: [PATCH 3/4] d/rules: Use dh_update_autotools_config to update
 config.guess, config.sub

The originals will be put back automatically by dh_clean.

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Closes: #856271
---
 debian/control | 2 +-
 debian/rules   | 6 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index b0a9ff5..2dcf9db 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: fonts
 Priority: optional
 Maintainer: Debian X Strike Force 
 Build-Depends:
- debhelper (>= 7),
+ debhelper (>= 10.8),
 Build-Depends-Indep:
  pkg-config,
  xfonts-utils (>= 1:7.5),
diff --git a/debian/rules b/debian/rules
index 99f313b..4e548a7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -45,8 +45,12 @@ else
 	confflags += --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
 endif
 
-$(STAMP_DIR)/build-%:
+$(STAMP_DIR)/prepare:
 	mkdir -p $(STAMP_DIR)
+	dh_update_autotools_config
+	>$@
+
+$(STAMP_DIR)/build-%: $(STAMP_DIR)/prepare
 	mkdir -p $*-build
 	cd $*-build && \
 	../$*/configure \
-- 
2.36.1

>From 3b12af51d153637bd0e45967e47f1d47a616e162 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:16:44 +0100
Subject: [PATCH 4/4] Update changelog

---
 debian/changelog | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 7271df0..d8a5622 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+xfonts-base (1:1.0.6) UNRELEASED; urgency=medium
+
+  * d/rules: Add missing build-arch, build-indep targets (Policy §4.9)
+(Closes: #999177)
+  * d/control: Declare that the build does not require (fake)root
+  * d/rules: Use dh_update_autotools_config to update config.guess,
+config.sub (Closes: #856271)
+
+ -- Simon McVittie   Thu, 21 Jul 2022 11:15:36 +0100
+
 xfonts-base (1:1.0.5) unstable; urgency=medium
 
   * Add Vcs-* control fields.
-- 
2.36.1

Bug#856271: xfonts-*: missing required debian/rules targets build-arch and/or build-indep

[Simon McVittie]

Control: tags -1 + patch

I've prepared merge requests for all the xfonts-* packages (except
xfonts-utils which contains utilities rather than fonts) fixing the
missing targets required by Policy §4.9:

https://salsa.debian.org/xorg-team/font/xfonts-100dpi/-/merge_requests/1
https://salsa.debian.org/xorg-team/font/xfonts-75dpi/-/merge_requests/1
https://salsa.debian.org/xorg-team/font/xfonts-base/-/merge_requests/1
https://salsa.debian.org/xorg-team/font/xfonts-cyrillic/-/merge_requests/1
https://salsa.debian.org/xorg-team/font/xfonts-encodings/-/merge_requests/1
https://salsa.debian.org/xorg-team/font/xfonts-scalable/-/merge_requests/1

Adding the new targets does not affect the contents of any built .deb.

I took the opportunity to fix the Vcs-Git, Vcs-Browser fields where
necessary, and add Rules-Requires-Root: no to avoid needing fakeroot
(I checked that this does not affect the contents of any of these .debs).

For -base, -cyrillic, -75dpi and -100dpi I also fixed FTBFS on newer
architectures such as arm64 by using dh_update_autotools_config to update
config.guess and config.sub (-base: #856271, -cyrillic: no bug reported,
-75dpi: #976471, -100dpi: #976571). Again, this does not affect the
contents of any built .deb. I didn't base this on Andrew Shadura's patch
from #856271, because that patch did the update manually and didn't handle
the clean step, whereas this version uses dh_update_autotools_config
which seems generally nicer (and in particular, dh_clean automatically
reverses it).

For -encodings and -scalable, the package's debhelper compat level 5
is no longer supported and the package FTBFS in unstable, so I had to
fix that first (#965901, #965894). Instead of doing a minimal bump to
deprecated version 7, I went directly to the recommended compat level
13 (available since stable and oldstable-backports). I verified with
diffoscope that the only effect this has on the contents of the .deb is
to add the upstream ChangeLog as changelog.gz, which seems harmless.

These packages would probably all benefit from moving to short-form dh,
but I haven't done that here, because that's a matter of style/opinion
which should be left to the maintainer.

Thanks,
smcv

Re: Bug#1015039: gtk4 memorytexture test-case regresses with Mesa 22.1

[Simon McVittie]

Control: reassign -1 src:mesa 22.1.3-1
Control: affects -1 + src:gtk4
Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/-/issues/6898

On Sat, 16 Jul 2022 at 18:16:11 +0100, Simon McVittie wrote:
> I can reproduce this test failure with sid's mesa 22.1.3-1, but not with
> bookworm's mesa, so it seems like this is probably a mesa regression (or
> possibly a mesa behaviour change that means what gtk4 is doing no longer
> works).

I bisected this to mesa commit 6bbbe15a "Reinstate: llvmpipe: allow
vertex processing and fragment processing in parallel" and reported it
upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6898

A straightforward revert of 6bbbe15a applies cleanly to 22.1.x and
appears to solve this.

smcv

Re: Bug#1015039: gtk4 memorytexture test-case regresses with Mesa 22.1

[Simon McVittie]

Control: retitle -1 gtk4 memorytexture test-case regresses with Mesa 22.1
Control: reassign -1 src:gtk4,src:mesa
Control: found -1 gtk4/4.6.6+ds-1
Control: found -1 mesa/22.1.3-1

On Sat, 16 Jul 2022 at 15:49:25 +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> > ▶  11/681 
> > ERROR:../../../testsuite/gdk/memorytexture.c:389:compare_textures: 
> > assertion failed (expected_data[y * width + x] == test_data[y * width + 
> > x]): (0x55441155 == 0x) ERROR 
> >  11/681 gtk:gdk / memorytexture 
> > ERROR   0.98s   killed by signal 6 SIGABRT

Context for Mesa maintainers: gtk4 fails one of its build-time tests
when built in a current sid environment. In this test, it fills a local
memory buffer with a random colour, uploads it to a GL texture, downloads
it using glReadPixels and compares each pixel with a matching in-memory
texture. The good result is that the colour is the same; the failing
result observed is that the texture is transparent black, rgba(0,0,0,0).

I can reproduce this test failure with sid's mesa 22.1.3-1, but not with
bookworm's mesa, so it seems like this is probably a mesa regression (or
possibly a mesa behaviour change that means what gtk4 is doing no longer
works).

I can also reproduce this test failure without needing to rebuild gtk4,
by using the installed-tests provided in the gtk-4-tests package. Steps
to reproduce:

# apt build-dep gtk4
# apt install gtk-4-tests xvfb xauth dbus
# adduser --disabled-password user
# runuser -u user -- xvfb-run dbus-run-session -- \
  /usr/libexec/installed-tests/gtk-4.0/gdk/memorytexture \
  || echo "failed with status $?"

In a debian:bookworm-slim podman container, this test succeeds.

With all packages except for src:mesa upgraded from bookworm to sid, this
test still succeeds (see attached working-packages.gz).

With all packages *including* those from src:mesa upgraded from bookworm
to sid, the test starts to fail (see attached not-working-packages.gz).

The test has a lot of versions of the scenario that I described, for
different texture sizes, pixel encodings and upload/download pairs: you
can run it as

/usr/libexec/installed-tests/gtk-4.0/gdk/memorytexture -l

to list them, and then run with arguments like

/usr/libexec/installed-tests/gtk-4.0/gdk/memorytexture -p 
/memorytexture/download_4x4/b8g8r8/gl

to run just one version.

>From a bit of experimenting, it seems like the pattern is:

* 1x1/*/gl: fails
* 4x4/*/gl: fails
* 192x192/*/gl: succeeds
* 1x1/*/gl-released: fails
* 4x4/*/gl-released: fails
* 192x192/*/gl-released: fails

The 1x1 or whatever refers to the pixel size of the test texture.
/gl is the sub-test that uploads the texture to GL and then downloads it
again. /gl-released is the same, but it also calls gdk_gl_texture_release(),
documented as:

Releases the GL resources held by a GdkGLTexture.

The texture contents are still available via the
gdk_texture_download() function, after this function has been called.

which seems to be implemented by downloading the GL texture into an
in-memory buffer which will be used as a source for subsequent downloads,
then discarding the actual GL resources. (I don't know why this makes a
difference to whether the 192x192 case succeeds.)

smcv

Bug#1010149: vulkan-loader: New upstream release 1.3.211 available

[Simon McVittie]

Source: vulkan-loader
Version: 1.3.204.1-2
Severity: wishlist

A new upstream release of vulkan-loader is available. This version is
on a branch named stabilized_release_2022_04 upstream, so perhaps it is
intended to be some sort of LTS branch?

This release adjusts the behaviour of environment variable overrides:

* $VK_ICD_FILENAMES is deprecated (but still works)
* $VK_DRIVER_FILES replaces $VK_ICD_FILENAMES
* VK_ADD_DRIVER_FILES is like $VK_DRIVER_FILES, but prepends to the search
  path instead of completely replacing it
* Similarly, $VK_ADD_LAYER_PATH prepends to the search path for
  explicit layers instead of completely replacing it like $VK_LAYER_PATH

smcv

Bug#1008890: libx11-6: XOpenDisplay segfaults if passed invalid display name

[Simon McVittie]

Package: libx11-6
Version: 2:1.7.4-1
Severity: normal
Tags: patch upstream
Forwarded: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/155

Since upgrading to 1.7.4, XOpenDisplay("this is invalid") segfaults.
This causes a FTBFS in GTK 3 (possibly also GTK 2 and GTK 4, I haven't
tried those yet), because GTK has a test-case asserting that GTK
initialization behaves correctly when XOpenDisplay() is made to fail,
which it does by specifying an invalid DISPLAY.

Please consider the patch that is available here:
https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/128

Thanks,
smcv

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'oldstable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libx11-6 depends on:
ii  libc62.33-7
ii  libx11-data  2:1.7.4-1
ii  libxcb1  1.14-3

libx11-6 recommends no packages.

libx11-6 suggests no packages.

-- no debconf information

Bug#607395: libx11-data: more compose key mappings

[Simon McVittie]

On Fri, 17 Dec 2010 at 16:24:58 -0500, Daniel Kahn Gillmor wrote:
>: "↑" U2191 # ARROW UP
>: "↑" U2191 # ARROW UP
>  : "↓" U2193 # ARROW DOWN
>  : "↓" U2193 # ARROW DOWN

These were added in 1.7.0.

>: "☠" U2620 # SKULL AND CROSSBONES
> : "☂" U2602 # UMBRELLA

These were not. I'd suggest sending merge requests (perhaps separately
rather than together) if you still want them.

smcv

Bug#1003219: vulkan-loader: FTBFS on i386: numbered symbols disappeared

[Simon McVittie]

Control: forwarded -1 https://github.com/KhronosGroup/Vulkan-Loader/issues/783
Control: tags -1 + patch

On Thu, 06 Jan 2022 at 14:07:40 +, Simon McVittie wrote:
> I think this is because changes to the build system resulted in some
> x86-specific code no longer being built on x86. Patches on the way when
> I have tested them.

Please see attached.

You might also want to make debian/libvulkan1.symbols.aarch64 a symlink to
libvulkan1.symbols.amd64, now that aarch64 is treated similarly to x86.

smcv
From: Simon McVittie 
Date: Thu, 6 Jan 2022 14:00:45 +
Subject: loader: Check for processor of compiler,
 not processor of build system

If we are cross-compiling, for example for aarch64 on x86, then the
compiler we care about here is the machine we are compiling *for*,
e.g. aarch64 (the "target" in CMake terminology, the "host system" in
Autotools/Meson) rather than the machine we are compiling *on*, e.g. x86
(the "host" in CMake terminology, the "build system" in Autotools/Meson).

Signed-off-by: Simon McVittie 
Bug: https://github.com/KhronosGroup/Vulkan-Loader/issues/783
Bug-Debian: https://bugs.debian.org/1003219
Forwarded: https://github.com/KhronosGroup/Vulkan-Loader/pull/784
---
 loader/CMakeLists.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/loader/CMakeLists.txt b/loader/CMakeLists.txt
index c33858d..e85fef6 100644
--- a/loader/CMakeLists.txt
+++ b/loader/CMakeLists.txt
@@ -224,12 +224,12 @@ else(UNIX AND NOT APPLE) # i.e.: Linux
 set(CMAKE_ASM_FLAGS "${CMAKE_C_FLAGS}")
 set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
 
-if (${CMAKE_HOST_SYSTEM_PROCESSOR} STREQUAL "aarch64")
+if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "aarch64")
 try_compile(ASSEMBLER_WORKS ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_SOURCE_DIR}/asm_test_aarch64.S)
 if(ASSEMBLER_WORKS)
 set(OPT_LOADER_SRCS ${OPT_LOADER_SRCS} unknown_ext_chain_gas_aarch64.S)
 endif()
-elseif(${CMAKE_HOST_SYSTEM_PROCESSOR} STREQUAL "x86_64" OR ${CMAKE_HOST_SYSTEM_PROCESSOR} STREQUAL "x86")
+elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86_64" OR ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86")
 check_include_file("cet.h" HAVE_CET_H)
 if(HAVE_CET_H)
 set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS HAVE_CET_H)
@@ -249,7 +249,7 @@ else(UNIX AND NOT APPLE) # i.e.: Linux
 add_custom_target(loader_asm_gen_files DEPENDS gen_defines.asm)
 else()
 if(USE_GAS)
-message(WARNING "Could not find working ${CMAKE_HOST_SYSTEM_PROCESSOR} GAS assembler\n${ASM_FAILURE_MSG}")
+message(WARNING "Could not find working ${CMAKE_SYSTEM_PROCESSOR} GAS assembler\n${ASM_FAILURE_MSG}")
 else()
 message(WARNING "Assembly sources have been disabled\n${ASM_FAILURE_MSG}")
 endif()
From: Simon McVittie 
Date: Thu, 6 Jan 2022 14:03:40 +
Subject: loader: Compile x86-specific code on x86 Linux

Unfortunately, the taxonomy used for CMAKE_SYSTEM_PROCESSOR is
OS-specific: on Windows, IA32 is identified as x86, but on Linux,
it can be identified as i386, i486, i586 or i686.

Signed-off-by: Simon McVittie 
Bug: https://github.com/KhronosGroup/Vulkan-Loader/issues/783
Bug-Debian: https://bugs.debian.org/1003219
Forwarded: https://github.com/KhronosGroup/Vulkan-Loader/pull/784
---
 loader/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/loader/CMakeLists.txt b/loader/CMakeLists.txt
index e85fef6..d7a876e 100644
--- a/loader/CMakeLists.txt
+++ b/loader/CMakeLists.txt
@@ -229,7 +229,7 @@ else(UNIX AND NOT APPLE) # i.e.: Linux
 if(ASSEMBLER_WORKS)
 set(OPT_LOADER_SRCS ${OPT_LOADER_SRCS} unknown_ext_chain_gas_aarch64.S)
 endif()
-elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86_64" OR ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86")
+elseif(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86_64" OR ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86" OR ${CMAKE_SYSTEM_PROCESSOR} MATCHES "^i.86$")
 check_include_file("cet.h" HAVE_CET_H)
 if(HAVE_CET_H)
 set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS HAVE_CET_H)

Bug#1003219: vulkan-loader: FTBFS on i386: numbered symbols disappeared

[Simon McVittie]

Source: vulkan-loader
Version: 1.2.198.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

https://buildd.debian.org/status/fetch.php?pkg=vulkan-loader&arch=i386&ver=1.2.198.1-1&stamp=1641378736&raw=0
> dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
> file: see diff output below
> dpkg-gensymbols: warning: debian/libvulkan1/DEBIAN/symbols doesn't match 
> completely debian/libvulkan1.symbols.i386
...
> +#MISSING: 1.2.198.1-1# vkPhysDevExtTermin177@Base 1.2.131.2
...
> +#MISSING: 1.2.198.1-1# vkdev_ext200@Base 1.2.131.2

(and many other numbered symbols)

I think this is because changes to the build system resulted in some
x86-specific code no longer being built on x86. Patches on the way when
I have tested them.

smcv

Bug#1003124: Segmentation fault when querying surface Segmentation fault querying physical device surface support for remote display

[Simon Richter]

Hi,

the missing example code is attached here.

   Simon


vkload-b0rked.tar.gz
Description: application/gzip

Bug#1002981: leaves callback registered after unload

[Simon Richter]

Package: libxext6
Version: 2:1.3.3-1.1
Severity: minor
Tags: upstream
X-Debbugs-Cc: s...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I have a very basic Vulkan app that uses libXext only indirectly through
the Vulkan X11 extension, so my program is not linked against libXext
directly (and can be linked only with --no-as-needed).

During shutdown, the program crashes with a segmentation fault, during

63  for (ext = dpy->ext_procs; ext; ext = ext->next) {
64  if (ext->close_display)
65  (*ext->close_display)(dpy, &ext->codes);

from src/ClDisplay.c in libX11. According to gdb,

*ext = {next = 0x558d0ee0, codes = {extension = 2, major_opcode = 128,
first_event = 0, first_error = 0}, create_GC = 0x0, copy_GC = 0x0,
  flush_GC = 0x0, free_GC = 0x0, create_Font = 0x0, free_Font = 0x0,
  close_display = 0x7fffed9c6ce0, error = 0x0, error_string = 0x0,
  name = 0x558d0ec0 "Generic Event Extension", error_values = 0x0,
  before_flush = 0x0, next_flush = 0x0}

The address for close_display refers to

0x7fffed9bd3d0  0x7fffed9c74ff  Yes (*) 
/lib/x86_64-linux-gnu/libXext.so.6

which has been unloaded at this point, together with the Vulkan driver.

It seems that libXext expects that it will remain loaded until
CloseDisplay() time, which is difficult to do here: I need to dismantle
Vulkan before closing the display connection, and libXext is only used
by an extension module that is loaded with dlopen(), so libXext will be
unloaded during Vulkan stack teardown.

I could reproduce this with both Intel and nVidia GPUs, using the source
attached. The problem goes away if I configure with

./configure LIBS='-Wl,--no-as-needed,-lXext'

to force link the application against libXext.

   Simon

- -- System Information:
Debian Release: 11.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages libxext6 depends on:
ii  libc6 2.31-13+deb11u2
ii  libx11-6  2:1.7.2-1

libxext6 recommends no packages.

libxext6 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFDBAEBCgAtFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAmHRPB4PHHNqckBkZWJp
YW4ub3JnAAoJEH69OHuwmQgRhVcH/395wMUzc6/q2MPTES2qNGiLqdbvy2prlgLy
MFRhvuhNGYFIxOhjaDPP9XKpjQ7FnZo54mVNq9FhSipbzCkTscj27s8bOVkcQ3Sz
wIi2NRkNuUOsrHdylxnqH9+tDOd4LhcpWONf3ch65a4siXrw6VjQ4+tdgayBdVgD
DzF0Ax2aXUyO/cAiUCoq4rbd1gaXkiAPSL6sprzklpf2H/Jqj475fr0cxAEJh/Mc
QvtV1hh26Cl1AIIkAM8EcD49fHCWXxIWscZDv5Ubw9ROCs1fUbLdMwczzeC4H8im
pFpf3TphQyB3LaZ6qSqDR3kQOv3jGcHhCPYFoc7U6dCpTmblz8Q=
=SA2i
-END PGP SIGNATURE-


vkload-0.0.20211229.tar.gz
Description: application/gzip

Re: Bug#1002690: clutter-1.0: unit tests fail on mips64el: segmentation fault in an llvmpipe thread with swrast_dri.so driver

[Simon McVittie]

On Mon, 27 Dec 2021 at 14:36:01 +, Simon McVittie wrote:
> I'm now trying to build 1.26.4+dfsg-2 on eller to see whether this is a
> regression in some other package - I suspect it was, since clutter-1.0
> has had no code changes since 2020, but it would be good to be more sure
> of this.

Yes, I think this is a regression in some other component, probably Mesa
or LLVM. 1.26.4+dfsg-2 passed unit tests on the buildds, but when rebuilt
on eller with current versions, it fails the same 5 tests as 1.26.4+dfsg-3
(although the failure is ignored by the d/rules from 1.26.4+dfsg-2).

smcv

Re: Bug#1002690: clutter-1.0: unit tests fail on mips64el: segmentation fault in an llvmpipe thread with swrast_dri.so driver

[Simon McVittie]

Control: user debian-m...@lists.debian.org
Control: usertags -1 + mips64el

On Mon, 27 Dec 2021 at 14:26:56 +, Simon McVittie wrote:
> The clutter-1.0 unit tests fail on mips64el with segmentation faults in
> actor-anchors, actor-layout, actor-offscreen-redirect, actor-pick and
> texture.
> 
> This (or at least a similar crash) is reproducible in a sid mips64el
> chroot on eller, and can be reproduced in the built tree with a command
> like:
> 
> dbus-run-session -- xvfb-run -a ./libtool --mode=execute gdb 
> ./tests/conform/texture

This might be related to https://bugs.debian.org/935884 and/or
https://bugs.debian.org/868745, which are other mips-specific crashes
involving llvmpipe.

I'm now trying to build 1.26.4+dfsg-2 on eller to see whether this is a
regression in some other package - I suspect it was, since clutter-1.0
has had no code changes since 2020, but it would be good to be more sure
of this.

smcv

Bug#1002690: clutter-1.0: unit tests fail on mips64el: segmentation fault in an llvmpipe thread with swrast_dri.so driver

[Simon McVittie]

Source: clutter-1.0
Version: 1.26.4+dfsg-3
Severity: important
Tags: ftbfs
X-Debbugs-Cc: debian-m...@lists.debian.org, m...@packages.debian.org

The clutter-1.0 unit tests fail on mips64el with segmentation faults in
actor-anchors, actor-layout, actor-offscreen-redirect, actor-pick and
texture.

This (or at least a similar crash) is reproducible in a sid mips64el
chroot on eller, and can be reproduced in the built tree with a command
like:

dbus-run-session -- xvfb-run -a ./libtool --mode=execute gdb 
./tests/conform/texture

By installing libgl1-mesa-dri-dbgsym on eller, I was able to get the
backtrace below. This might indicate that this is actually a Mesa bug,
I don't know.

Before version 1.26.4+dfsg-3, the result of clutter-1.0 unit tests was
ignored on mips*el. For now I'm going to resume ignoring the failed result:
I suspect that Mesa and Clutter have few or no users on mips*.

Clutter is essentially unmaintained upstream (see #996690) so if it needs
anything architecture-specific, that will have to come from architecture
porters, and is vanishingly unlikely to come from upstream.

smcv

Thread 10 (Thread 0xffe17f9e50 (LWP 25902) "texture:disk$0"):
#0  0x00fff6f813bc in __futex_abstimed_wait_common64 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#1  0x00fff6f8 in pthread_cond_wait@@GLIBC_2.3.2 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#2  0x00fff4c20e44 in cnd_wait (mtx=0xb30ba8, cond=0xb30bd0) at 
../include/c11/threads_posix.h:155
#3  util_queue_thread_func (input=) at ../src/util/u_queue.c:294
#4  0x00fff4c206e0 in impl_thrd_routine (p=) at 
../include/c11/threads_posix.h:87
#5  0x00fff6f6f24c in start_thread () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0

Thread 9 (Thread 0xffe1ffae50 (LWP 25901) "texture"):
#0  0x00fff6f813bc in __futex_abstimed_wait_common64 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#1  0x00fff6f8 in pthread_cond_wait@@GLIBC_2.3.2 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#2  0x00fff537102c in cnd_wait (mtx=0xb30250, cond=0xb30278) at 
../include/c11/threads_posix.h:155
#3  lp_cs_tpool_worker (data=0xb30250) at 
../src/gallium/drivers/llvmpipe/lp_cs_tpool.c:48
#4  0x00fff5370f80 in impl_thrd_routine (p=) at 
../include/c11/threads_posix.h:87
#5  0x00fff6f6f24c in start_thread () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0

Thread 8 (Thread 0xffe27fbe50 (LWP 25900) "texture"):
#0  0x00fff6f813bc in __futex_abstimed_wait_common64 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#1  0x00fff6f8 in pthread_cond_wait@@GLIBC_2.3.2 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#2  0x00fff537102c in cnd_wait (mtx=0xb30250, cond=0xb30278) at 
../include/c11/threads_posix.h:155
#3  lp_cs_tpool_worker (data=0xb30250) at 
../src/gallium/drivers/llvmpipe/lp_cs_tpool.c:48
#4  0x00fff5370f80 in impl_thrd_routine (p=) at 
../include/c11/threads_posix.h:87
#5  0x00fff6f6f24c in start_thread () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0

Thread 7 (Thread 0xffe2ffce50 (LWP 25899) "texture"):
#0  0x00fff6f813bc in __futex_abstimed_wait_common64 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#1  0x00fff6f8 in pthread_cond_wait@@GLIBC_2.3.2 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#2  0x00fff537102c in cnd_wait (mtx=0xb30250, cond=0xb30278) at 
../include/c11/threads_posix.h:155
#3  lp_cs_tpool_worker (data=0xb30250) at 
../src/gallium/drivers/llvmpipe/lp_cs_tpool.c:48
#4  0x00fff5370f80 in impl_thrd_routine (p=) at 
../include/c11/threads_posix.h:87
#5  0x00fff6f6f24c in start_thread () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0

Thread 6 (Thread 0xffe37fde50 (LWP 25898) "texture"):
#0  0x00fff6f813bc in __futex_abstimed_wait_common64 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#1  0x00fff6f8 in pthread_cond_wait@@GLIBC_2.3.2 () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#2  0x00fff537102c in cnd_wait (mtx=0xb30250, cond=0xb30278) at 
../include/c11/threads_posix.h:155
#3  lp_cs_tpool_worker (data=0xb30250) at 
../src/gallium/drivers/llvmpipe/lp_cs_tpool.c:48
#4  0x00fff5370f80 in impl_thrd_routine (p=) at 
../include/c11/threads_posix.h:87
#5  0x00fff6f6f24c in start_thread () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0

Thread 5 (Thread 0xffe3ffee50 (LWP 25897) "llvmpipe-3"):
#0  0x00fff6f79420 in pthread_barrier_wait () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0
#1  0x00fff5374944 in util_barrier_wait (barrier=0xb220a0) at 
../src/util/u_thread.h:301
#2  thread_function (init_data=0xb20e38) at 
../src/gallium/drivers/llvmpipe/lp_rast.c:887
#3  0x00fff5374350 in impl_thrd_routine (p=) at 
../include/c11/threads_posix.h:87
#4  0x00fff6f6f24c in start_thread () at 
/lib/mips64el-linux-gnuabi64/libpthread.so.0

Thread 4 (Thread 0xffe8f5ae50 (LWP 25896) "llvmpipe-2"):
#0  0x00fff6f79420

Bug#995835: mesa: moving to llvm-toolchain-13 made mesa unbuildable on armel, i386, mipsel, mips64el

[Simon McVittie]

Source: mesa
Version: 21.2.2-1
Severity: important
Justification: cannot migrate to testing

mesa recently moved to llvm-toolchain-13, which might have been too soon:

* it fails to build on i386 (#995786, fixed upstream), leading to multiarch
  skew that prevents upgrading mesa on amd64 with a foreign i386
  architecture;

* llvm-toolchain-13 fails to build on architectures that need more -latomic
  (#995827), so even with the i386 issue fixed, it won't be buildable on
  all release architectures and therefore can't migrate to testing

Does the new Mesa genuinely need LLVM 13, or would it maybe make sense
to stick to LLVM 12 until LLVM 13 is more ready?

Thanks,
smcv

Bug#995827: llvm-toolchain-13: FTBFS on armel, mipsel, mips64el: undefined references to __atomic_foo symbols

[Simon McVittie]

Source: llvm-toolchain-13
Version: 1:13.0.0-2
Severity: important
X-Debbugs-Cc: m...@packages.debian.org, debian-m...@lists.debian.org, 
debian-...@lists.debian.org

llvm-toolchain-13 has always failed to build on armel, mipsel, mips64el.
This makes mesa BD-Uninstallable on those release architectures since
its move to llvm-toolchain-13.

On armel:
> FAILED: bin/llvm-profdata 
> : && /<>/build-llvm/./bin/clang++ -fPIC 
> -Wno-unused-command-line-argument -Wno-unknown-warning-option -fPIC 
> -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time 
> -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
> -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
> -Wcovered-switch-default -Wno-class-memaccess -Wno-noexcept-type 
> -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override 
> -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color 
> -ffunction-sections -fdata-sections -O2 -DNDEBUG -g1 -marm -Wl,-z,relro
> -Wl,-rpath-link,/<>/build-llvm/tools/clang/stage2-bins/./lib  
> -Wl,-O3 -Wl,--gc-sections 
> tools/llvm-profdata/CMakeFiles/llvm-profdata.dir/llvm-profdata.cpp.o -o 
> bin/llvm-profdata  -Wl,-rpath,"\$ORIGIN/../lib"  lib/libLLVM-13.so.1  
> -lpthread && :
> /usr/bin/arm-linux-gnueabi-ld: 
> tools/llvm-profdata/CMakeFiles/llvm-profdata.dir/llvm-profdata.cpp.o: 
> undefined reference to symbol '__atomic_fetch_add_4@@LIBATOMIC_1.0'
> /usr/bin/arm-linux-gnueabi-ld: /usr/lib/arm-linux-gnueabi/libatomic.so.1: 
> error adding symbols: DSO missing from command line

On mips*el, the failure is in a different place, but might have the same
root cause (or not, clone this bug if necessary):
> FAILED: lib/clang/13.0.0/lib/linux/libclang_rt.scudo_standalone-mipsel.so 
> : && /usr/bin/g++-10 -fPIC -fPIC -Wno-unused-command-line-argument 
> -Wno-unknown-warning-option -fPIC -fno-semantic-interposition 
> -fno-shrink-wrap -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra 
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
> -Wno-missing-field-initializers -pedantic -Wno-long-long 
> -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess 
> -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type 
> -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment 
> -Wmisleading-indentation -fdiagnostics-color -ffunction-sections 
> -fdata-sections -Wall -std=c++14 -Wno-unused-parameter -O2 -DNDEBUG -g1  
> -fPIC -Wno-unused-command-line-argument -Wno-unknown-warning-option 
> -Wl,--build-id -Wl,-z,defs -Wl,-z,nodelete   -mips32r2 -mabi=32 
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wl,-z,defs,-z,now,-z,relro 
> -ffunction-sections -fdata-sections -Wl,--gc-sections -pthread 
> -Wl,-rpath-link,/<>/build-llvm/./lib -shared 
> -Wl,-soname,libclang_rt.scudo_standalone-mipsel.so -o 
> lib/clang/13.0.0/lib/linux/libclang_rt.scudo_standalone-mipsel.so 
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/checksum.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/common.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/crc32_hw.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/flags_parser.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/flags.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/fuchsia.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/linux.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/release.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/report.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/string_utils.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/wrappers_c.cpp.o
>  
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/wrappers_cpp.cpp.o
>   -Wl,-rpath,"\$ORIGIN/../lib" && :
> /usr/bin/ld: 
> projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-mipsel.dir/wrappers_c.cpp.o:
>  in function `scudo::atomic_u64::Type 
> scudo::atomic_load(scudo::atomic_u64 const volatile*, 
> scudo::memory_order)':
> /<>/compiler-rt/lib/scudo/standalone/atomic_helpers.h:66: 
> undefined reference to `__atomic_load_8'
> /usr/bin/ld: 
> /<>/compiler-rt/lib/scudo/standalone/atomic_helpers.h:66: 
> undefined reference to `__atomic_load_8'

smcv

Bug#995786: mesa: FTBFS on i386 with llvm 13: ‘class llvm::TargetOptions’ has no member named ‘StackAlignmentOverride’

[Simon McVittie]

Source: mesa
Version: 21.2.3-1
Severity: serious
Tags: ftbfs fixed-upstream patch
Justification: fails to build from source (but built successfully in the past)
Forwarded: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11940

https://buildd.debian.org/status/fetch.php?pkg=mesa&arch=i386&ver=21.2.3-1&stamp=1633351863&raw=0
> ../src/gallium/auxiliary/gallivm/lp_bld_misc.cpp: In function ‘LLVMBool 
> lp_build_create_jit_compiler_for_module(LLVMOpaqueExecutionEngine**, 
> lp_generated_code**, lp_cached_code*, LLVMModuleRef, 
> LLVMMCJITMemoryManagerRef, unsigned int, char**)’:
> ../src/gallium/auxiliary/gallivm/lp_bld_misc.cpp:354:12: error: ‘class 
> llvm::TargetOptions’ has no member named ‘StackAlignmentOverride’
>   354 |options.StackAlignmentOverride = 4;
>   |^~

This appears to be fixed in the upstream main branch by
.

smcv

Bug#952998: weston: change dependency to libegl1-mesa by libegl1?

[Simon McVittie]

Control: tags -1 + patch

On Mon, 02 Mar 2020 at 20:37:15 +0100, Patrice Duroux wrote:
> I think that libegl1-mesa is a transitional dummy package for some time. May 
> be
> it could be replaced by a non transitional one now which should be libegl1,
> isn't it?

weston is one of only a few packages still depending on the libegl1-mesa,
libgles2-mesa and libwayland-egl1-mesa transitional packages. I think the
attached patch is correct?

(Or if the dependencies generated by dpkg-shlibdeps are sufficient, use
those instead of hard-coding libraries.)

smcv
>From 3669640e77cb457df4665d6114d3963f62e46e6c Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 4 Oct 2021 19:45:38 +0100
Subject: [PATCH] Replace transitional package dependencies with their modern
 equivalents

Closes: #952998
---
 debian/control | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 1b774f11..54e26f63 100644
--- a/debian/control
+++ b/debian/control
@@ -56,9 +56,9 @@ Vcs-Browser: https://salsa.debian.org/xorg-team/wayland/weston
 Package: weston
 Architecture: linux-any
 Depends: adduser,
- libegl1-mesa (>= 8.0-2) | libegl1-x11,
- libgles2-mesa (>= 8.0-2) | libgles2,
- libwayland-egl1-mesa (>= 10.1.0-2) | libwayland-egl1,
+ libegl1,
+ libgles2,
+ libwayland-egl1,
  ${misc:Depends},
  ${shlibs:Depends}
 Breaks: libweston-8-dev
-- 
2.33.0

Bug#992857: wayland-protocols: please release 1.21 to unstable when ready

[Simon McVittie]

Package: wayland-protocols
Version: 1.20-1
Severity: wishlist
Control: fixed -1 1.21-1

I'm looking at what would be needed to get GTK 4 into testing/unstable,
and one of its dependencies is wayland-protocols 1.21. If 1.21 is ready
for wider testing and does not have an unacceptable regression risk,
please upload it to unstable.

Thanks,
smcv

Bug#992146: xwayland: after disabling CRTC with Xrandr, cannot enable it again

[Simon McVittie]

Package: xwayland
Version: 2:1.20.11-1
Severity: important
Forwarded: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1209
Tags: fixed-upstream
Control: found -1 2:1.20.13-1

When setting display modes with Xrandr, the recommended pattern seems
to be to disable the CRTC with XRRSetCrtcConfig(), change the screen
size with XRRSetScreenSize(), and then re-enable the CRTC with another
call to XRRSetCrtcConfig().

SDL 2.0.16 switched to using this pattern, but this caused a regression on
older versions of Xwayland like the one in Debian 11: after disabling the
CRTC, it does not seem to be possible to re-enable it, leaving Xwayland
in a broken state. Version 2:1.20.13-1 in experimental is also affected.
Please see the upstream bug for a minimal reproducer.

I've confirmed that this is fixed in the standalone Xwayland
(ITP: #981841), most likely as part of the Xrandr emulation feature, so
this will be fixed when the standalone Xwayland takes over the xwayland
binary package name. I tested with 21.1.1 built from
.

I think it would be good to get that version into the NEW queue, so that it
can be in bookworm soon after the release opens. It seems to be already
used in recent Ubuntu "short-term" releases.

Thanks,
smcv

Re: Bug#991283: unblock: mesa/20.3.5-1

[Simon McVittie]

On Wed, 21 Jul 2021 at 10:15:12 +0300, Timo Aaltonen wrote:
> On 19.7.2021 19.44, Simon McVittie wrote:
> > Should the mesa source package be unblocked for bullseye?
>
> ack

For clarity: does this mean "yes, I would like mesa_20.3.5-1 to reach
bullseye"?

> > There don't seem to be any RC bugs open. The Mesa maintainers would know
> > better than I do whether there have been non-RC regression reports.

Does your ack mean no regressions have been reported?

> >[ ] I reviewed all changes and I approve them

After looking at the filtered debdiff, do the Mesa maintainers approve
this unblock request?

Thanks,
smcv

Bug#991283: unblock: mesa/20.3.5-1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: moreinfo
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: m...@packages.debian.org, Timo Aaltonen 

Should the mesa source package be unblocked for bullseye? It was uploaded
to unstable several months ago.

Please note that I am not a Mesa maintainer, and I don't know whether
the uploader (cc'd) intended this to be for bullseye or not. I've tagged
this bug as moreinfo until Mesa maintainers confirm whether they want
this in bullseye.

If we're too late for 11.0, another option would be to convert this into
a mesa/20.3.5-0+deb11u1 upload targeting point release 11.1.

[ Reason ]
New upstream stable release with various bug fixes. The one I'm
particularly interested in is https://bugs.debian.org/983390 which causes
crashes and hangs when using third-party Vulkan layers like MangoHUD, but
there are lots of bugfixes listed in the upstream release notes.

[ Impact ]
Users of bullseye who run games etc. will experience various crashes,
hangs and rendering artifacts that could have been avoided.

[ Tests ]
I don't know, I'm not the maintainer. Presumably a lot of users of
unstable have been using this version to run games and other
graphically-intensive programs in the 116 days since it was uploaded.

There don't seem to be any RC bugs open. The Mesa maintainers would know
better than I do whether there have been non-RC regression reports.

[ Risks ]
It's a key package, involved in providing hardware support.

If the changes that upstream made in their development branch and then
backported into their stable branch are not all correct, then this version
could introduce new crashes, hangs and artifacts of a scope similar to the
ones it's fixing.

[ Checklist ]
  [ ] all changes are documented in the d/changelog
  - debian/patches/llvm-12-build-fix.diff is not explicitly documented
  [ ] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

The attached debdiff is lightly filtered to remove changes that appear to
be irrelevant (a copy of debian/patches/llvm-12-build-fix.diff in an
unintended location, and the JSON file that upstream use to track which
commits should/shouldn't be cherry-picked from their development branch).

Thanks,
smcv


mesa_20.3.5-1-filtered.diff.gz
Description: application/gzip

Bug#990229: libxi: Vcs-Git can't be cloned

[Simon McVittie]

Source: libxi
Version: 2:1.7.10-1
Severity: minor
Tags: patch
Forwarded: https://salsa.debian.org/xorg-team/lib/libxi/-/merge_requests/1

The Vcs-Git field in src:libxi has an extraneous /git/ left over from
Alioth's URL layout, preventing e.g. debcheckout from working as intended.

Fix available at
https://salsa.debian.org/xorg-team/lib/libxi/-/merge_requests/1 or as the
attached patch.

smcv
>From 7589595cd464fb39f90b3a0228a2fe76845e08bd Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Wed, 23 Jun 2021 14:32:34 +0100
Subject: [PATCH] d/control: Fix Vcs-Git URL

Signed-off-by: Simon McVittie 
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index ebaabc0..12b325d 100644
--- a/debian/control
+++ b/debian/control
@@ -22,7 +22,7 @@ Build-Depends:
  xsltproc,
  w3m,
 Standards-Version: 4.5.0
-Vcs-Git: https://salsa.debian.org/git/xorg-team/lib/libxi.git
+Vcs-Git: https://salsa.debian.org/xorg-team/lib/libxi.git
 Vcs-Browser: https://salsa.debian.org/xorg-team/lib/libxi
 Homepage: https://www.x.org/
 
-- 
2.32.0

Bug#899086: xserver-xorg-video-amdgpu: completely fails to detect AMD RX 550 (which uses the Polaris 12 chipset) unless firmware-amd-graphics package installed

[Simon Iremonger (debian)]

Alan and bug 899086,

Please try testing if this situation is improved or fixed in debian
testing (to soon become bullseye) images, similarly to as you did
before.

In fact the cdimage address you linked seems to be still exactly correct!.

I'd like to see bug-report either closed or updated for bullseye.
Given all the changes/massive improvements in amdgpu modesetting
I expect the situation to be considerably improved, at least!.

--Simon

Bug#890357: Graphical issues with an RX 480

[Simon Iremonger (debian)]

Can you confirm this issue is/is-not relevant any more on either of:-
* Debian Bullseye (testing)
* Debian Buster (stable) with the backported version of kernel
(5.10.0-0.bpo.7)  installed.

Amdgpu has improved a long way since the time this bug report was
created, and would be good to get the bug closed or issue forwarded
upstream if still relevant.

--simon

Bug#892982: system freeze after lock screen/switched off monitors/spontaneously

[Simon Iremonger (debian)]

I can confirm the buster-backports now offers kernel
5.10.0-0.bpo.7-amd64  ..

Please test this following notes on previous bug pointer.
Can the bug now be closed, if that works, or doesn't  -- I don't
think there is an X.org bug here.

--Simon

Bug#942318: xserver-xorg-video-amdgpu: VGA output is not detected in Radeon R7 (Carrizo) only the HDMI works. Motherboard MSI A68HM-E33 v2

[Simon Iremonger (debian)]

Julian and bug 942318,

buster-backports now provides kernel 5.10.0-0.bpo.7 via the
buster-backports linux-image-amd64 linux-headers-amd64 packages.

Please confirm if this solves the issue for you, and close the bug.

--Simon

Bug#970574: xserver-xorg-video-amdgpu: ABI changed (24.0 to 24.1) but not the dependencies

[Simon Iremonger (debian)]

GSR,

Buster now has xserver-xorg-core version  2:1.20.4-1+deb10u3
[in-between the versions you quoted] and bullseye now has a newer
newer  2:1.20.11-1 version.

Given the date of your bug-report, it looks like you had the old
2018 version of the xorg-xserver package even though the
buster package tas been updated twice since then to 2019 and
2020 versions.

See Changelog:-

https://metadata.ftp-master.debian.org/changelogs//main/x/xorg-server/xorg-server_1.20.4-1+deb10u3_changelog

In short, I think this bug report should now be closed unless there
is an apparent issue specifically in buster or bullseye now [??] ?

--Simon

Bug#974581: np longer able to set native resolution of Dell U3014

[Simon Iremonger (debian)]

Dear Janusz

linux-image-amd64 linux-headers-amd64 have now come out in version
5.10.0-0.bpo.7 in buster-backports.

Please confirm the issue is solved for you (or not) by using that
kernel as above, so the bug report can be prgressed or closed.

--Simon

Bug#900087: AMD RX 550 often locks up

[Simon Iremonger (debian)]

I would generally say this looks like problems more in kernel
and firmware land, than bugs in the xserver driver to me...

I would, generally note a lot of wider AMD instability/issues
(that Alan) talks about improved a lot in 5.8-ubuntu
and 5.10-debian (bullseye and buster-backports) kernels.
Even 5.4-ubuntu kernels still have problem with some newer
Ryzen systems.

In short, I'd recommend testing debian buster-backports
version of linux-image-amd64 linux-headers-amd64 and
report back on this bug.  In particular -- can this
bug now be closed, anyhow?  How could debian warn
users to update BIOS/firmware?

--Simon

Bug#942318: xserver-xorg-video-amdgpu: VGA output is not detected in Radeon R7 (Carrizo) only the HDMI works. Motherboard MSI A68HM-E33 v2

[Simon Iremonger (debian)]

I can say, I understood a limitation of amdgpu kernel driver
has been not supporting VGA/analogue outputs in some (or all?)
cases.  I understood this is part of the reason it is not the
default driver over radeon for some cards.


However, given many other other experiences and bugreports
with amdgpu modesetting problems, and looking at this bug,
I would recommend trying newer kernel in buster:-

enable backports  https://backports.debian.org/Instructions/

apt-get -t buster-backports install linux-image-amd64 linux-headers-amd64


This should get you a 5.10 series kernel which could well behave
better for you (let us know!).

--Simon


p.s.  the backports kernel is lagging behind a little,
hopefully 5.10.0-0.bpo.6 and 5.10.0-0.bpo.7 will come
out soon.

Bug#892982: system freeze after lock screen/switched off moniturs/spontaneously

[Simon Iremonger (debian)]

I have had first-hand experience of these Xorg crashes and lockups
in combination with either sleep or un-powering monitors.

I would 100% agree with Hermann that this is highly likely to be
improved with kernel update.

In short, I would go to *at least* the buster-backports kernel i.e.

https://backports.debian.org/Instructions/

apt-get -t buster-backports install linux-image-amd64 linux-headers-amd64


Over the recent 5.10 debian kernel provisions, I have seen incremental
improvement in this issue, to the point that now this seems to have
gone away.  I still experience complex MST monitor arrangement
reordering the displayport- virtual numbers (fixed with xrandr script)
but NO LONGER crashes needing reboot or restart-X11 like before...

In any case, please report back how 5.10 series kernel does/does-not
avoid the issue occuring for you.

--Simon




p.s. The buster-backports kernel [5.10.0-0.bpo.5-amd64] is lagging
 behind a little.  Hopefully .bpo.6 and .bpo.7 will come out
 soon.  I notice debian-deriv MXlinux have put out their own
 5.10.0-7mx kernel already.

Bug#974581: np longer able to set native resolution of Dell U3014

[Simon Iremonger (debian)]

Given some other experiences with amdgpu modesetting
problems, and looking at this bug, I would say:-

1) Please try updating all packages and reboot and
 try again, kernel should be now  4.19.0-16

2) Secondly, enable backports
 https://backports.debian.org/Instructions/
 and then:-

apt-get -t buster-backports install linux-image-amd64 linux-headers-amd64


This should get you a 5.10 series kernel.  My strong experience with
amdgpu has been that a whole lot of modesetting, sleep, etc etc.
issues are massively improved in 5.10 kernel series of late,
irrespective of the xserver-xorg version in use.

NB: At boot-time, in normal cases, GRUB menu should allow you
to 'select' which kernel you boot into i.e you should be
able to select between 5.10.0.bpo.?? and 4.19.0-16 kernel.

I note, the backports kernel is lagging behind a little,
hopefully 5.10.0-0.bpo.6 and 5.10.0-0.bpo.7 will come
out soon.


--Simon

Bug#987388: Crash of amdgpu on Debian 11 Bullseye

[Simon Iremonger (debian)]

Dear all on this bug,


I would like to briefly point out these crashes are showing kernel
errors, the kernel / amdgpu modesetting seems to be a very significant
part of the problem if I am not mistaken, this bug being against
the X-server component.

I would say, from the deb-10 / MX19.4 side of things with a GCN1.1
series amdgpu card,  updated 5.10 kernels (i.e. backports of deb11
bullseye kernels) have incrementally improved problems with crashing,
resuming from sleep, and so-on. With 5.10.0-7 I seem to be able to
reliably unpower and repower monitors and manage to keep X working
without crash and just xrandr fix up monitor layout.  Similar applies
to sleep/resume situation!.

I know the kernel amdgpu modesetting driver is a huge part of that work.

In short, I would highly recommend trying different kernels on your
deb11 testing machines and see how that affects your situation, and
in any case report which kernels are in use in the crash scenario.


Debian11 bullseye currently has 5.10.0-6 and I understand the 5.10.0-7
packages are to hit bullseye soon (through hard freeze).

5.10.0-7 is in sid and can be manually downloaded, or installed via
*temporary* adding sid to sources.list and then removing from sources
(or pinning to avoid all packages going to sid).

https://packages.debian.org/search?keywords=linux-image-5.10.0-7-amd64


Also, I would note, testing the older linux-image-4.19.0-16  may be
worthwhile, I get impression this (buster) kernel should nonetheless
'work' with bullseye and may assist with the 'it used to work' scenario.


Hope that helps,

--Simon

Bug#983390: mesa-vulkan-drivers: bad interactions between VkLayer_MESA_device_select and other layers

[Simon McVittie]

On Tue, 23 Feb 2021 at 12:20:08 +, Simon McVittie wrote:
> The device selection layer in Mesa 20.3.x >= 20.3.4 and 21.0.x >= 21.0.0~rc2
> has problematic interactions with other Vulkan layers, in particular
> MangoHUD. The bad interactions seem to be relatively complicated (dependent
> on other components), and particularly likely to be triggered when using
> Wine with DXVK.
...
> The attached patch from upstream appears to resolve this. I'm talking to
> an upstream Mesa maintainer about getting this into point releases, but
> it would also be great if you could make sure this gets into Debian 11.0.

A follow-up fix for this seems to be needed to avoid regressions:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9462

smcv

Bug#983390: mesa-vulkan-drivers: bad interactions between VkLayer_MESA_device_select and other layers

[Simon McVittie]

Package: mesa-vulkan-drivers
Version: 20.3.4-1
Severity: important
Tags: patch fixed-upstream
Forwarded: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3801
Control: found -1 21.0.0~rc2-1

The device selection layer in Mesa 20.3.x >= 20.3.4 and 21.0.x >= 21.0.0~rc2
has problematic interactions with other Vulkan layers, in particular
MangoHUD. The bad interactions seem to be relatively complicated (dependent
on other components), and particularly likely to be triggered when using
Wine with DXVK.

In Steam's Proton compatibility tool (Wine + DXVK) this seems to manifest
as a game not starting, rather than as a crash - although maybe this is
really a behind-the-scenes component like winedevice.exe crashing.

The attached patch from upstream appears to resolve this. I'm talking to
an upstream Mesa maintainer about getting this into point releases, but
it would also be great if you could make sure this gets into Debian 11.0.

I can reproduce this with 20.3.4-1, and it can be resolved by rebuilding
20.3.4 with this patch and overwriting both word-sizes' versions of
/usr/lib/*-linux-gnu/libVkLayer_MESA_device_select.so. Unfortunately, my
only reliable reproducer is far from minimal:

* Debian testing
* Install mesa-vulkan-drivers:amd64, mesa-vulkan-drivers:i386,
  mangohud:amd64, mangohud:i386 and Steam
* In Steam, install some games, and force them to use the Proton 5.13
  compatibility tool so that you get the Windows version instead of any
  native Linux version that might exist.
  I used Life Is Strange (32-bit) and Life Is Strange 2 (64-bit) which
  are available at no cost.
* Opt in to the beta branch of the "Steam Linux Runtime - soldier"
  container tool. This fixes a bug that hid this one by not always
  enabling MangoHUD successfully.
* Run Steam with MANGOHUD=1 in the environment
* Launch each game in turn
* Good result: The games launch, and have the MangoHUD fps display showing
* Bad result: The games don't start; `top` shows intermittent activity
  from winedevice.exe

I haven't yet verified that the Mesa in experimental also has this bug,
but from the git history, versions >= 21.0.0~rc2-1 are likely to have it,
and I've had reports of the same issue in 21.0.0~rc4 and ~rc5 in
non-Debian distros.

Thanks,
smcv
From: Bas Nieuwenhuizen 
Date: Mon, 11 Jan 2021 15:20:40 +0100
Subject: vulkan/device_select: Stop using device properties 2.

We have to choose between:
1) Stop handling two identical GPUs
2) Stop having crashes with other layers active.
3) Fix the Vulkan Loader.

Since nobody seems to want to spend enough effort to do 3 the
effective choice is between 1 and 2. This is choosing 2, as
two identical GPUs is pretty uncommon since crossfire doesn't
work on Linux anyway.

(And it would only work sporadically as the game needs to enable the
 extension)

CC: mesa-stable
Bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3801
Reviewed-by: Dave Airlie 
Part-of: 
Origin: upstream, 21.1, commit:38ce8d4d00c2b0e567b6dd36876cf171acb1dbc7
---
 .../device-select-layer/device_select_layer.c  | 30 +-
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/src/vulkan/device-select-layer/device_select_layer.c b/src/vulkan/device-select-layer/device_select_layer.c
index c381ac3..134a3bd 100644
--- a/src/vulkan/device-select-layer/device_select_layer.c
+++ b/src/vulkan/device-select-layer/device_select_layer.c
@@ -51,8 +51,8 @@ struct instance_info {
PFN_GetPhysicalDeviceProcAddr  GetPhysicalDeviceProcAddr;
PFN_vkEnumerateDeviceExtensionProperties EnumerateDeviceExtensionProperties;
PFN_vkGetPhysicalDeviceProperties GetPhysicalDeviceProperties;
-   PFN_vkGetPhysicalDeviceProperties2KHR GetPhysicalDeviceProperties2KHR;
-   bool has_props2, has_pci_bus;
+   PFN_vkGetPhysicalDeviceProperties2 GetPhysicalDeviceProperties2;
+   bool has_pci_bus, has_vulkan11;
bool has_wayland, has_xcb;
 };
 
@@ -150,8 +150,6 @@ static VkResult device_select_CreateInstance(const VkInstanceCreateInfo *pCreate
}
 
for (unsigned i = 0; i < pCreateInfo->enabledExtensionCount; i++) {
-  if (!strcmp(pCreateInfo->ppEnabledExtensionNames[i], VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_EXTENSION_NAME))
- info->has_props2 = true;
 #ifdef VK_USE_PLATFORM_WAYLAND_KHR
   if (!strcmp(pCreateInfo->ppEnabledExtensionNames[i], VK_KHR_WAYLAND_SURFACE_EXTENSION_NAME))
  info->has_wayland = true;
@@ -162,6 +160,14 @@ static VkResult device_select_CreateInstance(const VkInstanceCreateInfo *pCreate
 #endif
}
 
+   /*
+* The loader is currently not able to handle GetPhysicalDeviceProperties2KHR calls in
+* EnumeratePhysicalDevices when there are other layers present. To avoid mysterious crashes
+* for users just use only the vulkan version for now.
+*/
+   info->has_vulkan11 = pCreateInfo->pApplicationInfo &&
+pCreateInfo->pApplicationInfo->apiVersion >= VK_MAKE_VERSI

Bug#951988: libplacebo: FTBFS: (.text+0x8ee): undefined reference to `spvContextCreate'

[Simon McVittie]

On Mon, 18 Jan 2021 at 11:27:35 +, Simon McVittie wrote:
> On Mon, 18 Jan 2021 at 10:54:30 +0000, Simon McVittie wrote:
> > Unfortunately, unlike #980369, I was not able to find a combination of
> > libraries that I could add to spirv.pc to fix this bug.
> 
> I think the attached might do it? As before, I don't know this library,
> so please review carefully.
> 
> I have deliberately not used SPIRV-Tools-Shared here to avoid being
> affected by #980370.

https://salsa.debian.org/xorg-team/vulkan/glslang/-/merge_requests/4

(Updated patches attached, if you prefer the BTS.)

smcv
>From af942e4bc20bdb9fab9f187f497e7fe6c80cf12d Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 18 Jan 2021 11:24:30 +
Subject: [PATCH 1/2] Add missing dependencies to spirv.pc

Some code accessed via spirv.pc requires SPIRV-Tools and/or glslang.

Signed-off-by: Simon McVittie 
Closes: #951988
---
 debian/control|  3 +-
 debian/patches/series |  1 +
 ...endencies-on-SPIRV-Tools-and-glslang.patch | 38 +++
 3 files changed, 41 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/spirv.pc-Add-dependencies-on-SPIRV-Tools-and-glslang.patch

diff --git a/debian/control b/debian/control
index 594ac5a8..6eacf228 100644
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,8 @@ Description: OpenGL and OpenGL ES shader front end and validator -- tools
 
 Package: glslang-dev
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends},
+ spirv-tools,
 Suggests: glslang-tools
 Multi-Arch: same
 Description: OpenGL and OpenGL ES shader front end and validator -- development files
diff --git a/debian/patches/series b/debian/patches/series
index 7d0b1f9a..e66d681a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 glslang-default-resource-limits_staticlib.patch
 0001-pkg-config-compatibility.patch
 glslang.pc-Add-missing-libraries.patch
+spirv.pc-Add-dependencies-on-SPIRV-Tools-and-glslang.patch
diff --git a/debian/patches/spirv.pc-Add-dependencies-on-SPIRV-Tools-and-glslang.patch b/debian/patches/spirv.pc-Add-dependencies-on-SPIRV-Tools-and-glslang.patch
new file mode 100644
index ..160832d6
--- /dev/null
+++ b/debian/patches/spirv.pc-Add-dependencies-on-SPIRV-Tools-and-glslang.patch
@@ -0,0 +1,38 @@
+From: Simon McVittie 
+Date: Mon, 18 Jan 2021 11:22:34 +
+Subject: spirv.pc: Add dependencies on SPIRV-Tools and glslang
+
+Otherwise, a simple program like this will fail to link:
+
+#include 
+int main (void)
+{
+  std::string s;
+  glslang::GetSpirvVersion(s);
+  return 0;
+}
+
+when compiled with the obvious parameters from pkg-config:
+
+g++ -ospirv spirv.cpp $(pkg-config --cflags --libs spirv)
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951988
+Signed-off-by: Simon McVittie 
+---
+ SPIRV/spirv.pc.cmake.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/SPIRV/spirv.pc.cmake.in b/SPIRV/spirv.pc.cmake.in
+index dfcad94..d47d427 100644
+--- a/SPIRV/spirv.pc.cmake.in
 b/SPIRV/spirv.pc.cmake.in
+@@ -5,7 +5,7 @@
+ 
+ Name: @SPIRV_NAME@
+ Description: SPIR-V is a binary intermediate language for representing graphical-shader stages and compute kernels for multiple Khronos APIs, including OpenCL, OpenGL, and Vulkan
+-Requires:
++Requires: SPIRV-Tools, glslang
+ Version: @SPIRV_VERSION@
+ Libs: -L${libdir} -lSPIRV
+ Cflags: -I${includedir}
+\ No newline at end of file
-- 
2.30.1

>From ff5bf4e4301419d16f68a5ca673dc1c88c3f3c1f Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 18 Jan 2021 10:16:45 +
Subject: [PATCH 2/2] d/tests/glslang-dev: Add a test for spirv.pc

Signed-off-by: Simon McVittie 
Reproduces: #951988
---
 .../glslang.pc-Add-missing-libraries.patch   |  2 +-
 debian/tests/glslang-dev | 16 
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/debian/patches/glslang.pc-Add-missing-libraries.patch b/debian/patches/glslang.pc-Add-missing-libraries.patch
index f8029af4..b3fa7b4f 100644
--- a/debian/patches/glslang.pc-Add-missing-libraries.patch
+++ b/debian/patches/glslang.pc-Add-missing-libraries.patch
@@ -11,7 +11,7 @@ Signed-off-by: Simon McVittie 
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/glslang/glslang.pc.cmake.in b/glslang/glslang.pc.cmake.in
-index 921497e..fd92606 100644
+index 921497e..8c49e0c 100644
 --- a/glslang/glslang.pc.cmake.in
 +++ b/glslang/glslang.pc.cmake.in
 @@ -7,5 +7,5 @@
diff --git a/debian/tests/glslang-dev b/debian/tests/glslang-dev
index 3f6af04a..bf103ca0 100755
--- a/debian/tests/glslang-dev
+++ b/debian/tests/glslang-dev
@@ -35,6 +35,17 @@ int main (void)
 }
 EOF
 
+cat > spirv.cpp <<'EOF'
+#include 
+
+int main (void)
+{
+  std::string s;
+  glslang::GetSpirvV

Bug#980370: spirv-tools: shared library should be packaged like a shared library

[Simon McVittie]

On Thu, 11 Feb 2021 at 14:33:37 +0200, Timo Aaltonen wrote:
> Uh, the shared lib was supposed to be disabled in 2020.3-1, but looks like
> the build option broke since. But 2020.6 now has this merged:
> 
> https://github.com/KhronosGroup/SPIRV-Tools/pull/3910
> 
> which should allow building a proper shared lib, but still without
> versioning. I wonder what to do for bullseye, maybe force static like it's
> supposed to be and be happy for now?

I think the first thing to do is to disable (or just not install!) the
shared library. That doesn't need a trip through NEW and should be
straightforward; it would be good if that change can be included in
bullseye.

https://codesearch.debian.net/search?q=SPIRV-Tools-shared&literal=1
seems to indicate that nothing depends on SPIRV-Tools-shared yet.
All the search hits are in packages that bundle a copy of SPIRV-Tools,
except for vkd3d which only links to the shared library if you enable an
option that Debian apparently doesn't, and mojoshader, which is more
complicated.

mojoshader doesn't *seem* to have a runtime dependency on
libSPIRV-Tools-shared, but it checks for the -shared pkg-config data,
so it might accidentally FTBFS after disabling the shared library -
but it has a popcon score of 3 and nothing depends on it, so I don't
think you should necessarily feel guilty about breaking it?

The long-term solution is to teach upstream how SONAMEs work (I already
tried on ,
but it seems to be a slow process); and then when that has happened,
package the library according to Policy (libspirv-tools-dev and
libspirv-tools0, or similar) and go through NEW.

smcv

Bug#951988: libplacebo: FTBFS: (.text+0x8ee): undefined reference to `spvContextCreate'

[Simon McVittie]

tags -1 + patch

On Mon, 18 Jan 2021 at 10:54:30 +, Simon McVittie wrote:
> Unfortunately, unlike #980369, I was not able to find a combination of
> libraries that I could add to spirv.pc to fix this bug.

I think the attached might do it? As before, I don't know this library,
so please review carefully.

I have deliberately not used SPIRV-Tools-Shared here to avoid being
affected by #980370.

smcv
>From e0724824147f624563de94d2d1b497f1c36aff5e Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 18 Jan 2021 11:24:30 +
Subject: [PATCH 7/7] Add missing dependencies to spirv.pc

Some code accessed via spirv.pc requires SPIRV-Tools and/or glslang.

Signed-off-by: Simon McVittie 
Closes: #951988
---
 debian/control|  3 +-
 debian/patches/series |  1 +
 ...endencies-on-SPIRV-Tools-and-glslang.patch | 38 +++
 3 files changed, 41 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/spirv.pc-Add-dependencies-on-SPIRV-Tools-and-glslang.patch

diff --git a/debian/control b/debian/control
index 594ac5a8..6eacf228 100644
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,8 @@ Description: OpenGL and OpenGL ES shader front end and validator -- tools
 
 Package: glslang-dev
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends},
+ spirv-tools,
 Suggests: glslang-tools
 Multi-Arch: same
 Description: OpenGL and OpenGL ES shader front end and validator -- development files
diff --git a/debian/patches/series b/debian/patches/series
index 7d0b1f9a..e66d681a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 glslang-default-resource-limits_staticlib.patch
 0001-pkg-config-compatibility.patch
 glslang.pc-Add-missing-libraries.patch
+spirv.pc-Add-dependencies-on-SPIRV-Tools-and-glslang.patch
diff --git a/debian/patches/spirv.pc-Add-dependencies-on-SPIRV-Tools-and-glslang.patch b/debian/patches/spirv.pc-Add-dependencies-on-SPIRV-Tools-and-glslang.patch
new file mode 100644
index ..f88f3a32
--- /dev/null
+++ b/debian/patches/spirv.pc-Add-dependencies-on-SPIRV-Tools-and-glslang.patch
@@ -0,0 +1,38 @@
+From: Simon McVittie 
+Date: Mon, 18 Jan 2021 11:22:34 +
+Subject: spirv.pc: Add dependencies on SPIRV-Tools and glslang
+
+Otherwise, a simple program like this will fail to link:
+
+#undef NDEBUG
+#include 
+
+#include 
+
+int main (void)
+{
+  std::string s;
+  glslang::GetSpirvVersion(s);
+  return 0;
+}
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951988
+Signed-off-by: Simon McVittie 
+---
+ SPIRV/spirv.pc.cmake.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/SPIRV/spirv.pc.cmake.in b/SPIRV/spirv.pc.cmake.in
+index dfcad94..d47d427 100644
+--- a/SPIRV/spirv.pc.cmake.in
 b/SPIRV/spirv.pc.cmake.in
+@@ -5,7 +5,7 @@
+ 
+ Name: @SPIRV_NAME@
+ Description: SPIR-V is a binary intermediate language for representing graphical-shader stages and compute kernels for multiple Khronos APIs, including OpenCL, OpenGL, and Vulkan
+-Requires:
++Requires: SPIRV-Tools, glslang
+ Version: @SPIRV_VERSION@
+ Libs: -L${libdir} -lSPIRV
+ Cflags: -I${includedir}
+\ No newline at end of file
-- 
2.30.0

Bug#980370: spirv-tools: shared library should be packaged like a shared library

[Simon McVittie]

Package: spirv-tools
Version: 2020.6-1
Severity: important

If a package is linked to the libSPIRV-Tools-shared.so shared library,
then it will get a runtime dependency on libSPIRV-Tools-shared.so.
However, libSPIRV-Tools-shared.so is currently bundled into the
spirv-tools binary package rather than being packaged in accordance with
Policy §8.

libSPIRV-Tools-shared.so should be in a package named
libspirv-tools-shared. There should probably also be a libspirv-tools-dev
package containing the static libraries and pkg-config metadata. Ideally
both of those packages would be Multi-Arch: same.

Unfortunately, this will require a trip through the NEW queue.

libspirv-tools-shared needs to provide either a shlibs or symbols file,
as per Policy §8.6, so that ${shlibs:Depends} works correctly.
Unfortunately the form of the SONAME used by upstream (with no version
number) doesn't seem to be compatible with shlibs files, so I think there
is no choice but to use a symbols file. This is going to be annoying
because symbols files for C++ ABIs are not easy, but you could consider
having a libspirv-tools-shared.symbols.in file like this:

libSPIRV-Tools-shared.so libspirv-tools-shared #MINVER#
* Build-Depends-Package: libspirv-tools-dev
 (regex)".*" @DEB_VERSION_UPSTREAM@

and generating libspirv-tools-shared.symbols by substituting
@DEB_VERSION_UPSTREAM@, to get the equivalent of a legacy shlibs file?

If it cannot be packaged as a correct shared library for technical reasons
then I would recommend going back to it being static-only, which seems like
a lesser evil than having a non-Policy-compliant shared library.

smcv

Bug#951988: libplacebo: FTBFS: (.text+0x8ee): undefined reference to `spvContextCreate'

[Simon McVittie]

On Sun, 23 Feb 2020 at 11:17:31 +0100, Sebastian Ramacher wrote:
> On 2020-02-23 08:27:30, Lucas Nussbaum wrote:
> > Source: libplacebo
...
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> > 
> > Relevant part (hopefully):
> > > /usr/bin/ld: 
> > > /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libSPIRV.a(SpvTools.cpp.o):
> > >  in function `glslang::SpirvToolsValidate(glslang::TIntermediate const&, 
> > > std::vector >&, 
> > > spv::SpvBuildLogger*, bool)':
> > > (.text+0x8ee): undefined reference to `spvContextCreate'
> > > /usr/bin/ld: (.text+0x918): undefined reference to 
> > > `spvValidatorOptionsCreate'
> > > /usr/bin/ld: (.text+0x92b): undefined reference to 
> > > `spvValidatorOptionsSetRelaxBlockLayout'
> > > /usr/bin/ld: (.text+0x936): undefined reference to 
> > > `spvValidatorOptionsSetBeforeHlslLegalization'
> > > /usr/bin/ld: (.text+0x94b): undefined reference to 
> > > `spvValidateWithOptions'
> > > /usr/bin/ld: (.text+0xafc): undefined reference to 
> > > `spvValidatorOptionsDestroy'
> > > /usr/bin/ld: (.text+0xb06): undefined reference to `spvDiagnosticDestroy'
> > > /usr/bin/ld: (.text+0xb0e): undefined reference to `spvContextDestroy'
> > > collect2: error: ld returned 1 exit status
> 
> This static library is from glslang-dev. spirv.pc fails to mention the
> libraries from spirv-tools in its Libs, but would require as it can be
> seen from this build failure. Hence I'm reassigning this bug to
> glslang-dev.

Here is a reproducer:

cat > use-spirv.cpp <<'EOF'
#undef NDEBUG
#include 

#include 

int main (void)
{
  std::string s;
  glslang::GetSpirvVersion(s);
  return 0;
}
EOF
c++ -std=c++11 -o use-spirv use-spirv.cpp $("$PKG_CONFIG" --cflags --libs spirv)

I attach a patch that extends the autopkgtest to do this, which requires
the patches from #980369. As with the previous autopkgtests, it can be
run with sadt(1) from devscripts, or with autopkgtest(1), and I would
suggest doing so before uploads (at least for new upstream releases).

Unfortunately, unlike #980369, I was not able to find a combination of
libraries that I could add to spirv.pc to fix this bug.

smcv

Bug#980369: glslang: autopkgtest regression: undefined reference to `ShConstructUniformMap'

[Simon McVittie]

Source: glslang
Version: 11.1.0-1
Severity: serious
Justification: release team policy
X-Debbugs-Cc: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression
Tags: patch

Thanks for adding an autopkgtest (#940488) and pkg-config metadata
(#940487). However, since version 11.1.0-1, glslang fails the autopkgtest,
for example in
https://ci.debian.net/data/autopkgtest/testing/amd64/g/glslang/9766376/log.gz:

autopkgtest [13:18:41]: test glslang-dev: [---
+ mktemp -d
+ tempdir=/tmp/tmp.UEoTRS3LSr
+ cd /tmp/tmp.UEoTRS3LSr
+ cat
+ c++ -std=c++11 -o trivial trivial.cpp -lglslang -lHLSL -lOGLCompiler 
-lOSDependent -lSPIRV -lpthread
/usr/bin/ld: /tmp/ccZLSVyX.o: in function `main':
trivial.cpp:(.text+0x9): undefined reference to `ShConstructUniformMap'
/usr/bin/ld: trivial.cpp:(.text+0x19): undefined reference to `ShDestruct'
collect2: error: ld returned 1 exit status
autopkgtest [13:18:42]: test glslang-dev: ---]

This indicates that the compile-time interface has changed: it is now
necessary for client code to link to -lMachineIndependent and
-lGenericCodeGen in addition to the libraries that were previously
required. This will presumably mean that some packages dependent on
glslang will now FTBFS.

Linking with the new glslang.pc seems to have the same bug: glslang.pc
needs updating for the new compile-time interface.

I attach an attempt to fix this, together with improvements to the
autopkgtest.

(I should warn you that I don't really know how this library works,
so I'm guessing at what the intended compile-time interface is; please
review accordingly.)

smcv
>From fa64521cbd0bab95e1b5b4d935988e9e3c6be494 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 18 Jan 2021 10:41:45 +
Subject: [PATCH 1/5] d/tests: Recode into UTF-8

Signed-off-by: Simon McVittie 
---
 debian/tests/glslang-dev   | 2 +-
 debian/tests/glslang-tools | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/tests/glslang-dev b/debian/tests/glslang-dev
index 84463a9b..9cb42d7e 100755
--- a/debian/tests/glslang-dev
+++ b/debian/tests/glslang-dev
@@ -1,5 +1,5 @@
 #!/bin/sh
-# Copyright © 2019 Collabora Ltd.
+# Copyright © 2019 Collabora Ltd.
 # SPDX-License-Identifier: MIT
 # (see debian/copyright)
 
diff --git a/debian/tests/glslang-tools b/debian/tests/glslang-tools
index 1511c07a..2445c3ca 100755
--- a/debian/tests/glslang-tools
+++ b/debian/tests/glslang-tools
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-# Copyright © 2019 Collabora Ltd.
+# Copyright © 2019 Collabora Ltd.
 # SPDX-License-Identifier: MIT
 # (see debian/copyright)
 
-- 
2.30.0

>From cd19f2103a94377a7acefb57420f212c5280457a Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 18 Jan 2021 09:32:34 +
Subject: [PATCH 2/5] d/tests/glslang-dev: Use proposed interface for
 cross-testing

This allows testing glslang-dev:i386 on an amd64 system (see
<https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/69>).

Signed-off-by: Simon McVittie 
---
 debian/tests/glslang-dev | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/debian/tests/glslang-dev b/debian/tests/glslang-dev
index 9cb42d7e..6bf09482 100755
--- a/debian/tests/glslang-dev
+++ b/debian/tests/glslang-dev
@@ -1,5 +1,5 @@
 #!/bin/sh
-# Copyright © 2019 Collabora Ltd.
+# Copyright © 2019-2021 Collabora Ltd.
 # SPDX-License-Identifier: MIT
 # (see debian/copyright)
 
@@ -9,6 +9,14 @@ set -e
 set -u
 set -x
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+CXX="${CROSS_COMPILE}g++"
+PKG_CONFIG="${CROSS_COMPILE}pkg-config"
+
 tempdir="$(mktemp -d)"
 cd "$tempdir"
 
@@ -27,9 +35,9 @@ int main (void)
 }
 EOF
 
-# This is hard-coded because there's no pkg-config, but that matches
-# what renderdoc does...
-c++ -std=c++11 -o trivial trivial.cpp -lglslang -lHLSL -lOGLCompiler -lOSDependent -lSPIRV -lpthread
+# This is hard-coded because there used to be no pkg-config, but matches
+# what renderdoc does.
+"${CXX}" -std=c++11 -o trivial trivial.cpp -lglslang -lHLSL -lOGLCompiler -lOSDependent -lSPIRV -lpthread
 test -x trivial
 ./trivial
 
-- 
2.30.0

>From 65ca014d535af865479a64577f8b092fa60310d6 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 18 Jan 2021 09:41:58 +
Subject: [PATCH 3/5] d/tests/glslang-dev: Add missing libraries to linker line

Signed-off-by: Simon McVittie 
---
 debian/tests/glslang-dev | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/tests/glslang-dev b/debian/tests/glslang-dev
index 6bf09482..1804c26a 100755
--- a/debian/tests/glslang-dev
+++ b/debian/tests/glslang-dev
@@ -37,7 +37,7 @@ EOF
 
 # This is hard-coded because there used to be no pkg-config, but matches
 # what renderdoc does.
-"${CXX}" -std=c++11 -o trivial trivial.cpp -lglslang -l