From the site: WebKit is an open source web browser engine. WebKit is also the name of the Mac OS X system framework version of the engine that's used by Safari, Dashboard, Mail, and many other OS X applications. WebKit's HTML and JavaScript code began as a branch of the KHTML and KJS libraries from KDE. It has frontends for Qt and gtk, so let's start rolling. They don't have any release yet, but the subversion state is quite usable. Anyone starting on this might want to have a look at the work already done at Debian, see http://packages.qa.debian.org/w/webkit.html http://packages.debian.org/changelogs/pool/main/w/webkit/current/copyright Thanks.
Please use webkitqt or webkit-qt but not qtwebkit ;-)
Created attachment 131472 [details] WebKit live svn ebuild here's a live svn ebuild I've used to test some web browsers. It's still far from perfect, most notably because paths in pkgconfig files are invalid so you can't build anything until you fix them manually. note that webkit trunk is over 800M so the first checkout will take some time ;) also I'd suggest using net-libs as package category since webkit isn't actually www-client
Created attachment 131478 [details] WebKit live svn ebuild fix for tiny error on my previous ebuild
FYI, I poked webkit-9999.ebuild was filed at comment #3. Then I fixed CHOST and pkg-config related known issue on my personal overlay[1]. And I tested midori-0.0.10[2] on ~amd64. I'd have to say ITJUSTWORKS(tm). :) ----- [1] http://dev.gentoo.gr.jp/~hiyuh/cgi-bin/hgweb.cgi?file/tip/net-libs/webkit/ [2] http://dev.gentoo.gr.jp/~hiyuh/cgi-bin/hgweb.cgi?file/tip/www-client/midori/
(In reply to comment #4) > FYI, I poked webkit-9999.ebuild was filed at comment #3. > Then I fixed CHOST and pkg-config related known issue on > my personal overlay[1]. And I tested midori-0.0.10[2] on > ~amd64. I'd have to say ITJUSTWORKS(tm). :) > ----- > [1] http://dev.gentoo.gr.jp/~hiyuh/cgi-bin/hgweb.cgi?file/tip/net-libs/webkit/ > [2] > http://dev.gentoo.gr.jp/~hiyuh/cgi-bin/hgweb.cgi?file/tip/www-client/midori/ > KIMURA, your WebKit ebuild works for me. I can compile SVN epiphany with WebKit support now. And your midori ebuild works too, so you can add ~x86 to keywords. BTW, if someone is interested in subversion epiphany ebuild with webkit USE flag, let me know.
(In reply to comment #5) > (In reply to comment #4) > > FYI, I poked webkit-9999.ebuild was filed at comment #3. > > Then I fixed CHOST and pkg-config related known issue on > > my personal overlay[1]. And I tested midori-0.0.10[2] on > > ~amd64. I'd have to say ITJUSTWORKS(tm). :) > > ----- > > [1] http://dev.gentoo.gr.jp/~hiyuh/cgi-bin/hgweb.cgi?file/tip/net-libs/webkit/ > > [2] > > http://dev.gentoo.gr.jp/~hiyuh/cgi-bin/hgweb.cgi?file/tip/www-client/midori/ > > > > KIMURA, your WebKit ebuild works for me. I can compile SVN epiphany with WebKit > support now. And your midori ebuild works too, so you can add ~x86 to keywords. > > BTW, if someone is interested in subversion epiphany ebuild with webkit USE > flag, let me know. > I am interested ;-)
Created attachment 135215 [details] epiphany-9999.ebuild with webkit support Here it is, subversion ebuild for epiphany with optional support for webkit. There are three USE flags (firefox, webkit, xulrunner) to select backends. You should choose only one. Works-for-me with USE="webkit -firefox -xulrunner", didn't really test it with other combinations. Before compiling, double-check that /usr/lib/pkgconfig/WebKitGtk.pc contains right paths.
(In reply to comment #5) > KIMURA, your WebKit ebuild works for me. I can compile SVN epiphany with WebKit > support now. And your midori ebuild works too, so you can add ~x86 to keywords. Added ~x86, THX. ;) <SNIP>
(In reply to comment #3) > Created an attachment (id=131478) [edit] > WebKit live svn ebuild > > fix for tiny error on my previous ebuild > There is a typo in ebuild regarding build GTK command, it says "--gdk" http://live.gnome.org/WebKitGtk I am still trying to build GTK one
Created attachment 137507 [details] webkit-28278.ebuild (In reply to comment #9) > (In reply to comment #3) > > Created an attachment (id=131478) [edit] > > WebKit live svn ebuild > > > > fix for tiny error on my previous ebuild > > > There is a typo in ebuild regarding build GTK command, it says "--gdk" > http://live.gnome.org/WebKitGtk > I am still trying to build GTK one > actually its not a typo. the correct build command used to be "--gdk" until they chaned it to "--gtk" :) here's an updated ebuild that uses daily snapshots from http://nightly.webkit.org/ you'll need eqmake4-wrap.sh from KIMURA's overlay
As an irrelevant aside, your ebuild is helping me package it for Fedora too. Thanks. =)
Created attachment 138464 [details] webkit-28669.ebuild (In reply to comment #10) > here's an updated ebuild that uses daily snapshots from > http://nightly.webkit.org/ > you'll need eqmake4-wrap.sh from KIMURA's overlay And here's a slight mod using eqmake natively...
Created attachment 139361 [details] gperf depend and lgpl-2.1 Hi, add gperf dependency and LGPL-2.1 license (WebCore/LICENSE-LGPL-2.1).
Additionally please inherit from eclass multilib and use the get_libdir macro for WEBKIT_INC_DIR. It should look something like that: WEBKIT_INC_DIR=/usr/$(get_libdir)
Created attachment 139386 [details] use gnu build In the last nightly build webkit introduced the gnu build system for (actually yet) the GTK+ port. Well elibtoolize && eautoreconf don't add missing files such as install-sh, missing, depcomp, etc., should we call automake --add-missing ourselves?
Created attachment 139429 [details] remove qt build dependency and compile with -j1 I've added a few minor updates to the last ebuild which seems to work for me. Now calls autogen.sh to install missing files. Also removes the qt requirement with -qt use flag, and added a -j1 make option to stop errors when parallel building. Dale
Created attachment 139448 [details] ebuild for midori git repository The current midori release 0.0.15 does not appear to work with the latest webkit nightly build. Attached ebuild allows midori to be built with webkit-28997 ebuild. Dale
I removed old ebuild of webkit and midori from my overlay. B/c this bug's is more nicer for rice boys. :)
FYI, RESTRICT="mirror" is now redundant, I guess. (In reply to comment #17) > Created an attachment (id=139448) [edit] > ebuild for midori git repository <SNIP>
Created attachment 139504 [details] use automake --add-missing Using autogen.sh would configure the stuff twice, instead doing eautoreconf && automake --add-missing works very well.
Created attachment 139526 [details] Remove RESTRICT="mirror" Removed RESTRICT="mirror" as per Kimura's suggestion.
What about creating a WebKit project with WebKit, epiphany and midori ebuilds?
Created attachment 139707 [details] Update to latest nightly build Update to the latest webkit nightly build which contains a number of autotools updates. Also added xpath and icondb use flags to reflect the latest build.
One thing to note - this doesn't seem to work with --as-needed - not sure if it is WebKit itself, or icu - still trying to track it down - it would seem like the issue is with icu, but supposedly, the issue was fixed in icu-3.8.1...
Created attachment 140437 [details] webkit-gtk-29226.ebuild This is just a suggestion but since the webkit qt will be integrated into qt 4.4, maybe it would be simpler to only have webkit-gtk ebuild, especially now when qt and gtk ports have different build system. Here's an ebuild for latest snapshot with all the qt stuff removed. Also, xpath and xslt are now enabled by default so I removed use flags for them. I think that's something that most people would want anyway. I also removed the icondb use-flag and added sqlite flag which enables or disables HTML5 client-side storage and icon database support.
Created attachment 140439 [details] webkit-gtk-29226.ebuild gah.. accidentally removed the libxslt dependency for previous ebuild
Created attachment 140444 [details] webkit-29226 syntax errors and fix header Good job Joonas, can I ask you to use tabs instead of spaces and check errors with repoman next time?
Created attachment 140446 [details] update Do not check for a webkit gtk build and use www-client/ instead of net-libs/.
Created attachment 140447 [details] update sorry for previous mistake of www-client
Created attachment 140454 [details] update also here remove the gtk build check
I would disagree with webkit being in www-client - I liken webkit to xulrunner - not Firefox. Midori is a web browser - it would go into www-client - however I think webkit should go into net-libs like xulrunner. Just my opinion :)
(In reply to comment #27) > Created an attachment (id=140444) [edit] > webkit-29226 syntax errors and fix header > > Good job Joonas, can I ask you to use tabs instead of spaces and check errors > with repoman next time? > ok, sorry. I'm kinda new at this ebuild submitting thing :) wouldn't it be more logical to call the package webkit-gtk?
steev, good point
I updated epiphany and midori packages to drop the qt port, but I'm not still sure of this. In any case, if we'll really drop the qt idea, the right name would be webkitgtk. But i think it's better to keep the webkit name until qt 4.4 is released with webkitqt.
The bug is just going to keep update the three ebuilds, what about creating a WebKit overlay project so users are able to install it and test it using layman? And we can commit updates to the project svn rather than attaching patches for each nightly build or small change.
Committed here: http://overlays.gentoo.org/proj/sunrise/browser/sunrise/net-libs/webkitgtk
(In reply to comment #36) > Committed here: > http://overlays.gentoo.org/proj/sunrise/browser/sunrise/net-libs/webkitgtk > Great! Just don't use $use_enable with debug and video because for some reason --disable-option enables them.
(In reply to comment #37) > Great! Just don't use $use_enable with debug and video because for some reason > --disable-option enables them. Instead I'm going to fix that in webkit, thanks for this report.
(In reply to comment #29) > Created an attachment (id=140447) [edit] > update > > sorry for previous mistake of www-client > Building epiphany with this ebuild failed for me, apparently this version of epiphany depends on glib-2.15.0, which ist not yet in portage and some other lib called 'gio-unix-2.0', which I don't know. My log: checking for DEPENDENCIES... configure: error: Package requirements ( glib-2.0 >= 2.15.2 gmodule-2.0 gio-unix-2.0 >= 2.15.2 gtk+-2.0 >= 2.11.6 gtk+-unix-print-2.0 >= 2.11.6 libxml-2.0 >= 2.6.12 libxslt >= 1.1.7 libgnome-2.0 >= 2.14.0 libgnomeui-2.0 >= 2.14.0 libglade-2.0 >= 2.3.1 gconf-2.0 gnome-desktop-2.0 >= 2.9.91 libstartup-notification-1.0 >= 0.5 libnotify >= 0.4 ) were not met: Requested 'glib-2.0 >= 2.15.2' but version of GLib is 2.14.3 No package 'gio-unix-2.0' found
> Building epiphany with this ebuild failed for me, apparently this version of > epiphany depends on glib-2.15.0, which ist not yet in portage and some other > lib called 'gio-unix-2.0', which I don't know. In fact the epiphany ebuild is from svn, it's not a release thus might require glib with gio support which are not in portage yet.
New ebuild 29487 in sunrise. autotools.eclass has been patched in bug 205606 so we could remove the automake --add-missing stuff. Also configure script issues have been fixed inside webkit.
Created attachment 141803 [details] virtual/webkit Since portage is going to have at least 2 WebKit versions (Trolltech's and officials)... virtual/webkit
(In reply to comment #42) > Created an attachment (id=141803) [edit] > vitual/webkit > > Since portage is going to have at least 2 WebKit versions (Trolltech's and > officials)... virtual/webkit > As said in a previous comment #10 by Joonas Henriksson, webkitqt will be included in Qt 4.4. If you look in the sunrise overlay it's named webkitgtk.
- webkitgtk doesnt like --as-needed - midori fails to build for me with webkitgtk ( current sunrise version ) with ( among others ) : "»WEBKIT_TYPE_WEB_SETTINGS« not declared" Does midori currently build for others ?
(In reply to comment #44) > - webkitgtk doesnt like --as-needed > - midori fails to build for me with webkitgtk ( current sunrise version ) with > ( among others ) : "»WEBKIT_TYPE_WEB_SETTINGS« not declared" > > Does midori currently build for others ? > It shouldn't do. According to the midori website a newer revision of webkit is needed to compile the current release or git version.
(In reply to comment #43) > (In reply to comment #42) > > Created an attachment (id=141803) [edit] > > vitual/webkit > > > > Since portage is going to have at least 2 WebKit versions (Trolltech's and > > officials)... virtual/webkit > > > > As said in a previous comment #10 by Joonas Henriksson, webkitqt will be > included in Qt 4.4. If you look in the sunrise overlay it's named webkitgtk. > Yes, and webkit.org has their own qt webkit. Will an ebuild exist for both webkit versions?
(In reply to comment #46) > (In reply to comment #43) > > (In reply to comment #42) > > > Created an attachment (id=141803) [edit] > > > vitual/webkit > > > > > > Since portage is going to have at least 2 WebKit versions (Trolltech's and > > > officials)... virtual/webkit > > > > > > > As said in a previous comment #10 by Joonas Henriksson, webkitqt will be > > included in Qt 4.4. If you look in the sunrise overlay it's named webkitgtk. > > > > Yes, and webkit.org has their own qt webkit. Will an ebuild exist for both > webkit versions? > Actually the webkit integrated in qt 4.4 is the qt webkit from webkit.org, and it'll probably be more stable than nightly builds so I don't see the point of having two versions.
(In reply to comment #46) > Yes, and webkit.org has their own qt webkit. Will an ebuild exist for both > webkit versions? Qt 4.4 will include the Safari 3 branch as i know, which is different from the trunk (nightly builds). The problem is that two different webkit libraries could bring confusion. The only difference is that Safari 3 branch is stable while nightly builds are not. Also the virtual wouldn't sounds good to me, since webkitqt and webkitgtk are two different libraries that might live together. What you think about?
(In reply to comment #48) > (In reply to comment #46) > > Yes, and webkit.org has their own qt webkit. Will an ebuild exist for both > > webkit versions? > > Qt 4.4 will include the Safari 3 branch as i know, which is different from the > trunk (nightly builds). The problem is that two different webkit libraries > could bring confusion. > > The only difference is that Safari 3 branch is stable while nightly builds are > not. > > Also the virtual wouldn't sounds good to me, since webkitqt and webkitgtk are > two different libraries that might live together. > > What you think about? > If QT4 contains a straight, unmodified WebKit, and it's possible to use Safari or trunk branch, then there is no reason to have two. I'll obsolete the virtual.
(In reply to comment #49) > If QT4 contains a straight, unmodified WebKit, and it's possible to use Safari > or trunk branch, then there is no reason to have two. I'll obsolete the > virtual. I just had the response from the developers that Qt 4.4 will have the same branch of Safari 3, which is stable.
net-libs/webkitgtk-29487 fails to build exiting with: -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libxml2 -I/usr/include/libxml2 -mcpu=750 -O2 -pipe -MT DerivedSources/libWebKitGtk_la-JSCSSValue.lo -MD -MP -MF DerivedSources/.deps/libWebKitGtk_la-JSCSSValue.Tpo -c DerivedSources/JSCSSValue.cpp -fPIC -DPIC -o DerivedSources/.libs/libWebKitGtk_la-JSCSSValue.o make[1]: *** [JavaScriptCore/kjs/libJavaScriptCore_la-AllInOneFile.lo] Error 1 make[1]: *** Waiting for unfinished jobs.... mv -f DerivedSources/.deps/libWebKitGtk_la-JSCSSValue.Tpo DerivedSources/.deps/libWebKitGtk_la-JSCSSValue.Plo make[1]: Leaving directory `/var/tmp/portage/net-libs/webkitgtk-29487/work/WebKit-r29487' make: *** [all] Error 2 * * ERROR: net-libs/webkitgtk-29487 failed. * Call stack: * ebuild.sh, line 46: Called src_compile * environment, line 2459: Called die * The specific snippet of code: * emake || diefunc "$FUNCNAME" "$LINENO" "$?" "emake failed" * The die message: * emake failed emerge --info : Portage 2.1.4_rc7 (default-linux/ppc/ppc32/2007.0/desktop, gcc-4.2.2, glibc-2.7-r0, 2.6.23-gentoo-r3 ppc) ================================================================= System uname: 2.6.23-gentoo-r3 ppc 740/750 Timestamp of tree: Wed, 06 Feb 2008 03:46:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 3.2_p17-r1 dev-lang/python: 2.5.1-r4 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r2 ACCEPT_KEYWORDS="ppc ~ppc" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-mcpu=750 -O2 -pipe" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-mcpu=750 -O2 -pipe" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" MAKEOPTS="-j2"
New ebuild for nightly r30267 in sunrise.
Nightly r30468 in sunrise.
Created attachment 144737 [details] midori-9999.ebuild midori ebuild working with webkitgtk from sunrise overlay, cleaned up deps (RDEP and DEP were the same, beside git, but that's inherited by the git eclass).
(In reply to comment #54) > Created an attachment (id=144737) [edit] > midori-9999.ebuild > > midori ebuild working with webkitgtk from sunrise overlay, cleaned up deps > (RDEP and DEP were the same, beside git, but that's inherited by the git > eclass). > What about adding midori to sunrise too?
FYI, webkitgtk isn't available for PPC at this time due to a bug: http://bugs.webkit.org/show_bug.cgi?id=17449
(In reply to comment #56) > FYI, webkitgtk isn't available for PPC at this time due to a bug: > > http://bugs.webkit.org/show_bug.cgi?id=17449 This seems to be fixed now.
Created attachment 147569 [details, diff] Webkit gcc-4.3 patch from redhat.
There is a problem with the midori-9999.ebuild, building it yields: >>> Emerging (1 of 1) www-client/midori-9999 to / * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... * git clone start --> * repository: http://software.twotoasts.de/media/midori.git Initialized empty Git repository in /usr/portage/distfiles/git-src/midori/ Getting alternates list for http://software.twotoasts.de/media/midori.git Getting pack list for http://software.twotoasts.de/media/midori.git Getting index for pack 3b32177386d178a495d7b9d026974c3845c71b80 Getting pack 3b32177386d178a495d7b9d026974c3845c71b80 which contains f4abaeb00f7694970d55411768618461941e1db8 walk f4abaeb00f7694970d55411768618461941e1db8 walk a482dc36a82494cf52eecd8c2b729389460720e5 walk ccba177ecbcef8be9e067e4af8436fc38c6c7484 walk b01eb78c9d4be7a598ef6070a2100c059f21e1f6 walk 173b05dd78119942f8ef3bf10c2ac216633ac243 walk 00976c05363a131be2c0658ba019c8dcb66c0986 walk 2bb99e0030155ceafd8ae6e83a4349fd6b690c86 walk c8332ddf548fd11b899247b0321b0daf571f7bba walk fea97e80c3a6c77b6e2b8951fcc3bc17874e6526 walk b8ac63e60a2c3370ee8851f3891d1484659d35b1 walk e9710d3b3be74f50c97a8f059150ae99fa4579cc walk be89221aea13aa092f64d2133fd5bed5c23f4972 walk bf8061865856030f6fa273768d8fb6a0036818db walk 44bc12c305e7137e3b10f7ba86b383e249022a43 walk 02d7848c5ddab57941999e5a59e6ad52d48e36d7 walk 4a1e0ab67b712e7c5eedc607e7dc3ce7c598d9ea walk 9abae486dd2162266b41cc27fb2dac3b50ff2585 walk e1f62329f1d3ec037b398cf6148695063936f2ea walk 622f8ee4452cc22a2eb68051bb261cf341d6e266 walk fbcd3a968015c3ec4c66ec44eaa3216355f7470d walk 25ac3e993227af16cfc868d2de60b824e195dc78 walk 65535e1d875d8e7c51f4ec1bec1aa5593c8e2cc5 walk 1522f47002cbaae46ab10a400b6da422372f4200 walk 184b54e311633961f366e17f5390e1d870981a97 walk cd1fe6bac71cfa31e493a879a99ef04f4f8b9d0f walk 6477032a6d2d73aec2485220f108a9246d60513c walk b2c0363cb4c254602ee5438d3b6582c01c061116 walk 22b277d94b588d2ee49e888688a567ab5cd01f50 walk f614f5874a29a65623f587346d12f700f0e37296 walk e94d8c74e84fca4e116366dcf23c2edc199ad2b7 walk 54e03ab03012f091809ec81e2c52217d0a837a5a walk a9236468d94b67d18c815d6b47280a9383059bff walk 2c08ccbef5c97332fe97c39f872b6eb85daa7674 walk d5a4f4cfd71d919b97371b8ccdfae5138f6cb168 walk e2328a4bfcd0fd595209d01914c2ee6b6fe6965a walk 4a8b2bb226a33ebd34e1c1d895eaade2d5568111 walk 3fc2bced1286d8d2adbb93dc4cea49cf8080dbef walk 7c45654993394116d1fe9f7471f7091d6879b1ba walk 75b0dc673536cde0a9f5d5441d7d2f55e656ac4f walk 1b0b15f3de0c5f98d2f086db5c213038c4c65a40 walk 36a97da3b8612418ff85c01c41109f0e5be6b59c walk b6f248f3440f5e889b5e7910a874a642c9c0f505 walk cd8b1e5b220ddd6225b82b7b145e017765704dac walk 39dedae0d18796e32e34f2ef58670b9fb5b03a02 walk 352e4f7423ca20907870a2e57cbe3b955f88defc walk e3561c71ad9e5289e6726e6f6f6fb9f2df598a6d walk 3f4c2e3c14830eac63f700f5d6d9d7d9c0c79ba6 walk 84ceb56bf8091878193153d2e030ea3a1027f0f8 walk cd1dce0e83bfe8f5135c38eae781b2b763dc014d walk dcb8b2b8d154fc7d0cd4d74e40a0c93dc498a71f walk 5928f8ad88ae98416b7f416cbdf9237b12c3f562 walk 6994580e28d85358a6f4c5f9209e78c75b709d8c walk 118baa716ee4d2bec3b51c1c17686e23c07f8463 walk fb00d180ade114a20168259802dc92df96e58d67 walk 3bbd273a4f9e85a1d8380cb0924c875683fa3ad1 error: Can't lock ref stash * * ERROR: www-client/midori-9999 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2166: Called git_src_unpack * environment, line 1568: Called git_fetch * environment, line 1544: Called die * The specific snippet of code: * ${EGIT_FETCH_CMD} ${EGIT_OPTIONS} "${EGIT_REPO_URI}" ${EGIT_PROJECT } || die "${EGIT}: can't fetch from ${EGIT_REPO_URI}."; * The die message: * git.eclass: can't fetch from http://software.twotoasts.de/media/midori.git. * * If you need support, post the topmost build error, and the call stack if rele vant. * A complete build log is located at '/var/tmp/portage/www-client/midori-9999/t emp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/www-client/midori -9999/temp/environment'.
(In reply to comment #58) > Created an attachment (id=147569) [edit] > Webkit gcc-4.3 patch from redhat. > Did you test the patch? Actually i know several people using gcc 4.3 that have no problems, or experiences crashes or solved the crash by compiling with -O0. I think it's better to wait.
Created attachment 148486 [details] epiphany-9999 remove USE firefox and update Hello, this is a new ebuild which has some updates and removed the firefox USE flag just like the normal epiphany ebuild. For who's interested, i'm creating a gnome-live overlay which will contain also this epiphany ebuild.
Created attachment 148521 [details] epiphany updated for webkit news Ok this is the very latest ebuild for now, just after the firefox/xulrunner support has been removed from the epiphany build. Only webkit now, have fun!
Created attachment 148543 [details] latest (nightly) build of webkit, fixes for SVG use flag. Previous version's ebuild in sunrise will not merge properly with SVG selected due to a bug in the autoconfigure code. This is a known bug upstream. The SVG use flag now implies: $(use_enable svg svg-animation) \ $(use_enable svg svg-experimental) \ $(use_enable svg svg-filters) \ $(use_enable svg svg-fonts) \ $(use_enable svg svg-as-image) \ $(use_enable svg svg-use-element) \ Not just $(use_enable svg) \
(In reply to comment #63) > Created an attachment (id=148543) [edit] > latest (nightly) build of webkit, fixes for SVG use flag. > > Previous version's ebuild in sunrise will not merge properly with SVG selected > due to a bug in the autoconfigure code. This is a known bug upstream. The SVG > use flag now implies: > $(use_enable svg svg-animation) \ > $(use_enable svg svg-experimental) \ > $(use_enable svg svg-filters) \ > $(use_enable svg svg-fonts) \ > $(use_enable svg svg-as-image) \ > $(use_enable svg svg-use-element) \ > > Not just > $(use_enable svg) \ > That was already fixed in sunrise r31535, we're not using filters and experimental tough. The svg options are not fully splitted in the code yet. Can you test the current ebuild in sunrise?
(In reply to comment #64) > (In reply to comment #63) > > Created an attachment (id=148543) [edit] > > latest (nightly) build of webkit, fixes for SVG use flag. > > > > Previous version's ebuild in sunrise will not merge properly with SVG selected > > due to a bug in the autoconfigure code. This is a known bug upstream. The SVG > > use flag now implies: > > $(use_enable svg svg-animation) \ > > $(use_enable svg svg-experimental) \ > > $(use_enable svg svg-filters) \ > > $(use_enable svg svg-fonts) \ > > $(use_enable svg svg-as-image) \ > > $(use_enable svg svg-use-element) \ > > > > Not just > > $(use_enable svg) \ > > > > That was already fixed in sunrise r31535, we're not using filters and > experimental tough. The svg options are not fully splitted in the code yet. > > Can you test the current ebuild in sunrise? I didn't see the ebuild in sunrise when I posted the updated ebuild. Yes, the new ebuild in sunrise (r31535) builds fine, however, it does not get 100/100 on ACID3 -- only 99/100. The "experimental" features relating to animation are required for 100/100.
(In reply to comment #65) > I didn't see the ebuild in sunrise when I posted the updated ebuild. Yes, the > new ebuild in sunrise (r31535) builds fine, however, it does not get 100/100 on > ACID3 -- only 99/100. The "experimental" features relating to animation are > required for 100/100. Ah i didn't know just because it crashes for me for Javascript stuff, can you tell me your gcc version and what platform are you on? I updated the ebuild and bumped the version, can you test it again? Thanks.
webkitgtk-31535 built successfully on PPC
(In reply to comment #67) > webkitgtk-31535 built successfully on PPC > Thanks added ~ppc in latest webkitgtk-31623.ebuild in sunrise.
(In reply to comment #68) > (In reply to comment #67) > > webkitgtk-31535 built successfully on PPC > > > > Thanks added ~ppc in latest webkitgtk-31623.ebuild in sunrise. > Builds fine, no crashes or anything. I never got crashes before actually. What site were you testing?
(In reply to comment #69) > (In reply to comment #68) > > (In reply to comment #67) > > > webkitgtk-31535 built successfully on PPC > > > > > > > Thanks added ~ppc in latest webkitgtk-31623.ebuild in sunrise. > > > > Builds fine, no crashes or anything. I never got crashes before actually. What > site were you testing? > Web sites using javascript stuff, for example google products, acid3, ecc. Can you tell me your gcc version and platform? I fear it's a gcc < 4.2 issue.
(In reply to comment #70) > (In reply to comment #69) > > (In reply to comment #68) > > > (In reply to comment #67) > > > > webkitgtk-31535 built successfully on PPC > > > > > > > > > > Thanks added ~ppc in latest webkitgtk-31623.ebuild in sunrise. > > > > > > > Builds fine, no crashes or anything. I never got crashes before actually. What > > site were you testing? > > > > Web sites using javascript stuff, for example google products, acid3, ecc. > Can you tell me your gcc version and platform? I fear it's a gcc < 4.2 issue. > Not a < gcc 4.2 issue at all. :( # emerge --info Portage 2.1.4.4 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24-gentoo-r3 i686) ================================================================= System uname: 2.6.24-gentoo-r3 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ Timestamp of tree: Wed, 02 Apr 2008 21:00:01 +0000 app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r9 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac acl acpi aiglx alsa amr aoss asf bash-completion berkdb bzip2 cairo cjk cli cracklib crypt cups curl cvs dbus dri dvd encode exif fam fortran gdbm gif glitz gpm gstreamer gtk hal iconv isdnlog java jpeg mad midi mmx mp3 mp4 mudflap ncurses network nls nptl nptlonly nsplugin offensive ogg opengl openmp pam pcre pdf perl png pppd python quicktime rar readline real reflection samba sdl session spell spl sqlite sse sse2 ssl startup-notification subversion svg tcpd threads tiff tk truetype unicode vidix vim-syntax vorbis win32codecs x264 x86 xcb xcomposite xinerama xml xorg xprint xscreensaver xv xvid zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
epiphany-9999.ebuild fails on autogen: Checking for required M4 macros... gtk-doc.m4 not found ***Error***: some autoconf macros required to build epiphany were not found in your aclocal path, or some forbidden macros were found. Perhaps you need to adjust your ACLOCAL_FLAGS? I do have gtk-doc-1.10-r1 installed. A find / -name gtk-doc.m4 revealed nothing. I did find gtk-doc.m4 in gtk-doc-1.10-r1.tgz however but I would have no idea where to put it.
(In reply to comment #72) > epiphany-9999.ebuild fails on autogen: > > Checking for required M4 macros... > gtk-doc.m4 not found > ***Error***: some autoconf macros required to build epiphany > were not found in your aclocal path, or some forbidden > macros were found. Perhaps you need to adjust your > ACLOCAL_FLAGS? > > I do have gtk-doc-1.10-r1 installed. A > > find / -name gtk-doc.m4 > > revealed nothing. I did find gtk-doc.m4 in gtk-doc-1.10-r1.tgz however but I > would have no idea where to put it. > Try installing gtk-doc.
(In reply to comment #71) > Not a < gcc 4.2 issue at all. :( Yes you have just my same configuration, athlon 64 and gcc 4.1.2. I'm sad...
(In reply to comment #73) > (In reply to comment #72) > > epiphany-9999.ebuild fails on autogen: > > > > Checking for required M4 macros... > > gtk-doc.m4 not found > > ***Error***: some autoconf macros required to build epiphany > > were not found in your aclocal path, or some forbidden > > macros were found. Perhaps you need to adjust your > > ACLOCAL_FLAGS? > > > > I do have gtk-doc-1.10-r1 installed. A > > > > find / -name gtk-doc.m4 > > > > revealed nothing. I did find gtk-doc.m4 in gtk-doc-1.10-r1.tgz however but I > > would have no idea where to put it. > > > > Try installing gtk-doc. > Would be appreciative if someone would locate gtk-doc.m4 and and equery it for me. Globally I have "-doc" set and got this error output originally. So I'm thinking some other package may be responsible for it.
(In reply to comment #75) > Would be appreciative if someone would locate gtk-doc.m4 and and equery it for > me. Globally I have "-doc" set and got this error output originally. So I'm > thinking some other package may be responsible for it. > $ equery f gtk-doc-am [ Searching for packages matching gtk-doc-am... ] * Contents of dev-util/gtk-doc-am-1.10: /usr /usr/share /usr/share/aclocal /usr/share/aclocal/gtk-doc-1.10.m4 But I can't build epiphany from this ebuild too.
Comment on attachment 135215 [details] epiphany-9999.ebuild with webkit support Old ebuild, made before GNOME 2.22 was released. Possibly doesn't work anymore.
There are two outstanding security issues (CVE-2008-1010 and CVE-2008-1011) that Apple released update Safari builds for a while back; but I've been unable to track down the relevant fixes in upstream's Trac. Does this WebKit snapshot fix these? Just curious...thanks!
Created attachment 148838 [details] use autogen.sh Can you try this one? I couldn't test it actually.
(In reply to comment #78) > There are two outstanding security issues (CVE-2008-1010 and CVE-2008-1011) > that Apple released update Safari builds for a while back; but I've been unable > to track down the relevant fixes in upstream's Trac. Does this WebKit snapshot > fix these? Just curious...thanks! > They're fixed in Safari 3.1 (r31133) from this announce: http://lists.apple.com/archives/security-announce/2008/Mar/msg00000.html
(In reply to comment #80) > They're fixed in Safari 3.1 (r31133) from this announce: > http://lists.apple.com/archives/security-announce/2008/Mar/msg00000.html I _knew_ I was overlooking something. =) Thanks very much.
Created attachment 149045 [details] epiphany live svn ebuild with webkit Ok, I finally compiled epiphany. But after installing gtk-doc I had to do ln -s gtk-doc-1.10.m4 gtk-doc.m4 in /usr/share/aclocal directory. Looks like a dirty hack, but I'm really not good at editing autotools scripts. It can be either a bug in epiphany configure scripts, or a bug in Gentoo's gtk-doc installation, I don't know. Attached ebuild works with this hack.
(In reply to comment #82) > Created an attachment (id=149045) [edit] > epiphany live svn ebuild with webkit > > Ok, I finally compiled epiphany. But after installing gtk-doc I had to do > > ln -s gtk-doc-1.10.m4 gtk-doc.m4 > > in /usr/share/aclocal directory. Looks like a dirty hack, but I'm really not > good at editing autotools scripts. It can be either a bug in epiphany configure > scripts, or a bug in Gentoo's gtk-doc installation, I don't know. > > Attached ebuild works with this hack. > Ok, that was really a bug #216634 in Gentoo's gtk-doc. It should be fixed now, so the hack is not needed anymore and epiphany ebuild should work fine.
Nice job Andre, got it working.
I'm going to remove those redundant svg enables and keep only --enable-svg-experimental in sunrise. From configure.ac: if test "$enable_svg_experimental" = "yes"; then enable_svg=yes enable_svg_animation=yes # enable_svg_filters=yes enable_svg_fonts=yes enable_svg_foreign_object=yes enable_svg_as_image=yes enable_svg_use_element=yes fi Filters are not implemented in the GTK port so they're unuseful and most of all they need a bunch of time to compile. Anyone is going to not agree with this change?
(In reply to comment #59) > error: Can't lock ref stash Sorry, but what is a way to walk around this issue? Google is not helpful there…
Created attachment 150472 [details] dev-python/pywebkitgtk-9999 (git) Here's an ebuild I wrote for PyWebKitGtk, which is exactly what the name suggests. http://live.gnome.org/PyWebKitGtk It's from VCS because the released version is too old to link with the webkitgtk currently in sunrise. (BTW, the midori repo is down, which is why that ebuild no longer works.)
Created attachment 151408 [details] webkitgtk-32652.ebuild Proper ebuild. Removes unnecessary dependencies that are already in the "system" set, and fixes versions for others. Also removes dependencies that are already required by some other deps, like gtk. This one has *correct* USE flags. Take a look at configure.ac to see what's really there, and what should be optional. This ebuild allows proper selection of backends for font rendering, http, and xslt. Also allows for proper building with the MAEMO platform. You also get your choice of basic SVG support with USE=svg, or the experimental SVG options can be enabled with USE=svg-experimental. Note that configure.ac indicates that the individual SVG entries are experimental, which is why they're all turned on in one go if you build with svg-experimental. That's designed behavior; no need for a long list of SVG stuff in the ebuild when the configure script does it all for you with no intervention required. Final: it's very possible that you can actually build webkitgtk and an app that uses it without needing gnomevfs. gstreamer doesn't always need gnomevfs, and if you patch the makefile and configure.ac to remove all references to gnomevfs (and change the ebuild of course), webkitgtk will actually build. This is because there's only one file in the source that includes gnomevfs, and it doesn't actually pull any code from it or use it in the slightest...so theoretically, it should work without it. Haven't tested with a browser yet, just that it builds correctly. :)
webkitgtk-32652 with libsoup support seems to require libsoup 2.23 version at least as the following configure error msg says. its also confirmed with the webkit commit log [1]. (...) checking the font backend to use... pango checking for LIBSOUP... configure: error: Package requirements (libsoup-2.4 >= 2.23) were not met: Requested 'libsoup-2.4 >= 2.23' but version of libsoup is 2.4.0 (...) Simply renaming libsoup-2.4.1.ebuild to 2.23 did work. [1] http://trac.webkit.org/changeset/31878
libsoup 2.23 is a dev version, and so is in the gnome overlay, not in portage.
webkit in portage now, so closing it here
(In reply to comment #86) > (In reply to comment #59) > > error: Can't lock ref stash > > Sorry, but what is a way to walk around this issue? Google is not helpful > there… > http://forums.gentoo.org/viewtopic-t-683384-highlight-ref+stash.html
Created attachment 200349 [details] WebKit live git ebuild