I have been working on some changes for the chromium package, and what’s better than to first test those changes on a Chromium Development release?
I have not really been happy with the choice I made to have a single configuration file (/etc/default/chromium) which would then have to be re-written by any plugins that you would install. For instance, the PepperFlash plugin modifies that file so that Chromium learns of the pathname and version of that plugin when it starts. Unfortunately, some people would accidentally wipe those modifications with every update to the Chromium main package (the “/etc/default/chromium.new” file would overwrite the “/etc/default/chromium” file if you were not paying attention).
So what I did was change the single configuration file into a configuration directory, which is “/etc/chromium-dev/” for the Chromium Dev package. Each package (Chromium as well as any plugin or extension) can add its own configuration file to that directory. As an example of how that works, I have created packages for chromium-dev, chromium-dev-pepperflash-plugin and chromium-dev-widevine-plugin that use this new setup. Those are Slackware packages for -current only by the way – when a new version of Chromium Stable is released I will also add this new configuration setup and then the packages will be released for Slackware 14.1 as well.
What else is there to say about my chromium-dev packages? Chromium-dev is the development release of the browser (there’s also a “beta” channel but I don’t care about that too much). Testing the development release from time to time is preparing me well in advance for major (or subtle) changes in the compilation process and functionality, so that when the stable channel jumps to a higher major release it won’t take me long to come up with a set of packages.
The new chromium-dev packages have the version number 44.0.2398.0. So what changed with this new major release 44 compared to the previous 43 (or even the stable 42)? One important change is that it is no longer necessary to extract the Widevine CDM library from an official Google Chrome RPM in order to compile the Open Source Widevine adapter library which is the piece of code that interfaces between the browser and the closed-source Content Decryption Module. Therefore even the Open Source purists should be at peace now with the new process. If you do want to use Widevine CDM, for instance when you want to stream Netflix in your Chromium browser, you simply install my widevine-plugin package (the version it reports will be 1.4.8.823). The browser itself will not be tainted.
The PepperFlash plugin package which I added as well (first time for my Chromium Dev releases) has a change as well, compared to the package for Chromium Stable. The PepperFlash directory is installed to “/usr/lib64/chromium-dev/” instead of “/usr/lib64/” (it’s “lib” for 32bit Slackware of course) so that the pepperflash-plugin package’s files will not clash with the pepperflash-plugin for Chromium Stable. The plugin for Chromium Dev reports itself as version 18.0.0.114 by the way. This version is not even listed yet on Adobe’s Flash test page. I assume that this too, is a development version.
Get my Chromium Development packages in one of the usual locations:
Change the URL a bit to get the widevine-plugin and pepperflash-plugin packages.
Eric
The recent hack of the “Hacking Team” -a company that makes money from creating spyware for repressive governments – has uncovered evidence that they have been exploiting a yet unknown security hole which is present in all Adobe Flash players since version 7. Obviously based on the information obtained from the public dump of Hacking Team’s 400 GB Intranet data, there’s a Zero-Day exploit out there in the wild that is actively targeting computers (thanks mancha for the link). Adobe have released patched Flash player plugins today that fix this security hole and you are all urgently advised to update your flash player packages.
Recent comments