On Thu, Dec 9, 2021 at 11:27 AM Colin Watson <cjwat...@ubuntu.com> wrote: > > On Wed, Feb 03, 2021 at 11:12:57AM +0000, Iain Lane wrote: > > I think the Launchpad support is still missing, although we started on > > this several years ago. That will need to be picked up and finished off: > > > > https://bugs.launchpad.net/launchpad/+bug/1016776 > > > > That bug report talks about doing it pre-release (for devel only) but I > > think I'm now in favour of doing it always, and the proposed > > implementation in there would allow that. For devel, the main reason is > > that I frequently come across users who have misunderstood what proposed > > is for and manually enabled it themsleves, resulting in various degrees > > of brokenness on their systems and bug reports that take developers' > > time to triage and eventually close. These are not (always) people who > > have updated from a previous release, where we could have had tools > > disable -proposed for them, but also people who have explicitly turned > > it on after installing a daily out of an attempt to help test the > > upcoming release. > > > > On the client side, as Robie says, we will at least need to update > > documentation. I'm also not sure what update-manager will do if there > > are NotAutomatic updates present. It might need some tweaking to show > > them differently. This could be checked by looking at something in > > -backports, which is already present with these flags set. > > > > And finally, there's some implication for package builds; both Launchpad > > buildds and other builders would need to ignore this. Launchpad does > > this for -backports currently, i.e. -backports builds get Build-Depends > > from -backports wholesale; hoepfully that means the buildd side isn't > > too hard because we can reuse that. > > This is now ready to use from the Launchpad point of view. There's a > "proposed_not_automatic" flag on distro series exported over the API; if > this is set to True, Launchpad writes "NotAutomatic: yes" and > "ButAutomaticUpgrades: yes" to the Release file. We've also arranged > for *-proposed to be pinned to 500 in launchpad-buildd, so Launchpad > builds will ignore this; I can't speak for other build environments.
Just to clarify, people won't need to manually specify all dependencies, right? For example, if testing the 'systemd' package from -proposed, simply doing 'apt install systemd/jammy-proposed' would install the proposed version of systemd *and also* the proposed version of libsystemd0? Also, is this really needed? Is it really so hard for people to just do: $ sudo add-apt-repository -p proposed ...install proposed package(s) normally and do tests... $ sudo add-apt-repository -r -p proposed > > Thus, from the Launchpad point of view this is ready to use, although > somebody may want to check the behaviour of things like sbuild and > pbuilder first. > > Somebody in ~techboard would need to make the actual change, if you > think it's appropriate. For example, the following in "lp-shell > production devel" would do it for all supported Ubuntu series: > > for name in ("bionic", "focal", "hirsute", "impish", "jammy"): > series = lp.distributions["ubuntu"].getSeries(name_or_version=name) > series.proposed_not_automatic = True > series.lp_save() > > -- > Colin Watson (he/him) [cjwat...@ubuntu.com] > > -- > technical-board mailing list > technical-board@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/technical-board -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board