My thoughts on Slackware, life and everything

Category: Uncategorized (Page 5 of 5)

OpenJDK replacing Oracle’s binaries

I already wrote about it in an earlier post, that I was working on packages for OpenJDK. OpenJDK is an open-source implementation of the Java Platform, Standard Edition. In 2007, Sun delivered to its earlier promise to make Java open source and released the bulk of its code under a GPL license. Since then, high-profile companies like IBM and Apple have done major contributions to the OpenJDK codebase in order to create an industrial-strength alternative to the binary releases of Java SE..

Oracle assimilated Sun in 2010 and obtained the rights to Java SE.

For Linux distros, not much changed because binary releases of the JDK and JRE were still made available for re-distribution. In 2011 however, Oracle decided that new binary releases of its Java SE (the runtime or JRE as well as the SDK) may no longer be included with Linux distros. They retired the “Operating System Distributor License for Java” (DLJ) and decided that distros should compile their own packages using the Open Source codebase of OpenJDK,.which Oracle itself uses as well for their binary builds.

Of course, you as an “individual user of Java SE” still have the legal right to download and use Oracle’s binaries – you’re just not allowed to re-distribute it. Making a Slackware package out of your Oracle-downloaded binaries is simple – use the jdk.SlackBuild or jre.SlackBuild scripts which are part of Slackware and “wrap” those binaries into a convenient package.

While this is a nice solution for the individual, our own Slackware had to stop updating its Java packages. It now has to solve the question of keeping or removing Java from its distribution. Since Oracle’s binaries can no longer be included, Slackware has to follow the advice and build its own Java from source.

This situation now lasts since august 2011 and it is bothering me. So, in November 2011 I made a promise to Pat Volkerding that I would create a set of Slackware packages for the OpenJDK. Unfortunately that took me longer than expected because a lack of time and because (as outlined in my previous post) I wanted to build them in such a way that I could use the SlackBuild scripts on ARMedslack which still lacks a Java package.

I uploaded the results of my efforts last week but Pat has not responded since, so I am making the packages and sources/scriptes available to a wider audience. Please note that I named the resulting packages “openjdk” and “openjre” but the packages that could get included into Slackware eventually may be named differently (like “openjdk-jdk” and “openjdk-jre”). In any case, I invite you to test them and report your findings.

You can get all of it here: http://connie.slackware.com/~alien/openjdk/ with a mirror here: http://alien.slackbook.org/slackware/openjdk/

For ready-made packages (for Slackware-current !) you can check the two directories “pkg64” (containing 64bit versions) and “pkg” (for the 32bit version of Slackware).  If you want to install my pre-built packages, then all you really need are “rhino” which is the JavaScript engine, “icedtea-web” which is the browser plugin, and one of “openjdk” or “openjre” packages, depending of course on whether you need the full Java compiler suite or only the Java Runtime Environment.

You will also find packages for apache-ant, xalan and xerces.  These are only needed if you want to re-compile OpenJDK yourself. If you want to build your own packages instead of using (or after installing) mine, then follow the instructions in the sources/README.txt file. If you are not running Slackware-current but one of the stable releases, then compiling from source will be your only option.

For you wannabe-compilers, I will repeat part of that README text here. OpenJDK will not compile successfully on Slackware unless you make some modifications to the gcc and seamonkey packages. You can either recompile those using the modified SlackBuild scripts and sources which I also provided in the openjdk sources tree, but you can also choose the less intrusive alternative by running (as root !) two small shell scripts that add the missing functionality to your system: create_gcj_jvm.sh and fix_seamonkey_pkgconfig.sh. These two scripts should work on every Slackware release.

After running the two shell scripts (or after rebuilding gcc and seamonkey) you are ready to (build and) install apache-ant, xalan, xerces and rhino, logout and log back in again to set the ANT_HOME environment variable, and proceed with building OpenJDK and icedtea-web. Good luck!

Any questions or feedback about these scripts and packages? Please post them here and I will follow up.

Cheers, Eric

Huge update to slackware-current and what it meant to my laptop

Today, you may be watching the slackware-current ChangeLog.txt slack-faced, with a feeling of horror…

… because the update is HUGE. There are well over 300 lines of updates! That amounts to one-third of the full length of ChangeLog for the current development cycle. Those of you who thought Slackware was calmly drifting toward another stable release, will have to brace themselves for a round of fun and thorough testing.

I think the most obvious intrusive change is that Slackware-current moved to using the “new” X.Org which no longer depends on HAL for hardware detection and initialization. Instead, the new X.Org talks directly to udev.

Robby Workman has put a lot of work in assembling a coherent set of X.Org sources as well as getting this stuff tested widely before it got added to Slackware (see http://www.linuxquestions.org/questions/slackware-14/call-for-testing-xorg-updates-20100830-a-829336/).

There is also a newer GTK+2 (version 2.22). The new GTK proves to be a difficult bugger with apparent incompatibilities with previous releases. We have to see what the extent of these incompatibilities is; for instance I came across software does not compile anymore and needs patching or updating (gtk-chtheme).

When upgrading your slackware-current please note that several packages have been added, and others have been removed! If you are using slackpkg to do the upgrades for you, you can use the command “slackpkg clean-system” to remove the deprecated (mostly X.Org related) packages. In the package overview that presents itself, make sure to first deselect those you installed yourself before hitting the “OK” button! Likewise, running “slackpkg install-new” will install the newly added packages for you.

What were the bumps when I upgraded my Lenovo T400 laptop?

Well, several… but they were easy to fix.

X.Org configuration of the hardware:

Since the new X.Org no longer uses HAL, my old method of configuring the TrackPoint in a file “/etc/hal/fdi/policy/11-x11-trackpoint.fdi” no longer works. Instead, the new X.Org uses a configuration directory “/etc/X11/xorg.conf.d/” where you can add configuration files for your hardware. You’ll see the similarities; my old HAL file looks like this:

<match key="info.product" string_outof="TPPS/2 IBM TrackPoint;PS/2 Generic Mouse">
 <merge key="input.x11_options.EmulateWheel" type="string">true</merge>
 <merge key="input.x11_options.EmulateWheelButton" type="string">2</merge>
 <merge key="input.x11_options.YAxisMapping" type="string">4 5</merge>
 <merge key="input.x11_options.XAxisMapping" type="string">6 7</merge>
 <merge key="input.x11_options.Emulate3Buttons" type="string">true</merge>
 <merge key="input.x11_options.EmulateWheelTimeout" type="string">200</merge>
</match>

While the new way of configuring requires a file (I aptly named it “/etc/X11/xorg.conf.d/20-thinkpad.conf” but any name that ends on “conf” will do) in which I wrote:

Section "InputClass"
Identifier    "Trackpoint Wheel Emulation"
MatchProduct    "TPPS/2 IBM TrackPoint|DualPoint Stick|Synaptics Inc. Composite TouchPad / TrackPoint|ThinkPad USB Keyboard with TrackPoint|USB Trackpoint pointing device|Composite TouchPad / TrackPoint"
MatchDevicePath    "/dev/input/event*"
Option        "EmulateWheel"        "true"
Option        "EmulateWheelButton"    "2"
Option        "EmulateWheelTimeout"    "200"
Option        "XAxisMapping"        "6 7"
Option        "YAxisMapping"        "4 5"
Option        "Emulate3Buttons"    "true"
EndSection

You will have perform a similar exercise if you previously had configured a non-US keyboard in a HAL “fdi” file. I will leave it up to you to figure out how to repeat this for the new X.Org.

Hardware accelerated graphics:

Actually, this is where the updated packages shine! The combination of mesa, Intel graphics and KDE 4.5 proved to be quite disastrous a month ago when the kernel was updated in slackware-current. My KDE 4.5 packages froze the computer solid, the very moment when “desktop effects” (compositing) was enabled. This graphics hard lock is not caused by X.Org. Rather, it is the kernel’s DRI (direct rendering interface) and the way mesa interacts with it where all the trouble started. However,the real cause was not apparent at first (and some people were pointing at the open source graphics drivers). I had reported about this problem before – my Asus Eeepc 1000H which has an Intel graphics chip started having these compositing problems after the upgrade of the slackware-current kernel to 2.6.35.7 (i.e. before the upgrade of X.Org or mesa). As long as you were not using compositing in KDE 4.5, you would not see this problem at all.
The issue has been addressed in mesa (the library used by X.Org to enable software and hardware accelerated graphics). Slackware’s mesa was updated to 7.9 today and KDE’s compositing desktop is working now! My T400 with Intel graphics is happy again, as will be my EeePC after I upgrade that!

VLC and fullscreen video:

I had not expected this one, and I have not been able to find out what caused it. When resizing the VLC window, the dimensions of the embedded video would not grow beyond the actual pixel size of the video stream (i.e. there was no video scaling). I tried downgrading to an earlier version of VLC, I tried running XFCE instead of KDE, but the problem remained painfully visible as a big black border surrounding a tiny video. In the end, I ruthlessly removed the VLC configuration directories “~/.local/share/vlc/” and “~/.config/vlc/”. That helped! But it left behind a feeling of dissatisfaction.

xz (liblzma.so.0):

The xz package (used as the compression tool for the .txz package format) was updated too. The new dynamic library has another version number. I first noticed that I must have forgotten something when KDE refused to start after I finished upgrading. Several applications were spitting out errors about a missing “liblzma.so.0” library. This old library file was added to the “aaa_elflibs” package for compatibility reasons (along with a version of libtalloc.so), but this package is blacklisted in the “slackpkg” program so  “aaa_elflibs” was not getting upgraded. Usually (upgrading between two stable releases) this is the correct approach, because aaa_elflibs should contain redundant libraries. However, right after an update to this package you should run “upgradepkg” on it. I did that, and KDE started up normally again.

And thus starts a period of new play-testing, folks. Have fun, and give us good feedback!

Eric

Section “InputClass”
Identifier      “Trackpoint Wheel Emulation”
MatchProduct    “TPPS/2 IBM TrackPoint|DualPoint Stick|Synaptics Inc. Composite TouchPad / TrackPoint|ThinkPad USB Keyboard with TrackPoint|USB Trackpoint pointing device|Composite TouchPad / TrackPoint”
MatchDevicePath “/dev/input/event*”
Option          “EmulateWheel”          “true”
Option          “EmulateWheelButton”    “2”
Option          “EmulateWheelTimeout”   “200”
Option          “XAxisMapping”          “6 7”
Option          “YAxisMapping”          “4 5”
Option          “Emulate3Buttons”       “true”
EndSection

Newer posts »

© 2024 Alien Pastures

Theme by Anders NorenUp ↑