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=armel=23.3.3-1=1705055313=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

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.m4
+ltmain.sh
+lt~obs

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]
+*.obj
+*.patch
+*.so
+*.

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 

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(>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(>last_fence, NULL);
+
/* for synchronizing rasterization threads */
if (rast->num_threads > 0) {
   util_barrier_destroy( >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 *scene );
 
-
+void lp_rast_fence(stru

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 136f8d6..d

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 5410658a402f6825a93fcf82513e

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/control

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=i386=1.2.198.1-1=1641378736=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

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  

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=i386=21.2.3-1=1633351863=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#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 >= 

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::GetSpirvVersion(s);
+  r

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=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 -lHLSL -lOGLCompiler -lOSDepende

Bug#975895: libxkbregistry-dev: missing dependency on libxml2-dev

[Simon McVittie]

Package: libxkbregistry-dev
Version: 1.0.3-1
Severity: important
Tags: patch

If you have libxkbregistry-dev installed, but not libxml2-dev:

$ pkg-config --cflags --libs xkbregistry
Package libxml-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libxml-2.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libxml-2.0', required by 'xkbregistry', not found

See attached patch 0001 for a trivial solution.

This class of bug is easy to catch with an autopkgtest that links
a trivial executable to the library (and in fact that's how I found
it, by running that type of test on a library that recently gained a
libxkbregistry dependency). Please consider adding a test for each
library in xkbcommon, as in the attached patch 0002.

Thanks,
smcv

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-debug'), (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.9.0-3-amd64 (SMP w/8 CPU threads)
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 libxkbregistry-dev depends on:
ii  libxkbcommon-dev  1.0.3-1
ii  libxkbregistry0   1.0.3-1

libxkbregistry-dev recommends no packages.

libxkbregistry-dev suggests no packages.

-- no debconf information
>From 7c3b7f1b4aa741af5145c991dc7f6b170e25a65b Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 26 Nov 2020 10:53:46 +
Subject: [PATCH 1/2] libxkbregistry-dev: Depend on libxml2-dev

Otherwise, using pkg-config to check for the library or a library that
depends on it can fail:

$ pkg-config --cflags --libs xkbregistry
Package libxml-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libxml-2.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libxml-2.0', required by 'xkbregistry', not found

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

diff --git a/debian/control b/debian/control
index 3bc8bf0..27a6f54 100644
--- a/debian/control
+++ b/debian/control
@@ -183,6 +183,7 @@ Pre-Depends: ${misc:Pre-Depends}
 Depends:
  libxkbcommon-dev (= ${binary:Version}),
  libxkbregistry0 (= ${binary:Version}),
+ libxml2-dev,
  ${shlibs:Depends},
  ${misc:Depends}
 Description: library to query available RMLVO - development files
-- 
2.29.2

>From 916af9f7828fba99b54cada57f2c600919f80881 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 26 Nov 2020 10:50:38 +
Subject: [PATCH 2/2] Add a superficial compile/link/run test for each -dev
 package

This can be used to check that each -dev package is self-contained.

Signed-off-by: Simon McVittie 
---
 debian/tests/control  | 11 +
 debian/tests/libxkbcommon-dev | 36 +
 debian/tests/libxkbcommon-x11-dev | 37 ++
 debian/tests/libxkbregistry-dev   | 38 +++
 4 files changed, 122 insertions(+)
 create mode 100644 debian/tests/control
 create mode 100644 debian/tests/libxkbcommon-dev
 create mode 100644 debian/tests/libxkbcommon-x11-dev
 create mode 100644 debian/tests/libxkbregistry-dev

diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..fb0588f
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,11 @@
+Tests: libxkbcommon-dev
+Restrictions: allow-stderr, superficial
+Depends: build-essential, pkg-config, libxkbcommon-dev
+
+Tests: libxkbcommon-x11-dev
+Restrictions: allow-stderr, superficial
+Depends: build-essential, pkg-config, libxkbcommon-x11-dev
+
+Tests: libxkbregistry-dev
+Restrictions: allow-stderr, superficial
+Depends: build-essential, pkg-config, libxkbregistry-dev
diff --git a/debian/tests/libxkbcommon-dev b/debian/tests/libxkbcommon-dev
new file mode 100644
index 000..14fc4a5
--- /dev/null
+++ b/debian/tests/libxkbcommon-dev
@@ -0,0 +1,36 @@
+#!/bin/sh
+# Copyright 2020 Collabora Ltd.
+# Copyright 2020 Simon McVittie
+# SPDX-License-Identifier: MIT
+
+set -eux
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+CC="${CROSS_COMPILE}gcc"
+PKG_CONFIG="${CROSS_COMPILE}pkg-config"
+else
+CROSS_COMPILE=
+CC=cc
+PKG_CONFIG=pkg-config
+fi
+
+cd "$AUTOPKGTEST_TMP"
+
+cat > trivial.c <
+
+#include 
+
+int main (void)
+{
+assert(xkb_keysym_from_name("A", XKB_KEYSYM_NO_FLAGS) == XKB_KEY_A);
+return 0;
+}
+EOF
+
+# Deliberately word-splitting pkg-config's output:
+# shellcheck disable=SC2046
+"${CC}" -otrivial trivial.c $("${PKG_CONFIG}&

Bug#969614: Bug#966535: transition: pipewire 0.3

[Simon McVittie]

On Wed, 09 Sep 2020 at 13:17:05 +0100, Simon McVittie wrote:
>   + weston
> * Either upload experimental version to unstable, or disable
>   pipewire integration in unstable (as was already done in experimental)
>   + krfb
> * Maintainers say they will apply
>   https://salsa.debian.org/qt-kde-team/kde/krfb/-/merge_requests/2 in
>   unstable when the transition goes ahead, but do not want to upload it
>   to experimental right now
> * Contingency plan: disable its pipewire support instead
>   + xdg-desktop-portal-kde
> * The KDE team tell me the version in experimental is not yet suitable
>   for unstable
> * Maintainers say they will apply
>   
> https://salsa.debian.org/qt-kde-team/kde/xdg-desktop-portal-kde/-/merge_requests/5
>   in unstable when the transition goes ahead
> * Contingency plan: disable its pipewire support instead

pipewire 0.3 is in unstable and built on all release architectures, so
please upload weston, krfb and xdg-desktop-portal-kde to unstable, either
with a build-dependency on libpipewire-0.3-dev or with their pipewire
support disabled.

(For xdg-desktop-portal-kde: a version of xdg-desktop-portal with
Pipewire support enabled is also already available in unstable on all
release architectures.)

I'm looking into also re-enabling Pipewire support in GNOME 3.36. I couldn't
get it to work in a test VM, but that might just be because the VM is using
QXL graphics, which until recently didn't work with GNOME screencasting
due to driver limitations (3.37.x has a workaround). If it works on real
hardware, I'll upload. If not, we'll have to wait for 3.37.x (which I have
already confirmed does work).

Thanks,
smcv

Bug#969614: weston: please transition to pipewire 0.3

[Simon McVittie]

Package: weston
Version: 8.0.0-1
Severity: normal
Control: block #966535 by -1

pipewire 0.3 has now hit experimental. As discussed in #966535 and
on #debian-kde, the first step for transition #966535 is to make sure
the few packages that currently B-D on pipewire 0.2 can be recompiled
with 0.3.

In the case of weston, my understanding is that the next upstream version
will have pipewire 0.3 support, but the version in testing/unstable does
not. There are two options, please choose one:

1. Upload weston 8.0.0-2 to unstable soon, disabling pipewire support.
   After this has been done, #966535 will no longer be blocked by this
   bug (which can be retitled to "enable pipewire 0.3 support" or similar,
   and downgraded to wishlist).

2. Backport Pipewire 0.3 support from
   https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/456
   (which was recently merged), switch the B-D to libpipewire-0.3-dev,
   and upload to experimental. When the transition goes ahead, either
   re-upload to unstable, or give the go-ahead for someone to do a 0-day
   NMU to unstable.

Thanks,
smcv

Bug#966535: transition: pipewire 0.3

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: moreinfo
Control: block -1 by 954022
Control: affects -1 + src:pipewire
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pipew...@packages.debian.org, k...@packages.debian.org, 
wes...@packages.debian.org, mut...@packages.debian.org, 
gnome-remote-desk...@packages.debian.org

pipewire will need a transition from 0.2.x to 0.3.x at some point,
allowing remote desktop support in GNOME to be re-enabled. This is an
API and ABI break, although the API breaks appear to be small enough
that some packages support both versions with some #if conditions.

A prerequisite for all this is to get pipewire 0.3 through NEW and into
experimental (#954022). I've marked the transition bug as moreinfo to
indicate that it cannot go ahead right now.

Affected packages:

- mutter currently has remote desktop support disabled, but can
  re-enable it after Pipewire 0.3 becomes available

- xdg-desktop-portal will need new upstream release 1.7.x, or the Pipewire
  features being disabled (1.7.x is already in experimental, with its
  Pipewire support disabled for now because it needs Pipewire 0.3.x)

- gnome-remote-desktop will need new upstream release 0.1.8, and as far
  as I understand it, is non-functional without Pipewire support that
  matches what mutter uses

- krfb and xdg-desktop-portal-kde appear to support both APIs upstream,
  but will need some simple packaging changes to switch the dependency

- weston currently only supports Pipewire 0.2, and will need either
  https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/456,
  or that feature being disabled if it isn't considered important

Ben file:

title = "pipewire";
is_affected = .depends ~ "libpipewire-0.2-1" | .depends ~ "libpipewire-0.3-0";
is_good = .depends ~ "libpipewire-0.3-0";
is_bad = .depends ~ "libpipewire-0.2-1";

Bug#956510: spirv-tools: change to shared libraries breaks dpkg-shlibdeps during the build of reverse dependencies

[Simon McVittie]

Control: forwarded -1 https://github.com/KhronosGroup/SPIRV-Tools/issues/3214

On Fri, 15 May 2020 at 10:16:33 +0200, Sebastian Ramacher wrote:
> On 2020-05-14 17:18:38 +0100, Simon McVittie wrote:
> > Are these libraries intended to be a public API, or are they intended to be
> > a private implementation detail of the CLI tools?
> 
> They are intended to be public.

In that case I think the necessary steps are:

- wait for upstream to set an official SONAME
  - someone from Collabora can propose a PR if upstream say it would be
helpful, or if that seems to be necessary to unblock the upstream issue

- change the Debian package to be built like a Policy §8 shared library:
  - libspirv-tools-dev
  - libspirv-tools0
  - possibly also libspirv-tools-link0, etc., depending whether upstream
say the SONAMEs are meant to go up in lockstep or separately
(the safe/conservative option is one binary package per shared library)
  - again, someone from Collabora can propose patches for this if necessary
  - the upstream action needs to happen first, to avoid Debian producing an
ABI that is incompatible with upstream

- NEW queue processing

Thanks,
smcv

Bug#956510: spirv-tools: change to shared libraries breaks dpkg-shlibdeps during the build of reverse dependencies

[Simon McVittie]

On Sun, 12 Apr 2020 at 11:04:38 +0200, Sebastian Ramacher wrote:
> libplacebo now manually links the libraries from spirv-tools
> (libSPIRV-Tools and libSPIRV-Tools-opt) to work-around #951988 and
> #955431. Since the switch to shared libraries, however, dpkg-shlibdeps
> is unable to produce the correct dependencies when linking those
> libraries.

Are these libraries intended to be a public API, or are they intended to be
a private implementation detail of the CLI tools?

If they're a private implementation detail, then libplacebo shouldn't be
linked to them, and they should either be statically linked into the
various CLI tools, or installed to a private directory with a RUNPATH
so that the CLI tools will find them (like the way /usr/bin/sudo links
to the private library libsudo_util.so.0).

If they're considered to be public libraries, then there are two options,
depending how stable they are:

If their API/ABI are totally unmanaged, then they should probably be
provided as static-only, with libplacebo binNMU'd to pick up new versions.

Or, if their API/ABI are managed, then they should have proper SONAMEs
(see upstream issues, as previously mentioned), and they should be
packaged like shared libraries, with a runtime library package per shared
library (or a single runtime library package if the upstream developer
guarantees that their SONAMEs all change in lockstep, like libglib2.0-0),
and one or more -dev packages. (See Policy §8 for details.)

smcv

Bug#958836: vulkan-loader: autopkgtest failure: missing test dependencies

[Simon McVittie]

Control: tags -1 + patch

On Sat, 25 Apr 2020 at 20:42:22 +0200, Paul Gevers wrote:
> With a recent upload of vulkan-loader you added an autopkgtest, great.
> However, it fails. I copied some of the output at the bottom of this
> report. It seems you're missing some test dependencies.

Sorry, that was my fault - the Debian derivative for which I wrote the
autopkgtest (the Steam Runtime) normally uses non-minimal "SDK" containers,
and I didn't test the patch in a minimal chroot before proposing it. It
should work better with the attached.

smcv
>From b06d5f7e3f0b52f22faa4b133a7f121f2612b72a Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 27 Apr 2020 09:13:46 +0100
Subject: [PATCH] d/tests/libvulkan-dev: Explicitly depend on build-essential,
 pkg-config

Closes: #958836
---
 debian/tests/control | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/tests/control b/debian/tests/control
index 25ff803..ef2c88b 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,4 +1,6 @@
 Tests: libvulkan-dev
 Restrictions: allow-stderr, superficial
 Depends:
+ build-essential,
  libvulkan-dev,
+ pkg-config,
-- 
2.26.2

Bug#954087: vulkan-loader: consider adding a .symbols file

[Simon McVittie]

Source: vulkan-loader
Version: 1.2.131.2-1
Severity: wishlist
Tags: patch

Adding a symbols file for dpkg-gensymbols helps to detect many forms of
ABI break. libvulkan seems to have a simple C ABI with explicit control
over what's exported, so it's a good candidate for adding this.

Patch:
https://salsa.debian.org/xorg-team/vulkan/vulkan-loader/-/merge_requests/3

smcv

Bug#954086: vulkan-loader: consider adding a superficial autopkgtest for the library

[Simon McVittie]

Source: vulkan-loader
Version: 1.2.131.2-1
Severity: wishlist
Tags: patch

Compiling and linking what is essentially "hello, world" against a library
is not a thorough test, but can detect surprisingly many library packaging
mistakes, so I've started writing a superficial test like this for every
library I backport or otherwise work on.

Patch available here:
https://salsa.debian.org/xorg-team/vulkan/vulkan-loader/-/merge_requests/2

smcv

Bug#954078: vulkan-loader: consider using multiple .orig tarball to simplify packaging

[Simon McVittie]

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

I notice that vulkan-loader contains a vendored copy of vulkan-headers,
in order to keep the library and headers in sync, with the "upstream"
tarball actually being composed by repacking the combination of
vulkan-loader and vulkan-headers.

Since it's a 3.0 (quilt) package already, and the vendored vulkan-headers
is in the top-level directory, this seems like a perfect fit for multiple
.orig tarballs:

- download 
https://github.com/KhronosGroup/Vulkan-Loader/archive/sdk-1.2.131.2.tar.gz
  and rename it to vulkan-loader_1.2.131.2.orig.tar.gz
- download 
https://github.com/KhronosGroup/Vulkan-Headers/archive/sdk-1.2.131.1.tar.gz
  and rename it to vulkan-loader_1.2.131.2.orig-vulkan-headers.tar.gz
  (note the version number mismatch - sorry, I think this is unavoidable
  with current tools, if your upstream doesn't always keep the version
  numbers in sync)
- put both in ../ or wherever else you keep your upstream tarballs, or
  commit them to pristine-tar with gbp import-orig if you use that
- import them both into your upstream-unstable git branch, perhaps with
  gbp import-orig --upstream-vcs-tag=... --component=vulkan-headers
  to keep it as a descendant of the upstream git history

This would avoid needing to repack the upstream tarball, which seems likely
to be problematic if more than one developer imports it independently.

The yquake2 source package in contrib is an example of this technique.
I use DEP-14 branch names rather than the xorg-team's conventions, but
I think the difference is mostly just labelling? In particular,
"component=ctf" in debian/gbp.conf and debian/watch (in your case it
would be "component=vulkan-headers") activates the support for multiple
.orig tarballs in gbp and uscan.

I'm involved in the maintenance of a derivative (the Steam Runtime) that
has an interest in having the latest Vulkan library, and it's looking like
I might need to package the latest release (a development version "v...",
rather than the stable "sdk-..." versions that you package). Would you
be interested in receiving a merge request with that version, targeting
experimental?

Thanks,
smcv

Bug#952589: libx11-dev: trying to overwrite '/usr/include/X11/extensions/XKBgeom.h', which is also in package x11proto-dev 2018.4-4

[Simon McVittie]

On Wed, 26 Feb 2020 at 17:47:07 +0200, Timo Aaltonen wrote:
> On 26.2.2020 16.17, Dmitry Shachnev wrote:
> >   Unpacking libx11-dev:amd64 (2:1.6.9-1) ...
> >   dpkg: error processing archive .../097-libx11-dev_2%3a1.6.9-1_amd64.deb 
> > (--unpack):
> >trying to overwrite '/usr/include/X11/extensions/XKBgeom.h', which is 
> > also in package x11proto-dev 2018.4-4
> 
> bah, I'll release a new xorgproto asap

You'll probably need to give x11proto-dev a versioned Breaks on the older
libx11-dev versions that expected x11proto-dev to provide that header.

libx11-dev will also need another upload to add a versioned
Breaks/Replaces on older versions of x11proto-dev (or possibly
a versioned Depends: x11proto-dev (>= x), Replaces: x11proto-dev (<< x))
to avoid broken partial upgrades.

This might also be a good opportunity to move libx11-dev's dependencies
from the transitional packages x11proto-core-dev, etc. to x11proto-dev.

smcv

Bug#947310: mesa: FTBFS on mipsel: Cannot find (any matches for) "usr/lib/*/libvulkan_*.so"

[Simon McVittie]

Source: mesa
Version: 19.3.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

mesa doesn't seem to be building Vulkan drivers on mipsel, but the
Architecture field of mesa-vulkan-drivers says it should be:

https://buildd.debian.org/status/fetch.php?pkg=mesa=mipsel=19.3.1-2=1576796202=0
> Vulkan drivers:  no
...
> dh_install -a
> dh_install: Cannot find (any matches for) 
> "usr/share/vulkan/explicit_layer.d/*.json" (tried in ., debian/tmp)
> 
> dh_install: mesa-vulkan-drivers missing files: 
> usr/share/vulkan/explicit_layer.d/*.json
> dh_install: Cannot find (any matches for) "usr/share/vulkan/icd.d/*.json" 
> (tried in ., debian/tmp)
> 
> dh_install: mesa-vulkan-drivers missing files: usr/share/vulkan/icd.d/*.json
> dh_install: Cannot find (any matches for) "usr/lib/*/libvulkan_*.so" (tried 
> in ., debian/tmp)
> 
> dh_install: mesa-vulkan-drivers missing files: usr/lib/*/libvulkan_*.so
> dh_install: Cannot find (any matches for) 
> "usr/lib/*/libVkLayer_MESA_overlay.so" (tried in ., debian/tmp)
> 
> dh_install: mesa-vulkan-drivers missing files: 
> usr/lib/*/libVkLayer_MESA_overlay.so
> dh_install: missing files, aborting

This might be because mipsel is present in the list of architectures where
LLVM is enabled (confflags_GALLIUM += -Dllvm=true etc.), and is present in
the list of architectures where the Vulkan loader is enabled
(confflags_VULKAN += -Dvulkan-overlay-layer=true), but is absent from the
list of architectures where VULKAN_DRIVERS += amd, despite that list being
documented as "only build on the subset of arches where we have LLVM enabled
and where the Vulkan loader is built".

smcv

Bug#945433: FTBFS: Invalid SPIR-V binary version 1.3 for target environment SPIR-V 1.0 (under OpenGL 4.5 semantics)

[Simon McVittie]

Source: glslang
Version: 7.13.3496-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=glslang=amd64=7.13.3496-1=1574253637=0
(and all the other architectures):

> 1/1 Test #1: glslang-testsuite ***Failed7.43 sec
> Running reflection...
> Comparing single thread to multithread for all tests in current directory...
> Running entry-point renaming tests
> Running ill-defined uncalled function
> Tests Succeeded.
> Running explicit stage test and compound suffix tests
> Running hlsl offsets
> Running hlsl offsets
> Configuring HLSL descriptor set and binding number manually
> Testing per-descriptor-set IO map shift
> Testing SPV no location
> Testing SPV Debug Information
> 2,3d1
> < error: SPIRV-Tools Validation Errors
> < error: Invalid SPIR-V binary version 1.3 for target environment SPIR-V 1.0 
> (under OpenGL 4.5 semantics).
> Testing Includer
> Testing -D and -U
> Testing --client and --target-env
> spv.targetVulkan.vert
> spv.targetOpenGL.vert
> spv.targetVulkan.vert
> spv.targetVulkan.vert
> spv.targetOpenGL.vert
> spv.targetVulkan.vert
> spv.targetOpenGL.vert
> spv.targetVulkan.vert
> Testing GLSL entry point rename
> Testing remapper error handling
> Testing position Y inversion
> Testing hlsl_functionality1
> Testing HLSL-specific PP feature expansion
> Testing nan-clamp
> Tests Failed.

Bug#940488: glslang: add autopkgtest smoke-tests

[Simon McVittie]

Source: glslang
Version: 7.10.2984-1
Severity: wishlist
Tags: patch

While backporting glslang to an older Debian derivative, I wanted to check
that the backport was basically functional, so I added simple autopkgtests.
Please consider adding something similar.

I attach the patch I used, but I'm sure a more realistic smoke-test (like
making the tools actually compile a shader, not just show help) would
be straightforward for someone who knows this package better than I do!

Thanks,
smcv
>From d7cdbaa1f73f5dae468f1ad3dcbe4dae80a4e4ea Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 12 Sep 2019 19:36:12 +0100
Subject: [PATCH] d/tests: Add superficial autopkgtests

Signed-off-by: Simon McVittie 
---
 debian/tests/control   |  9 +
 debian/tests/glslang-dev   | 37 +
 debian/tests/glslang-tools | 17 +
 3 files changed, 63 insertions(+)
 create mode 100644 debian/tests/control
 create mode 100755 debian/tests/glslang-dev
 create mode 100755 debian/tests/glslang-tools

diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index ..b40ee0ea
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,9 @@
+Tests: glslang-dev
+Restrictions: allow-stderr, superficial
+Depends:
+ glslang-dev,
+
+Tests: glslang-tools
+Restrictions: allow-stderr, superficial
+Depends:
+ glslang-tools,
diff --git a/debian/tests/glslang-dev b/debian/tests/glslang-dev
new file mode 100755
index ..9cb42d7e
--- /dev/null
+++ b/debian/tests/glslang-dev
@@ -0,0 +1,37 @@
+#!/bin/sh
+# Copyright © 2019 Collabora Ltd.
+# SPDX-License-Identifier: MIT
+# (see debian/copyright)
+
+# Check that the library can be linked.
+
+set -e
+set -u
+set -x
+
+tempdir="$(mktemp -d)"
+cd "$tempdir"
+
+cat > trivial.cpp <<'EOF'
+#undef NDEBUG
+#include 
+
+#include 
+
+int main (void)
+{
+  ShHandle handle;
+  handle = ShConstructUniformMap();
+  ShDestruct(handle);
+  return 0;
+}
+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
+test -x trivial
+./trivial
+
+cd /
+rm -fr "$tempdir"
diff --git a/debian/tests/glslang-tools b/debian/tests/glslang-tools
new file mode 100755
index ..2445c3ca
--- /dev/null
+++ b/debian/tests/glslang-tools
@@ -0,0 +1,17 @@
+#!/bin/sh
+
+# Copyright © 2019 Collabora Ltd.
+# SPDX-License-Identifier: MIT
+# (see debian/copyright)
+
+set -eux
+export LC_ALL=C.UTF-8
+
+# For now just check that the executables can run at all. They exit
+# unsuccessfully when asked for help, so screen-scrape the help...
+
+spirv-remap --help 2>&1 | tee "$AUTOPKGTEST_TMP/help"
+grep -q Usage: "$AUTOPKGTEST_TMP/help"
+
+glslangValidator --help 2>&1 | tee "$AUTOPKGTEST_TMP/help"
+grep -q Usage: "$AUTOPKGTEST_TMP/help"
-- 
2.23.0

Bug#940487: glslang-dev: please codify how to link to the provided libraries (e.g. pkg-config .pc file)

[Simon McVittie]

Package: glslang-dev
Version: 7.10.2984-1
Severity: wishlist
Tags: upstream
Forwarded: https://github.com/KhronosGroup/glslang/issues/1715

While backporting glslang-dev to an older Debian derivative I noticed
that there doesn't seem to be an obvious way to link to the supplied
libraries: dependent packages need to have out-of-band knowledge of the
names and interdependencies of all the static libraries, and also have
to know that some (all?) of them depend on libpthread.

It would be great if glslang had pkg-config .pc files, or some similar
way to document/codify how to use each of the APIs it exports.

For example, libplacebo currently needs to have


  glslang_deps = [
cxx.find_library('glslang', required: glslang_req),
cxx.find_library('HLSL',required: glslang_req),
cxx.find_library('OGLCompiler', required: glslang_req),
cxx.find_library('OSDependent', required: glslang_req),
cxx.find_library('SPIRV',   required: glslang_req),
cxx.find_library('SPVRemapper', required: glslang_req),
  ]
  ...
pthread = cxx.find_library('pthread', required: false)
glslang_combined = declare_dependency(dependencies: glslang_deps + 
[pthread])

and renderdoc has similar glue, but with CMake instead of Meson, and
without pulling in SPVRemapper or pthread:

list(APPEND RDOC_LIBRARIES
 PRIVATE -lglslang
 PRIVATE -lHLSL
 PRIVATE -lOGLCompiler
 PRIVATE -lOSDependent
 PRIVATE -lSPIRV)

Bug#940486: glslang-dev: could be marked as Multi-Arch: same

[Simon McVittie]

Package: glslang-dev
Version: 7.10.2984-1
Severity: wishlist
Tags: patch

While backporting glslang-dev to an older Debian derivative I noticed
that it only contains files that are architecture-independent (headers,
documentation) and files that are installed in multiarch-qualified
directories (libraries), so it could be marked Multi-Arch: same for
easier use in cross-compiling.

I was backporting the version from buster, but the version in unstable
seems to be the same in this respect.

smcv
>From 582048c179ec70f65b6e7c231545bd955c204941 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 12 Sep 2019 19:01:26 +0100
Subject: [PATCH] d/control: Mark -dev package as Multi-Arch: same

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

diff --git a/debian/control b/debian/control
index 96709e90..955b45b1 100644
--- a/debian/control
+++ b/debian/control
@@ -24,6 +24,7 @@ Description: OpenGL and OpenGL ES shader front end and validator -- tools
 
 Package: glslang-dev
 Architecture: any
+Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: OpenGL and OpenGL ES shader front end and validator -- development files
  glslang is the official reference compiler front end for the OpenGL ES
-- 
2.23.0

Bug#935884: libgl1-mesa-dri: regression on mips64el llvmpipe: segfault in clutter-1.0 test actor-offscreen-limit-max-size

[Simon McVittie]

Package: libgl1-mesa-dri
Version: 19.1.4-1
Severity: important
X-Debbugs-Cc: debian-m...@lists.debian.org
User: debian-m...@lists.debian.org
Usertags: mips64el

Steps to reproduce:

* have unstable
* try to build the clutter-1.0 package from source, for example
  
https://buildd.debian.org/status/fetch.php?pkg=clutter-1.0=mips64el=1.26.2%2Bdfsg-11=1566879693=0
* if the build fails with the test failure that I am reporting, you can
  retry without rebuilding everything using a command like:
  ./libtool --mode=execute xvfb-run -a 
tests/conform/actor-offscreen-limit-max-size --verbose
  (possibly adding environment variables, gdb --args, etc.)

Alternative steps to reproduce:

* have unstable
* install precompiled clutter-1.0-tests, xauth, xvfb
  (this demonstrates that the bug is not a regression in clutter-1.0)
* xvfb-run -a 
/usr/lib/mips64el-linux-gnuabi64/installed-tests/clutter/actor-offscreen-limit-max-size
 --verbose

Expected result, as seen in a buster chroot:

> % xvfb-run -a 
> /usr/lib/mips64el-linux-gnuabi64/installed-tests/clutter/actor-offscreen-limit-max-size
>  --verbose
> GTest: random seed: R02Sbfd7336fb33bfafdd68baabe91d5b162
> GTest: run: /actor/offscreen/limit-max-size
> Checking effect1 size: 207.00 x 207.00
> Checking effect2 size: 300.00 x 300.00
> 'generic' is not a recognized processor for this target (ignoring processor)
> 'generic' is not a recognized processor for this target (ignoring processor)
...
> 'generic' is not a recognized processor for this target (ignoring processor)
> 'generic' is not a recognized processor for this target (ignoring processor)
> GTest: result: OK

This test was also successful on all other release architectures (in
particular mipsel), except for armel and s390x where the tests are
skipped because they have been known to block indefinitely in the past.

Actual result, as seen in a sid chroot:

> % xvfb-run -a 
> /usr/lib/mips64el-linux-gnuabi64/installed-tests/clutter/actor-offscreen-limit-max-size
>  --verbose
> GTest: random seed: R02S765417d5fb8d7844862eea7de5c996db
> GTest: run: /actor/offscreen/limit-max-size
> Checking effect1 size: 207.00 x 207.00
> Checking effect2 size: 300.00 x 300.00
> 'generic' is not a recognized processor for this target (ignoring processor)
> 'generic' is not a recognized processor for this target (ignoring processor)
...
> 'generic' is not a recognized processor for this target (ignoring processor)
> 'generic' is not a recognized processor for this target (ignoring processor)
> Segmentation fault (core dumped)

Unfortunately the backtrace is not very enlightening, at least to me:

> Thread 3 "llvmpipe-1" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xffefe34f00 (LWP 14160)]
> (gdb) thread apply all bt
> 
> Thread 5 (Thread 0xffeee32f00 (LWP 14162)):
> warning: GDB can't find the start of the function at 0xffee5cbadc.
> #0  0x00ffee5cbadc in  ()
> 
> Thread 4 (Thread 0xffef633f00 (LWP 14161)):
> warning: GDB can't find the start of the function at 0xffee5cbadc.
> #0  0x00ffee5cbadc in  ()
> 
> Thread 3 (Thread 0xffefe34f00 (LWP 14160)):
> warning: GDB can't find the start of the function at 0xffee5cbadc.
> #0  0x00ffee5cbadc in  ()
> 
> Thread 2 (Thread 0xfff0635f00 (LWP 14159)):
> warning: GDB can't find the start of the function at 0xffee5cbadc.
> #0  0x00ffee5cbadc in  ()
> 
> Thread 1 (Thread 0xfff643b010 (LWP 11652)):
> #0  0x00fff6fd97e0 in futex_wait_cancelable (private=0, expected=0, 
> futex_word=0xb84578) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
> #1  0x00fff6fd97e0 in __pthread_cond_wait_common (abstime=0x0, 
> mutex=0xb84528, cond=0xb84550) at pthread_cond_wait.c:502
> #2  0x00fff6fd97e0 in __pthread_cond_wait (cond=0xb84550, 
> mutex=0xb84528) at pthread_cond_wait.c:655   
> #3  0x00fff538bb2c in cnd_wait (mtx=0xb84528, cond=0xb84550) at 
> ../include/c11/threads_posix.h:155
> #4  0x00fff538bb2c in pipe_semaphore_wait (sema=0xb84528) at 
> ../src/gallium/auxiliary/os/os_thread.h:108
> warning: GDB can't find the start of the function at 0xfff7e7e0f7.
> #5  0x00fff538bb2c in lp_rast_finish (rast=0xb84410) at 
> ../src/gallium/drivers/llvmpipe/lp_rast.c:770
> #6  0x00fff539a160 in lp_setup_rasterize_scene (setup=0xc31090) at 
> ../src/gallium/drivers/llvmpipe/lp_setup.c:181
> #7  0x00fff539a160 in set_scene_state (setup=0xc31090, 
> new_state=, reason=) at 
> ../src/gallium/drivers/llvmpipe/lp_setup.c:331
> #8  0x00fff539af20 in lp_setup_flush (setup=0xc31090, fence=0x0, 
> reason=) at ../src/gallium/drivers/llvmpipe/lp_setup.c:360
> #9  0x00fff5389698 in llvmpipe_flush (pipe=0xb1fce0, fence=0x0, 
> reason=0xfff5d1e490 <__func__.18359> "do_flush") at 
> ../src/gallium/drivers/llvmpipe/lp_flush.c:56
> #10 0x00fff5388858 in do_flush (pipe=, fence= out>, flags=) at 
> ../src/gallium/drivers/llvmpipe/lp_context.c:117
> #11 0x00fff58d720c in st_glFlush (ctx=) at 
> 

Re: Bug#928297: xserver-xorg-core: transitively depends on libgl1-mesa-dri

[Simon McVittie]

Control: retitle -1 xserver-xorg-core: transitively depends on libgl1-mesa-dri

On Wed, 01 May 2019 at 15:42:23 +0200, Jonas Smedegaard wrote:
> Quoting Jonas Smedegaard (2019-05-01 15:25:16)
> > xserver-xorg-core 2:1.19.3-2 has Depends: libgl1-mesa-glx | libgl
> > 
> > xserver-xorg-core 2:1.19.4-1 has Depends: libgl

(The former is correct, but the latter should say libgl1, not libgl)

I don't think this is a bug. libgl1-mesa-glx was an implementation of
the abstract libgl interface. Xorg now depends on libgl1, which is a
vendor-neutral dispatcher that loads one of several backends, including
Mesa's: because it's vendor-neutral, there is no longer any need for
alternatives.

libgl1-mesa-glx is now a transitional package which pulls in libgl1
and libglx-mesa0, and (indirectly) libgl1-mesa-dri, so adding it as
an alternative would not help to make libgl1-mesa-dri more optional.

> Seems the change coincide with the introduction of src:libglvnd.

libgl1-mesa-glx | libgl dependencies being replaced by libgl1 is part
of the GLVND transition, but would not necessarily cause the symptom of
a transitive dependency on libgl1-mesa-dri.

I think that might actually be caused by:

mesa (17.2.0~rc6-1) experimental; urgency=medium
  ...
  * control: Bump libgl1-mesa-dri to libglx-mesa0 Depends, it's needed
for swrast used on some tests.

If I'm correct about that, then this bug should perhaps be reassigned to
libglx-mesa0.

Perhaps it should be those tests that explicitly pull in libgl1-mesa-dri?

(Although I do question how useful libglx-mesa0 can possibly be without
the DRI drivers that make it work.)

smcv

Re: Bug#922346: eog: Opened an image and my display server crashed

[Simon McVittie]

Control: reassign -1 libgl1-mesa-dri
Control: tags -1 + moreinfo

On Thu, 14 Feb 2019 at 21:18:42 +0100, Michel Le Bihan wrote:
> I opened a png file in eog and my display server crashed.

eog shouldn't be able to cause this, even if it wanted to, so this is
a bug in the display server or some library it uses.

>From the backtrace you provided, I think this is most likely to be an
assertion failure in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so, so I'm
reassigning this.

The Mesa maintainers will want to know more details of your system.
The output of `reportbug --template libgl1-mesa-dri` would presumably
be useful information.

Was the file that you opened in eog particularly large, or otherwise
unusual?

Thanks,
smcv

> Here is the relevant part of my syslog:
> 
> Feb 14 20:44:45 debian org.gnome.Shell.desktop[1414]: Window manager warning:
> Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for
> 0x187 (Visionneur)
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: Xwayland:
> src/intel/genxml/gen7_pack.h:72: __gen_uint: Assertion `v <= max' failed.
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE)
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) Backtrace:
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 0: 
> /usr/bin/Xwayland
> (OsLookupColor+0x139) [0x55b8e2f27e09]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 1:
> /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) [0x7fba70a3372f]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 2:
> /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x10b) [0x7fba708978bb]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 3:
> /lib/x86_64-linux-gnu/libc.so.6 (abort+0x121) [0x7fba70882535]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) unw_get_proc_name
> failed: no unwind info found [-10]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 4:
> /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7fba70882400]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 5:
> /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x42) [0x7fba708900f2]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 6:
> /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
> (__driDriverGetExtensions_nouveau_vieux+0x416573) [0x7fba6fb6c503]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 7:
> /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
> (__driDriverGetExtensions_nouveau_vieux+0x416dd5) [0x7fba6fb6cd95]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 8:
> /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
> (__driDriverGetExtensions_i915+0x136b7b) [0x7fba6f402d8b]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 9:
> /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
> (__driDriverGetExtensions_i915+0x1370e7) [0x7fba6f403ab7]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 10:
> /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
> (__driDriverGetExtensions_i915+0x12f041) [0x7fba6f3f3711]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 11:
> /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
> (__driDriverGetExtensions_i915+0x11a2dc) [0x7fba6f3c952c]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 12:
> /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
> (__driDriverGetExtensions_nouveau_vieux+0x1ccc7a) [0x7fba6f6d929a]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 13:
> /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
> (__driDriverGetExtensions_nouveau_vieux+0x1ccfea) [0x7fba6f6d999a]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 14:
> /usr/bin/Xwayland (glamor_create_gc+0xd535) [0x55b8e2df1a05]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 15:
> /usr/bin/Xwayland (DamageRegionAppend+0x19f8) [0x55b8e2e98eb8]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 16:
> /usr/bin/Xwayland (glamor_pixmap_exchange_fbos+0x7b7) [0x55b8e2deef57]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 17:
> /usr/bin/Xwayland (glamor_pixmap_exchange_fbos+0x67e) [0x55b8e2dee9be]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 18:
> /usr/bin/Xwayland (AddTraps+0x3551) [0x55b8e2e8aad1]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 19:
> /usr/bin/Xwayland (SendErrorToClient+0x35e) [0x55b8e2ef1e6e]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 20:
> /usr/bin/Xwayland (InitFonts+0x3b6) [0x55b8e2ef5df6]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 21:
> /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xeb) [0x7fba7088409b]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) 22:
> /usr/bin/Xwayland (_start+0x2a) [0x55b8e2dc71ea]
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE)
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE)
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: Fatal server error:
> Feb 14 20:44:46 debian org.gnome.Shell.desktop[1414]: (EE) Caught signal 6
> (Aborted). Server aborting
> Feb 14 20:44:46 

Bug#921940: Error "Could not resolve keysym XF86MonBrightnessCycle"

[Simon McVittie]

On Sun, 10 Feb 2019 at 13:42:28 +0100, Reiner Herrmann wrote:
> The XKEYBOARD keymap compiler (xkbcomp) reports:
> > Warning:  Unsupported high keycode 372 for name  ignored
> >   X11 cannot support keycodes above 255.
> >   This warning only shows for the first high keycode.
> > Internal error:   Could not resolve keysym XF86MonBrightnessCycle

I think this might be the same bug as #921867 and #922020.

smcv

Re: Bug#922020: gnome-shell: Keyboard layout not applied in programs using Xwayland

[Simon McVittie]

Control: reassign -1 xkb-data 2.26-1

On Mon, 11 Feb 2019 at 10:54:21 +, Simon McVittie wrote:
> On Mon, 11 Feb 2019 at 10:56:50 +0100, Paul Menzel wrote:
> > Since updating the packages on Saturday in Debian Sid/unstable, using GNOME
> > Shell with Wayland, the configure keyboard layout is not applied to programs
> > using XWayland anymore. Examples are Mozilla Firefox, Mozilla Thunderbird
> > and Google Chromium.
> 
> I'm not seeing this bug: I'm using a UK English keyboard layout myself,
> and I can still type Shift+3 into Firefox and GTK2 apps to get £ (which
> doesn't appear on USA keyboards).

I can reproduce this by adding a French AZERTY (fr+azerty) keyboard layout
as a third option alongside my current gb and us in GNOME Settings ->
Region & Language, and switching between them with Super+Space
(Windows key + Space). The Journal says:

Feb 11 11:10:43 espresso org.gnome.Shell.desktop[2322]: The XKEYBOARD keymap 
compiler (xkbcomp) reports:
Feb 11 11:10:43 espresso org.gnome.Shell.desktop[2322]: > Error:
Illegal keycode 374 (must be in the range 8-255 inclusive)
Feb 11 11:10:43 espresso org.gnome.Shell.desktop[2322]: >   
Value of "maximum" not changed
Feb 11 11:10:43 espresso org.gnome.Shell.desktop[2322]: > Warning:  
Unsupported high keycode 372 for name  ignored
Feb 11 11:10:43 espresso org.gnome.Shell.desktop[2322]: >   X11 
cannot support keycodes above 255.
Feb 11 11:10:43 espresso org.gnome.Shell.desktop[2322]: >   
This warning only shows for the first high keycode.
Feb 11 11:10:43 espresso org.gnome.Shell.desktop[2322]: Errors from xkbcomp are 
not fatal to the X server
Feb 11 11:10:43 espresso org.gnome.Shell.desktop[2322]: The XKEYBOARD keymap 
compiler (xkbcomp) reports:
Feb 11 11:10:43 espresso org.gnome.Shell.desktop[2322]: > Warning:  
Unsupported high keycode 372 for name  ignored
Feb 11 11:10:43 espresso org.gnome.Shell.desktop[2322]: >   X11 
cannot support keycodes above 255.
Feb 11 11:10:43 espresso org.gnome.Shell.desktop[2322]: >   
This warning only shows for the first high keycode.
Feb 11 11:10:43 espresso org.gnome.Shell.desktop[2322]: > Internal error:   
Could not resolve keysym XF86MonBrightnessCycle
Feb 11 11:10:43 espresso org.gnome.Shell.desktop[2322]: Errors from xkbcomp are 
not fatal to the X server

Answering some of my own questions:

> What keyboard layout are you using/intending to use? Does it still work
> correctly in native Wayland apps like gedit?

I used the fr+azerty layout.

> What precisely do you mean by "not applied"? Does typing into Firefox
> and GTK2 apps behave as though you were using a USA keyboard
> (shift+2 -> @, shift+3 -> #, etc.)

Yes, this. After reproducing the bug, switching back to my usual gb
keyboard layout with Super+Space also resulted in a USA layout.

Downgrading xkb-data to 2.23.1-1 and restarting GNOME Shell (logging out
and back in) successfully works around the bug.

smcv

Re: Bug#921715: libgtk2.0-0-udeb: wrong dependency while building on buster based system

[Simon McVittie]

Control: reassign 921715 libxinerama1 1.1.4-1
Control: reassign 921712 libxinerama1 1.1.4-1
Control: merge 921715 921712
Control: severity 921715 serious
Control: affects 921715 + libgtk2.0-0-udeb

On Fri, 08 Feb 2019 at 09:27:20 +, Mayer, Dirk wrote:
> while building the gtk+2.0 source package on a buster based build system, the 
> resulting package libgtk2.0-0-udeb yields a wrong dependency.
> Instead of the correct dependency to the package libxinerama1-udeb it depends 
> on the wrong package libxinerama1.
> On the stretch based build system the dependency correctly refers to the udeb 
> package.

This seems to be a regression in libxinerama1 1.1.4-1. Its shlibs
metadata doesn't list a record for a udeb:

$ cat /var/lib/dpkg/info/libxinerama1:amd64.shlibs
libXinerama 1 libxinerama1

whereas other X11 udebs have an extra line for udebs, for example:

$ /var/lib/dpkg/info/libxcursor1:amd64.shlibs
libXcursor 1 libxcursor1 (>> 1.1.2)
udeb: libXcursor 1 libxcursor1-udeb (>> 1.1.2)

As a result, when gtk+2.0 is compiled, dh_shlibdeps doesn't know that
its udeb should depend on libxinerama1-udeb.

I think this is because the "--add-udeb=$(PACKAGE)-udeb" option wasn't
preserved during the rewrite of d/rules from traditional debhelper style
to dh.

I've raised this bug to serious severity, because I think it would break the
graphical installer next time gtk+2.0 is rebuilt (we've just been lucky that
the most recent gtk+2.0 upload was a few days before libxinerama1 1.1.4-1). The
X11 and d-i maintainers are of course welcome to reduce the severity if they
disagree with my assessment of its impact.

This probably also affects gtk+3.0, but I don't think debian-installer uses
that yet, so it's only a theoretical issue there.

> Duplicate to Bug #921712 because of wrong package tag
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921712

I've merged the bugs.

Thanks,
smcv

Bug#921069: libxcb-dri3.so.0: added ABI without increasing -version-info

[Simon McVittie]

Package: libxcb-dri3-0
Version: 1.13.1-2
Severity: normal
File: /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0.0.0
Tags: upstream
X-Debbugs-Cc: st...@packages.debian.org

libxcb-dri3 version 1.13 appears to have added new symbols without increasing
the minor ABI version in its -version-info. This will break anything that
compares libraries by their version info to decide which one is newer.

The Steam Runtime uses libraries' major/minor/micro ABI version info (in this
case 0.0.0) to decide whether to use the system copy of a library or the copy
in the Steam Runtime, depending on which one is newer (#921026). We can
work around this by adding a versioned dependency on libxcb-dri3-0 and
deleting the copy from the Steam Runtime, but this isn't a particularly
scalable solution.

smcv

Re: Bug#909770: i915: Does not show gdm greeter on eDP: Link Training failed at link rate = 270000, lane count = 2

[Simon McVittie]

Control: retitle 909770 i915: Does not show gdm greeter on eDP: Link Training 
failed at link rate = 27, lane count = 2
Control: severity 909770 important
Control: reassign 909770 src:linux
Control: affects 909770 gdm3

On Wed, 10 Oct 2018 at 13:22:37 +0200, Sergio Villar Senin wrote:
> Note that I've reproduced today this very same issue with lightdm as
> well, so I guess this is the confirmation that the bug is somewhere
> else. Graphics drivers maybe?

Yes, this sounds like a graphics driver problem. Summarizing for
kernel/graphics maintainers:

Original bug report:

> Boot the computer, then wait for the login screen (gdm) to appear.
>
> The background of the plyumouth theme is shown but the list of
> users is not there as expected.
>
> Sometimes I press the power button and the system suspends to
> RAM. When resuming then the gdm login screen is there, *but* if I try to
> enter any session (GNOME) it does not work. The authentication seems
> to succeed but then the screen becomes blank and there is no
> possibility to even switch to the terminals via Ctr-Alt-Fx.

Logs: https://pastebin.com/PiwQdiR2 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909770#17

Most relevant-looking log message:

> laptop kernel: [drm:intel_dp_start_link_train [i915]] *ERROR*
> [CONNECTOR:71:eDP-1] Link Training failed at link rate = 27, lane
> count = 2

Workaround (presumably suspend/resume retries link training):

> BTW I noticed that it is possible to enter the session by following the
> next steps:
> 1- Boot
> 2- Nothing is shown. Press power button to suspend
> 3- Resume laptop. gdm is shown
> 4- Enter credentials. Succeeds.
> 5- Nothing is shown. Press power button to suspend
> 6- Resume laptop. GNOME session is opened and working normally

Disabling Wayland in gdm does not work around this. Switching to lightdm
works around this (presumably it chooses video modes in a way that does
not exactly match GNOME?), but not entirely reliably.

smcv

Bug#909242: Xvfb: segfaults on mips during gtk+3.0 build-time tests

[Simon McVittie]

Package: xvfb
Version: 2:1.20.1-2
Severity: important
X-Debbugs-Cc: debian-m...@lists.debian.org
User: debian-m...@lists.debian.org
Usertags: mips

My recent gtk+3.0 upload to experimental failed many of its build-time
tests on mips. The tests could not connect to the Xvfb server run by the
upstream build system, which later crashed with a segmentation fault.

https://buildd.debian.org/status/fetch.php?pkg=gtk%2B3.0=mips=3.24.1-1=1537406479=log

I can reproduce this reliably on the mips porterbox, minkus, by running
Xvfb in a schroot with the options shown below.

Core was generated by `Xvfb -ac -noreset -screen 0 1024x768x16 :1 -nolisten tcp 
-auth /dev/null'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x77a7c3f8 in ?? () from /usr/lib/mips-linux-gnu/libunwind.so.8
(gdb) bt
#0  0x77a7c3f8 in ?? () from /usr/lib/mips-linux-gnu/libunwind.so.8
#1  0x77a7c99c in _ULmips_is_signal_frame () from 
/usr/lib/mips-linux-gnu/libunwind.so.8
#2  0x77a7cbb0 in _ULmips_handle_signal_frame () from 
/usr/lib/mips-linux-gnu/libunwind.so.8
#3  0x77a7d01c in _ULmips_step () from /usr/lib/mips-linux-gnu/libunwind.so.8
#4  0x55eaaff0 in xorg_backtrace () at ../../../../os/backtrace.c:72
#5  0x55eb0444 in OsSigHandler (signo=11, sip=0x7fd51fc8, unused=) at ../../../../os/osinit.c:135
#6  
#7  0x77a7c3f8 in ?? () from /usr/lib/mips-linux-gnu/libunwind.so.8
#8  0x77a7c99c in _ULmips_is_signal_frame () from 
/usr/lib/mips-linux-gnu/libunwind.so.8
#9  0x77a7cbb0 in _ULmips_handle_signal_frame () from 
/usr/lib/mips-linux-gnu/libunwind.so.8
#10 0x77a7d01c in _ULmips_step () from /usr/lib/mips-linux-gnu/libunwind.so.8
#11 0x77a7a8f8 in unw_backtrace () from /usr/lib/mips-linux-gnu/libunwind.so.8
#12 0x55eb06b0 in OsInit () at ../../../../os/osinit.c:217
#13 0x55e4d708 in dix_main (argc=11, argv=0x7fd639e4, envp=) at 
../../../../dix/main.c:154
#14 0x7759ccf8 in __libc_start_main () from /lib/mips-linux-gnu/libc.so.6
#15 0x55d28e34 in __start ()
Backtrace stopped: frame did not save the PC

Line 217 is this backtrace() call:

#ifdef HAVE_BACKTRACE
/*
 * initialize the backtracer, since the ctor calls dlopen(), which
 * calls malloc(), which isn't signal-safe.
 */
do {
void *array;

backtrace(, 1); <--- here
} while (0);
#endif

so this might really be a libunwind bug (please reassign if you think so).
libunwind8:mips 1.2.1-8 was installed.

I thought this might be hardware-specific, but according to machines.cgi,
mips-sil-01 (where gtk+3.0 failed) and mips-manda-01 (where a libepoxy
build with the same xvfb and libunwind8 versions, also using Xvfb for
tests, succeeded) are matching hardware, a Rhino Labs UTM8.  minkus,
the porterbox where I reproduced this, is apparently an EdgeRouter Pro.

Xvfb is used in many packages' build-time tests, which for most
maintainers are the only evidence we have that our packages are at all
functional on mips, so it might be a good idea to work around this in
Xvfb by disabling backtrace support and/or libunwind on mips.

smcv

Re: Bug#908951: gnome-shell: Intermittent unrecoverable failures due to tp_detect_thumb_while_moving assertion failure

[Simon McVittie]

Control: reassign -1 libinput10 1.12.0-1
Control: retitle -1 ../src/evdev-mt-touchpad.c:1541: 
tp_detect_thumb_while_moving: Assertion `first' failed
Control: affects -1 + gnome-shell

On Sun, 16 Sep 2018 at 10:54:07 -0400, Matthew Berardi wrote:
>   org.gnome.Shell.desktop[10025]: gnome-shell: 
> ../src/evdev-mt-touchpad.c:1541: tp_detect_thumb_while_moving: Assertion 
> `first' failed.
>   ...
>   gnome-session-binary[9993]: Unrecoverable failure in required component 
> org.gnome.Shell.desktop
> 
> From the core:
> 
> Process 10025 (gnome-shell) of user 1000 dumped core.
> 
>   Stack trace of thread 10025:
>   #0  0x7f39ffbcd77b raise (libpthread.so.0)
>   #1  0x55a45a5eae2b n/a (gnome-shell)
>   #2  0x7f39ffbcd8e0 __restore_rt (libpthread.so.0)
>   #3  0x7f39ffa33f3b __GI_raise (libc.so.6)
>   #4  0x7f39ffa352f1 __GI_abort (libc.so.6)
>   #5  0x7f39ffa2ca8a __assert_fail_base (libc.so.6)
>   #6  0x7f39ffa2cb02 __GI___assert_fail (libc.so.6)
>   #7  0x7f39fa9a6c70 n/a (libinput.so.10)
>   #8  0x7f39fa9a7810 n/a (libinput.so.10)
>   #9  0x7f39fa99a890 n/a (libinput.so.10)
>   #10 0x7f39fa99697f libinput_dispatch (libinput.so.10)
>   #11 0x7f39ffdf01b5 n/a (libmutter-clutter-3.so)
>   #12 0x7f3a009b0c3e g_main_context_dispatch (libglib-2.0.so.0)
>   #13 0x7f3a009b0ed8 n/a (libglib-2.0.so.0)
>   #14 0x7f3a009b11d2 g_main_loop_run (libglib-2.0.so.0)
>   #15 0x7f39ffc89fcc meta_run (libmutter-3.so.0)
>   #16 0x55a45a5ea782 n/a (gnome-shell)
>   #17 0x7f39ffa20b17 __libc_start_main (libc.so.6)
>   #18 0x55a45a5ea8da n/a (gnome-shell)
> 
> The trackpad is the one in a first-generation macbook pro retina.
> 
> I do not know if the cause is upstream.

This assertion failure looks like a bug in libinput (or possibly in
something it relies on, like the kernel); reassigning, and guessing that
you have the version of libinput10 that is current in testing/unstable.

smcv

Re: Bug#902617: gnome-maps, totem: Cannot move map, play video without allow_rgb10_configs=false

[Simon McVittie]

Control: reassign 902617 libgl1-mesa-dri 18.1.2-1
Control: retitle 902617 gnome-maps, totem: Cannot move map, play video without 
allow_rgb10_configs=false
Control: tags 902617 + moreinfo

On Thu, 28 Jun 2018 at 17:15:12 +0200, Onno Leerink wrote:
> Since installing Debian buster it is not possible to move the map using the
> mouse in gnome-maps. Before this, moving the map was no problem.
> 
> I found the following temporary solution in Redhat bug 1560481, start gnome-
> maps with:
> 
> allow_rgb10_configs=false gnome-maps
> 
> This causes to gnome-maps to function normally again.
> 
> This same solution also solves a bug concerning Totem not playing videos
> anymore.
> 
> I have a amd graphics card.

This sounds like a bug in your graphics driver rather than gnome-maps, so
I'm reassigning it to the libgl1-mesa-dri package. The allow_rgb10_configs
environment variable that you're using to work around this is a Mesa
feature.

Does this still happen with the current versions of Mesa and the Linux
kernel? (mesa 18.1.5-1 and Linux 4.17.8-1)

The mesa maintainers will need some more information from you:
please run "reportbug --template libgl1-mesa-dri" and send the resulting
system information to the bug address.

(Context for Mesa maintainers: the similarity between gnome-maps and totem
is that they both use Clutter, which uses GL for its 2D scene graph.)

Thanks,
smcv

Bug#867701: Radeon HD 6450, black screen, cursor, no console

[Simon McVittie]

Control: severity -1 important

On Sat, 15 Jul 2017 at 12:29:39 +0900, Michel Dänzer wrote:
> The bug severities are defined in the context of all users, not just
> some individual users. "Makes the package in question unusable" means
> the package cannot be used on any system, which isn't the case here (or
> there would have been many more reports about it, but there hasn't been
> any other report).

Downgrading accordingly.

smcv

Bug#868179: xserver-xorg-video-radeon: SEGV when starting X11

[Simon McVittie]

Control: severity -1 important
Control: retitle -1 xserver-xorg-video-radeon: SEGV if xorg.conf contains both 
rotation and Virtual
Control: tags -1 + fixed-upstream moreinfo

On Sat, 15 Jul 2017 at 12:13:34 +0900, Michel Dänzer wrote:
> On 15/07/17 03:57 AM, bartek 'basz' szurgot wrote:
> > knowing the exact conditions under which SEGV occurs
> > (i.e. rotated screen in xorg.conf), i agree it is not a "grave" bug.
> 
> It's even more specific than that: The crash only happens if xorg.conf
> contains rotation and a Virtual stanza (which BTW is probably useless in
> this case anyway).

Downgrading to important based on this reasoning, and retitling to be more
specific.

> > when the fix is expected to arrive to the xserver-xorg-video-radeon
> > package in Debian-testing?
> 
> I have to defer to the Debian packagers on that. Upstream it'll likely
> only be in the 7.10.0 release.

The 18.0.1 release (xserver-xorg-video-ati/1:18.0.1-1) is now available in
Debian testing and unstable. bartek, does that resolve this crash for you?

Thanks,
smcv