Diff for "UbuntuBackports"


Differences between revisions 34 and 35
Revision 34 as of 2007-07-05 23:02:06
Size: 8481
Editor: ACC8B9B5
Comment: How to use APT pinning in combination with backports.
Revision 35 as of 2007-07-27 04:54:48
Size: 13144
Editor: SIMMONS-FIVE-FOURTY-SIX
Comment: Expanded development and ways users can contribute
Deletions are marked like this. Additions are marked like this.
Line 104: Line 104:
When you need a package backported which isn't currently available, create a new bug report in the Backports Product of Launchpad (for Dapper: [https://launchpad.net/products/dapper-backports/+filebug], for Edgy: [https://launchpad.net/products/edgy-backports/+filebug], for Feisty: [https://launchpad.net/products/feisty-backports/+filebug]). Choose a good summary that will quickly indicate what's need (e.g. "Please backport Bittornado"). Indicate the current Dapper version of the package and version being requested. If you've checked, indicate if the requested version has entered Edgy (and Feisty) to make our lives easier! When you need a package backported which isn't currently available, create a new bug report in the Backports Product of Launchpad (for Dapper: [https://launchpad.net/products/dapper-backports/+filebug], for Edgy: [https://launchpad.net/products/edgy-backports/+filebug], for Feisty: [https://launchpad.net/products/feisty-backports/+filebug]). Choose a good summary that will quickly indicate what's need (e.g. "Please backport Bittornado"). Indicate the current version of the package and version you would like. If you've checked, indicate if the requested version has entered Edgy (and Feisty) to make our lives easier!
Line 108: Line 108:
 1. Only packages currently in Ubuntu's development branches are eligible for backporting  1. Only packages currently in Ubuntu's development branches are eligible for backporting. We do NOT take packages from Debian repositories, unofficial repositories, or user-contributed source or binary packages.
Line 113: Line 113:
 1. Applications to be backported must have meaningful bug/security fixes or features.  1. Applications to be backported must have meaningful benefits to the user not attainable via other processes. Specifically:
   1. The sole purpose must not be to fix a bug or security vulnerability. There are more correct processes for these types of defects (specifically Security team and StableReleaseUpdates). Exceptions may be granted '''ONLY''' in the case that the other processes have failed or refused to address the issue. Please, for bugfixes, try StableReleaseUpdates first. We will reject any Backports requests for bugfixes if SRU has not been attempted.
   1. The application, therefore, should have some significant new feature or benefits.
Line 117: Line 119:
{{{TODO}}} Backports is largely powered by users and volunteers. We would appreciate any and all community involvement, but ask that it'd be constructive towards the progress of Backports. Some suggestions include:
 * Filing requests. We wouldn't know what to do without your input :)
 * Helping to sift through requests, looking for obviously invalid ones, such as ones listed above in the rules.
 * Helping to build test packages, or feed package requests to [http://sharkattack.media.mit.edu/request Sharkattack]
 * Helping to test built packages for proper functionality.
 * Helping to raise community awareness and get others involved.
Line 119: Line 126:
= Backport Process =


 1. User files request as described above.
 1. A test build of the backport is attempted. Possible ways include:
   * The pbuilder or [Prevu] build tool is used to generate testing .debs. Both are equally acceptable; Ubuntu developers would tend to have pbuilder already set up and ready to use, while most users would opt for Prevu's simpler setup routine and backporting convenience.
   * A new automated build system, called [http://sharkattack.media.mit.edu/ Sharkattack], is used to automatically generate testing debs. Sharkattack is easier to use, as it's a purely web-driven application. To request a backport, you simply have to fill out a form indicating what package you want, where you want to backport from/to, and an e-mail address to subscribe to build status. You can even paste in a Launchpad bug URL for the e-mail and it will send notifications directly to a bug ticket. Build logs are available, along with APT repositories containing binaries for i386 (if the build succeeds of course)
     * '''FYI''': Sharkattack uses a slightly modified version of prevu, which will build packages in a very similar fashion to official build servers.
     * '''NOTE''': Sharkattack is still beta-quality in development software, and as such it may not always be up or fast.
   * '''No other build methods will be accepted''' -- Please do not compile from source manually, use checkinstall, use dpkg-buildpackage, .debs from other websites, or any other testing method. It is of no use to our testing.
 1. If a test build has succeeded, the bug ticket should be marked '''''CONFIRMED''''' and a comment should be added asking for testing feedback.
 1. Users and backporters should try to install and run the built test packages (if none were provided, they should attempt a build themselves using the accepted methods.
   * This is a very important step. Several times before, I've caught packages that build correctly but either do not install, or crash upon running. Don't be hasty!
 1. If the package runs well, please mark as '''''TRIAGED'''''
 1. Users and backporters should continue testing, even when the bug is in a Triaged state.
 1. Once Backporters are sufficiently satisfied with the testing coverage, the package will be marked for approval.
   * A backporter will mark the bug status as '''''IN PROGRESS''''' and subscribe team ''ubuntu-archive''
 1. Ubuntu Archive Admins will, in about a week's time, push out backports builds to all the mirrors. They will mark the bug '''''FIX RELEASED'''''

As far as changing the status on the bug tickets, we welcome users to set bugs to any of the above states as appropriate, except the "In Progress", "Fix Committed", and "Fix Released" states. These are limited to authorized backports or core developers.
== Failure Modes ==
 1. ''INCOMPLETE'': A package requested is not currently in Ubuntu repositories but is expected to be in the future. Also packages that were abandoned during testing phase.
 1. ''INVALID'': A package requested is not available in Ubuntu repositories and not expected to be. Also, a package that failed any of the above testing stages.
 1. ''WONTFIX'': A valid backport that is too complex, requires source changes, has stale testing, or for some other reason Backporters are not willing to perform the request.

What are Backports

Ubuntu releases a new version of its OS every 6 months. After a release, the version of all packages stays constant for the entire 6 months. For example, if Ubuntu ships with Firefox 1.0.x, it will remain at Firefox 1.0.x for the entire 6-month release cycle, even if a later version gets released during this time. The Ubuntu team may apply important security fixes to 1.0.x, but any new features or non-security bugfixes won't be made available.

This is where Ubuntu Backports comes in. The Backports team believes that the best update policy is a mix of Ubuntu's security-only policy AND providing new versions of some programs. Candidates for version updates are primarily desktop applications, such as your web browser, word processor, IRC client, IM client, and so on. These can be updated without replacing a chunk of the operating system that would affect stability of the whole system.

Backports also include an extras repository which holds some packages which are not found in the official package collections. These include mainly legally-risky packages, for example many multimedia formats which are patent protected or some freeware commercial programs like the Adobe Acrobat Reader or Sun's Java Runtime Enviroment/Development Kit which are protected by a strict EULA.

As of June 2005, we are also an official Ubuntu project, so we are acknowledged by the developers.

Stability

Backports candidates are tested by several Backports developers before they are allowed to be placed in the repository. Backports packages are thus safer to use than the development distribution. At minimum the packages should be usable in a manner that the average Backports developer could test. However, given the nature of introducing newer versioned packages from a development distribution into a stable, released distribution, problems can arise. The most common side-effects would be a bug that escaped testing, or a new configuration file format (or other kind of incompatibility). If you have problems with a Backports package please report it in the [https://launchpad.net/products/feisty-backports/+filebug Backports bugtracker] and not the main Ubuntu one.

How to use

First make sure you have the Updates and Security [https://help.ubuntu.com/community/Repositories repositories] enabled (also available for [https://help.ubuntu.com/community/Repositories/Kubuntu Kubuntu]), as some packages from Backports rely on them. In addition, verify each repository has the "main, restricted, universe, and multiverse" components enabled. Backports will at times cross into a separate component in a manner that would be disallowed in other official repositories.

Installing a single package

A list of packages in Backports can be found at [http://packages.ubuntu.com/ the Ubuntu packages site] ([http://packages.ubuntu.com/feisty-backports/ Feisty], [http://packages.ubuntu.com/edgy-backports Edgy], and [http://packages.ubuntu.com/dapper-backports/ Dapper] backports).

Packages can be downloaded using your browser (choose the correct link for your system under the "Architecture" column)

Right-clicking on a downloaded package will offer an option to install the package. Downloaded packages can also be installed from a shell by typing

sudo dpkg -i ~/Desktop/<filename>.deb

(assuming the package was downloaded to the desktop).

After installing a package, it is advised to run

sudo apt-get -f update

in order to resolve any pending dependency issues.

Another method for installing a single package is to enable the whole repository, but use pinning so that it is only used when specifically requested -- see below.

Enabling the entire repository

Command Line Interface

Just add the following lines to your /etc/apt/sources.list :

For Feisty Fawn 7.04:BR deb http://archive.ubuntu.com/ubuntu feisty-backports main universe multiverse restricted

For Edgy Eft 6.10:BR deb http://archive.ubuntu.com/ubuntu edgy-backports main universe multiverse restricted

For Dapper Drake 6.06:BR deb http://archive.ubuntu.com/ubuntu dapper-backports main universe multiverse restricted

Now issue the command: sudo apt-get update

Through Package Manager

Adept (Kubuntu)

Using the directions on the [https://help.ubuntu.com/community/Repositories/Kubuntu How To Add Repositories Page for Kubuntu], just activate the Unsupported updates in the Updates tab.

Synaptic (Ubuntu, Xubuntu)

Using the directions on the [https://help.ubuntu.com/community/Repositories/Ubuntu How To Add Repositories Page for Ubuntu]; and the following information for each section:

For Feisty Fawn 7.04: {{{url: http://archive.ubuntu.com/ubuntu distribution: feisty-backports sections: main universe multiverse restricted }}}

For Edgy Eft 6.10: {{{url: http://archive.ubuntu.com/ubuntu distribution: edgy-backports sections: main universe multiverse restricted }}}

For Dapper Drake 6.06: {{{url: http://archive.ubuntu.com/ubuntu distribution: dapper-backports sections: main universe multiverse restricted }}}

Use pinning to limit the backports repository

You may want to keep your system as close to the normal repositories as possible, and only use the backports when you have to. APT has a mechanism called pinning that will allow you to do this. Assuming you are using 'feisty', save the following text in /etc/apt/preferences (which might not already exist):

{{{Package: * Pin: release a=feisty-backports Pin-Priority: 400 }}}

This code will set the priority for the 'feisty-backports' archive to 400, which is lower than the default (500), so that apt-get will not automatically upgrade to packages in the backports repository. The line release a=feisty-backports selects packages that belong to the 'Archive' (or 'Suite') called 'feisty-backports'. If you are not using feisty, look in /var/lib/apt/lists/*_Release to find the values to use in this line.

If you actually want to install packages from the backports, you will have to use the -t (target) option to apt-get. To upgrade a single package e.g. amarok, do this:

sudo apt-get install -t feisty-backports amarok

(Using -t is equivalent to setting a Pin-Priority of 990, so the priority for feisty-backports packages now beats that for the feisty, and the new version of amarok, with its dependencies, will be installed).

To see what is available in backports for upgrading, do:

sudo apt-get upgrade -u -t feisty-backports

Anchor(request-new-packages)

How to request new packages

When you need a package backported which isn't currently available, create a new bug report in the Backports Product of Launchpad (for Dapper: [https://launchpad.net/products/dapper-backports/+filebug], for Edgy: [https://launchpad.net/products/edgy-backports/+filebug], for Feisty: [https://launchpad.net/products/feisty-backports/+filebug]). Choose a good summary that will quickly indicate what's need (e.g. "Please backport Bittornado"). Indicate the current version of the package and version you would like. If you've checked, indicate if the requested version has entered Edgy (and Feisty) to make our lives easier!

These are the rules we try to follow when backporting packages:

  1. Only packages currently in Ubuntu's development branches are eligible for backporting. We do NOT take packages from Debian repositories, unofficial repositories, or user-contributed source or binary packages.
  2. Backports of large, interdepending application stacks are bad!
  3. New versions can be backported, when they're already compatible with OS and system-relevant libraries.
  4. No new libraries which will "break" or affect other applications (e.g. libvorbis, libz, etc.) unless the update fixes an exploit.
  5. No changes to language interpreters (python, mono). These could affect existing packages in unexpected ways.
  6. Applications to be backported must have meaningful benefits to the user not attainable via other processes. Specifically:
    1. The sole purpose must not be to fix a bug or security vulnerability. There are more correct processes for these types of defects (specifically Security team and StableReleaseUpdates). Exceptions may be granted ONLY in the case that the other processes have failed or refused to address the issue. Please, for bugfixes, try StableReleaseUpdates first. We will reject any Backports requests for bugfixes if SRU has not been attempted.

    2. The application, therefore, should have some significant new feature or benefits.

How to Help

Backports is largely powered by users and volunteers. We would appreciate any and all community involvement, but ask that it'd be constructive towards the progress of Backports. Some suggestions include:

  • Filing requests. We wouldn't know what to do without your input Smile :)

  • Helping to sift through requests, looking for obviously invalid ones, such as ones listed above in the rules.
  • Helping to build test packages, or feed package requests to [http://sharkattack.media.mit.edu/request Sharkattack]

  • Helping to test built packages for proper functionality.
  • Helping to raise community awareness and get others involved.

Backport Process

  1. User files request as described above.
  2. A test build of the backport is attempted. Possible ways include:
    • The pbuilder or [Prevu] build tool is used to generate testing .debs. Both are equally acceptable; Ubuntu developers would tend to have pbuilder already set up and ready to use, while most users would opt for Prevu's simpler setup routine and backporting convenience.
    • A new automated build system, called [http://sharkattack.media.mit.edu/ Sharkattack], is used to automatically generate testing debs. Sharkattack is easier to use, as it's a purely web-driven application. To request a backport, you simply have to fill out a form indicating what package you want, where you want to backport from/to, and an e-mail address to subscribe to build status. You can even paste in a Launchpad bug URL for the e-mail and it will send notifications directly to a bug ticket. Build logs are available, along with APT repositories containing binaries for i386 (if the build succeeds of course)

      • FYI: Sharkattack uses a slightly modified version of prevu, which will build packages in a very similar fashion to official build servers.

      • NOTE: Sharkattack is still beta-quality in development software, and as such it may not always be up or fast.

    • No other build methods will be accepted -- Please do not compile from source manually, use checkinstall, use dpkg-buildpackage, .debs from other websites, or any other testing method. It is of no use to our testing.

  3. If a test build has succeeded, the bug ticket should be marked CONFIRMED and a comment should be added asking for testing feedback.

  4. Users and backporters should try to install and run the built test packages (if none were provided, they should attempt a build themselves using the accepted methods.
    • This is a very important step. Several times before, I've caught packages that build correctly but either do not install, or crash upon running. Don't be hasty!
  5. If the package runs well, please mark as TRIAGED

  6. Users and backporters should continue testing, even when the bug is in a Triaged state.
  7. Once Backporters are sufficiently satisfied with the testing coverage, the package will be marked for approval.
    • A backporter will mark the bug status as IN PROGRESS and subscribe team ubuntu-archive

  8. Ubuntu Archive Admins will, in about a week's time, push out backports builds to all the mirrors. They will mark the bug FIX RELEASED

As far as changing the status on the bug tickets, we welcome users to set bugs to any of the above states as appropriate, except the "In Progress", "Fix Committed", and "Fix Released" states. These are limited to authorized backports or core developers.

Failure Modes

  1. INCOMPLETE: A package requested is not currently in Ubuntu repositories but is expected to be in the future. Also packages that were abandoned during testing phase.

  2. INVALID: A package requested is not available in Ubuntu repositories and not expected to be. Also, a package that failed any of the above testing stages.

  3. WONTFIX: A valid backport that is too complex, requires source changes, has stale testing, or for some other reason Backporters are not willing to perform the request.

Useful Links


CategoryUbuntuTeams CategoryDocumentation CategoryCleanup

UbuntuBackports (last edited 2022-01-13 17:06:47 by ddstreet)