Bug#1082148: webkit2gtk: broken on armhf

[Alberto Garcia]

On Wed, Sep 18, 2024 at 02:58:15PM -0400, Jeremy Bícha wrote:
> webkit2gtk is currently broken on armhf with the new 2.46.0 release.
> This was detected with autopkgtest failures. See
> https://launchpad.net/bugs/2081093

I was testing ealier versions of the WebKitGTK packages and I saw that
those < 2.45.91 don't crash.

So this bug seems to be a consequence of me disabling bmalloc in order
to fix a build failure in armhf starting from 2.45.91:

   https://bugs.webkit.org/show_bug.cgi?id=278858

I managed to build 2.46.0 with bmalloc using the change described
there and it seems to fix the crash, I'm currently rebuilding the
package to double check.

Berto

Bug#1082149: webkit2gtk: causes epiphany-browser to fail to build on s390x

[Alberto Garcia]

Control: tags -1 pending

On Wed, Sep 18, 2024 at 03:00:22PM -0400, Jeremy Bícha wrote:
> Could you cherry-pick the upstream fix for epiphany-browser's s390x
> build for your next upload?

This should be it, thanks:

   
https://salsa.debian.org/webkit-team/webkit/-/commit/8bb1ac3c66d9934ca651d808af14191fb25e9910

Berto

Bug#1066411: webkit2gtk: FTBFS: SharedContextMutex.cpp:219:41: error: inlining failed in call to ‘always_inline’ ‘egl::SharedContextMutex* egl::SharedContextMutex::doTryLock() [with Mute

[Alberto Garcia]

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

[Alberto Garcia]

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#1063223: wpewebkit: NMU diff for 64-bit time_t transition

[Alberto Garcia]

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#1062540: event-dance: NMU diff for 64-bit time_t transition

[Alberto Garcia]

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

[Alberto Garcia]

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#1057967: linux-image-6.1.0-15-amd64 renders my physical bookworm/gnome computer largely unusable

[Alberto Garcia]

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 system

Bug#1054150: surf: no longer display web pages after webkitgtk upgrades

[Alberto Garcia]

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

[Alberto Garcia]

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#1037894: webkit2gtk: ftbfs with GCC-13

[Alberto Garcia]

On Tue, Sep 12, 2023 at 10:28:06AM +0200, Manuel A. Fernandez Montecelo wrote:
> > FYI I have successfully built webkit2gtk 2.40.3-2 in a sid chroot with
> > with gcc-13 13.1.0-7 from experimental.
> 
> Also it built fine with gcc-13 in riscv64, which was rebootstrapped
> in the last weeks and with gcc-13 as the default compiler since the
> start.
> 
> Build for the new archive:
> 
>   2.40.5-1 (sid)  Maybe-Successful  2023-08-28 19:38:30
>   rv-osuosl-03  2d 10h 31m  23.91 GB
> 
>   https://buildd.debian.org/status/logs.php?pkg=webkit2gtk&arch=riscv64
> 
> So I think that this can be closed.

Matthias, what do you say, can we close this?

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.

[Alberto Garcia]

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.

[Alberto Garcia]

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.

Bug#1033230: webkit2gtk: version 2.39.90-1 lost its libgles2 runtime dependency

[Alberto Garcia]

On Mon, Mar 20, 2023 at 01:29:51PM +0100, Gianfranco Costamagna wrote:

> Hello, for some reasons, now webkit2gtk is not linking anymore
> libGLESv2.so.2 causing surf to fail autopkgtests on arm64 and armhf

Hmmm... the reason is that this is now handled via libepoxy, which
opens libGLESv2.so.2 on runtime using dlopen().

I think that I'll add the dependencies manually for now, but I wonder
if libepoxy should depend on those libraries instead?

Berto

Bug#1033224: gnome-builder: Depends on obsolete gir1.2-webkit2-5.0 package

[Alberto Garcia]

On Mon, Mar 20, 2023 at 09:48:36AM -0400, Jeremy Bícha wrote:

> This was a mistake in cherry-picking from the Experimental branch
> where I had previously applied
> https://salsa.debian.org/gnome-team/gnome-builder/-/commit/f87150bc

Maybe it's not a bad idea to let gir:Depends handle this instead, also
for bookworm. But either option is fine with me.

Berto

Bug#1033224: gnome-builder: Depends on obsolete gir1.2-webkit2-5.0 package

[Alberto Garcia]

Control: tags -1 patch

debdiff attached

Berto
diff -Nru gnome-builder-43.6/debian/changelog 
gnome-builder-43.6/debian/changelog
--- gnome-builder-43.6/debian/changelog 2023-03-16 01:29:37.0 +0100
+++ gnome-builder-43.6/debian/changelog 2023-03-20 12:45:40.0 +0100
@@ -1,3 +1,11 @@
+gnome-builder (43.6-3) unstable; urgency=medium
+
+  * Team upload
+  * debian/control.in: depend on gir1.2-webkit-6.0 instead of 5.0
+(Closes: #1033224)
+
+ -- Alberto Garcia   Mon, 20 Mar 2023 12:45:40 +0100
+
 gnome-builder (43.6-2) unstable; urgency=medium
 
   * debian/gbp.conf, debian/control.in: Branch for bookworm
diff -Nru gnome-builder-43.6/debian/control gnome-builder-43.6/debian/control
--- gnome-builder-43.6/debian/control   2023-03-16 01:29:37.0 +0100
+++ gnome-builder-43.6/debian/control   2023-03-20 12:45:40.0 +0100
@@ -6,7 +6,7 @@
 Section: editors
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

-Uploaders: Jeremy Bicha 
+Uploaders: Alberto Garcia , Jeremy Bicha 
 Build-Depends: appstream-util,
at-spi2-core ,
ca-certificates ,
@@ -77,7 +77,7 @@
  gir1.2-jsonrpc-1.0 (>= 3.42.0),
  gir1.2-panel-1 (>= 1.0.0),
  gir1.2-peas-1.0 (>= 1.34.0),
- gir1.2-webkit2-5.0,
+ gir1.2-webkit-6.0,
  python3-gi,
  libvala-dev,
  clang,
diff -Nru gnome-builder-43.6/debian/control.in 
gnome-builder-43.6/debian/control.in
--- gnome-builder-43.6/debian/control.in2023-03-16 01:29:37.0 
+0100
+++ gnome-builder-43.6/debian/control.in2023-03-20 12:45:40.0 
+0100
@@ -73,7 +73,7 @@
  gir1.2-jsonrpc-1.0 (>= 3.42.0),
  gir1.2-panel-1 (>= 1.0.0),
  gir1.2-peas-1.0 (>= 1.34.0),
- gir1.2-webkit2-5.0,
+ gir1.2-webkit-6.0,
  python3-gi,
  libvala-dev,
  clang,

Bug#1033224: gnome-builder: Depends on obsolete gir1.2-webkit2-5.0 package

[Alberto Garcia]

Package: gnome-builder
Version: 43.6-2
Severity: serious
Justification: Policy 7.2

gnome-builder 43.6-2 switched the build dependency from WebtKitGTK 5.0
to 6.0 since the former API is no longer available and is going away.

However it still contains a dependency on gir1.2-webkit2-5.0, so it
effectively depends on both 5.0 and 6.0 API builds of WebKitGTK.

Related bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029206

Berto

Bug#1016936: dwz: fails while building assaultcube

[Alberto Garcia]

On Wed, Aug 10, 2022 at 08:03:45AM +0200, Andreas Beckmann wrote:
> dwz: debian/assaultcube/usr/lib/games/assaultcube/ac_client: Unknown 
> debugging section .debug_addr
> dwz: debian/assaultcube/usr/lib/games/assaultcube/ac_server: Unknown 
> debugging section .debug_addr

FWIW this kind of errors can also happen with GCC with -gsplit-dwarf,
I just hit it in WebKitGTK:

   https://gcc.gnu.org/wiki/DebugFission

Berto

Bug#1020642: webkit2gtk: FTBFS on mipsel: virtual memory exhausted

[Alberto Garcia]

On Mon, Sep 26, 2022 at 04:00:30PM +0300, Adrian Bunk wrote:
> I had the worst possible outcome on the porterbox:
> The reference build succeeded unchanged.  :-(
> 
> I'll check again if your disabling of unified builds does not work.

I decided to upload 2.38.0-2 without unified builds, hopefully it'll
work.

Berto

Bug#1020642: webkit2gtk: FTBFS on mipsel: virtual memory exhausted

[Alberto Garcia]

On Sun, Sep 25, 2022 at 10:03:15AM +0200, Mathieu Malaterre wrote:
> On Sat, Sep 24, 2022 at 7:42 PM Simon McVittie  wrote:
> > webkit2gtk repeatedly failed to compile on the mipsel buildds:
> 
> Here is the trick I used on those arches for openvdb:
> 
> [...]
> # Disable optimization on mipsel because the compiler is running out of memory
> # see #847752 / #879636
> ifneq (,$(filter $(DEB_BUILD_ARCH), armel armhf i386 mipsel hppa
> riscv64 sh4 x32))
>   CXXFLAGS:=$(filter-out -O2,$(CXXFLAGS)) --param ggc-min-expand=10 -O1
> endif

At the moment we are using -Os --param ggc-min-expand=10

   
https://salsa.debian.org/webkit-team/webkit/-/blob/debian/2.38.0-1/debian/rules#L66

I'll try disabling unified builds.

Berto

Bug#1020642: webkit2gtk: FTBFS on mipsel: virtual memory exhausted

[Alberto Garcia]

On Sat, Sep 24, 2022 at 06:39:25PM +0100, Simon McVittie wrote:

> webkit2gtk repeatedly failed to compile on the mipsel buildds:
> 
> :
> > FAILED: 
> > Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-3a52ce78-32.cpp.o
> >  
> > /usr/bin/ccache /usr/bin/c++ [long command-line removed]
> > virtual memory exhausted: Cannot allocate memory
> 
> Can we perhaps disable the use of "unified" sources (fewer, larger
> translation units) for architectures where address space is
> limited?  Or maybe tell the compiler not to attempt memory-hungry
> optimizations, or something like that?

I was talking to Adrian Bunk about this a couple of days ago, he
was trying to build webkit in a mipsel buildd using different
alternatives.

Adrian, did you figure something out?

> I see this unreleased commit is available in git:
> https://salsa.debian.org/webkit-team/webkit/-/commit/e92e4c4654e6fd116ef30c5cc767cc25b675ed1f
> which might also help.

According to Adrian it probably won't (I didn't test it yet).

Berto

Bug#855541: purple-matrix: Not ready for release yet

[Alberto Garcia]

On Tue, Nov 09, 2021 at 09:22:36PM +0100, Alberto Garcia wrote:

> FYI I decided to give this package for adoption. I'll request its
> removal from the archive if there are no volunteers to take over its
> maintenance after some time.
> 
> https://bugs.debian.org/998660

I just requested its removal:

https://bugs.debian.org/1018077

Berto

Bug#1016224: binutils-z80: FTBFS: stdlib.h:134:10: error: argument 1 is null but the corresponding size argument 3 value is [128, 9223372036854775807] [-Werror=nonnull]

[Alberto Garcia]

Control: tags -1 fixed-upstream

On Fri, Jul 29, 2022 at 06:20:14PM +0200, Lucas Nussbaum wrote:

> During a rebuild of all packages in sid, your package failed to build
> on amd64.

> > In function ‘mbstowcs’,
> > inlined from ‘read_symbol_name’ at read.c:1670:11:
> > /usr/include/x86_64-linux-gnu/bits/stdlib.h:134:10: error: argument 1 is 
> > null but the corresponding size argument 3 value is [128, 
> > 9223372036854775807] [-Werror=nonnull]
> >   134 |   return __mbstowcs_alias (__dst, __src, __len);
> >   |  ^~

Hi,

this has been fixed in binutils upstream, is the normal binutils
package not affected?

   
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5858ac626e548772407c038b09b7837550b127dd

I can fix this in binutils-z80 but I'd rather have the fix in the
binutils-source package directly.

Berto

Bug#1010166: webkit2gtk: 2.36.1-1 apparent regression seen in devhelp autopkgtest

[Alberto Garcia]

On Mon, Apr 25, 2022 at 11:37:02AM -0400, Jeremy Bicha wrote:

> The new release of webkit2gtk won't migrate to Testing because of an
> autopkgtest regression in devhelp. I'm filing this bug to make sure
> that the maintainer notices the issue.

This has been fixed upstream but I think I'll just wait for the next
stable release instead of patching the current one.

Berto

Bug#1010352: wpewebkit: No longer provides libsoup2 version needed by gstreamer

[Alberto Garcia]

On Fri, Apr 29, 2022 at 06:56:45AM -0400, Jeremy Bicha wrote:

> wpewebkit has 2 reverse dependencies in Debian: cog and
> gstreamer1.0-wpe. Although cog was switched to use the new libsoup3,
> gstreamer1.0-wpe was not.

This is already fixed: https://bugs.debian.org/1009721

It was planned with the gst maintainer so it should have been seamless
but I guess we failed :-/

> Also, the package names in debian/control do not match the actual
> package names built. I believe this is a violation of Debian Policy.
> (Also it appears to break Ubuntu's NBS tracker.)

It lists both versions but we only build one or the other depending on
the target distro. If it causes breakage I guess I'll change it.

> I suggest you do like webkit2gtk and offer both libsoup2 and
> libsoup3 for now if you want to have the libsoup3 version available.

No need to do that since there's only two reverse dependencies.

Berto

Bug#1008424: audiofile: FTBFS: dh_auto_test: error: make -j8 check VERBOSE=1 returned exit code 2

[Alberto Garcia]

reassign 1008424 src:flac 1.3.4-1
affects 1008424 src:audiofile
retitle 1008424 flac 1.3.4 makes audiofile FTBFS
forwarded 1008424 https://github.com/xiph/flac/issues/327
tags 1008424 patch
thanks

On Sat, Apr 23, 2022 at 01:48:17AM +0200, Alberto Garcia wrote:
> I submitted a bug report upstream: https://github.com/xiph/flac/issues/327

So it seems that the problem is in flac after all, I'm reassigning the
bug to that package.

Berto

Bug#1008424: audiofile: FTBFS: dh_auto_test: error: make -j8 check VERBOSE=1 returned exit code 2

[Alberto Garcia]

On Mon, Apr 04, 2022 at 03:25:44PM +0200, Alberto Garcia wrote:

> > During a rebuild of all packages in sid, your package failed to
> > build on amd64.
> > 
> > > FAIL: FLAC
> 
> This started to happen after flac was updated from 1.3.3-2 to 1.3.4-1.

I bisected the changes in flac and the problems started here:

   commit 159cd6c41a6ec17b36d74043c45a3aa64de90d5e
   Author: Robert Kausch 
   Date:   Thu Oct 29 20:37:40 2020 +0100

   libFLAC/stream_decoder.c: Use current position as bound when seeking

I submitted a bug report upstream: https://github.com/xiph/flac/issues/327

Berto

Bug#1008424: audiofile: FTBFS: dh_auto_test: error: make -j8 check VERBOSE=1 returned exit code 2

[Alberto Garcia]

On Sat, Mar 26, 2022 at 10:03:42PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> > FAIL: FLAC

This started to happen after flac was updated from 1.3.3-2 to 1.3.4-1.

Downgrading the flac packages makes audiofile build fine again.

Berto

Bug#1005810: epiphany-browser: crash on session_tab_free at ../src/ephy-session.c:605

[Alberto Garcia]

Control: tags -1 patch fixed-upstream
Control: forwarded -1 
https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/954

On Tue, Feb 15, 2022 at 04:29:52PM +0200, Andres Gomez wrote:
> After talking with the main WebKitGtk developer and maintainer,
> he pointed that the cause of the crash actually laid in
> epiphany-browser and, specifically, the reason for the crash had
> been already addressed upstream in the following issue:
> 
> https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/954

I'm attaching the debdiff with this fix. If this fixes the issue I
think we should upload it to bullseye.

Berto
diff -Nru epiphany-browser-3.38.2/debian/changelog epiphany-browser-3.38.2/debian/changelog
--- epiphany-browser-3.38.2/debian/changelog	2022-01-12 18:33:21.0 +0100
+++ epiphany-browser-3.38.2/debian/changelog	2022-02-23 17:34:35.0 +0100
@@ -1,3 +1,11 @@
+epiphany-browser (3.38.2-1+deb11u2) bullseye; urgency=medium
+
+  * d/p/glib-bug-workaround.patch:
+- Cherry pick upstream patch ff8ecbf6. This works around a bug in GLib
+  and fixes a UI process crash (Closes: #1005810).
+
+ -- Alberto Garcia   Wed, 23 Feb 2022 17:34:35 +0100
+
 epiphany-browser (3.38.2-1+deb11u1) bullseye-security; urgency=medium
 
   * d/p/encode-untrusted-data.patch:
diff -Nru epiphany-browser-3.38.2/debian/patches/glib-bug-workaround.patch epiphany-browser-3.38.2/debian/patches/glib-bug-workaround.patch
--- epiphany-browser-3.38.2/debian/patches/glib-bug-workaround.patch	1970-01-01 01:00:00.0 +0100
+++ epiphany-browser-3.38.2/debian/patches/glib-bug-workaround.patch	2022-02-23 17:31:38.0 +0100
@@ -0,0 +1,30 @@
+From: Michael Catanzaro 
+Subject: remove user data from task to workaround glib bug
+Origin: https://gitlab.gnome.org/GNOME/epiphany/-/commit/ff8ecbf673cd25f8ed34d4ccb29cc5d3d13cd683
+Bug-Debian: https://bugs.debian.org/1005810
+Index: epiphany-browser-3.38.2/src/ephy-session.c
+===
+--- epiphany-browser-3.38.2.orig/src/ephy-session.c
 epiphany-browser-3.38.2/src/ephy-session.c
+@@ -844,6 +844,12 @@ save_session_in_thread_finished_cb (GObj
+ gpointer  user_data)
+ {
+   g_application_release (G_APPLICATION (ephy_shell_get_default ()));
++
++  /* FIXME: this is a workaround for https://gitlab.gnome.org/GNOME/glib/-/issues/1346.
++   * After this GLib issue is fixed, we should instead pass save_data_free() as the
++   * GDestroyNotify parameter to g_task_set_task_data().
++   */
++  save_data_free (g_task_get_task_data (G_TASK (res)));
+ }
+ 
+ static gboolean
+@@ -1026,7 +1032,7 @@ ephy_session_save_idle_cb (EphySession *
+   session->save_cancellable = g_cancellable_new ();
+   task = g_task_new (session, session->save_cancellable,
+  save_session_in_thread_finished_cb, NULL);
+-  g_task_set_task_data (task, data, (GDestroyNotify)save_data_free);
++  g_task_set_task_data (task, data, NULL);
+   g_task_run_in_thread (task, save_session_sync);
+   g_object_unref (task);
+ 
diff -Nru epiphany-browser-3.38.2/debian/patches/series epiphany-browser-3.38.2/debian/patches/series
--- epiphany-browser-3.38.2/debian/patches/series	2022-01-12 18:33:21.0 +0100
+++ epiphany-browser-3.38.2/debian/patches/series	2022-02-23 17:28:18.0 +0100
@@ -3,3 +3,4 @@
 dont-make-compulsory.patch
 build-Allow-libportal-support-to-be-disabled.patch
 encode-untrusted-data.patch
+glib-bug-workaround.patch

Bug#1005518: frogr: FTBFS: ../data/meson.build:32:5: ERROR: Function does not take positional arguments.

[Alberto Garcia]

On Sun, Feb 13, 2022 at 08:27:19AM +0100, Lucas Nussbaum wrote:

> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> > Configuring org.gnome.frogr.desktop.in using configuration
> > 
> > ../data/meson.build:32:5: ERROR: Function does not take positional 
> > arguments.

For reference, this is the reason why it fails:

   https://github.com/mesonbuild/meson/issues/9441

If you follow the link you'll see that lots of GNOME apps were
affected by this.

I'll prepare a fixed version of Frogr soon.

Berto

Bug#1005120: wpewebkit: Fails to build with gstreamer 1.20

[Alberto Garcia]

On Mon, Feb 07, 2022 at 10:53:56AM -0500, Jeremy Bicha wrote:
> wpewebkit fails to build from source, apparently because of the recent
> gstreamer 1.20 uploads.
> 
> -- Checking for module 'gstreamer-codecparsers-1.0 >= 1.14.0'
> --   No package 'gstreamer-codecparsers-1.0' found
> 
> That .pc file is provided by libgstreamer-plugins-bad1.0-dev so
> maybe you just need to Build-Depend on that.

As far as I'm aware gstreamer-codecparsers-1.0 is not needed in the
default build, the problem that I'm seeing here is this one:

   CMake Error at Source/cmake/GStreamerChecks.cmake:50 (message):
  GStreamerGL is needed for USE_GSTREAMER_GL.

GStreamerGL is however installed. The reason why this fails is this
one:

   # pkg-config --cflags gstreamer-gl-1.0
   Package gudev-1.0 was not found in the pkg-config search path.
   Perhaps you should add the directory containing `gudev-1.0.pc'

So I understand that libgstreamer-plugins-base1.0-dev would need to
depend on libgudev-1.0-dev, right Sebastian?

Berto

Bug#855541: purple-matrix: Not ready for release yet

[Alberto Garcia]

On Mon, Sep 28, 2020 at 07:03:45PM +0200, Alberto Garcia wrote:
> I think that this project is essentially dead, there has never been
> a release and as you say there hasn't been changes in almost a year.
> 
> I have stopped using it myself and the reason why I didn't ask for
> its removal from Debian is that it's a very small package with a
> very low manteinance burden (and because popcon shows that it has
> some users).

FYI I decided to give this package for adoption. I'll request its
removal from the archive if there are no volunteers to take over its
maintenance after some time.

https://bugs.debian.org/998660

Berto

Bug#989332: libwebkit2gtk-4.0-37: May 30 upgrade for DSA-4923-1 broke the epiphany browser

[Alberto Garcia]

On Thu, Jun 03, 2021 at 01:37:45AM +0200, Jose wrote:
> > Can you install gstreamer1.0-plugins-good and try again?
> 
> That was the issue. Thank you for helping.
> 
> I don't understand why it was working before the libwebkit2gtk
> update.  Maybe this is a dependency that should be added to the
> epiphany package?

WebKitGTK requires gstreamer1.0-plugins-good in order to play audio.
In earlier versions if the plugins were not found it would simply not
play any audio but continue browsing (that's why the plugins are not a
hard dependency but a recommendation).

This changed in WebKitGTK 2.32, so we either have to make it a
dependency or make it work again without the plugins installed.

I'll fix this for bullseye, but I'm not sure if there will be a new
security update just for this.

Berto

Bug#989332: libwebkit2gtk-4.0-37: May 30 upgrade for DSA-4923-1 broke the epiphany browser

[Alberto Garcia]

On Wed, Jun 02, 2021 at 09:21:54PM +0200, Jose wrote:
> Berto,
> 
> Thanks.
> 
> Here is the full gdb bt after installing the debug symbols.
> 
> Please tell me if you'd like me to do any additional tests
> or debugging.
> 
> --josé

> #0  0x7f707b64e7bb in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x7f707b639535 in __GI_abort () at abort.c:79
> #2  0x7f7080746085 in CRASH_WITH_INFO(...) () at 
> DerivedSources/ForwardingHeaders/wtf/Assertions.h:713
> #3  0x7f7080746085 in 
> WebCore::MediaPlayerPrivateGStreamer::createAudioSink() ()
> at 
> ../Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:1322

Can you install gstreamer1.0-plugins-good and try again?

Berto

Bug#989332: libwebkit2gtk-4.0-37: May 30 upgrade for DSA-4923-1 broke the epiphany browser

[Alberto Garcia]

On Wed, Jun 02, 2021 at 06:11:56PM +0200, Jose wrote:
> Hi Berto,
> 
> Sorry for the delay. Yopmail went down a little bit after I sent my
> initial report.
> 
> Discord still crashes for me. I'm attaching the gdb trace you
> requested. I opened epiphany with a blank home screen, then went
> to the discord site and clicked on "open discord in the browser"
> 
> As you can see, I have the same version of epiphany that you used
> in your own test:
> 
>   Installed: 3.32.1.2-3~deb10u1
>   Candidate: 3.32.1.2-3~deb10u1
> 
> I may be able to reproduce the error due to my using discord and belonging
> to some servers. This may make epiphany/webkit or the associated 
> javascript do some rendering or something I don't know that used to work
> and stopped after the libwebkit patch. It's just normal discord servers,
> nothing hacked or fancy afaik.

Yes, I guess the reason is the servers you belong to because I really
cannot reproduce the problem.

If you run Epiphany from the command line, does it show any error
message when it crashes? There's an abort() there which might give us
a clue (the rest of the backtrace if unfortunately not very useful
without the symbols).

Also, can you try with the Minibrowser?

$ /usr/lib/*/webkit2gtk-4.0/MiniBrowser https://discord.com

One more thing, you can also try without the JIT:

$ JavaScriptCoreUseJIT=0 epiphany

If this last one doesn't crash, can you tell me what CPU model does
your computer have?

> If you'd like me to download the debug symbols and generate another
> bt, please tell me so.

Unfortunately they don't seem to be available yet for your build:

http://debug.mirrors.debian.org/debian-debug/pool/main/w/webkit2gtk/

You would need to build them yourself (or I can also provide the debug
packages for you if you prefer).

Berto

Bug#989332: libwebkit2gtk-4.0-37: May 30 upgrade for DSA-4923-1 broke the epiphany browser

[Alberto Garcia]

On Tue, Jun 01, 2021 at 12:19:26PM +0200, jose wrote:

> Epiphany is based on libwebkit2. I access discord as a web app on
> epiphany.  To do so I go to the discord site [1] and click on "Open
> Discord in your browser".
> 
> Since the upgrade this systematically results in epiphany
> complaining with a "Something went wrong while displaying this
> page".

FWIW I just logged in to Discord just fine with webkit 2.32.1-1~deb10u1
and Epiphany 3.32.1.2-3~deb10u1.

Berto

Bug#987686: webkit2gtk breaks balsa autopkgtest: xwd: error: No window with name Balsa exists!

[Alberto Garcia]

On Fri, May 21, 2021 at 09:28:02PM +0200, Paul Gevers wrote:
> > In webkit2gtk 2.32.1-1 the dependency on xdg-desktop-portal-gtk was
> > downgraded to a recommendation so the test no longer fails.
> 
> balsa is close to autoremoval from bullseye because of this issue.
> Should xdg-desktop-portal-gtk really be a Depends? (Having the
> possibility to downgrade the dependency suggest it *is* not a
> dependency).
> 
> > The underlying cause is still there so I don't know if you want to
> > keep this bug report open to look for a proper solution.
> 
> If you're OK with keeping the downgraded dependency then I think
> this bug can be downgraded too.

Arguably this bug could be closed since the test no longer fails,
although I think it's useful to keep it open in order to track the
issue. But that's up to the Balsa maintainers in my opinion.

In any case I would definitely reduce the severity of the bug, I just
didn't want to do it on behalf of the original reporter :)

Berto

Bug#987686: webkit2gtk breaks balsa autopkgtest: xwd: error: No window with name Balsa exists!

[Alberto Garcia]

On Tue, Apr 27, 2021 at 11:27:32PM +0200, Alberto Garcia wrote:

> Nothing to do with webkit actually. The test launches Balsa, waits
> for two seconds and then takes a screenshot of the window. The bug
> happens because when xdg-desktop-portal-gtk is installed Balsa takes
> a very long time to start so those two seconds are not enough.

In webkit2gtk 2.32.1-1 the dependency on xdg-desktop-portal-gtk was
downgraded to a recommendation so the test no longer fails.

The underlying cause is still there so I don't know if you want to
keep this bug report open to look for a proper solution.

Berto

Bug#987686: webkit2gtk breaks balsa autopkgtest: xwd: error: No window with name Balsa exists!

[Alberto Garcia]

Control: found -1 balsa/2.6.1-1

On Tue, Apr 27, 2021 at 11:27:32PM +0200, Alberto Garcia wrote:
> The bug happens because when xdg-desktop-portal-gtk is installed
> Balsa takes a very long time to start so those two seconds are not
> enough.
> 
> g_application_register() calls g_dbus_proxy_new_sync(), and
> that times out. The problem seems to disappear if you unset
> DBUS_SESSION_BUS_ADDRESS, but that's a workaround I guess :)

I'm thinking that this should probably be fixed for bullseye. It may
not fail at the moment because xdg-desktop-portal-gtk is not installed
during the test, but webkit2gtk 2.32.x will make it to bullseye sooner
or later through a security release.

So I think it makes sense to at least apply the workaround?

I'm also attaching the full backtrace of the point where Balsa hangs
during the test.

Berto
(gdb) bt
#0  0x732113ff in __GI___poll (fds=0x55823e00, nfds=1, 
timeout=25000) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x733af0ae in g_main_context_poll (priority=, 
n_fds=1, fds=0x55823e00, timeout=, context=0x55866c00) 
at ../../../glib/gmain.c:4422
#2  g_main_context_iterate (context=0x55866c00, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4114
#3  0x733af40b in g_main_loop_run (loop=0x557e6c70) at 
../../../glib/gmain.c:4317
#4  0x735ff214 in initable_init (initable=0x5578cab0, 
cancellable=0x0, error=0x7fffda50) at ../../../gio/gdbusproxy.c:1903
#5  0x735608e2 in g_initable_new_valist (object_type=, 
first_property_name=0x7363283a "g-flags", 
var_args=var_args@entry=0x7fffd8a0, cancellable=cancellable@entry=0x0, 
error=error@entry=0x7fffda50) at ../../../gio/ginitable.c:248
#6  0x73560999 in g_initable_new 
(object_type=object_type@entry=93824994070512, 
cancellable=cancellable@entry=0x0, error=error@entry=0x7fffda50, 
first_property_name=first_property_name@entry=0x7363283a "g-flags") at 
../../../gio/ginitable.c:162
#7  0x73600913 in g_dbus_proxy_new_sync (connection=0x557180b0, 
flags=G_DBUS_PROXY_FLAGS_NONE, info=info@entry=0x0, 
name=name@entry=0x73d95460 "org.freedesktop.portal.Desktop", 
object_path=0x73d954a8 "/org/freedesktop/portal/desktop", 
interface_name=0x73e01cd0 "org.freedesktop.portal.Inhibit", 
cancellable=0x0, error=0x7fffda50) at ../../../gio/gdbusproxy.c:2093
#8  0x73d604ee in gtk_application_get_proxy_if_service_present 
(connection=, flags=, bus_name=0x73d95460 
"org.freedesktop.portal.Desktop", object_path=, 
interface=, error=0x7fffda50) at 
../../../../gtk/gtkapplication-dbus.c:132
#9  0x73d60678 in gtk_application_impl_dbus_startup 
(impl=0x55825500, register_session=1) at 
../../../../gtk/gtkapplication-dbus.c:461
#10 0x73a93690 in gtk_application_startup 
(g_application=0x557090f0) at ../../../../gtk/gtkapplication.c:307
#11 0x734a00a2 in g_closure_invoke 
(closure=closure@entry=0x557036e0, return_value=return_value@entry=0x0, 
n_param_values=1, param_values=param_values@entry=0x7fffdd10, 
invocation_hint=invocation_hint@entry=0x7fffdc90) at 
../../../gobject/gclosure.c:810
#12 0x734b20aa in signal_emit_unlocked_R 
(node=node@entry=0x55703710, detail=detail@entry=0, 
instance=instance@entry=0x557090f0, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffdd10) at 
../../../gobject/gsignal.c:3669
#13 0x734b86cf in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fffde90) at ../../../gobject/gsignal.c:3495
#14 0x734b8c3f in g_signal_emit 
(instance=instance@entry=0x557090f0, signal_id=, 
detail=detail@entry=0) at ../../../gobject/gsignal.c:3551
#15 0x735c4d92 in g_application_register 
(application=application@entry=0x557090f0, 
cancellable=cancellable@entry=0x0, error=error@entry=0x7fffdfb0) at 
../../../gio/gapplication.c:2204
#16 0x735c517a in g_application_real_local_command_line 
(application=0x557090f0, arguments=0x7fffe018, 
exit_status=0x7fffe014) at ../../../gio/gapplication.c:1106
#17 0x735c54ae in g_application_run (application=0x557090f0, 
argc=-8172, argc@entry=2, argv=argv@entry=0x7fffe188) at 
../../../gio/gapplication.c:2528
#18 0x555881e5 in main (argc=2, argv=0x7fffe188) at main.c:786

Bug#987686: webkit2gtk breaks balsa autopkgtest: xwd: error: No window with name Balsa exists!

[Alberto Garcia]

Control: notfound -1 webkit2gtk/2.32.0-2

On Tue, Apr 27, 2021 at 09:27:35PM +0200, Paul Gevers wrote:

> With a recent upload of webkit2gtk the autopkgtest of balsa fails
> in testing when that autopkgtest is run with the binary packages of
> webkit2gtk from unstable.

Nothing to do with webkit actually. The test launches Balsa, waits for
two seconds and then takes a screenshot of the window. The bug happens
because when xdg-desktop-portal-gtk is installed Balsa takes a very
long time to start so those two seconds are not enough.

g_application_register() calls g_dbus_proxy_new_sync(), and
that times out. The problem seems to disappear if you unset
DBUS_SESSION_BUS_ADDRESS, but that's a workaround I guess :)

I haven't debugged why this happens when xdg-desktop-portal-gtk is
installed.

More information here:

   https://bugs.launchpad.net/ubuntu/+source/webkit2gtk/+bug/1923817

Berto

Bug#987448: webkit2gtk regression: liferea: CSS for the posts is broken

[Alberto Garcia]

On Sat, Apr 24, 2021 at 09:52:51AM +0800, Paul Wise wrote:
> The recent upgrade to webkit2gtk 2.32.0-2 broke the CSS that the
> liferea RSS reader uses to style the HTML it injects for post
> metadata.

So it seems that this is a problem in Liferea after all.

webkit2gtk is covered by security support and version 2.32 will
eventually make it into bullseye, so I guess we have to apply this
liferea fix there as well?

Berto

Bug#987448: webkit2gtk regression: liferea: CSS for the posts is broken

[Alberto Garcia]

Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=225036
Control: tags -1 upstream

On Sat, Apr 24, 2021 at 09:52:51AM +0800, Paul Wise wrote:

> The recent upgrade to webkit2gtk 2.32.0-2 broke the CSS that the
> liferea RSS reader uses to style the HTML it injects for post metadata.

Thanks, I can reproduce the problem easily. I just reported it
upstream.

Berto

Bug#977779: geary FTBFS on mipsel: test suite failure

[Alberto Garcia]

On Fri, Jan 29, 2021 at 02:11:00PM +0200, Adrian Bunk wrote:
> > But this a bug in the CPU, right? Do I understand correctly that the
> > package can fail depending on what CPU it is run on regardless of how
> > it was built?
> > 
> > I'm trying to understand what we can do in WebKit in order to fix or
> > work around this.
> 
> It is a bug in WebKit that a kernel configuration is assumed that is
> not even permitted on Loongson:
> https://sources.debian.org/src/webkit2gtk/2.31.1-1/Source/WTF/wtf/PageBlock.h/#L54
> https://sources.debian.org/src/linux/5.10.9-1/arch/mips/Kconfig/#L2213-L2215

My question is: I cannot choose a page size depending on the
particular MIPS CPU model because once the package is built it could
be run on a CPU with a different page size, is that right?

If that's the case then I should use a conservative value that is
guaranteed to work on all models (64KB, or is 16KB safe?).

> BTW: The 4kB setting for arm64 is also questionable, Ubuntu releases 
>  now additionally ship kernels with 64 kB page size:
>  
> https://launchpad.net/ubuntu/groovy/+package/linux-image-unsigned-5.8.0-41-generic-64k

Ok, I'll use 64KB then.

Berto

Bug#977779: geary FTBFS on mipsel: test suite failure

[Alberto Garcia]

On Mon, Dec 21, 2020 at 11:30:14PM +0200, Adrian Bunk wrote:
> > I see that the build eventually succeeded:
> > 
> >
> > https://buildd.debian.org/status/logs.php?pkg=geary&ver=3.38.1-1&arch=mipsel
> > 
> > The webkit2gtk build is flaky itself in mipsel, we discussed this
> > already in the past (#962616), I wonder if this is the same root
> > problem?
> 
> This is the same problem.
> 
> Note that the build is not and never was flaky, it does 100%
> determinisitically fail on Loongson buildds and succeed on Octeon
> buildds.
> 
> Jiaxun Yang discovered this weekend that CeilingOnPageSize is wrong
> for Loongson which has 16 kB pagesize and this matches when the
> problems started in 2.28.1, but unfortunately fixing this does not
> seem to fix all problems.

But this a bug in the CPU, right? Do I understand correctly that the
package can fail depending on what CPU it is run on regardless of how
it was built?

I'm trying to understand what we can do in WebKit in order to fix or
work around this.

Berto

Bug#977779: geary FTBFS on mipsel: test suite failure

[Alberto Garcia]

On Sun, Dec 20, 2020 at 09:09:17PM +0200, Adrian Bunk wrote:
> > Source: geary
> > Version: 3.38.1-1

> > The latest version of geary fails to build on mipsel [1]. The test
> > suite fails.
> 
> This is not specific to geary and not specific to this version of
> geary, the search is already ongoing for the regression that makes
> webkit2gtk and some rdeps FTBFS on some buildds on mipsel.

I see that the build eventually succeeded:

   https://buildd.debian.org/status/logs.php?pkg=geary&ver=3.38.1-1&arch=mipsel

The webkit2gtk build is flaky itself in mipsel, we discussed this
already in the past (#962616), I wonder if this is the same root
problem?

Berto

Bug#976936: wpewebkit: FTBFS on ppc64el: dh_auto_build: error: cd obj-powerpc64le-linux-gnu && LC_ALL=C.UTF-8 ninja -j160 -v returned exit code 1

[Alberto Garcia]

Control: tags -1 moreinfo

On Wed 09 Dec 2020 09:42:53 AM CET, Lucas Nussbaum wrote:
> Source: wpewebkit
> Version: 2.30.3-1
> Severity: serious
> Justification: FTBFS on ppc64el
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on ppc64el. At the same time, it did not fail on amd64.

I can only see this in the build log:

> c++: fatal error: Killed signal terminated program cc1plus

This sounds like a bug in the compiler or some other external problem, I
haven't seen in the logs any indication that this is due to problems in
the code or the packaging.

Berto

Bug#975134: wpewebkit: FTBFS: ../Source/WebCore/platform/network/ResourceResponseBase.cpp:440:6: error: type precision mismatch in switch statement

[Alberto Garcia]

On Thu, Nov 19, 2020 at 10:39:08AM +0100, Lucas Nussbaum wrote:
> Source: wpewebkit
> Version: 2.30.2-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201119 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Thanks, this is a known problem, see #973293 and the upstream gcc bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97634

We have a workaround for webkit, it'll be included in the next
release, which will probably happen this week.

Berto

Bug#952262: psgml: FTBFS: Malformed UTF-8 character (fatal) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.

[Alberto Garcia]

Control: tags -1 patch pending

On Wed, Oct 21, 2020 at 04:10:41PM +0200, Alberto Garcia wrote:
> I confirm that the patch attached by Claudio Saavedra fixes the bug so
> I'll prepare an NMU (debdiff attached).

Uploaded to DELAYED/5

Berto

Bug#952262: psgml: FTBFS: Malformed UTF-8 character (fatal) at /usr/share/texinfo/Texinfo/ParserNonXS.pm line 3364.

[Alberto Garcia]

On Sun, Feb 23, 2020 at 02:22:05PM +0100, Lucas Nussbaum wrote:
> Source: psgml
> Version: 1.4.0-7.1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This bug has been open for almost a year and the package was removed
from testing 7 months go because of it.

I confirm that the patch attached by Claudio Saavedra fixes the bug so
I'll prepare an NMU (debdiff attached).

Berto
diff -u psgml-1.4.0/debian/changelog psgml-1.4.0/debian/changelog
--- psgml-1.4.0/debian/changelog
+++ psgml-1.4.0/debian/changelog
@@ -1,3 +1,11 @@
+psgml (1.4.0-7.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS due to malformed UTF-8 character (Closes: #952262):
+  - Applied patch for psgml.texi; thanks Claudio Saavedra.
+
+ -- Alberto Garcia   Wed, 21 Oct 2020 16:02:11 +0200
+
 psgml (1.4.0-7.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u psgml-1.4.0/psgml.texi psgml-1.4.0/psgml.texi
--- psgml-1.4.0/psgml.texi
+++ psgml-1.4.0/psgml.texi
@@ -1572,7 +1572,7 @@
 
 Set the variable @code{sgml-display-char-list-filename} to a file that
 contains mappings between all characters present in the presentation
-character set, and their "standard replacement text" names, e.g. "å"
+character set, and their "standard replacement text" names, e.g. "@U{00e5}"
 -> "[aring ]", e.t.c.
 
 The default value for this variable is `iso88591.map'. 

Bug#855541: purple-matrix: Not ready for release yet

[Alberto Garcia]

On Tue, Sep 22, 2020 at 09:51:14PM +0200, Alex ARNAUD wrote:

> > I think this version shouldn't be shipped with the next
> > release. Like the description says, it's "somewhat alpha".
> >
> > It works some times, but then stops working, it crashes,
> > and so on.
> 
> I've used the package purple-matrix on Debian 10 since at least 6
> months through Pidgin. It's not a perfect tool, have issues but in
> my opinion it is usable. Sometimes purple-matrix is disconnected
> or makes Pidgin to crash but it's quite rare. It's sufficient to
> restart Pidgin to make it working again.
> 
> I have two points why I think we should have it into next stable:
> 
>  * This is very difficult for a stable user to use purple-matrix. In my
>case, I have had to rebuilt the package due to dependencies and it's
>clearly something not easy for all.
>  * As a visual-impaired person, purple-matrix through Pidgin is the
>most accessible Matrix client I've used.
> 
> There are still reasons why we would like to keep it in unstable:
> 
>  * There are no commits in 2020
>  * The project doesn't publish new release and "just" push commits

Hi,

I think that this project is essentially dead, there has never been a
release and as you say there hasn't been changes in almost a year.

I have stopped using it myself and the reason why I didn't ask for its
removal from Debian is that it's a very small package with a very low
manteinance burden (and because popcon shows that it has some users).

But it seems that there are other alternatives nowadays. The official
Matrix website no longer lists purple-matrix, but there are however
other text-based clients such as weechat-matrix and gomuks. I cannot
evaluate how accessible they are, though.

Berto

Bug#962616: webkit2gtk: FTBFS on mipsel

[Alberto Garcia]

On Thu, Jun 11, 2020 at 11:19:10AM +0300, Adrian Bunk wrote:

> > > | Exception: gtkdoc-scangobj produced a non-zero return code 250
> > > | Command:
> > > |   gtkdoc-scangobj --module=webkit2gtk-4.0
> > > | Error output:
> > > |   
> > > |
> > > | ninja: build stopped: subcommand failed.
> > 
> > I've seen this several times, and it seems to happen randomly, and
> > only on mipsel. I haven't been able to reproduce it in a buildd.
> > 
> > I suspect it's a bug in gtk-doc-tools ?
> 
> It fails on the Loongson buildds but succeeds on the others,
> and the problem started recently:
> https://buildd.debian.org/status/logs.php?pkg=webkit2gtk&arch=mipsel

Ah, ok. FWIW I just built it again in eller.debian.org and everything
went fine.

Berto

Bug#962616: webkit2gtk: FTBFS on mipsel

[Alberto Garcia]

On Wed, Jun 10, 2020 at 08:08:27PM +0200, Sebastian Ramacher wrote:
> | Exception: gtkdoc-scangobj produced a non-zero return code 250
> | Command:
> |   gtkdoc-scangobj --module=webkit2gtk-4.0
> | Error output:
> |   
> |
> | ninja: build stopped: subcommand failed.

I've seen this several times, and it seems to happen randomly, and
only on mipsel. I haven't been able to reproduce it in a buildd.

I suspect it's a bug in gtk-doc-tools ?

Berto

Bug#956219: Error out when DISPLAY is unset

[Alberto Garcia]

On Sat, Apr 25, 2020 at 10:17:47AM +0200, Laurent Bigonville wrote:
> I'm reopening this as yelp still FTBFS with 2.28.2 with the same
> error, was the patch cherry-picked?

It was, but the problem seems to be different this time (a null
pointer):

process:35799): Gtk-CRITICAL **: 13:40:20.270: gtk_icon_theme_get_for_screen: 
assertion 'GDK_IS_SCREEN (screen)' failed

** (process:35799): WARNING **: 13:40:20.271: Unable to connect to dbus: Cannot 
autolaunch D-Bus without X11 $DISPLAY
Unable to init server: Could not connect: Connection refused
Segmentation fault

Thread 1 "libyelp-scan" received signal SIGSEGV, Segmentation fault.
0x7335cbd4 in wpe_renderer_backend_egl_destroy (backend=0x0) at 
./src/renderer-backend-egl.c:54
54  backend->base.interface->destroy(backend->base.interface_data);
(gdb) bt
#0  0x7335cbd4 in wpe_renderer_backend_egl_destroy (backend=0x0) at 
./src/renderer-backend-egl.c:54
#1  0x763bc8bb in 
WebCore::PlatformDisplayLibWPE::~PlatformDisplayLibWPE() ()
at ../Source/WebCore/platform/graphics/libwpe/PlatformDisplayLibWPE.cpp:66
#2  0x763bc8d9 in 
WebCore::PlatformDisplayLibWPE::~PlatformDisplayLibWPE() ()
at ../Source/WebCore/platform/graphics/libwpe/PlatformDisplayLibWPE.cpp:67
#3  0x77c59e27 in __run_exit_handlers
(status=0, listp=0x77dd8718 <__exit_funcs>, 
run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true)
at exit.c:108
#4  0x77c59fda in __GI_exit (status=) at exit.c:139
#5  0x77c42e12 in __libc_start_main (main=
0x6480 , argc=1, argv=0x7fffdd78, init=, 
fini=, rtld_fini=, stack_end=0x7fffdd68) at 
../csu/libc-start.c:342
#6  0x7b7a in _start () at libyelp-scan.c:1025

This looks like the WPE backend (which WebKitGTK uses), but from the
backtrace I can't quite tell yet where exactly the root of the problem
is. We'll investigate it and make sure that yelp builds after we have
fixed it.

Thanks for the report and sorry for the annoyance !

Berto

Bug#951984: tree-puzzle: FTBFS: mpi.h:322:57: error: static assertion failed: "MPI_Address was removed in MPI-3.0. Use MPI_Get_address instead."

[Alberto Garcia]

On Sun, Apr 05, 2020 at 07:37:28PM +0200, Alberto Garcia wrote:
> The attached patch fixes the build. The latest upstream release
> candidate still uses the old symbol btw.

I'm also attaching the full debdiff.

Berto
diff -Nru tree-puzzle-5.2/debian/changelog tree-puzzle-5.2/debian/changelog
--- tree-puzzle-5.2/debian/changelog	2018-10-16 11:06:43.0 +0200
+++ tree-puzzle-5.2/debian/changelog	2020-04-19 15:29:52.0 +0200
@@ -1,3 +1,11 @@
+tree-puzzle (5.2-11.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/fix-mpi3-build.patch:
+- Fix FTBFS due to the new MPI-3.0 API (Closes: #951984).
+
+ -- Alberto Garcia   Sun, 19 Apr 2020 15:29:52 +0200
+
 tree-puzzle (5.2-11) unstable; urgency=medium
 
   * debhelper 11
diff -Nru tree-puzzle-5.2/debian/patches/fix-mpi3-build.patch tree-puzzle-5.2/debian/patches/fix-mpi3-build.patch
--- tree-puzzle-5.2/debian/patches/fix-mpi3-build.patch	1970-01-01 01:00:00.0 +0100
+++ tree-puzzle-5.2/debian/patches/fix-mpi3-build.patch	2020-04-19 15:26:28.0 +0200
@@ -0,0 +1,22 @@
+From: Alberto Garcia 
+Subject: Replace obsolete MPI-2.0 API with their MPI-3.0 equivalents
+Bug-Debian: https://bugs.debian.org/951984
+Index: tree-puzzle-5.2/src/ppuzzle.c
+===
+--- tree-puzzle-5.2.orig/src/ppuzzle.c
 tree-puzzle-5.2/src/ppuzzle.c
+@@ -21,11 +21,14 @@
+ #endif
+ 
+ #define EXTERN extern
++#define OMPI_OMIT_MPI1_COMPAT_DECLS 1
+  
+ #include 
+ #include 
+ #include "ppuzzle.h"
+  
++#define MPI_Address MPI_Get_address
++#define MPI_Type_struct MPI_Type_create_struct
+ 
+ int PP_IamMaster;
+ int PP_IamSlave;
diff -Nru tree-puzzle-5.2/debian/patches/series tree-puzzle-5.2/debian/patches/series
--- tree-puzzle-5.2/debian/patches/series	2018-10-16 11:06:43.0 +0200
+++ tree-puzzle-5.2/debian/patches/series	2020-04-19 15:26:28.0 +0200
@@ -1,3 +1,4 @@
 20_no_copy_of_sprng.patch
 tests-need-bash.patch
 spelling.patch
+fix-mpi3-build.patch

Bug#952102: salmon: FTBFS: SalmonAlevin.cpp:780:6: error: ‘class rapmap::utils::MappingConfig’ has no member named ‘maxSlack’

[Alberto Garcia]

On Sun, Feb 23, 2020 at 09:02:55AM +0100, Lucas Nussbaum wrote:

> > /<>/src/SalmonAlevin.cpp: In function ‘void 
> > processReadsQuasi(alevin::paired_parser*, ReadExperimentT&, ReadLibrary&, 
> > alevin::AlnGroupVec&, std::atomic > unsigned int>&, std::atomic&, std::atomic > int>&, std::atomic&, std::atomic&, 
> > std::atomic&, RapMapIndexT*, std::vector&, 
> > ForgettingMassCalculator&, ClusterForest&, FragmentLengthDistribution&, 
> > BiasParams&, SalmonOpts&, std::mutex&, bool, std::atomic&, volatile 
> > bool&, AlevinOpts&, SoftMapT&, 
> > spp::sparse_hash_map, unsigned int>&)’:
> > /<>/src/SalmonAlevin.cpp:780:6: error: ‘class 
> > rapmap::utils::MappingConfig’ has no member named ‘maxSlack’
> >   780 |   mc.maxSlack = salmonOpts.consensusSlack;
> >   |  ^~~~
> > make[4]: *** [src/CMakeFiles/salmon.dir/build.make:274: 
> > src/CMakeFiles/salmon.dir/SalmonAlevin.cpp.o] Error 1

This usage of mc.maxSlack was already removed upstream last year, see

   
https://github.com/COMBINE-lab/salmon/commit/056f9c357a2b28ebcd5db923c53a1ea635bf88dd

I guess that the salmon package simply needs to be updated to the
most recent upstream version (latest is 1.1.0, Debian has 0.12.0 from
2018).

Berto

Bug#951984: tree-puzzle: FTBFS: mpi.h:322:57: error: static assertion failed: "MPI_Address was removed in MPI-3.0. Use MPI_Get_address instead."

[Alberto Garcia]

Control: tags -1 patch

On Sun, Feb 23, 2020 at 08:39:23AM +0100, Lucas Nussbaum wrote:

> >  2842 | #define MPI_Address(...)  
> > THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_Address, MPI_Get_address)
> >  2850 | #define MPI_Type_struct(...)  
> > THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_Type_struct, MPI_Type_create_struct)

So tree-puzzle uses two symbols from MPI-2.0 that have been deprecated
in MPI-3.0. Fortunately in both cases the only change is the name of
the symbol, and it's not necessary to do anything else.

See here for details:

   https://www.open-mpi.org/faq/?category=mpi-removed

The attached patch fixes the build. The latest upstream release
candidate still uses the old symbol btw.

Berto
From: Alberto Garcia 
Subject: Replace obsolete MPI-2.0 API with their MPI-3.0 equivalents
Bug-Debian: https://bugs.debian.org/951984
Index: tree-puzzle-5.2/src/ppuzzle.c
===
--- tree-puzzle-5.2.orig/src/ppuzzle.c
+++ tree-puzzle-5.2/src/ppuzzle.c
@@ -21,11 +21,14 @@
 #endif
 
 #define EXTERN extern
+#define OMPI_OMIT_MPI1_COMPAT_DECLS 1
  
 #include 
 #include 
 #include "ppuzzle.h"
  
+#define MPI_Address MPI_Get_address
+#define MPI_Type_struct MPI_Type_create_struct
 
 int PP_IamMaster;
 int PP_IamSlave;

Bug#952252: wpebackend-fdo: FTBFS: /bin/sh: 1: client-header: not found

[Alberto Garcia]

Control: tags -1 pending

On Sun, Feb 23, 2020 at 02:21:31PM +0100, Lucas Nussbaum wrote:
> Source: wpebackend-fdo
> Version: 1.4.0-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye

Known problem, it will be fixed in the next upload, thanks!

Berto

Bug#855541: Update: actually it works

[Alberto Garcia]

On Fri, Feb 21, 2020 at 04:05:51AM +0100, Jean-Philippe MENGUAL wrote:

> Ok I have just built the git release, now it works. So to maintain
> this package usable in Debian, you need to update it to the latest
> git release, from December, 28. Do you want a specific bug to
> request update? Without it, I think it is unusable now.

The Debian package is from the December 28 release (hence the version
number 0.0.0+git20191228-1). Which one are you trying?

Berto

Bug#949430: webkit2gtk: FTBFS: fatal error: X11/Xlib-xcb.h: No such file or directory

[Alberto Garcia]

Control: tags -1 pending

On Mon, Jan 20, 2020 at 08:44:30PM +0100, Mattia Rizzolo wrote:
> In file included from 
> ../Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp:64:
> /usr/include/gstreamer-1.0/gst/gl/x11/gstgldisplay_x11.h:26:10: fatal error: 
> X11/Xlib-xcb.h: No such file or directory
>26 | #include 
>   |  ^~~~

Thanks, I was aware of the problem and it will be fixed in the next
upload.

See also #948143.

Thanks,

Berto

Bug#930935: webkit2gtk: Baseline violation on i386

[Alberto Garcia]

On Mon, Jun 24, 2019 at 04:48:43PM +0300, Alberto Garcia wrote:

> If no one has anything to say I'll upload it today. This should work
> on all i386 CPUs, and we can later discuss if it's worth thinking of
> a solution for SSE2-capable machines.

Uploaded, unblock request at #931052

I don't have an Athlon XP myself but I can reproduce the bug (and
verify that the fix works) emulating a Pentium 3 with QEMU.

Berto

Bug#930935: webkit2gtk: Baseline violation on i386

[Alberto Garcia]

Control: tags -1 patch pending

On Mon, Jun 24, 2019 at 10:29:56AM +0200, Alberto Garcia wrote:
> 2) Build with SSE2 completely disabled (using WTF_CPU_UNKNOWN, or
>somethig else, I'm still discussing this with the team).

Ok, this patch disables SSE2 and forces Webkit to use CLoop, the
C-based JavaScript interpreter (instead of using JIT or the asm-based
intepreter). That's the one used when the CPU is unknown or not
supported.

If no one has anything to say I'll upload it today. This should work
on all i386 CPUs, and we can later discuss if it's worth thinking of a
solution for SSE2-capable machines.

Berto
diff --git a/debian/NEWS b/debian/NEWS
index 8b5be11c238..72ce8c9fdd9 100644
--- a/debian/NEWS
+++ b/debian/NEWS
@@ -1,12 +1,3 @@
-webkit2gtk (2.24.1-2) unstable; urgency=high
-
-  Since version 2.24.0, i386 builds of WebKitGTK require an SSE2-capable
-  CPU. This instruction set was first introduced with the Pentium 4 in
-  year 2000. Support for older processors was dropped in WebKitGTK
-  upstream and is unfortunately not expected to come back.
-
- -- Alberto Garcia   Fri, 10 May 2019 15:40:28 +0300
-
 webkit2gtk (2.20.0-2) unstable; urgency=medium
 
   webkit2gtk 2.20.0 contains a security feature named Gigacage that
diff --git a/debian/changelog b/debian/changelog
index e5224cae539..6ddef67d1b8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,26 @@
+webkit2gtk (2.24.2-2) unstable; urgency=high
+
+  * The WebKitGTK security advisory WSA-2019-0003 lists the following
+security fixes in the latest versions of WebKitGTK+:
++ CVE-2019-8571, CVE-2019-8583, CVE-2019-8586, CVE-2019-8594,
+  CVE-2019-8609, CVE-2019-8611, CVE-2019-8622 and CVE-2019-8623
+  (fixed in 2.24.0).
++ CVE-2019-6237, CVE-2019-8584, CVE-2019-8587, CVE-2019-8596,
+  CVE-2019-8597, CVE-2019-8601, CVE-2019-8608, CVE-2019-8610 and
+  CVE-2019-8619 (fixed in 2.24.1).
++ CVE-2019-8595, CVE-2019-8607 and CVE-2019-8615 (fixed in 2.24.2).
+  * Use the CLoop Javascript interpreter in i386 and stop telling gcc to
+use SSE2 instructions (Closes: #930935).
++ debian/rules:
+  - Build with -DENABLE_JIT=OFF -DENABLE_C_LOOP=ON and stop using
+-msse2 -mfpmath=sse.
++ debian/patches/dont-detect-sse2.patch:
+  - Don't check for SSE2 support.
++ debian/NEWS:
+  - Remove item about the requirement to have an SSE2-capable CPU.
+
+ -- Alberto Garcia   Mon, 24 Jun 2019 16:34:09 +0300
+
 webkit2gtk (2.24.2-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/patches/dont-detect-sse2.patch b/debian/patches/dont-detect-sse2.patch
new file mode 100644
index 000..59b3650f6b6
--- /dev/null
+++ b/debian/patches/dont-detect-sse2.patch
@@ -0,0 +1,24 @@
+From: Alberto Garcia 
+Subject: Don't check for SSE2 support on i386
+Bug-Debian: https://bugs.debian.org/930935
+Forwarded: no
+Index: webkitgtk/Source/cmake/WebKitCompilerFlags.cmake
+===
+--- webkitgtk.orig/Source/cmake/WebKitCompilerFlags.cmake
 webkitgtk/Source/cmake/WebKitCompilerFlags.cmake
+@@ -144,15 +144,6 @@ if (COMPILER_IS_GCC_OR_CLANG)
+ if (CMAKE_COMPILER_IS_GNUCXX)
+ WEBKIT_PREPEND_GLOBAL_COMPILER_FLAGS(-Wno-expansion-to-defined)
+ endif ()
+-
+-# Force SSE2 fp on x86 builds.
+-if (WTF_CPU_X86 AND NOT CMAKE_CROSSCOMPILING)
+-WEBKIT_PREPEND_GLOBAL_COMPILER_FLAGS(-msse2 -mfpmath=sse)
+-include(DetectSSE2)
+-if (NOT SSE2_SUPPORT_FOUND)
+-message(FATAL_ERROR "SSE2 support is required to compile WebKit")
+-endif ()
+-endif ()
+ endif ()
+ 
+ if (COMPILER_IS_GCC_OR_CLANG AND NOT MSVC)
diff --git a/debian/patches/series b/debian/patches/series
index 1bcc251ee09..12740b1f4e3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -7,3 +7,4 @@ detect-gstreamer-gl.patch
 detect-woff.patch
 user-agent-branding.patch
 prefer-pthread.patch
+dont-detect-sse2.patch
diff --git a/debian/rules b/debian/rules
index b1e8caeb46f..ae93d5e38f8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -23,9 +23,10 @@ ifeq (,$(filter $(DEB_HOST_ARCH),amd64 ppc64 ppc64el))
 	CFLAGS := $(CFLAGS:-g=-g1)
 endif
 
-# The 32-bit x86 build requires SSE2
+# Use the CLoop Javascript interpreter and disable the JIT. This is
+# slow but it is the most compatible solution for old (non-SSE2) CPUs.
 ifneq (,$(filter $(DEB_HOST_ARCH),i386))
-	CFLAGS += -msse2 -mfpmath=sse
+	EXTRA_CMAKE_ARGUMENTS += -DENABLE_JIT=OFF -DENABLE_C_LOOP=ON
 endif
 
 # See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426

Bug#930935: webkit2gtk: Baseline violation on i386

[Alberto Garcia]

On Mon, Jun 24, 2019 at 12:34:26AM +0300, Adrian Bunk wrote:

> > Building with SSE2 is not a decision made by the Debian
> > maintainers.  Upstream WebKit dropped support for non-SSE2
> > processors and the code assumes that SSE2 is always available:
> > 
> >https://bugs.webkit.org/show_bug.cgi?id=194853
> 
> "as part of Igalia's work on 32bit support"
> "there were no negative comments"
> 
> Someone should have told upstream at Igalia that non-SSE is
> supported by the Debian i386 port.

This was actually discussed, IIRC the concusion was that this was
a reasonable choice because (a) SSE2 is almost 20 years old, (b)
supporting non-SSE2 CPUs was increasing the maintaince burden for
upstream, and (c) other browsers had already followed the same path
for a few yeas.

> > And so did Firefox:
> > 
> >https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported
> 
> The Debian maintainers have patched both Rust and Firefox to make
> them work on non-SSE i386 despite upstream no longer supporting it.
> 
> There were plenty of bug reports when an SSE-using Firefox recently
> slipped through - and in general based on the numbers of bugs
> submitted non-SSE i386 has more users than half our release
> architectures combined.

Ok, that's interesting information.

Let's try to move forward then. I see three possibilities:

1) Detect SSE2 at runtime. This doesn't seem to be possible at this
   point, or at least not trivially so. Although we still have the
   JavaScriptCoreUseJIT variable, it's unclear whether this would be
   enough. I need to test it.

2) Build with SSE2 completely disabled (using WTF_CPU_UNKNOWN, or
   somethig else, I'm still discussing this with the team). This would
   probably solve the problem but would make all i386 builds much
   slower (in already slow machines) so I suppose many users would
   also complain.

3) Make two builds for i386: one with SSE2 and one without, and have
   two separate packages. Maybe it's too late for this? In any case
   I think this would only affect the libjavascriptcore package, the
   libwebkit2gtk build should be valid for all CPUs. So we'd have
   libjavascriptcoregtk-4.0-18 and libjavascriptcoregtk-4.0-18-sse2 or
   something like that.

Berto

Bug#930935: webkit2gtk: Baseline violation on i386

[Alberto Garcia]

On Sat, Jun 22, 2019 at 10:40:53PM +0300, Adrian Bunk wrote:

> Fix is attached.

Building with SSE2 is not a decision made by the Debian maintainers.
Upstream WebKit dropped support for non-SSE2 processors and the code
assumes that SSE2 is always available:

   https://bugs.webkit.org/show_bug.cgi?id=194853

As far as I'm aware this is also happening with other browsers,
e.g. Chromium dropped support 5 years ago:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763290

And so did Firefox:

   https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported

Berto

Bug#928399: libwebkit2gtk-4.0-37: White spaces are always skipped in redinering of text plain.

[Alberto Garcia]

Control: tags -1 patch

On Tue, May 07, 2019 at 04:29:29PM +0300, Alberto Garcia wrote:

> Thanks, I cannot reproduce this with the Spanish locale
> (es_ES.UTF-8) but it does happen with ja_JP.UTF-8 and the
> fonts-noto-cjk package installed.
> 
> I reported it upstream.

There's already a proposed patch on the upstream bugzilla that fixes
this problem:

https://bugs.webkit.org/attachment.cgi?id=369368&action=diff

Berto

Bug#926872: evolution: Spaces in mail view disappeared with recent updates

[Alberto Garcia]

On Thu, Apr 11, 2019 at 11:22:46AM -0400, Boyuan Yang wrote:

> I'm using the broken evolution to report bugs to you now. With the
> updates recently (within 1 week), evolution no longer shows spaces
> when displaying email.

I cannot confirm it 100%, but it seems that this is a bug in
WebKitGTK. I reported it upstream here:

   https://bugs.webkit.org/show_bug.cgi?id=197658

And there's also Debian #928399, which should probably be merged with
this one once we confirm that this is indeed the root cause.

Berto

Bug#928399: libwebkit2gtk-4.0-37: White spaces are always skipped in redinering of text plain.

[Alberto Garcia]

Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=197658

On Sat, May 04, 2019 at 02:03:22AM +0900, nozzy123no...@gmail.com wrote:

>  I find a problem of libwebkit2gtk-4.0-37, which doesn't show all white
> spaces in rendering text plain document under the locales except for
> "C" locale. 

Thanks, I cannot reproduce this with the Spanish locale (es_ES.UTF-8)
but it does happen with ja_JP.UTF-8 and the fonts-noto-cjk package
installed.

I reported it upstream.

Berto

Bug#922730: cannot browse anything

[Alberto Garcia]

Control: tags -1 patch

On Tue, Mar 05, 2019 at 12:46:59PM +0200, Alberto Garcia wrote:
> > > If would also be nice if you can get a backtrace.
> > 
> > Attached is a backtrace
> 
> I forgot to clarify: I got this from the versions currently in
> unstable (epiphany 3.31.91-2, webkit 2.22.7-1).
> 
> The MiniBrowser does run fine however, I can open e.g. Google Maps and
> use the website normally.

Ok, so this is a bug in Epiphany after all, I confirm that the
attached patch fixes the problem.

Here's the upstream merge request:

   https://gitlab.gnome.org/GNOME/epiphany/merge_requests/218

Berto
diff --git a/embed/web-extension/ephy-web-extension.c b/embed/web-extension/ephy-web-extension.c
index 49335621262cae4c9c7ba97ee6ec1c33f223a471..9f6ab15ebe1e9a31263862b945339d295e3f721b 100644
--- a/embed/web-extension/ephy-web-extension.c
+++ b/embed/web-extension/ephy-web-extension.c
@@ -733,12 +733,10 @@ window_object_cleared_cb (WebKitScriptWorld *world,
  js_ephy);
 
   if (!extension->is_private_profile) {
-guint64 page_id = webkit_web_page_get_id (page);
-g_assert (page_id < G_MAXINT32);
-
 g_autoptr(JSCValue) js_password_manager_ctor = jsc_value_object_get_property (js_ephy, "PasswordManager");
 g_autoptr(JSCValue) js_password_manager = jsc_value_constructor_call (js_password_manager_ctor,
-  G_TYPE_INT, page_id, G_TYPE_NONE);
+  G_TYPE_UINT64, webkit_web_page_get_id (page),
+  G_TYPE_NONE);
 jsc_value_object_set_property (js_ephy, "passwordManager", js_password_manager);
 
 js_function = jsc_value_new_function (js_context,

Bug#922730: cannot browse anything

[Alberto Garcia]

On Tue, Mar 05, 2019 at 11:56:58AM +0200, Alberto Garcia wrote:
> On Thu, Feb 21, 2019 at 02:01:45PM +0200, Alberto Garcia wrote:
> > If would also be nice if you can get a backtrace.
> 
> Attached is a backtrace

I forgot to clarify: I got this from the versions currently in
unstable (epiphany 3.31.91-2, webkit 2.22.7-1).

The MiniBrowser does run fine however, I can open e.g. Google Maps and
use the website normally.

Berto

Bug#922730: cannot browse anything

[Alberto Garcia]

On Thu, Feb 21, 2019 at 02:01:45PM +0200, Alberto Garcia wrote:
> If would also be nice if you can get a backtrace.

Attached is a backtrace

Berto
Core was generated by `/usr/lib/i386-linux-gnu/webkit2gtk-4.0/WebKitWebProcess 
7 23'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xb2e6fbba in jscValueCallFunction () at 
./Source/JavaScriptCore/API/glib/JSCValue.cpp:886
886 G_VALUE_COLLECT_INIT(¶meter, parameterType, args, 
G_VALUE_NOCOPY_CONTENTS, &error.outPtr());
[Current thread is 1 (Thread 0xaf3c5200 (LWP 1640))]
(gdb) bt
#0  0xb2e6fbba in jscValueCallFunction () at 
./Source/JavaScriptCore/API/glib/JSCValue.cpp:886
#1  0xb2e7097a in jsc_value_constructor_call () at 
./Source/JavaScriptCore/API/glib/JSCValue.cpp:1348
#2  0xae717a29 in window_object_cleared_cb (extension=0x17122c0, 
frame=0x1847028, page=0x1848750, world=0x1751a68) at 
../embed/web-extension/ephy-web-extension.c:748
#3  window_object_cleared_cb (world=0x1751a68, page=0x1848750, frame=0x1847028, 
extension=0x17122c0) at ../embed/web-extension/ephy-web-extension.c:671
#4  0xb153f10e in ffi_call_SYSV () from /lib/i386-linux-gnu/libffi.so.6
#5  0xb153ed9c in ffi_call () from /lib/i386-linux-gnu/libffi.so.6
#6  0xb401d919 in g_cclosure_marshal_generic (closure=, 
return_gvalue=, n_param_values=, 
param_values=, invocation_hint=, 
marshal_data=) at ../../../gobject/gclosure.c:1496
#7  0xb401d118 in g_closure_invoke (closure=0x1749410, return_value=0x0, 
n_param_values=3, param_values=0xbf8e9d80, invocation_hint=0xbf8e9d24) at 
../../../gobject/gclosure.c:810
#8  0xb4030ba2 in signal_emit_unlocked_R (node=node@entry=0x174a4e0, 
detail=detail@entry=0, instance=instance@entry=0x1751a68, emission_return=0x0, 
instance_and_params=0xbf8e9d80)
at ../../../gobject/gsignal.c:3635
#9  0xb4039e00 in g_signal_emit_valist (instance=, 
signal_id=, detail=, var_args=0xbf8e9f14 
"\266M\200\265\271\fn\265") at ../../../gobject/gsignal.c:3391
#10 0xb403a3f5 in g_signal_emit (instance=0x1751a68, signal_id=178, detail=0) 
at ../../../gobject/gsignal.c:3447
#11 0xb56d0188 in webkitScriptWorldWindowObjectCleared () at 
./Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitScriptWorld.cpp:99
#12 0xb56d510d in PageLoaderClient::didClearWindowObjectForFrame () at 
./Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebPage.cpp:212
#13 0xb57d998b in 
WebKit::WebFrameLoaderClient::dispatchDidClearWindowObjectInWorld () at 
./Source/WebKit/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:1683
#14 0xb64b4b0a in WebCore::FrameLoader::dispatchDidClearWindowObjectInWorld () 
at ./Source/WebCore/loader/FrameLoader.cpp:3794
#15 WebCore::FrameLoader::dispatchDidClearWindowObjectInWorld () at 
./Source/WebCore/loader/FrameLoader.cpp:3789
#16 0xb5f330f9 in WebCore::ScriptController::initScriptForWindowProxy () at 
./Source/WebCore/bindings/js/ScriptController.cpp:259
#17 0xb5f4af07 in 
WebCore::WindowProxy::createJSWindowProxyWithInitializedScript () at 
./Source/WebCore/bindings/js/WindowProxy.cpp:123
#18 0xb5f266f1 in WebCore::WindowProxy::jsWindowProxy () at 
./Source/WebCore/bindings/js/WindowProxy.h:70
#19 WebCore::ScriptController::jsWindowProxy () at 
./Source/WebCore/bindings/js/ScriptController.cpp:331
#20 0xb5820edc in WebCore::ScriptController::globalObject () at 
./Source/WebCore/bindings/js/ScriptController.h:86
#21 WebKit::WebFrame::jsContextForWorld () at 
./Source/WebKit/WebProcess/WebPage/WebFrame.cpp:527
#22 0xb56cf9fb in webkit_frame_get_js_context_for_script_world () at 
./Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitFrame.cpp:176
#23 0xae7175d8 in ephy_web_extension_page_created_cb (extension=0x17122c0, 
web_page=0x1848750) at ../embed/web-extension/ephy-web-extension.c:378
#24 0xb401d118 in g_closure_invoke (closure=0x17e9ea0, return_value=0x0, 
n_param_values=2, param_values=0xbf8ea2d0, invocation_hint=0xbf8ea274) at 
../../../gobject/gclosure.c:810
#25 0xb4030ba2 in signal_emit_unlocked_R (node=node@entry=0x1734a60, 
detail=detail@entry=0, instance=instance@entry=0x17db7a8, emission_return=0x0, 
instance_and_params=0xbf8ea2d0)
at ../../../gobject/gsignal.c:3635
#26 0xb4039e00 in g_signal_emit_valist (instance=, 
signal_id=, detail=, var_args=0xbf8ea450 "") at 
../../../gobject/gsignal.c:3391
#27 0xb403a3f5 in g_signal_emit (instance=0x17db7a8, signal_id=177, detail=0) 
at ../../../gobject/gsignal.c:3447
#28 0xb56d19a5 in WebExtensionInjectedBundleClient::didCreatePage () at 
./Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebExtension.cpp:163
#29 0xb56bebcb in WebKit::InjectedBundle::didCreatePage () at 
./Source/WebKit/WebProcess/InjectedBundle/InjectedBundle.cpp:534
#30 0xb58195b0 in WebKit::WebPage::create () at 
./Source/WebKit/WebProcess/WebPage/WebPage.cpp:341
#31 0xb56a5ea2 in WebKit::WebProcess::createWebPage () at 
./Source/WebKit/WebProcess/WebProcess.cpp:583
#32 0xb5376b5a in IPC::callMemberFunctionImpl, 0u, 1u> () at 
./Source/WebKit/

Bug#922730: cannot browse anything

[Alberto Garcia]

On Wed, Feb 20, 2019 at 07:00:07AM +0800, 積丹尼 Dan Jacobson wrote:
> Package: epiphany-browser
> Version: 3.31.91-2
> Severity: grave
> 
> $ mkdir /tmp/p
> $ HOME=/tmp/p epiphany /etc/motd
> 
> ** (epiphany:11842): WARNING **: 06:53:40.412: Web process crashed

If the web process crashed then it sounds like a problem in webkit.

Can you try with libwebkit2gtk-4.0-37 2.23.91-1 ??

If would also be nice if you can get a backtrace.

Berto

Bug#916347: (no subject)

[Alberto Garcia]

On Fri, Dec 14, 2018 at 09:54:01AM -0600, mcatanz...@gnome.org wrote:

> But equally problematic is the Debian security team's lack of
> interest in allowing updates to the security-critical WebKitGTK+
> package, which is currently vulnerable to issues since WSA-2018-0003
> [1]

Notice however that the latest stable release of WebKitGTK+ is always
available in stable-backports at the same time as in testing, so it
is indeed possible to run Epiphany from Debian stable with the most
up-to-date WebKitGTK+.

Berto

Bug#916347: (no subject)

[Alberto Garcia]

On Fri, Dec 14, 2018 at 10:17:18AM -0600, mcatanz...@gnome.org wrote:
> On Fri, Dec 14, 2018 at 10:02 AM, Alberto Garcia  wrote:
> >Notice however that the latest stable release of WebKitGTK+ is always
> >available in stable-backports at the same time as in testing, so it
> >is indeed possible to run Epiphany from Debian stable with the most
> >up-to-date WebKitGTK+.
> 
> Perhaps the epiphany package could be made available only in backports?

WebKitGTK+ has a policy of being conservative with the build
dependencies so we can rely on it being buildable for Debian stable. I
don't know if that's the case with Epiphany, and if someone has the
time to take care of the backport.

Berto

Bug#914986: webkit2gtk: FTBFS on i386: ENABLE_SAMPLING_PROFILER conflicts with ENABLE_C_LOOP

[Alberto Garcia]

Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=186722
Control: tags -1 upstream fixed-upstream pending

On Thu, Nov 29, 2018 at 11:28:27AM +0100, Andreas Beckmann wrote:

> webkit2gtk/experimental FTBFS on i386:

Known problem, it's been fixed upstream already.

You can work around it in the meantime by passing
-DENABLE_SAMPLING_PROFILER=OFF.

Berto

Bug#900282: webkitgtk FTBFS with new ICU

[Alberto Garcia]

On Mon, May 28, 2018 at 02:21:26PM +0100, peter green wrote:

> Webkitgtk seems to be failing to build, failures have been seen
> with binnmus in Debian and Raspbian and also on the reproducible
> builds service. I had a look at the insanely large build log from
> reproducible builds and found the following error, there are likely
> many others.

Although this is a very old and unsupported version of WebKitGTK+,
I think this upstream patch still applies:

   https://bugs.webkit.org/show_bug.cgi?id=171612

I'll give it a try and see if it works.

Berto

Bug#899338: WTFCrash

[Alberto Garcia]

On Thu, May 24, 2018 at 07:26:52PM +0800, 積丹尼 Dan Jacobson wrote:
> I can confirm that the problem doesn't occur on amd64 2.21.2-1, only i386.
> Do you have a i386 machine you can test
> /usr/lib/*-linux-gnu/webkit2gtk-4.0/MiniBrowser 
> https://www.couchsurfing.com/dashboard
> on?

Right, I can reproduce it here too.

A temporary workaround is to set the JavaScriptCoreUseJIT=0
environment variable.

Thread 1 "WebKitWebProces" received signal SIGSEGV, Segmentation fault.
WTFCrash () at ./Source/WTF/wtf/Assertions.cpp:267
267 *(int *)(uintptr_t)0xbbadbeef = 0;
(gdb) bt
#0  WTFCrash () at ./Source/WTF/wtf/Assertions.cpp:267
#1  0xf341d145 in WTF::CrashOnOverflow::crash () at 
./obj-i686-linux-gnu/DerivedSources/ForwardingHeaders/wtf/CheckedArithmetic.h:85
#2  WTF::CrashOnOverflow::overflowed () at 
./obj-i686-linux-gnu/DerivedSources/ForwardingHeaders/wtf/CheckedArithmetic.h:78
#3  WTF::Vector::at ()
at ./obj-i686-linux-gnu/DerivedSources/ForwardingHeaders/wtf/Vector.h:691
#4  WTF::Vector::operator[] ()
at ./obj-i686-linux-gnu/DerivedSources/ForwardingHeaders/wtf/Vector.h:711
#5  JSC::JIT::emitSlow_op_get_by_id () at 
./Source/JavaScriptCore/jit/JITPropertyAccess32_64.cpp:679
#6  0xf33d0457 in JSC::JIT::privateCompileSlowCases () at 
./Source/JavaScriptCore/jit/JIT.cpp:525
#7  0xf33d507d in JSC::JIT::compileWithoutLinking () at 
./Source/JavaScriptCore/jit/JIT.cpp:724
#8  0xf34359ae in JSC::JITWorklist::Plan::compileInThread () at 
./Source/JavaScriptCore/jit/JITWorklist.cpp:48
#9  JSC::JITWorklist::Plan::compileNow () at 
./Source/JavaScriptCore/jit/JITWorklist.cpp:89
#10 0xf343284a in JSC::JITWorklist::compileLater () at 
./Source/JavaScriptCore/jit/JITWorklist.cpp:233
#11 0xf345e93e in JSC::LLInt::jitCompileAndSetHeuristics () at 
./Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:356
#12 0xf345d444 in entryOSR () at 
./Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:378
#13 0xf3445b7e in llint_entry () from 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#14 0xf344a2f7 in llint_entry () from 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#15 0xf344a2f7 in llint_entry () from 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#16 0xf344a53c in llint_entry () from 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#17 0xf344a2f7 in llint_entry () from 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#18 0xf344a2f7 in llint_entry () from 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#19 0xf3444e1d in vmEntryToJavaScript () from 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#20 0xf33bfd8c in JSC::JITCode::execute () at 
./Source/JavaScriptCore/jit/JITCodeInlines.h:38
#21 JSC::Interpreter::executeProgram () at 
./Source/JavaScriptCore/interpreter/Interpreter.cpp:956
#22 0xf35afe34 in JSC::evaluate () at 
./Source/JavaScriptCore/runtime/Completion.cpp:103
#23 0xf35aff95 in JSC::profiledEvaluate () at 
./Source/JavaScriptCore/runtime/Completion.cpp:118
#24 0xf5f928e6 in WebCore::JSMainThreadExecState::profiledEvaluate () at 
./Source/WebCore/bindings/js/JSMainThreadExecState.h:78
#25 WebCore::ScriptController::evaluateInWorld () at 
./Source/WebCore/bindings/js/ScriptController.cpp:130
#26 0xf5f92af8 in WebCore::ScriptController::evaluate () at 
./Source/WebCore/bindings/js/ScriptController.cpp:146
#27 0xf61e4b63 in WebCore::ScriptElement::executeClassicScript () at 
./Source/WebCore/dom/ScriptElement.cpp:387
#28 0xf61b3731 in WebCore::LoadableClassicScript::execute () at 
./Source/WebCore/dom/LoadableClassicScript.cpp:123
#29 0xf61f08ba in WebCore::ScriptElement::executeScriptAndDispatchEvent () at 
./Source/WebCore/dom/ScriptElement.cpp:426
#30 0xf61f09dd in WebCore::ScriptElement::executePendingScript () at 
./Source/WebCore/dom/ScriptElement.cpp:434
#31 0xf64146fe in 
WebCore::HTMLScriptRunner::executePendingScriptAndDispatchEvent () at 
./Source/WebCore/html/parser/HTMLScriptRunner.cpp:114
#32 0xf641a70b in WebCore::HTMLScriptRunner::executeParsingBlockingScripts () 
at ./Source/WebCore/html/parser/HTMLScriptRunner.cpp:164
#33 0xf641b90e in 
WebCore::HTMLScriptRunner::execute(WTF::Ref >&&, WTF::TextPosition const&) () at 
./Source/WebCore/html/parser/HTMLScriptRunner.cpp:148
#34 0xf6407318 in WebCore::HTMLDocumentParser::runScriptsForPausedTreeBuilder 
() at ./Source/WebCore/html/parser/HTMLDocumentParser.cpp:212
#35 0xf640813e in WebCore::HTMLDocumentParser::pumpTokenizerLoop () at 
./Source/WebCore/html/parser/HTMLDocumentParser.cpp:231
#36 0xf640828d in WebCore::HTMLDocumentParser::pumpTokenizer () at 
./Source/WebCore/html/parser/HTMLDocumentParser.cpp:281
#37 0xf640848d in WebCore::HTMLDocumentParser::pumpTokenizerIfPossible () at 
./Source/WebCore/html/parser/HTMLDocumentParser.cpp:172
#38 0xf6408c9e in 
WebCore::HTMLDocumentParser::resumeParsingAfterScriptExecution () at 
./Source/WebCore/html/parser/HTMLDocumentParser.cpp:500
#39 0xf6408ef5 in 
WebCore::HTMLDocumentParser::executeScriptsWaitingForStylesheets () at 
./Source/WebCore/

Bug#899338: WTFCrash

[Alberto Garcia]

On Wed, May 23, 2018 at 09:05:24AM +0800, 積丹尼 Dan Jacobson wrote:
> Package: libjavascriptcoregtk-4.0-18
> Version: 2.21.2-1
> Severity: grave
> 
> 1   0xb37f73a4 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(WTFCrash+0x14) 
> [0xb37f73a4]
> 2   0xb340f325 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3JSC3JIT20emitSlow_op_in_by_idEPNS_11InstructionERPNS_13SlowCaseEntryE+0x1a5)
>  [0xb340f325]
> 3   0xb33c243a 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3JSC3JIT23privateCompileSlowCasesEv+0x60a)
>  [0xb33c243a]
> 4   0xb33c707d 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3JSC3JIT21compileWithoutLinkingENS_20JITCompilationEffortE+0x55d)
>  [0xb33c707d]
> 5   0xb34279ae 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3JSC11JITWorklist4Plan10compileNowEPNS_9CodeBlockEj+0x6e)
>  [0xb34279ae]
> 6   0xb342484a 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3JSC11JITWorklist12compileLaterEPNS_9CodeBlockEj+0x7a)
>  [0xb342484a]
> 7   0xb345093e 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3JSC5LLInt26jitCompileAndSetHeuristicsEPNS_9CodeBlockEPNS_9ExecStateEj+0x12e)
>  [0xb345093e]
> 8   0xb344f444 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(+0x778444) [0xb344f444]
> 
> Seen in epiphany or webkit minibrowser on pages like
> https://www.couchsurfing.com/dashboard
> or even after logging in to
> bugs.webkit.org .

Any chance that you could reproduce this with the debug symbols
installed? It would help to have a more detailed backtrace.

Berto

Bug#891983: gir1.2-javascriptcoregtk-4.0 from stable-pu breaks the whole Gnome

[Alberto Garcia]

On Thu, Mar 08, 2018 at 02:22:37PM +0100, Julien Aubin wrote:

> No I confirm the offending packages are *gstreamer*bad from
> deb-multimedia.org

Is then problem solved if you use the official gstreamer packages
then?

Berto

Bug#891983: gir1.2-javascriptcoregtk-4.0 from stable-pu breaks the whole Gnome

[Alberto Garcia]

On Sat, Mar 03, 2018 at 06:11:10PM +0100, Julien Aubin wrote:
> You released this morning on stable-pu new versions of the following
> packages :
> gir1.2-javascriptcoregtk-4.0
> gir1.2-webkit2-4.0/
> libjavascriptcoregtk-4.0-18
> libwebkit2gtk-4.0-37
> 
> It turns out that they won't upgrade automatically if you run apt upgrade or
> dist-upgrade, and if you try to install them manually here's the list of
> packages they break :

I installed all the packages that you mention (minus the ones that are
not in Debian) and I can do the upgrade just fine, so the problem has
to be in openra and/or steam-launcher.

We would need to see the exact output of the commands you're running,
but most likely the problem is in the unofficial packages. See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892216 for a related
problem.

Berto

Bug#876597: goocanvas FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available

[Alberto Garcia]

On Sun, Sep 24, 2017 at 01:08:34AM +0300, Adrian Bunk wrote:
> Source: goocanvas-2.0
> Version: 2.0.2-2
> Severity: serious
> Tags: buster sid

This seems to have been fixed in the most recent upstream version
(2.0.3). Packaging it should be enough to fix this bug.

Berto

Bug#862742: Error report for filetea

[Alberto Garcia]

On Tue, May 23, 2017 at 09:24:31AM +, Hari Krishna wrote:

> This is the patch for making filetea to work with jQuery
> v3.2.x. Hope this helps. Apply to upstream if needed.

This patch does not apply cleanly on the version of Filetea available
in Debian (0.1.16).

I'll try to backport it.

Berto

Bug#862742: Error report for filetea

[Alberto Garcia]

On Tue, Jun 06, 2017 at 11:32:43AM +0300, Adrian Bunk wrote:

> > > This is the patch for making filetea to work with jQuery
> > > v3.2.x. Hope this helps. Apply to upstream if needed.
> > 
> > Thanks for the patch, I'll forward it to upstream and discuss it
> > with him.
> > 
> > I guess another simpler possibility for the Debian case is to use
> > the libjs-jquery-migrate-1 package.
> 
> If filetea should not be removed from stretch, a fix has to be in
> unstable no later than tomorrow morning.

Thanks for pinging me, I'll try to upload the fixed version today.

Berto

Bug#862742: Error report for filetea

[Alberto Garcia]

On Tue, May 23, 2017 at 09:24:31AM +, Hari Krishna wrote:

> This is the patch for making filetea to work with jQuery v3.2.x. Hope this
> helps. Apply to upstream if needed.

Thanks for the patch, I'll forward it to upstream and discuss it with
him.

I guess another simpler possibility for the Debian case is to use the
libjs-jquery-migrate-1 package.

Berto

Bug#862742: Error report for filetea

[Alberto Garcia]

Control: tags -1 - unreproducible moreinfo

On Tue, May 23, 2017 at 07:14:39AM +, Hari Krishna wrote:

> ".live" method has been removed in jQuery version 1.9+. Please refer
> https://jquery.com/upgrade-guide/1.9/#live-removed

Yeah, I'm not sure how it worked last time I tried but I managed to
reproduce the problem now, thanks.

Berto

Bug#862742: filetea: Wrong version of jQuery gets installed

[Alberto Garcia]

Control: tags -1 moreinfo unreproducible

On Tue, May 16, 2017 at 12:30:10PM +, Rahul De wrote:

> The package uses the function live which has been removed in
> jQuery 1.9.  The source in the upstream depends on 1.7.2 and no
> version has been mentioned in the control file of the packaging
> for libjs-jquery. Hence the latest version(3.1.1) is fetched which
> breaks it and makes it unusable for everyone.

Hi,

I just tried filetea 0.1.16-3+b1 with libjs-jquery 3.1.1-2 and it
seems to work just fine. I shared a file between two machines without
problems.

What is the problem that you are having exactly?

Berto

Bug#855541: purple-matrix: Not ready for release yet

[Alberto Garcia]

On Thu, Feb 23, 2017 at 12:09:37AM +0100, Kurt Roeckx wrote:
> > > > Maybe I'm missing something, what is the scenario that you are
> > > > worried about?
> > > 
> > > So some of my worries:
> > > - It crashes for me a few times a week.
> > > - There seem to be various issues that don't make it behave
> > >   properly.
> > > - Maybe next year some of those issues have been fixed in
> > >   purple-matrix, it's recommended to use it for the desktop,
> > >   but then people install the version from Debian stable and
> > >   get a crappy version.
> > 
> > But how is that scenario better if there's no version at all in
> > Debian stable?
> 
> That they try to find it in a different place, like backports.
> 
> An other thing I'm concerned about is that I don't see any activity
> upstream.

Well, it's certainly not a very active project but there are pull
requests once a while and they are reviewed and merged when they are
ready.

I don't know, I see your concerns but I also see that this package
-even with missing features- covers a valid use case (I use it myself
after all). I don't have a strong opinion about this, to be honest.

Berto

Bug#855541: purple-matrix: Not ready for release yet

[Alberto Garcia]

On Wed, Feb 22, 2017 at 10:59:08PM +0100, Kurt Roeckx wrote:

> > I don't know, I think I would understand you better if I had a
> > list of specific problems that make this software unsuitable for
> > release.
> 
> I currently have a connection to my homeserver on 2 devices, and
> pidgin isn't receive any messages, but riot is. I have this problem
> every few days. And like I said, it's not clear where the problem
> is. It looks I can actually send things when in that state, and
> other people receive it, I just don't receive anything back.  And
> people generally blame purple-matrix for that if I tell I'm using
> that.

Ok, interesting.

> > > Like I said, if you think that you can support this version for
> > > the next 3 years, I have no problem with it. But I wouldn't add
> > > it to a stable release yet in it's current state.
> > 
> > I plan to keep using this plugin for the foreseeable time.
> 
> But do you think you'll still use this version, or will you upgrade
> the version you're running when there is a new upstream version?

Well, I'll upgrade it of course, and if there's any critical fix I'll
try to backport it.

> > Maybe I'm missing something, what is the scenario that you are
> > worried about?
> 
> So some of my worries:
> - It crashes for me a few times a week.
> - There seem to be various issues that don't make it behave
>   properly.
> - Maybe next year some of those issues have been fixed in
>   purple-matrix, it's recommended to use it for the desktop,
>   but then people install the version from Debian stable and
>   get a crappy version.

But how is that scenario better if there's no version at all in Debian
stable?

> - I don't know if it's still going to be compatible next year.

As far as I'm aware the client-server protocol is stable, well
documented and doesn't just break from one version to the next.

https://matrix.org/docs/spec/

Berto

Bug#855541: purple-matrix: Not ready for release yet

[Alberto Garcia]

On Mon, Feb 20, 2017 at 06:52:58PM +0100, Kurt Roeckx wrote:

> It's just that each time I mention I'm using this, people tell me
> taht it's experimental, and probably a bug in purple-matrix. But
> it's at least not always clear to me where the bugs are, and there
> seem to be various problems with the homeserver (synapse) too.

I don't know, I think I would understand you better if I had a list of
specific problems that make this software unsuitable for release.

I've been using it daily for months as my primary Matrix client on
my desktop computer, and the only issues I found are occasional
disconnects (and I'm not even sure that it's not a server problem).

> There are more problems with purple-matrix then that. For instance
> from the description of the package itself:
>  The following are not yet supported:
>   * Creating new rooms (and one-to-one chats)
>   * Joining existing rooms by alias instead of room_id

Those are clear missing features, and yes, you need a different client
to join a room. For some people that's probably an essential feature,
that's why it's clearly indicated in the package description.

In my case I only follow a limited number of rooms, I don't need to
join or create new ones, so this keeps me from having yet another chat
client open all the time.

> Like I said, if you think that you can support this version for the
> next 3 years, I have no problem with it. But I wouldn't add it to a
> stable release yet in it's current state.

I plan to keep using this plugin for the foreseeable time.

If this goes to stretch then it will be a simple Matrix client with
few dependencies and limited functionality, but otherwise stable
enough for everyday use.

Maybe I'm missing something, what is the scenario that you are worried
about?

Berto

Bug#855541: purple-matrix: Not ready for release yet

[Alberto Garcia]

On Mon, Feb 20, 2017 at 09:33:55AM +0100, Kurt Roeckx wrote:

> > Could you be a bit more specific about the problems? In my
> > experience it disconnects (infrequently) and it lacks some
> > features, but other than that it's perfectly usable.
> 
> See for instance:
> https://github.com/matrix-org/purple-matrix/issues/34

Well, that looks like a legitimate bug, but I wouldn't say that it
makes the package unusable. I cannot even reproduce it myself.

> Anyway, if you disagree with the severity, feel free to close this
> bug.

I can rename this bug and make it about that tab completion crash that
you reported upstream, but I don't see it as a generic "purple-matrix
is not ready yet".

Berto

Bug#855541: purple-matrix: Not ready for release yet

[Alberto Garcia]

On Mon, Feb 20, 2017 at 12:12:35AM +0100, Kurt Roeckx wrote:

> I think this version shouldn't be shipped with the next
> release. Like the description says, it's "somewhat alpha".
> 
> It works some times, but then stops working, it crashes,
> and so on.

I've been using it daily for several months with very few issues and
zero crashes.

Could you be a bit more specific about the problems? In my experience
it disconnects (infrequently) and it lacks some features, but other
than that it's perfectly usable.

Berto

Bug#850149: shotwell: Freezes when trying to open an image in fullscreen mode

[Alberto Garcia]

On Tue, Feb 14, 2017 at 06:36:05PM +, Debian Bug Tracking System wrote:
>  shotwell (0.25.4+really0.24.5-0.1) unstable; urgency=medium
>  .
>* Revert to last stable release 0.24.5 (Closes: #850149).

Thanks for this! Shotwell is finally usable again.

However the original problem (as described in the first comment) is
still present, do you want me to file a separate bug for that, or what
do you prefer?

Regards,

Berto

Bug#855103: Rendering fails on wayland/hidpi

[Alberto Garcia]

Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=168128
Control: tags -1 upstream fixed-upstream

On Tue, Feb 14, 2017 at 08:54:16AM +0100, Sjoerd Simons wrote:

> Both epiphany and evolution show blank output when trying to render
> website/e-mails. Downgrading libwebkit2gtk-4.0-37 to 2.14.3 seems to
> solve the issue.

webkitgtk 2.14.5 is about to be published with the fix for this.

Berto

Bug#848132: most is vulnerable to a shell injection attack using LZMA-compressed files

[Alberto Garcia]

Package: most
Version: 5.0.0a-1
Severity: grave
Tags: security patch
Justification: user security hole

Hello,

the most pager can automatically open files compressed with gzip,
bzip2 and (in Debian) LZMA.

This is done using popen() and, in earlier releases of most, it was
vulnerable to a shell injection attack.

most fixed this in v5.0.0 (released in 2007), but the Debian patch
that added LZMA support (bug #466574) remains vulnerable.

It is trivial to generate a file with a certain name and content that,
when opened with most, runs arbitrary commands in the user's computer.

most is also launched by other programs as a pager for text files
(example: an e-mail client that needs to open an attachment). If any
of those programs generates a temporary file name that can be set by
an attacker, then that can be used to break into the user's machine.
I don't have any example of such program, however.

All versions of most >= 5.0.0a-1 including 5.0.0a-2.5 in Debian
(and derivatives that include the LZMA patch) are vulnerable (older
versions are vulnerable in all distros as I explained earlier).

   https://security-tracker.debian.org/tracker/CVE-2016-1253

I'm attaching the debdiff with the patch. It simply replaces single
quotes with double quotes in the command passed to popen(). Double
quotes in the filename are escaped by most in order to prevent this
kind of attacks, but this offers no protection if the file name is
enclosed in single quotes.

Regards,

Berto

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages most depends on:
ii  libc6  2.24-7
ii  libslang2  2.3.1-5

most recommends no packages.

most suggests no packages.

-- no debconf information
diff -Nru most-5.0.0a/debian/changelog most-5.0.0a/debian/changelog
--- most-5.0.0a/debian/changelog	2016-08-05 02:55:52.0 +0300
+++ most-5.0.0a/debian/changelog	2016-12-14 14:31:29.0 +0200
@@ -1,3 +1,12 @@
+most (5.0.0a-2.6) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * lzma-support.patch:
+- Fix CVE-2016-1253 (shell injection attack when opening
+  lzma-compressed files).
+
+ -- Alberto Garcia   Wed, 14 Dec 2016 14:31:29 +0200
+
 most (5.0.0a-2.5) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru most-5.0.0a/debian/patches/lzma-support.patch most-5.0.0a/debian/patches/lzma-support.patch
--- most-5.0.0a/debian/patches/lzma-support.patch	2016-07-22 01:50:23.0 +0300
+++ most-5.0.0a/debian/patches/lzma-support.patch	2016-12-14 14:25:03.0 +0200
@@ -1,3 +1,5 @@
+Index: most-5.0.0a/src/file.c
+===
 --- most-5.0.0a.orig/src/file.c
 +++ most-5.0.0a/src/file.c
 @@ -77,7 +77,7 @@ static int create_gunzip_cmd (char *cmd,
@@ -32,13 +34,15 @@
  	
  	if (cmd != NULL)
  	  {
+Index: most-5.0.0a/src/file.h
+===
 --- most-5.0.0a.orig/src/file.h
 +++ most-5.0.0a/src/file.h
 @@ -22,6 +22,7 @@
  #define MOST_MAX_FILES 4096
  #define MOST_GUNZIP_POPEN_FORMAT "gzip -dc \"%s\""
  #define MOST_BZIP2_POPEN_FORMAT "bzip2 -dc \"%s\""
-+#define MOST_LZMA_POPEN_FORMAT "lzma -dc '%s'"
++#define MOST_LZMA_POPEN_FORMAT "lzma -dc \"%s\""
  
  extern void most_reread_file (void);
  extern void most_read_to_line (int);

Bug#839379: yelp: FTBFS: segmentation fault

[Alberto Garcia]

On Fri, Oct 28, 2016 at 02:38:18PM +0200, Michael Biebl wrote:

> > This is already fixed upstream, the next 2.14.x release of WebKit
> > won't need this hack.
> 
> When do you expect that next upstream release to be uploaded to
> unstable?

The release is expected to happen this week.

Berto

Bug#839379: yelp: FTBFS: segmentation fault

[Alberto Garcia]

On Fri, Oct 28, 2016 at 03:38:46AM +0200, Michael Biebl wrote:

> I built yelp inside a chroot (without X) and ran
> docs/libyelp/libyelp-scan directly. The resulting backtrace from the
> crash is attached. This looks to me like it's webkit2 related, so
> I'm reassigning the bug.

It looks like #839397. Can you try adding this to debian/rules and see
if that fixes the problem?

export WEBKIT_DISABLE_COMPOSITING_MODE=1

This is already fixed upstream, the next 2.14.x release of WebKit
won't need this hack.

Berto

Bug#834147: binutils: breaks mips and mipsel link of blender

[Alberto Garcia]

On Fri, Aug 12, 2016 at 02:06:53PM +, Gianfranco Costamagna wrote:

> Hi, as said the latest blender upload is not working anymore, and
> since the failure seems to be in ld.gold, I presume the changes
> between 2.26.1 and 2.27 broke the link.
  [...]
> /usr/bin/ld.gold: error: Can't find matching LO16 reloc
> /usr/bin/ld.gold: error: Can't find matching LO16 reloc

webkit2gtk is also affected by this. Switching to ld.bfd seems to
solve the problem.

Berto

Bug#835285: webkit2gtk FTBFS

[Alberto Garcia]

On Fri, Aug 26, 2016 at 12:35:16AM +0200, Thomas Goirand wrote:

> > Can I see the full log anywhere? Maybe you don't have enough RAM
> > to build webkit? What machine did you build it on?
> 
> Oh, I didn't think about that. I tried on a 4GB virtualbox machine,
> and in a 8GB VM (but no swap) on an OpenStack cloud, each time I
> had the same result. So I guess you must be right, and there's not
> enough RAM.

You can try building it with less debug symbols or with no debug
symbols at all (see debian/rules).

But that's with 8GB, I don't think you can build webkitgtk with 4GB,
but I might be wrong.

Berto

Bug#835285: webkit2gtk FTBFS

[Alberto Garcia]

On Wed, Aug 24, 2016 at 10:40:59AM +0200, Thomas Goirand wrote:

> I've been strugling to rebuild webkit2gtk backport. I tried with
> 2 environement, one using Jessie and sbuild, and one using a
> virtualbox machine without sbuild.  Both times, I had the below
> output:
> 
> collect2: error: ld returned 1 exit status
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/build.make:19680: recipe 
> for target 'lib/libjavascriptcoregtk-4.0.so.18.3.11' failed
> 
> I'm not pasting the full command line for linking, because it's
> really huge.

Can I see the full log anywhere? Maybe you don't have enough RAM to
build webkit? What machine did you build it on?

webkit2gtk should build fine on all jessie-backports architectures:

https://buildd.debian.org/status/package.php?p=webkit2gtk&suite=jessie-backports

Berto

Bug#802380: epiphany-browser: System crashes when visiting reuters.com URL (GPU crash?)

[Alberto Garcia]

On Mon, Oct 19, 2015 at 12:45:30PM -0700, David Glover-Aoki wrote:

> When visiting the following URL in Epiphany/Web:
> http://www.reuters.com/article/2015/10/18/us-new-york-flightcenter-
> idUSKCN0SC14B20151018
> 
> The entire screen turns black, then red, then finally is covered in garbage
> random red pixels. It looks very much like a GPU crash. At this point the
> system is hung and must be rebooted.

We believe that this is fixed in WebKitGTK 2.13.4, currently available
in Debian experimental.

Can you try that version and confirm that it solves your problem?

Thanks!

Berto

Bug#830516: clex: Cannot read the keyboard input

[Alberto Garcia]

Package: clex
Version: 3.15-1+b1
Severity: grave
Justification: renders package unusable

Hi,

It seems that I'm unable to run clex at all:

 -
$ clex




Starting CLEX 3.15

Terminating CLEX: Cannot read the keyboard input
 -

I don't know what's causing this, but strace shows a lot of failing
ioctls:

ioctl(0, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
ioctl(0, TIOCGPGRP, [2608]) = 0
ioctl(0, TIOCSPGRP, [2612]) = 0
ioctl(1, TCGETS, 0x7ffee7859f80)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, TCGETS, 0x7ffee7859f80)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, TCGETS, 0x7ffee7859f20)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, TCGETS, 0x7ffee7859ee0)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, TCGETS, 0x7ffee7859f50)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, TCGETS, 0x7ffee7859f60)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(1, TCGETS, 0x7ffee7859f80)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, TCGETS, 0x7ffee7859f60)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, SNDCTL_TMR_STOP or TCSETSW, {B0 -opost isig -icanon -echo ...}) = -1 
ENOTTY (Inappropriate ioctl for device)
ioctl(2, TCGETS, 0x7ffee785a070)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, TCGETS, 0x7ffee785a010)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, SNDCTL_TMR_STOP or TCSETSW, {B0 -opost -isig -icanon -echo ...}) = -1 
ENOTTY (Inappropriate ioctl for device)
ioctl(2, TCGETS, 0x7ffee7859ee0)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, SNDCTL_TMR_STOP or TCSETSW, {B0 -opost -isig -icanon -echo ...}) = -1 
ENOTTY (Inappropriate ioctl for device)
ioctl(0, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
ioctl(0, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig -icanon -echo ...}) 
= 0
ioctl(0, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
ioctl(0, TIOCSPGRP, [2608]) = 0

Regards,

Berto

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages clex depends on:
ii  libc62.22-11
ii  libncurses5  6.0+20160319-1
ii  libtinfo56.0+20160319-1

clex recommends no packages.

clex suggests no packages.

-- no debconf information

Bug#826991: fastboot missing libziparchive.so.0

[Alberto Garcia]

On Fri, Jun 10, 2016 at 10:04:35PM +, Mouaad Aallam wrote:

> fastboot fails, says libziparchive.so.0 is missing:
> 
> $fastboot devices
> fastboot: error while loading shared libraries: libziparchive.so.0: cannot 
> open shared object file: No such file or directory

Same problem here, but with libext4_utils.so.0 instead:

$ fastboot
fastboot: error while loading shared libraries: libext4_utils.so.0: cannot open 
shared object file: No such file or directory

$ ldd /usr/bin/fastboot
linux-vdso.so.1 (0x7ffdc29c3000)
libziparchive.so.0 => /usr/lib/android/libziparchive.so.0 
(0x7f58671ab000)
libsparse.so.0 => /usr/lib/android/libsparse.so.0 (0x7f5866fa3000)
libext4_utils.so.0 => not found
libf2fs_utils.so.0 => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f5866bd5000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f58669b9000)
libutils.so.0 => /usr/lib/android/libutils.so.0 (0x7f5866793000)
liblog.so.0 => /usr/lib/android/liblog.so.0 (0x7f586658b000)
libbase.so.0 => /usr/lib/android/libbase.so.0 (0x7f5866385000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f5866005000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5865d07000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f5865af)
/lib64/ld-linux-x86-64.so.2 (0x56389cce9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f58658d3000)
libcutils.so.0 => /usr/lib/android/libcutils.so.0 (0x7f58656c7000)
libbacktrace.so.0 => /usr/lib/android/libbacktrace.so.0 
(0x7f58654ba000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f58652b2000)
libunwind.so.0 => not found

$ ls /usr/lib/x86_64-linux-gnu/android/
libext4_utils.so.0  libf2fs_utils.so.0  libselinux.so.0  libunwind.so.0

Berto