libc borked

[Stephan Hermann]

hi Colin,


Colin Watson wrote:
> On Thu, Mar 13, 2008 at 12:55:47PM +0100, Stephan Hermann wrote:
>   
>> The package is not at fault...
>> The fault was to upload dpkg (2008-02-11 imho) with 
>> https://wiki.ubuntu.com/DistCompilerFlags this in mind.
>> Setting those flags is not good without a bunch of testing.
>>     
>
> I only discovered today that wine broke a few weeks ago due to this
> change, and that you applied the same kind of fix to wine last week as
> has since been applied to glibc. I'm curious whether you escalated this
> anywhere at the time, and if so where? If it was escalated but not dealt
> with, that's something we should look at too.
>   

Well, when I upload 0.9.54 of wine, this problem wasn't arising.
After this date, a new dpkg was uploaded with a change of behaviour for 
CFLAGS etc.
This wasn't clear, just beacuse the changelog only mentioned this, 
without noticing WHAT actually was changed. (no clue about the 
difference of LDFLAGS we were passing on now)
Others and I were tracking down the problem, but that the problem was 
with ldflags wasn't quite known until one contributor pointed us to the 
LDFLAGS issue.

I was asking about differences between a normal manual build and our 
sbuilds...but actually Scott Ritchie and I (and other contributors) were 
quite alone with this. I can understand this, because wine is in 
universe and "not sooo" important.

But a better communication or at least a mentioning in the changelog, 
what actually was changed (e.g. "New behaviour: ldflags now brings 
<insert our flags here>, please be careful")
I for myself wasn't quite sure, if the new behaviour was tested 
beforehand, or just that wine was broken by some things. The funny part, 
this misbehaviour with our new ldflags was mentioned in a bug report 
from 2007 which was set invalid/closed in wines bugzilla.


>   
>> 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. Fun part, a change in LDFLAGS won't obviously shown 
up during the build process (as we saw with wine), but during 
runtime..(which is quite hard for devs who are running the devel release 
on their WS, I know, but why not use vmware ;)).

>   
>>> I was mad. I'm human. I'm over it. Time to spend the day rebuilding 3
>>> machines. ;)
>>>       
>> Repeat with us: You should not use Development Releases on production 
>> machines, until you know that it can break (badly) !
>>     
>
> This is definitely worth noting, but it's also clearly true that
> breakage should be minimised where possible. This is a reminder that the
> fact that development releases are generally not actually all that bad
> doesn't mean that they'll never break spectacularly, while also serving
> as a demonstration of various problems in our processes.
>
>   
TBH, I'm always ready and waiting for any breakage during 
development..this is nothing new, and this should be known to everybody. 
Development releases are not intend for the normal audience, and 
everybody who runs a development release has to know for sure, that at 
some time everything breaks.

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).

Well, my fault was not to escalate this issue to the right people, just 
because I thought, those changes were already tested.

Regards,

\sh