Testing/EnableProposed

Migrated content

This page has been ported from the previous wiki as-is.

Some of the formatting is likely to be broken.
The content may be outdated and needs to be reviewed.
Where the content has since migrated elsewhere, a link is provided to the new page.

How to enable proposed

Enable the -proposed pocket in order to test new packages before they are released to -updates.

This section has moved. See the Enable proposed article in the Ubuntu Project documentation.

Selective upgrading from proposed

This section on APT pinning only applies to Ubuntu 22.04 LTS and earlier releases.

This section has moved. See the On Ubuntu 22.04 LTS and older section in the Enable Proposed article in the Ubuntu Project documentation.

Enable Apport

This section has migrated, and was incorporated into the bug reporting section of the Ubuntu Project documentation.

This section has moved, and is now part of the Report a bug article. If you are interested in Apport, you might also find the Debugging section of the Ubuntu Project documentation useful.

Installation testing using -proposed

Obsolete

The apt-setup/proposed=true parameter was specific to the legacy debian-installer netboot images. Modern Subiquity installer testing flows are handled differently.

Sometimes you may be asked to test a netboot installer image from trusty-proposed. The images may be found here (replace "i386" with your architecture as necessary):

http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-i386/

In order to install successfully from these images, you will normally need to tell the installer to fetch its own components from -proposed as well, which is not the default. To do this, add the following boot parameter:

apt-setup/proposed=true

You must make sure that the mirror you are installing from contains packages from -proposed. All official mirrors will do so; if you operate your own mirror or use a site-local mirror, it may need to be modified to pull from -proposed. Make sure that you do not simply use a loopback mount of a CD or DVD image as an installation source; this is one of the cases where such mirrors will not work, since they do not contain the updated kernel packages required by the new installer.

Uploading your hardware profile

Obsolete

The legacy checkbox-gtk hardware submission flow has been replaced by modern QA tracking.

To help us track the hardware test coverage, please upload your hardware profile for the system you will run proposed on using the hardware testing tool, found in the System -> Administration menu or with the command checkbox-gtk.

You can see your submitted information at https://launchpad.net/people/+me/+hwdb-submissions

Register your participation

Obsolete

The legacy Launchpad bug tracking method (proposed-tracking architecture bugs) is no longer the standard process.

We have set up an improvised way of tracking -proposed archive coverage using the bug tracker in Launchpad (but we are designing a more automated solution). To register your participation please select the appropriate bug for your architecture [[1]] and add a comment using the template in the description. Thanks!

Verifying Stable Release Updates (SRU) bugs

This section has migrated. All documentation about SRUs is now found in the Ubuntu Project documentation.

SRU verification page in the Ubuntu Project documentation.

Rolling back

Needs review

This section was not migrated to the Ubuntu Project docs. The manual apt-offline rollback procedure was not ported. Modern environments generally recommend using filesystem snapshots (like ZFS) or testing on disposable VMs.

Sometimes proposed makes a mess of things, especially if you're on a development release. An example of such a terrible scenario would be losing networking. Here's how to fix that:

Comment or remove any entries related to proposed in `/etc/apt/sources{.list,.d/*}`.
Set pinning to allow for downgrades. See above about selective upgrades. The priority of the normal repos should be 1000 and proposed -10.
On a machine that has Internet, go grab the latest .deb for apt-offline for your version and architecture. It only depends upon apt, less, and python, so you should have the depends.
Transfer the .deb file over to the broken computer.
Install the package, e.g. `dpkg -i /path/to/apt-offline*.deb`.
Allow downgrades when using `--yes` (which apt-offline uses). Add `APT::Get::allow-downgrades "true";` to some file like `/etc/apt/apt.conf.d/99-unproposed`.
On the broken computer, gather the necessary information with `apt-offline set SOME-NAME.sig --upgrade-type dist-upgrade --release CODENAME`.
Copy SOME-NAME.sig to the computer with Internet
Grab the indices and files with `apt-offline get SOME-NAME.sig --bundle SOME-NAME.zip`.
Copy SOME-NAME.zip to the broken computer.
Install with `apt-offline install SOME-NAME.zip`
You might want to remove the pinning, especially if you plan to use proposed again at some later point.
Absolutely remove the file that allows downgrades. That's relatively dangerous.

Note this will technically roll back to what is currently in release. If whatever broke things in proposed migrated to release by the time you went to do this, it might be for naught. However, that's less likely to happen, except perhaps if you're on a development release.