State of X Server 1.9

The push of X Server 1.9 mentioned previously continued past weekend, with an upload of 1.9.1 rc2 this time, which is likely to become 1.9.1 in a few days. To keep it company in experimental, almost all X video drivers were uploaded as well, with a few exceptions:

• intel: We would like the current version in sid to migrate to squeeze now that a suitable kernel (≥ 2.6.32-24) is available there. Additional patches from experimental or from upstream might be added to sid then. For now, I kept 2.13 (built against X Server 1.7) in experimental, since I asked users a couple of times to try 2.13 from there.

• nouveau and openchrome: There were entirely new codebases in experimental for both of them, so I didn’t touch anything there.

• nv: We plan to drop it entirely in favor of nouveau.

If my package manager isn’t lying, the xserver-xorg-video-all meta package pulling everything could almost be installed, if one were to ignore those drivers.

The same goes for xserver-xorg-input-all: almost alright, except for xserver-xorg-input-wacom, which is maintained outside debian-x.

Autobuilding X packages

So we have mostly this situation: 1.7 in sid, 1.9 in experimental. But we may want to build experimental packages (new upstream releases, or packages with patches cherry-picked from upstream) against either of them, without interfering with what is in the archive. We could ask users to try some patches. Actually, we do that already, and while many of them are usually responsive and willing to do so, not everyone knows how to build a package, or has time to.

That’s why I spent some time setting up http://autobuild.mraw.org/, where I can push source packages in the autobuild-unstable or autobuild-experimental suites, so that they get built on amd64 and on i386. It supports multiple versions in a given suite, which may help narrowing down when a fix appeared.

That’s part of a let’s try to stick as closely as possible to upstream plan. We regularly get blamed for not doing so, but there are several reasons (or excuses? You decide.) for that:

• Spending time stabilizing stuff is the established standard in Debian, with that stuff called freeze. This means that rushing for the very last upstream releases isn’t usually a good idea.
• X is some kind of a beast. Many libraries, many drivers, and a server. That means plenty of time to spend. And we’re only a handful (and that includes Ubuntu folks who are helping us preparing stuff in git, thanks guys).

So if anyone thinks we’re willingly holding back any kind of move towards newer upstream releases or the like, rest assured that’s not the case. There’s just too few of us to closely track upstream (which we do by reporting bugs and trying to cherry-pick patches anyway) in addition to preparing stuff for the next stable release. Now that things are settling down, that sounds feasible somehow, but remember: your help is more than welcome.

Speaking of those Ubuntu guys, Robert Hooker is currently updating a bunch of drivers in experimental, yay.