Meeting Minutes

IRC Log of the meeting.

Agenda

2010-6-1 Meeting Agenda

Maverick Release Metrics

Bugs

	Alpha 1 Milestoned Bugs (0)	Release Targeted Bugs (40 accross all packages)
linux	0	5

Blueprints

• 14 Blueprints (includes HWE blueprints)

Bugs with Patches Attached: 130 (down 2 from last week)

• Launchpad Report
• Breakdown by status

Blueprint: kernel-maverick-apparmor (jjohansen)

Nothing new this week.

Blueprint: kernel-maverick-firewire-stack (manjo)

Nothing new this week.

Blueprint: kernel-maverick-misc (apw)

There are two outstanding items for Alpha-1, getting mainline builds to include linux-tools and progressing the -preempt pakcages. These are both non-release tasks. The first is likely to slip to alpha-2 now, the second is progresing but also likely to slip.

Blueprint: kernel-maverick-new-kernel-on-lts (tgardner)

LTS backport kernel and meta package are in the kernel-ppa. Its tracking maverick as its released.

Blueprint: kernel-maverick-pv-ops-ec2-kernel (jjohansen)

Slow progress, more testing without success. Will have to try pv-ops on HVM drivers this week.

Blueprint: kernel-maverick-tracing-support (cnd)

Kernel config is set, confirmed with upstream. No new work other than that yet.

Blueprint: kernel-maverick-ubuntu-delta-review (ogasawara)

There are only two work items still open for Alpha-1, both of which are not critical for Alpha-1’s release.

apw, manjo: if you don’t think you’ll get to those before Thurs, I’ll move them under the Alpha-2 milestone.

Blueprint: kernel-maverick-union-mounts (apw)

Still no testing feedback from foundations on union-mounts, there is talk of another drop occuring from upstream which will simplify the patches. It is unclear when this new drop will occur however.

We also have an issue with aufs2 in maverick which is leading to aufs2 panics during boot on the live-cd. I have an update for aufs2 which I am attempting to test to see if that fixes the issues. It is likely we will have to update aufs2 as soon as we are on 2.6.35-rcN. The update does appear to be good, and we are being asked to respin with aufs2 updated. Will get patches out shortly.

Blueprint: kernel-maverick-bug-handling (jfo)

Continuing work on the wiki pages with input from apw, ogasawara and smb. I plan to send some e-mail out on the ongoing effort today.

Also, I have some prep work happening that will move several topics to INPROGRESS.

Blueprint: kernel-maverick-upstart (apw)

We have patches pending for the remaining Alpha-1 deliverable, waiting on testing from Foundations. These would most readily be applied post Alpha-1.

Blueprint: kernel-maverick-reducing-dkms-packages-required-for-hardware-enablement (cking)

Nothing new this week

Blueprint: kernel-maverick-bios-test-automation (cking)

 
 *  Added functionality:
    *   Test for common BIOS error messages
    *   APIC edge/level trigger test
    *   acpiinfo: common kernel log ACPI checks
    *   Common S3/S4 PM kernel error checks
    *   S3 multiple suspend/resume cycle tests
    *   S4 hibernate/resume test
    *   Add in test run order/priority
    *   Rework kernel log scanning + execution of some user space tools
    *   Rework wakealarm code into common library calls
    *   Add ability to take pre-captured input from dmidecode, /proc/acpi/dsdt and dmesg 
rather than at run time
    *   Manoj added a test from the test suite into kernel-qa dev to prove the test suite 
integrates in okay.

Status: Maverick (ogasawara)

We uploaded the 2.6.34-5.12 Alpha 1 kernel last Friday. There will be no further uploads until after Thurs. Unfortunately the first iso’s were just spun yesterday and have uncovered 2 bugs we need to be aware of (thanks apw and tgardner for already taking ownership):

• Launchpad bug 587888 in linux (Ubuntu Maverick) “aufs oops in au_do_open() on maverick live system boot” [Critical,Triaged]
• Launchpad bug 587893 in linux (Ubuntu Maverick) “linux-image-2.6.34-5-virtual is oversized, results in oversized server ISO” [High,In progress]

I should take that back, we might upload for the aufs bits. Also note that 2.6.35-rc1 was released so I’ll be rebasing Maverick today.

Security & bugfix kernels – Karmic/Jaunty/Intrepid/Hardy/Others (gnarl/smb)

 
 * Dapper:      2.6.15-55.83  (updates)
 * Hardy:       2.6.24-27.69  (updates)
 * Intrepid:    --- End of Support ---
 * Jaunty:      2.6.28-18.60  (updates)
 * Karmic:      2.6.31-21.59  (updates)
    - mvl-dove  2.6.31-213.27 (updates)
    - fsl-imx51 2.6.31-111.27 (updates)
    - ec2       2.6.31-306.14 (updates)
 * Lucid:       2.6.32-22.33  (updates)
    - mvl-dove  2.6.32-204.16 (release)
    - fsl-imx51 2.6.31-607.13 (release)
    - ti-omap   2.6.33-500.6  (release)
    - qcm-msm   2.6.31-800.2  (release)
    - ec2       2.6.32-305.9  (release)

Status unchanged from last week. Security release nearly out (probably tomorrow).

Incoming Bugs and Regression Stats

Incoming Bugs:

Version	Count
Maverick	5 (+1)
Lucid	1005 (-129)

Current regression stats:

Version	Potential	Update	Release	Proposed
maverick	5 (+2)
lucid	262 (-40;)	26 (+1)	146 (-3)	1
karmic		9	50	1
jaunty		5	20
hardy		1 (-1)	3

Incoming Bugs: Bug day report (JFo)

This week’s Bug Day will be on Thursday. I plan to send out an announcement for it later today with a reminder going out tomorrow. The current plan is to review Bugs with Patches attached to eliminate misreported patches and prepare the list for team review. Additionally, i will resume our use of the ‘cherry-pick’ tag to identify bugs with upstream commit SHA1s in them for us to review and react accordingly. You can see the list of these from this url

Open Discussion or Questions: Anyone have anything? (raise your hand please)

jfo	Just wanted to draw your attention here
bjf	Pointing to here
apw	Remember we discussed the b43 driver not working, i’ve confirmed that it does not work in the current release kernel in lucid due to dma errors, etc.
	With smb’s latest stable 32.13 the b43 does work pretty well, and i am using it now
tgardner	Is compat-wireless any better?
apw	Can’t say i’ve tried it no

[Discuss Kernel Team Meeting Minutes – June 1st, 2010 on the Forums]

Originally posted to the Canonical Voices -Kernel Team Blog by Brad Figg on Wed, June 2nd, 2010

Background

Firefox 3.0 and xulrunner 1.9 are now unsupported by Mozilla. Rather than backporting security fixes to these now, we are moving to a support model where we will be introducing major new upstream versions in stable releases. The reason for this is the support periods from Mozilla are gradually becoming shorter, and it will be more and more difficult for us to maintain our current support model in the future.

What we are going to do

We are going to release Firefox 3.6.4 as a minor update to the 3.6 series in Lucid. This will also be rolled out to Hardy, Jaunty and Karmic (along with xulrunner 1.9.2.4). The update for Lucid is quite trivial, but the update in Hardy, Jaunty and Karmic is not quite as simple.

Before releasing these updates to the public, we need testing in Firefox, the extensions in the archive and distributions upgrades after those updates. We have published all these packages in a PPA and we will track test results before moving anything to the archive.

How you can help

We need people running *Hardy* (Jaunty and Karmic will see a similar call for testing in the following days) in bare metal or a virtual machine. If you are willing to help, you can follow the instructions below:

1. Add the Mozilla Security PPA to your software sources

   You need to manually edit your /etc/apt/sources.list and add the following lines:

   deb http://ppa.launchpad.net/ubuntu-mozilla-security/ppa/ubuntu hardy main

   deb-src http://ppa.launchpad.net/ubuntu-mozilla-security/ppa/ubuntu hardy main

   After saving the file, you have to run:

   sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 7EBC211F

   sudo apt-get update

   sudo apt-get dist-upgrade

2. You have to have an account in our tracking system. Go to http://mozilla.qa.ubuntu.com and click on “Log In” and “Create New Account”
3. Explore your Firefox installation

   Basically we want people to perform the same activities that the do daily, without issues. In order to make testing easier, this is a checklist of things worth looking:

   • The upgrade to Firefox 3.6.4 goes smoothly.
   • The extensions get upgraded as well.
   • All the Firefox plugins (i.e. Flash, Java) still work.
   • The extensions work correctly.
   • Full distributions upgrades are not broken.
   • Upgrades work with only the security pocket enabled (ie, hardy-updates disabled)

To report your findings you need to use the test tracker.

Once you have selected the Hardy image, you will see a set of “testcases”, with a summary of how many reports have been sent. Obviously, the most important one is “Firefox”.

Once you open one of the testcases, you will be able to report back your findings if something went wrong. Even if everything went fine, it is always good to report back the success (“Passed”) with a comment on the activities you performed.

Use the “Firefox” testcase for general testing (upgrade, rendering, plugins, etc.) and the rest of the testcases if you want to report something more specific (Upgrades to Lucid, specific extensions errors, etc.)

IMPORTANT!! How to file bugs

As we are testing a PPA, not an official Ubuntu package, if you find an issue is NOT OK to file a bug in Launchpad. Rather than doing so, please, just explain your issue in the Comments field of the tracker and mark the test as Failed.

The tracker requires a bug number in order to mark a test as Failed. To bypass this requirement, just use the bug number “1″

Thanks for helping to maintain secured Ubuntu stable releases!

[Discuss Call for Testing: Hardy Firefox Users (or willing to install Hardy in a VM) on the Forums]

Originally posted here by Ara Pulido on Tue, June 1, 2010

The desktop team has been working since the Karmic UDS on the following blueprint: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model

The upshot of the blueprint is that there will be some changes to users’ desktops if they are currently Hardy, Jaunty or Karmic users.

In Lucid, we put in a lot of effort to ensure these updates will be easier in the future (Firefox now uses bundled libraries rather than system libraries, we have reduced the number of applications in the archive using xulrunner, and dropped a lot of extensions too). The update for Lucid is quite trivial, but the update in Hardy, Jaunty and Karmic is not quite as simple. When we roll out the new version, we also need to update the following:

• All the Firefox extensions that we ship in the archive
• Language packs

In addition to this, we are going to be porting some applications which are currently using xulrunner 1.9 to either the latest version of xulrunner (1.9.2.4) or Webkit. However, this can happen after the Firefox rollout, as the 2 xulrunner versions can be installed in parallel. We have a list of the affected applications. We won’t be porting all of the applications on that list, but will be focusing on the applications which are exposed to insecure content (at the bottom of
the page).

Why:

Firefox 3.0 (and xulrunner 1.9) are now unsupported by Mozilla. Rather than backporting security fixes to these now, we are moving to a support model where we will be introducing major new upstream versions in stable
releases. The reason for this is the support periods from Mozilla are gradually becoming shorter, and it will be more and more difficult for us to maintain our current support model in the future.

When:

Next week, Mozilla will release Firefox 3.6.4 as a minor update to the 3.6 series. This will be rolled out to Lucid, Hardy, Jaunty and Karmic (along with xulrunner 1.9.2.4).

Call for Testing:

Packages will be hosted in the Ubuntu Mozilla Security team PPA.

As this is being rolled out as a security update (rather than a SRU), there is no bug report tracking this. The rollout is being covered (and will be announced) by USN-930-1.

Clearly, there are significant risks associated with the update. In addition to ensuring that Firefox and all the extensions still function correctly after the update, we also need to ensure:

1. All the Firefox plugins (eg, Flash) still work
2. The actual upgrade to the latest version goes smoothly
3. We don’t break Hardy -> Lucid and Jaunty -> Karmic upgrades
4. The upgrade works with the *-updates pocket disabled

Applications that are ported to the latest version of xulrunner (or to Webkit) will also need testing. However, we will also need to test every application on the list in (even the ones which aren’t being updated), with the latest version of xulrunner installed on the system. The reason for this is that most applications dynamically load one of the GRE’s on the system, and some of these applications will load 1.9.2.4 if it is present. I already know of 1 API change in 1.9.2.4 which had been causing me problems with applications I’ve been porting, so it’s possible that the same issue will affect applications we aren’t
porting if they load the newest GRE.

You can help testing the upgrade by following the instruction on https://lists.ubuntu.com/archives/ubuntu-devel/2010-June/030811.html

[Discuss New Firefox Support Model and Coming Changes in Stable Updates on the Forums]

Originally posted on the ubuntu-devel-announce by Sebastien Bacher on Tue Jun 1 11:59:25 BST 2010