Top things that I missed in 2015

Another year of blogging comes to an end. It has been quite full of *BSD stuff so that I’d even say: Regarding this blog it has been a BSD year. This was not actually planned but isn’t a real surprise, either. I’ve not given up on Linux (which I use on a daily basis as my primary desktop OS) but it’s clear that I’m fascinated with the BSDs and will try to get into them further in 2016.

Despite being a busy year, there were quite a few things that I would have liked to do and blog about that never happened. I hope to be able to do some of these things next year.

Desktops, toolkits, live DVD

One of the most “successful” (in case of hits) article series was the desktop comparison that I did in 2012. Now in that field a lot has happened since then and I really wanted to do this again. Some desktops are no longer alive others have become available since then and it is a sure thing that the amount of memory needed has changed as well… 😉

Also I’ve never been able to finish the toolkit comparison which I stopped in the middle of writing about GTK-based applications. This has been started in 2013 so it would also be about time. However my focus has shifted away from the original intend of finding tools for a light-weight Linux desktop. I’ve become involved with the EDE project (“Equinox Desktop Environment”) that uses the FLTK toolkit and so people could argue that I’m not really unbiased anymore. Then again… I chose to become involved because that was the winner of my last test series – and chances are that the reasons for it are still valid.

And then there’s the “Desktop Demo DVD” subproject that never really took off. I had an Arch-based image with quite some desktops to choose from but there were a few problems: Trinity could not be installed alongside KDE, Unity for Arch was not exactly in good shape, etc. But the biggest issue was the fact that I did not have webspace available to store a big iso file.

My traffic statistics show that there has been a constant interest in the article about creating an Arch Linux live-CD. Unfortunately it is completely obsolete since the tool that creates it has changed substantially. I’d really like to write an updated version somewhen.

In fact I wanted to start over with the desktop tests this summer and had started with this. However Virtual Box hardware acceleration for graphics was broken on Arch, and since this is a real blocker I could not continue (has this been resolved since?).


I wrote an article about HURD in 2013, too, and wanted to re-visit a HURD-based system to see what happened in the mean time. ArchHURD has been in coma for quite some time. Just recently there was a vital sign however. I wish the new developer best luck and will surely do another blog post about it once there’s something usable to show off!

The experiments with Arch and an alternative libc (musl) were stopped due to a lack of time and could be taken further. This has been an interesting project that I’d like to continue some time in some form. I also had some reviews of interesting but lesser known Linux distros in mind. Not sure if I find time for that, though.

There has been a whole lot going about both FreeBSD and OpenBSD. Still I would have liked to do more in that field (exploring jails, ZFS, etc.). But that’s things I’ll do in 2016 for sure.


I’ve played a bit with a Raspberry 2 and built a little router with it using a security orientated Linux distro. It was a fun project to do and maybe it is of any use to somebody.

One highlight that I’m looking forward to mess with is the RISC-V platform, a very promising effort to finally give us a CPU that is actually open hardware!

Other things

There are a few other things that I want to write about and hope to find time for soon. I messed with some version control tools a while back and this would make a nice series of articles, I think. Also I have something about devops in mind and want to do a brief comparison of some configuration management tools (Puppet, Chef, Salt Stack, Ansible – and perhaps some more). If there is interest in that I might pick it up and document some examples on FreeBSD or OpenBSD (there’s more than enough material for Linux around but *BSD is often a rather weak spot). We’ll see.

Well, and I still have one article about GPL vs. BSD license(s) in store that will surely happen next year. That and a few topics about programming that I’ve been thinking about writing for a while now.

So – goodbye 2015 and welcome 2016!

Happy new year everyone! As you can see, I have not run out of ideas. 🙂

Eerie Linux and Musl libc

Happy Easter, everyone! Guess it’s about time I admit that my previous post was just an april fools, right? It’s been 20 days already after all! Well, there are reasons why I couldn’t do it. Two actually, if you disregard obstacles due to real life!

Keyboard issues

The first one is that I’m currently trying to get used to an alternate keyboard layout called Neo². You’ve never heard of it? We’ll that’s actually quite likely as it is neither well-known nor in wide-spread use – even in my country.

It’s basically an ergonomic keyboard layout optimized primarily for the German language (but also well fit for English as many of us frequently use that language, too). It uses six(!) layers and quite some dead keys, thus allowing for many, many more characters that you can type with it. Have you heard about dvorak (wikipedia article) for example? Then you know the basic idea of rearranging keys (and the advantage of having more characters easily accessible, like e.g. the whole Greek alphabet, is pretty obvious).

Neo² promises even more typing speed once I learned it properly and got some experience with it. I can already see that this claim makes sense as the keys are re-arranged very reasonably. However for the time being, it makes me type damn slow! Do I hear anybody laughing? Well, chances are that there’s an alternate keyboard for your language, too. Why don’t you try it out yourself and share some of the pain having to relearn something you’ve gotten used to for way over two decades? 😉

Not really all an april fool

And the second reason is… that most of what I wrote was not actually an april fool! Ok, some of it was. While the size of the TinyCore kernel is true (I really built it), I do not intend to use it as the default kernel. Also E5 won’t switch to musl – because I consider E5 a project on halt. What IS true however, is the fact that I’ve been experimenting with musl for quite a while now. In fact I actually plan to build another experimental Arch-like system which will be based on musl.

This is clearly the most challenging experiment I’ve made so far. Many standard packages are tested only with glibc and may require excessive patching to play together with musl nicely. Fortunately one of my favorite Linux distributions, Alpine Linux, decided to switch to musl! Thanks to their experience with µclibc – another alternative libc – it’s without question that they have the technical knowledge to make this happen. I have been very excited since I read their announcement and had been following the “edge-musl” branch closely. Now only ten days ago they dropped the “edge-musl” branch. First I was shocked. But then I realized that musl is now the standard libc for “edge”!

Alpine has been a great resource for me while I was trying to build an Arch system on musl. Musl is also available on Arch thanks to the AUR, but there it’s only a secondary libc installed with a different prefix. It’s meant more or less for static linking only. The great news: There seem to be quite a few people around who are interested in both Arch and musl. So why not combine the two?

Project status

It didn’t really take me long to get a musl-based mini-system working in a chroot. Adding more packages and making the beast boot was actually quite painful. In some regards I had to resort to what I’d consider “cheating”: So far mkinitcpio is completely broken and I just copied an initramfs image from my previous Arch:E5 project. I was really happy, though, when I finally got the whole thing booting…

Then it took a few weeks to get pam and logging in working and runit (the init replacement I’m using) to spawn some tty… Welcome to a bare system that won’t provide much more functionality than just coreutils and the like! Next I added a text editor so messing with configuration files became easier and prepared all the dependencies for pacman. There were quite some struggles along the way but in the end I succeeded: Eerie has pacman now!

The logical next step was adding the basic development packages. Most of them even built without any special means necessary. However GCC proved really troublesome to build. I was stuck on that one for weeks (and even though it were weeks with little time on my hands, it proved to be a real blocker). In the end I gave in and used what Alpine provides (did the same thing for gcc-libs before, anyways!). So I at least have a working GCC.

Getting the net to work has been giving me the creeps. I have failed to get xinetd to compile against musl and I’ve also failed to find an alternative to it that would do the job instead. Now I know why many distros use busybox together with a dhclient script… Definitely have to take a look at how Alpine does it, but I’m not really knowledgable about openRC and would like to look into that one first. Maybe I’ll find a little time for that soon. Who knows. The most important thing is that network connection with EERIE is possible.

I’ve built a few packages natively on my EERIE system but most of them were built externally. My goal is of course to be able to build all of them on EERIE and thus make the project self-hosted.

Open development

So far I’ve done all my projects in a semi-open way. I came up with an idea and tried to cook something up behind closed doors. When I thought that it was ready, I made it public and that was it. However these projects were more or less personal experiments that I shared with anybody who might care. Now I’d like to take the next step and set up a project that’s actually useful (while still being experimental for the forseeable future).

For that reason I set up a repository to store all PKGBUILD files for EERIE using a DVCS (distributed version control system) called Fossil. It’s way less known that e.g. git, mercurial, etc., but it provides some nice extras. Look here for a little how-to on cloning the repository.

Join the feast!

Building an Arch-like Linux distribution on musl is a gigantic task. For that reason I could really use any bit of help I can get. If you care for Musl and like Arch, please consider supporting this project. And no, I’m not asking for money. If you think you have a bit of free time on your hands and the skill (or will to learn since that’s what we all start with) to mess with package building, just get in touch with me! Oh, and even if you don’t think you can help by making more packages available, you may just invest the one or two minutes that it takes to write me a comment here and show some interest in the project. That would also help and is greatly appreciated!

What’s next?

I’m busy getting the repos with binary packages up so that an EERIE system can be pacstrapped. I’ll try to make a release announcement as soon as possible. Probably in early May. Please bear with me!

Arch:E5 ditches eglibc and goes for musl libc!

Those of you who follow the development of Linux for embedded devices (or simply older hardware) will probably have noticed, that eglibc is effectively dead. According to their website “EGLIBC is no longer developed and such goals are now being addressed directly in GLIBC.”!

E5 and eglibc

Arch:E5 was built to be a bit lighter than todays mainline Arch. To do just that it’s obviously necessary to deal with the root of the trouble (yeah, a pretty lame pun, I know). The standard C library is – together with the kernel – the very heart of every Linux distro, that’s for sure! And since ordinary glibc is quite a memory hog, eglibc was a pretty self-evident choice to keep things a little smaller and prettier. But as this variant of the GNU C library will cease to exist after the 2.19 branch, E5 had to look for alternatives.

There are actually quite a few alternative C libraries around. Dietlibc for example. But it’s primarily meant for static linking. Yet there are more candidates. Like µclibc. A pretty nice libc actually which is also already proven and tested: There are even a few distributions built upon it. So could that be an option for E5? Nah, not really! Wanna know why not? ’cause it would be rather boring. And even worse: It has already been done for Arch and is even described in its own page on the ArchWiki!

So – is E5 doomed to eat humble pie and return to glibc, losing one of the main characteristics which made it diverge from mainline Arch? But no, fear not dear brethren! Luckily for us there’s also Musl, a rather young libc which you may not even have heard of. It has reached version 1.0 just these days and thus it practically calls for being used in place of our old C library! There are a few distros already which are based upon musl. But everything’s experimental and pretty much a mess to work with. In other words: Absolutely ideal preconditions!

I’ve been secretly working to make E5 run with musl as the distro’s libc for about two weeks now and just a few minutes ago I succeeded in getting E5 “Musl edition” to run! It was quite a bit of work and took quite some time. So far I have not spoken a word about it with anybody. But today’s the big day to announce it to the public!

Like the idea of Arch based on musl? If you don’t have a clue why you should like it, you may want to take a look at this table which compares musl to other libc projects. Convinced? Great! Now as proof that I’m not lying about the successful porting, here’s a screenshot which should confirm my claims:

Arch:E5 Musel’s boot screen!


While I was at it anyways, I thought that I might change the kernel as well. Ok, I have to admit that I’m still not cool enough to use some BSD kernel. But it’s clear that E5 (being an experimental distro!) needs something more… extraordinary. In the end I settled for a minimalistic Linux kernel by compiling one with the kernel settings from the TinyCore Linux project.

The result is really astounding if you ask me: That kernel image is just 2.5 Megs in size!! No, I’m not kidding. Don’t believe me? I can well understand you. But behold!, all you sceptics out there, here’s one more screenshot of the secret project for you:

Arch:E5 Musel with a TinyCore-like kernel!

So what do ‘ya say now? The “Arch Linux 3.10.33-1-LIBRE-LTS” line?? Uhm, well… *cough* Guess I gave that kernel a wrong name then! Yes, exactly that must be the case…

What’s next?

The logical next step would be publishing an E5-Musl repository, wouldn’t it??

Arch:E5 update and more repos (x11, gtk, fltk)

Finally I found some time to update and expand E5 a bit. The biggest news is surely the release of the e5-x11, e5-gtk and e5-fltk repositories. On the top of that packages have been updated and more than 80 new ones added (mostly to extra). This update also fixes a few issues that E5 had before.


Most notably the docbook issue has been resolved. It took me quite a while to figure out what was wrong there. I was able to narrow down the problem to be solely related to the docbook-xsl package as simply replacing the E5 one with the package from Arch solved the problem. This made me guess that probably some other E5 components (docbook-xml?) were semi-broken. I tried this and that to no avail. Finally I decided to build a package on a pure Arch system using the PKGBUILD from E5. Result: Broken package. Build the package again with an unmodified Arch PKGBUILD? Result: Working. Hm! Since it is an arch-independant package I hadn’t really changed anything except for setting the epoch value. And in the end it turned out: Leaving out epoch makes the package work, setting it breaks it!

Even though it bugs me to make an exception the epoch “rule” for this package, I’ve removed the epoch value for docbook-xsl for now. If anybody has any idea exactly what’s going on there, feel free to tell me. I’m very interested in it but don’t have the time to dig any deeper on the issue in the forseeable future.

For some reason I had forgotten to disable the libsystemd dependency on the polkit package. And since E5 doesn’t come with systemd, polkit could not be used. This bug has been corrected.

There were two or three smaller issues I was able to solve during the last weeks but I didn’t write them down and can’t really remember what they were.

The Equinox Desktop Environment on Arch:E5


Quite a few packages have been updated to newer versions. Most of them are from the skel or default repository but a few other ones were updated as well.

Here are some of the most important ones:

  • linux-libre-lts-5:3.10.33-1-i686.pkg.tar.xz
  • ignite-5:20140212-3-i686.pkg.tar.xz
  • eudev-5:1.5-1-i686.pkg.tar.xz
  • tzdata-5:2014a-1-any.pkg.tar.xz
  • bash-5:4.3-1-i686.pkg.tar.xz
  • openssh-5:6.5p1-2-i686.pkg.tar.xz
  • openldap-5:2.4.39-1-i686.pkg.tar.xz
  • pulseaudio-5:5.0-1-i686.pkg.tar.xz

New repositories

However the main news is clearly that the new repositories “x11”, “fltk” and “gtk” are available now. Like their names suggest, they hold packages which provide graphical programs which run on pure X11 or depend on the FLTK or GTK+ toolkits.

To install a very light-weight desktop, simply install the package “ede”:

pacman -S ede

Or if you want a full-blown, yet traditional desktop, the “mate” (and probably “mate-extra”) group(s) may fit your needs:

pacman -S mate

I had also intended to package a game for demonstration and since the new widelands beta was released not too long ago, I tried to prepare that. Arch:E5 has all the packages needed to build it and widelands compiles fine, too. Unfortunately it segfaults upon execution… And since I don’t have the time needed to look into that, it’s unfortunately no widelands right now. 😦

The new MATE 1.8 on Arch:E5

The furure

I think that Arch:E5 has already grown quite large for the quick project that it is. Right now it consists of 700+ packages which are roughly 1GB in size!

While it has been an interesting project, I’m not really sure what to do with it now. Most of what I was aiming for has been accomplished and the next step would now be bug hunting and adding even more packages. In other worlds: Nothing spectacular. In general I’m up to the challenge to maintain a linux distro for a longer time. However there’s of course no reason to maintain anything that isn’t of any use to anybody.

For that reason I’ll just let Arch:E5 live for a while doing the occasional update now and then and see if it is at least remotely interesting for somebody.

What’s next?

There are a lot of things which I’d like to do next. However I haven’t really decided, yet. So it’ll have to be a surprise!

[Edit: Added pictures]

More e5 repositories available (default, devel, extra)

Today more e5 repositories have been made available to the public. Most notably: e5-default, e5-devel and e5-extra. Also the linux-libre-lts kernel in e5-skel has been updated from minor version 27 to 29.

New to E5? You may want to read this and this post first!

An experimental Arch system

While a minimal working E5 system could be pacstrapped before since the time when the skel repository became available, it is possible to install an E5 system now that is actually useful (without having to relay on packages from mainline Arch). Unlike before, pacstrapping base now installs 34 more packages, among them vim and pacman. So you can now at least edit files and do package management! The base system is now also capable of dhcp.

The group base-devel installs everything necessary for starting to build programs yourself or to do some packaging. This group is a bit larger in comparison with mainline Arch: clang was added to it since that is meant to be the default compiler with E5. However the devel repository holds quite a few more packages which are not part of that group – cmake, valgrind or java7-openjdk are some examples (the later is not quite the latest version, though).

The extra repository offers what you would expect as an Arch user: Tools like wget, VCS like git and subversion, and lots of other things (cups, python, etc.). Only all packages of TeX are in their own separate repo (e5-tex), mainly due to its size.

To install it, see the previous post and add the e5-default repository together with the e5-skel one.

These packages allow for an Arch:E5 system which offers pretty endless possibilities for you to mess with. Happy hacking! 😉

(I’d love to hear your feedback, BTW. Don’t hesitate to post it here or to mail me!)

Known problems

There are a few issues that I am aware of but didn’t have the time to look into properly or haven’t found a solution for, yet. If you think you have an idea on what’s going wrong, please get in touch with me! I’m very interested in any help, even if it’s just a small clue. And of course: Please report any other issues you might run into!

Here’s a list of issues I’m currently aware of:

  • There are some packages which do not compile at all with clang. Sometimes they did work with clang 3.3 but stopped working with 3.4 (or vice-versa). In some cases I’ve found patches or was able to apply a little sed magic. But since I’m not a programmer my capabilities in this area are fairly limited.
  • With some packages the checks fail when built with clang. Since this is an experimental distribution I chose to simply ignore any failed tests and just hope that the package will work correctly, anyway. It’s quite likely however that some don’t.
  • There are cases where c++ programs compile with clang++ in general but not if libc++ is chosen as the standard c++ library. However libc++ is under active development and compatibility will surely increase over time.
  • DragonEgg is seems to be broken in version 3.4. When version 3.3 was the current one I used it with packages that didn’t work with clang and most of them were building fine. Currently I’m falling back on pure gcc for those, too (a bit unwillingly, though).
  • Some packages seem to work but are in fact broken. A perfect example of this is libxcb. It compiles fine with clang but makes X11 unable to start up (and rather misleading error messages made me search for a solution in an entirely wrong direction for days!).
  • The ca-certificates package is part of base but it’s not working corrently after the pacstrap for whatever reason. Simply re-installing it once E5 has booted up solves the problem, though. I’m a but puzzled about this one.
  • There’s some issue with docbook. Some packages try to load entries from the web (sourceforge). This fails with E5 for some reason. I’ve built a few custom Arch-like mini distros before (like an i586 Arch) and never had this problem. I’ll have to dig into that somewhen.
  • I REALLY should update for E5, but I didn’t find the time to do so, yet…

What’s next?

I’ve already got a few more repositories on my drive. These are e5-x11 (which holds anything related to “pure” X), e5-plus (some uncommon stuff like anything that’s just a make dependency for some package), e5-gtk (for the GTK toolkit(s) and all applications that depend on it), e5-fltk (the FLTK toolkit, an FLTK-based desktop environment, FLTK-based applications) and e5-qt (obviously for Qt and Qt-based applications).

There are a few problems remaining with some packages and a lot of important ones missing completely. I’ll have to put some more work into that. I’d also like to provide the PKGBUILD files that I use(d) to build the E5 packages. These should be of some use for people who want to play around with E5 some more. Perhaps I should just put them on github like many other projects do?

And then I’d like to replace some more core system components with alternative ones (like trying to use obase instead of coreutils, dracut instead of mkinitcpio and things like that). In any case there’s a lot of fun waiting!

[Edit: Forgot to mention the ca-certificates issue.]

First public Arch:e5 repository published

The first public Arch:e5 repository is available now! If you have no idea what E5 is, you may want to take a look at the post Announcing Arch:E5! first.

About one month passed and I just made the skel (or “skeleton”) repository available. It can be used to pacstrap a fairly minimal Arch:e5 installation. I’ll describe how to do that in a minute, but first a few words about what this actually is.

Arch:e5 structure

Arch uses a rather simple repository layout: The most important packages are in core and everything else is in extra. Packages not officially maintained by the project can probably be found in community. Disregarding a few special things this is already it.

E5 booted using runit/ignite

While a “base” install of Arch is quite small compared to most well-known distros, it still pulls in quite a few things you might not want to have. Right, you can easily uninstall packages later. Or you could do without the “pacstrap” script and make use of pacman’s group feature. But using pacstrap is simply a very convenient way of installing Arch.

Now the idea is to allow for an installation that can be customized even more than Arch’s right from the beginning and thus split core into two repositories: skel and default. The former consists of everything absolutely necessary to get an Arch-based system up and running while the later holds the default packages that make the system actually useful.

The skeleton repository

Why would one do that split? Well, imagine you have a very specific idea of what your system should be. Perhaps you are an vi user. For what reason should nano even be installed at all? Or you don’t intend on using systemd. Why put it on your system in the first place?

Just pacstrapping the skeleton of your system together with what you actually want is a pretty obvious and comfortable solution.

E5 brings back one of the strong points of the classical Arch: rc.conf!

Right now skel contains all the packages which are in the “mini” group – 59 packages to be precise. I intend to put some more work into it to break it down to 50 packages at most (or rather: as few as possible). Some packages like the bootloader (syslinux) or the init-system (runit) are likely to be moved to the repository default in the future when E5 begins to offer alternative choices. Decreasing the number of packages could also be done by replacing some of them with others that have fewer dependencies.

How to install?

Warning: This ist just a preview. The system you’ll end up with is not of much use on its own at this time.

It doesn’t come with dhcp.
It doesn’t have a package manager.
It doesn’t even provide an editor.

If you want anything more than the bare skeleton, pacstrap it on top of E5 (from the Arch repositories) after the initial pacstrap is complete!

Preparing to pacstrap an Arch:e5 skeleton installation

As you can see, installing Arch:e5 is rather simple. Just boot from an Arch Linux live medium and make some changes to the /etc/pacman.conf file.

1. Comment out any Arch Linux repositories.

2. Then add the following:

SigLevel = Never
Server =

3. Once you saved the changes, you can check if pacman can read the package database using pacman -Sy. This is optional, of course, since the pacstrap script updates the db anyways.

4. Proceed with a more or less typical Arch installation:

Create and format your partitions, mount them and finally pacstrap the group mini instead of base. Then use genfstab and reboot. That’s it. If you follow the default partition layout, there’s no need to chroot to the environment since syslinux is installed automatically.

What’s next?

I’ll definitely continue working on E5. My next goal is currently to prepare and publish the default repository.

Content of skel

Since there’s not much in it, here’s the complete list of packages which skel currently holds (all but 3 packages were actually built with clang 3.4, btw.):

  1. acl-5:2.2.52-1-i686.pkg.tar.xz
  2. ath9k-htc-firmware-5:1.3.2-3-any.pkg.tar.xz
  3. attr-5:2.4.47-1-i686.pkg.tar.xz
  4. bash-5:4.2.045-5-i686.pkg.tar.xz
  5. bzip2-5:1.0.6-5-i686.pkg.tar.xz
  6. coreutils-5:8.22-2-i686.pkg.tar.xz
  7. cracklib-5:2.9.0-2-i686.pkg.tar.xz
  8. dash-5:0.5.7-4-i686.pkg.tar.xz
  9. db-5:5.3.21-2-i686.pkg.tar.xz
  10. e2fsprogs-5:1.42.8-2-i686.pkg.tar.xz
  11. eglibc-5:2.18r24829-1-i686.pkg.tar.xz
  12. eudev-5:1.4-1-i686.pkg.tar.xz
  13. expat-5:2.1.0-3-i686.pkg.tar.xz
  14. filesystem-5:2013.05-2-i686.pkg.tar.xz
  15. findutils-5:4.4.2-5-i686.pkg.tar.xz
  16. gawk-5:4.1.0-2-i686.pkg.tar.xz
  17. gcc-libs-5:4.7.3-4-i686.pkg.tar.xz
  18. glib2-5:2.39.3-1-i686.pkg.tar.xz
  19. gmp-5:5.1.3-1-i686.pkg.tar.xz
  20. grep-5:2.16-1-i686.pkg.tar.xz
  21. gzip-5:1.6-1-i686.pkg.tar.xz
  22. hwids-5:20130915.1-1-any.pkg.tar.xz
  23. iana-etc-5:2.30-4-any.pkg.tar.xz
  24. ignite-5:20131028-1-i686.pkg.tar.xz
  25. iproute2-5:3.12.0-1-i686.pkg.tar.xz
  26. iptables-5:1.4.21-1-i686.pkg.tar.xz
  27. kbd-5:2.0.1-1-i686.pkg.tar.xz
  28. keyutils-5:1.5.8-1-i686.pkg.tar.xz
  29. kmod-5:15-1-i686.pkg.tar.xz
  30. krb5-5:1.12.1-1-i686.pkg.tar.xz
  31. less-5:458-1-i686.pkg.tar.xz
  32. libarchive-5:3.1.2-3-i686.pkg.tar.xz
  33. libcap-5:2.24-1-i686.pkg.tar.xz
  34. libffi-5:3.0.13-4-i686.pkg.tar.xz
  35. libldap-5:2.4.38-1-i686.pkg.tar.xz
  36. libsasl-5:2.1.26-6-i686.pkg.tar.xz
  37. libtirpc-5:0.2.4-1-i686.pkg.tar.xz
  38. linux-libre-api-headers-5:3.10.27-1-i686.pkg.tar.xz
  39. linux-libre-firmware-5:3.10-1-any.pkg.tar.xz
  40. linux-libre-lts-5:3.10.27-1-i686.pkg.tar.xz
  41. lzo2-5:2.06-3-i686.pkg.tar.xz
  42. mkinitcpio-5:0.15.0-1-any.pkg.tar.xz
  43. mkinitcpio-busybox-5:1.21.1-2-i686.pkg.tar.xz
  44. mpfr-5:3.1.2.p5-1-i686.pkg.tar.xz
  45. ncurses-5:5.9-5-i686.pkg.tar.xz
  46. nettle-5:2.7.1-1-i686.pkg.tar.xz
  47. openssl-5:1.0.1.f-1-i686.pkg.tar.xz
  48. pam-5:1.1.8-2-i686.pkg.tar.xz
  49. pambase-5:20130928-1-any.pkg.tar.xz
  50. pcre-5:8.34-2-i686.pkg.tar.xz
  51. procps-ng-5:3.3.9-2-i686.pkg.tar.xz
  52. readline-5:6.2.004-1-i686.pkg.tar.xz
  53. runit-5:2.1.1-3-i686.pkg.tar.xz
  54. shadow-5:
  55. syslinux-5:6.01-4-i686.pkg.tar.xz
  56. tzdata-5:2013i-1-any.pkg.tar.xz
  57. util-linux-5:2.23.2-1-i686.pkg.tar.xz
  58. xz-5:5.0.5-2-i686.pkg.tar.xz
  59. zlib-5:1.2.8-3-i686.pkg.tar.xz

Announcing Arch:E5!

Merry Christmas, everybody!

I’ve been very busy the last couple of weeks. Time to reveal what I’ve been silently cooking up during that period of time: Welcome to “Arch Linux Epoch 5” or – in short – Arch:E5.

What is it?

It’s basically a handful of repositories which allow pacstrapping a clean Arch:E5 system or turning an existing mainline Arch into a more experimental system. It’s generally possible to “mix” mainline Arch and Arch:E5 packages. These are the key differences from Arch:

  • Uses the Linux-libre kernel which has all binary blobs removed (yes, like Parabola GNU/Linux)
  • Provides eglibc (the binary compatible embedded variant) instead of glibc as standard libc
  • LLVM/Clang is the primary compiler used for package building; gcc with dragonegg is the second choice and pure gcc is the fallback option for some packages
  • Whenever possible libc++ and libc++abi are used instead of stdlibc++
  • Comes with the Runit init system instead of systemd
  • Replaces some core components with light-weight alternatives (like pkgconf instead of pkg-config)
  • Uncouples its packages from Arch’s rolling release process so that they won’t be overwritten automatically
  • Slight preference of more liberal licenses than GPL
  • There’s also a special “nucleus” repository which offers a minimal Arch system (without kernel, bootloader, etc.) meant for chroot environments. It’s using musl libc.

This is just the current status; more things are going to be changed eventually.

Why to give it a try?

Well, you’ve got to answer that for yourself. Perhaps you agree that Clang is cool/light-weight is better/systemd is playing bull in a china shop and rc.conf once was the very essence of Arch? Probably you have some more ideas in with other areas Arch could be modified and like to experiment with it? Or maybe you’ve got an additional Arch box (or VM) for playing around with, anyway? You decide.

Why “Arch:E5”??

Short version: It sounds pretty nice, doesn’t it?

Long version: Pacman provides the “epoch“ value which can be used to force lower version numbers to be treated as higher ones. It is separated from the regular version string by a colon.
EERIE starts with ‘E’, which is the fifth letter of the alphabet. To avoid self-built packages to be overwritten during updates thanks to Arch’s rolling release process, an epoch of five is used to prevent that. Hence the name.

What’s the current status? How to get it?

Arch:E5 is not currently available for downloading. The system is running nicely for a while now and I’ve got almost 1GB worth of packages in my local repositories. Currently I’m pursuing the goal of making Arch:E5 self-hosting. There should not be too many packages missing to reach that. The next step is to rebuild the whole thing (which comes at the right moment since LLVM 3.4 is to be released these days) and prove that it’s self-hosting.

Once I got through with that, I’ll have to decide how to make the derivative available. I’ll probably set up a publically available install repository on my site (, but I don’t have the bandwidth to share the whole thing. I might upload the other repositories on some share-hosting service, though. Maybe I can organize something better at a later time. We’ll see.

What are the reasons for E5?

The primary reason for most of my computer projects is simply that I want to get familiar with Linux in-depth. And surely the best way to do so is by actually getting your feet wet and just try things out. You could say: For educational reasons.

Of course there are more specific reasons for E5. While I’m a happy Archer in general (using the OS both at home and at work) there are still a few things I’d do differently. But hey: this is FOSS – and therefore I actually can. Great, isn’t it?

Oh, of course everybody is invited to join the playground. This isn’t meant as a “one man show”. You like (some of the) idea(s)? Get in touch! I’m pretty open to any comments, proposals or offers.

Anything to show off, yet?

Yes, of course. I’ve got a screenshot from this morning for you. It’s demonstrating what E5 can actually do right now.

Just in case you care: DooM (considered the real father of FPS games by many) had its 20th anniversary this month. This good old game is still very much alive and thus we recently saw the release of a lot DooM related material – including a new version of the Chocolate DooM source port. And since I wanted to give it a try anyway, I thought, I might as well do it on E5!

Running Chocolate DooM on Arch:E5!

So what you can see here is Arch:E5 running X11 with the FLTK-based EDE desktop, the GTK+2-based LWT terminal and the SDL-based DooM port “Chocolate Doom”.

As you can see, quite a few things are actually working already. I haven’t made any statistics, yet, but I think that >90% of all packages were built successfully with clang. In general I’m pretty happy with the project and I think it was about time to announce it to the public. 🙂

What’s next?

I’ll write one final post in 2013, providing a retrospect of this year. And in January I hope to have some news regarding Arch:E5.

The compiler toolchain – updating an old Linux system pt.3

In the previous two posts I showed how to install ConnOS (website here, will vanish at the end of 2013!) and demonstrated how to update a few important system components. Today we’re in for more updating fun: We’ll be rebuilding the whole compiler toolchain and replace the pretty ancient versions available on ConnOS with far more current software.

Updating the toolchain

Now that our system is much easier to work with we’re ready to go on with the more important stuff, right? Right. The first package we’re going to update is the api-headers of the kernel. Since we’re going to stick with Linux-libre (a variant of Linux that has each and every binary blob removed from the kernel), we can get a PKGBUILD over at Parabola GNU/Linux.

Downloading the PKGBUILD file from Parabola

There’s not much to say about it except for the fact that it needs the kernel source which is really big (about 70 MB!). In building and installing it there’s nothing special.

Normally our next candidate would be tzdata, which contains time zone information. However it won’t build yet as the zic tool is not available in ConnOS’s native eglibc. For that reason we will have to build a more current libc first.

Installing new api headers

This means we’re in for a special package: The system’s standard C library. Most Linux distributions use glibc which is rather fat and lavish but also has the best level of compatibility with most applications (due to it being the de-facto standard). ConnOS uses a glibc variant called eglibc which has some patches applied to make it work better on embedded systems (and thus on all kinds of machines with low resources). Unfortunately neither Arch nor Parabola use it and even on the AUR there’s only an ancient version of it (just barely newer than the one ConnOS ships).

The eglibc project also doesn’t seem to provide source tarballs. Instead the source is always cloned from their repository. However we’re not going to mess with a VCS (Version Control System) now. Fortunately there are projects using eglibc which provide source packages for it. Debian does and Cross-Linux-from-scratch does, too, just to name two. We opt for the later since it offers a more current version.

So our best bet with eglibc is to take the very old PKGBUILD from ConnochaetOS and update it to build a newer version. This is actually a bit tricky. If you want to save yourself some time trying everything out you can just use the PKGBUILD I prepared.

Installing a new version of eglibc

For some reason makepkg has difficulties with the packaging of this one. It creates the pkg directory with too restrictive permissions and fails to go one with package building. The easy solution here would be to simply use sudo since root is allowed to write anywhere. However package building as root is strongly discouraged – for a good reason. If you’re not absolutely sure your PKGBUILD is completely correct, some files could end up being installed to wrong paths on your real system, creating a glorious mess! So we’re going to take the right path and avoid dangerous root packaging. Which means we have to fix that directory issue. And right: It’s actually as simple as changing the directory permissions in the PKGBUILD.

Once it finished building (which can take a while) we’re going to install it. Since the contents of the package has changed compared to the older version we have to install the new one with the –force parameter, allowing to overwrite files owned by other packages currently installed (-f as we used before doesn’t work with the updated pacman anymore…).

Now that we have replaced eglibc version 2.11 (sic!) with 2.18, we’re good to build and install tzdata. It’s an unproblematic quickie.

Installing current tzdata

On to the next step: Updating the binutils package. Binutils consists of several tools needed whenever binaries are created: like two linkers (ld and gold), an assembler (gas), the stripping tool and some more. It’s one of the bigger packages and thus takes a while to complete. Other than that there’s nothing special here.

Upgrading binutils

Next in line: The GMP library (providing some advanced math functions). Again building and installing it is nothing special. However the library received what is called a soname bump. The non-technical explanation of that is that the number after the “.so” (for shared object) extension increased. But since many applications (including e.g. GCC and pacman!) were built against the old one, they expect that it is still available and will be missing it after installing the new one.

In theory we should now rebuild all (!) packages which depend on GMP so we have a clean system again, working entirely with the new one. Of course we’re not going to do this now and even if we did plan to do so, we first need to make GCC work again. We do so by softlinking the new library to the file name of the old one with the command: sudo ln -s /usr/lib/ /usr/lib/

Updating the GMP library

The old GCC present on our system uses a package called cloog-ppl. It does no longer exist as cloog and ppl are separate packages now. With newer GCC versions ppl is now an optional dependency. And since it also is a monster of a package (compiling it on an 1.6 GHz Pentium4m machine took over 40h!) we’re going to drop it. You most likely don’t feel like building it on a pc you’re using ConnOS on, anyway, do you?

Our updated GMP enables us to build a new package – isl – which itself is a dependency of cloog. So we’re building and installing both of them.

Adding the new package isl to our system

Isl shouldn’t be a problem at all and cloog only needs to be installed with the –force parameter, as it needs to overwrite some files of the old cloog-ppl package. Of course it would be better if we could just remove the conflicting package. Unfortunately it’s not that easy in our case. Said old package is needed for the currently installed version of GCC to work so we currently have no chance to uninstall it without breaking the compiler and rendering our system useless for the further updating process.

Installing cloog

Thanks to the updated GMP we can also update another library which depends on it: mpfr. The one on our system is very old and like GMP it has received a soname bump in between. Since it’s also a dependency of GCC, we need to symlink the new library to the names in use with the old version (see the picture for details) or our compiler will be broken.

Updating the mpfr library

The last library in line is libmpc. We’re going to update it right now as it’s one more dependency of GCC. It’s soname hasn’t changed so we’re good with the update and don’t need any symlinks this time.

Updating libmpc

Finally we’re in for the true bigwing of our update: GCC! We’ve built all the dependencies for it in their newest versions available. However we’re not going to build GCC 4.8x and opt for 4.7x instead. Why? Simple. I had first built 4.8 before and all seemed to be working well. Then however I came across a rather special package required to go on. It builds its own temporary toolchain since it’s only known to compile well with certain versions of the compiler and libraries. Now for some reason (one of the more or less frequent regressions) GCC 4.8x is severely broken: Building older versions of GCC with it doesn’t seem to be working easily! And since I passionately hate software broken in such a way, I’ll ignore that there is such a thing as GCC 4.8x. Period.

For that reason we’re going to build GCC 4.7.3 (a version Arch never used since they went from 4.7.2 directly to 4.8.0). If you want to use the PKGBUILD I prepared, it builds GCC fit for the languages C, C++ and fortran. We won’t need the later right now and thus I also don’t install it yet. But there are some important packages that use fortran. So it’s good to support it, too. GCC takes very, very long to build, btw. Depending on the speed of your machine, it may even be a good idea to start building it over night.

Updating GCC

Now we have to build libtool and libltdl. Don’t look for the PKGBUILD file of the later; it’s part of the libtool source package. Also don’t ask me for what reason they are being packaged separately now…

Even if there was no new version of it, we would now rebuild libtool. Why? Because we’ve just built GCC! Libtool is tied to GCC very closely and needs to be rebuilt as well if GCC changes. Another thing about libtool which is important to know: Due to its close ties to GCC you should avoid just updating one of the two. If a new libtool is released it’s meant for the recent version of GCC and not for older versions. Also newer versions of GCC may be meant to work with current libtool and you can run into trouble if you stick with older versions. Just keep that in mind to avoid unneccessary issues.

Updating libtool

Now as a last step we need to rebuild and reinstall two packages we’ve built before: binutils and eglibc. The reason is that binutils should be rebuilt with the current version of GCC (the previous binutils package was built before we updated the compiler) and the C-library was built with both the old GCC and the old binutils. Once we’re done with these two packages we again have what is called a sane toolchain. With the big difference of course that it’s more than two full years newer than the one our system had before!

That means we’re done with the task of today’s post. Having taken a crucial step this time, we’ve already gone a fair bit on the path of updating ConnOS. But still this is just a start.

What’s next?

I’m considering to write one more updating post. But honestly I’m not quite sure if I should. Free time is a scarce resource. And thinking about how short the rest of 2013 is and how many topics there are which I’d like to write about in the remaining one and a half months… Well. I simply don’t know right now. Feel free to comment on this topic and tell me what you think. Would one more update post be a good thing or should this be the final one?

Sudo and package manager – updating an old Linux system pt.2

The previous post introduced ConnochaetOS, a nice i586 Linux-libre desktop distro which is now dead. Not having received any updates for a long time makes it the ideal target for a little (?) exercise: Updating an old Linux distro which has missed a lot of important changes!

While the previous post showed how to install, update to the most recent (albeit very old) versions available on the repos and change the filesystem to today’s (Arch Linux) layout, we’re going a little bit deeper today by doing some package building and manual updating. The goal is to build newer packages of some important programs which can then be used to further update the system.

It’s only 5 packages today – but I show the package building process in detail here so that even people new to this can easily follow it. Also the next part can then be much shorter.

Package building on Arch-derivatives

With ConnOS being an Arch-derivative, there are fortunately a great many of PKGBUILDS available for most of the programs relevant for us. Most of them can be downloaded from or the Arch User Repository (AUR). When it comes to completely free software replacements (like Linux-libre, a modified kernel without any binary blobs and such) there’s, another fine source.

With these two alone we already have a great resource which almost completely satisfies our needs. Most of the package build recipes need to be modified for use with ConnOS, primarily because both distributions are not targeted at i586 machines. However this is usually a simple thing to do.

Generally arch=(‘any’) PKGBUILDs will work without modifications if all the dependencies are available on ConnOS. If they are not, it may be desirable to modify them and drop some dependencies which may not be worth the effort. All other recipe files need to be modified to make the i586 architecture available and often to add –host=i586-pc-linux-gnu and –build=i586-pc-linux-gnu to the configure parameters, too.

In many cases this is already all there is to do and package building can begin. The more interesting part is to understand which packages should be updated – and in which order. This is not always clear. And the really tricky part is finding out what to do in case any technology leaps occurred and there isn’t simply a newer version of some package available but a whole new application (which works differently) has replaced it. However this won’t be the case in this part of the updating series.

But enough of the theoretical talk – let’s get started!

Filesystem related updates

I’ll describe what I did to update ConnochaetOS here – including downloading the PKGBUILD files (but not my modifications to them in detail). If you also want to update ConnOS, you can save yourself some time and download my update pack which contains the modified PKGBUILDs I use here.

ConnOS with the “new” kernel

Alright. We have a system which runs on top of the “new” 3.2 kernel and uses the new filesystem layout now. First I create a new src directory and a subdirectory called iana-etc in my user’s home. Then I use links to go to, search for iana-etc and download both files needed to create the package.

Getting the PKGBUILD with links

Since the version of links available is very old, it doesn’t cope well with compressed files. Both PKGBUILD and newer.patch are gzipped files. And thanks to gzip being an incredibly stupid program (behaving like a Windows application!) we need to add the .gz extension to both files so that we can decompress them…

Building the package

Then we’re set and can begin building the package with makepkg. If all goes well (and it should) we’re left with a new package called iana-etc-2.30-3-any.pkg.tar.xz. After we become root (with su) we can install it using the pacman -Uf command (“f” is for force and allows pacman to overwrite files currently installed by other packages). Pressing CTRL+D (or typing exit) we leave the root shell since packages should in general not be built with root privileges.

Forcefully updating the package as root

The next package is called filesystem (which could not be installed if we hadn’t adapted our filesystem’s layout to the new one in the previous post). I create a directory for it, download all the required files and decompress them.

Links again

While you can at least use wildcards with gunzip, this is not possible when renaming the files. Since there are quite a lot of them in case of this package, the for command comes in handy (for file in *; do mv $file $file.gz; done).

It should actually be adapted to ConnOS, but then again it won’t hurt anybody if some of the installed files say “Arch Linux”, right? Also I simply disabled the manpage part of it – this saves us from building the package asciidoc first and I don’t think that it would be worth our time.

Renaming files and package building

Building and installing (after becoming root) is just the same as above. This package must also be installed with the “f” switch enabled since it needs to override some already existing files which were not part of the old filesystem package. We’ll ignore the warnings and errors right now.

Modernizing a few system components

Next we have to take care of one of the biggest drawbacks with ConnOS: The unavailability of sudo! Creating a new dir for it, downloading the files, renaming and decompressing is nothing new anymore. But since we’re building a package now that contains binaries, the PKGBUILD from Arch needs to be modified. Afterwards the new package can be installed as root (for the last time now). Then only the file /etc/sudoers needs to be changed so that the new user is allowed to use sudo to temporarily gain root privileges.

Adding the normal user to the sudoers file

Now it’s a good idea to update pacman. The most important reason is because the old version ConnOS has cannot understand some important things which many new PKGBUILDs rely on (like e.g. the options variable or the prepare() function). Downloading and building is more or less like before and the modifications include disabling the depends since the PKGBUILD claims pacman to need newer versions of bash, curl and others which is not quite the case. Also some architecture related changes have to be made.

Upgrading pacman

Installing pacman is now a lot more convenient since we can use sudo from now on (no more su!). After upgrading it, the package database must be converted to the new format and the repositories should be updated, too.

The next one is a mere convenience update: Links. The version that comes with ConnOS works well enough but updating it means no more messing with gzipped files. So from my point of view it’s well worth it.

Upgrading links

So now ConnOS is in a state where it is much more pleasant to work with. Still this is just one little step compared to all the work that would have to be done to fully update the system.

What’s next?

Describing package building at length took more space than I had anticipated. So the next post will deal with a very important process: Updating the compiler toolchain!

ConnochaetOS – An example of updating an old Linux system pt.1

Surprise, surprise! Today we have a topic very different from what I guessed it to be. I’m going to write about the process of updating an old Linux system (which is in fact rather challenging due to the fact that so many things changed in the time that has passed).

Updating an old Linux system can be quite adventurous (seriously!). If you’ve never done it there’s quite a bit you can learn from the process. This post is in fact more or less just an introduction. It describes installing the system (ConnochaetOS) and making some preparations.


This would probably have remained a little personal experiment but I wanted to dedicate this post to the memory of ConnochaetOS – an Arch-based GNU/Linux-libre distro with eglibc which was made with older PCs (i586) in mind. It has been a great distro but has been inactive for a long time. A few month ago the maintainer finally decided to shut down the project. While this didn’t really come unexpected, it still is a pity.

Well, there’s one very important sentence in Haary’s post: Of course everyone is welcome to overtake and to fork.

The ConnochaetOS logo

So far it doesn’t look like somebody will do this, though. I would consider to take it over – but then again I don’t feel that I have the knowledge needed for such a project just yet. Also there’s EERIE/ELDER to work on and while it’s going in a somewhat similar direction there are of course quite a few differences in design. Still I’d like to show how a system like ConnOS can be (partly) updated to become a more modern Linux system.

Installing the system

Currently all the files from the project are still accessible but will be removed at the end of the year. You can download the ISO directly from SF.

The ConnOS installer

ConnochaetOS comes with a very simple but friendly installer. It lets you choose how to install and then simply does the rest of the show.

Preparing the kernel images

Unlike Arch, ConnOS never was a rolling-release distro. For that reason the system packages are not downloaded from the net but installed from cd. This is actually a good thing since it enables you to install the system on old machines without access to the internet, too.

The installer finished

Once the installer is done, just reboot and you should be able to log into your “new” ConnOS system!

Starting and updating

ConnochaetOS is a desktop distribution so you will be greeted by a graphical display manager. After the login ConnOS provides us with a simple, light-weight wm (iceWM) which is quite nice.

The ConnOS login screen

First it’s of course a good idea to install any updates available from the distro’s repositories. Since there’s no sudo installed we have to do this the old-fashioned way and use su to become root. Now we have the chance to start updating.

Updating the system with pacman

There are not too many updates available (and these are pretty old, too, but installing them surely doesn’t hurt).

While ConnOS 0.9.1 comes with a 2.6.32 (lts) kernel it also has a 3.2 (“current”) kernel available. Of course we’re going to uninstall the 2.6 one and replace it with the 3.2 kernel!

Updating the kernel

Following the kernel update we’re left with a broken system for the moment. This means that rebooting now would be a bad idea. For that reason we’re going to edit /boot/grub/menu.lst and point the boot manager to the new kernel image.

Modifying the boot loader config

This is as far as we can update the system with already existing binary packages. We’ll have to do the rest by hand! To be able to do so we first need to install the development tools.

Installing development tools

Filesystem change

One of the big things that happened after ConnOS fell dormant was a change of the filesystem layout in Arch. Since all current package recipes are expecting the system to follow the new way, we’re converting our system to the new standard.

As this involves moving important system executables it cannot be done while the system is running. We’ll have to use an external live system to be able to manipulate our ConnOS installation according to what we’re up to. Unfortunately I have not been able to get this done with ConnOS’s own installation image. But pretty much any live distro should do the trick.

Making changes to the filesystem

I’ve booted into an Arch install system. Doing the changes is actually pretty simple:

  1. we need to mount the system partition
  2. we move all the files from lib to usr/lib
  3. we move all the files from bin and sbin to usr/bin
  4. we remove the directories lib, bin and sbin
  5. we create new symlinks instead which point to the new locations
  6. we modify GRUB’s menu.lst again, appending init=/usr/bin/init to the kernel line

Notifying GRUB on where init resides

So far for our preparations. Now at this point we have a ConnOS system which is ready to receive some manual updating!

What’s next?

Part two of the updating example will deal with building packages to update a few important system components and building an up-to-date toolchain (for compiling even more updated packages ;)).