Bunsen-pepperflash and Opera-type browsers?

stevep · 2017-03-02 00:47:19

"Opera-type" means Chromium derivatives that don't include or auto-download the pepperflash plugin. The version we borrowed for MX Linux (thanks again!) doesn't seem to get it working for Opera, so I added a file from pepperflashplugin-nonfree and a couple of symlinks, and that got it up and running. Is this a problem with pure BL?

johnraff · 2017-03-02 04:48:35

Hi Steve, I hadn't thought about enabling this for Opera to be honest. Is it a Chromium derivative these days?
Chromium can certainly use the flashplugin downloaded by bunsen-pepperflash - a config file is put in /etc/chromium.d/ with this content:

flashso=/usr/lib/bunsen-pepperflash/libpepflashplayer.so
flashversion=$(strings $flashso 2>/dev/null |  sed -n '/LNX/ {s/^LNX //;s/,/./gp}')
CHROMIUM_FLAGS="$CHROMIUM_FLAGS --ppapi-flash-path=$flashso --ppapi-flash-version=$flashversion"

It's similar to what pepperflashplugin-nonfree puts, with the exception of the path to the library.

I've just installed Opera in a VM to test, and in BL it recommends flashplugin-nonfree which provides the NPAPI plugin, which implies our Opera won't use the pepperflash plugin natively. Installed without recommends it finds the freshplayer plugin so uses the library downloaded by bunsen-pepperflash with no further action from the user, if browser-plugin-freshplayer-pepperflash has also been installed. (In fact, if a BL user installed Opera from the menu they'd get flashplugin-nonfree installed too.)

Does MX Linux use a newer, pepperflash-compatible, version of Opera?

Last edited by johnraff (2017-03-02 04:51:34)

geekosupremo · 2017-03-02 20:23:42

johnraff wrote:

Is it [Opera] a Chromium derivative these days?

Yep, Opera joined Google on the Blink train in 2013 - https://en.wikipedia.org/wiki/History_o … eb_browser

Which made me a little sad, I liked that their previous rendering engine was the most standards compliant of the lot. I knew if the code worked there, it was a work around I'd need to do for the other browsers.

That said, I understand why they went to Blink, being a much smaller footprint on the browser world made it hard to push change, since they would rarely be seen as a "major" player.

stevep · 2017-03-02 20:54:18

I deleted the freshplayer NPAPI wrapper for pepperflash, and Opera is still working using pepperflash directly, so it seems to be using the PPAPI plugin interface instead of the NPAPI.

There's a partially fixed pepperflashplugin-nonfree in Sid that only builds a 64-bit package--which seems to be why it's stuck in Sid. That also works to get pepperflash for Opera. Though it's just scripts and is really an arch-independent package, it builds arch-dependent packages because it will only work on the i386 and amd64 platforms, since those are the only binaries Adobe provides, so the architecture is listed as "amd64 i386" to restrict it to those builds. If the distrelease I'm porting it over to only provides those architectures (like MX), we could be safe with changing that to "all" to create an arch-independent version and work around the i386 build failure. (testing the "all" version first on both arches, of course)

Or I (we?) could try and fix it so it would build on i386...maybe looking at the broken version in Jessie could give us a hint on how to do that.

Last edited by stevep (2017-03-02 20:56:59)

johnraff · 2017-03-03 05:36:20

I just had a look at opera on Stretch. The same opera repo url is used as on Jessie, but the package "opera" is not installable on Stretch (missing deps), you need opera-stable (or opera-{beta, developer}).
"opera" is still on version 12, the old engine, and uses NPAPI.
"opera-*" (ver 43~) are using the new chromium-related engine and the PPAPI flash.

bunsen-pepperflash sounds similar to the improved pepperflashplugin-nonfree, ie: "Though it's just scripts and is really an arch-independent package, it builds arch-dependent packages because it will only work on the i386 and amd64 platforms, since those are the only binaries Adobe provides, so the architecture is listed as "amd64 i386" to restrict it to those builds"

What is it that fails to build on i386? Are you working on Jessie or Stretch?

Opera/jessie uses the mozilla plugin path, so picks up freshplayer's PP>NP wrapper out of the box.

Just trying opera-stable in a 64bit Stretch VM, it doesn't pick up the flash library put in by bunsen-pepperflash, but if symlinks are made in /usr/lib/pepperflashplugin-nonfree pointing to libpepflashplayer.so and manifest.json in /usr/lib/bunsen-pepperflash then Opera finds and uses those. I found the config at /usr/lib/x86_64-linux-gnu/opera/resources/pepper_flash_config.json

{
  "PepperFlashPaths" : [
    "/usr/lib/adobe-flashplugin/libpepflashplayer.so",
    "/usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so",
    "/usr/lib/PepperFlash/libpepflashplayer.so",
    "/usr/lib64/PepperFlash/libpepflashplayer.so",
    "/usr/lib/chromium-browser/PepperFlash/libpepflashplayer.so",
    "/usr/lib/chromium/PepperFlash/libpepflashplayer.so",
    "/usr/lib64/chromium-browser/PepperFlash/libpepflashplayer.so",
    "/usr/lib64/chromium/PepperFlash/libpepflashplayer.so",
    "/opt/google/chrome-beta/PepperFlash/libpepflashplayer.so",
    "/opt/google/chrome-unstable/PepperFlash/libpepflashplayer.so",
    "/opt/google/chrome/PepperFlash/libpepflashplayer.so"
  ]
}

So I guess having symlinks in any of those locations should work. (manifest.json does seem to be necessary too.) Maybe it's possible to configure opera to look somewhere else (ie the bunsen-pepperflash dir)?

Last edited by johnraff (2017-03-03 05:39:31)

stevep · 2017-03-03 18:59:10

It seems that opera-stable would also have pepperflash working if Google Chrome is also installed, which explains why some users were saying "it's just working for me", but wasn't for others. But I have Chrome installed, and it still wouldn't work... I added symlinks for the .so and .json files to /usr/lib/pepperflashplugin-nonfree to bunsen-pepperflash the simple way, just put them in a new /debian/links file instead of patching one of your scripts or hacking a debian/postinst script, but no doubt a fix to the bunsen-pepperflash source in github would be better.

I'll check to see if this also fixes Vivaldi--I don't know how many other Blink-based Linux browsers are out there with the issue, though. Slimjet bundles the plugin in its deb file, so no problem with it.

The version of pepperflashplugin-nonfree from Sid has been changed to get the plugin directly from Adobe instead of Chrome, which is what broke the older versions when Google stopped bundling it in the deb file, but it still fails to build from source for i386 when I tried in on a Jessie base. The Sid repo also only has an amd64 package, so I assume it's something in the package and not just me. I'll check it out later.

stevep · 2017-03-03 20:48:28

* Offtopic somewhat: It turns out that fixing the i386 build for the Sid pepperflashplugin-nonfree was very simple; I only had to add i386 back to the Architecture: field in debian/control, but I also removed some now unused cruft left over from the Chrome download process and changed the package description to reflect what's going on for the download process. I made some MX packages, but since it's a script package, they are pretty much universally installable.

https://drive.google.com/open?id=0BxE7w … HIyQ0JTaFE

I also see that Ubuntu has the half-fixed Sid version in their latest releases--64-bit only, of course...I wonder how many questions for 32-bit pepperflash that's generating on their forums?

Last edited by stevep (2017-03-03 20:49:55)

johnraff · 2017-03-04 03:06:58

It sounds as if the new pepperflashplugin-nonfree is doing more-or-less the same as bunsen-pepperflash these days. What we have extra is the built-in systemd daily upgrade check and popup notification, but not everyone would want those of course.

That sounds like a good idea to add a debian/links to make symlinks to the necessary files somewhere where Opera (+ Vivaldi?) can find them. Any of the directories listed in /usr/lib/x86_64-linux-gnu/opera/resources/pepper_flash_config.json should work, but since bunsen-pepperflash already has:
Conflicts: pepperflashplugin-nonfree
Replaces: pepperflashplugin-nonfree
in debian/control, there's no risk of clashing with pepperflashplugin-nonfree so that might be the best location to use.
EDIT: on reflection, it might be better to make the symlinks in the main script, perhaps in a config_opera() function.

I was thinking of upgrading our package anyway, because of the discovery of a json file from Adobe with the version numbers etc., that saves us the need to scrape the web page.
eg things like:

john@bunsen1:~$ arch="x86-32"
john@bunsen1:~$ curl -s "https://get.adobe.com/flashplayer/webservices/json/?platform_type=Linux&platform_arch=${arch}&browser_dist=Chrome" | jq -r '.[0].Version'
24.0.0.186
john@bunsen1:~$ curl -s "https://get.adobe.com/flashplayer/webservices/json/?platform_type=Linux&platform_arch=${arch}&browser_dist=Chrome" | jq -r '.[0].download_url'
http://fpdownload.adobe.com/pub/flashplayer/pdc/24.0.0.186/flash_player_ppapi_linux.x86_64.tar.gz

So the download urls don't have to be hard-coded either. It brings a dependency on jq but it's a small package that we use for conky anyway, and in return we can drop some python deps.

Last edited by johnraff (2017-03-05 06:25:26)

#1 2017-03-02 00:47:19

Bunsen-pepperflash and Opera-type browsers?

#2 2017-03-02 04:48:35

Re: Bunsen-pepperflash and Opera-type browsers?

#3 2017-03-02 20:23:42

Re: Bunsen-pepperflash and Opera-type browsers?

#4 2017-03-02 20:54:18

Re: Bunsen-pepperflash and Opera-type browsers?

#5 2017-03-03 05:36:20

Re: Bunsen-pepperflash and Opera-type browsers?

#6 2017-03-03 18:59:10

Re: Bunsen-pepperflash and Opera-type browsers?

#7 2017-03-03 20:48:28

Re: Bunsen-pepperflash and Opera-type browsers?

#8 2017-03-04 03:06:58

Re: Bunsen-pepperflash and Opera-type browsers?

Board footer