(It s a new day, it s a new bug )
A regression appeared in the
synaptics input driver, between the
1.4.1 and the 1.5.0 release, as reported in Debian
#649002 by many users. Basically, no
more touchpad on PowerPC (hi, iBook G4 users!).
:-(
What follows is how I tracked it down. The upstream bug report is
fdo#43728. Anyone could have
done so, there s no black magic involved. A little hint maybe:
git bisect
is really easy on X drivers, since one can build and test
without the Debian packaging bits.
1st step: Getting started
You need sources and build dependencies, nothing fancy. Since packages
might be named a bit differently, there s a reference to the relevant
upstream repositories in debian/watch for X packages.
# You need git here:
debcheckout xserver-xorg-input-synaptics synaptics.git
cd synaptics.git
# Let s get the upstream tags and branches:
cat debian/watch
git remote add upstream git://anongit.freedesktop.org/xorg/driver/xf86-input-synaptics
git fetch --all
# Let s install build dependencies:
sudo apt-get build-dep xserver-xorg-input-synaptics
2nd step: Reproducing
It was said 1.5.0 was the first known buggy version, so let s make
sure:
# Get the appropriate tag:
git checkout xf86-input-synaptics-1.5.0
# Prepare the build system:
autoreconf -vfi
# X finds its modules under /usr, not /usr/local:
./configure --prefix=/usr
# Build and install:
make && sudo make install
Now time to restart the display manager, and confirm that the pointer
is not moving bug reproduced.
Now let s check the 1.4.1 release isn t affected:
# Clean everything:
git clean -xdf
git checkout xf86-input-synaptics-1.4.1
autoreconf -vfi
./configure --prefix=/usr
make && sudo make install
And after a display manager restart, the pointer is moving again,
good! For reference, the log has very different lines about
appletouch, so it can be used to programmatically learn about the
status (good or bad).
3rd step: Narrowing it down
So, we have a known good version and a known bad version. Time for a
binary search to find the guilty commit which introduced that
regression!
git bisect start
git bisect good xf86-input-synaptics-1.4.1
git bisect bad xf86-input-synaptics-1.5.0
You don t even need to know that 1.4.x and 1.5.x live in different
branches, git figures that out for you:
Bisecting: a merge base must be tested
[de0dfb76444ad4160468d00515876c91a9fa20bf] synaptics 1.4.0
It s just a matter of running
autoreconf && ./configure && make && sudo make install && sudo /etc/init.d/xdm restart
every step of the way, so it s pretty easy.
No wonder, 1.4.0 was working OK, so it can be recorded as such through
git bisect good, and the binary search goes between that commit and
1.5.0. After a few iterations of
git bisect good and
git bisect bad,
we get to the commit reported on the upstream bug.
As an extra bonus, mentioning the upstream bug number/URL in the
Debian bug means it can be marked as
forwarded there and we ll
receive automatic notifications when its status changes, thanks to
bts-link.
Now, if you want to provide a patch for this bug, you may want to try
and revert this commit.
4th step: Providing a patch
Let s go back to the affected release and try to revert the guilty
commit:
git checkout xf86-input-synaptics-1.5.0
git revert 13543b156d78bc4d01a19844a5ee8f283269621b
Unfortunately, some later commits modified the affected areas so we re
running into conflicts:
error: could not revert 13543b1... eventcomm: replace synaptics-custom TEST_BIT with server's BitIsOn.
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
Let s try to understand what the
offending commit
did: it replaced a set of macros with a single one, taken from the
server. Both the old
TEST_BIT() and the new
BitIsOn() take 2
arguments, but the order is reversed. Reverting it should only be a
matter of introducing the
TEST_BIT() macro again (along with the two
other ones it needs), and using it.
The problem is replacing all
BitIsOn(foo,bar) with
TEST_BIT(bar,foo):
foo and
bar might not be trivial, they could
be complex C expressions, and a replacement in your favourite editor
might not get all occurrences right.
Thankfully, there s a nice tool to handle such things, called
coccinelle. I won t go into details,
just show how it can help here. Basically you just need to craft a
tiny patch, called a
semantic patch, which describes what I wrote in
the previous paragraph. You only need to declare two expressions, say
a and
b, and declare that all
BitIsOn(a,b) must be replaced with
TEST_BIT(b,a). Here s the syntax:
@@
expression a,b;
@@
-BitIsOn(a,b)
+TEST_BIT(b,a)
Save it under
testbit.cocci and apply it through
spatch (from the
coccinelle package), asking it to perform in-place replacement
(we re in a git checkout copy, remember):
# Apply:
spatch -sp_file testbit.cocci -in_place .
# Profit:
git diff
Then you can run
git commit -s, write a nice commit message, send it
upstream, and enjoy the rest of the night.
Coming soon to a mirror near you:
fixing commit.
As mentioned on the upstream bug report, I got the Debian reference
wrong in the commit message, I really meant
#649002.
Thanks to the longstading work by Paul Wise in nearly 3 years...and
with some help from my side (and from other members of the font
packaging team), we're getting closer of a longstanding goal : removing Defoma
from the archive. Defoma is indeed obsoleted by fontconfig, which
doesn't need these "hints" file, turning the packaging of fonts into a
very simple process.
On last Saturday, Paul sent the removal
request for defoma. The request mentions blocking bugs that are, for most of
them, requests for font packages to drop the dependency on defoma.
As we already sent patches for these bugs, I started NMU'ing the
remaining packages this week-end. Most of them were apparently nearly
abandoned packages, so I had no shame doing that so quickly. Indeed, I
no longer fear NMU'ing packages even for non critical issues and I
even sometimes no longer fear adding a few other fixes when the
packages are very obviously poorly maintained (things like source v3,
debhelper compatibility bump, build- indep arch targets support,
etc.).
After this NMU wave, we should be left, in one week, with only five
packages blocking the removal of defoma. I might even NMU some of
them, though some are TeX-related packages providing T1 fonts
additionnally to TrueType ones...something I'l less familiar with.
Whatever happens, I now nearly sure that wheezy will not have defoma.
Yay! Hats off to Paul.
Late last month our six year anniversary of moving to the US quietly came
and went. This also makes it six years with Google.
I think if you had have told me at the start of 2005, that I'd be ending the
year off by starting a six year (and counting) stint in Silicon Valley, I
wouldn't have believed you.
Six years is comfortably the longest I've spent in any one place since I
moved out of home (the four years living at the Central Park Apartments was
the longest I've spent in any one home, also).
Six years is also far and away the longest time I've stayed with one
employer.
I wonder what life will be like in another six years' time?
I got this error when starting xend after a filesystem crash:
[2011-12-09 11:05:04 5590] ERROR (SrvDaemon:349) Exception starting xend (not well-formed (invalid token): line 3, column 0)
It sounded like an XML parsing error, but the stack trace in the log didn t say which file it had loaded. It turns out that it was trying to load something from /var/lib/xend/state/. Purging the /var/lib/xend/state directory fixed the problem, and hopefully had no side-effects.
Thanks to 
It s been a couple days since I returned from this year s WebKitGTK+ hackfest in A Coru a, Spain. The weather was very nice, not too cold and not too rainy, we had great food, great drinks and I got to meet new people, and hang out with old friends, which is always great!
Prepare a location to run juju and install it:
It has been a while since I blogged but I've been very busy, with my new job and this new blog!
New job!
I quitted my job last September, and found another one that I started in
October. I'm now the lead developer of 
Updating the bios on my X200 Tablet was surprisingly simple in Debian.
Often, updating bios requires some sort of Windows or Dos boot disk
and all kinds of machinations to make that happen. Lenovo provides an
iso image to update the bios which alleviates some of these problems,
but as the X series don't have built-in CDROM drives (and I don't have
an ultrabay),
All you have to do is download the
This weekend, we held a combined Debian Bug Squashing Party and Ubuntu Local
Jam in Portland, OR. A big thank you to PuppetLabs for hosting!
Thanks to a brilliant insight from Kees Cook, we were able to give everyone
access to their own pre-configured build environment as soon as they walked
in the door by deploying schroot/sbuild instances in "the cloud" (in this
case, Amazon EC2). Small blips with the mirrors notwithstanding, this worked
out pretty well, and let people start to get their hands dirty as soon as
they walked in the door instead of spending a lot of time up front doing the
boring work of setting up a build environment. This was a big win for people
who had never done a package build before, and I highly recommend it for
future BSPs. You can read about the build environment setup in the