Going to Debconf11


See you in Banja Luka!

Upcoming travel

April is shaping up to be a busy month; I have several trips lined up.

I'll be giving talks on Cassandra at Texas Linux Fest and POSSCON, and I've organized a Debian booth for Texas Linux Fest (a first for me).

The hackathon should also be a real treat. It's always great to spend a little face-time with the people you normally only interact with online.

As always, if my travel plans intersect with yours (or if you live in Austin, Columbia, or San Francisco), and you want to chat over a beer (or coffee, tea, etc), drop me a line.

Git repo for Cassandra packaging

I put the repository for my Cassandra package up on Github. The repo browser can be found here, and the wiki has a brief writeup of the build process for those unfamiliar with git-buildpackage.

Patches welcome!

NP: Take It Out On Me, Bullet For My Valentine

On the road again

Debconf is over. Boo. :(

Like those I've attended in the past, Debconf9 was well organized with plenty of interesting talks, in a great venue. I had loads of fun, learned a ton, and even managed to get a bit done. Many thanks to the organization team, the local team, the speakers, and the sponsors.

This year I managed to sneak an extra couple of days post-conference which will be spent in the general vicinity of Madrid. I'm going to continue dumping my camera daily so tune into my flickr stream if your interested.

Cassandra 0.3.0 for Debian

As announced here, I put a Debian package together for Cassandra 0.3.0.

I don't have any (immediate )plans to upload a Cassandra package to the Debian archive, (this package isn't even policy compliant), so consider this unofficial and report any packaging bugs directly to me.

deb http://people.apache.org/~eevans/debian cassandra/
deb-src http://people.apache.org/~eevans/debian cassandra/


Debconf9: Day trip

Yesterday was the Day Trip at Debconf, an opportunity for folks to step away from their computers (usually), and leave the venue (always) for some sort of group activity or tourism.

When the organizers first started talking about this years Day Trip there were two candidates, Valle del Jerte and Teatro romano de Merida, or "Roman theater of Merida". I'm kind of a history junkie and generally get pretty excited at the idea of touring ruins so I was heartbroken when Merida lost out. The closer it got to the scheduled day the lower my enthusiasm sank, until eventually I just opted out entirely. The obvious by-product of skipping the Day Trip though was a need to find something else to do, and the obvious choice seemed like a trip to Merida. Michael was pretty keen on the idea too.

The entire thing was thrown together very last minute (we barely made it to the bus station), but luckily there was enough time to spot a generous offer via IRC from itais (a Merida local) for transportation from the bus stop to the theater.

As promised, itais was waiting for us at the bus station and took us on a quick tour to see, among other things, a Roman acquaduct and The Arch of Trajan. He then dropped us off in front of the theater with a recommendation for a place to eat.

After an awesome meal we walked the ruins for a couple of hours, tracked down The Temple of Diana, and then settled into the main square for a couple of beers before catching a cab back to the bus station.

Much fun.

A few of the pictures I took can be seen here, and I'll get the rest up eventually.


Going to Debconf9

A week from today and I'll be headed to Spain for Debconf9. Can't wait!

NP: Worlds Collide, Apocalyptica

Transitioning My GPG Key

A few months ago a group of researchers announced a fairly serious attack that shattered everyone's faith in SHA-1. It has frightening implications for anyone who relies on cryptographic signatures, and while consensus is that there is little danger in the near-term, most people agree that now is the time to start a move to something stronger.

So, I've begun my transition, (document here), and submitted my new key for the Debconf9 signing party later this month. I intentionally left out any mention of a time-line in the transition doc, and I'm in no big hurry. I'll retire the old key once I have enough signatures, or once there is evidence of a real threat, whichever comes first.

Howto: Epson Perfection 3940 on Debian

Getting the Epson Perfection 3940 scanner setup on Linux requires jumping through just enough hoops that even if you have managed it before, it's easy to forget when it comes time to do it again.

I put this here in the hopes that it will make things easier for someone, (and it's entirely likely that someone will be me one day :).

  1. Make sure your user is a member of the scanner group, (adduser youruser scanner).
  2. Install xsane, (sudo aptitude install xsane).
  3. Get the firmware. It seems most people grab one of the Suse RPMS of iscan-firmware.
  4. Get the firmware out of the RPM (rpm2cpio iscan-firmware- | cpio -i --make-directories).
  5. And install it, (sudo install -m 644 usr/share/iscan/esfw52.bin /lib/firmware/)
  6. Edit /etc/sane.d/snapscan.conf and adjust the firmware directive to point to /lib/firmware/esfw52.bin
  7. Profit.

Thrift Packaging

My latest project at work is Cassandra, a distributed, eventually consistent, column oriented data store. It's somewhere between Dynamo (Cassandra's original author worked on Dynamo), and Google's BigTable. It was developed as an internal application at Facebook, later open sourced, and is now an Apache incubator project.

The external interface to Cassandra is thrift-based. Thrift is a framework for creating network services, services that communicate using a compact binary data format. It's similar to Google's Protocol Buffers, but with more of a focus on RPC, and greater language coverage, (much greater actually). The bottom line, any application that uses Cassandra for structured data storage is going to need Thrift. So, I filed an ITP (Intent To Package) and have started work on packaging it for Debian.

Thrift is an interesting project to package as it has an architecture specific application (C++), 6 architecture specific and 5 architecture independent libraries, and covers 12 different languages. That's right, 12.

I'm still somewhat undecided on a game plan; the options I've considered so far are:

  1. Convince upstream to split their source tree and distribute all of these libraries separately, allowing them to be packaged by people with the skills and/or motivation for each.
  2. Split the source myself and package the bits that are most important to me.
  3. One source package based on the official upstream release, with binary packages for each of the components that I need/am comfortable maintaining. Folks interested in the parts not packaged could step up to the plate and contribute their time.
  4. Best-effort packaging of most/all of the libraries upstream ships with the proviso that for any I'm not comfortable seeing in a release, and for which no one has stepped forward for, they would be removed prior to Squeeze.

I've already taken a stab at #1 and it didn't seem promising. #2 is an option I still consider on the table but I'm a little concerned that it could lead to a mess. #3 and #4 really boil down to the same thing, collaborating with others to package as much as possible while maintaining the standards everyone expects from Debian. I guess I'm currently leaning toward some variation of #3 or #4, probably through the use of collab-maint or a dedicated Alioth project.

For the time being, my efforts can be tracked in Git here, so drop me a line if you're interested in joining the fun!

NP: Sand and Mercury, The Gathering

Lenny Released On Time

Lenny released yesterday. This is great news, and congratulations all around to everyone that worked their asses off making it happen.

By my calculations this comes 677 days after the initial release of Etch, (or 22 months and change). I've said before, Debian releases When Ready and that (to the best of my observations), consensus seems to be that somewhere between 18 and 24 months is the sweet spot. Not only does this make for the second "on-time" release in a row, but there was an Etch-And-A-Half sporting new kernels and video drivers in the mean time.

With any luck the various "Debian is too old/can't release" memes will finally die.

Back Home

After 5+ hours on a bus, several hours at Ezeiza airport, and 12 hours on two different planes, I'm back home from Debconf8, (technically speaking I've been back since 8am yesterday, but was in no condition to post).

Debconf8 was definately the best organized of the 4 Debconfs I've attended, and Argentina was an awesome setting, but it is good to be home.

Pictures are here or here.

Update: I've updated the Debconf8 set on Flickr with a panorama of the beach and skyline in front of the conference venue.

Happy Birthday Debian

15 years ago today, Debian was born.

Publishing divergence from upstream

On Monday I attended Martin Krafft's talk, Packaging with version control systems. Martin has started a project, coordinated via http://vcs-pkg.org, to explore work patterns for packaging and cross-distro collaboration using distributed version control systems. This is a topic that I've spent a fair amount of time on so it was interesting to see Martin's packaging work flow, and hear him discuss its evolution.

Today I attended a Bof organized by Luciano Bello. Luciano is the developer that discovered the recent OpenSSL vulnerability. The point of the BoF was to discuss ways of preventing this sort of thing from happening in the future. The vulnerability in question was introduced in a Debian-specific patch, so a good bit of the discussion centered around code review and the need to make Debian's upstream divergences more transparent.

There were quite a few in attendance that felt that the best way to publish divergences is by using a patch series, (something that recently received first class support by way of the new dpkg v3 format). I used to fall into this camp, but a blog post from Joey Hess got me to reevaluate my work flow, and I now feel pretty strongly that using a patch series is not the answer.

I switched to Git a while back and have adopted a work flow similar to Martin's with an upstream branch, a Debian packaging branch, and topic branches for each customization or bug fix. Obtaining the divergence from upstream is a simple matter of diff'ing the topic branches against the upstream branch and the entire change history is preserved. Using a patch system alone seems woefully inadequate when compared to any of the modern VCS, and generating a patch series from branches in a VCS feels like, as Martin likes to say, Yak Shaving.

I plan to subscribe to the vcs-pkg.org mailing list and follow the discussions taking place there. It should be interesting.


It's that time of year again!

Going to Debconf

I'm at the airport soaking up a little free bandwidth (yes, it would seem that San Antonio International finally has free wifi), before boarding a flight to Houston, and then on to Buenos Aires. With the layover in Houston, the four wait before catching the bus to Mar del Plata, and the six hour bus ride itself, I'm looking at a full 24 hours of travel.

This year I am going to try and post at least a couple of times while there, and put up a few pictures while I'm at it.

Die Disk, Die

There's been a lot of "Ubuntu kills laptop hard drives" buzz going around lately. The implication is that over aggressive power management is causing excessive load/unload cycles, exceeding a reasonable duty cycle, and drastically shortening the life of your drive. I run Debian unstable on my laptop but I looked into it anyway and sure enough it's something which is effecting me as well.

As Matthew Garrett points out, it doesn't have anything to do with Ubuntu, Debian, or Linux in general, the culprit is aggressive power management settings in the drive firmware, or settings applied by the BIOS.

If this is happening to you, it's possible that it can be rectified with a firmware upgrade or by updating settings in the BIOS. The solution I chose was to allow laptop-mode-tools to control power management, applying maximum power savings when on battery (hdparm -B 1 /dev/$device), and disabling it when on AC power (hdparm -B 254 /dev/$device).

If you have an otherwise default install of laptop-mode-tools on Debian you can accomplish this by setting CONTROL_HD_POWERMGMT=1 in /etc/laptop-mode/laptop-mode.conf and issuing an /etc/init.d/laptop-mode restart.

Duplicity backport for Etch

I've been backing up all of my important machines to Amazon S3 using Duplicity for sometime now. It's worked out really well but required just enough hackery to prevent me from providing straight forward instructions for others.

I'm all about sharing the love so I submitted a new S3 backend to upstream using the excellent [boto] (http://code.google.com/p/boto/) library from Mitch Garnaat, and I packaged boto for Debian. The new backend made it into the 0.4.3 release of Duplicity, which in turn migrated to testing a couple of weeks ago. Now there is an Etch backport of 0.4.3 on backports.org.

In addition to installing duplicity from backports.org you will also need to pin python-boto from Lenny.


Etch Released On Time

Etch released yesterday. Awesome news. Now I rant.

There is no one-size-fits-all release cycle. Some people wait on pins and needles for the next release of their favorite distro, and six months is almost more than they can bear. Others milk their vendor's support for a full six years and are upset when it is EOL'd and they are forced to upgrade. Releasing every six months and supporting each release for six years is a costly endeavor because it means floating up to twelve releases at once. Someone once said that you can make some of the people happy some of the time, but not all of the people all of the time. They must have been talking about distribution release cycles.

It's very difficult (some would say impossible) to obtain consensus among volunteers in a project the size of Debian. I don't speak for the Debian Project as a whole, but I do however perceive this as an area where consensus has been reached, and the time-line is: When It Is Ready. "Ready" as it is used here relates to the completion of certain goals outlined at the beginning of the cycle combined with the absence of release critical bugs. "When" is targeted at 18 to 24 months after the previous release, but only if it is "Ready".

Debian does not have a fixed release schedule. If that bothers you then you are free to jump in and try to change things (it is a community-based project). If it bothers you than perhaps you should consider a distribution that does have a fixed release cycle. You could also just try getting over it.

Etch released when it was Ready (22 months and 2 days after Sarge). Etch released on time.

Debconf6: Pictures

I'm back home now, but before settling into my normal routine I thought I'd take the time to get some pictures put up.

Debconf6: Crap

I just ate a bug. On purpose.

Debconf6: Day 6

Yesterday was a little disappointing. As the day wore on my upset stomach persisted despite the fact that I ate nothing but a handful of crackers. I seriously considered attending the formal dinner anyway, (and just passing on the food), but in the end decided against this based on the need for frequent and immediate access to a bathroom. I really should have went.

As reported on a number of blogs, it turned out to be quite an evening. My favorite though is Joey's.

Debconf6: Day 5

Yesterday was the day-trip to Xochicalco, the remains of a pre-hispanic city. Afterward, we had lunch at a restaurant nearby, and then it was on to Cuernavaca where we had about an hour to walk around the market and do some shopping.

Of note is that yesterday was the first day since I've been here that I did not eat at least one meal at the open market in the village. It is also the first day that I've felt sick. Go figure.

Debconf6: Day 2

I went to the marcado for breakfast this morning, quesedillas de papas y chorizo, and polo con queso. Damn fine. I was also able to score some melon agua, something I haven't had since I left El Paso. Deciphering the menu, placing my order, and paying was made awkward by the language barrier though.

On that note, I've alway been irritated watching folks attempt to communicate with a non-English speaking person by talking very slowly, and very loudly. Not to slag my own country, (there are plenty of others around to do that for me), but I thought this practice was uniquely American. I was wrong. Surprisingly, it was not irritating to be on the receiving end, it was kind of funny.

Next Stop: Oaxtepec

Just soaking up a little of the free WiFi here at the airport and then I'm on my way to Mexico City. With any luck I'll meet up with peterS at the airport there, and then it's on to Oaxtepec for Debconf 6.

It should be a lot of fun, I'm pumped.

Coming soon: ucarp 1.2-1

Coming soon to an archive near you, a shiny new version of ucarp, the first in more than a year.

I've also put the packaging source up on my darcs repository.