Summary: | Package standalone QtWebKit 2.3.x for Qt4 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Manuel Nickschas <sputnick> |
Component: | New packages | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | alecm_88, ansla80, anton.wd, b.brachaczek, bensagal, enrico.tagliavini, eugene.shalygin, franz.trischberger, itumaykin+gentoo, jkt, luke-jr+gentoobugs, moltonel, n1ghtmare, nikoli, nordwnd, ostroffjh, paolo.pedroni, solpeth, xaviermiller, zfmeze |
Priority: | High | Keywords: | InVCS, PMASKED |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://gitorious.org/webkit/qtwebkit-23 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 522880, 539234 | ||
Attachments: |
qt-webkit 2.3b2 ebuild
0001-ICU-has-defined-UChar32-to-be-an-int32_t-since-2002.patch qtwebkit23-2.3.3.ebuild |
Description
Manuel Nickschas
2011-10-23 11:36:48 UTC
Davide, what do you think? 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? The correct git repo url is git://gitorious.org/+qtwebkit-developers/webkit/qtwebkit.git No objections from my side, sounds reasonable. 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 (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... 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. 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). 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.
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 :/ 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). 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? 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.
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".
(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. (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 . (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 (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... (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 :). Any updates on this? *** Bug 489354 has been marked as a duplicate of this bug. *** 2.3.4 has been tagged in git. 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? 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. 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. 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. 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. (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. 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 (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? (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? Need to investigate the possibility of restoring the icu USE flag. Without it, the libxml2[-icu] dependency blocks some other packages like chromium. 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. Looks like simply removing the dep on qtwebkit in qtdeclarative makes portage happy, I was worried for nothing :). 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)? (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? Most other distros seem to be using the standalone version as their main qtwebkit package. Following suit would certainly be a lot less work. 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§ion=all 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. (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 :( (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? (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. Btw the current ebuild installs the .pc file in the wrong location. (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/ ? 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) > 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. *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 (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 :( (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" ? (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. (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. (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. (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... 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. (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. 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). (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 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? (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. (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. qtwebkit4 has been masked for removal |