To enable the proposed archive for Ubuntu 16.04 and later, use the Software & Updates program and ensure that Pre-released updates (release_name-proposed) is ticked in the Developer Options tab.
Click to zoom
To enable the proposed archive for Ubuntu 14.04 use the Software & Updates program and ensure that Pre-release updates (trusty-proposed) is ticked in the Updates tab.
Click to zoom
If the file /etc/apt/sources.list.d/ubuntu.sources exists on your system you can add <release>-proposed to the "Suites:" line. For example:
Types: deb URIs: http://archive.ubuntu.com/ubuntu Suites: noble noble-updates noble-backports noble-proposed Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
Otherwise, you can modify the software sources manually by adding the proposed archive to your apt sources:
cat <<EOF >/etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list # Enable Ubuntu proposed archive deb http://archive.ubuntu.com/ubuntu/ $(lsb_release -cs)-proposed restricted main multiverse universe EOF
If you are using a port arch such as armhf/arm64/ppc64el/s390x you need to add it with the following instead:
cat <<EOF >/etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list # Enable Ubuntu proposed archive deb http://ports.ubuntu.com/ubuntu-ports $(lsb_release -cs)-proposed restricted main multiverse universe EOF
And then run sudo apt update to fetch the new pocket info.
If you are using version 22.04 or lower, it is recommended to enable selective upgrading from -proposed as described in the next section!
Selective upgrading from -proposed
You do not need to enable selective upgrades if you are using 24.04 and above.
After enabling the -proposed archive as shown above, you can configure apt to allow selective installs of packages from it instead of upgrading all of your packages to the -proposed versions:
cat <<EOF >/etc/apt/preferences.d/proposed-updates # Configure apt to allow selective installs of packages from proposed Package: * Pin: release a=$(lsb_release -cs)-proposed Pin-Priority: 400 EOF
With this preference file in place, Update Manager, Synaptic, Aptitude and Apt won't ask for upgrades from the -proposed repositories.
You can test this by simulating an upgrade with apt:
sudo apt-get upgrade -s
If any packages are available for upgrade then the pinning process was set up incorrectly. Make sure you wrote the proper distro name (trusty, precise, etc.).
If you want to see the proposed packages under the 'Upgradable Packages' listing, run aptitude as follows
sudo aptitude -t xenial-proposed
In aptitude, you should first update the package listings ('u' key), mark any of the packages you want to upgrade ('+' key), and finally install them ('g' key). After this, if you run Aptitude without options again, the rest of trusty-proposed upgradable packages will remain hidden.
Alternatively, you can use apt-get to install a package from -proposed by using
sudo apt-get install packagename/xenial-proposed
This method uses a higher priority to install packages.
If you use another release of Ubuntu, replace xenial by your release name everywhere.
Enable Apport
When running proposed it is recommend that you re-enable Apport's bug filing of crash reports. Crashses regarding proposed packages are automatically tagged 'package-from-proposed', so we can distinguish them from other crash reports.
You can enable Apport's reporting of crashes on a stable system by editing /etc/apport/crashdb.conf and changing the following line in the ubuntu section from:
'problem_types': ['Bug', 'Package'],
to:
'problem_types': ['Bug', 'Package', 'Crash'],
To test that Apport is now running, enter the following command to cause a simple crash and generate a crash file in /var/crash:
sh -c 'kill -SEGV $$'
This should notify about the crash and offer you to submit it to Launchpad. Click on 'Report' and verify that the details look complete (package name and version, has a (broken) stack trace, etc.). Please do not actually send it to Launchpad, though, since it is not a genuine bug.
Click to zoom
Installation testing using -proposed
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
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
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 here and add a comment using the template in the description. Thanks!
Verifying Stable Release Updates (SRU) bugs
For extra points please help us verify the fixes to the proposed updates.
You don't have to be very technical to do this kind of testing, simply read how to perform a Stable Release Update verification, read the Stable Release Update procedure and choose the packages you want to test from the Stable Release Update report.
Rolling back
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.