Re: Setting NotAutomatic for hirsute+1-proposed
On Mon, Dec 13, 2021 at 09:44:11AM -0500, Dan Streetman wrote: > On Fri, Dec 10, 2021 at 9:10 AM Robie Basak wrote: > > On Thu, Dec 09, 2021 at 04:27:31PM +, Colin Watson wrote: > > > 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. > > > 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. > > Thank you Colin for the work! > > If sbuild/pbuilder need adjusting, then maybe we need to do that and > > then give developers some time to update their chroots so that we don't > > break them (in non-obvious ways) all at once. > > Another thought is that if there turns out to be an unintended > > consequence for users enabling jammy-proposed (after Jammy's release), > > then we'll have done that to them in an LTS instead of hitting an > > interim release first. > This is certainly a concern for me...this kind of change seems like > it's more appropriate for an interim release. The consequences of the current behavior are sufficiently heinous (users running apt dist-upgrade after enabling -proposed for testing of an unrelated SRU may break their systems, up to and including them unbootable) that I am strongly opposed to deferring this change for after the LTS and delaying another 2 years before it starts to benefit the vast majority of affected users. There may be knock-on consequences in terms of SRU workflows and documentation that needs updated; but we should eat that cost now, not delay this change another LTS cycle. If it were up to me alone, I would want this enabled retroactively for all supported releases. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Setting NotAutomatic for hirsute+1-proposed
On Fri, Dec 10, 2021 at 9:10 AM Robie Basak wrote: > > On Thu, Dec 09, 2021 at 04:27:31PM +, Colin Watson wrote: > > 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. > > > > 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. > > Thank you Colin for the work! > > If sbuild/pbuilder need adjusting, then maybe we need to do that and > then give developers some time to update their chroots so that we don't > break them (in non-obvious ways) all at once. > > Another thought is that if there turns out to be an unintended > consequence for users enabling jammy-proposed (after Jammy's release), > then we'll have done that to them in an LTS instead of hitting an > interim release first. This is certainly a concern for me...this kind of change seems like it's more appropriate for an interim release. > That might adversely affect SRU verification > workflow. But given that jammy-proposed is (after release) specifically > for opt-in and more-risky-than-stable testing, perhaps that doesn't > warrant delaying until Keen. > > -- > 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
Re: Setting NotAutomatic for hirsute+1-proposed
On Mon, Dec 13, 2021 at 9:04 AM Colin Watson wrote: > > On Mon, Dec 13, 2021 at 08:32:53AM -0500, Dan Streetman wrote: > > 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? > > That's how it behaves in my tests, yes - if a dependency imposes a > version constraint requiring a lower-priority version, then apt tries to > satisfy it. > > > 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 > > This has been an issue on and off for at least a decade, so my > impression is that we have solid empirical evidence that this is indeed > too hard for many testers in practice. Ok, but the (non-graphical) method of enabling/disabling the proposed pocket is quite painful on focal and earlier, so maybe now that users can simply use add-apt-repository to enable/disable it with a 1-line command, it might not be as much of an issue? Updating the 'EnableProposed' wiki page might help, since currently it seems hugely over-complicated and out of date. Anyway, if the change is made so apt treats the proposed pocket the same as the backports pocket, i assume (hope) all new systems will have the proposed pocket enabled by default in their sources.list? > > -- > 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
Re: Setting NotAutomatic for hirsute+1-proposed
On Mon, Dec 13, 2021 at 08:32:53AM -0500, Dan Streetman wrote: > 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? That's how it behaves in my tests, yes - if a dependency imposes a version constraint requiring a lower-priority version, then apt tries to satisfy it. > 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 This has been an issue on and off for at least a decade, so my impression is that we have solid empirical evidence that this is indeed too hard for many testers in practice. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Setting NotAutomatic for hirsute+1-proposed
On Thu, Dec 9, 2021 at 11:27 AM Colin Watson wrote:
>
> On Wed, Feb 03, 2021 at 11:12:57AM +, 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
