Thanks for the heads-up.

I took a quick preliminary look at this:

- The Adobe download simply consists of a tarball with the binary, no installation instructions.

- Looks like Chromium on Linux still requires explicit command line parameters to load this kind of external pepper-flash. Our chromium startup script currently does that but it only checks for Chrome flash location, so not enough for an independent package which would install at a different location.

- There is a provision for system-provided pepperflash in Chromium code so that it would be loaded automatically from a specific path, but the pepperflash path is not set on Linux (#ifdef), with the following comment:
// TODO(wfh): If Adobe release PPAPI binaries for Linux, add support here.
( https://chromium.googlesource.com/chromium/src/+/master/chrome/common/chrome_paths.cc#293 )

CC: (none) => anssi.hannula

Rosa may help with this, they have had an independent Pepper Flash install process for some time. I notified them too, What I think you should do, is let Rosa decide how to proceed first then just port their scripts.

I'm not all that interested in what Rosa does with it, as I'm not impressed with their existing Pepper Flash installer.

Anssi, if the Adobe download just gives you a binary, could our package just ensure that it gets put in the appropriate location?  It will need to be, not only for Chromium to see it, but also for freshplayerplugin for Firefox to see it.

If we can get that working, I think that it should just require freshplayerplugin and replace our existing flash-player-plugin package.

I see no reason for it to replace flash-player-plugin.

I see no reason for it not to.  The current one is old and doesn't work on an increasing number of sites.  The Pepper one provides the same functionality via freshplayerplugin and then works on two browsers instead of one.  I certainly see no reason to package both when we can just have the newer one.

FreshPlayerPlugin has occasional bugs that can cause High CPU Utilizations or Browser Crashes.

I don't doubt that, but honestly, I've experienced less issues with freshplayerplugin at work than I have with flash-player-plugin at home.  My only concern is when Firefox drops support for all NPAPI plugins except for Flash next year, will freshplayerplugin still work?

*** Bug 19182 has been marked as a duplicate of this bug. ***

CC: (none) => mageia

Created attachment 8365 [details]
script to download pepperflash

CC: (none) => ghibomgx

Probably the quickest way is to clone the current flash-player-plugin SPEC file and rename to "flash-player-ppapi-plugin", and readapt (I think it doesn't need the same Conflicts|Provides as flash-player-plugin) so both can coexists and don't get overridden each other. In the meanwhile for those impatient I attach a simple and ugly script to generate the package locally using "alien".

Note that also ubuntu had something similar to Rosa, there was a package called "browser-plugin-freshplayer-pepperflash" that downloads current google-chrome-stable and extract and builds pepperflash from there on the fly, more or less.

BTW, I noticed also that the slow behaviour (almost hang) of freshplayer with pepperflash happens remotely (tried current freshplayer 0.36-0.20160824 git snapshot), i.e. e.g. you run a flash page trough firefox which has been launched in a remote ssh (even on a quick LAN, so 100Mbit or 1Gbit). Simple test here: https://www.adobe.com/software/flash/about/.

I don't think it makes any sense to package both.  It offers us nothing we don't already have really (as it's not hard to just install Chrome from upstream) and it just buys us the headache of having to update and test *two* Flashes every time it needs an update.

So, you may have heard that Adobe is going to update the Flash plugin again:
https://blogs.adobe.com/flashplayer/2016/08/beta-news-flash-player-npapi-for-linux.html

So, the PPAPI Pepper Flash will still have more functionality, so I still think that it would make more sense for now to change our flash-player-plugin package to package that one and Recommend freshplayerplugin.  I think this makes even *more* sense now, because now that the NPAPI Flash Plugin will be updated, even if when Firefox removes support for all plugins except Flash, if this breaks freshplayerplugin, we can just go back to packaging the NPAPI one (and if that happens, I suppose at *that* point it might make sense to package both, but for now it does not).

*** Bug 13118 has been marked as a duplicate of this bug. ***

CC: (none) => ozkyster

They say they are. However Rosa just packaged an update to the 11.2 NPAPI Plugin that fixes more stuff.

Assigning this package request to all packagers collectively. On a voluntary basis, one of them might want to integrate it to the distribution and maintain it for bug and security fixes.

You might also want to join the packager team to maintain this piece of software: see https://wiki.mageia.org/en/Becoming_a_Mageia_Packager

Assignee: bugsquad => pkg-bugs

Created attachment 8532 [details]
script to download and package pepperflash

script to download an repackage pepperflash to be used with freshplayerplugin or chromium. Use linux32 to create the i586.rpm over the x86_64 platform.

Attachment 8365 is obsolete: 0 => 1

This takes on a higher sense of urgency now.  In Chrome 54, Google silently dropped Pepper Flash:
https://bugs.chromium.org/p/chromium/issues/detail?id=645687

So now, users relying on the google-chrome-stable package to provide Flash for any of their browsers are screwed.  We should update our flash-player-plugin package to provide pepper flash, and soon.

CC: (none) => luigiwalser

(In reply to David Walser from comment #18)
> We should update our
> flash-player-plugin package to provide pepper flash, and soon.

If we decide to build the two in the same SRPM (which might make sense), please ensure to split them into separate binary RPMs. I'm interested in having the PPAPI one but I don't want the NPAPI plugin installed and polluting my Firefox :)

Indeed.  I don't think we need the NPAPI one anymore.

here is my experience, and to resume:

- PPAPI 23.x plugin bundled with freshplayerplugin package wrapper: works locally on a firefox with also freshplayerplugin 0.3.x package installed. Doesn't work remotely (i.e. when firefox is ran trough ssh for instance, haven't tried under NX). The best dir to place the pepper library is /opt/google/chrome/PepperFlash/libpepflashplayer.so, in that way is also recognized by chromium and chrome without any further addition.

A minor glitch exists, and is that if you upgrade freshplayerplugin package without upgrading the ppapi plugin or viceversa just upgrade the ppapi plugin package without the freshplayerplygin, firefox could have difficult in recognizing the change and still thinks to deal with the old version. A trick (that however not always works 100%) is to upgrade the timestamp of both (by just running:

   touch /usr/{lib,lib64}/mozilla/plugins/libfreshwrapper-flashplayer.so
   touch /opt//opt/google/chrome/PepperFlash/libpepflashplayer.so

but in this way would alter the RPM's MD5 (in the timestamp) of the package. Alternatively it can be cleaned $HOME/.mozilla (losing the configuration) or create a new firefox profile. Also dealing with $HOME/.mozilla/firefox/<random>.default/pluginreg.dat might be used as workaround in case of problems about plugin (re)detection.
  
- NPAPI 11.x plugin with flash-player-plugin package. Works with firefox directly. Of course is OLD and mayny sites don't recognize it anymore when asking for a flash player and requires newer one. This package is not only a way for circumventing the license or repackaging restrictions by downloading and repackaging on the fly, but it's also a wrapper that, according to the package SPEC docs, "creates a wrapper plugin that loads both the real Flash Player and the wrapper libhal.so.1", so I guess it creates a further layer between the plugin and the browser (browser which should have already its own sandbox layer for the plugins). Works also when the browser is ran remotely trough SSH.

- NPAPI 23.x native plugin. This has been recently available trough beta Adobe site, but natively under firefox it's actually a lot more unstable than the PPAPI 23.x plugin wrapped into freshplayerplugin. This package is not available in the distro.

When both the plugins (i.e. 23.x PPAPI+freshplayer and 11.x NPAPI native) are installed, firefox recognizes both the versions, and apparently would allow the user to choose which one to active, trough the menu "Tools/Addons/Plugins". Indeed this works only apparently as at the next restarting, firefox chooses always one of them according to its own criteria that appears almost random, despite of the user saved or preferred choice.

Apparently using package flash-player-ppapi-plugin-23.0.0.205-2.x86_64.rpm (you can generate this package with the script provided above using at least alien-8.95-4.mga6, and changing the REL at the top of the file to REL=23.0.0.205) and freshplayerplugin-0.3.6-1.mga6, would work also remotely (ssh) on firefox now. You can try installing the YT Flash Player plugin so to use Flash Player instead of HTML5 for YT videos.

Ok, I found the source of the inconsistency behaviour (work or doesn't?) in using the pepper flash wrapper remotely trough SSH: if you ran firefox remotely and play some flash video, it works but ONLY if the remote machine has also logged in an X11 session with the same username: the video output will go on the machine you ran the ssh, but the "audio" output will be emitted trough loudspeakers of the remote machine (that's the weirdness), and the playback is smootly. If you logout the remote machine from its local X11 session (apparently such session is not tied to the remote SSH one) and you do the playback trough the first SSH connection, such playback won't work and the video just hangs (it won't crash or anything, just stalls or wait), and thus seems that the pepper flash wrapper is not working.

(In reply to David Walser from comment #20)
> Indeed.  I don't think we need the NPAPI one anymore.

No we don't we could port this script,it download adobe binary and copy it to google-chrome location automatically even check which arch is used x86 or x86_64.

https://gist.github.com/ruario/215c365facfe8d3c5071

Today's flash-player-plugin package update (cauldron freeze push sent to ml) includes the PPAPI version of Flash Player and the freshplayerplugin wrapper (and not the Adobe NPAPI Flash version).

Please report any issues.

The PPAPI version is installed in /usr/lib(64)/flash-plugin (the same as upstream Adobe RPMs from adobe.com), but the last point in comment #1 is still valid so Chromium does not find it automatically. So the /usr/bin/chromium-browser shell script still needs to be updated to point there.

Just three considerations:

- whenever upgrade the flash-player-plugin package you need also to touch the datestamp of the wrapper freshplayerplugin, otherwise the browser wont' detect the upgrade, so remember to upgrade both package, even if the freshplayer hadn't any code change.

- when used remotely e.g. trough ssh the freshplayer doesn't not crash anymore, but slows down the browser so much that it almost hangs. That's the only side-effect I'm aware of.

- please instead of fixing the chromium-browser, add a softlink of the ppapi, to /opt/google/chrome/PepperFlash/libpepflashplayer.so and /opt/google/chrome/PepperFlash/manifest.json. In this way both chromium (as well as upstream chrome) will detect them correctly without any change.

Giuseppe, I believe the touch the timestamp issue has been fixed.  Do we have any remaining issues or can we close this?

(In reply to David Walser from comment #27)
> Giuseppe, I believe the touch the timestamp issue has been fixed.  Do we
> have any remaining issues or can we close this?

No reply and Mageia 5 is no longer supported, so closing as OLD

Please reopen if needed, and change the Version: of this bug report :-)

Status: NEW => RESOLVED
CC: (none) => marja11
Resolution: (none) => OLD