phantomjs 1.5.0 is available. It supports X-less rendering. Nevertheless, bumping does not seem straightforward to me. phantomjs 1.5.0 bundles its own qt version and depends on qt[qpa]. Of course, it fails to build if previous phantomjs 1.4.1 ebuild is used as is.
Created attachment 307405 [details] 1.5.0 ebuild well, we can't use the bundled QT, and apparently they've extended the bundled QT so the system one won't work, and it relies on a USE flag that is package.use.mask-ed atm, so this version is going nowhere fast ...
src is now a .zip Doesn't look like 1.6.0 is any better: >>> Compiling source in /var/tmp/portage/www-client/phantomjs-1.6.0/work/phantomjs-1.6.0 ... make cd src/ && /usr/bin/qmake /var/tmp/portage/www-client/phantomjs-1.6.0/work/phantomjs-1.6.0/src/phantomjs.pro QTDIR=/usr/lib64 QMAKE=/usr/bin/qmake QMAKE_CC=x86_64-pc-linux-gnu-gcc QMAKE_CXX=x86_64-pc-linux-gnu-g++ QMAKE_LINK=x86_64-pc-linux-gnu-g++ QMAKE_CFLAGS=-O2\ -pipe QMAKE_CFLAGS_RELEASE= QMAKE_CFLAGS_DEBUG= QMAKE_CXXFLAGS=-O2\ -pipe QMAKE_CXXFLAGS_RELEASE= QMAKE_CXXFLAGS_DEBUG= QMAKE_LFLAGS=-Wl,-O1\ -Wl,--as-needed QMAKE_LFLAGS_RELEASE= QMAKE_LFLAGS_DEBUG= QMAKE_LIBDIR_QT=/usr/lib64/qt4 QMAKE_LIBDIR_X11=/usr/lib64 QMAKE_LIBDIR_OPENGL=/usr/lib64 QMAKE_STRIP= -o Makefile.phantomjs cd src/ && make -f Makefile.phantomjs make[1]: Entering directory `/var/tmp/portage/www-client/phantomjs-1.6.0/work/phantomjs-1.6.0/src' x86_64-pc-linux-gnu-g++ -c -O2 -pipe -Wall -W -D_REENTRANT -DHAVE_CONFIG_H -DHAVE_FCNTL_H -DHAVE_STDARG_H -DHAVE_STDINT_H -DHAVE_UNISTD_H -DUSE_UTF8 -DQT_NO_DEBUG -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtWebKit -I/usr/include/qt4 -Igif -Imongoose -Ilinenoise/src -Ibreakpad/src -I. -o phantom.o phantom.cpp In file included from phantom.cpp:42:0: webpage.h:49:1: error: expected class-name before ‘{’ token phantom.cpp: In member function ‘void Phantom::onInitialized()’: phantom.cpp:318:5: error: no matching function for call to ‘QWebFrame::evaluateJavaScript(QString, QString)’ phantom.cpp:318:5: note: candidate is: In file included from /usr/include/qt4/QtWebKit/QWebFrame:1:0, from utils.h:35, from phantom.cpp:41: /usr/include/qt4/QtWebKit/qwebframe.h:203:14: note: QVariant QWebFrame::evaluateJavaScript(const QString&) /usr/include/qt4/QtWebKit/qwebframe.h:203:14: note: candidate expects 1 argument, 2 provided make[1]: *** [phantom.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/www-client/phantomjs-1.6.0/work/phantomjs-1.6.0/src' make: *** [sub-src-phantomjs-pro-make_default-ordered] Error 2 emake failed * ERROR: www-client/phantomjs-1.6.0 failed (compile phase): * died running emake, base_src_make
How about a phantomjs-bin ? This is maintained upstream.
Version 1.7 is out now. Because of the library bundling I still think it would make sense to move this package to phantomjs-bin . Here are the soure URI's. http://phantomjs.googlecode.com/files/phantomjs-1.7.0-linux-x86_64.tar.bz2 http://phantomjs.googlecode.com/files/phantomjs-1.7.0-linux-i686.tar.bz2 vapier, would you consider maintaining this version?
PhantomJS 1.7 compiles and tests just fine on my system if I use the provided build.sh script (which uses the bundled QT). I've created the following ebuilds: phantomjs-1.7.0.ebuild phantomjs-1.7.9999.ebuild phantomjs-9999.ebuild phantomjs-bin-1.7.0.ebuild These ebuilds work for me, but please double check them before using them. Any feedback would be appreciated. You can find everything here: https://github.com/gg7/gentoo-overlay/tree/master/www-client .
phantomjs 1.9.0 is in the tree now, so I guess this can be closed?
Jason: you need to talk to maintainers before you go updating packages like this. silently adding yourself to metadata.xml doesn't cut it. i cleaned up a lot of beginner mistakes in the ebuild for you. this version also heavily violates the bundled lib policy and ignores a lot of common USE flags
To confirm, I am following upstream working practices. I have untangled the git submodule madness and am using clean upstream tarballs, but for now this is as close as I will get. If we can patch the current 2.1.1 ebuid then I'm all for it, but let's do that in a new bug.