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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
