Linaro: Accelerating Linux on ARM

At our last UDS in Belgium it was notable how many people were interested in the ARM architecture. There have always been sessions at UDS about lightweight environments for the consumer electronics and embedded community, but this felt tangibly different. I saw questions being asked about ARM in server and cloud tracks, for example, and in desktop tracks. That’s new.

So I’m very excited at today’s announcement of Linaro, an initiative by the ARM partner ecosystem including Freescale, IBM, Samsung, ST-Ericsson and TI, to accelerate and unify the field of Linux on ARM. That is going to make it much easier for developers to target ARM generally, and build solutions that can work with the amazing diversity of ARM hardware that exists today.

The ARM platform has historically been superspecialized and hence fragmented – multiple different ARM-based CPU’s from multiple different ARM silicon partners all behaved differently enough that one needed to develop different software for each of them. Boot loaders, toolchains, kernels, drivers and middleware are all fragmented today, and of course there’s additional fragmentation associated with Android vs mainline on ARM, but Linaro will go a long way towards cleaning this up and making it possible to deliver a consistent platform experience across all of the major ARM hardware providers.

Having played with a prototype ARM netbook, I was amazed at how cool it felt. Even though it was just a prototype it was super-thin, and ran completely cool. It felt like a radical leap forward for the state of the art in netbooks. So I’m a fan of fanless computing, and can’t wait to get one off the shelf ':-)'

For product developers, the big benefit from Linaro will be reduced time to market and increased choice of hardware. If you can develop your software for “linux on ARM”, rather than a specific CPU, you can choose the right hardware for your project later in the development cycle, and reduce the time required for enablement of that hardware. Consumer electronics product development cycles should drop significantly as a result. That means that all of us get better gadgets, sooner, and great software can spread faster through the ecosystem.

Linaro is impressively open: www.linaro.org has details of open engineering summits, an open wiki, mailing lists etc. The teams behind the work are committed to upstreaming their output so it will appear in all the distributions, sooner or later. The images produced will all be royalty free. And we’re working closely with the Linaro team, so the cadence of the releases will be rigorous, with a six month cycle that enables Linaro to include all work that happens in Ubuntu in each release of Linaro. There isn’t a “whole new distribution”, because a lot of the work will happen upstream, and where bits are needed, they will be derived from Ubuntu and Debian, which is quite familiar to many developers.

The nature of the work seems to break down into four different areas.

First, there are teams focused on enabling specific new hardware from each of the participating vendors. Over time, we’ll see real convergence in the kernel used, with work like Grant Likely’s device tree forming the fabric by which differences can be accommodated in a unified kernel. As an aside, we think we can harness the same effort in Ubuntu on other architectures as well as ARM to solve many of the thorny problems in linux audio support.

Second, there are teams focused on the middleware which is common to all platforms: choosing APIs and ensuring that those are properly maintained and documented so that people can deliver any different user experience with best-of-breed open tools.

Third, there are teams focused on advancing the state of the art. For example, these teams might accelerate the evolution of the compiler technology, or the graphics subsystem, or provide new APIs for multitouch gestures, or geolocation. That work benefits the entire ecosystem equally.

And finally, there are teams aimed at providing out of the box “heads” for different user experiences. By “head” we mean a particular user experience, which might range from the minimalist (console, for developers) to the sophisticated (like KDE for a netbook). Over time, as more partners join, the set of supported “heads” will grow – ideally in future you’ll be able to bring up a Gnome head, or a KDE head, or a Chrome OS head, or an Android head, or a MeeGo head, trivially. We already have goot precedent for this in Ubuntu with support for KDE, Gnome, LXE and server heads, so everyone’s confident this will work well.

The diversity in the Linux ecosystem is fantastic. In part, Linaro grows that diversity: there’s a new name that folks need to be aware of and think about. But importantly, Linaro also serves to simplify and unify pieces of the ecosystem that have historically been hard to bring together. If you know Ubuntu, then you’ll find Linaro instantly familiar: we’ll share repositories to a very large extent, so things that “just work” in Ubuntu will “just work” with Linaro too.

[Discuss Linaro: Accelerating Linux on ARM on the Forums]

Originally posted on Mark Shuttleworth’s Blog by Mark Shuttleworth on Thursday, June 3rd, 2010

Kernel Team Meeting Minutes – June 1st, 2010

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)

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):

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

Postponing Ubuntu User Days

With the second Ubuntu User Day being less than a week away, and in going over our final checklist, it has come to our attention it would be a better event, both in attendance and in the choice of session if we were to postpone this event.

While we understand that you may have scheduled time on the June 5th, 2010, to facilitate a session or participate by attending we want the experience of both session leaders and participants to be the best possible.

Keeping in mind we want to present the best possible learning opportunity, we have made the decision to postpone this event until July 10, 2010.

It is our, the User Days Planners, sincere hope that this will not be an inconvenience to you or any helpers with your session.

Thank you so much for you understanding! We are looking forward to another great second Ubuntu User Day (but a few weeks later and with more planning, promotion, participants, and more awesome session leaders like yourselves).

[Discuss Postponing Ubuntu User Days on the Forums]

Originally posted to the ubuntu-classroom mailing list

Call for Testing: Hardy Firefox Users (or willing to install Hardy in a VM)

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”.

List of testcases

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.

Report back

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

New Firefox Support Model and Coming Changes in Stable Updates

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