Gitolite 3.0 is out.  It’s a total rewrite from the 2.x series, which will be maintained for some time, apparently.  I’m working on updating the Fedora RPM (rawhide only, or course).  It’s not entirely compatible, but migration looks pretty straightforward.  The best part. . .we can drop all our patches. 🙂


The things we do

I like making RPMs.  I do it for Fedora, and it’s fun.  I do it at work, and I like that too, but sometimes I do things that make me cringe.  In my defence, I was driven to it by something that rhymes with Whoracle.



More systemd migrations done.  I’m getting a better feel for how some of the more complex use cases work.  If you want me to do yours, let me know.

Some movement on Merge Reviews, new count is down to 69 NEW.  Not too bad.

And Beta looks great.  Following the yum upgrade page, even usermove was painless.

F17 Beta today

Today should, barring major catastrophe, mark the release of Fedora 17 Beta.  The download page hasn’t yet been updated, but the moderately enterprising can figure it out.  Download, enjoy, test, test test!

Hardened builds

Amongst the recent set of Packaging Guidelines changes written up and announced (thanks spot!) was this one.  If you maintain a package for anything that has an executable that’s long running, like a server daemon, runs as root, is setuid or uses capabilities, or accepts untrusted input, I strongly recommend you have a read.  Then consider trying it out on your relevant package(s).

I ran down my list, and identified several that seemed like good candidates.  Most programs build just fine with the change, and it’s only 1 line added to the spec file, which calls a macro to add to the build flags, so it’s easy to do.  Most code won’t show any run-time effects, other than a tiny reduction in startup speed from lack of prelinking, but for a long-running and/or root process, it’s more than worth it for the extra security.

Given that F17 Beta is gold and on it’s imminent way, this is a great time to try it in F18.  In the unlikely event that it breaks anything, you have plenty of time to fix it.


Another reason I like systemd

Got a bug report that liquidwar-server was crashing.  I’ve been playing liquidwar for ages, but had never used the server.  So I don’t really know how long that’s been broken, I inherited the package from someone else.  So I patched that. Total time spend on buffer overflow: 10 minutes.

The server ran great from the command line but hung when started by systemd.  I changed the service type from forking to simple (by removing the Type declaration) and it worked as expected, so I committed and built for rawhide and f17.  Total time spent on systemd issue:  5 minutes.

Then I worked my way back to f16, which is still on sysvinit.  Patch applied, binary ran, but it still hung at service start.  I’ll be the first to admit that I’m not a sysvinit expert.  I experimented and googled and eventually stuck quotes around the command and arguments.  Total time spent on sysvinit issue: 20 minutes.

It took me more time to fix the sysvinit issue than the systemd issue, but it also took me more time to fix the sysvinit issue than it took me to fix a C buffer overflow.

And that is one more reason why I like systemd. 🙂