I found the following quote from Stefano's DPL platform interesting:

When faced with the dilemma, I've favored ditching some DPL tasks and communicating or taking notes about the others, instead of the other way around.

It takes someone who really knows Debian to realize that sometimes communicating about what's being done is more important than doing more.

Inspired by various Planet Debian postings, I've spent some time recently looking into a few RC bugs to help with the Squeeze release.

mpg123-el #581227 A previous commenter on this bug suggested a proposed fix, which I tested and uploaded. I think the bug's severity was inflated to begin with, so I downgraded the bug as well.

doclifter #580246 This one had to do with the python2.6 transition. I pointed out a patch against Ubuntu's version of the package that fixes this problem, and someone else made an NMU based on that. (Seemed like a good idea to look in the PTS for Ubuntu patches since Ubuntu always transitions to newer Python before Debian proper.)

gnuvd #580110 I checked upstream and a new version that's supposed to fix this bug was released today, so I updated the bug report to make note of this and give the maintainer a chance to look at it.

libtommath #583820 This FTBFS bug was caused by a previous NMU that fixed a different FTBFS and also made some unrelated changes. I sent a message to the previous NMUer noting this fact and made a new upload fixing the new FTBFS.

fceu #580820 Needs new upstream packaged to fix. The maintainer seems pseudo-MIA but has shown some signs of returning to activity; I sent an email inquiring as to whether he intends to fix the critical issue in this package.

op-panel #582377 and #571427 These were not merged when I started out, so I merged them after noticing they were the same. I spent some poking at the bug itself and made a simple patch, only to find out that there was a pending patch in pkg-voip's subversion repo. I hopped onto #debian-voip to prod the person who'd prepared the patch in subversion about the importance of updating the BTS when working on bugs. These bugs are currently blocking on testing the patch.

Most all of these bugs I've subscribed to in case of follow-up. (Geez, challenge-response subscription via email is kind of a pain.)

I occasionally get emails from people looking for GPG keysigning around the Boston area, addressed to all the local Debian Developers on the keysigning offers list. Generally, I'm the only one who replies to them, despite there being four or so other people addressed. I wonder if this problem pervades other locations as well.

Keysigning is one of the hurdles every person interested in becoming a full Debian Developer must overcome. The New Maintainer process is a hurdle enough in itself! Let's try not to discourage excited newcomers who are already convinced that they want to help Debian by leaving them hanging for long periods of time trying to get their key signed.

Have you moved? Are you no longer interested in filling keysigning requests? (I suspect many of those who would answer "yes" to that question are actually inactive, and so are unlikely to actually see this.) Are you interested in filling keysigning requests but didn't know about the offers list? Go to the keysigning offers list on the Debian wiki and update, add, or remove your information. There's also the list of people requesting keysigning—you can subscribe to this page to see updates.

Flights and train tickets are all booked (with some difficulty) since a few days ago. Looking forward to seeing people at my second DebConf!

Debathena Beta was rolled out to something along the lines of 10% of formerly RHEL-based computing cluster machines about a month ago. I talked about the plans for this some time ago, and it's exciting to see it actually occurring on vaguely the intended schedule. Now I can tool on campus on Debian (well, almost), and thanks to a generous application of magic**, I can even install any package in Ubuntu's universe repository on cluster machines if I need it (the machine will be restored to a good state on session logout). Rock on.

** I hear it involves schroot and LVM snapshots, but at any rate it appears to be approximately indistinguishable from magic.

Thanks to the hard work of Tim Abbott and the FTP masters, Sage can now be found in the unstable repository. Tim deserves a whole bunch of kudos for his determination in getting Sage into Debian—it involved a lot of working with upstream to resolve a variety of problems that made life difficult for packagers, and, as far as I can tell, a non-trivial amount of time. My involvement in the job was fairly minimal—just reviewing and uploading. There are still a few issues with the packaging that are being worked out with upstream for the next version before sagemath can migrate into testing (after Lenny, of course), but the package should be at least functional.

If you were looking to give Sage a try before but gave up because it wasn't in Debian, now's your chance to check it out! (The same goes if you're interested in free mathematics software but hadn't heard of Sage before.)

The usual suspects apply: too expensive for me especially without a guarantee of sponsorship, etc. Maybe next year!

It turns out that due to a weird collision of circumstances I am going to GUADEC, however. I will probably be doing more Istanbul-exploring than talk-attending, but I will certainly be around for evening socialization.

I am also currently in Cambridge, UK, and will be here until mid-August.

This is the summer of last-minute plans, apparently.

(Disclaimer: I work for MIT Information Services & Technology blah blah blah I am a student blah blah these are only my words and do not represent the opinion(s) of my employer.)

Way back in the day in 1983, MIT started something it called Project Athena, which had the goal of investigating how computers could be used to enhance education at MIT. This project became the origin of such pieces of software as the X Window System and Kerberos, as well as a campus-wide network of workstations all running similar software. In 1991, Project Athena ended, but the Athena system continued on, taken over by MIT Information Systems.

It's 2008, and Athena still exists at MIT--walk into a computing cluster, and chances are all the machines will be running Athena software. (Unless that particular cluster has been taken over be Athena's evil sibling, often referenced as "WinAthena", which often seems to be maintained by no one, and whose existence is sometimes denied by those who maintain and support Real Athena. Not many machines have suffered this agonizing fate, luckily.)

Unfortunately, as the years have progressed recently, fewer and fewer resources have been put into the development of Athena. In many ways it is no longer on the cutting edge of things as it has been in the past, though it is certainly still useful. Some students these days, however, even think of Athena as only "their MIT email" or maybe use it occasionally to print something in a cluster on the way to class. I've seen people grow frustrated and storm out of a cluster due to things like instructions for using a flash drive that involve more steps than just plugging it in. While on the one hand it's easy to laugh at people for a lack of patience or being open to a computing system that is not either Windows or Mac and perhaps a bit more complicated on the surface, on the other hand, some of these things really should just work by now, and on other UNIX-based systems they do--but Athena has lagged behind.

When you log into an Athena workstation for the first time, you are confronted with what looks like this:

That's GNOME 2.8, and it looks kind of like the GNOME 2.8 default but uglier. When you look under the hood, there are pieces of the system that obviously originated in a time where nothing better existed and so something new had to be created--the "xlogin" login system doesn't support PAM, and the login path involves a hairy maze of scripts that perform various tasks. Under the hood, the base OS is currently RHEL 4 or Solaris 10. I still can't remember what the right options are to feed RPM whenever I need some information that I think I should be able to get from it. These things were once necessary but today just look crufty.

Some people have tossed around the idea that everyone has a laptop these days and thus clusters are uselessly expensive, but it's been met with a lot of resistance. I'm all for progress, but I use clusters all the time! They're one thing that makes it an easy choice for me to have a really portable laptop, because when I really need computing power or screen space on campus away from my room, there is always a cluster nearby. They're also nice isolated places that can be associated with "work mode", which is good for productivity. Beyond all this, Athena provides a common platform that all technical classes can depend on, from providing standard and specialized academic software to standing as a baseline of "make sure your code works on this before handing it in because that is how it will be graded".

At any rate, things are finally happening on this front. Athena can't stay RHEL 4 forever--while AFS allows non-system software to be easily updated for all machines without requiring any OS release, hardware moves on and compatibility is lost, and the rest of the world is coming up with new awesome things that Athena machines are missing out on. A student group that I am vaguely involved with, SIPB, took the early initiative with this and created DebAthena, which takes stock Debian and Ubuntu and allows it to closely resemble an Athena environment. We even run a campus Linux dialup using the packages. (I won't claim to have done much work on DebAthena myself because, well, I didn't.) Amazingly, the Athena release team has decided to work with the SIPB on the next release of Athena.

So, what I really just wasted over 600 words prepping for is to say that Athena 10 will be based on Ubuntu. This is only relatively new news, but I am lame about finishing blog posts. There are a variety of reasons why Ubuntu was chosen over Debian. Some of them are lame and some of them are not. Even so, I am excited about this prospect--and it should be possible to peripherally support Debian in such a way that was not possible with Athena 9.4.

I really like Athena. Even coming to MIT with a background in Linux there has been a steep learning curve, though, and I think that things could be better. Lots of people here have their first encounter with a 'nix system in the form of Athena, and we should strive to make that experience as good as possible. I'm kind of skeptical on the expected release date of this upcoming summer, but as long as it happens soon it will be a big step forward.

In some ways it's kind of sad that I'm excited about a big part of a research institution catching up with others--but inertia is a strong force, and dealing with thousands of workstations is no trivial task. I kind of long for the exciting days of creating new big pieces of free software like X. I bet I imagine those days as being better than they actually were.

Going: Best. Choice. Ever.

(Ironically?,) I spent way less time on my computer than I do when I'm at home.

Made it to the "real" Cambridge in one piece. I'm currently in Dafydd Harries and Matthew Garrett's living room.

Last night when we were all sitting around hacking and drinking tea, there were four X-series Thinkpads and four people at the table. Clearly these must be smart people.