Ubuntu Wiki

For minutes of previous meetings, please see https://wiki.ubuntu.com/PlatformTeam/

Present

• ColinWatson

• AlexanderSack

• ArneGoetje

• BryceHarrington

• ChrisCheney

• EvanDandrea

• JamesWestby

• LarsWirzenius

• LukeYelavich

• OliverGrawert

• SteveLangasek

Apologies

• MatthiasKlose

Agenda

• Activity Reports
• Partner Archive Package Review
• 8.04.1 Status Report
• libx11/libxcb
• Xserver 1.5 Update

Outstanding actions from last meeting

None identified

Actions from this meeting

• Everyone to send future activity summaries on TUESDAY to Colin, not to distro-team@
• cjwatson to assign partner package reviews to volunteers
• bryce to follow up with the people who have reported problems after your wontfix status change, and make sure that we can deal with them
• bryce to let cr3 and heno know to test many different drivers after the pciaccess change goes through

Activity Reports

Firstly (and this one is only relevant for Canonical staff) the distro team managers have agreed that distro-team@ would become more useful if each team collected activity reports privately and then included them in its meeting summaries. There are some disadvantages, mostly that it means we can't follow up to individual activity reports as easily, but Colin feels it would make the list more bearable to follow.

Henceforth, Platform team members are to mail activity summaries at the end of their day on TUESDAY. Colin will collect them and do some trivial reformatting, and place them on a wiki page, where they can be referred to from the meeting agenda. A goal is for the public portions of the activity reports be easily posted to ubuntu-devel@.

There were various opinions on whether this would make the reports read more or less frequently, whether it makes it easier or harder to reply to status reports, whether people should be writing longer or shorter activity reports, and whether decreasing the traffic on the mailing list is good or bad. We will be trying this out for a while; if it causes serious problems, we can revert.

Partner Archive Package Review

It would be beneficial for packages in the partner archive (archive.canonical.com) to receive brief reviews from some experienced platform team members to ensure that they interoperate well with the rest of the distribution.

There are 38 packages to be reviewed; it's estimated to take about 15 minutes per source package. Some of the packages are large, but we needn't do very deep review of the upstream code (which may be unavailable in any case); it's mostly a matter of making sure they're packaged correctly, and to provide some mentoring for the people doing this work.

Luke, Lars, Steve, Alex, and Chris all volunteered to help with this.

• ACTION: cjwatson to assign partner package reviews to volunteers

8.04.1 Status Report

8.04.1 is coming on very well, for all the (typical) last-minute rush of fixes. We still have a couple of SRUs that are on the CDs right now by virtue of building out of -proposed which have still not made it through the SRU verification process, so those need to be sorted in short order.

One of them is bug #219587 in cairo ("03-turn_on_buggy-repeat_handling.dpatch causes slowdown in Evolution"); this is certainly the riskiest of the SRUs that we have left, but all things considered there's insufficient evidence of regressions to block it and force a reroll of all images. seb128 wishes to drop the patch, however we've had only a single, unreproducible and uninvestigatable report of a regression correlated to the cairo update, despite this update being in -proposed for 28 days with no other reports of issues. Slangasek asks that if anyone notices cairo behaving funny, to flag the issues for him ASAP, but otherwise he plans to just push it.

Other than that, the ISO testing has been going *very* well. More ISO testing may still be of help; please coordinate with #ubuntu-testing on this to find out where help is needed, so we don't have 5 people all independently downloading the same image for one test. There's a bunch of ISOs on the tracker that don't yet have complete coverage, and one or two without any coverage.

On a related note, we know we have a few high-priority SRUs to push out of the queue right on the heels of 8.04.1. slangasek will be be unfreezing -proposed shortly, but unfortunately won't have any time to process those SRUs himself for a bit.

libx11/libxcb

Bryce reported that the two xcb issues mentioned last week have been resolved with workarounds to 8.04.1. The two critical manifestations of xcb issues were xubuntu login lockups and OOo/amd64.

The OOo portion of the issue, calc confirms was due to a xrandr heap corruption issue and has been fixed in hardy-updates now.

The Xubuntu issue was found by Cody to be a race condition caused by gnome-screensaver trying to run dbus-launcher before dbus had been started; when the XFCE startup script then tried launching dbus, it caused deadlock in XCB. Shuffling the startup order of gnome-screensaver made the lockups stop occurring.

There may be other similar XCB-related issues in other applications (Java apps possibly), however since the two known issues are worked around, last week's proposed approach of disabling XCB in libX11 seems too risky and perhaps overkill. In particular, compiz now has a dependency on an XCB-enabled libX11, so doing this would require also making modifications to compiz to remove that dependency. An alternate suggestion had been made, to provide two libX11's, one with XCB disabled, and another just for compiz with XCB present; however, the xcb-enabled libX11.so.6 doesn't use symbol versions today, so trying to clear up symbol collisions between compiz and its libs would require a rebuild of the whole dep chain, /after/ the work to actually add symbol versions, and this whole plan would also need to be passed by upstream to verify that it's even possible to use both X11 libs from the same process (they might try to overrun each other's state via env vars or something). So that seems pretty infeasible to do for Hardy.

The Java issue is fairly well-known and fixed upstream, but you have to be running a pretty up-to-date JRE (we're not sure if it's fixed in OpenJDK 6). There is an environment variable workaround (some of these issues can be worked around with LIBXCB_DISABLE_SLOPPY_LOCK=1, but maybe not all), so we should remind folks of that.

ACTION: bryce to follow up with the people who have reported problems after your wontfix status change, and make sure that we can deal with them

Xserver 1.5 Update

Bryce reports that xserver 1.5 + new mesa + new libxrm + new xorg + rebuild of all drivers is coming within a week or so.

xserver 1.5 ended up being principly a bug fix release, due to scheduled features that got delayed til 1.6. Changes included in this release (according to Phoronix - http://www.phoronix.com/scan.php?page=news_item&px=NjU1Ng):

• libpciaccess is now required of all drivers
• CVE security fixes
• fixes so the X Server can build properly on the Alpha platform
• dropping the GLCore dependency (and move it to dynamic loading)
• memory leak fixes

Building X Server 1.4.99.904+ now requires building against Mesa 7.1 RC1 or later, which is what's been delaying this merge. Timo has taken the task of getting these pieces packaged and tested. We already know this breaks compiz on -intel and brings some other problems, which we'll be working on in the coming weeks. After the base merge is in, we'll also be switching on input-hotplug.

The major change will be switching to pciaccess, which *hopefully* should be an invisible change, but probably won't - the less actively maintained drivers are especially vulnerable with this change, so we should notify our QA and HW Cert teams of symptoms to test for.

Ogra asked if this will avoid situations like the -geode pci id shuffle. In fact it doesn't solve that, it just switches the procedure we use. The good news is we're going from a procedure specific to Debian, to one that upstream Xorg will be supporting.

Aside from the PCI ID changes that may affect less common video drivers, just watch out for the usual stuff... performance degradation, failure to start X, input device oddities, etc.

ACTION: bryce to let cr3 and heno know to test many different drivers after the pciaccess change goes through