Re: Setting NotAutomatic for hirsute+1-proposed
On Sat, Jan 21, 2023 at 08:30:33PM +0100, Gunnar Hjalmarsson wrote: On 2023-01-20 21:47, Steve Langasek wrote: On Thu, Jan 19, 2023 at 01:44:12PM +0100, Gunnar Hjalmarsson wrote: On 2021-01-21 11:20, Robie Basak wrote: https://wiki.ubuntu.com/Testing/EnableProposed will need a rework though. We link to that from every SRU bug. That page was last updated on 2020-06-19, and is obsolete. Would be great i someone could follow up the change and edit the Testing/EnableProposed page so it makes sense again. Have you run into problems with the instructions on that page? I skimmed it and aside from mentioning "Selective upgrading from -proposed" which is redundant for newer releases, I don't immediately see anything incorrect there. If you can point out where it's wrong, I'll happily edit it to correct it but I don't have time just now to run through the full instructions there to find out what doesn't work. Maybe the change of behavior here is the confusing bit? Previously, following the first part of the guide (before the "selective upgrading" docs) would be enough to install the desired package(s) from proposed without specifying the pocket in the apt command. First I have to admit that I thought the change had been implemented already in jammy. I see now that that's not the case, at least not yet. As regards the contents of the wiki page, you are right and I stand corrected — there is not much of directly incorrect information. I think it's mostly about my personal taste: I have long thought that the page is overly complicated. I made use of Ask Ubuntu to illustrate what a less wordy page might look like: https://askubuntu.com/questions/1451256 That Ask Ubuntu answer is not exactly targeted people like the ones who have participated in this list thread. I have rather the not so tech savvy user in mind, like a bug reporter who wants to help verify a proposed SRU fix. I simply fear that the current wiki page contains so much information, so a prospective tester may be discouraged to follow through. Perhaps, in the first section, after "It is recommended to enable selective upgrading from -proposed as described in the next section!" we could metion the NotAutomatic setting and point out that just creating the file under /etc/apt/sources.list.d/, as shown in the guide, will no loger make the user's system to prefer newer packages from proposed, as it would happen in the past. Instead, they should follow the next section (selective upgrading from -proposed). If they desire the former behavior they could change the preferences file priority as well. -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Athos Ribeiro -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
On 2023-01-20 21:47, Steve Langasek wrote: On Thu, Jan 19, 2023 at 01:44:12PM +0100, Gunnar Hjalmarsson wrote: On 2021-01-21 11:20, Robie Basak wrote: https://wiki.ubuntu.com/Testing/EnableProposed will need a rework though. We link to that from every SRU bug. That page was last updated on 2020-06-19, and is obsolete. Would be great i someone could follow up the change and edit the Testing/EnableProposed page so it makes sense again. Have you run into problems with the instructions on that page? I skimmed it and aside from mentioning "Selective upgrading from -proposed" which is redundant for newer releases, I don't immediately see anything incorrect there. If you can point out where it's wrong, I'll happily edit it to correct it but I don't have time just now to run through the full instructions there to find out what doesn't work. First I have to admit that I thought the change had been implemented already in jammy. I see now that that's not the case, at least not yet. As regards the contents of the wiki page, you are right and I stand corrected — there is not much of directly incorrect information. I think it's mostly about my personal taste: I have long thought that the page is overly complicated. I made use of Ask Ubuntu to illustrate what a less wordy page might look like: https://askubuntu.com/questions/1451256 That Ask Ubuntu answer is not exactly targeted people like the ones who have participated in this list thread. I have rather the not so tech savvy user in mind, like a bug reporter who wants to help verify a proposed SRU fix. I simply fear that the current wiki page contains so much information, so a prospective tester may be discouraged to follow through. -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
On Thu, Jan 19, 2023 at 01:44:12PM +0100, Gunnar Hjalmarsson wrote: > On 2021-01-21 11:20, Robie Basak wrote: > > https://wiki.ubuntu.com/Testing/EnableProposed will need a rework > > though. We link to that from every SRU bug. > That page was last updated on 2020-06-19, and is obsolete. Would be great i > someone could follow up the change and edit the Testing/EnableProposed page > so it makes sense again. Have you run into problems with the instructions on that page? I skimmed it and aside from mentioning "Selective upgrading from -proposed" which is redundant for newer releases, I don't immediately see anything incorrect there. If you can point out where it's wrong, I'll happily edit it to correct it but I don't have time just now to run through the full instructions there to find out what doesn't work. -- 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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
On 2021-01-21 11:20, Robie Basak wrote: https://wiki.ubuntu.com/Testing/EnableProposed will need a rework though. We link to that from every SRU bug. That page was last updated on 2020-06-19, and is obsolete. Would be great i someone could follow up the change and edit the Testing/EnableProposed page so it makes sense again. -- Thanks, Gunnar Hjalmarsson https://launchpad.net/~gunnarhj -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
Sebastien Bacher wrote on 22/11/2022: > Le 22/11/2022 à 20:24, Julian Andres Klode a écrit : >> We have no idea why the test dependencies are failing to install in a >> normal setup, > > Which case are you talking about? The dbus issue is clear, the base > image used by the autopkgtest infra is build from kinetic with > kinety-security versions of packages but the apt source are lunar ones > without proposed. The packages are failing to install because > kinetic-security has updates which are in lunar-proposed but didn't > migrate to lunar. A follow-up on this. The curl package also had the same issue, as the version in kinetic was newer than the version in lunar-release. Now curl migrated, and we are not aware of other problematic packages (i.e. packages in the lunar autopkgtest images which are not available in lunar-release). So for the Lunar cycle this issue is behind us. Starting from the MM cycle we'll generate the early autopkgtest images using the *release* images of the previous release, instead of using dailies. In this way we'll avoid having packages in the autopkgtest images which are not in the release pocket of the new devel release. Paride -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
I'm saying the error message here is not entirely relevant as I've said multiple times before, because it is the result of a broken autopkgtest pinning setup. There might be other reasons the test dependencies are not installable that we do not see because our fallback is broken and we don't have a useful error message before that when we had working pinning. If that dbus update is the only issue it can be worked around by retrying with an addition dbus trigger so that libdbus-1-dev from proposed is used. Sebastien Bacher schrieb am Di., 22. Nov. 2022, 20:49: > Le 22/11/2022 à 20:24, Julian Andres Klode a écrit : > > We have no idea why the test dependencies are failing to install in a > > normal setup, > > > Which case are you talking about? The dbus issue is clear, the base > image used by the autopkgtest infra is build from kinetic with > kinety-security versions of packages but the apt source are lunar ones > without proposed. The packages are failing to install because > kinetic-security has updates which are in lunar-proposed but didn't > migrate to lunar. > > Cheers, > Sebastien > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
Le 22/11/2022 à 20:24, Julian Andres Klode a écrit : We have no idea why the test dependencies are failing to install in a normal setup, Which case are you talking about? The dbus issue is clear, the base image used by the autopkgtest infra is build from kinetic with kinety-security versions of packages but the apt source are lunar ones without proposed. The packages are failing to install because kinetic-security has updates which are in lunar-proposed but didn't migrate to lunar. Cheers, Sebastien -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
No bumping it doesn't help. The version in the release pocket is still not installable, and what's broken here is the fallback in autopkgtest to retry with all-proposed, because it removes the pin (thus restoring NotAutomatic, aka no-proposed) rather than adding a pin for proposed at priority 500. We have no idea why the test dependencies are failing to install in a normal setup, before the all-proposed retry, but people are of course free to retry with the dpkg in proposed as an additional trigger, thus ensuring it's not broken before the broken all-proposed fallback. Dimitri John Ledkov schrieb am Di., 22. Nov. 2022, 19:59: > In such cases it is usually best to bump version number, and do a fresh > upload to lunar-proposed such that it is higher than any of (kinetic, > lunar). > > Might make sense to still upload no change rebuild of dbus into > lunar-proposed. > > On Tue, 22 Nov 2022, 18:45 Sebastien Bacher, wrote: > >> Hey there, >> >> Le 22/11/2022 à 18:21, Paride Legovini a écrit : >> > The dbus package has now need force-migrated from lunar-proposed to >> > -release (currently pending publication). This should fix the issue. >> >> I've stated that via chat but I still disagree that was the right thing >> to do. Without tests result how are we confident that the update isn't >> bringing a regression (one other update in lunar could create issue for >> the dbus in proposed)? Why didn't we fix the autopkgtest setup to use an >> lunar image or enable proposed to allow the tests to be correctly tried >> instead? >> >> Also are we confident that they aren't other packages in the same >> situations? >> >> Cheers, >> Sebastien >> >> >> -- >> ubuntu-devel mailing list >> ubuntu-devel@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >> > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
In such cases it is usually best to bump version number, and do a fresh upload to lunar-proposed such that it is higher than any of (kinetic, lunar). Might make sense to still upload no change rebuild of dbus into lunar-proposed. On Tue, 22 Nov 2022, 18:45 Sebastien Bacher, wrote: > Hey there, > > Le 22/11/2022 à 18:21, Paride Legovini a écrit : > > The dbus package has now need force-migrated from lunar-proposed to > > -release (currently pending publication). This should fix the issue. > > I've stated that via chat but I still disagree that was the right thing > to do. Without tests result how are we confident that the update isn't > bringing a regression (one other update in lunar could create issue for > the dbus in proposed)? Why didn't we fix the autopkgtest setup to use an > lunar image or enable proposed to allow the tests to be correctly tried > instead? > > Also are we confident that they aren't other packages in the same > situations? > > Cheers, > Sebastien > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
Hey there, Le 22/11/2022 à 18:21, Paride Legovini a écrit : The dbus package has now need force-migrated from lunar-proposed to -release (currently pending publication). This should fix the issue. I've stated that via chat but I still disagree that was the right thing to do. Without tests result how are we confident that the update isn't bringing a regression (one other update in lunar could create issue for the dbus in proposed)? Why didn't we fix the autopkgtest setup to use an lunar image or enable proposed to allow the tests to be correctly tried instead? Also are we confident that they aren't other packages in the same situations? Cheers, Sebastien -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
Hi Jeremy, Jeremy Bicha wrote on 22/11/2022: > On Tue, Nov 8, 2022 at 6:05 AM Paride Legovini wrote: >> Steve Langasek wrote on 01/11/2022: >>> I have set the flag now for lunar as it came up in discussion with >>> Foundations. The question of whether to change this for stable series is >>> still open (now with some further series that are stable) but can be >>> discussed separately. >> >> I very much welcome this change, but I think we're now missing an easy >> way to build (sbuild) packages with -proposed fully enabled. schroots >> created by mk-sbuild and sbuild-launchpad-chroot may have -proposed in >> sources.list, but that's not going to be used in >= Lunar. On Launchpad >> some extra pinning is done to fully enable -proposed [1]. >> >> One way to re-enable easy builds with full -proposed could be modifying >> sbuild-launchpad-chroot (/etc/schroot/setup.d/90apt-sources) to do the >> same pinning that Launchpad does [1]. Once we have a way to sbuild with >> -proposed enabled I think enabling NotAutomatic for the stable releases >> would be a good idea: other than helping with SRU verification, the >> change will keep the -proposed behavior uniform across releases. >> >> Paride >> >> [1] >> https://git.launchpad.net/launchpad-buildd/commit/?id=c2ebcb6752af496166a5fffd9df3a4d6df6048ef > > Gianfranco pointed out that there are dbus installability problems in > the lunar autopkgtests. For instance: > https://autopkgtest.ubuntu.com/packages/c/cinnamon-control-center/lunar/amd64 > > libdbus-1-dev : Depends: libdbus-1-3 (= 1.14.0-2ubuntu2) but > 1.14.0-2ubuntu3 is to be installed > > dbus 1.14.0-2ubuntu3 is built and I think it was published correctly > but it hasn't migrated out of lunar-proposed yet. > > Is the breakage fallout from the changes to how proposed is handled for lunar? Not really: this is due to a version skew in the archive caused by a dbus SRU upload done to Kinetic before Lunar was open. This caused the dbus version in kinetic-updates to be newer than the version in lunar-release. The dbus package has now need force-migrated from lunar-proposed to -release (currently pending publication). This should fix the issue. One (unrelated) autopkgtest aspect that is affected by NotAutomatic: yes is triggering tests with all-proposed=1. This is currently not working as expected as we're not setting the pin yet. Paride -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
On Tue, Nov 8, 2022 at 6:05 AM Paride Legovini wrote: > Steve Langasek wrote on 01/11/2022: > > I have set the flag now for lunar as it came up in discussion with > > Foundations. The question of whether to change this for stable series is > > still open (now with some further series that are stable) but can be > > discussed separately. > > I very much welcome this change, but I think we're now missing an easy > way to build (sbuild) packages with -proposed fully enabled. schroots > created by mk-sbuild and sbuild-launchpad-chroot may have -proposed in > sources.list, but that's not going to be used in >= Lunar. On Launchpad > some extra pinning is done to fully enable -proposed [1]. > > One way to re-enable easy builds with full -proposed could be modifying > sbuild-launchpad-chroot (/etc/schroot/setup.d/90apt-sources) to do the > same pinning that Launchpad does [1]. Once we have a way to sbuild with > -proposed enabled I think enabling NotAutomatic for the stable releases > would be a good idea: other than helping with SRU verification, the > change will keep the -proposed behavior uniform across releases. > > Paride > > [1] > https://git.launchpad.net/launchpad-buildd/commit/?id=c2ebcb6752af496166a5fffd9df3a4d6df6048ef Gianfranco pointed out that there are dbus installability problems in the lunar autopkgtests. For instance: https://autopkgtest.ubuntu.com/packages/c/cinnamon-control-center/lunar/amd64 libdbus-1-dev : Depends: libdbus-1-3 (= 1.14.0-2ubuntu2) but 1.14.0-2ubuntu3 is to be installed dbus 1.14.0-2ubuntu3 is built and I think it was published correctly but it hasn't migrated out of lunar-proposed yet. Is the breakage fallout from the changes to how proposed is handled for lunar? Thank you, Jeremy Bicha -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
Steve Langasek wrote on 01/11/2022: > I have set the flag now for lunar as it came up in discussion with > Foundations. The question of whether to change this for stable series is > still open (now with some further series that are stable) but can be > discussed separately. I very much welcome this change, but I think we're now missing an easy way to build (sbuild) packages with -proposed fully enabled. schroots created by mk-sbuild and sbuild-launchpad-chroot may have -proposed in sources.list, but that's not going to be used in >= Lunar. On Launchpad some extra pinning is done to fully enable -proposed [1]. One way to re-enable easy builds with full -proposed could be modifying sbuild-launchpad-chroot (/etc/schroot/setup.d/90apt-sources) to do the same pinning that Launchpad does [1]. Once we have a way to sbuild with -proposed enabled I think enabling NotAutomatic for the stable releases would be a good idea: other than helping with SRU verification, the change will keep the -proposed behavior uniform across releases. Paride [1] https://git.launchpad.net/launchpad-buildd/commit/?id=c2ebcb6752af496166a5fffd9df3a4d6df6048ef -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
On Tue, Nov 01, 2022 at 12:22:00PM +0100, Steve Langasek wrote: > Unfortunately this discussion foundered on lack of consensus about whether > to make this change after the fact for stable series; which resulted in both > jammy and kinetic going out without this being set. > > I have set the flag now for lunar as it came up in discussion with > Foundations. The question of whether to change this for stable series is > still open (now with some further series that are stable) but can be > discussed separately. Cool, thanks. > Colin, will this flag be inherited in the future at series opening? Yes. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
Unfortunately this discussion foundered on lack of consensus about whether
to make this change after the fact for stable series; which resulted in both
jammy and kinetic going out without this being set.
I have set the flag now for lunar as it came up in discussion with
Foundations. The question of whether to change this for stable series is
still open (now with some further series that are stable) but can be
discussed separately.
Colin, will this flag be inherited in the future at series opening?
On Thu, Dec 09, 2021 at 04:27:31PM +, 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.
>
> 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-bo...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board
Thanks,
--
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
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
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-bo...@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/technical-board -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
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-bo...@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/technical-board -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
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] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
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-bo...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
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. 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. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
On Thu, Dec 09, 2021 at 05:53:20PM +0100, Julian Andres Klode wrote: > We only should do it for jammy though, and not risk breaking scripts > for testing stable releases IMO. The benefit of this change to people running stable releases is just as great as for those running devel. Arguably moreso, as we actually instruct people to enable proposed to test updates. There's a strong case for making that far less risky. I can see a case for trying to anticipate any scripts which might break though, and/or trying by enabling *one* stable release to see how it goes. And there's documentation to update as previously mentioned in this thread. This will probably want to be squared off before enabling, so it may well make sense to do dev first and stables some time later on. Thanks a lot to Colin for working on this. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
On Thu, Dec 09, 2021 at 04:27:31PM +, 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.
>
> 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()
We only should do it for jammy though, and not risk breaking scripts
for testing stable releases IMO.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
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.
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]
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
On Wed, Feb 03, 2021 at 11:12:57AM +, Iain Lane wrote: > On Thu, Jan 21, 2021 at 02:15:59AM -0800, Julian Andres Klode wrote: > > Hi people, > > > > I'd like to suggest that we start setting NotAutomatic: yes for the > > proposed pocket with hirsute+1, such that things like SRU verification > > will be easier, and all those people who enable proposed in sources.list > > for I don't know what reasons don't get their systems destroyed as much. > > > > This would obviously require some changes to pin the repo back up on the > > builders, but I think it would be useful overall. > > Sounds good to me. > > 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. Just as a reminder ubuntu-release-upgrader does disable -proposed during the upgrade to a development release of Ubuntu. Cheers, -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
On Thu, Jan 21, 2021 at 02:15:59AM -0800, Julian Andres Klode wrote: > Hi people, > > I'd like to suggest that we start setting NotAutomatic: yes for the > proposed pocket with hirsute+1, such that things like SRU verification > will be easier, and all those people who enable proposed in sources.list > for I don't know what reasons don't get their systems destroyed as much. > > This would obviously require some changes to pin the repo back up on the > builders, but I think it would be useful overall. Sounds good to me. 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. So yes, let's get this work scheduled if we can. :-) Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
Hi Julian, On Thu, Jan 21, 2021 at 02:15:59AM -0800, Julian Andres Klode wrote: > I'd like to suggest that we start setting NotAutomatic: yes for the > proposed pocket with hirsute+1, such that things like SRU verification > will be easier, and all those people who enable proposed in sources.list > for I don't know what reasons don't get their systems destroyed as much. > > This would obviously require some changes to pin the repo back up on the > builders, but I think it would be useful overall. I have no objection, and if it works without UX edge cases then I think it would be useful to users. https://wiki.ubuntu.com/Testing/EnableProposed will need a rework though. We link to that from every SRU bug. signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
