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#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#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#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#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#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#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#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#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#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#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#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
Bug#1036946: webkit2gtk: Tries to build Bubblewrap support even if its disabled
On Wed, May 31, 2023 at 10:57:32AM -0400, Jeremy Bícha wrote: > Untested, but I think this would work: > https://salsa.debian.org/webkit-team/webkit/-/merge_requests/17 I already had some of this changes already applied locally, I just pushed them. Thanks! Berto
Bug#1036946: webkit2gtk: Tries to build Bubblewrap support even if its disabled
Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=256917 Control: tags -1 patch fixed-upstream pending On Tue, May 30, 2023 at 02:23:31PM +0200, John Paul Adrian Glaubitz wrote: > webkit2gtk currently FTBFS on multiple architectures since it tries > to build Bubblewrap support code despite being configured with > -DENABLE_BUBBLEWRAP_SANDBOX=OFF. This has been fixed upstream already, I'll include the fix in the next upload: https://github.com/WebKit/WebKit/commit/4977290ab4ab35258a6da9b13795c9b0f7894bf4 Berto
Bug#1035877: webkit2gtk-driver: Encryption based porting error to non-sse2 systems fail website processes
On Wed, May 10, 2023 at 03:26:40PM +0200, Christian Kiss wrote: > specific websites do not work around encryption like password > generation in yahoo or gmx login cookiesettings on. Sorry, I'm not sure that I understand that sentence... could you try to rephrase it? Thanks! In general WebKit dropped support for non-SSE2 CPUs at least 5 years ago and it does not even build in those CPUs. In Debian we're actually patching the source to relax those requirements, and while it more or less works fine for basic browsing we cannot guarantee that for all features. Berto
Bug#1036154: Temporary fix - issue connected with [DSA 5340-1] webkit2gtk security update?
On Tue, May 16, 2023 at 04:21:29PM +0200, Matthias Kirschner wrote: > (Added Alberto in CC, as the issue might be connected with the > webkit2gtk security update: > https://lists.debian.org/debian-security-announce/2023/msg00029.html ) I think that it is this upstream bug: https://github.com/astroidmail/astroid/issues/720 And yes, it is unfortunately related to the webkit2gtk upgrade. The good news is that it can be worked around locally without having to modify the astroid package (although it's a good idea to do that anyway). Berto
Bug#1035794: debian-security-support: Please mark wpewebkit as unsupported in bookworm
On Fri, May 12, 2023 at 08:27:49AM +, Holger Levsen wrote: > > Note that wpewebkit is still supported in bullseye and will remain > > supported until the distro reaches EOL. > does that mean when the Debian security stops supporting bullseye Yes, that one (summer 2024). After that if it keeps building I can prepare the uploads for LTS if there's interest but I won't handle the DLAs myself (we are doing exactly that for WebKitGTK in buster). Berto
Bug#1035794: debian-security-support: Please mark wpewebkit as unsupported in bookworm
Package: debian-security-support Version: 1:12+2023.03.23 Severity: normal Hi, we won't be providing security updates of the wpewebkit package for bookworm. The package will be kept up-to-date in unstable and users will still be able to find the most recent versions there. wpewebkit should be buildable in bookworm during its lifetime so users can create their own packages easily if they need to. However, some APIs will probably change so reverse dependencies can be affected. Note that wpewebkit is still supported in bullseye and will remain supported until the distro reaches EOL. Regards, Berto
Bug#1035042: wpewebkit: ftbfs riscv64 Error: open CFI at the end of file; missing .cfi_endproc directive
On Mon, May 01, 2023 at 05:18:39AM +, sun min wrote: > I get the package source with below command: > dget http://deb.debian.org/debian/pool/main/w/wpewebkit/wpewebkit_2.38.6-1.dsc I have seen people reporting the same bug when building other projects and it seems that this could be hardware or memory related... how much RAM do you have to build WebKit? Berto
Bug#1035469: libwebkit2gtk-4.0-37: After upgrading to libwebkit2gtk-4.0-37_2.40.1-1~deb11u1, Gnome Evolution does not load the body content of emails.
On Wed, May 03, 2023 at 01:32:18PM -0400, Jim Popovitch wrote: > > Thanks for the report, we'll prepare an update asap. > > > > Best wishes! It took longer than I would have wished, but this is now fixed in evolution 3.38.3-1+deb11u2 Berto
Bug#1035469: libwebkit2gtk-4.0-37: After upgrading to libwebkit2gtk-4.0-37_2.40.1-1~deb11u1, Gnome Evolution does not load the body content of emails.
So what happens is that the Evolution in bullseye is using a
deprecated WebKit API that was removed in the 2.40.x branch (the
function remains but it's a no-op now). Reverting that change in
WebKit is unfortunately not an option.
This was fixed in Evolution upstream a while ago[1] so bookworm is not
affected. The patch was backported to at least Evolution 3.28.5[2] and
3.40.4[3]. The latter can be applied fine to our version (3.38.3) and
fixes the problem for me, I'm putting Milan Crha on Cc for comments
since the patch is not trivial.
I'm also attaching the debdiff for Evolution with this patch included.
The other alternative would be to switch back to WebKitGTK 2.38.x but
that branch is not likely to receive any further security updates.
Berto
[1] https://gitlab.gnome.org/GNOME/evolution/-/issues/2001
[2]
https://gitlab.com/redhat/centos-stream/rpms/evolution/-/blob/c8s/evolution-3.28.5-frame-flattenning.patch
[3]
https://gitlab.com/redhat/centos-stream/rpms/evolution/-/blob/c9s/evolution-3.40.4-frame-flattenning.patch
diff -Nru evolution-3.38.3/debian/changelog evolution-3.38.3/debian/changelog
--- evolution-3.38.3/debian/changelog 2022-10-18 22:36:42.0 +0200
+++ evolution-3.38.3/debian/changelog 2023-05-04 00:33:14.0 +0200
@@ -1,3 +1,10 @@
+evolution (3.38.3-1+deb11u2) bullseye-security; urgency=medium
+
+ * Add a patch to make Evolution display email bodies properly when using
+WebKitGTK 2.40.x (Closes: #1035469).
+
+ -- Alberto Garcia Thu, 04 May 2023 00:33:14 +0200
+
evolution (3.38.3-1+deb11u1) bullseye; urgency=medium
* Add a patch from upstream to move Google Contacts addressbooks to
diff -Nru evolution-3.38.3/debian/control evolution-3.38.3/debian/control
--- evolution-3.38.3/debian/control 2022-10-18 22:36:42.0 +0200
+++ evolution-3.38.3/debian/control 2023-05-04 00:33:14.0 +0200
@@ -6,7 +6,7 @@
Section: gnome
Priority: optional
Maintainer: Debian GNOME Maintainers
-Uploaders: Iain Lane , Jeremy Bicha , Laurent Bigonville , Sebastien Bacher
+Uploaders: Alberto Garcia , Iain Lane , Jeremy Bicha , Laurent Bigonville , Sebastien Bacher
Build-Depends: cmake,
debhelper (>= 11),
dh-sequence-gnome,
diff -Nru evolution-3.38.3/debian/patches/frame-flattening.patch evolution-3.38.3/debian/patches/frame-flattening.patch
--- evolution-3.38.3/debian/patches/frame-flattening.patch 1970-01-01 01:00:00.0 +0100
+++ evolution-3.38.3/debian/patches/frame-flattening.patch 2023-05-04 00:33:14.0 +0200
@@ -0,0 +1,478 @@
+From: Milan Crha
+Subject: Handle frame flattening change in WebKitGTK 2.40.x
+Bug: https://bugs.webkit.org/show_bug.cgi?id=256266
+Bug-Debian: https://bugs.debian.org/1035469
+Origin: https://gitlab.com/redhat/centos-stream/rpms/evolution/-/blob/c9s/evolution-3.40.4-frame-flattenning.patch
+Index: evolution-3.38.3/data/webkit/e-web-view.js
+===
+--- evolution-3.38.3.orig/data/webkit/e-web-view.js
evolution-3.38.3/data/webkit/e-web-view.js
+@@ -722,6 +722,38 @@ Evo.EnsureMainDocumentInitialized = func
+ Evo.initializeAndPostContentLoaded(null);
+ }
+
++Evo.mailDisplayUpdateIFramesHeightRecursive = function(doc)
++{
++ if (!doc)
++ return;
++
++ var ii, iframes;
++
++ iframes = doc.getElementsByTagName("iframe");
++
++ /* Update from bottom to top */
++ for (ii = 0; ii < iframes.length; ii++) {
++ Evo.mailDisplayUpdateIFramesHeightRecursive(iframes[ii].contentDocument);
++ }
++
++ if (!doc.scrollingElement || !doc.defaultView || !doc.defaultView.frameElement)
++ return;
++
++ if (doc.defaultView.frameElement.height == doc.scrollingElement.scrollHeight)
++ doc.defaultView.frameElement.height = 10;
++ doc.defaultView.frameElement.height = doc.scrollingElement.scrollHeight + 2 + (doc.scrollingElement.scrollWidth > doc.scrollingElement.clientWidth ? 20 : 0);
++}
++
++Evo.MailDisplayUpdateIFramesHeight = function()
++{
++ var scrolly = document.defaultView ? document.defaultView.scrollY : -1;
++
++ Evo.mailDisplayUpdateIFramesHeightRecursive(document);
++
++ if (scrolly != -1 && document.defaultView.scrollY != scrolly)
++ document.defaultView.scrollTo(0, scrolly);
++}
++
+ if (this instanceof Window && this.document) {
+ this.document.onload = function() { Evo.initializeAndPostContentLoaded(this); };
+
+@@ -807,9 +839,8 @@ Evo.mailDisplayResizeContentToPreviewWid
+ local_width -= 2; /* 1 + 1 frame borders */
+ } else if (!iframes.length) {
+ /* Message main body */
+-local_width -= 8; /* 8 + 8 margins of body without iframes */
+-if (level > 1)
+- local_width -= 8;
++local_width -= level * 20; /* 10 + 10 margins of body without iframes */
++local_width -= 4;
+
+ Evo.addRuleIntoStyleSheetDocument(doc, "-e-mail-formatter-style-sheet", "body", "width: " + local_width + "px;");
+ Evo.addRuleIntoStyl
Bug#1035469: libwebkit2gtk-4.0-37: After upgrading to libwebkit2gtk-4.0-37_2.40.1-1~deb11u1, Gnome Evolution does not load the body content of emails.
Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=256266 On Wed, May 03, 2023 at 01:32:18PM -0400, Jim Popovitch wrote: > If you don't currently use Evolution and are looking for a way to > test this I can reproduce the problem just fine, thanks. I'm adding a link to the upstream bug for reference. As you probably noticed the problem is that the area where the body should appear is now very narrow so although the document is there you can barely read it. Sorry for the mess! Berto
Bug#1035469: libwebkit2gtk-4.0-37: After upgrading to libwebkit2gtk-4.0-37_2.40.1-1~deb11u1, Gnome Evolution does not load the body content of emails.
On Wed, May 03, 2023 at 12:28:38PM -0400, Jim P. wrote: >* What led up to the situation? > > A: The updates to libjavascriptcoregtk-4.0-18 libwebkit2gtk-4.0-37 Thanks for the report, we'll prepare an update asap. Berto
Bug#1035042: wpewebkit: ftbfs riscv64 Error: open CFI at the end of file; missing .cfi_endproc directive
Control: tags -1 moreinfo On Fri, Apr 28, 2023 at 05:57:34AM +, sun min wrote: > Source: wpewebkit > Version: 2.38.6-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > > Dear Maintainer, > > My sbuild for risv64 archtecture log says: Hi, wpewebkit 2.38.x has been building fine in riscv64 for a while without many problems: https://buildd.debian.org/status/logs.php?pkg=wpewebkit=riscv64 There was a failure in November 2022 seemingly because of a compiler bug, but that's about it. What is the exact environment that you are using to build webkit? Berto
Bug#1034872: unblock: wpewebkit/2.38.6-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package wpewebkit [ Reason ] Fix five CVEs, one of them reported to have been actively exploited. [ Impact ] wpewebkit, like all other major browser engines, is affected by a constant stream of security bugs so it's not recommended to browse the web using an outdated version of the package. For this reason the security team has been providing wpewebkit updates using the upstream stable releases sice Debian bullseye. 2.38.6 is the next stable point release after 2.38.5 (already in bookworm). It contains fixes for several bugs including 5 CVEs: CVE-2022-0108 Impact: An HTML document may be able to render iframes with sensitive user information. CVE-2022-32885 Impact: Processing maliciously crafted web content may lead to arbitrary code execution. CVE-2023-27932 Impact: Processing maliciously crafted web content may bypass Same Origin Policy. CVE-2023-27954 Impact: A website may be able to track sensitive user information. CVE-2023-28205 Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited. [ Tests ] Tested manually using the cog web browser. [ Risks ] WPE WebKit evolves very fast and its stable releases contain other fixes apart from the security ones. Because of this the chance of regressions is higher than with other packages. That said, upstream has had a good track record of publishing updates with no major issues. In addition to that, WPE WebKit is also a niche browser engine with few reverse dependencies so the impact of any possible regression is very low and the risk is therefore much more controlled. [ 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 testing [ Other info ] This new version also works in bullseye and the the corresponding security update is also being prepared. Note that I only include the debian/ part of the debdiff since the changes to the source itself are larger due to the nature of the release. unblock wpewebkit/2.38.6-1 diff -Nru wpewebkit-2.38.5/debian/changelog wpewebkit-2.38.6/debian/changelog --- wpewebkit-2.38.5/debian/changelog 2023-02-15 22:52:14.0 +0100 +++ wpewebkit-2.38.6/debian/changelog 2023-04-25 09:17:43.0 +0200 @@ -1,3 +1,13 @@ +wpewebkit (2.38.6-1) unstable; urgency=high + + * New upstream release. + * The WPE WebKit security advisory WSA-2023-0003 lists the following +security fixes in the latest versions of WPE WebKit: +- CVE-2022-0108, CVE-2022-32885, CVE-2023-27932, CVE-2023-27954, + CVE-2023-28205 (fixed in 2.38.6 and 2.40.1). + + -- Alberto Garcia Tue, 25 Apr 2023 09:17:43 +0200 + wpewebkit (2.38.5-1) unstable; urgency=high * New upstream release.
Bug#1034870: unblock: webkit2gtk/2.40.1-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package webkit2gtk
[ Reason ]
Fix five CVEs, one of them reported to have been actively exploited.
[ Impact ]
webkit2gtk, like all other major browser engines, is affected by a
constant stream of security bugs so it's not recommended to browse the
web using an outdated version of the package. For this reason the
security team has been providing webkit2gtk updates using the upstream
stable releases sice Debian buster.
2.40.1 is the first stable point release after 2.40.0 (already in
bookworm). It contains fixes for several bugs including 5 CVEs:
CVE-2022-0108
Impact: An HTML document may be able to render iframes with
sensitive user information.
CVE-2022-32885
Impact: Processing maliciously crafted web content may lead to
arbitrary code execution.
CVE-2023-27932
Impact: Processing maliciously crafted web content may bypass Same
Origin Policy.
CVE-2023-27954
Impact: A website may be able to track sensitive user information.
CVE-2023-28205
Impact: Processing maliciously crafted web content may lead to
arbitrary code execution. Apple is aware of a report that this
issue may have been actively exploited.
This new version also works in bullseye and the the corresponding
security update is also being prepared.
[ Tests ]
Tested manually using the Epiphany web browser for several days.
[ Risks ]
WebKitGTK evolves very fast and its stable releases contain other
fixes apart from the security ones. Because of this the chance of
regressions is higher than with other packages. That said, upstream
has had a good track record of publishing updates with no major
issues.
[ 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 testing
Note that I only include the debian/ part of the debdiff since the
changes to the source itself are larger due to the nature of the
release.
unblock webkit2gtk/2.40.1-1
diff -Nru webkit2gtk-2.40.0/debian/changelog webkit2gtk-2.40.1/debian/changelog
--- webkit2gtk-2.40.0/debian/changelog 2023-03-21 18:11:48.0 +0100
+++ webkit2gtk-2.40.1/debian/changelog 2023-04-20 14:29:23.0 +0200
@@ -1,3 +1,15 @@
+webkit2gtk (2.40.1-1) unstable; urgency=high
+
+ * New upstream release.
+ * debian/rules:
+- Build with -DUSE_GBM=OFF in the Hurd (Closes: #1033999).
+ * Drop fix-script-message-received-marshaller.patch and
+fix-gst-crash.patch. Refresh all other patches.
+ * debian/copyright:
+- Update copyright information of all files.
+
+ -- Alberto Garcia Thu, 20 Apr 2023 14:29:23 +0200
+
webkit2gtk (2.40.0-3) unstable; urgency=medium
* debian/{rules,control.in}:
diff -Nru webkit2gtk-2.40.0/debian/copyright webkit2gtk-2.40.1/debian/copyright
--- webkit2gtk-2.40.0/debian/copyright 2023-03-21 18:11:48.0 +0100
+++ webkit2gtk-2.40.1/debian/copyright 2023-04-20 14:29:23.0 +0200
@@ -1923,8 +1923,6 @@
Source/WebCore/rendering/RenderTextInlines.h
Source/WebCore/rendering/RenderTheme.cpp
Source/WebCore/rendering/RenderTheme.h
- Source/WebCore/rendering/RenderThemeGtk.cpp
- Source/WebCore/rendering/RenderThemeGtk.h
Source/WebCore/rendering/RenderThemeMac.h
Source/WebCore/rendering/RenderThemeWin.cpp
Source/WebCore/rendering/RenderThemeWin.h
diff -Nru webkit2gtk-2.40.0/debian/patches/fix-ftbfs-m68k.patch
webkit2gtk-2.40.1/debian/patches/fix-ftbfs-m68k.patch
--- webkit2gtk-2.40.0/debian/patches/fix-ftbfs-m68k.patch 2023-03-21
18:11:48.0 +0100
+++ webkit2gtk-2.40.1/debian/patches/fix-ftbfs-m68k.patch 2023-04-20
14:29:23.0 +0200
@@ -158,7 +158,7 @@
namespace JSC {
template
-@@ -5497,3 +5502,6 @@ void printInternal(PrintStream& out, JSC
+@@ -5499,3 +5504,6 @@ void printInternal(PrintStream& out, JSC
} // namespace WTF
diff -Nru webkit2gtk-2.40.0/debian/patches/fix-gst-crash.patch
webkit2gtk-2.40.1/debian/patches/fix-gst-crash.patch
--- webkit2gtk-2.40.0/debian/patches/fix-gst-crash.patch2023-03-21
18:11:48.0 +0100
+++ webkit2gtk-2.40.1/debian/patches/fix-gst-crash.patch1970-01-01
01:00:00.0 +0100
@@ -1,65 +0,0 @@
-From: Philippe Normand
-Subject: Fix crash in webkit_media_stream_src_class_init()
-Bug: https://bugs.webkit.org/show_bug.cgi?id=254025
-Origin:
https://github.com/WebKit/WebKit/commit/358ce3a4bd7353c8edaa5720c949301f31c9a5e9
-Index:
webkitgtk/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
-===
webkitgtk.orig/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
-+++
webkitgtk/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
-@@ -2647,6 +2647,9 @@ MediaPlayer::SupportsType MediaP
Bug#1014030: conmon: Hang with lots of terminal output
On Tue, Jun 28, 2022 at 03:55:45PM -0600, Dan Nicholson wrote: > conmon 2.0.25 contains a bug where the container will hang when > there is lots of terminal output. You can easily reproduce like so: > > podman run -it --rm debian:latest > find / This is a very annoying bug. I confirm that the attached patch solves the problem for me. Berto
Bug#1033999: webkit2gtk: FTBFS on hurd-i386 (disable GBM support)
On Thu, Apr 06, 2023 at 10:04:34AM +0200, Laurent Bigonville wrote: > It seems that webkit FTBFS again on hurd-i386 > > The issue seems to be the fact that libgbm is missing: > > -- Could NOT find GBM (missing: GBM_LIBRARIES GBM_INCLUDE_DIR) I don't have an easy way to verify if that's enough to fix the build... I guess I can try on a VM first. Berto
Bug#1033644: libwebkit2gtk-4.1-0: WebKitWebProcess constantly segfaulting
On Wed, Mar 29, 2023 at 05:01:00PM +0200, karogyoker999 wrote: > For the others watching (if any): I have sent the core dump to Berto. The stack trace, for reference: Core was generated by `/usr/lib/i386-linux-gnu/webkit2gtk-4.1/WebKitWebProcess 12 18'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0xb59e2128 in WebCore::Font::Font () at ./Source/WebCore/platform/graphics/Font.cpp:89 89 , m_allowsAntialiasing(true) [Current thread is 1 (Thread 0xac0b3a00 (LWP 3370))] (gdb) bt #0 0xb59e2128 in WebCore::Font::Font () at ./Source/WebCore/platform/graphics/Font.cpp:89 #1 0xd0015949 in ?? () #2 0x010159eb in ?? () #3 0x in ?? () Berto
Bug#1033644: libwebkit2gtk-4.1-0: WebKitWebProcess constantly segfaulting
On Wed, Mar 29, 2023 at 02:33:14PM +0200, karogyoker999 wrote: > Yes, it is still crashing by running it that way. Do you think you would be able to obtain a core dump from one of those crashes? Berto
Bug#1033644: libwebkit2gtk-4.1-0: WebKitWebProcess constantly segfaulting
On Wed, Mar 29, 2023 at 06:22:25AM -0400, Karo Gyoker wrote: > If I try to open any page in epiphany-browser, nothing happens. The CPU is at > 100%. > I can see it in dmesg that WebKitWebProcess is constantly segfaulting. > > cat /proc/cpuinfo > processor : 0 > vendor_id : AuthenticAMD > cpu family: 6 > model : 10 > model name: AMD Athlon(tm) Can you try to set JavaScriptCoreUseJIT=0 in the environment and try again? Does it still crash? $ export JavaScriptCoreUseJIT=0 $ epiphany-browser Berto
Bug#1033568: unblock: gnome-calendar/43.1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package gnome-calendar [ Reason ] If the user tries to add a new calendar manually, the version of gnome-calendar currently in testing crashes while the user is typing the URI. This happens while the URI is incomplete because it is not validated before proceeding. [ Impact ] The application crashes suddenly and must be restarted with no clue about why the crash happened. [ Tests ] Tested manually, the bug is very easy to reproduce, simply typing 'https://' on the URL entry is enough. The new package also provides a test case. [ Risks ] Very low, this is the upstream patch for this bug and is very straightforward. [ 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 testing unblock gnome-calendar/43.1-2 diff -Nru gnome-calendar-43.1/debian/changelog gnome-calendar-43.1/debian/changelog --- gnome-calendar-43.1/debian/changelog2022-10-18 16:09:27.0 +0200 +++ gnome-calendar-43.1/debian/changelog2023-03-20 18:25:22.0 +0100 @@ -1,3 +1,14 @@ +gnome-calendar (43.1-2) unstable; urgency=high + + [ Alberto Garcia ] + * debian/patches/validate-uri.patch: +- Fix crash when adding an url manually (Closes: #1033239) + + [ Jeremy Bicha ] + * Branch for bookworm + + -- Alberto Garcia Mon, 20 Mar 2023 18:25:22 +0100 + gnome-calendar (43.1-1) unstable; urgency=high * New upstream release (LP: #1993308) diff -Nru gnome-calendar-43.1/debian/control gnome-calendar-43.1/debian/control --- gnome-calendar-43.1/debian/control 2022-10-18 16:09:27.0 +0200 +++ gnome-calendar-43.1/debian/control 2023-03-20 18:25:22.0 +0100 @@ -6,7 +6,7 @@ Section: gnome Priority: optional Maintainer: Debian GNOME Maintainers -Uploaders: Iain Lane , Jeremy Bicha , Laurent Bigonville +Uploaders: Jeremy Bicha Build-Depends: appstream-util, debhelper-compat (= 13), dh-sequence-gnome, @@ -29,8 +29,8 @@ xvfb , Standards-Version: 4.6.0 Rules-Requires-Root: no -Vcs-Browser: https://salsa.debian.org/gnome-team/gnome-calendar -Vcs-Git: https://salsa.debian.org/gnome-team/gnome-calendar.git +Vcs-Browser: https://salsa.debian.org/gnome-team/gnome-calendar/tree/debian/bookworm +Vcs-Git: https://salsa.debian.org/gnome-team/gnome-calendar.git -b debian/bookworm Homepage: https://wiki.gnome.org/Apps/Calendar Package: gnome-calendar diff -Nru gnome-calendar-43.1/debian/control.in gnome-calendar-43.1/debian/control.in --- gnome-calendar-43.1/debian/control.in 2022-10-18 16:09:27.0 +0200 +++ gnome-calendar-43.1/debian/control.in 2023-03-20 18:25:22.0 +0100 @@ -25,8 +25,8 @@ xvfb , Standards-Version: 4.6.0 Rules-Requires-Root: no -Vcs-Browser: https://salsa.debian.org/gnome-team/gnome-calendar -Vcs-Git: https://salsa.debian.org/gnome-team/gnome-calendar.git +Vcs-Browser: https://salsa.debian.org/gnome-team/gnome-calendar/tree/debian/bookworm +Vcs-Git: https://salsa.debian.org/gnome-team/gnome-calendar.git -b debian/bookworm Homepage: https://wiki.gnome.org/Apps/Calendar Package: gnome-calendar diff -Nru gnome-calendar-43.1/debian/gbp.conf gnome-calendar-43.1/debian/gbp.conf --- gnome-calendar-43.1/debian/gbp.conf 2022-10-18 16:09:27.0 +0200 +++ gnome-calendar-43.1/debian/gbp.conf 2023-03-20 18:25:22.0 +0100 @@ -1,6 +1,6 @@ [DEFAULT] pristine-tar = True -debian-branch = debian/master +debian-branch = debian/bookworm upstream-branch = upstream/latest [buildpackage] diff -Nru gnome-calendar-43.1/debian/patches/series gnome-calendar-43.1/debian/patches/series --- gnome-calendar-43.1/debian/patches/series 2022-10-18 16:09:27.0 +0200 +++ gnome-calendar-43.1/debian/patches/series 2023-03-20 18:25:22.0 +0100 @@ -0,0 +1 @@ +validate-uri.patch diff -Nru gnome-calendar-43.1/debian/patches/validate-uri.patch gnome-calendar-43.1/debian/patches/validate-uri.patch --- gnome-calendar-43.1/debian/patches/validate-uri.patch 1970-01-01 01:00:00.0 +0100 +++ gnome-calendar-43.1/debian/patches/validate-uri.patch 2023-03-20 18:25:22.0 +0100 @@ -0,0 +1,121 @@ +From: Georges Basile Stavracas Neto +Subject: Test URI before discovery +Bug: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/794 +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033239 +Origin: https://gitlab.gnome.org/GNOME/gnome-calendar/-/commit/0322bcf54cf1fc37ff74b87fd36e282dc1cf7863 +Index: gnome-calendar-43.1/src/utils/gcal-source-discoverer.c +=== +--- gnome-calendar-43.1.orig/src/utils/gcal-source-discoverer.c gnome-calendar-43.1/src/utils/gcal-source-discoverer.c +@@ -183,6 +183,26 @@ is_authentication_error (gint code) + return FALSE
Bug#1033239: libsoup-3.0-0: Crash when adding a new calendar in gnome-calendars
On Mon, Mar 27, 2023 at 08:02:39AM -0400, Jeremy Bícha wrote: > > I confirm that this patch fixes the problem. > > Thanks for preparing this patch. I'm uploading it to Unstable now. > Could you handle the unblock request? Yes, I can do it. Berto
Bug#1029206: [pre-approval] unblock: webkit2gtk 2.40.0-2
On Wed, Mar 08, 2023 at 09:36:23PM +, Alberto Garcia wrote:
> Upstream has just confirmed that the new WebKit API for GTK4 is
> final[1] so this is effectively a release candidate for WebKitGTK
> 2.40.0, to be released in ~10 days.
2.40.0-2 has been in unstable for a while, I had to upload 2.40.0-3
because of a missing dependency in arm that was causing an autopkgtest
to fail, all tests run fine now (mipsel is still missing but it worked
fine in 2.40.0-2 with no changes affecting mipsel since then).
This is tagged as 'moreinfo', is there anything else that I can
provide?
Berto
diff -Nru webkit2gtk-2.40.0/debian/changelog webkit2gtk-2.40.0/debian/changelog
--- webkit2gtk-2.40.0/debian/changelog 2023-03-18 11:41:32.0 +0100
+++ webkit2gtk-2.40.0/debian/changelog 2023-03-21 18:11:48.0 +0100
@@ -1,3 +1,10 @@
+webkit2gtk (2.40.0-3) unstable; urgency=medium
+
+ * debian/{rules,control.in}:
+- Add dependency on libgles2 on arm (Closes: #1033230).
+
+ -- Alberto Garcia Tue, 21 Mar 2023 18:11:48 +0100
+
webkit2gtk (2.40.0-2) unstable; urgency=medium
* debian/patches/fix-script-message-received-marshaller.patch:
diff -Nru webkit2gtk-2.40.0/debian/control webkit2gtk-2.40.0/debian/control
--- webkit2gtk-2.40.0/debian/control 2023-03-18 11:41:32.0 +0100
+++ webkit2gtk-2.40.0/debian/control 2023-03-21 18:11:48.0 +0100
@@ -180,6 +180,7 @@
gstreamer1.0-plugins-good,
${bwrap:Depends},
${shlibs:Depends},
+ ${gles:Depends},
${misc:Depends}
Recommends: gstreamer1.0-gl,
libgl1-mesa-dri,
@@ -311,6 +312,7 @@
gstreamer1.0-plugins-good,
${bwrap:Depends},
${shlibs:Depends},
+ ${gles:Depends},
${misc:Depends}
Recommends: gstreamer1.0-gl,
libgl1-mesa-dri,
@@ -442,6 +444,7 @@
gstreamer1.0-plugins-good,
${bwrap:Depends},
${shlibs:Depends},
+ ${gles:Depends},
${misc:Depends}
Recommends: gstreamer1.0-gl,
libgl1-mesa-dri,
diff -Nru webkit2gtk-2.40.0/debian/control-common.in webkit2gtk-2.40.0/debian/control-common.in
--- webkit2gtk-2.40.0/debian/control-common.in 2023-03-18 11:41:32.0 +0100
+++ webkit2gtk-2.40.0/debian/control-common.in 2023-03-21 18:11:48.0 +0100
@@ -61,6 +61,7 @@
gstreamer1.0-plugins-good,
${bwrap:Depends},
${shlibs:Depends},
+ ${gles:Depends},
${misc:Depends}
Recommends: gstreamer1.0-gl,
libgl1-mesa-dri,
diff -Nru webkit2gtk-2.40.0/debian/rules webkit2gtk-2.40.0/debian/rules
--- webkit2gtk-2.40.0/debian/rules 2023-03-18 11:41:32.0 +0100
+++ webkit2gtk-2.40.0/debian/rules 2023-03-21 18:11:48.0 +0100
@@ -148,6 +148,11 @@
DH_GENCONTROL_ARGS += -Vgst:Recommends="gstreamer1.0-libav, gstreamer1.0-plugins-bad"
endif
+# This is loaded at runtime using libepoxy so add an explicit dependency (#1033230)
+ifneq (,$(filter $(DEB_HOST_ARCH),arm64 armel armhf))
+ DH_GENCONTROL_ARGS += -Vgles:Depends="libgles2"
+endif
+
CXXFLAGS=$(CFLAGS)
# Disable commands and binary packages of the builds that we don't want
