This page is here to collect together proceedings from sessions as part of sessions that don't fit one of the pre-defined tracks at the Natty UDS in Orlando, Florida.

Please add proceedings by doing the following:

• Add a new section with the name of the session.
• Add the outcomes of the session as a collection of bullet points. The goal of the proceedings is to really focus on decided outcomes, so please try to keep them crisp.

Thanks!

Proceedings

Paper Cuts for Natty

• Vish has been doing a lot last time, but he shouldn't have to do all work. This cycle more people should help him with triaging paper cuts;

• There will come an open Launchpad team, for everyone who is interested in fixing paper cuts. This team gets assigned to all paper cuts that are accepted, so the team's mailing list gets a mail and the team members know there is a new paper cut to fix;
• Until other package description projects get going we should continue to accept descriptions paper cuts, but they could be moved to a separate milestone;

• There will be a separate 'Paper Cuts'-like project for Unity, so the One Hundred Paper Cuts Project should be about applications and upstreams;

• Paper cuts in featured applications and in applications of upstreams willing to cooperate will be accepted during the Natty cycle as well;
• We will cooperate more directly with upstreams and Debian with regard to the package descriptions, to make sure our improvements benefit other projects as well, and we get feedback from the people who know the applications like no other;

• Vish will select the milestones for the Natty cycle;

• JonoBacon, JorgeCastro, SenseHofstede and Vish should generate (more) buzz at the usual channels about fixed paper cuts, including quotes from happy upstreams in the posts;

• We will investigate the possibility of using Launchpad Translations and a custom version of US English to provide a temporary easy way to modify package descriptions in Ubuntu;

• JorgeCastro will communicate our package description improvement effort to Debian, to make sure the Debian Developers understand what is going on and are prepared for our forwarded bug reports.

Testing Ubuntu on different architectures

• Only the testcases with subscribers in the ISO trackers will be built.
• Distributions will choose what architectures and "special testcases" they commit to.
• We will have regular names for architectures and distro names.
• The release manifest will include only the images that were tested properly.
• All this process should be automatic
• This change of policy will be announce to ubuntu-devel-announce

Cross-compilation Environment

• We will pursue and extend the efforts started under the ALIP umbrella to cover a larger set of packages
• Automation will be setup to test cross-compilation of the new package set in both in "from scratch" and "source by source" modes
• Multiarch control fields will be used to classify packages in host versus build packages

Kexec

• Kexec needs lot of fixes and testing on ARM, subarch by subarch
• Will extend kexec to cover device tree
• Some demo / test features will be implemented with kexec (kexec-reboot, boot menu etc.)

Kernel configuration management

• Will create a dataset of config requirements as to allow tailoring the config for a distro, or for a product
• Only machine specific configs could possibly be stored upstream
• Needs policies for Ubuntu and for Linaro to define common configs such as networking, security etc.

ARM gdbserver support

• gdbserver will be included in developer images
• New package for an armel cross-gdb
• Developer experience will include a new tool to grab debug symbols from ddebs
• Will develop new test frameworks and safety checks

Reinvigorating the artwork team

Session identified need to start a web presence project including following activities: 1.research

• .existing questionaire
• .Describe problem
• .Conduct survey
• .Analyse
• .gather data about lapsed members

2. Define our objective 3. Sketch solutions 4. Test and iterate 5. Launch

TASKS

• design a questionaire - Ivanka
• Set up fortnightly meetings - Iain/ Ivanka/ Docmo
• move the questionaire to a central place- docmo
• email the loco team leaders the survey- have them direct
• publicize the survey- on blogs, lists
  • .design blog, u-artlist local, contacts list, Flickr group.

Process

Project broken up into four sprints (2 weeks each)

1st Sprint

1. Review data in central place

2. Design questionnaire

2nd Sprint

1. Get survey out there and receive input after which steps 3 & 4 can be determined.

Design in open source

A first project to kick us off while we prepare the web project is Launchpad Edit Icon

1. Icon brief by wednesday
2. picpick for contributions
3. publicize
4. two week deadline - last submission
5. winner announced 3 days later

Defining Gestures in Ubuntu via Configuration

• Agreed that physically literal gestures don't need configuration options

Using QEMU for demonstrations

• many of Linaro's other outputs (kernel power management, performance, graphics improvements) are not demoable via qemu
• we should get the Beagle XM model working with Linaro images (as a compromise between memory size/capability and being a platform Linaro supports in h/w)
• investigate/use the paravirtualised OpenGL work done by Nokia for maemo/meego
• good audio support is tricky -- low priority

Using QEMU for development

• for development users we need not be modelling real hardware : we should define a "virtual platform" which is simpler and less prone to fragility in the face of kernel changes, and has more memory, fast virtual devices, and so on
• we are effectively "filling the gap" between now and when native ARM dev/build hardware is more prevalent/cheap
• need to test/validate qemu so it is trustable as a dev platform
• need to consolidate qemu trees to avoid the "which qemu should we use?" problem

Ubuntu One file sharing, sync status, and UDF selection

• Ubuntu One button in Unity launcher and notifications that something has happened (a share has arrived and needs accepting, etc) will go into the Messaging Menu
• Need to decide how to handle shares between these options:
  • Expose the current "reject this share completely" u1sdtool feature in the GUI,

in the Nautilus folder right-click menu, clicking it completely rejects that share from all your machines

• Change syncdaemon to allow rejection of shares per-machine (like UDFs will be handled)
• Only provide "reject this share completely" on the web and provide rejection of shares per-machine in N+1

• User Defined Folderes (UDFs) will not sync automatically by default
  • User will need to tell Ubuntu One which folders she wants to sync via the Ubuntu One control panel and at initial setup

Ubuntu One visibility and integration with Unity

• Ubuntu One in Unity launcher, launching the Ubuntu One control panel (ubuntuone-preferences)
• Ubuntu One notifications will go in the messaging menu
• Indication of syncing will likely go in the Ubuntu One launcher item

Ubuntu One integration with Zeitgeist

• Ubuntu One will log events in Zeitgeist and aggregate this data to display notifications to the user about important activity (content synced, etc.)
• An ontology for Ubuntu One events will be created and documented so that other similar services can use the ontology
• GNOME Activity Journal to support viewing events other thancreated, edited, deleted type events

Security AppArmor packaging

• get bindings in order (have perl, want python and ruby built, tested and packaged)
• cleanup to use modern debian packaging

• better upstart integration. This does not necessarily mean AppArmor will use a job file, but we should make it easier for applications with job files and AppArmor profiles to load their profiles via the job file. This will likely be done via a helper

• clean up /etc layout
• work towards inclusion in Debian so we can get expert feedback on existing profiles as well as more high-quality profiles

Security AppArmor upstream planning

Preliminary TODO list for natty:

• get the compatibility patches into natty - High - should be next week
• level 1 btrfs for natty (patch sent up for review very soon and then iterated) - High
• level 2 btrfs for natty (should be small after the first is sent up) - Medium
• level 1 network mediation - Medium (we have a compat patch in the meanwhile)
• send up his thoughts to the ml - Low - (we have a compat patch in the meanwhile)
• discuss and spec out sysfs hiearchy in the wiki
• sysfs introspection
• fix kernel so that it will drop policy compiled on a newer kernel for which it doesn't understand(currently network, capabilities, rlimits)
• make sure upstream initscripts or ok
• clean out super-crufty, old log parsing stuff

Kernel Testing

• Current testing resources and methods:
  • abrek - automatically adds support for a large number of test suites
  • checkbox - some automated tests and implementation of manual tests
  • firmware test suite
  • linux standard base
• Discussed methods of remote reset and power cycling features
• Security testing may be a future requirement
• Kernel tests to be implemented: NEON, Suspend/Resume, Kexec
• A method of automated testing needs to be implemented - OEM has some ideas
• Hardware needs to be consolidated to single test site

Eclipse CDT Support

CDT was accepted into Natty during the session. The blueprint will be massaged to encompass:

• Ensure seamless C/C++ development experience using eclipse
• Including external hardware
• Including debug of that hardware
• Including cross compilation targets
• Including qemu

Linaro Kernel Packaging

• Investigate script for producing per-flavour kernel source packages to allow parallel builds
• OMAP3 and OMAP4 should be able to coexist with some future upstream kernel
• udebs are not needed for Linaro kernel

Continuous Integration for Linaro

• Hudson is the tool we're going to use for this
• One instance will be shared by all linaro teams
• Try to get Hudson deployed on a separate DMZ in the DC
• If not acceptable, investigate and do it on ec2 as an interim solution
  • Need to figure out how it's going to be paid for
  • Can use Michael Hope's network for arm slaves as an interim solution

Package Development Tools

• Target audience: Linaro engineers not familiar with Debian packaging
• Implemented as a single command with multiple subcommands
• Use sane defaults to make things simpler but still allow flexibility for experienced users
• Focus on package fetching, building and uploading this cycle
• Will use chroots for cleanliness and to make it possible to target releases other than the one running on the host

Kubuntu Natty Docs

Notes

• stick with docbook for natty, reconsider in future if upstream KDE get the wiki process working well
• On kubuntu-users mailing list ask for howtos
• videos on new kubuntu.org site, basic setup topics. needs hosted agreed with IS and format sorted (ogg/HTML5 with youtube fallback?). not targetting translations for this cycle but consider in future.
• wiki cleaning would be lovely. - Setup a request to the Kubuntu users ML and get them involved.

Actions

• review welcome and about docs, consider combining them, add back link from live CD
• ask sysadmin for help.kubuntu.org, export docs to HTML and put there
• build an area of the wiki for documentation writing knowledge
• update docs for 11.04/4.6
• backport docs for 10.10/4.5
• Get packaging translations scripted as much as possible
• hold kubuntu docs days to list what needs to be fixed, updated, changed for cycle. at feature freeze
• Agree hosting of videos for kubuntu.org with IS
• Create tutorial videos for new kubuntu.org website

Internationalization of Launchpad Answers

• We discussed some of the internationalization issues with the current Launchpad code:
  • Launchpad was designed to have internationalization support, but it was never implemented end to end
  • Some parts of the code are in some way prepared for localization (e.g. python code with strings marked for translation), but they'd need more work
  • The way the Launchpad code is structured, internationalization could be implemented globally, but it would be interesting to do the work progressively: we are proposing starting with Answers and see how the process would work.
• We came up with a set of high-level actions that would enable any community member interested in leading the effort of internationalizing Launchpad Answers to get started on this project and follow it through to completion:
  • Mark strings as translatable from Zope templates
  • Check the structure of sentences to be translator-friendly
  • Make sure POT template generation works with i18n_extract
  • Make sure localization works in Launchpad itself
  • Review directionality of Launchpad pages
  • Figure out a way to select a language for the user (get SSO to provide it?)
  • Set up translations in Launchpad as a project and get translations exposed

Provide ARM cross-compiler packages for Ubuntu Natty

We discussed state of current toolchain and what will be done/investigated for Natty.

• need to check support for multilibs so we can get armv7 hardfp/softfp vfp/neon libs in one run
• need to prepare patches to have PPA with backports for Lucid and Maverick
• need to create a way to ship toolchain tarballs
• relocatable toolchains?

Supported releases will be:

• current development (with current packages)
• last stable release (with packages from release + current ones)
• last LTS release (with current packages)

other-foundations-n-backports-notautomatic

• Apt maintainers (Debian/Ubuntu) will address the apt resolver issue that prevents packages that are installed in a pinned repository from pulling dependencies from the pinned repository. This will benefit Ubuntu Backports, Debian Backports, Debian Volatile, and Debian Experimental.
• The Ubuntu Backports pockets will be set up so that packages from backports will not be automatically installed (take from backports only when the user requests it), but upgrades to newer packages in backports will be automatic.
• Ubuntu Software Center, Kpackagekit (and/or Muon), and update-manager will be adapted to appropriately expose this new option for an alternative (newer, but less tested) version.

Patch Tracking for Linaro

• The Linaro landing teams would be interested in something like patchwork
• The toolchain working group has some different needs for tracking patches carried, as well as changesets against their tree and upstream that are not in the other tree
  • They have a tool that they developed for tracking this that could serve as a prototype for what they are looking for
• We should look at extending patchwork to cover the needs of both these teams
• Another group has a completely different need that doesn't fit well within this model - tracking a small number of patches against a large, unknown number of packages and upstreams
  • Recommended approach is to use LP bugs against a tracking project, with upstream tasks to track upstream status

other-dx-n-connman-qa

• We need to get more users testing connman and we should do that from ubuntu-dev, blogs and tweets
• The automatic connman hardware test script, ubuntu-connman-test, will be ported to use launch control backend.
• Also we need to start looking at automated test suites for connman.

* Python script for testing Connman:
  * http://launchpad.net/ubuntu-connman-test
  * automated test suite
  * possibly send results to launch control
  * http://dashboard.linaro.org/data/dashboard_app/testrun/objects/2
  * Desktop Testing team integration?
  * getting more users to test connman

 * how to get testers
  * call for help on ubuntu-devel
  * blogging/twitter/etc.


 * automatic testing through code test suites


ACTIONS:
[kvalo] update ubuntu-connman-test scripts for launch control
[kvalo] issue call for testing for connnman
[mathieu-tl] upload newer connman

other-n-kernel-trees-maintenance

• We discussed plans for ongoing maintenance of Linaro kernel and U-Boot trees:
  • The packaged kernel tree will continue to track the upstream Ubuntu Maverick tree
  • No new features will go into the packaged kernel tree or the Linaro stable tree
  • For the Natty cycle the Linaro next tree will include the upstream PM tree at the request of the PM team.
  • Linaro U-Boot next tree will track upstream mainline closely with appropriate delay when upstream is particularly unstable.
  • Linaro packaged U-Boot tree will track upstream releases.
  • A wiki page will be created to document this

other-n-android

• Not trying to take over Android development from Google!!! (Or even do much Android development.)
• Not trying to produce a Linaro-branded Android!!!
• Will do:
  • Upstreaming: help make case for upstreaming of Android code, help with upstreaming.
  • Common tree: internal builds for Q/A of Linaro kernel and toolchain features.
  • Demo non-smartphone use cases for Android features

Handle core boot files update on ARM

• Coordinate with the Design Team to identify the best method to warn the user about the update
• Design a tool that is able to update the core boot files, like x-loader and u-boot
• Share the subarch detection library provided by other-arm-n-userland-subarch-detection
• Create proper documentation describing the update procedure and what to do in case of problems