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