debian ubuntu

Keeping free software projects fun as they grow

On the whole I agree with Erich. Subprojects are key to preserving positive energy as a free software project scales. But I wouldn’t say the ill effects suffered by projects as they age is just “a matter of size”. And I wouldn’t de-emphasize the importance of guidelines like the Ubuntu Code of Conduct and the Debian Community Guidelines in countering those effects, though I’d agree they do not provide immunity by themselves.

Ubuntu benefits from the Debian social experiment having started first. So the people involved have the opportunity to learn from and improve on earlier efforts while their project is still young. The DCG and CoC are no panacea, but they are a clue that lessons are being learned; deliberate effort needs to be made to keep work fun, especially as a project grows and people begin to lose touch with each other. Putting these lessons into practice isn’t always easy, but I think it would help if as individual developers we’d reflect more on how we interact within our projects and work on making improvements. I appreciate the personal guidelines Erich shared and will adapt them to make them my own.

debian packaging

Plumbing the depths of cdbs

On #debian-games we were discussing today how opaque cdbs is for those who aren’t intimately acquainted with its inner workings. I want to be able to easily see, at least at the level of detail visible in a purely debhelper-based rules file, what’s going on inside just by running make itself, e.g.

debian/rules -p | grep -v ^# | grep -B1 dh_

Here’s a small excerpt of the output when run on ri-li:

        dh_installdocs -p$(cdbs_curpkg) $(DEB_INSTALL_DOCS_ALL) $(DEB_INSTALL_DOCS_$(cdbs_curpkg))
        dh_installexamples -p$(cdbs_curpkg) $(DEB_INSTALL_EXAMPLES_$(cdbs_curpkg))
        dh_installman -p$(cdbs_curpkg) $(DEB_INSTALL_MANPAGES_$(cdbs_curpkg))
        dh_installinfo -p$(cdbs_curpkg) $(DEB_INSTALL_INFO_$(cdbs_curpkg))
        dh_installmenu -p$(cdbs_curpkg) $(DEB_DH_INSTALL_MENU_ARGS)
        dh_installcron -p$(cdbs_curpkg) $(DEB_DH_INSTALL_CRON_ARGS)

OK, it’s a bit crude and misses a lot of interesting details, but it is a starting point that can be tweaked to zero in on whatever parts interest you.

debian games xpilot

XPilot change of upstream growing pains

XPilot development has changed hands over the past several years. While the
original website at continues to be run by the original
developers, XPilot-NG ( is where all of the new development has
been happening. But still performs an important function for the user
community: they run the meta servers1 that list all public xpilot servers around
the world.

Recently, we (the XPilot-NG developers on #xpilot at noticed
quite a number of uncontactable servers popping up on the meta servers. This is
annoying, to say the least. Users don’t know they can’t connect until they’ve
tried (unless they’ve bothered to try pinging the server first) and besides
which, having all those “junk” servers in the list makes it harder to locate
contactable servers.

Now, naturally, we wanted to know where all of those servers were coming
from, and why now, at this particular time? I knew my Debian package (and
presumably any derivatives) do not report to the metaserver by default. Any
admin starting an XPilot server would have to explicitly configure it to do so,
so the incidence of uncontactable Debian XPilot-NG servers should remain
relatively low and have a constant growth rate. Then I found the Fedora
package, and started poking around inside. After a shallow review of the
package, I concluded there was a good chance it was the culprit2, especially
since it recently (FC5) had an init script added. Such a bug, coupled with the
relatively recent release of FC5, would account for the sudden spike in number
of permanently running non-contactable XPilot-NG servers.

Bingo! I found some helpful folks at #fedora-games at, including the XPilot NG maintainer, which
led to filing this
. I subsequently invited the maintainer over to #xpilot and had a nice time introducing him to the other upstream devs and chatting about our current issues.

Ultimately, we know we need to fix the problem at the metas, but in the meantime, I am pleased to have established contact with my counterpart in the
Fedora project, expanding the diminishingly
small XPilot developer community by one.

1 They deliberately never released any source code for those metas
to try to keep the user community unified at the centralized servers. While I
see the reasoning behind the decision, given the problems we’re facing now,
it’s clear the XPilot community would be better off with meta server source that
is actively being maintained.

2 Admittedly two problems with the +reportMeta option upstream set us up for this problem. First, counterintuitively, +reportMeta disables reporting to the metaserver (following the rule ”+” negates the meaning of an option starting with ”-”). Second, -reportMeta is a stupid default. Most people starting servers are behind firewalls these days, so unless they consciously decide to make their server public, making the corresponding adjustments to their firewall, the option should not be set (not to mention the security implications of making a server public by default).


Work around GTK+ open type ahead find

Typeahead find in gvim’s GTK+ open dialog box is driving me bananas, but today I discovered a trick I hadn’t seen before that will help work around it with a bit of relearning.

For those who aren’t familiar with the problem, John Goerzen describes how painful this feature is for large directories. Just imagine, then, having to regularly deal with large directories on particularly slow, remote filesystems. Argh. Unusable!

The trick I came up with to work around the problem is to first enter the path incorrectly and then fix it afterwards. Type a blank first, then the whole filepath, then [Home] to return to the beginning of the line, and finally [Delete] to fix the path, and [Enter] to open the file.

It still takes an awfully long time for gvim to read the file, but it’s a great improvement over either trying to type the filename blind, or waiting for each directory to be scanned. Ultimately, these files should be moved off the remote filesystem and into subversion, but there are cross-platform compatibility issues that prevent me from doing this at this time (OpenVMS + Linux + win32).

I’m still looking for a real solution. In the comments to John’s post, someone suggested there is a gconf setting that controls this, but so far I haven’t been able to find it. So for now, I’ll have to live with this hack.

debian jr kids

Geek father

Being Father’s Day today gives me pause to consider Debian Jr., a project for kids. The goal was to make Debian the OS kids prefer to use. I wanted my own kids to grow up enjoying using a system that puts the fewest barriers in the way to learning about how computers work, and to making computers work for them.

It’s nearly six years later now: enough time for my second youngest to grow from a toddler to an eight-year-old girl, for my youngest girl to be born and put to the test the lower limit of our “for kids from 0 to 99” slogan, for our boy in the middle to grow from a preschooler to a preteen, and for the two oldest girls to turn into teenagers. Perhaps by the time we have grandkids, Debian Jr. will finally be “done”.

In that time, our kids have gone from using a VT-420 attached to my Pentium 100, exploring commands using the “magic” tab-key at the bash prompt, playing with words and letters in pico, to playing 3D games and creating artwork in the Gimp on the family Sempron 3300+. And through it all, they’ve remained happy and proud to use Linux, which none of their friends have. They have become, I believe, more firmly grounded and comfortable with computing than they might have been using a system “dumbed down” for kids.

To all the Debian using fathers out there today, Happy Father’s Day! May you and your kids’ lives be enriched as you share in the finest OS in the world.

debian jr programming

Junior programming refocused on “kid languages”

I’ve refocused the Debian Jr. programming metapackage on languages made for kids. I’m sure there are some who have used scheme or python with their kids, and sure, if you want to do that, go ahead. But these were only initially included because of a lack of choices.

Littlewizard is an icon-based language only recently added, and kturtle replaces the less-kid-friendly ucblogo. I’ve also been pursuing #236721 to see what it would take to get Squeak into main. While it doesn’t look like there’s hope of that anytime soon, recent changes to their licensing might allow it to go into non-free.

blogging debian rails

Tinkerer and explorer

Always a tinkerer and an explorer, I’ve known I wanted to self-host a blog for some time. Blog hosting sites have their pluses, but I couldn’t resist making something distinctively mine with cool technology like the Rails-based Typo. Besides, I couldn’t be outdone by my wife, who has for months now kept a successful knitting blog. The time has come. will include ideas about programming at work and play, Debian development, home-based learning, kids and family, or whatever else strikes my fancy or seems noteworthy at the time. No lofty goals, in other words. Just a place to collect my thoughts and connect up to the blogosphere.