Stuff/team I’m currently involved with:

• Debian System Administration: I’m just in the porter-* groups, so that I can fulfill installation requests in various chroots on Debian porterboxes; this means real DSA members can concentrate on more important things while still keeping the turnaround quick for developers who want to debug stuff on exotic architectures. Reminder for that procedure: Chroot Install Request Guidelines.

• After having maintained the kfreebsd-* buildds for a while, I’m still in the wanna-build team, meaning I can take care of give backs, one of the most common requests on debian-wb-team@. It’s been a while since it’s been split up from debian-release@, and instructions are still available in wanna-build.txt. Basically: anything buildd-related goes to $arch@buildd.debian.org or debian-wb-team@lists.debian.org, with the sole exception of binNMUs, which are handled by the release team.

• Speaking of which, I joined the release team a few months ago; plenty of (not-so-)funny things to do, like coordinating transitions to testing, and more recently, dealing with unblock requests during the freeze. While the Debian world is usually driven by the “just do” motto, there’s one area where one has to learn to say “no, sorry”. Hopefully people won’t hate us for that, and we’ll find alternative ways (like backporting specific fixes, or postponing new features until wheezy-backports is open).

• Given nobody on debian-boot@ stepped up to prepare new debian-installer releases, I figured I would give a hand there until somebody more involved with d-i would manage that on the long run. That’s a lot of heavy work, trying to get all involved packages into shape at a given moment, and getting people to fix their stuff when anything breaks. Hopefully that’ll work out and once CD images are ready, we should be able to run some more tests on those before officially publishing d-i beta 1.

• And since the CD team is also understaffed, I joined Steve McIntyre a while ago during a point release to see how that was done, and how I could help. Things drove me to the other teams above, so I couldn’t help much so far, but at least I managed to build a few test images on pettersson (the very nice machine on which images are built), using the debian-cd account. The intent was to make sure debian-installer could safely migrate from unstable to testing. That has happened lately, so images are being prepared.

• And of course I’m still maintaining the whole X stack, with the help of a few other guys on specific areas.

I don’t feel like getting hit by a bus, but I would hate burning out and going away from all this.

People have called repeatedly for help in core packaging team. And that has been true for the X Strike Force for a while (hint: Julien only managed to pull me into this because I ported the Graphical Installer from DirectFB to X11).

The same holds with non-packaging teams. I’m pretty sure Steve would love to see new members in debian-cd. I’m also pretty sure having more people involved in the d-i team would be very nice, especially if one could find out how to make the whole release process less insane than it is currently. I guess we could try out new ideas right after the release; it feels to me that right now is just not the time to fight the current release process.

Time for a DXN#11 follow-up.

1. The recent xserver-xorg-input-synaptics rc4 upload solved a lot of issues, but the 1.6.0 release (just uploaded) should fix some more. Enjoy!

2. I’ve also uploaded a new xorg-server, merging from upstream server-1.12-branch to get many XI2.2 bug fixes, along with an infinite loop bug fix (also seen with synaptics).

3. Many drivers can no longer work on ia64 due to the recent changes, so we requested they be removed, which happened promptly!

4. All XSF-maintained packages build happily against X server 1.12, meaning users can get back to running apt-get dist-upgrade blindly without having to fear the consequences. Pro tip: when you see something like xserver-xorg go away during a dist-upgrade, think twice before confirming!

5. xf86-input-mtrack was recently fixed; xf86-video-glamo and xf86-video-msm fail to build (#671028, #671806), so they stay uninstallable for now. Thankfully nothing appears to depend on them, so they can be temporarily removed from testing if needs be.

6. In the meanwhile, xserver-xorg-video-intel 2.19 was released. It will probably land into experimental first, until the new server and its drivers make it into testing.

7. Andreas Beckmann asked me to mention the status of the binary drivers, so here is my take about them: fglrx still doesn’t support X server 1.12 (LOL!). The other, big fat blobby driver is installable, and supposed to work.

Long time no see…

Summary

Anyway, here are some quick news from the X packaging front, focussing on the past few weeks.

1. While I was busy doing other things, Julien took care of uploading lots of libraries (making most of them multiarch-aware) along with our usual meta-packages (like x11-apps, x11-utils, etc.), preparing for the upcoming 7.7 katamari.

2. Mesa 8.0.2 was finally uploaded to experimental, where it seems to be building fine, and working fine, at least for me.

3. Accordingly, I’m planning an upload to unstable very soon, and I won’t be disabling wayland support this time, since wayland/weston reached their first milestone with a public release (0.85). There’s nothing very interesting to see here, but since wayland support doesn’t really hurt, I thought I’d just keep it. That’s why wayland hit unstable yesterday; weston should follow after mesa. (In case somebody is in a hurry, they have been in experimental for quite some time already.)

4. Scrolling issues with the synaptics driver seem to be finally fixed thanks to rc4: #665004 was confirmed as fixed by many reporters (thanks everyone for the quick feedback after my ping). Accordingly, I’ve pinged the release team to get an age-days 3 to make it migrate faster, and a kind RM added that hint to his file, so testing is getting the fixed package thanks to this midnight’s britney run.

5. libcairo2/server/EXA/ati/nouveau fun: will be added through an edition of this post. Executive summary: downgrade libcairo2 to testing’s version if you’re seeing text corruptions.

Upcoming X server transition

X server 1.12 has been prepared in experimental for a while, from release candidates to the first stable release from server-1.12-branch. Since a bunch of drivers were uploaded to cope with that version when it shows up, we should be able to upload xorg-server 1.12 to unstable VERY SOON.

What does that mean?

Basically, that’s a transition. In details:

1. We upload xorg-server, and wait for it to be built everywhere, then we trigger binNMUs for all architectures at once when it’s ready on all of them.

2. Unlike shared libraries, there’s no old and new library packages (old+new SONAME); instead, the server itself provides different packages (because of the different input and video ABI). That means that drivers won’t be installable until they are rebuilt against the new server. Usually, we’re talking about a few dinstall runs, meaning less than a day.

Frequently Yelled Phrases:

1. Upgrades are broken! No, it just means you can’t upgrade the server alone, you need the drivers too (see above).

2. Installations are broken! Well, that’s unstable, and you probably know installability-related issues are trivially solved by pulling packages from testing when needed. This is such a case.

Please don’t report bugs on this topic, thanks already, and enjoy that new server.

It’s this time of the year again: a new X release approaches. The upstream schedule has been delayed a tiny bit so that the multitouch changes could land in master during this merge window. Which is what happened, a few days before Christmas.

The other components involved in XI2.2 (aka. “multitouch”) were packaged in experimental while the server side was getting prepared:

• inputproto
• libXi

Given we reached the 1.12 RC1 stage, it’s a good idea to start building drivers against the new server to make it possible for users to perform some tests. And as usual, a new server means bumped input and video ABI, meaning a rebuild for the drivers to pick new dependencies. Some of them also needed a few fixes to make them build against the new server. Nothing that can’t be fixed with a few merges from upstream master branches.

The usual set of “major” drivers was uploaded to experimental:

• xserver-xorg-input-evdev
• xserver-xorg-input-keyboard
• xserver-xorg-input-mouse
• xserver-xorg-input-synaptics
• xserver-xorg-input-void
• xserver-xorg-video-ati
• xserver-xorg-video-dummy
• xserver-xorg-video-nouveau
• xserver-xorg-video-fbdev
• xserver-xorg-video-intel
• xserver-xorg-video-vesa

Significant change on the intel side: a snapshot of the current master branch was created, and packaged with SNA support enabled. SandyBridge's New Acceleration has apparently reached a point where it can be published to the masses, so here we go. Some details about it can be found in the initial commit.

Also, for those wondering about the xorg-server FTBFS on some architectures, fixes are pending.

Happy new year.

(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.

If you’re having issues with video playback in unstable on Intel hardware, this post is for you.

Some buffer freeing code was added in libdrm 2.4.28 to try and fix exhaustion of per-process limits. Some safeguards (assert()) were put in place to see whether some other components needed fixing (like unbalanced map()/unmap()). It’s hard to miss those, since the server crashes when something’s wrong. Good news: for affected users, downgrading to libdrm 2.4.27 (currently available in testing) should restore a functional setup.

So far, patches have floated around for libva[1], xserver-xorg-video-intel[1,2] and libdrm[1,2,3] itself. Since libdrm has already been exposed to a wide audience for a while, a new upstream release is planned in a few days, disabling those assert()s. Other packages will then have some extra time to get new releases with the appropriate patches.

this is not a robbery, only a regular X server branch switch, from 1.10 to 1.11. That means X drivers (for input and video) need to be rebuilt against the new server, which is happening through binNMUs. That also means the X stack from sid might be uninstallable for a few hours, but impatient people can still use the stack from wheezy in the meanwhile.

Please refrain from reporting uninstallability bugs. That’s expected, can’t be avoided, and only for a few hours (assuming no driver starts to Fail To Build From Source).

Many thanks to the following people, who joined the “let’s do a pre-upload crash test” effort:

• Marc Dequènes
• Jakub Wilk
• David Bremner

It took some time but it finally happened!

Rule of thumb: if you're happy with Squeeze’s X, stick to it. If you need a newer driver, for example for Intel Sandy Bridge, then give squeeze-backports a shot, and cross fingers!

As usual, x.debian.net contains the relevant documentation. Hopefully, the short squeeze-backports instructions will be sufficient. If you encounter some issues, feel free to contact debian-x@.

Things aren’t exactly going as smoothly as expected. Here are some explanations.

First collateral damage: non-free fglrx and nvidia drivers.

We have to admit we didn’t think of those when we moved libGL.so.1 (and friends) from /usr/lib to /usr/lib/<triplet> (that’s the move we call “adding multiarch support”). In the mesa 7.10.3-2 upload, some Breaks statements were added to prevent users from installing new mesa packages if they still have old (without multiarch support) fglrx or nvidia packages.

Solution: Sticking to the mesa packages in testing is the way to go until fixed fglrx and nvidia packages are uploaded.

Second collateral damage: xserver-xorg-core in testing.

The plan was to rebuild the server in unstable against the new mesa libraries, so that it would look into the new /usr/lib/<triplet> directory for mesa drivers. Since no source changes were needed, we went for a binNMU as explained in the previous blog post.

That’s the usual way to deal with libraries, and does the job very nicely. But that failed in this special case, for the following reasons:

1. The server only has libgl1-mesa-dri in Recommends, so there’s no hard dependency here.
2. Usually, rebuilding a package against a new library means getting a dependency on the new library (typically because the binary compatibility has been broken, so the SONAME got bumped, meaning one depends on libfoo42 instead of libfoo41). And that means going in testing at the same time as the new library.

But in this case, rebuilding against the new library just means having a different search path somewhere in libglx.so. So the rebuilt package (2:1.10.2-1+b1) happily reached testing, which still contains the old mesa packages, which ship their files in the old /usr/lib path!

Solution: Stick to 2:1.10.2-1 packages (snapshot.debian.org to the rescue), or wait a bit and get fixed packages.

To get fixed packages, two things were needed:

1. Getting the server package fixed in unstable: that means adding Breaks against old (pre-multiarch) mesa packages, as seen in 2:1.10.2-2. This will ensure that new server package built against new mesa will not be co-installable with old mesa packages, and both mesa and the server should migrate together to testing.
2. Getting the server built again within testing, so that it gets built against old mesa, so that both mesa and the server in testing remains without multiarch until the packages in unstable are ready to migrate together.

While taking care of that second step, it was discovered that many buildds are still lacking a testing chroot, so there might be some delay until the server is rebuilt in testing (as 2:1.10.2-1+wheezy1). Eager users can use the time travel machine mentioned above to get stuff working again sooner.

(As far as I can tell, the last problematic combination which would remain would be 2:1.10.2-1+wheezy1 server with new mesa, but we’ll make sure we update the Breaks in the new mesa to make sure that it can’t happen. Since it’s not as urgent as getting the server in testing fixed, it’s only queued for mesa 7.10.3-3 for now.)

Just a quick heads-up: I’ve just uploaded mesa 7.10.2-4, which is multiarch-enabled, thanks to Steve Langasek. As explained in its changelog, this breaks the X server currently in testing and in unstable, but a rebuild is already pending, which will make everyone upgradable.

For curious people, those commands took care of scheduling the binNMU, with a proper dep-wait:

wb nmu xorg-server . ALL . -m 'Rebuild against new (multiarch-enabled) mesa.'
wb dw xorg-server . ALL . -m 'libgl1-mesa-dev (>= 7.10.2-4)'

In the meanwhile, if your mirror gets a new mesa without the rebuilt server, your package manager should bail out and refuse to upgrade mesa (or propose to remove the server). So wait a bit, upgrade everything, and enjoy!

mesa 7.10.3 (released a few hours ago) should reach unstable tomorrow, so that we can ask our users to track (possible) regressions between 7.10.2-3 and 7.10.3-1 to either 7.10.2-4 (multiarchification), or to 7.10.3-1 (the stable upgrade), thanks to the excellent http://snapshot.debian.org/ service.