Platform

UDS Intrepid Platform Report

back to the reports index page

Plans for 8.10

Place in this section bullet points of specific intended outcomes for the 8.10 development cycle.

  • Outcome
  • Outcome

Sessions

Session

19 May Round Table

CD size discussion
 list/manifest in bzr?
  deltas of individual package sizes?
  Size and Installed-Size of packages
  squashfs detects duplicates
 record of wubi version
 archive germinate output
 analyse popcon output for little-used packages
 aggressively add reasons to seeds
 use germinate warnings
  way to tell germinate about expected output, so that we can concentrate on new items

compression of sound files: GNOME uses libaudiofile which wants raw PCM data
 5.1MB of sound data in default desktop (ubuntu-sounds, pidgin, ...)
 832KB when compressed, though some are used by ALSA test code
 could also lower quality on PCM sounds

extending weather report for package-level checks
 DDPO clone?
 really-fix-it: gardening patch tags (james_w)
 fix text/* content-types in Launchpad

3G networking

need to improve approaches to testing of networking changes
 prioritise hardware, buy as necessary
 prioritise telco peculiarities
 differs by country
 variety of dial-in numbers per provider (per country)
 maemo have a list of this
 Arne has a list for Taiwan
 some telco hardware requires proprietary applications
 target countries where pervasive broadband networking is otherwise hard to obtain

network-manager 0.7 has 3g backend, uses ppp behind the scenes
profiles for different operators

structured testing via network-manager.qa.ubuntu.com (?)
 functional test plan, per-hardware and with workflow tests
 prepare the website for hardware testing. Can users that have new
  hardware add a new entr into the testplan without too much overhead?y
 Tony Espy has test plan from Pepper

 Arne: Taiwan: integrated into USB stick, modem itself is usb-serial (e.g. Huawei E220, NU MU-Q101)

 Netherlands: USB stick with weird driver (HSO; http://www.pharscape.org/component/option,com_forum/Itemid,68/page,viewforum/f,14/sid,385962821b26c5fcda08f344931d0b71/) (Option Icon 7.2); has a serial interface to "dial" and a network interface for the network traffic; might need extra N-M work

 Spain: Vodafone & Movistar developed different solutions for these usb or PCMCIA devices. Both developments are free. They are included in Guadalinex so they are Ubuntu compatible.
   * https://forge.vodafonebetavine.net/projects/vodafonemobilec/
   * http://open.movilforum.com/wiki/index.php/Escritorio_movistar  (Spanish) Contact: Jose Antonio Moujadami Urosa <joseantonio.moujadamiu

 Movistar is attempting to develop base 3G libraries: it's important that any base libraries are written in such a way that they are usable from an application such as network-manager that owns the networking stack

Education Edition: Local content filtering

Education Edition: GUI for dynamic menus

The current edubuntu-menus package installs a fixed set of menus bound to Unix groups. To maintain the menus it is currently necessary to edit the .menu files by hand. The menu group also doesn't show up in the ubuntu users and groups tool yet.

The goal of editing menus is to make structural changes to the .menu files; that is, to add or remove individual desktop files and/or categories from them. This seems very similar to the job of Alacarte, which is that of adding or removing individual desktop files and/or categories from a user's menu. The principal difference is that Alacarte edits configuration in a user's home directory, while this tool edits (initially) pre-generated configuration in /usr/share/edubuntu-menus; but this seems like essentially a matter of configuration.

  • point alacarte to the edubuntu menus .menu file
  • make sure alacarte can work without any categories
  • if alacarte can't do what we want, look for other tools that can provide the functionality
  • if nothing helps write a tool from scratch
  • the users and groups tool needs to be made aware of the edubuntu menu groups to expose them in the ui
    • the hardcoded list of exposed groups in the users-admin binary Info (!) makes this very inconvenient

    • may need to be in a separate tab, enabled or disabled automatically depending on whether the edubuntu-* groups exist

Firefox KDE integration

No integration with protocol handlers (e.g. mailto:)

  • Riddell thinks that KDE only has a small number of special cases for particular jobs (visible in Settings application):
    • e-mail client
    • embedded text editor
    • instant messenger
    • terminal emulator
    • web browser
  • otherwise KIO slave downloads object until it can figure out its MIME type

Currently, Firefox asks GNOME-VFS for the application to run for a given MIME type

Migrate Firefox to use XDG tools for MIME type queries

Would be useful to get hold of all applications that can handle a MIME type, in order to build an Applications menu

  • xdg-open uses ktradertest, but can only return the default application
    • ktradertext MIME-TYPE Application
    • ... but want list of all configured MIME types

Firefox translations were moved into the GNOME language packs to save CD space

  • about 185KB per language; may need to drop one language
  • otherwise can safely be moved
    • What about KDE users? Why do they have to install whole gnome langpack when they only need a Firefox translation? -- AzraelNightwalker 2008-05-27 15:07:16

ubufox: ships Ubuntu-specific extensions, e.g. plugin finder service, start page

  • apturl needs to be customised for KDE
  • start page needs to be customised for Kubuntu
  • tentative decision (?) to use online start page for KDE

To check for KDE session: [ "$KDE_FULL_SESSION" = true ]

Icons:

  • Firefox currently uses GTK stock icons
  • Qt widget theming support added for Firefox 4
    • would require a duplicate xulrunner build, which will be inconvenient; asac to talk with upstream about this

Boot performance

We need faster boots for various reasons: mobile, laptop, etc. It's also just generally nice.

Overview

boot process spends a lot of time in initramfs:

  • initramfs stuff written in shell -> slowish

  • probing is fast, except for some systems like mobile stuff (ogra)
  • cpu is finite, but fast
  • ram is fast, we don't care about it much
  • disk is really, really slow
  • readahead is a static list that should be regenerated often to be really useful
  • flash devices should not use readahead-->Detect type of disk.

  • readahead is up to date after a new fresh install
  • prefetch is a potential new way of doing what readahead does

Readahead problems: 1) operates on file-by-file basis 2) generating the lists is very difficult

Prefetch is kernel-level

  • works on disk blocks => more efficient

  • essentially self-updating
  • however, needs some work to be actually usable (at least for this)
  • documentation!

during boot, we're cpu bound during modprobe (via udev?). mobile is almost entirely cpu bound

  • Keybuk: udevsettle is completely pointless, udev could just be started early
  • plan to do that, is after intrepid, probably intrepid+1
  • Artir:Use bootchart to check boot time changes caused by improvements.

rc2 is highly subjective to people's configurations (but we could benchmark default install)

mobile with fixed hardware may gain a lot of boot speed by compiling drivers into the kernel

X/gdm should start earlier, but this requires dbus+hal to be started earlier

Goal 25 secs?(On Core2Duo, 1 Gb Ram p.e.). Less on QuadCore systems?

Solutions

  1. Use multithreading. Take advantage of multi-core systems.-->Detect processor.

  2. Auto regenerative readahead and grub autoprofiler.
  3. Preload&Prefetch&Grub auto-profiler by default

  4. Restructure boot order

Plan for intrepid:

  • prefetch
  • Better multithreading
  • dbus, hal moving to upstart
  • elimiante udev settle
  • stop X from stating like crazy at startup.(Kernal based modesetting)

20 May Round Table (Resource reduction: profiling tools)

Basic System

  • sysstat (iostat)
  • htop (as better readable top replacement)

C/C++

  • valgrind (memgrind, not yet mainline; doko to follow up)
  • non-static-const constant data (particularly in libraries) wastes memory
    • this is possible to detect statically with objdump

Python

  • http://guppy-pe.sourceforge.net/

    • collects and partitions objects in the heap
    • not very good at linking these back to symbol table entries
  • interpreter currently built with --enable-unicode=ucs-4
    • however ucs-2 loses ability to represent codepoints outside the BMP
  • gdb hacks to tie back into symbol table
  • bind SIGQUIT to pdb
  • del is a good way to leak memory

  • new-style objects have references to classes
    • needs debug build of Python
  • pygtk is a single import that pulls in everything
  • investigate reporting of shared writable resources used by only one process

Desktop

Colin's system monitor output (by writable memory):

  • deskbar-applet (20.2 MiB)
  • nautilus (12.2 MiB), but this includes icon cache shared over the desktop
  • tomboy (10.9 MiB)
  • gnome-settings-daemon (9.6 MiB)
  • gnome-system-monitor (7.8 MiB)
  • trackerd (5.7 MiB)
  • notification-daemon (5.0 MiB)
  • metacity (5.0 MiB)
  • mixer_applet2 (4.7 MiB)
  • nm-applet (4.0 MiB)
  • update-notifier (3.9 MiB)
  • x-session-manager (3.8 MiB)
  • fast-user-switch-applet (3.7 MiB)

Ubuntu Distributed Development - Importer

  • Aim to have all of Ubuntu, and possibly Debian imported during the
    • Intrepid cycle.
  • Use the upcoming features in bzr and launchpad to make it very quick
    • to make small changes.

Fallback option is to throw away (or better, migrate) old-phase branches to new history

rebase / tree-mapper allows more graceful migration

separate namespace for source package branches
 * also doesn't ''require'' creating upstream projects
 * to be raised further with Soyuz developers

naming scheme for branches:

official branches:

  lp:ubuntu/intrepid/glibc <- lp:ubuntu/glibc

user branches:

  lp:~cjwatson/ubuntu/intrepid/glibc/foo <- lp:~cjwatson/ubuntu/glibc/foo

Debian adoption is beneficial long-term but not immediately necessary; indeed, in the short term, multiple runs of the importer will merely create id clashes and require extra migration work - but James will import both Debian and Ubuntu at the same time, so those branches can be used by Debian developers too

dependency on performance improvements for rapid checkouts
 * shallow branches / stacked branches, in progress

Font selector

Current situation

  • fontconfig provides a low level method to configure and manipulate font settings
    • distribution wide (/etc/fonts/conf.avail/ and /etc/fonts/conf.d/)
    • system wide (/etc/fonts/local.conf) -- overrides settings in /etc/fonts/conf.d/
    • by user (~/.fonts.conf) -- overrides system wide and distribution wide settings
  • QT4 in Appearances/Fonts overwrites (?) ~/.fonts.conf when settings for anti-aliasing are changed. KDE 3 does this as well.
  • Gnome has its own way to store this configuration information -- overrides fontconfig settings in Gnome apps.
    • need to cause running applications to be updated
    • gnome-settings-daemon uses X Settings to communicate this to running applications
  • Problems we face:
    • Users have different preferences about font settings, which cannot be satisfied with a 'one configuration fits all' approach.
    • This includes:
      • Anti-aliasing on/off/embedded bitmaps for CJK
      • Hinting (autohinting on/off/binary hinting)
      • Font ordering for the meta fonts (serif, sans-serif, monospace)
      • cannot be set by locale as users use all kinds of locales to display all kinds of scripts
        • User A uses en_US and wants to use DejaVu as his default fonts and Japanese fonts for CJK text

        • User B uses en_US and wants to use a Chinese font for CJK text instead of the Japanese font.
        • User C uses zh_CN and prefers the Latin glyphs from the Chinese font
        • User D uses zh_CN and prefers the Latin glyphs from DejaVu instead of the Chinese font

    • Full implementation requires language tags for text (which many applications do not support), but a lesser implementation is possible

font-selector

  • GUI interface to manipulate fontconfig settings per user / system wide
  • uses ~/.fontselector.conf and /etc/fonts/fontselector.conf, which gets linked to /etc/fonts/conf.d/52-fontselector.conf
    • would allow ~/.fonts.conf and /etc/fonts/local.conf to override fontselector.conf settings if necessary
  • allows users to adjust the order of the available fonts for each metafont
    • can be different for different lang codes (requires applications to support XML/HTML and to define the lang= tag per paragraph)
  • allows users to manipulate font rendering based on condition checking (if/then like)

other user requests

  • manage installation/removal of font packages based on the the selected font family
  • have a preview area to see how the actual setting will look like
  • enable/disable fonts without removing them from the system
  • add custom non-packaged fonts and enable/disable them

Investigation of Intel connection manager

Notes

original plan never to replace network-manager

network-manager was unable to deal with advanced/experimental technology (e.g. WiMAX)

very ambitious plans for features, but still working on basic functionality at present

polling network hardware (scanning) will drain battery very quickly

  • Full WiMAX scan can take 10 hours!
  • deliberately does not perform automatic scanning unless the connection drops (no point)

documentation not yet completely released for legal reasons (will be merged into source code)

master git tree is private for now. moblin will be the master tree in the future (~1 month); in the meantime bug Marcel Smile :-)

Uses a number of plugins:

  • dhclient for DHCP (for now); code is wrong now for WiMAX (ARP problems due to it being IP-only, with no lower levels)
  • plan to create simple dhcp library (protocol only, no network interface handling)
  • wpa_supplicant for WPA using (broken) D-BUS interface, but wpasupplicant people are willing to fix
  • resolvconf -- Scott said it will break ubuntu's libc due patches to read /etc/resolv.conf, Marcel said it works for him... maybe coincidence.
  • private wimax plugin
  • HAL/devicekit (to allow switching reasonably easily)

Provision to store configuration/authentication system-wide, though if authentication is needed then of course it will require a UI

Will emulate network-manager's online/offline state, though not other interfaces

It will use special library for dbus: libgdbus, a thin wrapper for libdbus and glib, without gobject. It will not use GObject.

Current approach on broken drivers: no tweaks -> fix the drivers and reevaluate regularly

Timeline/Roadmap

3G:

  • basic research still needed
  • network-manager did a good job
  • modem classification went into HAL

Improve Flash experience

Current implementation detects Flash object, pops up UI, runs apturl to install selected plugin

  • blocks Firefox UI

Most web sites use Flash detection kit, implemented in JavaScript; checks whether plugin is installed

  • not currently handled

Approaches:

  1. Adobe to link to Ubuntu packages from their Flash page
  2. Detect property requests from JS from FDK

plugin finder service needs to die; can't support alternatives plugins can/should be wrapped in extensions, which adds more metadata plugins could (in principle) be added to Ubuntu add-ons list Firefox 3.1 will embed add-ons much more directly

Gnash to be packaged as an XPI upstream so that it can go on addons.mozilla.org

For Intrepid:

  • way to access Flash extension choice again
  • improve presentation in add-ons wizard

Backport free Flash packages more frequently; consider for stable updates as long as we sort out test suite coverage when run on Ubuntu

Comments:

  • Adobe has opened Flash specifications--> Better gnash/swfdec

    • Yes, we know Smile :-)

    Gnash/Swfdec by default Intrepid+1?

OpenOffice.org upload schedule

OpenOffice.org language packs

21 May Round Table (X.org in Intrepid)

  • Merging of Xorg 7.4 / xserver 1.5
    • once Mesa 7.1 is released
  • Criteria for deciding if we should merge xserver 1.6 too, if it is released in time for Intrepid
    • most likely won't be released in time
    • the proprietary drivers need time to gain support for new releases
  • LibDRM - git snapshot
    • should not break compatibility with the released version (2.3.0)
  • TTM (vs. Intel's GEM) - from libdrm
  • Kernel modesetting - matching
  • Splitting nvidia/fglrx from l-r-m
  • Input-hotplug
    • F9 uses i-h only for !keyboards
    • tablet support should be checked (wacom etc)
    • synaptics mess, upstream dead
  • Bug triaging/fixing objectives for Intrepid

Spec: xorg-intrepid

Upgrade hints (really: remove cruft after upgrades)

Post-hoc hints for cleaning up system from non-update-manager upgrades; incorporate:

  • apt-get autoremove
  • replacement of now-unsupported packages
  • cleaning up old kernels (has been pending for ages, should happen independent of the rest)
  • deborphan?
    • finds rather more packages for apt-get install users, so still useful for several people
  • deprecated dotfiles?
  • purging removed packages with configuration files
    • only unmodified conffiles (or ucf-managed files)?
      • code for this in unattended-upgrades already (mvo)
  • .dpkg-old/new files?
  • the cruft program exists (used to?)
  • random files belonging to packages that aren't removed by remove
    • (piuparts finds these)

Michael reluctant to add to update-manager UI itself; update-manager should only install packages, not remove them, otherwise people will be more reluctant to run it

Most applications of a cleanup tool are package-related

Need to add upgrade hints for certain packages moved from main to universe. Also installer changes (e.g. relatime)

Code in update-manager mostly fairly separate

Some is more difficult to perform after installation due to lack of context (e.g. no knowledge of previous state)

  • libapt could record previous state in its extended_states file

Cleanup items need to have a "no, and don't ask me again" option, which is difficult to incorporate into current update-manager design

Loose consensus to add new System -> Administration entry for this tool due to this; mvo and liw to talk with mpt

DVD live installation performance hacks

Installer would skip copying any files that matched a certain pattern.

http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.intrepid/dvd-live

Some packages would fail if certain files were missing. Possible to run dpkg -L on each package to create a blacklist, or look at /var/lib/dpkg/info/*.list if that's too slow. If a package does not have a prerm, it's safe to remove. Alternatively, we could use a whitelist.

Profiling!

  • Before doing any of this, need to confirm which parts are taking a long time
  • Calculation of removals is known to be slow
  • Instrument actual removal of individual packages to find the slowest ones

gimp-help-* has a prerm that runs install-docs -r; this appears to be safe language-pack packages appear to be safe. Might be more efficient to remove specific packages first in do_remove().

  • Discuss with mvo.

Triggerisations:

  • aspell-* should use a trigger for update-dictcommon-aspell
  • myspell-* should use a trigger for update-openoffice-dicts
  • ttf-* could possibly use a trigger for defoma-font
    • definitely need to keep defoma hint file on the file system, which means triggers are difficult since they happen after removal
    • could have each prerm write to a transient file, which is then processed by the trigger

Calculation of removal still takes a long time (1200+ packages)

  • Removing language-support-writing-* might be OK, and would remove 240+ packages
  • It is also possible that the method for calculating this removal is inefficient
    • Any inefficiencies here are likely to be in apt
    • Produce stub versions of markDelete et al that do less work, to confirm this

Instrumentation for gathering translation statistics

Problem statement

OEMs would love to have information on which languages are well-supported. As well as software-level support (information being collected elsewhere), this involves translation levels of visible parts of the desktop. Current translation statistics of main do not do a good job of representing this, because they include things like gcc error messages which are largely invisible to most users.

It would be useful to have instrumentation so that we can ask users to install a package and thereby gather information on which messages they actually see, and which ones are translated; this information can then be sent back and incorporated into the ordering presented to translators by Launchpad.

(New languages can be added by means of a request on https://answers.launchpad.net/rosetta with information on the new language.)

Design

Most software (with a few prominent exceptions such as Firefox and OpenOffice.org) uses the gettext library for translated strings, either directly in C or via bindings to languages such as Python. This can be intercepted with an LD_PRELOAD wrapper, which dumps out information (e.g. to a database or a raw file) and then calls the underlying gettext functions. A user can then install that wrapper and play with a desktop system for a while, then send the dump file to us.

Font coverage

Statistics of which Unicode codepoints are covered by which fonts, or not covered at all

Some blocks have multiple preferences or other difficulties:

  • Han characters (Chinese, Japanese, Korean Hanji)
  • Arabic (e.g. Arabic vs. Persian); some fonts only have basic support
  • Extended Latin (complex composed diacritics)
  • Indic (ligatures; components are in Unicode, but no codepoints for the combined forms)

3 statistics:

Future of i486 and i586 support

USB installation images

Targets

  • Ubuntu desktop installable USB key
  • Netbook/Classmate installation
  • Ubuntu Mobile? (much less user interaction required/desired)
  • Ubuntu alternate installable USB key
  • Ubuntu server installable USB key

Design

  • Don't want to ship (and mirror) yet another 700M blob
  • Prefer to have a tool which accepts an Ubuntu .iso as input and writes the necessary bits to a USB stick
  • Linux-only tool in first iteration, Windows later (unless volunteers materialise)
    • Write in Python, use IronPython to ship .NET object code?

    • Windows can also boot a live CD and transform to USB stick

Advantages

  • No CD waste
  • Possibility to have 1 Gb ubuntu image (300 more Mb of space)
  • No need for optical drive
  • Faster. (USB has 480 Mb per second and CD-ROM 52X has 62 Mb per second)

Notes from previous discussion (UDS-Seville)

Live/Install from USB key

  • Much faster for ISO testing
  • Avoid "CD blanks"
  • Works on machines without optical drive
  • USB key is a mass storage device (a hard drive)
    • Rather than a floppy disk

Use cases

Results

  • Modify installer to check for:
    • /ubuntu*.iso containing either a .deb local repo

      • Already done for hd-media installer (alternate-style)
    • Live Ubuntu image containing a squashfs
  • Prefer copying entire file tree to USB image
    • Simpler
    • Guaranteed to work even with 4.3GB DVD images (VFAT limit is 4.0GB)

Needs research

  • Relationship to smart-boot-manager
  • Syslinux/isolinux
    • Syslinux wrapper writes a bootsector "blob" to the front of the CD
      • opens as vfat with mtools
      • writes out ldlinux.sys
      • copies syslinux code (ldlinux.bss) into bootsector
  • We can do the equivalent under MS Windows (rawrite) provided that we ship the two files above on the CD
    • Question: can we access the raw device without Administrator privileges?
  • http://www.weethet.nl/english/hardware_bootfromusbstick.php

    • Method involving the MS Windows formatting "[x] Create start up disk".

Targets

  • Desktop CD/DVD on USB --- (direct dd > /dev/sdb); should work but believed to be buggy at the moment

  • Desktop CD/DVD on USB with local ISO --- not interesting (except for having a small bootstrap image)
  • Desktop CD/DVD on USB with persistence
  • Netboot on USB with network fetch
  • Netboot on USB with local alternate .iso

Wants

Transformation utility that takes a .iso image and it works out what to do with it

Should work for Linux and Windows, so possibly two separate applications

  • "Write to USB key?"
  • MAKE THE DESKTOPCD ON USB WORK.
    • Makes ISO testing easier
    • The place where we have less technical users.
    • Persistence?
    • ALREADY COVERED BY WUBI!
  • Casper to look for .iso and look inside for squashfs, mount boot that
    • Hunt though top-level directories
      • Modify checkdev in casper, recurse one level.
        • Already done for wubi installer.
  • Make persistency not check for partition label
  • Copy /contents/ of .iso image to vfat.
  • Copy .iso to USB stick
  • Fish vmlinuz and initrd out of .iso
  • Run syslinux
  • Make a Unix script to do this
  • Ask somebody to reimplement for MS Windows
  • Point to this from the CD download pages.
  • Provide a mini DesktopCD dd-able image of the above.

22 May Round Table (Python 3)

Archive component reorganisation

Input hotplug

* Input-hotplug

  • F9 uses i-h only for !keyboards
  • tablet support should be checked (wacom etc)
  • synaptics mess, upstream dead
  • HAL is being rewritten -> DeviceKit

Sample bugs:

  • 206649 MASTER: ubuntu does not use xinput hotplug
  • 42678 Need input-hotplug - solves Logitech MX500 mouse forward/back
    • buttons not detected
  • 57310 Need input-hotplug - horizontal scrolling and squeeze button
    • Apple Mighty Mouse does not just work
  • 107876 Need input-hotplug - Microsoft IntelliMouse Explorer 3.0 not

    • installed correctly

User-specific settings would need .fdi files in the user's homedir. This isn't available currently.

After logging in if a device is plugged in, how does the fdi files for it get put into place?

Currently, the xorg.conf sets the global xorg default. gdm currently can set a default session keyboard gconf setting the user can then specify its own keyboard to override that.

With XInput, DeviceKit has an idea of what the layout is, and a standard generic layout default ("us"). gdm can override it if a gconf key is set the user can also specify a user-specific setting.

what about kdm/xdm users? We need to put it somewhere more generic. Perhaps either taken from console-setup or in DeviceKit.

Implementationally, should we follow fedora and roll it out just for non-keyboards as phase 1, and then do keyboards as a phase 2 rollout.

We should take the input configuration settings out of dexconf as soon as possible so users won't have xorg.conf files with input settings that override input hotplug, which would prevent them from testing it in the future.

Some keyboards provide their layouts, but many do not. Is it even worth spending time on?

What about configuration of touchscreens that require calibration? For touchscreens, mayb need to do calibration at installation time (or for OEM's at image creation time). However for touchpads and connectable devices, need way to run calibration tools during runtime, not at install time.

There are a variety of calibration tools available for different devices; some don't have any tools at all. Ogra will compose a list of available tools and send to bryce.

Historically, xserver needs a CoreKeyboard and a CorePointer. If these aren't specified in xorg.conf, xserver will try to auto-find them via /dev/input and create default devices (do not want). So we need the "AllowEmptyInput" server flag set.

Spec: xorg-input-hotplug

DM-RAID support

spec on the Ubuntu Wiki

System recovery for OEMs

Initramfs performance

23 May Round Table (Ubuntu policy manual and standards)

Documents describing policy and standards are difficult to track in the wiki:

  • no changelog
  • completely lost if you return after a break
  • no upgrading-checklist.txt

https://wiki.ubuntu.com/UbuntuPackagingChanges

debian-policy is mostly appropriate except for section 3

it's important to preserve section numbers

developers-reference for workflow

Refer to UbuntuArchitecture

Policy changes:

  • Maintainer
  • python-minimal
  • Components and sections
  • Seeds
  • Upstart
  • /var/run as a tmpfs (also should go to Debian)
  • udev changes compared to debian
  • casper
  • Package versioning
  • See UbuntuPackagingChanges

  • experimental -> PPA

  • Standards-Version: should refer to the ubuntu policy?
    • Avoid frivolous Standards-Version: diffs
  • call it ubuntu-policy, keep debian-policy in archive identical to Debian's

Developer's reference:

  • Merging
  • Resources such as ubuntuwire.com and REVU
  • Language packs
  • Branding (cf. DistributionDefaultsAndBranding

  • Source-only uploads (incl. lack of binNMUs)
  • References to archive structure, admin, etc.
  • Release scheduling: perhaps external reference
  • Require upgradeability between LTS releases (policy or reference?)
    • Some kind of argument about partial upgrades

Announcement of changes:

  • including merged changes from Debian
  • diffs sent to ubuntu-devel
  • changelog (or similar) sent to ubuntu-devel-announce

Revitalise ubuntu-devel!

Lightweight process on ubuntu-devel for making changes

  • Post proposed change (description or diff)
  • If no objections, anyone else may apply diff (to avoid one-man changes)

  • If objections, discuss

Accessibility review of Ubuntu-specific desktop tools

Spec on the Ubuntu Wiki

Wubi

Possible New Features

  • d-i support (i.e. same hooks as lupin-casper)
    • initrd-preseed needs to be able to take UUID and path; possibly file-preseed as well but we really need the former
    • iso-scan needs to be able to take UUID and path
    • sync this with lupin-casper
    • lupin-casper should drop initrd-override
    • casper-premount.sh should be native to lupin-casper
  • Bootable USB device with ISO with casper-rw
  • HD-media like installation from HD (target empty partitions?)
    • Depends on fixing bugs in partman that cause partition tables to be marked dirty
    • Any partition table changes require the disk to be entirely unused during partitioning, which is infeasible in Ubiquity
      • Consider supporting this only for d-i
  • Grub2 (as recommended by bean123)
    • grub is still unsupported in Ubuntu anyway, and it won't be critical to have grub4dos unsupported too
    • we should move over eventually, but consensus is "not yet"
  • Better build scripts (nsis is available in the repositories)
  • Support for "large" distros such as Ubuntu Studio or Ubuntu Education Edition (support separate add-on CD directly? or leave it as post-installation task? shall we automate such tasks somehow?)
  • support DVD
  • Use resizable image files (LVM or simply 4GB zeroed + nGB sparse, or qcow2 type of images or images that are contiguous for the first 4GB and sparse for nGB)
  • Support for "native" installations (installation inside a folder, no loopfile)
  • "My Documents" bookmark pointing to the appropriate windows folder (migration-assistant?)
    • Evan does not want to add this to m-a. He's afraid users would get horribly confused when they removed their NTFS partition and all of their documents suddenly disappeared. Since it's specific to Wubi, Evan thinks it should be done there.

Windows frontend improvements:

  • Add bittorrent support to built-in download manager
  • Built-in CD burner (need to evaluate CD burning libraries)
  • Add "Use existing ISO" button, to use a pre-downloaded ISO (at the moment ISO and wubi.exe can be placed in the same folder, but it is not too obvious).

improvements

  • Don: use umount -l in /etc/init.d/umountfs (use a /etc flag to set the -l parameter)
    • why does /etc/init.d/umountfs not yet simply iterate in reverse order over /proc/mounts? this would be much simpler and I think more robust than the current scheme
    • this also ought to obviate the need for umount -f

UI Changes

  • Can we further simplify the interface?
  • Changes to the accessibility page
  • Do we want to have advanced options?
  • Possiblility of a frontend rewrite in python or c++ and such

Porting Wubi to other platforms

  • Could use a native installation approach (installation inside a folder, no loopfile)
    • very important that this be separated such that it imposes zero cost on most Ubuntu users
  • lubi (wubi for linux)
  • mubi (wubi for mac)

Porting Wubi To Debian

  • Requires D-I hooks.
  • Requires porting upstream all the changes to initramfs-tools, grub & co, sysvinit scripts, casper/d-i initrd hooks, lupin-support.

    • ... and almost certainly most of Ubuntu's d-i customisations! This is a large project (which should be done anyway, but will take a while and contains some elements which are likely to be contentious).
    • console-setup needs to become the default in Debian
    • localechooser encoding support needs to be fixed
  • Investigate the opportunity of a tighter integration with the win32-loader project (at the moment it does netinstallation only).

extraction tools

  • bsdtar (can extract ISO image as if it were a tar file)

Wubi to native migration

Rely on existing Ubuntu CD or USB stick; alternatively, offer to burn an existing CD or USB stick All from Ubuntu; Windows need not be involved

First stage (so that users know how to find this feature):

  • Ask the user if they have an existing ISO if they want to use. Use BitTorrent to download a new ISO if they do not.

  • Modifies a known bit on the disk to notify gfxboot-theme-ubuntu that it should show the migrate option (TBD).

Ubiquity derivative with a simpler UI; partitioning options are more restricted, and many questions need not be asked; bottom half performs some different customisations

Language, keyboard, user questions are unnecessary because all the answers are in place on the source filesystem already; migration-assistant is unnecessary

Simpler partitioner

No advanced partitioner

Autopartitioning alternatives:

  • Resize nominated partition
  • Select free space
  • Install into existing partition? -> general feature

Bottom half:

  • mount partitions and clear if necessary (i.e. normal bottom half of partman)
  • copy - potential checksumming will depend on method of copying:
  • regenerate fstab from scratch
  • menu.lst
  • install grub package and do usual grub installation
  • remove lupin-support package
  • regenerate initramfs

Notify user that they can remove Wubi from the Windows side.

Ubiquity visual refresh

Advanced mode for editing xorg.conf

  • This GUI tool will allow for adding or editing Device and Server options
  • Will be stand-alone from gnome-display-properties, but callable from it via Advanced... button
  • List of options can be parsed from the respective man page
  • tseliot has volunteered to do the development on this
  • There may be some sharing of backend xorg.conf parsing/updating code with envyng and/or jockey
  • Can be written in Python for now (can re-code in C later on if upstream is interested in having it)
  • Dialog layout was sketched out; tseliot kept a copy
  • Priorities:
    • Updating 'Virtual' option: Very high priority for Intrepid; possible backport candidate for hardy too
    • General purpose option editing: Medium priority for Intrepid, but we do want it in place by Intrepid+1.

Spec: xorg-options-editor

UDS-Intrepid/Report/Platform (last edited 2008-08-06 17:01:13 by localhost)