Bug 1959319

Gentle ping: this bug is blocking an important gcc update in rawhide/f34.

Ping again…

Is anybody looking at QtWebEngine at all anymore or do I need to take the package back for something to happen? And if the latter, are you going to give it to me out voluntarily or do I really have to start the nonresponsive maintainer process? I understand that you are busy, we all are, but there are also the 5.15.x bugfix and security releases in upstream git that need to be worked on urgently.

I would have responded earlier, but I have been offline for the last 2 weeks for health reasons.

I'll try the quick-n-dirty workaround suggested in bug #1945595 first.

Longer-term plans are to actually update qtwebengine, but upstream has made that complicated unfortunately.

Created attachment 1791365 [details]
qtwebengine-release.sh

The attached script builds a 5.15.3 release tarball (or at least it did back when 5.15.3 was current, I have not tried running it since, though I wrote it in such a way that it SHOULD keep working permanently). It is already outdated though because current is 5.15.4 now.

unfortunately, the script you provided me via email no longer works, appears Qt shutdown code.qt.io.  I'm trying the debian equivalant of that to see if I can generate a workable tarball: current work-in-progress:

CURDIR=$(pwd)
TEMPDIR=$(mktemp -d)
VERSION=5.15.3
SUBMODULE_COMMIT=d9d9e606cb34b1b4ac0f44de132b1eb10763f1f6
cd ${TEMPDIR}
wget https://github.com/qt/qtwebengine/archive/${VERSION}.tar.gz && \
tar xzf ${VERSION}.tar.gz && \
cd qtwebengine-${VERSION}/src/3rdparty && \
wget https://github.com/qt/qtwebengine-chromium/archive/${SUBMODULE_COMMIT}.tar.gz && \
tar xz --strip-components=1 -f ${SUBMODULE_COMMIT}.tar.gz && \
rm ${SUBMODULE_COMMIT}.tar.gz && \
cd ${TEMPDIR}/qtwebengine-${VERSION} && \
cd src/3rdparty/chromium/third_party/devtools-frontend/src/node_modules && \
ls -A | grep -Ev '^(@types|rollup|typescript)$$' | xargs rm -rf && \
cd ${TEMPDIR} && \
tar cJ --sort=name -f ${CURDIR}/qtwebengine-opensource-src-${VERSION}.tar.xz qtwebengine-${VERSION} && \
rm -rf ${TEMPDIR}

Arg, turns out my @dayjob wifi network makes .qt.io unreachable (just for me).  Nevermind.

First try at 5.15.5 scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=70574124

Fixed 2 other FTBFS issues with 5.15.2, now hit a 3rd:

In file included from gen/v8/v8_base_without_compiler_jumbo_29.cc:6:
./../../3rdparty/chromium/v8/src/objects/js-list-format.cc: In static member function 'static v8::internal::MaybeHandle<v8::internal::JSListFormat> v8::internal::JSListFormat::New(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Map>, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>)':
./../../3rdparty/chromium/v8/src/objects/js-list-format.cc:145:69: error: 'static icu_69::ListFormatter* icu_69::ListFormatter::createInstance(const icu_69::Locale&, const char*, UErrorCode&)' is private within this context
  145 |   icu::ListFormatter* formatter = icu::ListFormatter::createInstance(
      |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
  146 |       icu_locale, GetIcuStyleString(style_enum, type_enum), status);
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
In file included from ./../../3rdparty/chromium/v8/src/objects/js-list-format.cc:25,
                 from gen/v8/v8_base_without_compiler_jumbo_29.cc:6:
/usr/include/unicode/listformatter.h:267:27: note: declared private here
  267 |     static ListFormatter* createInstance(const Locale& locale, const char* style, UErrorCode& errorCode);
      |                           ^~~~~~~~~~~~~~

*** Bug 1945595 has been marked as a duplicate of this bug. ***

First real try at official 5.15.5 build,
https://koji.fedoraproject.org/koji/taskinfo?taskID=70984536

Latest commit,
https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/d122c011631137b79455850c363676c655cf9e09

Succeeded, will followup with f34 builds soon (once I have rpmfusion updated too)

Great, thanks very much

Upstream fix for the std::max(16384, SIGSTKSZ) issue posted to https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3340721