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…

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.

With the toolchain rebuild for binutils-2.20, I decided it would be good idea to use package splitting to create the gcc and gcc-libs packages as that saved me a lot of build time. While I was at it, I split gcc-fortran, gcc-objc and added a gcc-ada package.

That was when I ran into fun… Once I had built gcc with package splitting, I decided to attempt to rebuild it again with the new packages just to make sure everything was OK. Turns out, that was not the case. The C pre-processor was failing basic sanity checks and that falls into the category of “not a good thing”.

So I compared the list of files in the split packages to the originals as I made quite a few changes and could have plausibly “lost” some files. Everything seemed as expected. The only real difference was the “fixed” include headers were gone. This was also expected as the previous PKGBUILD had this line:


# Remove fixed includes, either no need for them, or they're not complete
rm -rf ${pkgdir}/usr/lib/${CHOST}/${pkgver}/include-fixed/*


That comment is quite correct as the gcc packages are built in a minimal chroot and all headers in the packages within the chroot are in no need of fixing. However, earlier in the package splitting process I noted that the fixed includes directory was actually in /usr/lib/gcc/$CHOST/... and not /usr/lib/$CHOST/..., so I fixed the PKGBUILD.

And here was the problem… As of GCC-4.3, the compiler installs a limits.h file into the private include-fixed directory and that directory is an absolute requirement. So, the unnoticed bug in the PKGBUILD actually was saving us from a far more severe bug and had been for some time.

The only conclusion I can draw from all of this is we should never strive for bug free code as some bugs are good!

Dusty recently introduced his Arch Bounty project. The basic idea is people have an idea of what they would like implemented in Arch Linux but are unable to implement it themselves. Instead, they craft a clearly worded specification for their proposal and submit it to the Arch Bounty site. Once the proposal is accepted, people can make a donation towards the completion of the project.

That seems a great idea for those who have big ideas without the know-how to implement them. And if many people want the same things, I can see quite a nice monetary motivator building up to get the job done. However, after several weeks, there is still a dearth of projects. Someone proposed creating a fully featured usenet client, but I think that is really too big of a project to succeed with this system (and the project was rejected from the system). And that is the sum total of all projects proposed so far…

Here are some ideas that I know people want implemented that would make good proposals:

• Universal sign-in across Arch sites (forum, wiki, bug tracker, AUR)
• Package signing in pacman
• Finally finishing the AUR2 (may be a bit ambitious)

Those are just ideas from what I see repetitively asked for on the forums (and I could think of while typing this…). I am sure there are many other ideas out there that people want implemented and would be willing to put a couple of dollars towards.