1. Monday - Proceedings
    1. Kubuntu Natty Kontact
    2. Kubuntu Packaging
    3. Arm Server Optimized Lamp Stack
      1. Problem
      2. Questions
      3. Goals
      4. Benchmark Candidates
      5. Other ARM Server workloads
      6. Testing
      7. Profiling
      8. Server root fs
      9. Next Steps
    4. Finish Upstart
    5. GNOME plans for the natty cycle
      1. GLIB 2.28
      2. GTK3
      3. GNOME3
      4. Package selection
    6. Server Application Packaging and Distribution
      1. Topics for discussion
      2. Session notes
    7. Ubuntu Chinese Edition
      1. Proposed Changes
    8. Integrate Wine into Software Center
    9. Bash Tab Completion and command-not-found enhancements
      1. Main topics
      2. bash-completion
      3. command not found
  2. Tuesday - Proceedings
    1. Photo printing is not user-friendly and often broken
      1. Session Notes
      2. ACTIONS
    2. General networking stack enhancements
      1. Goal
      2. Aspects
      3. Issues
      4. ACTIONS
    3. Indicator Datetime for N cycle
    4. Cluster Stack in Natty
    5. Use GRUB2 and a boot framebuffer for a smoother boot splash
      1. ACTIONS
    6. Donations for free software through Software Center
      1. Unresolved questions
    7. Java Development Toolsets
      1. Session Notes
    8. Java Application Server Packaging
      1. Session Notes
    9. Thunderbird in the messaging indicator
      1. Session Notes
      2. Work Items
    10. Automatic printer driver download should support signed packages
    11. Improve detection of device class at install time
    12. OneConf in Natty
      1. Session Notes
  3. Wednesday - Proceedings
    1. Support mounts by unprivileged users
      1. Overview
      2. ACTIONS
    2. Ubuntu Server Install Flavors
      1. Background
      2. Proposal
        1. Options
      3. Decision
    3. Harmonize the behavior between apps and SoundMenu/MessagingMenu indicators
      1. Overview
      2. Plan of Record
    4. Transition to Firefox 4.0 in Natty
      1. Notable Firefox 4 changes and challenges
      2. ACTIONS
    5. Server application enhancements for upstart and upstart best practices
      1. Session Notes
      2. ACTION Items
    6. Ratings and reviews in software-center
      1. Overview
      2. Session Questions/Answers
    7. a11y support for unity
      1. Discussion Notes
      2. Goals / Scope
      3. Design Aspects
      4. Infrastructure
    8. Tools
      1. Development Plan
      2. Test Plan
    9. Linaro toolchain integration in Ubuntu Natty
      1. Summary
      2. Assumptions
      3. Code Changes
      4. ACTIONS
    10. Ensure integration with drizzle for Ubuntu
      1. Things to look at
      2. Actions
    11. Software selection and seed review for Edubuntu Natty
      1. Addition to ubuntu-edu-primary
      2. Addition to ubuntu-edu-secondary
      3. Addition to ubuntu-edu-tertiary
      4. Addition to dvd
      5. Addition to desktop-gnome
      6. Addition to desktop-kde
    12. Event-based initramfs
      1. Session Notes
  4. Thursday - Proceedings
    1. PowerNAP Improvements
      1. Overview
      2. Session Notes
      3. ACTIONS
    2. Hudson CI Packaging and Integration
      1. Use cases in Ubuntu
      2. Requirements from IS
      3. Packaging Complexity
      4. Integration Value
      5. ACTIONS
    3. How To Spy on Your Users
      1. Session Notes
    4. Indicator Framework Changes for N
      1. Agenda
      2. Test framework
      3. Development Plan
    5. Configuring a valid system hostname during install and boot
      1. Session Notes
      2. ACTIONS
    6. Resizing windows
      1. Background
      2. Ideas
      3. ACTIONS
    7. Java Library Housekeeping
    8. Thunderbird On Ubuntu
      1. Issues
      2. Advantages
      3. Gateways that work with Exchange
      4. Other
      5. ACTIONS
    9. Bringing the Ubuntu Desktop and Netbook favors closer
      1. Background
      2. Session Notes
    10. Indicator Messages for N Cycle
      1. Messaging menu discussion
      2. Me menu discussion
    11. Evaluate squashfs-lzma for the live CDs again
      1. Background
      2. Work Items
    12. Keyboard menu for Natty
      1. Agenda
      2. Links
    13. Enhancing indicator-network to support NetworkManager as a backend
      1. Session Notes
      2. ACTION
    14. Use LightDM for display management
      1. What is a display manager?
      2. LightDM in Ubuntu
      3. Why change?
      4. Requirements for the display manager
      5. Desirable Features
    15. Use a desktop-oriented form factor of Unity instead of GNOME Shell in the Natty Narwhal
      1. Background
      2. Agenda
      3. ACTIONS
    16. Improve User Translation Experience in Kubuntu
  5. Friday - Proceedings
    1. We Menu - Bringing Community to the Desktop
      1. Session Notes
        1. UI Considerations
        2. Family & Friends menu items
      2. Links
      3. ACTIONS
    2. Desktop Applications Selection for Natty
    3. DBusMenu changes for N
    4. Discoverability of alternate server packages
    5. More stable VM solution for running armel VMs
      1. Current situation
      2. Use cases
      3. Hardware
    6. Provide a Linaro image with a set of developer-oriented tools installed by default
      1. Assumptions
      2. Design
    7. Indicator Application N cycle
      1. Session Notes
      2. Q & A
      3. Action Items
      4. Links
    8. Multiarch Support for gcc, binutils, dpkg, and apt
    9. Geoclue on the desktop
      1. Ensure geoclue is maintainable in the distribution
      2. Available providers
      3. Providers to include
      4. Ideas
      5. Concerns
      6. ACTIONS
    10. Server Natty Kolab

Natty UDS Package Selection And System Defaults Proceedings

Track Schedule:

Monday - Proceedings

Kubuntu Natty Kontact



  • No scheduled release date for KMail 2/Kontact 4.5
  • Assume going with Kontact 4.4
  • Be very wary about new version if it does appear, do lots of testing
  • Impractical to split out KMail 2 from rest of KDE PIM
  • KDE-mobile -- still experimental, but on its way, we should package it (it's part of 4.5 tars we think so include with them)


  • Ensure Kontact works from live image, currently shows Akonadi error due to no Nepomuk
  • Review Lionmail for packaging
  • Work with Kolabsys for testing before beta and RC
    • Testing takes two days. Kubuntu people needed for verification

Kubuntu Packaging



  • Ship with KDE SC 4.6
  • make sure PPA packaging is based on current release as much as possible
  • we need to test ourselves, since we cannot rely on upstream for that (or good change documentation
  • Thiago says should be fine to turn on Qt raster painting for everything, will be default in 4.8 anyway
  • Interesting wishlist: Implement likeback in kdelibs and turn on for all apps for alpha/beta


  • Package KDE SC 4.6
  • Package Qt 4.7.1
  • Package QtWebkit 2.1

  • Ensure we have latest KOffice, KDevelop, Amarok etc
  • Inform Debian of delta in packaging, highlighting parts they're interested in
  • Project Neon, add KDM session
  • Project Neon, go big with announce! Dot News, blogs, fridge
  • Project Neon, fix Cache issues using patches for kde4libs
  • Integrate automatic ARM building with KDE dashboard
  • (re-)propose to tech board to include updates in -updates, QA'd in PPA first
  • Get 4.4.5 into lucid-updates (Kontact 4.4.7)
  • Turn on raster for Qt for an alpha
  • Switch from qtcurve to gtk-oxygen-engine, ensure settings update properly
  • split up kdegames-card-data (ideally get upstream to move bad ones to kdeartwork) so kpat can fit on the CD
  • make a metapackage > kubuntu-desktop-all for DVD

  • Consult with upstream and switch to Phonon GStreamer backend
  • Package owncloud
  • Package Plasma Media Centre

Arm Server Optimized Lamp Stack



  • No solid benchmarks for server apps on ARM or collected data can't be shared
    • So what does it mean to have a high performance LAMP stack on ARM?


  • What kind of utilities and tools can we use to benchmark a system?
  • What type of packages do we need to provide a high performing LAMP stack on ARM?


  • Figure out the benchmark numbers as they are for ARM, compare to Intel/AMD, then improve.

Benchmark Candidates

Other ARM Server workloads

  • Squid
  • MariaDB/Drizzle
  • Redis -

  • Memcached
  • HipHop for PHP

  • PHP workloads (with benchmarks?) Drupal (, Wordpress (has benchmark)

  • Samba (?)
  • Cluster file systems (?) GFS / Gluster
  • Shark JIT on ARM
  • Python, Twisted (used by Launchpad), Ruby on rails (new kid on block but growing)
  • DNS - bind (Memcached a good proxy for DNS performance - essentially a look up)
  • HAProxy - user space - interesting


  • Look at adding hooks into checkbox for benchmark testing on ARM
  • Martin B, Dave Rusling (Linaro), Chuck, Leo (ARM) - willing to help with testing with hardware and appropriate information that makes things easy to run
    • Scripts? Apt install on top of Linaro testing?
  • Results to be hosted on UDS wiki for now
  • Recomended kernel config
    • + perf / oprofile
      - debug
      + large block handling


  • Dave Martin / Will Deacon (ARM) will post pointers to info about using the Linux perf tools to collect profiling data.
  • Important to collect profiling information during benchmark runs

Server root fs

  • How to grab server root fs - grab right ARM image - no server ISO right now
  • Martin Bogomolni to test root stack / media create to base file system only
    • - Exact binaries needed for testing
      - Align with Linaro methodology on this

Next Steps

  • Distribute work
  • Collect results (once testing made easy / repeatable)
  • Circle back on identification of focus areas
  • Identify bugs / route to owners for resolution (missing packages, broken, poor performance etc...)

Finish Upstart

Last UDS (recap): Stable version of Upstart in Ubuntu now for a few releases, working out reasonably well, but there are a number of things we need to fix (the fact that mountall is needed, user services, etc.). Used last UDS to get a sense of what complaints were from various people and groups, and made sure that appropriate bugs were filed.

Upstart's design is too simple. The goal of the next version is to fix problems based on deployment experience while retaining the "Upstartishness", and reach an elegant, simple design that we don't need to change again: i.e. 1.0.

Proposed Changes:

  • add the concepts of states which are based on events and persist beyond the event, which jobs can depend on
  • child tracking should use proc connector
  • events should be queued against jobs when the job is transitioning
  • overrides to local configuration of jobs without editing them
  • new hook on starting * to allow tracking of job dependancies
  • upstart will know about chroots and make itself available in there if it is going to start jobs automatically; and use the root directory for local start within a chroot to start the right jobs

Need to get buy in for these features

GNOME plans for the natty cycle


GLIB 2.28

  • Ready by December
  • Non-controversial release
  • Still a number of applications require porting to gsettings
    • gnome-panel in process of porting
    • We should generate a list of applications Ubuntu needs porting to have the CD gconf-less


  • Plan of record to release in December
  • There will be more ABI breaks coming before then
  • Will need both versions on the CD
  • List of libraries in jhbuild that will need a GTK2 and a GTK3 library
  • We only want gsettings/GTK3 in the LTS
  • No GTK# bindings for GTK3


  • Clean the CD this cycle of obsolete libraries:
    • gnomeVFS, libglade, libgnomeui...
  • Upstream needs feedback on gobject-introspection/PyGTK
    • port our apps (software-center, apport, etc.)
  • GNOME Control Center etc are all or nothing upgrades
    • Rodrigo has a plugin that provides the old gconf API for older apps
  • GNOME Shell will be available in Universe
    • Ubuntu patched apps don't always work perfectly (e.g. indicators) in different shells
      • Need a consistent way for these patches to detect they are in vanilla GNOME and behave as upstream intended (ryan)

Package selection

  • Drop tsclient, and use vinagre if it supports RDP, otherwise consider Remmina
  • Consider sticking with existing versions if packages are doing risky changes (like we did for Maverick)
    • Most packages should be OK, nothing controvercial
    • Keep evolution at 2.32 as of now (will be updated the week after UDS), see what's going on later on the cycle.
    • Totem should be fine for 3.0 (vuntz) - it didn't make a 2.32 release
    • Consider replacing EOG with shotwell (fagan via irc) - need to ask shotwell devs, for Maverick they didn't recommend this
    • Nothing major happening in GNOME Games, gcalctool
    • GEdit is gold as always
    • Cheese has new features but should be good (vuntz)
    • Yelp can go to latest version now (changes were held back)
    • GDM update to 2.32. GNOME Design has mockups for new greeter, but wont be ready for 3.0
    • Applets may not work with the latest gnome-panel
      • Tomboy might need porting
  • Can get rid of gnome-system-tools?
    • Only thing being used is time configuration
    • Features are being merged into gnome-control-center
  • gnome-utils
    • Package has been split since maverick
    • Drop gnome-dictionary - doesn't work outside of english, not well supported
    • gnome-search-tool - not needed in Unity, needed for 2D experience
    • an environment variable to add to get some default GNOME experience and don't break the GS

Server Application Packaging and Distribution


Server (and specifically Java) applications present a challenge in terms of packaging for Ubuntu. Alternative packaging and distribution methods should be considered to ensure that Ubuntu can support server application requirements whilst minimising overheads.

* Spawned two other sessions * Two problems need to be solved: Freshness of fast moving upstreams, and packaging of upstream applications that don't fit into the archive. * Freshness will be pushed to the discussion about making it easier to create source packages and upload them "Somewhere". * Unsuitable packages will be addressed by making it easier to discover alternative archives. packageselection-server-n-discoverability

Topics for discussion

  • Policy of when server applications and services should sit outside of the normal release cycle
    • Contributing factors
      • Frequency of upstream
      • Complexity of dependencies/overlap with Ubuntu
      • Demand for application or service
      • Plans for build-from-source packaging
  • Where upstream development methodology does not fit with build from source
    • Java stack packaging approach
      • Build from source or binary packaging?
  • Distribution methodology
    • Options:
      • PPA - have all the functionality necessary already to group packages and dependencies to ride on top of the core releases.
      • Upstream conduits?
    • Challenges: visibility from update-manager/apt
  • Roles in packaging and distribution
  • Other Considerations
    • Security vulnerability monitoring and patching
    • SRU equivalent processes.
  • Examples to support discussion from Maverick
    • Cassandra
    • Hadoop
    • Terracotta
  • Potential candidates for Natty
    • Hudson
    • JEE Application Servers
    • + Others

Session notes

  * Server applications specifically
  * Many projects release early, release often, and that isn't a good fit
    for the distribution cycle


  * Conduits - blessed PPAs (blessed by Ubuntu or the upstream project)
    - e.g. drizzle
  * Added specific pakcages (or specific versions of those packages), while
    not changing the base OS
  * Sometimes libraries are added to these PPAs, which can cause problems
    with other applications. SONAMEs mitigate this somewhat, but aren't
    perfect, and there are also cases where problems can be caused by
    behaviour changes in new versions etc.
  * Use copies of libraries if you need an update, rather than changing the
    version used by everything on the system?
    - Harder for sysadmins to know what is on their system.
  * Something people are doing now (mathiaz - 95% comes from archive, 5%
    from upstream) - making it easier and encouraging best practices.
    - Spamaps: more aiming for fast-moving projects: Cassandra et. al.
    - ttx: two related cases we are dealing with Cassandra, and
      getting latest packages for the area that you care about.
  * ScottK: clamav may provide an example we could follow, maintaining
    current clamav releases in all supported Ubuntu releases. Assuming that
    we can't do it in the archive may be a mistake.
  * backports might be useful to, if the bug is fixed that means you get
    everything in backports if you enable it for everything.
  * Dustin has had success with pushing to PPAs for all releases when he makes
    a release of his projects.
  * mtaylor: leaving old versions in the archive still gives you a headache,
    as that's where people go by default.
  * ttx: possibly two solutions. "Freshness" could be fixed with backports,
    should talk about "unpackageable" packages.
  * Java is a common source of these packages.
    - Getting everything built from source and packaged is a huge task given
      the number of libraries required by the transitive dependencies.
  * ttx: is allowing distribution of binary versions of these packages a solution?
  * slangasek: what value are we adding if we are just passing on the upstream
  * mathiaz: discoverability: apt-get install hudson
  * ttx: some level of integration, e.g. deploying hudson with tomcat
  * SpamapS: did it with Cassandra: have a PPA which uses upstream packages,
    based on binary jars embedded in the package.
  * ScottK: what difference to multiverse?
  * multiverse is a definite possibility, and wouldn't really be the first time
    that we would have used it for this.
  * SpamapS: upstream are releasing these things in a format that works for them,
    maybe we are missing a tool that allows us to package them easily.
  * multiverse implies a value judgement on the package, so could take care
    to document why they are in multiverse.
  * A related problem is that upstreams will demand particular versions of packages.
    Providing multiple versions in the platform might be needed.
  * Upstreams often see the platform as constraining, so bundle their libraries
    so that they can have greater control.
  * We usually do that for security update purposes, and that is some of the value
    that we add, so there's a fine line to walk between enabling upstreams
    and providing security support.
  * Some nascent effects to encourage Java developers to use common versions.
    - maven makes it a hard sell.
  * cjwatson: get them to ship test suites, so we can have some confidence that
    if we change library versions an app uses it will work.
  * mtaylor: as much as I agree with our approach, convincing these communities
    may be tough when they are heading in a different direction, and other platforms
    don't follow our model.
  * ttx: for each of the "unpackageable" things we should look at the cost of
    doing it right, before using any alternative method.
  * SpamapS: if we aren't adding value, we should get out of people's way
  * ScottK: is the integration ttx described enough value to make it
    worthwhile chasing this?
    - not really
  * slangasek: if we don't support it then don't make it look like we do.
  * mtaylor: probably more upstreams that would create a PPA. Better tools for
    packaging could help with those that don't know how to package, even if
    the packages are crappy.
  * Documentation problem. It's fairly easy if you use the right tools.
  * ttx: based on the amount of added value multiverse would make sense, with
    PPAs where we don't add any value?
    - yes(?)
  * james_westby: build tools for upstream development communities to generate a debian source package.
    * Make creating source packages OBVIOUS and SIMPLE
      - "debuild" without ./debian
  * Dual approach: go multiverse+backports or PPAs based on Ubuntu-specific added value
  * To be continued in a "discoverability" and a "language-oriented dev tools" sessions

Ubuntu Chinese Edition


Proposed Changes

  • Same packages as Ubuntu
  • Consider settings changes appropriate for China
    • Language Pack - Chinese
    • Fonts
      • Quality issues with current open source fonts
      • Considering non-open source font alternatives
  • Would like to have in this release cycle (Started early experiments to confirm feasibility)
  • More like a localized Desktop Edition
  • cdimage & releases would cause issues by getting asked for other versions in many other countries. (Suggests finding another resource)

    • many of the answers could depend on the questions
    • Goal would be to make this perpetual for each version. (Not just 11.04)
    • Govt. standards
  • Need to consider local choices (Baidu, etc.) and produce a list

Integrate Wine into Software Center


  • Have applications offered in the Software Centre
  • Direct X Support could be marketed as a potential benefit
  • Could use a windicator for the user to notice that he is running a Windows program
  • Nothing today to prevent Wine from making general system calls, so we need to find a way to isolate things to prevent accidental or malicious use.
  • We can handle prefixes for packaged cases
  • Show apps that have been installed in the /home directory.

    • Could remove using Software Centre even though they were installed by other means
  • We should promote our own applications when the user is installing a Windows program
    • for example, if a user wants to install MS Office, we warn him that LibreOffice offers the same functionality

  • In a multi-user case the removing of things may be difficult.
  • Cautious Launcher isn't favored because it's not easily translatable.
  • Channel thread that we should encourage local Linux apps rather than enable old Windows addiction
    • Adding to the above point, if Canonical notices that a Windows application gets lot of users, Canonical should encourage the application developers to port it to Linux, or even propose to port it themselves.
  • If we can make things smoother it will lead to more Ubuntu users.
  • We need to be sensitive to GPL redistribution issues
  • From a commercial perspective, could we use this to enable "Windows only" program to get it in the Software Centre.
  • The use case of getting Software Centre to list the applications and remove installed apps is something that would need to be written.
    • Designed first, then code written

Bash Tab Completion and command-not-found enhancements


  • bash tab completion will be reviewed for inconsistencies and bugs filed
  • A complete review of the current design was done, but no clear way was found to improve it.
  • command-not-found may have some arbitrary hints added, but a broader discussion is needed before its clear that we should do this.

Main topics

  • bash argument completion
    • lack of consistency (sqlite doesn't let you complete database files)
  • command-not-found
  • Bash tab completion unpredictable, handled differently by each different program


  1. identify packages without completion information
  2. review current ones and make sure they're accurate
  3. file bugs accordingly
  4. Investigate Apport Integration

command not found

  • support arbitrary hints
  • ACTION: set opinionated defaults for the server seed (put in a special package)
  • ACTION: modify command-not-found to use ^
  • ACTION: publicize this capability to ubuntu / debian developers

Tuesday - Proceedings

Photo printing is not user-friendly and often broken


Session Notes

shotwell doesn't easily allow specifying paper size (in the print dialog the widget is disabled)
general GTK printing architecture problem
you can only select relative size
paper size can be set in "Page Setup"

eog: no separate "Page Setup" menu entry, it's integrated into dialog, and paper size combobox is enabled:

upstream: hasn't been first priority so far, since most people just published it to the web; would like to get input about which features people want

= Open Printing Dialog =
There is funding for it and completion is in June 2011, so it looks like 11.10.


SebastienBacher: check with GNOME guys why paper size widget is disabled by default TillKamppeter: report bug upstream, if ^ turns out to be intended

General networking stack enhancements



defining the requirements to give the best network experience to users in natty.


  • kernel drivers (e.g. broadcom)
    • more work required
    • the new opensource driver is currently poor quality and requires many man months of effort, this is not likely to be done within the project for natty
  • network device naming
    • primarily on server people are interested in naming being stable
    • people prefer to have fixed names in some cases
    • udev already supplies stable names for them, but they are not necessarily sane ordering
    • can we use the BIOS naming at all?
    • changing the rules is problematic as preseeds may rely on the current rules
    • we could use a new preseed option to select any new naming
  • DHCP (v4?)
    • we need this to handle IPv6, should pull this in
  • ifupdown
    • doesn't seem to be an updated version
  • wpasupplicant (0.7 ?)
    • kvalo & cyphermox

  • IPv6
    • much of this should already be working
    • testing: will need coordinated testing across many different network environments
  • network manager (0.9 ?)
    • this sounds like it is something we do need
    • likely to switch if it is of sufficient quality in time, but this is likely to hit in a few weeks
    • likely to move to system connections by default, but with ACLs
    • user switch leaves a VPN open for all other user sessions, currently no plan to resolve this, primary focus is preventing exposure of the passwords etc not the connection itself
  • indicator for UI (session Thu 5pm)
    • need indicator support in network manager
    • there is support added to network manager to make adding this kind of bells and whistles easier


  • applications attempt to use the hostname to find IP address, this not so clear if the name points to 127.x
  • use of clock for dhcp leases might be problematic (block skew is not handled which can lead to use of expired allocations)


  • ColinWatson

    • sync DHCP v4 from debian
    • integrate biosdevname ( for stable network device naming in installer
  • MathieuTrudel

    • enable test runs for network manager during build
    • look at getting indicator support into network manager
    • wpa-supplicant support for the installer
    • blog how to help with NM -- writing test cases (for code), other low-hanging fruit
  • kvalo/MathieuTrudel

    • get wpasupplicant 0.7 from debian SVN ready + upload

Indicator Datetime for N cycle


  • No Gobby Notes Available

Cluster Stack in Natty


  • Meta-package: Simple - Only to join the cluster.
  • Docs:
    • We need to improve docs -> server guide (once packages reach main)

    • clvm docs
    • provide recommendations (which cluster FS to use... ocfs2, fencing)
  • UEC/EC2
  • Upstart RA
    • upstream included patches
  • Use Cases for automated deployment. Two main types of use cases:
    • simple
      • (would be messaging layer + pacemaker)
      • Virtual IP
    • advanced (would be shared file system, clvm, drbd)
    • Puppet?

Use GRUB2 and a boot framebuffer for a smoother boot splash


This issue was first addressed during Maverick UDS, then result was that many machines no longer booted as the graphics drivers were not able to program the card correctly from anything other than VGA modes

Bugs from previous attempt:

We could at least whitelist known working machines. Not ideal but workable. This may have to be done at GRUB loader time, because if we do it in grub-mkconfig then swapping graphics cards may result in inability to boot. We will have to fix PCI probing in GRUB (see LP 641259).


  • ColinWatson

    • re-enable gfxpayload=keep and call for testing
    • re-enable lua grub-extras module
    • cut over to whitelist mode some point reasonably before beta
    • general bug triage work item
  • JeremyFoshee

    • tag bugs 605614, 608429, 612626 and other similar bugs and monitor for new
  • AndyWhitcroft

    • give graphics upstreams a heads-up about impending bug reports
  • EvanBroder

    • add white/blacklist functionality to grub2

Donations for free software through Software Center


  • Intent - accept payments through software center for free software in the Ubuntu stack, and have those payments make their way to the developer
  • Proposed model - token model: prove you can modify package/code/whatever before receiving $$$
    • Use package homepage from package file, and inspect that home page for token?
    • Has other problems (this is open source software, after all)
  • Issues
    • What about when an app doesn't have a clear person to donate to?
      • option 1: don't donate
      • option 2: take $ for all apps and donate to a single place
      • option 3: do a general donation
      • Developer Portal could help define who is the person
      • If we restrict our initial implementation to packages with very clear answers and existing 501c3 foundations, then someone would soon make a 501c3 foundation to handle "the rest" -- so we may not need to worry about individual donations to individuals
  • rickspencer3 feels strongly that we should only accept donations for projects with clearly defined "end points"
  • we could add a "I would like to donate" button
  • How do you prove that you own assets related to the projects?
    • we could check the defined homepad and see if there is key there?
  • Provide fundraiser-like ( donation messages.

Unresolved questions

  • how to have people register as project owners to receive funds
  • how to respond to and resolve disputes
  • how to pay $ out to the parties

Java Development Toolsets


Ubuntu currently packages Ant and Maven 2; a number of other development/build tool-sets including Gradle, Spring Roo and Grails are gaining popularity in the Java development community and we should consider packaging for Ubuntu.

Session Notes

Discussion Topics:

* Making Ubuntu the Java Development platform of choice
  * Why? Should make Ubuntu Java packaging from source easier for Ubuntu based projects.
        Agreement that this was a good objective....
  * Review of current tools
  * The future of Java development.
  * Key targets for improving the appeal of the platform by taking the engineering effort out of Java development.
    * Grails (depends on Gradle) -
    * SpringRoo
        Good targets for Natty cycle.
    * buildr (Ruby based build toolset).

* Supporting Java development off platform through Ubuntu:
  * Ubuntu based Maven repository?
        Potential target for natty cycle depending on complexity.
  * Would align non-Ubuntu based development to Ubuntu Java Reference Library.
* IDE; lag behind latests versions so limited development appeal.
  * Challenges
         * enterprise fix versions, but not the same version.
  * Potential Solutions (depending on outcome of distribution channel sessions)
        * PPA's for latest stable release of each version.
        * Challenges around packaging due to breaks in dependencies need to be considered.
  Potential requirement for discussion with maintainers of Eclipse around packaging and use of alternative distribution channels.


  • Grails (and gradle) - target for Natty release
  • Spring Roo - target for Natty release.
  • Define approach for IDE packaging alongside application distribution changes

Java Application Server Packaging


Session Notes

* Is a full JEE stack where we should be going (see SpringSource for an alternative approach)?
        * Is JEE webscale?

* Complexity of build from source/packaging vs value of bring JEE stack to the platform i.e. is anyone going to use it?
        * Build from Source
                * Supporting multiple versions of dependencies to resolve conflicts?
        * Binary Packaging
                * Channel through PPA or Multiverse
                * JEE compatilbity against binary artifact not source artifact
                * JONAS (OW2) could be a 
        * Patent Encumbered; needs to be considered.
        * Potentially start small by removing backend options

* When to target Tomcat 7 -> Ubuntu?
        * Relatively low cost so should be considered to support latest Servlet/JSP API's
        * Current Tomcat is 7.0.4 (released 2010.10.21)
        * with support for Servlet 3.0, JSP 2.2 and EL 2.2
* Maven -> debian automation.
        * Required to support scalability if we choose to support a large numbers 
          of java libraries.


  • james to update Tomcat 7
  • james to make a jonas package from binaries
  • james to try packaging jonas from source, see if it works / how hard it is
    • nijaba to introduce james to ow2
  • clint to create an automatically populated PPA with the content from the
    • maven archive

Thunderbird in the messaging indicator


Session Notes

* BAMF to see if program is running

* Need to see if there's a trademark is with "Mail" name for indicator

.desktop - static menus
 - blacklist for Global Menu
appindicator - dynamic menus

Xul to indicator conduit

Messaging Menu integration preferences
* Ability to Disable
* Able to select which mailboxes are displayed

* Cluster Notifications (note that a notification can append)

Possible Lists
* Last 10 messages
* 1 msg/mailbox

Evolution current messaging menu:
* Compose New Message
* Address Book
* Mailboxes up to 7

Work Items

  • ChrisCoulson

    • write messaging menu extension
    • discuss with Mozilla about global menu
    • Investigate Lightning integration w/evolution data stores
  • ChrisCoulson/JorgeCastro

    • mail to tb-planning about indicator integration

Automatic printer driver download should support signed packages


  • No Gobby Notes Available

Improve detection of device class at install time


  • No Gobby Notes Available

OneConf in Natty


Session Notes

OneConf is currently integrated with USC, relying on desktopcouch. There is the issue of scalibity:
- improvment to desktopcouch? (a lot of data filing in)
-> refactoring of desktopcouch will be done soon

- real deletion to the DB
-> compressing

The current design isn't the mpt one:
- how can we get a complex tree from USC?
-> postpone for natty

- having a touch approach?
- how can we remove/hide selection from another computer (like, you reinstalled it, need a GUI for that)
- we can know the cause of the difference between two computers, like "never installed on remote computer", or "as beeing removed at…" or "installed on…"

What can we do with the data we have?
- additional ppa?
  -> available in the detail view, enabling the ppa from there
- ordering by installation date
- sharing a list of applications/bundle
  -> creating a manifest file for that.
- being able to push temporary directly to desktopcouch in the u1 db so that you can access to it anywhere (signing temporary to your u1 account). Making a website.

Use Ubuntu sso
Some enhance performance trick, especially on netbook.
Get and update the wallpaper of the recorded host
use the wallpaper icon in the back

Integration in ubiquity ?
-> sso authentifcation at start
-> can't wait for desktopcouch to sync, how to get the data ?

Wednesday - Proceedings

Support mounts by unprivileged users



  • at some point in the past there was a kernel patch to allow a user to
    • do some restricted mounts
  • Can we allow some set of mounts
  • Can we come up with a solution to denial of service issue
  • Can we do something in Natty to get patch upstream or ...
  • there is a command line utility that does dbus calls to mount usb and such from command line
  • generally makes kees uncomfortable


  • KeesCook to look more at patch and think about it more

  • SergeHallyn to follow up on dbus socket user id

Ubuntu Server Install Flavors



For years now, the Ubuntu Server has tried to perform a balancing act, aiming to provide a feature-ful, useful server while being as trim as possible. In doing so, we're failing to meet the needs of both camps, landing somewhere in the middle ground where few people are happy with the default package set.
Server installer currently provides options for:

  • Ubuntu Enterprise Cloud
  • Ubuntu Server
  • Buried under F4 -> Install a minimal virtual machine


To solve the above problem, I suggest that we expose two different installer options right on the boot menu.

Ubuntu Server Deluxe would be a bit like the current default Ubuntu server install, but just slightly richer. This method installs a rich set of defaults useful to a large cross-section of Server users, including SSH-enabled-and-running by default, Byobu-launched-by-default, perhaps etckeeper enabled-by-default. We're open to other suggestions. The Ubuntu Server Deluxe install is intended for new server users.

Ubuntu Server Minimal is similar to JeOS, but actually even smaller. Here, we do not install recommended packages, language packages, perhaps purge documentation (leaving pointers to web accessible docs), prune unneeded kernel modules, etc. We can get this footprint down under 100MB. This installation is intended for power Server users, who want to completely customize their system after a minimal installation.

  • DustinKirkland's initial view: two options on the main ISO menu, where we should expose all 3 of these in the syslinux menu:

  • Install Ubuntu Enterprise Cloud
  • Install Ubuntu Server Deluxe
  • Install Ubuntu Server Minimal
    • will detect if running on an hypervisor and install appropriate kernel(this has to be checked on VMware, virtualbox and Xen and make sure it works there as well)
      • running in kvm, /proc/cpuinfo says: QEMU Virtual CPU

      The Ubuntu Enterprise Cloud works as it has for the past few releases, installing all of the components necessary to host a cloud. The key difference is in (2) and (3).

  • ThierryCarrez's view: pimp preseeding, by providing the ability to access preseeds on the network and expose more profiles this way.

    • could be a way to measure popularity of profiles
    • needs to work with alternate repositories including local ones (enterprises may not have internet access)
  • Mathias' suggestion:
    • Make the server installer a 2-stage installer
      • 1st step, install a minimal server
      • 2nd step, add whatever server tasks afterward
    • Makes it look more like cloud images, which are all "the same" at first, and are customized afterward using cloudinit, apt, etc
    • Potentially make demo ISOs if you need customized one-stop shop
      • Could be offered as a service
    • Integrated view across cloud-init/servers/installservice (rename cloud-init to [ubuntu|server]-init)
    • Blends into the enterprise way of doing things (plug into puppet for example)


  • The 3rd option of having a 2 stage installer was most preferred by session attendees, with those in attendance not seeing any significant drawbacks to this approach.
  • The Ubuntu Installer team will be consulted and further discussion will take place within the Ubuntu Server community

OpenSSH by default was also discussed, but attendees agreed to discuss this issue separately.

Harmonize the behavior between apps and SoundMenu/MessagingMenu indicators



In lucid, rhythmbox has a smart "close" feature:

  • if you hit the close button in the decorator while rhythmbox is doing nothing, it closes indeed
  • if you hit the close button while rhythmbox is playing, it's hiding completely from the desktop, and you can get it back by the soundmenu.

This session discussed how we can get the same behavior in the messaging menu applications.

Plan of Record

  • nothing to do with messaging menu applications as not seen as a desktop service
  • File->Quit to be renamed File->Close to have the same behavior as the quit button

  • subscribe design team to the bug report.
  • See with rhythmbox and banshee people if we can keep the same state across session (like, if you pause, your launch it again, it's still paused).
  • Post on about ui state between sessions.
  • API for applications developer to do that easier.

Transition to Firefox 4.0 in Natty


Notable Firefox 4 changes and challenges

  1. omnijar packaging by default
    • Default preferences are packed inside omni.jar, which means there is no way to change default preferences on an installed system.
    • We can provide a system-wide preference file in /etc via an extension, which administrators can use to configure defaults.
    • We won't be providing a mechanism to allow applications (ie, software center) to drop random preferences in the firefox directory. The only supported way to do this in the future will be via an extension or distribution bundle.
  2. Packed extensions
  3. XPCOM component registration changes
  4. Depending on GNOME plans, we might need to add GSettings support where Firefox is currently using GConf
  5. It currently provides an about:home handler, we need to investigate whether it provides the functionality that currently exists in ubufox
  6. Translations:
    • Now we don't have someone from the Desktop team dedicated to uploading Firefox translations, could these uploads be part of the packaging process?
    • If we want to use the dev mode in po2xpi we should document the process
    • Is po2xpi working properly? Are there any major bugs that need fixing?
    • Usage of localized search engines.
    • We should find out whether there are trademark issues in using translations that have not yet been submitted upstream


  • ChrisCoulson

    • Review ubufox about:home to see if it needs to be changed since Firefox 4 has an about:home now
    • Look into changing translations from addons to distribution bundles
    • Review extension list in archive to see what can be pruned
    • Port Firefox 4 to gsettings
  • DaniloŠegan

    • Automate upstream translation imports for Firefox into Launchpad
  • DavidPlanella

    • Talk to Mozilla people about using user provided translations from Launchpad
  • Micah Gersten

    • Abrowser broke (needs to be updated to 4.0)
    • Possibly build abrowser on xulrunner

Server application enhancements for upstart and upstart best practices


  • Upstart refactoring in packageselection-foundations-n-finish-upstart should solve most issues raised in the blueprint.

  • Logging is a separate issue from the refactor and can be done by anyone in parallel with the refactor.
  • Best practices were discussed, many of which were rehashed from older UDS sessions. A single wiki page on will be created or updated and made the trusted source for these best practices.
  • It was reiterated that upstart does not implement the LSB or sysvinit interface, and so software such as puppet needs to have an upstart module to complement their sysvinit module to help manage services properly.
  • cjwatson will extend plymouth to listen to upstart's dbus interface for jobs being started and stopped and report this in the details plugin.
  • Overlay files were discussed to allow server administrators to override an upstart config without triggering dpkg conffile conflicts. It was also reiterated that upstart jobs should be simple enough to be treated as config files.

Session Notes

* Best practices for upstart jobs - document and list them
 * Conffiles - should upstart jobs be software or configuration or both?
   - [action] document upstart job best practices (should be small/simple)
   - /etc/default was created because changing scripts in /etc/init.d often caused hideous merges (cjwatson)
   - suggestion: provide framework for an "override" file, which are nonexistent by default, concatenated to the end of the conffile upstart, in /etc/init/local/*
 * Logging in upstart jobs
   - upstream fix: stdout/stderr proxied through init to [initctl/logging daemon/etc]
   - no "refactor" required; could be done by anyone; couple of weeks work
 * Maintainer scripts should use start/stop instead of invoke-rc.d's return code
   - planned fix has been documented at a previous UDS upstart session (ask keybuk or slangasek to find this). exists somewhere on wiki.u.c (need to find)
   - no they shouldn't - slangasek
 * Stability/reproducibility in boot
   - upstream working on this during the refactor
 * Server boot process - making it admin friendly
   - plymouth takes output, upstart needs to publish meaningful output to plymouth (see upstart logging item above)
   - have plymouth listen to upstart's dbus interface, and have the details plugin report jobs being started in a traditional format
 * Status from upstart is pretty worthless; need a way for scripts to supply an arbitrary script that upstart would run after looking for the process, which can determine if the service is actually in a usable state
   * DustinKirkland has a patch to the service command that does this, but it would be ideal if Upstart supported it properly
   - post-start stanza can be made to check the service validity after the pid starts
 * Return code of start/stop/restart/status should be more indicative (Puppet, for instance, has modules for dealing with sysvinit that are totally broken by the start/stop/restart command's return codes.
 * How to programmatically disable a service


  • ColinWatson - extend plymouth to listen to upstart's dbus interface for jobs being started/stopped, and report this in details plugin

Ratings and reviews in software-center



  • Demo of Software Center client available by MichaelVogt with:

    • Star ratings,
    • Writing reviews (summary, detail and rating).
    • Reporting of reviews as innappropriate.
  • On the server-side, a review will be needed for:
    • an application
    • a version
    • a distroseries (as even the same version in different series).

Session Questions/Answers

  • Can we add a 'This was a helpful review'? Yes - needed.
  • Can the reporting of innappropriate reviews not be abused? Yes, need thought as to, for example, requiring 2 reports before it is hidden and added to the moderation queue.
  • Will reviews persist between application versions? Show reviews for the current version, but with access to reviews from previous versions.
    • A downside here is that we may lose (hide) a "valuable" review that may actually still be perfectly relevant, just because of a version bump
    • Reviews should also be sensitive to origin of the package, in case one "version" might come from different source (e.g. PPAs)
  • Languages - we need to support multiple languages. What should our defaults be? Should the server serve English reviews if there are no native language reviews? (Proposal: if there are no localized reviews yet, show a note: "Be the first to add a <language> review!")

    • If we default to English when no native-language reviews, maybe show a button to "See all language reviews"
  • Spam filtering on the server-side? Yes - we may need something. We will not linkify in comments (and may disallow links entirely).
  • Will we be able to edit/update a review after adding it. Yes, for 10mins or so (otherwise the 'Was this review helpful' is incompatible).
  • Would we be able to have special reviewers (OMG! Ubuntu!, ars technica)
  • Using Karma or CoC for moderators? Proposal: not unless we have a simplified/condensed CoC that is more relevant. URCoC - Ubuntu Reviewers Code of Conduct Smile :)

  • API for other websites to show top reviews etc.
  • Do we need licensing of the reviews? Using a default CC license?
  • Evan would like to see metrics like bug-count, crashes, install count, delta between when a bug is reported to when it is fixed (help?)
  • Initially mvo would like to limit reviews to commercial apps and distro apps, not random PPAs, but the infrastructure needs to support PPAs in the future.
  • Should vendors be able to opt-out of reviews? (perhaps restricted to commercial apps/apps where we can know who the vendor is).
  • Can we do something similar to the 'launchpad-integration plugin', adding a menu-item to an App's help menu.
  • Can Vendors/authors respond to reviews?
  • Hooks to allow an application to provide in-app review ability? Maybe from an About dialog?
  • If a user uses an application a lot, maybe pop up an invitation to review it
    • If we do this, would we end up with tens of thousands of reviews for a single app, which is not so useful?
    • What about command-line apps, such as "ls"? Smile :)

    • Pop-ups should not interrupt the user's workflow

a11y support for unity


Discussion Notes

We need to integrate Unity with the ATK/at-spi framework. This is a freedesktop technology. Becoming a widely used framework.

 Qt integration is coming via
 keyboard accessability - arrow-keys to navigate, and indication of focus
We need good keyboard navigation for Unity.

Goals / Scope

Making Unity accessible, what does it mean?

  • the panel, and the indicators that go with it
  • the launcher
  • the places (but it's more a "nice-to-have" since we can find fallbacks with nautilus & synaptics for example)

Defining the baseline, ie what does the class Gnome Desktop provide, in particular keyboard shortcuts that help in a lot of cases for making an interface accessible?


  • needs a shortcut to gain input-focus
  • should be able to navigate between entries (see nautilus-a11y as an example)
  • tell the app. name, if it's running
  • access the quicklists (SHIFT-F10), navigate in them, support keyboard shortcuts as well
  • need a means to present app info (is running, how many windows) via a11y-interface


  • CTRL-ALT-TAB takes you to the panel (gain input-focus)
  • TAB to navigate between indicator entries, or arrow keys (need to test what's usable)
  • Need to also support the shortcuts on the top entries (and the visual trigger associated with the ALT key press)

Application Switcher

  • the compiz app. switcher already is accessible

Design Aspects

Apart from keyb nav. are there other aspects of the design to adjust?

  • large fonts (UI-elements need to adapt to font-size)
  • colors?
  • way to change the icon-size of the launcher
  • on screen keyboards need to fit in somehow with the maximised windows design and work with the global menu


Will use libatk. It will isolate us from the at-spi / dbus migration.


  • Orca
  • on-screen keyboard
    • Onboard - few other distros use this
    • Caribou - brand new still in development process
    • dasher
  • screen magnifiers
    • orca & gnome-shell are working on something together

    • compiz can also provide a good screen magnifier solution

Development Plan

(also planning indications: A1, A2, etc.)

  • A1: feedback from platform on which screen readers to test unity with; also same for screen magnifiers
  • A1: provide keyboard navigation
  • A2: enable panel, indicators, launcher accessible
  • A2: connect with Mago? use Mago as a test case for how accessible we are?
  • A3: add accessibility to the places API and places view

Test Plan

  • Bug Mgmt
  • Will document a11y test plans
    • into the feature test cases directly (enable people without disabilities to test that as well)
    • report more specifically

Linaro toolchain integration in Ubuntu Natty



Maverick includes gcc-4.4 and gcc-4.5 packages based on the Linaro GCC branches. Natty will open with gcc-4.5 as default, and may include gcc-4.6.
Will this 4.6 package need to be built from Linaro GCC for compatibility? Do we want to use Linaro GCC for 4.6 even if not required? What is the timeline for delivering a Linaro GCC 4.6 release for inclusion in Natty?

  • No - gcc-4.6 not releasing until next year and it doesn't make sense to include it in natty

  • will be included as gcc-snapshot, but nothing else
  • 4.6 (trunk) hasn't been buildable for about 2 months now...


  • same upstream versions of toolchain components as default on arm vs. x86 to avoid putting all the porting burden on the ARM community
  • same upstream versions of toolchain components as default in Ubuntu vs. Debian for a similar reason, but this would be less serious than an ARM vs. x86 delta
  • gcc-4.5 packages will be available and set as default

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Follow-on to <>. Maverick includes gcc-4.4 and gcc-4.5 packages based on the Linaro GCC branches. Natty will open with gcc-4.5 as default, and may include gcc-4.6. Will this 4.6 package need to be built from Linaro GCC for compatibility? Do we want to use Linaro GCC for 4.6 even if not required? What is the timeline for delivering a Linaro GCC 4.6 release for inclusion in Natty?

  • natty has already opened with linaro branches of -4.4 and -4.5; there is no intention to change this
  • of greater concern is how and when we integrate "point-release" updates from Linaro through the release cycle
    • upstream FSF releases expected: 4.5.2 in November, 4.5.3 in February but maybe delayed by the 4.6 release (timing flakier because development has moved on)
    • Linaro intends to continue releasing its consolidation branch monthly (second Tuesday of every month)
  • review of maverick:
    • maverick opened without the Linaro toolchain
    • partway through the cycle, Linaro gcc was added which brought in not only Linaro changes, but also all the backported CodeSourcery changes. This introduced some problems which are now believed to be addressed as of the 10.10 release.

  • 4.6 compiler: will it be only performance fixes?
    • Linaro has not committed to avoiding all consumer-affecting behavior regressions
    • but likely to make this trade-off in order to be usable by Ubuntu
    • doko requests documentation, *advertisement* of these issues
    • michaelh1: goal is to improve transparency and predictability
    • doko doesn't want to make the decision now; defer to rally in January
  • doko wants same compiler on armel and x86
  • if we don't have resources to regression-test on powerpc, do we want to use the FSF gcc on powerpc to keep closer to Debian to share the load?
  • committment for other frontends besides C, C++?
    • michaelh1: generally good; Java/Fortran/ObjC not currently being worked on and no optimization work to be done this cycle, but faults in other languages will be addressed
    • work being done to import Apple ObjC improvements into FSF trunk
  • gcj doesn't currently support Thumb2 for ARM
    • not ideal, but currently we need gcj mostly for openjdk bootstrapping
  • Ada wants setzx exceptions; ARM currently only has setjmp/longjmp exceptions
    • should be tracked as a ticket/bug
  • soyuz admins vetoed last rebuild because it would stall out the ppas!
    • maybe Julian fixed this now? The last rebuild was in August


  • armel rebuild of the archive with a 4.6 compiler *before 4.6.0* in the natty release cycle
    • get fixes into natty for this where possible, or for natty+1
  • review the question of Linaro 4.6 for natty+1 at the Rally in January
  • getting a rebuild of the entire archive done
    • blocks on getting more buildds
  • test-rebuilds need to be doable more frequently and with less setup delay
    • do a rebuild of the failing builds in a ppa using the FSF gcc to check which ones are regressions
  • before switching to a new gcc version
  • and towards end of cycle when things are stabilizing

Ensure integration with drizzle for Ubuntu


  • Drizzle should be more supportable than mysql long term
  • Several upstream enhancements will be put into the final release to make it more suitable for distribution usage, such as security infrastructure enhancements.
  • As a proof of concept, we will drizzle-enable wordpress with a 'wordpress-drizzle' package.

Things to look at

  • upstart integration - upstart job file written (clint needs to commit)
  • DBUS protocol integration
    • Server admin/config
    • Desktop DB provisioning
    • Use of Drizzle as a system db?
      • Useful for Akonadi apps?
  • MySQL/Drizzle protocol situation
    • Drizzle protocol still at spec
    • MySQL is the default protocol
      • Re-add support for SSL
      • On both ports..... (3306 + 4427)
  • HandlerSocket

  • Authentication Plugins - PAM, LDAP, File
    • SSL code removed from mysql protocol, needed for security of PAM auth (upstream)
    • GRANT's Removed - Authorization plugins can be written.
      • Simple auth -- username <-> schemaname restriction

      • LDAP plugin supports full auth
    • auth_file needs Authorization support
      • management tool
    • Multi-tenancy plugin creates a sandbox per IPv6 endpoint -- PLANNED NOT IMPLEMENTED
  • Objective: drizzle as 'Recommends' alongside MySQL


  • Add SSL capability back to mysql protocol (upstream: mtaylor?)
  • Add Authorization to auth_file plugin
  • Build tool for managing auth_file plugin
  • Drizzle-ize wordpress
  • Create wordpress-drizzle package

Software selection and seed review for Edubuntu Natty

packageselection-edubuntu-n-seed-review ==== Addition to ubuntu-edu-preschool =====

  • Gamine

Addition to ubuntu-edu-primary

  • openspell [needs-packaging],
  • Laby
  • Stellarium
  • Celestia
  • geogebra
  • Lybniz

Addition to ubuntu-edu-secondary

  • pencil
  • Laby
  • Calibre
  • geogebra
  • Stellarium
  • Celestia
  • Lybniz
  • melting
  • Gally

Addition to ubuntu-edu-tertiary

  • pencil
  • Laby
  • Calibre
  • Stellarium
  • Celestia
  • geogebra
  • Lybniz
  • melting
  • Gally

Addition to dvd

  • qimo-session-gnome (mhall119)
  • sugar-session

Addition to desktop-gnome

  • pdfmod
  • ttf-sil-andika
  • scribus-ng

Addition to desktop-kde

  • pdfmod
  • ttf-sil-andika
  • scribus-ng

Event-based initramfs


Session Notes

[presentation from Surbhi - insert URL for slides here, won't repeat it all]

A few parts of the boot process are purely procedural: starting to mount the rootfs, and handling in case the rootfs is unavailable.  cryptsetup is also procedural, and its user interaction code in the initramfs predates plymouth.

appropriate for udev rules: probing
appropriate for upstart jobs: services, require supervision, logging, etc.

mountall should be usable in initramfs - there are enough filesystems being mounted that it's worthwhile

cryptsetup user interaction needs to defer ROOTDELAY
in fact, ROOTDELAY should measure a period of inactivity, so each thing that happens should reset the timer (see mountall)

casper is likely to need a complete rewrite
 * mount handling should move into mountall
 * snapshot handling would be beneficial in mountall for other reasons

add parallel directory to /usr/share/initramfs-tools/scripts ('jobs'? 'upstart'? 'init' is unfortunately already taken by a file)
start by migrating init daemon to upstart
could have transitional handling of initramfs scripts directories - mountall states correspond quite well to initramfs' phases

raid failure code in initramfs is not mirrored in the real system; this would be a benefit of harmonisation

upstart state passing:
 * most should be reasonably obvious from job and event data structures
 * biggest problem is dbus connections
 * short-term solution may be to tear down all dbus connections on re-exec, and ensure that anything that connects to upstart knows how to reconnect

networking needs attention: configure_networking can probably become a specialised upstart job

Thursday - Proceedings

PowerNAP Improvements



1. As per discussed with Dustin, a method to execute various actions to bring servers to the lowest power states without having to suspend/hibernate/power off is required. This involves using various hacks and tricks to fulfill the objectives. Examples of these hacks and tricks are: - Turn off (N-1) out of N cores. - Spin down hard drives. - Turn off hardware that's not required to be running (sound, bluetooth). - Reduce CPU frequency to the lowest possible. - etc

2. Also, as per discussed with Dustin, instead of monitoring the process table, it might also be a good idea to monitor various services, such as load in webserver, connections in databases, etc, and according to that, bring the server to the lowest power state possible.

3. Provide any other waking up methods for PowerWake, such as IPMI.

4. Given that PowerNAP is integrated in the cloud, it would be nice to improve PowerNAP in such a way that will also be used in other kind of clustered environments, or in a set of servers were traffic is monitored. For example, in a loadbalanced webserver cluster, sometimes there;s not enough traffic that will involve all the webservers to be up. PowerNAP can be extended in such a way that it will do the same that is done with UEC when servers are idled, or when the load is not too much that will involve having lots of servers running.

5. Obtain feedback from community is also desired to be able to extend PowerNAP uses.

Session Notes

  • - Open all input devices and poll/monitor activity - Look at udev for all input devices, look for id-input-key and mouse - see pm-utils fpm-powersave (Does something similar) - look at using poll(2,3) to monitor input - investigate getting kernel events on new processes (rather than polling) -- perhaps upstart? - check upstart for notification of new processes - actions should be added to pm-utils package (such as powering down cores)


  • ACTION: Talk to ScottJamesRemnant about Upstart, how PowerNap could tap into Upstart to monitor processes in an event driven manner rather than polling /proc

  • ACTION: Use pm-powersave for PowerNap new power save mode

  • ACTION: Contribute any new actions to pm-utils (rather keeping in PowerNap)

  • ACTION: Use event based monitoring for input polling (limited to keyboard and mouse)
  • ACTION: Get network monitor matching the MAC in the WoL

Hudson CI Packaging and Integration


Use cases in Ubuntu

  • All the cool guys are using it
  • Ubuntu server ISO testing:
    • based on kvm+libvirt
    • new daily -server isos are automatically tested and tests are aggregate
    • master + slave architecture
  • Ubuntu QA:
    • test the daily isos.
  • Launchpad:
    • try to get the LP test suite to run on Hudson.
  • Landscape:
    • leverage metrics and measurement provided by Hudson.
    • unable to install in the DC.
  • openstack and drizzle:
    • jcloud plugin in replacement of ec2 plugin
    • master+slave development
    • hudson plugin to track LP API: merge proposals, new packages in PPA.
  • linaro:
    • test kernels, toolchain.
  • DX
  • ISD is also using it.
  • Ubuntu One has been testing it out. With plans to make more use of it in this cycle.

Requirements from IS

  • difficulty to deploy in DC.
  • plugins: lock down. Unable to install plugins from the web interface.
  • self upgrade: turned off in the upstream package.
  • license of jar files from plugins.

Packaging Complexity

  • Existing package available from upstream. Easy for testing and deploy.
  • Summary : 106 potential hits, 56 misses (not bad)
  • Some forking of dependent libraries by hudson (15 dependencies):
    • need to get upstream input on why forked have happened.
  • Approach to plugins/upgrades:
    • disable upstream pluging/upgrade mechanism
    • Currently managed through Hudson: disable it.
    • Provide an option that can disable plugin downloads/upgrade that is not changeable from the web interface.
    • provide plugins as packages.
  • provide a slave package.
  • Create a Hudson PPA rather than targeting inclusion in the Ubuntu archive because upstream release cycle is too fast:
    • build from source:
      • injecting test suite pulls a lot of dependencies: remove from the build process and test the published binaries packages.
      • remove as much dependencies as possible:
        • package only core and relevant plugins.
    • relavant plugins:
      1. bzr plugin
      2. uec/ec2 plugin (to be replaced by jcloud plugin when it exists)
      3. git plugin
      4. ssh slave plugin
      5. url monitor plugin
      6. launchpad plugin when it exists
      7. code coverage (cobertura) plugin
    • Three packaging approaches
      • Binary packaging (probably not appropriate for Canonical IS)
      • Build from source from source from source... (probably pulls all the Java world)
        • Necessary to target main/universe
      • Build from source and binary build-only deps (might make a reasonable compromise)
        • All the binaries distributed would be "built from source"

Integration Value

  • Standalone using winstone?
    • Should be supported. Upstream help community knows about this deployment.
  • Tomcat/Jetty integration?
    • Good value adds but potentially not wide appeal. Good be provided with hudson-{tomcat,jetty} packages - see solr-* packages for examples.
  • Easing slave deployment?
    • provide a -slave package. Is the hudson slave jar built specifically by the master?
  • Build from source of PPA/binary packaging approach (or both!)


  • JamesPage

    • evaluate effort in each packaging approach
    • setup project/ppa/mailing list (users and maintainers)

How To Spy on Your Users

packageselection-desktop-n-instrumentation ==== Context ==== MIT has about 350 public Ubuntu-based workstations, and the group that maintains them was being asked how they were getting used. Machines are owned by MIT, which we felt changed the "what is acceptable spying" situation some, so grain of salt and all that.

Session Notes

Paper with analysis of ingimp data, and describing the use of clustering to make sense of log data:
(ACM Link:

Indicator Framework Changes for N



  • issues or improvements we'd like to make to the framework
  • discuss changes proposed for the indicator framework
  • gather feedback from developers and the community

==== Session Notes =====

 * Port to GTK3?
  * yes
  * we plan to switch indicators (system ones) with a "flag day" as we maintain most of them anyway

 * gdbus port
  * we're going for it
  * packages have already been patched (thanks mterry) to build with api warning flags
  * there is an issue with mouse/keyboard grabs that are used by ido but not exposed by gtk3; upstream has a patch in his review queue; we may have to distro patch for natty

Application Launchers
 * they are now shared in libindicator

 * adding a helper script to remove entries from category indicators (sound, messaging for example)

gnome-panel is going to be gtk3, so indicators have to move to gtk3

But upstreams plans to have a gtk3.2 release around january/february
=> we should do the glib/gdbus transition first, and let gtk3 stabilize a bit before doing more of the gtk3 port

Test framework

  • in indicator tools, there is a tool called indicator-loader
  • we plan to extend it to support more test cases and ease the integration with mago
  • there is a package for developers *only* to help with debugging indicators
  • adding timestamps printout to do performance testing
  • dbus-test-runner is another tool that helps test indicators, do to full integration testing, by managing both parts of the service + indicator system

Development Plan

  • A1: provide the QA team with the
  • A2: gdbus version of indicators
  • A2: gtk3 switch of indicators

Configuring a valid system hostname during install and boot


Session Notes

Code duplication netcfg/ubiquity

Since intrepid netcfg should actually put the domain in the right place if it's included in the hostname input

Process for getting hostname:
 * from dhcp by default if exists
 * from entry 
  * if there is a domain part, it is stripped out and put in the right place
/etc/hosts gets: localhost (unconditionally)
  if static:
    if domain:
      IP hostname.domain hostname
      IP hostname
    if domain: hostname.domain hostname
    else: hostname

No "_" in hostnames.

Postfix Exit Code 75 Examples:
08:19 < SpamapS> example bad hostname: from 
08:19 < udsbotu> Launchpad bug 606898 in postfix (Ubuntu) "package postfix 2.7.0-1 failed to install/upgrade: subprocess 
                 installed post-installation script returned error exit status 75" [Medium,Invalid]
08:19 < SpamapS> example bad hostname: from 
08:19 < udsbotu> Launchpad bug 606898 in postfix (Ubuntu) "package postfix 2.7.0-1 failed to install/upgrade: subprocess 
                 installed post-installation script returned error exit status 75" [Medium,Invalid]


  • [mathieu-tl] NM shouldn't write localhost.localdomain (see changelog for netcfg 1.17): TODO
  • [cjwatson] strip any trailing dot from domain: TODO
  • [lamont] make postfix cope with invalid hostname (270521): TODO

  • [clint-fewbar] Make postfix's apport hook include /var/log/installer/syslog and /var/log/installer/cdebconf/questions.dat (if present) when postinst exits with code 75: TODO
  • [cjwatson] check that ubiquity's netcfg clone is in sync: TODO
  • fix netcfg to make it possible for ubiquity to use it directly: TODO
  • line-by-line compare netcfg's hostname validation with postfix's: TODO

Resizing windows



Window borders were made very narrow. This was a design choice. Unfortunately, it has had negative repurcussions for interaction.

  • GTK+ 3.0 adds a resize grip, by default, to the corner of each toplevel GTK window that is resizable. If an application author is so inclined, an option could be added for that application to remove the grip, but it is otherwise enabled in all cases and not explicitly configurable by the user.


  • In window decorator, add invisible hit area for window borders.
    • Someone may want to click a button on a window behind and close to the edge of the focus window. However, the Resize pointer should indicate what will happen when the user clicks, the act of resizing is not destructive, and there is some ambiguity about where exactly the anchor for the pointer is. We don't believe it will be a problem in practice.
  • Window resize mode that adds large, clearly visible clickable handles to each edge of a window. The touch screen people are pondering a gesture that feels like this.
  • System-wide preference to adjust interface size and contrast. Scales font size, size of widgets (like scrollbars), and colours. May be able to replace accessibility themes.
  • Divvy for Mac OSX is an interesting tool for managing windows.


  • Make sure the new resize grip fits in current applications; doesn't interfere with anything. We should make some noise about this during the Natty cycle so people keep their eyes open and file bugs.
  • Neil: Invisible window resize area

Java Library Housekeeping


Topics for discussion:

* Agree policy on re-mediation activity in main for build from source issues (see FTBFS for spring-2.5 due to late changes in libcommons-file-upload to resolve FTBFS due to dependencies on universe.

        * Visibility of packages which are not built in the archive.
        * How do we address features which can be built but we don't want in main.
                * Policy: rename package where features are disabled.
                        * Limits impact to main.
                * Issues with version dependencies
                        * Overlay full featured package over feature disabled package.

* Agree policy on enabling unit testing in build processes
  * Contributing factors:
    * Age of packaged library and activity in upstream projects.
    * Value to build process; i.e. unit testing actually does unit testing (see asm for an example)
    * Complexity and dependencies when enabled (for example database required for c3p0 testing).
    * Part of the MIR process already
    * Policy of enabling (if we can).
    * Functionality for testing capability of 'build' environment 
        * Defer to alternative session? (lamont/doko/james-page)

* Agree approach/policy to variant libraries to support Java application packaging.

    * Good unit testing within the package would be key to enabling this approach 
    * Investigate debian policy and how this approach would deviate (if-at-all).

* Time for maven-debian-helper into main?

    * We need to anticipate (do it early in the cycle and not waiting for things to break)
    * Cost?
    * Current componemt mismatches shows when it becomes NEEDED
    * Assess when auto-import from debian has completed for Natty.
    * Policy of NOT updating Java libraries after DebianImportFreeze (unless there s a really good reason)

Natty work:

* File MIR (libportlet-spec-2.0)and revert changes to re-enable portlet API support in libcommons-file-upload, revert changes to spring in universe to re-align to debian and remove libcommons-file-upload-universe.
        * Approach: flip naming to revert universe and specialise main packaging.
* File MIR's (libxmlbeans-java, libsaxonb-java ) and revert changes to rhino to restore E4X support.
        * libxmlbeans-java -> build dependency on itself.
        * Manual build required to support.

* File MIR's (jansi, jansi-native, hawtjni) and upgrade groovy to latest debian version (1.7.4-1).
        * MIR's to be filed.

* Merge antlr3-3.2 (build dependency on Maven so potential for many MIR's).
        * New upstream version via debian.

* Merge jython2.5.1-2 (and file MIR's to support).
        * Build dependency on itself??

* "tomcat6 -> ant-trax -> ant1.7-optional -> ant1.7 MIR is needed" solution (bug 662588)
        * Was in main to move back using bug report.


  • JamesPage - Calculate cost for moving maven + debian helper to main (50-60 packages to main).

  • ttx - Submit "no updates after debianimportfreeze" policy as a discussion on ubuntu-dev
  • JamesPage - Fix the tomcat and xmlbeans issue

  • JamesPage - update Java packaging part of Ubuntu wiki/java-common to describe policy of fixing in main for feature disablement.

Thunderbird On Ubuntu




  • Netbook UI in progress (Thunderbird Air)

Gateways that work with Exchange


Talked a bit about Raindrop. Find out more about Raindrop here


  • [jcastro] User testing, research, Ubuntu One syncing of prefs.
  • [micahg] Daily builds for Thunderbird 3.2 (next), 3.3 (trunk)
  • [micahg] Make sure enigmail and lightning are available in thunderbird-stable

Bringing the Ubuntu Desktop and Netbook favors closer



There is the feeling that maintaining a UNE and a Desktop image is a lot of duplicated efforts (ISO testing, seeds maintenance) without a lot of gain. Indeed, the set of differences are really small and both are installable in parrallel. The user can choose the session on login which switch to a mode or another. In addition to that, we should note that the Desktop and UNE image are really close package-wise (just some settings and some application selection differs).

This situation even brings some drawbacks like people not really making the difference and don't know if they should install ubuntu netbook or ubuntu desktop on their computer.

This discussion aims at seeing what we can imagine to file this gap.

We can even, detecting automatically what we should launch (based on screen size?), still enabling the user to override that decision. Also, this infers that we should get the same application set, like banshee on both or stick with rhythmbox because of CD space.

Session Notes

* not a lot of changes:
∘ barely brasero/cheese
∘ right langpackage list (French on UNE) :)
-> Take cheese out because of some slowiness experienced this cycle.
-> keep brasero

One CD to rule them all!

* when to do the detection ?
-> detection on screen size
Can be done on soft by soft basis.

if banshee by default -> default to the desktop interface

run evo express on the desktop and document how to run the "normal ui".

* The main difference between the netbook and the desktop will be consequently maximized/unmaxized applications by default. When an application is maximized, the buttons will be in the panel for both.

* set of applications by default in the launcher:
  - nautilus on both cases
  - firefox
  - ubuntu one

* SoundMenu should show banshee or rhythmbox once installed, not after first registration as of today.
-> banshee icon in the soundmenu.
-> install the banshee soundmenu integration by default.

• We can maybe remove the seed? metapackage? One CD
  ∘ armel

• Transition handling (UNE/Destkop, gdm session)

Indicator Messages for N Cycle


Messaging menu discussion

  1. Have a menuitem in the menu to clear the enveloppe
  2. Want to change the color of the running-app triangle
  3. Want to add the concept of default application for a protocol/domain and bind that to
    • plan to use what gnome supports
    • check infrastructure changes (gtk3)
    • may require a UI change that mpt may propose
  4. Fix the bug where the counter where not rendered propertly depending on their types (counters vs time)
  5. Putting the counters as a label in the panel (the sum)
    • no UI requirement to enforce a "no-jiggle" default, so the indicator may move a bit when transitioning to multiple

Me menu discussion

Top-3 bugs:

  • character counter
  • network selector
  • conf. option for displaying either the login name or the fullname

Evaluate squashfs-lzma for the live CDs again



squashfs-lzma tried a couple of release sprints ago, and completely killed rsyncability - this is a blocker for switching Ubuntu to it cjwatson has synced squashfs-tools 1:4.1-1 from Debian experimental, which enables userspace mksquashfs xz (much like lzma) and lzo support apw thinks that the current kernel doesn't support lzma in squashfs (despite having the algorithm elsewhere)

Much discussion on whether we could make USB images, and to do that we would need more space in cdimage mirror. Moving the source packages to non-mirrored spot might allow that ( (Also, isohybrid, currently blocked on making this play well with jigdo, but this will probably unblock in the not so distant future.)

Could we drop the alternate cds. Those are required where we want any form of package selection, this includes the kernel. Its possible we could put d-i onto the desktop live CD, to get both forms but there is already much space issues.

It is possible we could put _uncompressed_ debs onto a squashfs containing the files extracted for almost no additional cost. This could make a shared CD. (this may break signatures)

Work Items

  • [apw] determine status of squashfs compression algorithm support in the kernel: TODO
  • experiment with current xz and lzo mksquashfs output, evaluating size and [rz]sync performance: TODO
  • determine whether this is a top-level/essential issue (somebody in platform)---if it is, resources can possibly be thrown at it.

Keyboard menu for Natty



(empty in Gobby)

Enhancing indicator-network to support NetworkManager as a backend


Session Notes

* we do not want to loose any nm-applet functionality
* using gnome3 icons? displaying multiple icons at the same time
* patch the nm-applet, instead of extending indicator-network
* rfkill daemon possibly in the future


  • [kvalo] tell cyphermox about indicator menu opened signal in indicator-network
  • [mpt] enabling in system tray in places, whitelisting it

Use LightDM for display management


What is a display manager?

  • Technical: Runs X server and user sessions
  • User: The login screen

LightDM in Ubuntu

  • Would replace GDM
  • Not proposed for natty, due to Unity changes
    • Will be in natty universe, and usable as an alternative display manager
    • Will re-propose for natty+1
  • Can be shared amongst derivatives
    • Kubuntu netbook edition?

Why change?

  • Simpler than GDM (~50,000 lines of code to ~6,000)
  • Flexible UI - can develop new greeters with no more knowledge than general application programming
  • Can be shared between desktops (like the X server is)
  • Can provide different greeters for different use cases
    • 3D greeters
    • Webkit greeters
    • Mii greeter

Requirements for the display manager

  • User authentication
  • Session starting
  • Session selection
  • Language settings
  • Accessibility
  • Automatic Login
  • Guest login(s)
  • User switching
  • Multiple displays
  • Configuration dialog
  • Consistent behaviour of audio volume and brightness between greeter and session
    • and potentially allow "system-level" volume (being separate from any other users sound settings).
  • Secure session

  • The greeter is an opportunity to welcome the user and guide them into the desktop

Desirable Features

  • Greeter->Session transitions

    • Cross-fade
    • Logo/face animation to ubuntu/me menu

Use a desktop-oriented form factor of Unity instead of GNOME Shell in the Natty Narwhal



The session was scheduled by a community member, with no prior knowledge of the decision that was announced on Monday in Mark's keynote. The session is transformed into a Q&A session on the plan and changes that are planned to adapt Unity to the desktop form factor


  • Launcher hide & reveal

  • Panel to follow the GTK theme (also to support a11y requirements)
  • Multi-monitor, as currently supported by compiz & unity

    • Post 11.04 we will try to address potential issues further
  • Nautilus will need a patch to not put icons where the overlay would be
  • Places, and Files Place in particular, UI will be adjusted
  • Nautilus Desktop with icons will be there; both on desktop and netbooks


  • A1 - Design to test a11y settings for the panel, launcher and /dash/
  • Ax - Nautilus patch to adjust for the launcher overlay case
  • A1 - Design to provide a list of changes and adjustments for the Files Place, Apps Place
  • A2 - Provide support for RTL
  • A2 - Provide support for IME

Improve User Translation Experience in Kubuntu


  • Translations experience has gotten a lot better: gone from terrible to not horrible.
  • There are fundamental problems that are difficult to solve — some are social issues rather than bugs:
    • translations continue to suck up developer time
    • some inconsistencies between how upstream and LP teams work (socially a huge issue with upstreams)
  • Developers (mostly English native speakers) don't see benefits of the current setup, only see problems. The infrastructure is fragile so some developer time is always going to be needed.
  • Sometimes Ubuntu translators change translations in a way that makes them inconsistent with the upstream KDE translations (not necessarily in incorrect way, but at least inconsistent).
  • Survey of upstream KDE to launchpad experiences interesting but would result in flame war
  • Lithuanian translations bug:, follow up in =>

Critical points

  • Frequency of updates from upstream
  • There is some intentional overriding of translations (data needed)
  • Directly notifying upstream whenever something is added (in scope for LP team)
  • Template generation process is broken

Friday - Proceedings

We Menu - Bringing Community to the Desktop


Session Notes

  • One advantage of having its own menu is project can work on it independently
  • In Natty there would be IP lookup with Geoclue so perhaps the city or other relevant info could be shown
  • Questions about adding an icon to a theme (referring to the fish icon near Vancouver in spec)
    • Not sure if this is possible (Should add "fishbowl" to theme) so icons could be added to their own theme/application indicators
  • Translation question about common/overlapping threads in app menu (iPhone debug disabled intentionally by desktop team at RC time to avoid having to look at numerous duplicate bugs?)
  • In spec where it refers to LoCo, what if there is no LoCo in area? (Default to nearest local team? Some LoCo teams are country vs. city specific. example of France vs. Vancouver)

  • Sometimes LoCo Team is referred to a Language not a country

  • FDO local collaboration protocal, has a protocol to help people find people who can help users
  • Similar to the KDE Social Desktop project (Code is open with the idea others will take this and leverage for their community.)
  • Someone should investigate the code for ""
  • there was a sessions about, make it more it local specific, someone should investigate that
  • those loco teams, they should, be careful about your location
  • can we look at where loco-directory gets data and utilize some of that?
  • the people with ubuntutheproject-community-n-ubuntudotcom-community-onramp & ubuntutheproject-community-n-webpresence are interested in pointing users to specific locos based on their location. They want to use geoip and the loco directory. This blocks on adding geolocation data to the loco directory.

  • Some items seem not to be associated with people or localities, like: "i found a bug"
    • need to be represented in the icon set to keep the association with the "people" that will help fix bugs, work on translation, etc.

UI Considerations
  • the sub-menu and large icon rows are not supported in the dbusmenu/indicator system
  • would require a custom menu item, similar to the one created by Cody Russell in the IDO library

Family & Friends menu items
  • they seem to be really close to what people would have in their Empathy contacts
  • could either be pre-configured in Empathy
  • or also reflected in the me menu (my take on family and friends is that it ties all the services into one icon, so it would pull in the resources from empathy, gwibber, blogs, etc and offer one entry point to them all)
  • Can we use the meetup APIs and other APIs and create a map of events, people, etc...? Look at a Google map layer. (meetup's API is highly attractive to local groups.)
  • how can people opt in to being discoverable by the We Menu?
  • can we make it so that you can easily follow everyone in the loco?
  • French loco discussion is on the forums
  • can we have a twitter list of all the locos, and then have a button to subscribe to all the people in your loco?
  • can we repurpose groups to make it so that it's easy to subscribe to a loco?
  • Avahi integration for conferences and stuff, can pull in people - make it so you can chat, follow, broadcast your status, etc...


  • A1 (ted) - recommend API for using the fishbowl icon (preferably without adding it to the theme)
  • rickspencer3 to start and host the application
  • rrnwexec to reach out to loco-contacts to get data (things like feeds, wiki info, etc.
  • rrnwexec to update spec and keep it fresh

Desktop Applications Selection for Natty


  • Outcome
  • Outcome
  • Outcome

DBusMenu changes for N


  • Outcome
  • Outcome
  • Outcome

Discoverability of alternate server packages


  • Rather than develop a tool, the server guide will be used as a place to direct users to alternative archives.
  • Classifications will be made to qualify each alternative archive depending on who has upload rights and the quality of its packages.
  • A review at UDS-O will be done to decide if a launchpad feature might be a good way to improve this discoverability further.


* Getting out of upstreams way when we add no value
* Ensure that message is clear under what terms this is provided under
        * i.e. where is the trust

Discussion Topics:

* Discoverability of upstream provided software for Ubuntu

* Clear messaging on the heritage of the packaging and where trust should be placed

* PPA approach
        * Associated team
                * Core Devs potentially builds trust.
* Use Cases:
        * Upstream packaging and distribution
                * Is the location of the apt repository important?
        * Distro packaging of packages unsuitable for main archive
* Not discoverability of packages, discoverability of repositories.
        * Ensure that classification of repository is included:
                * Upstream Packaged (Upstream Controlled)
                * Distro Packaged (Ubuntu Controlled)
                * Upstream Backports (Upstream Controlled)
                * Distro Backports (Ubuntu Controlled)

Package         In Archive                      Not in Archive
Upstream        e.g Zmanda                      PPA or apt archive
                No discovery                    Archive must be signed
                Detail in Server Guide          to be discoverable
                on how to raise bugs for        drizzle, hadoop
                Entry in archive is appropriate
                for production use.
Ubuntu Devs     PPA (-backports proposed)       PPA 
                -> -backports                   Discoverable
                Discoverable                    cassandra
                clamav                          Blessed: python2.6 for Hardy

Feature in Launchpad to classify PPA's automatically?
        * Visual feature on PPA front screen.
        * Ability to list upstream apt archives outside of launchpad

Review of PPA's/upstream at UDS to validate current list.

* Feature request for Launchpad if required.
        * Server guide can support < 6 month iterations
        * Review at next UDS to determine if required.
  • Process to update server guide to enable discoverability.
    • Description of classifications
    • Process to add to archive list

More stable VM solution for running armel VMs


Current situation

  • using qemu from qemu-kvm
  • many available qemu trees for arm
  • linaro is using qemu-maemo (omap) for image build

Use cases

  • user emulation
  • rootstock
  • full emulation

Linaro is planning to create an arm tree for linaro to help pushing the arm related patches upstream. Ubuntu can then generate a package for it, and use it as default.


  • better use omap 3 beagleboard as main cpu emulation, as we have a working tree for it and Nokia is using at MeeGo

Provide a Linaro image with a set of developer-oriented tools installed by default



  • There are mutually-incompatible requirements for our headless images: some users want an image that is as small as possible with a basic shell environment, some users want a GUIless image that includes a rich set of developer tools (profiling, debugging, compiling?, etc) for kernel and plumbing development.
  • The size of gdbserver is negligible; we should include it on *all* images except for those with specific size constraints (headless, alip)


  • Create a new ARM-targeted "developer" image, while keeping the existing minimal "headless" image
  • Make the developer image a strict superset of the headless image, to reduce maintenance
  • Include developer tools in the developer image:
    • gcc
    • gdb, gdbserver
    • lttng
    • oprofile
    • ltrace
    • strace
    • systemtap
    • input-utils
    • iotop
    • gator.ko, gatord
      • gatord is closed-source
    • powerdebug
    • perf tools (part of kernel package)
    • evtest - maybe input-utils already does this?
    • devmem2
    • i2c-tools
    • abrek
    • what else?
  • Drop packages from the headless image that should be moved to the developer image instead - we may do this even for packages that are not developer-oriented, but that we can do without in the minimal image as long as the developer image doesn't get too big
    • no suggestions here - instead focus on stripping out unneeded files from /usr/share
  • Impose an upper limit on the reasonable size of the developer image - what is this limit?
  • Include other useful packages in the developer image that aren't strictly developer-oriented, but are generally interesting/useful
    • an ssh server
    • a default user account
  • Packages missing from headless:
    • usb-utils
    • powertop
    • lsof
  • Make sure the kernel image configs have the right bits enabled
  • Do we need a better vi than vim-tiny? Yes Smile :)

    • or fix vim-tiny keybindings (we don't care about programming modes and such)
  • this dev image will be a base for the graphics dev image
  • rename the headless image - "base", "minimal", "small", "console"?
  • can we do mirrors? (better than reducing the size of a particular image, for those on the Pacific rim)
  • should we make it easier for users to build images themselves? (Package up the cross-debootstrap, cross-live-builder bits slangasek is working on)

Indicator Application N cycle


Session Notes

 * Review of the bugs
   - technical changes / fixes
 * signal when the menu is shown/hidden
 * scroll events will be supported as well

Dynamic icons
* we want to require that they be symbolic icons, in order to preserve the consistency of the panel
* problem: 16x16 is required for symbolic icons
* need to submit a patch that would remove this limitation
* libappindicator (or another related library) could provide an helper to help application developers; would also do the image processing to ensure consistency

Other technical changes: gdbus, gtk3, and other captured in bug reports attached to the blueprint

Issue with the fallback mechnanism (using systray) being triggered where it should not: startup, crashes, etc.
 * there is a nasty race condition that is really hard to reproduce
 * ted thinks he fixed the issue, but would like to get more testing
 * proposing to land the fix as an SRU for Maverick

Proposal to use the running-triangle indicator in the window menu

Discussion on the "service" vs "normal" application
 * questions on which applications qualify as "service" applications (like RB)
 * how to let the user know about this distinction and prevent the confusion
 * think about the difference UI elements that are part of this experience (and also part of the confusion): 
   * close button (red cross)
   * application menu on the panel
   * application launchers in the menu (sound, messaging), with the running triangle
   * icons on the launcher bar (unity), with the running triangle
   * launcher quicklist items related to the "service" nature of the application

Proposal: have a close button with a different color / shape / behavior to give hint to the user that this application is different.

Q & A

Ability for an application to display a custom icon on the panel, ie an icon that is not part of the system theme, but installed in an application specific path)?

  • ted: it's supported right now, the developer needs to provide

Action Items

  • A1 - (ted) propose the fallback fix as an SRU
  • A2 - mpt - write down guidelines on how to address the confusion around closing or quitting "service" applications (example: rythmbox)
  • A? - (desktop) - fix the 16x16 limitation in symbolic icon support (would require an rsvg patch in particular)
  • A? - (dx) provide support for dynamic icons and image processing in libappindicator


Multiarch Support for gcc, binutils, dpkg, and apt


  • Session Notes

dpkg contract likely to happen

Plan for deployment post-dpkg-landing:
 * patches available in Steve's PPA for gcc-4.5, eglibc, zlib
 * Steve has local builds of libselinux,  pam (but ugly) that should be pushed to ppa

Non self-hosting architectures (cross compilers, mingw and win32, etc)
 * not immediately on roadmap (see "Partial architectures" in MultiarchSpec)

Geoclue on the desktop


Ensure geoclue is maintainable in the distribution

  • Inspect the package
  • Configuration?
  • Consumers?
  • choose which providers to include by default

Available providers

  • geoclue-geonames
  • geoclue-gpsd
  • geoclue-gsmloc
  • geoclue-gypsy
  • geoclue-hostip
  • geoclue-localnet
  • geoclue-manual
  • geoclue-plazes
  • geoclue-skyhook
  • geoclue-yahoo
  • ubuntu-geoip

Providers to include

  • ubuntu-geoip
  • ubuntu-geonames (not done yet)


  • Perhaps avahi service so a host on a local network could advertise it provides geoip
  • Added configuration settings for the host to do the lookup
  • Package the server side script for others to use
  • NetworkManager "zones"

  • Make the server entry a list
  • experiment more with libchamplain, and consider moving it to main in natty+1
  • Zeitgeist is looking at adding location awareness to events


  • ubuntu-geoip IS scalability
  • display maps from google or osm via libchamplain
  • can osm support the traffic?


  • [ken-vandine] submit RT ticket to IS to beef up infrastructure
  • [ken-vandine] upload ubuntu-geoip
  • [ted] create ubuntu-geonames
  • [rick-rickspencer3] map display in gwibber
  • [ken-vandine] contact osm about scaling concerns
  • [magicfab] community participation to improve osm mapping

Server Natty Kolab


  • Build on the progress made in Maverick to integrate changes required in other packages to try to eliminate duplicate -kolab code copies (only cyrus-imapd is left)
  • Update Kolab packages via Debian (if possible) or directly from upstream depending on Squeeze release timing.
  • Worth with interested community members to test, document, and give feedback to upstream on Kolab/Dovecot integration.
  • A step in the goal towards having Kolab be a first class groupware solution for Ubuntu in the next LTS.


UDSProceedings/N/PackageSelectionAndSystemDefaults (last edited 2010-11-02 16:51:26 by host-84-9-86-232)