Stable Release Update Regression/Build Problem
An SRU for aptoncd was just moved from hardy-proposed (where it worked) to hardy-updates where it does not due to a pending python-central SRU. https://bugs.launchpad.net/ubuntu/+source/aptoncd/+bug/199600 The aptoncd package was apparently built against python-central 0.6.7ubuntu0.1 in hardy-proposed which produces a versioned depends on python-central (>=0.6.7) but 0.6.5ubuntu1 is all that is currently available in Hardy's release pocket. I'm not sure if there are other packages that use python-central in hardy-proposed, but none should be pocket copied from hardy-proposed to hardy-updates until python-central gets moved. Filed in launchpad as bug 242554. https://bugs.launchpad.net/ubuntu/+source/aptoncd/+bug/242554 Scott K pgp7dqBfO3N6x.pgp Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Stable Release Update Regression/Build Problem
On Mon, Jun 23, 2008 at 11:17:37PM -0400, Scott Kitterman wrote: > An SRU for aptoncd was just moved from hardy-proposed (where it worked) to > hardy-updates where it does not due to a pending python-central SRU. > https://bugs.launchpad.net/ubuntu/+source/aptoncd/+bug/199600 > The aptoncd package was apparently built against python-central > 0.6.7ubuntu0.1 > in hardy-proposed which produces a versioned depends on python-central > (>=0.6.7) but 0.6.5ubuntu1 is all that is currently available in Hardy's > release pocket. > I'm not sure if there are other packages that use python-central in > hardy-proposed, but none should be pocket copied from hardy-proposed to > hardy-updates until python-central gets moved. > Filed in launchpad as bug 242554. > https://bugs.launchpad.net/ubuntu/+source/aptoncd/+bug/242554 Scott got ahold of me on IRC shortly after sending this email, and I've followed through on the python-central SRU candidate which has now been validated and copied to hardy-updates. I've marked bug #242554 as 'fix released', as the dependency of aptoncd should now be satisfiable within hardy-updates as soon as the package has been published and the mirrors catch up. This highlights the need for a check as part of our SRU process to verify that packages which are being copied into -updates won't cause uninstallability problems. python-central is not a unique case in warranting such a check; whenever an ABI-changing kernel SRU is done, it's important to be sure that all the packages are copied as a group to avoid regressions in installability such as this, and currently this check is done entirely by hand. An appropriate follow-up to prevent this problem from recurring would be to implement such a check. Perhaps britney is the right starting point for this? -- 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 Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Stable Release Update Regression/Build Problem
On Mon, 23 Jun 2008 23:16:07 -0700 Steve Langasek <[EMAIL PROTECTED]> wrote: >On Mon, Jun 23, 2008 at 11:17:37PM -0400, Scott Kitterman wrote: >> An SRU for aptoncd was just moved from hardy-proposed (where it worked) to >> hardy-updates where it does not due to a pending python-central SRU. > >> https://bugs.launchpad.net/ubuntu/+source/aptoncd/+bug/199600 > >> The aptoncd package was apparently built against python-central 0.6.7ubuntu0.1 >> in hardy-proposed which produces a versioned depends on python-central >> (>=0.6.7) but 0.6.5ubuntu1 is all that is currently available in Hardy's >> release pocket. > >> I'm not sure if there are other packages that use python-central in >> hardy-proposed, but none should be pocket copied from hardy-proposed to >> hardy-updates until python-central gets moved. > >> Filed in launchpad as bug 242554. > >> https://bugs.launchpad.net/ubuntu/+source/aptoncd/+bug/242554 > >Scott got ahold of me on IRC shortly after sending this email, and I've >followed through on the python-central SRU candidate which has now been >validated and copied to hardy-updates. > >I've marked bug #242554 as 'fix released', as the dependency of aptoncd >should now be satisfiable within hardy-updates as soon as the package has >been published and the mirrors catch up. > >This highlights the need for a check as part of our SRU process to verify >that packages which are being copied into -updates won't cause >uninstallability problems. python-central is not a unique case in >warranting such a check; whenever an ABI-changing kernel SRU is done, it's >important to be sure that all the packages are copied as a group to avoid >regressions in installability such as this, and currently this check is done >entirely by hand. > >An appropriate follow-up to prevent this problem from recurring would be to >implement such a check. Perhaps britney is the right starting point for >this? > Another related issue is the question of running with *-proposed enabled versus installation of single packages from proposed. This package could have only passed verififcation if *-proposed was enabled on the system in question. While running with *-proposed enabled may have some benefit for regression detection, I don't think it is suitable for SRU verification. Generally, I the verification should be against *-release and *-updates without other packages from *-proposed. It is feasible to mechanize installability checks, but more subtle package interactions need to be explored during the verification process. Unless someone objects, I'll update the SRU process to reflect this requirement. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Stable Release Update Regression/Build Problem
On Tue, Jun 24, 2008 at 07:24:59AM -0400, Scott Kitterman wrote: > Another related issue is the question of running with *-proposed enabled > versus installation of single packages from proposed. This package could > have only passed verififcation if *-proposed was enabled on the system in > question. > > While running with *-proposed enabled may have some benefit for regression > detection, I don't think it is suitable for SRU verification. Generally, I > the verification should be against *-release and *-updates without other > packages from *-proposed. It is feasible to mechanize installability > checks, but more subtle package interactions need to be explored during the > verification process. Agreed, it's sensible to test the update in the same environment to which it is about to be deployed. > Unless someone objects, I'll update the SRU process to reflect this > requirement. I don't object to the proposed change in itself, but I think changes to that process should go through the SRU team first. -- - mdz -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Stable Release Update Regression/Build Problem
On Tue, Jun 24, 2008 at 11:49 AM, Steve Beattie <[EMAIL PROTECTED]> wrote: > [0] Admittedly, I was doing this by playing a solitaire variant. See, >if you help out with SRU verifications, you too can justify playing >solitaire for two hours as a contribution to improving Ubuntu. :-) > It would have been nice if you had tested glchess, one reason gnome-games was updated in the first place =). Justin Dugger -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Stable Release Update Regression/Build Problem
On Tue, Jun 24, 2008 at 07:24:59AM -0400, Scott Kitterman wrote: > Another related issue is the question of running with *-proposed enabled > versus installation of single packages from proposed. This package > could have only passed verififcation if *-proposed was enabled on the > system in question. When we do SRU verifications, we do enable *-proposed, but that's only so we can pull the specific package that we're trying to test. We try to be very careful to make sure that the only additional package we install is the one we're trying to test; specifically we try to do verification in pristine vm images and install the specific package via "apt-get install " just so that we do not get "pollution" from other packages in *-proposed. For verifying fixes, we specifically try to not do blanket pulls from *-proposed; the QA team is trying to encourage power users and developers to run *-proposed to catch embarrassing regressions, but that's separate from how we want to verify bugfixes. Sometimes, this approach bites us in other ways; for example, in testing a fix for the gnome-games package, I spent a couple of hours[0] becoming convinced that the package in *-proposed didn't fix anything before I realized that that actual fix was contained in the gnome-games-data package (built from the same source package). And in fact, I assert that there's a certain unreality to that approach of verification as well, as someone who has one package installed will likely have the other installed and get both when updating, which does not necessarily get reflected by the way that we're testing. All that said, the people doing SRU verifications are human and fallible, and do make mistakes sometimes. It's possible that in installing aptoncd, the verifier overlooked that the python-central update got pulled in as well. Improvements to processes and tools and assistance in doing verifications is greatly appreciated. > While running with *-proposed enabled may have some benefit for > regression detection, I don't think it is suitable for SRU verification. > Generally, I the verification should be against *-release and *-updates > without other packages from *-proposed. This is exactly how we try to operate. Finding a clear way to express this in the wiki documentation would be appreciated. [0] Admittedly, I was doing this by playing a solitaire variant. See, if you help out with SRU verifications, you too can justify playing solitaire for two hours as a contribution to improving Ubuntu. :-) -- Steve Beattie <[EMAIL PROTECTED]> http://NxNW.org/~steve/ signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Stable Release Update Regression/Build Problem
On Tuesday 24 June 2008 13:41, Scott Kitterman wrote: > I think I have a sense of it. I'll work up a diff and run it by the other > members of motu-sru, ubuntu-sru, and the sru-verification teams. > > Scott K As promised, here is the diff I propose. I'd appreciate concurrence from members of the above teams. Comments from anyone are welcome too. --- sru 2008-06-24 22:15:10.0 -0400 +++ sru.new 2008-06-24 22:17:59.0 -0400 @@ -1,4 +1,4 @@ -The [WWW] SRU verification team will regularly check open bugs with the verification-needed tag and test proposed updates on different hardware to check for inadvertent side effects. +The [WWW] SRU verification team will regularly check open bugs with the verification-needed tag and test proposed updates on different hardware to check for inadvertent side effects. Verification must be done in a software environment as close as is feasible to that which will exist after the package is copied to *-updates for. Generally this will be with a system that is up to date from *-release, *-security, and *-updates, but not other packages from *-proposed. If they discover that your fix is insufficient, or the test case is not sufficient to reproduce the bug, they will: If there are no objections from the relevant teams, I'll update the wiki page with a suitably wikified version of this. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Stable Release Update Regression/Build Problem
Hi Scott, Scott Kitterman [2008-06-24 22:21 -0400]: > -The [WWW] SRU verification team will regularly check open bugs with the > verification-needed tag and test proposed updates on different hardware to > check for inadvertent side effects. > +The [WWW] SRU verification team will regularly check open bugs with the > verification-needed tag and test proposed updates on different hardware to > check for inadvertent side effects. Verification must be done in a software > environment as close as is feasible to that which will exist after the > package is copied to *-updates for. Generally this will be with a system > that is up to date from *-release, *-security, and *-updates, but not other > packages from *-proposed. That sounds good to me in spirit, however, I'd like it to have some operational instructions. Can we add a sentence like This generally means to update all binary packages which are built from the affected source package. ? Since it is not even technically possible to copy just some binary packages from -proposed to -updates, verification should always be done that way IMHO. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Stable Release Update Regression/Build Problem
On Wed, 25 Jun 2008 09:26:15 +0200 Martin Pitt <[EMAIL PROTECTED]> wrote: >Hi Scott, > >Scott Kitterman [2008-06-24 22:21 -0400]: >> -The [WWW] SRU verification team will regularly check open bugs with the >> verification-needed tag and test proposed updates on different hardware to >> check for inadvertent side effects. >> +The [WWW] SRU verification team will regularly check open bugs with the >> verification-needed tag and test proposed updates on different hardware to >> check for inadvertent side effects. Verification must be done in a software >> environment as close as is feasible to that which will exist after the >> package is copied to *-updates for. Generally this will be with a system >> that is up to date from *-release, *-security, and *-updates, but not other >> packages from *-proposed. > >That sounds good to me in spirit, however, I'd like it to have some >operational instructions. Can we add a sentence like > > This generally means to update all binary packages which are built > from the affected source package. > >? Since it is not even technically possible to copy just some binary >packages from -proposed to -updates, verification should always be >done that way IMHO. > Yes. That makes complete sense. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Stable Release Update Regression/Build Problem
On Wed Jun 25 7:15 , Scott Kitterman sent: >On Wed, 25 Jun 2008 09:26:15 +0200 Martin Pitt [EMAIL PROTECTED]> >wrote: >>Hi Scott, >> >>Scott Kitterman [2008-06-24 22:21 -0400]: >>> -The [WWW] SRU verification team will regularly check open bugs with the >>> verification-needed tag and test proposed updates on different hardware >to >>> check for inadvertent side effects. >>> +The [WWW] SRU verification team will regularly check open bugs with the >>> verification-needed tag and test proposed updates on different hardware >to >>> check for inadvertent side effects. Verification must be done in a >software >>> environment as close as is feasible to that which will exist after the >>> package is copied to *-updates for. Generally this will be with a >system >>> that is up to date from *-release, *-security, and *-updates, but not >other >>> packages from *-proposed. >> >>That sounds good to me in spirit, however, I'd like it to have some >>operational instructions. Can we add a sentence like >> >> This generally means to update all binary packages which are built >> from the affected source package. >> >>? Since it is not even technically possible to copy just some binary >>packages from -proposed to -updates, verification should always be >>done that way IMHO. >> >Yes. That makes complete sense. Updated. https://wiki.ubuntu.com/StableReleaseUpdates Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Stable Release Update Regression/Build Problem
On Wed, Jun 25, 2008 at 10:51:03AM -0400, Scott Kitterman wrote: > >>Scott Kitterman [2008-06-24 22:21 -0400]: > >>> -The [WWW] SRU verification team will regularly check open bugs with the > >>> verification-needed tag and test proposed updates on different hardware > >to > >>> check for inadvertent side effects. > >>> +The [WWW] SRU verification team will regularly check open bugs with the > >>> verification-needed tag and test proposed updates on different hardware > >to > >>> check for inadvertent side effects. Verification must be done in a > >software > >>> environment as close as is feasible to that which will exist after the > >>> package is copied to *-updates for. Generally this will be with a > >system > >>> that is up to date from *-release, *-security, and *-updates, but not > >other > >>> packages from *-proposed. > >>That sounds good to me in spirit, however, I'd like it to have some > >>operational instructions. Can we add a sentence like > >> This generally means to update all binary packages which are built > >> from the affected source package. > >>? Since it is not even technically possible to copy just some binary > >>packages from -proposed to -updates, verification should always be > >>done that way IMHO. > >Yes. That makes complete sense. > Updated. > https://wiki.ubuntu.com/StableReleaseUpdates Thanks for this, Scott. I've followed up with a small grammar edit, but otherwise this looks perfect to me. -- 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 Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
