On Tue, 23 Jul 2024 at 20:06:46 +0100, Simon McVittie wrote:
> I needed this version for a work project, so I did some draft packaging
> where libgallium.so is a new binary package mesa-libgallium,
> which libglx-mesa0, libegl-mesa0 and libgbm1 all depend on.
https://salsa.debian.org/
On Wed, 24 Jul 2024 at 18:35:54 +0800, Bo YU wrote:
> The good news is that llvmpipe support riscv64 with orcjit has been
> merged[0]!
>
> [0]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26018
That's great news. I hope that this can be extended to other problematic
architectures
Source: mesa
Version: 24.1.3-2
Severity: wishlist
Tags: trixie sid patch
A new upstream release candidate is available, 24.2.0~rc1.
This adds a new private library libgallium.so which is a new dependency
for libGLX_mesa.so.0, libEGL_mesa.so.0 and libgbm.so.1, and therefore
is likely to need a
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
> > &
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
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
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,
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/
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:
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
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
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
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:
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:
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
D
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:
(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 McVit
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
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
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
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
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
1 - 100 of 145 matches
Mail list logo
