Bug 5321

 - No %{?dist} tag?


Package approved, please add the dist tag before import.


Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed


Issues:
=======
- Dist tag is present.


===== MUST items =====

C/C++:
[x]: Development (unversioned) .so files in -devel subpackage, if present.
     Note: Unversioned so-files in private %_libdir subdirectory (see
     attachment). Verify they are not in ld path.

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "Unknown or generated". 3 files have unknown license. Detailed
     output of licensecheck in /home/bob/packaging/review/widevine-
     cdm/review-widevine-cdm/licensecheck.txt
[x]: License file installed when any subpackage combination is installed.
[-]: Package requires other packages for directories it uses.
     Note: No known owner of /usr/lib64/firefox/defaults,
     /usr/lib64/firefox/defaults/pref
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[-]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %license.
[x]: Package does not own files or directories owned by other packages.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 0 bytes in 0 files.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[-]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[-]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in
     chromium-widevine , mozilla-widevine
[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Scriptlets must be sane, if used.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: SourceX is a working URL.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: widevine-cdm-1.4.9.1088-1.x86_64.rpm
          chromium-widevine-1.4.9.1088-1.x86_64.rpm
          mozilla-widevine-1.4.9.1088-1.x86_64.rpm
          widevine-cdm-1.4.9.1088-1.src.rpm
widevine-cdm.x86_64: W: invalid-license Widevine
widevine-cdm.x86_64: W: no-documentation
chromium-widevine.x86_64: W: invalid-license Widevine
chromium-widevine.x86_64: W: no-documentation
mozilla-widevine.x86_64: W: invalid-license Widevine
mozilla-widevine.x86_64: W: only-non-binary-in-usr-lib
mozilla-widevine.x86_64: W: no-documentation
mozilla-widevine.x86_64: W: non-conffile-in-etc /etc/profile.d/widevinecdm.sh
mozilla-widevine.x86_64: W: dangling-symlink /usr/lib64/mozilla/plugins/gmp-widevinecdm/system-installed/LICENSE.txt /usr/lib64/widevine-cdm/LICENSE.txt
mozilla-widevine.x86_64: W: dangling-symlink /usr/lib64/mozilla/plugins/gmp-widevinecdm/system-installed/manifest.json /usr/lib64/widevine-cdm/manifest.json
widevine-cdm.src: W: invalid-license Widevine
4 packages and 0 specfiles checked; 0 errors, 11 warnings.

@Rathann Need some changes here. Can you please add a chromium-vaapi-widevine subpackage which will install the cdm library to %{_lib}/chromium-vaapi folder and will require chromium-vaapi package?

FYI, QtWebEngine looks for this in one of the following locations:
https://code.qt.io/cgit/qt/qtwebengine.git/tree/src/core/content_client_qt.cpp?id=31730085ee9247864a5da5682939eb399853f984#n298

As you can see, /usr/lib64/chromium-browser as used by your package is missing, unfortunately.

Alternatively, the plugin can be installed specifically for QtWebEngine into %{_libdir}/qt5/plugins/webengine/ (see webenginePluginsPath() in the linked file). Though that directory is not currently owned by any RPM as far as I can tell.

* You are probably missing the following to avoid stripping on binary only content:
%global        __strip /bin/true


* Is there a way to avoid having a sub-package for every project that might use the  plugin ? Or do we want an explicit request from end-user to enable the plugin for a given browser ?

From a end-user perspective, when I have firefox and widevine-cdm, then I would expect that the plugin register automatically. (without adding yet another package). It's the same expectation with flash plugins.
It could be done using %triggerin -- firefox

Another way would be to have the plugin provided in _libdir/chromium-plugins and have the related chromium based project adapted to search for plugins using this path ?


* Is there any support for others architectures ? 
At least there are consumers devices with chrome-os on armhfp and probably aarch64. If it's the case, then maybe it will be possible to have them all provided from the same spec file if the version will be the same. 
An alternative is probably to have a widevine-cdm-%{_arch}.spec that will provide windevine-cdm packages for the related architectures.

* I would indeed prefer to have a dist tag. Even if it's only about the default rpm feature that a fedora version might have (and to denote that the package will be signed by a different key also)

@Rober-André
Don't forget to change the status to assigned. Thx for the review.

@Rathann
Thx for the package submission.

(In reply to Kevin Kofler from comment #3)
> FYI, QtWebEngine looks for this in one of the following locations:
> https://code.qt.io/cgit/qt/qtwebengine.git/tree/src/core/content_client_qt.
> cpp?id=31730085ee9247864a5da5682939eb399853f984#n298
> 
> As you can see, /usr/lib64/chromium-browser as used by your package is
> missing, unfortunately.

I can see /usr/lib/chromium and /usr/lib64/chromium there, so adding a symlink
%{_libdir}/chromium/libwidevinecdm.so => %{_libdir}/widevine-cdm/libwidevinecdm.so should just work, correct?

Is anything else capable of consuming the plugin from that path?

> Alternatively, the plugin can be installed specifically for QtWebEngine into
> %{_libdir}/qt5/plugins/webengine/ (see webenginePluginsPath() in the linked
> file). Though that directory is not currently owned by any RPM as far as I
> can tell.

I have no problem with this solution as well. My package would own that path.

(In reply to Akarshan Biswas from comment #2)
> @Rathann Need some changes here. Can you please add a
> chromium-vaapi-widevine subpackage which will install the cdm library to
> %{_lib}/chromium-vaapi folder and will require chromium-vaapi package?

Sure, it looks like it works if I put the files (.so and .json) directly in that folder, though VAAPI accel doesn't work for me for some reason. I'll open a separate bug for that.

(In reply to Nicolas Chauvet from comment #4)
> * You are probably missing the following to avoid stripping on binary only
> content:
> %global        __strip /bin/true

Why? Does it stop working for you if you let rpmbuild strip the binary? It works for me with standard stripping.

> * Is there a way to avoid having a sub-package for every project that might
> use the  plugin ? Or do we want an explicit request from end-user to enable
> the plugin for a given browser ?

Personally I prefer to have a choice and enable this only in selected browser(s) instead of everywhere unconditionally (provided you have a given browser installed), but I'm not opposed to other solutions.

> From a end-user perspective, when I have firefox and widevine-cdm, then I
> would expect that the plugin register automatically. (without adding yet
> another package). It's the same expectation with flash plugins.

Existing weak dependencies solve this already, I think. I agree that subpackage proliferation is not ideal. If you/anyone else has a proposal to make everything work with one package, I'm all ears.

> It could be done using %triggerin -- firefox

You may be thinking about Chromium.. The Firefox plugin doesn't need any scripts, it just drops files in the right place. The only browser that needs scripts (due to alternatives usage) is Chromium and the subpackage for Chromium doesn't contain anything apart from the scriptlets.

Or am I mistaken and you're suggesting to create files/symlinks via triggers?

> Another way would be to have the plugin provided in _libdir/chromium-plugins
> and have the related chromium based project adapted to search for plugins
> using this path ?

I don't care much about Chromium ecosystem. I use it only for stuff that doesn't work in Firefox. If anyone wants to pursue this path, I'm open to co-maintainers/patches.

> * Is there any support for others architectures ? 
> At least there are consumers devices with chrome-os on armhfp and probably
> aarch64. If it's the case, then maybe it will be possible to have them all
> provided from the same spec file if the version will be the same. 
> An alternative is probably to have a widevine-cdm-%{_arch}.spec that will
> provide windevine-cdm packages for the related architectures.

Only x86 (32 and 64-bit) blobs are provided (based on https://hg.mozilla.org/mozilla-central/file/tip/toolkit/content/gmp-sources/widevinecdm.json). I'll include both in the next revision. If you have the URLs for other arches, I'll include them as well, but I was unable to find others.

> * I would indeed prefer to have a dist tag. Even if it's only about the
> default rpm feature that a fedora version might have (and to denote that the
> package will be signed by a different key also)

Ok.

(In reply to Dominik 'Rathann' Mierzejewski from comment #7)
> (In reply to Nicolas Chauvet from comment #4)
> > * You are probably missing the following to avoid stripping on binary only
> > content:
> > %global        __strip /bin/true
> 
> Why? Does it stop working for you if you let rpmbuild strip the binary? It
> works for me with standard stripping.
Does it works in mock ? (or koji scratch build ?)
I expect it won't (because of BuildID is not present)

But BuildID only exhibit the problem, when dealing with proprietary software, there is some expectation that the binary are "untouched". But stripping still occurs if you only disable debuginfo sub-package.(that may modify few binaries) You need to both disable stripping and debuginfo generation while dealing with proprietary software. This is a packaging "meme".

I don't care that much about i686 as we already moving to deprecate i686 userspace and no i686 browsers are copied into x86_64 repository anymore.

For el7/el8 it won't be relevant at least and for fedora < 31 it can be done eventually.
So it can be done if you want, but I won't spend much time on this.
(I only had armhfp/aarch64 in mind, but it could be done on a separate package if relevant).

About the sub-packaging vs triggerin I think the former is more elegant
If one really want to disable "widevine auto-installation" it could be done by a file dropped into _libdir/chomium-browser/.no_widevine-cmd (%ghost from this package) and bypass the alternative registration.

I think the packaging should do the right thing by default and not let end-user system in "in-between" state.

... the former is ... I meant the latter.

(In reply to Dominik 'Rathann' Mierzejewski from comment #6)
> (In reply to Akarshan Biswas from comment #2)
> > @Rathann Need some changes here. Can you please add a
> > chromium-vaapi-widevine subpackage which will install the cdm library to
> > %{_lib}/chromium-vaapi folder and will require chromium-vaapi package?
> 
> Sure, it looks like it works if I put the files (.so and .json) directly in
> that folder, though VAAPI accel doesn't work for me for some reason. I'll
> open a separate bug for that.

Sure.

Spec URL: https://www.greysector.net/~rathann/review/widevine-cdm/widevine-cdm.spec

* Tue Aug 06 2019 Dominik Mierzejewski <rpm@greysector.net> - 4.10.1440.19-1
- update to 4.10.1440.19
- add qtwebengine support
- add chromium-vaapi support
- simplify chromium support (alternatives dropped)
- disable stripping
- add dist tag

I'm not posting the src.rpm with the "source" included because I/we don't have permission to redistribute. I asked Google for that again. Maybe I'll get a different answer this time.

I think I addressed all the comments so far.

I've tested it with chromium-vaapi and it works. But for some reason it doesn't work with chromium (even with chromium-libs-media-freeworld).

In bothes cases the plugin doesn't appears in chrome://components

Tested using this URL: https://bitmovin.com/demos/drm
Which show detected chrome with widevine. (removing the package again make the DRM feature to disappear).


I'm not fan of splitting sub-packages into small pieces. It usually leads to documentation issue and isn't appropriate for non-specialist.( aka not end-users friendly).
I would find it better if it would ends in a fedy hook to install widevine drm for netflix and all.


Without a formal hack from "upstream" and with obvious precedent of having the plugin already redistributed publicly, I would be inclined in allowing that with the nonfree tainted repo. (And to full-fill inter-operability as allowed from European law ).
See (15) https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32009L0024&from=EN#d1e40-16-1

I think subpackages shipping package-managed files are a much cleaner solution than tools like fedy dropping unpackaged files directly onto the file system (into /usr). Nothing other than RPM should be writing to /usr.

That said, without permission to redistribute, it looks like we are stuck with ugly hacks such as lpf. I don't think the interoperability provision extends to redistributing copyrighted decoding software without the copyright holder's permission. By that argument, it would be legal to redistribute any proprietary software operating on a proprietary file format. The interoperability exception is only intended to apply to the DMCA-like parts of the EUCD, i.e., to the copyright on the data being decoded, not on the decoding software.

My understanding (as a non-lawyer!) is: Developing a reverse-engineered Widevine decoder (as libdvdcss did for DVD CSS) MIGHT fall under the interoperability exception (but I am not aware of any such implementation), but shipping copies of Widevine itself probably doesn't.

(In reply to Kevin Kofler from comment #14)
> I think subpackages shipping package-managed files are a much cleaner
I criticize sub-packages compared to having a single package registering everything in %posttriggerin 
But in the current shape, the Requires/Supplements looks sub-optimal compared to booleans dependencies. Requires: (widevine-cdm-chromium if chromium).
As if widevine-cdm is installed the supplements might occurs only on chromium update. (to be tested).

Also you totally miss the point with fedy for some reason.
But I'm not going to extend in this thread.

lpf is acceptable if one want to go that route. But I'm not confident that lpf will install the appropriate sub-packages (it will install them all).

Now I can't let end-users without a solution.

I don't think lpf worth the effort compared to having the content sanely provided into a repository.

So I don't mean to have the package provided in the rpmfusion-nonfree section like any regular package where we have determined a clear redistribution status. But having it in nonfree tainted is appropriate to the best of my knowledge.

(In reply to Nicolas Chauvet from comment #16)
> (In reply to Kevin Kofler from comment #14)
> > I think subpackages shipping package-managed files are a much cleaner
> I criticize sub-packages compared to having a single package registering
> everything in %posttriggerin 
> But in the current shape, the Requires/Supplements looks sub-optimal
> compared to booleans dependencies. Requires: (widevine-cdm-chromium if
> chromium).
> As if widevine-cdm is installed the supplements might occurs only on
> chromium update. (to be tested).

Alright. This package contains only small drop-in files in addition to the main binary, nothing needs to be registered at install time. Let's switch to a single package that "just works" for all supported browsers, then:

https://www.greysector.net/~rathann/review/widevine-cdm/widevine-cdm.spec

* Tue Sep 03 2019 Dominik Mierzejewski <rpm@greysector.net> - 4.10.1440.19-2
- switch to a single package

I would have expected the symlink to be ghosted and created on posttrigerin 
(or even better, the plugin put in _libdir/chromium-plugins and every others packages searching for this path).

I prefer avoiding scriptlets if possible, triggers included. What is wrong with my latest approach?

(In reply to Dominik 'Rathann' Mierzejewski from comment #20)
> I prefer avoiding scriptlets if possible, triggers included. What is wrong
> with my latest approach?

Everything is wrong, I would say.
- You end up having plugins installed for components that are not (necessarily)
chromium-vaapi might not be installed while you will install it's plugin anyway.
- You need to implement a new directory/symlink implementation every now and then once a new chromium implementation comes to birth.
- Suggest is totally spurious. RPM doesn't know if end-users explicitly want widevine-cdm. That's not because you have firefox or chromium that you will want it. Looking for RPM "suggestions" is not something that many users are expected to do.
This specially with a component that

That's why I also prefer the fedy workflow over a worklow where RPM suggestion would install license controversial components in the end-users back! (one one or another repository is enabled, sure. But still without an explicit ACK from end-user).

(In reply to Nicolas Chauvet from comment #21)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #20)
> > I prefer avoiding scriptlets if possible, triggers included. What is wrong
> > with my latest approach?
> 
> Everything is wrong, I would say.
> - You end up having plugins installed for components that are not
> (necessarily)
> chromium-vaapi might not be installed while you will install it's plugin
> anyway.

There's just one plugin binary. The links or drop-in files enable the plugin for supported browsers. Why is that bad? You said it yourself in comment #4:
> From a end-user perspective, when I have firefox and widevine-cdm, then I
> would expect that the plugin register automatically. (without adding yet
> another package). It's the same expectation with flash plugins.

I've implemented your expectation and now you're objecting to it? I don't understand.

> - You need to implement a new directory/symlink implementation every now and
> then once a new chromium implementation comes to birth.

So?

> - Suggest is totally spurious. RPM doesn't know if end-users explicitly want
> widevine-cdm. That's not because you have firefox or chromium that you will
> want it. Looking for RPM "suggestions" is not something that many users are
> expected to do.

It's Supplements: not Suggests:. Why would anyone have to look for RPM suggestions here? I don't quite understand what you mean. I can drop the weak dependencies, no problem.

> This specially with a component that

... I think you wanted to write something more here.

> That's why I also prefer the fedy workflow over a worklow where RPM
> suggestion would install license controversial components in the end-users
> back! (one one or another repository is enabled, sure. But still without an
> explicit ACK from end-user).

I think dropping the weak dependencies would solve what you call "behing users back" installation.

Anything else?

> I've implemented your expectation and now you're objecting to it? I don't understand.

I've suggested two methods to avoid the previous issues:
- Install the plugin into _libdir/chromium-plugins
- Use posttriggerin to register the symlink upon each chromium variant (until the variant can support the _libdir/chromium-plugins search path)

If you don't want to implement posttriggerin, then the current way works. But it would be better to have a standard system path for chromium plugins.

This patch will make chromium look for widevine library from the defined paths other than the path where chromium(vaapi) is installed. I need to edit it to load from _libdir/chromium-plugins instead of google chrome installation directory.

https://paste.fedoraproject.org/paste/0jUo4SB~gWDTDWzI32L1qA

(In reply to Akarshan Biswas from comment #24)
> This patch will make chromium look for widevine library from the defined
> paths other than the path where chromium(vaapi) is installed. I need to edit
> it to load from _libdir/chromium-plugins instead of google chrome
> installation directory.
> 
> https://paste.fedoraproject.org/paste/0jUo4SB~gWDTDWzI32L1qA

Can you attach the patch in this bug report ?


Is there any improvement on this ? If we don't enforce a full redistribution can we at least go with lpf package ?

There is a new widevine-cmd in google, but this version cannot downloaded from 
the previous location, last version that can be downloaded is:

#widevine_version=4.10.1610.0
widevine_version=4.10.1582.1
curl -LO https://redirector.gvt1.com/edgedl/widevine-cdm/${widevine_version}-linux-x64.zip
unzip ${widevine_version}-linux-x64.zip -d /usr/lib64/chromium-plugins/WidevineCdm

About the plugin directory.
So far using /usr/lib64/chromium-plugins doesn't work. Not even /usr/lib64/widevine-cdm (which worked with chromium-vaapi-77.0.3865.120-1.fc29)

The only method that works is by copying /opt/google/chrome/WidevineCdm/ into /usr/lib64/chromium-freeworld
That's because the 4.10.1610.0 (released in 9/12/2019 according to timestamp) is not downloadable from gvt1.com


So the questions are:
- Is it possible to consider for chromium-freeworld (and others) to add a symlink in %post if google-chrome-stable is available ?
- Does it worth to maintain a common chromium plugin directory into /usr/lib64/chromium-plugins (to be owned by the related chromium packages) ?
- Is this review still relevant ?

My bad, f29 used to have a symlink to widevine-cdm from the chromium-freeworld directory, but that doesn't work anymore either.

(In reply to Nicolas Chauvet from comment #26)
> There is a new widevine-cdm in google, but this version cannot downloaded
> from the previous location, last version that can be downloaded is:
>
> #widevine_version=4.10.1610.0
> widevine_version=4.10.1582.1
> curl -LO
> https://redirector.gvt1.com/edgedl/widevine-cdm/${widevine_version}-linux-
> x64.zip
> unzip ${widevine_version}-linux-x64.zip -d
> /usr/lib64/chromium-plugins/WidevineCdm

Not sure what you mean. I replaced the version field in my latest spec and spectool -g worked just fine.

> About the plugin directory.
> So far using /usr/lib64/chromium-plugins doesn't work. Not even
> /usr/lib64/widevine-cdm (which worked with
> chromium-vaapi-77.0.3865.120-1.fc29)
> 
> The only method that works is by copying /opt/google/chrome/WidevineCdm/
> into /usr/lib64/chromium-freeworld
> That's because the 4.10.1610.0 (released in 9/12/2019 according to
> timestamp) is not downloadable from gvt1.com

They changed paths. I'll post an updated spec soon. I was able to get (Fedora) Chromium to show me the 4.10.1582.2 version in chrome://components/ .

> So the questions are:
> - Is it possible to consider for chromium-freeworld (and others) to add a
> symlink in %post if google-chrome-stable is available ?

Why?

> - Does it worth to maintain a common chromium plugin directory into
> /usr/lib64/chromium-plugins (to be owned by the related chromium packages) ?

Not sure it's worth the effort, but if all Chromium flavours use one directory, it'll simplify the spec file a bit. Symlinks work just fine though.

> - Is this review still relevant ?

I may convert this to an lpf-* package if there's enough interest.

OK, I got it to work.

https://demo.castlabs.com/ works in Firefox but not in Chromium. I think it does detection based on User-Agent: string and tries to load Silverlight plugin instead.
https://shaka-player-demo.appspot.com/demo/ works for me in Chromium and Firefox.

I haven't tested the other Chromium flavours or any qt5-webengine browsers.

https://gitlab.com/greysector/widevine-cdm/raw/master/widevine-cdm.spec

* Fri Jan 17 2020 Dominik Mierzejewski <rpm@greysector.net> - 4.10.1582.2-1
- update to 4.10.1582.2
- use correct paths for current chromium flavours
- sort file list alphabetically

(In reply to Dominik 'Rathann' Mierzejewski from comment #29)
> OK, I got it to work.
FYI, I've contacted upstream and I've received confirmation that we cannot redistribute the package as such, so a lpf package is the way to go.

There's another issue: Firefox and Chromium support different versions of widevine. Firefox is usually somewhat behind, though the older Firefox-compatible version still work in Chromium.

If someone wants to convert my work to an lpf package, go ahead. I'm not interested in maintaining an lpf package at this time.

As I'm aware, firefox maintains it's owns grabber for widevine-cdm and download the code into the end-user profile.

I wish it would be possible to use a lpf package to create a fedy plugin, but without someone to volunteer, it should be possible to do the same for chromium (and to avoid a system-wide directory).

I do not think that software in Fedora should be automatically downloading non-free plugins the way Firefox currently does. And at least QtWebEngine currently has no upstream support for doing that. (It will pick up the plugin if it is installed to one of the directories in its hardcoded list, but it will not download it for you.)

(In reply to Kevin Kofler from comment #33)
> I do not think that software in Fedora should be automatically downloading

Then can you describe how end-users should grab widevine-cdm on chromium when they want to use DRM restricted contents ? (assuming they don't know what widevine is in the first step).

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