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!

Kernels…

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.

Fixes

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

Updates

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’s like git and subversion, and lots of other things (cups, python, etc.). Only any packages of TeX is in its 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 elderlinux.org 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:

[e5-skel]
SigLevel = Never
Server = http://www.elderlinux.org/repos/e5-skel

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:4.1.5.1-6-i686.pkg.tar.xz
  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

New year – looking back at 2013

Happy new year 2014 everybody!

For me the second blogging year has passed and the third one stands at the door. A good opportunity to look back at what 2013 brought!

Last year went by quickly from my perspective. This was due to huge and time-consuming changes in my life. Still I managed to publish 22 posts in the last 12 month – probably not too bad.

Topics

While I had intended to simply continue with the toolkit specific application tests, I chose to open up the blog for more diverse topics. The blogging year started with a series of memory consumption tests of various Qt-based applications. Following Canonical’s announcement of Mir I simply had to write about the Linux desktop again.

Experimenting with various Unix-like systems beside Linux during that time I chose to write about that topic, too. And being an Arch user, it suggests itself to introduce the ArchHurd and ArchBSD projects

Next was an interesting interview with the developer of the FLTK-based Equinox Desktop Environment, just before the Blog’s first birthday post.

The second half of the year started with the first GTK+ application tests. Since there are just so many terminals around which are built upon this toolkit, this was quite a bit of work. For that reason I decided to postpone further GTK+ application tests – and in fact I haven’t had the time for them up to now!

A sample of what elderlinux.org currently looks like

An American programmer got in touch with me and we soon agreed to work together on some projects. This was the initial spark for me to seriously start working on an experimental i586 distribution. Due to it progressing nicely, I registered the domain elderlinux.org which is meant to be the future home of various things related to distribution creation. I hadn’t written any html for more than 10 years and it took me quite some effort to come up with something that doesn’t instantly make your eyes bleed. Unfortunately I don’t have the time to update the page regularly.

I had used ConnochaetOS in the past and was a bit sad to see it shut down. Since I was building an Arch-inspired i586 distro, too, I decided to blog about it before it would vanish. Development of that distribution effectively stopped in 2011 and A LOT has happened since then in the rolling-release world of Arch. This made a journey possible which was more like a time-travel. In a series of three posts I described how such an old system could be (partially) updated to meet today’s standards. I had actually also updated the kernel, bootloader and made the switch from the old init-system to systemd in my VM, but I had forgotten to take screenshots and didn’t find the time to write another post about it, anyway.

While the i586 distribution is generally in a pretty usable shape, the project has already become a bit too big. It currently has repositories worth of several GB of data – and I honestly have no idea how I could share this with others. I was playing around with several other things again, anyway. I decided to put this project on hold when I gave in to the idea of going just one step back: Building something that could be used together with a big distribution (Arch) instead of being completely incompatible with anything but itself. This eventually lead to the creation of Arch:E5 and the last blog post of last year.

A little bit statistics

This kind of retrospect posts wouldn’t be complete without a bit of statistic, would it? So here it comes! Each and every month has surpassed the previous peeks by far. The blog had about 1.000 hits in 2012 – and even if you take into account that I didn’t start to blog before late June, the > 6.600 total hits of 2013 were simply amazing!

The weekly hit statistic on 12/31/2013

The least successful month was January which just barely beat December 2012 with about 320 hits. There was one month (April) which scored a little lower and two which had significantly fewer hits than the previous month. The best one of the year was October with well over 750 hits! The new all-time peak of page hits occurred on 10/11 with 85 in one day!

The monthly hit statistic on 12/31/2013

My blog got even more hits from around the world. However the top countries didn’t change much, so I’ll skip the graphic for it this time. But here’s the map:

Hits by country

Due to the higher variety and new sub-projects some new tags have been added. However these were added to recently to carry much weight.

Tags and categories

Now for some very pleasant changes: I finally started receiving the first comments which are not spam! ;) And yes, I’m pretty happy about that.

Some comments at last!

For those interested in exact numbers (and to document these statistics for later), here’s a summary:

Monthly and yearly totals

Daily averages

Very suitable for the blog’s first birthday, it was this day that scored four trophies! The trophy case also holds medals for 10 followers and likes now, but I think this little graphic is even nicer:


Four trophies for EERIE on the blog’s birthday

Outlook

So what’s going to come this year? Well, who knows? Honestly: I don’t know. There are three things I intend to dedicate some time to: The GTK+ application tests, the Desktop Demo DVD and of course Arch:E5. But as the past year has shown there’s no chance to know before what exactly will happen. But that’s a good thing actually. So let’s just see what 2014 has in store for all of us!

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 (elderlinux.org), 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/libgmp.so.10.1.2 /usr/lib/libgmp.so.3

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?