Alternative view: by date.
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
firstname.lastname@example.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
Given nobody on
debian-boot@stepped up to prepare new
debian-installerreleases, I figured I would give a hand there until somebody more involved with
d-iwould 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-cdaccount. The intent was to make sure
debian-installercould safely migrate from
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.
rc4upload solved a lot of issues, but the
1.6.0release (just uploaded) should fix some more. Enjoy!
I’ve also uploaded a new
xorg-server, merging from upstream
server-1.12-branchto get many XI2.2 bug fixes, along with an infinite loop bug fix (also seen with
Many drivers can no longer work on
ia64due to the recent changes, so we requested they be removed, which happened promptly!
All XSF-maintained packages build happily against X server 1.12, meaning users can get back to running
apt-get dist-upgradeblindly without having to fear the consequences. Pro tip: when you see something like
xserver-xorggo away during a
dist-upgrade, think twice before confirming!
xf86-input-mtrackwas recently fixed;
xf86-video-msmfail to build (#671028, #671806), so they stay uninstallable for now. Thankfully nothing appears to depend on them, so they can be temporarily removed from
testingif needs be.
In the meanwhile, xserver-xorg-video-intel 2.19 was released. It will probably land into
experimentalfirst, until the new server and its drivers make it into
Andreas Beckmann asked me to mention the status of the binary drivers, so here is my take about them:
fglrxstill doesn’t support X server 1.12 (LOL!). The other, big fat blobby driver is installable, and supposed to work.
Long time no see…
Anyway, here are some quick news from the X packaging front, focussing on the past few weeks.
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-utils, etc.), preparing for the upcoming 7.7 katamari.
Mesa 8.0.2 was finally uploaded to
experimental, where it seems to be building fine, and working fine, at least for me.
Accordingly, I’m planning an upload to
unstablevery 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
westonshould follow after
mesa. (In case somebody is in a hurry, they have been in
experimentalfor quite some time already.)
Scrolling issues with the
synapticsdriver 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 3to make it migrate faster, and a kind RM added that hint to his file, so
testingis getting the fixed package thanks to this midnight’s
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:
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.
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
videoABI). That means that drivers won’t be installable until they are rebuilt against the new server. Usually, we’re talking about a few
dinstallruns, meaning less than a day.
Frequently Yelled Phrases:
Upgrades are broken! No, it just means you can’t upgrade the server alone, you need the drivers too (see above).
Installations are broken! Well, that’s
unstable, and you probably know installability-related issues are trivially solved by pulling packages from
testingwhen 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
a few days before Christmas.
The other components involved in
XI2.2 (aka. “multitouch”) were
experimental while the server side was getting prepared:
Given we reached the
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
The usual set of “major” drivers was uploaded to
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
Also, for those wondering about the
FTBFS on some
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:
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
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
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
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
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.
If you’re having
issues with video playback in
unstable on Intel hardware, this post is for you.
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
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
So far, patches have floated around for
libdrm has already been exposed to a wide audience for
a while, a new upstream release is planned in a few days, disabling
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.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
a shot, and cross fingers!
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
(and friends) from
/usr/lib/<triplet> (that’s the move
we call “adding multiarch support”). In the
mesa 7.10.3-2 upload,
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:
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:
- The server only has
Recommends, so there’s no hard dependency here.
- 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
libfoo41). And that means going in
testingat 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
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:
- Getting the server package fixed in
unstable: that means adding
Breaksagainst 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
- Getting the server built again within testing, so that it gets
built against old mesa, so that both mesa and the server in
testingremains without multiarch until the packages in
unstableare 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
fixed, it’s only
queued for mesa 7.10.3-3
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
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