| Summary: | www-plugins/pipelight - use Silverlight apps in browser using Wine | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | James Le Cuirot <chewi> |
| Component: | New packages | Assignee: | Richard Yao (RETIRED) <ryao> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | 96bd763529be62c7350d43e8ae67f9623c998ddc, allen.m.holl, andrzej.kardas, bugs.gentoo.org, bugzilla93443, dschridde+gentoobugs, fitzcarraldo1, gentoo, kripton, manschwetus, michael, mrueg, mstomich, odi, olemarkus, ppn, tobias |
| Priority: | Normal | Keywords: | EBUILD |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://launchpad.net/pipelight | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
pipelight-9999.ebuild
pipelight-9999.ebuild pipelight-9999.ebuild pipelight-9999.ebuild using binary pluginloader.exe www-plugins/pipelight-0.2.2.ebuild metadata.xml www-plugins/pipelight-0.2.2.ebuild www-plugins/pipelight-0.2.3.ebuild metadata.xml Update to 0.2.4.2 Update to 0.2.5 with fds-team prebuilt Update to 0.2.6 Update to 0.2.7.1 pipelight-0.2.7.2.ebuild pipelight-9999.diff |
||
Just in case someone stumbles across this and want to try it out, you need to apply 8 patches against Wine 1.7.0. Sounds nasty but they apply perfectly if you just drop them in /etc/portage/patches/app-emulation/wine. http://bazaar.launchpad.net/~ehoover/netflix-desktop/trunk/files/head:/wine-patches https://bitbucket.org/mmueller2012/pipelight/raw/master/wine-patches/0008-winex11-Add-minimal-XEmbed-client-support.patch Created attachment 356452 [details]
pipelight-9999.ebuild
One of my sed's was fixed upstream, plus some other improvements. More to come.
Created attachment 356458 [details]
pipelight-9999.ebuild
Ignore that last attempt, it was all wrong! :/
I wanted to test out the ebuild, I already have wine setup as is. It is erroring out for me on packages such as cross-mingw32/w32api or the other cross-mingw32 one. This is probably still being update just wanted to let you know. This highlights a decision I need to make regarding the approach to dependencies. A mingw32 toolchain is required but these packages don't exist in the tree. You need to create them manually with crossdev. # emerge crossdev # crossdev -t mingw32 I previously thought that I couldn't add these to DEPEND because they used different KEYWORDS and, as such, I added the check to pkg_pretend, which allowed me to include the instructions about crossdev. I later realised that I was mistaken about the KEYWORDS and, on balance, I thought a correct DEPEND would be less hacky than using pkg_pretend. Given what you just said though, I should reconsider pkg_pretend. In fact, I don't think there's any reason why I couldn't use both. pkg_pretend is executed before the dependencies are checked so this would still be useful. I had wine already installed, same with mingw32. I removed the parts from the ebuild that handled the mingw32 as a depend. So it basically just installed pipelight. That was successful and now I have it working in firefox off the ebuild. Glad it worked out. So you have mingw32 but you're saying it didn't come from cross-mingw32/gcc and friends? Would you mind telling me where it did come from? If it was some other package, this should tell us. # equery b `ls /usr/bin/mingw32-g++-*` I just did the: # emerge crossdev # crossdev -t mingw32 Manually and it gave it to me. That is how I got it, so I am not sure about those packages you're asking. Okay, so exactly what error was it giving you before you removed mingw32 from DEPEND? emerge: there are no ebuilds to satisfy "cross-mingw32/gcc[cxx]". emerge: there are no ebuilds to satisfy "cross-mingw32/w32api". WFM. I’m guessing rat tried emerging pipelight before running 'emerge -n crossdev && crossdev -t mingw32', which would spit out such an error. Managed to do that myself at least once. :) Either that or his mingw32 stuff is in an odd place. Actually I didn't. I was just giving James the errors of what it would give if I hadn't. :) The main blocker for inclusion into the main tree is the dependence on the ebuilds dynamically generated by crossdev. I shared this concern with upstream about a week ago, which resulted in the addition of a USE_WINE_GCC flag in the upstream repository. Unfortunately, that flag is not working yet and until it does, this cannot enter the main tree. In the mean time, I have developed an overlay that should contain everything necessary to install pipelight: https://github.com/ryao/pipelight-overlay This is a first attempt, so it is likely rough around the edges. Feedback is appreciated. My plan going forward is to move www-plugin/pipelight into the main tree after USE_WINE_GCC is fully functional and I have had a chat with the app-emulation/wine maintainer about possibly merging the compholio patches to eliminate the need for app-emulation/wine-compholio. Aah clever, I didn't know Winelib was a possibility. ryao, please also note my bug report about the Wine dependency on xattr.h being automagic. https://bugs.launchpad.net/netflix-desktop/+bug/1219457 Did you write the scripts in files to install Silverlight? Nice work. I was thinking of writing an eselect module to switch between them and also install them if necessary but I'll check those out first. (In reply to James Le Cuirot from comment #14) > Aah clever, I didn't know Winelib was a possibility. > > ryao, please also note my bug report about the Wine dependency on xattr.h > being automagic. > https://bugs.launchpad.net/netflix-desktop/+bug/1219457 Thanks for letting me know. app-emulation/wine and app-emulation/wine-compholio should both depend on sys-apps/attr until Wine has --with-xattr. Would you mind opening a Gentoo bug for the wine maintainer? I would prefer an end-user to file it to show that this matters to more people than just me. > Did you write the scripts in files to install Silverlight? Nice work. I was > thinking of writing an eselect module to switch between them and also > install them if necessary but I'll check those out first. The Arch Linux Pipelight maintainer wrote those scripts. We have been chatting about this and other things in #pipelight on freenode. Thanks for the overlay! However, could it be possible that this only works for 32 bit setups? Crossdev does not install the cross-i686-w64-mingw32/* packages, but instead I have some cross-x86_64-w64-mingw32/* packages. I tried to modify the ebuild accordingly, but now emerge fails with make[1]: i686-w64-mingw32-g++: Command not found Is there any chance to get this running on 64 bit? just wanted to try pipelight-9999 on my ~amd64 htpc. crossdev and crossdev -t mingw32 are already installed wine patches are directly applied to wine via /etc/portage/patches/. EGIT_COMMIT="v0.2.0" up to current master dies with an undefined reference to RRF_RT_ANY (and some others following) pinned to the old EGIT_COMMIT="v0.1-4" also doesn't succeed as it dies with an undefined reference to _CW_DEFAULT (v.0.2.0 would die there too if it got so far). RRF_RT_ANY is said (google) to be defined in "winreg.h" which should come with mingw-runtime but this is not the case here. _CW_DEFAULT is defined in /usr/include/wine/msvcrt/float.h so I guess the assumption that maybe the wrong float.h is included which I found here is probably right: http://wiki.gentoo.org/wiki/Talk:Netflix/Pipelight on the other hand the line _controlfp_s(&control_word, _CW_DEFAULT, MCW_PC); which is only parsed if wine is not used (as controlfp_s is not built into wineg++ - see comment in code) should not receive the wine float.h from above, right? Any hints are welcome and I hope USE_WINE_GCC will work soon :} Created attachment 362472 [details]
pipelight-9999.ebuild using binary pluginloader.exe
I worked around the build issues by using the pluginloader.exe binary from launchpad.
attached modified ebuild, based on Richard Yao's ebuild from his overlay (see #13)
is somewhat unpolished but works for me and might be useful for someone else.
I prefer to use the winepatches in /etc/portage/patches/app-emulation/wine
instead of pulling a wine-compholio, so i removed that in the ebuild.
${FILESDIR} is in the overlay oc
Created attachment 365206 [details]
www-plugins/pipelight-0.2.2.ebuild
After 4 days I've written an ebuild from the ground up, although I borrowed a little from Richard Yao's ebuild on the pipelight overlay. One thing of note which I intentionally omitted is an abi specification for wine. I admit that I don't know much about multilib Gentoo, so if someone who does understand multilib knows that this is really necessary, then by all means add it back. However, the only part of the whole thing that must be compiled 32-bit is the pluginloader.exe which will be loaded by wine. But 64-bit wine can run both 32-bit and 64-bit Windows programs, so I don't see any need to require a 32-bit version of wine to be installed.
In any case, I give the user a choice of using the upstream binary pluginloader.exe or compiling their own. I have tested both, and I have compiled the pluginloader.exe both statically and dynamically linked. All 3 options worked well on the 64-bit system I used for testing.
As for which cross compiler can be used, it seems that it must be i686-w64-mingw32. I originally tried to compile with x86_64-w64-mingw32, but it would not compile even when trying to pass -m32 as a Parameter to gcc. slackner and DarkPlayer on Freenode's #pipelight concurred that this will not work, and they were very helpful in helping me troubleshoot.
If anyone wants to try it out, I have this ebuild and an ebuild for a version of wine-1.7.8 with Compholio patches on paddymac overlay ready for testing. Any suggestions are welcome. Version 0.2.3 of Pipelight should be out in a few days. Also, I'm willing to volunteer to maintain this package if it doesn't have a maintainer yet.
Created attachment 365208 [details]
metadata.xml
Created attachment 365210 [details]
www-plugins/pipelight-0.2.2.ebuild
Upon further investigation, I see why [abi_x86_32] is needed. I added this and fixed a typo in the RDEPEND.
Hi Patrick. I think that maybe you should stick with crossdev's preferred HOST, which is simply mingw32. See "crossdev -t help" for this. I already used mingw32 for other things and it would be annoying to have to rebuild it just to get a different HOST. If you look at my ebuild (see comment #3) then you'll see that a sed is all that is required to make this work. As for x86_64-w64-mingw32, when I originally tried to use this, I built it as a 64-bit binary but that certainly doesn't work. I didn't think to try -m32. I'm not sure if this toolchain supports multilib but using mingw32 is simplest. I'm still very interested in this but I was holding out in the hope that someone would get a winelib version working. (In reply to Patrick McMunn from comment #21) > Created attachment 365210 [details] > www-plugins/pipelight-0.2.2.ebuild > > Upon further investigation, I see why [abi_x86_32] is needed. I added this > and fixed a typo in the RDEPEND. Please add x11-apps/mesa-progs and app-arch/cabextract to RDEPEND. x11-apps/mesa-progs (glxinfo) is used by /usr/share/pipelight/hw-accel-default script. app-arch/cabextract is used by /usr/share/pipelight/install-dependency script. Created attachment 366520 [details]
www-plugins/pipelight-0.2.3.ebuild
I added app-arch/cabextract and x11-apps/mesa-progs to the RDEPEND. I also modified the ebuild slightly to support the additional plugins supported by 0.2.3. Also, in response to Mr. Le Cuirot's comments, I think it would be good to have the ebuild configurable to support a choice of cross compilers if multiple ones will perform the task. So I tested it on my own computer then chatted with the devs in #pipelight on Freenode. Apparently mingw32 would work on Pipelight in the past, but it now fails on the current code due to changes which were made in more recent versions of Pipelight. So at least for the time being, i686-w64-mingw32 is the only confirmed working cross compiler for the current Pipelight code.
Created attachment 366522 [details]
metadata.xml
Updated metadata.xml for 0.2.3
Comment on attachment 366520 [details]
www-plugins/pipelight-0.2.3.ebuild
you cannot modify the / system like that in pkg pre/post rm
use the nsplugins eclass
Created attachment 371638 [details]
Update to 0.2.4.2
Here is an update to 0.2.4.2. It was updated from 0.2.3 and fixes the problem with tar.xz. Also the source folder was updated. This update fixes for me the problem with Amazon Instant Video. To run NETFLIX, you need to apply some patches to run the DRM, for example. I took a "ebulid" a guy who created for archlinux, but serves as a basis, who can implement this for Gentoo, because the wine must contain these patches to work. If so, can create a "wine-silverlight" with all patches applied. "Ebuild" - https://aur.archlinux.org/packages/wi/wine-silverlight/PKGBUILD Link patches: http://fds-team.de/cms/pipelight-compile-wine.html Created attachment 373832 [details] Update to 0.2.5 with fds-team prebuilt Use binary-pluginloader from http://repos.fds-team.de/pluginloader/ Extract license from /src/linux/basicplugin.c Created attachment 374380 [details]
Update to 0.2.6
Update to 0.2.6
It is now possible to use WineG++ to compile the 32 bit version of pluginloader.exe and no cross compiler is needed any more.
Comment on attachment 374380 [details] Update to 0.2.6 ># Distributed under the terms of the GNU General Public License v2 > >EAPI=5 > >inherit eutils multilib > >DESCRIPTION="A browser plugin which allows one to use windows-only plugins inside Linux browsers." >HOMEPAGE="http://fds-team.de/cms/index.html https://launchpad.net/pipelight" >SRC_URI="https://bitbucket.org/mmueller2012/pipelight/get/v${PV}.tar.gz -> ${P}.tar.gz >binary-pluginloader? ( http://repos.fds-team.de/pluginloader/v${PV}/pluginloader.tar.gz -> pluginloader-prebuilt-v${PV}.tar.gz )" >LICENSE="GPL-2 LGPL-2.1 MPL-1.1" >SLOT="0" >KEYWORDS="~amd64 ~x86" >IUSE="adobereader +binary-pluginloader flash foxitpdf grandstream installation-dialogs npactivex roblox shockwave +silverlight static unity3d" > >DEPEND="app-arch/cabextract > >=app-emulation/wine-1.7.8-r100[abi_x86_32] > x11-apps/mesa-progs" > >RDEPEND="${DEPEND}" > >S="${WORKDIR}/mmueller2012-pipelight-487f8db5a03d" > >src_prepare() { > if use binary-pluginloader; then > mv ${WORKDIR}/src/windows/pluginloader.exe ${S}/src/windows/pluginloader.exe > fi >} > >src_configure() { > > local myargs > if use binary-pluginloader; then > myargs+="--win32-prebuilt" > elif use !binary-pluginloader; then > if use static; then > myargs+=" --win32-static" > else > myargs+=" --win32-cxx=$(/usr/bin/which wineg++)" > fi > fi > if use installation-dialogs; then > myargs+=" --show-installation-dialogs" > fi > > # We're not using econf because this is not an autotools configure script > ./configure \ > --prefix=/usr \ > --wine-path=/usr/bin/wine \ > --moz-plugin-path=/usr/$(get_libdir)/nsbrowser/plugins \ > ${myargs} >} > >src_install() { > default > #LICENSE is taken from src/linux/basicplugin.c in the pipelight source code. > sed -n -e '/BEGIN LICENSE/,/END LICENSE/p' ${S}/src/linux/basicplugin.c >> ${S}/LICENSE > dodoc ${S}/LICENSE debian/changelog >} > >pkg_postinst() { > einfo "Creating copies of libpipelight.so..." > pipelight-plugin --create-mozilla-plugins > > #The following plugins are not created by "pipelight-plugin --create-mozilla-plugins" and must be "unlocked" > use adobereader && pipelight-plugin --unlock-plugin adobereader > use foxitpdf && pipelight-plugin --unlock-plugin foxitpdf > use grandstream && pipelight-plugin --unlock-plugin grandstream > use npactivex && pipelight-plugin --unlock-plugin npactivex > use roblox && pipelight-plugin --unlock-plugin roblox > use shockwave && pipelight-plugin --unlock-plugin shockwave > > einfo "Enabling plugins..." > # Setup symlinks to enable plugins based on USE flags > use adobereader && ln -sf /usr/$(get_libdir)/pipelight/libpipelight-adobereader.so /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-adobereader.so > use flash && ln -sf /usr/$(get_libdir)/pipelight/libpipelight-flash.so /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-flash.so > use foxitpdf && ln -sf /usr/$(get_libdir)/pipelight/libpipelight-foxitpdf.so /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-foxitpdf.so > use grandstream && ln -sf /usr/$(get_libdir)/pipelight/libpipelight-grandstream.so /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-grandstream.so > use npactivex && ln -sf /usr/$(get_libdir)/pipelight/libpipelight-npactivex.so /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-npactivex.so > use roblox && ln -sf /usr/$(get_libdir)/pipelight/libpipelight-roblox.so /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-roblox.so > use shockwave && ln -sf /usr/$(get_libdir)/pipelight/libpipelight-shockwave.so /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-shockwave.so > use silverlight && ln -sf /usr/$(get_libdir)/pipelight/libpipelight-silverlight5.1.so /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-silverlight5.1.so > use unity3d && ln -sf /usr/$(get_libdir)/pipelight/libpipelight-unity3d.so /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-unity3d.so > > echo > elog "When you first start your browser after installing Pipelight, Pipelight will " > elog "download and install any enabled plugins. This may take a few minutes to " > elog "complete. " > elog > elog "Some web sites will check what operating system you are using and will not " > elog "function properly if they detect Linux. For these sites, you will need to " > elog "install and enable a user agent string editor. The user agent string " > elog "recommended by upstream for many Silverlight apps is " > elog "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120427 Firefox/15.0a1 " > elog "and for many Unity 3D apps is " > elog "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/534.55.3 (KHTML, like" > elog " Gecko) Version/5.1.3 Safari/534.53.10 " > elog "See https://answers.launchpad.net/pipelight/+faq/2351 for more information. " > elog > elog "GPU acceleration is not enabled by default for all graphics cards. See " > elog "https://answers.launchpad.net/pipelight/+faq/2364 for more information. " > echo >} > >pkg_prerm() { > einfo "Removing copies of libpipelight.so..." > pipelight-plugin --remove-mozilla-plugins > > einfo "Disabling plugins..." > if [ -h /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-adobereader.so ] ; then > rm /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-adobereader.so > fi > if [ -h /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-flash.so ] ; then > rm /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-flash.so > fi > if [ -h /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-foxitpdf.so ] ; then > rm /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-foxitpdf.so > fi > if [ -h /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-grandstream.so ] ; then > rm /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-grandstream.so > fi > if [ -h /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-npactivex.so ] ; then > rm /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-npactivex.so > fi > if [ -h /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-roblox.so ] ; then > rm /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-roblox.so > fi > if [ -h /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-shockwave.so ] ; then > rm /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-shockwave.so > fi > if [ -h /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-silverlight4.so ] ; then > rm /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-silverlight4.so > fi > if [ -h /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-silverlight5.0.so ] ; then > rm /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-silverlight5.0.so > fi > if [ -h /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-silverlight5.1.so ] ; then > rm /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-silverlight5.1.so > fi > if [ -h /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-unity3d.so ] ; then > rm /usr/$(get_libdir)/nsbrowser/plugins/libpipelight-unity3d.so > fi >} (In reply to ppn from comment #31) > Created attachment 374380 [details] > Update to 0.2.6 > > It is now possible to use WineG++ to compile the 32 bit version of > pluginloader.exe and no cross compiler is needed any more. That's great news, I was really hoping that would work out. Do you think it's really necessary to support the prebuilt version now? I'd be tempted to drop it. The wineg++ works only for 32bit version and devs plan to bring out 64bit version for some plugins (at least flash and unity). This version doesn't need a prebuilt, but next with 64bit support can be. (Thanks to remove my two previous comments (32-33) ....). Hi, I am part of the Pipelight Team and wanted to say something about the 64 bit support for plugins. This is currently very experimental as almost all plugins hit bugs in Wine when using the 64 bit version and the 32 bit version are much more stable. From my point of view it is therefore perfectly okay to use wineg++ and skip 64 bit plugin support at the moment. @ppn: You can use "pipelight-plugin --disable-all" to remove all symlinks again. There is no need to do this manually. Moreover, is there any reason why you create the symlinks manually, instead of using "pipelight-plugin --enable PLUGIN"? You may need to pass "--accept" to automatically accept the license, though you may want to give the user the possibility to actually read it. I am therefore not sure whether it is a good idea to make the plugin activation a part of the post installation instruction as you also enable the plugins for all users on the system. Michael The latest version of wine testing is 1.7.19-r1 in the main tree, but it's using an outdated compholio patch for wine 1.7.18 when using the pipelight use flag. Hello, if I use wine-1.7.20 with pipelight Use Flag it will not compile.. Error: -I. -I/var/tmp/portage/app-emulation/wine-1.7.20/work/wine-1.7.20/include -I../include \ -I/var/tmp/portage/app-emulation/wine-1.7.20/work/wine-1.7.20/include -D__WINESRC__ x86_64-pc-linux-gnu-gcc -m32 -O2 -pipe -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o wrc dumpres.o genres.o newstruc.o po.o readres.o translation.o utils.o wrc.o writeres.o parser.tab.o parser.yy.o -lgettextpo ../../libs/wpp/libwpp.a ../../libs/wine/libwine_static.a ../../libs/port/libwine_port.a -Wl,-O1 -Wl,--as-needed make[1]: Leaving directory `/var/tmp/portage/app-emulation/wine-1.7.20/work/wine-1.7.20-abi_x86_32.x86/tools/wrc' make[1]: Leaving directory `/var/tmp/portage/app-emulation/wine-1.7.20/work/wine-1.7.20-abi_x86_32.x86/include' * ERROR: app-emulation/wine-1.7.20::gentoo failed (compile phase): with 1.7.19-r1 it ends at: ../tools/widl/widl -o docobjectservice.h /var/tmp/portage/app-emulation/wine-1.7.19-r1/work/wine-1.7.19/include/docobjectservice.idl \ -I. -I/var/tmp/portage/app-emulation/wine-1.7.19-r1/work/wine-1.7.19/include -I../include \ -I/var/tmp/portage/app-emulation/wine-1.7.19-r1/work/wine-1.7.19/include -D__WINESRC__ x86_64-pc-linux-gnu-gcc -m32 -O2 -pipe -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o wrc dumpres.o genres.o newstruc.o po.o readres.o translation.o utils.o wrc.o writeres.o parser.tab.o parser.yy.o -lgettextpo ../../libs/wpp/libwpp.a ../../libs/wine/libwine_static.a ../../libs/port/libwine_port.a -Wl,-O1 -Wl,--as-needed make[1]: Leaving directory `/var/tmp/portage/app-emulation/wine-1.7.19-r1/work/wine-1.7.19-abi_x86_32.x86/tools/wrc' make[1]: Leaving directory `/var/tmp/portage/app-emulation/wine-1.7.19-r1/work/wine-1.7.19-abi_x86_32.x86/include' * ERROR: app-emulation/wine-1.7.19-r1::gentoo failed (compile phase): * emake failed Created attachment 380570 [details]
Update to 0.2.7.1
Have attached an ebuild for Version 0.7.2.1. I can only get it to merge if I do not use the binary downloader, i.e. I have to do:
USE="-binary-pluginloader" emerge pipelight
Anyway, it works with wine-1.7.21 (with USE="pipelight") and firefox-30.0 in my ~amd64 installation.
Created attachment 381512 [details]
pipelight-0.2.7.2.ebuild
Ebuild for Version 0.2.7.2
A preliminary 9999 ebuild has been committed to portage. I will commit a keyworded ebuild after I package the pipelight sandbox. (In reply to Richard Yao from comment #42) > A preliminary 9999 ebuild has been committed to portage. I will commit a > keyworded ebuild after I package the pipelight sandbox. I'm getting this: sed: can't read /usr/bin/pipelight-plugin: No such file or directory * ERROR: www-plugins/pipelight-9999::gentoo failed (install phase): * Generating temporary pipelight-plugin failed * * Call stack: * ebuild.sh, line 93: Called src_install * environment, line 2764: Called die * The specific snippet of code: * sed -e "s:^\(PIPELIGHT_LIBRARY_PATH=\"\)\(.*\):\1${ED}\2:" "${DESTDIR}/usr/bin/pipelight-plugin" > "${T}/pipelight-plugin" || die "Generating temporary pipelight-plugin failed"; I could attach a full log, but everything else looks good in it :P (In reply to Michael Cook from comment #43) > (In reply to Richard Yao from comment #42) > > A preliminary 9999 ebuild has been committed to portage. I will commit a > > keyworded ebuild after I package the pipelight sandbox. > > I'm getting this: > > sed: can't read /usr/bin/pipelight-plugin: No such file or directory > * ERROR: www-plugins/pipelight-9999::gentoo failed (install phase): > * Generating temporary pipelight-plugin failed > * > * Call stack: > * ebuild.sh, line 93: Called src_install > * environment, line 2764: Called die > * The specific snippet of code: > * sed -e "s:^\(PIPELIGHT_LIBRARY_PATH=\"\)\(.*\):\1${ED}\2:" > "${DESTDIR}/usr/bin/pipelight-plugin" > "${T}/pipelight-plugin" || die > "Generating temporary pipelight-plugin failed"; > > I could attach a full log, but everything else looks good in it :P Would you attach `emerge --info sed` and check if the sed binary works on your system? A user in IRC had a failure with the committed 9999 ebuild. sed is used to inject ${ED} into the pipelight-plugin script to work around missing DESTDIR support without restoring to a post install step. Somehow, sed modified the pipelight-plugin script in such a way that lib64 became lib, which broke the build. The following patch to change the sed command, which I am told resolves the issue:
cvs diff: Diffing .
Index: pipelight-9999.ebuild
===================================================================
RCS file: /var/cvsroot/gentoo-x86/www-plugins/pipelight/pipelight-9999.ebuild,v
retrieving revision 1.3
diff -r1.3 pipelight-9999.ebuild
40c40
< sed -e "s:^\(PIPELIGHT_LIBRARY_PATH=\"\)\\(.*\):\1${ED}\2:" \
---
> sed -e "s:^\(PIPELIGHT_LIBRARY_PATH=\"\)\\(.*\):\1${ED}usr/$(get_libdir)/${PN}\":" \
Oddly, I do not see how this issue happened given that the line modified int he original file is `PIPELIGHT_LIBRARY_PATH="/usr/lib64/pipelight"`. I am inclined to think that GCC generated bad code in sed, but I do not have time to dig further. Anyway, explicitly specifying the full path works fine, so I have committed this change. A keyworded ebuild will likely follow in the next 24 hours.
(In reply to Richard Yao from comment #44) > Would you attach `emerge --info sed` and check if the sed binary works on > your system? sed works fine, I think the issue is that ${DESTDIR} isn't defined, which results in trying to edit the installed file. Did you mean ${D}? PLUGIN_PATH also needs to be modified with ${D} added in. Not sure about PIPELIGHT_SHARE_PATH, but it at least runs with no errors without editing it.
Created attachment 382168 [details, diff]
pipelight-9999.diff
(In reply to Richard Yao from comment #45) > Oddly, I do not see how this issue happened given that the line modified int > he original file is `PIPELIGHT_LIBRARY_PATH="/usr/lib64/pipelight"`. I am > inclined to think that GCC generated bad code in sed, but I do not have time > to dig further. Anyway, explicitly specifying the full path works fine, so I > have committed this change. A keyworded ebuild will likely follow in the > next 24 hours. It's a bug in the ebuild seding a previously manually installed copy, I would recommend doing something like the diff I attached. (In reply to Michael Cook from comment #49) > (In reply to Richard Yao from comment #45) > > Oddly, I do not see how this issue happened given that the line modified int > > he original file is `PIPELIGHT_LIBRARY_PATH="/usr/lib64/pipelight"`. I am > > inclined to think that GCC generated bad code in sed, but I do not have time > > to dig further. Anyway, explicitly specifying the full path works fine, so I > > have committed this change. A keyworded ebuild will likely follow in the > > next 24 hours. > > It's a bug in the ebuild seding a previously manually installed copy, I > would recommend doing something like the diff I attached. You are right. My eyes skipped over ${DESTDIR}, which should have been ${ED}. As for editing the other variables, that is not necessary because we are creating a temporary copy of the pipelight-plugin script. Its only purpose is to copy the plugins. That invokes create_mozilla_plugins() in the script, which only uses PIPELIGHT_LIBRARY_PATH. We should get DESTDIR support in the future, which will eliminate the need to use sed here. I'm glad to see this package in portage! I had an issue when I tried to emerge this. I pasted the output from portage below. I used the same ebuild from portage but replaced the ${DESTDIR} with ${ED} which is why this is in an overlay.
sed -e 's|@@BASH@@|/bin/bash|g' -e '1s|/usr/bin/env bash|/bin/bash|' -e 's|@@BINDIR@@|/usr/bin|g' -e 's|@@DATADIR@@|/usr/share|g' -e 's|@@GCC_RUNTIME_DLLS@@||g' -e 's|@@GPG@@|/usr/bin/gpg|g' -e 's|@@LIBDIR@@|/usr/lib64|g' -e 's|@@MANDIR@@|/usr/share/man|g' -e 's|@@MOZ_PLUGIN_PATH@@|/usr/lib64/mozilla/plugins|g' -e 's|@@PIPELIGHT_LIBRARY_PATH@@|/usr/lib64/pipelight|g' -e 's|@@PIPELIGHT_SHARE_PATH@@|/usr/share/pipelight|g' -e 's|@@PREFIX@@|/usr|g' -e 's|@@QUIET_INSTALLATION@@|true|g' -e 's|@@VERSION@@|0.2.7.3|g' -e 's|@@SILVERLIGHT_GPU_ACCEL@@|# overwriteArg = enableGPUAcceleration=false|g' pipelight-plugin.1.in > pipelight-manpage.tmp
touch -r pipelight-plugin.1.in pipelight-manpage.tmp
install -pm 0644 pipelight-manpage.tmp "/tmp/portage/www-plugins/pipelight-9999/image//usr/share/man/man1/pipelight-plugin.1"
rm pipelight-manpage.tmp
realpath: ‘/usr/lib64/mozilla/plugins’: No such file or directory
* ERROR: www-plugins/pipelight-9999::Allen-s-custom-overlay failed (install phase):
* Creating plugins failed
*
* Call stack:
* ebuild.sh, line 93: Called src_install
* environment, line 2743: Called die
* The specific snippet of code:
* "${T}/pipelight-plugin" --create-mozilla-plugins || die "Creating plugins failed"
I should note that after manually creating the missing directorys I was able to emerge this without any issues although I didn't see any of the post install messages that are present in the ebuild.
(In reply to Allen Holl from comment #51) > realpath: ‘/usr/lib64/mozilla/plugins’: No such file or directory Same error with the new ebuild from the gentoo tree. I will set aside time this evening to properly test the ebuild in a fresh chroot. Then I should be able to do a keyworded ebuild of 0.2.7.3 (the most recent tag), so the 9999 ebuild will not be necessary. (In reply to Michael Cook from comment #47) > PLUGIN_PATH also needs to be modified with ${D} added in. Not sure about > PIPELIGHT_SHARE_PATH, but it at least runs with no errors without editing it. Upon further review, it turned out that you were correct. create_mozilla_plugins() calls get_directories(), which uses PLUGIN_PATH. I did not see it at first. This is the issue that Kornel reported. This issue is now fixed. I have also added an einfo notice that users must be in the video group for hardware video acceleration to work. In addition, I have committed www-plugins/pipelight-0.2.7.3 to the main tree. Initially, it is only keyworded on ~amd64 until either I or someone else finds time to test it on ~x86. However, it is expected to work fine on ~x86. I just wanted to report that I tested the pipelight 0.2.7.3 currently in Portage, and it does work on my 32-bit desktop system. So I'd say it's good to have an ~x86 keyword added.
I only had one problem which I don't think is related to Pipelight but maybe should be addressed by the ebuild. I had to move the plugins from /usr/lib/mozilla/plugins to /usr/lib/nsbrowser/plugins because Firefox doesn't find plugins installed to the first location on my desktop system. However, Firefox on my 64-bit laptop has no trouble finding them. I've only found a single bug report from a few years ago from another user who had this same issue on Gentoo, so it may be a rare bug or a configuration issue. In any case, I was under the impression that /usr/${libdir}/nsbrowser/plugins was the default plugin directory on Gentoo anyway. This can be set by passing --moz-plugin-path to Pipelight's configure script.
|
Created attachment 356404 [details] pipelight-9999.ebuild This project was announced a couple of days ago and I suspect someone else will try to create an ebuild soon so I'm jumping in here with what I've got so far. It works but I'd like to make some further improvements. Just a git ebuild for the moment, I'll create a release-based one later.