ArchiveAdministration

Differences between revisions 121 and 323 (spanning 202 versions)
⇤ ← Revision 121 as of 2009-05-01 18:21:02 →
Size: 41462
Editor: pool-71-114-243-118
Comment: update override command for bulk processing of source NEW imported from Debian so it actually works
← Revision 323 as of 2023-05-08 14:00:45 → ⇥
Size: 45825
Editor: seb128
Comment: update the machine reference for the copy-report job
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:
= Client-side tools =

We are transitioning towards client-side administration as the necessary facilities become available via the Launchpad API. To get hold of these [[https://code.launchpad.net/+branch/ubuntu-archive-tools|tools]]:

 {{{
$ git clone lp:ubuntu-archive-tools
}}}
Line 14: Line 22:
All administration is performed on `cocoplum.canonical.com`, accounts are provided to members of the team. Changes can only be made as the `lp_archive` user, to which you'll have `sudo` access. A few operations still require direct ssh access to `pepo.canonical.com`; accounts are provided to some members of the team. (We are [[FoundationsTeam/ReplaceArchiveAdminShellAccess|transitioning away from direct shell access]], so new team members will not get accounts here, thereby encouraging us to complete the transition more quickly.) Changes can only be made as the `lp_archive` user, to which you'll have `sudo` access.
Line 18: Line 26:
$ ssh cocoplum $ ssh pepo
Line 24: Line 32:
'''IMPORTANT:''' This document uses `$SUDO_USER` in several places. If your `cocoplum.canonical.com` uid is not that same as your Launchpad id, be sure to use your Launchpad id when running Launchpad related scripts.
Line 28: Line 34:
To work with the upload queue, you may either use the [[https://launchpad.net/ubuntu/xenial/+queue|web interface]] or the `queue` API client in `ubuntu-archive-tools`. The API client should generally be faster and more flexible; in particular, it is [[Bug:828649|not currently possible to override individual binaries using the web interface]].
Line 32: Line 40:
$ queue info
}}}

This is the `NEW` queue for `ubuntu/feisty` by default; you can change the queue with `-Q`, the distro with `-D` and the release using `-s`. To list the `UNAPPROVED` queue for `ubuntu/edgy`, for example:
 {{{
$ queue -s edgy -Q unapproved info		 $ ./queue info
}}}

This is the `NEW` queue for the development series of Ubuntu by default; you can change the queue with `-Q`, the distro with `-D` and the release using `-s`. To list the `UNAPPROVED` queue for `ubuntu/xenial`, for example:
 {{{
$ ./queue -s xenial -Q unapproved info
Line 46: Line 54:
$ queue report $ ./queue report
Line 51: Line 59:
$ queue info
 Listing ubuntu/dapper (NEW) 4/4		 $ ./queue info
 Listing ubuntu/dapper (New) 4
Line 54: Line 62:
   25324 | S- | diveintopython-zh | 5.4-0ubuntu1 | three minutes    25324 | S- | diveintopython-zh | 5.4-0ubuntu1 | 3 minutes
Line 58: Line 66:
   23635 | -B | upbackup (i386) | 0.0.1 | two days    23635 | -B | upbackup (i386) | 0.0.1 | 2 days
Line 60: Line 68:
         | * upbackup_0.0.1_i386_translations.tar.gz Format: ROSETTA_TRANSLATIONS          | * upbackup_0.0.1_i386_translations.tar.gz Format: raw-translations
Line 64: Line 72:
                                                               4/4 total                                                                4
Line 69: Line 77:
New sources need to be checked to make sure they're well packaged, the licence details are correct and permissible for us to redistribute, etc. See [[PackagingGuide/Basic#NewPackages]], [[PackagingGuide/Basic#Copyright]] and [[http://ftp-master.debian.org/REJECT-FAQ.html|Debian's Reject FAQ]]. You can fetch a package from the queue for manual checking, be sure to do this in a directory of your own:
 {{{
$ mkdir /tmp/$SUDO_USER
$ cd /tmp/$SUDO_USER

$ queue fetch 25324		 New sources need to be checked to make sure they're well packaged, the licence details are correct and permissible for us to redistribute, etc. See [[http://packaging.ubuntu.com/html/packaging-new-software.html|Packaging new software]], [[http://packaging.ubuntu.com/html/debian-dir-overview.html#the-copyright-file|debian/copyright file]] and [[http://ftp-master.debian.org/REJECT-FAQ.html|Debian's Reject FAQ]]. You can fetch a package from the queue for manual checking:
 {{{
$ ./queue fetch 25324
}}}

Or, if you just want to print the URLs so that you can fetch them on a system with a faster network connection:
 {{{
$ ./queue show-urls 25324
Line 79: Line 89:
$ queue reject 25324 $ ./queue reject 25324
Line 84: Line 94:
To alter the overrides for a source package, use:
 {{{
$ queue override -c universe source ubuntustudio-menu
}}}

Where the override can be -c <component> and/or -x <section>   To alter the overrides for a binary package, use:
 {{{
$ queue override -c universe binary ubuntustudio-menu
}}}

Where the override can be -c <component>, -x <section> and/or -p <priority>

Often a binary will be in the `NEW` queue because it is a shared library that has changed SONAME. In this case you'll probably want to check the existing overrides to make sure anything new matches. These can be found in `~/ubuntu/indices'.

Currently a special case of this are the kernel packages, which change package names with each ABI update and build many distinct binary packages in different sections. A helper tool has been written to apply overrides to the queue based on the existing packages in hardy:
 {{{
$ kernel-overrides [-s <sourcepackage>] <oldabi> <newabi>
}}}

Binary packages are not often rejected (they go into a black hole with no automatic notifications), do, check the .deb contains files, run lintian on it and file bugs when things are broken. The binaries also need to be put into universe etc as appropriate even if the source is already there.		 To alter the overrides for a package, use:
 {{{
$ ./queue override -c universe ubuntustudio-menu
}}}

Where the override can be `-c <component>`, `-x <section>`, and/or (for binary packages) `-p <priority>`. If you want to limit the override application to only source or only binary packages, use the `--source` or `--binary` option respectively.

Often a binary will be in the `NEW` queue because it is a shared library that has changed SONAME. In this case you'll probably want to check the existing overrides to make sure anything new matches. These can be found in `/ubuntu/indices` on Ubuntu mirrors.

Currently a special case of this are the kernel packages, which change package names with each ABI update and build many distinct binary packages in different sections. A helper tool has been written to apply overrides to the queue based on the packages that are currently published:
 {{{
$ ./kernel-overrides [-s <sourcepackage>] <newabi>
}}}

Binary packages are not often rejected (they go into a black hole with no automatic notifications), so, check the .deb contains files, run lintian on it and file bugs when things are broken. The binaries also need to be put into universe etc as appropriate even if the source is already there.
Line 109: Line 112:
$ queue accept 23712
}}}

In the case of language packs, add `-M` to not spam the changes lists with the new packages. You can also use ''queue accept binary-name'' which will accept it for all architectures.		 $ ./queue accept 23712
}}}

You can also use `./queue accept binary-name` which will accept it for all architectures.

== partner archive ==

The Canonical partner archive, though not part of Ubuntu proper, is managed using the same tools and queues. As such, use the same procedures when processing partner packages. E.g. (notice 'Component: partner'):

 {{{
$ ./queue -s hardy info
Listing ubuntu/hardy (New) 2
---------|----|----------------------|----------------------|---------------
 1370980 | S- | arkeia | 8.0.9-3 | 19 hours
  | * arkeia/8.0.9-3 Component: partner Section: utils
 1370964 | S- | arkeia-amd64 | 8.0.9-3 | 19 hours
  | * arkeia-amd64/8.0.9-3 Component: partner Section: utils
---------|----|----------------------|----------------------|---------------
                                                               2
}}}

Use `-A ubuntu/partner` to remove a package:
 {{{
$ ./remove-package -m "request from First Last name" -A ubuntu/partner -s precise adobe-flashplugin
}}}

The rules governing package inclusion in partner are not the same as those for the main Ubuntu archive. See ExtensionRepositoryPolicy for the Technical Board's requirements regarding the contents of add-on repositories made available through the {{{Software Sources}}} interface.
Line 118: Line 144:
Every hour or so, the difference between what the seeds expect to be true and what the archive actually believes is evaluated by the `component-mismatches` tool, and the output placed at:

 http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt		 Every 30 minutes or so, the difference between what the seeds expect to be true and what the archive actually believes is evaluated by the `component-mismatches` tool, and the output placed at:

 http://people.canonical.com/~ubuntu-archive/component-mismatches.txt

 http://people.canonical.com/~ubuntu-archive/component-mismatches.svg ([[http://people.canonical.com/~ubuntu-archive/component-mismatches.dot|dot source]])
Line 138: Line 166:
Once you've determined what overrides need to be changed, use the `change-override.py` tool to do it. Once you've determined what overrides need to be changed, use the `change-override` client-side tool to do it.
Line 142: Line 170:
$ change-override.py -c main git-email $ ./change-override -c main git-email
Line 147: Line 175:
$ change-override.py -c universe -S tspc $ ./change-override -c universe -S tspc
Line 152: Line 180:
$ change-override.py -c universe tspc $ ./change-override -c universe tspc
Line 154: Line 182:
$ change-override.py -c universe -t tspc $ ./change-override -c universe -t tspc
Line 159: Line 187:
$ change-override.py -c universe -B flite $ ./change-override -c universe -B flite
Line 166: Line 194:
Sometimes packages just need removing entirely, because they are no longer required. This can be done with:
 {{{
$ lp-remove-package.py -u $SUDO_USER -m "reason for removal" konserve		 Sometimes packages just need removing entirely, because they are no longer required. This can be done using the `remove-package` client-side tool:
 {{{
$ ./remove-package -m "reason for removal" konserve
Line 173: Line 201:
  $ lp-remove-package.py -u $SUDO_USER -m "NBS" -b konserve $ ./remove-package -m "NBS" -b konserve
Line 184: Line 212:
If you remove source packages which are in Debian, and they are not meant to ever come back, add it to the blacklist at `/srv/launchpad.net/dak/sync-blacklist.txt`, document the reason, and `bzr commit` it with an appropriate changelog. This will avoid getting the package back to source NEW in the next round of autosyncs from Debian. If you remove source packages which are in Debian, and they are not meant to ever come back, add it to the blacklist in `lp:~ubuntu-archive/+junk/sync-blacklist`, document the reason, and `bzr commit` it with an appropriate changelog. This will avoid getting the package back to source NEW in the next round of autosyncs from Debian.
Line 188: Line 216:
From time to time we should remove packages which were removed in
Debian, to avoid accumulating cruft and unmaintained packages. This
will interactively go through the removals and ask for confirmation:

 {{{
$ cd ~/syncs/
$ update-sources
$ process-removals		 From time to time we should remove packages which were removed in Debian, to avoid accumulating cruft and unmaintained packages. This client-side tool (from `ubuntu-archive-tools`) will interactively go through the removals and ask for confirmation:

 {{{
$ ./process-removals
Line 202: Line 226:
== Failed SRUs ==

If a package should be removed from -proposed, use the ```remove-package``` tool (from `ubuntu-archive-tools`). e.g., to remove source and binaries for the ```libreoffice``` package currently in xenial-proposed:

 {{{
$ ./remove-package -m "SRU abandoned (verification-failed)" -s xenial-proposed libreoffice
}}}
Line 204: Line 236:
Syncing packages with Debian is a reasonably common request, and currently annoyingly complicated to do. The tools help you prepare an upload, which you'll still need to check and put into incoming. The following recipe takes away some of the pain:

First go to LP to see the [[https://launchpad.net/~ubuntu-archive/+subscribedbugs?field.searchtext=sync&orderby=targetname|list of current sync requests]]

Review the bugs, and make sure that the sync request is ACK'd (or requested by) someone with MOTU or core-dev privileges. If past FeatureFreeze, check the changelog to make sure the new version has only bug fixes and not new features.

If there are pending sync requests, change into the `~/syncs` directory and make sure the Debian sources lists are up to date:
 {{{
lp_archive@...$ cd ~/syncs
lp_archive@...$ update-sources
}}}

Now prepare the source packages to be uploaded:
 {{{
lp_archive@...$ sync-source.py -b LPUID srcpkg
}}}

Replace `LPUID` with the Launchpad username of the sync requester, or the acknowledger if the requester is not an active developer, and `srcpkg` with the names of the sources they asked for.

This will fail if there are any Ubuntu changes, make sure they've asked to override them, and use `-f` to override them, e.g.
 {{{
lp_archive@...$ sync-source.py -b LPUID -f dpkg
}}}

If the source comes from a non-standard component, such as 'contrib', you might need:
 {{{
lp_archive@...$ sync-source.py -b LPUID -C contrib srcpkg
}}}

You'll now have a bunch of source packages in the `~/syncs` directory of the `lp_archive` user which need uploading. To do that, just run

 {{{
flush-syncs
}}}

To sync all the updates available in Debian

 {{{
sync-source.py -a
NOMAILS=-M flush-syncs
}}}

This does not import new packages from Debian that were not previously present in Ubuntu. To get a list of new packages available for sync, use the command
 {{{
new-source [contrib|non-free]
 }}}

which gives a list of packages that can be fed into `sync-source.py` on the commandline after review

To sync from Debian incoming wget the sources,
 {{{
apt-ftparchive sources ./ > Debian_incoming_main_Sources
sync-source.py -S incoming <package>
}}}

Backports work much the same way; the tool is `backport-source` and it should be run in `~/backports`. There's also a `flush-backports` tool that works the same way as `flush-syncs` above. Backports do not require any Sources files. Note that backporting packages which did not exist in the previous version will end up in NEW which defaults to main, so universe packages need to have that override set.

Backports should reference the Launchpad username of the backporter who approved the backport, not the user requesting the backport.		 Syncing packages with Debian used to be a reasonably common request. It is now self-service for developers using `syncpackage`. If you are asked to process a sync in the old style, you can use the `-s` option to `syncpackage` to do so in the name of the requester.

Most updates available in Debian are automatically synced before DebianImportFreeze, but packages that were previously in Ubuntu will not be automatically reintroduced. To process these interactively:
 {{{
$ ./auto-sync --new-only
}}}

To sync from any source which is not automatically imported by Launchpad, use the `syncpackage` tool on a `.dsc` file. Any uploader can do this; it does not require being an archive administrator.

Likewise, backports are now self-service for members of [[https://launchpad.net/~ubuntu-backporters|ubuntu-backporters]] using `backportpackage`.

= NBS =

Sometimes binary packages are not built by any source (NBS) any more. This usually happens with library SONAME changes, package renamings, etc. Those need to be removed from the archive from time to time, and right before a release, to ensure that the entire archive can be rebuilt by current sources.

Such packages are detected by `archive-cruft-check`. This tool does not check for reverse dependencies, though, so you should use `checkrdepends -b` for checking if it is safe to actually remove NBS packages from the archive.

Look at the [[http://people.canonical.com/~ubuntu-archive/nbs.html|half-hourly generated NBS report]] which shows all NBS packages, their reverse dependencies, and a copy-and-paste-able command to clean up the "safe" ones.

The rest needs to be taken care of by developers, by doing transition uploads for library SONAME changes, updating build dependencies, etc. The remaining files will list all the packages which still need the package in question.

Please refrain from removing NBS kernel packages for old ABIs until debian-installer and the seeds have been updated, otherwise daily builds of alternate and server CDs will be made uninstallable.

= i386 whitelist updates =

The i386 is a partial archive now, details on https://wiki.ubuntu.com/i386

To add packages to the whilelist

 * Update the update-i386-whitelist script from u-a-t (typically adding a newSet.update(['$package']) entry
 * run the script
 * trigger the i386 build either by doing an upload or by copying the package over itself (copy-package -b --force-same-destination -e $version $pkg )

the copy should trigger a build on i386, once it's published

 * remove the entry from the update-i386-whitelist script
 * if the new item isn't pulled in as a build-/dependencies manually add it to https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/i386/
  * if a source package builds multiple binary packages, and a binary package other than the one pulled into the seed has dependencies that are not otherwise included, then this binary package will also need to be seeded in order to ensure dependency availability.

= Adjusting Launchpad ACLs =

'''NOTE''': due to [[https://bugs.launchpad.net/soyuz/+bug/562451|bug #562451]], archive administrators cannot currently adjust Launchpad ACLs.

The new ArchiveReorganisation brings finer grained access controls than what components can provide. Launchpad ACLs allow individuals and teams to have upload or admin rights on certain packages, referred to as sets. In general, an archive administrator can process requests to create and delete package sets, as well as add or remove packages from package sets. Archive administrators should not add individuals or teams to package sets without explicit TechnicalBoard approval.

== Package sets ==
Packages can be added to or removed from package sets using the ```edit-acl``` tool from `ubuntu-archive-tools`.

To list the packages currently in the package set ```mozilla```:
 {{{
$ ./edit-acl query -P mozilla -S zesty
adblock-plus
all-in-one-sidebar
bindwood
...
}}}

To add a package to the ```mozilla``` package set:
 {{{
$ ./edit-acl -P mozilla -S zesty -s foo -s bar -s baz add
}}}

To remove a package from the ```mozilla``` package set:
 {{{
$ ./edit-acl -P mozilla -S zesty -s foo delete
}}}

For more information, please see ```edit-acl --help```.

= Raw UEFI uploads =
Launchpad supports autosigning of EFI binaries using the Secure Boot signature format. This is implemented using a "raw uefi" format upload within a binary package build (see the efilinux package in quantal or later for an example). To provide additional assurance that only trusted EFI bootloaders are signed using this method, packages that include raw UEFI binary uploads land in the unapproved queue and require archive admin approval before they are signed. Archive admins should review the corresponding source upload for correctness prior to approving these uploads.
Line 269: Line 314:
`madison-lite` (aliased to `m`) examines the current state of the archive for a given binary/source package:
 {{{
$ madison-lite dpkg		 `rmadison` (in the `devscripts` package, run on your client system) examines the current state of the archive for a given binary/source package:
 {{{
$ rmadison dpkg
Line 280: Line 325:
$ madison-lite dselect $ rmadison dselect
Line 292: Line 337:
$ madison-lite -S dpkg $ rmadison -S dpkg
Line 323: Line 368:
$ checkrdepends -b nm-applet dapper $ checkrdepends -s zesty -b nm-applet
Line 328: Line 373:
$ checkrdepends network-manager dapper $ checkrdepends -s zesty network-manager
Line 335: Line 380:
 * There are often duplicate source NEWs in the queue if the auto-syncer run twice in a row without clearing the imported sources from NEW. These can be weeded out with:

 {{{
 new-remove-duplicates > /tmp/$SUDO_USER/cmds
sh /tmp/$SUDO_USER/cmds }}}

 (Please eyeball `cmds` before feeding it to the queue).

 * `new-binary-debian-universe` creates queue commands for overriding and accepting all binary NEW packages whose source was imported from Debian and is in universe. While it runs, it `lintian`s all the imported .debs. Watch the output and note all particularly worrisome issues (ignore the 'is not a shared library' errors for amd64 debs, that's a bug with the local lintian installation). Check the `cmds` file for obvious errors, and when you are happy, execute it with `sh cmds`.

 Warning: This command will fail when there are duplicates in the queue. Clean them up with `new-remove-duplicates` first.
 {{{
 new-binary-debian-universe > /tmp/$SUDO_USER/cmds
vi /tmp/$SUDO_USER/cmds
sh /tmp/$SUDO_USER/cmds }}}

 * For bulk processing of source NEW imported from Debian you should do something like:

 {{{
 cd /tmp/$SUDO_USER/
q fetch
for i in `ls *_source.changes| grep -v ubuntu`; do grep -q 'Changed-By: Ubuntu Archive Auto-Sync' $i || continue; egrep -q ' (contrib|non-free)' $i && continue ; echo "override source -c universe ${i%%_*}"; echo "accept ${i%%_*}"; done > cmds }}}

 Then go over the cmds list, verify on http://packages.qa.debian.org that all the packages mentioned are indeed in Debian main (and not in non-free, for example), and again feed it to the queue with `q -e -f cmds`.		  * The first thing you need to handle are native syncs. These are syncs performed via URLs like https://launchpad.net/ubuntu/zesty/+localpackagediffs or via the LP API. You can recognize these in the LP queue pages because they have '(sync)' in the name. In `queue info`, they show up as 'X-' (as opposed to 'S-' like normal source uploads). There are no changes files for these, so they cannot currently be fetched via `queue fetch`. To verify a native sync:
  0. Download the source package from Debian (eg, via `dget` or `apt-get source <pkg>=<version>`)
  0. Download the imported dsc file from the Debian project in LP (eg https://launchpad.net/debian/sid/+source/pxe-kexec)
  0. Compare the dsc file from Debian and from LP. Since both should be signed, if they are identical, then you know the package hasn't been tampered with. I can also compare the full source package from Debian and LP if desired.
 Once verified, accept it normally via LP or `./queue accept <srcpkg>`.

 * `./new-binary-debian-universe` accepts all binary NEW packages whose source was imported from Debian and is in universe. With the `--lintian` option, it runs `lintian` over all the imported .debs while it runs, so you can watch the output and note all particularly worrisome issues. When you are happy, say yes at each confirmation prompt.
Line 364: Line 392:
=== Standard case ===
Packages in -proposed can be moved to -updates once they are approved by someone from sru-verification, and have passed the minimum aging period of '''7 days'''.

 {{{
copy-package.py -vbs feisty-proposed --to-suite=feisty-updates kdebase
}}}

=== Special case: DDTP updates ===

 1. Disable publisher cron job and wait until it finished. It must not run during the copy operation.
 1. Copy
 `/srv/launchpad.net/ubuntu-archive/ubuntu/dists/`''release''`-proposed/`''component''`i18n/*` to the corresponding -updates directory, for all relevant components. This needs to happen as user `lp_publish`.
 1. Reenable publisher cron job.

=== Resources ===
 * [[http://people.ubuntu.com/~ubuntu-archive/pending-sru.html|Currently pending SRUs]]
 * Verified bugs for [[https://bugs.launchpad.net/ubuntu/intrepid/+bugs?field.tag=verification-done|intrepid]], [[https://bugs.launchpad.net/ubuntu/hardy/+bugs?field.tag=verification-done|hardy]], [[https://bugs.launchpad.net/ubuntu/gutsy/+bugs?field.tag=verification-done|gutsy]], [[https://bugs.launchpad.net/ubuntu/dapper/+bugs?field.tag=verification-done|dapper]]		 Packages in -proposed can be moved to -updates once they are approved by someone from sru-verification, and have passed the minimum aging period of '''7 days'''. Use the `sru-release` script from `ubuntu-archive-tools` for this:
 {{{
$ ./sru-release xenial kdebase
}}}

Please see `--help`, you can also use this tool to copy packages to `-security` and to the current development release. N.B. before copying a package to `-security` ping a member of the [[https://launchpad.net/~ubuntu-security/+members|ubuntu-security]] team.

 * [[http://people.canonical.com/~ubuntu-archive/pending-sru.html|Currently pending SRUs]]
Line 384: Line 403:
/!\ Note that this action, unlike most archive actions, requires you to be logged in as the `lp_publish` user (and currently only on germanium).

Security uploads in Soyuz are first built, published, and tested in the Security Team's private PPA. To unembargo them, we use a tool that re-publishes them to the primary archive. Note that this should never be done without an explicit request from a member of the Security Team.

To publish `nasm` from the `ubuntu-security` PPA to the `-security` pocket of `ubuntu`'s `hardy` release, you would do the following:

 {{{
LPCONFIG=production /srv/launchpad.net/codelines/ppa/scripts/ftpmaster-tools/unembargo-package.py -p ubuntu-security -d ubuntu -s hardy-security nasm
}}}

== Publishing mozilla security uploads from the ubuntu-mozilla-security public PPA ==
Mozilla (ie, firefox and thunderbird) security uploads in Soyuz are first built, published, and tested in the Mozilla Security Team's public PPA. To publish them into the main archive, use copy-package.py. Note that this should never be done without an explicit request from a member of the Ubuntu Security Team (Mozilla Security Team is not enough).

To publish `firefox-3.0` version `3.0.7+nobinonly-0ubuntu0.8.04.1` from the `ubuntu-mozilla-security` PPA to the `-security` pocket of `ubuntu`'s `hardy` release, you would do the following:
 {{{
copy-package.py -b --ppa=ubuntu-mozilla-security -s hardy --to-suite hardy-security -e 3.0.7+nobinonly-0ubuntu0.8.04.1 firefox-3.0
security-firefox-overrides -S hardy-security
}}}

The `security-firefox-overrides` script needs to be run because copying a package from a PPA to the `ubuntu` archive puts all the binaries into main.		 Security uploads in Soyuz are first built, published, and tested in the Security Team's private PPA. To unembargo them, the security team use a tool that re-publishes them to the primary archive. This is now [[SecurityTeam/UpdatePublication|self-service]], although you may occasionally be asked to adjust overrides, which can be done in the usual way.

== Publishing packages from the ubuntu-mozilla-security public PPA ==

Mozilla (ie, firefox and thunderbird) uploads in Soyuz are first built, published, and tested in the Mozilla Security Team's public PPA. To publish them into the main archive, use `copy-package` from `ubuntu-archive-tools`. Note that pocket copies to the security pocket should never be done without an explicit request from a member of the Ubuntu Security Team (Mozilla Security Team is not enough), and copies to the proposed pocket should not be done without an explicit request from a member of the SRU Team. Keep in mind that `firefox` 2.0 and later (ie `hardy` and later) will always have a corresponding `xulrunner` package that needs copying.

To publish `firefox` version `22.0+build2-0ubuntu0.12.04.2` from the `ubuntu-mozilla-security` PPA to the `-security` pocket of `ubuntu`'s `precise` release, you would do the following:
 {{{
$ ./copy-package -b --from=~ubuntu-mozilla-security/ubuntu/ppa -s precise --to=ubuntu --to-suite precise-security -e 22.0+build2-0ubuntu0.12.04.2 firefox
}}}

Alternatively, can use `lp:ubuntu-qa-tools/security-tools/unembargo` like so:
 {{{
$ unembargo --ppa=ubuntu-mozilla-security -r xenial --pocket=proposed chromium-browser
}}}

== Publishing packages from the ubuntu-security-proposed public PPA to proposed ==
This works the same as the `ubuntu-mozilla-security` PPA, above. Eg, using `lp:ubuntu-qa-tools/security-tools/unembargo`:
 {{{
$ unembargo --ppa=ubuntu-security-proposed -r xenial --pocket=proposed gnupg
}}}

== Copying PPA kernels to proposed ==
With the new [[Kernel/StableReleaseCadence|StableReleaseCadence]], kernels are built in the [[https://launchpad.net/~canonical-kernel-team/+archive/ppa|kernel team PPA]] and then pocket copied to the proposed pocket in the main archive once they are ACKd.

The two most useful URLs for this process are the [[http://status.qa.ubuntu.com/reports/kernel-bugs/reports/sru-report.html|Kernel SRU Report]], where you will find links to the tracking bugs (the magnifying glasses), as well as the status of each package in each release, and the [[Kernel/kernel-sru-workflow|Kernel SRU workflow]], which outlines in fine detail how each bug task should be handled, what the states mean, etc. The executive summary of the previous link is "only operate on tasks assigned to your team, and only when they're in the Comfirmed state, and when you do, please reassign to yourself and set the task to Fix Released when you're done".

The [[http://people.canonical.com/~ubuntu-archive/pending-sru.html#kernelppa|Pending SRU report]] has a section for the kernel PPA which shows all newer kernels in the PPA, provides clickable links to open all bugs (with separate CVE bugs), and copy&pasteable `copy-proposed-kernel` and `sru-accept` commands (both in `ubuntu-archive-tools`).
To publish `linux` version `2.6.32-27.49` from the `canonical-kernel-team` PPA to the `-proposed` pocket of `ubuntu`'s `lucid` release, you would do the following:

 * Click on the "open bugs" button and check that the bugs are in a reasonable state, i. e. they target the right source package (`linux` vs. `linux-ec2` etc.), are fixed in the development release (or at least upstream), and that the changes are limited to bug fixes, and are in general within the boundaries of the StableReleaseUpdates policy. They should ideally have a task for the stable release the SRU targets. Note that this button does not open CVE bugs, as they don't get verification or other tracking (there is a separate button for opening them, if desired).

 * Find the tracking bug by either traversing through the list of bugs, or opening the .changes file and looking at the top (the release bug is pointed out there). Ensure that there is a proper stable task, and that the main (development release) task is invalid.

 * Run the `copy-proposed-kernel` command to copy it to -proposed. Once the kernels are copied to proposed and accepted, update the bug to close the Promote-to-proposed task and assign it to yourself.

 However, with some flavours like -ec2 or armel kernels, which are mostly just a merge with the main `linux` kernel, it is too much overhead to add -ec2 tasks to all the bugs.

 * Due to current limitations of Launchpad, new packages copied from a PPA into the archive sometimes go to 'universe'. As a result, please '''verify the overrides for all packages''' copied to -proposed, otherwise these packages might become uninstallable when they are ultimately copied to -updates/-security. ```find-bin-overrides``` from lp:ubuntu-qa-tools can help with this. You use it like so: `find-bin-overrides <pocket to compare to> <target pocket> <ubuntu release> <source package>=<version in pocket to compare to>,<old abi>,<new abi>`. Eg, suppose there is a new kernel in hardy-proposed with a new ABI of 2.6.24-30 and you want to get a list of overrides for the new kernel based on the old ABI of 2.6.24-16 in the 2.6.24.12-16.34 version from the release pocket of hardy. For the `linux-restricted-modules-2.6.24 source package`, you might use:
 {{{
$ find-bin-overrides release proposed hardy \
linux-restricted-modules-2.6.24=2.6.24.12-16.34,2.6.24-16,2.6.24-30
# hardy/linux-restricted-modules-2.6.24
./change-override -c multiverse -s hardy-proposed fglrx-kernel-source ...
./change-override -c restricted -s hardy-proposed avm-fritz-firmware-2.6.24-30 ...
}}}
 For the `linux` source package, you might use:
 {{{
$ find-bin-overrides release proposed hardy linux=2.6.24-16.30,2.6.24-16,2.6.24-30
# hardy/linux
...
}}}
 You may also specify `--show-main` to also show the the change-override command to move things to main. This can be useful if you know the overrides are very wrong. See `find-bin-overrides -h` for details.

'''TODO:''' A process/script similar to `kernel-overrides` should be developed to make sure overrides are properly handled for binaries not in main. Is ```find-bin-overrides``` from lp:ubuntu-qa-tools good enough?
Line 415: Line 469:
{{{
$ copy-report		  {{{
$ ./copy-report
Line 420: Line 474:
copy-package.py -y -b -s feisty-security --to-suite feisty-updates -e 8.3.5-6ubuntu2.1 tk8.3
copy-package.py -y -b -s feisty-security --to-suite feisty-updates -e 8.4.14-0ubuntu2.1 tk8.4
}}}

The block of output under "The following packages can be copied safely:" may be copied and pasted in its entirety. If there is a block headed "The following packages need to be merged by hand:", then make sure that the security team is aware of those cases.

== Syncs with syncbugbot ==

=== Purpose ===
If you process a long list of sync requests from Launchpad bugs, using
`sync-source.py` manually is tedious. To automate this, there is a
script `syncbugbot` which does the following:

 * Take a list of sync request bug # and additional sync options as input.
 * For each sync request bug:
  * get the source package name and requestor from Launchpad
  * Call `sync-source.py` with the requestor and source package name and all additional sync options from the input file
  * On success, close the bug with the output of `sync-source.py`.

Note that this currently ''only'' works for sync request bugs which have a package. In particular, it does not work for syncing packages which are not yet in Ubuntu, because the bug task will be against "Ubuntu" and syncbugbot cannot figure out the package name. This limitation might be addressed in an improved version of syncbugbot.

=== Steps ===

 * Open the [[https://launchpad.net/~ubuntu-archive/+subscribedbugs?field.searchtext=sync&orderby=targetname|list of current sync requests]] in browser.
 * Starting from the first bug which is associated to a package (see limitation above), use ctrl+mouse marking to select the column with the bug numbers. Paste them into a text file, let's call it `syncs.txt`.
 * `syncs.txt` is the input to syncbugbot and must contain one line per sync request bug, with the bug number being leftmost. Everything after the bug number are extra options to `sync-source.py` which get passed to it unmodified.
 * Now open all the sync requests (in browser tabs) and walk through them:
  * Delete bug # from `syncs.txt` which are not approved or invalid. Set those to "Incomplete" in Launchpad, and provide necessary followup.
  * Use `rmadison -u debian` to verify the component to sync from (often, requestors get it wrong, or `unstable` got a newer version than `experimental` since the sync request was made)
  * Add appropriate sync options, e. g. if package has Ubuntu changes or needs to be synced from exerimental.
 * Copy file to `cocoplum` and run it:

 {{{
  cd ~/syncs
  update-sources
  syncbugbot < /tmp/syncs.txt
  flush-syncs
 }}}

 If you are not an archive admin with shell access to `cocoplum`, hand the file to someone who has.

=== sync-source.py options ===

The most common options are:

 || '''Option''' || '''Description''' || '''Default''' ||
 || `-f`, `--force` || Overwrite Ubuntu changes || abort if Ubuntu package has modifications ||
 || `-S` ''suite'' || Sync from particular suite (distrorelease), e. g. `experimental` || `unstable` ||
 || `-C` ''component'' || Sync from particular component, e. g. `non-free` || `main` ||

== Backports with syncbugbot ==

Since backports are very similar to syncs, `syncbugbot` can also be
used to do those. It needs to get the source package name passed,
though, since backport requests are not filed against source
packages, but against ''release''`-backports` products.

=== Steps ===

 * Open the [[https://launchpad.net/hardy-backports/+bugs?field.status%3Alist=In+Progress|list of current backport requests]] for a particular release (this URL is for hardy) in browser. Note that this URL only lists bugs being "in progress", since that's what the backporters team will set when approving backports.
 * Use ctrl+mouse marking to select the column with the bug numbers. Paste them into a text file, let's call it `backports-hardy.txt`.
 * `backports-hardy.txt` is the input to syncbugbot and must contain one line per backport request bug, with the bug number being leftmost and the source package name being second. Everything after the bug number are extra options to `backport-source.py` which get passed to it unmodified.'''Do not mix backports for different target releases in one file.'''
 * Now open all the backport requests (in browser tabs) and walk through them:
  * Delete bug # from `backport.txt` which are invalid. Set those to "Incomplete" in Launchpad, and provide necessary followup.
  * Check with `rmadison` if the current version is still the same that was approved and tested. If there is a newer one, set back to "Incomplete" and mention the newer version.
  * If a backport requires an actual upload due to source changes, these need to be approved differently. Remove the bug from `backports-hardy.txt`, but do not change the bug report.
  * Add appropriate backport options to `backports-hardy.txt`, e. g. if package should not be backported from the current development release.
 * Copy file to `cocoplum` and run it:

 {{{
  cd ~/backports
  syncbugbot --backport=hardy < /tmp/backports-hardy.txt
  flush-backports
 }}}

 If you are not an archive admin with shell access to `cocoplum`, hand the file to someone who has.

=== backport-source.py options ===

The most common options are:

 || '''Option''' || '''Description''' || '''Default''' ||
 || `-S` ''suite'' || Backport from particular suite (distrorelease), e. g. `intrepid` || current development release ||

=== Example input file ===
{{{
12345 lintian
23456 frozen-bubble -S intrepid		 copy-package -y -b -s feisty-security --to-suite feisty-updates -e 8.3.5-6ubuntu2.1 tk8.3
copy-package -y -b -s feisty-security --to-suite feisty-updates -e 8.4.14-0ubuntu2.1 tk8.4
}}}

The block of output under "The following packages can be copied safely:" may be copied and pasted in its entirety (or run `copy-report --safe`). If there is a block headed "The following packages need to be merged by hand:", then make sure that the security team is aware of those cases.

Note that `copy-report --safe` is run from a cron job as the `ubuntu-archive` user on `ubuntu-archive-toolbox`, and so does not typically need to be run by hand.

== Other copies ==

`copy-package` is a versatile tool and can be used for a number of other purposes. If you are doing something not documented here, please ask on `#ubuntu-release` first.

Archive administrators technically (as in, per the ACLs) have the ability to copy into the `RELEASE` pocket of the current development series. Please do not do this; that pocket is owned by the [[http://people.canonical.com/~ubuntu-archive/proposed-migration/|proposed-migration]] tools, and those tools have built-in override facilities for the cases where they are wrong. The release team has [[https://code.launchpad.net/~ubuntu-release/britney/hints-ubuntu|access]] to apply such overrides when needed.

== Handling updates to partner ==
Updates to the partner archive follow a similar process as packages in the Ubuntu archive. Specifically, packages are first built in the proposed pocket, then they need to be copied to the release pocket after they are built and then cleaned up from the proposed pocket. The process is (examples show adobe-flashplugin being updated for xenial):
 0. Review the package in the "unapproved" queue, and if appropriate, accept the package into partner for the proposed pocket (in this example, proposed for xenial)
 0. When the package builds on all architectures, copy it to the partner release pocket (this makes it available to users). Eg:
 {{{
$ ./copy-package -b --auto-approve --from=ubuntu/partner -s xenial-proposed --to-suite xenial adobe-flashplugin
}}}
 or to do all at once:{{{
$ for i in xenial bionic focal groovy; do ./copy-package -b --auto-approve --from=ubuntu/partner -s $i-proposed --to-suite $i adobe-flashplugin ; done
}}}
 0. Remove the package from proposed in the partner archive. Eg:
 {{{
$ ./remove-package -A ubuntu/partner -m "copied to release" -s xenial-proposed adobe-flashplugin
}}}
 or to do all at once:{{{
$ for i in xenial bionic focal groovy; do ./remove-package -A ubuntu/partner -m "copied to release" -s $i-proposed adobe-flashplugin ; done
Line 517: Line 514:
This can be done with the
[[http://bazaar.launchpad.net/%7Eubuntu-archive/ubuntu-archive-tools/trunk/annotate/head%3A/queuediff|queuediff]]
tool in
[[https://code.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/|lp:~ubuntu-archive/ubuntu-archive-tools/trunk]],
which generates a debdiff between the current version in the archive, and the		 This can be done with the `queuediff` tool in `ubuntu-archive-tools`, which
generates a debdiff between the current version in the archive, and the
Line 524: Line 518:
{{{
$ queue-diff -s hardy-updates hal
$ queue-diff -b human-icon-theme | view -		  {{{
$ ./queuediff -s hardy-updates hal
$ ./queuediff -b human-icon-theme | view -
Line 547: Line 541:
== Cleaning up NBS ==

Sometimes binary packages are not built by any source (NBS) any more. This usually happens with library SONAME changes, package renamings, etc. Those need to be removed from the archive from time to time, and right before a release, to ensure that the entire archive can be rebuilt by current sources.

Such packages are detected by `archive-cruft-check.py /srv/launchpad.net/ubuntu-archive/`. Apart from NBS packages it also prints out 'ASBA' ("Arch: all" superseded by "Arch: any"), but they are irrelevant for day-to-day archive administration. This tool does not check for reverse dependencies, though, so you should use `checkrdepends -b` for checking if it is safe to actually remove NBS packages from the archive:

As a first step, create a work directory and a list of all packages (one file per package) which are NBS and check their reverse dependencies:

 {{{
 mkdir /tmp/$SUDO_USER/cruft
cd /tmp/$SUDO_USER/cruft
for i in $(archive-cruft-check.py /srv/launchpad.net/ubuntu-archive/ 2>&1| grep '^ *o ' | sed 's/^.*://; s/,//g'); do checkrdepends -b $i hardy > $i; done }}}

Replace `hardy` with the name of the current development release. This will take a long time, so consider using screen. Please note that this list is [[http://people.ubuntu.com/~ubuntu-archive/NBS/|generated automatically]] twice a day.

Those packages which do not have any reverse dependencies can be removed safely in one go:

 {{{
 for p in $(find -empty | sed 's_^./__'); do lp-remove-package.py -yb -u $SUDO_USER -m "NBS" $p; rm $p; done
}}}

The rest needs to be taken care of by developers, by doing transition uploads for library SONAME changes, updating build dependencies, etc. The remaining files will list all the packages which still need the package in question.

Please refrain from removing NBS kernel packages for old ABIs until debian-installer and the seeds have been updated, otherwise daily builds of alternate and server CDs will be made uninstallable.

== partner archive ==

The Canonical partner archive is in a distro of its own, ubuntu-partner.

Queue is much the same

 {{{
queue -s hardy info
}}}

Use -j to remove a package

 {{{
lp-remove-package.py -u jr -m "request Brian Thomason" -d ubuntu -s feisty realplay -j
}}}

Please get sign-off from the Ubuntu QA team (via Steve Beattie) before accepting packages into partner.

= reprocess-failed-to-move =		 == reprocess-failed-to-move ==
Line 593: Line 544:

== Reprocessing failed source uploads ==

If a source upload fails for spurious/transient reasons (you can check in `pepo:/srv/launchpad.net/production-logs/lp_queue/process-upload.log`), ask webops to locate the appropriate `upload-*` directory and corresponding `.distro` file in `/srv/launchpad.net/ubuntu-queue/` (they will probably be in either `failed` or `rejected`) and move them both back to `/srv/launchpad.net/ubuntu-queue/incoming/`.
Line 597: Line 552:
Archive admins manually need to process StableReleaseUpdates. Run the `pending-sru` script to 'queue fetch' all currently unapproved uploads. Review them according to the following guidelines:

 * Reject uploads which do not conform to the StableReleaseUpdates policy. If the changelog refers to a bug number, follow up there with an explanation.

 * Only process an upload if the SRU team approved the update in the bug report trail.

 * Verify that the package delta matches the debdiff attached to the bug report and that there are no other unrelated changes.

 * If you accept a package into `-proposed`,
  1. Add a `verification-needed` tag to the bug report.
  1. Set the appropriate bug task to '''Status: Fix Committed'''.
  1. Subscribe the `sru-verification` team.

 * After the package in `-proposed` has been successfully tested and passed a minimum aging period of '''7 days''' (check the [[http://people.ubuntu.com/~ubuntu-archive/pending-sru.html|status page]]), and is approved by the SRU verification team, the package should be moved to `-updates`:
   1. Use `copy-package.py` to copy the source and binary packages from `-proposed` to `-updates`.
   1. Set the bug task to '''Status: Fix Released'''. 		SRU packages in -proposed must be approved by ~ubuntu-sru before accepting.

Please see https://wiki.ubuntu.com/StableReleaseUpdates#Reviewing_procedure_and_tools

== langpack SRUs ==
 * Language packs are a special case; these packages are normally uploaded as a batch and will not normally reference specific bugs. The [[http://people.canonical.com/~ubuntu-archive/pending-sru.html|status page]] will only show {{{language-pack-en}}}. Please see [[http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/view/head:/doc/operator-guide.txt|the documentation]] how to copy packages between PPA, -proposed, and -updates.

= Other archives =

[[http://extras.ubuntu.com/|extras.ubuntu.com]] is not managed by the Ubuntu archive administration team, but is a PPA owned by the [[https://launchpad.net/~app-review-board|Application Review Board]].
Line 618: Line 567:
[[http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt]] [[http://people.canonical.com/~ubuntu-archive/component-mismatches.txt]]
Line 622: Line 571:
[[http://people.ubuntu.com/~ubuntu-archive/germinate-output/]] [[http://people.canonical.com/~ubuntu-archive/germinate-output/]]
Line 626: Line 575:
[[http://people.ubuntu.com/~ubuntu-archive/priority-mismatches.txt]] [[http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt]]
Line 630: Line 579:
[[http://people.ubuntu.com/~ubuntu-archive/architecture-mismatches.txt]] [[http://people.canonical.com/~ubuntu-archive/architecture-mismatches.txt]]
Line 634: Line 583:
[[http://people.ubuntu.com/~ubuntu-archive/testing/jaunty_probs.html]]

  Generated by the hourly run of `britney` and indicates packages that are uninstallable on jaunty, usually due to missing dependencies or problematic conflicts.

[[http://people.ubuntu.com/~ubuntu-archive/testing/jaunty_outdate.html]]		 [[http://people.canonical.com/~ubuntu-archive/testing/xenial_probs.html]]

  Generated by the half-hourly run of `britney` and indicates packages that are uninstallable on xenial, usually due to missing dependencies or problematic conflicts.

[[http://people.canonical.com/~ubuntu-archive/testing/xenial_outdate.html]]
Line 642: Line 591:
[[http://people.ubuntu.com/~ubuntu-archive/NBS/]]

  This contains a list of binary packages which are not built from source (NBS) any more. The files contain the list of reverse dependencies of those packages (output of `checkrdepends -b`). These packages need to be removed eventually, thus all reverse dependencies need to be fixed. This is updated twice a day.		 [[http://people.canonical.com/~ubuntu-archive/NBS/]]
[[http://people.canonical.com/~ubuntu-archive/nbs.html]]

  This contains a list of binary packages which are not built from source (NBS) any more. The files contain the list of reverse dependencies of those packages (output of `checkrdepends -b`). These packages need to be removed eventually, thus all reverse dependencies need to be fixed. This is updated half-hourly.
Line 651: Line 601:
Soyuz stores one chroot per (suite, archictecture).

`manage-chroot.py`, which runs only as 'lp_buildd' in cocoplum or cesium, allows the following actions upon a specified chroot:

{{{
$ sudo -u lp_buildd -i
lp_buildd@cocoplum:~$ LPCONFIG=ftpmaster /srv/launchpad.net/codelines/current/scripts/ftpmaster-tools/manage-chroot.py
ERROR manage-chroot.py <add|update|remove|get>		 Soyuz stores one chroot per (suite, architecture).

`manage-chroot` allows the following actions upon a specified chroot:

 {{{
$ ./manage-chroot
Usage: manage-chroot -a ARCHITECTURE [options] <get|info|remove|set>

manage-chroot: error: You must specify an architecture.
Line 663: Line 614:
{{{
$ manage-chroot.py [-s SUITE] <-a ARCH> get		  {{{
$ ./manage-chroot [-s SUITE] <-a ARCH> get
Line 671: Line 622:
{{{
$ manage-chroot.py [-s SUITE] <-a ARCH> add -f <CHROOT_FILE>
}}}

'add' and 'update' action are equivalents. The new chroot will be immediatelly used for the next build job in the corresponding architecture.		  {{{
$ ./manage-chroot [-s SUITE] <-a ARCH> set -f <CHROOT_FILE>
}}}

The new chroot will be immediately used for the next build job in the corresponding architecture.
Line 681: Line 632:
{{{
$ manage-chroot.py [-s SUITE] <-a ARCH> remove		  {{{
$ ./manage-chroot [-s SUITE] <-a ARCH> remove
Line 687: Line 638:
= Archive days =

Current members with regular admin days are:
 * Monday: SteveLangasek
 * Tuesday: JonathanRiddell
 * Wednesday: DustinKirkland (syncs, bug processing)
 * Thursday, SteveKowalik
 * Friday: JamieStrandboge

On an archive day, the following things should be done:
 * If we are not yet in the DebianImportFreeze, run `sync-source -a` to sync unmodified packages from Debian.
 * Process all [[https://launchpad.net/~ubuntu-archive/+subscribedbugs|pending archive bugs]]. Most of those are syncs, removals, component fixes, but there might be other, less common, requests.
 * Process all backports.		 = Archive administration shifts =

This is a next try for establishing Archive Admin shifts during the week. During an AA shift, an archive admin allocates at least 2 hours to work on tasks requiring special ubuntu-archive permissions.

Current members with regular admin shifts are:
 * Monday:
 * Tuesday:
 * Wednesday: sil2100 (9:00-11:00 UTC)
 * Thursday: seb128 (10-12 CET)
 * Friday:

On an archive shifts, the following items should be the main focus:
 * Stay open for any 'ubuntu-archive' IRC requests, being available to help developers out with their everyday work

Additionally, the performing the following should be considered:
 * Process [[https://launchpad.net/~ubuntu-archive/+subscribedbugs|pending archive bugs]]. This query often generates a Launchpad OOPS rather than succeeding; [[https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-archive&field.status=NEW&field.status=Confirmed&field.status=Triaged&field.status=INPROGRESS&field.status=FIXCOMMITTED&field.status=INCOMPLETE_WITH_RESPONSE&orderby=-id&start=0|this query]] is more likely to succeed, but might miss some bugs. Most of those are syncs, removals, component fixes, but there might be other, less common, requests.
Line 701: Line 655:
 * Run `process-removals` to review/remove packages which were removed in Debian.  * If we are not yet in the DebianImportFreeze, run `process-removals` to review/remove packages which were removed in Debian.
Line 703: Line 657:
 * Look at [[http://people.ubuntu.com/~ubuntu-archive/testing/jaunty_probs.html]], fix archive-admin related issues (component mismatches, etc.), and prod maintainers to fix package related problems.
Line 706: Line 659:
== Archive Administration and Freezes == = Archive Administration and Freezes =
Line 710: Line 663:
 * During the week before final release, you need an ACK from `motu-release` for any uploads to universe/multiverse
 * When the archive is not frozen, bugfix-only sync requests can be processed if filed by a `core-dev`, `ubuntu-dev` or `motu` (universe/multiverse only) or have an ACK by a sponsor from one of these groups, ubuntu-main-sponsors or ubuntu-universe-sponsors
 * After FeatureFreeze, all packages in main require an ACK from ubuntu-release for any FreezeException (eg FeatureFreeze, UserInterfaceFreeze, and [[MilestoneProcess|Milestone]]) and an ACK from motu-release for universe/multiverse
 * New packages in universe/multiverse need two ACKs after FeatureFreeze		  * During the week before final release, you need an ACK from `ubuntu-release` for any uploads to universe/multiverse
 * When the archive is not frozen, bugfix-only sync requests can be processed if filed by a `core-dev`, `ubuntu-dev` or `motu` (universe/multiverse only) or have an ACK by a sponsor or someone from ubuntu-sponsors.
 * After FeatureFreeze, all (new or otherwise) packages in the archive (ie main, restricted, universe and multiverse) require an ACK from ubuntu-release for any !FreezeException (eg FeatureFreeze, UserInterfaceFreeze, and [[MilestoneProcess|Milestone]]). Packages that do not require a !FreezeException can be processed normally.
Line 716: Line 668:

= OEM metapackages =

The archive team runs a script, maintained by the DeveloperMembershipBoard, to automatically grant upload rights to `oem-*-meta` packages - including packages which aren't yet in Ubuntu (uploaders can upload to NEW for these packages) - to some members of Canonical's OEM delivery team via a packageset called "canonical-oem-metapackages".

The DMB handle applications to the packageset and maintain the code. Our responsibility in the archive team is to run the script reasonably frequently, pull any changes when the DMB ask us to, and arrange for its output to be emailed at least to the `devel-permissions` list.

See [[DeveloperMembershipBoard/KnowledgeBase#Canonical_OEM_metapackage_packageset|the DMB's knowledge base]] and [[https://git.launchpad.net/~developer-membership-board/+git/oem-meta-packageset-sync/tree/oem-meta-packageset-sync|the script itself]] for some further information and links.

Contents

  1. Client-side tools
  2. Logging In
  3. NEW Processing
    1. partner archive
  4. Component Mismatches and Changing Overrides
  5. Removals
    1. Manual
    2. Blacklisting
    3. Removals in Debian
    4. Failed SRUs
  6. Syncs
  7. NBS
  8. i386 whitelist updates
  9. Adjusting Launchpad ACLs
    1. Package sets
  10. Raw UEFI uploads
  11. Useful tools
    1. Archive state checks
    2. NEW handling
    3. Moving Packages to Updates
    4. Publishing security uploads from the ubuntu-security private PPA
    5. Publishing packages from the ubuntu-mozilla-security public PPA
    6. Publishing packages from the ubuntu-security-proposed public PPA to proposed
    7. Copying PPA kernels to proposed
    8. Copying security uploads to updates
    9. Other copies
    10. Handling updates to partner
    11. Diffs for unapproved uploads
  12. Useful runes
    1. reprocess-failed-to-move
    2. Reprocessing failed source uploads
  13. Stable release updates
    1. langpack SRUs
  14. Other archives
  15. Useful web pages
  16. Chroot management
  17. Archive administration shifts
  18. Archive Administration and Freezes
  19. OEM metapackages

This page details the processes for the Ubuntu Package Archive Administrators team, and hopefully provides a decent guide for new members of the team.

Bugs should be filed against the appropriate packages, and the team subscribed (not assigned) to the bug.

The requests can be found at https://launchpad.net/~ubuntu-archive/+subscribedbugs.

Team members may assign bugs to themselves and mark them In Progress if they're working on them, or discussing them; to act as a lock on that request.

1. Client-side tools

We are transitioning towards client-side administration as the necessary facilities become available via the Launchpad API. To get hold of these tools: 

  • $ git clone lp:ubuntu-archive-tools

2. Logging In

A few operations still require direct ssh access to pepo.canonical.com; accounts are provided to some members of the team. (We are transitioning away from direct shell access, so new team members will not get accounts here, thereby encouraging us to complete the transition more quickly.) Changes can only be made as the lp_archive user, to which you'll have sudo access.

So to begin: 

  • $ ssh pepo
$ sudo -u lp_archive -i

The -i is important as lp_archive's .bashrc sets the right environment variables and makes sure the directory with all of the tools is placed in the PATH.

3. NEW Processing

To work with the upload queue, you may either use the web interface or the queue API client in ubuntu-archive-tools. The API client should generally be faster and more flexible; in particular, it is not currently possible to override individual binaries using the web interface.

Both source packages and new binaries which have not yet been approved are not automatically accepted into the archive, but are instead held for checking and manual acceptance. Once accepted they'll be automatically approved from then on.

The current queue can be obtained with: 

  • $ ./queue info

This is the NEW queue for the development series of Ubuntu by default; you can change the queue with -Q, the distro with -D and the release using -s. To list the UNAPPROVED queue for ubuntu/xenial, for example: 

  • $ ./queue -s xenial -Q unapproved info

Packages are placed in the UNAPPROVED queue if they're uploaded to a closed distribution, and are usually security updates or similar; this should be checked with the uploader.

You can give an string argument after info which is interpreted as a substring match filter.

To obtain a report of the size of all the different queues for a particular release: 

  • $ ./queue report

Back to the NEW queue for now, however. You'll see output that looks somewhat like this: 

  • $ ./queue info
 Listing ubuntu/dapper (New) 4
---------|----|----------------------|----------------------|---------------
   25324 | S- | diveintopython-zh    | 5.4-0ubuntu1         | 3 minutes
         | * diveintopython-zh/5.4-0ubuntu1 Component: main Section: doc
   25276 | -B | language-pack-kde-co | 1:6.06+20060427      | 2 hours 20 minutes
         | * language-pack-kde-co-base/1:6.06+20060427/i386 Component: main Section: translations Priority: OPTIONAL
   23635 | -B | upbackup (i386)      | 0.0.1                | 2 days
         | * upbackup/0.0.1/i386 Component: main Section: admin Priority: OPTIONAL
         | * upbackup_0.0.1_i386_translations.tar.gz Format: raw-translations
   23712 | S- | gausssum             | 1.0.3-2ubuntu1       | 45 hours
         | * gausssum/1.0.3-2ubuntu1 Component: main Section: science
---------|----|----------------------|----------------------|---------------
                                                               4

The number at the start can be used with other commands instead of referring to a package by name. The next field shows you what is actually in the queue, "S-" means it's a new source and "-B" means it's a new binary. You then have the package name, the version and how long it's been in the queue.

New sources need to be checked to make sure they're well packaged, the licence details are correct and permissible for us to redistribute, etc. See Packaging new software, debian/copyright file and Debian's Reject FAQ. You can fetch a package from the queue for manual checking: 

  • $ ./queue fetch 25324

Or, if you just want to print the URLs so that you can fetch them on a system with a faster network connection: 

  • $ ./queue show-urls 25324

The source is now in the current directory and ready for checking. Any problems should result in the rejection of the package (also send a mail to the uploader explaining the reason and Cc ubuntu-archive@lists.ubuntu.com): 

  • $ ./queue reject 25324

If the package is fine, you should next check that it's going to end up in the right part of the archive. On the next line of the info output, you have details about the different parts of the package, including which component, section, etc. it is expected to head into. One of the important jobs is making sure that this information is actually correct through the application of overrides.

To alter the overrides for a package, use: 

  • $ ./queue override -c universe ubuntustudio-menu

Where the override can be -c <component>, -x <section>, and/or (for binary packages) -p <priority>. If you want to limit the override application to only source or only binary packages, use the --source or --binary option respectively.

Often a binary will be in the NEW queue because it is a shared library that has changed SONAME. In this case you'll probably want to check the existing overrides to make sure anything new matches. These can be found in /ubuntu/indices on Ubuntu mirrors.

Currently a special case of this are the kernel packages, which change package names with each ABI update and build many distinct binary packages in different sections. A helper tool has been written to apply overrides to the queue based on the packages that are currently published: 

  • $ ./kernel-overrides [-s <sourcepackage>] <newabi>

Binary packages are not often rejected (they go into a black hole with no automatic notifications), so, check the .deb contains files, run lintian on it and file bugs when things are broken. The binaries also need to be put into universe etc as appropriate even if the source is already there.

If you're happy with a package, and the overrides are correct, accept it with: 

  • $ ./queue accept 23712

You can also use ./queue accept binary-name which will accept it for all architectures.

3.1. partner archive

The Canonical partner archive, though not part of Ubuntu proper, is managed using the same tools and queues. As such, use the same procedures when processing partner packages. E.g. (notice 'Component: partner'): 

  • $ ./queue -s hardy info
Listing ubuntu/hardy (New) 2
---------|----|----------------------|----------------------|---------------
 1370980 | S- | arkeia               | 8.0.9-3              | 19 hours
         | * arkeia/8.0.9-3 Component: partner Section: utils
 1370964 | S- | arkeia-amd64         | 8.0.9-3              | 19 hours
         | * arkeia-amd64/8.0.9-3 Component: partner Section: utils
---------|----|----------------------|----------------------|---------------
                                                               2

Use -A ubuntu/partner to remove a package: 

  • $ ./remove-package -m "request from First Last name" -A ubuntu/partner -s precise adobe-flashplugin

The rules governing package inclusion in partner are not the same as those for the main Ubuntu archive. See ExtensionRepositoryPolicy for the Technical Board's requirements regarding the contents of add-on repositories made available through the Software Sources interface.

4. Component Mismatches and Changing Overrides

Sadly packages just don't stay where they're put. SeedManagement details how packages get chosen for the main component, the various meta packages and presence on the CD. What it doesn't point out is that packages which fall out of the seeding process are destined for the universe component.

Every 30 minutes or so, the difference between what the seeds expect to be true and what the archive actually believes is evaluated by the component-mismatches tool, and the output placed at:

This is split into four sections:

Source and binary promotions to main

  • These are source packages currently in universe that appear to need promoting to main. The usual reasons are that they are seeded, or that a package they build has become a dependency or build-dependency of a package in main. New sources need to be processed through the UbuntuMainInclusionQueue, and have been approved before they should be promoted. Also ensure that all of their dependencies (which will be in this list) are approved as well.

Binary only promotions to main

  • These are binary packages currently in universe that appear to need promoting to main, as above; except that their source package is already in main. An inclusion report isn't generally needed, though the package should be sanity checked. Especially check that all of the package's dependencies are already in main, or have been approved.

Source and binary demotions to universe

  • Sources and their binaries that are currently in main but are no longer seeded or depended on by another package. These either need to be seeded explicitly, or demoted.

Binary only demotions to universe

  • Binary packages in main that are no longer seeded or depended on, but the source is still to remain in main -- usually because another binary saves it. Often these tend to be -dev or -dbg packages and need to be seeded, rather than demoted; but not always.

Once you've determined what overrides need to be changed, use the change-override client-side tool to do it.

To promote a binary package to main: 

  • $ ./change-override -c main git-email

To demote a source package and all of its binaries to universe: 

  • $ ./change-override -c universe -S tspc

Less-used are the options to just move a source, and leave its binaries where it is (usually just to repair a mistaken forgotten -S): 

  • $ ./change-override -c universe tspc
...oops, forgot the source...
$ ./change-override -c universe -t tspc

and the option to move a binary and its source, but leave any other binaries where they are: 

  • $ ./change-override -c universe -B flite

5. Removals

5.1. Manual

Sometimes packages just need removing entirely, because they are no longer required. This can be done using the remove-package client-side tool: 

  • $ ./remove-package -m "reason for removal" konserve

By default this removes the named source and binaries, to remove just a binary use -b: 

  • $ ./remove-package -m "NBS" -b konserve

"NBS" is a common short-hand meaning that the binary is No-longer Built by the Source.

To remove just a source, use -S.

The tool tells you what it's going to do, and asks for confirmation before doing it, so it's reasonably safe to get the wrong options and say N.

5.2. Blacklisting

If you remove source packages which are in Debian, and they are not meant to ever come back, add it to the blacklist in lp:~ubuntu-archive/+junk/sync-blacklist, document the reason, and bzr commit it with an appropriate changelog. This will avoid getting the package back to source NEW in the next round of autosyncs from Debian.

5.3. Removals in Debian

From time to time we should remove packages which were removed in Debian, to avoid accumulating cruft and unmaintained packages. This client-side tool (from ubuntu-archive-tools) will interactively go through the removals and ask for confirmation: 

  • $ ./process-removals

Please note that we do need to keep some packages which were removed in Debian (e. g. "firefox", since we did not do the "firefox" → "iceweasel" renaming).

5.4. Failed SRUs

If a package should be removed from -proposed, use the remove-package tool (from ubuntu-archive-tools). e.g., to remove source and binaries for the libreoffice package currently in xenial-proposed: 

  • $ ./remove-package -m "SRU abandoned (verification-failed)" -s xenial-proposed libreoffice

6. Syncs

Syncing packages with Debian used to be a reasonably common request. It is now self-service for developers using syncpackage. If you are asked to process a sync in the old style, you can use the -s option to syncpackage to do so in the name of the requester.

Most updates available in Debian are automatically synced before DebianImportFreeze, but packages that were previously in Ubuntu will not be automatically reintroduced. To process these interactively: 

  • $ ./auto-sync --new-only

To sync from any source which is not automatically imported by Launchpad, use the syncpackage tool on a .dsc file. Any uploader can do this; it does not require being an archive administrator.

Likewise, backports are now self-service for members of ubuntu-backporters using backportpackage.

7. NBS

Sometimes binary packages are not built by any source (NBS) any more. This usually happens with library SONAME changes, package renamings, etc. Those need to be removed from the archive from time to time, and right before a release, to ensure that the entire archive can be rebuilt by current sources.

Such packages are detected by archive-cruft-check. This tool does not check for reverse dependencies, though, so you should use checkrdepends -b for checking if it is safe to actually remove NBS packages from the archive.

Look at the half-hourly generated NBS report which shows all NBS packages, their reverse dependencies, and a copy-and-paste-able command to clean up the "safe" ones.

The rest needs to be taken care of by developers, by doing transition uploads for library SONAME changes, updating build dependencies, etc. The remaining files will list all the packages which still need the package in question.

Please refrain from removing NBS kernel packages for old ABIs until debian-installer and the seeds have been updated, otherwise daily builds of alternate and server CDs will be made uninstallable.

8. i386 whitelist updates

The i386 is a partial archive now, details on https://wiki.ubuntu.com/i386

To add packages to the whilelist

  • Update the update-i386-whitelist script from u-a-t (typically adding a newSet.update(['$package']) entry
  • run the script
  • trigger the i386 build either by doing an upload or by copying the package over itself (copy-package -b --force-same-destination -e $version $pkg )

the copy should trigger a build on i386, once it's published

  • remove the entry from the update-i386-whitelist script

  • if the new item isn't pulled in as a build-/dependencies manually add it to https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/i386/

    • if a source package builds multiple binary packages, and a binary package other than the one pulled into the seed has dependencies that are not otherwise included, then this binary package will also need to be seeded in order to ensure dependency availability.

9. Adjusting Launchpad ACLs

NOTE: due to bug #562451, archive administrators cannot currently adjust Launchpad ACLs.

The new ArchiveReorganisation brings finer grained access controls than what components can provide. Launchpad ACLs allow individuals and teams to have upload or admin rights on certain packages, referred to as sets. In general, an archive administrator can process requests to create and delete package sets, as well as add or remove packages from package sets. Archive administrators should not add individuals or teams to package sets without explicit TechnicalBoard approval.

9.1. Package sets

Packages can be added to or removed from package sets using the edit-acl tool from ubuntu-archive-tools.

To list the packages currently in the package set mozilla: 

  • $ ./edit-acl query -P mozilla -S zesty
adblock-plus
all-in-one-sidebar
bindwood
...

To add a package to the mozilla package set: 

  • $ ./edit-acl -P mozilla -S zesty -s foo -s bar -s baz add

To remove a package from the mozilla package set: 

  • $ ./edit-acl -P mozilla -S zesty -s foo delete

For more information, please see edit-acl --help.

10. Raw UEFI uploads

Launchpad supports autosigning of EFI binaries using the Secure Boot signature format. This is implemented using a "raw uefi" format upload within a binary package build (see the efilinux package in quantal or later for an example). To provide additional assurance that only trusted EFI bootloaders are signed using this method, packages that include raw UEFI binary uploads land in the unapproved queue and require archive admin approval before they are signed. Archive admins should review the corresponding source upload for correctness prior to approving these uploads.

11. Useful tools

There are other useful tools in your PATH which are invaluable.

11.1. Archive state checks

rmadison (in the devscripts package, run on your client system) examines the current state of the archive for a given binary/source package: 

  • $ rmadison dpkg
      dpkg | 1.10.22ubuntu2 |         warty | source, amd64, i386, powerpc
      dpkg | 1.10.22ubuntu2.1 | warty-security | source, amd64, i386, powerpc
      dpkg | 1.10.27ubuntu1 |         hoary | source, amd64, i386, ia64, powerpc, sparc
      dpkg | 1.10.27ubuntu1.1 | hoary-security | source, amd64, i386, ia64, powerpc, sparc
      dpkg | 1.10.27ubuntu2 | hoary-updates | source, amd64, i386, ia64, powerpc, sparc
      dpkg | 1.13.10ubuntu4 |        breezy | source, amd64, hppa, i386, ia64, powerpc, sparc
      dpkg | 1.13.11ubuntu5 |        dapper | source, amd64, hppa, i386, ia64, powerpc, sparc

$ rmadison dselect
   dselect | 1.10.22ubuntu2 |         warty | amd64, i386, powerpc
   dselect | 1.10.22ubuntu2.1 | warty-security | amd64, i386, powerpc
   dselect | 1.10.27ubuntu1 |         hoary | amd64, i386, ia64, powerpc, sparc
   dselect | 1.10.27ubuntu1.1 | hoary-security | amd64, i386, ia64, powerpc, sparc
   dselect | 1.10.27ubuntu2 | hoary-updates | amd64, i386, ia64, powerpc, sparc
   dselect | 1.13.10ubuntu4 |        breezy | amd64, hppa, i386, ia64, powerpc, sparc
   dselect | 1.13.11ubuntu5 |        dapper | amd64, hppa, i386, ia64, powerpc, sparc

Or when used with -S and a source package, the source and every binary built by it: 

  • $ rmadison -S dpkg
      dpkg | 1.10.22ubuntu2 |         warty | source, amd64, i386, powerpc
      dpkg | 1.10.22ubuntu2.1 | warty-security | source, amd64, i386, powerpc
      dpkg | 1.10.27ubuntu1 |         hoary | source, amd64, i386, ia64, powerpc, sparc
      dpkg | 1.10.27ubuntu1.1 | hoary-security | source, amd64, i386, ia64, powerpc, sparc
      dpkg | 1.10.27ubuntu2 | hoary-updates | source, amd64, i386, ia64, powerpc, sparc
      dpkg | 1.13.10ubuntu4 |        breezy | source, amd64, hppa, i386, ia64, powerpc, sparc
      dpkg | 1.13.11ubuntu5 |        dapper | source, amd64, hppa, i386, ia64, powerpc, sparc
  dpkg-dev | 1.10.22ubuntu2 |         warty | all
  dpkg-dev | 1.10.22ubuntu2.1 | warty-security | all
  dpkg-dev | 1.10.27ubuntu1 |         hoary | all
  dpkg-dev | 1.10.27ubuntu1.1 | hoary-security | all
  dpkg-dev | 1.10.27ubuntu2 | hoary-updates | all
  dpkg-dev | 1.13.10ubuntu4 |        breezy | all
  dpkg-dev | 1.13.11ubuntu5 |        dapper | all
  dpkg-doc | 1.10.22ubuntu2 |         warty | all
  dpkg-doc | 1.10.22ubuntu2.1 | warty-security | all
  dpkg-doc | 1.10.27ubuntu1 |         hoary | all
  dpkg-doc | 1.10.27ubuntu1.1 | hoary-security | all
  dpkg-doc | 1.10.27ubuntu2 | hoary-updates | all
   dselect | 1.10.22ubuntu2 |         warty | amd64, i386, powerpc
   dselect | 1.10.22ubuntu2.1 | warty-security | amd64, i386, powerpc
   dselect | 1.10.27ubuntu1 |         hoary | amd64, i386, ia64, powerpc, sparc
   dselect | 1.10.27ubuntu1.1 | hoary-security | amd64, i386, ia64, powerpc, sparc
   dselect | 1.10.27ubuntu2 | hoary-updates | amd64, i386, ia64, powerpc, sparc
   dselect | 1.13.10ubuntu4 |        breezy | amd64, hppa, i386, ia64, powerpc, sparc
   dselect | 1.13.11ubuntu5 |        dapper | amd64, hppa, i386, ia64, powerpc, sparc

checkrdepends lists the reverse dependencies of a given binary: 

  • $ checkrdepends -s zesty -b nm-applet

or source package: 

  • $ checkrdepends -s zesty network-manager

11.2. NEW handling

A lot of churn in NEW comes from Debian imports. Since they already went through NEW in Debian, we should not waste too much time on it, so there are some tools.

  • The first thing you need to handle are native syncs. These are syncs performed via URLs like https://launchpad.net/ubuntu/zesty/+localpackagediffs or via the LP API. You can recognize these in the LP queue pages because they have '(sync)' in the name. In queue info, they show up as 'X-' (as opposed to 'S-' like normal source uploads). There are no changes files for these, so they cannot currently be fetched via queue fetch. To verify a native sync:

    1. Download the source package from Debian (eg, via dget or apt-get source <pkg>=<version>)

    2. Download the imported dsc file from the Debian project in LP (eg https://launchpad.net/debian/sid/+source/pxe-kexec)

    3. Compare the dsc file from Debian and from LP. Since both should be signed, if they are identical, then you know the package hasn't been tampered with. I can also compare the full source package from Debian and LP if desired.

    Once verified, accept it normally via LP or ./queue accept <srcpkg>.

  • ./new-binary-debian-universe accepts all binary NEW packages whose source was imported from Debian and is in universe. With the --lintian option, it runs lintian over all the imported .debs while it runs, so you can watch the output and note all particularly worrisome issues. When you are happy, say yes at each confirmation prompt.

  • When unpacking a source package for source NEW checks, you should run suspicious-source. This is basically a find -type f which ignores all files with a known-safe name (such as *.c, configure, *.glade). Every file that it outputs should be checked for being the preferred form of modification, as required by the GPL. This makes it easier to spot PDFs and other binary-only files that are not accompanied by a source. The licensecheck command is also useful for verifying the license status of source packages.

11.3. Moving Packages to Updates

Packages in -proposed can be moved to -updates once they are approved by someone from sru-verification, and have passed the minimum aging period of 7 days. Use the sru-release script from ubuntu-archive-tools for this: 

  • $ ./sru-release xenial kdebase

Please see --help, you can also use this tool to copy packages to -security and to the current development release. N.B. before copying a package to -security ping a member of the ubuntu-security team.

11.4. Publishing security uploads from the ubuntu-security private PPA

Security uploads in Soyuz are first built, published, and tested in the Security Team's private PPA. To unembargo them, the security team use a tool that re-publishes them to the primary archive. This is now self-service, although you may occasionally be asked to adjust overrides, which can be done in the usual way.

11.5. Publishing packages from the ubuntu-mozilla-security public PPA

Mozilla (ie, firefox and thunderbird) uploads in Soyuz are first built, published, and tested in the Mozilla Security Team's public PPA. To publish them into the main archive, use copy-package from ubuntu-archive-tools. Note that pocket copies to the security pocket should never be done without an explicit request from a member of the Ubuntu Security Team (Mozilla Security Team is not enough), and copies to the proposed pocket should not be done without an explicit request from a member of the SRU Team. Keep in mind that firefox 2.0 and later (ie hardy and later) will always have a corresponding xulrunner package that needs copying.

To publish firefox version 22.0+build2-0ubuntu0.12.04.2 from the ubuntu-mozilla-security PPA to the -security pocket of ubuntu's precise release, you would do the following: 

  • $ ./copy-package -b --from=~ubuntu-mozilla-security/ubuntu/ppa -s precise --to=ubuntu --to-suite precise-security -e 22.0+build2-0ubuntu0.12.04.2 firefox

Alternatively, can use lp:ubuntu-qa-tools/security-tools/unembargo like so: 

  • $ unembargo --ppa=ubuntu-mozilla-security -r xenial --pocket=proposed chromium-browser

11.6. Publishing packages from the ubuntu-security-proposed public PPA to proposed

This works the same as the ubuntu-mozilla-security PPA, above. Eg, using lp:ubuntu-qa-tools/security-tools/unembargo: 

  • $ unembargo --ppa=ubuntu-security-proposed -r xenial --pocket=proposed gnupg

11.7. Copying PPA kernels to proposed

With the new StableReleaseCadence, kernels are built in the kernel team PPA and then pocket copied to the proposed pocket in the main archive once they are ACKd.

The two most useful URLs for this process are the Kernel SRU Report, where you will find links to the tracking bugs (the magnifying glasses), as well as the status of each package in each release, and the Kernel SRU workflow, which outlines in fine detail how each bug task should be handled, what the states mean, etc. The executive summary of the previous link is "only operate on tasks assigned to your team, and only when they're in the Comfirmed state, and when you do, please reassign to yourself and set the task to Fix Released when you're done".

The Pending SRU report has a section for the kernel PPA which shows all newer kernels in the PPA, provides clickable links to open all bugs (with separate CVE bugs), and copy&pasteable copy-proposed-kernel and sru-accept commands (both in ubuntu-archive-tools). To publish linux version 2.6.32-27.49 from the canonical-kernel-team PPA to the -proposed pocket of ubuntu's lucid release, you would do the following:

  • Click on the "open bugs" button and check that the bugs are in a reasonable state, i. e. they target the right source package (linux vs. linux-ec2 etc.), are fixed in the development release (or at least upstream), and that the changes are limited to bug fixes, and are in general within the boundaries of the StableReleaseUpdates policy. They should ideally have a task for the stable release the SRU targets. Note that this button does not open CVE bugs, as they don't get verification or other tracking (there is a separate button for opening them, if desired).

  • Find the tracking bug by either traversing through the list of bugs, or opening the .changes file and looking at the top (the release bug is pointed out there). Ensure that there is a proper stable task, and that the main (development release) task is invalid.

  • Run the copy-proposed-kernel command to copy it to -proposed. Once the kernels are copied to proposed and accepted, update the bug to close the Promote-to-proposed task and assign it to yourself.

    However, with some flavours like -ec2 or armel kernels, which are mostly just a merge with the main linux kernel, it is too much overhead to add -ec2 tasks to all the bugs.

  • Due to current limitations of Launchpad, new packages copied from a PPA into the archive sometimes go to 'universe'. As a result, please verify the overrides for all packages copied to -proposed, otherwise these packages might become uninstallable when they are ultimately copied to -updates/-security. find-bin-overrides from lp:ubuntu-qa-tools can help with this. You use it like so: find-bin-overrides <pocket to compare to> <target pocket> <ubuntu release> <source package>=<version in pocket to compare to>,<old abi>,<new abi>. Eg, suppose there is a new kernel in hardy-proposed with a new ABI of 2.6.24-30 and you want to get a list of overrides for the new kernel based on the old ABI of 2.6.24-16 in the 2.6.24.12-16.34 version from the release pocket of hardy. For the linux-restricted-modules-2.6.24 source package, you might use: 

    $ find-bin-overrides release proposed hardy \
linux-restricted-modules-2.6.24=2.6.24.12-16.34,2.6.24-16,2.6.24-30
# hardy/linux-restricted-modules-2.6.24
./change-override -c multiverse -s hardy-proposed fglrx-kernel-source ...
./change-override -c restricted -s hardy-proposed avm-fritz-firmware-2.6.24-30 ...

    For the linux source package, you might use: 

    $ find-bin-overrides release proposed hardy linux=2.6.24-16.30,2.6.24-16,2.6.24-30
# hardy/linux
...

    You may also specify --show-main to also show the the change-override command to move things to main. This can be useful if you know the overrides are very wrong. See find-bin-overrides -h for details.

TODO: A process/script similar to kernel-overrides should be developed to make sure overrides are properly handled for binaries not in main. Is find-bin-overrides from lp:ubuntu-qa-tools good enough?

11.8. Copying security uploads to updates

Security uploads are distributed from a single system, security.ubuntu.com (consisting of one or a small number of machines in the Canonical datacentre). While this ensures much quicker distribution of security updates than is possible from a mirror network, it places a very high load on the machines serving security.ubuntu.com, as well as inflating Canonical's bandwidth expenses very substantially. Every new installation of a stable release of Ubuntu is likely to be shortly followed by downloading all security updates to date, which is a significant ongoing cost.

To mitigate this, we periodically copy security uploads to the -updates pocket, which is distributed via the regular mirror network. (In fact, the pooled packages associated with -security are mirrored too, but mirrored -security entries are not in the default /etc/apt/sources.list to avoid causing even more HTTP requests on every apt-get update.) This is a cheap operation, and has no effect on the timely distribution of security updates, other than to reduce the load on central systems.

The copy-report tool lists all security uploads that need to be copied to -updates. If the package in question is not already in -updates, it can be copied without further checks. Otherwise, copy-report will extract the changelogs (which may take a little while) and confirm that the package in -security is a descendant of the package in -updates. If that is not the case, it will report that the package needs to be merged by hand.

The output of the tool looks like this: 

  • $ ./copy-report
The following packages can be copied safely:
--------------------------------------------

copy-package -y -b -s feisty-security --to-suite feisty-updates -e 8.3.5-6ubuntu2.1 tk8.3
copy-package -y -b -s feisty-security --to-suite feisty-updates -e 8.4.14-0ubuntu2.1 tk8.4

The block of output under "The following packages can be copied safely:" may be copied and pasted in its entirety (or run copy-report --safe). If there is a block headed "The following packages need to be merged by hand:", then make sure that the security team is aware of those cases.

Note that copy-report --safe is run from a cron job as the ubuntu-archive user on ubuntu-archive-toolbox, and so does not typically need to be run by hand.

11.9. Other copies

copy-package is a versatile tool and can be used for a number of other purposes. If you are doing something not documented here, please ask on #ubuntu-release first.

Archive administrators technically (as in, per the ACLs) have the ability to copy into the RELEASE pocket of the current development series. Please do not do this; that pocket is owned by the proposed-migration tools, and those tools have built-in override facilities for the cases where they are wrong. The release team has access to apply such overrides when needed.

11.10. Handling updates to partner

Updates to the partner archive follow a similar process as packages in the Ubuntu archive. Specifically, packages are first built in the proposed pocket, then they need to be copied to the release pocket after they are built and then cleaned up from the proposed pocket. The process is (examples show adobe-flashplugin being updated for xenial):

  1. Review the package in the "unapproved" queue, and if appropriate, accept the package into partner for the proposed pocket (in this example, proposed for xenial)
  2. When the package builds on all architectures, copy it to the partner release pocket (this makes it available to users). Eg: 
    $ ./copy-package -b --auto-approve --from=ubuntu/partner -s xenial-proposed --to-suite xenial adobe-flashplugin

    or to do all at once:

    $ for i in xenial bionic focal groovy; do ./copy-package -b --auto-approve --from=ubuntu/partner -s $i-proposed --to-suite $i adobe-flashplugin ; done
  3. Remove the package from proposed in the partner archive. Eg: 
    $ ./remove-package -A ubuntu/partner -m "copied to release" -s xenial-proposed adobe-flashplugin

    or to do all at once:

    $ for i in xenial bionic focal groovy; do ./remove-package -A ubuntu/partner -m "copied to release" -s $i-proposed adobe-flashplugin ; done

11.11. Diffs for unapproved uploads

The "unapproved" queue holds packages while a release is frozen, i. e. while a milestone or final freeze is in progress, or for post-release updates (like hardy-proposed). Packages in these queues need to be scrutinized before they get accepted.

This can be done with the queuediff tool in ubuntu-archive-tools, which generates a debdiff between the current version in the archive, and the package sitting in the unapproved queue: 

  • $ ./queuediff -s hardy-updates hal
$ ./queuediff -b human-icon-theme | view -

-s specifies the release pocket to compare against and defaults to the current development release. Please note that the pocket of the unapproved queue is not checked or regarded; i. e. if there is a hal package waiting in hardy-proposed/unapproved, but the previous version already migrated to hardy-updates, then you need to compare against hardy-updates, not -proposed.

Check --help, the tool has more options, such as specifying a different mirror, or -b to open the referred Launchpad bugs in the webbrowser.

This tool works very fast if the new package does not change the orig.tar.gz, then it only downloads the diff.gz. For native packages or new upstream versions it needs to download both tarballs and run debdiff on them. Thus for large packages you might want to do this manually in the data center.

12. Useful runes

This section contains some copy&paste shell bits which ease recurring jobs.

12.1. reprocess-failed-to-move

In some cases, binary packages fail to move from the incoming queue to the accepted queue. To fix this, run ~lp_buildd/reprocess-failed-to-move as lp_buildd

12.2. Reprocessing failed source uploads

If a source upload fails for spurious/transient reasons (you can check in pepo:/srv/launchpad.net/production-logs/lp_queue/process-upload.log), ask webops to locate the appropriate upload-* directory and corresponding .distro file in /srv/launchpad.net/ubuntu-queue/ (they will probably be in either failed or rejected) and move them both back to /srv/launchpad.net/ubuntu-queue/incoming/.

13. Stable release updates

SRU packages in -proposed must be approved by ~ubuntu-sru before accepting.

Please see https://wiki.ubuntu.com/StableReleaseUpdates#Reviewing_procedure_and_tools

13.1. langpack SRUs

  • Language packs are a special case; these packages are normally uploaded as a batch and will not normally reference specific bugs. The status page will only show language-pack-en. Please see the documentation how to copy packages between PPA, -proposed, and -updates.

14. Other archives

extras.ubuntu.com is not managed by the Ubuntu archive administration team, but is a PPA owned by the Application Review Board.

15. Useful web pages

Equally useful to the tools are the various auto-generated web pages in ubuntu-archive's public_html that can give you a feel for the state of the archive.

http://people.canonical.com/~ubuntu-archive/component-mismatches.txt

  • As described above, this lists the differences between the archive and the output of the germinate script. Shows up packages that are in the wrong place, or need seeding.

http://people.canonical.com/~ubuntu-archive/germinate-output/

  • This is the output of the germinate script, split up into each release of each flavour of ubuntu.

http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt

  • Shows discrepancies between priorities of packages and where they probably should go according to the seeds.

http://people.canonical.com/~ubuntu-archive/architecture-mismatches.txt

  • Shows override discrepancies between architectures, which are generally bugs.

http://people.canonical.com/~ubuntu-archive/testing/xenial_probs.html

  • Generated by the half-hourly run of britney and indicates packages that are uninstallable on xenial, usually due to missing dependencies or problematic conflicts.

http://people.canonical.com/~ubuntu-archive/testing/xenial_outdate.html

  • Lists differences between binary and source versions in the archive. This often shows up both build failures (where binaries are out of date for particular architectures) but also where a binary is no longer built from the source.

http://people.canonical.com/~ubuntu-archive/NBS/ http://people.canonical.com/~ubuntu-archive/nbs.html

  • This contains a list of binary packages which are not built from source (NBS) any more. The files contain the list of reverse dependencies of those packages (output of checkrdepends -b). These packages need to be removed eventually, thus all reverse dependencies need to be fixed. This is updated half-hourly.

16. Chroot management

Warning /!\ Please note that chroot management is something generally handled by Canonical IS (and specifically by Adam Conrad). The following section documents the procedures required should one have to, for instance, remove all the chroots for a certain suite to stop the build queue in its tracks while a breakage is hunted down and fixed, but please don't take this as an open invitation to mess with the buildd chroots willy-nilly.

Soyuz stores one chroot per (suite, architecture).

manage-chroot allows the following actions upon a specified chroot: 

  • $ ./manage-chroot
Usage: manage-chroot -a ARCHITECTURE [options] <get|info|remove|set>

manage-chroot: error: You must specify an architecture.

Downloading (get) an existing chroot: 

  • $ ./manage-chroot [-s SUITE] <-a ARCH> get

The chroot will be downloaded and stored in the local disk name as 'chroot-<DISTRIBUTION>-<SERIES>-<ARCHTAG>.tar.bz2'

Uploading (add/update) a new chroot: 

  • $ ./manage-chroot [-s SUITE] <-a ARCH> set -f <CHROOT_FILE>

The new chroot will be immediately used for the next build job in the corresponding architecture.

Disabling (remove) an existing chroot:

Warning /!\ Unless you have plans for creating a new chroots from scratch, it's better to download them to disk before the removal (recover is possible, but involves direct DB access) 

  • $ ./manage-chroot [-s SUITE] <-a ARCH> remove

No builds will be dispatched for architectures with no chroot, the build-farm will continue functional for the rest of the system.

17. Archive administration shifts

This is a next try for establishing Archive Admin shifts during the week. During an AA shift, an archive admin allocates at least 2 hours to work on tasks requiring special ubuntu-archive permissions.

Current members with regular admin shifts are:

  • Monday:
  • Tuesday:
  • Wednesday: sil2100 (9:00-11:00 UTC)
  • Thursday: seb128 (10-12 CET)
  • Friday:

On an archive shifts, the following items should be the main focus:

  • Stay open for any 'ubuntu-archive' IRC requests, being available to help developers out with their everyday work

Additionally, the performing the following should be considered:

  • Process pending archive bugs. This query often generates a Launchpad OOPS rather than succeeding; this query is more likely to succeed, but might miss some bugs. Most of those are syncs, removals, component fixes, but there might be other, less common, requests.

  • Process the NEW queues of the current development release and *-backports of all supported stable releases.

  • If we are not yet in the DebianImportFreeze, run process-removals to review/remove packages which were removed in Debian.

  • Clean up component-mismatches, and poke people to fix dependencies/write MIRs.
  • Remove NBS packages without reverse dependencies, and prod maintainers to rebuild/fix packages to eliminate reverse dependencies to NBS packages.

18. Archive Administration and Freezes

Archive admins should be familiar with the FreezeExceptionProcess, however it is the bug submitter's and sponsor's responsibility to make sure that the process is being followed. Some things to keep in mind for common tasks:

  • When the archive is frozen (ie the week before a Milestone, or from one week before RC until the final release), you need an ACK from ubuntu-release for all main/restricted uploads

  • During the week before final release, you need an ACK from ubuntu-release for any uploads to universe/multiverse

  • When the archive is not frozen, bugfix-only sync requests can be processed if filed by a core-dev, ubuntu-dev or motu (universe/multiverse only) or have an ACK by a sponsor or someone from ubuntu-sponsors.

  • After FeatureFreeze, all (new or otherwise) packages in the archive (ie main, restricted, universe and multiverse) require an ACK from ubuntu-release for any FreezeException (eg FeatureFreeze, UserInterfaceFreeze, and Milestone). Packages that do not require a FreezeException can be processed normally.

See FreezeExceptionProcess for complete details.

19. OEM metapackages

The archive team runs a script, maintained by the DeveloperMembershipBoard, to automatically grant upload rights to oem-*-meta packages - including packages which aren't yet in Ubuntu (uploaders can upload to NEW for these packages) - to some members of Canonical's OEM delivery team via a packageset called "canonical-oem-metapackages".

The DMB handle applications to the packageset and maintain the code. Our responsibility in the archive team is to run the script reasonably frequently, pull any changes when the DMB ask us to, and arrange for its output to be emailed at least to the devel-permissions list.

See the DMB's knowledge base and the script itself for some further information and links.

ArchiveAdministration (last edited 2024-11-12 13:41:12 by tjaalton)