Stable Release Update Regression/Build Problem

Scott Kitterman ubuntu at
Tue Jun 24 12:24:59 BST 2008

On Mon, 23 Jun 2008 23:16:07 -0700 Steve Langasek 
<steve.langasek at> 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) 
>> hardy-updates where it does not due to a pending python-central SRU.
>> The aptoncd package was apparently built against python-central 
>> 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.
>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
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 

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 

Scott K

More information about the Ubuntu-motu mailing list