libc borked

[Stephan Hermann]

Hi Colin,

Colin Watson wrote:
>>>> Fact, rebuilding the archive won't show any build failures, but running 
>>>> those rebuilt apps would have shown the evilness of this change.
>>>>         
>>> Rebuilding the archive against the output of the rebuild in progress
>>> would have shown it up very quickly; note that glibc 2.7-9ubuntu2 itself
>>> failed to build (without hand-holding) due to upgrading to libc6
>>> 2.7-9ubuntu1 at the start of the build, and many packages would have
>>> failed in the same way.
>>>       
>> The problem I see here is: When we upload something new e.g. toolchain, 
>> glibc, dpkg-buildpackage changes etc. we are not automatically 
>> rebuilding our archive against those new versions. Which would be quite 
>> helpful if we did.
>>     
>
> It isn't practical for us to upload the entire archive when the
> toolchain changes; we would rapidly lose mirrors if we started doing
> things like that.
>   
No, that I don't mean/want either...but an internal test rebuild of the 
archive should be possible without injecting any new packages to the 
archive/mirros.
Just for QA purposes.
> However, we can and do perform test rebuilds that don't end up in the
> archive; in fact, such a test rebuild was performed after dpkg was
> changed, but unfortunately did not make use of its own output so this
> problem didn't show up. We'll fix that for the next test rebuild. We may
> also try to construct a CD image from the output of the test rebuild,
> which would allow us to discover more subtle problems; although we'd
> have to be very careful about labelling these.
>   

> I'm not sure if any of this would have shown up the wine problem, unless
> lmms would have encountered it via its build-dependency on wine-dev.
> Automatic tests in the package itself are probably the best chance we
> have here.
>   
TBH, the break of wine was just a coincidence...as I already said on 
IRC, I tested the wine 0.9.55 before I uploaded it, but to my fault I 
didn't update my personal ubuntu mirror to the latest state, and sadly 
on my system it worked, but not for others after upload. this has been 
fixed on my site with a 0,6,12,18 interval of "mirror_hardy.sh ; 
update_chroots.sh" via cron :)
More sad is, that this bug was known to wine devs, but the corresponding 
bug report was set to invalid/closed which wasn't in my search query.

>   
>> I don't blame anybody...we just need to fix some processes, e.g. 
>> describing a bit more  what the change  is (not only : ok we  
>> intrdoduced new cflags,ldflags handling and passing some sane/insane 
>> flags via dpkg-buildpackage towards our buildsystems).
>>     
>
> I still think that in general this is a sane flag (and so far it's
> broken fewer packages than -fstack-protector did), but more work is
> clearly needed on spotting the exceptions.
>
>   
Yepp..even with glibc working now, it can happen that some apps (like 
wine) are breaking during runtime (which can't be catched during the 
build). those buggers needs to be catched during testing the CDs, or 
universe archives from testers...or we find an automatic way of running 
the packages after building (which could be a cool project for SoC 
students or mad mans task ;))


Anyhow, I think we know now what went wrong, and we do better in the 
future :)

\sh