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…

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.

I saw a post on the Arch Linux forums from a user wanting to build an Ada compiler and having issues with the PKGBUILD from the AUR. The main issue building the Ada compiler is that you need the Ada compiler to do it. Classic chicken and egg problem. The maintainer of the AUR package works around this by having the PKGBUILD download a tarball from his site that provides the necessary binaries to build the compiler. It is probably perfectly safe, but I would not be doing that… Also, according to the forum post, the binary compiler package seems slightly broken at the moment.

So I went on a mission to create some gcc-ada packages for Arch. I had some interesting problems along the way (you really should not try to compile on an x86_64 system with an i686 makepkg.conf…), but I succeeded in in the end. Get packages for i686 and x86_64 from here. Note that I provide the build files too, but remember you will need the package to build the package…

For those that are interested in how I bootstrapped this package (or do not trust my binaries), here are the details:

• Create a build chroot (sudo mkarchroot /path/to/chroot base base-devel sudo)
• Extract rpms from Fedora rawhide for gcc, libgnat, libgnat-devel and gcc-gnat into the chroot
• In the chroot: cd /usr/bin && ln -s ../lib/gcc/i686-pc-linux-gnu/4.4.1/cc1 cc1
• Comment out the makedepends and CC=gcc-ada lines in the PKGBUILD
• Build the package (sudo makechrootpkg -c -r /path/to/chroot)
• Revert the comments in the PKGBUILD, create a clean chroot, install the built gcc-ada package and rebuild

Then you end up with a nicely bootstrapped Ada compiler. Fedora packages were used as their tool-chain package versions are very similar to those in Arch and thus likely to actually work as drop-in replacements for our packages. Note that the last step is superlative given gcc bootstraps itself as part of its build process.

Edit: gcc-ada is now available from the Arch Linux repos.

I have been experimenting with running an x86_64 kernel with an i686 userland. The motivation for me was to be able to build both i686 and x86_64 packages on my primary system, because the access to the machine I have an x86_64 install on is becoming limited. I could have just reinstalled with x86_64, but I use wine regularly (I need MS Office for work, among other things) and I really dislike needing multilib or a chroot to run this in x86_64. Also, I did not want to do a reinstall on my primary production system (but other “risky” changes are fine…). Fedora had planned to ship an x86_64 kernel on 32-bit x86 with Fedora 11, but decided against it, so there is probably some issues with this setup.

The advantages I see of this setup are:

• The ability to use more than 4GB RAM without compiling (a reportedly slower) PAE kernel. However, individual processes will still have the 32bit memory limitation.
• Being able to create chroots for building both 32 and 64 bit packages.
• There is no need for ugly multilib packages for wine, skype or whatever 32bit only software you need.

The last one is the only real advantage over running pure x86_64. The disadvantages are:

• Not being able to automatically update the kernel and modules using the standard Arch repos.
• Some configure scripts use uname to figure out which architecture to build for. This is worked around by using linux32.

I work around the update issue by creating a local repo containing just the kernel and its firmware and having this automatically updated when I rsync my local package mirror. I suspect that the second issue is probably a factor in Fedora backing out this change as it would not be very user friendly (although I have no confirmation of this).

Actually achieving this setup is easy. Just download the x86_64 version of the kernel26-firmware, kernel26 and any additional drivers you need and then install them. Reboot and marvel as the output of “uname -m” says x86_64! It is now several days since I did this and I have noticed no issues, although I have not done any major package building in that time.

I had to make a couple of changes to get the Arch devtools to run correctly (using linux32 when appropriate within i686 build scripts, using /etc/makepkg64.conf and a separate package cache for x86_64), but the changes are very minor. One day I will look into patching these properly as it would probably be useful for people wanting to use these on a pure x86_64 system to build i686 packages.

Running out of space on /usr or just want to slim down your system? In Arch (or any distro using pacman as their package manager), you could just use “pacman -Qi” and parse the output. But that does not really tell you the “actual” amount of space required for a package. e.g. on my system skype is the only package using qt so having skype installed costs me at least 105Mb (~20Mb for skype and ~85Mb for qt).

I try to address this with a python script called bigpkg. It works by calculating the size of a package as its actual size plus the sum of its share of its dependencies (for each dependency, add the dep size divided by the number of packages needing that dep).

This was the output of the top 10 packages on my system:

...
deluge: 81306.0K
jabref: 83594.0K
wine: 85750.0K
r: 88727.0K
kernel26: 99609.0K
skype: 106191.0K
acroread: 150832.0K
neverball: 191562.0K
texlive-bibtexextra: 206465.0K
openoffice-base: 370234.0K


It is not perfect (e.g. jabref is one of two packages on my system using openjdk6 so removing it will not save 83MB as the ~75MB of openjdk attributed to it is still needed by the other package.) But gives a fair indication of what is taking up your hard-drive space.