Howto: Epson Perfection 3940 on Debian

Posted May 10, 2009

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-1.18.0.1-10.i586.rpm | 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.

Categories: debian linux

Thrift Packaging

Posted May 1, 2009

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

Categories: debian geek programming thrift