CUPS-PDF: how my first Debian package briefly became a key component of the Ubuntu desktop strategy

Back in 2003, I packaged my very first piece of software for Debian: CUPS-PDF. The observation came to a German physics researcher, Volker C. Behr, that he constantly needed to generate PDF documents as a daily part of his workflow and that he would rather do this via desktop application's Print menu, so he coded a simple CUPS printer driver that spits out PDF documents instead of paper sheets.

This packaging gig has been one of the best cases of upstream collaboration I've been involved with, simply because Volker himself subscribes to the BTS for CUPS-PDF at various Linux distributions and because he is very proactive at responding to bug reports that concern the upstream code and the philosophy behind its implementation.

Simultaneously, there's been plenty of collaboration between Debian and Ubuntu on this package. For starters, maintaining a CUPS driver meant that I should maintain close collaboration with the CUPS maintainer. Back in 2003, this meant getting to know Kenshi Muto, first on IRC and then in person at Debconf5.

At the same event in 2005, many people had their first real experience of Ubuntu, when Mark Shuttleworth made his first keynote appearance at a Debian event. This later lead me to becoming familiar with the work of Martin Pitt and Till Kamppeter on the Ubuntu version of CUPS and CUPS-PDF packages, because Ubuntu had decided on delivering PDF generation as a standard feature of its desktop and CUPS-PDF was considered as the key solution towards implementing this. However, CUPS-PDF being a mere printer driver, it did not fit well with the GUI-oriented paradigm of the desktop, so pre-configuring the package with sensible default settings only partially worked. This issue was recently solved when GTK2 and QT (the core libraries behind GNOME and KDE applications) were upgraded to include printer management and PDF generation by standard, which resulted in the Ubuntu build of CUPS-PDF being relegated to the Universe repository.

Amusingly, the most interesting part of my collaboration with Martin and Till wasn't how it slowly helped me improve the packaging of CUPS-PDF on Debian, as much as that it introduced me to the wonders of Launchpad (tracking other distributions' bugs on the same package, Personal Package Archive, etc.) and it eventually convinced me to switch to Ubuntu for everything except my old ThinkPad, which I retained as a genuine Debian environment for development purposes.

While CUPS-PDF has mostly been superseded by GTK2 and QT's new printing features on the desktop, it definitely remains a key element of an educational or enterprise network, especially in a situation where desktop computers are in fact thin clients connecting to an LTSP server and where PDF generation is a part of the standard daily workflow.

Speaking of which, I'm currently looking for investors to launch a business venture that leverages and expands upon the ideas I've developed at Linutop and Artec. Please contact me via e-mail if you're interested in financing this venture or if you know someone who would be.

Almost there: granny-friendly PDF writing

One aspect of Ubuntu that I really enjoy is the sheer amount of constructive feedback a maintainer gets about the usability of their packages. In my case, CUPS-PDF [1] [2] has been a landmark example of how beneficial this feedback can be:

See, one long-standing goal at Ubuntu has been to include the capability to generate PDF documents "out of the box" and regardless of which Desktop Environment is used. Many people considered that CUPS-PDF would be an excellent tool, but various technical issues prevented this from working in a security-conscious way. Once that issue was taken care of, someone pondered how the PDF queue could be automatically created at installation time?

It turns out that we're almost there: with the upload of version 2.4.6 into Debian today (which should propagate into Ubuntu within a few days), only one configuration step remains: the selection of a PPD driver. Everything else is automatically detected and configured by CUPS itself. Kudos to our friendly upstream, Volker, for implementing this driver magic in his back-end code! Enjoy!

CUPS-PDF finally works on Ubuntu

For a long time, one of my Debian packages, cups-pdf, could not work on Ubuntu, because Ubuntu runs its CUPS daemon using a low-privilege user. I'm happy to report that this issue is finally resolved: following the release of CUPS 1.2, a simple solution was discovered by Andre Klitzing.

However, I only noticed this recently, after registering myself on Launchpad to respond to Ubuntu bugs affecting my Debian packages. Sigh! Perhaps notifying me earlier, via the Debian BTS, would have been a good idea?

Anyhow, after checking that the solution wouldn't break anything on the Debian side, I committed the fix to cups-pdf 2.4.1-2. Enjoy!

Tales of positive upstream collaboration

Amaya talks about a case where an upstream developer contributed a patch to the Debian package of his software. I'll take this opportunity to mention a couple of positive experiences of my own:

• CUPS-PDF is a CUPS backend to generate PDF documents instead of printing out hard copies. Given my complete ignorance of CUPS internals, I figured that I would kindly ask upstream to subscribe himself to the PTS, just in case an RC bug would rear its ugly head.

  Volker immediately agreed and, sure enough, someone filed a number of RC bugs resulting from an audit they had performed. Volker replied and argued every point with the submitter by himself, then promptly released a new tarball which included all the fixes.

  This is the best case of collaborative maintenance I've encountered so far: Volker maintains his code and I maintain the Debian package. Everybody wins.

• Ispell-et is an Estonian wordlist from which all 3 dictionary variants (aspell, ispell, myspell) are generated, plus an hyphenation pattern for OpenOffice, which upstream also uses to generate compound words.

  Jaak is a linguistic technology developer whose extremely busy schedule leaves very little time for hobbies. However, the appearance of my package in the Debian repository renewed his interest in maintaining his wordlist. He promptly reviewed my package and suggested a couple of fixes to improve the quality of the dictionary generation process. He also proposed further improvements to eventually generate Hunspell dictionaries as well. Once again, everybody wins.

Wouldn't it be great if all upstream developers subscribed to the Debian PTS for their software and answered bugs related to the codebase themselves?