Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure

[László Böszörményi (GCS)]

On Sat, Apr 2, 2016 at 11:40 AM, Niko Tyni <ntyni at debian.org> wrote:
> On Sat, Apr 02, 2016 at 11:20:02AM +0200, László Böszörményi (GCS) wrote:
>> I think libdatabase-dumptruck-perl upstream should be noted about this
>> issue. May check it locally, but please don't take my word on it.
>
> Thanks. I'll try to investigate this and the
> libdbix-class-schema-loader-perl issue myself further later, will keep
> you posted. And sure, upstream certainly needs to be notified too.
 OK. Did some local testing. First, libdatabase-dumptruck-perl doesn't
build depend on sqlite3 directly, but transitively via
libdbd-sqlite3-perl. Just a binNMU of the latter doesn't help. While
downgrading sqlite3 to 3.11.1 works, there's a strange going on with
the Perl test suite - with is_deeply() to be exact.
The failing line is in t/dumptruck.t:
is_deeply ($dt3->get_var('array_of_the_beast'), [666],
'Array variable retrieved');
Its first parameter is the function the call and the second is the
expected result[1]. If I use sqlite3 3.11.1, then the function returns
an array, but not [666]. With sqlite3 3.12.0 it returns the expected
[666].
As such I don't see why the test suite equals in the former an array
with [666]; then in the latter fails to make [666] equal to [666]. If
someone knows Perl better, please make some lights here. Maybe some
pointer vs value thing happens here.

Regards,
Laszlo/GCS
[1] http://sqa.fyicenter.com/Perl_Test_Tutorial/63_is_deeply_.html