Closing in on FOSSCON
 FOSSCON is only 4 days away now and I'm trying to figure out all the things I need to do before the conference..

Plane ticket and hotel is booked (I'd be in big problems otherwise) but I haven't prepared my slides yet. I also need to find lots of small things like travel adapter, camera and all the other small things I wouldn't want to do without.

All in all I'm very excited about FOSSCON though, especially since it's going to be my first talk outside of Europe and I'm really looking forward to peoples reactions to my talk.

My talk centers around effective ways of building a developer community, mostly based on my experience from the Exherbo project. When I did a similar talk here in Denmark about 8 months ago most people were quite surprised at first but also found my ideas very interesting and I've had some very positive feedback from the people I've met again afterwards. I'm hoping the FOSSCON audience will be just as interested and that they'll give my ideas on managing open source projects some serious thoughts.

And if any one of you should happen to visit FOSSCON I won't be opposed to having a beer or two.. :)

Exherbo rejected my patch, now what?

Exherbo has a fairly strict patch policy that's usually summarised as "no patches without a damn good reason". Good reasons includes "Compile fixes" and "Security patches" at the very least but we do end up rejecting quite a few proposed patches.

I decided on this policy from the very beginning of Exherbos life as it's much easier working with upstream if we don't add patches against their wishes and it also makes it a lot easier for users to move to another distribution if/when needed (assuming that other distribution haven't patched the application(s) too heavily).

All in all this policy have worked very well for Exherbo so far but what can you do when you really, really want that patch for your favorite application? The first (and in many cases best) option is simply talking to upstream and convincing them that the patch is a good idea. That way all users benefits from the patch regardless of their choice of distribution and upstream takes care of maintainance and QA.

But what can you if that fails or you simply want a patch specifically tailored to your local needs? An easy way to solve that is through the magic of auto patching - paludis makes it quite easy to add local patches to specific packages any time you upgrade/reinstall them using phase hooks.

Below is a generic auto patch hook courtesy of Ciaran McCreesh.

$ cat /etc/paludis/hooks/ebuild_prepare_post/patches.bash
# vim: set sw=4 sts=4 et :

    cd "${S}"
    if [[ -d $patchdir ]] ; then
        einfo "Applying user patches"
        for p in $patchdir/*.patch ; do
            [[ -f "${p}" ]] || continue
            einfo "Applying $(basename ${p} )"
            patch -p1 < ${p} || exit 1
        einfo "Done"

Before using this hook you want to change "patchdir" so it points to your own local patch directory. And then you simply add patches (files should be named *.patch) in $category/$packagename directories in your patch directory. As an example you could add a net-www/chromium/omnibar-http.patch file containing the following patch if you want to revert the recent sillyness of not showing http in the omnibar in chromium.

Source: Timothy Redaelli - updated by Elias Pipping
Upstream: Rejected, see
Reason: Do not strip http:// from omnibar!

--- b/net/base/
+++ a/net/base/
@@ -1452,7 +1452,7 @@
url_string == kHTTP && (! ||
( &&,
- std::string(kFTP).size(), kFTP))));
+ std::string(kFTP).size(), kFTP))) && false);

new_parsed->scheme = parsed.scheme;

Adding local patches is now just a question of dropping the patch file in the correct path but keep in mind that you have the responsibility of maintaining not only your local patch but also anything it might affect (not limited to the patched package).

Exherbo at Open Source Days
The danish open source conference, Open Source Days, will run this friday and saturday. Exherbo will be present both days with quite a few developers in attendance.

I'm sure there will be a (little) hacking on Exherbo and related projects like Genesis but it's also a very good, if somewhat rare, opportunity to meet some of the leading Exherbo developers and talk to them about the current status of Exherbo and what's in the future.

Personally I'm hoping to have some good discussions about the kind of problems people currently face when they use Linux in various business settings and ways that those problems might be solved. I'm also hoping that you can learn something from the way the Exherbo project is managed and get an idea how the project manages to move at such a fast pace.

And finally I'm looking forward to meeting lots of people and having a good time :)

On Genesis commits
I've been asked a few times by different people whether they should push simple patches to genesis. The answer is a resounding 'Yes, please go ahead' but it seems like stating my policy towards other peoples contributions might not go entirely amiss.

My current policy (which will stay until genesis starts stabilising a lot more) is:
  • Any contribution is welcome so you just need to find somebody with push access (the usual Exherbo devs will do)
  • Large patches / feature contributions are also extremely welcome but you might want to contact me first and make sure I won't undo you hard work.

I'm not in any case going to complain about contributions (large or small) so don't hold back. And remember that I have a pressing need for people to play around with genesis scripts and tell me what you need from genesis. git:// was created yesterday for this purpose.

And for those of you who don't have direct push access you can just cue your patches using the hacchi patch bot in #exherbo on irc:// and I'm sure one of the friendly exherbo developers will help you :)

Genesis just got internal events
One of the big problems with Genesis was that you'd get its coldplugging events in that the events wasn't necessarily delivered in a sane order. I briefly considered different ways of controlling the order of the events but quickly came to the conclusion that was madness.

The solution I decided upon instead is generating an internal event after coldplugging is finished and send that event to all event modules. This way we can simply trigger on the 'genesis-started' event and start mounting filesystems and whatever else is needed for bootup.

So how can you help? What I need right now from you is just playing around with some homegrown scripts, trying to catch some events and telling me about all the things that are absolutely impossible to do without. Testing Genesis is quite simple and can easily be done without interfering with the rest of your system.

How to test Genesis:
1. Clone the git:// repository
2. Run ./ in the genesis repository
3. Run ./configure
4. Run make
5. Run sudo make install (by default it installs to /usr/local and won't conflict with anything)
6. Write a /usr/local/etc/genesis/config file
My current config file looks like:

# Currently supported log destinations are file and console
logging = console
logfile = /var/log/genesis.log

command = yes
netlink-uevent = yes
netlink-route = yes

coldplug = yes
coldplug_mounts_sysfs = no
log_matched_events = yes
log_unmatched_events = yes
Ignore all the options except the coldplug_* options. The other options might be necessary due to the rather haphazard way configuration is implemented currently but don't expect them to work right now. The coldplug option enables/disables coldplug events and the coldplyg_mounts_sysfs option controls whether the coldplugging part tries to mount and umount /sys. You want to keep this option disabled unless you're doing actual boot testing.

Stick one or more bash scripts in /usr/local/etc/genesis/netlink-uevent/ or /usr/local/etc/genesis/netlink-route/ and try running: sudo /usr/local/sbin/genesis

The test scripts I'm using currently looks like (from /usr/local/etc/genesis/netlink-uevent/


    echo "netlink-uevent::add" >> /var/tmp/genesis.log

You can add any number of event subscriptions you like in a single script or spread subscriptions over several scripts. Each subscription is defined as SUBSCRIPTION_function=trigger

Trigger is simply a regex that matches the metadata from events in an internally serialized string format. Function denotes the function in the script called when matching that event. So all the above script does is triggering the add() function on all events matching the string 'vcs10'. Since I have coldplugging enabled I'm guaranteed to see that event.

And that's all there is to it.. One of the things high on my TODO list is to replace the regex matching with a udev like language where I can match on subsystem, MAC address or whatever other metadata events generate. I'd very much appreciate comments on what you think is needed in a simple language like that.

Remember Genesis? The oft mentioned new init system for Exherbo?
If not you might want to read this old exherbo-dev post to refresh your mind.

Genesis started out as me being rather frustrated with current init systems and their huge failures. My basic idea was that all the different init systems fail badly at solving any real problems for system administrators and that it was about time fixing that situation.

So as I started really thinking about the problems that init systems should solve I decided that writing a new init system from scratch was the approach..

A short while later I discussed most of my ideas in a talk at FOSS Aalborg and had a fair bit of positive feedback. It's worth noting that I haven't started writing any code at this point and consequently my problems hadn't started yet.

When I did start writing code I quickly got even more ideas for Genesis and it became an even more ambitious project. And then it changed radically.. again and again.

Due to all the changes and lack of direction I didn't want to publish the code and it was often compared to Duke Nukem Forever (for good reasons I might add). But now that I finally seem to be reasonably sure about the direction I've finally released the code for everybody to peruse and contribute to.

The current status of the code is quite messy and it's not yet usable as an init system at all. You can glean the basic ideas of it however and there's a TODO list that you're most welcome to take a swing at. A few people have already contributed some minor patches for the build system for which I am grateful. I'd get around to fixing those things myself but for now I'd rather focus more on Genesis design/architecture and make sure that development progresses quickly.

As for progress I'm trying to make sure I do at least one Genesis commit every day and tracking that on Some days might only see very small commits but I'm shooting for larger, daily updates.

My primary goals right now is getting Genesis to a state where it can boot a system as well as making the code more hacker friendly so more people can contribute.

As for booting I expect to set up a separate git repository for genesis scripts as soon as Genesis is ready for that. It's my hope that most scripts will be contributed by other Exherbo contributors and that I can keep my focus on Genesis itself.

Half the solution..
For a long time I've wanted to replace the Developers listing on Exherbos website with a list generated from git log showing all the authors.

A while ago this got much easier as Ingmar Vanhassel and others added .mailcap files to our repositories. This means that some of my commits that I've accidentally made as kloeri@localhost can be grouped with commits.

The actual page generation is still missing however so I'm looking for a volunteer that want to tackle this task.

Steps involved should be something like:
1. Clone git://
2. Read the Makefile to get an idea how our website is maintained. Reading my old blog post on our website setup is also useful
3. Figure out how to get a list of authors from git log. I just want a plain list containing the real names of all the contributors but without email addresses, commit count or other stats like that
4. Sort the list so it's easier to read
5. Make sure your list can be parsed by Maruku (a Markdown processor) and make sure it's processed along all the static .mkd files

Limiting the author list to just cover the arbor repository is fine for now.

Finally, give me a git format-patch of your changes so I can push it and we can all enjoy the improved website. Of course, you're more than welcome to ask me for help as needed.

Changes in Microsoft Windows EULA
My friend Peter Toft just blogged about an important change in the Windows EULA that could very well affect a large part of us. His original blog post (in danish) is available here.

But the short story is that Windows Vista allowed you to contact the manufacturer for a refund for the software if you didn't accept the EULA and Windows 7 appears to have removed that option. You can know contact the manufacturer to cancel the entire order or have them tell you which rights you no longer have because you didn't accept the EULA. Given how stubborn manufacturers are about refunding the windows license here in Denmark and several other countries I guess the Microsoft tax is pretty much impossible to escape now. The way I understand it this EULA change practically makes it mandatory paying for Microsoft Windows if you want a laptop for professionel use at least.

The exact part of the Windows Vista EULA mentioned by Peter is:
By using the software, you accept these terms. If you do not accept them, do not use the
software. Instead, contact the manufacturer or installer to determine their return policy for
a refund or credit..

The same part from the Windows 7 EULA is now:
By using the software, you accept these terms. If you do not accept them, do not use the
software. Instead, contact the manufacturer or installer to determine its return policy. You
must comply with that policy, which might limit your rights or require you to return the
entire system on which the software is installed.

I know of two current cases where Lenovo refuses to follow the Vista EULA and refund the Windows license. One being in Denmark where FreeBSD developer Poul-Henning Kamp is suing Lenovo and the other being in Hong Kong.

I'm curious how people think this EULA change will affect future refunds in different countries and how it relates to the different court cases in the european union and elsewhere that have already taken steps to limit Microsofts abuse of it's de-facto monopoly and secure free competition.

Please comment if you know of other current cases or have any information that can help keep open source operating systems an option when buying laptops.

Slides from my recent talk on effective community management
On October 24th I did a talk on managing communities more effectively and my experiences with that. The talk draws primarily on my experiences with Exherbo but all my points are more general in nature and can easily be used by other projects.

The slides from the talk also contains some advice for users on how to handle developers more effectively so there's a bit for everybody in it.

The original slides (in danish) are available at CommunityManagement.pdf and the english translation is available at

Exherbo is growing
Recently I've been talking about various community issues and how Exherbo handles them. I think Exherbo has been very successful in making sure people enjoy taking part in the daily maintenance and people have often told me that they really enjoy this aspect of Exherbo.

Not only are we solving technical issues that're interesting to people but we're doing so in a way that makes people want to actively take part in it. And while most people takes part in various ways a few have done some really outstanding work and I've wanted to thank them properly for a while now. So in true open source style I've rewarded them by giving them even more responsibility and full access to all our official git repositories.

A big thank you to Markus Rothe for all his PPC64 work, Elias Pipping for lots of Gnome related work as well as general bug fixes, Ali Polatel for his work on Sydbox as well as lots of Python and media related packages, Marvin Schmidt for his always good work and Thomas Anderson for lots of package bumps and fixes all over the place.


Log in