[ubuntu-x] Ubuntu-x mini-meeting minutes

[Bryce Harrington]

Quick update on last month's X meeting:

On Wed, Jun 06, 2012 at 05:32:54PM -0700, Bryce Harrington wrote:
> We had a ubuntu-x team meeting today to coordinate tasks across several
> topics.  Below is a brief summary of the discussions.

The xserver 1.12 stack was uploaded last week following alpha-2
release.

UDS plans are to track the 1.12 release and move to 1.13 when we're
closer to release, but we'll keep our options open in case 1.13 looks
like it's going to be problematic.  So, we'll not worry too much about
stabilizing 1.12 in Ubuntu and instead send changes upstream so we can
get them via 1.13.


> == X stack for LTS point release ==
> 
> The repository is up with the renamed X stack, and it is successfully
> working as a proof-of-concept for the rename procedure.  Next step is to
> update it to the Q stack, but that's blocked on the Q stack landing in Q
> (which happens after alpha1).
> 
> There is a known issue that downgrading from the renamed stack won't
> work, but we're not going to be supporting downgrading so we're not
> planning to worry about that.  We do need to ensure it's documented
> upfront, so testers know what they're getting into.
> 
> No actions at this time.  mlankhorst owns the project in general and
> will follow up on work items subsequent to the stack merge in Q.

Now that we have a new stack in Quantal, mlankhorst says he'll be
turning the gears of the rename scripts to create a P stack as the next
step here.

> == Updating -nouveau snapshot ==
> 
> A new snapshot of the -nouveau DDX tree will be merged into quantal (and
> to LTS backports).  This new DDX has some fermi changes that will break
> acceleration for fermi for kernels < 3.4, so it is suitable only quantal
> and ppas with explicit dependency on the LTS backport kernel.
> 
> mlankhorst took the action of liaising with upstream first, then if all
> looks ok will coordinate getting this in for quantal (bryce, chris,
> timo, et al can sponsor.)

Done.  The snapshot was updated as planned.  In addition nouveau 1.0.1
was released!  So we've sync'd that in from Debian as version 1:1.0.1-1

> == Hybrid Graphics ==
> 
> mlankhorst has been working with airlied upstream on hybrid but it seems
> to still be a fair ways off (not looking likely for formally landing in
> Q), so he's going to shift focus back to LTS work, nouveau, etc. for the
> time being.  Hardware availability for testing remains an issue, so
> near-term tasks involve addressing that need.
> 
> 
> == SNA for Intel Graphics ==
> 
> SNA is the new 2D acceleration technology for the Intel graphics driver.
> It's been under development and testing upstream for quite some time,
> but is generally considered "ready for use" by upstream.  Debian has it
> enabled in experimental but not unstable at this time.
> 
> We enable SNA in our xorg-edgers PPA for preliminary testing.  After a
> week if it doesn't seem to have caused severe breakage, we'll go ahead
> and enable it, and then re-evaluate it some time prior to alpha-2,
> giving consideration to bug reports filed during this period.  Bryce
> will handle forwarding bug reports to Intel and working with them
> towards fixes.  At the re-evaluation point we will consider the level of
> stability and decide whether to return to UXA or move ahead with SNA.

We ended up not doing this for alpha-1, but have started the experiment
for alpha-2.  SNA is currently enabled in edgers, and we plan to switch
it on in -intel early next week.


> == Mesa 8.0.3 SRU ==
> 
> Mesa 8.0.3 is a bug-fix-only release.  We believe this new mesa may
> solve a number of hard-to-analyze GPU lockups and corruption problems
> that people are seeing, so we feel that 8.0.3 is vital to get out to
> the LTS users.
> 
> We will be upgrading to it in quantal after alpha-1, and we'd like to
> try SRU'ing the full package for precise.  This is as opposed to
> cherrypicking specific patches out of it, as we have done historically;
> the problem is that many fixes fix legitimate problems but it's quite
> hard to match those to user-reported bugs in launchpad.
> 
> To help temper regression fears, Bryce will do A/B piglit testing on a
> few video drivers to demonstrate lack of regression, Chris will write up
> a metabug with a detailed explanation of each change to help, and we'll
> seek out a non-X team SRU reviewer for an independent set of eyes.

A spate of piglit tests were done.  No regressions were found and some
tests now run and pass which don't pass with the current 8.0.2 stack.
I've uploaded 8.0.3 to quantal and no issues have arisen, so will be
proceeding with the SRU.

> == Mesa Binary Packages Cleanup ==
> 
> Proposed to drop 8-bit and 16-bit osmesa binary packages.  We don't
> think anyone actually needs these, and dropping them would speed up our
> builds.  We'd still build 23bit libosmesa.
> 
> Proposed to drop libgl1-mesa-swx11.  This conflicts with some of the
> other mesa binary packages, so if you blindly 'dpkg -i *.deb' on your
> freshly built mesa packages, breakage ensues.  Dropping this fixes that.
> The software acceleration that this package provides is horrible;
> generally we consider it a bug if this is installed.
> 
> We will test disabling all the above packages post-alpha-1, and then
> make a formal evaluation prior to alpha-2.  Even if we end up disabling
> them, we can always easily restore them even post-release.
> 
> The one concern is if dropping swx11 would make the LTS backport more
> challenging.  However, this will become obvious enough once we've made
> the change.  If it does and there's no way around it, we will re-enable
> it at that point.

Not sure on the status of this but believe it still to be done.

> == Various Proposed Patches ==
> 
> #993427 - Fixes -fglrx in quantal.  It broke with the new kernel.
> Bryce took the action on this.

Done.  Thanks tseliot

> #1002224 - Enable gallium vdpau.  We'll go ahead and do this post-alpha1
> and then re-evaluate it at alpha2.

Done.  The patch in question turned out to not be 100% complete, but
Debian is working on integrating it.  We'll wait until they're done and
pull it in at that point.

> #610206 - Compile-in the input drivers for boot speed as per Meego.  Not
> really sane to do for non-embedded use cases.  tjaalton took action to
> wontfix this.

Done

> CVE patches - Bryce took action to coordinate with security team on
> ownership of tasks for resolving these.

Still TBD