spaceblog

It would be really nice if those projects that consider themselves to be major pieces of infrastructure made it a priority to support a build on stock vendor releases of distros older than the current release.

I’m trying to build OpenLDAP 2.3.20 on Red Hat 7.3. Yes, that sounds like a bad idea, and it is quite painful. This pain is mostly due to the versions of Berkeley DB that OpenLDAP wants to build against: Red Hat 7.3 shipped with BDB 3.3.11; it wants at least version 4, bud the configure script makes it quite clear that version 4.1 isn’t supported.

The LDBM backend can use older BDBs, i.e. 3.x, but OpenLDAP 2.2 deprecates the LDBM backend in favour of back-bdb. That concerns me for a 2.3 series build of OpenLDAP: is it still stable, or has it been left to rot? Of course the test suite doesn’t cover the LDBM backend…

I would really like to not have to build for this old OS version, but sadly it exists and it needs to be a syncrepl slave. In order to finally put this box to rest it needs to have OpenLDAP running, so that we can migrate the services off it with minimal outage. There are so many bugs running OpenLDAP on this box that I want to try this 2.3 series version on it, in the same configuration as every other machine on the network, but the more I work on it, the less it feels like I’m making any progress on it at all.

Fighting version dependencies on old distros just isn’t fun. If the developers had considered this, and at least said “OK, well, RHEL 2.1 is still supported by Red Hat, so let’s try to configure and build on that platform too” then this wouldn’t nearly be as painful as it is.

The Annodex developers, as well as Conrads’ other projects (sweep, etc) work quite hard to make sure they build with the versions of libraries on peoples year-old desktop machines; sure this means sometimes having extra code to cope with API differences, but a small amount of effort on the developers part makes a massive difference when you think about how much time the users will spend trying to get the software to build.

It’s the little things that make the difference between an OK project and an Awesome project.

Meanwhile, on the cutting edge of RHEL 3 and 4, and FC 4 and 5, latest OpenLDAP 2.3 looks to be a really promising piece of work, the amount of work that’s gone into it since 2.2.27 is impressive, and if it works nearly as well as it looks like it will from the ChangeLog, then that’ll finally put to rest a whole lot of problems we’ve had since deploying LDAP as our authentication database.

Fingers crossed I can get there without losing all my hair.

HFS the conference bag we’re looking at is so amazingly awesome.

Yesterday, four of the seven trekked up to [redacted] for some hands-on experience with the bag in question. You guys are going to love it! Here’s a picture of the bag:

If for no other reason, you should come to LCA 2007 here in Sydney JUST FOR THE SCHWAG.

Once upon a time, (25th of August 2003 to be precise), Goswin von Brederlow submitted a patch to add RFC822-like output to debbugs. It never made it into upstream.

This is very sad.

I’ve spent all morning writing some test code that screenscrapes my Debian bug list from the quasi-HTML that it generates, using the almighty BeautifulSoup. But in the end it’s a hack, it’s dirty, it’s not very general and it’s going to take a bit of work before it’s usable with tuffet for anyone but me.

Debbugs, Bugzilla, Sourceforget, none of them have a programmatic interface. (Ok, so there’s a patch that adds XML-RPC to Bugzilla… has it been incorporated upstream yet? Who other than Gnome and Red Hat are actually using it?) What decade are we in again?

Request Tracker has a programmatic API – REST. So RT’s off my immediate shitlist, but nobody’s writing client libraries for REST so again I’m building up dirty hacks to get the immediate job done.

I suppose that this will change over time. I hope that this tool will get used by enough people that there will be demand for programmatic APIs in all the bug tracking webapps out there. I also hope that all webapps that provide some storage service create a programmatic API – LiveJournal and Flickr and Google Maps are great examples of what people can do when your access to the data model is not restricted to an HTML view. MVC all the way baby.

If you’re writing a public webapp, you are doing your users a disservice by not considering non-browser access to the data model. If you’re building an public webapp for the open source community, and you don’t have a programmatic API to your data model, you’re not just doing your users a disservice, you’re committing a crime against humanity.

At LCA 2005, Luis Villa presented a talk on being a bugmaster, and that inspired me to do some triage on SCons. Unfortunately that means dealing with Sourceforget’s hideous tracker interface, so of course I never got around to it.

Some months and thinking later, I realised I needed to pay more attention to my Debian bugs, which being in a separate bug tracker meant they were rarely on my radar. In our own office, we have both a Request Tracker and a Bugzilla, and keeping a track of my todo list is pretty hard when it’s split between the two – it’s hard enough when requests come from staff out of band of either of them.

I also forget how to use the tools: there’s a threshold of work in triaging bugs, and if that threshold is too high, I’ll do something else instead.

So the solution was to make a tool that put all my bugs, all tickets, issues, problems, feature requests, and so on into a single view – aggregate them from all the trackers that I use and put them on my desktop. Present a single interface to triage all those bugs, so that I don’t have to remember how to use the upstream tracker.

I mention this all, because Mark Shuttleworth’s keynote this morning really hit home with me – all of the merging of information and collaboration is exactly the way to go forward, and I’m excited that Canonical is building the infrastructure to help push that forward.

So, I have this tool, still in development, in bzr:

bzr pull http://repo.spacepants.org/bugtool/bugtool.dev/

It’s able to pull bugs from Sourceforget, and from the RT instance in our office; needs a bit of work now to get the interaction going but that should appear in the coming weeks.

I don’t like the name, though… I’m thinking it should be called ‘tuffet’:

Little Miss Muffet
Sat on her tuffet
Triaging her bugs all day

Along came a spider
and sat down beside her
So she "triaged" that bug with some spray.

Congregation,

Please open your Lions’ Book to Chapter Seven, page 7-1, verse 7, and we shall begin.

At the Lower Level, "processes" are inactive entities which are
acted on by active entities such as the processor.

On Sheet 15, line 1550 (Chapter 1, “Initialisation, Process Initialisation”), we find the main() function of the kernel. It takes no arguments, and returns nothing. It starts by zeroing and freeing all of core, and printing a copyright :-)

The System 6 code uses an initial indent of 3 spaces, and then 8 spaces for every level of indent after that.

–

Tonight, a “cartel” of ex- and current UNSW students pooled together to win the auction of a copy of the Lions’ Commentary on the System 6 Unix Source, famously distributed by John Lions from UNSW via photocopier before it was officially published in 1996.

The book in question was signed by the original Unix hackers Ken Thompson and Dennis Ritchie, as well as Eric Allman of Sendmail fame, as well as Linus Torvalds, to name a few. (The speakers of the LCA 2006 conference also have signed the book). The auction was to raise funds to support the creation of the John Lions Chair – a position for a professor of great talent to teach in perpetuity at UNSW.

Tonight, we raised and bid $10,000 to this cause. The book will appear on display at the University of NSW, in honour of Lions, who has inspired generations of students and academics in the elegance of simple design, open communication and sharing of knowledge; key elements of the community of open source.

We’d like to thank those members of the open source community who offered bonuses to the auction to boost the bid, and as such claim the following:

• Jeff Waugh’s hair.
• The text ‘The KDE Project uses and recommends the GNOME DESKTOP’ in the KDE 4 about dialog.
• Rusty Russell’s mustache.
• Dave Miller’s facial hair in its entirety.
• Greg ‘groggy’ Lehey’s facial hair.
• The text ‘We may be fast, but for real data security, use PostgreSQL’ in the MySQL 5.1 release notes.
• A thankyou to John Lions in the Planet 1.0 release announcement.
• oh there were probably more, but who can remember? :-)

(the LCA 2006 photoset has been updated)