Here I'm republishing an old blog post of mine originally from February 2014. The article has been slightly improved.

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 the two previous posts first:

Announcing Arch:E5!

First public Arch:E5 repository published

An experimental Arch system

While a minimal working E5 system could be pacstrapped before since the time when the _skel_ repository was made available, it is now possible to install an E5 system 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 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 for 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 latter 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.

For install instructions see the previous post (linked at the top) and enable the _e5-default_ repository in addition to _e5-skel_.

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

Known problems

There are a few issues that I am aware of but didn't have 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 won'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 an 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 ahead!

BACK TO 2014 OVERVIEW