Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 388207 - Package standalone QtWebKit 2.3.x for Qt4
Summary: Package standalone QtWebKit 2.3.x for Qt4
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement with 6 votes (vote)
Assignee: Qt Bug Alias
URL: https://gitorious.org/webkit/qtwebkit-23
Whiteboard:
Keywords: InVCS, PMASKED
: 489354 (view as bug list)
Depends on:
Blocks: 522880 539234
  Show dependency tree
 
Reported: 2011-10-23 11:36 UTC by Manuel Nickschas
Modified: 2017-12-22 12:31 UTC (History)
20 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
qt-webkit 2.3b2 ebuild (qt-webkit-4.10.0.ebuild,765 bytes, text/plain)
2013-02-28 09:10 UTC, Francisco J. Vazquez
Details
0001-ICU-has-defined-UChar32-to-be-an-int32_t-since-2002.patch (0001-ICU-has-defined-UChar32-to-be-an-int32_t-since-2002.patch,1.23 KB, patch)
2013-09-03 17:42 UTC, Jan Kundrát (RETIRED)
Details | Diff
qtwebkit23-2.3.3.ebuild (qtwebkit23-2.3.3.ebuild,1.17 KB, text/plain)
2013-09-03 17:53 UTC, Jan Kundrát (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Manuel Nickschas 2011-10-23 11:36:48 UTC
For quite some time, QtWebKit has been developed outside of Qt (see http://trac.webkit.org/wiki/QtWebKit). Qt proper only receives code drops every now and then, which means that the qt-webkit we have right now (building from qt.git) is frequently outdated.

It would be great to allow building qt-webkit from its upstream repo at git://gitorious.org/webkit/qtwebkit.git, at least for live versions of qt-webkit. Could maybe make that a USE flag, or even always use the upstream repo for live...

The rationale for this is that QtWebKit is a fast-moving target with frequent enhancements and bugfixes, and it's kinda annoying to have to wait for months until we get them, even when installing Qt from the live ebuilds.
Comment 1 Markos Chandras (RETIRED) gentoo-dev 2011-10-23 11:39:33 UTC
Davide, what do you think?
Comment 2 Davide Pesavento gentoo-dev 2011-10-23 11:56:37 UTC
Yeah, I realized this a while ago too, while reading a Qt labs blog post. IMHO we should do what Manuel proposed. QtWebKit is rather loosely coupled with the rest of qt, thus switching to the standalone repo should be quite straightforward.

What do the other qt team members think?
Comment 3 Davide Pesavento gentoo-dev 2011-11-11 23:44:48 UTC
The correct git repo url is git://gitorious.org/+qtwebkit-developers/webkit/qtwebkit.git
Comment 4 Johannes Huber gentoo-dev 2012-03-28 13:59:51 UTC
No objections from my side, sounds reasonable.
Comment 5 Bartosz Brachaczek 2012-11-17 19:17:00 UTC
FWIW, QtWebKit 2.3 has been started[1], and it's a very nice update for Qt 4.

[1] http://blogs.kde.org/2012/11/14/introducing-qtwebkit-23
Comment 6 Davide Pesavento gentoo-dev 2013-02-15 18:29:05 UTC
(In reply to comment #5)
> FWIW, QtWebKit 2.3 has been started[1], and it's a very nice update for Qt 4.
> 
> [1] http://blogs.kde.org/2012/11/14/introducing-qtwebkit-23

And it's now at beta2
http://blogs.kde.org/2013/02/15/qtwebkit-23-beta-2-tagged

Not sure what to do with the version number though...
Comment 7 Francisco J. Vazquez 2013-02-25 11:09:48 UTC
Could we get a -9999 ebuild until it is decided what to do with version numbers? qt-webkit 2.3 seems a big step forward with respect to what we have in portage (with things like web fonts, for example). I tried making one from the 4.8.4 ebuild in portage, but failed miserably.
Comment 8 Francisco J. Vazquez 2013-02-28 08:45:20 UTC
I've made a quick-and-horribly-dirty ebuild for 2.3b2 and the library installs itself as 4.10.0. So you could use that as version number (after removing that annoying block in qt-build.eclass).
Comment 9 Francisco J. Vazquez 2013-02-28 09:10:32 UTC
Created attachment 340458 [details]
qt-webkit 2.3b2 ebuild

This is the ebuild. Disclaimer: the ebuild is crap. It uses the bundled script for configuring and compiling, so it probably has several automagic dependencies, and I've removed the USEs. I still don't understand the compiling process of these qt-based programs and libraries (just recently moved from gtk to qt).

Anyway, it works with qupzilla (git), so it's there for people like me who want to try.
Comment 10 Franz Trischberger 2013-03-14 07:39:36 UTC
We entered RCs:
http://blogs.kde.org/2013/03/05/first-release-candidate-qtwebkit-23

Is there anything we can help? I also would like to go back to qupzilla as my main browser, with the stability of current qtwebkit:4 it is not really usable :/
Comment 11 Davide Pesavento gentoo-dev 2013-03-16 03:26:53 UTC
http://blogs.kde.org/2013/03/15/qtwebkit-230-out
Comment 12 Francisco J. Vazquez 2013-03-16 11:17:03 UTC
My ebuild compiles fine for 2.3.0 final replacing the SRC_URI with qtwebkit-2.3.0 -> ${PN}-2.3.tar.gz and works ok with qupzilla 1.4.0. Still don't know how to USE gstreamer or icu (as with the 4.8.4 ebuild).
Comment 13 Xavier Miller gentoo-dev 2013-04-16 09:25:35 UTC
Hello,

qtwebkit-4.8.4 from QT 4.8.4 doesn't work with GCC 4.8 : I got crashes within qupzilla, and it seems there are patches for GCC 4.8 fixing QT/WebKit.

Wouldn't be nice to use that external QT/Webkit, maybe by using a virtual?
Comment 15 Jan Kundrát (RETIRED) gentoo-dev 2013-09-03 17:42:58 UTC
Created attachment 357772 [details, diff]
0001-ICU-has-defined-UChar32-to-be-an-int32_t-since-2002.patch

This patch fixes a build failure related to the fact that recent libxml2 and a recent gstreamer brings in libICU, but the qtwebkit build still uses a typedef back from 2002. Reported upstream via IRC, not bugreport yet.
Comment 16 Jan Kundrát (RETIRED) gentoo-dev 2013-09-03 17:53:44 UTC
Created attachment 357774 [details]
qtwebkit23-2.3.3.ebuild

This is an updated ebuild for the recently tagged 2.3.3 release. A couple of gotchas:

- I've only built with --no-xslt before, so this particular configuration is "untested"
- It conflicts with dev-qt/qtdeclarative's /usr/lib64/qt4/imports/QtWebKit/qmldir and /usr/lib64/qt4/imports/QtWebKit/libqmlwebkitplugin.so; a proper fix is IMHO to add a dep on dev-qt/qtdeclarative[-webkit]
- The conflict with the upstream's vanilla qtwebkit is obvious; there shall be a blocker
- ICU is unconditionally used. It is a mess, but I do not suppose it's worth anyone's time to support building QtWebKit without ICU anyway
- There's probably some automagic dependency on gstreamer
- The new gitorious apparently won't create tarballs anymore, especially from repos weighing in roughly 4GBs, so I had to make one myself from a clone (see ebuild).

I guess that this should get into tree rather soon as it fixes a ton of crasher bugs (have a look at rekonq's bugzilla if you don't trust me). I'd suggest a virtual for the "qtwebkit:4" which will default to this new 2.3 "release".
Comment 17 Davide Pesavento gentoo-dev 2013-09-03 18:00:20 UTC
(In reply to Jan Kundrát from comment #15)

That's the reason behind the dev-libs/libxml2:2[!icu?] dep in qtwebkit. I tried to submit a patch upstream more than one year ago, but the fallout it caused required several other fixes which were deemed "too big of a change" for the 4.8 branch, so the patch was ultimately rejected.
Comment 18 Jan Kundrát (RETIRED) gentoo-dev 2013-09-03 18:19:46 UTC
(In reply to Davide Pesavento from comment #17)
> That's the reason behind the dev-libs/libxml2:2[!icu?] dep in qtwebkit.

I'm happy to see that I'm not the only one hitting this. Have you tried to apply the patch I attached? The conflicting declaration of UChar32 is clearly a bug in Qt's webkit port and not something which should force a choice between gstreamer and a libxmlw+ICU. To me, this looks like something trivial to fix, so I wonder what I am missing here.

> I tried to submit a patch upstream more than one year ago, but the fallout it
> caused required several other fixes which were deemed "too big of a change"
> for the 4.8 branch, so the patch was ultimately rejected.

Got a pointer for this one? I don't see anything relevant at 
https://codereview.qt-project.org/#dashboard,1001039 .
Comment 19 Davide Pesavento gentoo-dev 2013-09-03 18:21:58 UTC
(In reply to Jan Kundrát from comment #18)
> Got a pointer for this one? I don't see anything relevant at 
> https://codereview.qt-project.org/#dashboard,1001039 .

https://codereview.qt-project.org/28797
Comment 20 Davide Pesavento gentoo-dev 2013-09-03 18:26:08 UTC
(In reply to Davide Pesavento from comment #19)
> (In reply to Jan Kundrát from comment #18)
> > Got a pointer for this one? I don't see anything relevant at 
> > https://codereview.qt-project.org/#dashboard,1001039 .
> 
> https://codereview.qt-project.org/28797

After Thiago's last comment, the discussion continued briefly on IRC where they basically told me to abandon the change.

It seems the compilation failures are in qtscript's copy of javascriptcore, so the standalone webkit might not be affected...
Comment 21 Jan Kundrát (RETIRED) gentoo-dev 2013-09-03 18:35:51 UTC
(In reply to Davide Pesavento from comment #20)
> https://codereview.qt-project.org/28797

Ah, that sucks. It could be another reason to migrate to qtwebkit23 which does not suffer from this problem, though :).
Comment 22 Luke-Jr 2013-10-22 05:41:28 UTC
Any updates on this?
Comment 23 Davide Pesavento gentoo-dev 2013-11-12 22:36:55 UTC
*** Bug 489354 has been marked as a duplicate of this bug. ***
Comment 24 Davide Pesavento gentoo-dev 2014-09-28 12:32:11 UTC
2.3.4 has been tagged in git.
Comment 25 Eugene Shalygin 2014-12-10 20:02:52 UTC
It seems like standalone QtWebkit solves also quite annoying bug when kdewebkit segfaults after idling: https://bugs.kde.org/show_bug.cgi?id=294707

Since 3 years has passed from the time the bug was opened there must be a serious problem to implements this?
Comment 26 Davide Pesavento gentoo-dev 2014-12-11 01:31:16 UTC
QtWebKit, and any WebKit fork in general, is well known for being a royal PITA to package, with its huge codebase, complex interdependencies, and messy build system. In order to write a proper ebuild, a lot of time and motivation are needed.

Personally, I have neither since 1) I have very little time for gentoo in general, and 2) I don't use qtwebkit so I don't care about it.
Comment 27 Michael Palimaka (kensington) gentoo-dev 2014-12-11 06:52:46 UTC
This is on my TODO (we definitely need it at some point to solve the gstreamer version problem). Biggest blocker for me is not having hardware capable of repeatedly building for testing.
Comment 28 Eugene Shalygin 2014-12-11 17:42:31 UTC
Thank you for your replies! The situation is sad. I will try to live with package.provided and custom ebuild, but I'm sure some other Gentoo KDE users would benefit from qtwebkit ebuild even of not the best quality.
Comment 29 Ben de Groot (RETIRED) gentoo-dev 2015-02-17 17:12:13 UTC
I think we need to accept the reality that this will be a WONTFIX. Apparently nobody is motivated enough to make a proper ebuild. And besides, Qt is moving on to QtWebEngine (from the Chromium sources) in Qt5.
Comment 30 Michael Palimaka (kensington) gentoo-dev 2015-02-18 04:03:12 UTC
(In reply to Ben de Groot from comment #29)
> I think we need to accept the reality that this will be a WONTFIX.
> Apparently nobody is motivated enough to make a proper ebuild. And besides,
> Qt is moving on to QtWebEngine (from the Chromium sources) in Qt5.

I'll try to have another look soon. The gstreamer symbol collision issue is still a bad bug for users.
Comment 31 Michael Palimaka (kensington) gentoo-dev 2015-02-19 17:28:37 UTC
I've pushed an ebuild to the overlay for testing and review.

It still has at least the following issues:

* Does not respect CC, CFLAGS etc.
* Missing multilib support
* Does not touch qconfig at all
* Needs to be checked wrt bug #524584

https://github.com/gentoo/qt/commit/9f265c3427d3c00735e43d6813aecf37b14f09c8
Comment 32 Michael Palimaka (kensington) gentoo-dev 2015-02-22 15:33:56 UTC
(In reply to Michael Palimaka (kensington) from comment #31)
> I've pushed an ebuild to the overlay for testing and review.
> 
> It still has at least the following issues:
> 
> * Does not respect CC, CFLAGS etc.
> * Missing multilib support
> * Does not touch qconfig at all
> * Needs to be checked wrt bug #524584
> 
> https://github.com/gentoo/qt/commit/9f265c3427d3c00735e43d6813aecf37b14f09c8

I've pushed an update to respect *FLAGS etc. Also, I can't find any evidence that it is affected by bug #524584.

So, I guess the next step is multilib so it could satisfy a virtual/qtwebkit virtual.

Davide, is it correct to handle QCONFIG the same way as in qtwebkit-4.8.6?
Comment 33 Jan Kundrát (RETIRED) gentoo-dev 2015-02-24 15:30:06 UTC
(In reply to Ben de Groot from comment #29)
> And besides, Qt is moving on to QtWebEngine (from the Chromium sources) in Qt5.

Because of a different API in QtWebEngine, they will not be able to deprecate QtWebkit until Qt6. besides that, what do you think that this move implies for this qtwebkit 2.3 port for Qt4?
Comment 34 Michael Palimaka (kensington) gentoo-dev 2015-02-24 19:36:23 UTC
Need to investigate the possibility of restoring the icu USE flag. Without it, the libxml2[-icu] dependency blocks some other packages like chromium.
Comment 35 Enrico Tagliavini 2015-02-28 14:01:47 UTC
I took the ebuild from comment #32 and applied the patch from comment #15 to solve the compilation error when libxml2 is compiled with icu support. I come to the same conclusion as Jan, that ifdef really looks like a very old leftover forgotten from a long time.

With this I was able to compile qtwebkit correctly, but then I hit a file collision with dev-qt/qtdeclarative-4.8.5

 * Detected file collision(s):
 *
 *      /usr/lib64/qt4/imports/QtWebKit/libqmlwebkitplugin.so
 *      /usr/lib64/qt4/imports/QtWebKit/qmldir
 *
 * Searching all installed packages for file collisions...
 *
 * Press Ctrl-C to Stop
 *
 * dev-qt/qtdeclarative-4.8.5:4::gentoo
 *      /usr/lib64/qt4/imports/QtWebKit/libqmlwebkitplugin.so
 *      /usr/lib64/qt4/imports/QtWebKit/qmldir

So i forcefully disabled webkit support in qtdeclarative by passing -no-webkit. Packages depending on qtdeclarative[webkit], like kdevelop, will need a little adjustment. With this change qtwebkit 2.3.4 can be installed, I fired up rekonq briefly and it worked as expected (tried to load youtube in html5).

This also solved bug #522880 . I have now phonon-gstreamer 4.8 installed, qtwebkit compiled with USE=gstreamer, KDE configured to use the gstreamer backend, amarok is happy as well of the rest of KDE.

There is still a potential problem I didn't investigated: dependencies between qtdeclarative and qtwebkit. qtdeclarative needs to be recompiled first to avoid the file collision, otherwise the update will fail, causing some headache for users. I think the correct solution would be to make qtwebkit depending (both for runtime and build) on qtdeclarative, but I didn't tried if this causes a blocker during the update since the deps are inverted.
Comment 36 Enrico Tagliavini 2015-02-28 14:19:55 UTC
Looks like simply removing the dep on qtwebkit in qtdeclarative makes portage happy, I was worried for nothing :).
Comment 37 Michael Palimaka (kensington) gentoo-dev 2015-05-23 16:58:57 UTC
Multilib support is now in the overlay, thanks to Enrico.

Should we introduce this to the main tree with a virtual (are we happy with the package name qtwebkit23)?
Comment 38 Davide Pesavento gentoo-dev 2015-05-23 17:21:08 UTC
(In reply to Michael Palimaka (kensington) from comment #37)
> Should we introduce this to the main tree with a virtual (are we happy with
> the package name qtwebkit23)?

Good question... phonon is in a similar situation (qtphonon vs m-l/phonon) but does not have a virtual.

Another option is replacing qtwebkit-4.8.x with this branch altogether, using the installed .so version number...

what are other distros doing?
Comment 39 Michael Palimaka (kensington) gentoo-dev 2015-05-23 17:27:34 UTC
Most other distros seem to be using the standalone version as their main qtwebkit package. Following suit would certainly be a lot less work.
Comment 40 Enrico Tagliavini 2015-05-24 09:10:38 UTC
I think the main point is if the version from upstream webkit covers all use cases where the qt one works. Also is it worth keeping around the Qt one being so old and still using gstreamer 0.10 while most stuff is ported to gst >= 1.0?

Fedora [1], Arch Linux [2] and Debian Jessie (stable!)[3] are all on qtwebkit 2.3.4 and, based on the name, they seems not to ship the Qt version at all. My concern with having both is that conflicts can be a pain for users to solve, the less we potentially introduce, the better (at least if we loose nothing by not providing one of the two packages).

[1] https://apps.fedoraproject.org/packages/qtwebkit
[2] https://www.archlinux.org/packages/extra/x86_64/qtwebkit/
[3] https://packages.debian.org/search?keywords=qtwebkit&searchon=names&suite=stable&section=all
Comment 41 Jan Kundrát (RETIRED) gentoo-dev 2015-06-08 07:49:31 UTC
I am pretty sure that both of these webkit versions are effectively unmaintained, security-wise. Just take a look at http://code.qt.io/cgit/qt/qt.git/log/src/3rdparty/webkit and https://gitorious.org/webkit/qtwebkit-23/commits/e0b7a390c4b95f8ca2fdf857502040c7f7d87d4d . I do not think that it is safe to assume that there's been no fresh exploits in WebKit over the last six months, and I do not see any security fixes in these repos. That's the whole reason they're working on that QtWebEngine now, after all.

Qt4 itself will cease to be supported by The Qt Company at the end of 2015, so it's a question if it's worth it to introduce massive changes just for six months.
Comment 42 Enrico Tagliavini 2015-06-08 08:19:17 UTC
(In reply to Jan Kundrát from comment #41)
> Qt4 itself will cease to be supported by The Qt Company at the end of 2015,
> so it's a question if it's worth it to introduce massive changes just for
> six months.

I mainly have two points for a yes:
 1. this means KDE users will potentially have six more months of problems. I did this work in the first place because I was exasperated by the issues qtwebkit, as provided by upstream Qt, is giving due to gstreamer 0.10 only support.
 2. There are a lot of packages depending on qtwebkit, mostly KDE 4 apps but also stuff like skype (which will be slow picking up new libs). If it happens that gentoo has to keep qtwebkit around for longer that what upstream support I would say it is better to go with what other distro are using. More chances to get out of tree patches if anything surface.

This is far from being ideal and not introducing the change is an option, which I don't at all but I can understand. I'm pretty sure security wise you are right. However this is not an argument for not introducing the change, it is an argument to remove support for qtwebkit entirely imho since it is valid for both implementations, or am I understanding it wrong?

Lastly if it is decided gentoo stays with qtwebkit 4.8.$latest blockers needs to be introduced to avoid possible issues with KDE applications like Amarok (bug #522880 ), but I had more problems (possibly some root cause) since I disabled webkit support in quassel... I can't really remember the reason now. Unfortunately disabling gstreamer support in qtwebkit cripple the functionality quite a bit. Blocking phonon-gstreamer is not ideal solution either, the reason I didn't switched to VLC backend is because it was not working as well for me.

There is no win-win I'm afraid, we need to decide for the least worst :(
Comment 43 Davide Pesavento gentoo-dev 2015-06-08 11:12:31 UTC
(In reply to Jan Kundrát from comment #41)
> I am pretty sure that both of these webkit versions are effectively
> unmaintained, security-wise. Just take a look at
> http://code.qt.io/cgit/qt/qt.git/log/src/3rdparty/webkit and
> https://gitorious.org/webkit/qtwebkit-23/commits/
> e0b7a390c4b95f8ca2fdf857502040c7f7d87d4d . I do not think that it is safe to
> assume that there's been no fresh exploits in WebKit over the last six
> months, and I do not see any security fixes in these repos. That's the whole
> reason they're working on that QtWebEngine now, after all.

Agreed, but QtWebEngine is Qt5 only, and I don't see any other alternatives for Qt4.

> Qt4 itself will cease to be supported by The Qt Company at the end of 2015,
> so it's a question if it's worth it to introduce massive changes just for
> six months.

Are you suggesting we should treeclean Qt4 in January 2016?
Comment 44 Davide Pesavento gentoo-dev 2015-06-08 11:16:26 UTC
(In reply to Enrico Tagliavini from comment #42)
> I'm pretty sure security wise you
> are right. However this is not an argument for not introducing the change,
> it is an argument to remove support for qtwebkit entirely imho since it is
> valid for both implementations, or am I understanding it wrong?

I agree with Enrico's interpretation here.
Comment 45 Davide Pesavento gentoo-dev 2015-06-08 15:56:34 UTC
Btw the current ebuild installs the .pc file in the wrong location.
Comment 46 Enrico Tagliavini 2015-06-08 16:30:31 UTC
(In reply to Davide Pesavento from comment #45)
> Btw the current ebuild installs the .pc file in the wrong location.

Oh damn. Move them to /usr/$(get_libdir)/pkgconfig/ ?
Comment 47 Davide Pesavento gentoo-dev 2015-06-10 01:30:51 UTC
So, unless someone raises objections, I'm going to move the current qtwebkit23-2.3.4 ebuild to gx86 as dev-qt/qtwebkit-4.10.4 soon (p.masked at first)
Comment 48 Jan Kundrát (RETIRED) gentoo-dev 2015-06-14 12:26:44 UTC
> Are you suggesting we should treeclean Qt4 in January 2016?

I'm pointing out that we are shipping a software where the likelihood of being vulnerable is pretty close to 100% (qtwebkit, not Qt4 of course). I for one didn't know about this fact until I attended the QtCS. I think that our users don't know about this situation, either. I also don't see anybody providing these security fixes -- if there was someone like that, they should have worked with the Qt upstream during the past year(s).

What are other distros going to do?

(In reply to Davide Pesavento from comment #47)
> So, unless someone raises objections, I'm going to move the current
> qtwebkit23-2.3.4 ebuild to gx86 as dev-qt/qtwebkit-4.10.4 soon (p.masked at
> first)

I don't object to this, and I've been running with this new webkit "for years" before I switched to Firefox and Qt5; it indeed sounds like an improvement. BUT, at the same time, doing this might suggest that the code is in fact maintained. It is *not* maintained at all.

I'm all for saying that this situation sucks, including the feature gap between the QtWebkitWidgets and QtWebEngine from the programmer's point of view. I also cannot really blame upstream here, this is an issue of manpower and I was told that the requirements of coping up with webkit were HUGE, and they meant it.
Comment 49 Davide Pesavento gentoo-dev 2015-07-23 20:42:14 UTC
*qtwebkit-4.10.4 (23 Jul 2015)

  23 Jul 2015; Davide Pesavento <pesa@gentoo.org>
  +files/4.10.4-use-correct-icu-typedef.patch, +qtwebkit-4.10.4.ebuild,
  metadata.xml:
  Import qtwebkit23-2.3.4 from qt overlay as qtwebkit-4.10.4 (version of the
  installed library). See bug 388207.


Next steps are:

* see if other distros have patches we should apply (probably yes)
* check rpath
* rekeyword
* test reverse deps
Comment 50 Luke-Jr 2015-07-31 10:50:10 UTC
(In reply to Davide Pesavento from comment #49)
> *qtwebkit-4.10.4 (23 Jul 2015)
> 
>   23 Jul 2015; Davide Pesavento <pesa@gentoo.org>
>   +files/4.10.4-use-correct-icu-typedef.patch, +qtwebkit-4.10.4.ebuild,
>   metadata.xml:
>   Import qtwebkit23-2.3.4 from qt overlay as qtwebkit-4.10.4 (version of the
>   installed library). See bug 388207.
> 
> 
> Next steps are:
> 
> * see if other distros have patches we should apply (probably yes)
> * check rpath
> * rekeyword
> * test reverse deps

FWIW, it doesn't seem practical to actually install this? qtdeclarative[webkit] at least won't accept it :(
Comment 51 Michael Palimaka (kensington) gentoo-dev 2015-07-31 11:34:52 UTC
(In reply to Luke-Jr from comment #50)
> FWIW, it doesn't seem practical to actually install this?
> qtdeclarative[webkit] at least won't accept it :(

What do you mean by "won't accept it" ?
Comment 52 Luke-Jr 2015-07-31 11:37:42 UTC
(In reply to Michael Palimaka (kensington) from comment #51)
> (In reply to Luke-Jr from comment #50)
> > FWIW, it doesn't seem practical to actually install this?
> > qtdeclarative[webkit] at least won't accept it :(
> 
> What do you mean by "won't accept it" ?

It depends on qtwebkit-${PV}, which never can be satisfied by 4.10.4 since qtdeclarative has no such version.
Comment 53 Enrico Tagliavini 2015-07-31 11:53:33 UTC
(In reply to Luke-Jr from comment #50)
> FWIW, it doesn't seem practical to actually install this?
> qtdeclarative[webkit] at least won't accept it :(

This qtwebkit package provides its own qtdeclarative bits. All applications depending on qtdeclarative[webkit] should be adjusted to depends on this package directly. In fact this package blocks qtdeclarative[webkit] for this very reason.
Comment 54 Greg Turner 2015-09-07 16:10:23 UTC
(In reply to Enrico Tagliavini from comment #53)
> (In reply to Luke-Jr from comment #50)
> > FWIW, it doesn't seem practical to actually install this?
> > qtdeclarative[webkit] at least won't accept it :(
> 
> This qtwebkit package provides its own qtdeclarative bits. All applications
> depending on qtdeclarative[webkit] should be adjusted to depends on this
> package directly. In fact this package blocks qtdeclarative[webkit] for this
> very reason.

Maybe there should be a virtual/qtdeclarative[webkit]?

I'm not exactly sure who to thank -- Davide, perhaps you're my knight in shining armor? -- but, at long, long last I find myself able to return to phonon-gstreamer, which seems to have resolved all sorts of little stupid problems I didn't even know were problems in the first place.

I haven't followed this carefully as I (thought I) had no urgent need of it.  Had I known how many little misbehaviors and limitations on my workstation accrued to this bug I'd have been busting chops to fix it myself.

Anyhow, it's a medium-huge improvement, here, I really like it.

One note, on my workstation (32g ram w/ huge /var/tmp/portage tmpfs), I couldn't compile it with debug-symbols enabled, but maybe that was resource exhaustion on my end, rather than a bug.
Comment 55 Greg Turner 2015-09-12 18:28:07 UTC
(In reply to Davide Pesavento from comment #49)
> *qtwebkit-4.10.4 (23 Jul 2015)
> 
>   23 Jul 2015; Davide Pesavento <pesa@gentoo.org>
>   +files/4.10.4-use-correct-icu-typedef.patch, +qtwebkit-4.10.4.ebuild,
>   metadata.xml:
>   Import qtwebkit23-2.3.4 from qt overlay as qtwebkit-4.10.4 (version of the
>   installed library). See bug 388207.
> 
> 
> Next steps are:
> 
> * see if other distros have patches we should apply (probably yes)

Found one.

See bug 547722.  (At least) the patch referenced for gcc-5.x (but ultimately not needed downstream due to in-vcs) was required for me to compile qtwebkit-4.10.4 with gcc-5.2:

https://codereview.qt-project.org/gitweb?p=qt/qtwebkit.git;a=commitdiff_plain;h=650c6ee8e76bb574d3a1bea09e2494992d8f070e;hp=f9966f351678351ee6b971d7b6b25a4987407e46

Quite possibly more, waiting on my build outcome, but I accidentally built with -j1 so I won't know that for ages...
Comment 56 Paolo Pedroni 2016-04-18 10:51:34 UTC
net-im/skype needs qtwebkit[-exceptions] (bug #546746), but there's no "exceptions" USE flag in qtwebkit-4.10.4. It is thus impossible to install qtwebkit-4.10.4 in a PC with net-im/skype installed.
Comment 57 Petr Orlov 2016-08-06 11:02:34 UTC
(In reply to Paolo Pedroni from comment #56)
> net-im/skype needs qtwebkit[-exceptions] (bug #546746), but there's no
> "exceptions" USE flag in qtwebkit-4.10.4. It is thus impossible to install
> qtwebkit-4.10.4 in a PC with net-im/skype installed.

Not only skype - dev-qt/designer is also expecting aqua flag and qtdeclarative depens on. In the other hand media-libs/phonon-gstreamer 4.9.0 has !<dev-qt/qtwebkit-4.10.4:4[gstreamer] depend and this mask completely blocks any future updates.

IMO new ebuilds for skype, designer and qtdeclarative with usage of qtwebkit new version may be added for tests. If we have 4.10.4 in the main overlay at least users should test it.
Comment 58 Michael Palimaka (kensington) gentoo-dev 2016-08-06 15:41:31 UTC
Unfortunately realistically I don't expect to see much traction here. qtwebkit is deprecated (double for qtwebkit4) and we should work towards removing it completely (similar work is also being done in other distros).
Comment 59 Coacher 2016-08-22 15:29:34 UTC
(In reply to Michael Palimaka (kensington) from comment #58)
> qtwebkit is deprecated (double for qtwebkit4) and we should work towards
> removing it completely (similar work is also being done in other distros).
Surprise! https://qtwebkit.blogspot.com/2016/08/qtwebkit-im-back.html
Comment 60 Daniel Kuehn (RETIRED) gentoo-dev 2016-09-12 19:31:18 UTC
I'm working together with a proxy to make an ebuild for the new webkit, they think that the repo might be Qt5 only tho.

They aren't really interested in maintaining it once we've got something that works, maybe the Qt project wants to take it over then?
Comment 61 Davide Pesavento gentoo-dev 2016-09-12 20:14:37 UTC
(In reply to Daniel Kuehn from comment #60)
> I'm working together with a proxy to make an ebuild for the new webkit, they
> think that the repo might be Qt5 only tho.
> 
> They aren't really interested in maintaining it once we've got something
> that works, maybe the Qt project wants to take it over then?

If you're talking about the unofficial qtwebkit presented at https://qtwebkit.blogspot.fr/2016/08/qtwebkit-im-back.html , then AFAIU it's Qt5 only, and pretty much unrelated to this bug. I suggest you open a separate one.
Comment 62 Daniel Kuehn (RETIRED) gentoo-dev 2016-09-12 20:21:11 UTC
(In reply to Davide Pesavento from comment #61)
> (In reply to Daniel Kuehn from comment #60)
> > I'm working together with a proxy to make an ebuild for the new webkit, they
> > think that the repo might be Qt5 only tho.
> > 
> > They aren't really interested in maintaining it once we've got something
> > that works, maybe the Qt project wants to take it over then?
> 
> If you're talking about the unofficial qtwebkit presented at
> https://qtwebkit.blogspot.fr/2016/08/qtwebkit-im-back.html , then AFAIU it's
> Qt5 only, and pretty much unrelated to this bug. I suggest you open a
> separate one.

Yeah, sorry, forgot to reply to Coacher's comment, as he pointed to that blogpost in comment 59.

Once it becomes anything worth putting in the tree, we'll open up a new bug for it.
Comment 63 Michael Palimaka (kensington) gentoo-dev 2017-12-22 12:31:47 UTC
qtwebkit4 has been masked for removal