Colors of Noise

Many team maintained packages in Debian are maintained in Subversion which makes a lot of sense if people agreed on a common workflow. If you want to use git to work on these packages you can still do so with a bit of configuration without changing anything for the other team members. Let's take system-config-printer as example. git-svn can be used to checkout the svn repository:

git svn clone svn+ssh://svn.debian.org/svn/pkg-gnome/ -T packages/unstable/system-config-printer -t tags/system-config-printer system-config-printer

Since the pkg-gnome team keeps all the packages in one huge SVN repository and splits the directories by release first and then by package the above command uses -T to point git-svn to system-config-printer's trunk and -t to point it to the tags directory. In simpler repositories where trunk, branches and tags are subdirectories of the same base directory using --stdlayout instead is enough.

Since in SVN based packaging the upstream sources usually aren't kept in the repository git-buildpackage needs to know where to find them and how to combine things in the build-directory:

cd system-config-printer
cat <<EOF >.git/gbp.conf
[git-buildpackage]
# Build in a separate build-area
export-dir = ../build-area/
# Look for tarballs in ../tarballs
tarball-dir = ../tarballs/
# Overlay the upstream sources on top of it
overlay = True
# Don't use pristine-tar
pristine-tar = False
# Compression type of the tarball
compression = bzip2

Like with svn-buildpackage the orig-tarball is expected to be found in ../tarballs where you should put it now e.g. using the get-orig-source target of debian/rules (yes, git-buildpackage should support this implicitly). You can then work on the package as usual using all the nifty git commands like git-rebase, etc. and build the package (in this case using git-pbuilder):

git-buildpackage --git-pbuilder

or if you don't want to export the current branch's HEAD of your git repository but your working copy (which might contain uncommitted changes) to the build-area instead use:

git-buildpackage --git-pbuilder --git-export=WC

The built packages can then be found in ../build-area. Once the package is ready pushing the changes into the SVN remote repository is as simple as:

git svn dcommit
git svn tag -m"Tagging system-config-printer (1.2.3-0.2)" 1.2.3-0.2

The last command appropriately tags the new version. This saves a bit of typing. In order to fetch changes others have made use:

git svn rebase

Chris reports back to Debian duty: `Since one week I'm back from NYC where I enjoyed a very nice Debconf. It was my second one after last year in Cáceres. When I unpacked all my luggage - three weeks in the US need some stuff - I found these cute green guys between my clothes. Did they break their UFO and use my airplane to travel with me? Anyway. Thanks to all who made Debconf10 in New York possible. It was a great conference! And last but not least: "Happy Squeeze Freeze"' I too enjoyed DC10 a lot.

I got tired of having to authenticate as root to change printer settings like paper size or printout mode via a GUI. Since system-config-printer uses PolicyKit things like allow myself to change printer settings when logged into the system should be possible without having to mess with cupsd.conf or sudo, are they?

Which printer related actions are governed by PolicyKit:

pkaction | grep printer

shows about the following if you have cups-pk-helper installed. The later is used by system-config-printer to interface with PolicyKit:

org.opensuse.cupspkhelper.mechanism.printer-enable
org.opensuse.cupspkhelper.mechanism.printer-local-edit
org.opensuse.cupspkhelper.mechanism.printer-remote-edit
org.opensuse.cupspkhelper.mechanism.printer-set-default
org.opensuse.cupspkhelper.mechanism.printeraddremove

So org.opensuse.cupspkhelper.mechanism.printer-local-edit seems to be what I'm looking for. Let's change the policy for this action:

cat <<EOF >/etc/polkit-1/localauthority/50-local.d/99-local.pkla 
[EditPrinters]
Identity=unix-user:foo
Action=org.opensuse.cupspkhelper.mechanism.printer-local-edit
ResultAny=no
ResultInactive=no
ResultActive=yes
EOF

This allows user foo to perform the action org.opensuse.cupspkhelper.mechanism.printer-local-edit if the user is logged into a local interactive session. The pklocalauthority(8) manpage has all the details. PolicyKit will pick up the configuration file changes on the fly. Lets see if this worked by getting the process id of the running system-config-printer and checking via pkcheck if the process is authorized to use that action:

PID=$(ps a | awk '/[p]ython .*system-config-printer/ { print $1 }')
pkcheck --action-id org.opensuse.cupspkhelper.mechanism.printer-local-edit --process $PID
echo $?

If pkcheck returns with a zero return value everything is fine and user foo won't need any password to modify local printer settings from now on.

Check the output of pkaction(1) to list more actions that can be setup this way.

Git-buildpackage 0.5.6 in experimental got rid of it's pbuilder/cowbuilder examples and added Russ's nice git-pbuilder script. I'm very happy how this turned out, now building with cowbuilder is as simple as:

# Initially create a cowbuilder environment once
git-pbuilder create

# Build the package
git-buildpackage --git-pbuilder

# At a later point update the cowbuilder environment with new versions
git-pbuilder update

Or for another distribution:

DIST=lenny git-pbuilder create 
git-buildpackage --git-pbuilder --git-dist=lenny

The new version also better interacts with dch from devscripts. So things like:

git-dch --bpo|--qa|--nmu

are now also supported when adding new changelog sections. Git-dch now detects new upstream version numbers automatically and bumps the version accordingly. In order to get this working I finally fixed the tag format.

Since the current version in unstable should get a chance to move to testing first, I've uploaded 0.5.6 to experimental.

Those old school ones among us that still need a printer who are new school enough to want to get rid of HAL should try system-config-printer from experimental. After replacing hal-cups-utils by system-config-printer-udev aptitude tells me:

    The following packages will be REMOVED:
      hal{u} hal-info{u} 
    0 packages upgraded, 2 newly installed, 2 to remove and 121 not upgraded.

Which means faster startup times and one daemon less on Squeeze's GNOME desktop. The new version also uses PolicyKit instead of gksu for finer grained permission control.