dev-qt/qtwebkit:5 is marked as deprecated, but there's actually an updated half-official version of it available, see https://github.com/annulen/webkit/wiki It's mostly a drop-in replacement, based on an upstream WebKit which is roughly 3 years newer than the QtWebKit in Qt's community releases (plus even more security fixes from WebKit's trunk). There's an ebuild by the author here: https://gist.github.com/annulen/309569fb61e5d64a703c055c1e726f71 Archlinux had a qt5-webkit-ng package since January and recently merged it into qt5-webkit: https://lists.archlinux.org/pipermail/arch-dev-public/2017-January/028656.html https://lists.archlinux.org/pipermail/arch-dev-public/2017-June/028895.html Fedora also updated its package: http://lupinix.blogspot.ch/2017/06/improving-qtwebkit-security-for-fedora.html Debian and Void Linux are in the progress of doing so: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862452 https://github.com/voidlinux/void-packages/pull/6876
Yes, I'm aware of that effort. I was waiting for it to become more mature. It seems the time has come. On the other hand, a couple of months ago there was a discussion upstream about "merging" the new QtWebKit into the official webkit module, or at least release it as the official module with an independent schedule, but I don't remember if an agreement was reached... @Konstantin, what was the decision back then?
(In reply to Davide Pesavento from comment #1) > Yes, I'm aware of that effort. I was waiting for it to become more mature. > It seems the time has come. > > On the other hand, a couple of months ago there was a discussion upstream > about "merging" the new QtWebKit into the official webkit module, or at > least release it as the official module with an independent schedule, but I > don't remember if an agreement was reached... > > @Konstantin, what was the decision back then? My work was merged into http://code.qt.io/cgit/qt/qtwebkit.git/, see 5.212 and dev branches. We've decided that QtWebKit will use separate release schedule from Qt, and therefore have independent version numbers.
and upstream will keep releasing the old QtWebKit in Qt 5.10 and later? So there will be 2 QtWebKits?
(In reply to Davide Pesavento from comment #3) > and upstream will keep releasing the old QtWebKit in Qt 5.10 and later? So > there will be 2 QtWebKits? No, old QtWebKit won't be released anymore. Actually, 5.9.1 was not released
Also, give that dev contains updated QtWebKit now, it won't be technically possible to make a branch for 5.10 wih legacy contents
(In reply to Konstantin Tokarev from comment #4) > Actually, 5.9.1 was not released There are qtwebkit-opensource-src-5.9.1.tar.xz and qtwebkit-opensource-src-5.9.1.zip in https://download.qt.io/official_releases/qt/5.9/5.9.1/submodules/
What is meaning of "212" in name of branch "5.212"?
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #6) > (In reply to Konstantin Tokarev from comment #4) > > Actually, 5.9.1 was not released > > There are qtwebkit-opensource-src-5.9.1.tar.xz and > qtwebkit-opensource-src-5.9.1.zip in > https://download.qt.io/official_releases/qt/5.9/5.9.1/submodules/ Oops, I've missed that. >What is meaning of "212" in name of branch "5.212"? That it's based on same branch as WebKitGTK 2.12.x
(In reply to Konstantin Tokarev from comment #2) I've added your ebuild plus a few minor repoman complaint fixes and built several depending packages without any issue yet.
(In reply to Konstantin Tokarev from comment #5) > Also, give that dev contains updated QtWebKit now, it won't be technically > possible to make a branch for 5.10 wih legacy contents Ok, so qtwebkit-5.9999 is already building the new code, right? (assuming the ebuild still works) If going forward the version numbers will be different, we need to revise all = or ~ deps on qtwebkit in the tree.
(In reply to Davide Pesavento from comment #10) > (In reply to Konstantin Tokarev from comment #5) > > Also, give that dev contains updated QtWebKit now, it won't be technically > > possible to make a branch for 5.10 wih legacy contents > > Ok, so qtwebkit-5.9999 is already building the new code, right? (assuming > the ebuild still works) AFAIK there is no 9999 ebuild for qtwebkit, and if there was one it would not be appropriate because of build system change. New ebuild is based on webkit-gtk. > > If going forward the version numbers will be different, we need to revise > all = or ~ deps on qtwebkit in the tree. Sure, but note that new 5.x versions are API and ABI compatible with previous versions.
(In reply to Konstantin Tokarev from comment #11) > AFAIK there is no 9999 ebuild for qtwebkit, and if there was one it would > not be appropriate because of build system change. New ebuild is based on > webkit-gtk. https://gitweb.gentoo.org/proj/qt.git/tree/dev-qt/qtwebkit/qtwebkit-5.9999.ebuild But as you said, it probably needs major changes.
Yes, even if it works, dependencies are not accurate, and use flags won't work
Will 5.9 be the last release of old qtwebkit? I'm wondering if the 5.0 bump will be a good opportunity to change all the ~ deps to >=.
(In reply to Michael Palimaka (kensington) from comment #14) > Will 5.9 be the last release of old qtwebkit? Yes
I've unpinned the various qtwebkit dependencies in 5.9 and later: https://gitweb.gentoo.org/proj/qt.git/commit/?id=b0c5d8c3dd86479acbd325dac93a104c200a767c
Does anyone know if/when a release will happen? It looks like there was no qtwebkit-5.9.2 release so we'll have to ship 5.9.1 with the rest of 5.9.2 if there's no updated qtwebkit.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/qt.git/commit/?id=71a304ff572407c07cf4c0708ff0e9b9d901487e commit 71a304ff572407c07cf4c0708ff0e9b9d901487e Author: Michael Palimaka <kensington@gentoo.org> AuthorDate: 2017-10-07 03:23:40 +0000 Commit: Michael Palimaka <kensington@gentoo.org> CommitDate: 2017-10-07 03:38:03 +0000 dev-qt/qtwebkit: unpin dev-qt dependencies dev-qt/qtwebkit is no longer being released together with the rest of Qt, so pinned dependencies no longer make sense. This is a followup to b0c5d8c3dd86479acbd325dac93a104c200a767c. Bug: https://bugs.gentoo.org/624404 Package-Manager: Portage-2.3.8, Repoman-2.3.3 dev-qt/qtwebkit/qtwebkit-5.9.1.ebuild | 27 ++++++++++++++------------- dev-qt/qtwebkit/qtwebkit-5.9.9999.ebuild | 27 ++++++++++++++------------- dev-qt/qtwebkit/qtwebkit-5.9999.ebuild | 27 ++++++++++++++------------- 3 files changed, 42 insertions(+), 39 deletions(-)}
(In reply to Michael Palimaka (kensington) from comment #17) > Does anyone know if/when a release will happen? It looks like there was no > qtwebkit-5.9.2 release so we'll have to ship 5.9.1 with the rest of 5.9.2 if > there's no updated qtwebkit. Please use https://gist.github.com/annulen/309569fb61e5d64a703c055c1e726f71
Created attachment 498468 [details, diff] qtwebkit-5.9.1-to-5.212.0_alpha2.diff (In reply to Konstantin Tokarev from comment #19) > Please use https://gist.github.com/annulen/309569fb61e5d64a703c055c1e726f71 I've been using that version since 5.7.1 without issues albeit not much is left to depend on qtwebkit here. At least current kde-misc/kwebkitpart snapshot is broken, but 9999 builds fine. Besides minor fixes I've also spent a bit of time to harmonise the diff to 5.9.1 which should make the changes, cmake aside, easier to review. Since the build system is hardcoding the required Qt version it was built against in its cmake files (and breaking configure of rdeps after an upgrade of Qt) I've added a subslot operator on qtcore, but that should be fixed upstream if possible(?). As for the DEPEND changes that stand out which I haven't looked into: >- >=dev-libs/leveldb-1.18-r1 ...is it bundled again? >- webp? ( media-libs/libwebp:0= ) >+ media-libs/libwebp:= ...possible to make optional again? >- >=dev-qt/qtsql-${QT_MIN_VER} >- media-libs/fontconfig:1.0 >- >=sys-libs/zlib-1.2.5 >- virtual/opengl ...not necessary anymore?
Created attachment 498470 [details, diff] qtwebkit-5.9.1-to-5.212.0_alpha2.diff (In reply to Andreas Sturmlechner from comment #20) > >- webp? ( media-libs/libwebp:0= ) > >+ media-libs/libwebp:= > ...possible to make optional again? Answer to myself: Yes.
Fails with -opengl: In file included from /var/tmp/portage/dev-qt/qtwebkit-5.212.0_alpha2/work/qtwebkit-5.212.0-alpha2/Tools/QtTestBrowser/launcherwindow.cpp:37:0: /var/tmp/portage/dev-qt/qtwebkit-5.212.0_alpha2/work/qtwebkit-5.212.0-alpha2/Tools/QtTestBrowser/launcherwindow.h:39:30: fatal error: QtOpenGL/QGLWidget: No such file or directory compilation terminated.
launcherwindow.h contains this: #ifndef QT_NO_OPENGL #include <QtOpenGL/QGLWidget> #endif but I don't see any qconfig include - I wonder if this is an artifact of not using qmake. Do we need to build this tools directory anyway?
(In reply to Michael Palimaka (kensington) from comment #23) >Do we need to build this tools directory anyway? It may be useful as smoke test, nothing more. Pass -DENABLE_TOOLS=OFF to disable it. Alternatively, it's possible to make QtTestBrowser installable for bug reproduction purposes
Andreas: I've incorporated some of your changes in my version of ebuild. Note that parts which are not Qt-specific should be kept in sync with net-libs/webkit-gtk. If some improvements are needed in QtWebKit ebuild they should also be applied there is applicable Also note that [icu] on QtCore is not relevant for a long time (since https://codereview.qt-project.org/#/c/153222/ went in)
Since alpha2 was not configuring anymore (I assume because of Qt-5.9.3 or cmake-3.10) I've had to switch to a recent snapshot of 5.212 branch. That worked, and as a side-effect, the need for a rebuild after Qt upgrade (see comment #20) seems to be gone.
(In reply to Andreas Sturmlechner from comment #26) > Since alpha2 was not configuring anymore (I assume because of Qt-5.9.3 or > cmake-3.10) I've had to switch to a recent snapshot of 5.212 branch. Do you mind sharing the ebuild? (The alpha2 is nearly 6 months old.)
Created attachment 507256 [details] qtwebkit-5.212.0_alpha2.ebuild
http://bpaste.net/show/4f68bd1f4783 -> qtwebkit-5.212-up-to-date.patch
@Konstantin, any chance of a beta/rc release soon?
qt 5.9.3 and qt 5.10.0 work fine. With cmake 3.10 the alpha2 is not configuring.
Please use https://github.com/annulen/webkit/commit/f51554bf104ab0491370f66631fe46143a23d5c2.diff
(In reply to Davide Pesavento from comment #30) > @Konstantin, any chance of a beta/rc release soon? ping? we'd like to replace the old qtwebkit with a version from the new branch, and an official release from upstream would help a great deal.
Any plan for a alpha3/beta/rc/...? The alpha2 is seven month old.
How about spectre?
(In reply to Markus from comment #35) > How about spectre? Mitigations were merged into 5.212, 5.9 and 5.6 branches
Could we get 5.9.4 http://blog.qt.io/blog/2018/01/23/qt-5-9-4-released/ ? My qt-based apps are crashing because of disparate qt vesion numbers in shared libs. The rest of my qt5 stuff is at 5.9.4 version so I assume qtwebkit-5.9.1 is the one causing troubles. Thank you for the bump.
Upstream stopped at qtwebkit-5.9.1, there is no more release.
(In reply to Martin Mokrejš from comment #37) Use https://gist.github.com/annulen/309569fb61e5d64a703c055c1e726f71
So what is the http://blog.qt.io/blog/2018/01/23/qt-5-9-4-released/ thing?
(In reply to Martin Mokrejš from comment #40) > So what is the http://blog.qt.io/blog/2018/01/23/qt-5-9-4-released/ thing? qtwebkit-5.9.1 was the last qtwebkit upstream release. qt-5.9.2 and later do not include any qtwebkit.
If for some reason you want to continue using 5.9 branch, please use tip of it, it contains important security fixes.
(In reply to Konstantin Tokarev from comment #39) > (In reply to Martin Mokrejš from comment #37) > Use https://gist.github.com/annulen/309569fb61e5d64a703c055c1e726f71 Thank you, mixing qtwebkit-5.212.0_alpha2 with the remainder from 5.9.4 works for me (app-text/master-pdf-editor-4.3.82 does not crash anymore). I am at ~amd64 so I do not quite get why this is not in portage, if it nevertheless can replace outdated qtwebkit-5.9.1.
Created attachment 526228 [details] qtwebkit-5.212.9999.ebuild This qtwebkit-5.212.9999.ebuild is based on qtwebkit-5.212.0_pre20171112.ebuild from https://github.com/a17r/a17rgentoo/tree/master/dev-qt/qtwebkit with small updates, mostly related to using git-r3.eclass.
There is also https://github.com/Hummer12007/h-overlay/blob/master/dev-qt/qtwebkit/qtwebkit-5.212.0_alpha2-r1.ebuild (I didn't compare with your version, but you might want to take a look)
(In reply to Martin Mokrejš from comment #43) > I am at ~amd64 so I do not quite get why this is not in portage, if it > nevertheless can replace outdated qtwebkit-5.9.1. Waiting for a release.
Is the new upstream dead now as well? (No commits for quite some while.)
@pesa, in absence of the PR, just ack here for me to merge the last revision of it (no changes since).
Created attachment 537868 [details, diff] qtwebkit-5.212.0_pre20180120.ebuild.diff
Created attachment 537870 [details, diff] qtwebkit-5.212.0_pre20180120-functional.patch required patch.
(In reply to Andreas Sturmlechner from comment #48) > @pesa, in absence of the PR, just ack here for me to merge the last revision > of it (no changes since). ship it :)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ea2ae777d028e584cd175b2d4081dea826c8f7d1 commit ea2ae777d028e584cd175b2d4081dea826c8f7d1 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2018-07-03 06:06:37 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2018-07-03 06:09:14 +0000 dev-qt/qtwebkit: 5.212.0_pre20180120 snapshot bump Closes: https://bugs.gentoo.org/624404 Package-Manager: Portage-2.3.41, Repoman-2.3.9 dev-qt/qtwebkit/Manifest | 1 + .../qtwebkit-5.212.0_pre20180120-functional.patch | 22 ++++ dev-qt/qtwebkit/metadata.xml | 1 + .../qtwebkit/qtwebkit-5.212.0_pre20180120.ebuild | 141 +++++++++++++++++++++ 4 files changed, 165 insertions(+)
