Update qtwebengine to 2021-05-03.

This commit is contained in:
Ken Moffat 2021-05-06 21:15:00 +01:00
parent 70896c42b5
commit 685b8672b8
2 changed files with 39 additions and 6 deletions

View File

@ -43,6 +43,10 @@
<listitem>
<para>May 6th, 2021</para>
<itemizedlist>
<listitem>
<para>[ken] - Patch qtwebengine-20210401 for latest fixes. Fixes
<ulink url="&blfs-ticket-root;14999">#14999</ulink>.</para>
</listitem>
<listitem>
<para>[renodr] - Update to ICU-69.1. Fixes
<ulink url="&blfs-ticket-root;14884">#14884</ulink>.</para>

View File

@ -13,7 +13,7 @@
<!ENTITY qtwebengine-md5sum "97ee413dccf03d2fc09a7718f39367f7">
<!ENTITY qtwebengine-size "306 MB">
<!ENTITY qtwebengine-buildsize "5.1 GB (154 MB installed)">
<!ENTITY qtwebengine-time "101 SBU (Using parallelism=4)">
<!ENTITY qtwebengine-time "100 SBU (Using parallelism=4)">
]>
<sect1 id="qtwebengine" xreflabel="qtwebengine-&qtwebengine-version;">
@ -79,8 +79,8 @@
<para> <!-- for git versions -->
The tarball linked to below was created from the 5.15 git branch
and the 87-branch of the chromium submodule (which is forked from
chromium). See the GIT-VERSIONS file in the tarball for details of
the latest commits.
chromium). See the GIT-VERSIONS file in the tarball (after applying
any patches) for details of the latest commits.
</para>
</warning>
@ -119,6 +119,12 @@
in a similar way, but remember that everythng EXCEPT qtwebengine and chromium
is private to Qt until they choose to release it.
NOTE: the 3rdparty/chromium tree may contain more patches than have been
merged into the current 5.15.x branch. Any patches after what was in the
last 'update chromium' merge in qtwebengine may break the build. When Qt
is close to releasing a paid-for 5.15 version, items from 5.15.x get merged
into 5.15.
After merging the contents of the qtwebengine and src/3rdparty git extracts,
in the top level please create a GIT-VERSIONS file summarising the HEAD
commits of both parts, as a reminder of where we are up to.
@ -129,6 +135,17 @@
the qtwebengine-chromium module). Then in a work area untar the qtwebengine
tarball, go down to src/3rdparty and untar the submodule tarball.
Decide on what to call the result and create a full xz tarball using tar -cJf.
UPDATE: Since we have to host the tarball, and it is over 300MB, it makes
sense to create a patch for subsequent fixes (for the first version, 314KB
including the updates to the GIT-VERSIONS file). For future updates, view
the current updates patch to see the previous commits. When the new commits
have been applied, rename the updated version to 'b', but untar the
unpatched tarball as 'a' and then diff a to b in the usual manner to get
all updates since the tarball was created.
For our own releases, probably best to create a fresh tarball.
end of note for editors -->
&lfs101_checked;
@ -195,7 +212,13 @@
<!-- keep links for releases and git versions as a reminder
that the tarball names names differ
<ulink url="&patch-root;/qtwebengine-everywhere-src-&qtwebengine-version;-ICU68-2.patch"/> -->
<ulink url="&patch-root;/qtwebengine-&qtwebengine-version;-build_fixes-1.patch"/>
<ulink url="&patch-root;/qtwebengine-&qtwebengine-version;-build_fixes-2.patch"/>
</para>
</listitem>
<listitem>
<para>
Required patch:
<ulink url="&patch-root;/qtwebengine-&qtwebengine-version;-upstream_fixes-1.patch"/>
</para>
</listitem>
</itemizedlist>
@ -271,11 +294,17 @@
Now apply a patch to fix several issues that can prevent the build working:
</para>
<screen><userinput remap="pre">patch -Np1 -i ../qtwebengine-&qtwebengine-version;-build_fixes-1.patch</userinput></screen>
<screen><userinput remap="pre">patch -Np1 -i ../qtwebengine-&qtwebengine-version;-build_fixes-2.patch</userinput></screen>
<para>
Next apply a patch for security and other fixes:
</para>
<screen><userinput remap="pre">patch -Np1 -i ../qtwebengine-&qtwebengine-version;-upstream_fixes-1.patch</userinput></screen>
<!-- start of commands for git versions only -->
<para>
Although the patch has ensured that git is not invoked during the build,
Although the first patch has ensured that git is not invoked during the build,
the build system has labyrinthine rules of byzantine complexity, and in
particular trying to build without two <filename>.git</filename> directories
will lead to it eventually falling into unexpected and unbuildable code