libc borked

[Colin Watson]

On Fri, Mar 14, 2008 at 12:36:04PM +0100, Stephan Hermann wrote:
> 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)

I do agree that the changelog should have been more detailed.

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

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.

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

-- 
Colin Watson                                       [cjwatson at ubuntu.com]