Bug#665221: libdancer-plugin-database-perl: FTBFS: tests failed

[Lucas Nussbaum]

Source: libdancer-plugin-database-perl
Version: 1.81-1
Severity: serious
Tags: wheezy sid
User: debi...@lists.debian.org
Usertags: qa-ftbfs-20120321 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part:
> make[1]: Entering directory `/«PKGBUILDDIR»'
> PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
> # Testing Dancer::Plugin::Database 1.81, Perl 5.014002, /usr/bin/perl
> t/00-load.t ....... ok
>
> # Failed test 'database_connection_failed hook fires'
> # at t/01-basic.t line 155.
> # got: ''
> # expected: '1'
> # Looks like you failed 1 test of 41.
> t/01-basic.t ......
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/41 subtests
> # Testing Dancer::Plugin::Database::Handle 0.12, Perl 5.014002, /usr/bin/perl
> t/02-handle.t ..... ok
> t/manifest.t ...... skipped: Author tests not required for installation
> t/pod-coverage.t .. ok
> t/pod.t ........... ok
>
> Test Summary Report
> -------------------
> t/01-basic.t (Wstat: 256 Tests: 41 Failed: 1)
> Failed test: 41
> Non-zero exit status: 1
> Files=6, Tests=50, 2 wallclock secs ( 0.07 usr 0.02 sys + 0.68 cusr 0.11 csys = 0.88 CPU)
> Result: FAIL
> Failed 1/6 test programs. 1/50 subtests failed.
> make[1]: *** [test_dynamic] Error 255

The full build log is available from:
http://people.debian.org/~lucas/logs/2012/03/21/libdancer-plugin-database-perl_1.81-1.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
of the Grid'5000 platform, using a clean chroot. Internet was not
accessible from the build systems.



--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[intrigeri]

Hi,

Niko Tyni wrote (31 Mar 2012 07:46:37 GMT) :
> I'm attaching a test script that should demonstrate this
> in a reproducible way.

I'm impressed by the detailed debugging you did!
Congrats :)

> I've forwarded this upstream as
> <https://github.com/bigpresh/Dancer-Plugin-Database/issues/29>.

... unfortunately, they did not comment yet.

I'd like the RC part of the problem to be fixed in time for Wheezy,
so I suggest we:

1. patch the failing test to become a TODO one
2. add Niko's TODO minimal test case (to be notified if the
bug is fixed upstream)
3. file a new (non-RC) Debian bug about the actual bug that's
demonstrated by the FTBFS
4. close this FTBFS bug

Niko, what do you think?

Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

[Niko Tyni]

On Sat, Jun 09, 2012 at 07:15:21PM +0200, intrigeri wrote:

> I'd like the RC part of the problem to be fixed in time for Wheezy,
> so I suggest we:
>
> 1. patch the failing test to become a TODO one
> 2. add Niko's TODO minimal test case (to be notified if the
> bug is fixed upstream)
> 3. file a new (non-RC) Debian bug about the actual bug that's
> demonstrated by the FTBFS
> 4. close this FTBFS bug

OK by me (but you could also just downgrade the existing bug after adding
the workaround.)

It would be good to ping upstream on a mailing list or something,
I don't know how actively they use the github issue tracker.

Thanks for looking at this,
--
Niko Tyni nt...@debian.org

[intrigeri]

Hi David,

while debugging a test failure that was reported to Debian [0] and on
Github [1] a few months ago, a bug was uncovered, which is described,
along with a minimal test case along with some thoughts about
possible fixes.

[0] http://bugs.debian.org/665221
[1] https://github.com/bigpresh/Dancer-Plugin-Database/issues/29

Not knowing how closely you monitor the issue tracker on Github, we at
the Debian Perl team thought it would be useful to point you at this
specific issue. Do you think you'll be able to fix this shortly, or
shall we workaround it to ship this package in Debian Wheezy?

Thank you for writing Dancer-Plugin-Database!

Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

[David Precious]

On Sat, 23 Jun 2012 21:05:12 +0200
intrigeri <intr...@boum.org> wrote:

> Hi David,

>
> intrigeri wrote (10 Jun 2012 17:49:39 GMT) :
> > [0] http://bugs.debian.org/665221
> > [1] https://github.com/bigpresh/Dancer-Plugin-Database/issues/29
>

> I've seen you have replied on GitHub two weeks ago. Great!
>
> Do you think you'll be able to fix this in the next few days,
> or shall we workaround it to ship Dancer-Plugin-Database in Debian
> Wheezy?

I'll do my best to get it sorted out tomorrow, thanks for the poke.

I may have to release a dev version to CPAN and wait a couple of days
for tester reports, though, as it'll change how the module currently
caches handles, and I really don't want to risk breaking things for
people.

Cheers

Dave P



--
David Precious ("bigpresh") <dav...@preshweb.co.uk>
http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter
www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook
www.preshweb.co.uk/cpan www.preshweb.co.uk/github

[David Precious]

On Thu, 28 Jun 2012 21:24:03 +0200
intrigeri <intr...@boum.org> wrote:

> David Precious wrote (28 Jun 2012 18:42:19 GMT) :
> > I'm looking for a decent safe fix now; if I find one, I'll get a new
> > release out tonight, hopefully that's not too late.
>
> Tonight would be perfect.
> Thanks for working on it.
>
> > If I do, I'll provide a link to the commit(s) which fix the issue,
> > in case you need to backport only the changes.
>
> Emailing me and 665...@bugs.debian.org would be perfect :)

Version 1.82 just headed to CPAN, containing a simple fix for this
issue.

The actual fix was:

https://github.com/bigpresh/Dancer-Plugin-Database/commit/85e8cd06ff

When caching a handle, if we were given a hashref of settings, we cache
a reference to that hashref, too - so the original hashref of settings
doesn't go out of scope while the handle is still cached.

This simple change should do the job!

Many thanks for reporting this issue to me and prompting me for a fix
before Wheezy :)