xorgKiBi’s bloghttp://mraw.org/blog/tags/xorg/KiBi’s blogikiwiki2013-12-17T02:11:29ZBus factorhttp://mraw.org/blog/2012/07/15/Bus_factor/2013-12-17T02:11:29Z2012-07-15T17:15:00Z
<p>Stuff/team I’m currently involved with:</p>
<ul>
<li><p>Debian System Administration: I’m just in the <code>porter-*</code> 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:
<a href="http://dsa.debian.org/doc/install-req/">Chroot Install Request Guidelines</a>.</p></li>
<li><p>After having maintained the <code>kfreebsd-*</code> 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 <code>debian-wb-team@</code>. It’s
been a while since it’s been split up from <code>debian-release@</code>, and
instructions are still available in
<a href="http://release.debian.org/wanna-build.txt">wanna-build.txt</a>.
Basically: anything buildd-related goes to
<code>$arch@buildd.debian.org</code> or <code>debian-wb-team@lists.debian.org</code>,
with the sole exception of binNMUs, which are handled by the
release team.</p></li>
<li><p>Speaking of which, I joined the release team a few months ago;
plenty of (not-so-)funny things to do, like coordinating
transitions to <code>testing</code>, 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 <code>wheezy-backports</code> is open).</p></li>
<li><p>Given nobody on <code>debian-boot@</code> stepped up to prepare new
<code>debian-installer</code> releases, I figured I would give a hand there
until somebody more involved with <code>d-i</code> would manage that on the
long run. That’s
<a href="https://lists.debian.org/20120610232949.GA1059@mraw.org">a</a>
<a href="https://lists.debian.org/20120624215418.GU6468@mraw.org">lot</a>
<a href="https://lists.debian.org/20120708160952.GM29142@mraw.org">of</a>
<a href="https://lists.debian.org/20120709231514.GA6071@mraw.org">heavy</a>
<a href="https://lists.debian.org/20120711200313.GC6631@mraw.org">work</a>,
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 <code>d-i beta 1</code>.</p></li>
<li><p>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 <code>pettersson</code> (the very nice machine on which images
are built), using the <code>debian-cd</code> account. The intent was to make
sure <code>debian-installer</code> could safely migrate from <code>unstable</code> to
<code>testing</code>. That has happened lately, so images are being prepared.</p></li>
<li><p>And of course I’m still maintaining the whole X stack, with the
help of a few other guys on specific areas.</p></li>
</ul>
<p>I don’t feel like
<a href="http://en.wikipedia.org/wiki/Bus_factor">getting hit by a bus</a>, but I
would hate burning out and going away from all this.</p>
<p>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 <a href="http://mraw.org/2010/01/31/Saving_private_GI/">from DirectFB to X11</a>).</p>
<p>The same holds with non-packaging teams. I’m pretty sure Steve would
love to see new members in <code>debian-cd</code>. I’m also pretty sure having
more people involved in the <code>d-i</code> 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.</p>
Debian XSF News #12http://mraw.org/blog/2012/05/07/DXN-12/2013-12-17T02:11:29Z2012-05-07T02:00:00Z
<p>Time for a <a href="http://mraw.org/2012/05/01/DXN-11/">DXN#11</a> follow-up.</p>
<ol>
<li><p>The recent <code>xserver-xorg-input-synaptics</code> <code>rc4</code> upload solved a lot
of issues, but the <code>1.6.0</code> release (just uploaded) should fix some
more. Enjoy!</p></li>
<li><p>I’ve also uploaded a new <code>xorg-server</code>, merging from upstream
<code>server-1.12-branch</code> to get many XI2.2 bug fixes, along with an
infinite loop bug fix (also seen with <code>synaptics</code>).</p></li>
<li><p>Many drivers can no longer work on <code>ia64</code> due to the recent changes,
so we requested <a href="http://bugs.debian.org/671386">they be removed</a>,
which happened promptly!</p></li>
<li><p>All XSF-maintained packages build happily against X server 1.12,
meaning users can get back to running <code>apt-get dist-upgrade</code>
blindly without having to
<a href="https://lists.debian.org/debian-user/2012/05/msg00112.html">fear the consequences</a>.
<strong>Pro tip:</strong> when you see something like <code>xserver-xorg</code> go away
during a <code>dist-upgrade</code>, think twice before confirming!</p></li>
<li><p><code>xf86-input-mtrack</code> was recently
<a href="http://bugs.debian.org/671027">fixed</a>; <code>xf86-video-glamo</code> and
<code>xf86-video-msm</code> fail to build
(<a href="http://bugs.debian.org/671028">#671028</a>,
<a href="http://bugs.debian.org/671806">#671806</a>), so they stay
uninstallable for now. Thankfully nothing appears to depend on
them, so they can be temporarily removed from <code>testing</code> if needs
be.</p></li>
<li><p>In the meanwhile,
<a href="http://lists.x.org/archives/xorg-announce/2012-May/001943.html">xserver-xorg-video-intel 2.19</a>
was released. It will probably land into <code>experimental</code> first,
until the new server and its drivers make it into <code>testing</code>.</p></li>
<li><p>Andreas Beckmann asked me to mention the status of the binary
drivers, so here is my take about them: <code>fglrx</code> still
<a href="http://bugs.debian.org/671320">doesn’t support X server 1.12 (LOL!)</a>. The
other, big fat blobby driver is installable, and supposed to work.</p></li>
</ol>
Debian XSF News #11http://mraw.org/blog/2012/05/01/DXN-11/2013-12-17T02:11:29Z2012-04-30T22:40:00Z
<p>Long time no see…</p>
<h3>Summary</h3>
<p>Anyway, here are some quick news from the X packaging front, focussing
on the past few weeks.</p>
<ol>
<li><p>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 <code>x11-apps</code>, <code>x11-utils</code>, etc.), preparing for
the upcoming 7.7 katamari.</p></li>
<li><p>Mesa 8.0.2 was finally uploaded to <code>experimental</code>, where it seems to
be building fine, and working fine, at least for me.</p></li>
<li><p>Accordingly, I’m planning an upload to <code>unstable</code> 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 <code>wayland</code>
hit <code>unstable</code> yesterday; <code>weston</code> should follow after <code>mesa</code>. (In
case somebody is in a hurry, they have been in <code>experimental</code> for
quite some time already.)</p></li>
<li><p>Scrolling issues with the <code>synaptics</code> driver seem to be finally fixed
thanks to <code>rc4</code>: <a href="http://bugs.debian.org/665004">#665004</a> was
confirmed as fixed by many reporters (thanks everyone for the quick feedback
after <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665004#144">my ping</a>).
Accordingly, I’ve pinged the release team to get an <code>age-days 3</code> to
make it migrate faster, and a kind RM added that hint to his file, so
<code>testing</code> is getting the fixed package thanks to this midnight’s
<code>britney</code> run.</p></li>
<li><p><em>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.</em></p></li>
</ol>
<h3>Upcoming X server transition</h3>
<p>X server 1.12 has been prepared in <code>experimental</code> for a while, from
release candidates to the first stable release from
<code>server-1.12-branch</code>. Since a bunch of drivers were uploaded to cope
with that version when it shows up, we should be able to upload
<code>xorg-server</code> 1.12 to <code>unstable</code> <strong>VERY SOON</strong>.</p>
<h4>What does that mean?</h4>
<p>Basically, that’s a transition. In details:</p>
<ol>
<li><p>We upload <code>xorg-server</code>, 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.</p></li>
<li><p>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 <code>input</code> and <code>video</code> ABI). That
means that drivers won’t be installable until they are rebuilt
against the new server. Usually, we’re talking about a few
<code>dinstall</code> runs, meaning less than a day.</p></li>
</ol>
<h4>Frequently Yelled Phrases:</h4>
<ol>
<li><p><em>Upgrades are broken!</em> No, it just means you can’t upgrade the
server alone, you need the drivers too (see above).</p></li>
<li><p><em>Installations are broken!</em> Well, that’s <code>unstable</code>, and you
probably know installability-related issues are trivially solved
by pulling packages from <code>testing</code> when needed. This is such a
case.</p></li>
</ol>
<p>Please don’t report bugs on this topic, thanks already, and enjoy that
new server.</p>
X server 1.12 RC1http://mraw.org/blog/2012/01/01/XServer_1.12RC1/2013-12-17T02:11:29Z2012-01-01T08:20:00Z
<p>It’s this time of the year again: a new X release approaches. The
upstream schedule has been
<a href="http://thread.gmane.org/gmane.comp.freedesktop.xorg.announce/1488/focus=1491">delayed a tiny bit</a>
so that the multitouch changes could land in <code>master</code> during this
merge window. Which is
<a href="http://thread.gmane.org/gmane.comp.freedesktop.xorg.devel/27517/focus=27557">what happened</a>,
a few days before Christmas.</p>
<p>The other components involved in <code>XI2.2</code> (aka. “multitouch”) were
packaged in <code>experimental</code> while the server side was getting prepared:</p>
<ul>
<li><a href="http://lists.x.org/archives/xorg-announce/2011-December/001777.html">inputproto</a></li>
<li><a href="http://lists.x.org/archives/xorg-announce/2011-December/001778.html">libXi</a></li>
</ul>
<p>Given we reached the
<a href="http://lists.x.org/archives/xorg-announce/2011-December/001782.html">1.12 RC1</a>
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 <code>master</code> branches.</p>
<p>The usual set of “major” drivers was uploaded to <code>experimental</code>:</p>
<ul>
<li><code>xserver-xorg-input-evdev</code></li>
<li><code>xserver-xorg-input-keyboard</code></li>
<li><code>xserver-xorg-input-mouse</code></li>
<li><code>xserver-xorg-input-synaptics</code></li>
<li><code>xserver-xorg-input-void</code></li>
<li><code>xserver-xorg-video-ati</code></li>
<li><code>xserver-xorg-video-dummy</code></li>
<li><code>xserver-xorg-video-nouveau</code></li>
<li><code>xserver-xorg-video-fbdev</code></li>
<li><code>xserver-xorg-video-intel</code></li>
<li><code>xserver-xorg-video-vesa</code></li>
</ul>
<p>Significant change on the intel side: a snapshot of the current
<code>master</code> branch was created, and packaged
<a href="http://packages.qa.debian.org/x/xserver-xorg-video-intel/news/20120101T060310Z.html">with SNA support enabled</a>. <em>SandyBridge's
New Acceleration</em> 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
<a href="http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=bcef98af561939aa48d9236b2dfa2c5626adf4cb">initial commit</a>.</p>
<p>Also, for those wondering about the <code>xorg-server</code> <code>FTBFS</code> on some
architectures,
<a href="http://lists.x.org/archives/xorg-devel/2011-December/028170.html">fixes are pending</a>.</p>
<p>Happy new year.</p>
Fixing synaptics on powerpchttp://mraw.org/blog/2011/12/12/Fixing_synaptics_on_powerpc/2013-12-17T02:11:29Z2011-12-12T02:35:00Z
<p><em>(It’s a new day, it’s a new bug…)</em></p>
<p>A regression appeared in the <code>synaptics</code> input driver, between the
1.4.1 and the 1.5.0 release, as reported in Debian
<a href="http://bugs.debian.org/649002">#649002</a> by many users. Basically, no
more touchpad on PowerPC (hi, iBook G4 users!). <code>:-(</code></p>
<p>What follows is how I tracked it down. The upstream bug report is
<a href="https://bugs.freedesktop.org/43728">fdo#43728</a>. Anyone could have
done so, there’s no black magic involved. A little hint maybe: <code>git bisect</code>
is really easy on X drivers, since one can build and test
without the Debian packaging bits.</p>
<p><strong>1st step: Getting started</strong></p>
<p>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.</p>
<pre><code># 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
</code></pre>
<p><strong>2nd step: Reproducing</strong></p>
<p>It was said 1.5.0 was the first known buggy version, so let’s make
sure:</p>
<pre><code># 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
</code></pre>
<p>Now time to restart the display manager, and confirm that the pointer
is not moving → bug reproduced.</p>
<p>Now let’s check the 1.4.1 release isn’t affected:</p>
<pre><code># Clean everything:
git clean -xdf
git checkout xf86-input-synaptics-1.4.1
autoreconf -vfi
./configure --prefix=/usr
make && sudo make install
</code></pre>
<p>And after a display manager restart, the pointer is moving again,
good! For reference, the log has very different lines about
<code>appletouch</code>, so it can be used to programmatically learn about the
status (good or bad).</p>
<p><strong>3rd step: Narrowing it down</strong></p>
<p>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!</p>
<pre><code>git bisect start
git bisect good xf86-input-synaptics-1.4.1
git bisect bad xf86-input-synaptics-1.5.0
</code></pre>
<p>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:</p>
<pre><code>Bisecting: a merge base must be tested
[de0dfb76444ad4160468d00515876c91a9fa20bf] synaptics 1.4.0
</code></pre>
<p>It’s just a matter of running <code>autoreconf … && ./configure … && make && sudo make install && sudo /etc/init.d/xdm restart</code>
every step of the way, so it’s pretty easy.</p>
<p>No wonder, 1.4.0 was working OK, so it can be recorded as such through
<code>git bisect good</code>, and the binary search goes between that commit and
1.5.0. After a few iterations of <code>git bisect good</code> and <code>git bisect bad</code>,
we get to the commit reported on the upstream bug.</p>
<p>As an extra bonus, mentioning the upstream bug number/URL in the
Debian bug means it can be marked as <code>forwarded</code> there and we’ll
receive automatic notifications when its status changes, thanks to
<a href="http://bts-link.alioth.debian.org/">bts-link</a>.</p>
<p>Now, if you want to provide a patch for this bug, you may want to try
and revert this commit.</p>
<p><strong>4th step: Providing a patch</strong></p>
<p>Let’s go back to the affected release and try to revert the guilty
commit:</p>
<pre><code>git checkout xf86-input-synaptics-1.5.0
git revert 13543b156d78bc4d01a19844a5ee8f283269621b
</code></pre>
<p>Unfortunately, some later commits modified the affected areas so we’re
running into conflicts:</p>
<pre><code>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'
</code></pre>
<p>Let’s try to understand what the
<a href="http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=13543b156d78bc4d01a19844a5ee8f283269621b">offending commit</a>
did: it replaced a set of macros with a single one, taken from the
server. Both the old <code>TEST_BIT()</code> and the new <code>BitIsOn()</code> take 2
arguments, but the order is reversed. Reverting it should only be a
matter of introducing the <code>TEST_BIT()</code> macro again (along with the two
other ones it needs), and using it.</p>
<p>The problem is replacing all <code>BitIsOn(foo,bar)</code> with
<code>TEST_BIT(bar,foo)</code>: <code>foo</code> and <code>bar</code> might not be trivial, they could
be complex C expressions, and a replacement in your favourite editor
might not get all occurrences right.</p>
<p>Thankfully, there’s a nice tool to handle such things, called
<a href="http://coccinelle.lip6.fr/">coccinelle</a>. I won’t go into details,
just show how it can help here. Basically you just need to craft a
tiny patch, called a <em>semantic</em> patch, which describes what I wrote in
the previous paragraph. You only need to declare two expressions, say
<code>a</code> and <code>b</code>, and declare that all <code>BitIsOn(a,b)</code> must be replaced with
<code>TEST_BIT(b,a)</code>. Here’s the syntax:</p>
<pre><code>@@
expression a,b;
@@
-BitIsOn(a,b)
+TEST_BIT(b,a)
</code></pre>
<p>Save it under <code>testbit.cocci</code> and apply it through <code>spatch</code> (from the
<code>coccinelle</code> package), asking it to perform in-place replacement
(we’re in a git checkout copy, remember):</p>
<pre><code># Apply:
spatch -sp_file testbit.cocci -in_place .
# Profit:
git diff
</code></pre>
<p>Then you can run <code>git commit -s</code>, write a nice commit message, send it
upstream, and enjoy the rest of the night.</p>
<p>Coming soon to a mirror near you:
<a href="http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=b7e65f04f5f0c17ac8a26393134cc7e8418ccdec">fixing commit</a>.
As mentioned on the upstream bug report, I got the Debian reference
wrong in the commit message, I really meant
<a href="http://bugs.debian.org/649002">#649002</a>.</p>
Fixing libdrm for intelhttp://mraw.org/blog/2011/12/11/Fixing_libdrm_for_intel/2013-12-17T02:11:29Z2011-12-11T02:40:00Z
<p>If you’re having
<a href="http://bugs.debian.org/651316">issues with video playback</a> in
<code>unstable</code> on Intel hardware, this post is for you.</p>
<p>Some
<a href="http://cgit.freedesktop.org/mesa/drm/commit/?id=c549a777c1b6227a724942c64aa5cd181eb93c6c">buffer freeing code</a>
was added in <code>libdrm</code> 2.4.28 to try and fix exhaustion of per-process
limits. Some safeguards (<code>assert()</code>) were put in place to see whether
some other components needed fixing (like unbalanced
<code>map()</code>/<code>unmap()</code>). 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 <code>testing</code>) should restore a
functional setup.</p>
<p>So far, patches have floated around for
<code>libva</code>[<a href="https://bugs.freedesktop.org/show_bug.cgi?id=43554#c3">1</a>],
<code>xserver-xorg-video-intel</code>[<a href="http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=699888a6410b0699c69a7f8a8d82dc4fde6fcc7f">1</a>,<a href="http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=eb859f644633ee716083d253a5b7ff95163380e5">2</a>]
and <code>libdrm</code>[<a href="http://cgit.freedesktop.org/mesa/drm/commit/?id=5c5332bbc38ff25c06081ac53a15ad583ad4cbc4">1</a>,<a href="http://cgit.freedesktop.org/mesa/drm/commit/?id=e4b60f29609e9993dc7268993da509530862aa78">2</a>,<a href="http://cgit.freedesktop.org/mesa/drm/commit/?id=dd9a5b4f7fb07c78db4e7481bedca1b981030e3f">3</a>]
itself. Since <code>libdrm</code> has already been exposed to a wide audience for
a while, a new upstream release is planned in a few days, disabling
those <code>assert()</code>s. Other packages will then have some extra time to
get new releases with the appropriate patches.</p>
Everybody be cool…http://mraw.org/blog/2011/08/28/Everybody_be_cool/2013-12-17T02:11:29Z2011-08-28T10:50:00Z
<p>this is not a robbery, only a regular X server branch switch, from
<code>1.10</code> to <code>1.11</code>. 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 <code>sid</code> might be uninstallable
for a few hours, but impatient people can still use the stack from
<code>wheezy</code> in the meanwhile.</p>
<p>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).</p>
<p>Many thanks to the following people, who joined the “let’s do a
pre-upload crash test” effort:</p>
<ul>
<li>Marc Dequènes</li>
<li>Jakub Wilk</li>
<li>David Bremner</li>
</ul>
Squeeze backports for Xorghttp://mraw.org/blog/2011/08/20/Squeeze-backports/2013-12-17T02:11:29Z2011-08-19T22:00:00Z
<p>It took some time but it finally happened!</p>
<p><img src="http://mraw.org/blog/2011/08/20/backports-new-queue.png" width="697" height="237" alt="NEW queue for backports" class="img" /></p>
<p><strong>Rule of thumb:</strong> 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 <code>squeeze-backports</code>
a shot, and cross fingers!</p>
<p>As usual, <a href="http://x.debian.net/">x.debian.net</a> contains the relevant
documentation. Hopefully, the short
<a href="http://x.debian.net/reference/squeeze-backports.html"><code>squeeze-backports</code> instructions</a>
will be sufficient. If you encounter some issues, feel free to contact
<code>debian-x@</code>.</p>
mesa: a disturbance in the Force!http://mraw.org/blog/2011/06/18/mesa_a_disturbance_in_the_Force/2013-12-17T02:11:29Z2011-06-17T22:05:00Z
<p>Things aren’t exactly going as
<a href="http://mraw.org/2011/06/14/mesa_a_disturbance_in_the_Force/">smoothly as expected</a>. Here
are some explanations.</p>
<p><strong>First collateral damage:</strong> <strong>non-free</strong> fglrx and nvidia drivers.</p>
<p>We have to admit we didn’t think of those when we moved <code>libGL.so.1</code>
(and friends) from <code>/usr/lib</code> to <code>/usr/lib/<triplet></code> (that’s the move
we call “adding multiarch support”). In the
<a href="http://packages.qa.debian.org/m/mesa/news/20110617T135141Z.html">mesa 7.10.3-2 upload</a>,
some <code>Breaks</code> statements were added to prevent users from installing
new mesa packages if they still have old (without multiarch support)
fglrx or nvidia packages.</p>
<p><strong>Solution:</strong> Sticking to the mesa packages in <code>testing</code> is the way to
go until fixed fglrx and nvidia packages are uploaded.</p>
<p><strong>Second collateral damage:</strong> <code>xserver-xorg-core</code> in <code>testing</code>.</p>
<p>The plan was to rebuild the server in <code>unstable</code> against the new
<code>mesa</code> libraries, so that it would look into the new
<code>/usr/lib/<triplet></code> directory for mesa drivers. Since no source
changes were needed, we went for a binNMU as explained in the
<a href="http://mraw.org/2011/06/14/mesa_a_disturbance_in_the_Force/">previous blog post</a>.</p>
<p>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:</p>
<ol>
<li>The server only has <code>libgl1-mesa-dri</code> in <code>Recommends</code>, so there’s
no hard dependency here.</li>
<li>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 <code>libfoo42</code> instead of <code>libfoo41</code>). And that means
going in <code>testing</code> at the same time as the new library.</li>
</ol>
<p>But in this case, rebuilding against the new library just means having
a different search path somewhere in <code>libglx.so</code>. So the rebuilt
package (2:1.10.2-1+b1) happily reached <code>testing</code>, which still
contains the old mesa packages, which ship their files in the old
<code>/usr/lib</code> path!</p>
<p><strong>Solution:</strong> Stick to 2:1.10.2-1 packages
(<a href="http://snapshot.debian.org/package/xorg-server/2:1.10.2-1/">snapshot.debian.org to the rescue</a>), or wait a bit and get fixed packages.</p>
<p>To get fixed packages, two things were needed:</p>
<ol>
<li>Getting the server package fixed in <code>unstable</code>: that means adding
<code>Breaks</code> against old (pre-multiarch) mesa packages, as seen in
<a href="http://packages.qa.debian.org/x/xorg-server/news/20110617T164806Z.html">2:1.10.2-2</a>. 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 <code>testing</code>.</li>
<li>Getting the server built again <em>within testing</em>, so that it gets
built against old mesa, so that both mesa and the server in
<code>testing</code> remains without multiarch until the packages in
<code>unstable</code> are ready to migrate together.</li>
</ol>
<p>While taking care of that second step, it was discovered that many
buildds are still lacking a <code>testing</code> 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.</p>
<p>(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 <code>testing</code>
fixed, it’s only
<a href="http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=commitdiff;h=0136b9db4736bcc9dc7e6bce92d8cd421e625f0e">queued for mesa 7.10.3-3</a>
for now.)</p>
mesa: a disturbance in the Force?http://mraw.org/blog/2011/06/14/mesa_a_disturbance_in_the_Force/2013-12-17T02:11:29Z2011-06-14T12:55:00Z
<p>Just a quick heads-up: I’ve
<a href="http://packages.qa.debian.org/m/mesa/news/20110614T114829Z.html">just uploaded mesa 7.10.2-4</a>,
which is multiarch-enabled, thanks to
<a href="http://web.dodds.net/~vorlon/wiki/blog/Multiarch_Monomania/">Steve Langasek</a>. As
explained in its changelog, this breaks the X server currently in
<code>testing</code> and in <code>unstable</code>, but a rebuild is already pending, which
will make everyone upgradable.</p>
<p>For curious people, those commands took care of scheduling the binNMU,
with a proper dep-wait:</p>
<pre><code>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)'
</code></pre>
<p>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!</p>
<p>mesa 7.10.3 (released a few hours ago) should reach <code>unstable</code>
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
<a href="http://snapshot.debian.org/">http://snapshot.debian.org/</a> service.</p>