On Mon, 10 Jun 2024 at 12:35:25 +0200, gru...@laposte.net wrote:
> Among GNOME settings, I have three choices available:
> Français
> Français Azerty
> Français Azerty (AFNOR)
There should be a lot more than that. I don't speak French, but in an
English-language GNOME installation on Debian 12,
On Mon, 10 Jun 2024 at 05:48:44 +0200, gru...@laposte.net wrote:
> I did a
> $ sudo dpkg-reconfigure keyboard-configuration
This changes the keyboard layout that is used for the login screen, and
for any session that does not have its own, separate configuration.
It does not change the keyboard
Control: reassign -1 xkb-data 2.35.1-1
On Sun, 09 Jun 2024 at 23:13:32 +0200, gru...@laposte.net wrote:
> XKBMODEL="pc105"
> XKBLAYOUT="fr"
> XKBVARIANT="azerty"
(and)
> $ dconf dump /org/gnome/desktop/input-sources/
> [/]
> show-all-sources=false
> sources=[('xkb', 'fr+azerty')]
>
On Sun, 09 Jun 2024 at 18:16:01 +0100, Simon McVittie wrote:
> However, the French layout in /usr/share/X11/xkb/symbols/fr says that
> pressing the 7 key (with AltGr held) sends "grave" like my UK English
> layout, and not "dead_grave" like the German layout. So if t
ibus and xkeyboard-config maintainers and debian-l10n-french cc'd in
the hope that someone understands what is happening here, because I dont
think this is actually a libglib2.0-0 bug.
On Sun, 09 Jun 2024 at 17:23:27 +0200, gru...@laposte.net wrote:
> When you did the fix that repaired most of
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
>
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'
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
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
Source: vulkan-loader
Version: 1.3.268.0-1
Severity: wishlist
A new upstream release vulkan-sdk-1.3.275.0 is available.
smcv
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
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
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
(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
> > &
kernel
in case there's something subtly different.
Thanks,
Simon
[ 7.490078] ucsi_acpi USBC000:00: ucsi_handle_connector_change:
GET_CONNECTOR_STATUS failed (-5)
[ 7.605873] ucsi_acpi USBC000:00: possible UCSI driver bug 1
[ 7.605903] ucsi_acpi USBC000:00
timeout!
[ 1169.147619] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR*
wait_for_completion_timeout timeout!
[ 1179.387933] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR*
wait_for_completion_timeout timeout!
Thank you, hopefully this info is useful to someone!
Simon
request: 0x0
Serial number of failed request: 271
Current serial number in output stream: 271
The resulting file is empty. This also happens when -icmap is specified.
Simon
-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500
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).
>
>
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,
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
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
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
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
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
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:
>
>
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
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:
-
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.
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
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
hanges 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
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 m
+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: D
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 thi
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
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
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-
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
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
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 +
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
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:
>
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
> v
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
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 w
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'r
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 t
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:0
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:0
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
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
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
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
> book
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
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
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
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.
>
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. P
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
Hi,
the missing example code is attached here.
Simon
vkload-b0rked.tar.gz
Description: application/gzip
plication against libXext.
Simon
- -- System Information:
Debian Release: 11.2
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'),
(500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Ar
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
> o
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
>
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.
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
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
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
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
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
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
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"?
> > The
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
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: Si
for bullseye.
Given all the changes/massive improvements in amdgpu modesetting
I expect the situation to be considerably improved, at least!.
--Simon
the bug closed or issue forwarded
upstream if still relevant.
--simon
I can confirm the buster-backports now offers kernel
5.10.0-0.bpo.7-amd64 ..
Please test this following notes on previous bug pointer.
Can the bug now be closed, if that works, or doesn't -- I don't
think there is an X.org bug here.
--Simon
Julian and bug 942318,
buster-backports now provides kernel 5.10.0-0.bpo.7 via the
buster-backports linux-image-amd64 linux-headers-amd64 packages.
Please confirm if this solves the issue for you, and close the bug.
--Simon
in buster or bullseye now [??] ?
--Simon
Dear Janusz
linux-image-amd64 linux-headers-amd64 have now come out in version
5.10.0-0.bpo.7 in buster-backports.
Please confirm the issue is solved for you (or not) by using that
kernel as above, so the bug report can be prgressed or closed.
--Simon
BIOS/firmware?
--Simon
behave
better for you (let us know!).
--Simon
p.s. the backports kernel is lagging behind a little,
hopefully 5.10.0-0.bpo.6 and 5.10.0-0.bpo.7 will come
out soon.
monitor arrangement
reordering the displayport- virtual numbers (fixed with xrandr script)
but NO LONGER crashes needing reboot or restart-X11 like before...
In any case, please report back how 5.10 series kernel does/does-not
avoid the issue occuring for you.
--Simon
p.s. The buster-backports
.7 will come
out soon.
--Simon
'work' with bullseye and may assist with the 'it used to work' scenario.
Hope that helps,
--Simon
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 complic
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
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
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
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
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
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:
> > >
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: [PA
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 +
Subj
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 appl
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.
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,
if the system was still alive.
* What was the outcome of this action?
The video completely froze.
* What outcome did you expect instead?
Here is the relevant content from kern.log:
Jun 10 17:53:55 simon kernel: [71840.100209] nouveau :01:00.0: gr: TRAP ch
11 [003f6ed000 systemd-logind[788
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
>
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
ed.
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/
1 - 100 of 311 matches
Mail list logo
