Alien Pastures

My thoughts on Slackware, life and everything

Month: January 2012

KDE 4.8.0 arrives

January 25, 2012 / / 97 Comments

The release schedule could have told you in advance – here we have the first installment in the KDE 4.8 series!

The Slackware KDE 4.8.0 packages are ready for your enjoyment..

A good primer on the how and why of the modularization of KDE, resulting in an abundance of smaller packages compared to the big meta packages of Slackware 13.37, please read my earlier post about KDE 4.7.0.

My packages have been compiled on Slackware-current. There has been an incompatible update to slackware-current recently (the glibc package). If you consider using KDE 4.8.0 on one of Slackware’s earlier (stable) releases, then you have no other option than to compile packages yourself. I have written down the guidelines in another blog post..

Read the accompanying README file for installation and upgrade instructions!

Some of the highlights of these KDE packages:

  • Being the first release in the KDE 4.8 series means, there will probably be some bugs to iron out. But, I really can not find anything wrong with this point zero release. It sports a new default background “Ariya” to replace “Horos” of the 4.6 and 4.7 releases. It’s nothing but straight-line geometry, giving the desktop a professional look. The desktop feels fast and snappy, partly thanks to the upgraded Qt 4.8.0 which I added as well, but also thanks to the improvements made to kwin, KDE’s window manager. Enabling the “blur” effect should no longer slow down your desktop.
  • There are a lot of updated dependencies compared to Slackware’s own KDE 4.5.5: PyQt, QScintilla, akonadi, attica, clucene, ebook-tools, hunspell, libdbusmenu-qt, libvncserver, phonon, polkit-qt-1, qt, raptor2, rascal, redland, shared-desktop-ontologies, sip, soprano, strigi, system-config-printer and virtuoso-ose. I really hope Slackware will catch up some day, as it is no fun to maintain so many packages outside of the main Slackware tree.
  • In comparison with my previous KDE 4.7.4 the number of updated dependencies is still rather big because I wanted to offer the best experience: akonadi, attica, hunspell, libatasmart, libvncserver, phonon, phonon-xine, polkit-qt-1, qt, strigi, udisks, and upower have all been brought to their most recent versions. Note that libktorrent is now located in “deps” instead of “kde” directory because it has become a dependency for more than just ktorrent.
  • KDE dpendencies that are not part of Slackware 13.37 at all (yet): grantlee, herqq, libatasmart, libbluedevil, libssh, phonon-gstreamer, phonon-xine, sg3_utils, udisks and upower. Note that I added phonon-gstreamer and phonon-xine only after I had already released KDE 4.7.0 packages because people reported that they no longer had sound. These two packages solve that issue.

Also worth mentioning is some stuff which is not completely new, since I added these to previous releases of KDE 4.7 already (but if you are new to KDE 4.8 this will certainly interest you):

  • You will find some additional useful new applications, which are not part of the KDE core set. They are new, compared to Slackware’s own version of KDE. I already added bluedevil to my 4.6.5 package-set. Bluedevil is the new KDE bluetooth stack with a nice GUI, based on the BlueZ libraries already present in Slackware. And with KDE 4.7.0, I included kplayer, a KDE front-end to MPlayer. With KDE 4.7.2, I added Quanta Plus, which disappeared from KDE4 because that migrated from Qt3 to Qt4. It is now being worked on again, but no longer as a standalone application – instead it is available as a plugin to the Kdevelop Platform. And with KDE 4.7.3, I added a native WICD applet for KDE, called “wicd-kde“. It can replace the GTK based “wicd-client” which is part of the wicd package.
  • I also added oxygen-gtk2 (renamed from “oxygen-gtk” now that there is also a version supporting GTK3). It is not really an application, but a theme engine. It (optionally) makes GTK2 applications visually blend in with KDE’s own Oxygen theme. There is a README in its documentation directory which explains how to enable it.
  • Since KDE 4.7.2, I include a “test” directory. This directory contains NetworkManager, plus some other dependencies, that allows me to create a KDE package for “networkmanagement“. Networkmanagement is an applet plus a kcontrol (i.e. a plugin for KDE’s systemsettings). Use the packages in this “test” directory if you want to switch from WICD to NetworkManager as your basic network management service. The applet plus kcontrol make it quite easy to configure your network in KDE (wired, wireless, vpn, dsl and mobile broadband). No new Gnome libraries had to be added for this (NM itself plus its supporting tools have no dependency on the rest of Gnome). I have added NM installation/configuration instructions to the README. Note that I moved from NM 0.8 (which I had in KDE 4.7) to the newer NM 0.9 because that is what KDE currently supports best.

The KDE 4.8.0 packages for Slackware-current are available for download from my “ktown” repository and several mirrors (taper will probably be in sync when I post this, the other mirrors will have to catch up):

Have fun! Eric

LibreOffice 3.4.5 released, OpenJDK package update.

January 18, 2012 / / 32 Comments

There was a new maintenance release from the Document Foundation. We now have LibreOffice 3.4.5 and I spent the night (or rather, two virtual machines did the work while I slept) to produce packages for Slackware 13.37 and later.

You can find the packages in the usual locations (all of the mirrors below also offer  rsync access):

Also I rebuilt my OpenJDK packages (JDK as well as JRE and the browser plugin icedtea-web) to address the issues that had popped up in the comments section of my previous post:

  • The java web start (javaws, part of the “icedtea-web” package) would not work with just openjre installed – it worked fine with openjdk;
  • The openjre pakage missed two important configfiles which made it unusable,
  • The CA certificates file was empty in both JDK and JRE packages

Download locations for the updated packages: http://slackware.com/~alien/openjdk/ with a mirror here: http://alien.slackbook.org/slackware/openjdk/ . Please note that there is an updated (with regard to Slackware’s stock version) of ca-certificates. I needed that to generate a “cacerts” file for the openjdk and openjre package, but for you the upgrade is optional. You’ll see it appear in slackware-current soon enough anyway because the upgrade is well overdue.

Cheers, Eric

OpenJDK replacing Oracle’s binaries

January 7, 2012 / / 47 Comments

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

Happy New Year 2012

January 2, 2012 / / 17 Comments

I assume all of you had a safe year-ending? With all the fireworks, a finger or an eye is easily lost… I also assume that you are full of good intentions for the new year. I wish you all a prosperous and happy 2012, and I hope we will see a new shining release of Slackware Linux in the course of this new year!

Let me tell you some about what I have been doing in the past days. Thinking about the future of course – not much of that will interest you. More to the point, I have been thinking what needs to be done for Slackware to gain a little more ground.

There has not been a lot of movement in slackware-current for the past months and while that is pretty frustrating, we will have to respect Patrick Volkerding for giving his personal life a bit more priority now. In the meantime, I will keep myself busy with some of the “subsystems” in Slackware – KDE 4.8 is around the corner and I will certainly build packages for that.

There is also the urgent issue of dealing with JDK and JRE. As you may remember, Oracle decided that new binary releases of its own 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. Slackware has not seen an update to its Java packages since that announcement. I have been busy in the past weeks preparing a set of Slackware OpenJDK packages. That was not trivial, since OpenJDK requires several additional packages in order to be compiled from source. It also required changes to Slackware’s gcc-java and seamonkey packages since I wanted OpenJDK to be “bootstrapped” against GCC’s java compiler. I could have chosen the easy way and compile it using a binary Java package downloaded from Oracle (which is acceptable as long as I do not re-distribute the downloaded binaries) but I had my reasons for not doing that – see below. I have now a working OpenJDK installed on my Slackware-current laptop, including a web-browser plugin for Java. That looks promising and I have uploaded all my work to the Slackware server so that Pat V. can have a look at it and ultimately add it to Slackware.

I had a goal in mind when I decided to take the hard way and compile OpenJDK using the (not fully compliant) GCC Java compiler It is the only way that we may finally be able to create a Java package for ARMedslack! The ARM port of Slackware currently has no Java support at all and I intend to change that.

You may ask, where this interest in Slackware ARM comes from. You have not read my recent posts perhaps?

It’s quite simple really. Because I think this platform is ready for prime time. The first powerful ARM based laptops have finally shown up. They are currently mostly running Android – think of the ASUS Transformer (powered by a Tegra 2 – essentially the chip which also powers a lot of the new Android tablets). You can barely fail to notice that all the big distros (Arch Linux, Gentoo, Fedora, Debian, Ubuntu) are working hard on a port to these new ARM platforms. I believe that Slackware should be part of that effort.

So, first of all, I am eagerly waiting for the Raspberry Pi devices to become available for sale. A computer for 35 dollars, that is something nobody should be able to resist. I want one of those and install ARMedslack on it. Stuart Winter is willing to port ARMedslack to this new device (hopefully the kernel is the only package which needs to be crafted specifically for the new ARM CPU). And second, I already bought another ARM based computer: the TrimSlice Pro. The TrimSlice is of an entirely different league than the low-spec Raspberry Pi. It runs on the same Nvidia Tegra-2 chip I already mentioned earlier. The Tegra 2 has a dual-core ARM CPU running at 1 GHz and a GeForce GPU which should be capable of 1080p full-screen HD video payback.The TrimSlice also has 1 GB of RAM and comes pre-installed with Ubuntu Linux on a 32 GB SSD harddisk… now that screams to be replaced with Slackware. This device should be fast enough to be used for compilation of ARM packages. Stuart is working on a kernel for this device, but there are some complications. The TrimSlice uses a USB to SATA bridge to connect the SSD. That causes USB disconnects with the ARMedslack kernel when large amounts of data are written. Stuart will undoubtedly find a fix for that in the end.

And while Stuart works on the ARMedslack packages I have been considering what would be a second port to ARM. The crux is that ARMedslack supports a wide range of ARM computers (which is linked to the history of the port) and therefore does not profit from the new CPU’s which also have hardware floating point units (FPU). I want to try and start a port to “ARM hard float” architecture which should give it a big speed boost compared to ARMedslack. Of course, this means that the new port will not run on older devices like the SheevaPlug, or ARM based NAS/mediaplayer boxes which typically run cusom Debian distributions. I spent part of my holiday to write a script which cross-compiles a basic toolchain (kernel, binutils, glibc, gcc, bash and other necessary stuff) which can be used to compile the rest of Slackware. I now have a small root filesystem (containing a “armv7hl-slackware-linux-gnueabi” target) ready for testing on the TrimSlice. If only there is enough time left… my short X-Mas holiday is nearing its end, and with it the room to experiment.

Eric

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑