Allan McRae

This is what happens if you ignore a weed growing on your lawn for a while. It grew to over four metres and had thorns all along the stem. In an effort to convince me that I should remove it, my wife found out that it is a Giant Devil’s Fig, which is classified as a “Noxious weed” in Brisbane. After much nagging, I chopped it down before the native bats could eat its fruit and spread it further.

And yes, my lawnmower is missing a front wheel…

A while back, I wrote about using an x86_64 kernel on an i686 userland. After using this setup for a while, I began to discover that it is not that user friendly to have to use linux32 in front many commands. In particular, when building software the ./configure needs to be prefixed with it and bash can not handle creating an alias to transparently do that. Also, I would need to make aliases for all build tools I could encounter (make, cmake, qmake, …), which is almost an impossible task.

In true Baldrick style, I came up with a cunning plan… What if I called my shell with a linux32 prefix and then my system would think it was always an i686 one. I only need my system to think it is an x86_64 when I enter an x86_64 chroot, so that is much easier to create aliases to deal with. The trick was to create a /bin/bash32 file containing:

#!/bin/bash
linux32 /bin/bash -l "$@"

Then add bash32 to the list of shells in /etc/shells and use “chsh -s bash32” to start using it.

After using this setup for several weeks, the only issue I notice is that when using chroot, it will look for /bin/bash32 in the chroot and likely fail. That can be fixed by prefixing with the SHELL environmental variable pointing at an appropriate shell (more than likely /bin/bash). I am sure that creating a wrapper script to handle that would be easy but using chroots via the Arch devtools does not suffer from this problem so I have not looked into it further.

The Chakra Project is a “distrolet” based on Arch Linux and providing its own KDE packages (collectively called KDEmod). I really do not like KDE so I am only interested in how the install goes. I used QEMU with a 4GB image and 512MB RAM with the 2010-01-10 “Aesop” installer.

The installer is live CD based, so boots you into a nice looking desktop [01]. Starting the installation takes you to a graphical install system [02] with the prerequisite warning about being an alpha release and the issues it can cause your hamster. After reading some notes and agreeing to various EULAs [03], the install is all go.

Onto the preparation of your system. The language and time settings looked quite ugly [04], but I have suspicions that QEMU was running this quite slow and maybe this was an artefact. I found it good to know that despite the complexities of installing being hidden, there was options to go in deeper [05] if needed. Partitioning [06] was not particularly simple, but that is being reworked for the future.

The actual installation of packages [07] proceeds with a montage of screenshot to whet your appetite for your new install. Of course you probably have already seen what it looks like from the live CD… Then you create some new users [08] (although I do not know what exactly an “Administrator” is), enter the root password and install the bootloader. I have no idea what the “Configure System” item at the end of the installer sidebar does as after installing the bootloader I got a reboot dialog.

The booting system looks familiar [09] to any Arch Linux user. I had expected a graphical boot-up as I had heard something about it using Plymouth, but I guess that is for the future. The login screen indicates that the /etc/hosts file has issues with setting the hostname [10]. Other than that, I was left with a fully working KDE desktop with no obvious issues. Looking at some configuration files to see how well the automatic set-up went found some interesting points. The MODULES array in /etc/rc.conf both disables and enables the e1000 module [11]. Also, I noticed that kdm is started as a daemon rather than using the inittab method, which I guess is more in line with what Chakra wants to provide but I find that to be less flexible. The supplied pacman.conf has the repos listed in an interesting order [12] (I think [core] should at least come before the KDEmod repos).

Overall, the installer does its job despite a few rough edges. The install booted to the desktop with relatively few configuration issues that I could spot. Not bad for something labelled “alpha”. Is it the “Arch made easy” that is often touted on Distrowatch Weekly comments? Maybe. But with a distro like Arch, that is not necessarily a good thing.

Screenshot index:

[01] – Live CD Desktop
[02] – Installer start screen
[03] – EULAs
[04] – Language and timezone setup
[05] – Hidden “advanced” options
[06] – Partitioning
[07] – Package installation
[08] – User creation
[09] – Bootup
[10] – Login
[11] – /etc/rc.conf
[12] – /etc/pacman.conf

Many Arch Linux users are hitting issues with the updates for libpng and libjpeg. This update required us to rebuild about 15% of our packages so the mirrors are struggling to sync. I’d recommend waiting for a day or two, or finding an up-to-date mirror. Also, this update will require you to rebuild any packages from the AUR or unofficial repos that link to those libraries. If you run into issues:

• Check the problem package is up to date (using the package search on the Arch Linux web-site)
• Check the binary files in the package using readelf -d file. If that does not show libpng12.so.0 or libjpeg.so.7, that package is not the problem.
• Try finding the problem package using the lddd script from the devtools package.
• If you are certain this is because of a package in the Arch Linux repos, file a bug report.

Or you could just ignore all that and rebuild cairo-lcd as that is probably your issue…

It seems that the admins over at jabber.org are having a disaster server upgrade so I can not use my jabber account with any regularity.

There are becoming more and more distros that are based on Arch Linux, with some so heavily “based” that they actually use Arch packages. This is fun for me as it means that I can now break multiple distros in one go, bringing “Allan broke it” to a whole new level.

One such distro is Kahel OS. Breaking through the market-speak on their website, it basically claims to be a newbies distro that has all the features a guru expects. It comes in Server, Desktop and Light Editions. I decided to try the Desktop Edition using the installer released on 2009-12-25. I installed using QEMU as I do not have a spare partition at the moment.

The install CD boots to a horrific orange screen [01]. After selecting the “install” option, you are greeted with bunch of kernel bootup text [02], followed by an Arch style boot process [03]. No graphical boot for this distro, so newbie friendly is a bit dicey already. Once booted, you are presented with a screen explaining why Kahel OS is good [04]. I suppose that was in case all that boot text was scaring us away.

Then we are actually installing. The installer is what I call ascii-graphical [05], although reverts you to text based screens as needed [06] (from that screenshot, you might notice that the answers are not necessarily intuitive…). Partitioning is done in cfdisk [07], followed by reselecting what type of filesystem you really want [08]. I decided for a single partition taking up the whole 4GB image I created and selected Btrfs for something new and given support for new filesystems is one of Kahel’s claimed features. I found it a bit strange that there was no warning about this filesystem still being experimental, but after some searching I found one hidden away on another TTY [09].

The “Install Packages” step goes straight to output from pacman [10], so there is no option to customize your install. The default install uses 3GB of space [11]. The package list is certainly interesting…. it installs the entire base, base-devel, xorg, xorg-video-drivers, gnome and gnome-extra groups. These are supplemented with a variety of other software including banshee, brasero, gnote, firefox, go-openoffice, xsane, and lots of fonts. I do not understand the use of gnote over Tomboy given mono is already installed for banshee. The SVN version of gtkpacman is installed for graphical package management. Other software choices are plain strange, such as libgpod, which is not required by anything else and is fairly useless on its own.

Finally, the installer takes you through some basic setup [12]. This distinguishes three types of users; root, administrators and normal. An “administrator” appears to have been given permissions to perform a variety of tasks via policy-kit.

Once you are done, you can reboot into your nice preconfigured desktop… but I could not. Those of you paying attention earlier would have noticed that I choose to have a single partition using btrfs. Of course, grub can not boot from that so that is a fail on my behalf. But a newbie friendly distro should have stopped me from doing that.

So, here is what I found different form Arch Linux without actually booting the system. There are a couple of extra repos enabled in pacman.conf. The listed Kahel OS repo does not exist yet. I did find a link to another Kahel repo, but it was empty. As a non-working repo breaks gtkpacman, package management is broken out of the box. Also the archlinuxfr repo is present but disabled, probably just so you can easily install yaourt.

Several packages are novel to Kahel OS. These are mainly for automatic configuration of the desktop and fonts as well as providing nice icons. The developers need to learn about makepkg.conf as they have not set their PACKAGER variable. Also, something strange is happening to their kahel-desktop-base-configurations package. It has 22 files, but “pacman -Qk” show that 11 of them are missing from the system so some installer magic has occurred. Not a great use of package management…

Overall, I am not sure what this distribution hopes to achieve. It seems that that it wants to provide a fully functional desktop after install and maybe it achieved that (I can not comment). But the installer is far from what is considered user-friendly, to the point that I do not think someone could achieve an install using it and not be able to do so with the Arch installer. Looking at screenshots on their home page, I can not see a major improvement graphically from a standard GNOME install. From all their “release announcements”, I am not sure that they know what they are trying to achieve either.

As an aside, of the 704 packages installed by Kahel OS, I built 80 (11%). So there is a lot of scope for me to cause breakage for unsuspecting Kahel OS users!

Screenshot index:

[01] – Bootscreen with lots of orange.
[02] – Boot text
[03] – Familiar boot-up from Arch
[04] – Market-speak
[05] – Ascii-graphical installer
[06] – Configuring timezone
[07] – Partitioning disk
[08] – Selecting filesystem type
[09] – Hidden Btrfs warning
[10] – Installing packages
[11] – 3Gb installed
[12] – Set-up

OS News has published an interview with the Arch Linux team. Its full of insightful comments from a fair portion of the developers (including me!).

I have always been interested in the GNU Hurd. This probably stems from the endless discussions on Slashdot about how (in my interpretation) microkernels should be full of awesome but none have really managed to obtain the greatness that they deserve. I always thought the status of Hurd was so far off being useful that there was no point in looking into it further. However, I recently read the Hurd status page and there was a picture of a GUI, doing useful spreadsheet type stuff.

My interest was piqued… Combining that with the joys of building a cross-compiler for an operating system or architecture you do not actually have access too (yes, I am a sad, sad person) and you get a Hurd cross compiler. I built a few packages and even managed to get (a slightly patched) pacman built. Then, having wasted much time, I moved on.

Several months pass and there is a post on the Arch forums, with someone trying to compile a GNU operating system for themselves. I mentioned my previous endeavours and somewhat surprisingly others seem interested in the possibility of making a Hurd distro. Well, Arch users are a weird bunch…

And so, Arch Hurd was born. There is a website, so there is no stopping now! The current status is a bunch of scripts that create a quite up-to-date cross-compiling toolchain (glibc-2.10.1, binutils-2.19.1 and gcc-4.4.2), which can be used to build the GNU Mach kernel, the Hurd, coreutils and bash (the latter two being more updated than the versions in Arch!). That is not far from a minimally bootable (but completely useless) system. Then we can all bask in the microkernally goodness.

SDL_mixer is my least favourite piece of software today and is being very closely followed by SDL_image. A few updates that should have taken me about half an hour today ended up taking over three hours due to bugs in these packages.

I had a bunch of SDL related packages (sdl_gfx, sdl_image, sdl_mixer, sdl_perl) to update. These are usually fun, because they require extensive game playing for testing! My first point of testing is always Chromium B.S.U. Everything looked good there so I upload the updated sdl_gfx and sdl_image packages. Now for the second line of testing: Frozen Bubble. Interesting… SDL_mixer has an soname bump despite being an update from 1.2.9 to 1.2.10. Stranger things have happened (heimdal likes slipping soname bumps into minor version releases). So a rebuild of many other packages is in order. Rebuild frozen-bubble and try again…

FATAL: Couldn't load '/usr/share/frozen-bubble/gfx/loading.png' into a SDL::Surface.

Hmm… looks like an SDL_image issue. I can confirm this using some other games too. It turns out the SDL_image 1.2.9 release is very broken; just not broken enough to break Chromium B.S.U. So much for my extensive testing… It appears fixed in upstream SVN, but I am feeling lazy and just downgrade it while waiting for the new release that appears to be due in the next day.

Now, try Frozen Bubble again. Still no good…

[Graphics..........] [Sound Init] at /usr/games/bin/frozen-bubble line 312


Looks like the SDL_mixer update is causing issues. That may not be surprising given the soname bump. This is confirmed by starting the game with the --no-sound option. While searching for a fix, I discovered that the soname bump was an accident. Apparently, this has been fixed, but either the source was missed or something else was going on. The good news is, I do not have to do a big rebuild now (but the rebuilds I had already done were a waste). The bad new is, SDL_mixer is still broken… The change-log in SVN lists this:

Fixed bug loading multiple music files

Pull that patch and we can all play games again! Luckily, not all updates are that painful.

Edit: updates are now available for both SDL_mixer and SDL_image that fix these issues.

I do not think I will be using Chihiro Fansubs to watch To Aru Kagaku no Railgun:

The grass is a deeper shade of green across the other side of the fence.

Close and somewhat better that the original in many ways…