Planet Exherbo

May 27, 2018

Ali Polatel

alip's exherbo shortlog 20180527

Here is a summary of my recent Exherbo activity:

May 27, 2018 12:00 AM

January 13, 2017

Ali Polatel

Shell Meditation

Seek your music. As you please.

    while true; do
        (( z = ${RANDOM} % 100 ))
        (( a = $z % 10 ))
        mpc seek $z% &
        sleep $a
        kill $!

January 13, 2017 12:00 AM

Bright Side of the Moon

Quick Update: I have a flat! My German was barely enough to make it. Und zwar komisch. You get a flat on your birthday. Hard to say how it could get any fucking better than that.

Oh: Ev buldum lan. Na aşağıdaki! #direnkigülsünyüzün. Yolu düşen gelsin. Yoksa. Ayıp. Olur. Bana. Bak. Manifestolâmin.

Ay gidiyor

Last and least. Here is a poem and a song that describes everything so far. Life. is. just. pregnant.

Çağırın! Güneşin zaptı yakın! #martılaraselam #petşişeistemezük.



Hayali Ali, Çengelköy

drawing curtains
hiding fetus
behind venus
all Night long
let it flow
into snow
crystals in a row
mothers will bow
and swallow
their unborn babies!

Do the Evolution:

January 13, 2017 12:00 AM

January 03, 2017

Ali Polatel

Endgame Tricks

Chess endgames often look deceptively simple. Reduced number of pieces on the board brings reduced alertness to the player. Thus, it is not uncommon for the adversary to come up with sneaky ways to take advantage of this relaxed state. Thinking in terms of psychology, the most important feature of this relaxed state is the reduced feeling of danger which in turn leads to reluctance to justify moves with concrete variations. Even though, schematic thinking is an important feature of endgame technique, it has a psychological danger where player's reliance upon natural moves rather than logical ones can lead h/er to trouble when there exists a non-obvious nuisance in the position which establishes a significant distinction between the natural and the logical. At the end of the day chess is purely mathematics and the term natural is nothing but pattern recognition. Yet, no pattern is exactly the same.

One form of blunder which is very common to such a frame of mind is quiescence errors where the player is decepted by the natural aesthetics of a seemingly winning move sequence and fails to spot a trap which is no further than half a move away. The main reason of the blunder is psychological, the sudden change of excitement coupled with the reduced sense of danger literally blinds the player who could otherwise easily spot the problem with the move sequence at hand. Below is a simple, illustrative example of such an error. This is an online blitz game where I had the white pieces.

January 03, 2017 12:00 AM

December 27, 2016

Ali Polatel

Envtag 0.6

Envtag-0.6 has been released.

  • Fix alt_getopt and envutils for Lua-5.2 and newer.

tarball: envtag-0.6.tar.bz2
sha1sum: e1e1179198cab15717daea986f0a27cbe3a0e963

December 27, 2016 12:00 AM

December 26, 2016

Ali Polatel

Envtag 0.5

Envtag-0.5 has been released.

  • Add support for Lua-5.2 and newer.
  • Fix –delimiter option of get-xiph and set-xiph commands
  • Update alt_getopt to 0.7
  • Follow symlinks when determining filetype information using libmagic

tarball: envtag-0.5.tar.bz2
sha1sum: 04a8fb00cadd452899620bd168d36a6015b6b772

December 26, 2016 12:00 AM

March 13, 2016

Wulf C. Krueger

Gerrit updated to 2.12.2 / Jenkins updated to 1.652

I’ve updated Gerrit from 2.11.5 to the latest release 2.12.2. These are the user-visible highlights:

  • New Submit Whole Topic setting: All changes belonging to the same topic will be submitted at the same time. Currently disabled because it’s still experimental but I will enable this once it’s considered stable.
  • Support for GPG Keys and signed pushes. You can add your GPG key in Gerrit and git push –signed to use this. This should work right now – but doesn’t for me at least. If you have more success, let me know. :)
  • New search operators, e. g. author:, committer:, commentby: and a few others.
  • Your preferences for editing and diff presentation can now be configured in your user settings.
  • Gerrit’s in-line editor has now support for Emacs and Vim key maps.
  • There are several new API calls available for those using their own Gerrit clients (yes, I’m looking at you, Kylie McClain! ;-) ).

You can find the complete release notes for the Gerrit versions here:

Gerrit 2.11.6
Gerrit 2.11.7
Gerrit 2.12
Gerrit 2.12.1
Gerrit 2.12.2

As for Jenkins, I’ve updated it to 1.652 as well. Nothing spectacular there but some bug fixes in the backend mostly; including two security fixes.

The full changelog can be found here.

P. S.: If you’re from Germany, specifically from Baden-Württemberg, Rheinland-Pfalz or Sachsen-Anhalt: STOP READING THIS AND GO TO CAST YOUR VOTE. I did.

P. P. S.: If you (want to) vote for the AfD or other fascist parties: Please let me know. I like to know my enemies.


by Wulf C. Krueger at March 13, 2016 03:19 PM

October 27, 2015

Wulf C. Krueger

“Where have you been?!”

As many of you will have noticed, I’ve been “gone” for almost two months. To some of you, I’ve explained my absence but I’d like to present a “compact” version here as well.

As many of you know, I’ve been the head of my department at work last year. Due to problematic circumstances beyond my control, I decided it best for me to formally resign from said position effective December, 31st 2014.

Fast-forward to mid 2015: A new head of department has been installed. Naturally, I’m her deputy. The “problematic circumstances” mentioned above have gone even more “challenging” by now. Both my new team lead and I do all we can for everyone involved.

Mid September 2015 – things get rougher for a lot of reasons. The team lead goes on extended holidays and I’m taking over. There are lots of things to do and way too few hours in a day to work on them – even for a highly skilled and systematically working professional like myself.

I’m working very long each week (I won’t mention how long exactly to avoid all kinds of trouble :) ) and, thus, have to cut down on all other activities and since Exherbo is the most time-consuming one, it’s the first (but not the last) to suffer from that.

By now, I have a few effective methods (and professional help) to avoid a burn-out, etc. and so, now that my team lead is back at work, things should slowly be going back to normal. Which – as you can see – effectively means: I’m back. :-)


by Wulf C. Krueger at October 27, 2015 01:52 PM

September 01, 2015

Wulf C. Krueger

Jenkins updated to 1.627

Another quick news blurb: I’ve updated Jenkins to 1.627. It has a few bugfixes but nothing really spectacular.

The full changelog can be found here.



by Wulf C. Krueger at September 01, 2015 12:29 AM

August 30, 2015

Wulf C. Krueger

Gerrit updated to 2.11.3 / Jenkins updated to 1.626

I’ve just updated Gerrit to the latest release 2.11.3. These are the user-visible highlights:

  • When you choose a user (e. g. to add a reviewer) inactive accounts are not suggested anymore.
  • If you use side-by-side diffs (why ever would you?!), their performance has been improved
  • If your browser supports the JavaScript clipboard API (e. g. Chromium does) that’s preferred over the old Flash widget.
  • Quite a few bug fixes.

You can find the complete release notes for Gerrit 2.11.3 here.

As for Jenkins, I’ve updated it from 1.623 to 1.626 as well. Nothing spectacular there but some bug fixes in the backend mostly.

The full changelog can be found here.

by Wulf C. Krueger at August 30, 2015 02:06 PM

August 08, 2015

Wulf C. Krueger

Jenkins updated to 1.623

Quick news blurb: I’ve updated Jenkins to 1.623. It has quite few bugfixes but nothing really spectacular.

The full changelog can be found here.



by Wulf C. Krueger at August 08, 2015 09:37 AM

July 14, 2015

Wulf C. Krueger

Gerrit updated to 2.11.2 / Jenkins updated to 1.620

This morning, I’ve updated Gerrit to the latest release 2.11.2. These are the user-visible highlights:

  • Automatic suggestions in the search box work again.
  • Several issues that could potentially cause data loss have been fixed.
  • Newer jgit version

You can find the complete release notes for Gerrit 2.11.2 here.

As for Jenkins, I’ve updated it from 1.617 to 1.620 as well. Lots of bugfixes were implemented the most interesting of which concerned the console (log) output that could get truncated.

The full changelog can be found here.


by Wulf C. Krueger at July 14, 2015 03:03 PM

Gerrit updated to 2.11.1

I’ve just finished updating Gerrit to the latest release 2.11.1. These are the highlights:

  • You can now link accounts to each other (Settings / Identities / Link Another Identity). This means, if you want to be able to use both Github and Google, just use that button.
    Furthermore, if you accidentally create a new account (you’ll know it happened if you can’t +2 changes for your own repository anymore), you can now just link both yourself.
    If things still somehow go wrong, just let me know and I’ll link your accounts manually.
  • Performance improvements for pushing changes to Gerrit and some other areas
  • Newer jgit version
  • Lots of bugfixes

You can find the complete release notes for Gerrit 2.11 here.



by Wulf C. Krueger at July 14, 2015 02:50 PM

May 08, 2015

Wulf C. Krueger

Gerrit updated to 2.11 – being in-line, changing change screens and the return of the king!

I’ve just finished updating Gerrit to the latest release 2.11. This gives us some amazingly cool new features to play with:

  • The Return of The King or: The Empire strikes back! Authentication using Google’s Oauth2 is supported now. When logging in, you can choose between github (the preferred supplier) or Google.
    (This is going to change once more this year and then hopefully never again. User accounts have been preserved now, though, and will be preserved when I’m done with the authentication changes I’m preparing.)
  • Gerrit is now back where it belongs – in Tomcat. That makes it faster and more reliable.

You can find the complete release notes for Gerrit 2.11 here.


by Wulf C. Krueger at May 08, 2015 05:44 PM

May 07, 2015

Wulf C. Krueger

Gerrit update tomorrow

Just a short heads-up: I’m going to update our Gerrit installation tomorrow so please expect some downtime.


by Wulf C. Krueger at May 07, 2015 05:23 PM

April 06, 2015

Wulf C. Krueger

The Great Merge II: Exherbo’s multi-arch/cross implementation has been merged to master

Exherbo’s multi-arch/cross implementation1 has been merged to master.

You WILL have to migrate to this new setup in order to be able to
install new software and updates.

You’ll find the migration guide at 2. Make sure to follow it VERY
closely because getting things wrong does have the potential to break
your system. (You’ll of course be able to access your data via a rescue
system if everything goes wrong. We’re changing the base system but are
NOT touching user data.)

If you don’t want to migrate right now, you shouldn’t update or install
ANYTHING anymore until you are ready to do so.

The last commit prior to the migration has been tagged as “pre-cross” in
all official repositories so that you can stick with that if need be.
If you wish to stay on the pre-cross revision, you need to set
“sync_options = –revision=pre-cross” in the repository’s configuration

If you do migrate (which you should), you’ll find that some packages
might not yet install. As always, you’re fully expected to help with
migrating exheres to the new base system which basically involves
undoing our former multi-lib approach. You’ll find more details at 3
and you’re, of course, encouraged to look at recent commits that mention
“multiarch” or “cross” for tips on converting other packages.

Furthermore, we have no control over 3rd-party/unofficial repositories.
While quite a few of them feature a “cross” branch right now, they might
not have been merged when the official repositories were.
Thus, you might have to add “sync_options = –branch=cross” (without the
quotation marks) to the respective repository’s configuration until the
maintainer has merged the cross branch into master.

by Wulf C. Krueger at April 06, 2015 12:08 AM

April 04, 2015

Ciaran McCreesh

Paludis 2.4.0 Released

Paludis 2.4.0 has been released:

  • Bug fixes.
  • We now use Ruby 2.2, unless –with-ruby-version is specified.

by Ciaran McCreesh at April 04, 2015 11:55 AM

Wulf C. Krueger

Cross/multi-arch: Get going! Merge date: TOMORROW, Sunday, April 5th 2015

I’d like to remind everyone that we are going to merge all the cross branches to their respective master branches

TOMORROW, Sunday, April 5th 2015!

Whatever you’re doing Exherbo-wise, please DROP IT for the moment and help us get more packages ready!

Migrating exheres to the new base system isn’t (most of the time) complicated: It basically involves undoing our former multi-lib approach. You’ll find more details here and you’re, of course, encouraged to look at recent commits that mention “multiarch” or “cross” for tips on converting other packages.

You may, of course, test cross-compilation to something but what’s REALLY important is that the package works on a NATIVE system, e. g. boost does work natively but fails at cross-compilation currently. For now, that’s ok.

If you want to convert packages in a third-party repository that doesn’t have a cross branch yet, please get in touch with me – I can create cross branches for EVERY repository in Gerrit.

To get started:

So, go for it!

(And always remember: My statistics will record your fabulous work for generations to come who will sing the praise of the immortal heroes who made cross work! ;-) )

(Questions? -> #exherbo)

by Wulf C. Krueger at April 04, 2015 10:04 AM

March 24, 2015

Wulf C. Krueger

January 17, 2015

Wulf C. Krueger

Gerrit: Update to 2.10-rc1, GitHub, OpenID & other stuff

As you will have noticed, after a hard crash and failed efforts to restore the existing Gerrit, it had to be re-installed from scratch. With it, some changes had to be made:


  • OpenID is no longer available for authentication as Google is deprecating it.
  • GitHub is now used for authentication. So you must have an account there.
  • cgit is integrated into Gerrit and can be used stand-alone as well.
  • All repositories had to be re-imported. If you have a repository in Gerrit, please contact zlin (via IRC or email) or myself (via IRC or email) to get your permissions set up again.


I’ve updated my post Gerrit Code Review for Exherbo as well.


P. S.: Due to being ill, I might not be available.

by Wulf C. Krueger at January 17, 2015 06:44 PM

Quick information: Jenkins’ build scripts are in git and Gerrit

Just a small update today: You can find my build bash scripts for Jenkins in git and Gerrit now.



git clone



Please submit patches via Gerrit.

by Wulf C. Krueger at January 17, 2015 02:55 PM

December 19, 2014

Mike Kelly

Any good perl or FreeBSD books?

I'm starting to learn perl, and I've found the perldoc intro/tutorial stuff to be pretty useful, but I'd like to get a good printed book or two to read through and use as a reference.

Similarly, while I'd say I'm pretty *NIX savvy, I'm not too familiar with some BSD-isms, particularly where they differ from Linux. Are there any good books out there to help with the transition from Linux to FreeBSD? (No, I'm not abandoning Linux... it's just that my current employer used FreeBSD for many things.)

Any suggestions?

by Mike Kelly at December 19, 2014 08:16 AM

Encrypting (almost) your entire hard drive with dm-crypt (LUKS) and lvm2, Part 2

Six months ago I posted an outline for encrypting your system with LUKS. Well, I figure it's about time for me to write up how to actually go about it. In this post, I'll outline the necessary kernel configuration.

The basic kernel configuration that I mentioned a long time ago still holds. Basically, you need to have the following options built into your kernel: CONFIG_DM_CRYPT, CONFIG_CRYPTO_CBC, CONFIG_CRYPTO_SHA256, and CONFIG_CRYPTO_AES. Most of those will be turned on when you enable:

Device Drivers ->
  Multiple devices driver support (RAID and LVM) ->
    Device mapper support ->
      Crypt target support

However, the SHA256 support will not be. It can be found at:

Cryptographic API ->
  SHA224 and SHA256 digest algorithm

On the note of kernel configuation: for this process, you will need to do a fair amount of work from within another linux environment (most likely a LiveCD). For Gentoo, the most recent CD image I've found that has all the necessary configuration is the 2006.1 version... As I recall, some of the intermediate minimal CDs, at least, didn't possess cryptsetup at all. And the most recent weekly build I tried, while it did have lvm and cryptsetup installed, didn't have CONFIG_CRYPTO_SHA256 either built in, or as a module.

Probably the best bet is an Ubuntu 8.10 Alternative CD. You'll have to either boot in recovery mode, or go through a bit of the installation procedure, as it doesn't initially have cryptsetup available. But, once it's detected the CD and loaded the modules from it, you can just switch to another virtual console and do things from there.

Next time, I'll outline creating the disk partitions.

by Mike Kelly at December 19, 2014 08:15 AM is Moving

All of is moving to a new server. To start things off, I’m locking my blog read-only. If you want to keep track of all this, Paludis ticket #582 has the details.

by Mike Kelly at December 19, 2014 08:14 AM

Disk encryption w/ dm-crypt (LUKS) and lvm2, part 3

Last time I kinda cheated and gave pretty much a redux of an earlier post. This one will hopefully have some more substance to it.

The partitioning scheme I'm currently using is like this:

/dev/sda1 - /boot (ext2)
/dev/sda2 - LUKS encrypted lvm2 physical volume

The /boot partition is created like any normal ext2 partition.

The sda2 partition is created like so:

cryptsetup luksFormat /dev/sda2

This usually is sufficient to provide decent encryption, but it is worth checking the documentation for cryptsetup to look for further options -- in particular, the option to use a keyfile.

Once we formatted this partition, we'll need to open it, so that we can then add our lvm pv to it:

cryptsetup luksOpen /dev/sda2 sda2_crypt

We'll now have a new device available as /dev/mapper/sda2_crypt. This can be treated just like any other block device -- we could just format it as a regular ext3 partition, but then we can't really ever resize it. So, we're going to make a LVM2 partition:

pvcreate /dev/mapper/sda2_crypt

Now, we create a volume group. I choose 'Exherbo' as the name, but you can really just use whatever (often people just use 'vg').

vgcreate Exherbo /dev/mapper/sda2_crypt

Now, we just need to make our partitions:

lvcreate -L 1G -n swap Exherbo
lvcreate -n root Exherbo
vgchange -a y

This creates a 1G swap partition, and uses the rest of the space for our root (/) partition. Again, see the documentation for lvm2 for more options.

Finally, we need to format those partitions:

mkswap /dev/mapper/Exherbo-swap
mke2fs -T ext3 /dev/mapper/Exherbo-root

Next time, I'll go over how to boot this system.

by Mike Kelly at December 19, 2014 08:13 AM

My random old scripts moved to git

So, I had a few random old scripts lying around in SVN. I've migrated them to git now. Along with my other repos, they're browseable at

Things of interest might be:

  • rbtpb - A replacement for tpb which is hopefully more robust.
  • rubeak - A tool for handling multimedia keyboard keys, and some IR remotes.

Update: fixed links.

by Mike Kelly at December 19, 2014 08:11 AM

Encrypting (almost) your entire hard drive with dm-crypt (LUKS) and lvm2, Part 1


About five months ago, I wrote about how to convert an existing Linux install from using regular partitioning to encrypted volumes (in particular, an encrypted /home with an unencrypted /). That sort of setup is relatively simple, once you have all the partitioning done. There is no need for any special early userland stuff (an initramfs image). However, that approach only provides a relatively minimal level of security for your data -- someone could still root your system.

For those who are a little more paranoid (especially in light of some recent news), the next level of security for your data is to encrypt everything except your /boot partition.

Going to this level, you're going to be repartitioning pretty much your entire hard disk, so you might be best off just backing up everything (you should do this in any case), and reinstalling your system.

Some recent Linux installers make this sort of setup relatively pain-free. For example, Ubuntu 8.04's Alternative install disk gives the option of setting up an encrypted LVM volume to install the system on during its guided partitioning wizard. This is a rather easy way have your laptop's data securely encrypted quickly. However, with this setup, I wasn't able to get suspend-to-disk support to function properly (though I'm sure it could be done with a little extra effort, I don't know if most Ubuntu users would be willing to do so).

However, this guide is focused on the crowd of people who use distros that do not make this easy. For myself, I'm installing Exherbo during this guide, but the instructions should be almost exactly the same for Gentoo, or most any other distro.

Partitioning Overview

For this first step, you will need to create two standard disk partitions. The first should be only 32M or so in size -- this will be our /boot partition, and should probably be ext2. The second will be the rest of the space you wish to devote to this Linux install (in my case, 10G).

The final layout of everything is going to be like this:

/dev/hda1 - /boot
/dev/hda2 - dm-crypt encrypted volume, containing one lvm2
  physical volume

/dev/mapper/hda2_crypt - what we get when we run cryptsetup luksOpen
  on hda2, contains one lvm physical volume, containing the volume
  group "vg"

/dev/mapper/vg-swap - our swap partition
/dev/mapper/vg-root - our root partition

With this layout, all our data that can be encrypted / lvm-ized is. And we only need to enter our disk decryption key once to get to all of it.

Next Time...

In my next few posts, I'll go into more details about how to set this partition scheme up, how to configure your kernel, and how to create the necessary initramfs image to boot from an encrypted / partition.

by Mike Kelly at December 19, 2014 08:07 AM

Disk encryption w/ dm-crypt (LUKS) and lvm2, part 4

Previously I described how to partition your drive using LVM2 and dm-crypt. This time, I'm going to go over how to boot this system.

First off, you're going to want to have your livecd handy, because it's likely something won't quite be right the first time around. Also, you'll want to make sure your kernel is built with support for initramfs. This requires the BLK_DEV_INITRD configure option, named "Initial RAM filesystem and RAM disk (initramfs/initrd) support" in the "General setup" menu. You'll then need to specify the location of a source file for the initramfs.

Probably the easiest thing to do is to grab my current initramfs package and tweak it to suit your needs. You'll at the least need to change some paths in the config.txt and init files. But, it should serve as a good starting point. When you're done, put the path to the config.txt file in the "Initramfs source file(s)" (CONFIG_INITRAMFS_SOURCE) setting in the kernel.

Now, rebuild and reinstall your kernel, reboot, and pray.

I hope this will help people improve their laptop's security. Feel free to post any questions you have in the comments. Good luck!

by Mike Kelly at December 19, 2014 08:05 AM

Migrating from Typo to Movable Type

I migrated my blog from Typo to Movable Type a while ago. I wrote a little script to do it, but I've only just now gotten around to cleaning it up enough so that it's suitable for general use.

It's available now from my git repo, and on CPAN

As always, "patches welcome".

by Mike Kelly at December 19, 2014 08:03 AM

Exherbo: Myths and Facts

So, some people seem to have gotten all in a tizzy about Exherbo. While I don't personally think the wording on the front page is necessarily the best, here's the deal:

  • We don't hate you. We just know we don't quite have something ready for general use. Rather than deal with many users wanting to try out something that most likely will not work for them, we have attempted to dissuade people from trying Exherbo until we think it's ready for them to.
    • "Then why announce it?" Because Bryan is going to discuss it at an upcoming conference, so we decided we should have some sort of web page up. We didn't put it up on Slashdot, though.
  • This isn't Ciaran's brainchild. It's Bryan Østergaard's (aka kloeri). Yes, Ciaran is involved in the project, along with a number of other former Gentoo developers, but he isn't the "lead" (though I don't think we really formal roles at this point).
  • "Why don't you use...?" We've already looked at many existing projects to fill some of the spots we've decided to fill ourselves instead. For example, we took a look at upstart, Gentoo's baselayout 1.x, openrc, etc. However, none of them seemed to do quite what we wanted. That's why we're working on projects like genesis, why we're writing our package tree from scratch, and using our own package format.

So, I hope this helps to clarify things for some people who still seem to be confused as to what Exherbo is all about.

Update: fix links.

by Mike Kelly at December 19, 2014 08:01 AM

Random Perl Hacking

My day job mostly involves Perl, so I've been using it more for my random tasks at home. I've now put a few of them up on CPAN:

  • Unix::Uptime - Determine the current uptime, in seconds, and load averages, across different *NIX architectures.
  • Remind::Client - class for working with remind's daemon mode

I also have a few other scripts I've been messing around with, for doing some reporting and such:

by Mike Kelly at December 19, 2014 07:57 AM

October 01, 2014

Ciaran McCreesh

Paludis 2.2.0 Released

Paludis 2.2.0 has been released:

  • Bug fixes.
  • Compilation fixes for Clang.
  • Added ‘cave resolve –chroot-path’.
  • Removed the “breaks Portage” feature.

by Ciaran McCreesh at October 01, 2014 06:05 PM

June 27, 2014

Wulf C. Krueger

Server update: Gerrit, Jenkins & friends (some downtime today)

As some of you will have noticed, my server has had some performance issues lately. Testing patches with Jenkins could take a long time, building stages was taking up to 20 hours (!) instead of the normal two and Gerrit itself could be slow at times as well.

This was due to aging hardware (that server was assembled in 2010), one horribly performing hard disk and constant over-heating of the machine. I’ve changed a few things over the last few days and performance is much better now but still not to my satisfaction.

Today, I’ve finally had enough of squeezing performance out of rotting hardware and simply ordered a new server. Functionally, it will be identical to good old galileo but on beefier hardware, especially with much more RAM (48 GB instead of 12 GB) which is essential for my uses.

While I’m writing this, I’m copying over the entire galileo to the new server which will hopefully be finished in a few hours from now. Once that’s done, I’m going to

  • shut down all non-essential services on galileo (that includes Gerrit, Jenkins, the bots and lots of other stuff),
  • re-sync the data to the new server,
  • change the DNS records,
  • fire up all current services on the new server,
  • rejoice!

(N. B.: Should you think I’ve forgotten something important here, please comment while you still can. :-) )

This update will, thus, cause some downtime (there was some earlier today already when I was preparing the migration). So don’t be alarmed if all services (including my IRC bouncer :-) ) are gone for a while – we’ll be back!

Ideally, you’ll only even read this post when all is over. :-)

by Wulf C. Krueger at June 27, 2014 04:09 PM

May 07, 2014

Wulf C. Krueger

Stages – some changes

As most of you know from my earlier stage building post, our stages for amd64 and x86 are being built automatically using Jenkins. And that won’t change.


Recently, there has been a discussion about adding Emacs to the stages in addition to vim. The reaction was overwhelmingly negative; even more so than I had expected.




  • I’m the one who spends his time and actual money on building stages, deploying them to, dealing with fall-out from changes, etc.,
  • there’s no real argument against adding Emacs but “it’s not POSIX!” and “stages should be minimal!”, “only having Vim is a nice filter against the kind of user we don’t really want anyway”, “use the editor outside the stage”, etc.
  • people are told to use e4r, which stands for “editor for retards” and is neither Emacs nor vim and, thus, doesn’t fix the problem,


… this is what I’ve changed effective by May, 7th 2014


  • I’ve added Emacs to the stages I build unilaterally (the first stage with Emacs included will be built on May, 8th 2014),
  • I’m not going to change the stages set because that would influence any stages not built by me,
  • I’ve stopped deploying the stages I build to (the last stage I deployed there is of May, 7th 2014),
  • The stages I build will always be located at (where they’ve been since I started building them),
  • I’ve added the link to the stages on my server to the install guide as an alternative.


In consequence…


  • if it is that big a deal that Emacs will be included in my stages, someone else will have to build official stages manually,
  • if it’s not that big a deal, our core devs can say so on our mailinglist and I’ll gladly revert things to how they were – just with Emacs in the stages set.


by Wulf C. Krueger at May 07, 2014 09:12 PM

April 21, 2014

Wulf C. Krueger

Exherbo’s Gerrit for 3rd party repositories

Exherbo’s Gerrit has left its infancy and, thus, I can now add 3rd party repositories to our Gerrit installation. Please just let me know if you’d like that.

  • Requirements:
    • Your repository must use git.
    • You must have an account in Gerrit.
    • You must be willing to add a Gerrit user (github: Gerrit-Exherbo) to your repository as a contributor.  Here’s the public key. (You don’t need the public key for github; if you’re unsure, you most likely don’t need it.)
    • Your repository should be hosted on one of the big git hosting providers, e. g. github (preferred) or gitorious. Ask me if your repository is hosted elsewhere; I do make exceptions.
    • Please let me know the push URI for your repository.

Once I’ve set you up, you can immediately work on Gerrit patches for your repository. You are, of course, its sole owner and fully responsible for it.

By default, Exherbo’s core devs (but nobody else unless you explicitly ask me to add someone) will be able to +2 Gerrit changes for your repository, too. This is meant to potentially help you keep your repository up to date (e. g. when mass changes occur). This is entirely optional, though, and you can choose to opt-out at any time if you don’t like it; you only need to let me know.

by Wulf C. Krueger at April 21, 2014 11:28 AM

April 16, 2014

Wulf C. Krueger

Miscellaneous Updates to Gerrit, Jenkins & friends

Over the last few weeks, I’ve made a few changes to Exherbo’s Gerrit and Jenkins installation:

  • Build artifacts are stored in Jenkins:

    If a build is unsuccessful, the Paludis build log, config.log (if it exists) and the cave-resolve command used are stored. Since build artifacts are associated with a project (i. e. the repository) and not individual builds, the files have the build number prepended in their file name:

    If a build is successful, only the cave-resolve command and the detected dependencies are archived:


    This change is effective immediately for all exheres repositories in Jenkins. If you have further suggestions of files to archive, please let me know.


  • Due to the recent OpenSSL Heartbleed bug issue, I’ve re-issued the SSL certificates on my machines on April, 11th 2014. If you have a password login on galileo, now is the time to change it. For, the host key fingerprints are as follows:

1024 a8:8c:7d:87:3d:a6:61:78:8d:59:f5:52:d7:b1:3c:34 (DSA)
256 f1:08:b0:12:66:1c:72:af:2d:d8:c7:15:ca:13:f6:f2 (ECDSA)
256 68:1c:27:e2:8e:b5:42:62:98:8a:f3:04:45:c1:60:f9 (ED25519)
2048 37:38:6e:81:4a:53:24:4d:b0:fb:c7:3e:f0:1d:63:8c (RSA1)
2048 06:57:ff:b7:e6:6f:c8:31:76:c8:9a:7c:37:d7:f5:47 (RSA)

The web server’s certifacte has the following fingerprints:
  • SHA-256 Fingerprint:
    85 3D 47 8B A5 44 76 A0 09 96 9F 15 4A 9A F8 C5 1C 95 D1 1D 92 4E 78 06 0D F6 E5 7B 1B C5 B2 07
  • SHA-1 Fingerprint:
    0D E8 77 4F 74 67 AB 61 12 97 A5 57 84 1F B4 51 C1 1D D4 19


  • Gerrit was updated to version 2.8.4. There are quite a few bug fixes in the release notes but probably most important for those of you who experienced issues with the side-by-side diff view in the new change screen are the fixes they applied to it.


There’s more to come but that’s going into another post. :-)

by Wulf C. Krueger at April 16, 2014 01:18 PM

March 05, 2014

Wulf C. Krueger

Re-testing patches in Gerrit with Jenkins

A recent request concerned the possibility to re-test patches patches in Gerrit with Jenkins. I’ve now added a very simple switch for that:

In any given given change (but your own!), you can add a comment with “+1 Retest” set as a “verdict”. On the old change screen (really, change to the new one, it’s much nicer), it looks like this:

Retest: Old change screen


On the new change screen, it looks like this:

Retest: New change screen

It’s really, truly easy. You can even do it multiple time – just uncheck the “Retest” checkbox (new screen) or set “0 Retest” (old screen) first and then set it again.

This works for any change as long as you are a registered user – any change but your own. Unfortunately, the Jenkins’ Gerrit-Trigger plugin simply ignores the “CommentAdded” event completely for ones own changes. If you want those re-tested, just amend your commit (no need to actually change anything; the commit timestamp will be updated) and Jenkins will see the patch’s new revision and re-run the test.


On a side note, I’d like to apologise for the instability for about 1,5 days earlier this week. There were some really nasty hardware/software issue that I had to sort out. This is done now, though, and things are running smoothly again.


by Wulf C. Krueger at March 05, 2014 06:13 PM

February 27, 2014

Wulf C. Krueger

Automated stage building with Jenkins

For quite some time now, I’ve been working on the automatic creation of Exherbo stages for AMD64 (x86_64) and X86 using Jenkins.

Till now, Exherbo’s stages were created manually by one of us Exherbo core developers and usually basically “on-demand” or when they were major changes. This finally changed yesterday.

Using the jobs stage_amd64 and stage_x86 respectively, the stages…

  • are built using a modified stage building script – each stage is build from scratch. The latest stage gets unpacked and used to build a new one. I call this: Implicit pro-active quality assurance. No pbins are used in the entire process. Everything is fresh and new, just for you.
  • the sources are kept right next to the stages at You can see right there what sources were used.
  • the XZ archive is added to the job (the most recent ten stage archives are kept on their respective job). Like this, you can always check the exact build log for the stage you want and rest assured both are right there at your fingertips.
  • next, the successfully built stage is deployed to is undergoing maintenance but you really want your Exherbo? Download a stage from this alternative location, sync your repositories from Gerrit and you’re unstoppable!
  • and finally automatically transferred to our traditional where some “extra magic” is performed by Jenkins that creates the “current” symlinks, updates the checksum files, etc.

And this happens every single day. The entire process is completely scalable as well – once the cross stuff is production-ready, I’m going to build ARM stages as well and it will be done by simply copying a Jenkins job and changing a few lines. A milestone for Exherbo.

We just made major changes? Wait a few hours, get them in your stage for your new Exherbo installation.
You somehow got a broken stage? Use an older one, compare them, go nuts with them. There are always at least 10 stages per architecture to choose from.
And if a stage fails to build? Well, the next day it will be fixed because we’re watching over the entire process.

Isn’t this incredibly awesome?

And you can even play a round of Bullshit Bingo using this very post! ;-)


by Wulf C. Krueger at February 27, 2014 08:58 PM

February 23, 2014

Bryan Østergaard

So I was dox'ed yesterday

and nobody gives a fuck.

Here's the associated spam:
14:53 < ~dd0sb0ss> rip
14:53 < ~dd0sb0ss> PARTY AT Vølundsgade 31, 3. th. 2200 København N
14:53 < ~zsasz> ur unicode is broken dd0sb0ss
14:53 < ~dd0sb0ss> fuq
14:54 -!- dd0sb0ss was kicked from #freenode by kloeri_ [dd0sb0ss]

Ignoring the broken unicode that's actually the correct information. Well done on finding this information that has been publically available (by my own choice) for several years.

It's never been hard to find me and that's not changing in the future just because of some silly kids either. Unlike these kids I'm actually proud of what I do and I'm more than happy to stand by my actions with my real name and even address widely available.

And for all those sensible people out there just shaking your heads at this sillyness - you're welcome to visit, especially if you are interested in open source software or need a consultant on some project :) I'd suggest contacting me by email first though.

PS. Thanks to GNAA for this obvious advertising opportunity.

by kloeri at February 23, 2014 08:49 PM

January 03, 2014

Wulf C. Krueger

Jenkins: Build-testing for every single commit

As of yesterday, I’ve drastically increased the number of testing machines in Jenkins (from two to 21!). This enables me to poll for changes in git every five minutes and automatically start a testing run for every single commit – regardless of it entering via Gerrit or not. (Note: This is in addition to the Gerrit trigger I’ve been using from day one on, not replacing it.)

Here’s an example from today:

Apart from looking at Jenkins directly, you can join the #exherbo-bots channel where the jenkins-exherbo bot announces all test results. Here’s an example for that:

[03.01.2014 13:42:59] <irker657> Exherbo: pipping arbor:master * 76ec9309669d / packages/sys-apps/grep/grep-2.15.exheres-0 packages/sys-apps/grep/grep-2.16.exheres-0: grep: Bump to 2.16
[03.01.2014 13:46:50] <jenkins-exherbo> Project arbor build #67:SUCCESS in 1 min 5 sec:

I hope you’ll find this useful and will actually look at the results since it will find out if you missed a dependency. And it potentially shows you automagic dependencies.


by Wulf C. Krueger at January 03, 2014 04:29 PM

Version bump to systemd-43 / Move to /usr

(This is the same as the news item but I want this to get maximum exposure.)

Read ALL of this, it’s important to everyone using systemd.

Up to systemd[=42] we installed boot-critical components to / and others to /usr. This split was causing issues with respect to tmpfiles, intrinsic dependencies and dependencies on stuff on /usr.

systemd[=43] finally removes this split and installs everything but udev and pam stuff to /usr.

This won’t matter much to you if you don’t have /usr split from / (it should not be split; cf.

Even if you don’t have /usr != /, you need to update all packages that install to /${LIBDIR}/systemd/system because that got moved, too, of course. I’ve rev-bumped all packages, that install their own custom systemd units but even after you’ve updated those, you’ll still have some in /${LIBDIR}/systemd/system. Find out which package they belong to (use cave owner) and re-install them.

Should you forget to do so, you might end up in systemd’s emergency mode. If that happens, don’t panic. Get your network connection up and continue updating/re-installing. You’ll live, I promise.

There might be orphaned systemd units left behind. Check those on your own and decide if you need to move them to /etc/systemd/system. If you do, don’t forget to systemctl disable and then enable them.

You’ll also have some broken symlinks in /etc/systemd/system pointing to /${LIBDIR}/systemd/system. To fix those, all you have to do is disable and re-enable the respective unit. Here’s how to do it quickly and easily:

for link in $(find -L /etc/systemd/system -type l); do
systemctl disable $(basename ${link});
systemctl enable $(basename ${link});

Final sanity checks:

1. Is /${LIBDIR/systemd gone? If so, carry on; if not, you missed a step. Go back and find out which one.

2. No broken symlinks in /etc/systemd/system anymore? (“find -L /etc/systemd/system -type l” doesn’t output anything) If so, carry on. Otherwise, you missed a step. Go back and find out which one.

If you do NOT have /usr separated from /, you’re done now and it should be safe to reboot if you so desire.

If you do have /usr separated from /, you’ll have to use an initramfs (preferrably created by dracut) for booting from systemd[=43] onwards.

The first step to using an initramfs is enabling CONFIG_BLK_DEV_INITRD in your kernel, recompiling and installing it. If you want to switch from a custom initramfs to dracut, don’t forget to empty CONFIG_INITRAMFS_SOURCE in your kernel configuration either if you have been using it before.

If you want to use dracut (sys-boot/dracut[>=14]), install it and add


to /etc/dracut.conf. If you have some weird configuration, you might need to add further dracut or kernel modules. In general, though, dracut is going to pick up everything you’ll need to boot.

Now run dracut to create your shiny new initramfs:

dracut -H <initramfs filename incl. path> <kernel version>

e. g.

dracut -H /boot/init-3.2.5.gz 3.2.5-00001-gf74dd96

-H (or –hostonly) tells dracut to build an initramfs for the machine it’s running on. Leaving it out should create a HUGE generic initramfs that should bascially be able to boot everything. In reality, leaving -H out usually builds something that doesn’t boot anything.

Next, update grub’s config so that it includes a root= parameter for the kernel command line and your new initramfs, e. g.:

(for grub-0.9x’s menu.lst)
title Exherbo Linux
root (hd0,1)
kernel /kernel-3.2.5-00001-gf74dd96 root=/dev/primary/uselv
initrd /init-3.2.5.gz


(for grub-1.9x’s grub.cfg)
menuentry “Exherbo Linux” {
set root=(hd0,1)
linux /kernel-3.2.5-00001-gf74dd96 root=/dev/primary/uselv
initrd /init-3.2.5.gz

Do NOT forget the root= parameter. It’s essential.

(Of course, you need to adjust paths and filenames to your setup but if I need to tell you that, you shouldn’t be using Exherbo in the first place.)

If you’re using a custom initramfs, you must make sure that you mount /usr as early as possible but definitely before systemd (/sbin/init) starts. If you’re rolling your own initramfs, you should know how to accomplish that.

After you’ve updated your grub configuration, systemd is updated and your kernel is ready, too, say a little prayer ;-) and reboot.

Best regards, Wulf

by Wulf Krueger at January 03, 2014 12:56 PM

Samba has no maintainer on Exherbo any more

After having worked with Samba for almost 20 years, I'm giving up now.

I have submitted patches upstream when Samba (and I :) ) was young,
I've proof-read books on Samba and NTLM but where they're going, I
can't follow them any more.

- Samba 4.1.0 doesn't even build for me any more and I'm too
frustrated to figure it out.

- In Samba 4.1.0, SWAT (the configuration web interface) seems to have
been removed. I might be missing something but if I'm not, that sucks.

- Samba's "new" crappy build system WAF is just horrible and I simply
don't understand it. I asked for help (and it was offered) but nothing
was ever done.

- New versions of Samba 4 try to build against already installed
versions in the live filesystem and I don't understand WAF enough to
fix that.

I've just removed myself from BUGS_TO. If you want it, take it but if
you do, do me a favour and do a better job than me and make sure
you're weird enough to understand (and ideally like) WAF.

by Wulf Krueger at January 03, 2014 12:55 PM

Exherbo’s Patch Queue

Today, on May, 5th 2012, our patch queue on Zebrapig the Ugly did the impossible; it achieved re-floration! ;-)


[05.05.2012 21:57:36] <Philantrop> !pl

[05.05.2012 21:57:37] [Notice] -zebrapig to #exherbo- 0 patches in queue:


by Wulf Krueger at January 03, 2014 12:54 PM is gone for good. Please re-submit your patches. is gone for good. Please re-submit your patches.

Here’s the list of affected patches:

[28.04.2012 17:24:28] [Notice] -zebrapig- 13 matching patches in queue:
[28.04.2012 17:24:28] [Notice] -zebrapig- ::sydbox (submitted by worr 161 days and 17 hours ago): [PATCH] Fixed race condition in sydbox
[28.04.2012 17:24:28] [Notice] -zebrapig- ::kde (submitted by heirecka_ 17 days and 5 hours ago): [PATCH 1/2] Move stuff from qt-creator-scm to its exlib
[28.04.2012 17:24:28] [Notice] -zebrapig- ::arbor (submitted by SuperHeron 11 days and 20 hours ago): [PATCH] app-shells/bash-completion[=scm]: /etc/bash_completion.d is
[28.04.2012 17:24:28] [Notice] -zebrapig- ::x11 (submitted by moben 11 days and 8 hours ago): [PATCH 1/2] mesa multilib: Use multiunpack exparam
[28.04.2012 17:24:30] [Notice] -zebrapig- ::arbor (submitted by keruspe 11 days and 1 hour ago): [PATCH] llvm: allow gcc 4.7.0
[28.04.2012 17:24:32] [Notice] -zebrapig- ::mawww (submitted by heirecka 8 days and 3 hours ago): [PATCH] Fix building of espeak
[28.04.2012 17:24:34] [Notice] -zebrapig- ::arbor (submitted by SuperHeron 7 days and 4 minutes ago): [PATCH] dev-lang/python: Add .pc file into alternatives
[28.04.2012 17:24:36] [Notice] -zebrapig- ::anderslm (submitted by Philantrop 6 days and 18 hours ago): [PATCH] dev-libs/dotconf: ::anderslm -> ::media
[28.04.2012 17:24:38] [Notice] -zebrapig- ::kde (submitted by Apetrini 3 days and 13 hours ago): [PATCH] networkmanagement: bump to, fix dep
[28.04.2012 17:24:40] [Notice] -zebrapig- ::ingmar (submitted by nakamuray 1 day and 3 minutes ago): [PATCH 1/3] notmuch: version bump to 0.12
[28.04.2012 17:24:42] [Notice] -zebrapig- ::arbor (submitted by keruspe 23 hours and 6 minutes ago): [PATCH 1/3] autoconf: bump to 2.69
[28.04.2012 17:24:44] [Notice] -zebrapig- ::x11 (submitted by keruspe 22 hours and 47 minutes ago): [PATCH] xkeyboard-config-scm: fix build
[28.04.2012 17:24:46] [Notice] -zebrapig- ::kde (submitted by heirecka_ 19 hours and 56 minutes ago): [PATCH] Version bump to akonadi-1.7.2

by Wulf Krueger at January 03, 2014 12:54 PM

Gerrit Code Review for Exherbo

As an experiment,  I’ve installed a Gerrit Code Review instance on my server for use with Exherbo.

Gerrit is a code review tool and allows for


- discussing patches and keeping the results for future reference
- get notified by email about every change (if you want)
- easily work on every official Exherbo repository (more to come later if people are interested)
- contributors to get their repositories added to Gerrit as well (optional)


You’ll find an introduction to Gerrit here:




Random thoughts:
- If Gerrit isn’t being used, it will go away. This is an experiment because I think Zebrapig (albeit its undisputed merits) has inherent limitations that can’t be easily fixed.
- Gerrit is not supposed to supersede Zebrapig but to complement it.
- There have been controversial internal discussions about this. Please keep in mind that I don’t mean to take anything away from anyone but to improve Exherbo.


Notes about the installation:
- The Gerrit instance fetches and pushes repository updates every 15 minutes. Gerrit now replicates merged changes pretty much immediately. This sometimes/rarely fails on the first attempt for various reason. I’ve implemented a fallback that occurs every 15 minutes.
- You need an OpenID to register. This is mostly for copyright reasons as well and probably won’t change. (I’ve evaluated a lot of other options; they all had in common that they couldn’t be used together with other methods.)
- You MUST use your real name for copyright reasons.
- In the future there might be a mailinglist that gets all notifications from Gerrit. For now, please subscribe/unsubscribe to/from notifications yourself as you see fit.




How to use Gerrit:



Registration and initial setup: 



2. In the upper right corner, click “Register”.
3. In the next screen, enter your full name (for copyright reasons, it must be your real name) and choose a user name.
4. Paste your ssh public key into the box at the bottom and click “Add”. If you don’t have one, there’s an explanation about creating one.
5. Click ”Continue”.
6. Click on your full name in the upper right corner (where “Register” was), and choose “Settings”.
7. Enter a git/https user name. You can use the one you chose in step 3.



Cloning a repository:


1. Click “Projects”, “List”, then choose a project.
2. You should see several methods for cloning the project, the easiest way is to choose the ssh method.
3. Clone, e. g. git clone ssh://<user name>
4. Install a hook that sets a Change-Id automatically (choose one of the two alternatives):

scp -p -P 29418 <your username> <local path to your repository>/.git/hooks/
curl -o <local path to your repository>/.git/hooks/commit-msg





There are several methods to upload changes. The easiest is to just push:


1. Work on your copy of the repository, commit.
2. Push your changes: git push origin HEAD:refs/for/master



You can use git review for easily setting up your repository clone and submitting patches, too. I haven’t tested it myself, though. It’s quite nice, use it!



by Wulf Krueger at January 03, 2014 12:54 PM

News about Gerrit, Jenkins & friends

Here are a few things I’ve updated on Gerrit, Jenkins and associated tools:

  1. Gerrit
    • The Gerrit bot, gerritwk23, has now support for !pl (and pl in a query). It’s just like zebrapig’s !pl.
    • I’ve updated Gerrit in mid-Decembre. Since then, you can switch to a newly designed “Change View” which you’ll find under your account’s settings in the “Change View” option. There’s also an associated “Diff View” option to set your preferred diff style if you switch to the new Change View.

2. Jenkins

    • In its build logs, you’ll now find the mounts, the cave resolve command and the (likely) dependencies gathered from the installed package. Dependency information might not be 100% accurate so please take it with a grain of salt but it’s usually a good indicator.
      Look out for “**************************************************************” to find that information.


If you have any ideas about what else to improve, please let me know.

by Wulf C. Krueger at January 03, 2014 12:54 PM

Another good reason to use Gerrit: Jenkins is at your service

If it’s not yet good enough for you that using Gerrit

  • is even easier and faster than using zebrapig (you just push your change and you’re done! And if you use git review it’s getting even easier.),
  • the review turn-around times are often better when using Gerrit than zebrapig,
  • discussing patches can be done both when you’re on IRC and on Gerrit,

then here’s another good reason to use it: I’ve set up Jenkins for all repositories on Gerrit to build every change in a chroot (including sydbox-1, pinktrace-1 and docs).

For now, all reports only go to me (and anyone else who wants to get an email with the result included) and Jenkins will not report back to Gerrit because the setup is quite fragile yet and I want to be sure it works properly before making it do more.

No idea how to use Gerrit? Just read my earlier posts Gerrit Code Review for Exherbo and Gerrit for Core-Devs. Of course, you can ask me, too. :-)


by Wulf C. Krueger at January 03, 2014 12:54 PM

Gerrit installation updated to the 2.7 release, pesky “internal server error” fixed

I’ve just updated the Gerrit installation to the 2.7 release and fixed the pesky “internal server error” that occurred when entering a user name or similar.

I’ve also updated my posts on Gerrit and the FAQ-like post for core devs:

Experiment: Gerrit Code Review for Exherbo

Gerrit for Core-Devs



by Wulf Krueger at January 03, 2014 12:54 PM

Gerrit for Core-Devs

There have been a few questions and potential misunderstandings I’m going to try to address here. I’ll update this post if new stuff comes up.

  • Getting the foo Or: How do I become a Core-Dev on Gerrit?
    Simple: You register with your OpenID then you ask any other core dev to add you to the group. At least Bo “zlin” Ørsted Andresen and I know how to do it and every member has the necessary privileges.
  • Reviewing Or: +1+1 != +2
    Every registered user can comment and/or +1 a change. This is an indication said user has reviewed the patch and, ideally, tested it. It’s basically only an opinion, though.
    Only Core-Devs can +2 a change. This means they’ve reviewed and tested that change and are approving it. The change then will get merged and pushed.
    It’s important to remember, though, that +1′s do NOT add up. You can +1 a change a hundred times but it will still need one bold man (or woman) to +2 it.
    Important as well, use the “Publish and Submit” button, not the “Submit” button if you want to get a change merged.
  • What about testing (or the lack of)?
    Nothing has changed compared to Zebrapig. Everyone who +2′s a change at least (ideally, +1 would indicate you tested the thing, too!) is expected to have actually tested it. If you +2 it but didn’t test it, we’re going to slowly roast you over a scented candle. 
  • What’s the easiest way to test a patch?
    Personally, I look at the patch, at the “Downloads” line, I click on “Patch” and then click on the small clipboard icon next to the git fetch comand. That adds said line to your clipboard. Next, I cd into the respective repository, paste the line we just copied and append “| git am”. That’s it, patch applied, now test it!
  • Merging & pushing (no, not like that, you pervert!)
    Gerrit now pushes merged changes directly to our repositories. This means, once you +2 a change (cf. first point), you push it.
  • Command line tricks or How do I…
    … most easily review a change?

    git review -d -t <change number, e. g. 202>

    … merge a boat-load of patches I reviewed and tested at once?

    On your branch with the changes applied: ssh -p 29418 <username> gerrit review –code-review +2 –submit $(git rev-list gerrit/master..HEAD)

    … query for a specific change?

    ssh -p 29418 <username> — gerrit query –comments change:212

    …  get a list of all open changes?

    ssh -p 29418 <username> — gerrit query status:open (add a “project” parameter if you want only changes for a certain repository, e. g. “project:arbor”)

    … add a comment from the command line?

    ssh -p 29418 <username> — gerrit review -m “\”At the very least this commit message should explain why we have to put PWD in PYTHONPATH which can’t be quoted properly… But other than that, seems sensible at least for now.\”” $changeid

by Wulf Krueger at January 03, 2014 12:54 PM

October 13, 2013

Ciaran McCreesh

September 24, 2013

Ali Polatel

A Study in Sydbox

Due to the fact that sydbox is a low level tool which inspects system calls, debugging its bugs become cumbersome at times. GDB and Valgrind are two valuable tools which comes to rescue.

I hit this bug when I was investigating Exherbo bug 369. I wrote a small C program to reproduce the problem:

#include <errno.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <elf.h>
#include <sys/auxv.h>
#include <sys/types.h>

int main(void)
    pid_t pid;
    int pfd[2];
    unsigned long val;
    char buf[1024];
    int auxfd;

    val = getauxval(AT_SECURE);
    fprintf(stderr, "getauxval(%lu) = %lu (errno:%d %s)\n",
        AT_SECURE, val, errno, strerror(errno));

    pid = fork();
    if (pid == 0) {
        /* 23 is AT_SECURE as defined in elf.h */
        char *const argv[] = {"sh", "-c", "od -t u8 | awk '{if ($2 == 23) print }'", NULL};
        dup2(pfd[0], STDIN_FILENO);
        execvp(argv[0], argv);
    } else {
        auxfd = open("/proc/self/auxv", O_RDONLY);
        while (read(auxfd, buf, 1024) > 0)
            write(pfd[1], buf, 1024);

I compiled this small program with gcc and when I run it under sydbox-1 I witnessed an interesting output:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % ./sydbox ./a.out
getauxval(23) = 0 (errno:0 Success)
sydbox@1379972151: bash[26306.0:26305] sys:4|stat| PANIC_KILL

Note there is not a prompt at the end. sydbox-1 hung right after logging PANIC_KILL. Before firing up a debugger and start to debug, let’s gather as much information as possible by checking whether verbose logging will tell us something:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % ./sydbox -m log/console_level:511 ./a.out
sydbox@1379972294: [wait(-1, 0x857f) = 28848] WIFSTOPPED,sig=133|(null)|
sydbox@1379972294: [wait(-1, 0x857f) = 28848] WIFSTOPPED,sig=133|(null)|
sydbox@1379972294: [wait(-1, 0x857f) = 28848] WIFSTOPPED,sig=133|(null)|
sydbox@1379972294: bash[28848.0:28847] sys:4|stat| entering system call
sydbox@1379972294: bash[28848.0:28847] sys:4|stat| PANIC_KILL
sydbox@1379972294: bash[28848.0:28847] sys:4|stat| trace_kill(sig:9) failed (errno:3|ESRCH| No such process)
sydbox@1379972294: process 28848 ignored

After a couple of wait(2) loops the stat(2) system call handler - which takes magic commands as input paniced for some reason and called the function panic() which decided to kill the traced process.

So far so good. Although this looks unrelated to the bug at hand, it is still a good idea to fix it when you have some free time. Let’s fire up the debugger and try to do a reverse debug. I use cgdb which provides a nice curses frontend to gdb.

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % libtool --mode=execute cgdb --args ./sydbox -m log/console_level:511 ./a.out
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
Reading symbols from /home/alip/src/sydbox/sydbox-1/src/.libs/lt-sydbox...done.

First let’s break on main(), run the program and when the breakpoint is hit set another breakpoint on sys_stat (the stat(2) system call handler function) and start [recording][recording] the program instructions and continue.

(gdb) break main
Breakpoint 1 at 0x419d98: file sydbox.c, line 1255.
(gdb) run
Starting program: /home/alip/src/sydbox/sydbox-1/src/.libs/lt-sydbox -m log/console_level:511 ./a.out
warning: no loadable sections found in added symbol-file system-supplied DSO at
warning: Could not load shared library symbols for
Do you need "set solib-search-path" or "set sysroot"?

Breakpoint 1, main (argc=4, argv=0x7fffffffd428) at sydbox.c:1255
(gdb) record
(gdb) break sys_stat
Breakpoint 2 at 0x411d58: file syscall-special.c, line 150.
(gdb) cont
Do you want to auto delete previous execution log entries when record/replay buffer becomes full (record full stop-at-limit)?([y] or n)

This takes some time. When the record/replay buffer is full, gdb kindly asks you whether you want to continue execution and auto-delete previous log entries or stop instantly and investigate further on. We’re not interested in the previous log entries so let’s just hit [enter] and continue.

Process record and replay target doesn't support syscall number -1
Process record: failed to record execution log.

[process 8201] #1 stopped.

This is a weird message by gdb which fortunately I have seen before. sydbox-1 makes use of some rather new system calls which gdb does not support. The newest of those are process_vm_readv and process_vm_writev which were added to Linux as of kernel version 3.2. I’ll add a small one-time tweak to the auto-generated pinktrace/system.h file telling sydbox-1 that these system calls are not supported by the system and let it use the good old ptrace(2) way of reading one long at a time:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % cd ../pinktrace
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % sed -i -e '/^#define PINK_HAVE_PROCESS_VM_\(READ\|WRITE\)V/s/1/0/' system.h
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % grep PINK_HAVE_PROCESS system.h
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % make clean && make -j

Now let’s return to src/ and rebuild sydbox:

alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % cd ../src
alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % make clean && make -j

Let’s re-run sydbox to make sure the bug is still there:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % ./sydbox ./a.out
getauxval(23) = 0 (errno:0 Success)
0000340                   23                    0

This is where my luck kicks in! The bug is not there anymore. Now we know the problem is actually in pinktrace, the underlying library providing thin wrappers around the ptrace(2) system call. We have also narrowed the problem down to one of process_vm_readv and process_vm_writev functions. Now let’s go back to turn the #defines on and retry with gdb:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % cd ../pinktrace
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % sed -i -e '/^#define PINK_HAVE_PROCESS_VM_\(READ\|WRITE\)V/s/0/1/' system.h
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % grep PINK_HAVE_PROCESS system.h
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % make clean && make -j
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % cd ../src
alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % make clean && make -j

Now we will start recording only after we enter the sys_stat() function:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % libtool --mode=execute cgdb --args ./sydbox -m log/console_level:511 ./a.out
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
Reading symbols from /home/alip/src/sydbox/sydbox-1/src/.libs/lt-sydbox...done.
(gdb) break sys_stat
Breakpoint 1 at 0x411d58: file syscall-special.c, line 150.
(gdb) run
sydbox@1379974050: [wait(-1, 0x857f) = 31387] WIFSTOPPED,sig=133|(null)|
sydbox@1379974050: [wait(-1, 0x857f) = 31387] WIFSTOPPED,sig=133|(null)|
sydbox@1379974050: bash[31387.0:31386] sys:4|stat| entering system call 

Breakpoint 1, sys_stat (current=0x62fa00) at syscall-special.c:150
(gdb) record
(gdb) cont
Process record and replay target doesn't support syscall number -1
Process record: failed to record execution log.

[process 31382] #1 stopped.
0x00007ffff78fa048 in process_vm_readv () from /usr/lib/

Gdb kindly stopped where the bug is actually located. Let’s stop recording and single-step to see what error this function returns.

(gdb) record stop
Process record is stopped and all execution logs are deleted.
(gdb) n
Single stepping until exit from function process_vm_readv, which has no line number information.
_pink_process_vm_readv (pid=31387, local_iov=0x7fffffffbe10, liovcnt=1, remote_iov=0x7fffffffbe00, riovcnt=1, flags=0) at vm.c:199
(gdb) n
(gdb) p r
$1 = -1

The function _pink_process_vm_readv is returning -1 which is the negated errno value EPERM. This makes pink_vm_cread_nul fail with -1 which in turn makes pink_read_vm_data_nul return -1 which in turn makes syd_read_string function to call panic(). Now we have a detailed information about the panic happening.

Another valuable tool to aid in debugging system call inspection is strace. Let’s check with strace what these stat(2) system calls’ arguments are. I have not updated my strace.git tree for a while and trying to compile it I have found a problem due to an inconsistency between glibc and linux kernel headers which keruspe fixed for pinktrace with commit e1aa031 a week ago:

alip@hayalet ~/src/strace (git)-[master] % make -j1
gcc -DHAVE_CONFIG_H -I.  -I./linux/x86_64 -I./linux -I./linux  -Wall -Wwrite-strings -D__ALIP_WAS_HERE -g -ggdb3 -O2 -march=native -D__PINK_IS_BEHIND_THE_WALL -MT process.o -MD -MP -MF .deps/process.Tpo -c -o process.o process.c
In file included from process.c:66:0:
/usr/include/linux/ptrace.h:58:8: hata: 'struct ptrace_peeksiginfo_args' yeniden tanımlanmış
 struct ptrace_peeksiginfo_args {
In file included from defs.h:169:0,
                 from process.c:37:
/usr/include/sys/ptrace.h:191:8: bilgi: originally defined here
 struct ptrace_peeksiginfo_args

struct ptrace_peeksiginfo_args is a recent addition to ptrace.h headers and both sys/ptrace.h of glibc-2.18 and linux/ptrace.h of Linux define it. Thus defining the same struct twice fails. Fortunately we have seen this error before with the IA64 architecture where the same happens with struct pt_all_user_regs and struct ia64_fpreg.

Having hit another totally unrelated bug, I have prepared a patch and tested it:

alip@hayalet ~/src/strace (git)-[master] % make
gcc -Wall -Wwrite-strings -D__ALIP_WAS_HERE -g -ggdb3 -O2 -march=native -D__PINK_IS_BEHIND_THE_WALL   -o strace bjm.o block.o count.o desc.o file.o io.o ioctl.o ipc.o loop.o mem.o mtd.o net.o pathtrace.o process.o quota.o resource.o scsi.o signal.o sock.o strace.o stream.o syscall.o system.o term.o time.o util.o vsprintf.o  
make[2]: `/home/alip/src/strace' dizininden çıkılıyor
make[1]: `/home/alip/src/strace' dizininden çıkılıyor

It compiles and runs fine. Time to prepare a git-format-patch and send to strace-devel mailing list. These git tools make it really easy to prepare patches and submit them. Here is the link to the actual mail.

So far so good. Another bug fixed and submitted upstream. Let’s go ahead and see whether strace can make sense of those stat(2) arguments:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % ~/src/strace/strace -f -e stat ./a.out Process 18698 attached [pid 18697] +++ exited with 0 +++ stat(0x9db090, {…}) = 0 stat(0x485897, {…}) = 0 stat(0x485897, {…}) = 0 …

Note the `-f` argument. Remember our panic line started with
`bash[31387.0:31386]` this does not happen in my small program but in bash which
is spawned right after `fork(2)`. The `-f` argument of [strace][strace] follows

Now the question is what those hex values in the first arguments are.
[strace][strace] usually does a good job in decoding strings so something is
weird going on here. Let's go one step ahead and try to trace [strace][strace]
using [strace][strace] itself. One has to be careful here not to use `-f` with
the first [strace][strace] because *only one process may trace a process at a
time* and we want the first [strace][strace] to only trace [strace][strace] not
our small program `a.out`. We also use the option `-e 'signal=!all'` so that we
filter some of the unwanted output:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % strace -q -e ‘process_vm_readv’ -e ‘signal=!all’ – strace -e ‘signal=!all’ -f -e stat ./a.out getauxval(23) = 0 (errno:0 Success) Process 22286 attached [pid 22285] +++ exited with 0 +++ process_vm_readv(22286, 0x7fff71faed40, 1, 0x7fff71faed50, 1, 0) = -1 EPERM (Operation not permitted) stat(0x1938070, process_vm_readv(22286, 0x7fff71fafce0, 1, 0x7fff71fafcf0, 1, 0) = -1 EPERM (Operation not permitted) {…}) = 0

The output of the two strace processes are mixed but here we can also see that
the system call `process_vm_readv()` returns the error condition `EPERM`.
Consulting the [process_vm_readv(2)][man_process_vm_readv] manual page:

EPERM The caller does not have permission to access the address space of the process pid.

Now, why on earth is `ptrace()` is permitted but `process_vm_readv()` is not? It
is clear that they are two different APIs. It is time to dig into the kernel
source. Having walked through the kernel code on [lxr][lxr] for a while, I
figured this [sydbox-1][sydbox_1] PANIC was due to the fact that I have the
sysctl `kernel.yama.ptrace_scope` set to 1 which is [YAMA restricting
ptrace()][yama_restricts_ptrace]. After:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % sudo sysctl kernel.yama.ptrace_scope=0 kernel.yama.ptrace_scope = 0 ~~~

Everything works OK and now I am aware of the fact that there is another way to restrict ptrace() and I will work on sydbox-1 to make it handle such errors gracefully (without hanging) but that’s for another night.

Confession: I started working at Özgür Yazılım A.Ş. as a Linux system administrator and programmer and I have been using Arch Linux for a while which means I have not been configuring/compiling my own kernel. This was a nice message to me that I should stop being a slacker and return to Exherbo now.

The Exherbo bug 369 is still not fixed, but I am working on it :-)

September 24, 2013 12:00 AM

September 21, 2013

Ali Polatel

Killing tracees on exit with sydbox-1

As I’ve written in my blog post Recent Linux changes to help sandboxing Linux has a few new features which may aid in enhancing sydbox-1.

One of these features is PTRACE_O_EXITKILL. This is a new ptrace option to kill tracees upon tracer exit. Quoting from ptrace(2)

PTRACE_O_EXITKILL (since Linux 3.8)
If a tracer sets this flag, a SIGKILL signal will be sent to every
tracee if the tracer exits.  This option is useful for ptrace
jailers  that want to ensure that tracees can never escape the
tracer's control.

This is a simple feature providing a nice enhancement. sydbox-1 had a similar feature to prevent tracees from running upon an abnormal exit. There are two options, namely core/abort/decision and core/panic/decision, which when given the value killall sends SIGKILL to all traced processes upon abnormal exit. There is also the option core/trace/exit_wait_all to make sydbox-1 wait for all tracees to exit before exiting.

However, doing this in user-space is tricky and error-prone. Considering it’s the tracer who is dying unexpectedly, it may not always be possible to kill tracees which will then run in potentially unsafe mode. You can read this lkml thread and many more to dive into the internals of ptrace(2).

Thus, sydbox-1 learned a new magic command with the name core/trace/exit_kill to turn this functionality on with the two commits I pushed to master today:

One restriction is the option core/trace/exit_kill is only useful when it is set upon startup. It does not work with the magic stat() system call. ptrace(2) options are inherited from parent to children thus trying to set this on a per-tracee basis requires one to change the value of the option for the parent and all its children. Although this is possible in theory (sydbox-1 keeps track of parent<->children relationships) it would add some complexity to the program which I do not want unless I see a well-founded reason to do so.

September 21, 2013 12:00 AM

September 14, 2013

Alexander Færøy

Enhancing SSL Security for IRC: DANE Support

September 14, 2013.

A couple of weeks ago, I had a discussion with some of the Quakenet coders on how to add SSL support to their IRC daemon, but the discussion ended up being about the false sense of security that SSL potentially can give to the user. The Quakenet hackers have an interesting article online about their thoughts on the matter and while I do understand their points, I do not agree with it being a good enough reason to completely avoid SSL on your IRC network.

We quickly changed the discussion to be about how the IRC clients should be able to verify that the SSL certificate, received from the server, is not a malicious certificate from someone doing MITM attacks. This was not the discussion I had hoped for, but nevertheless, it was an interesting discussion to participate in and made me spend a few days thinking about their concerns.

Sadly, as it is today, some IRC clients, including Irssi, only do full SSL certificate validation as an opt-in option (via the -ssl_verify option for /connect in Irssi’s case) rather than having it as an opt-out option, which would be ideal. This is simply because people in the IRC community have historically not wanted to spend money on certificates from the so called “trusted” Certificate Authorities like we have seen on the web. Changing this from opt-in to opt-out is something that I would like to see happen, but it is not something that is going to be easy. We saw how many web sites got a “proper” certificate after the Mozilla guys made it slightly harder to actually mark a self-signed certificate as trusted. This was at first a very annoying move, but these days we rarely see self signed certificates when we browse around the web.

A few days after the discussion on IRC, I was having dinner at Thomas’s place and I mentioned the discussion with the Quakenet hackers. Thomas knows a lot about security, privacy and DNS, and he is an avid Quakenet user, so it appeared more than obvious to take the discussion with him and hear what his take to the problem was. His suggestion was to take a look at DNSSEC and DANE and see if that could be used as a possible solution.

Luckily for me, it was exactly what I was looking for.

A few days after the dinner conversation, I pushed a patch to Irssi’s source code repository that enabled support for DANE validation of SSL certificates.

Let’s have a look at how DANE works. This will hopefully give you enough knowledge to understand the basics of what is going on. I will document how to compile Irssi with DANE support enabled and test whether it works or not.

What is DANE?

DANE is an acronym for “DNS-Based Authentication of Named Entities” and comes with a protocol named TLSA. DANE is an internet standard and you can read the full technical specification of DANE in RFC6698, but hopefully, this article will give you an introduction to get started using DANE for your IRC servers right away. The concepts are totally protocol agnostic so this will work for other protocols than IRC as well, but it does require modification to the client software to work.

DANE is a simple way of storing information about a certificate in the DNS system. Adding DNSSEC on top of the cake, gives you a very powerful way of validating certificates where the client relies on a trusted source (their ISP’s DNS server and DNSSEC) validating the information from the possibly eavesdropped IRC server.

DANE is implemented as a new DNS resource record named TLSA. You can see an example of such record here from our test IRC server linked to the IRCsource IRC network:

$ dig TLSA

; <<>> DiG 9.8.3-P1 <<>> TLSA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38406
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 9


;; ANSWER SECTION: 3358 IN TLSA 3 0 1 9B954A014881108A9058DB80020909FFD8B4C44C6F41C8796B3A1EA4 3A444B94

;; AUTHORITY SECTION:      50607   IN  NS      50607   IN  NS      50607   IN  NS      50607   IN  NS      50607   IN  NS

;; ADDITIONAL SECTION:   7417    IN  A   36319   IN  AAAA    2a02:9d0:3002:1::2   25447   IN  A   31182   IN  A   28269   IN  AAAA    2001:678:5::6   31182   IN  A   28269   IN  AAAA    2a01:558:4000::3   25447   IN  A   28269   IN  AAAA    2001:6f8:3ad::1

;; Query time: 55 msec
;; WHEN: Sat Aug 10 13:16:23 2013
;; MSG SIZE  rcvd: 393

Note: If your version of dig doesn’t recognize the TLSA type, you can easily replace it with TYPE52 like this: dig TYPE52.

Notice how the port, 6697, and protocol, TCP, is part of the DNS query. This will be familiar for people who have worked with SRV DNS records.

The interesting part of the output is the answer section where you see the following:

3 0 1 9B954A014881108A9058DB80020909FFD8B4C44C6F41C8796B3A1EA4 3A444B94

What does all of this mean?

Let’s start out by looking at the format. The format for a TLSA reply is as following:

<certificate usage> <selector> <matching type> <certificate association data>

This means that our certificate usage field is 3, our selector is 0 and our matching type is 1. The associated data is the string "9B954A014881108A9058DB80020909FFD8B4C44C6F41C8796B3A1EA4 3A444B94".

It is important to understand the semantics of these fields, because they will dictate how and if the client is going to do further validation of the certificate once the client has received it from the IRC daemon.

Using 3 0 1 means that we are using a self-signed certificate and we will rely on DANE for validating the certificate only (3); that we are using the full certificate and not just the SubjectPublicKeyInfo part (0) and we will be using a hexadecimal encoded SHA256 hash of the DER-encoded certificate (1).

To fully understand the various options available, I suggest you take a look at RFC 6698 section 2.1.

Enable DANE Support for your IRC Server

The first step you will have to take is to ensure that whoever runs your DNS servers supports both DNSSEC and TLSA records. In Denmark, a lot of users are using the free DNS hosting provider GratisDNS. GratisDNS supports both DNSSEC and TLSA records which makes setting this up a lot easier.

Sadly, GratisDNS’ interface is currently only available in Danish, so you might have to look for other solutions available online.

Once you have a DNS provider that supports DNSSEC and TLSA records, it is fairly easy to create the records. In our example, the following assumptions are made:

  1. You already have an IRC daemon running with SSL enabled on port 6697 and you have verified that it actually works as expected.

  2. Your certificate is self-signed, so you would like to rely on DANE support only for the validation. This means that the user will not see any self-signed certificate errors when connecting with certificate validation enabled.

  3. We will create a record using a SHA-256 hash of the certificate data. Feel free to use something stronger, if you are more crypto paranoid than I am.

This means that our TLSA record will end up looking something similar to this: TLSA 3 0 1 <SHA-256 hash of the certificate data>

This is basically going to be a description of the exact same setup that I am using for

To find the SHA-256 value of your certificate, start by logging onto the server running the IRC daemon and find the directory that contains your certificate files. We are then going to find the SHA-256 value of the DER representation of our certificate:

$ openssl x509 -in -outform DER | sha256sum
9b954a014881108a9058db80020909ffd8b4c44c6f41c8796b3a1ea43a444b94  -

This is the value we will be using in our final TLSA record, which now looks like the following: TLSA 3 0 1 9b954a014881108a9058db80020909ffd8b4c44c6f41c8796b3a1ea43a444b94

Once you have added this record to your DNS zones, it is now time to actually test whether it works as expected.

Building Irssi with DANE Support

This part is tested on FreeBSD 9.2-PRERELEASE. Hopefully, it works for other people as well. Feel free to report any issues you may experience.

  1. Download the dnsval tarball from its download page. This is quite new software so I haven’t run into many distributions that have packages available, so we will assume that we have to compile it ourselves.

    $ mkdir dane
    $ cd dane
    $ fetch
    $ tar zxfv dnsval-2.0.tar.gz
    $ cd dnsval-2.0
    $ ./configure --prefix=/usr/local
    $ make
    $ sudo make install
  2. Next we will download the Irssi source code from the Git repository. We start by cloning the repository into our newly created dane directory:

    $ cd dane
    $ git clone git://
    $ cd irssi
  3. We bootstrap the build system:

    $ sh
  4. We configure our test Irssi client:

    $ CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure --enable-dane --with-perl=no

    Make sure that somewhere near the end of the output of the configure script contains:

    Building with DANE support ....... : yes

    Otherwise you should take a look at the config.log file and look for places where libval is mentioned and figure out why it doesn’t find the library correctly.

  5. Compile Irssi:

    $ make
  6. Fire up your new Irssi client and give it a spin:

    $ ./src/fe-text/irssi -!
  7. Try to connect to our test server,, using DANE:

    /connect -ssl -ssl_verify 6697

    If everything was done correctly, Irssi will now connect to the server, verify the signature of the certificate using TLSA and allow you to connect without seeing any self-signed certificate errors.

DANE Enabled IRC Servers

Here’s a list of IRC servers that supports DANE. If you are running a public IRC server and would like to see the server added here, feel free to drop me an email at with information about the server.


IRCsource is a small network where people with a general interest in IRC hang out together to discuss and test various new concepts and ideas for IRC.

  • (SSL ports: 6697 and 9999)

I will do my best to maintain this list of servers supporting DANE in the future.

Next Stop?

The next step for me is to start securing server-to-server links within the IRC networks with DANE. This will require some modifications to the IRC daemons themselves. I plan on looking into adding support for DANE in a personal feature branch of ircd-ratbox and some of its derivatives.


I am unable to say if DANE support is what the IRC community will be adopting. The IRC community is very conservative in general so time will have to tell.

If you believe you have found a bug in my code or have any troubles setting DANE up for your own IRC server, I will be more than happy to help. Drop me an email and I will take a look at it whenever I have time. Otherwise, feel free to poke me on IRC. My nickname is ahf and I am available on most of the “larger” IRC networks (EFnet, Freenode, IRCnet and Quakenet).

All of this code will be available in the upcoming Irssi 0.8.16 release, but if you want to test it right away, my suggestion is to follow my guide from above and use Irssi directly from Git.

Hopefully, we will see other IRC client and server hackers implementing DANE support in the nearby future. If you like what you have read here, please help me making this happen by spreading the word about the possibilities available for enhancing the SSL support in IRC clients as well as other SSL based online services.

This is too easily implementable to be ignored.


I would like to thank Thomas Steen Ramussen for being the originator of the idea and setting up the initial DNS server for testing purpose; Peter Larsen for expeditiously implementing TLSA support for GratisDNS; the guys for late night discussions about DANE; Mickey Fischer for testing the Irssi patches on Gentoo Linux with various options enabled and disabled; the DNSSEC-Tools Project for creating the libraries used and finally the rest of the Irssi team for reviewing the patches and coming with recommendations for my code.

September 14, 2013 12:00 AM

September 13, 2013

Wulf C. Krueger

You all suck at working on patches, my fellow Exherbo devs!

I originally posted this in 2011. Unfortunately, hardly any significantly changed since then. I decided to add !pd statistics this time, though:

Philantrop: 557
sepek: 271
ar: 207
keruspe: 180
SardemFF7: 105
zlin: 98
compnerd: 94
sepek_: 88
SuperHeron: 67
heirecka: 53
moben: 43
mrothe: 37
woutershep: 33
pipping: 33
Bruners: 33
virkony: 30
arnej: 27
nicoo: 24
tgurr: 22
freeedrich|: 22



What really annoys me lately is the unwillingness of my fellow Exherbo core developers to act on user-contributed patches. While it’s certainly true that some patches need extensive testing and, thus, require a lot of time, there are usually a lot of trivial patches or patches that can be tested with moderate effort.

Let’s look at an example:

From 2a11f609e8be4f61a545112f1fceda6f8c40bfeb Mon Sep 17 00:00:00 2001

From: Johannes Nixdorf <>

Date: Thu, 24 Mar 2011 16:26:59 +0100

Subject: [PATCH] revive agg in ::mixi

drizzt.graveyard | 7 ——-

1 files changed, 0 insertions(+), 7 deletions(-)

diff –git a/drizzt.graveyard b/drizzt.graveyard

index 98979b9..92ed79a 100644

— a/drizzt.graveyard

+++ b/drizzt.graveyard

@@ -287,10 +287,3 @@ www-servers/

homepage =

removed-by = Wulf C. Krueger <>

removed-from = drizzt


- agg/

- :0 2.5

- description = A High Quality Rendering Engine for C++

- homepage =

- removed-by = Wulf C. Krueger <>

- removed-from = drizzt

This patch was for ::graveyard. It simply removes a single entry for a package that found a new home since I removed it. Great!

Anyone with push access could have verified and pushed it with minimal effort and, yet, nobody did for about two days and I’m pretty sure it would still be rotting on zebrapig if I hadn’t done so today.

Unfortunately, it’s by far not the only example. At the time of writing, zebrapig keeps 16 patches. A week ago, it were over 30. Nobody gave a shit.

There are patches that have been on zebrapig for months now (Ruby comes to mind!) and help with them is rejected because some people have worked on them and instead of submitting improved patches, they keep them to themselves, effectively stopping anyone from doing anything. And hardly anyone gives a shit.

Now, why is that situation so bad:

  1. Patches are submitted to improve Exherbo. You’re impeding improvement by ignoring them.
  2. Patches are submitted by our contributors/non-core developers. If you ignore their patches, they will become frustrated and stop submitting patches but create their own repositories, duplicating our work and making things harder for all of us. Or they will just go away. The latter is the worst possible outcome for Exherbo as a whole because with hardly more than a handful of active core developers, we will fail if we drive contributors away.
  3. You’re putting more workload on the even fewer people with push access that actually work on patches. This takes away from our time working on more interesting stuff and, at least in my case, really alienates people from Exherbo.

Effectively, I’m handling most of the contributed patches myself. Either by reviewing, discussing and pushing them myself or by asking people to work on them (and usually getting stupid answers…).

Another thing that annoys me greatly are the answers I’m getting from people I’m asking to review patches; here are some examples (in no particular order) and what I think about them (which is usually not what I say):

  • “I prefer playing SC2.” / “I’m watching Star Trek!” – Well, yes, fine but I’m sure you could really dedicate at least one or two hours per week to work on patches.
  • “Exherbo is just something nice to play with. I don’t really want to really work on it or be professional about it.” – (I really hate that one.) If you take up responsibility for something, even as a hobby or so, then live up to it or leave it be. Get used to behaving professionally now while you can afford it not to be. Once you get a job, people won’t be so forgiving.
  • “I don’t really care about that package anymore.” – Well, I don’t either but there’s a patch so other people obviously do care. If you really want to get rid of a package, mail the exherbo-dev mailinglist and tell people. If there’s no taker, use Dexter to bury the package if need be.
  • “I prefer vodka over patches.” – …
  • “I’m working! Not a student anymore.” / “I’m so tired!” – So am I. And I’m married, have three kids and two rabbits. I’m working hard myself so you have my sympathy but, really, are one or two hours per week too much to ask? I usually invest much more time myself.
  • “I’ve been busy slacking for a year!” (or longer) – Then please make it official and resign as a core developer. At least I’m going to know whom not to ask and it’ll become more obvious we’re under-staffed.
  • “I said I’d do it but now I can’t be arsed.” – Great, you could at least have told me right from the start you’re not going to do anything. I could have acted accordingly then.

And sometimes, the very same people who just refused to even look at a patch will ask me to review their patches seconds later…

All of this is really annoying and it’s the most likely reason for me to quit working on Exherbo and switching all my machines to another Linux distribution at some point if we don’t find a solution.

by Wulf Krueger at September 13, 2013 05:14 PM

September 02, 2013

Ciaran McCreesh

Paludis 1.4.1 Released

Paludis 1.4.1 has been released:

  • Compatibility with newer Boost.
  • Minor bug fixes and UI tweaks.

by Ciaran McCreesh at September 02, 2013 01:00 PM

June 27, 2013

Ali Polatel

Sandboxing Skype with sydbox-1

There are various tools to provide enhanced restriction mechanisms under Linux. In case security is the major concern, these mechanisms need to be in the kernel level which in turn means specific configurations or in some cases modifications (in forms of patches etc.) to the Linux kernel. Some examples are AppArmor, Security Enhanced Linux, Tomoyo Linux, and Grsecurity. User space solutions are either not as flexible or not as secure depending on the use case scenario.

We, at Exherbo, need a sandbox for misbehaving package builds. One should note that such misbehaviours can sometimes be rather fun (or not safe for work at times). I used the term misbehaving on purpose because this does not mean the sandbox itself can make the build environment totally secure. Linux has good old UNIX goodies like separate permissions for users, chroots and new shiny stuff like per-process namespaces to implement further restrictions.

Exherbo’s practical solution to this issue is sydbox. With the upcoming version sydbox-1 - which is yet to be released - this solution can easily be adapted to different use cases.

As I was browsing through Arch Linux Wiki pages I stumbled upon the Skype page which describes different approaches to restrict such close sourced applications.

I am not claiming using sydbox-1 for this purpose is secure but it is most certainly practical. Here is my proof-of-concept attempt at sandboxing Skype using sydbox-1. Below is a sample sydbox-1 profile for use with Skype. You can also find it in sydbox-1.git under examples/ directory.

# sydbox profile for Skype4

# Sandboxing





# Logging

# /dev

# /proc & /sys

# nscd (glibc)

# /etc

# Libraries

# Share dirs

# Xorg/X11 & dbus

# /tmp

# Skype

# Host specific configuration under /home

# Skype specific configuration

# Temporary files & caches

# Networking
# note: allow IPv4 and IPv6 by default since Skype operates on a P2P model.
# You may further restrict access by only allowing access to SKYPENET,
# Akamai and Microsoft Corporation together with your contact's IP
# address.

# Allow some external programs

A couple of things to note:

  1. sydbox-1 is still in heavy development and the file format may change.
  2. This approach is not secure. Author claims no responsibility if Skype kills your goats.
  3. Three is the loneliest number since number two which is the loneliest number since the number one.

Happy hacking!

June 27, 2013 12:00 AM

June 13, 2013

Ali Polatel

I Can Not Tell

As the Garip poet Orhan Veli once wrote,

Can you hear me if I cry,
In my verses;
Can you touch,
My tears, with your hands?

I hadn't known how songs were so lovely,
And yet the words so inadequate
Before I had fallen into this suffering.

I know there is somewhere
To say anything about which is possible;
I am very close, I can hear;
I can not tell...

in his poem Anlatamıyorum (I Can Not Tell, translated by myself on 2013-06-13). Sometimes a photo may describe what we can’t describe with a thousand words.

You know your government has failed, when your grandma starts to riot!

Long story short, you know your government has failed, when your grandma starts to riot…

Occupy Gezi! Diren Gezi!


  • 2013-06-14: Translation of the first quatrain was slightly modified.
  • 2013-06-16: More translation fixes.

June 13, 2013 12:00 AM

May 16, 2013

Ciaran McCreesh

Paludis 1.4.0 Released

Paludis 1.4.0 has been released:

  • Tweaked ‘cave resolve’ output to add blank lines.
  • Support for libarchive 3.1.2.
  • Compatibility fixes for GCC 4.8.

by Ciaran McCreesh at May 16, 2013 01:29 PM

March 25, 2013

Ciaran McCreesh

Paludis 1.2.0 Released

Paludis 1.2.0 has been released:

  • Bug fixes.
  • Dep specs can now use ‘[.key!=value]’. The behaviour of ‘<‘ and ‘>’ has changed: for key types where order comparisons don’t make sense, the match now always fails.
  • Various compiler-compatibility fixes.

by Ciaran McCreesh at March 25, 2013 06:51 PM