Main menu:

Sponsoring

Please consider a small donation:

 

 

Or you can donate bitcoin:

 

Thanks to TekLinks in Birmingham, AL, for providing colocation and bandwidth.

Page Rank

Fame

FOSS Force Best Blog--2013 Award

Recent posts

Recent comments

About this blog

I am Eric Hameleers, and this is where I think out loud.
More about me.

Search

My Favourites

Slackware

Calendar

March 2015
M T W T F S S
« Feb    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages

Meta

Using git while working on KDE 5

Even though I caught a bad cold (luckily, it was not the flu as I feared at first) I managed to do a lot of prepping for new KDE 5 packages (Frameworks, Plasma, Applications) since last week.

The way I tackled KDE updates in the past, was to update the sources, check the continued need of patches used for prior releases, and then start compiling and checking the build logs for errors – and responding to errors with fixes to the scripts, new patches or even new or updated dependencies. The core of the KDE.SlackBuild framework would remain largely unchanged, and it never took lots of going back and forth to recompile packages and get rid of errors or missing dependencies. KDE 4 has always been very easy to update (well, easy – experience helps a lot, plus the fact that I wrote the KDE.SlackBuild framework and know its ins and outs).

Working with the first test release of KDE 5, last summer, was a bit of a challenge, but I took it like I did with every change to a new release cycle of KDE 4 (4.11 -> 4.12 etc…): finding all available documentation on the available sources, their inter-dependencies as well as their other needs, and reading the comments and patch proposals on the KDE packagers mailing list. Going from KDE 4 to 5 was a heck of a lot more work than I initially anticipated (the hardest part was figuring out the tiering concept of the Frameworks, and of course there was a lot of cursing at the immaturity of the Plasma sources) but I considered that first release for Slackware as nothing more than a play-test. The preview packages were designed not to mess up your existing KDE 4 configuration, and easily un-installable. For me the important thing with this proof of concept was to convince myself that the updates to the KDE.SlackBuild framework were sound and I understood and was able to respond to the new reality of fragmented release cycles.

This last week, I have been targeting a more serious outcome. The upcoming KDE 5 packages for Slackware which I will be releasing sometime later this month, are meant to replace your good old KDE 4 installment, and therefore I need to deliver something that you can work with on a daily basis – a full set of applications in a functional Desktop Environment.

For that reason, I decided to call upon git to guide me through the process of making changes to the build framework. I needed to be able to reproduce my previous build environments in order to back-track after encountering errors or dead ends, and take a fork from there and try again. Putting the whole KDE.SlackBuild tree in a git repository was something I did in advance – see my previous post on KDE 5 – and since then, I have been pushing my changes to the repository continuously.

Definitely, this has saved me from finding myself in a dead end. What sometimes happened was that some application would compile into a package one time, and fail to compile the next iteration. Usually the cause would be an update of a dependency, the introduction of a patch to another package and more of that vague stuff. My git updates enabled me to inspect all updates I had done since a previous compilation attempt, and revert or adapt some of the changes I had made. In some other cases, the changes I could track graphically in the ktown cgit web interface showed cause and effect with more ease than back in the time when I would keep multiple directory trees of past attempts. A time saver!

I am currently compiling the last couple of packages that are part of the Applications. If they succeed, it means that the KDE.SlackBuild is ready and I have a full set of packages. If you ask whether they produce a wonderful Desktop Environment… I do not know yet :-) That will be the next step: when all packages are conceptually OK, I will fire up an X session in the virtual machine and see if the stuff I compiled works at all. If I get into a functional KDE 5 environment, that will be cause for celebration. But I expect that I will have issues in the VM (with sddm and/or kwin). If I see failure, I will try installing the packages on a real computer and see how it fares there.

I won’t release any packages until I am fully satisfied, but feel free to tinker with the KDE.SlackBuild in advance.

Eric

Monthly Flash Player security updates

Pepper Flash for Chromium:

chromium_iconChrome was updated because of a Flash security bulletin from Adobe. The new Slackware package for chromium-pepperflash-plugin has version 16.0.0.257.

 

 

Linux Flash for Mozilla-compatibles:

adobe_flash_8s600x600_2 The “legacy” Linux NPAPI plugin for Mozilla-compatible browsers was updated as well – never leaving version 11. My Slackware package for the flashplayer-plugin went “up” to 11.2.202.429 (micro version update).

 

 

Windows Flash for Mozilla-compatibles provided by Pipelight:

pipelight-logoFor my pipelight package, you can easily update the Windows plugins it installed for you earlier (including the Windows Flash player if you use that) by running (as root) the script:

# pipelight-plugin --update

A new package is not required therefore.

Eric

Terror does not kill freedom

jesuischarlie

Bear with me – I need to make this statement.

The terror attack on a  french satirical magazine, killing 10 of its cartoonists and journalists, is an attack on Freedom of Speech. Only morons are afraid of words and images. Who in his right mind kills journalists unless he is afraid of the truth?

Wars are fought to gain power, for money, for religion. But religious wars are also just a fight for power. The Crusaders in the Western past, and the Jihadists in the Eastern present, there is no difference. Totally convinced of their own beliefs, the beliefs of other people must be repressed at any cost. What else is this but madness?

Terror goes beyond war. Warring factions are both defending their beliefs, however twisted their beliefs are. Terror on the other hand is waged on innocent people. It is meant to put fear in the hearts of the citizen with a long-term goal of establishing some form or repressive regime – even in democratic countries, repression can be achieved. People can be herded like sheep if you keep the truth from them. In Western (Christian) civilization, it was the period of Enlightenment that rid us of the repression of religion. In some islamic countries, this step still needs to be made. The Crusaders are no more (despite the statements of islamic fanatics) – and now Muslims need to raise their voice and fight these people who justify their actions by calling upon Allah but are in fact without faith. Terror does not need a God.

What is the best weapon against terror and false beliefs? The truth! You can live in freedom only if you have access to the truth, and are able to fight falsehoods with proof to the contrary. Do not let yourself be scared away by terror. The terrorist has already lost if you stand up for your freedom and for the truth.

Eric

Thinking about working on KDE 5 again (frameworks, plasma, applications)

qt-kde-620x350During these final days of my relatively long Christmas holiday, I have started looking at the KDE 5 build scripts again. KDE 4 has seen its final release sometime ago, and Patrick shows no signs of updating the KDE in slackware-current, so in order to bring some fresh excitement to KDE users on Slackware, I am pondering an update of the “testing” repository aka the KDE5 repository.

In December, the KDE community released the first tarballs of the “Applications” which is the first step to completion of the new KDE 5 desktop. Remember: the Frameworks 5 came first (a set of modular libraries that expand the functionality of Qt5), Plasma 5 builds a desktop workspace on top of the Frameworks, so that had to come next, and finally there are the Applications which are now ported from the KDE 4 Development Platform to Frameworks 5 slowly.

In particular that recent release of Applications 14.12 (the notation used here is YY.mm) gave me some headaches. Most of these applications are familiar from KDE 4, and only a few are now ready for the Plasma 5 desktop workspace (Kate and KWrite, Konsole, Gwenview, KAlgebra, Kanagram, KHangman, Kig, Parley, KApptemplate and Okteta). It is impossible for me to separate the KDE 5 applications from the KDE 4 applications. Their names have not changed, and whereas I needed to rename a few packages in Frameworks and Plasma in order to prevent a clash with package names in the KDE 4 set, I do not want to do the same for the Applications. After all, when running Plasma 5 you do not want to see both KDE 4 and Plasma 5 versions of the Konsole application in your desktop menu – just the Plasma 5 version. Also, compiling these “Applications 14.12″ will cause a lot of KDE 4 packages to be overwritten – for example, marble-4.14.3 with marble-14.12.0 et cetera. That is a one-way road. I can not think of a clean method of separating the old and the new.

In my “preview” of KDE 5, I was able to offer the KDE 5 packages as co-installable to KDE 4 because it was not yet more than Frameworks and Plasma packages – it needed the presence of KDE 4.x in order to provide a meaningfull Plasma 5 workspace. That meant, you could install KDE 5, play around with it for a bit, and then un-install the packages if you had seen enough, without this process touching or destroying the configuration of your KDE 4 environment. That was a good thing, because Plasma 5 was quite unstable at that time, and the whole exercise was not meant to probide an actual day-to-day work environment.

We are now 5 months further in time, and the current state of Frameworks/Plasma 5 combined with the new set of Application releases, should provide a stable platform that is slowly migrating from KDE 4 to 5.

That is why I decided to not stretch my luck and try another co-installable version of KDE 5 but instead go all the way and provide a full upgrade from KDE 4.14.3 to Frameworks/Plasma/Applications. It will take a while because of all the unknowns, but I think I have done most of the preparations now (gathering all the sources, updating the build scripts). It will be a matter of compiling, fixing failures and retracing issues to their resolution.

I think I will also provide scripts for an easy roll-back from the new KDE 5 packages to either the default Slackware packages or else my KDE 4.14.3 packages.

Note that this is going to be relevant and beneficial only to people who are running Slackware-current (our development version) so if you are going to want to try this later on, you need to know what you are up to. Once you will upgrade from KDE 4 to my new KDE 5 packages, it may not be trivial (i.e. without cleaning out your ~/.kde and ~/.local directories) to downgrade at a later point in time.

End transmission.

Eric

Watch Netflix video in your chromium browser – this time for real

chromium_icon

I have made change to my Chromium package which some of you will find interesting. As you might know (I wrote about it in an earlier article here on Alien Pastures) Google and Netflix combined their efforts and that resulted in native support in Chrome for the playback of Netflix videos, using the Widevine Content Decryption Module (CDM) which is incidentally also owned by Google. This was all made possible using the Encrypted Media Extensions (EME) in a HTML5 player. Unfortunately, I was not able to find a way to add this Widevine CDM support to my Chromium package – using a similar approach to the way I add support for Flash using the binary libraries taken from the official Chrome RPM.

Then my Slackware buddy ppr:kut pointed me to a discussion in the Chromium bugtracker on Google Code where someone stated he had found the solution. The description was a bit vague, no patches were posted, but the general concept was clear.

I proceeded with updating my SlackBuild for chromium-dev (which is currently at version 41.0.2236.0) and re-writing my not-working widevine patch. That resulted in a new chromium-dev package which reported that a Widevine plugin was available. Alas… when opening a Netflix page and attempting to play a video, this only resulted in the error “M7363-1262-00000000″ which seems to have a relation to a mismatch between the Widevine CDM library and the browser. A possible explanation could be that I used the Widevine CDM library from stable Chrome 39.0.2171.95 in that build of the chromium development version 41.

So, my next attempt was to rebuild the stable chromium package (39.0.2171.95) with the Widevine patch, using the Widevine CDM library from the Chrome RPM bearing that same version. And what do you know… success!

I can now watch Netflix video’s in my Slackware chromium browser. How nice is that.

Apparently, having a functional Widevine CDM support will allow you to watch Youtube Movies as well, but since I already pay for Netflix I did not want to test these Youtube rentals. Another test which failed was my attempt to watch television on horizon.tv, the content streaming network of my provider (UPC/Liberty Global). Even with a UserAgent spoofer and all browser cookies removed, that site still detected that I was visiting using a Chrome/Chromium browser and kept presenting an annoying popup to force me to switch to a different browser because Chrome does not support Silverlight anymore (on Mac OSX and Windows 64-bit at least, remember their NPAPI depreciation). No way around that, even though I was fairly sure that Horizon TV also used Widevine for Digital Rights Management (DRM) in the past. Guess I still have to use Firefox with Pipelight for that, then.

What do you need in order to watch Netflix in Chromium on Slackware (14.1 and -current)?

  • Just two packages are needed: chromium and chromium-widevine-plugin. The latest chromium package was rebuilt to enbable support for Widevine. The chromium package itself does not contain any proprietary binaries. The chromium-widevine-plugin package is what contains the “libwidevinecdm.so” library which was extracted from the official binary Chrome RPM – this is proprietary software.
  • It is not necessary to use a UserAgent spoofer. Netflix works out of the box.
  • Make sure your mozilla-nss package has at least version 3.16.4 (Pat Volkerding upgraded all mozilla-nss packages in recent Slackware releases for this reason)
  • In Netflix Playback-settings chose HTML5

Note 1:

No more changes are needed to the file “/etc/default/chromium”. The plugin is announced to chromium by means of the “libwidevinecdmadapter.so” library which is built from the Open Source code in the chromium tarball, but only in the presence of the proprietary “libwidevinecdm.so”. Installing or upgrading the chromium-widevine-plugin package will show a few lines of warning if it detects that you still have the old configuration block enclosed by “START chromium-widevine-plugin” and “END chromium-widevine-plugin“. You should delete that block now.

Note 2:

If you don’t care about Netflix or don’t want to install any non-free software, then the chromium package is still OK for you – just don’t install chromium-widevine-plugin and you’ll be fine. If you even want to get rid of any hint of Widevine support you can always recompile the package with the variable “USE_CDM” inside the chromium.SlackBuild set to zero (0). That will prevent the creation of the (open source) adapter library “libwidevinecdmadapter.so”.

Have fun! Eric