sh at sourcecode.de
Fri Mar 14 11:36:04 UTC 2008
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
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
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.
More information about the Ubuntu-devel-discuss