Your daily nightmare with ABI_X86

Let's take a break here from the previous post. I don't know if you've read about it, but Portage (hence, Gentoo) is on its way to becoming a true multilib distro, the Gentoo way. This means that in the near future you won't need precompiled 32 bits libraries anymore (thus, effectively removing emul-linux-x86-* packages). This is a good thing...

... is it?

No, seriously, this is a good thing. Gentoo's philosophy of compiling and adjusting packages to your needs clashes with what we've had over the years in the emul-linux-x86 packages (not being able to change anything since they're precompiled binaries, having to wait for a new snapshot if something isn't working properly, etc.); so we're finally bringing the Gentoo philosophy to the multilib part. And this will apply not only to 32bits binaries from the x86 architecture. I've already seen hints of other ABIs for other archs.

This will be implemented with an expand USE: ABI_X86. All you have to do is define this in your make.conf:

ABI_X86="64 32"

Supposing you'll be wanting 32bits copies of any library that supports them so as to properly run e.g. wine. Another way is specifying individual USE for packages:

category/package abi_x86_32 abi_x64_64

However, the road is long and there are many perils. First of all, this is all in ~arch, so if you have a stable system, you can bother to read this when the ABI changes are pushed to stable, hopefully with more documentation. Second of all, if you have a completely unmasked system for ~, you won't notice any problems likely. The thing is, if you have a mixed system (stable but a few things unmasked). This is where all hell breaks loose.

I've already fought twice with this on my PC and one on my laptop, both mixed stable and ~ amd64 systems. Whenever I have one of these wrestling sessions with any of my Gentoo systems, I tend to work fast and loose, trying many things at the same time whenever possible. That is why I don't have a fixed walkthrough that can get you to this, but nevertheless my memory serves me right on some points which I'll write below:

• You will get many slot blocks the first time around (and probably most of the following times until you've fixed this). This is normal. Don't panic.
• Consider removing libreoffice, wine and your currently installed emul-linux libraries. You can install them again later.
• Unmask abi_x86_32 by putting the following into /etc/portage/profile/use.mask (seriously, I'm not joking you in this. I've spent three days fighting with my laptop until this solved everything. The creepy symptom if you don't do this is that most packages will build fine with the 32 ABI, but some Xorg libraries will refuse to merge, and will show 32 as hard negated in ABI_X86 ("(-32)"):

-abi_x86_32

• If this gets paired with a big world update (as is almost always the case with me and my systems), consider dividing the upgrade by sections and doing those sections first before trying to update world. As an example, on my laptop I first tried to upgrade kde-meta to the newest version and solved first the blockers for that package, before tackling world. This removes around ~300 packages from the world update afterwards.
• Whenever you have a slot conflict, this is due to the ABI change. Most of them can be fixed by individually upgrading the offending package to the newest version (keep in mind that most likely the newest version will be the one supporting the ABI changes. And also keep in mind that you might need to unmask said newest version of the package).

That's all I can remember for now. I seriously hope more documentation to come before the ABI move to stable. And I seriously hope noone has to go through this hell again.

Cheers!

Marrying SOGo and Gentoo: part 1

Long time no see! Since I've been away I've been fiddling with many many things (personal projects, life, etc.). One of my latest adventures was trying to make SOGo work on Gentoo. But first, a little bit of background:

My personal pain

6 years ago I was building my very first email server. It was not much but it is still working, albeit with a few modifications. I've kept postfix but replaced courier with dovecot for the IMAP part, and replaced MySQL with OpenLDAP for the authentication part. Back then one of the missing things was a calendaring solution to work on top of it. Keep in mind this was 2007.

There was no good solution available, given the self-imposed features that the system had to have in order to satisfy my needs:

1. It had to be FLOSS.
2. It had to work seamlessly with and reuse my current setup (no starting from scratch).
3. It had not to use Java.
4. It had to look like it was made after 1995.

#1 left most commercial solutions out and #2 left things like Kolab out. Meanwhile, #3 left Zimbra and OpenXchange out and #4 left Horde out.

Note: I did try to install Kolab one time in a VM. Let's just say the end result was not pretty at all.

Back in that day I found things like DAVical which at first glance seemed to work (basically it was DAV thru HTTP on a PHP webapp). Sadly, the state of PIM solutions at that time was not good (KDE4 was either coming out or had just come out, and GNOME had the ever-depressing Evolution). After several tries to make it work with my partner, we eventually gave up.

A sign of hope

A few months ago a colleague pointed me to SOGo, a solution which seemed to fullfil my criteria (it was FLOSS, it was not Java, it looked REALLY nice and it integrated seamlessly with an existing SMTP/IMAP/authentication backend). I decided to try it out...

... sadly, the ebuilds I found in the gnustep overlay were quite outdated. The last stable one was 1.2.6 (SOGo is now at version 2.0.7) and the live ones which point to their monotone server did not work (it seems their server falls down from time to time). I had to compile it by hand, for which SOGo provides some simple instructions. After editing SOGo's configuration file, which is also heavily documented (quite a bit hard to get the hang of GNUstep, but once you do it's simple enough), I had created a user which did not have a home directory. That kind of messed up starting SOGo.

I dug a bit more and created the needed directories by hand and fixed the permissions (remember: no initscript or anything):

# mkdir /var/spool/sogo
# chown sogo:sogo /var/spool/sogo
# mkdir /home/sogo
# chown sogo:sogo /home/sogo
# mkdir /var/log/sogo
# chown sogo:sogo /var/log/sogo
# mkdir /var/run/sogo
# chown sogo:sogo /var/run/sogo

Also, I found a nice Nginx sample configuration file which I used to proxy SOGo thru my web server (SOGo runs on port 20000 by default and is designed to work behind a web server). After enabling memcache (both the initscript and the Nginx module), I prayed and tested it...

... and it works beautifully. Next steps are making proper initscripts and conf.d files and after that proper ebuilds for SOGo and its main library, SOPE.

Stay tuned.