Re: Advice for bug fix
Am Mittwoch, den 21.02.2007, 16:19 -0800 schrieb Steve Langasek:
> On Wed, Feb 21, 2007 at 06:52:02PM +0100, Thomas Weber wrote:
> > with the fix for #410070 in octave2.9-2.9.9-8, an FTBFS error in
> > octave2.9-forge was found (#410463). This turned out to be an error in
> > the way the unit tests for octave2.9-forge are created at build time.
>
> > Unfortunately, in fixing this bug in octave2.9-forge, we hit another bug
> > in Octave2.9 (which was already fixed upstream some time ago), namely
> > #411863: one of the unit tests lets Octave use all available memory
> > until the OOM killer kicks in. So, we currentyl can't build
> > octave2.9-forge with activated unit tests.
>
> > Now, I need your advice:
> > We can upload fixed packages for both octave2.9 and octave2.9-forge into
> > unstable and later on they are unblocked (the changes are only a few
> > lines diff for each bug fix).
> > Or we upload only a new package for octave2.9-forge, where the unit
> > tests are disabled.
>
> Does that mean the unit tests currently /are/ activated in
> octave2.9-forge version 2006.07.09+dfsg1-7?
Yes, but please ignore me, I'm lame. The current version of octave2.9 in
testing builds octave2.9-forge just fine (the unit tests are just not
run). We'll upload fixed versions of octave2.9 and octave2.9-forge into
unstable and come back when the packages are built.
The rest of the mail is an explanation of the problem, but I just
realized that testing is not affected. Sorry for the noise.
We always did "make check" when building octave2.9-forge. Due to an
error in the way octave2.9-forge ran this, the tests themselves were
never run[1]. With earlier versions of Octave 2.9 (up to -7), that
wasn't a problem. The log was full of "Can't find file to test"
messages, but that was it.
The fix for #410070 in Octave means that Octave now will choke on the
test script itself, breaking the build. This is #410463, a bug in
octave2.9-forge (the test script has invalid statements).
Upon fixing this, we hit a bug in Octave 2.9, namely #411863 (out of
memory). A statement triggering this bug is part of octave2.9-forge's
test suite.So if I upload a fixed version of octave2.9-forge, that runs
all unit tests properly, we will need a fixed version of Octave 2.9
first or buildd admins won't be that happy.
> If so, of the two choices I
> would rather see octave2.9 fixed so the unit tests can be run; but I don't
> understand why you're asking about having fixes for /both/ packages. I
> certainly don't understand why you're referencing bug #410463, which is only
> reported against the unstable version of octave2.9.
That bug is mis-assigned. It's a bug in octave2.9-forge.
octave2.9-2.9.9-8 is meant for testing, and wasn't only going in due to
a typo by Luk.
I've reassigned it and bumped the severity of #411863 instead, to
prevent -8 of octave2.9 from entering testing (Luk fixed the typo).
> > Octave2.9-2.9.9-8 should enter testing, but I guess Luk mistyped the
> > numbers:
> > http://lists.debian.org/debian-release/2007/02/msg00287.html
>
> It isn't going to enter anyway right now, because there's an open RC bug;
> and knowing that the new version of octave2.9 breaks the builds of the
> octave2.9-forge currently in testing, that rather invalidates the rationale
> for a freeze exception in the first place, i.e., that it's a non-disruptive
> bugfix-only update.
>
> At the very least, octave2.9-forge needs to be fixed and allowed into
> testing /first/, before octave2.9 is considered again.
I hope it's clear now that this is not possible. Uploading a fixed (aka
with unit tests that are actually run) version of octave2.9-forge will
break the buildds with the current version (-8) of octave2.9.
[1] You can see this in the build logs:
"passes 0 out of 0 tests"
Due to the "success" messages, we didn't notice this earlier.
Thomas
Reply to: