Package Details: qtwebkit 2.3.4-7

Git Clone URL: https://aur.archlinux.org/qtwebkit.git (read-only, click to copy)
Package Base: qtwebkit
Description: An open source web browser engine (Qt port)
Upstream URL: http://trac.webkit.org/wiki/QtWebKit
Licenses: GPL3, LGPL2.1
Conflicts: qt<4.8
Submitter: arojas
Maintainer: fbrennan
Last Packager: FredBezies
Votes: 54
Popularity: 0.078968
First Submitted: 2017-02-09 07:52
Last Updated: 2018-07-07 22:15

Sources (6)

Pinned Comments

FredBezies commented on 2018-02-05 17:10

@alban : so just use qtwebkit-bin package.

By the way, last time I build this package successfully? January 15th, 2018.

fred@fredo-arch ~ % pacman -Qi qtwebkit

name : qtwebkit

Version : 2.3.4-6

Description : An open source web browser engine (Qt port)

Architecture : x86_64

URL : http://trac.webkit.org/wiki/QtWebKit

Licenses : LGPL2.1 GPL3

Groups : None

Provides : None

Depends On : qt4 systemd gst-plugins-base-libs

Optional Deps : None

Required By : google-musicmanager

Optional For : None

Conflicts With : qt<4.8

Replaces : None

Installed Size : 35.26 MiB

Packager : Unknown Packager

Build Date : Mon Jan 15 10:41:57 2018

Install Date : Mon Jan 15 10:47:06 2018

Install Reason : Explicitly installed

Install Script : No

Validated By : None

Latest Comments

« First ‹ Previous ... 2 3 4 5 6 7 8 9 10 11 12 ... Next › Last »

WoefulDerelict commented on 2017-05-30 15:35

ZeroBit: That is interesting. I haven't encountered that at all. Building this via a call to extra-x86_64-build has worked fine so far. I will check it against the new gcc update that just dropped, perhaps it breaks things again.

This software takes a very long time to build. The average is about two hours; however, the Qt wiki tells users it could take up to four hours. If it has not been 'looping' for more than four hours it just may be building normally and you are misinterpreting the output.

ADDENDUM: While the output is much more verbose thanks to all the added messages in GCC 7, the new compiler still builds this just fine in a clean chroot via the extra-x86_64-build script from devtools.

ZeroBit commented on 2017-05-30 07:13

@WoefulDerelict
I'm trying to make build this package in a clean chroot via the devtools scripts for x86_64 (using updated PKGBUILD and resources found here https://github.com/WoefulDerelict/PKGBUILDs/tree/master/qtwebkit) WITHOUT editing libxml2 to remove ICU support. The result: endless loop while making with makechrootpkg -c -r $CHROOT

geosam commented on 2017-05-29 17:42

Thanks @WoefulDerelict by the repository. Please update and merge.

geosam commented on 2017-05-29 17:42

Thanks @WoefulDerelict by the repository. Please update and merge.

WoefulDerelict commented on 2017-05-29 14:35

ZeroBit: I am glad it worked. When possible building troublesome packages using the appropriate script from the devtools package is your best option; however, I doubt prying the ICU support back out of libxml2 is going to cause immediate issues for users that chose this fix.

[https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot] provides detailed information on the devtools scripts and what they are used for. As i686 support was dropped the majority of users would be on x86_64 and using extra-x86_64-build to wrangle this build in a clean chroot. There isn't anything this needs to build that isn't in the repos so the script can be called without arguments. This process obviously eats more drive space than using makepkg but prevents unwanted inclusions and helps spot when dependencies are actually missing. As a bonus the script finishes by running a test install of the package in chroot and examining it with namcap.

ZeroBit commented on 2017-05-29 07:14

@WoefulDerelict
> Is your system in sync with the repos? Have you replaced any packages, like libxml2, with something from the AUR or edited them to remove ICU support?
Yes my system is synced with repos. After removing ICU support from PKGBUILD for libxml2 I was able to install qtwebkit successfully. Thank you for your hard work and efforts to help us!

WoefulDerelict commented on 2017-05-28 22:23

ZeroBit: That looks familiar. Similar to the earlier issues when the ICU support in qt4 and libxml2 was mismatched. Is your system in sync with the repos? Have you replaced any packages, like libxml2, with something from the AUR or edited them to remove ICU support? Have you tried using the appropriate devtools script to build it in a clean chroot?

I suspect this is an issue similar to the one this package causes when building Qt4 and there is a feature incompatible package present on your system that is interfering with the build. I doubt users experiecing this issue would be able to reproduce it in a clean chroot.

UPDATE: I actually managed to repro this on a bloated test box. Building it on a very dirty box caused the same type of explosion; however, it succeeds in a clean chroot on the same machine. Sadly this confirms my suspicion and points down a deep and nasty little rabbit hole. I will look through the output and see if I can't find the stray include causing the issue; however, it is unlikely to lead to a fix.

The only immediate solution that won't involve a custom update to packages on your system or removing something you use or that something you use depends on is to build the software in a clean chroot away from the offending package. The devtools scripts make this very simple. A call to extra-[ARCHITECTURE]-build should successfully generate a package.

CONCLUSION: This issue appears to result from interactions with libxslt. libxslt is not necessary to build this package and is not included in the chroot when using devtools scripts so the package builds without issue. Including libxslt in the chroot will reliably reproduce the declaration error.

ZeroBit commented on 2017-05-28 19:46

@WoefulDerelict
Even with your latest updated PKGBUILD I have this error:
...
/tmp/yaourt-tmp-user/aur-qtwebkit/src/qtwebkit-2.3.4/Source/WTF/wtf/unicode/qt4/UnicodeQt4.h:72:18: note: previous declaration as ‘typedef uint32_t UChar32’
typedef uint32_t UChar32;
^~~~~~~
make[3]: *** [Makefile.WebCore.Target:52494: obj/release/JSDOMWindowCustom.o] Error 1
make[3]: Leaving directory '/tmp/yaourt-tmp-user/aur-qtwebkit/src/qtwebkit-2.3.4/WebKitBuild/Release/Source/WebCore'
make[2]: *** [Makefile.WebCore:72: sub-Target-pri-make_default-ordered] Error 2
make[2]: Leaving directory '/tmp/yaourt-tmp-user/aur-qtwebkit/src/qtwebkit-2.3.4/WebKitBuild/Release/Source/WebCore'
make[1]: *** [Makefile:153: sub-Source-WebCore-WebCore-pro-make_default-ordered] Error 2
make[1]: Leaving directory '/tmp/yaourt-tmp-user/aur-qtwebkit/src/qtwebkit-2.3.4/WebKitBuild/Release'
make: *** [Makefile:408: incremental] Error 2
==> ERROR: A failure occurred in build().

WoefulDerelict commented on 2017-05-28 13:51

LordAro: That is unreasonable and not at all the best solution. This should build just fine against the current packages for qt, libxml2 and icu shipping from the binary repos. I've successfully built this multiple times using the devtools scripts to construct it in a clean chroot against the most recent packages from the Arch Linux repos.

LordAro commented on 2017-05-28 13:42

It seems unreasonable to me that the requirement for building this package it to modify an "official" package from extra (libxml2) Is there no other solution?