Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

Dominique MARTINET wrote on Tue, Sep 27, 2022 at 10:10:40AM +0900:
> (Or I guess I could actually build the deb package now I have ldd figured
> out, but allowing partial builds would be great for actual development...)

hmpf!

So I have rebuilt as a package, and it .. just works?

At this point I'm starting to think the build environment matters quite
a bit, would you mind comparing with what I'm doing:

- I do not have any beefy aarch64 machine, so building from a x86_64
host with qemu-user-static and binfmt

- in order to get the sysroot I just run inside a container:
podman run docker.io/arm64v8/debian:bullseye
(using a volume for build data)

- in that container I intalled all required dependencies with apt
build-dep in build tree, I don't think there is anything else, so it
should be similar to pdebuild

- there is a bug with ldd and qemu user: I replace ldd with the
following script
---
#!/bin/sh

lddtree "$@" 2>/dev/null \
	| sed -e '/^[^ ]/d' -e 's/^  */\t/' \
		-e 's/ld-linux-aarch64.so.1.*/ld-linux-aarch64.so.1/' \
		-e 's/$/ (0x0000005501acc000)/'
---
This is used by g-ir-scanner afaiu; build fails for me without it.

- I used the upstream tarball
https://webkitgtk.org/releases/webkitgtk-2.38.0.tar.xz

- I used the debian directory from sid, with a few adjustments:
http://deb.debian.org/debian/pool/main/w/webkit2gtk/webkit2gtk_2.38.0-2.debian.tar.xz
--------
diff -ur orig/debian/patches/series webkitgtk-2.38.0/debian/patches/series
--- orig/debian/patches/series	2022-09-26 18:25:41.000000000 +0900
+++ webkitgtk-2.38.0/debian/patches/series	2022-09-27 10:27:48.811885275 +0900
@@ -5,3 +5,4 @@
 dont-detect-sse2.patch
 reduce-memory-overheads.patch
 fix-ftbfs-hurd.patch
+fix-bullseye.patch
diff -ur orig/debian/rules webkitgtk-2.38.0/debian/rules
--- orig/debian/rules	2022-09-26 18:25:41.000000000 +0900
+++ webkitgtk-2.38.0/debian/rules	2022-09-27 11:09:31.391250044 +0900
@@ -12,8 +12,8 @@
 # soup3 build -> 4.1 API packages
 # gtk4 build  -> 5.0 API packages
 ENABLE_SOUP2=YES
-ENABLE_SOUP3=YES
-ENABLE_GTK4=YES
+ENABLE_SOUP3=NO
+ENABLE_GTK4=NO
 # Set to YES to use the docs from the tarball instead of generating them.
 # Use only if gi-docgen is not available.
 USE_PREBUILT_DOCS=NO
diff -ur orig/debian/control.in webkitgtk-2.38.0/debian/control.in
--- orig/debian/control.in	2022-09-26 18:25:41.000000000 +0900
+++ webkitgtk-2.38.0/debian/control.in	2022-09-27 11:11:07.441672820 +0900
@@ -51,7 +51,7 @@
                libegl1-mesa-dev,
                libgl-dev,
                libgles-dev
-Build-Depends-Indep: gi-docgen, libglib2.0-doc, libgtk-3-doc, libsoup2.4-doc
+Build-Depends-Indep: libglib2.0-doc, libgtk-3-doc, libsoup2.4-doc
 Standards-Version: 4.6.1.0
 Rules-Requires-Root: no
 Vcs-Browser: https://salsa.debian.org/webkit-team/webkit
---------

+ fix-bullseye.patch as per link
---------
--- a/Source/WebKit/UIProcess/API/glib/WebKitWebsiteDataManager.cpp	
+++ a/Source/WebKit/UIProcess/API/glib/WebKitWebsiteDataManager.cpp	
@@ -498,6 +498,9 @@ WebKit::WebsiteDataStore& webkitWebsiteDataManagerGetDataStore(WebKitWebsiteData
             configuration->setServiceWorkerRegistrationDirectory(FileSystem::stringFromFileSystemRepresentation(priv->swRegistrationsDirectory.get()));
         if (priv->domCacheDirectory)
             configuration->setCacheStorageDirectory(FileSystem::stringFromFileSystemRepresentation(priv->domCacheDirectory.get()));
+#if !ENABLE(SERVER_PRECONNECT)
+        configuration->setAllowsServerPreconnect(false);
+#endif
         priv->websiteDataStore = WebKit::WebsiteDataStore::create(WTFMove(configuration), PAL::SessionID::generatePersistentSessionID());
         priv->websiteDataStore->setIgnoreTLSErrors(priv->tlsErrorsPolicy == WEBKIT_TLS_ERRORS_POLICY_IGNORE);
     }
---------

- I built without documentation because no gi-docgen:
DEB_BUILD_OPTIONS=nodoc dpkg-buildpackage


With that package, epiphany works just fine.


I will rebuild the package again without the patch, to check if I can
reproduce the issue without it in my build environment.

That takes quite a while, so will probably only report back tomorrow.


Thanks,
-- 
Dominique