I decided to do an update of my “pipelight” package. I had not looked at it for a long time, basically because I do not use it anymore, but after I upgraded my “wine” package someone asked if I could please write up what could be done for wine-pipelight.
As you know, pipelight is a Linux plugin wrapper for Mozilla-compatible browsers which lets you install and use Windows plugins on Linux. This configuration enables you to access online services which would otherwise be unavailable to you on a Linux platform. The pipelight plugin wrapper uses wine to load the Windows software.
The pipelight developers created a series of patches for Wine which made all of this possible. They called this patch set “wine-compholio” which was later renamed to “wine-staging” and eventually was absorbed into the Wine developer community. Nowadays, wine-staging is the testing ground for Wine – stuff which has not yet been approved for inclusion into the main repository but looks promising.
Together with my “pipelight” package I offered a “wine-pipelight” package which contained a version of wine that had been patched with the “wine-staging” patch set and installed into a non-standard location so that only the pipelight plugin would find it.
Since then, my regular “wine” package has also been enhanced with the wine-staging patch set. In addition, I am applying the d3d9 (wine-nine) patch set which uses the gallium-nine state tracker in Mesa for added performance on some graphics cards.
Therefore a separate “wine-pipelight” package is no longer required. My regular wine package is sufficient.
I have reconfigured and rebuilt my pipelight packages (for Slackware 14.1 and newer) so that you can remove the old “wine-pipelight” package. Pipelight uses my regular wine package now. The “wine-pipelight” packages (for Slackware 14.1 and newer) have been removed from my repository.
That simplifies things a lot. I used to have a warning that you should not try to run programs simultaneously that use the wine and wine-pipelight programs – the two would interfere. That warning has become obsolete now that there is only one version of wine left on your system.
If you want to use someone else’s wine package instead of mine, you need to ensure that that wine package applies the wine-staging patches or else your pipelight will not work!
Good to know: you can always get the latest Windows plugin releases (an important feature in case of security fixes) without having to wait for me creating a new package. Just run the command “pipelight-plugin –update” as root. After doing that, the next time your browser loads the pipelight plugin, it will automatically download the newest version of your installed Windows plugin(s).
This feature depends on the pipelight developers updating their “install-dependency” script, so if they forget or are too busy, the above command will not give you the latest Windows plugin releases unfortunately…
In my original post about pipelight, you will find full installation and configuration instructions, as well as a troubleshooting section. That blog article is also referred to on the pipelight.net support page. Let me remind you that you need to go multilib if you want to use pipelight on 64-bit Slackware.
Packages can be downloaded from these locations:
Have fun! Eric
Eric, this is brilliant. Thank you for the update and for the clear explanation of what needs to be done to continue to use pipelight for that pesky Silverlight (and flash if one really still wants to run flash on Linux)l
Thank you very much!
thanks for your wine update. I’ve never had much luck with wine but this build looks good so far.
One thing I noticed is your wine-gecko build is old. Should we just accept the winecfg offer to download and install it instead?
Pingback: Links 30/7/2016: Sysadmin Day, Stardew Valley on GNU/Linux | Techrights
Just wanted to say thanks for this!
you dedicate more time and love to slackware than patric. im sure if you would be the owner of slackware we would enjoying slackware 15 with plasma 5 in release version right now.
Was curious if your 64bit wine can be installed alongside 32bit wine, or if they conflict. I’ve had success with the 32bit version, but have a 64bit program I want to try.
You install only one of the two. On a 64bit Slackware with multilib you should install (only) the package from my 64bit repository, it will give you support for 64bit as well as 32bit Windows programs.
By the way, it never hurts to remind again that the wine package requires OpenAL. And on 64bit Slackware not just the regular 64bit package but additionally the converted “compat32” version of the OpenAL package.
This is what you would do for Slackware 14.2:
This is interesting: Firefox 49 is going to support the widevine plugin.
Yes, even earlier Firefox versions already support this but you have to enable it at built-time with “–enable-eme=adobe,widevine” for DRM support. Then you might have to tweak a couple of things to make Netflix work like UA spoofing (Netflix will not consider Firefox for Linux a supported platform yet, not unlike the early Netflix-on-chromium days).
But yes, version 49 should support this properly. And… you’ll get Widevine support for your 32bit Firefox browser too, whereas Google stopped releasing 32bit widevine updates some time ago (because they stopped releasing a 32bit Chrome).