Skip to content

Import packaging for QtWebengine version 5.15.10

Ratchanan Srirattanamet requested to merge personal/peat-psuwit/qtwebengine-5-15-9 into ubports/xenial

This MR is a start-from-scratch attempt to build the latest version of QtWebengine against UBports' Xenial. The branch starts from Debian's packaging for experimental, then:

  • Make the build import upstream's tarballs, as we need certain bundled files that Debian excluded.
  • The build is made to use Clang 8 and NodeJS 12, available in Xenial specifically to build more recent versions of Chromium and Firefox.
  • A number of reverts are made, so that we're using bundled versions of libraries instead of system ones when they're too old.
  • Selected numbers of UBports patches are re-added. Specifically, the hybris camera support patch is adapted to changes in Chromium 87.
  • The symbol files are adapted to Clang build result.

When the MR is approved, I'll have to force-push the branch over ubports/xenial. A backup tag will be made.

Since CI won't build an MR with conflicts, this MR is also available at ubports/xenial_-_qtwebengine-5-15-x branch, which should be identical to this MR except the debian/changelog. To test, please uses ubports-qa like so:

sudo ubports-qa install PR_morph-browser_530 # Fixes custom HTTP error page breakage.
sudo ubports-qa install xenial_-_qtwebengine-5-15-x

After that, make sure to re-launch Morph Browser so that it picks up the new version of QtWebengine.

You may also find these documents from Ubuntu Wiki useful:

A note on the orig tarball situation (or: why ubports.source_location lists 2 tarballs?)

Because Xenial doesn't have certain node modules that Chromium requires, we need the bundled files that Debian excludes from its tarball (for DFSG compliance). That means we cannot use Debian's tarball. And because there isn't actually Qt 5.15.9 release for OSS, we can't use Qt's released tarball either.

So, we have to grab the tarball ourselves from git snapshot. However, the way QtWebengine's repository is structured is that it contains a separated git submodule for all Chromium code. That requires us to be a bit creative about how to get the orig tarball.

I can think of 4 options:

  • debian/rules contain a standard target get-orig-source which, as the name suggested, get and repack the orig tarball for you. So, we can add a support for it in our build-tools. To make sure the orig tarball stays the same across the builds, subsequent builds can pull the orig tarball from Aptly.
    • Pros: Completely transparent. Pave the way for deprecating ubports.source_location
    • Cons: Too much upfront cost?
  • Repack it locally. Host it on some file hosting server. Initially points ubports.source_location to that, and then points ubports.source_location to Aptly for subsequent builds.
    • Cons: Not transparent.
  • Repack it in e.g. GitLab CI, and point ubports.source_location to that.
    • Pros: transparent.
    • Cons: Means a throw-away branch has to be used.
  • Pulls git snapshots from both of repositories, and use them as orig tarballs. However, since dpkg cannot extract an add-on orig tarball into a sub-directory, a symlink has to be placed to put the source in the correct layout.
    • Pros: Transparent. Can be done right away.
    • Cons: Not what the upstream does, so prone to breakage.

In the end, I've chosen to go with the last method. Only 1 patch has to be made against the code to support this case.

Edited by Ratchanan Srirattanamet

Merge request reports