My thoughts on Slackware, life and everything

Month: June 2012 (Page 1 of 3)

VLC 2.0.2

Another (bugfix) release of the VLC media player is ready. The time between this release and the previous 2.0.1 was longer than usual, due to a recent fall-out between several of the core developers. For a while, it looked like the VideoLAN project’s existence was doomed when their most important Linux developer quit the team out of frustration. However he re-joined, and the dust has settled again.

The VideoLAN web site still does not have an official blurb about the 2.0.2 release, two days after making it available, so I decided to mention it on my blog without waiting any further.

For this vlc-2.0.2 package, I also updated several of the internal libraries (ffmpeg, x264, lame, bluray and upnp). Note that the BluRay support in VLC (at least in my package) works only for unencrypted disks. Unencrypted BluRay disks are pretty rare birds. Playback of encrypted BluRay DVD’s requires that you also install my libaacs package: http://slackware.com/~alien/slackbuilds/libaacs or http://taper.alienbase.nl/mirrors/people/alien/slackbuilds/libaacs/) and find yourself a set of AACS decryption keys (see these comments for some hints on that).

This is where you’ll find the new VLC packages:

Rsync acccess is offered by the mirror server: rsync://taper.alienbase.nl/mirrors/people/alien/restricted_slackbuilds/vlc/ .

My usual warning about patents: versions that can not only DEcode but also ENcode mp3 and aac audio can be found in my alternative repository where I keep the packages containing code that might violate stupid US software patents.

Have fun! Eric

Note 01-jul-2012: The release notes for vlc-2.0.2 have been published on the VideoLAN web site.

Getting closer: KDE 4.9 Release Candidate 1

Today, the KDE team officially announced the first release candidate for KDE Software Compilation 4.9. That is less than a day after the source tarballs were posted on the private area where packagers have access. The new KDE release manager is giving “us packagers” a hard time – it was probably done as a penalty for the fact that several of the “big distros” were releasing packages long before the KDE team officially announced them. This was seen by the KDE release team as abusing a privileged position. After all, the sources are released in advance so that packages can be ready when a new release is announced… but those packages should stay under wraps as long as the release team has not given a go-ahead. The discussions on the (private) kde-packager and releaseteam mailing lists were not always friendly.

But. of course compiling the KDE packages is trivial using the modular KDE.SlackBuild script, and I have the packages ready for you – compiled for Slackware-current. The upgrade from Slackware’s KDE 4.8.4 to the 4.9-rc1 release (the version number is 4.8.95) should be trivial. There are three updated dependencies (akonadi, soprano and shared-desktop-ontologies). The new akonadi is a requiremnt for RC1. The RC1 packages also fix the incompatibilities with Slackware-current’s new attica and python packages (the previous Beta2 packages needed some tweaking to work with the latest slackware-current).

Like with the previous betas, I did not bother with anything from “extragear”. Pat Volkerding updated many of those when he added KDE 4.8.4 to Slackware-current. Speaking of 4.8.4 – that is the version which will ship with Slackware 14 unless KDE releases an unplanned bugfix 4.8.5. DO NOT expect KDE 4.9 in the next Slackware. We have a winner with 4.8.4 and we do not want to risk introducing new bugs with a 4.9 zero release when we are basically cleaning up the loose ends in slackware-current.

Enough chatter, back to reality now. While you good folk are waiting for your KDE download, I will continue my fight with VLC dependencies in another Virtual Machine… those are currently giving me headaches, and VLC 2..0.2 has been tagged so I expect an official source tarball any moment.

Get my KDE packages in any of the following locations (the master repository at alien.slackbook.org is severely restricted in bandwidth so using a mirror is always advised):

The accompanying README file contains detailed installation/upgrade instructions.

As you may have noticed when inspecting the above URLs, I have re-arranged my “ktown” repository. People were confused about what version would work with Slackware -current and what would work for 13.37. Also, some people have asked for sources of older releases for which I no longer host the packages.

I moved all the sources out of the package trees, you will now find a “source” directory right at the top level of the repository. Below that will be the sources of all package sets which I currently have in my repository (KDE 4.6.5, 4.7.4, 4.8.4 and 4.8.95, including all the dependencies you may want for compiling it on Slackware 13.37). The packages will be available below a toplevel directory equal to the Slackware version they were compiled for (at the moment those are “13.37” and “current“). Below that you will find the actual KDE versions and further down, the 32-bit and 64-bit packages.

Have fun! Eric

New multilib packages for slackware-current

 Earlier today, there was a massive update to Slackware-current. The ride was fun, and I am fairly certain we’ll see some breakage. In fact, we found some already and fixed that in a quick update (mounting of Samba shares was broken after splitting the mount utility for Samba shares into its own “cifs-utils” package).

So, what was updated? The highlights of this batch are:

  • the version of the next release is known: it will be “Slackware 14”.
  • kernel is now 3.2.21 – we will likely stick with the 3.2 series since that will get long-term support.
  • KDE moved up to 4.8.4 (meaning that I can remove my own packages for that version from my ktown repository).
  • gcc was bumped to 4.7.1 to accompany the new kernel.
  • glibc was patched to fix a regression
  • python got updated to 2.7.3 (the switch from the old 2.6.x version meant that every package needed to be recompiled which depends on python)
  • the network scripts (rc.inet1) got support for setting up betwork bridges – something I use every day because it allows me to make my Virtual Machines accessible from other computers in my LAN.
  • lots of other individual updates (the complete ChangeLog.txt entry of “Mon Jun 25 05:17:48 UTC 2012” measures more than 300 lines)

And since glibc was rebuilt and gcc updated, I needed to create multilib versions of those.

They can be found here (all of the mirrors below also offer rsync access):

 NOTE:

The update to attica-0.4.0 in slackware-current broke many packages of my KDE 4.9-beta2 set. Head over to my other blog post to find out how to fix that easily!

Have fun! Eric

Update 5 for OpenJDK 7 available

OpenJDK 7u5

Quite by accident I noticed that a newer version of Oracle’s Java 7 SE was available on my son’s Windows computer. I checked my Linux sources and indeed I was running behind.

Soon after icedtea 2.2 there has been a new release: 2.2.1. This version of the “icedtea build framework” creates binaries for update 5 to the Java 7 platform. The resulting OpenJDK binaries will have additional patches compared to the original OpenJDK sources. Using icedtea is also the only way to get a Java web browser plugin: icedtea-web (Oracle did not release the source code of their browser Java plugin under an open license). Icedtea-web requires an “icedtea build” of OpenJDK (or OpenJRE if you only require a Java Runtime).

The new package for OpenJDK identifies itself as “7u5_b21-icedtea” which is at the same level as Oracle’s official binaries..

Note: you will have noticed that Slackware has not seen an update to the Oracle Java packages for a long time. This is the result of a new license policy by Oracle (who currently “owns” Java), whereby it is no longer allowed to re-distribute the official Oracle binaries of the JDK and JRE. These new license terms were added after large parts of Oracle’s Java code had been open-sourced as “OpenJDK”. You can update your Java using my native (i.e. compiled on Slackware) packages, or download Oracle’s official binaries yourself (which is allowed by their license). In that case, you can adapt Slackware’s “jdk.SlackBuild” build script to wrap those binaries into a Slackware package. The choice is yours!

Note: you will see two packages on my download server: a JRE (java runtime engine) and a JDK (java development kit) package. You should only install one of those! The JRE is sufficient if you just want to run Java based applications. You need the JDK if you want to be able to compile Java code. Also, do not use “upgradepkg” when upgrading from Oracle’s binaries to my own OpenJDK package or vice versa. Nor should you use “upgradepkg” when switching from a JRE to a JDK or vice versa. This will mess with the symbolic links used by the packages. Instead, use “removepkg” to get rid of the installed version and “installpkg” to get the new package.

You can test the installed packages here for instance:

Upgrade to my OpenJDK package now! In that case, you’ll need rhino too (the JavaScript engine for OpenJDK). If you want the mozilla compatible browser plugin, get icedtea-web.

Please consider using one of the mirrors. When we got the slackware.com web server up and running again, we applied a download cap to the core team’s pages which will slow down your retrievals. For instance, you could use my mirror taper.alienbase.nl or else one of the other mirrors like slackware.org.uk or alien.slackbook.org.

Have fun! Eric

 

Blog updated to 3.4, sqlite database fixed

I just upgraded my blog to WordPress 3.4.

My blog’s database backend is not MySQL but instead (for portability reasons) I am using PDO for WordPress, a plugin which uses PDO (a PHP data access abstraction layer) to allow the use a sqlite database; i.e. a simple file.

Unfortunately this sqlite backend is not 100% compatible with WordPress installations starting with version 3.3. You can not even create a new blog using the PDO plugin with WordPress 3.3 and higher. The blog has to be created using wordpress-2.2.x, and then upgraded to 3.3 or later.

It looks like the maintainer of the PDO plugin will not be able to give adequate support for the sqlite backend. Not because he does not want to, but because it is difficult to create the proper glue between WordPress SQL code and generic SQL backends (WordPress developers have stated that they are not interested in supporting anything else than MySQL).

The problems with the PDO plugin show when creating a new post… the blog will be “dead” for at least five minutes and the apache log full of SQL errors. I am considering to  move “back” to a supported backend and wanted to check if I could export the full blog so that I could import it to a fresh installation with a MySQL backend.

I quickly discovered that this was not possible. Somewhere along the line, WordPress has added a new table to the database (wp_commentmeta) and the PDO plugin apparently has not been able to add that to my sqlite database. An attempt to export the blog to an XML file (one of the standard tools in WordPress) would lead to a lot of errors in the apache log about “Problem preparing the PDO SQL Statement.  Error was no such table: wp_commentmeta“.

I compared my blog’s sqlite database to a fresh MySQL-backed blog database and thus found the new table’s properties. I upgraded the database on the fly using the sqlite3 command-line program as follows:

$ sqlite MyBlog.sqlite > CREATE TABLE wp_commentmeta (
 meta_id integer NOT NULL PRIMARY KEY AUTO_INCREMENT,
 comment_id integer NOT NULL DEFAULT '0',
 meta_key text DEFAULT NULL,
 meta_value text); > .quit

After that modification, exporting the blog to XML took only seconds to create a 4.3 MB file instead of the previous 400 KB partial dump which took painstakingly long. I still have not tried to import that XML dump into an empty blog. Also, this new post will be a test to see how the blog recovers… will it still take many minutes before it is available again after I press “Publish”?

Eric

« Older posts

© 2024 Alien Pastures

Theme by Anders NorenUp ↑