• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Notes from UDS Maverick, Belgium, May 2010

Three big requirements generally from Soyuz:

1. Support ARM
   • derived distros/archives
   • rebuilds
   • sftp uploads (in progress!)
2. Software Centre
   • API support to control private PPAs (create/remove subscriptions/tokens etc.)
   • meta-data publishing for PPAs (consider how this works with private PPAs)
   • new pocket for "coolapps"
3. Make buildd-manager more scalable and faster
   • Need more knobs to dynamically change the queue priorities and weightings
   • Need to make build uploads asynchronous
   • Change /builders so the queue length/time shows archive type so we get a better idea of priority (mainly during rebuilds)
   • Ensure branch builds are scored at ~1000

ARM

Can use the language of branches to talk about archives: the ubuntu-on-arm archive is like an integration branch for the various arm work, which will in part happen in further derived archives.

• Want an overlay archive (where versions of packages override potentially higher versions in the parent archive)
• Need control over which changes in the parent archive appear in the overlay

• Similar to the debian -> ubuntu merge process

  • runs automatically some of the time, periods where we carefully review
  • default behaviour should be to stay in sync
  • should be possible to avoid upgrades for particular packages (blacklist)

• Other archives may be derived from the derived archive itself (consider Ubuntu -> arm archive -> project-specific archive)

• Will need packageset-based ACLs and other related features of them
• Will need API tools such as "which packages are newer in archive A compared to archive B?"
• tools for syncing between archives will be paramount
• Rebuilds:
  • Binary rebuild NMUs are required, toolchain changes can happen that require recompilation and we don't want to re-upload the sources

RAW GOBBY NOTES FROM UDS

ARM

 (main ubuntu archive)
    /\
    | 
 (ubuntu-on-arm archive)
    /\
    |
 (various further archives)
 
Can use the language of branches to talk about archives: the ubuntu-on-arm
archive is like an integration branch for the various arm work, which will in 
part happen in further derived archives.

 * Want to maintain an overlay archive over the main archive
 * A bit like archive + ppa, but one sources.list entry and no pinning
   * why is this a requirement?
 * ways to specify which packages are 'part' of the archive
  * everything but ..., only ...
 * need to control over which changes from parent archive appear in our archive means "overlay" might not be the best term
 * similar to the debian -> ubuntu merge process
   * runs automatically some of the time, periods where we carefully review
   * default behaviour should be to stay in sync
   * should be possible to avoid upgrades for particular packages (blacklist)
  * will ubuntu on arm's milestones be synchronized with ubuntu's?
  * binary copy archives / source full archive
  * there will be derived archives of the ubuntu-on-arm archive
  * analagous to testing/unstable relationship?
    * quiet complex and we need to learn first if thats what we want
 * want to use same tool to maintain relationship between ubuntu and arm archives
   as between the arm archive and further-derived archives
   * unity work for example could have been done in a derived archive

 * do we start with ubuntu on arm being minimal?
   * as we may want to rebuild all binaries in the archive with a new toolchain,
     obviously not having to rebuild 16000 packages is a good thing
   * but subsetting the archive is hard beyond existing main/universe/multiverse split
   * package sets
   * if archive is incomplete, updates to ubuntu may introduce or lose a build dependency
   * something about resurrecting binaries
 * rebuild requirements relate to binNMUs
   * launchpad doesn't support binNUMs yet
   * for now we can say "don't expire binaries" for the next cycle
 * can one add new-to-ubuntu packages to ubuntu-on-arm (derivative) archive?
   * yes (well, requires policy thinking ... yes is definitly true for topic archives)
 * policy related to taking not-yet upstreamed patches
 * usual question of "how built into launchpad?"
   * a core api is "how many packages are newer in archive a than archive b"

what happens in the remote tool:
 * manual actions need to go into tools
 * automatic work goes into launchpad.
 * operations used by launchpad to get the automatic behaviour needs to be made available to the archive tool.


 * copying packages in launchpad is cheap
 * need:
   * to be able to find packages are eligible for syncing
   * need something to then every $N hours to do this syncing
   * can allow for launchpad and non-launchpad implementations of each building block

 * what about people who want to run their own archive

 * full archive vs overlay is about not having to follow your parent's timescale
   * also toolchain rebuilds

 * use cases:
   * debian->ubuntu
   * rebuild archives
   * start with these!

 * can we extend PPAs?
 * implementation-wise should we start with a special kind of ppa?
 * each archive needs a special flag in the version number to block auto-syncs (e.g. 'ubuntu' for the debian->ubuntu sync)
 * not chnaged packages have the same version that is in ubuntu
 * changed packages should not be synched

 * need secure upload queue (sftp)