Debian Bug report logs - #838531
nose2: FTBFS in testing (failing tests)

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Debian BTS <submit@bugs.debian.org>

Subject: nose2: FTBFS in testing (failing tests)

Date: Wed, 21 Sep 2016 23:33:43 +0200 (CEST)

[Message part 1 (text/plain, inline)]

Package: src:nose2
Version: 0.6.5-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed.

I'm attaching a single build log, but it fails every time I try, and it
also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/nose2.html

which is also an indication that the error seems completely unrelated
to using "dpkg-buildpackage -A".

Thanks.

[nose2_0.6.5-1_amd64-20160921T202215Z.gz (application/gzip, attachment)]

Message #10 received at 838531@bugs.debian.org (full text, mbox, reply):

From: Chris Lamb <lamby@debian.org>

To: 838531@bugs.debian.org

Cc: Santiago Vila <sanvila@unex.es>

Subject: Re: nose2: FTBFS in testing (failing tests)

Date: Sat, 24 Sep 2016 15:47:02 +0100

Hi,

> nose2: FTBFS in testing (failing tests)

This is somewhat mind-bending to debug:

   AssertionError: Regex didn't match:
      'FAILED \\(failures=5, errors=1, skipped=1\\)' not found in
      […] FAILED (failures=1, errors=1, skipped=1)\n'

ie. the wrong tests in a set of tests for a testcase in a testing utility
are passing when they should be failing, and it's not even clear which of
them should be failing.


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

Message #15 received at 838531@bugs.debian.org (full text, mbox, reply):

From: Barry Warsaw <barry@debian.org>

To: 838531@bugs.debian.org

Subject: Re: Bug#838531: nose2: FTBFS in testing (failing tests)

Date: Mon, 26 Sep 2016 11:25:06 -0400

On Sep 24, 2016, at 03:47 PM, Chris Lamb wrote:

>> nose2: FTBFS in testing (failing tests)
>
>This is somewhat mind-bending to debug:
>
>   AssertionError: Regex didn't match:
>      'FAILED \\(failures=5, errors=1, skipped=1\\)' not found in
>      […] FAILED (failures=1, errors=1, skipped=1)\n'
>
>ie. the wrong tests in a set of tests for a testcase in a testing utility
>are passing when they should be failing, and it's not even clear which of
>them should be failing.

Hi, I can't seem to reproduce this on unstable.  Both dpkg-buildpackage -A and
sbuild work just fine, as does autopkgtest in an unstable chroot.

However, the reproducible build problem is a real issue; I'm about to upload
0.6.5-2 which will fix this.  Once that's pushed to git or uploaded, could you
please try again?

Message #22 received at 838531-done@bugs.debian.org (full text, mbox, reply):

From: Barry Warsaw <barry@debian.org>

To: 838531-done@bugs.debian.org

Date: Thu, 29 Sep 2016 11:19:05 -0400

[Message part 1 (text/plain, inline)]

Since this is unreproducible, I'm closing it.  Please reopen if you can
provide more information.

[Message part 2 (application/pgp-signature, inline)]

Message #27 received at 838531@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Barry Warsaw <barry@debian.org>

Cc: 838531@bugs.debian.org

Subject: Re: Bug#838531: nose2: FTBFS in testing (failing tests)

Date: Thu, 29 Sep 2016 23:01:36 +0200 (CEST)

On Mon, 26 Sep 2016, Barry Warsaw wrote:

> Hi, I can't seem to reproduce this on unstable.  Both dpkg-buildpackage -A and
> sbuild work just fine, as does autopkgtest in an unstable chroot.

Well, it failed in testing when I reported it, on five different
autobuilders and also here:

https://tests.reproducible-builds.org/debian/rb-pkg/testing/amd64/nose2.html

But now I can no longer reproduce it. I guess some build-dependency
was changed to fix this. If you are still interested to know why it
failed and want to do "package archeology", you could maybe try with
snapshot.debian.org.

But I don't think package maintainers should be doing this (unless
they want, of course), so closing the bug is probably the only
sensible thing to do.

Thanks.

Send a report that this bug log contains spam.