Somewhere at the beginning of the holiday madness, which seems like a long couple of weeks ago, my laptop crashed and came up with a bad superblock. That's Not Good, but fsck fixed it, and I was too busy preparing for company and parties and trips and stuff to do anything about it. And forgot about it.

Of course it died. Right before new years, and with only 5 minutes advance warning from SMART before it started spewing IO errors and corrupting files. I have a new drive on order, and am running diskless from NFS over wireless, which is an amusing way to use a laptop, but acceptable if you don't plan to go anywhere for a few days. Maybe they'll be snowbound days.

This seems less of a disaster than other times a laptop's disk has died on me. When did it start to become routine? Maybe this will be the second to last time -- I certianly hope that my next laptop has a flash disk. The Debian Live CDs were quite helpful before I set up the NFS, and I even managed to use the default gnome desktop for an evening with them, without utterly hating it. My mr and etckeeper setup made it easy to check everything back out from revision control. So the tools for dealing with a dead laptop disk are improved, though d-i still doesn't support installs over NFS, which would have saved me some time setting that up.

The first snow is starting to fall..

discussion

Clock: inserting leap second 23:59:60 UTC

Happy leap second, everyone. The earth's rotation slowed by another second, and the extra second was added just before the new year.

Or did it? According to the NIST "NOTE: No leap second will be added at the end of December 2007"

So why did some of my machines see one and some not? All are running NTP, all using pool.ntp.org. Perhaps some NTP servers in the pool falsely inserted a leap second?

According to this thread I'm not the only one to notice spurious leap seconds, one also happened in July 07, and this page documents one in July 06 with some great graphs.

Figuring out whodonit is tricky..

(Insert {conspiracy theory,thriller plot} here.)

Does anyone else enjoy using git just to produce images like this in gitk? I can't look at this without imagining it as a london-tube-esque map of a public transport system that wisked my code up to its current exaulted state at the top of the Red Line.

(Officially a git fanboy now obviously.)

discussion

Yesterday alioth's ikiwiki was upgraded from 1.x to 2.x. About 15 or so people seem to use ikiwiki on alioth. If you do, please read this page for instructions about the upgrade and some other hints. There are some incompatible changes in 2.x, most notably usedirs.

discussion

I'm about to release debhelper 6.0.0. But this blog is really about CDBS, and why it's entirely unlike debhelper despite being based on it.

With CDBS you're building a ship in a bottle. You have all the same tools available, but there's this bottle in the way, which doesn't let you bring any of them fully to bear, and requires all your techniques be changed around to fit its limited interface.

This is a beautiful example of the kind of fun you're setting yourself up for by chosing CDBS. With debhelper, two commands can be easily reordered. With CDBS, you need three magic environment variables and either a hardcoded package name or some grody Makefile code: http://lists.debian.org/debian-python/2008/01/msg00039.html

Porteños greeted the new year by fleeing the city as fast as gridlocked roads could take them. January is the month Buenos Aires takes its summer vacation, and the destination of choice is Mar del Plata, a seaside resort I have never visited. Given my love for crowds, heat and strangers' children it sounds it would be my own personal Mordor. "You can't even see the sand for all the people! It's an absolute madhouse!" Argentine friends tell me in horror, as they pack up their cars to head down there.

-- from Idle Words

Makes me glad that I'll be there in the August chill for DebConf 8. I hope.

I bought one of the new terabyte drives, to double the storage space on my home network. I put it in a Thecus, so I have a terabyte of storage in a computer about the size of my first computer's floppy disk drive.

I happened to be wearing my old LinuxCabal T-shirt when I ran across this video.

Wow, memories.

The past few weekends I've been drawn to the mountains. Two weeks ago I went up on Holston mtn after the snow had melted down here, and enjoyed a snowy hike on the AT. From there I drove over to Shady valley, and found the only gas station I've seen with a wood stove in it. I've never enved a gas station attendant their workplace before, but that was nice.

Last weekend Maggie and I went up to Roan mtn. On road up we began to get glimpses of the peak in between the fog, and it looked strange, almost like there was snow, but not as white as you'd expect. While the ground was clear of snow, the windward side of each pine, rhododendron, and leaf of grass in the balds was outlined in a thick coat of frost. Gorgeous. As a sheltered Southerner, I've never seen anything like it, but I think it was soft rime, formed from the fog.

We wished we'd brought a camera, but thanks to the magic of the 'net, here's a similar rime on Roan:

I'm not much of a joiner. I do better at starting things than joining things others have started. I spent the first 16 years of my life not online, followed by 16 years online. Maybe some time I will spend some serious time not-online again, who knows.

Today I found the book My Tiny Life, thanks to Biella, and re-read its chapter "A Rape in Cyberspace". I last read that sometime in 1995 or so, early into my own time online. That was one of a few things that got me interested in virtual worlds. But while I logged into LambdaMOO and a few other MUDs briefly, I didn't join any of them. I observed them, and spent some time developing my own, with modest success.

Another document that I remember reading was a short post to comp.os.linux.announce titled "Debian and FSF Cooperate". That and a few other things got me interested in Debian, and I did join it, and have gotten so tightly bound up in it that there's no way out.

Of course, before I so explicitly and decisively joined Debian, I had sort of joined the larger "free software community". But it's so split up and many-faceted that it took a long time to really feel a part of it. Nowadays I can get git commits accepted into to free software projects that I don't feel I'm part of at all, despite my name appearing in their commit logs.

For a while it seemed perhaps I should join in on Wikipedia. Lots of people I knew were doing so. I looked at it in detail, looked at discussion pages and internal documents and lots of stuff, and decided not to join it. I have no wikipedia login, and have only anonymously edited it once or twice to post corrections on discussion pages.

I joined in on the blogging thing, and sometimes feel part of something there, although it's the most amorphous and vague thing of all.

In the woods on a chilly day. I've been walking around enjoying ice covered waterfalls and creek. I was up late last night reading Julain Dibbell's My Tiny Life, and wandering around a deserted LamdaMOO as Rosy Guest, finding some of the places in the book still there with little change over a decade later.

This was engrossing, but mostly depressing, I kept finding too many parallels to things I don't like about the communities I'm active in online. I was on LambdaMOO briefly myself ten years ago, but only long enough to decide I needed to set up my own moo so I could freely build. Reading this book makes me glad I missed all the drama.

I didn't realize how cold it was last night until the heat just wouldn't stay off, though I had it on the lowest setting. Having the heat on explains why I woke up with a scratchy eye and stuffed nose -- but not why only one side of my face was affected and the other side fine.

Brr, my hands are getting cold..

We have a problem with our tools in Debian, and it's this:

Above the core tools in dpkg-dev, and the nearly core tools in debhelper and devscripts, and the many different -- but all slowly converging -- revision control systems, there is the potential for infinite cruft to pollute the source package.

Note that one developer's cruft is another developer's use of an excellent tool. If you don't believe that, you haven't read a lot of crufy upstream build systems, because Debian isn't the only project with this problem.

The source of this cruft is a near-constant stream of new tools that are each developed in good faith by someone who needs that tool, and then adopted and used in packages of a generally small percentage of developers, who think that tool might be a good fit for their problems. The tool isn't yet suitable for everyone to use, and most of these tools never become suitable for everyone, because

1. making the leap from a special-purpose, poorly-designed hack to a general-purpose tool is hard
2. getting the project to standardise on a tool is hard
3. a tool often doesn't become general purpose until enough people use it, no matter how well designed it is to start out with

So after a while, a better, or at least different, solution to some of the same problems will come along, and some generally small percentage of developers will choose to use it in their source packages. Meanwhile, the developers who chose the old thing will be set in their ways and not want to use the new thing, and generally cannot be budged to stop using the old thing by any amount of argument.

Which in a sense is normal, and fine, until you have to collaborate with them. I don't care if someone I'm collaborating with uses emacs to my vim, but I do care if they use cdbs to my debhelper. I care because their tool-choice encrufts the source that I'm supposed to be working on.

Once a significant percentage of all the source packages in Debian are encrufted for a wide array of different tools, it will become harder and harder to work with Debian's source packages. We're already seeing this happen. Another way of looking at it is that we've invented dozens of source package formats that all work differently, aside from a small shared core, and we expect our developers to be able to use all of them.

At this point I see this as a huge, potentially killer problem, that is making Debian development become worse with every passing year. But I have no real solution. Obviously pointing out that tools are obsoleted or bad doesn't work; we still have dozens of packages using yada, which everyone agrees is horrible. That doesn't bode well, does it?

One partial solution is to design a category killer, and get it embedded in acknowledged core tools. That's what I have tried, and so far, failed, to do with an evolutionary change to the Debian source package format, which I'd hope would give people a reason to stop using dpatch, dbs, and their ilk. As noted, this approach is Hard.

For now, I have no interest in being on a team that requires I use any of the following things:

• dpatch
• dbs
• quilt
• Any similar system that is used to move all patches to under the debian/ directory.
• Any system that nests the actual original upstream .tar.gz inside an .orig.tar.gz.
• yada
• cdbs
• Any similar system that obfuscates debian/rules.
• Any special script that is required to be used to build a package as a wrapper around dpkg-buildpackage.

This means that I can't be on the security or release teams, and even teams like the perl team are getting sticky to be on.

PS, this doesn't mean I dislike quilt. I dislike quilt encrufting Debian source packages, which is entirely different.

PPS, In case you're wondering why debhelper gets a pass, it's because it's gone through the three numbered steps above to become a standard, general purpose tool, and has no serious competators. (Though it does have parasites, like cdbs.)

discussion

Bee-dum

Bee-dum

5 minutes later:

Bee-dum

2 minutes later:

Bee-dum

1 minute later:

Bee-dum Bee-dum Bee-dum Bee-dum Bee-dum Bee-dum
Bee-dum Bee-dum Bee-dum Bee-dum Bee-dum Bee-dum Bee-

At this point I ripped my doorbell out and threw it away. Hurrah.

discussion

With pristine-tar version 0.5, I've added a new feature: The ability to easily inject enough information into a git repository so that a pristine tarball can later be regenerated from that repository.

If a package's upstream branch contains the upstream source corresponding to the tarball to be imported, it's very simple to use.

joey@kodama:~/src/fbreader> pristine-tar commit ~/lib/debian/unstable/fbreader_0.8.12.orig.tar.gz 
pristine-tar: committed fbreader_0.8.12.orig.tar.gz.delta to branch pristine-tar

Otherwise, you also have to specify a tag (or any tree-ish really) where the upstream source can be found.

joey@kodama:~/src/fbreader> pristine-tar commit ~/fbreader_0.8.9.orig.tar.gz upstream/0.8.9
pristine-tar: committed fbreader_0.8.9.orig.tar.gz.delta to branch pristine-tar

Here's what it puts in the pristine-tar branch that it creates. In this example, the delta files are 40-some kilobytes, which is much nicer than if I'd had to check the 2 megabyte tarballs into git directly.

joey@kodama:~/src/fbreader> git checkout pristine-tar 
Switched to branch "pristine-tar"
joey@kodama:~/src/fbreader> ls -l
total 104
-rw-r--r-- 1 joey joey 46583 Jan 31 21:26 fbreader_0.8.12.orig.tar.gz.delta
-rw-r--r-- 1 joey joey    40 Jan 31 21:26 fbreader_0.8.12.orig.tar.gz.id
-rw-r--r-- 1 joey joey 45267 Jan 31 21:26 fbreader_0.8.9.orig.tar.gz.delta
-rw-r--r-- 1 joey joey    40 Jan 31 21:26 fbreader_0.8.9.orig.tar.gz.id

Don't forget to push the pristine-tar branch to your server for safekeeping.

joey@kodama:~/src/fbreader> git push origin pristine-tar

Once a tarball's delta is checked in, you can easily and quickly regenerate the original tarball.

joey@kodama:~/src/fbreader> pristine-tar checkout ../fbreader_0.8.12.orig.tar.gz
pristine-tar: successfully generated ../fbreader_0.8.12.orig.tar.gz

Yes, it's really the same file. :-)

joey@kodama:~/src/fbreader> md5sum ~/lib/debian/unstable/fbreader_0.8.12.orig.tar.gz ../fbreader_0.8.12.orig.tar.gz 
8045abe1acc75dbdd220400df541f23f  /home/joey/lib/debian/unstable/fbreader_0.8.12.orig.tar.gz
8045abe1acc75dbdd220400df541f23f  ../fbreader_0.8.12.orig.tar.gz

The above example is from the perspective of a maintainer of a Debian package. But this can also be used by the authors who generate the pristine tarballs in the first place. Check them into git using pristine-tar. Then you can regenerate any tarball you've ever released using just your project's git repository.

joey@kodama:~/src/pristine-tar> pristine-tar commit ../pristine-tar_0.5.tar.gz tags/0.5
pristine-tar: committed pristine-tar_0.5.tar.gz.delta to branch pristine-tar

One word of warning: For pristine-tar to check out the tarball, git needs to be able to check out the tree that you referred to when you committed it in the first place. If that was a tag that you've told git to delete, you're SOL. If it was a branch and the branch has changed in the meantime, that's fine, so long as git can find the original id that is stored in the .tar.gz.id file.

I hope that tools like git-import-orig and git-debimport can get support for automatically calling pristine-tar commit when importing tarballs into git, and that tools like git-buildpackage and gitpkg can use it to check out the tarballs.