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 <debianjr-maintainers@lists.alioth.debian.org> 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 <pjb@debian.org>, 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 <dleidert@debian.org> 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 <debian-eeepc-devel@lists.alioth.debian.org> 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!
Ben

Stay in touch

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

  • Follow my blog: http://syn.theti.ca
    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 irc.oftc.net (irc.debian.org) or irc.freenode.net.
    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: https://www.facebook.com/SynrG
    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: https://wrweo.ca
    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.

Eleventh hour upload of tuxpaint

I have just made an eleventh hour upload of tuxpaint, tuxpaint-config and tuxpaint-stamps. With luck, this will make it in time for the Nov. 5 Jessie freeze deadline so it goes in as an unassisted migration. Coming soon to a mirror near you!

Involve kids in free software development through play

Giving up on a position within a free software project when you know you’re no longer managing to do an effective job is a wonderfully liberating experience. Now that I have started to talk with Miriam Ruiz about handing over the Debian Jr. project, I can stop worrying about the leadership task and just have fun with it.

I can always count on Miriam for recommendations for games in Debian my kids may enjoy, as she has a passion for finding good games to package for Debian, and in particular, games for children. Over the past few weeks we’ve had some fun with her picks. At the same time, I always have Debian Jr. in mind. How can we ensure kids can have the most fun with this? How do we equip their guides to help them?

What we’ve done with each new piece of software is to find a quiet time when one or more of the children can start playing with it on their own while we watch, offering such guidance as they need, but for the most part just letting them loose with it. Each wrinkle of the brow, each impetuous thump of the mouse, every illuminated grin and exclamation of delight is noted. We try to see what frustrates or pleases our kids and discuss it both with them and the Debian maintainers and upstream developers. This is an excercise we’ve managed to pull off without being overly intrusive and the results have been well worth the effort.

Using a few of Miriam’s picks we tried this week, we were able to draw their play into the free software development process. Here’s a brief summary of those sessions:

Platinum Arts Sandbox puts into children’s hands the ability to role play in a 3D world and edit that world using simplified controls. The expressions on the faces of our kids as they played were priceless: both the ups and the downs. I wanted to capture this on video and share it. After having established a rapport with upstream, we took a 20 minute clip of one of our play sessions and gave a copy to them to use to help further their work. Here is the edited result. They were very pleased to have that kind of feedback and found the video valuable for determining where the software still needed improvement and to notice which aspects particularly pleased the children.

I happen to know that Hex-a-hop is one of Miriam’s personal favourites. We have a household full of puzzle-lovers so this puzzle game was an instant hit. While on irc on #debian-jr with Miriam we relayed in real-time some of the reactions as they played this and a handful of her other picks. This gave her some confirmation of areas she knew needed work as well as inspiration for upcoming releases of these packages.

During this play session, which also included StegaVorto, kartofel, Anagramarama, Funny Boat and Vodovod, my youngest girl, age 7, plunked down on the couch next to me as her 10-year-old sister played. Then she started to notice I was typing what people in the livingroom were saying and doing on irc. She took a mild affront to me copying her own words and actions, so I decided it would be better to let her participate so she would feel included. At this point, I started playing secretary for her, typing what she dictated to me while she read the responses from the display. Later, I just handed her the keyboard so she could type and read the responses on her own. She was still at it long past bedtime and it was with some reluctance that she finally gave up the keyboard. We all had a lot of fun and look forward to doing this again.

We are particularly careful with privacy, taking care to share pictures, videos, and other personal details only so far as we believe it does not put our children at risk. Also, we need to ensure we observe in a way that is welcome and doesn’t interfere with their enjoyment. But with a little bit of prudence and a practiced eye and ear for what increases or diminishes enjoyment of the software, we can involve our children directly in the free software development process. I commend to anyone who has the privilege to share free software with children to use this method to communicate with maintainers and developers, increasing your own enjoyment of the software in the process and that of children and their guides everywhere.

Update: A quote from this article has made it to Slashdot. Although many of the comments seem to miss my point entirely, it’s nice to get a wider audience.

The children of Debian

Who are the next generation of Debianists? Are they all still coming to us out of different OS backgrounds, or do we now have the significant beginnings of a home grown generation, born and raised in Debian-using families and now making their voices heard?

I hope that Debian Jr. will encourage this kind of generational growth of the project. When recently I rewrote the guiding principles of Debian Jr., my vision was a Debian that children would identify as their own. I expect they will be eager to add their own ideas as they grow up with it. It was pointed out to me today that there is some evidence that this is already happening (thanks for the link, Matthew Wilcox).

As for my own kids, ages 16, 15, 12, 9 and 5, only the oldest have ever used some system at home other than Debian1. They all comfortably use our Debian systems daily, discussing regularly with me what they need. This leads to filing bugs and patches on their behalf2, and inspires further development of the Debian Jr. project.

So, in at least this sense, the children of Debian are already contributing members of Debian, if not voting members. The ideas of families are improving Debian for everyone. As the project grows, I expect the ways in which families will change Debian will be more significant, not only technically but also in Debian’s character.

1 Before we started using Debian in 1995, the family system was a VT-420 terminal connected to the Solaris system running our community freenet. At that time our kids would sit in my lap and play at typing into pico for their amusement.

2 For instance, I was pleased to discover the other day that my egoboo patch was accepted. That was a direct result of my kids asking me to make it work for them.

Moved Debian Jr. repository to Alioth

A little remembered fact is that the Debian Jr. project had a directory in the subversion repository of the CDD project at Alioth. Aside from Andreas Tille’s experimental conversion of Debian Jr. to use cdd-dev1, there was nothing else there until today.

While I was in the process of populating this directory with the junior-* metapackages and adding an external reference to the live CD config, it seemed to me that it would be better to move the whole thing to our own repository at Alioth, which I promptly did. So now you can check it out:

$ svn co svn://svn.debian.org/debianjr

As well, I registered Debian Jr. at http://cia.vc/ and configured svn so that the CIA bot will report on the #debian-jr channel at irc.debian.org for every commit.

And finally, I applied for the creation of a debian-commits@lists.alioth.debian.org list. As soon as the list is created, I will hook it up to the repository so you can subscribe to commit emails.

1 Although this seemed like a good idea at the time, for various reasons I ended up sticking with the single metapackage per category model Debian Jr. uses to this day. But I have retained this experiment in the repository under svn://svn.debian.org/debianjr/branches/EXP-cdd-dev
in case we ever reverse that decision.

Launcher for xjig adds open dialog and file conversion

I have long recognized that to be usable by young kids, xjig really needs a better user interface. So I wrote a launcher, xjig-menu to address the problem. It adds a file open dialog (via zentiy) and support for more file formats (via imagemagick).

Update

I have put this script in subversion and added a man page. Check it out:

  $ svn co svn://svn.debian.org/pkg-games/people/synrg/xjig

or browse the repository.

live-helper progress

Now that live-helper1 has superceded live-package I have a config for the junior livecd work-in-progress in the debian-live repository:

sudo apt-get install live-helper
svn co svn://svn.debian.org/debian-live/configs/junior
sudo make-live --root junior &>make-live.log

This will build a usb image for the gnome-junior package list. If you want a regular iso image or want to try the kde-junior or xfce-junior lists, just make the appropriate changes in config.

I have tested the usb image on a 1G usb key. At this point I’m not layering on customizations, but am focusing on basic usability issues: X autoconfiguration, sound, menus, etc. Once I’m happy with these I’ll move on to the kinds of customizations we’d like to make for children.

1 live-helper is still in NEW at the moment. I’ve been checking it out from svn and building the package myself, though you can also get Daniel’s packages from his site. My config should work with a2-1 or later.

update

For the time being it is best to stick with live-helper from svn, as my configs are being developed to work with trunk, which is still in flux (e.g. config variables are renamed without notice, etc.)

svn co svn://svn.debian.org/debian-live/dists/trunk/live-helper
cd live-helper ; debuild -us -uc

make-live -p gnome-junior

Ever since I started working towards a Debian Jr. livecd back in November, I’ve played off and on with qemu, approx and debian-live.

Yesterday, I took another kick at the can. Being frustrated with make-live’s inability to combine two package lists, Daniel Baumann came to my rescue, promptly commiting and then releasing live-package 0.99.23-1
with three new package lists for Debian Jr.

  • gnome-junior
  • kde-junior
  • xfce-junior

So now we have something to play with. Try it out. Install live-package 0.99.23-1 or later, configure /etc/make-live.conf to set LIVE_MIRROR to your favourite mirror (I use the apt caching proxy approx to avoid re-downloading the same packages from one run to the next) and pick an image and type to build, e.g.

$ sudo make-live -t usb -p gnome-junior

This makes a ./debian-live/binary.img that can be put on a 1G usb key flashdrive.

We have more work to do to polish this. Particularly, since the GNOME and KDE flavours are larger than a 700M CD, some fat could be trimmed. If you’ve tried it, I’d love to hear your ideas on debian-jr@lists.debian.org.

Towards a Debian Jr. Live CD

Debian Jr. development revived

Recently there has been some lively discussion on the Debian Jr. list about how to arrange an account for a child of 1 to 3 years of age. Suggestions included using set-top box software like Freevo, tailoring DEs with panels and large buttons, using simpler WMs like fvwm, or using an “activity centre” app like Gcompris.

Now, I respect those parents who hold that a child this young should interact more with the “real world”. While I wouldn’t go so far as to outright prohibit my young ones from computer use, I can see the wisdom in keeping it to a minimum. But, for better or worse, our family is one of several who have some experience helping our youngest members use our Debian systems. We would like to share what we’ve learned through the Debian Jr. project.

Getting started with live.debian.net

To that end, last week I was inspired to follow the Debian Live ISO Howto to produce my first rough draft of a Debian Jr. live CD built from scratch on Etch.

For the final product, we’ll want to use a local partial Debian archive mirror, as it not only optimizes fetching packages for several build iterations, but also can be kept stable, which is important as we near release. But for this draft, I ran into trouble building the complete package list to populate the partial mirror, as cdebootstrap, which make-live uses, has no handy --print-debs switch like debootstrap does. So for now, I rely on approx to cache packages for optimization only.

A straightforward process to create a working live CD

The rest of the process was straightforward: using live-package, I created a package list1 containing Gnome and the Debian Jr. metapackages, I configured /etc/make-live.conf to point at my proxy, and then I ran the make-live script on the package list. The end result was ./debian-live/binary.iso, which successfully booted under qemu.

At this stage, there is not much to show. To be truly useful, the live CD needs to be set up so that children and their guides can immediately find and use the material intended for them. We will need not only one live CD user, but four, varying in age range and role. (More about this in a future article.) However, it is an encouraging start, and shows that we may be able to produce something usable by the time Etch releases.

1 For this exercise, I simply combined /usr/share/make-live/lists/gnome with the junior-* metapackages in Etch, and added mozilla-firefox-gnome-support to satisfy Gnome’s web browser dependency and cut down on redundancy, resulting in the following list.

junior-art
junior-doc
junior-games-card
junior-games-gl
junior-games-net
junior-games-sim
junior-games-text
junior-gnome
junior-internet
junior-kde
junior-math
junior-programming
junior-puzzle
junior-sound
junior-system
junior-toys
junior-typing
junior-writing
mozilla-firefox-gnome-support
eject sudo
console-common locales
gdm gdm-themes gnome-desktop-environment gnome-cups-manager gnome-screensaver
gnome-themes-extras
rhythmbox synaptic
x-window-system-core

Mythgame player to run native Linux games

I recently started to be aware of a problem in our family. Ever since we configured Mythgame to run Xmame games, we started to ignore native Linux games. This is a shame, because often the quality of such games is much higher, and besides, they are open source, which I strongly believe in.

I looked around for help configuring Mythgame to run Linux games, and was unable to find a way to make a game player that would play any Linux game. So I devised the following solution:

Step 1: Set up directories for pseudo-roms, command switches and snapshots


mkdir /usr/share/games/roms
mkdir /usr/share/games/switches
mkdir /usr/share/games/snaps

Step 2: Define a player in Mythgame


Player name: Linux
Type: OTHER
Command: %s `cat \`dirname %s\`/../switches/\`basename %s\``
Rom Path: /usr/share/games/roms
ScreenShots: /usr/share/games/snaps

Step 3: Populate the directories with data


cd /usr/share/games/roms
ln -s /usr/games/oolite
ln -s /usr/games/starvoyager
cd /usr/share/games/snaps
cp ~synrg/snaps/oolite.png .
cp ~synrg/snaps/starvoyager.png .
cd /usr/share/games/switches
touch oolite
echo "-f" >starvoyager

Step 4: In Mythgame, “Scan for Games”

Step 5: Play!