Bug#1032443: webkit2gtk: Consider building with clang instead to speed up build time
On Mon, Mar 06, 2023 at 04:07:36PM -0500, Jeremy Bícha wrote: > I heard that the time to build webkit2gtk can be noticeably reduced > if we build it with clang. I'm going to start using clang for the 2.45.x branch since it's the recommended compiler to build Skia: https://skia.org/docs/user/build/#supported-and-preferred-compilers The problem is that it doesn't work in some architectures, this is s390x: Source/WTF/wtf/simde/arm/neon.h:8808:11: error: _Float16 is not supported on this target typedef _Float16 simde_float16; ^ Source/WTF/wtf/simde/arm/neon.h:34339:47: error: _Float16 is not supported on this target return simde_vceq_f16(a, simde_vdup_n_f16(SIMDE_FLOAT16_VALUE(0.0))); ^ Source/WTF/wtf/simde/arm/neon.h:8975:38: note: expanded from macro 'SIMDE_FLOAT16_VALUE' #define SIMDE_FLOAT16_VALUE(value) SIMDE_FLOAT16_C(value) ^ Source/WTF/wtf/simde/arm/neon.h:8813:55: note: expanded from macro 'SIMDE_FLOAT16_C' #define SIMDE_FLOAT16_C(value) HEDLEY_STATIC_CAST(_Float16, (value)) ^ So I guess I'll start with amd64 Berto
Bug#1070246: libayatana-appindicator version of Debian package does not match the upstream version
Source: libayatana-appindicator Severity: serious Version: 0.5.92-1 Version: 0.5.93-1 The package of libayatana-appindicator on Debian is not building from the right orig tarball as indicated on the package version. Both package versions on Debian 12 and testing (versions 0.5.92-1 and 0.5.93-1) are actually version 0.5.90 of upstream. $ apt-cache policy libayatana-appindicator3-1 libayatana-appindicator3-1: Installed: 0.5.92-1 Candidate: 0.5.92-1 Version table: *** 0.5.92-1 500 500 http://deb.debian.org/debian bookworm/main amd64 Packages 100 /var/lib/dpkg/status $ zcat /usr/share/doc/libayatana-appindicator3-1/changelog.gz|head Overview of changes in libayatana-appindicator 0.5.90 - Mono bindings: Change namespace from ayatana-appindicator-sharp3 to ayatana-appindicator3-sharp (and similar). - Port to CMake. - Default to GTK+-3.0 as default build flavour. - Add Travis CI configuration. - Add --keep-env option to dbus-test-runner calls. Allows propagating e.g. a build HOME into the DBus test environment. See how on the upstream changelog file it says version "0.5.90" I have triple checked this by comparing the orig.tar.gz tarball from the Debian packages VS the ones at https://github.com/AyatanaIndicators/libayatana-appindicator/tags And the version shipped on Debian (both for 0.5.92-1 and 0.5.93-1) is actually the upstream 0.5.90 version Please fix this Thanks
Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
On Sun, Apr 28, 2024 at 01:02:26PM +0100, Alberto Bertogli wrote:
The problem seems to be that some of the functions that have 64-bit
variants (e.g. pread64, pwrite64) have an assembler name declared for
the regular variant in the header; while other platforms don't do that
and have the two functions declared separately.
https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html
For example, this is the declaration of pread and pwrite in a
post-preprocessed file, diff between x86_64 (without the bug, '-') and
armel (with the bug, '+'):
```
@@ -1068,18 +,14 @@
extern ssize_t write (int __fd, const void *__buf, size_t __n)
__attribute__ ((__access__ (__read_only__, 2, 3)));
-# 389 "/usr/include/unistd.h" 3 4
-extern ssize_t pread (int __fd, void *__buf, size_t __nbytes,
-__off_t __offset)
-__attribute__ ((__access__ (__write_only__, 2, 3)));
-
-
+# 404 "/usr/include/unistd.h" 3 4
+extern ssize_t pread (int __fd, void *__buf, size_t __nbytes, __off64_t __offset) __asm__
("" "pread64")
+__attribute__ ((__access__ (__write_only__, 2, 3)));
+extern ssize_t pwrite (int __fd, const void *__buf, size_t __nbytes, __off64_t __offset) __asm__
("" "pwrite64")
-extern ssize_t pwrite (int __fd, const void *__buf, size_t __n,
- __off_t __offset)
__attribute__ ((__access__ (__read_only__, 2, 3)));
# 422 "/usr/include/unistd.h" 3 4
extern ssize_t pread64 (int __fd, void *__buf, size_t __nbytes,
```
That's why it's the assembler (and not linking) stage that's
complaining, because that means both functions end up named as the
64-bit variant. This can be seen in the assembly file. Continuing to
use pread/pread64 as an example, there is no definition for pread(),
only pread64() twice: once for pread and one for pread64.
It's tricky to support this in a generic way, because it's difficult
to detect this is even happening, as the assembler name operates at a
compiler level so we can't just undo it.
More things that make this interesting.
This program:
```
#include
#include
#include
int main() {
printf("pread: %p\n", pread);
printf("pread64: %p\n", pread64);
printf("pread64 is pread: %b\n", pread == pread64);
void *lib = dlopen(NULL, RTLD_NOW);
void *l_pread = dlsym(lib, "pread");
void *l_pread64 = dlsym(lib, "pread64");
printf("l_pread: %p\n", l_pread);
printf("l_pread64: %p\n", l_pread64);
printf("l_pread64 is l_pread: %b\n", l_pread == l_pread64);
}
```
Built with:
cc -save-temps=obj -D_XOPEN_SOURCE=600 -D_LARGEFILE64_SOURCE=1 -std=c99
-Wall demo.c
Prints this on x86_64 Debian testing (which does not show this bug):
```
pread: 0x7fc1970f0c10
pread64: 0x7fc1970f0c10
pread64 is pread: 1
l_pread: 0x7fc1970f0c10
l_pread64: 0x7fc1970f0c10
l_pread64 is l_pread: 1
```
And prints this on the armel chroot:
```
pread: 0xf7da6a90
pread64: 0xf7da6a90
pread64 is pread: 1
l_pread: 0xf7da68f8
l_pread64: 0xf7da6a90
l_pread64 is l_pread: 0
```
So on x86_64 both pread() and pread64() are the same function, yet the
headers allow us to declare them individually.
But on armel, even though there is a separate implementation of pread()
on libc, the headers prevent us from declaring them separately (because
of the asm name declaration in unistd.h).
Just putting this here in case it helps someone else debug a similar
problem in the future.
I'm still trying to find a reasonable workaround.
Thanks,
Alberto
Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
On Sat, Apr 20, 2024 at 10:30:20AM +0100, Alberto Bertogli wrote:
On Sat, Apr 20, 2024 at 12:00:00AM +0200, Santiago Vila wrote:
I can't offer ssh access either (for now), but I've checked and
this error may be reproduced easily on an arm64 machine using an
armel chroot.
Oohhh this is good to know, I didn't know that was a viable option.
Thank you for the suggestion!
I will try to reproduce it this way, I'll let you know how it goes.
I managed to reproduce this the way you suggested, on a Hetzner VM and
an armel chroot.
The problem seems to be that some of the functions that have 64-bit
variants (e.g. pread64, pwrite64) have an assembler name declared for
the regular variant in the header; while other platforms don't do that
and have the two functions declared separately.
https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html
For example, this is the declaration of pread and pwrite in a
post-preprocessed file, diff between x86_64 (without the bug, '-') and
armel (with the bug, '+'):
```
@@ -1068,18 +,14 @@
extern ssize_t write (int __fd, const void *__buf, size_t __n)
__attribute__ ((__access__ (__read_only__, 2, 3)));
-# 389 "/usr/include/unistd.h" 3 4
-extern ssize_t pread (int __fd, void *__buf, size_t __nbytes,
-__off_t __offset)
-__attribute__ ((__access__ (__write_only__, 2, 3)));
-
-
+# 404 "/usr/include/unistd.h" 3 4
+extern ssize_t pread (int __fd, void *__buf, size_t __nbytes, __off64_t __offset) __asm__
("" "pread64")
+__attribute__ ((__access__ (__write_only__, 2, 3)));
+extern ssize_t pwrite (int __fd, const void *__buf, size_t __nbytes, __off64_t __offset) __asm__
("" "pwrite64")
-extern ssize_t pwrite (int __fd, const void *__buf, size_t __n,
- __off_t __offset)
__attribute__ ((__access__ (__read_only__, 2, 3)));
# 422 "/usr/include/unistd.h" 3 4
extern ssize_t pread64 (int __fd, void *__buf, size_t __nbytes,
```
That's why it's the assembler (and not linking) stage that's
complaining, because that means both functions end up named as the
64-bit variant. This can be seen in the assembly file. Continuing to use
pread/pread64 as an example, there is no definition for pread(), only
pread64() twice: once for pread and one for pread64.
It's tricky to support this in a generic way, because it's difficult to
detect this is even happening, as the assembler name operates at a
compiler level so we can't just undo it.
I'll keep trying to find a viable workaround for this.
Thanks,
Alberto
Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
On Sat, Apr 20, 2024 at 12:00:00AM +0200, Santiago Vila wrote:
El 25/3/24 a las 20:12, Chris Lamb escribió:
Alberto Bertogli wrote:
If you know of a functional official image that I can use to try to
reproduce the problem, or recently-tested steps I can follow to get
a working qemu install, please let me know.
Alas, I can't actually be helpful here. There are no official images
as far as I know… and somewhat annoyingly I (ie. a Debian Developer)
actually have access to some machines set aside for this purpose. I
call this "annoying" because I naturally can't then give you direct
SSH access transitively — but I can proxy ideas, of course.
Hi.
I can't offer ssh access either (for now), but I've checked and
this error may be reproduced easily on an arm64 machine using an
armel chroot.
Oohhh this is good to know, I didn't know that was a viable option.
Thank you for the suggestion!
I will try to reproduce it this way, I'll let you know how it goes.
Thank you!
Alberto
Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
On Mon, Mar 25, 2024 at 07:12:24PM +, Chris Lamb wrote: Alberto Bertogli wrote: If you know of a functional official image that I can use to try to reproduce the problem, or recently-tested steps I can follow to get a working qemu install, please let me know. Alas, I can't actually be helpful here. There are no official images as far as I know… and somewhat annoyingly I (ie. a Debian Developer) actually have access to some machines set aside for this purpose. I call this "annoying" because I naturally can't then give you direct SSH access transitively — but I can proxy ideas, of course. I totally understand the access part, that's very reasonable on Debian's part. But unfortunately, if I can't even run a local VM to try to reproduce the problem, it's too limiting for me. Especially considering the kind of issues libfiu often runs into, which tend to be a bit on the esoteric side :) Hm, googling the actual error message a little, I think this might be a bigger issue... or perhaps more accurately, at least one that has potentially been also solved elsewhere: * Same think in lightdm: <https://bugs.debian.org/1067561> * Some kind of "_FILE_OFFSET_BITS"-related patch for v4l-utils <https://www.spinics.net/lists/linux-media/msg230147.html> Thank you for looking at this! I think they could be similar; in particular the second one. Maybe there's something like `#define pread pread64` in the architecture's headers that is triggering these errors? Does this spark anything worth trying? :-) Maybe seeing the preprocessor output and the actual (temporary) file getting the complaints could be useful in figuring out what's going on. That said, even if we find what the problem is, we may keep finding other issues in the future. If I'm not able to have a VM for this platform where I can try to reproduce problems, I'm not sure it's viable to support the package on it :( Thanks! Alberto
Bug#1037139: gst-plugins-bad1.0: Please switch gstreamer1.0-wpe to the new 2.0 WPE API
On Tue, Jun 06, 2023 at 11:42:57AM +0200, Alberto Garcia wrote: > The wpewebkit-2.0 packages have already been uploaded to experimental. And now they are in unstable, you can finally upload gstreamer1.0-wpe. Thanks, Berto
Bug#1068024: revert to version that does not contain changes by bad actor
On Sun, Mar 31, 2024 at 01:16:07AM +0100, Christoph Anton Mitterer wrote: > The last one, still from Lasse Collin seems to be 5.4.1: > https://git.tukaani.org/?p=xz.git;a=tag;h=f52502e78bf84f516a739e8d8a1357f27eeea75f There are commits from Jia before that, and some that are authored by Lasse but thank Jia for the contribution (the oldest one is 20e7a33e). The most recent release that does not contain any of that seems to be v5.3.2alpha. Berto
Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
On Sun, Mar 24, 2024 at 06:00:51PM +, Chris Lamb wrote: Alberto Bertogli wrote: I'll try to get a debian install to boot for armhf, but it'll take me a bit because it's not straightforward (to put it mildly :). Oh, yeah. :/ Perhaps qemu might be better option here. There might even be pre-built disk images flying around. Sorry, yes that's what I meant! To install it under qemu! Unfortunately, I haven't been able to get it to work. I managed to get bookworm installed, and then extracted the kernel+initrd from inside the virtual disk (as apparently that's needed), but the kernel won't boot due to: `Unhandled fault: synchronous abort (translation table walk)`. At this point I'm not really keen on debugging whatever that armhf kernel issue is :( If you know of a functional official image that I can use to try to reproduce the problem, or recently-tested steps I can follow to get a working qemu install, please let me know. Thanks, Alberto
Bug#1067643: webkit2gtk: please use architecture whitelist for libseccomp-dev B-D
On Sun, Mar 24, 2024 at 10:49:37PM +, Thorsten Glaser wrote: > Please use libseccomp-dev B-D only on architectures where it > actually exists (i.e. is not in state uncompiled). Those would be: all of the official ones plus hppa, ppc64 and x32. I can do that. Berto
Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
On Mon, Mar 18, 2024 at 12:29:40PM +, Chris Lamb wrote:
Dear Alberto,
Hi!
Hope this finds you well. Any quick/immediate ideas on what might be
behind this build failure? Note that this is on ARM architectures
rather than amd64 — I often misread and conflate them at speed. :) Oh,
and I can't reproduce this on amd64 locally, at least, so I don't think
it is, say, due to some *general* update to the GLIBC build toolchain.
Nothing obvious.
It's a bit strange because the "symbol X already defined" errors most
likely come from the assembler when building the individual files, not
from linking stage.
While it's impossible to be 100% sure because of the parallel build and
the lack of command-output correlation in the logs, everything points to
that being the case.
I'll try to get a debian install to boot for armhf, but it'll take me a
bit because it's not straightforward (to put it mildly :).
How urgent/important is this issue?
Thanks,
Alberto
- Original message -
From: Sebastian Ramacher
To: Debian Bug Tracking System
Subject: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error:
symbol `open64' is already defined
Date: Friday, 15 March 2024 6:50 PM
Source: libfiu
Version: 1.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org
https://buildd.debian.org/status/fetch.php?pkg=libfiu=armhf=1.2-2=1710292712=0
cc -D_XOPEN_SOURCE=600 -fPIC -DFIU_ENABLE=1 -D_LARGEFILE64_SOURCE=1 -I. -I../../libfiu/ -g
-O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=.
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2
-Wl,-z,relro -Wl,-z,now -D_GNU_SOURCE -c codegen.c -o codegen.o
/tmp/cc54dEva.s: Assembler messages:
/tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
/tmp/cchEoHpC.s: Assembler messages:
/tmp/cchEoHpC.s:474: Error: symbol `mmap64' is already defined
make[4]: *** [Makefile:67: modules/posix.mm.mod.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: *** [Makefile:67: modules/posix.custom.o] Error 1
/tmp/cct4HXD3.s: Assembler messages:
/tmp/cct4HXD3.s:1810: Error: symbol `pread64' is already defined
/tmp/cct4HXD3.s:3995: Error: symbol `pwrite64' is already defined
/tmp/cct4HXD3.s:5803: Error: symbol `truncate64' is already defined
/tmp/cct4HXD3.s:6480: Error: symbol `ftruncate64' is already defined
/tmp/ccInAMjZ.s: Assembler messages:
/tmp/ccInAMjZ.s:437: Error: symbol `fopen64' is already defined
make[4]: *** [Makefile:67: modules/posix.io.mod.o] Error 1
/tmp/ccInAMjZ.s:1099: Error: symbol `freopen64' is already defined
/tmp/ccInAMjZ.s:3393: Error: symbol `tmpfile64' is already defined
/tmp/ccInAMjZ.s:5973: Error: symbol `ftello64' is already defined
/tmp/ccInAMjZ.s:7007: Error: symbol `fseeko64' is already defined
/tmp/ccInAMjZ.s:7699: Error: symbol `fsetpos64' is already defined
make[4]: *** [Makefile:67: modules/posix.stdio.mod.o] Error 1
Alberto
Bug#1037139: gst-plugins-bad1.0: Please switch gstreamer1.0-wpe to the new 2.0 WPE API
On Tue, Mar 05, 2024 at 12:58:51PM +0100, Alberto Garcia wrote: > > > gst-plugins-bad1.0 is buildable now. I am ready to do this mini > > > transition when you are, except that I see wpewebkit is on the > > > time_t transition list so we should let that transition complete > > > first. > > > > Yes, let's do that, thanks. > > libwpewebkit-2.0-dev is now in experimental in case you want to give > it a try. I'll upload it to unstable as soon as I verify that it > builds in all architectures and the time_t transition is finished. wpewebkit 2.44.0 has just been released, I confirmed that both gstreamer1.0-wpe and cog build and work fine with it. The armel and armhf builds are still missing for a lot of packages, and it's been a while already. So I wonder if I should go forward and upload the 2.0 API packages to unstable. I'm ready to do it so I'll wait for your confirmation. Berto
Bug#1066191: libapache2-mod-security2: when building an apache2 docker image with sid packages for armhf the build fails
Hi, as you already mention, the t64 transition is taking place right now. I'm quite sure this will be solved in some days/weeks. On Wed, Mar 13, 2024 at 12:39:11PM +0100, logo wrote: > Package: libapache2-mod-security2 > Version: 2.9.7-1+b1 > Severity: important > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > time_64 migration >* What exactly did you do (or not do) that was effective (or > ineffective)? > Fails to build an Dockerfile with the following command: > > #MODSECURITY_VERSIONi=2.9.7-1+b1 > RUN set -x && apt-get update \ >&& apt-get -t sid install -o APT::Immediate-Configure=false -y > libapache2-mod-security2=$MODSECURITY_VERSION > >* What was the outcome of this action? > #10 0.187 Reading package lists... > #10 5.903 Building dependency tree... > #10 6.837 Reading state information... > #10 7.275 Some packages could not be installed. This may mean that you have > #10 7.275 requested an impossible situation or if you are using the unstable > #10 7.275 distribution that some required packages have not yet been created > #10 7.275 or been moved out of Incoming. > #10 7.275 The following information may help to resolve the situation: > #10 7.275 > #10 7.276 The following packages have unmet dependencies: > #10 7.690 libdb5.3t64 : Breaks: libdb5.3 (< 5.3.28+dfsg2-5) but > 5.3.28+dfsg2-1 is to be installed > #10 7.690 libgdbm6t64 : Breaks: libgdbm6 (< 1.23-5.1) but 1.23-5+b1 is to be > installed > #10 7.690 libgnutls30t64 : Breaks: libgnutls30 (< 3.8.3-1.1) but 3.8.3-1 is > to be installed > #10 7.690 libhogweed6t64 : Breaks: libhogweed6 (< 3.9.1-2.2) but 3.8.1-2 is > to be installed > #10 7.691 libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.2) but 3.9.1-2+b1 is > to be installed > #10 7.693 libssl3t64 : Breaks: libssl3 (< 3.1.5-1.1) but 3.1.5-1 is to be > installed > #10 7.699 E: Unable to correct problems, you have held broken packages. > >* What outcome did you expect instead? > Installed package > > > -- System Information: > > is not clear, as it is running in docker buildx v0.13.0 with docker buildx > build --platform=linux/arm/v7 on docker 25.0.4 in: > > Debian Release: 12.5 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') > Architecture: arm64 (aarch64) > > Kernel: Linux 6.1.0-18-arm64 (SMP w/4 CPU threads) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > > Base image is debian:bookworm-slim > no other sid packages > > image builds fine for arm64 or amd64 > > I know that the package is currently the same in bookworm but I build on new > releases in sid. > > Please advise. > > Thank You > > Peter -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
Bug#1066411: webkit2gtk: FTBFS: SharedContextMutex.cpp:219:41: error: inlining failed in call to ‘always_inline’ ‘egl::SharedContextMutex* egl::SharedContextMutex::doTryLock() [with Mute
On Thu, Mar 14, 2024 at 11:00:26AM -0400, Jeremy Bícha wrote: > > - Several undefined references at link time. > It is caused by a changed in dpkg in Unstable > > https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration Indeed, we were incorrectly adding that flag to CXXFLAGS. I'm confirming that this fixes everything and I'll upload the new package asap. Thanks! Berto
Bug#1066411: webkit2gtk: FTBFS: SharedContextMutex.cpp:219:41: error: inlining failed in call to ‘always_inline’ ‘egl::SharedContextMutex* egl::SharedContextMutex::doTryLock() [with Mute
Control: retitle -1 webkit2gtk: FTBFS due to several undefined references On Wed, Mar 13, 2024 at 01:05:55PM +0100, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. Thanks, there are two build failures here: - The one you reported (recursive inlining). This one is also affecting wpewebkit (#1066454) but I have a fix for it already. - Several undefined references at link time. This is reported upstream as https://bugs.webkit.org/show_bug.cgi?id=270970 and is still not fixed. I thought these were caused by the new version of gcc in sid but I tried downgrading the packages and the problem is still there. In trixie everything works fine. Since the first problem is already taken care of I'm changing the title of this bug to that of the second problem. Berto
Bug#1037139: gst-plugins-bad1.0: Please switch gstreamer1.0-wpe to the new 2.0 WPE API
On Mon, Feb 12, 2024 at 11:53:00AM +, Alberto Garcia wrote: > > gst-plugins-bad1.0 is buildable now. I am ready to do this mini > > transition when you are, except that I see wpewebkit is on the > > time_t transition list so we should let that transition complete > > first. > > Yes, let's do that, thanks. libwpewebkit-2.0-dev is now in experimental in case you want to give it a try. I'll upload it to unstable as soon as I verify that it builds in all architectures and the time_t transition is finished. Berto
Bug#1063223: wpewebkit: NMU diff for 64-bit time_t transition
On Thu, Feb 29, 2024 at 09:23:38AM +, Steve Langasek wrote: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. Thanks for the patch! I have a question: soon I'll need to start transitioning the WPE packages to a new API (we were blocked by the reverse dependencies) which means libwpewebkit-1.1-0 -> libwpewebkit-2.0-0 Shall I add the 't64' suffix to the new binaries for clarity or is it unnecessary? In principle they won't have a version without 64-bit time_t (unless there's a backport which I'm not planning to do). Berto
Bug#1062012: libwebkit2gtk-4.1-0: Video playback is buggy, particularly after seeking or resuming
On Tue, Jan 30, 2024 at 04:54:16PM -0500, erusan wrote:
> Package: libwebkit2gtk-4.1-0
> Version: 2.42.4-1
> Severity: normal
> X-Debbugs-Cc: eru...@gmail.com
>
> Dear Maintainer,
>
> Video playback is buggy on many (all?) sites, with regular YouTube
> and Odysee use confirming this issue.
Hello, what is the difference between this and #1062009 ? ("Video
streaming sites seem to have all sorts of problems. Odysee.com,
YouTube, others.")
Berto
Bug#1037139: gst-plugins-bad1.0: Please switch gstreamer1.0-wpe to the new 2.0 WPE API
Control: block -1 by 1063223 On Sat, Feb 03, 2024 at 08:33:19AM -0500, Jeremy Bícha wrote: > gst-plugins-bad1.0 is buildable now. I am ready to do this mini > transition when you are, except that I see wpewebkit is on the > time_t transition list so we should let that transition complete > first. Yes, let's do that, thanks. Berto
Bug#1062540: event-dance: NMU diff for 64-bit time_t transition
On Mon, Feb 05, 2024 at 12:08:33PM +, Alberto Garcia wrote: > > To ensure that inconsistent combinations of libraries with their > > reverse-dependencies are never installed together, it is necessary > > to have a library transition, which is most easily done by > > renaming the runtime library package. > If the ABI is broken is it normal that the shared library keeps the > same name ?? (libevd-0.2.so.0 -> libevd-0.2.so.0.0.1) Never mind, this was already answered in debian-devel: https://lists.debian.org/debian-devel/2024/02/msg00074.html The changes look good to me. Berto
Bug#1062540: event-dance: NMU diff for 64-bit time_t transition
On Thu, Feb 01, 2024 at 09:16:08PM +, mwhud...@debian.org wrote: > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary > to have a library transition, which is most easily done by renaming > the runtime library package. If the ABI is broken is it normal that the shared library keeps the same name ?? (libevd-0.2.so.0 -> libevd-0.2.so.0.0.1) Berto
Bug#1061879: webkit2gtk: Incorrect build-dependency on libseccomp-dev for m68k
Control: tags -1 pending On Tue, Jan 30, 2024 at 08:22:48AM +0100, John Paul Adrian Glaubitz wrote: > > Otherwise changing the libseccomp build depencency is not really > > going to solve anything, it only adds additional complexity to the > > build scripts. > > Please just fix the build dependencies and let the rest be my > problem. > > It will eventually be fixed. Ok then :) https://salsa.debian.org/webkit-team/webkit/-/commit/32e21f6d0b4d329c37585d032e6ed5c3bb65d675 Berto
Bug#1061879: webkit2gtk: Incorrect build-dependency on libseccomp-dev for m68k
On Mon, Jan 29, 2024 at 11:57:31PM +0100, John Paul Adrian Glaubitz wrote: > src:webkit2gtk is currently BD-Uninstallable on m68k [1] since > libseccomp is currently not available yet. I guess that the main problem is that webkit2gtk hasn't built in m68k since the 2.36.x branch[1]. Is there anyone with the time and knowledge to make it work again? Otherwise changing the libseccomp build depencency is not really going to solve anything, it only adds additional complexity to the build scripts. [1] https://buildd.debian.org/status/logs.php?pkg=webkit2gtk=m68k Regards, Berto
Bug#1060091: chasquid: v1.11.1 with backported SMTP smuggling fix was released, will this be released in debian stable?
On Fri, Jan 05, 2024 at 09:02:26PM +0100, Matěj Volf wrote:
Package: chasquid
Version: 1.11-2+b2
Severity: normal
Hi all,
you might have heard about the latest SMTP smuggling vulnerability.
Author of chasquid responsed by releasing 1.13 and 1.11.1
(<https://github.com/albertito/chasquid/releases/tag/v1.11.1>) with
the backported fix. From <https://tracker.debian.org/pkg/chasquid>, I
understand that 1.13 was automatically accepted into testing, but I
didn't notice anything happening regarding 1.11.1 (my server is on
Debian stable, which only has 1.11), so I wanted to politely ask if
this could be processed as well.
Thanks for requesting this!
I have very little knowledge about the Debian packaging and release
process, so please correct if I have any major misunderstanding of the
process and what I'm asking is unreasonable.
That's viable, and it was discussed in the debian-go mailing list too:
https://lists.debian.org/debian-go/2023/12/msg00121.html
Unfortunately, I don't have time to work on this due to some unexpected
personal circumstances, and I won't be able to do the 1.11.1 Debian
package for (probably) a few more weeks.
Hopefully someone can do it in the meantime.
Otherwise, a workaround is to build chasquid v1.11.1 locally, and copy
the binary to /usr/lib. It's not pretty, but it should work.
Again, apologies for not being able to fix this in a timely fashion for
Debian this time.
Thanks a lot!
Alberto
Bug#1046037: marked as done (jool: Fails to build source after successful build)
For the record: The problem was that the Makefiles not managed by autotools were missing the "distclean" target. Therefore, dh_auto_clean was falling back to `make clean` (when it actually wanted to run `make distclean`), which skipped the removal of a bunch of files generated by `configure`: - Makefile - config.log - config.status - libtool - src/common/Makefile - src/usr/Makefile - src/usr/argp/Makefile - src/usr/joold/Makefile - src/usr/nat64/Makefile - src/usr/nl/Makefile - src/usr/siit/Makefile - src/usr/util/Makefile And this made dpkg-source think the workspace was damaged. I'm explaining this because Kbuild Makefile samples aren't terribly keen on referencing GNU targets [1] they don't immediately need, so I suspect lots of novice kernel module coders will run into this problem eventually. [1] https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets
Bug#1059560: libwebkit2gtk-4.1-0: Can not add google online account via gnome-controle-center without : export WEBKIT_DISABLE_DMABUF_RENDERER=1
On Thu, Dec 28, 2023 at 03:56:17PM +0100, Maurin Sylvain wrote: > I did libnvidia-egl-gbm1 installation and probed : > > maurin@gimli:~$ unset WEBKIT_DISABLE_DMABUF_RENDERER > maurin@gimli:~$ gnome-control-center [...] > providerKMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied > Failed to create GBM buffer of size 496x346: Permission denied > KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied > Failed to create GBM buffer of size 496x346: Permission denied > KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied > Failed to create GBM buffer of size 496x346: Permission denied > Failed to create EGL images for DMABufs with file descriptors -1, -1 > and -1 Can you run /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/MiniBrowser and see if websites work normally? If not, can you open webkit://gpu with the MiniBrowser and send me the output? Thanks, Berto
Bug#1059560: libwebkit2gtk-4.1-0: Can not add google online account via gnome-controle-center without : export WEBKIT_DISABLE_DMABUF_RENDERER=1
Control: tags -1 moreinfo On Thu, Dec 28, 2023 at 12:40:06PM +0100, Sylvain Maurin wrote: > After a fresh install on a DELL Precision 3620 with i915 and Quadro > K420 display adapters (used with Nvidia legacy driver v470), I > wished to add a Google account via the 'Online Accounts' [...] > DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied > Failed to create GBM buffer of size 496x346: Permission denied Can you install libnvidia-egl-gbm1 and try again ? Berto
Bug#1041311: marked as done (jool: please drop superfluous B-D: dkms)
Sorry, Andreas. As mentioned in the other bug, I struggle to notice these bug reports among the Debian notifications. Removing dkms from Build-Depends results in a Lintian error: E: jool source: missing-build-dependency-for-dh_-command dh_dkms => dkms N: E: missing-build-dependency-for-dh_-command N: N: The source package appears to be using a dh_ command but doesn't build N: depend on the package that actually provides it. If it uses it, it N: must build depend on it. N: N: Severity: error N: N: Check: debhelper I have not deleted dh-sequence-dkms from the Build-Depends. Any advice? On Tue, Jul 18, 2023 at 11:11 AM Debian Bug Tracking System wrote: > > Your message dated Tue, 18 Jul 2023 17:06:11 + > with message-id > and subject line Bug#1041311: fixed in netplan.io 0.106.1-6 > has caused the Debian Bug report #1041311, > regarding jool: please drop superfluous B-D: dkms > to be marked as done. > > This means that you claim that the problem has been dealt with. > If this is not the case it is now your responsibility to reopen the > Bug report if necessary, and/or fix the problem forthwith. > > (NB: If you are a system administrator and have no idea what this > message is talking about, this may indicate a serious mail system > misconfiguration somewhere. Please contact ow...@bugs.debian.org > immediately.) > > > -- > 1041311: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041311 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > > -- Forwarded message -- > From: Andreas Beckmann > To: Debian Bug Tracking System > Cc: > Bcc: > Date: Mon, 17 Jul 2023 12:17:57 +0200 > Subject: jool: please drop superfluous B-D: dkms > Source: jool > Version: 4.1.10-1 > Severity: minor > > Hi, > > src:jool has a superfluous B-D on dkms. Everything that is needed comes > with dh-sequence-dkms. > > > Andreas > > > > -- Forwarded message -- > From: Debian FTP Masters > To: 1041311-cl...@bugs.debian.org > Cc: > Bcc: > Date: Tue, 18 Jul 2023 17:06:11 + > Subject: Bug#1041311: fixed in netplan.io 0.106.1-6 > Source: netplan.io > Source-Version: 0.106.1-6 > Done: Lukas Märdian > > We believe that the bug you reported is fixed in the latest version of > netplan.io, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 1041...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Lukas Märdian (supplier of updated netplan.io package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Format: 1.8 > Date: Tue, 18 Jul 2023 17:35:49 +0200 > Source: netplan.io > Built-For-Profiles: noudeb > Architecture: source > Version: 0.106.1-6 > Distribution: unstable > Urgency: medium > Maintainer: Debian Netplan Maintainers > Changed-By: Lukas Märdian > Closes: 1041311 > Changes: > netplan.io (0.106.1-6) unstable; urgency=medium > . >* Fix ethernets,vlans,scenarios autopkgtests on systemd 254, Closes: > #1041311 > Checksums-Sha1: > 5866e1cafec487762ff29d221293b6b174bbd065 2747 netplan.io_0.106.1-6.dsc > 60732dc8da053041526f01d6883a5bd3c431510b 29552 > netplan.io_0.106.1-6.debian.tar.xz > ec27beebf6043915662c115e9d289f12a9a306bf 12131 > netplan.io_0.106.1-6_source.buildinfo > Checksums-Sha256: > 84e233657f8b23136e8a3c3b41dce79783c6a1145b4169f4da5b941f78385016 2747 > netplan.io_0.106.1-6.dsc > a82a2fc8194abbb47d1958b6d7fb86a6b6daee45fa126f096d47ef93de5d0ee5 29552 > netplan.io_0.106.1-6.debian.tar.xz > 4323c40f0ee19bb4746466422a0afb8632f8bf2df745cc0a5fa05d58d4389f46 12131 > netplan.io_0.106.1-6_source.buildinfo > Files: > 2989b821aa41a6ca3f2c6512e5c0a61f 2747 net optional netplan.io_0.106.1-6.dsc > a8644d161b561b112cdda3cc1155a6ca 29552 net optional > netplan.io_0.106.1-6.debian.tar.xz > c198db04b372c3a6e1765cf496ec7a39 12131 net optional > netplan.io_0.106.1-6_source.buildinfo > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEE496GmCL5m2y8NfJ5v322IrMDrIsFAmS2tysACgkQv322IrMD > rIvJzRAArnu7hzJcVUDQ+pWbZXg08MhfETdpBk2T76ovfj3emymjEnXxHZfHZ9J2 > k0AnNRTlzNKs3Q0MGEI1ZnxAee6QUsG+KUc5UsG0BZZw67QzGkHq+pnAYs+sa5H4 > NTJVJ1WMjRdjrraUZVuyNwpYTM5OtXN2VKAHGQ4mF/25QFyBW2a0NnH1rUspfuJJ > i6Qh2/FXv5vq7im6x6Hn10ziM/N19EnmtsX0z7aJ5MGm5khuQdW+VX7QGzFrc/EO > stZJPdZyoiBXmXIKXm+yQlYY8KRnFngK3FWpu3IhzYBKSz/rjyb3R5SX4cuYTNy6 > zbFJWCZO8ZWrd23hGJ2VF4cd6SpObSAmcbFMYVqM3fdIwAY7KnlXdvamRasfOW5U > gdnNUnXTHYE/rH/eDQy5F3Hg4vdiiDEU08KWVsdlwPC7od+CPY4F8rIY8TK0PDuR > jU7HcrzzC8A5kZAikXwemRwlbQjbZFIxbntZPb+hqFkBz1i/O2H1PAZNypAcvMh4 >
Bug#1057703: Please stop build-depending on mime-support
Sorry; I struggle to notice these bug reports among the Debian notifications. Thank you; I will have this fixed by version 4.1.11, which should be released tomorrow at the latest. On Tue, Dec 12, 2023 at 8:29 AM Charles Plessy wrote: > > Le Thu, Dec 07, 2023 at 08:14:30PM +0900, Charles Plessy a écrit : > > > > Please either drop the build-depend on mime-support or replace it by > > media-types. > > > > If you are busy I can offer to NMU your package. I would like to remove > > mime-support from the archive. > > Dear Alberto, > > unless you object, I intend to upload the fix to DELAYED/8 soon. > > Have a nice day, > > Charles
Bug#1058034: webkit2gtk: 2.43 fails to build on riscv64
On Thu, Dec 21, 2023 at 07:03:31AM -0500, Jeremy Bícha wrote: > > Jeremy, can you give this one a try? > The build is still in progress which seems like a good sign that it > will succeed. > > https://launchpad.net/~jbicha/+archive/ubuntu/arch2/+build/27578344 Ok, I wanted to upload 2.43.3 to experimental today and I decided to include that patch. Berto
Bug#1058034: webkit2gtk: 2.43 fails to build on riscv64
On Thu, Dec 14, 2023 at 05:25:45PM +0100, Alberto Garcia wrote: > Maybe we can try treating the CPU as unknown, as we do with x32: Jeremy, can you give this one a try? Berto Index: webkitgtk/Source/WTF/wtf/PlatformCPU.h === --- webkitgtk.orig/Source/WTF/wtf/PlatformCPU.h +++ webkitgtk/Source/WTF/wtf/PlatformCPU.h @@ -292,14 +292,6 @@ #endif /* ARM */ -/* CPU(RISCV64) - RISC-V 64-bit */ -#ifdefined(__riscv) \ -&& defined(__riscv_xlen) \ -&& (__riscv_xlen == 64) -#define WTF_CPU_RISCV64 1 -#define WTF_CPU_KNOWN 1 -#endif - #if !CPU(KNOWN) #define WTF_CPU_UNKNOWN 1 #endif Index: webkitgtk/Source/cmake/WebKitCommon.cmake === --- webkitgtk.orig/Source/cmake/WebKitCommon.cmake +++ webkitgtk/Source/cmake/WebKitCommon.cmake @@ -122,8 +122,6 @@ if (NOT HAS_RUN_WEBKIT_COMMON) set(WTF_CPU_PPC64 1) elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "ppc64le") set(WTF_CPU_PPC64LE 1) -elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "^riscv64") -set(WTF_CPU_RISCV64 1) elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "^loongarch64") set(WTF_CPU_LOONGARCH64 1) else ()
Bug#1058758: linux-image-6.1.0-16-amd64 breaks middle-button handling with the ThinkPad TrackPoint Keyboard II
Source: linux Version: 6.1.67-1 Severity: normal Tags: patch upstream Hi, the ThinkPad TrackPoint Keyboard II had a long-standing bug due to which middle-button scrolling emulation was broken and was reporting spurious press events. This was fixed in Linux 5.19 (specifically in commit 24401f291dcc) and has been working fine ever since. With the recent update to 6.1.67 in bookworm things are broken again, it seems that commit 46a0a2c96f0f introduced a regression. The author of that patch fixed it 3 days ago with commit 43527a0094c1: https://github.com/torvalds/linux/commit/43527a0094c10dfbf0d5a2e7979395a38de3ff65 More information: https://lore.kernel.org/linux-input/ZXRiiPsBKNasioqH@jekhomev/ https://bbs.archlinux.org/viewtopic.php?pid=2135468#p2135468 Regards, Berto
Bug#1057755: Qt WebEngine Security Support In Stable
On Wed, Dec 13, 2023 at 08:49:55PM -0700, Soren Stoutner wrote: > Currently there is no real security support for Qt WebEngine in > stable, which is an oversight that might surprise many Debian users. > The purpose of this discussion is to figure out the best way to > change that. Hello, I would like to offer my (outsider) perspective as the Debian WebKitGTK / WPE WebKit maintainer. I'm not too familiar with the Qt, KDE or Chromium release cycles, but having that in mind I think that although I welcome the efforts to provide security support to the Qt WebEngine I also share Adrian's concerns that this is probably not going to be an easy task. For reference, in the case of WebKitGTK, and as it was correctly pointed out, Debian didn't provide security support for a long time. We started talking about it ages ago but it took years of work before it finally happened. Off the top of my head: - The project created a policy to support Debian and Ubuntu LTS by not bumping the dependencies: https://docs.webkit.org/Ports/WebKitGTK%20and%20WPE%20WebKit/DependenciesPolicy.html We had the explicit goal to support those distros, I was part of those conversations. This was coordinated with Apple so they e.g. would not start using too recent C++ features that would require us to use a new compiler. In practice WebKitGTK would continue working for a while after the officially supported period (we were still providing security updates for buster during H1 2023). - Strong API / ABI stability. Although we don't have LTS releases any stable WebKitGTK build works with any app linked against an earlier version. If some of the basic dependencies have a major API / ABI break (soup2 -> soup3, gtk3 -> gtk4) we keep supporting the old versions for as long as it's feasible. We currently have three different sets of binary packages from the same sources so older apps can still use the latest WebKitGTK packages. - WebKitGTK and WPE publish security advisories, thanks also to the good relationship that we have with Apple, which allows us to have up-to-date information about the CVEs that affect us. - Before having official security support in Debian we were providing stable updates via backports starting from jessie. It wasn't until buster (3-4 years later) that WebKitGTK got officially supported, thanks also to the good track record of security updates that Ubuntu had due to the great work of Jeremy Bicha. - And even with all that in our favor, keeping WebKitGTK up-to-date and properly supported is not a trivial amount of work, and we could also not avoid having the occasional regression, sometimes our fault (#1035469) and sometimes due to problems in other packages (#1054150). If you still want to give it a go maybe try updating the Qt WebEngine via backports first, although if that requires that the Qt / KDE maintainers stick to a specific LTE branch then you need to coordinate that with them first. One last thing: when you say "When the LTS in stable is no longer supported, security patches can be backported from the current LTS to the one in stable" I think you might be underestimating the complexity of doing that. Web engines are extremely active projects (WebKit has some 50 commits per day, and if I'm reading GitHub's numbers correctly Chromium has 10 times more). Identifying and backporting the security fixes (of which Chromium has a lot) is not a joke. And I think that's all from my side, I hope this was useful. Regards, Berto
Bug#1058034: webkit2gtk: 2.43 fails to build on riscv64
On Tue, Dec 12, 2023 at 10:57:50PM +, Alberto Garcia wrote: > > > > I can do a riscv64 test build in a special Ubuntu PPA if you > > > > want to turn that into a patch. > > > > I built with -DENABLE_JIT=OFF -DENABLE_C_LOOP=ON > > -DENABLE_WEBASSEMBLY=OFF but the build fails. > > https://launchpadlibrarian.net/702273866/buildlog_ubuntu-noble-riscv64.webkit2gtk_2.43.2-1ubuntu0~ppa2_BUILDING.txt.gz > > Oh, crap ... can you add that information to the upstream bug report? Maybe we can try treating the CPU as unknown, as we do with x32: https://salsa.debian.org/webkit-team/webkit/-/blob/debian/2.42.3-1/debian/patches/fix-ftbfs-x32.patch Berto
Bug#1058034: webkit2gtk: 2.43 fails to build on riscv64
On Tue, Dec 12, 2023 at 04:45:07PM -0500, Jeremy Bícha wrote: > > > I can do a riscv64 test build in a special Ubuntu PPA if you want to > > > turn that into a patch. > > I built with -DENABLE_JIT=OFF -DENABLE_C_LOOP=ON > -DENABLE_WEBASSEMBLY=OFF but the build fails. > https://launchpadlibrarian.net/702273866/buildlog_ubuntu-noble-riscv64.webkit2gtk_2.43.2-1ubuntu0~ppa2_BUILDING.txt.gz Oh, crap ... can you add that information to the upstream bug report? Thanks! Berto
Bug#1057967: linux-image-6.1.0-15-amd64 renders my physical bookworm/gnome computer largely unusable
On Mon, Dec 11, 2023 at 02:55:50AM +0100, Kevin Price wrote: > 3. There seems to be no network connectivity. No WiFi icon. "ping > 8.8.8.8" returns IIRC network unreachable. Hi, ThinkPad T14s AMD Gen1 user here, I'm also having lots of problems with this kernel and this seems related. In particular I cannot even shut down the system properly because it hangs when trying to stop Network Manager, I'm attaching some logs. I also noticed this kernel message during boot, it didn't happen with earlier kernels: r8169 :02:00.0 eth0: rtl_ep_ocp_read_cond == 0 (loop: 10, delay: 1). The test build from Salvatore seems to fix the problem for me too. Berto 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne Root Complex [1022:1630] 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne IOMMU [1022:1631] 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge [1022:1632] 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge [1022:1632] 00:02.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge [1022:1634] 00:02.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge [1022:1634] 00:02.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge [1022:1634] 00:02.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge [1022:1634] 00:02.7 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge [1022:1634] 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge [1022:1632] 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus [1022:1635] 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 51) 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e] (rev 51) 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 0 [1022:1448] 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 1 [1022:1449] 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 2 [1022:144a] 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 3 [1022:144b] 00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 4 [1022:144c] 00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 5 [1022:144d] 00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 6 [1022:144e] 00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 7 [1022:144f] 01:00.0 Non-Volatile memory controller [0108]: SK hynix Gold P31/PC711 NVMe Solid State Drive [1c5c:174a] 02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0e) 02:00.1 Serial controller [0700]: Realtek Semiconductor Co., Ltd. RTL8111xP UART #1 [10ec:816a] (rev 0e) 02:00.2 Serial controller [0700]: Realtek Semiconductor Co., Ltd. RTL8111xP UART #2 [10ec:816b] (rev 0e) 02:00.3 IPMI Interface [0c07]: Realtek Semiconductor Co., Ltd. RTL8111xP IPMI interface [10ec:816c] (rev 0e) 02:00.4 USB controller [0c03]: Realtek Semiconductor Co., Ltd. RTL811x EHCI host controller [10ec:816d] (rev 0e) 03:00.0 Network controller [0280]: MEDIATEK Corp. MT7921 802.11ax PCI Express Wireless Network Adapter [14c3:7961] 04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader [10ec:522a] (rev 01) 05:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller [1912:0015] (rev 02) 06:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Renoir [1002:1636] (rev d1) 06:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Renoir Radeon High Definition Audio Controller [1002:1637] 06:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) Platform Security Processor [1022:15df] 06:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne USB 3.1 [1022:1639] 06:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne USB 3.1 [1022:1639] 06:00.5 Multimedia controller [0480]: Advanced Micro Devices, Inc. [AMD] ACP/ACP3X/ACP6x Audio Coprocessor [1022:15e2] (rev 01) 06:00.6 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family 17h/19h HD Audio Controller [1022:15e3] Dec 12 11:37:56 debian systemd[1]: run-user-0.mount: Deactivated successfully. Dec 12 11:37:56 debian systemd[1]: Unmounted run-user-0.mount - /run/user/0. Dec 12 11:37:56 debian systemd[1]: run-user-116-gvfs.mount: Deactivated successfully. Dec 12 11:37:56 debian
Bug#1033482: also here
Control: fixed -1 1.0.128+nmu2+deb12u1 On Thu, Dec 07, 2023 at 10:23:59AM +0100, Paolo Greppi wrote: > Alberto's workaround (sudo apt install -t bookworm-backports > debootstrap) worked for me. This is working fine with the new version of debootstrap in bookworm, i.e version 1.0.128+nmu2+deb12u1 from Debian 12.4 Berto
Bug#1058034: webkit2gtk: 2.43 fails to build on riscv64
On Mon, Dec 11, 2023 at 10:23:36AM -0500, Jeremy Bícha wrote: > > Considering that the upstream bug (265082) has been open for > > a month maybe we can work this around with -DENABLE_JIT=OFF > > -DENABLE_C_LOOP=ON (I haven't tested it). > > I can do a riscv64 test build in a special Ubuntu PPA if you want to > turn that into a patch. Yeah that would be nice, thanks. Berto
Bug#1058034: webkit2gtk: 2.43 fails to build on riscv64
On Mon, Dec 11, 2023 at 08:54:52AM -0500, Jeremy Bícha wrote: > /Source/JavaScriptCore/offlineasm/riscv64.rb:132:in > `riscv64RaiseMismatchedOperands': > Unable to match operands [RegisterID, RegisterID, LabelReference] > (due to LowLevelInterpreter64.asm:258) (LoweringError) > > I have reported this issue to the webkitgtk developers. Considering that the upstream bug (265082) has been open for a month maybe we can work this around with -DENABLE_JIT=OFF -DENABLE_C_LOOP=ON (I haven't tested it). Berto
Bug#1033482: debootstrap fails when invoked with --merged-usr
On Fri, Nov 10, 2023 at 02:50:43PM +0100, Alberto Garcia wrote: > I'm having this problem in bookworm, even with --no-merged-usr: This works fine if I install the package from bookworm-backports (1.0.133~bpo12+1) so the package in stable should be fixed Berto
Bug#1033482: debootstrap fails when invoked with --merged-usr
On Sat, Mar 25, 2023 at 10:05:54PM +0100, David Heidelberg wrote: > W: Failure while unpacking required packages. This will be attempted up to > five times. > W: See /lava-files/rootfs-amd64/debootstrap/debootstrap.log for details > (possibly the package /var/cache/apt/archives/usr-is-merged_35_all.deb is at > fault) > > Whole log: https://gitlab.freedesktop.org/okias/mesa/-/jobs/38725690 > > These errors can be prevented when using --no-merged-usr. I'm having this problem in bookworm, even with --no-merged-usr: $ debootstrap --no-merged-usr sid /var/tmp/chroot/ [...] I: Unpacking tzdata... I: Unpacking usr-is-merged... I: Unpacking zlib1g:amd64... W: Failure while unpacking required packages. This will be attempted up to five times. W: See /var/tmp/chroot/debootstrap/debootstrap.log for details (possibly the package /var/cache/apt/archives/usr-is-merged_38_all.deb is at fault) Because of this I cannot use pbuilder. Berto
Bug#1055446: libervia-backend: requires python3-txdbus
Package: libervia-backend Version: 0.9.0~hg3993-4 Severity: normal X-Debbugs-Cc: alua...@udc.es Dear Maintainer, When starting libervia-backend, I get this error, and the command stops: > 2023-11-06T12:55:38+0100 Can't import bridge 'dbus': No module named 'txdbus' > 2023-11-06T12:55:38+0100 /!\ Can't find bridge module of name dbus Installing python3-txdbus fixes the problem, that's why I think this package should be set as a dependency. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libervia-backend depends on: ii python3 3.11.4-5+b1 ii python3-aiosqlite 0.17.0-2 ii python3-alembic 1.8.1-2 ii python3-babel 2.10.3-2 ii python3-dateutil 2.8.2-3 ii python3-dbus 1.3.2-5 ii python3-idna 3.3-2 ii python3-lxml 4.9.3-1 ii python3-mutagen 1.46.0-2 ii python3-openssl 23.2.0-1 ii python3-pil 10.0.0-1 ii python3-potr 1.0.2-5 ii python3-pycryptodome 3.11.0+dfsg1-4 ii python3-service-identity 23.1.0-1 ii python3-shortuuid 1.0.11-2 ii python3-sqlalchemy1.4.47+ds1-1 ii python3-treq 22.2.0-0.1 ii python3-twisted 22.4.0-4 ii python3-wokkel18.0.0-4 ii python3-xdg 0.28-2 ii python3-xmlschema 1.10.0-6 ii python3-zope.interface5.5.2-1+b1 Versions of packages libervia-backend recommends: ii dbus-x11 1.14.10-3 ii libervia-tui 0.9.0~hg3993-4 ii python3-cairosvg 2.7.1-1 ii python3-html2text 2020.1.16-2 ii python3-markdown 3.4.4-1 ii python3-miniupnpc 2.2.5-1 ii python3-netifaces 0.11.0-2+b1 ii python3-oldmemo1.0.3-2 ii python3-omemo 1.0.2-3 ii python3-twomemo1.0.3-2 libervia-backend suggests no packages. -- no debconf information
Bug#1055445: libervia-backend: manual page says it is autorun, but it is not.
Package: libervia-backend Version: 0.9.0~hg3993-4 Severity: minor X-Debbugs-Cc: alua...@udc.es Dear Maintainer, The manual page of libervia-backend says > note that you don't have to run sat manually, it will be started > whenever you launch one of the frontends. However, when trying to run libervia-tui, one is greeted with > Can't connect to SàT backend, are you sure it's launched ? -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libervia-backend depends on: ii python3 3.11.4-5+b1 ii python3-aiosqlite 0.17.0-2 ii python3-alembic 1.8.1-2 ii python3-babel 2.10.3-2 ii python3-dateutil 2.8.2-3 ii python3-dbus 1.3.2-5 ii python3-idna 3.3-2 ii python3-lxml 4.9.3-1 ii python3-mutagen 1.46.0-2 ii python3-openssl 23.2.0-1 ii python3-pil 10.0.0-1 ii python3-potr 1.0.2-5 ii python3-pycryptodome 3.11.0+dfsg1-4 ii python3-service-identity 23.1.0-1 ii python3-shortuuid 1.0.11-2 ii python3-sqlalchemy1.4.47+ds1-1 ii python3-treq 22.2.0-0.1 ii python3-twisted 22.4.0-4 ii python3-wokkel18.0.0-4 ii python3-xdg 0.28-2 ii python3-xmlschema 1.10.0-6 ii python3-zope.interface5.5.2-1+b1 Versions of packages libervia-backend recommends: ii dbus-x11 1.14.10-3 ii libervia-tui 0.9.0~hg3993-4 ii python3-cairosvg 2.7.1-1 ii python3-html2text 2020.1.16-2 ii python3-markdown 3.4.4-1 ii python3-miniupnpc 2.2.5-1 ii python3-netifaces 0.11.0-2+b1 ii python3-oldmemo1.0.3-2 ii python3-omemo 1.0.2-3 ii python3-twomemo1.0.3-2 libervia-backend suggests no packages. -- no debconf information
Bug#1054777: Fwd: Bug#1054777: libfiu: FTBFS: dh_auto_test: error: make -j8 test V=1 LC_ALL=C returned exit code 2
On Sun, Oct 29, 2023 at 02:00:32PM +, Chris Lamb wrote:
Dear Alberto,
I think this is likely a problem I already fixed back in February in
commit 5dcc6d4.
Ah, cherry-picking that commit fixed it for me. I've gone ahead and
uploaded that to Debian in order to close this RC bug, but please do
feel free to also release a libfiu v1.2 as well.
That would have the added advantage of "clearing out" the other patch
we had to apply re. Link-Time Optimisation.
Great!
I've just released libfiu 1.2 then :)
Just in case, one of the possibly-impacting patches is updating to
setuptools, that may need some adjustments in the build-depends:
https://blitiri.com.ar/git/r/libfiu/c/88b961aad6b1fcbc0e1decbf34a0bc9510600988/
Hopefully with that you can clear the other patch!
Thank you!
Alberto
Bug#1054777: Fwd: Bug#1054777: libfiu: FTBFS: dh_auto_test: error: make -j8 test V=1 LC_ALL=C returned exit code 2
On Sat, Oct 28, 2023 at 09:58:14AM +0100, Chris Lamb wrote: Hey Alberto, Hope all is well with you. Just wondering if you received the below re. a recently-filed bug report against libfiu. I can reproduce it locally if that helps. I got it, but I appreciate you forwarding it explicitly anyway just in case, and the confirmation of a reproduction! ./wrap-python 3 ./test-basic.py Can't find python3 bindings, run make python3 make[3]: *** [Makefile:96: py-run-test-basic] Error 1 Looking at this, I don find any issues with the Makefile dependency chain itself. I think this is likely a problem I already fixed back in February in commit 5dcc6d4. https://blitiri.com.ar/git/r/libfiu/c/5dcc6d449dc86d4ba9abc99ac52fd5798e573738/ There have been a few commits since v1.1, I think a v1.2 is probably overdue at this point in any case. Chris, do you want to confirm that patch fixes the issue in the Debian build environment? And if so I can just make a 1.2 including it. Do you think that would be the most practical course of action here? Thank you! Alberto
Bug#1054150: surf: no longer display web pages after webkitgtk upgrades
On Wed, Oct 18, 2023 at 05:06:16PM +0900, Dominique Martinet wrote: > After upgrading my system to the latest security updates surf no > longer displays anything. I had a look at this, the problem is caused by Surf's AppArmor configuration. I can make it run on my computer with something like this added to /etc/apparmor.d/usr.bin.surf, but your mileage may vary: /sys/devices/virtual/dmi/id/chassis_type r, /etc/glvnd/egl_vendor.d/ r, /etc/glvnd/egl_vendor.d/** r, /usr/share/glvnd/egl_vendor.d/ r, /usr/share/glvnd/egl_vendor.d/** r, /usr/share/libdrm/* r, I think that Surf's AppArmor profile is just too restrictive for a program that has so many dependencies. Berto
Bug#1054150: surf: no longer display web pages after webkitgtk upgrades
On Wed, Oct 18, 2023 at 05:06:16PM +0900, Dominique Martinet wrote: > For bullseye, this package upgrade reliably triggers the issue, and > installing old packages back makes surf work again: > Unpacking libwebkit2gtk-4.0-37:amd64 (2.42.1-1~deb11u1) over > (2.40.5-1~deb11u1) ... > Unpacking libjavascriptcoregtk-4.0-18:amd64 (2.42.1-1~deb11u1) over > (2.40.5-1~deb11u1) ... I checked and every other WebKitGTK browser that I tested in bullseye works fine (epiphany, luakit, midori, giara, and WebKitGTK's own MiniBrowser), so I suspect that there's something odd that Surf is doing. Until this is investigated I would just run it with WEBKIT_DISABLE_COMPOSITING_MODE=1. Surf could also be patched downstream in Debian to force this, it also needs to force the x11 backend because its Wayland support is broken (see #1012739). Berto
Bug#1054103: Bug#1054111: liferea crashes (SIGABRT) in libwebkit2gtk/libepoxy
On Thu, Oct 19, 2023 at 09:58:35PM +0200, Christian Henz wrote: > > To work around the problem users can disable compositing mode: > > > > export WEBKIT_DISABLE_COMPOSITING_MODE=1 > > I can confirm this works (WEBKIT_DISABLE_DMABUF_RENDERER=1 does as well). Thanks for testing this. I just uploaded webkit2gtk 2.42.1-1~deb11u2, it should fix this problem. Regards, Berto
Bug#1054101: webkit2gtk: No provider of eglCreateImage found. Requires one of: EGL 15, yelp can't start
On Fri, Oct 20, 2023 at 11:47:40AM +0800, xiao sheng wen wrote: > > https://people.debian.org/~berto/webkit/ > I download and installed these packages: > [...] > When I run yelp or /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/MiniBrowser, > I get the crash. Ok, thanks for testing it. I just uploaded a new version of webkit2gtk to debian-security, you'll see it soon when you do a normal apt update + upgrade. It should fix the problem, tell me if it doesn't. Berto
Bug#1054254: Regression: Securty fix in webkit2gtk breaks gp-saml-gui
On Thu, Oct 19, 2023 at 02:07:12PM -0600, Jaimos Skriletz wrote: > KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied > Failed to create GBM buffer of size 500x500: Permission denied > Failed to create EGL images for DMABufs with file descriptors -1, -1 and -1 > > I am using the nvidia non-free driver, which might be related due to the KMS > errors. Do you have the libnvidia-egl-gbm1 package installed, and if not can you install it and try again? Berto
Bug#1054111: liferea crashes (SIGABRT) in libwebkit2gtk/libepoxy
On Thu, Oct 19, 2023 at 11:38:47AM +0200, Paul Gevers wrote: > Dear webkit2gtk maintainers, > > Can you please help to see if this bug report (quoted below) is > caused by the security update in oldstable/bullseye? And if so, what > can be done about it (on your side or on the side of liferea). I discussed this with upstream and we're going to disable the WebKit DMABuf renderer by default in bullseye, I'm preparing a new security update. Liferea does not need to do anything. See also #1054101 (I guess both bugs can be merged?) Berto
Bug#1054101: webkit2gtk: No provider of eglCreateImage found. Requires one of: EGL 15, yelp can't start
On Thu, Oct 19, 2023 at 07:58:04PM +0800, xiao sheng wen wrote: > I download and installed yelp-dbgsym_3.38.3-1_amd64.deb > > $ gdb yelp Thanks, that backtrace is useful. We have a patch that might help with this but I cannot test it myself because I cannot reproduce the problem. The patch is this one: https://commits.webkit.org/267503@main I rebuilt WebKitGTK 2.42.1-1~deb11u1 with this patch applied and I put the binaries here so people can test them: https://people.debian.org/~berto/webkit/ The integrity of the files can be checked using the SHA256 sums, which are signed with my public key. If you would be so kind to test these packages and tell me if they help it would be great. (if you prefer not to install out-of-repo packages I understand it) Thanks, Berto
Bug#1054111: liferea crashes (SIGABRT) in libwebkit2gtk/libepoxy
On Thu, Oct 19, 2023 at 11:38:47AM +0200, Paul Gevers wrote: > Can you please help to see if this bug report (quoted below) is > caused by the security update in oldstable/bullseye? And if so, what > can be done about it (on your side or on the side of liferea). We are currently investigating the problem, would it be possible to get a stack trace with symbols? It should work with debuginfod export DEBUGINFOD_URLS="https://debuginfod.debian.net; Another question: is libgles2 installed, and if not can you try installing it and see if the problem disappears? To work around the problem users can disable compositing mode: export WEBKIT_DISABLE_COMPOSITING_MODE=1 Berto
Bug#1054111: liferea crashes (SIGABRT) in libwebkit2gtk/libepoxy
On Thu, Oct 19, 2023 at 11:49:39AM +0200, Paul Gevers wrote: > I've just read bug #1052055 [1]. > > Do you have a nvidia chipset and do you have libnvidia-egl-gbm1 > installed (from contrib)? I'm not sure that this is the problem here but yeah it's also good to check it, thanks. Berto
Bug#1054101: webkit2gtk: No provider of eglCreateImage found. Requires one of: EGL 15, yelp can't start
On Thu, Oct 19, 2023 at 11:03:53AM +0800, xiao sheng wen wrote: > > Also, do you think you can obtain a stack trace of that abort? > > strace /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/MiniBrowser webkit://gpu > 2>&1 |tee strace-webkit-egl.error.log Thanks, that's useful, although I meant with gdb: $ gdb yelp [ let it crash ] Program received signal SIGABRT, Aborted. (gdb) bt Berto
Bug#1054101: webkit2gtk: No provider of eglCreateImage found. Requires one of: EGL 15, yelp can't start
On Wed, Oct 18, 2023 at 11:01:31AM +0800, xiao sheng wen wrote: > > > No provider of eglCreateImage found. Requires one of: > > > EGL 15 > > > Aborted > > Do you have the egl library installed? > Yes. Ok, can you open webkit://gpu and send me the output? /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/MiniBrowser webkit://gpu Also, do you think you can obtain a stack trace of that abort? Thanks, Berto
Bug#758068: mod_security bad performance due to misuse of apr allocator
Hello, Nelson. We were going over the opened bugs on modsecurity-apache and noticed this old one. Upstream did not update his forwarded bug either. Is this still relevant to the current version or can we close it? Thanks, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
Bug#1054101: webkit2gtk: No provider of eglCreateImage found. Requires one of: EGL 15, yelp can't start
On Tue, Oct 17, 2023 at 10:39:45AM +0800, xiao sheng wen wrote: > No provider of eglCreateImage found. Requires one of: > EGL 15 > Aborted Do you have the egl library installed? Berto
Bug#1003868: Debian 11
tags 1003868 + pending thanks Hi, the configure option will be added in the next upload. Sorry Albert, old releases aren't built with it. Regards, Alberto On Fri, Sep 29, 2023 at 03:34:55PM +0200, Albert van der Veen wrote: > In response to the bug report that covers 2.9.3-1+deb10u1: Is > 2.9.3-3+deb11u1 built with the option --enable-collection-global-lock? > > Best, > Albert van der Veen -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
Bug#1020303: Ping
On Sun, Oct 08, 2023 at 12:59:21PM +0100, Jonathan Wiltshire wrote: > Hi, > > On Mon, Jun 26, 2023 at 06:42:18PM +0100, Jonathan Wiltshire wrote: > > On Tue, Mar 21, 2023 at 12:58:31PM +0100, Alberto Gonzalez Iniesta wrote: > > > Hi, all. We're looking forward to uploading the latest CRS package to > > > bullseye-backports, but this will require this pending update to > > > bullseye. Any news on this front? > > > > Please go ahead. > > This request was approved but not uploaded in time for the previous point > release (11.8). Should it be included in 11.9, or should this request be > abandoned and closed? > Hi, Jonathan. Sorry I missed the previous point release. I thought, from Tobias last mail, that he would do the upload. I just made it. Regards, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
Bug#1052055: Webkit output fully white
On Wed, Oct 11, 2023 at 07:13:40PM +0200, R Pi wrote: > Downgraded to 2.42.1-1 and tested. The result is: 2.42.1-1 without any > env variables will NOT WORK. > > It appears the fix introduced in 2.42.1-2 is necessary. Thanks a lot for your help. So we need the fix from 2.42.1-2 and the libnvidia-egl-gbm1 package. This should work without any environment variables or other tweaks. From what I see there is already a dependency chain: nvidia-driver depends on nvidia-driver-libs nvidia-driver-libs recommends libnvidia-allocator1 libnvidia-allocator1 recommends libnvidia-egl-gbm1 So if people have the recommmended packages installed then everything is fine. Berto
Bug#1039720: Solution in stable
On Wed, Oct 11, 2023 at 05:25:09PM +0200, Patrick Holthuizen wrote: > Will the solution also come through into current stable Debian 12? Yes, I plan to make a security upload this week. Berto
Bug#1052055: Webkit output fully white
On Wed, Oct 11, 2023 at 11:10:05AM -0400, Jeremy Bícha wrote: > libnvidia-egl-gbm1 is in contrib. Ah, you're right. Berto
Bug#1052055: Webkit output fully white
On Wed, Oct 11, 2023 at 04:26:20PM +0200, R Pi wrote: > Correct. Installing libnvidia-egl-gbm1 was the only step needed to > get everything working, without further tweaks required. Do you think you can try downgrading WebKitGTK to 2.42.1-1 (currently on testing) and see if libnvidia-egl-gbm1 also solves the problem with that one? I want to evaluate if the fix that we introduced in 2.42.1-2 is necessary. > Is there a way to fix this in the deb dependencies? That's something that I need to evaluate, but being nvidia-specific I think I'll probably add with a Recommends: Berto
Bug#1039720: Acknowledgement (gnome-online-accounts: google account stop working files and calendar. Not able to re create online account.)
On Wed, Oct 11, 2023 at 11:12:00AM -0300, sergio wrote: > using *2.42.1-1~bpo12+1* package and removing *libnvidia-egl-gbm1* I can > confirm that the process still works. > > Please let me know if I need to re install or not the libnvidia-egl-gbm1 > package. That's all, you can reinstall it, thanks! Berto
Bug#1039720: Acknowledgement (gnome-online-accounts: google account stop working files and calendar. Not able to re create online account.)
On Wed, Oct 11, 2023 at 10:25:40AM -0300, sergio wrote: > sudo apt policy libnvidia-egl-gbm1 > libnvidia-egl-gbm1: > Instalados: 1.1.0-2 > Candidato: 1.1.0-2 If it's easy to test and not too much hassle, can you try removing that package and see if the problem happens again? No need to do it if it's too complicated! Berto
Bug#1039720: Acknowledgement (gnome-online-accounts: google account stop working files and calendar. Not able to re create online account.)
One question, do you have the libnvidia-egl-gbm1 package installed, and if not can you install it? Berto
Bug#1052055: Webkit output fully white
On Wed, Oct 11, 2023 at 01:31:43PM +0200, R Pi wrote: > > Do you have libnvidia-egl-gbm1 installed ? > It does work now with it installed... Oh, ok, so everything works fine if you install libnvidia-egl-gbm1 without having to do any extra tweak, or is there any problem left? Berto
Bug#1052055: Webkit output fully white
On Mon, Oct 09, 2023 at 12:26:24PM +0200, R Pi wrote: > There you go: Thanks, this is without any environment variable set, right? Do you have libnvidia-egl-gbm1 installed ? And if not, can you install it and try again? Berto
Bug#1052055: Webkit output fully white
On Mon, Oct 09, 2023 at 12:15:27PM +0200, R Pi wrote: > Thing is I don't think I could do it without the environment > variables because I still get full white output when not using them, > and wouldn't be able to browse to the webkit://gpu page You can try to click the "Copy to clipboard" button even if you don't see it (use the env variables to see the location). Berto
Bug#1052055: Webkit output fully white
On Sun, Oct 08, 2023 at 04:19:18PM +0200, R Pi wrote: > Here's the output from webkit://gpu Thanks, were you using any of the environment variables that we have been discussing? (WEBKIT_DISABLE_DMABUF_RENDERER, etc.) If so, can you send me the output of webkit://gpu without using any of those variables? Also, can you send me the output of 'ls /dev/dri/' ? Thanks! Berto
Bug#1052055: Webkit output fully white
On Thu, Oct 05, 2023 at 02:18:39PM +0200, R Pi wrote: > Unfortunately, I am still encountering the same issue. Can you open webkit://gpu on the browser and send me the output? You are using WebKitGTK 2.42.1-2, right ? Berto
Bug#1039720: Acknowledgement (gnome-online-accounts: google account stop working files and calendar. Not able to re create online account.)
On Thu, Oct 05, 2023 at 01:45:13PM -0300, sergio wrote: > Waiting until the package version it is upgradeed on the backports repo has > sense ? > Upgrading from stable warn me that i will need to update 27 other packages. Hi, if you're using stable then it's better that you don't install WebKitGTK from unstable, I'll tell you when a backport is available. Thanks, Berto
Bug#1039720: Acknowledgement (gnome-online-accounts: google account stop working files and calendar. Not able to re create online account.)
On Thu, Jun 29, 2023 at 03:51:53PM -0400, Sergio Zamora wrote: > looks like this update *WebKitGTK 2.38 -> 2.40* left the account > unusable and then made it impossible to configure it again. Hello, I just uploaded WebKitGTK 2.42.1-2 to unstable. Could you give it a try and tell me if it works fine without having to use any environment variable or any other workaround? Thanks! Berto
Bug#1052055: Webkit output fully white
On Sat, Sep 16, 2023 at 06:29:52PM +0200, R Pi wrote: > I'm currently developing an app using Tauri. Since upgrading > libwebkit2gtk-4.0-dev from version 2.40.5-1~deb12u1 to version > 2.42.0-1, whenever I launch my app I'm getting the following > messages: Hello, I just uploaded WebKitGTK 2.42.1-2 to unstable. Could you give it a try and tell me if it works fine without having to use any environment variable or any other workaround? Thanks! Berto
Bug#1052710: bookworm-pu: package modsecurity/3.0.9-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: modsecur...@packages.debian.org, car...@debian.org,
airw...@gmail.com
Control: affects -1 + src:modsecurity
[ Reason ]
Fix for CVE-2023-38285, not DSA for it.
[ Impact ]
Possible DoS.
[ Tests ]
Manually tested by package maintainers.
[ Risks ]
Low risk, small patch from upstream.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Changes in transformations functions.
https://github.com/SpiderLabs/ModSecurity/pull/2934/files
diff -Nru modsecurity-3.0.9/debian/changelog modsecurity-3.0.9/debian/changelog
--- modsecurity-3.0.9/debian/changelog 2023-04-25 11:49:24.0 +0200
+++ modsecurity-3.0.9/debian/changelog 2023-09-25 14:43:11.0 +0200
@@ -1,3 +1,10 @@
+modsecurity (3.0.9-1+deb12u1) bookworm; urgency=medium
+
+ * Applied upstream patch to fix DoS.
+CVE-2023-38285 (Closes: #1042475)
+
+ -- Ervin Hegedüs Mon, 25 Sep 2023 14:43:11 +0200
+
modsecurity (3.0.9-1) unstable; urgency=medium
* New upstream version.
diff -Nru modsecurity-3.0.9/debian/patches/cve-2023-38285.diff
modsecurity-3.0.9/debian/patches/cve-2023-38285.diff
--- modsecurity-3.0.9/debian/patches/cve-2023-38285.diff1970-01-01
01:00:00.0 +0100
+++ modsecurity-3.0.9/debian/patches/cve-2023-38285.diff2023-09-25
14:43:11.0 +0200
@@ -0,0 +1,258 @@
+Description: Added fixes against CVE-2023-38285
+ These modifications fix CVE-2023-38295.
+Author: Ervin Hegedüs
+Origin: upstream
+Bug: https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.10
+Last-Update: 2023-09-25
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: modsecurity/src/actions/transformations/remove_comments_char.cc
+===
+--- modsecurity.orig/src/actions/transformations/remove_comments_char.cc
modsecurity/src/actions/transformations/remove_comments_char.cc
+@@ -1,6 +1,6 @@
+ /*
+ * ModSecurity, http://www.modsecurity.org/
+- * Copyright (c) 2015 - 2021 Trustwave Holdings, Inc.
(http://www.trustwave.com/)
++ * Copyright (c) 2015 - 2023 Trustwave Holdings, Inc.
(http://www.trustwave.com/)
+ *
+ * You may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+@@ -15,12 +15,7 @@
+
+ #include "src/actions/transformations/remove_comments_char.h"
+
+-#include
+ #include
+-#include
+-#include
+-#include
+-#include
+
+ #include "modsecurity/transaction.h"
+ #include "src/actions/transformations/transformation.h"
+@@ -37,39 +32,40 @@ RemoveCommentsChar::RemoveCommentsChar(const std::string
)
+
+ std::string RemoveCommentsChar::evaluate(const std::string ,
+ Transaction *transaction) {
+-int64_t i;
+-std::string value(val);
++size_t i = 0;
++std::string transformed_value;
++transformed_value.reserve(val.size());
+
+-i = 0;
+-while (i < value.size()) {
+-if (value.at(i) == '/'
+-&& (i+1 < value.size()) && value.at(i+1) == '*') {
+-value.erase(i, 2);
+-} else if (value.at(i) == '*'
+-&& (i+1 < value.size()) && value.at(i+1) == '/') {
+-value.erase(i, 2);
+-} else if (value.at(i) == '<'
+-&& (i+1 < value.size())
+-&& value.at(i+1) == '!'
+-&& (i+2 < value.size())
+-&& value.at(i+2) == '-'
+-&& (i+3 < value.size())
+-&& value.at(i+3) == '-') {
+-value.erase(i, 4);
+-} else if (value.at(i) == '-'
+-&& (i+1 < value.size()) && value.at(i+1) == '-'
+-&& (i+2 < value.size()) && value.at(i+2) == '>') {
+-value.erase(i, 3);
+-} else if (value.at(i) == '-'
+-&& (i+1 < value.size()) && value.at(i+1) == '-') {
+-value.erase(i, 2);
+-} else if (value.at(i) == '#') {
+-value.erase(i, 1);
++while (i < val.size()) {
++if (val.at(i) == '/'
++&& (i+1 < val.size()) && val.at(i+1) == '*') {
++i += 2;
++} else if (val.at(i) == '*'
++&& (i+1 < val.size()) && val.at(i+1) == '/') {
++i += 2;
++} else if (val.at(i) == '<'
++&& (i+1 < val.size())
++&& val.at(i+1) == '!'
++&& (i+2 < val.size())
++&& val.at(i+2) == '-'
++&& (i+3 < val.size())
++&& val.at(i+3) == '-') {
++i += 4;
++} else if (val.at(i) == '-'
++&& (i+1 < val.size()) && val.at(i+1) == '-'
++&& (i+2 < val.size()) && val.at(i+2) == '>') {
++i += 3;
++} else if (val.at(i) == '-'
++&& (i+1 < val.size()) && val.at(i+1) == '-')
Bug#1035471: revolt no longer starts up on bookworm
Package: revolt Followup-For: Bug #1035471 X-Debbugs-Cc: alua...@udc.es I have two computers with the same debian version (testing currently). - On one it works (KDE+i3 wm) - On the other (i3 wm) it starts, but the window hangs forever. I have tried to delete ~/.cache/revolt, but it does not help. Just to add a bit more of information. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages revolt depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii gir1.2-webkit2-4.0 2.42.0-1 ii python3 3.11.4-5+b1 ii python3-gi 3.46.0-1 revolt recommends no packages. revolt suggests no packages. -- no debconf information
Bug#1052055: Webkit output fully white
On Sat, Sep 16, 2023 at 06:29:52PM +0200, R Pi wrote: > KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied > Failed to create GBM buffer of size 1024x741: Permission denied Hello and thanks for the bug report. What happens if you set WEBKIT_DISABLE_DMABUF_RENDERER=1 in the environment? If it works, does it also work if you set WEBKIT_DMABUF_RENDERER_DISABLE_GBM=1 instead? Also, please try with the MiniBrowser (with and without that variable) to see if it makes a difference. /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/MiniBrowser /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/MiniBrowser /usr/lib/x86_64-linux-gnu/webkitgtk-6.0/MiniBrowser The first two should behave the same, I'm curious if there's a difference with the third one. Thanks! Berto
Bug#1012746: Holds, if differently, on bookworm and later libwebkit2gtk-s
On Mon, Jul 31, 2023 at 01:22:43PM +0200, Markus Demleitner wrote: > With bookworm, things have significantly changed; it seems webkit2gtk > is now pretty much broken on non-local displays, but then the > crashes are somewhat milder. > > I believe the easiest webkit client to investigate the problem in is > surf, where the raw symptom is: > > $ ssh -X surf http://www.debian.org > libEGL warning: DRI2: failed to authenticate Out of curiosity, can you try the same with the MiniBrowser instead of surf? /usr/lib/x86_64-linux-gnu/webkit*/MiniBrowser Berto
Bug#1051447: wpewebkit: Circular build-dependency on gst-plugins-bad1.0 prevents bootstrap
On Fri, Sep 08, 2023 at 09:18:28AM +0200, John Paul Adrian Glaubitz wrote: > Could you add a build profile to either src:gst-plugins-bad1.0 or > src:wpewebkit to allow the packages to be boostrapped on loong64? Hi, I just gave this a quick try. In theory it should be possible to build wpewebkit without gstreamer (-DENABLE_WEB_AUDIO=OFF -DENABLE_VIDEO=OFF) but wpewebkit 2.40.5 fails to build because of a missing definition. These kinds of errors are normally not hard to fix but the real problem is that this no-gstreamer configuration is not tested in any of the bots, so while I can make 2.40.5 build fine this is likely to break again in the future. I suspect that it's much easier to build gst-plugins-bad without the WPE plugin, so I would suggest to add the new build profile there. Did you file a separate bug, and if not can you reassign this one? Regards, Berto
Bug#1012739: surf: Doesn't run
On Tue, Jun 14, 2022 at 08:14:33PM +0200, Reiner Herrmann wrote:
> surf currently does not support wayland (and I think it's unlikely it will
> get support for it in the long term).
>
> On the Internet I found the following workaround that might work for you:
>
> $ GDK_BACKEND=x11 surf
Since Surf does not currently support Wayland I think that it would be
a good idea to patch the source code to force the X11 backend (see the
attached patch).
Berto
Index: surf-2.1+git20221016/surf.c
===
--- surf-2.1+git20221016.orig/surf.c
+++ surf-2.1+git20221016/surf.c
@@ -347,6 +347,7 @@ setup(void)
atoms[AtomUri] = XInternAtom(dpy, "_SURF_URI", False);
atoms[AtomUTF8] = XInternAtom(dpy, "UTF8_STRING", False);
+ gdk_set_allowed_backends("x11");
gtk_init(NULL, NULL);
gdpy = gdk_display_get_default();
Bug#1050777: The surf autopkgtests are failing with webkitgtk 2.41
On Wed, Aug 30, 2023 at 04:22:04PM +, Alberto Garcia wrote:
> I'm having problems passing the autopkgtests locally with Wayland,
> but already with WebKitGTK 2.40.x ...
I noticed that surf assumes that it's running under an X11 display in
places like this:
https://sources.debian.org/src/surf/2.1%2Bgit20221016-4/surf.c/#L1403
It doesn't work for me at all in a Wayland environment, even if
Xwayland is available.
I think that this is orthogonal to this GL problem we're talking
about, but surf should force the GDK backend to X11 because that's the
only one that it supports. gdk_set_allowed_backends() before gtk_init()
should be enough:
gdk_set_allowed_backends("x11");
gtk_init(NULL, NULL);
https://sources.debian.org/src/surf/2.1%2Bgit20221016-4/surf.c/#L350
Or the GDK_BACKEND=x11 variable for a quick test.
Berto
Bug#1050777: The surf autopkgtests are failing with webkitgtk 2.41
On Thu, Sep 07, 2023 at 12:19:29PM +0200, Sebastien Bacher wrote: > > FWIW I uploaded a new package with a dependency on libgles2 and > > now the surf autopkgtests are passing: > > > > https://ci.debian.net/packages/s/surf/unstable/amd64/ > > > I saw, sadly that's not enough to fix it in Ubuntu for some reason :-/ > > https://autopkgtest.ubuntu.com/results/autopkgtest-mantic/mantic/amd64/s/surf/20230907_090320_43dbb@/log.gz I don't understand why it is pulling libgles1 instead of libgles2, webkit2gtk 2.41.91-2 should depends on the latter. Berto
Bug#1050777: The surf autopkgtests are failing with webkitgtk 2.41
FWIW I uploaded a new package with a dependency on libgles2 and now the surf autopkgtests are passing: https://ci.debian.net/packages/s/surf/unstable/amd64/ On Wed, Sep 06, 2023 at 05:57:51PM +0200, Sebastien Bacher wrote: > Checking a strace output it's loading libEGL.so.1 on my machine and > not libGLES.so.2 And do you have both installed? (in other words, does webkit load the library fine?) Berto
Bug#1050777: The surf autopkgtests are failing with webkitgtk 2.41
On Tue, Aug 29, 2023 at 09:47:01AM +0200, Sebastien Bacher wrote: > The issue seems to be there in Debian as well > https://ci.debian.net/packages/s/surf/unstable/amd64/ This is due to a missing dependency on libgles2 (which is loaded at runtime via libepoxy), so I will add that to the package. Do you have that package installed? Berto
Bug#1050777: The surf autopkgtests are failing with webkitgtk 2.41
On Tue, Aug 29, 2023 at 05:09:32PM +0200, Sebastien Bacher wrote: > And as a follow up it's not only an autopkgtest issue, surf fails to render > any webpage on my Ubuntu mantic system with the new webkitgtk installed This might be the same problem reported upstream here: https://bugs.webkit.org/show_bug.cgi?id=259858 Berto
Bug#1050777: The surf autopkgtests are failing with webkitgtk 2.41
On Wed, Aug 30, 2023 at 10:14:15AM +0200, Sebastien Bacher wrote: > The MiniBrowser works fine and render webpages as expected > > Starting surf with WEBKIT_DISABLE_COMPOSITING_MODE=1 set also > workaround the issue and gives working rendering You are using Wayland I suppose? What if you run surf with WAYLAND_DISPLAY=none, does it work then? I'm having problems passing the autopkgtests locally with Wayland, but already with WebKitGTK 2.40.x ... Berto
Bug#1050777: The surf autopkgtests are failing with webkitgtk 2.41
On Tue, Aug 29, 2023 at 05:09:32PM +0200, Sebastien Bacher wrote: > And as a follow up it's not only an autopkgtest issue, surf fails to > render any webpage on my Ubuntu mantic system with the new webkitgtk > installed I cannot reproduce the problem in Debian with libwebkit2gtk-4.1-0 2.41.91-1, it seems to work fine. What happens if you use the MiniBrowser directly instead of surf? $ /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/MiniBrowser https://www.debian.org/ Berto
Bug#1021656: please package new upstream release
On Wed, Oct 12, 2022 at 01:24:40PM +0200, Piotr Ożarowski wrote: > Package: tt-rss > Version: 21~git20210204.b4cbc79+dfsg-1 > Severity: wishlist > > Hi, > > Please prepare new upstream release. Hello, I think that tt-rss as it is now in bookworm is barely usable (using the web interface at least). It's hard to tell which articles are read and which ones are not, plus they don't get marked as read automatically (#1005331). Also the journal is full of PHP warnings (#1006956). My impression is that that the packaged version (february 2021) just doesn't work with PHP 8, which was released a couple of months before that. Berto
Bug#1050168: FTBFS: test_no_local_cert: tlsv13 alert certificate required
On Mon, Aug 21, 2023 at 05:32:53PM +0800, Shengjing Zhu wrote: Source: kxd Version: 0.15-4 Severity: serious Tags: ftbfs X-Debbugs-Cc: albert...@blitiri.com.ar, z...@debian.org I'm not sure if it's related to golang-defaults -> golang-1.21 recently. [...] Traceback (most recent call last): File "/<>/tests/run_tests", line 360, in test_no_local_cert self.assertEqual(err.reason, "SSLV3_ALERT_BAD_CERTIFICATE") AssertionError: 'TLSV13_ALERT_CERTIFICATE_REQUIRED' != 'SSLV3_ALERT_BAD_CERTIFICATE' - TLSV13_ALERT_CERTIFICATE_REQUIRED + SSLV3_ALERT_BAD_CERTIFICATE Thanks for filing this! Yeah I think it's likely, this looks like a more specific and accurate error is now reported in this case, either due to the Go TLS library, or OpenSSL (which the tests use because they're written in Python). I have a patch in the `next` branch that should update the test accordingly: https://blitiri.com.ar/git/r/kxd/c/ca7d96cc6088cddbdd9904cc8de8192b417a9340/ https://blitiri.com.ar/git/r/kxd/c/ca7d96cc6088cddbdd9904cc8de8192b417a9340.patch Would you mind giving it a try? It should solve the problem. Thanks! Alberto
Bug#985769: xwayland: 100% of CPU, The system gets stuck.
On Mon, Jul 03, 2023 at 04:23:30PM +0200, Alberto Garcia wrote: > > > Could be https://gitlab.freedesktop.org/xorg/xserver/-/issues/1442 > > > fixed by > > > https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1086 . > > > > Thanks, it does sound like that, I'll try to cherry pick that > > fix and see how it goes. I'll come back in a week or two with my > > conclusions. > > I have been using xwayland 2:22.1.9-1 with those two commits > cherry-picked and so far I haven't had any issues. I have been using those patches for around one month now and I haven't had the problem again. I think it would be great to have this fixed in bookworm. Berto
Bug#1039720: Acknowledgement (gnome-online-accounts: google account stop working files and calendar. Not able to re create online account.)
On Tue, Jul 11, 2023 at 12:17:22PM -0400, Sergio Zamora wrote: > try this from terminal ? : > > $ WEBKIT_DISABLE_COMPOSITING_MODE=1 gnome-control-center Yes. This only has a temporary effect and it will last until you close the GNOME control center. Thanks, Berto
Bug#1039720: Acknowledgement (gnome-online-accounts: google account stop working files and calendar. Not able to re create online account.)
On Thu, Jun 29, 2023 at 03:51:53PM -0400, Sergio Zamora wrote: > looks like this update *WebKitGTK 2.38 -> 2.40* left the account > unusable and then made it impossible to configure it again. Can you try setting WEBKIT_DISABLE_COMPOSITING_MODE=1 in the environment? Does it solve the problem? Berto
Bug#985769: xwayland: 100% of CPU, The system gets stuck.
On Thu, Jun 22, 2023 at 12:42:51PM +, Alberto Garcia wrote: > On Thu, Jun 22, 2023 at 02:30:25PM +0200, Michel Dänzer wrote: > > Could be https://gitlab.freedesktop.org/xorg/xserver/-/issues/1442 > > fixed by > > https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1086 . > > Thanks, it does sound like that, I'll try to cherry pick that fix and > see how it goes. I'll come back in a week or two with my conclusions. I have been using xwayland 2:22.1.9-1 with those two commits cherry-picked and so far I haven't had any issues. Berto
Bug#1038355: fuse-emulator: Depends on SDL 1.2
On Tue, Jun 27, 2023 at 01:59:41PM +0100, Simon McVittie wrote: > On Tue, 27 Jun 2023 at 11:39:04 +0000, Alberto Garcia wrote: > > One thing that I just noticed when using the shim is that after > > switching the app to full screen mode and then back to windowed mode > > the mouse pointer remains trapped inside the window. This only seems > > to happen with SDL2 (both with and without SDL_VIDEODRIVER=wayland), I > > cannot reproduce that behavior with SDL1. > > > > If I press alt-tab to switch to another window I can move the pointer > > just fine, but if I go back to Fuse and move the pointer inside the > > window then it gets trapped again. > > I don't know whether this is working as designed, or a bug - > either one seems plausible for a machine emulator. If this seems > wrong to you as its maintainer, please could you report it to > <https://github.com/libsdl-org/sdl12-compat/> with steps that > someone who doesn't know anything about this particular package > could use to reproduce it? I don't think this works as designed, since the original SDL1 version does not do that and it would be weird to grab the mouse only after coming back from full screen... anyway, it's not a terrible problem and it would not be a blocker for me, but I just reported it: https://github.com/libsdl-org/sdl12-compat/issues/301 Thanks! Berto
Bug#1038355: fuse-emulator: Depends on SDL 1.2
On Tue, Jun 27, 2023 at 12:16:44PM +0100, Simon McVittie wrote: > > > 3. Install libsdl1.2-compat-shim and run the program in a Wayland > > >environment, but this time with environment variable > > >SDL_VIDEODRIVER=wayland > > > > The window appears without decorations so it's impossible to move > > it. Otherwise it seems to work fine. > > libsdl2-2.0-0 Depends on libdecor-0-0, which Recommends > libdecor-0-plugin-1-cairo (or another compatible plugin, but currently > there are none in Debian). Indeed, installing that plugin solves the problem, thanks. One thing that I just noticed when using the shim is that after switching the app to full screen mode and then back to windowed mode the mouse pointer remains trapped inside the window. This only seems to happen with SDL2 (both with and without SDL_VIDEODRIVER=wayland), I cannot reproduce that behavior with SDL1. If I press alt-tab to switch to another window I can move the pointer just fine, but if I go back to Fuse and move the pointer inside the window then it gets trapped again. Berto
Bug#1038355: fuse-emulator: Depends on SDL 1.2
On Sat, Jun 17, 2023 at 10:45:37AM +0100, Simon McVittie wrote: > Source: fuse-emulator > Tags: trixie sid > User: pkg-sdl-maintain...@lists.alioth.debian.org > Usertags: libsdl1.2 Tested with - fuse-emulator-sdl 1.6.0+dfsg1-2 - libsdl1.2-compat / libsdl1.2-compat-shim 1.2.64-2 > 1. Install libsdl1.2-compat-shim and run the program in an X11 environment, >such as "GNOME on Xorg" or XFCE. >($XDG_RUNTIME_DIR/wayland-* should not exist) This seems to work perfectly fine. > 2. Install libsdl1.2-compat-shim and run the program in a Wayland >environment such as GNOME's default mode, using Xwayland. >($XDG_RUNTIME_DIR/wayland-* should exist) This seems to work perfectly fine. > 3. Install libsdl1.2-compat-shim and run the program in a Wayland >environment, but this time with environment variable >SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface >(this is not currently the default for SDL 2). The window appears without decorations so it's impossible to move it. Otherwise it seems to work fine. Switching between fullscreen and normal mode also works as expected. > 4. Install libsdl1.2-compat-dev and recompile the package. The package builds fine without issues. Berto
Bug#985769: xwayland: 100% of CPU, The system gets stuck.
On Thu, Jun 22, 2023 at 02:30:25PM +0200, Michel Dänzer wrote: > Could be https://gitlab.freedesktop.org/xorg/xserver/-/issues/1442 > fixed by > https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1086 . Thanks, it does sound like that, I'll try to cherry pick that fix and see how it goes. I'll come back in a week or two with my conclusions. Berto
Bug#985769: xwayland: 100% of CPU, The system gets stuck.
On Tue, Mar 23, 2021 at 03:57:41PM +0800, john wrote: > The xwayland cpu utilization rate reaches 100%, which often happens. I have actually had this problem a few times since I upgraded from bullseye to bookworm. The UI becomes unresponsive and the only alternative is to ssh into the machine and kill Xwayland. I don't think I ever had this problem in bullseye. I think this tends to happen when I am using Steam (and I don't mean playing a game but simply browsing the store or the library). Unfortunately the patch suggested by Timo Lindfors is already applied in bookworm so if that solves the problem for him then the underlying cause is probably different. Berto
Bug#1037139: gst-plugins-bad1.0: Please switch gstreamer1.0-wpe to the new 2.0 WPE API
Source: gst-plugins-bad1.0
Version: 1.22.3-1
Severity: normal
Tags: patch
Hi,
the new 2.40.x branch of the WPE WebKit engine introduced a new 2.0
API. The GStreamer WPE plugin uses the 1.1 API, which upstream would
like to remove sooner or later.
The wpewebkit-2.0 packages have already been uploaded to experimental.
Since WPE WebKit in Debian only has two reverse dependencies I would
like to make the transition, move wpewebkit-2.0 to unstable and get
rid of wpewebkit-1.1.
One of the reverse dependencies (cog) is ready and also available in
experimental.
The other one is gstreamer1.0-wpe. This has been updated upstream to
support the 2.0 API but it hasn't been released yet (it will likely
happen after summer if I'm not wrong). However the patch can be cherry
picked to the stable branch.
I'm attaching the debdiff in case you want to consider switching the
gst-wpe plugin to the 2.0 API in experimental. Once that is done I'm
ready to move the wpewebkit-2.0 packages to unstable.
Thanks,
Berto
diff -Nru gst-plugins-bad1.0-1.22.3/debian/changelog
gst-plugins-bad1.0-1.22.3/debian/changelog
--- gst-plugins-bad1.0-1.22.3/debian/changelog 2023-05-21 14:31:50.0
+0200
+++ gst-plugins-bad1.0-1.22.3/debian/changelog 2023-06-06 11:05:15.0
+0200
@@ -1,3 +1,13 @@
+gst-plugins-bad1.0 (1.22.3-2) experimental; urgency=medium
+
+ [ Alberto Garcia ]
+ * Build the gst-wpe plugin using the 2.0 WPE API.
+- debian/patches/wpe-2.0-api.patch: Cherry pick the corresponding
+ upstream commit (fe4f034c8a).
+- debian/control: Build depend on libwpewebkit-2.0-dev.
+
+ -- Alberto Garcia Tue, 06 Jun 2023 11:05:15 +0200
+
gst-plugins-bad1.0 (1.22.3-1) experimental; urgency=medium
* Team upload
diff -Nru gst-plugins-bad1.0-1.22.3/debian/control
gst-plugins-bad1.0-1.22.3/debian/control
--- gst-plugins-bad1.0-1.22.3/debian/control2023-05-21 14:31:50.0
+0200
+++ gst-plugins-bad1.0-1.22.3/debian/control2023-06-06 11:04:47.0
+0200
@@ -57,7 +57,7 @@
libopencv-dev (>= 3.0.0) [amd64 arm64 armel armhf i386 mips64el
mipsel ppc64el s390x alpha hppa hurd-i386 m68k powerpc ppc64 riscv64],
opencv-data [amd64 arm64 armel armhf i386 mips64el mipsel
ppc64el s390x alpha hppa hurd-i386 m68k powerpc ppc64 riscv64],
libwpebackend-fdo-1.0-dev (>= 1.8.0) [linux-any],
- libwpewebkit-1.1-dev (>= 2.28.0) [linux-any],
+ libwpewebkit-2.0-dev [linux-any],
libopenexr-dev,
libopenh264-dev (>= 1.3.0),
libopenjp2-7-dev (>= 2.2),
diff -Nru gst-plugins-bad1.0-1.22.3/debian/patches/series
gst-plugins-bad1.0-1.22.3/debian/patches/series
--- gst-plugins-bad1.0-1.22.3/debian/patches/series 2023-05-21
14:31:50.0 +0200
+++ gst-plugins-bad1.0-1.22.3/debian/patches/series 2023-06-06
11:03:23.0 +0200
@@ -1,2 +1,3 @@
02_opencv-data-path.patch
Skip-failing-tests.patch
+wpe-2.0-api.patch
diff -Nru gst-plugins-bad1.0-1.22.3/debian/patches/wpe-2.0-api.patch
gst-plugins-bad1.0-1.22.3/debian/patches/wpe-2.0-api.patch
--- gst-plugins-bad1.0-1.22.3/debian/patches/wpe-2.0-api.patch 1970-01-01
01:00:00.0 +0100
+++ gst-plugins-bad1.0-1.22.3/debian/patches/wpe-2.0-api.patch 2023-06-06
11:05:15.0 +0200
@@ -0,0 +1,246 @@
+From: Philippe Normand
+Subject: wpe: Add support for the WPEWebKit 2.0 API version
+Origin:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/fe4f034c8a2a569c1530a3e98622b0ea1d96a0cb
+Index: gst-plugins-bad1.0-1.22.3/ext/wpe/WPEThreadedView.cpp
+===
+--- gst-plugins-bad1.0-1.22.3.orig/ext/wpe/WPEThreadedView.cpp
gst-plugins-bad1.0-1.22.3/ext/wpe/WPEThreadedView.cpp
+@@ -186,7 +186,11 @@ initialize_web_extensions (WebKitWebCont
+ const gchar *local_path = gst_wpe_get_devenv_extension_path ();
+ const gchar *path = g_file_test (local_path, G_FILE_TEST_IS_DIR) ?
local_path : G_STRINGIFY (WPE_EXTENSION_INSTALL_DIR);
+ GST_INFO ("Loading WebExtension from %s", path);
++#if USE_WPE2
++webkit_web_context_set_web_process_extensions_directory (context, path);
++#else
+ webkit_web_context_set_web_extensions_directory (context, path);
++#endif
+ }
+
+ static void
+@@ -348,10 +352,14 @@ WPEView* WPEContextThread::createWPEView
+ WPEView* view = nullptr;
+ dispatch([&]() mutable {
+ if (!glib.web_context) {
++#if USE_WPE2
++glib.web_context =
WEBKIT_WEB_CONTEXT(g_object_new(WEBKIT_TYPE_WEB_CONTEXT, nullptr));
++#else
+ auto *manager = webkit_website_data_manager_new_ephemeral();
+ glib.web_context =
+ webkit_web_context_new_with_website_data_manager(manager);
+ g_object_unref(manager);
++#endif
+ }
+ view = new WPEView(glib.web_context, src, context, display, width,
height);
+ });
+@@ -407,7 +415,11 @@ WPEView::WP
