qtwebengine-5.15.8

[ken@…]

The paid-for 5.15.8 Qt release was announced today, ​https://www.qt.io/blog/commercial-lts-qt-5.15.8-released and therefore the public qtwebengine source can be retrieved.

I lack cycles at the moment, but hope to get to this in a few days. Meanwhile, is my current "add a patch rather than a tarball, because of the space implications for both BLFS and our mirrors" approach the best way to go ?

I think Doug is unhappy with this approach, and it also means that we claim to be building 5.15.6 on a quick look at the book.

The next release, 5.15.9, is planned for the beginning of March.

Flagging as elevated, because there were the usual batch of CVE fixes when I looked before Xmas.

[Bruce Dubbs]

I see that Arch is set at 5.15.7 via git:

_qtver=5.15.7
pkgver=${_qtver/-/}

source=(git+https://code.qt.io/qt/qtwebengine.git#tag=v${pkgver}-lts
        git+https://code.qt.io/qt/qtwebengine-chromium.git
        git+https://chromium.googlesource.com/catapult#commit=5eedfe23148a234211ba477f76fc2ea2e8529189
        qt5-webengine-python3.patch
        qt5-webengine-chromium-python3.patch)

Should we be doing something similar and creating our tarball from that and using the appropriate version?

[ken@…]

I thought I'd seen the tree somewhere, but it didn't show up when I was last looking at the kf5.15 trees, although I can see the current files in the kf5.15 online repo.

Obvious really - it isn't in kde/5.15 because it's fully public (although the kf5.15 patches can lag behind it, because someone has to propose them for kf5.15, and someone then has to apply them).

At the moment I pull qtwebengine.git from the 5.15 branch, qtwebengine-chromium from the correct branch (from memory, 87-based but the tabs for those are on another machine), then review our patches (those include inter-alia fixes for not building in a git tree (Arch force that), sed to keep the version as 5.15.2, Doug's fix for when libxml2 has been built before ICU.

The catapault commit might be something we already have among the patches - no idea. Their two python3 patches sound interesting.

I'm assuming that we want to keep installing as 5.15.2. That is what I've been doing with the other kf5.15 patches (got as far as building kf5.15 itself, but not any apps nor plasma so no proof that it all hangs together, and no time until at least after doing next firefox esr and qtwebengine).

[ken@…]

I see that Arch updated to 5.15.8 a few hours ago.

Is the consensus that we should have a new tarball (rather more than 300MB) for every 5.15 point release ? And keep everything that is not upstream in the build_fixes patch ? The chromium python3 patch is large, but it would make sense to put everything currently required into one patch.

[Bruce Dubbs]

We might want to consider creating a patched tarball. Then the user doesn't have to download two and apply the 2nd as a patch. I can think of some pros and cons for that approach.

[ken@…]

Replying to Bruce Dubbs:

We might want to consider creating a patched tarball. Then the user doesn't have to download two and apply the 2nd as a patch. I can think of some pros and cons for that approach.

A patched tarball makes it a lot harder to clarify what we are doing which is not upstream.

[ken@…]

I'm now starting to look at this. It looks as if some of the existing fixes are now upstream, so will need to break down our patch into its parts.

Looking at Arch's history with patching for python3, I'm slightly worried that future chromium changes might need other changes to the python3 fixes. OTOH I'm well behind Arch in doing this, so probably they'll be there before I get to it for 5.15.9.

My current plan is to look at our patches, batch up whatever is left, and try to build using python2.7 before making changes for python3. The machine where I'm doing this is still on python3.9, but I'll also be testing on 3.10 when I get that far.

[ken@…]

A small setback on this build: I have updated to icu70 for firefox, qt5 is still linked against icu69.

/usr/bin/ld: warning: libicui18n.so.69, needed by /opt/qt5/lib/libQt5Core.so, may conflict with libicui18n.so.70
/usr/bin/ld: warning: libicuuc.so.69, needed by /opt/qt5/lib/libQt5Core.so, may conflict with libicuuc.so.70

Rebuilding Qt5 ...

[ken@…]

That works ok. Looking at hte Arch patches for python3, we cannot use them as-is:

--- a/chromium/build/print_python_deps.py
+++ b/chromium/build/print_python_deps.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python2.7
+#!/usr/bin/python

They have python -> python3.

Similarly, their patch for qtwebengine itself will look for python instead of python2.7. But that *might* be achievable by using a sed instead of a patch.

The bug for updating chromium to python3 is ​https://bugs.chromium.org/p/chromium/issues/detail?id=942720.

[ken@…]

Replying to ken@…:

They have python -> python3.

Similarly, their patch for qtwebengine itself will look for python instead of python2.7. But that *might* be achievable by using a sed instead of a patch.

No, looks as if the first part needs a patch similar to theirs, and then the remaining parts need changing for ython2 to ython3.

I'm tempted to create my own patches by trying to replicate what Arch are doing, but looking at the chromium patch I don't think it will be maintainable going forward.

From ​https://bugs.gentoo.org/698988 chromium 93+ supports python3, but qtwebengine5 is on chromium 87 and only gets security backports. Qtwebengine6 apparently supports python3, but that is no use for anything in kde5 that uses qtwebengine.

Staying with python2. :-(

[ken@…]

Updated in @9e0ab8337e7fd97980606b2d7daaa75b96c2956f 11.0-419

[ken@…]

Security Advisory SA 11.0-057.