blog conservation debian development eeepc family installer irc jr live nature packaging taskwarrior trail tuxpaint wellness xjig xpilot

Retiring as a Debian developer

This is a repost and update of my retirement letter sent privately to Debian last month, July 10, 2016. At that time I received many notes of appreciation and good wishes which I treasure. Now, I’d like to say goodbye to the broader Debian community and, as well, indicate which of the cleanup items have since been addressed in strikethrough style and with annotations. Also, I’d like to stay in touch with many of you, so I have added some comments oriented towards those of you who are interested in doing that after the letter.

When in 1995, on a tip from a friend, I installed Debian on my 386 at work and was enthralled with the results, I could not have foreseen that two years later, friends I had made on channel #debian would nudge me to become a Debian developer. Nor when that happened did I have any idea that twenty years later, I’d consider Debian to be like family, the greatest free software community in the world, and would still be promoting it and helping people with it whenever I could. Debian quietly, unexpectedly became a part of what defines me.

My priorities in life have changed over that time, though. I have shifted my attention to things that are more important to me in life, such as my family, my health and well-being physically and spiritually, and bringing all I can to bear on the task of preserving our local wilderness areas and trails. In the latter area, I’m now bringing all of what Debian has helped shaped me to be to the table, launching some ambitious projects I hope will bear fruit in the coming years, and make a measurable contribution to help us hang onto our precious natural preserves where I live.

Unfortunately, as I’ve poured more time and energy into these things, I’ve increasingly not been giving my packages the care they need. Nor do I have any roles or goals now for any of the Debian projects I was previously involved in. So, after much careful deliberation, and as much as it pains me to say it, it’s time to retire as a Debian developer. It has been a great privilege to work with you, and to meet many of you in New York at Debconf 10. I plan to be around online, and will continue to take an interest in Debian, lending a hand when I can. Thanks for all of the fun times, for all that I’ve learned, and for the privilege to make awesome things with you. I’ll treasure this forever.

So much for the soppy bits. ๐Ÿ™‚ Now, business. These things remain to clean up upon my departure, and I’d appreciate help from QA, and anyone else who can lend a hand. My packages are effectively orphaned, but I haven’t the time to do any of the cleanup myself, so please speak up if you can help.

  1. Debian Jr.
    • O: junior-doc. The junior-doc package has been awaiting an overhaul by whoever revives the project since I gave it up years ago. I’m still listed as maintainer and that should be changed to Debian Junior Maintainers <> if they want it. Otherwise, it is orphaned.
    • I should also be dropped from Uploaders from debian-junior, the metapackages source. Fixed in git.
  2. Tux Paint. This is a very special package that deserves to go to someone who will love it and care for it well. There are three source packages in all:
    • O: tuxpaint
    • O: tuxpaint-config
    • O: tuxpaint-stamps
  3. O: xletters. This is a cute little typing practice game and needs a new maintainer.
  4. XPilot is co-maintained by Phil Brooke <>, so he should replace me as Maintainer. Phil said he’ll pick up xpilot-ng and will also look at xpilot-extra.
    • xpilot-ng
    • O: xpilot-extra (recently removed from testing due to my neglect, and not co-maintained by Phil; it’s unclear if anyone really uses this anymore)
  5. GTypist is co-maintained by Daniel Leidert <> and should replace me as Maintainer.
  6. My ruby packages. A group of packages that I brought into Debian as dependencies of taskwarrior-web, which I never completed. Maybe they’ll be useful in and of themselves, and maybe not. In any case, they are maintained by pkg-ruby-extras-maintainers, but I’m the sole developer in Uploaders and should be removed: Fixed in git.
    • ruby-blockenspiel
    • ruby-parseconfig
    • ruby-rack-flash3
    • ruby-simple-navigation
    • ruby-sinatra-simple-navigation
    • ruby-term-ansicolor
    • ruby-versionomy
  7. Debian Live stuff: I am listed in Uploaders for live-manual (fixed in git) and debian-installer-launcher (fixed in git) and need to be removed.
  8. O: eeepc-acpi-scripts. The defunct Debian EeePC project has just this one package. Recently, the mailing list was asked about its status, and it was recently NMU’d. To my knowledge, nobody from the original team remains to take care of it, so it needs a new maintainer. I should be removed from Uploaders, and since the Debian Eee PC Team no longer exists, it should be removed as maintainer. It is effectively orphaned unless someone speaks up.

There are also some Alioth projects / lists that are defunct that I’ll need to talk to the Alioth admins about cleaning up in the coming days. One of these is <> and since it is still listed as the maintainer of eeepc-acpi-scripts, that needs to be sorted out before the list can be closed.

Thanks again, and see you around!

Stay in touch

For those of you who would like to stay in touch, here are some ways to do that:

  • Follow my blog:
    If you already do that, great! If not, welcome to my blog! For the past couple of years you may have noticed a decrease in technical content and increase in local trails and conservation oriented posts. You can expect more of the latter.
  • Say hi to me on irc: SynrG (also SynrGy) on ( or
    I still intend to hang out and offer support when I can, just no longer as a developer. Channel #debian-offtopic on either network is a good place to catch up with me socially.
  • Follow me on Facebook:
    For better or worse, a lot of the trails and conservation folks hang out here, and many of you in the Debian community are already my Facebook friends.
  • Look for my Bluff Trail posts on their site:
    Providing tech support to this organization is where much of my time and energy is going these days. I post here once in a while, but do most of my work behind the scenes as a volunteer and, newly this year, as a board member.
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).