Bug#823481: libimager-perl: FTBFS: t/200-file/400-basic.t failure
Package: libimager-perl Version: 1.004+dfsg-1 Severity: serious User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs This package fails to build on current sid/amd64. Log at https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/libimager-perl.html t/200-file/400-basic.t .. 1..262 [...] # type gif #opening Format: gif, options: file=>GIF/testimg/expected.gif ok 69 # Imager=HASH(0x1b10430) ok 70 # opening GIF/testimg/expected.gif ok 71 # ok 72 # seek after read ok 73 # Dubious, test returned 255 (wstat 65280, 0xff00) Failed 189/262 subtests [...] Test Summary Report --- t/200-file/400-basic.t(Wstat: 65280 Tests: 73 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 262 tests but ran 73. Files=65, Tests=4481, 33 wallclock secs ( 0.75 usr 0.21 sys + 14.70 cusr 1.56 csys = 17.22 CPU) Result: FAIL Running manually: % perl -Iblib/lib -Iblib/arch t/200-file/400-basic.t [...] # type gif #opening Format: gif, options: file=>GIF/testimg/expected.gif ok 69 # Imager=HASH(0x12fac00) ok 70 # opening GIF/testimg/expected.gif Use of uninitialized value $msg in concatenation (.) or string at t/200-file/400-basic.t line 343. ok 71 # Use of uninitialized value $msg in concatenation (.) or string at t/200-file/400-basic.t line 344. ok 72 # seek after read Use of uninitialized value $msg in concatenation (.) or string at t/200-file/400-basic.t line 343. ok 73 # Use of uninitialized value $msg in concatenation (.) or string at t/200-file/400-basic.t line 344. Use of uninitialized value in subroutine entry at t/200-file/400-basic.t line 79. Use of uninitialized value in subroutine entry at t/200-file/400-basic.t line 79. im1 is not of type Imager::ImgRaw at t/200-file/400-basic.t line 79. The tests in subdirectories don't get run on the autopkgtest side (#812219), which is why this didn't show up there. -- Niko Tyni nt...@debian.org
Bug#823455: libpdl-io-matlab-perl: FTBFS in sid: 1.5.0 is not a valid version
On Wed, May 04, 2016 at 11:23:36PM +0200, Samuel Thibault wrote: > Package: libpdl-io-matlab-perl > Version: 0.005-1 > Severity: serious > Justification: FTBFS > libpdl-io-matlab-perl currently FTBFS in sid: > dpkg-checkbuilddeps: error: 1.5.0 is not a valid version > I guess the space after 1.5.0 in the Build-Depends field of > debian/control is the culprit. That's a dpkg regression, see #823431. -- Niko Tyni nt...@debian.org
Bug#823428: dpkg: many packages affected by dpkg-source: error: source package uses only weak checksums
On Wed, May 04, 2016 at 08:13:56PM +0200, Guillem Jover wrote: > First off, with the reproducible and rebootstrap efforst rebuilding > stuff with latest dpkg, it's really fast to catch regressions, that's > very helpful, thanks! And second, also thanks for tracking this down. :) Thanks for the kind words :) > No, serious is right, this was over eagerness from my part. The > signature checks are non-fatal, and not being able to verify the sigs > is way worse security wise than having weak checksums (and that's > common for revoked/expired/retired keys), so this needs to be a warning > ineed. I'm fixing this for 1.18.7. Cool, thanks again. Do you think a lintian check for weak checksums would be worthwhile? I can't see an existing one but I suppose that shouldn't be too hard to implement. It could also serve as a basis for a mass bug filing if that turns out to be desirable. -- Niko
Bug#823428: dpkg: many packages affected by dpkg-source: error: source package uses only weak checksums
Package: dpkg Severity: serious Version: 1.18.5 X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org There are a number of packages in sid can't currently be unpacked with the default dpkg-source options. dpkg-source: error: source package uses only weak checksums This happens since dpkg 1.18.5, apparently https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=040973c7a1e50b78ef042ef5ffbfff0440c24700 Error out on source packages without any strong digests in Dpkg::Source::Package, used by dpkg-source --extract, which can still be disabled with --no-check. With about 2.5% of the archive test built on tests.reproducible-builds.org with a newer dpkg, we've caught at least apparix apwal asterisk-prompt-se bbpager bbtime brag btyacc libclass-pluggable-perl libcrypt-des-ede3-perl libdatetime-format-db2-perl libdbd-excel-perl sgml-spell-checker which would give a linear estimate of roughly 400 broken packages in total. A mass bug filing (at RC level) seems to be in order, but maybe dpkg should just warn for a while until packages get fixed? I assume the Debian buildds don't use --no-check, so binNMUs of affected packages are probably broken at the moment? Tentatively setting at 'serious' but feel free to adjust/close if this is all going as designed. -- Niko Tyni nt...@debian.org
Bug#816104: libcrypt-gcrypt-perl: FTBFS against libgcrypt 1.7.0 beta
Control: tag -1 patch
On Sat, Apr 23, 2016 at 02:55:55PM +0200, Andreas Metzler wrote:
> On 2016-04-20 Niko Tyni <nt...@debian.org> wrote:
> [...]
> > The failure can be triggered with this:
>
> > % perl -MCrypt::GCrypt -e
> > '$c=Crypt::GCrypt->new(type=>"cipher",algorithm=>"aes");$c->start("encrypting");
> > $c->encrypt("a").$c->finish'
>
> > which gets a SIGSEGV in libgcrypt. Backtrace below.
>
> > Adding a $c->setkey('whatever') before calling encrypt() makes it go
> > away. The test isn't trying to do anything meaningful at that point,
> > it's just checking that it gets a warning when not calling $c->finish()
> > or something like that. Later tests of actual encrypting pass.
>
> > Is this something to be fixed on the libgcrypt side?
> I have forwarded this upstream
> <http://article.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/4487>
> and got a quick response, whichcan be summed up in short with:
> 1. encryption without setkey must not be used.
> 2. gcrypt should throw an error instead of a segfault
Thanks! The attached trivial patch fixes the test failure in
libcrypt-gcrypt-perl by calling setkey() first. I've verified it works
with both libgcrypt 1.6.5 and 1.7.0.
--
Niko Tyni nt...@debian.org
>From cf6ef66ab447c696d465d3d1123685c2f281e8c2 Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Sat, 23 Apr 2016 16:49:57 +0300
Subject: [PATCH] Use an encryption key in the test suite
While encrypting without calling setkey() used to work before libgcrypt
1.7.0, this was accidental and not supported. It causes a SIGSEGV in
1.7.0 and will return an error in future versions.
See <http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/4487>
Bug-Debian: https://bugs.debian.org/816104
---
t/01-cipher.t | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/01-cipher.t b/t/01-cipher.t
index 3f7de37..0bbdf0a 100644
--- a/t/01-cipher.t
+++ b/t/01-cipher.t
@@ -102,6 +102,7 @@ ok(substr($d, 0, length $p) eq $p)
algorithm => 'aes',
padding => 'none'
);
+$c->setkey($key);
$c->start('encrypting');
ok(!eval {my $e2 = $c->encrypt('aaa'); 1}); # this should die
ok(eval { my $e2 = $c->encrypt('') . $c->finish; 1 }); # this should not die
--
2.8.0.rc3
Bug#821233: perlbal: FTBFS: Unable to start socket: Address already in use
Control: reopen -1 Control: severity -1 important On Sun, Apr 17, 2016 at 12:41:15AM +0200, gregor herrmann wrote: > Control: tag -1 + unreproducible > > On Sat, 16 Apr 2016 23:23:50 +0100, Chris Lamb wrote: > > > perlbal fails to build from source in unstable/amd64: > > > Didn't get 200 OK: GET /reqdecr,status HTTP/1.0 > > Unable to start socket: Address already in use > > # Looks like your test exited with 29 before it could output anything. > > t/32-selector.t .. > > 1..38 > > Dubious, test returned 29 (wstat 7424, 0x1d00) > > Failed 38/38 subtests > > The tests pass for me, both during build and in autopkgtest. It has just failed on ci.debian.net in the same way for the first time in a year or so. I can (eventually) reproduce it locally by running t/32-selector.t in a loop. Caught it with strace, and it looks like - the main process checks that the local port (in my case 60070) is free in Perlbal::Test::test_port() by making a new socket there and closing it immediately - later, in Perlbal::Test::WebServer::start_webserver() a server child process is forked off and then the main process tries to connect it. It gets a connection on something which doesn't respond properly but rather echoes the request back - in parallel but a bit later, the child process starts a server but gets EADDRINUSE from bind(2). I'm not aware of having any other process running that's greedy for local ports, and it seems really improbable that something would hit by chance in the window between the first check and the actual use. I wonder if the kernel is just slow to actually release the port after the first check. But surely at least the connect(2) call should have failed when the port was already closed. And why does the peer look like an echo service? I'm reopening but downgrading this. Perhaps we should just have start_webserver() retry a couple of times somehow if it fails the first time. -- Niko Tyni nt...@debian.org
Bug#816104: libcrypt-gcrypt-perl: FTBFS against libgcrypt 1.7.0 beta
On Sat, Feb 27, 2016 at 03:04:21PM +0100, Andreas Metzler wrote:
> Package: libcrypt-gcrypt-perl
> Version: 1.26-3
> Severity: important
> the package FTBFS against libgcrypt 1.7.0 beta with the folowing error:
>
> Test Summary Report
> ---
> t/01-cipher.t (Wstat: 11 Tests: 19 Failed: 0)
> Non-zero wait status: 11
> Parse errors: Bad plan. You planned 20 tests but ran 19.
Thanks for the warning and sorry for the earlier lack of action on this.
The failure can be triggered with this:
% perl -MCrypt::GCrypt -e
'$c=Crypt::GCrypt->new(type=>"cipher",algorithm=>"aes");$c->start("encrypting");
$c->encrypt("a").$c->finish'
which gets a SIGSEGV in libgcrypt. Backtrace below.
Adding a $c->setkey('whatever') before calling encrypt() makes it go
away. The test isn't trying to do anything meaningful at that point,
it's just checking that it gets a warning when not calling $c->finish()
or something like that. Later tests of actual encrypting pass.
Is this something to be fixed on the libgcrypt side?
I guess I can come up with a C test case if needed, but maybe you
can cook up one easier? The perl side setkey() just seems to wrap
gcry_cipher_setkey().
Core was generated by `debugperl -Iblib/lib -Iblib/arch -MCrypt::GCrypt -e
$c=Crypt::GCrypt->new(type='.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x7f5a5bce89c5 in _gcry_aes_cbc_enc (context=0x280a8e0, iv=0x280a6d0
"", outbuf_arg=,
inbuf_arg=, nblocks=1, cbc_mac=0) at
../../cipher/rijndael.c:811
#2 0x7f5a5bcc6565 in _gcry_cipher_cbc_encrypt (c=0x280a660,
outbuf=outbuf@entry=0x27cf850 "a", '\017' ,
outbuflen=outbuflen@entry=16,
inbuf=inbuf@entry=0x2840650 "a", '\017' ,
inbuflen=)
at ../../cipher/cipher-cbc.c:65
#3 0x7f5a5bcc5400 in cipher_encrypt (inbuflen=,
inbuf=0x2840650 "a", '\017' , outbuflen=16,
outbuf=0x27cf850 "a", '\017' , c=) at
../../cipher/cipher.c:826
#4 _gcry_cipher_encrypt (h=, out=out@entry=0x27cf850,
outsize=outsize@entry=16,
in=in@entry=0x2840650, inlen=, inlen@entry=16) at
../../cipher/cipher.c:913
#5 0x7f5a5bcba91e in gcry_cipher_encrypt (h=,
out=0x27cf850, outsize=16, in=0x2840650,
inlen=16) at ../../src/visibility.c:828
#6 0x7f5a5bfc1a53 in XS_Crypt__GCrypt_finish (my_perl=0x2785010,
cv=0x27d47f0) at GCrypt.xs:439
#7 0x0050f456 in Perl_pp_entersub (my_perl=0x2785010) at
pp_hot.c:3270
#8 0x004da689 in Perl_runops_debug (my_perl=0x2785010) at dump.c:2234
#9 0x00450e92 in S_run_body (oldscope=1, my_perl=0x2785010) at
perl.c:2453
#10 perl_run (my_perl=0x2785010) at perl.c:2376
#11 0x0041d09b in main (argc=6, argv=0x7ffc0f9ebfe8,
env=0x7ffc0f9ec020) at perlmain.c:116
--
Niko Tyni nt...@debian.org
Bug#820824: libapache2-mod-perl2: FTBFS: t/protocol/pseudo_http.t failure
Package: libapache2-mod-perl2 Version: 2.0.9-4 Severity: serious User: debian-p...@lists.debian.org Usertags: autopkgtest X-Debbugs-Cc: apac...@packages.debian.org This package fails to build on current sid/amd64. # Failed test 3 in t/protocol/pseudo_http.t at line 59 # Failed test 4 in t/protocol/pseudo_http.t at line 64 t/protocol/pseudo_http.t Failed 11/13 subtests [...] Test Summary Report --- t/protocol/pseudo_http.t (Wstat: 13 Tests: 4 Failed: 2) Failed tests: 3-4 Non-zero wait status: 13 Parse errors: Bad plan. You planned 13 tests but ran 4. Looking at the CI results at https://ci.debian.net/packages/liba/libapache2-mod-perl2/unstable/amd64/ this started happening between 2016-04-09 and 2016-04-10, probably with the apache2 2.4.18 -> 2.4.20 upgrade. I can get this to happen with just # ./t/TEST -verbose -httpd_conf $(pwd)/debian/apache2.conf t/protocol/pseudo_http.t and I see the Apache server process dies with SIGSEGV. Backtrace below. Cc'ing the Apache maintainers, seems to be a regression there? Core was generated by `/usr/sbin/apache2 -d /home/niko/tmp/libapache2-mod-perl2/t -f /home/niko/tmp/li'. Program terminated with signal SIGSEGV, Segmentation fault. #0 apr_getnameinfo (hostname=hostname@entry=0x7fd4461ee368, sockaddr=0x0, flags=flags@entry=0) at /tmp/buildd/apr-1.5.2/network_io/unix/sockaddr.c:663 663 /tmp/buildd/apr-1.5.2/network_io/unix/sockaddr.c: No such file or directory. [Current thread is 1 (Thread 0x7fd44740d700 (LWP 13678))] (gdb) bt #0 apr_getnameinfo (hostname=hostname@entry=0x7fd4461ee368, sockaddr=0x0, flags=flags@entry=0) at /tmp/buildd/apr-1.5.2/network_io/unix/sockaddr.c:663 #1 0x55feaf0f513a in ap_get_useragent_host (r=r@entry=0x7fd4461ee0a0, type=type@entry=3, str_is_ip=str_is_ip@entry=0x7fd44740c9c4) at core.c:990 #2 0x7fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0, method=method@entry=0, a=, a=) at mod_access_compat.c:279 #3 0x7fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at mod_access_compat.c:332 #4 0x55feaf0f8f30 in ap_run_access_checker (r=r@entry=0x7fd4461ee0a0) at request.c:87 #5 0x7fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker (my_perl=0x55feb2964a20, cv=) at HookRun.c:235 #6 0x7fd44f5f7e6a in Perl_pp_entersub () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22 #7 0x7fd44f5f0ca6 in Perl_runops_standard () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22 #8 0x7fd44f575f06 in Perl_call_sv () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22 #9 0x7fd44f91ec28 in modperl_callback (my_perl=my_perl@entry=0x55feb2964a20, handler=0x7fd4461f2750, p=p@entry=0x7fd4461f2028, r=r@entry=0x0, s=s@entry=0x7fd453ddc628, args=0x55feb3beebd0) at modperl_callback.c:100 #10 0x7fd44f91f576 in modperl_callback_run_handlers (idx=0, type=type@entry=1, r=r@entry=0x0, c=, s=0x7fd453ddc628, pconf=pconf@entry=0x0, plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:236 #11 0x7fd44f91fd4f in modperl_callback_connection (idx=, c=, run_mode=) at modperl_callback.c:359 #12 0x55feaf10cdf0 in ap_run_process_connection (c=c@entry=0x7fd4461f22b8) at connection.c:42 #13 0x55feaf10d340 in ap_process_connection (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0) at connection.c:226 #14 0x7fd4523f3e6b in process_socket (bucket_alloc=0x7fd4461f0028, my_thread_num=1, my_child_num=0, sock=0x7fd4461f20a0, p=0x7fd4461f2028, thd=0x7fd453eb27a0) at worker.c:631 #15 worker_thread (thd=0x7fd453eb27a0, dummy=) at worker.c:990 #16 0x7fd453418454 in start_thread (arg=0x7fd44740d700) at pthread_create.c:334 #17 0x7fd453155ecd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 -- Niko Tyni nt...@debian.org
Bug#819787: libdbix-class-schema-loader-perl: FTBFS: t/10_01sqlite_common.t failure
On Wed, Apr 06, 2016 at 01:07:17PM +0200, László Böszörményi wrote: > On Wed, Apr 6, 2016 at 11:53 AM, Niko Tyni <nt...@debian.org> wrote: > > This is due to a change in 'PRAGMA table_info' behaviour in 3.12.0. The > > "type" column in PRAGMA table_info() is now a blank string when the > > target object is a view. > It seems it'll stay. Please read the opinion of the main SQLite3 > developer[1]: > "This could easily be considered a bug fix rather than a regression." > There are examples in his mail which demonstrate why a type of view is > unambiguous and should not be depend on. Hence they chose to return an > empty string for these queries. OTOH there's this trunk commit from yesterday: http://www.sqlite.org/src/info/fb555c3c2af7f5e6 which looks like it's trying to restore the older behaviour? -- Niko
Bug#819787: libdbix-class-schema-loader-perl: FTBFS: t/10_01sqlite_common.t failure
On Sat, Apr 02, 2016 at 12:10:20PM +0300, Niko Tyni wrote: > Package: libdbix-class-schema-loader-perl > Version: 0.07045-1 > Severity: serious > User: debian-p...@lists.debian.org > Usertags: autopkgtest > X-Debbugs-Cc: sqli...@packages.debian.org > > As noticed by the ci.debian.net test setup, this package > currently fails its test suite, making it fail to build. > > > https://ci.debian.net/packages/libd/libdbix-class-schema-loader-perl/unstable/amd64/ > >not ok 301 - columns for views are introspected > ># Failed test 'columns for views are introspected' ># at t/10_01sqlite_common.t line 171. ># got: '' ># expected: 'integer' This is due to a change in 'PRAGMA table_info' behaviour in 3.12.0. The "type" column in PRAGMA table_info() is now a blank string when the target object is a view. The type is exposed to the Perl side via the DBI column_info() method, key 'TYPE_NAME'. See DBD::SQLite::column_info() at https://sources.debian.net/src/libdbd-sqlite3-perl/1.50-1/lib/DBD/SQLite.pm/#L838 or so. There's a thread about this at http://thread.gmane.org/gmane.comp.db.sqlite.general/100856 but it doesn't seem quite clear yet if this is an accidental regression or something that will stay. In case it stays, I suppose DBD::SQLite could work around it centrally by implementing TYPE_NAME in a different way. -- Niko Tyni nt...@debian.org
Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure
On Wed, Apr 06, 2016 at 08:36:51AM +0200, László Böszörményi (GCS) wrote: > On Sat, Apr 2, 2016 at 9:40 PM, Niko Tyni <nt...@debian.org> wrote: > > The root cause is that sqlite3_column_decltype() quotes its output in > > 3.12.0, where previously it didn't. > [...] > > So is this an intentional change or a regression? > I still don't know, but will post here what upstream says about this. > I've reported this issue[1], but the mailing list is private (online > bug reporting is not possible). :( All I know they've read it. Thanks! There's a public archive of the sqlite-users list on gmane.org, here's a link to the relevant thread there FWIW: http://thread.gmane.org/gmane.comp.db.sqlite.general/100862 -- Niko
Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure
On Sat, Apr 02, 2016 at 12:10:31PM +0200, László Böszörményi wrote:
> 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].
The root cause is that sqlite3_column_decltype() quotes its output in
3.12.0, where previously it didn't.
I'm attaching Perl and C test cases for it.
With 3.11.1 the output of these test cases is
type:json text value:bar
and with 3.12.0 we get
type:'json text' value:bar
So is this an intentional change or a regression?
--
Niko Tyni nt...@debian.org
#!/usr/bin/perl -w
use DBI;
use strict;
my $dbh = DBI->connect("dbi:SQLite:dbname=ttt","","", { RaiseError => 1 });
$dbh->do("DROP TABLE IF EXISTS foo");
$dbh->do("CREATE TABLE foo ('value' 'json text')");
$dbh->do("INSERT INTO foo ('value') VALUES ('bar')");
my $sth = $dbh->prepare("SELECT * FROM foo");
$sth->execute;
while (my $row = $sth->fetch) {
print "type:$sth->{TYPE}[0] value:$row->[0]\n";
}
#include
#include
#include
int main(void) {
sqlite3 *db;
char *err_msg = 0;
sqlite3_stmt *res;
int rc = sqlite3_open("ttt", );
if (rc != SQLITE_OK) {
fprintf(stderr, "Cannot open database: %s\n", sqlite3_errmsg(db));
sqlite3_close(db);
return 1;
}
char sql[1024];
strcpy(sql, "DROP TABLE IF EXISTS foo; CREATE TABLE foo ('value' 'json text'); INSERT INTO foo ('value') VALUES ('bar')");
rc = sqlite3_exec(db, sql, NULL, 0, _msg);
if( rc != SQLITE_OK ){
fprintf(stderr, "Can't select: %s\n", err_msg);
return 1;
}
strcpy(sql, "SELECT * FROM foo");
rc = sqlite3_prepare_v2(db, sql, -1, , 0);
if (rc != SQLITE_OK) {
fprintf(stderr, "Failed to execute statement: %s\n", sqlite3_errmsg(db));
return 1;
}
int step = sqlite3_step(res);
if (step == SQLITE_ROW) {
printf("type:%s value:%s\n",
sqlite3_column_decltype(res, 0),
sqlite3_column_text(res, 0));
}
sqlite3_finalize(res);
sqlite3_close(db);
return 0;
}
Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure
On Sat, Apr 02, 2016 at 11:20:02AM +0200, László Böszörményi (GCS) wrote: > On Sat, Apr 2, 2016 at 11:02 AM, Niko Tyni <nt...@debian.org> wrote: > > Package: libdatabase-dumptruck-perl > > Version: 1.2-2 > [...] > > As noticed by the ci.debian.net test setup, this package > > currently fails its test suite, making it fail to build. > > > > > > https://ci.debian.net/packages/libd/libdatabase-dumptruck-perl/unstable/amd64/ > > Needs further investigation, but cc'ing the sqlite3 maintainer as a > > heads-up. > I think the reason can be two things, quoting SQLite3 upstream: > - The SQLITE_DEFAULT_PAGE_SIZE is increased from 1024 to 4096. > - The SQLITE_DEFAULT_CACHE_SIZE is changed from 2000 to -2000 so the > same amount of cache memory is used by default. > > There's a detailed description[1] on these, but upstream emphasize: > "Not a Compatibility Break" / "The only thing that is changing is some > default settings. This should result in a performance increase for > many applications.". > 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. -- Niko
Bug#819115: cowsay: missing dependency on libtext-charwidth-perl
Package: cowsay Version: 3.03+dfsg1-14 Severity: serious This package is missing a dependency on libtext-charwidth-perl. % /usr/games/cowsay Can't locate Text/CharWidth.pm in @INC (you may need to install the Text::CharWidth module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.22.1 /usr/local/share/perl/5.22.1 /usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at /usr/games/cowsay line 14. BEGIN failed--compilation aborted at /usr/games/cowsay line 14. -- Niko Tyni nt...@debian.org
Bug#818924: libjson-webtoken-perl: missing dependency on libmodule-runtime-perl
Package: libjson-webtoken-perl Version: 0.10-1 Severity: serious User: debian-p...@lists.debian.org Usertags: autopkgtest This package is missing a runtime dependency on libmodule-runtime-perl. https://ci.debian.net/packages/libj/libjson-webtoken-perl/unstable/amd64/ # Failed test '/usr/bin/perl -w -M"JSON::WebToken" -e 1 2>&1 exited successfully' # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 74. # Failed test '/usr/bin/perl -w -M"JSON::WebToken" -e 1 2>&1 produced no output' # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 75. # Looks like you failed 2 tests of 2. /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t .. 1..2 # Can't locate Module/Runtime.pm in @INC (you may need to install the Module::Runtime module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.22.1 /usr/local/share/perl/5.22.1 /usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at /usr/share/perl5/JSON/WebToken.pm line 14. # BEGIN failed--compilation aborted at /usr/share/perl5/JSON/WebToken.pm line 14. -- Niko Tyni nt...@debian.org
Bug#814492: libgnome2-wnck-perl: FTBFS: Package 'xres', required by 'libwnck-1.0', not found
Package: libgnome2-wnck-perl Version: 0.16-3 Severity: serious Tags: stretch sid X-Debbugs-Cc: libwnck-...@packages.debian.org This package fails to build on current sid/amd64. It looks like libwnck-dev recently dropped its dependency on libxres-dev, making things like 'pkg-config --cflags libwnck-1.0' fail. Cc'ing the libwnck maintainers. Was this intentional? https://reproducible.debian.net/rb-pkg/unstable/amd64/libgnome2-wnck-perl.html dh_auto_configure perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Package xres was not found in the pkg-config search path. Perhaps you should add the directory containing `xres.pc' to the PKG_CONFIG_PATH environment variable Package 'xres', required by 'libwnck-1.0', not found at Makefile.PL line 46. *** can not find package libwnck-1.0 >= 2.20.0 *** check that it is properly installed and available in PKG_CONFIG_PATH at Makefile.PL line 46. dh_auto_configure: perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 LD=x86_64-linux-gnu-gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro returned exit code 1 debian/rules:4: recipe for target 'build' failed make: *** [build] Error 1 -- Niko Tyni nt...@debian.org
Bug#813792: courier-unicode: FTBFS: w3c-dtd-xhtml is gone
Package: courier-unicode Version: 1.4-1 Severity: serious This package build-depends on w3c-dtd-xhtml, which was removed from the archive a month ago. See #711332. -- Niko Tyni nt...@debian.org
Bug#813189: libio-socket-ssl-perl: FTBFS with current libssl1.0.2: t/startssl-failed.t hangs
On Sat, Jan 30, 2016 at 12:03:27PM +0200, Niko Tyni wrote: > Package: libio-socket-ssl-perl > Version: 2.022-1 > Severity: serious > X-Debbugs-Cc: open...@packages.debian.org > > The libio-socket-ssl-perl started hanging in its test suite > with libssl1.0.2 upgrade from 1.0.2e-1 to 1.0.2f-2. > > The hanging test is t/startssl-failed.t, and running it > manually shows > > perl t/startssl-failed.t > 1..9 > ok #Server Initialization > ok #client tcp connect > ok #tcp accept > ok #send non-ssl data It's looping in IO::Socket::SSL::stop_SSL, repeatedly getting 0 from Net::SSLeay::shutdown(), which seems to be just a thin wrapper for the libssl SSL_shutdown(). Reverting https://github.com/openssl/openssl/commit/f73c737c7ac908c5d6407c419769123392a3b0a9 makes things work again. Kurt, which one do you think is wrong? -- Niko Tyni nt...@debian.org
Bug#813189: libio-socket-ssl-perl: FTBFS with current libssl1.0.2: t/startssl-failed.t hangs
Package: libio-socket-ssl-perl Version: 2.022-1 Severity: serious X-Debbugs-Cc: open...@packages.debian.org The libio-socket-ssl-perl started hanging in its test suite with libssl1.0.2 upgrade from 1.0.2e-1 to 1.0.2f-2. The hanging test is t/startssl-failed.t, and running it manually shows perl t/startssl-failed.t 1..9 ok #Server Initialization ok #client tcp connect ok #tcp accept ok #send non-ssl data The libio-socket-ssl-perl package is arch:all, the actual extension linking with libssl is libnet-ssleay-perl. That one is passing its test suite, and recompiling it with 1.0.2f-2 doesn't change the situation with libio-socket-ssl-perl. Another affected package seems to be libnet-https-nb-perl, which is using libio-socket-ssl-perl. Cc'ing the openssl maintainers; any ideas? I hope I can make a smaller test case later, but I'm out of time right now. -- Niko Tyni nt...@debian.org
Bug#812093: libimager-perl: FTBFS: Failed 1/65 test programs. 0/4481 subtests failed.
Control: reassign -1 libgif7 5.1.2-0.1 Control: forwarded -1 http://sourceforge.net/p/giflib/bugs/81/ Control: retitle -1 libgif7: DGifOpen() broken because it uses unallocated memory Control: tag -1 upstream patch On Thu, Jan 21, 2016 at 06:37:30PM +1100, Tony Cook wrote: > On Wed, Jan 20, 2016 at 10:38:27PM +0200, Niko Tyni wrote: > > On Wed, Jan 20, 2016 at 02:42:04PM +0100, Chris Lamb wrote: > > > Source: libimager-perl > > > Version: 1.004+dfsg-1 > > > Severity: serious > > > Justification: fails to build from source > > > User: reproducible-bui...@lists.alioth.debian.org > > > Usertags: ftbfs > > > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > > > > libimager-perl fails to build from source in unstable/amd64: > > > > It broke with src:giflib 5.1.2-0.1 -> 5.1.1-0.2. Don't know > > why yet. > > > > % perl -MImager -e 'Imager->new->read(type => "gif", file => > > "GIF/testimg/expected.gif") or die' > > > > dies with the new giflib but not the old one. > > > > Cc'ing Matthias Klose as a heads-up, he uploaded 5.1.1-0.2. > > The read failures are caused by a bug present in both 5.1.1 and 5.1.2, > partly fixed in giflib git at commit > ef0cb9b4be572262b49fbc26fb2348683f44a517. > > A similar fix is required to DGifOpen() for Imager's GIF support to > work (reliably), reported upstream as > https://sourceforge.net/p/giflib/bugs/81/ Thanks! I can confirm that libimager-perl builds and works again for me with the attached patch to giflib. Reassigning. -- Niko Tyni nt...@debian.org >From 60d124d3e829635b5b868f5dd6de6b7421ce03b5 Mon Sep 17 00:00:00 2001 From: Niko Tyni <nt...@debian.org> Date: Thu, 21 Jan 2016 18:56:49 +0200 Subject: [PATCH] Initialize memory in DGifOpen() too Commit ef0cb9b4be572262b49fbc26fb2348683f44a517 fixed this for DGifOpenFileHandle(), but missed the other code path. Bug: http://sourceforge.net/p/giflib/bugs/81/ Bug-Debian: https://bugs.debian.org/812093 --- lib/dgif_lib.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/dgif_lib.c b/lib/dgif_lib.c index 667e939..2f8ac8b 100644 --- a/lib/dgif_lib.c +++ b/lib/dgif_lib.c @@ -166,6 +166,7 @@ DGifOpen(void *userData, InputFunc readFunc, int *Error) *Error = D_GIF_ERR_NOT_ENOUGH_MEM; return NULL; } +/*@i1@*/memset(GifFile, '\0', sizeof(GifFileType)); memset(GifFile, '\0', sizeof(GifFileType)); @@ -180,6 +181,7 @@ DGifOpen(void *userData, InputFunc readFunc, int *Error) free((char *)GifFile); return NULL; } +/*@i1@*/memset(Private, '\0', sizeof(GifFilePrivateType)); GifFile->Private = (void *)Private; Private->FileHandle = 0; -- 2.7.0.rc3
Bug#812093: libimager-perl: FTBFS: Failed 1/65 test programs. 0/4481 subtests failed.
On Wed, Jan 20, 2016 at 02:42:04PM +0100, Chris Lamb wrote: > Source: libimager-perl > Version: 1.004+dfsg-1 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > libimager-perl fails to build from source in unstable/amd64: It broke with src:giflib 5.1.2-0.1 -> 5.1.1-0.2. Don't know why yet. % perl -MImager -e 'Imager->new->read(type => "gif", file => "GIF/testimg/expected.gif") or die' dies with the new giflib but not the old one. Cc'ing Matthias Klose as a heads-up, he uploaded 5.1.1-0.2. -- Niko Tyni nt...@debian.org
Bug#811177: closed by Thomas Goirand <z...@debian.org> (Problem *not* in automysqlbackup)
On Sat, Jan 16, 2016 at 08:56:50PM +0100, Julian Andres Klode wrote:
> Control: reopen -1
> Control: reassign -1 needrestart
>
> On Sat, Jan 16, 2016 at 05:27:56PM +0100, Alexander Schier wrote:
> > And the error seems to come from /etc/needrestart/needrestart.conf,
> > which is included via
> > eval `cat "$opt_c"`
> > at line 125 *shudders*
> >
> > neither the file, nor the files in /etc/needrestart/conf.d were modified
> > by me (conf.d only contains the README).
>
> Reassigning. This is likely caused by the Perl transition, BTW.
Unlikely, given the original reporter seems to be using stable.
I can reproduce the exact same error by uncommenting line 97 in
/etc/needrestart/conf.d of needrestart_1.2-8+deb8u1, as it has a missing
semicolon (see #805755).
# Disable hints on pending kernel upgrades.
#$nrconf{kernelhints} = 0
No idea what would have uncommented that if the administrator didn't, though.
--
Niko Tyni nt...@debian.org
Bug#810910: libmath-bigint-gmp-perl: FTBFS: test failures with newer libmath-bigint-perl
Package: libmath-bigint-gmp-perl Version: 1.47-1 Severity: serious Tags: fixed-upstream User: debian-p...@lists.debian.org Usertags: autopkgtest User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs This package recently started to fail its test suite on current sid. The ci.debian.net results suggest that this happened between 2016-01-03 and 2016-01-05, probably due to libmath-bigint-perl_1.999714-1. Upstream has released 1.49, and its CHANGES suggest the problem may be already fixed there, so tentatively tagging fixed-upstream. 2016-01-03 v1.49 pjacklam * Sync test files with Math-BigInt-1.999714. 2015-12-31 v1.48 pjacklam * Sync test files with Math-BigInt-1.999713. Log excerpt: # Failed test at t/bigfltpm.inc line 185. # got: '0.78539816339745' # expected: '0.7853981633974' # Failed test at t/bigfltpm.inc line 185. # got: '-0.78539816339745' # expected: '-0.7853981633974' # Failed test at t/bigfltpm.inc line 185. # got: '-0.78539816339745' # expected: '-0.78539816339744' # Failed test at t/bigfltpm.inc line 185. # got: 'inf' # expected: 'NaN' # Failed test at t/bigfltpm.inc line 185. # got: '1' # expected: '0' # Failed test at t/bigfltpm.inc line 185. # got: '1' # expected: '0' # Looks like you failed 6 tests of 2368. [...] Test Summary Report --- t/bigfltpm.t (Wstat: 1536 Tests: 2368 Failed: 6) Failed tests: 141, 143, 173, 477, 2114-2115 Non-zero exit status: 6 t/bigintpm.t (Wstat: 512 Tests: 3707 Failed: 2) Failed tests: 677-678 Non-zero exit status: 2 Files=12, Tests=6550, 9 wallclock secs ( 1.72 usr 0.08 sys + 8.51 cusr 0.18 csys = 10.49 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#810912: libx11-xcb-perl: missing dependency on libxs-object-magic-perl
Package: libx11-xcb-perl Version: 0.15-1 Severity: serious User: debian-p...@lists.debian.org Usertags: autopkgtest This package failed its autopkgtest checks on ci.debian.net, because of a missing runtime dependency on libxs-object-magic-perl. http://ci.debian.net/packages/libx/libx11-xcb-perl/unstable/amd64/ % perl -e 'use X11::XCB' Can't locate XS/Object/Magic.pm in @INC (you may need to install the XS::Object::Magic module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.22.1 /usr/local/share/perl/5.22.1 /usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at /usr/lib/x86_64-linux-gnu/perl5/5.22/X11/XCB.pm line 18. BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl5/5.22/X11/XCB.pm line 18. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#809759: liblasso-perl: quoting problems with Perl $Config{ccflags}, unusable on 32-bit architectures
Package: liblasso-perl
Version: 2.5.0-1
Severity: grave
Tags: patch
X-Debbugs-Cc: pkg-perl-maintain...@lists.alioth.debian.org, Xavier
<x.guim...@free.fr>
On Sun, Jan 03, 2016 at 04:42:56PM +0200, Niko Tyni wrote:
> On Sun, Jan 03, 2016 at 01:44:25PM +0100, Frederic Peters wrote:
> > Xavier wrote:
>
> > > reproductible.debian.org reports an FTBFS problem on lemonldap-ng which
> > > seems to point a Lasso problem:
> > >
> > > Lasso.c: loadable library and perl binaries are mismatched (got
> > >handshake key 0x9200080, needed 0x9400080)
>
> Interesting. I can reproduce this on harris.debian.org and
> liblasso-perl 2.5.0-1+b1 with just 'perl -e "use Lasso"'.
It also happens on i386. I expect it's broken on all 32-bit
architectures.
> I think it must be something with the compiler/linker flags Lasso.so gets
> built with, but the automake terseness gets in the way by stripping that
> from the logs. I'm looking into it, but harris is really slow atm so it
> will take a while.
Indeed, it's invoking the compiler with
arm-linux-gnueabihf-gcc [...] '-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64' [...]
and the quoting breaks the definitions.
Patch attached. I've tested this as far as producing a usable Lasso.so
on harris.
--
Niko Tyni nt...@debian.org
>From 7abd488e135d540db2c4fc8ec903940a0d46570e Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Sun, 3 Jan 2016 19:51:33 +0200
Subject: [PATCH] Fix quoting of Perl ccflags
perl -V::cflags: outputs a quoted string (like '-DTHIS -DTHAT'), which
never got unquoted, but instead passed as-is to cc as
cc '-DTHIS -DTHAT'
which somewhat surprisingly defines just one preprocessor symbol "THIS"
to an unintended value "-DTHAT 1" while leaving "THAT" undefined.
% echo THIS and THAT | cpp '-DTHIS -DTHAT'
# 1 ""
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 ""
-DTHAT 1 and THAT
This broke the binary interface between Perl and the built Lasso.so
extension, resulting in the failure
Lasso.c: loadable library and perl binaries are mismatched (got
handshake key 0x9200080, needed 0x9400080)
on at least the armhf and i386 architectures, probably on all
32-bit architectures.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 7a1a6ce..c07f623 100644
--- a/configure.ac
+++ b/configure.ac
@@ -531,7 +531,7 @@ AC_ARG_ENABLE(perl, [ --disable-perl disable the Perl binding],,
if test "X$PERL" != "X"; then
PERLINSTALLSITEARCH=`$PERL -MConfig -e 'print $Config{installsitearch};'`
PERLMAN3DIR=`$PERL -MConfig -e 'print $Config{man3dir};'`
- PERL_CFLAGS=$($PERL -V::ccflags:)
+ PERL_CFLAGS=`$PERL -MConfig -e 'print $Config{ccflags};'`
else
PERLINSTALLSITEARCH=none
PERLMAN3DIR=none
--
2.6.4
Bug#809759: liblasso-perl: quoting problems with Perl $Config{ccflags}, unusable on 32-bit architectures
found 809759 2.4.1-1 tag 809759 jessie stretch sid On Sun, Jan 03, 2016 at 09:04:57PM +0200, Niko Tyni wrote: > Package: liblasso-perl > Version: 2.5.0-1 > Severity: grave > Tags: patch > > > > Lasso.c: loadable library and perl binaries are mismatched (got > > > >handshake key 0x9200080, needed 0x9400080) > > > > Interesting. I can reproduce this on harris.debian.org and > > liblasso-perl 2.5.0-1+b1 with just 'perl -e "use Lasso"'. > > It also happens on i386. I expect it's broken on all 32-bit > architectures. I see this on stable/i386 too. Please consider fixing that in a point release. Hope I got the tags right... -- Niko Tyni nt...@debian.org
Bug#809759: liblasso-perl: quoting problems with Perl $Config{ccflags}, unusable on 32-bit architectures
On Sun, Jan 03, 2016 at 09:37:28PM +0200, Niko Tyni wrote: > On Sun, Jan 03, 2016 at 09:04:57PM +0200, Niko Tyni wrote: > > Package: liblasso-perl > > Version: 2.5.0-1 > > Severity: grave > > Tags: patch > > > > > > Lasso.c: loadable library and perl binaries are mismatched (got > > > > >handshake key 0x9200080, needed 0x9400080) > > > > > > Interesting. I can reproduce this on harris.debian.org and > > > liblasso-perl 2.5.0-1+b1 with just 'perl -e "use Lasso"'. > > > > It also happens on i386. I expect it's broken on all 32-bit > > architectures. > > I see this on stable/i386 too. Please consider fixing that in a point > release. To clarify, the symptoms are a bit different on Perl 5.20 but the reason is the same. (jessie-i386)root@estella:/home/niko# perl -e 'use Lasso' Can't use an undefined value as a subroutine reference at /usr/share/perl/5.20/XSLoader.pm line 92. END failed--call queue aborted at /usr/lib/i386-linux-gnu/perl5/5.20/Lasso.pm line 92. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- Niko Tyni nt...@debian.org
Bug#808233: p10cfgd still depends on perl5
On Wed, Dec 30, 2015 at 08:24:09AM +, Debian Bug Tracking System wrote:
> > # still depends on perl5
> > found 808233 1.0-15
> Bug #808233 {Done: Bdale Garbee <bd...@gag.com>} [p10cfgd] p10cfgd: Depends
> on virtual package "perl5" which will is gone with perl/5.22
Hi Bdale, looks like something went wrong with 1.0-15 as the package
still depends on perl5. So I've reopened the bug.
--
Niko Tyni nt...@debian.org
Bug#809192: libterm-termkey-perl: FTBFS: 05flags.t: Non-zero wait status: 11
On Sun, Dec 27, 2015 at 11:35:48PM -0500, Aaron M. Ucko wrote: > Source: libterm-termkey-perl > Version: 0.16-1 > Severity: serious > Justification: fails to build from source > > Automated builds of libterm-termkey-perl have been failing with errors > of the form > > Test Summary Report > --- > t/05flags.t (Wstat: 11 Tests: 2 Failed: 0) > Non-zero wait status: 11 > Parse errors: Bad plan. You planned 4 tests but ran 2. > Files=11, Tests=100, 1 wallclock secs ( 0.08 usr 0.01 sys + 0.52 cusr > 0.04 csys = 0.65 CPU) > Result: FAIL > > (with some timing variation, of course). Could you please take a look? I can get this to happen with an unset TERM (on both amd64 and i386). Core was generated by `perl -Iblib/lib -Iblib/arch t/05flags.t'. Program terminated with signal SIGSEGV, Segmentation fault. #0 unibi_from_term (term=0x0) at uniutil.c:177 177 uniutil.c: No such file or directory. (gdb) bt #0 unibi_from_term (term=0x0) at uniutil.c:177 #1 0x7f5a6bd1c43f in load_terminfo (term=0x0, ti=0x1f1fbd0) at driver-ti.c:171 #2 new_driver (tk=, term=0x0) at driver-ti.c:278 #3 0x7f5a6bd19b1d in termkey_init (tk=tk@entry=0x1d033a0, term=0x0) at termkey.c:326 #4 0x7f5a6bd19c14 in termkey_new (fd=, flags=136, flags@entry=128) at termkey.c:404 #5 0x7f5a6bf27389 in XS_Term__TermKey_new (my_perl=, cv=) at lib/Term/TermKey.xs:400 #6 0x004bd6ea in Perl_pp_entersub (my_perl=0x1cd6010) at pp_hot.c:3270 #7 0x004b6586 in Perl_runops_standard (my_perl=0x1cd6010) at run.c:41 #8 0x00443999 in S_run_body (oldscope=1, my_perl=0x1cd6010) at perl.c:2453 #9 perl_run (my_perl=0x1cd6010) at perl.c:2376 #10 0x0041cbbb in main (argc=4, argv=0x7ffc3c971a08, env=0x7ffc3c971a30) at perlmain.c:116 unibi_from_term is in /usr/lib/x86_64-linux-gnu/libunibilium.so.0, load_terminfo and termkey_* are in in /usr/lib/x86_64-linux-gnu/libtermkey.so.1 -- Niko Tyni nt...@debian.org
Bug#809192: libterm-termkey-perl: FTBFS: 05flags.t: Non-zero wait status: 11
On Mon, Dec 28, 2015 at 04:42:03PM +0100, gregor herrmann wrote: > > I can get this to happen with an unset TERM (on both amd64 and i386). > > > > Core was generated by `perl -Iblib/lib -Iblib/arch t/05flags.t'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > Same here. Another interesting data point: > # TERM=dumb prove --blib --verbose t/05flags.t > t/05flags.t .. > 1..4 > ok 1 - Explicit UTF-8 flag preserved > ok 2 - Explicit RAW flag preserved > > And here it hangs since 5 minutes using 100% of one core ... Interrupting it in gdb gives this backtrace: #0 0x76cc8006 in compress_trie (n=0xa3f2d0) at driver-ti.c:148 #1 0x76cc8713 in new_driver (tk=, term=) at driver-ti.c:281 #2 0x76cc5b1d in termkey_init (tk=tk@entry=0x9fe330, term=0x7ec445 "dumb") at termkey.c:326 #3 0x76cc5c14 in termkey_new (fd=, flags=136, flags@entry=128) at termkey.c:404 #4 0x76ed3389 in XS_Term__TermKey_new (my_perl=, cv=) at lib/Term/TermKey.xs:400 #5 0x004bd6ea in Perl_pp_entersub (my_perl=0x7d2010) at pp_hot.c:3270 #6 0x004b6586 in Perl_runops_standard (my_perl=0x7d2010) at run.c:41 #7 0x00443999 in S_run_body (oldscope=1, my_perl=0x7d2010) at perl.c:2453 #8 perl_run (my_perl=0x7d2010) at perl.c:2376 #9 0x0041cbbb in main (argc=4, argv=0x7fffe8f8, env=0x7fffe920) at perlmain.c:116 > Not sure what to do here. Is there an underlying bug or do we need to > set TERM to something nice or should we skip the test? Setting TERM=vt100 seems to not trigger either of these problems, so I guess we could try doing that in debian/rules. Cc'ing James, the libtermkey and unibilium maintainer. Any thoughts? Would you like separate bugs about these 'unset TERM' SIGSEGV and TERM=dumb busy loop issues? -- Niko Tyni nt...@debian.org
Bug#809100: libmarc-lint-perl: FTBFS with Perl 5.22: test failures
Package: libmarc-lint-perl Version: 1.49-1 Severity: serious User: debian-p...@lists.debian.org Usertags: autopkgtest This package fails to build on current sid/amd64. Looks like the module should be using the 'version' module to compare version numbers; this was presumably broken by libbusiness-isbn-perl 2.010-1, which entered unstable recently. # Failed test 'Checking expected messages, 020: Subfield a has bad checksum, 1548794743.' # at t/check020.t line 88. # got: 'Business::ISBN version must be below 2 or above 2.02_02.' # expected: '020: Subfield a has bad checksum, 1548794743.' [...] Test Summary Report --- t/check020.t (Wstat: 2560 Tests: 31 Failed: 11) Failed tests: 7, 16, 18, 21, 23-24, 26-27, 29-31 Non-zero exit status: 10 Parse errors: Bad plan. You planned 28 tests but ran 31. t/lint.t (Wstat: 2304 Tests: 40 Failed: 9) Failed tests: 5, 7, 11, 13, 15, 17, 19, 21, 23 Non-zero exit status: 9 -- Niko Tyni nt...@debian.org
Bug#809110: libxml-compile-dumper-perl: FTBFS with Perl 5.22: needs dependency on libpadwalker-perl
Package: libxml-compile-dumper-perl Version: 0.14-1 Severity: serious Tags: stretch sid User: debian-p...@lists.debian.org Usertags: autopkgtest perl-5.22-transition Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=100488 Control: block 796345 with -1 This package fails to build on current sid/amd64. It was earlier unbuildable because of the build dependency on libdata-dump-streamer-perl, which was only recently fixed to support Perl 5.22. It looks like newer perls have changed so that this module now needs the PadWalker module available, otherwise it will fail to load. See [rt.cpan.org #100488]. A build and runtime dependency on libpadwalker-perl therefore seems to be in order, and makes the tests pass here. Can't locate object method "object_2svref" via package "B::PADNAME" at /usr/lib/x86_64-linux-gnu/perl5/5.22/Data/ Dump/Streamer.pm line 3718. # Looks like your test exited with 25 before it could output anything. t/20dump.t .. 1..7 Dubious, test returned 25 (wstat 6400, 0x1900) Failed 7/7 subtests -- Niko Tyni nt...@debian.org
Bug#809100: libmarc-lint-perl: FTBFS with newer Business::ISBN: test failures
Control: tag -1 patch
On Sun, Dec 27, 2015 at 04:53:08PM +0200, Niko Tyni wrote:
> On Sun, Dec 27, 2015 at 01:32:55PM +0200, Niko Tyni wrote:
> > Package: libmarc-lint-perl
> > Version: 1.49-1
> > Severity: serious
> > User: debian-p...@lists.debian.org
> > Usertags: autopkgtest
> >
> > This package fails to build on current sid/amd64.
> >
> > Looks like the module should be using the 'version' module to compare
> > version numbers; this was presumably broken by libbusiness-isbn-perl
> > 2.010-1, which entered unstable recently.
>
> In fact the fault is with Business::ISBN, which messed up its
> version numbering, as discussed in
> https://github.com/briandfoy/business-isbn/pull/2
>
> Looks like Business::ISBN upstream isn't planning to fix this,
> so I suppose MARC::Lint needs to adapt.
I suggest that we patch the VERSION comparisons to check for >= 2.010, add
versioned dependencies to debian/control, and make libbusiness-isbn-perl
Break libmarc-lint-perl (<< 1.49-2). See the attached patch.
Does that make sense?
--
Niko Tyni nt...@debian.org
>From 2f64649306df12e4fb41944280c9eb11e2f3fb06 Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Sun, 27 Dec 2015 17:02:33 +0200
Subject: [PATCH] Fix test failures due to Business::ISBN version mess
Business::ISBN changed its version from 2.09 to 2.010,
breaking the version comparisons in MARC::Lint.
---
debian/control | 4 ++--
lib/MARC/Lint.pm | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/debian/control b/debian/control
index 227a6b4..a54 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Section: perl
Priority: optional
Build-Depends: debhelper (>= 8)
Build-Depends-Indep: perl,
- libbusiness-isbn-perl,
+ libbusiness-isbn-perl (>= 2.010),
libmarc-record-perl
Standards-Version: 3.9.6
Vcs-Browser: https://anonscm.debian.org/cgit/pkg-perl/packages/libmarc-lint-perl.git
@@ -22,7 +22,7 @@ Package: libmarc-lint-perl
Architecture: all
Depends: ${perl:Depends},
${misc:Depends},
- libbusiness-isbn-perl,
+ libbusiness-isbn-perl (>= 2.010),
libmarc-record-perl
Description: Perl extension for checking validity of MARC records
MARC::Lint is a Perl module for checking the validity of MARC records. Most
diff --git a/lib/MARC/Lint.pm b/lib/MARC/Lint.pm
index d96e78b..c401622 100755
--- a/lib/MARC/Lint.pm
+++ b/lib/MARC/Lint.pm
@@ -319,14 +319,14 @@ sub check_020 {
else {
if ((length ($isbnno) == 10)) {
-if ($Business::ISBN::VERSION gt '2.02_01') {
+if ($Business::ISBN::VERSION ge '2.010') {
$self->warn( "020: Subfield a has bad checksum, $data." ) if (Business::ISBN::valid_isbn_checksum($isbnno) != 1);
} #if Business::ISBN version higher than 2.02_01
elsif ($Business::ISBN::VERSION lt '2') {
$self->warn( "020: Subfield a has bad checksum, $data." ) if (Business::ISBN::is_valid_checksum($isbnno) != 1);
} #elsif Business::ISBN version lower than 2
else {
-$self->warn( "Business::ISBN version must be below 2 or above 2.02_02." );
+$self->warn( "Business::ISBN version must be below 2 or at least 2.010." );
} #else Business::ISBN version between 2 and 2.02_02
} #if 10 digit ISBN has invalid check digit
# do validation check for 13 digit isbn
--
2.6.4
Bug#809100: libmarc-lint-perl: FTBFS with newer Business::ISBN: test failures
On Sun, Dec 27, 2015 at 01:32:55PM +0200, Niko Tyni wrote: > Package: libmarc-lint-perl > Version: 1.49-1 > Severity: serious > User: debian-p...@lists.debian.org > Usertags: autopkgtest > > This package fails to build on current sid/amd64. > > Looks like the module should be using the 'version' module to compare > version numbers; this was presumably broken by libbusiness-isbn-perl > 2.010-1, which entered unstable recently. In fact the fault is with Business::ISBN, which messed up its version numbering, as discussed in https://github.com/briandfoy/business-isbn/pull/2 Looks like Business::ISBN upstream isn't planning to fix this, so I suppose MARC::Lint needs to adapt. -- Niko Tyni nt...@debian.org
Bug#809110: libxml-compile-dumper-perl: FTBFS with Perl 5.22: needs dependency on libpadwalker-perl
Control: reassign -1 libdata-dump-streamer-perl 2.39-1 On Sun, Dec 27, 2015 at 02:10:03PM +0200, Niko Tyni wrote: > Package: libxml-compile-dumper-perl > Version: 0.14-1 > Severity: serious > Tags: stretch sid > User: debian-p...@lists.debian.org > Usertags: autopkgtest perl-5.22-transition > Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=100488 > Control: block 796345 with -1 > > This package fails to build on current sid/amd64. > It looks like newer perls have changed so that this module > now needs the PadWalker module available, otherwise it will > fail to load. See [rt.cpan.org #100488]. > > A build and runtime dependency on libpadwalker-perl therefore seems to > be in order, and makes the tests pass here. > > Can't locate object method "object_2svref" via package "B::PADNAME" at > /usr/lib/x86_64-linux-gnu/perl5/5.22/Data/ > Dump/Streamer.pm line 3718. The dependency needs to go in lbdata-dump-streamer-perl. >From the documentation: If PadWalker 1.0 is installed you can use DumpLex() to try to automatically determine the names of the vars being dumped. As long as the vars being dumped have my or our declarations in scope the vars will be correctly named. Padwalker will also be used instead of the B:: modules when dumping closures when it is available. So I suppose the B:: modules have become incompatible, and Data::Dump::Streamer no longer works without PadWalker. The package currently Recommends: libpadwalker-perl, so just upgrading that should be enough to fix the immediate problem. -- Niko Tyni nt...@debian.org
Bug#808826: libkavorka-perl: FTBFS: Can't locate object method "_set_declared_name" via package "Kavorka::Sub::Fun"
Control: tag -1 patch
Control: forwarded -1 https://rt.cpan.org/Public/Bug/Display.html?id=110623
On Fri, Dec 25, 2015 at 11:00:18AM +0200, Niko Tyni wrote:
> use Devel::CallParser;
>
> sub f {
> my $arg = shift;
>
> { my $arg; } # ???
> print $arg ? "ok\n" : "not ok\n";
> }
>
> f(1);
>
> which gives "ok" on 5.20 and "not ok" on 5.22.
Patch attached, sent upstream in
https://rt.cpan.org/Public/Bug/Display.html?id=110623
Will upload shortly.
--
Niko Tyni nt...@debian.org
>From ba92f4cba247c91d100e05f2b83dd093055e462b Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Fri, 25 Dec 2015 18:53:08 +0200
Subject: [PATCH] Fix a pad problem with Perl >= 5.21.4 on threaded builds
This broke at least the Kavorka and Moops distributions.
Bug-Debian: https://bugs.debian.org/808826
Bug: https://rt.cpan.org/Public/Bug/Display.html?id=110623
---
lib/Devel/CallParser.xs | 10 +++---
t/pad2.t| 15 +++
2 files changed, 22 insertions(+), 3 deletions(-)
create mode 100644 t/pad2.t
diff --git a/lib/Devel/CallParser.xs b/lib/Devel/CallParser.xs
index 6643739..847742c 100644
--- a/lib/Devel/CallParser.xs
+++ b/lib/Devel/CallParser.xs
@@ -323,10 +323,14 @@ static int my_keyword_plugin(pTHX_
* The core bug was supposedly fixed in Perl 5.19.4, but actually
* that version exhibits a different bug also apparently related
* to padrange. Restoring the pad's fill pointer works around
- * this bug too. So for now this workaround is used with no
- * upper bound on the Perl version.
+ * this bug too.
+ *
+ * The other padrange bug was fixed in Perl 5.19.5 (commit aa033da),
+ * so the workaround is no longer needed after that, but it remains
+ * harmless until v5.21.4 (commit c9859fb) where it starts breaking
+ * (see t/pad2.t.)
*/
-#define MUST_RESTORE_PAD_FILL PERL_VERSION_GE(5,17,6)
+#define MUST_RESTORE_PAD_FILL PERL_VERSION_GE(5,17,6) && ! PERL_VERSION_GE(5,19,5)
#if MUST_RESTORE_PAD_FILL
I32 padfill = av_len(PL_comppad);
#endif /* MUST_RESTORE_PAD_FILL */
diff --git a/t/pad2.t b/t/pad2.t
new file mode 100644
index 000..92c6dab
--- /dev/null
+++ b/t/pad2.t
@@ -0,0 +1,15 @@
+use warnings;
+use strict;
+
+use Test::More tests => 1;
+
+use Devel::CallParser;
+
+sub f {
+ my $arg = shift;
+
+ { my $arg; } # ???
+ ok($arg, '$arg stays set after a "my $arg" block');
+}
+
+f(1);
--
2.6.4
Bug#809009: libmoops-perl: FTBFS: Can't locate object method "done" via package "Moops::Parser"
Control: reassign -1 libdevel-callparser-perl Control: forcemerge 808826 -1 On Sat, Dec 26, 2015 at 03:27:04AM +, Chris Lamb wrote: > Source: libmoops-perl > Version: 0.034-1 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > libmoops-perl fails to build from source in unstable/amd64: This is #808826 in libdevel-callparser-perl, which I'm about to fix. Merging. -- Niko Tyni nt...@debian.org
Bug#808629: Bug#798096: usrmerge: Conversion fails if libautodie-perl package is installed
tag 798096 patch fixed-upstream
tag 808629 patch fixed-upstream
thanks
On Tue, Dec 22, 2015 at 09:11:43AM +0200, Niko Tyni wrote:
>
> Once there's a fix, the separate libautodie-perl needs to be fixed
> first so that installing it over the Perl core version will not
> reintroduce the bug.
>
> FWIW I made some progress on the upstream ticket yesterday but
> it's not quite there yet. It would have been nice to hear about
> this earlier.
Niels has merged the attached patch upstream (thanks!), so I suppose
it's OK for us to backport it to both libautodie-perl and perl.
Cc'ing Niels. Please let us know if you think it's too soon for that.
--
Nio
>From c1b4fc4a319f8139d1cd6770bfb7b72a59ae232d Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Mon, 21 Dec 2015 19:20:12 +0200
Subject: [PATCH] Fix a scoping issue with "no autodie" and the "system" sub
Don't queue nonexisting subs for reinstalling later when
exiting the 'no autodie' scope.
FIXME: if the original sub 'can be undef for "CORE::" subs', does this
break for those? Is that the case when $symbol =~ /::/, as guarded for
on L566?
Bug: https://github.com/pjf/autodie/issues/69
Bug-Debian: https://bugs.debian.org/798096
---
lib/Fatal.pm | 7 ++-
t/no-all.t | 22 ++
t/no-default.t | 23 +++
3 files changed, 51 insertions(+), 1 deletion(-)
create mode 100755 t/no-all.t
create mode 100755 t/no-default.t
diff --git a/lib/Fatal.pm b/lib/Fatal.pm
index 62ec1c0..d0f9cef 100644
--- a/lib/Fatal.pm
+++ b/lib/Fatal.pm
@@ -581,7 +581,12 @@ sub unimport {
# Record the current sub to be reinstalled at end of scope
# and then restore the original (can be undef for "CORE::"
# subs)
-$reinstall_subs{$symbol} = \&$sub;
+
+{
+no strict 'refs';
+$reinstall_subs{$symbol} = \&$sub
+if exists ${"${pkg}::"}{$symbol};
+}
$uninstall_subs{$symbol} = $Original_user_sub{$sub};
}
diff --git a/t/no-all.t b/t/no-all.t
new file mode 100755
index 000..1a503f6
--- /dev/null
+++ b/t/no-all.t
@@ -0,0 +1,22 @@
+#!/usr/bin/perl
+
+package foo;
+use warnings;
+use strict;
+use Test::More tests => 1;
+use autodie qw(:all);
+
+use_system();
+ok("system() works with a lexical 'no autodie' block (github issue #69");
+
+sub break_system {
+no autodie;
+open(my $fh, "<", 'NONEXISTENT');
+ok("survived failing open");
+}
+
+sub use_system {
+system($^X, '-e' , 1);
+}
+
+1;
diff --git a/t/no-default.t b/t/no-default.t
new file mode 100755
index 000..44d2acf
--- /dev/null
+++ b/t/no-default.t
@@ -0,0 +1,23 @@
+#!/usr/bin/perl
+
+package foo;
+use warnings;
+use strict;
+use Test::More tests => 2;
+use autodie;
+
+
+use_system();
+ok("system() works with a lexical 'no autodie' block (github issue #69");
+break_system();
+
+sub break_system {
+no autodie;
+open(my $fh, "<", 'NONEXISTENT');
+ok("survived failing open");
+}
+
+sub use_system {
+system($^X, '-e' , 1);
+}
+1;
--
2.6.4
Bug#808826: libkavorka-perl: FTBFS: Can't locate object method "_set_declared_name" via package "Kavorka::Sub::Fun"
retitle 808826 libdevel-callparser-perl: breaks parsing with 5.22?
reassign 808826 libdevel-callparser-perl 0.002-1
affects 808826 + libparse-keyword-perl
thanks
> > It's indeed a regression caused by the perl 5.20 -> 5.22 upgrade.
> > Not sure why our rebuilds didn't catch it.
>
> Evidence seems to be pointing at Parse::Keyword.
... and further to one of its reverse dependencies, Devel::CallParser.
I've got it down to this:
#!/usr/bin/perl -w
use Devel::CallParser;
sub f {
my $arg = shift;
{ my $arg; } # ???
print $arg ? "ok\n" : "not ok\n";
}
f(1);
which gives "ok" on 5.20 and "not ok" on 5.22.
--
Niko Tyni nt...@debian.org
Bug#808560: [buildd-tools-devel] Bug#808560: sbuild: Use of uninitialized value $_ in concatenation (.)
On Wed, Dec 23, 2015 at 11:27:43AM +0200, Niko Tyni wrote: > I can confirm that sbuild works fine for me again with your patch. > > Please consider an upload soon, this is blocking the Perl 5.22 > transition. Oh, and we should probably add a Breaks entry on the perl side for earlier versions when this is fixed, to make sure partial upgrades pull in a working version. I've filed #808805 about that. -- Niko Tyni nt...@debian.org
Bug#808825: libperl-apireference-perl: FTBFS: missing support for Perl 5.22.1
Package: libperl-apireference-perl
Version: 0.21-2
Severity: serious
User: debian-p...@lists.debian.org
Usertags: perl-5.22-transition
Control: block 796345 with -1
This package fails to build with Perl 5.22.1, currently in unstable.
[...]
Processing: 5.22.0
echo Current Perl is `perl -MConfig -we'printf("%d_%03d_%03d.pm",
$Config{PERL_REVISION}, $Config{PERL_VERSION}, $Config{PERL_SUBVERSION})'`
Current Perl is 5_022_001.pm
test -f lib/Perl/APIReference/V`perl -MConfig -we'printf("%d_%03d_%03d.pm",
$Config{PERL_REVISION}, $Config{PERL_VERSION}, $Config{PERL_SUBVERSION})'`
debian/rules:8: recipe for target 'regenerated-stamp' failed
--
Niko Tyni nt...@debian.org
Bug#808826: libkavorka-perl: FTBFS: Can't locate object method "_set_declared_name" via package "Kavorka::Sub::Fun"
Package: libkavorka-perl Version: 0.036-1 Severity: serious Forwarded: https://rt.cpan.org/Ticket/Display.html?id=109841 This package fails to build on current sid. It's not clear if this is a Perl 5.22 regression or something else, but it fails reliably here. t/01basic.t ok 1 - use Kavorka; 1..1 ok Can't locate object method "_set_declared_name" via package "Kavorka::Sub::Fun" at /<>/blib/lib/Kavorka/Sub.pm line 182. t/02named-functions.t .. Dubious, test returned 255 (wstat 65280, 0xff00) No subtests run [...] Files=43, Tests=1, 16 wallclock secs ( 0.22 usr 0.06 sys + 15.33 cusr 0.68 csys = 16.29 CPU) Result: FAIL Failed 41/43 test programs. 0/1 subtests failed. -- Niko Tyni nt...@debian.org
Bug#808826: libkavorka-perl: FTBFS: Can't locate object method "_set_declared_name" via package "Kavorka::Sub::Fun"
Control: block 796345 with -1 On Wed, Dec 23, 2015 at 04:05:27PM +0200, Niko Tyni wrote: > Package: libkavorka-perl > Version: 0.036-1 > Severity: serious > Forwarded: https://rt.cpan.org/Ticket/Display.html?id=109841 > > This package fails to build on current sid. > Can't locate object method "_set_declared_name" via package > "Kavorka::Sub::Fun" at /<>/blib/lib/Kavorka/Sub.pm line 182. > t/02named-functions.t .. > Dubious, test returned 255 (wstat 65280, 0xff00) It's indeed a regression caused by the perl 5.20 -> 5.22 upgrade. Not sure why our rebuilds didn't catch it. It works on stretch, then 'apt-get install perl' breaks it. I see no source versions changed except perl. Log of the upgrade: Preparing to unpack .../libparams-classify-perl_0.013-5+b1_amd64.deb ... Unpacking libparams-classify-perl (0.013-5+b1) over (0.013-5) ... Preparing to unpack .../libsub-name-perl_0.14-1+b1_amd64.deb ... Unpacking libsub-name-perl (0.14-1+b1) over (0.14-1) ... Preparing to unpack .../libpadwalker-perl_2.2-1+b1_amd64.deb ... Unpacking libpadwalker-perl (2.2-1+b1) over (2.2-1) ... Processing triggers for man-db (2.7.5-1) ... dpkg: perl-modules: dependency problems, but removing anyway as you requested: perl depends on perl-modules (>= 5.20.2-6). (Reading database ... 19995 files and directories currently installed.) Removing perl-modules (5.20.2-6) ... (Reading database ... 19270 files and directories currently installed.) Preparing to unpack /perl_5.22.1-2_amd64.deb ... Unpacking perl (5.22.1-2) over (5.20.2-6) ... Selecting previously unselected package perl-modules-5.22. Preparing to unpack .../perl-modules-5.22_5.22.1-2_all.deb ... Unpacking perl-modules-5.22 (5.22.1-2) ... Selecting previously unselected package libperl5.22:amd64. Preparing to unpack .../libperl5.22_5.22.1-2_amd64.deb ... Unpacking libperl5.22:amd64 (5.22.1-2) ... Preparing to unpack /perl-base_5.22.1-2_amd64.deb ... Unpacking perl-base (5.22.1-2) over (5.20.2-6) ... Processing triggers for man-db (2.7.5-1) ... Setting up perl-base (5.22.1-2) ... (Reading database ... 20572 files and directories currently installed.) Preparing to unpack .../liblocale-gettext-perl_1.07-1+b1_amd64.deb ... Unpacking liblocale-gettext-perl (1.07-1+b1) over (1.07-1) ... Preparing to unpack .../libscope-upper-perl_0.28-1+b1_amd64.deb ... Unpacking libscope-upper-perl (0.28-1+b1) over (0.28-1) ... Preparing to unpack .../libmouse-perl_2.4.5-1+b1_amd64.deb ... Unpacking libmouse-perl (2.4.5-1+b1) over (2.4.5-1) ... Preparing to unpack .../libclass-load-xs-perl_0.09-1+b1_amd64.deb ... Unpacking libclass-load-xs-perl (0.09-1+b1) over (0.09-1) ... Preparing to unpack .../libscalar-list-utils-perl_1%3a1.42-1+b1_amd64.deb ... Unpacking libscalar-list-utils-perl (1:1.42-1+b1) over (1:1.42-1) ... Preparing to unpack .../libparams-validate-perl_1.21-1+b1_amd64.deb ... Unpacking libparams-validate-perl (1.21-1+b1) over (1.21-1) ... Preparing to unpack .../libsub-identify-perl_0.12-1+b1_amd64.deb ... Unpacking libsub-identify-perl (0.12-1+b1) over (0.12-1) ... Preparing to unpack .../libdevel-callparser-perl_0.002-1+b2_amd64.deb ... Unpacking libdevel-callparser-perl (0.002-1+b2) over (0.002-1+b1) ... Preparing to unpack .../libmoose-perl_2.1604-1+b1_amd64.deb ... Unpacking libmoose-perl (2.1604-1+b1) over (2.1604-1) ... Preparing to unpack .../libdata-alias-perl_1.20-1+b1_amd64.deb ... Unpacking libdata-alias-perl (1.20-1+b1) over (1.20-1) ... Preparing to unpack .../libdevel-callchecker-perl_0.007-1+b1_amd64.deb ... Unpacking libdevel-callchecker-perl (0.007-1+b1) over (0.007-1) ... Preparing to unpack .../libvariable-magic-perl_0.59-1+b1_amd64.deb ... Unpacking libvariable-magic-perl (0.59-1+b1) over (0.59-1) ... Preparing to unpack .../libdatetime-perl_2%3a1.21-1+b1_amd64.deb ... Unpacking libdatetime-perl (2:1.21-1+b1) over (2:1.21-1) ... Preparing to unpack .../libparse-keyword-perl_0.08-2+b1_amd64.deb ... Unpacking libparse-keyword-perl (0.08-2+b1) over (0.08-2) ... Preparing to unpack .../liblist-moreutils-perl_0.413-1+b1_amd64.deb ... Unpacking liblist-moreutils-perl (0.413-1+b1) over (0.413-1) ... Preparing to unpack .../libparams-util-perl_1.07-2+b2_amd64.deb ... Unpacking libparams-util-perl (1.07-2+b2) over (1.07-2+b1) ... Preparing to unpack .../libtext-charwidth-perl_0.04-7+b4_amd64.deb ... Unpacking libtext-charwidth-perl (0.04-7+b4) over (0.04-7+b3) ... Preparing to unpack .../libtext-iconv-perl_1.7-5+b3_amd64.deb ... Unpacking libtext-iconv-perl (1.7-5+b3) over (1.7-5+b2) ... Preparing to unpack .../libpackage-stash-xs-perl_0.28-2+b2_amd64.deb ... Unpacking libpackage-stash-xs-perl (0.28-2+b2) over (0.28-2+b1) ... Preparing to unpack .../libb-hooks-op-check-perl_0.19-2+b2_amd64.deb ... Unpacking libb-hooks-op-check-perl (0.19-2+b2) over (0.19-2+b1
Bug#808826: libkavorka-perl: FTBFS: Can't locate object method "_set_declared_name" via package "Kavorka::Sub::Fun"
retitle 808826 libparse-keyword-perl: breaks Moo::Role on Perl 5.22?
reassign 808826 libparse-keyword-perl 0.08-2
affects 808826 libmoops-perl libkavorka-perl
thanks
On Wed, Dec 23, 2015 at 08:03:33PM +0200, Niko Tyni wrote:
> On Wed, Dec 23, 2015 at 04:05:27PM +0200, Niko Tyni wrote:
> > Package: libkavorka-perl
> > Version: 0.036-1
> > Severity: serious
> > Forwarded: https://rt.cpan.org/Ticket/Display.html?id=109841
> >
> > This package fails to build on current sid.
>
> > Can't locate object method "_set_declared_name" via package
> > "Kavorka::Sub::Fun" at /<>/blib/lib/Kavorka/Sub.pm line 182.
> > t/02named-functions.t ..
> > Dubious, test returned 255 (wstat 65280, 0xff00)
>
> It's indeed a regression caused by the perl 5.20 -> 5.22 upgrade.
> Not sure why our rebuilds didn't catch it.
Evidence seems to be pointing at Parse::Keyword. This script:
#!/usr/bin/perl -w
use strict;
package M;
use Moo::Role;
has myattr => (is => 'rwp');
1;
package main;
use Parse::Keyword {};
my $m = bless {}, 'M';
$m->_set_myattr("foo");
print $m->myattr, "\n";
1;
outputs "foo" on 5.20 as expected, but dies on 5.22 with
Can't locate object method "_set_myattr" via package "M" at m.pl line 13.
Removing the "use Parse::Keyword {};" line makes it go away.
The only two reverse dependencies (both build and runtime) of
libparse-keyword-perl,
libkavorka-perl and libmoops-perl, both currently fail to build from source with
similar messages.
I'm therefore tentatively reassigning this to libparse-keyword-perl,
although it would be nice to distill this further down to something that
takes Moo::Role out of the equation.
I note that Parse::Keyword is officially not recommended for use, so
it might not be worth it blocking the Perl 5.22 transition for this.
Quoting:
DESCRIPTION
DO NOT USE!
This module has fundamental errors in the way it handles closures,
which are not fixable. Runtime keywords will never be able to work
properly with the current design of this module. There are certain
cases where this module is still safe to use (keywords that only
have effect at compile time, or keywords that never call any of
the "parse_*" functions), but that is limiting enough to make
this module mostly worthless, and I likely won't be continuing
to maintain it. Be warned!
--
Niko Tyni nt...@debian.org
Bug#808560: [buildd-tools-devel] Bug#808560: sbuild: Use of uninitialized value $_ in concatenation (.)
On Tue, Dec 22, 2015 at 09:00:20AM +0200, Niko Tyni wrote: > On Tue, Dec 22, 2015 at 07:48:11AM +0100, Johannes Schauer wrote: > > If the problem is this change of behaviour as you described it, then the > > fix is > > a very simple one: > > Cool, thanks! I'm not sure if there are other problems, this was the > one I found first. I can confirm that sbuild works fine for me again with your patch. Please consider an upload soon, this is blocking the Perl 5.22 transition. Thanks again, -- Niko Tyni nt...@debian.org
Bug#799718: libthread-pool-perl: nondeterministic test failure in t/Pool01.t
On Mon, Dec 21, 2015 at 06:35:33PM +, Chris Lamb wrote: > severity 799718 serious > thanks > > > This package failed to build in the reproducible.debian.net CI setup, > > and I can reproduce this locally by running the test in a loop while > > loading the host. Apparently there's a race condition in the test suite. > > Given that it makes the package unreliably build from source, this warrants > an RC severity. While I'm not going to start a severity war (and agree that the package should be fixed), this is not the traditional interpretation. FTBFS bugs have been routinely downgraded to 'important' in the past when the build failures were nondeterministic and the build succeeded part of the time. My understanding is that the baseline requirement from the release team is that 'buildds need to be able to build the packages'. It may be that the awesome continuous integration that reproducible.d.n is doing has changed this picture and we should start treating all such bugs as release critical, but discussing that first with the release team and/or on the debian-devel list would be appropriate IMHO. -- Niko Tyni nt...@debian.org
Bug#808560: sbuild: Use of uninitialized value $_ in concatenation (.)
Control: block 796345 with -1 On Sun, Dec 20, 2015 at 06:27:09PM -0500, John David Anglin wrote: > Package: sbuild > Version: 0.66.0-5 > Severity: normal > > Dear Maintainer, > > After upgrading perl to 5.22.1-2, sbuild fails to move .debs to the upload > directory. This can be seen for example in the following build log: > https://buildd.debian.org/status/fetch.php?pkg=r-cran-ape=hppa=3.4-1=1450633031 > > We have the following errors: > Use of uninitialized value $_ in concatenation (.) or string at > /usr/share/perl5/Sbuild/Build.pm line 1918. My preliminary findings are that a change in Perl broke the sbuild parsing of .changes files, in lib/Sbuild/Build.pm:1865 or so. This has different behaviour on 5.20 and 5.22: perl -MData::Dumper -e '@a=(split( /\s+/, "foo"))[5]; print Dumper \@a' which shows an empty array on 5.20 and an array of one undef element on 5.22. I'm not yet sure if this is a regression in Perl or a bugfix. Will follow up later when I know more. Marking this as blocking the Perl transition to testing for now. -- Niko Tyni nt...@debian.org
Bug#808560: [buildd-tools-devel] Bug#808560: sbuild: Use of uninitialized value $_ in concatenation (.)
On Tue, Dec 22, 2015 at 07:48:11AM +0100, Johannes Schauer wrote: > Quoting Niko Tyni (2015-12-21 23:43:24) > > My preliminary findings are that a change in Perl broke the sbuild parsing > > of > > .changes files, in lib/Sbuild/Build.pm:1865 or so. > > > > This has different behaviour on 5.20 and 5.22: > > > > perl -MData::Dumper -e '@a=(split( /\s+/, "foo"))[5]; print Dumper \@a' > > > > which shows an empty array on 5.20 and an array of one undef element > > on 5.22. > > > > I'm not yet sure if this is a regression in Perl or a bugfix. > > Will follow up later when I know more. Marking this as blocking the Perl > > transition to testing for now. FWIW it turns out it's a bugfix not a regression in Perl. The relevant perl5220delta entry is List slices now return an empty list only if the original list was empty (or if there are no indices). Formerly, a list slice would return an empty list if all indices fell outside the original list; now it returns a list of undef values in that case. [perl #114498]. and the gory details are at https://rt.perl.org/Public/Bug/Display.html?id=114498 > > If the problem is this change of behaviour as you described it, then the fix > is > a very simple one: Cool, thanks! I'm not sure if there are other problems, this was the one I found first. -- Niko Tyni nt...@debian.org
Bug#799718: libthread-pool-perl: nondeterministic test failure in t/Pool01.t
On Mon, Dec 21, 2015 at 09:05:43PM +, Chris Lamb wrote: > Disagree on almost all points but I find debates about bug severities > so utterly demotivating I will defer. I'm sorry to hear that. I certainly didn't want to demotivate you. On the contrary, I very much appreciate your work on Debian. Many thanks for that! FWIW I'd have fixed this bug last night by marking the failing test as TODO, but was caught out by #808560 which took priority by preventing me to upload :) -- Niko
Bug#808603: debhelper: dh_installmanpages is broken
Package: debhelper
Version: 9.20151220
Severity: serious
It looks like
https://anonscm.debian.org/cgit/debhelper/debhelper.git/commit/?id=1bd369cc52115fd179a46d6f8d9af6e9f126ffa8
broke dh_installmanpages, which has
@allpackages=getpackages('');
The new code handles a missing argument but not an empty one.
+ my ($type) = @_;
+ $type //= 'both';
This made at least four packages FTBFS, see
#808592 #808590 #808589 #808588
dh_installmanpages
dh_installmanpages: This program is deprecated, switch to dh_installman.
dh_installmanpages: getpackages: First argument must be one of "arch",
"indep" or "both"
debian/rules:35: recipe for target 'binary-arch' failed
Not sure which side to fix so I'm leaving it to you.
codesearch.debian.net reports no other hits for getpackages("") or
getpackages('') FWIW.
--
Niko Tyni nt...@debian.org
Bug#798096: usrmerge: Conversion fails if libautodie-perl package is installed
Control: severity -1 normal Control: clone -1 -2 Control: reassign -2 perl 5.22.1-2 On Sun, Dec 20, 2015 at 07:47:43PM +0100, Marco d'Itri wrote: > reassign -1 libautodie-perl > severity -1 critical > thanks > > On Sep 05, Julien Muchembled <j...@jmuchemb.eu> wrote: > > > $ /usr/lib/convert-usrmerge > > Undefined subroutine called at /usr/lib/convert-usrmerge line 248. > > > > After uninstalling 'libautodie-perl' package: > > $ /usr/lib/convert-usrmerge > > The system has been successfully converted. > This is a bug in libautodie-perl, I am attaching a trivial test case. Thanks. I suspect the critical severity is a pun (as in "breaks the whole system() [call]"), but in case it isn't, please provide some justification. Downgrading for now. Niels already forwarded this upstream as https://github.com/pjf/autodie/issues/69 Please note that the bug is also present in the autodie version bundled with Perl 5.22, currently in unstable and soon in testing, so I'm cloning this bug and reassigning the clone. -- Niko Tyni nt...@debian.org
Bug#805391: src:rrdtool: FTBFS on mips: `FAIL: tune2`
Control: tag -1 patch
On Sat, Dec 19, 2015 at 02:45:03PM +0100, Aurelien Jarno wrote:
> On 2015-12-19 15:03, Niko Tyni wrote:
> > It's a latent bug in rrdtool that triggered with libc6 2.19-20 on mips.
> > The problem is that rrd_write() ends up calling memcpy(3) on overlapping
> > memory areas, which is explicitly prohibited in its documentation. With
> > libc6 2.19-20 on mips, this started zeroing out part of the areas under
> > some conditions.
> The change is likely due to the switch to the MIPS32R2 ISA on mips.
> A different code is used, so with a different undefined behaviour.
Right, thanks.
> Can't you replace memcpy calls with overlapping areas with a memmove
> instead? Even if the testsuite looks fine you will definitely have some
> corruptions with memcpy and overlapping area on other architectures too.
Sure, that works and the memmove() overhead is presumably negligible
with mmap'ed disk IO. Patch attached, I've tested that the package
builds on mips and amd64 with this and forwarded it upstream at
https://github.com/oetiker/rrdtool-1.x/pull/693
Jean-Michel: this is somewhat urgent given it blocks the Perl 5.22
transition, so please let us know if you'd like an NMU.
--
Niko Tyni nt...@debian.org
>From c0ac2ba5afeedd535367d78bf39cbe58e968a345 Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Sun, 20 Dec 2015 09:49:14 +0200
Subject: [PATCH] Use memmove instead of memcpy in rrd_write() to fix undefined
behaviour
At least rrdtune ends up calling rrd_write() with the same memory
area for the source and the destination, causing undefined behaviour
that has been observed to actually break on the mips architecture.
Bug-Debian: https://bugs.debian.org/805391
Bug: https://github.com/oetiker/rrdtool-1.x/issues/688
---
src/rrd_open.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/rrd_open.c b/src/rrd_open.c
index b4e151e..9e05164 100644
--- a/src/rrd_open.c
+++ b/src/rrd_open.c
@@ -808,7 +808,8 @@ ssize_t rrd_write(
rrd_set_error("attempting to write beyond end of file (%ld + %ld > %ld)",rrd_file->pos, count, old_size);
return -1;
}
-memcpy(rrd_simple_file->file_start + rrd_file->pos, buf, count);
+/* can't use memcpy since the areas overlap when tuning */
+memmove(rrd_simple_file->file_start + rrd_file->pos, buf, count);
rrd_file->pos += count;
return count; /* mimmic write() semantics */
#else
--
2.6.4
Bug#808480: libdevel-bt-perl: FTBFS on mips*: test failures
Package: libdevel-bt-perl Version: 0.06-3 Severity: serious Tags: sid patch Control: block 796345 with -1 This package failed to build on mips and mipsel with Perl 5.22 in unstable. # Failed test 'perl backtrace for SIGABRT' # at t/basic.t line 26. # '#0 0x77999480 in waitpid () from /lib/mips-linux-gnu/libpthread.so.0 # #1 0x7779d178 in backtrace () at bt.xs:187 # #2 signal_handler (sig=) at bt.xs:194 # #3 # #4 0x77837240 in kill () from /lib/mips-linux-gnu/libc.so.6 # #5 0x00547b28 in Perl_apply () # ' # doesn't match '(?^:\bperl_run\b)' While this looks very similar to #721421, it may not be quite the same issue. I tried on minkus.d.o, and building with perl-debug installed fixes it. Given the test suite is looking for /perl_run/ in the backtrace, it seems fair to require that. I think a runtime dependency on perl-debug would make sense too: this is presumably meant to get useful backtraces, and debugging symbols help a lot with that. (Not sure what's going to happen with perl-debug now that we've got automatic debug symbol packages, but we can look at that after the Perl 5.22 transition that this is blocking.) -- Niko Tyni nt...@debian.org
Bug#808489: acm: FTBFS: Type of arg 1 to dbmclose must be hash (not constant item) at ./create-tables-5 (perl 5.22?)
On Sun, Dec 20, 2015 at 01:51:08PM +, Chris West (Faux) wrote: > Source: acm > Version: 5.0-29 > Severity: serious > Justification: fails to build from source > Tags: sid > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org > perl ./create-tables-5 > Type of arg 1 to dbmclose must be hash (not constant item) at > ./create-tables-5 line 41, near "entities)" > Type of arg 1 to dbmclose must be hash (not constant item) at > ./create-tables-5 line 56, near "sites)" FWIW, this is indeed a Perl upstream change in 5.22 removing really old syntax that has warned since Perl 5.0. http://perl5.git.perl.org/perl.git/commit/b5adc3e5c5c4fa9a0d3b230a000a7644b71a169f -- Niko Tyni nt...@debian.org
Bug#808395: libprelude: FTBFS everywhere
On Sat, Dec 19, 2015 at 03:39:00PM +0100, gregor herrmann wrote:
> > /usr/bin/swig -c++ -I../bindings -I../bindings/c++/include -I../src/include
> > -I../src/libprelude-error -perl5 -o perl/PreludeEasy.cxx libpreludecpp.i
> > perl/libpreludecpp-perl.i:1: Error: Unknown SWIG preprocessor directive:
> > Exception (if this is a block of target language code, delimit it with %{
> > and %})
> The attached patch fixes these errors;
The patch looks good to me FWIW (but I don't really claim to know anything
about libprelude or swig :)
This seems to be fallout from
https://github.com/swig/swig/issues/217
and the #-comment lines were always ignored as unknown preprocessor
directives.
> now some warnings are left:
> ../bindings/c++/include/prelude-error.hxx:37: Warning 401: Nothing known
> about base class 'std::exception'. Ignored.
> ../bindings/c++/include/prelude-error.hxx:48: Warning 503: Can't wrap
> 'operator const char*' unless renamed to a valid identifier.
> ../bindings/c++/include/idmef.hxx:15: Warning 503: Can't wrap 'operator >>'
> unless renamed to a valid identifier.
> In file included from PreludeEasy.cxx:1637:0:
> ../../config.h:1564:0: warning: "VERSION" redefined
> #define VERSION "1.0.0"
> ^
> :0:0: note: this is the location of the previous definition
All these were in the old build logs too, so at least they aren't
regressions.
--
Niko Tyni nt...@debian.org
Bug#805391: src:rrdtool: FTBFS on mips: `FAIL: tune2`
On Tue, Nov 24, 2015 at 04:24:54PM +, Jean-Michel Vourgère wrote:
> Control: tags -1 + help
>
> Antonio Terceiro wrote:
> > "make check-TESTS" fails
>
> I tested previous version on mips, and it now FTBFS too. It used to work
> ok. [1] (thanks Tobias, upstream, for suggesting that.)
>
> So I suppose it is related to another package.
>
> I tried compiling with good old gcc 4.9 and I get the same error in 1.5.4.
It's a latent bug in rrdtool that triggered with libc6 2.19-20 on mips.
The test suite failure in tests/tune2 boils down to
rrdtool tune --beta 0.4 tests/tune2-testorg.rrd
zeroing out a big part of the file in addition to changing a single byte
like it's supposed to. It's easy to see by calling
rrdtool dump tests/tune2-testorg.rrd >/dev/null
which starts to fail with stderr
ERROR: unknown consolidation function ''
on a corrupted file.
This started to happen with libc6 2.19-20, as tested by compiling rrdtool
1.5.5 on jessie and running with LD_LIBRARY_PATH pointing to different
libc.so.6 versions.
The problem is that rrd_write() ends up calling memcpy(3) on overlapping
memory areas, which is explicitly prohibited in its documentation. With
libc6 2.19-20 on mips, this started zeroing out part of the areas under
some conditions. The attached testcase triggers it at least on minkus.d.o,
tested with something like
#!/bin/bash
dd if=/dev/urandom of=testfile.orig bs=1024 count=1
gcc t.c
cp testfile.orig testfile
./a.out testfile
diff -u <(od -x testfile.orig) <(od -x testfile)
which normally doesn't show any differences. I'm cc'ing the libc6
maintainers, not sure how intentional this change of behaviour is.
Backtrace for the rrd_write() call that triggers it:
#0 rrd_write (rrd_file=0x41d038, buf=0x77fef168, count=560) at rrd_open.c:798
#1 0x77f65888 in rrd_tune (argc=4, argv=0x7fff6648) at rrd_tune.c:395
#2 0x00402f44 in HandleInputLine (argc=5, argv=0x7fff6644, out=0x77f56900
<_IO_2_1_stderr_>) at rrd_tool.c:800
#3 0x00400f10 in main (argc=5, argv=0x7fff6644) at rrd_tool.c:545
(gdb) print ((rrd_simple_file_t *) rrd_file->pvt)->file_start + rrd_file->pos
$6 = 0x77fef168 "HWPREDICT"
(gdb) print (char *)buf
$8 = 0x77fef168 "HWPREDICT"
A workaround is to configure with --disable-mmap, except that seems
to break tests/tune1 on all architectures (at least amd64 and mips).
I haven't looked into that.
--
Niko Tyni nt...@debian.org
#include
#include
#include
#include
#include
#include
#include
#define MYSIZE 1024
int main(int argc, char **argv) {
int fd;
char *d;
if (argc != 2) {
fprintf(stderr, "file argument needed\n");
exit(1);
}
fd = open(argv[1], O_RDWR);
if (fd < 0)
perror("open failed");
d = mmap(NULL, MYSIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (!d)
perror("mmap");
memcpy(d+260, d+260, 355);
if (munmap(d, MYSIZE) < 0)
perror("munmap");
return 0;
}
Bug#808329: linux-tools: needs a rebuild for Perl 5.22
Source: linux-tools Version: 4.3.1-1 Severity: serious Control: block 796345 with -1 The linux-perf-4.3 package is currently uninstallable in sid because it depends on libperl5.20 while we're switching to 5.22. The binNMUs scheduled by the release team failed with debian/bin/gencontrol.py md5sum debian/bin/gencontrol.py debian/changelog debian/templates/control.main.in debian/templates/control.source.in > debian/control.md5sum This target is made to fail intentionally, to make sure that it is NEVER run during the automated build. Please ignore the following error, the debian/control file has been generated SUCCESSFULLY. exit 1 debian/rules:69: recipe for target 'debian/control-real' failed so it seems to need sourceful upload to get rebuilt. -- Niko Tyni nt...@debian.org
Bug#808325: postgresql-9.4: FTBFS: libxml2 changes
Package: postgresql-9.4 Version: 9.4.5-1 Severity: serious X-Debbugs-Cc: libx...@packages.debian.org This package fails to build on current sid on all architectures due to test suite failures. This regressed with libxml2 2.9.3+dfsg1-1 and works fine with 2.9.2+zdfsg1-4 from testing. Cc'ing the libxml2 maintainers. The timing is rather unfortunate, as this made binNMUs for the current Perl 5.22 transition fail, leaving postgresql-plperl-9.4 uninstallable. https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4=amd64=9.4.5-1%2Bb2=1450443135 >From the log: build/src/test/regress/regression.diffs *** /«PKGBUILDDIR»/build/../src/test/regress/expected/xml.out Mon Oct 5 19:12:06 2015 --- /«PKGBUILDDIR»/build/src/test/regress/results/xml.out Fri Dec 18 12:52:04 2015 *** *** 9,16 LINE 1: INSERT INTO xmltest VALUES (3, '
Bug#730908: libio-event-perl: FTBFS: Failed tests
Control: tag -1 patch
On Sat, Nov 30, 2013 at 09:17:11PM +0100, gregor herrmann wrote:
> On Sat, 30 Nov 2013 17:33:15 +0100, David Suárez wrote:
>
> > > t/forked1.t . ok
> > > # Looks like you planned 115 tests but ran 111.
> > > print 26175: Connection reset by peer
> > > Compilation failed in require at t/forked2.t line 5.
> > > t/forked2.t .
> > > Dubious, test returned 255 (wstat 65280, 0xff00)
> > > Failed 4/115 subtests
>
> Now that's an intereting bug.
> The tests still pass for me but take quite some long. So maybe we're
> running into a timeout here, or some other fork problem on the amazon
> build machine ...
What happens here is that
- the test script forks, the parent sets up a TCP server and starts an
event loop for clients
- child connects there, sends test data and synchronizes on event
indications from the parent
- for every test data group, client disconnects when it has sent
all the data and then makes a new connection for the next group
- when the parent gets a new connection, it decrements its counter
of tests left (in ie_connection())
- when the parent gets an EOF from a client connection, it exits
if the test counter is zero (in ie_eof())
Now, it can happen that the client disconnect and the next connect both
happen before the parent gets CPU time. In this case, the parent may get
the 'new connection' event before the 'eof' event. This wouldn't matter
otherwise, but if it's the last test group starting, ie_connection()
decrements the counter to zero first, and ie_eof() thinks it's all done
even though a new connection has just been accepted.
The parent then does an exit(0) in ie_eof(), the child gets a connection
reset, and an END block in the test libraries notices that there were
too few tests and dies.
The attached patch should fix it by making the client synchronize on the
eof event from the parent before making a new connection. Will send
it properly upstream once rt.cpan.org is up again.
--
Niko Tyni nt...@debian.org
>From e11dc91080151bb59d73e72c3c0a3409c1b999ef Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Sat, 12 Dec 2015 11:33:34 +0200
Subject: [PATCH] Fix undeterministic test failures in t/forked2.t
The parent process may get both the eof event from an old connection
and the connect event from a new connection at the same time, and in an
unpredictable order. If the connect event comes first, the handler may
decrement the test counter to zero and make the eof handler think the
testing is already over.
Having the child synchronize on the eof event before making a new
connection fixes this race.
Bug-Debian: https://bugs.debian.org/730908
Bug: https://rt.cpan.org/Ticket/Display.html?id=92200
---
t/forked.tt | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/forked.tt b/t/forked.tt
index e56c7fa..0d9ce18 100755
--- a/t/forked.tt
+++ b/t/forked.tt
@@ -265,6 +265,7 @@ if ($child = fork()) {
}
print "# CHILD closing\n";
close($s);
+ syncto("e");
}
} else {
die "fork: $!";
--
2.6.2
Bug#807647: perl/experimental: trigger cycle on upgrades
Package: perl Version: 5.22.1~rc4-1 Severity: serious Tags: patch When spamassassin is installed, upgrading perl et al. from sid/5.20 to experimental/5.22.1~rc4-1 breaks due to a trigger cycle, see below. I believe perl.postinst should trigger 'perl-major-upgrade' with 'noawait'. Quoting deb-triggers(5): The “-noawait” variants should always be favored when possible since triggering packages are not put in triggers-awaited state and can thus be immediately configured without requiring the processing of the trigger. If the triggering packages are dependencies of other upgraded packages, it will avoid an early trigger processing run and make it possible to run the trigger only once as one of the last steps of the upgrade. It seems sensible that perl configuration shouldn't wait for spamassassin to recompile its ruleset. I've tested locally that --- a/debian/perl.postinst +++ b/debian/perl.postinst @@ -21,7 +21,7 @@ then [ -n "$2" ] && \ dpkg --compare-versions "$2" lt 5.21.9 then -dpkg-trigger perl-major-upgrade +dpkg-trigger --no-await perl-major-upgrade fi fi makes the problem go away. Setting up perl (5.22.1~rc4-1) ... dpkg: cycle found while processing triggers: chain of packages whose triggers are or may be responsible: spamassassin -> spamassassin packages' pending triggers which are or may be unresolvable: sa-compile: perl-major-upgrade libc-bin: ldconfig spamassassin: perl-major-upgrade dpkg: error processing package sa-compile (--configure): triggers looping, abandoned dpkg: cycle found while processing triggers: chain of packages whose triggers are or may be responsible: spamassassin -> spamassassin -> spamassassin packages' pending triggers which are or may be unresolvable: libc-bin: ldconfig spamassassin: perl-major-upgrade dpkg: error processing package libc-bin (--configure): triggers looping, abandoned dpkg: cycle found while processing triggers: chain of packages whose triggers are or may be responsible: spamassassin -> spamassassin -> spamassassin -> spamassassin -> spamassassin -> spamassassin packages' pending triggers which are or may be unresolvable: spamassassin: perl-major-upgrade dpkg: error processing package spamassassin (--configure): triggers looping, abandoned Setting up libnet-ssleay-perl (1.72-1+b2) ... Setting up libhtml-parser-perl (3.71-2+b1) ... Setting up libnet-dns-perl (0.81-2+b1) ... Setting up libsocket6-perl (0.25-1+b2) ... Setting up libnetaddr-ip-perl (4.078+dfsg-1+b1) ... Errors were encountered while processing: sa-compile libc-bin spamassassin -- Niko Tyni nt...@debian.org
Bug#807251: libdebug-client-perl: FTBFS: tests hang with current Term::ReadLine::Gnu
Package: libdebug-client-perl Version: 0.29-2 Severity: serious Tags: sid This package fails to build on current sid. The tests hang in t/07-initialize.t after ok 1 - initialize with prams This broke with libterm-readline-gnu-perl 1.28-1. Debug::Client creates a network server that a 'perl -d' process configured with PERLDB_OPTS='RemotePort=host:port' can connect to. With the new Term::ReadLine::Gnu, the perl debugger no longer outputs its prompt and other messages to the socket, so Debug::Client can't interact with it and hangs forever waiting. The package build-depends on libterm-readline-gnu-perl, so the build fails. I suppose a workaround would be to build-conflict on it instead. Without libterm-readline-gnu-perl installed, with netcat listening for connections in place of Debug::Client, we see everything working correctly: (window 1) % nc -l -p 65400 (window 2) % PERLDB_OPTS="RemotePort=127.0.0.1:65400" perl -d -e 'print "Hello, world!\n"' (window 1) Loading DB routines from perl5db.pl version 1.44 Editor support available. Enter h or 'h h' for help, or 'man perldebug' for more help. main::(-e:1): print "Hello, world!\n" DB<1> c Debugged program terminated. Use q to quit or R to restart, use o inhibit_exit to avoid stopping after program termination, h q, h R or h o to get additional info. DB<1> q (window 2) Hello, world! With libterm-readline-gnu-perl_1.28-1, we no longer get the DB prompts or the 'Debugged program terminated' messages, but typing blindly works. (window 1) nc -l -p 65400 (window 2) % PERLDB_OPTS="RemotePort=127.0.0.1:65400" perl -d -e 'print "Hello, world!\n"' (window 1) Loading DB routines from perl5db.pl version 1.44 Editor support available. Enter h or 'h h' for help, or 'man perldebug' for more help. main::(-e:1): print "Hello, world!\n" c q (window 2) Hello, world! The upstream version that broke this is Term-ReadLine-Gnu-1.26. -- Niko Tyni nt...@debian.org
Bug#807251: libdebug-client-perl: FTBFS: tests hang with current Term::ReadLine::Gnu
clone 807251 -1 retitle -1 libterm-readline-gnu-perl: breaks remote perl debugging (perl -d with RemotePort) reassign -1 libterm-readline-gnu-perl 1.28-1 severity -1 important affects -1 perl libdebug-client-perl block 807251 with -1 thanks On Sun, Dec 06, 2015 at 08:58:16PM +0200, Niko Tyni wrote: > Package: libdebug-client-perl > Version: 0.29-2 > Severity: serious > Tags: sid > > This package fails to build on current sid. The tests > hang in t/07-initialize.t after > ok 1 - initialize with prams > The upstream version that broke this is Term-ReadLine-Gnu-1.26. Cloning a separate bug for libterm-readline-gnu-perl; while the issue would ideally be fixed there, it might be possible to work around it in libdebug-client-perl for the time being. -- Niko Tyni nt...@debian.org
Bug#807038: Perl 5.22.1-RC3 is now available!
On Fri, Dec 04, 2015 at 02:08:01PM -0600, Craig A. Berry wrote: > On Fri, Dec 4, 2015 at 12:24 PM, Niko Tyni <nt...@debian.org> wrote: > > doublekind='4'; looks like those tests get run only on linux > > with that doublekind. > > Right. I hadn't noticed the linux-only part before. These tests came > in with a fix for a problem reported on Debian PPC64: > > <http://perl5.git.perl.org/perl.git/commit/5488d3733162ee806bb5f5c55694e8beaaf7b1cc?f=t/op/sprintf2.t> > > <https://rt.perl.org/Public/Bug/Display.html?id=125633> > > To me the configuration in that ticket looks awfully similar to the > configuration that now sees test failures, but I could be missing > something. The difference was that we don't use -Duselongdouble. Jarkko says the tests were only intended for long double configurations and has added more skip conditions with http://perl5.git.perl.org/perl.git/commit/df3d8cc3eeca597a21c2d7ad7686adbef4df784b I've tested that this works for us. -- Niko Tyni nt...@debian.org
Bug#807086: perl/experimental: FTBFS: cpan/podlators/t/devise-date failure
Package: perl
Version: 5.22.1~rc3-1
Severity: serious
Tags: upstream patch
X-Debbugs-Cc: Russ Allbery <r...@debian.org>
This package failed to build on ppc64el and mips64el:
cpan/podlators/t/devise-date .. # Failed
test 'devise_date matches strftime'
# at t/devise-date.t line 20.
# got: '2015-12-04'
# expected: '2015-12-05'
# Looks like you failed 1 test of 6.
FAILED at test 1
This is because we now set SOURCE_DATE_EPOCH to the latest
debian/changelog time stamp, and those builds happened on the next day.
Turns out the backported SOURCE_DATE_EPOCH support from podlators-4.00
doesn't itself survive being build with SOURCE_DATE_EPOCH (or
POD_MAN_DATE, for that matter) set. Patch attached.
--
Niko Tyni nt...@debian.org
>From aee8ad90d019667a85e5653f8ec35fc74aa81491 Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Sat, 5 Dec 2015 10:08:13 +0200
Subject: [PATCH] Guard for building with SOURCE_DATE_EPOCH or POD_MAN_DATE set
The strftime test expects the current time rather than anything
in the environment.
---
t/man/devise-date.t | 3 +++
1 file changed, 3 insertions(+)
diff --git a/t/man/devise-date.t b/t/man/devise-date.t
index a6ceba1..8a1c06e 100755
--- a/t/man/devise-date.t
+++ b/t/man/devise-date.t
@@ -14,6 +14,9 @@ use POSIX qw(strftime);
use Test::More tests => 6;
+local $ENV{SOURCE_DATE_EPOCH};
+local $ENV{POD_MAN_DATE};
+
# Check that the results of device_date matches strftime. There is no input
# file name, so this will use the current time.
my $parser = Pod::Man->new;
--
2.6.2
Bug#807038: perl/experimental: FTBFS on powerpc: t/op/sprintf2.t failure
Package: perl
Version: 5.22.1~rc3-1
Severity: serious
Tags: upstream
This package failed to build on powerpc and ppc64.
https://buildd.debian.org/status/fetch.php?pkg=perl=powerpc=5.22.1%7Erc3-1=1449230321
https://buildd.debian.org/status/fetch.php?pkg=perl=ppc64=5.22.1%7Erc3-1=1449231009
t/op/sprintf2 . # Failed test
1451 - at op/sprintf2.t line 671
# got '0x1p+1020
# '
# expected /(?^:^0x1.0{522}1p\+1020$)/
# Failed test 1452 - at op/sprintf2.t line 673
# got '0x1p+1021
# '
# expected /(?^:^0x1.0{523}8p\+1021$)/
# Failed test 1453 - at op/sprintf2.t line 675
# got '0x1p+1022
# '
# expected /(?^:^0x1.0{523}4p\+1022$)/
# Failed test 1454 - at op/sprintf2.t line 677
# got '0x1p+1023
# '
# expected /(?^:^0x1.0{523}2p\+1023$)/
# Failed test 1455 - at op/sprintf2.t line 679
# got '0x1p+1023
# '
# expected /(?^:^0x1.0{523}1p\+1023$)/
# Failed test 1456 - at op/sprintf2.t line 681
# got '0x1p+1023
# '
# expected /(?^:^0x1.0{524}8p\+1023$)/
FAILED at test 1451
I'm reporting this upstream.
--
Niko Tyni nt...@debian.org
Bug#807038: Perl 5.22.1-RC3 is now available!
On Wed, Dec 02, 2015 at 10:17:44PM +, Steve Hay via perl5-porters wrote:
> ***Please, please, please*** test your code against perl-5.22.1-RC3.
> This is your last chance to point out any critical regressions before
> v5.22.1 ships "for real," and we'd rather fix things for v5.22.1 than
> for v5.22.2!
Hi, we're seeing t/op/sprintf2.t failures on Debian powerpc and ppc64.
https://buildd.debian.org/status/fetch.php?pkg=perl=powerpc=5.22.1~rc3-1=1449230321
https://buildd.debian.org/status/fetch.php?pkg=perl=ppc64=5.22.1~rc3-1=1449231009
I've reproduced these with the pristine 5.22.1-RC3 (no Debian
modifications) and just './Configure -des'. (Please ignore the 'Commit
id' below, it comes from our separate git repo.)
t/op/sprintf2 . # Failed test
1463 - at op/sprintf2.t line 671
# got '0x1p+1020
# '
# expected /(?^:^0x1.0{522}1p\+1020$)/
# Failed test 1464 - at op/sprintf2.t line 673
# got '0x1p+1021
# '
# expected /(?^:^0x1.0{523}8p\+1021$)/
# Failed test 1465 - at op/sprintf2.t line 675
# got '0x1p+1022
# '
# expected /(?^:^0x1.0{523}4p\+1022$)/
# Failed test 1466 - at op/sprintf2.t line 677
# got '0x1p+1023
# '
# expected /(?^:^0x1.0{523}2p\+1023$)/
# Failed test 1467 - at op/sprintf2.t line 679
# got '0x1p+1023
# '
# expected /(?^:^0x1.0{523}1p\+1023$)/
# Failed test 1468 - at op/sprintf2.t line 681
# got '0x1p+1023
# '
# expected /(?^:^0x1.0{524}8p\+1023$)/
FAILED at test 1463
% ./perl -Ilib -V
Summary of my perl5 (revision 5 version 22 subversion 1) configuration:
Commit id: 8683e3a63304bb451ebf91256afd91c581a74546
Platform:
osname=linux, osvers=3.16.0-4-powerpc64, archname=ppc-linux
uname='linux partch 3.16.0-4-powerpc64 #1 smp debian 3.16.7-ckt11-1+deb8u6
(2015-11-09) ppc gnulinux '
config_args='-des'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fwrapv -fno-strict-aliasing -pipe
-fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O1',
cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong
-I/usr/local/include'
ccversion='', gccversion='5.2.1 20151129', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321, doublekind=4
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16,
longdblkind=6
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -fstack-protector-strong -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib/gcc/powerpc-linux-gnu/5/include-fixed
/usr/include/powerpc-linux-gnu /usr/lib /lib/powerpc-linux-gnu /lib/../lib
/usr/lib/powerpc-linux-gnu /usr/lib/../lib /lib
libs=-lpthread -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
libc=libc-2.21.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.21'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O1 -L/usr/local/lib
-fstack-protector-strong'
Characteristics of this binary (from libperl):
Compile-time options: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV
PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_MALLOC_WRAP
PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV
USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE
USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LOCALE_TIME
USE_PERLIO USE_PERL_ATOF
Locally applied patches:
RC3
Built under linux
Compiled at Dec 4 2015 12:20:55
@INC:
lib
/usr/local/lib/perl5/site_perl/5.22.1/ppc-linux
/usr/local/lib/perl5/site_perl/5.22.1
/usr/local/lib/perl5/5.22.1/ppc-linux
/usr/local/lib/perl5/5.22.1
--
Niko Tyni nt...@debian.org
Bug#807038: Perl 5.22.1-RC3 is now available!
On Fri, Dec 04, 2015 at 10:28:50AM -0600, Craig A. Berry wrote:
> On Fri, Dec 4, 2015 at 6:42 AM, Niko Tyni <nt...@debian.org> wrote:
> > t/op/sprintf2 . # Failed
> > test 1463 - at op/sprintf2.t line 671
> > # got '0x1p+1020
> > # '
> > # expected /(?^:^0x1.0{522}1p\+1020$)/
> FWIW, on Darwin PPC these tests are skipped:
>
> ok 1463 # skip darwin doublekind=4
> ok 1464 # skip darwin doublekind=4
> ok 1465 # skip darwin doublekind=4
> ok 1466 # skip darwin doublekind=4
> ok 1467 # skip darwin doublekind=4
> ok 1468 # skip darwin doublekind=4
>
> What does Debian PPC show for:
>
> % ./perl -Ilib -V:doublekind
> doublekind='4';
doublekind='4'; looks like those tests get run only on linux
with that doublekind.
I'm attaching 'perl -V' output for all the failing platforms: powerpc
s390x and ppc64. All are big-endian, and the latter two are 64-bit. All
have doublekind=4.
--
Niko Tyni nt...@debian.org
Summary of my perl5 (revision 5 version 22 subversion 1) configuration:
Platform:
osname=linux, osvers=3.16.0-4-powerpc64, archname=ppc-linux
uname='linux partch 3.16.0-4-powerpc64 #1 smp debian 3.16.7-ckt11-1+deb8u6
(2015-11-09) ppc gnulinux '
config_args='-des'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fwrapv -fno-strict-aliasing -pipe
-fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O1',
cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong
-I/usr/local/include'
ccversion='', gccversion='5.2.1 20151129', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321, doublekind=4
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16,
longdblkind=6
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -fstack-protector-strong -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib/gcc/powerpc-linux-gnu/5/include-fixed
/usr/include/powerpc-linux-gnu /usr/lib /lib/powerpc-linux-gnu /lib/../lib
/usr/lib/powerpc-linux-gnu /usr/lib/../lib /lib
libs=-lpthread -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
libc=libc-2.21.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.21'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O1 -L/usr/local/lib
-fstack-protector-strong'
Characteristics of this binary (from libperl):
Compile-time options: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV
PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_MALLOC_WRAP
PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV
USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE
USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LOCALE_TIME
USE_PERLIO USE_PERL_ATOF
Locally applied patches:
RC3
Built under linux
Compiled at Dec 4 2015 18:02:31
@INC:
lib
/usr/local/lib/perl5/site_perl/5.22.1/ppc-linux
/usr/local/lib/perl5/site_perl/5.22.1
/usr/local/lib/perl5/5.22.1/ppc-linux
/usr/local/lib/perl5/5.22.1
.
Summary of my perl5 (revision 5 version 22 subversion 1) configuration:
Platform:
osname=linux, osvers=3.16.0-4-powerpc64, archname=ppc64-linux
uname='linux pizzetti 3.16.0-4-powerpc64 #1 smp debian
3.16.7-ckt11-1+deb8u6 (2015-11-09) ppc64 gnulinux '
config_args='-des'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fwrapv -fno-strict-aliasing -pipe
-fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O1',
cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong
-I/usr/local/include'
ccversion='', gccversion='5.2.1 20151129', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321,
doublekind=4
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16,
longdblkind=6
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -fstack-protector-strong -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib/gcc/powerpc64-linux-gnu/5/include-fixed
/usr/include/powerpc64-linux-gnu /usr/lib /lib/powerpc64-linux-gnu /lib/../lib
/usr/lib/powerpc6
Bug#787493: libapache2-mod-perl2 Perl 5.22 fixes entering experimental
Control: tag -1 patch pending
This bug is surprisingly quiet, so an update seems to be in order.
For quite some time, this issue has been the last real blocker for Perl
5.22 transition.
As seen in the upstream ticket [rt.cpan.org #101962], recent progress
upstream got us to a point where the test suite is passing, and we're
now waiting for the proposed patch to be cleaned up and committed.
I'm about to upload the proposed patch to experimental as 2.0.9-2 so we
can test it in our Perl 5.22 rebuilds. Any other testing would be welcome
too. The patch does not have separate code paths for Perl 5.20 and 5.22,
so testing the actual 2.0.9-2 binary packages from experimental on
sid (still Perl 5.20 for now) would be just as useful.
I'm attaching the actual patch I'm using for completeness. It's unmodified
from the RT one except for line endings and -p0 -> -p1 conversion required
by dpkg v3.0 (quilt) source format.
--
Niko Tyni nt...@debian.org
Subject: Perl 5.22 compatibility
Author: Steve Hay <steve.m@googlemail.com>
Author: Niko Tyni <nt...@debian.org>
Origin: https://rt.cpan.org/Ticket/Attachment/1564180/834925/Perl-5.22-compatibility-take-4.patch
Bug: https://rt.cpan.org/Public/Bug/Display.html?id=101962
Bug-Debian: https://bugs.debian.org/787493
Please note that this patch is still work in progress.
--- libapache2-mod-perl2.orig/src/modules/perl/mod_perl.c
+++ libapache2-mod-perl2/src/modules/perl/mod_perl.c
@@ -262,6 +262,8 @@
exit(1);
}
+modperl_env_init(aTHX);
+
/* suspend END blocks to be run at server shutdown */
endav = PL_endav;
PL_endav = (AV *)NULL;
@@ -576,9 +578,6 @@
/* modifies PL_ppaddr */
modperl_perl_pp_set_all();
-/* modifies PL_vtbl_env{elem} */
-modperl_env_init();
-
return APR_SUCCESS;
}
@@ -597,8 +596,6 @@
MP_TRACE_i(MP_FUNC, "mod_perl sys term");
-modperl_env_unload();
-
modperl_perl_pp_unset_all();
PERL_SYS_TERM();
--- libapache2-mod-perl2.orig/src/modules/perl/modperl_env.c
+++ libapache2-mod-perl2/src/modules/perl/modperl_env.c
@@ -121,6 +121,7 @@
const apr_array_header_t *array;
apr_table_entry_t *elts;
+modperl_env_init(aTHX);
modperl_env_untie(mg_flags);
array = apr_table_elts(table);
@@ -434,11 +435,8 @@
/* to store the original virtual tables
* these are global, not per-interpreter
*/
-static MGVTBL MP_PERL_vtbl_env;
-static MGVTBL MP_PERL_vtbl_envelem;
-
#define MP_PL_vtbl_call(name, meth) \
-MP_PERL_vtbl_##name.svt_##meth(aTHX_ sv, mg)
+PL_vtbl_##name.svt_##meth(aTHX_ sv, mg)
#define MP_dENV_KEY \
STRLEN klen; \
@@ -612,16 +610,22 @@
}
#endif
+static int modperl_env_magic_copy(pTHX_ SV *sv, MAGIC *mg, SV *nsv, const char *name, I32 namlen);
+static int modperl_env_magic_local_all(pTHX_ SV *nsv, MAGIC *mg);
+
/* override %ENV virtual tables with our own */
static MGVTBL MP_vtbl_env = {
0,
modperl_env_magic_set_all,
0,
modperl_env_magic_clear_all,
-0
+0,
+modperl_env_magic_copy,
+0,
+modperl_env_magic_local_all
};
-static MGVTBL MP_vtbl_envelem = {
+MGVTBL MP_vtbl_envelem = {
0,
modperl_env_magic_set,
0,
@@ -629,22 +633,73 @@
0
};
-void modperl_env_init(void)
+static int modperl_env_magic_copy(pTHX_ SV *sv, MAGIC *mg, SV *nsv, const char *name, I32 namlen)
+{
+MP_TRACE_e(MP_FUNC, "setting up %%ENV element magic");
+sv_magicext(nsv, mg->mg_obj,
+toLOWER(mg->mg_type),
+_vtbl_envelem,
+name, namlen);
+
+return 1;
+}
+
+static int modperl_env_magic_local_all(pTHX_ SV *nsv, MAGIC *mg)
{
-/* save originals */
-StructCopy(_vtbl_env, _PERL_vtbl_env, MGVTBL);
-StructCopy(_vtbl_envelem, _PERL_vtbl_envelem, MGVTBL);
+MAGIC *nmg;
+MP_TRACE_e(MP_FUNC, "localizing %%ENV");
+nmg = sv_magicext(nsv, mg->mg_obj,
+mg->mg_type,
+_vtbl_env,
+NULL, 0);
+nmg->mg_ptr = mg->mg_ptr;
+nmg->mg_flags |= MGf_COPY;
+nmg->mg_flags |= MGf_LOCAL;
-/* replace with our versions */
-StructCopy(_vtbl_env, _vtbl_env, MGVTBL);
-StructCopy(_vtbl_envelem, _vtbl_envelem, MGVTBL);
+return 1;
}
-void modperl_env_unload(void)
+void modperl_env_init(pTHX)
{
-/* restore originals */
-StructCopy(_PERL_vtbl_env, _vtbl_env, MGVTBL);
-StructCopy(_PERL_vtbl_envelem, _vtbl_envelem, MGVTBL);
+MAGIC *mg;
+/* Remove existing 'E' magic from %ENV */
+/* TODO: Should check there is not multiple 'E' magic! */
+if (!my_perl)
+return;
+if (!PL_envgv)
+return;
+if (!SvRMAGICAL(ENVHV))
+return;
+mg = mg_find((const SV *)ENVHV, PERL_MAGIC_env);
+if (!mg)
+return;
+if (mg->mg_virtual == _vtbl_env)
+return;
+MP_TRACE_d(MP_FUNC, "ptr: %x obj: %x f
Bug#806544: libical-parser-sax-perl: FTBFS: t/01parse.t failure
Package: libical-parser-sax-perl Version: 1.09-3 Severity: serious Tags: sid Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=109258 This package fails to build on current sid/amd64. The first matching ci.debian.net autopkgtest failure happened on 2015-11-24, and reproducible.debian.net built the package successfully on 2015-11-17. Apparently stretch was still unaffected as of 2015-11-26. https://reproducible.debian.net/history/libical-parser-sax-perl.html http://ci.debian.net/packages/libi/libical-parser-sax-perl/unstable/amd64/ [rt.cpan.org #109258] blames DateTime-Event-Recurrence-0.18 and DateTime-Set-0.3600. The above timeline indeed matches libdatetime-event-recurrence-perl_0.18-1. # Failed test 'rrule' # at t/01parse.t line 19. # Found 6 differences with expected: # Rogue element 'dtend' in element '/ical[1]/events[1]/year[1]/month[1]/week[1]/day[5]/event[1]'. # Rogue element 'event' in element '/ical[1]/events[1]/year[1]/month[1]/week[1]/day[5]'. # Rogue element 'dtstamp' in element '/ical[1]/events[1]/year[1]/month[1]/week[1]/day[5]/event[1]'. # Rogue element 'hours' in element '/ical[1]/events[1]/year[1]/month[1]/week[1]/day[5]/event[1]'. # Rogue element 'summary' in element '/ical[1]/events[1]/year[1]/month[1]/week[1]/day[5]/event[1]'. # Rogue element 'dtstart' in element '/ical[1]/events[1]/year[1]/month[1]/week[1]/day[5]/event[1]'. # in processed XML: # wierd2004-11-13T21:47:342004-12-02T00:00:002004-12-02T01:00:001.001.002004-12-03T01:00:002004-12-03T00:00:002004-11-13T21:47:34wierd # Looks like you failed 1 test of 19. [...] Test Summary Report --- t/01parse.t (Wstat: 256 Tests: 19 Failed: 1) Failed test: 10 Non-zero exit status: 1 Files=2, Tests=21, 2 wallclock secs ( 0.03 usr 0.00 sys + 1.52 cusr 0.02 csys = 1.57 CPU) Result: FAIL
Bug#805105: libatombus-perl: FTBFS: Atompub::DateTime does not export: datetime
reassign 805105 libperl6-export-attrs-perl 0.04-2
affects 805105 libatompub-perl
tags 805105 patch
forwarded 805105 https://rt.cpan.org/Ticket/Display.html?id=107627
thanks
On Sat, Nov 14, 2015 at 09:25:35PM +0200, Niko Tyni wrote:
> On Sat, Nov 14, 2015 at 09:19:14PM +0200, Niko Tyni wrote:
> > Package: libatombus-perl
> > Version: 1.0405-2
> > Severity: serious
> >
> > This package fails to build on current sid:
> >
> > Atompub::DateTime does not export: datetime
>
> > Looking at https://reproducible.debian.net/history/libatombus-perl.html
> > this regressed in sid between 2015-10-18 and 2015-10-27.
>
> This was apparently broken by libperl6-export-attrs-perl_0.04-2.
>
> See https://rt.cpan.org/Public/Bug/Display.html?id=108287
> and https://rt.cpan.org/Public/Bug/Display.html?id=107627
It's indeed a trivial regression there, patch attached.
--
Niko Tyni nt...@debian.org
>From 132e0e132ba7d5185433e760f390aa330ea3ab49 Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Sun, 22 Nov 2015 00:08:55 +0200
Subject: [PATCH] Fix a 0.04 regression in exporting subroutines
While at it, add a test case catching the regression.
Bug: https://rt.cpan.org/Public/Bug/Display.html?id=107627
Bug-Debian: https://bugs.debian.org/805105
---
lib/Perl6/Export/Attrs.pm | 2 +-
t/01export.t | 12
2 files changed, 13 insertions(+), 1 deletion(-)
create mode 100644 t/01export.t
diff --git a/lib/Perl6/Export/Attrs.pm b/lib/Perl6/Export/Attrs.pm
index cbe36b0..03016aa 100644
--- a/lib/Perl6/Export/Attrs.pm
+++ b/lib/Perl6/Export/Attrs.pm
@@ -141,7 +141,7 @@ sub _generic_import {
REQUEST:
while ($argno < @_) {
my $request = $_[$argno];
-if (my ($sub_name) = $request =~ m/\A & ($IDENT) (?:\(\))? \z/xms) {
+if (my ($sub_name) = $request =~ m/\A &? ($IDENT) (?:\(\))? \z/xms) {
if (exists $request{$sub_name}) {
splice @_, $argno, 1;
next REQUEST;
diff --git a/t/01export.t b/t/01export.t
new file mode 100644
index 000..976e924
--- /dev/null
+++ b/t/01export.t
@@ -0,0 +1,12 @@
+use Test::More tests => 1;
+
+package Lib;
+use Perl6::Export::Attrs;
+sub doit :Export { "Do it!"; }
+1;
+
+package main;
+import Lib qw(doit);
+
+is(doit(), "Do it!", "function exported as expected");
+
--
2.6.2
Bug#805737: libembperl-perl: FTBFS: apache2 crash during test suite
Package: libembperl-perl Version: 2.5.0-4 Severity: serious Tags: sid stretch X-Debbugs-Cc: apac...@packages.debian.org This package fails to build on current sid. Testing mod_perl mode... #0 ascii... ok #1 pure.htm...ERR:Status read failed: Connection reset by peer The test apache2 process is crashing with this backtrace: Core was generated by `/usr/sbin/apache2 -X -f /home/niko/tmp/libembperl-perl-2.5.0/test/conf/httpd.co'. Program terminated with signal SIGSEGV, Segmentation fault. #0 ap_mpm_pod_check (pod=0x0) at mpm_unix.c:459 459 mpm_unix.c: No such file or directory. (gdb) bt #0 ap_mpm_pod_check (pod=0x0) at mpm_unix.c:459 #1 0x7f280ff3cb17 in child_main (child_num_arg=child_num_arg@entry=0, child_bucket=child_bucket@entry=0) at prefork.c:732 #2 0x7f280ff3cd32 in make_child (s=0x7f2811a2c470, slot=slot@entry=0, bucket=bucket@entry=0) at prefork.c:767 #3 0x7f280ff3e292 in prefork_run (_pconf=, plog=0x7f2811a27028, s=0x7f2811a2c470) at prefork.c:979 #4 0x56038855f9ae in ap_run_mpm (pconf=0x7f2811a53028, plog=0x7f2811a27028, s=0x7f2811a2c470) at mpm_common.c:94 #5 0x560388559040 in main (argc=4, argv=0x7ffed5563c88) at main.c:777 This regressed with apache2 upgrade from 2.4.16-3 to 2.4.17-2, so I'm cc'ing the apache2 maintainers in case they have ideas. -- Niko Tyni nt...@debian.org
Bug#805403: libpango-perl: FTBFS: undefined symbol: pango_cairo_update_layout (broken by pkg-config 0.29)
Control: tag -1 patch
On Tue, Nov 17, 2015 at 10:07:51PM +0200, Niko Tyni wrote:
> Package: libpango-perl
> Version: 1.226-2
> Tags: sid
> Severity: serious
> X-Debbugs-Cc: pkg-con...@packages.debian.org
>
> The libpango-perl package fails to build on current sid.
>
> [...]
> Warning (mostly harmless): No library found for -lglib-2.0-lpangocairo-1.0
> [...]
> Can't load 'blib/arch/auto/Pango/Pango.so' for module Pango:
> blib/arch/auto/Pango/Pango.so: undefined symbol: pango_cairo_update_layout at
> /usr/lib/x86_64-linux-gnu/perl/5.20/DynaLoader.pm line 187.
> This broke with pkg-config 0.28-1 -> 0.29-2, because 'pkg-config --libs
> pango' output no longer has a space at the end. The libpango-perl build
> system concatenates the output with the 'pkg-config --libs pangocairo'
> output, which now breaks.
>
> Cc'ing the pkg-config maintainer. Tollef, is this an intentional change?
Looking at
http://cgit.freedesktop.org/pkg-config/commit/?id=f26a505826acec6b1e1af8d1efdf959913421c3a
it apparently was intentional.
Patch for libpango-perl attached.
--
Niko Tyni nt...@debian.org
>From 6bdc1e830eb1bb48209a22510425f9b0d88592ae Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Sat, 21 Nov 2015 10:38:52 +0200
Subject: [PATCH] Ensure word separation in linker arguments with pkg-config >=
0.29
Since pkg-config 0.29,
http://cgit.freedesktop.org/pkg-config/commit/?id=f26a505826acec6b1e1af8d1efdf959913421c3a
the cflags and libs no longer have a trailing space, resulting
in bogus linker arguments like -lglib-2.0-lpangocairo-1.0.
The 'cflags' strings are already joined with whitespace earlier
so only the 'libs' need fixing.
---
Makefile.PL | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile.PL b/Makefile.PL
index e644209..1d3349d 100644
--- a/Makefile.PL
+++ b/Makefile.PL
@@ -161,7 +161,7 @@ my $libs = $pango_pkgcfg{libs};
if ($have_cairo) {
push @deps, qw/Cairo/;
$inc .= $pangocairo_pkgcfg{cflags};
- $libs .= $pangocairo_pkgcfg{libs};
+ $libs .= ' ' . $pangocairo_pkgcfg{libs};
}
my @typemaps = map { File::Spec->catfile(cwd(), $_) }
--
2.6.2
Bug#805387: libtypes-datetime-perl: FTBFS: t/02mxtdt.t failure, broken by libdatetime-locale-perl_1:1.01-1
Package: libtypes-datetime-perl
Version: 0.001-3
Severity: serious
Tags: upstream sid stretch
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=108684
This package fails to build on current sid:
Attribute (loc) does not pass the type constraint because: Reference bless(
{"am_pm_abbreviated" => ["AM","PM"],"available_format...) did not pass type
constraint "Locale" (not isa DateTime::Locale::root) at
/usr/lib/x86_64-linux-gnu/perl5/5.20/Moose/Object.pm line 24
Moose::Object::new('Gorch', 'loc', 'he_IL') called at t/02mxtdt.t line 121
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 13.
[...]
Test Summary Report
---
t/02mxtdt.t (Wstat: 65280 Tests: 13 Failed: 0)
Non-zero exit status: 255
Parse errors: No plan found in TAP output
This is [rt.cpan.org #108684] and was apparently broken recently by
libdatetime-locale-perl_1:1.01-1.
--
Niko Tyni nt...@debian.org
Bug#805403: libpango-perl: FTBFS: undefined symbol: pango_cairo_update_layout (broken by pkg-config 0.29)
Package: libpango-perl Version: 1.226-2 Tags: sid Severity: serious X-Debbugs-Cc: pkg-con...@packages.debian.org The libpango-perl package fails to build on current sid. [...] Warning (mostly harmless): No library found for -lglib-2.0-lpangocairo-1.0 [...] Can't load 'blib/arch/auto/Pango/Pango.so' for module Pango: blib/arch/auto/Pango/Pango.so: undefined symbol: pango_cairo_update_layout at /usr/lib/x86_64-linux-gnu/perl/5.20/DynaLoader.pm line 187. at -e line 0. Compilation failed in require. BEGIN failed--compilation aborted. Makefile:1388: recipe for target 'build/podindex' failed make[1]: *** [build/podindex] Error 2 This broke with pkg-config 0.28-1 -> 0.29-2, because 'pkg-config --libs pango' output no longer has a space at the end. The libpango-perl build system concatenates the output with the 'pkg-config --libs pangocairo' output, which now breaks. Cc'ing the pkg-config maintainer. Tollef, is this an intentional change? With 0.28-1: % pkg-config --libs pango|grep -q ' $' && echo ok ok With 0.29-2: % pkg-config --libs pango|grep -q ' $' && echo ok % -- Niko Tyni nt...@debian.org
Bug#805144: libmongodbx-class-perl: FTBFS: Attribute (bson_codec) is required at constructor
Package: libmongodbx-class-perl
Version: 1.030002-1
Severity: serious
Tags: sid stretch
This package fails to build on current sid. Looking at
https://reproducible.debian.net/history/libmongodbx-class-perl.html
this regressed between 2015-10-21 and 2015-11-02.
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-MTest::Harness"
"-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch')"
t/*.t
# Testing MongoDBx::Class 1.030002, Perl 5.020002, /usr/bin/perl
t/00-load.t
1..1
ok 1 - use MongoDBx::Class;
ok
Attribute (bson_codec) is required at constructor
MongoDBx::Class::Database::new (defined at
/build/libmongodbx-class-perl-1.030002/blib/lib/MongoDBx/Class/Database.pm line
110) line 22
MongoDBx::Class::Database::new('MongoDBx::Class::Database', '_client',
'MongoDBx::Class::Connection=HASH(0x54f41c8)', 'name', 'mongodbx_class_test')
called at
/build/libmongodbx-class-perl-1.030002/blib/lib/MongoDBx/Class/Connection.pm
line 102
MongoDBx::Class::Connection::__ANON__('MongoDBx::Class::Connection=HASH(0x54f41c8)',
'mongodbx_class_test') called at
/usr/lib/x86_64-linux-gnu/perl5/5.20/Moose/Meta/Method/Overridden.pm line 38
MongoDBx::Class::Connection::get_database('MongoDBx::Class::Connection=HASH(0x54f41c8)',
'mongodbx_class_test') called at t/01-simple.t line 31
# Looks like you planned 32 tests but ran 2.
# Looks like your test exited with 255 just after 2.
t/01-simple.t ..
1..32
ok 1 - successfully loaded schema
ok 2 - Using safe operations by default
Dubious, test returned 255 (wstat 65280, 0xff00)
[...]
Test Summary Report
---
t/01-simple.t(Wstat: 65280 Tests: 2 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 32 tests but ran 2.
--
Niko Tyni nt...@debian.org
Bug#803043: mod_perl2 / Apache segfaults after upgrading from Wheezy to Jessie
On Tue, Nov 10, 2015 at 11:09:24AM +0100, Patrick Matthäi wrote: > > > Am 28.10.2015 um 21:25 schrieb Niko Tyni: > >On Tue, Oct 27, 2015 at 12:24:26PM +0200, Niko Tyni wrote: > >>On Tue, Oct 27, 2015 at 10:24:23AM +0100, Patrick Matthäi wrote: > >I think the two attached patches from upstream r1636289 and r1676417 are > >the only likely candidates and should most probably be included together. > >They apply as-is to the jessie package. > > > >Any testing would be very welcome. > > Looks still good. Would you prepare a stable upload please? Yes, I'll do that. Thanks for your help in testing this! -- Niko Tyni nt...@debian.org
Bug#805233: libdbix-class-perl: FTBFS: t/105view_deps.t failure
Package: libdbix-class-perl Version: 0.082820-1 Severity: serious Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=107852 Tags: fixed-upstream This package fails to build on current sid/amd64. Looking at https://reproducible.debian.net/history/libdbix-class-perl.html the regression happened between 2015-10-20 and 2015-11-01. [rt.cpan.org #107852] indicates this broke with SQLite 3.9.0 or so, and should be fixed by https://github.com/dbsrgits/dbix-class/commit/26c663f1 # Failed test 'Deploying the bad schema produces a warning: aba_name_artists was not created.' # at t/105view_deps.t line 79. # didn't find a warning # expected to find warning: (?^:no such table: main.aba_name_artists) # Failed test 'Query on AbaNameArtistsAnd2010CDsWithManyTracks throws, because the table does not exist' # at t/105view_deps.t line 110. # expecting: Regexp ((?^:no such table: aba_name_artists_and_2010_cds_with_many_tracks)) # found: normal exit # Looks like you failed 2 tests of 25. [...] Test Summary Report --- t/105view_deps.t (Wstat: 512 Tests: 25 Failed: 2) Failed tests: 17, 25 Non-zero exit status: 2 -- Niko Tyni nt...@debian.org
Bug#805102: liblog-dispatch-message-passing-perl: FTBFS: t/basic.t failure
Package: liblog-dispatch-message-passing-perl Version: 0.009-2 Severity: serious Tags: sid This package fails to build on current sid: Can't locate JSON.pm in @INC (you may need to install the JSON module) (@INC contains: /<>/inc /<>/blib/lib /<>/blib/arch /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl .) at /usr/share/perl5/Message/Passing/Role/Output.pm line 3. BEGIN failed--compilation aborted at /usr/share/perl5/Message/Passing/Role/Output.pm line 3. Compilation failed in require at /usr/share/perl5/Module/Runtime.pm line 317. Compilation failed in require at /usr/share/perl5/Module/Runtime.pm line 317. Compilation failed in require at t/basic.t line 8. [...] Test Summary Report --- t/basic.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output This is a regression between 2015-10-29 and 2015-11-10 (see https://reproducible.debian.net/history/liblog-dispatch-message-passing-perl.html ). It looks like the root is libmessage-passing-perl missing a runtime dependency on libjson-perl, but this used to be masked by libmoox-options-perl depending on libjson-perl until recently (4.020-1). -- Niko Tyni nt...@debian.org
Bug#805105: libatombus-perl: FTBFS: Atompub::DateTime does not export: datetime
Control: reassign -1 libatompub-perl 0.3.7-2 Control: retitle -1 libatompub-perl: doesn't work with Perl6::Export::Attrs-0.0.4 Control: affects -1 libatombus-perl On Sat, Nov 14, 2015 at 09:19:14PM +0200, Niko Tyni wrote: > Package: libatombus-perl > Version: 1.0405-2 > Severity: serious > > This package fails to build on current sid: > > Atompub::DateTime does not export: datetime > Looking at https://reproducible.debian.net/history/libatombus-perl.html > this regressed in sid between 2015-10-18 and 2015-10-27. This was apparently broken by libperl6-export-attrs-perl_0.04-2. See https://rt.cpan.org/Public/Bug/Display.html?id=108287 and https://rt.cpan.org/Public/Bug/Display.html?id=107627 -- Niko Tyni nt...@debian.org
Bug#805102: liblog-dispatch-message-passing-perl: FTBFS: t/basic.t failure
retitle 805102 libmessage-passing-perl: missing runtime and build dependencies on libjson-perl reassign 805102 libmessage-passing-perl 0.116-1 affects 805102 liblog-dispatch-message-passing-perl thanks On Sat, Nov 14, 2015 at 08:55:33PM +0200, Niko Tyni wrote: > Package: liblog-dispatch-message-passing-perl > Version: 0.009-2 > Severity: serious > Tags: sid > > This package fails to build on current sid: > > Can't locate JSON.pm in @INC (you may need to install the JSON module) > (@INC contains: /<>/inc /<>/blib/lib > /<>/blib/arch /etc/perl > /usr/local/lib/x86_64-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 > /usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5 > /usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 > /usr/local/lib/site_perl .) at > /usr/share/perl5/Message/Passing/Role/Output.pm line 3. > This is a regression between 2015-10-29 and 2015-11-10 (see > > https://reproducible.debian.net/history/liblog-dispatch-message-passing-perl.html > ). It looks like the root is libmessage-passing-perl missing a > runtime dependency on libjson-perl, but this used to be masked by > libmoox-options-perl depending on libjson-perl until recently (4.020-1). I see libmessage-passing-perl is failing to build too because of a missing build dependency on libjson-perl. I'm reassigning and retitling this, no use tracking two bugs about it. -- Niko Tyni nt...@debian.org
Bug#805103: libmessage-passing-filter-regexp-perl: FTBFS: missing build-dependency on libjson-perl
Package: libmessage-passing-filter-regexp-perl Version: 0.05-1 Severity: serious Tags: sid This package fails to build on current sid: Can't locate JSON.pm in @INC (you may need to install the JSON module) (@INC contains: lib /<>/blib/lib /<>/blib/arch /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl .) at t/003-Message-Passing-Filter-Regexp.t line 7. BEGIN failed--compilation aborted at t/003-Message-Passing-Filter-Regexp.t line 7. t/003-Message-Passing-Filter-Regexp.t .. Dubious, test returned 2 (wstat 512, 0x200) No subtests run Test Summary Report --- t/003-Message-Passing-Filter-Regexp.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output This is a recent regression, very similar to #805102. However, even though it will go away by making libmessage-passing-perl depend on libjson-perl, that is not quite the correct fix as t/003-Message-Passing-Filter-Regexp.t is using the JSON module directly. So it looks like libmessage-passing-filter-regexp-perl needs an explicit build dependency on libjson-perl. -- Niko Tyni nt...@debian.org
Bug#805105: libatombus-perl: FTBFS: Atompub::DateTime does not export: datetime
Package: libatombus-perl Version: 1.0405-2 Severity: serious This package fails to build on current sid: Atompub::DateTime does not export: datetime use Atompub::DateTime failed at /<>/lib/AtomBus.pm line 5. BEGIN failed--compilation aborted at /<>/lib/AtomBus.pm line 5. Compilation failed in require at t/01-basic.t line 16. [...] Test Summary Report --- t/01-basic.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 12 tests but ran 0. t/02-paging.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 21 tests but ran 0. Files=2, Tests=0, 1 wallclock secs ( 0.06 usr 0.00 sys + 0.76 cusr 0.06 csys = 0.88 CPU) Result: FAIL Looking at https://reproducible.debian.net/history/libatombus-perl.html this regressed in sid between 2015-10-18 and 2015-10-27. -- Niko Tyni nt...@debian.org
Bug#803975: libcrypt-ssleay-perl: Uses SSLv3_client_method()
On Fri, Nov 06, 2015 at 05:48:32PM +0100, gregor herrmann wrote: > I have to admit that I'm still not completely sure if/how this > affects us packaging-wise. My current understanding is, that the > library would allow to set SSLv3 via HTTPS_VERSION which will fail > now on Debian but that it should just work fine with the default > values. Is this correct? As discussed on IRC, it looks to me like there's no code support for HTTPS_VERSION in 0.73_04 anymore. It seems to be just a leftover in the docs. The upstream code in 0.73_04 now uses SSLv23_client_method() with SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 by default, and with SSL_OP_ALL | SSL_OP_NO_SSLv2 if the (currently undocumented) environment variable CRYPT_SSLEAY_ALLOW_SSLv3 is set. This seems to be pretty much we want, so I think uploading 0.73_04 is the way to fix this bug. The docs could be improved a bit of course. -- Niko Tyni nt...@debian.org
Bug#803326: libperl6-export-attrs-perl: missing dependency on libpadwalker-perl
Package: libperl6-export-attrs-perl Version: 0.04-1 Severity: serious Control: affects -1 libatombus-perl This package is missing a runtime dependency on libpadwalker-perl: # perl -e 'use Perl6::Export::Attrs' Can't locate PadWalker.pm in @INC (you may need to install the PadWalker module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl .) at /usr/share/perl5/Perl6/Export/Attrs.pm line 9. BEGIN failed--compilation aborted at /usr/share/perl5/Perl6/Export/Attrs.pm line 9. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. This makes at least libatombus-perl fail to build from source in current sid. -- Niko Tyni nt...@debian.org
Bug#803321: [Reproducible-builds] Bug#803321: rawdns: FTBFS: cp: cannot stat 'debian/tmp/debian/tmp/dh-exec.ShSIquIE/etc/rawdns.json': No such file or
On Wed, Oct 28, 2015 at 07:08:27PM +, Chris Lamb wrote: > Source: rawdns > Version: 1.2~ds1-2 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > rawdns fails to build from source in unstable/amd64: > > [..] > > dh_install -O--buildsystem=golang > cp: cannot stat > 'debian/tmp/debian/tmp/dh-exec.ShSIquIE/etc/rawdns.json': No such file > or directory Looks like #802034, fixed today in dh-exec_0.22. -- Niko Tyni nt...@debian.org
Bug#803043: mod_perl2 / Apache segfaults after upgrading from Wheezy to Jessie
On Tue, Oct 27, 2015 at 12:24:26PM +0200, Niko Tyni wrote:
> On Tue, Oct 27, 2015 at 10:24:23AM +0100, Patrick Matthäi wrote:
> > If it fixes the problem, do you have got an idea which changes to pick up
> > for fixing jessie?
>
> I haven't looked at it properly yet, but I think there weren't too many
> changes between the versions. I'll follow up on this later when I find
> the time, but it might take a week or so.
I think the two attached patches from upstream r1636289 and r1676417 are
the only likely candidates and should most probably be included together.
They apply as-is to the jessie package.
Any testing would be very welcome.
--
Niko Tyni nt...@debian.org
>From 514800554f704d0fe90fefd70016583099d7944b Mon Sep 17 00:00:00 2001
From: Steve Hay <steve...@apache.org>
Date: Mon, 3 Nov 2014 08:41:03 +
Subject: [PATCH] Decrement interp->refcnt when freeing interpreter in
modperl_interp_unselect()
The case where interp->refcnt==1 was not being handled correctly. Prior to r1562772 the refcnt was decremented to 0 but then the function returned early, wrongly not freeing the interpreter, leading to deadlock in the event MPM. Following that change the interpreter was now freed, but the refcnt was wrongly no longer decremented.
This change decrements the refcnt (always) and frees the interpreter as well (unless the refcnt is still > 0). An extra safety check is also made, to return early if the interpreter has already been unselected, although with correct refcnting now, we do not expect this to happen.
This patch is based on investigations and a tentative patch suggested by Richard M Kandarian:
http://marc.info/?t=14019121874=1=2
git-svn-id: https://svn.apache.org/repos/asf/perl/modperl/trunk@1636289 13f79535-47bb-0310-9956-ffa450edef68
---
src/modules/perl/modperl_interp.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/modules/perl/modperl_interp.c b/src/modules/perl/modperl_interp.c
index 430a2af..a984006 100644
--- a/src/modules/perl/modperl_interp.c
+++ b/src/modules/perl/modperl_interp.c
@@ -273,17 +273,24 @@ apr_status_t modperl_interp_unselect(void *data)
modperl_interp_t *interp = (modperl_interp_t *)data;
modperl_interp_pool_t *mip = interp->mip;
-MP_ASSERT(interp && MpInterpIN_USE(interp));
+MP_ASSERT(interp && MpInterpIN_USE(interp) && interp->refcnt > 0);
MP_TRACE_i(MP_FUNC, "unselect(interp=%pp): refcnt=%d",
interp, interp->refcnt);
-if (interp->refcnt > 1) {
---interp->refcnt;
+--interp->refcnt;
+
+if (interp->refcnt > 0) {
MP_TRACE_i(MP_FUNC, "interp=0x%lx, refcnt=%d -- interp still in use",
(unsigned long)interp, interp->refcnt);
return APR_SUCCESS;
}
+if (!MpInterpIN_USE(interp)){
+MP_TRACE_i(MP_FUNC, "interp=0x%pp, refcnt=%d -- interp already not in use",
+ interp, interp->refcnt);
+return APR_SUCCESS;
+}
+
MpInterpIN_USE_Off(interp);
modperl_thx_interp_set(interp->perl, NULL);
--
2.5.1
>From c7979a708a7be018e5e22680314ea580b2ac2c7a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jan=20Kalu=C5=BEa?= <jkal...@apache.org>
Date: Tue, 28 Apr 2015 06:51:12 +
Subject: [PATCH] Initialize interp->refcnt to 1 in modperl_interp_select.
Reasoning:
1. All calls of MP_INTERPa do not increment interp->refcnt, so refcnt
used to be 0 before this commit. But there is always matching
MP_INTERP_PUTBACK, which calls modperl_interp_unselect which decreases
the refcnt, so it was possible to get negative refcnt or crash with
threaded MPMs, because reference counting has been broken.
2. modperl_interp_select increases the refcount if it finds the PerlInterp in
ccfg, so it makes sense to increase it (it means set to 1) during
initialization too. Otherwise the refcnt would be incremented for the caller
in some cases, but wouldn't be in other.
This commit fixes the crash seen on worker MPM when PerlInterp has been used
by two threads and the first one freed PerlInterp during
modperl_interp_unselect.
git-svn-id: https://svn.apache.org/repos/asf/perl/modperl/trunk@1676417 13f79535-47bb-0310-9956-ffa450edef68
---
src/modules/perl/modperl_interp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/modules/perl/modperl_interp.c b/src/modules/perl/modperl_interp.c
index a984006..67dd2e4 100644
--- a/src/modules/perl/modperl_interp.c
+++ b/src/modules/perl/modperl_interp.c
@@ -460,7 +460,7 @@ modperl_interp_t *modperl_interp_select(request_rec *r, conn_rec *c,
interp = modperl_interp_get(s);
MP_TRACE_i(MP_FUNC, " --> got %pp (perl=%pp)", interp, interp->perl);
++interp->num_requests; /* should only get here once per request */
-interp->refcnt = 0;
+interp->refcnt = 1;
/* set context (THX) for this thread */
PERL_SET_CONTEXT(interp->perl);
--
2.5.1
Bug#803043: mod_perl2 / Apache segfaults after upgrading from Wheezy to Jessie
On Mon, Oct 26, 2015 at 11:21:12AM +0100, Patrick Matthäi wrote: > Package: libapache2-mod-perl2 > Version: 2.0.9~1624218-2 > Severity: grave > after upgrading our otrs2 server from wheezy/amd64 to jessie I noticed > dozens of apache segfaults per day on this machine. In dmesg it looks like > this: > Now the more curious thing. I have updated another server from Wheezy to > Jessie, which is just serving gitolite and subversion repositories (about > mod_svn). After the upgrade full svn checkouts were impossible, also because > of segfaults from Apache itself. Later I found, that mod_perl2 was installed > and activated on this system, but it was not used at all. So uninstalling > libapache2-mod-perl2 solved the issue on the server, where it was not > required. Thanks for the report. Would it be possible for you to test if 2.0.9-1 from stretch/sid has the same behaviour? The binaries aren't quite installable in jessie, but the build dependencies are so it's just a simple rebuild. I can also provide binaries if you like. -- Niko Tyni nt...@debian.org
Bug#803043: mod_perl2 / Apache segfaults after upgrading from Wheezy to Jessie
On Tue, Oct 27, 2015 at 10:24:23AM +0100, Patrick Matthäi wrote: > Am 27.10.2015 um 08:34 schrieb Niko Tyni: > >Would it be possible for you to test if 2.0.9-1 from stretch/sid has > >the same behaviour? The binaries aren't quite installable in jessie, > >but the build dependencies are so it's just a simple rebuild. I can also > >provide binaries if you like. > > No problem. Already deployed on both machines for testing: Thanks! Please keep us updated on the results. > If it fixes the problem, do you have got an idea which changes to pick up > for fixing jessie? I haven't looked at it properly yet, but I think there weren't too many changes between the versions. I'll follow up on this later when I find the time, but it might take a week or so. > Maybe it is relevant, that all our services are reachable about HTTPS? Hard to say yet, but it's a data point at least. Thanks again, -- Niko
Bug#803178: libmongodb-perl: FTBFS on various architectures
On Tue, Oct 27, 2015 at 06:48:59PM +0100, gregor herrmann wrote:
> Package: libmongodb-perl
> Version: 1.0.2-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Yesterday's 1.0.2-1 upload failed to build on mips, powerpc, and
> s390x (plus hppa and ppc64):
>
> https://buildd.debian.org/status/package.php?p=libmongodb-perl
> https://buildd.debian.org/status/logs.php?pkg=libmongodb-perl=1.0.2-1
>
> The failing tests seem to be the same on all architectures, and they
> are new in this release.
It's clearly an endianness issue. All the failing platforms are big
endian and this looks pretty clear:
# Failed test 'encode_one( HASH )'
# at t/bson_codec/containers.t line 201.
# got:
'\x{10}\x{00}\x{00}\x{00}\x{01}a\x{00}\x{ae}G\x{e1}z\x{14}\x{ae}\x{f3}?\x{00}'
# expected:
'\x{10}\x{00}\x{00}\x{00}\x{01}a\x{00}?\x{f3}\x{ae}\x{14}z\x{e1}G\x{ae}\x{00}'
Adding some diagnostics indicates the actual data encoding is stable
between the platforms, but the test suite expectations depend on the
endianness. The attached patch seems to fix this on at least s390x,
but perhaps we should have a test run with it before pushing it upstream.
--
Niko Tyni nt...@debian.org
>From 6469bf8eb321686c3b38a15b9a8a311a838568cb Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Tue, 27 Oct 2015 20:49:00 +
Subject: [PATCH] Expect BSON encoded doubles in little endian order
This fixes bson_codec test failures on big endian platforms.
Bug-Debian: https://bugs.debian.org/803178
---
t/lib/TestBSON.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/lib/TestBSON.pm b/t/lib/TestBSON.pm
index e400586..b0f5b04 100644
--- a/t/lib/TestBSON.pm
+++ b/t/lib/TestBSON.pm
@@ -82,7 +82,7 @@ sub _doc {
sub _cstring { return $_[0] . "\x00" }
BEGIN { *_ename = \&_cstring }
-sub _double { return pack( "d", shift ) }
+sub _double { return pack( PERL58 ? "d" : "d<", shift ) }
sub _int32 { return pack( P_INT32, shift ) }
--
2.1.4
Bug#787453: libdata-alias-perl: FTBFS with perl 5.22
On Wed, Oct 21, 2015 at 11:33:44PM +0100, Zefram wrote: > The compiler-dependent problem turned out to be some C-level undefined > behaviour in the module, with insufficient sequence points around a > variable mutation. The compilers differed in whether they performed > the write before or after a call to a Perl core function (yylex()) > that in 5.22 has come to depend on the variable more than it used to. > > Fixed in Data-Alias-1.20, now on CPAN. Awesome, many thanks for your work! -- Niko Tyni nt...@debian.org
Bug#787453: libdata-alias-perl: FTBFS with perl 5.22
On Wed, Oct 21, 2015 at 06:22:28PM +0100, Zefram wrote: > It would be really helpful if someone with a failing setup would > try figuring out which part of the perl build makes the difference. > Something I haven't yet tried varying is the C compiler. I'm using Debian > gcc 4.7.2-5, which doesn't understand the -fstack-protector-strong option > that the failing perls are built with. I've just tried building Data-Alias-1.19 on unmodified upstream Perl 5.22.0 with gcc 4.8.5 and 5.2.1, with and without -Dusethreads, and with and without -fstack-protector-strong. It fails with all of these. However, building Data-Alias-1.19 with clang works even on our packaged perl 5.22.0-4. So the perl build doesn't seem to matter that much. For more data points, all 5.22.0 CPAN testers seem to fail except Darwin, which is using clang of course. Even Win32 builds fail :) Unfortunately I don't have gcc-4.7 handy right now, so I can't say yet if that works for me or not. Hope this helps a bit, -- Niko Tyni nt...@debian.org
Bug#802034: mb2md: FTBFS: dh_install failure
Package: mb2md Version: 3.20-7 Severity: serious X-Debbugs-Cc: dh-e...@packages.debian.org This package fails to build on current sid. dh_install cp: cannot stat 'debian/tmp/debian/tmp/dh-exec.JqZw1lqx/usr/bin/mb2md': No such file or directory dh_install: cp --reflink=auto -a debian/tmp/debian/tmp/dh-exec.JqZw1lqx/usr/bin/mb2md debian/mb2md/usr/bin// returned exit code 1 make: *** [binary] Error 2 This broke with dh-exec 0.18. Apparently it's something to do with the DH_CONFIG_ACT_ON_PACKAGES changes (#698054). It's not clear to me if mb2md is doing something wrong or if it's a regression in dh-exec. The debian/install contents are just #!/usr/bin/dh-exec mb2md-3.20.pl => usr/bin/mb2md Copying the dh-exec maintainer. -- Niko Tyni nt...@debian.org
Bug#801659: XML-Compile-Dumper and Perl 5.22
Hi Mark, just a note in case you're not aware of the issue: your CPAN module XML-Compile-Dumper can't currently be installed with Perl 5.22. This is because it requires Data-Dump-Streamer which has compatibility problems: https://rt.cpan.org/Public/Bug/Display.html?id=102369 We'll be updating Debian testing/unstable to Perl 5.22 soonish, and currently that means that the packages for Data-Dump-Streamer and XML-Compile-Dumper need to be removed. These are tracked on the Debian side as https://bugs.debian.org/787912 https://bugs.debian.org/801659 Do you think XML-Compile-Dumper could be made to use another backend or something? Many thanks for your work on free software, -- Niko Tyni (Debian Perl Group) nt...@debian.org
Bug#801659: XML-Compile-Dumper and Perl 5.22
On Tue, Oct 13, 2015 at 10:52:23AM +0300, Niko Tyni wrote: > We'll be updating Debian testing/unstable to Perl 5.22 soonish, and > currently that means that the packages for Data-Dump-Streamer and > XML-Compile-Dumper need to be removed. Upstream responded to me privately, saying XML-Compile-Dumper has very few users and can well be dropped from Debian if necessary. -- Niko Tyni nt...@debian.org
Bug#787912: libdata-dump-streamer-perl: FTBFS with perl 5.22
clone 787912 -1 -2 -3 -4 -5 retitle -1 libxml-compile-dumper-perl: depends on libdata-dump-streamer-perl, broken by perl 5.22 retitle -2 libtest-aggregate-perl: relax dependencies on libdata-dump-streamer-perl, broken by perl 5.22 retitle -3 libmoosex-runnable-perl: relax dependencies on libdata-dump-streamer-perl, broken by perl 5.22 retitle -4 libdevel-repl-perl: relax dependencies on libdata-dump-streamer-perl, broken by perl 5.22 retitle -5 libuniversal-ref-perl: relax build-dependency on libdata-dump-streamer-perl, broken by perl 5.22 reassign -1 libxml-compile-dumper-perl 0.14-1 reassign -2 libtest-aggregate-perl 0.372-1 reassign -3 libmoosex-runnable-perl 0.09-1 reassign -4 libdevel-repl-perl 1.003027-1 reassign -5 libuniversal-ref-perl 0.14-2 thanks On Sat, Jun 06, 2015 at 10:24:35AM +0100, Dominic Hargreaves wrote: > Source: libdata-dump-streamer-perl > Version: 2.38-2 > Severity: important > User: debian-p...@lists.debian.org > Usertags: perl-5.22-transition > Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=102369 > > This package FTBFS with perl 5.22: There's no action on the upstream ticket(s), so it looks like this module won't get updated for 5.22. I think we should look at minimizing the cost of its removal. The binary reverse dependencies are libxml-compile-dumper-perl libtest-aggregate-perl libmoosex-runnable-perl libdevel-repl-perl and additionally there's one more package build depending on it: libuniversal-ref-perl All of these except libxml-compile-dumper-perl have Data-Dump-Streamer as an optional dependency, so I think we could just relax the dependencies to recommendations. The libxml-compile-dumper-perl package clearly needs Data-Dump-Streamer. It doesn't have any reverse dependencies itself, so it may just have to go with libxml-compile-dumper-perl if needed. I'm cloning separate bugs for all the affected packages. -- Niko Tyni nt...@debian.org
Bug#801610: libogg-vorbis-decoder-perl: FTBFS: Failed test 'raw_total'
Package: libogg-vorbis-decoder-perl Version: 0.9-2 Severity: serious User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs As noticed by the reproducible.debian.net CI setup, this package fails to build on current sid: # Failed test 'raw_total' # at t/basic.t line 20. # got: '4414398' # expected: '4418594' # Looks like you failed 1 test of 20. [...] Test Summary Report --- t/basic.t (Wstat: 256 Tests: 20 Failed: 1) Failed test: 9 Non-zero exit status: 1 -- Niko Tyni nt...@debian.org
Bug#801609: license-reconcile: FTBFS: cannot parse file 't/data/example/sample.png'
Package: license-reconcile
Version: 0.7
Severity: serious
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
As noticed by the reproducible.debian.net CI setup, this package
fails to build on current sid:
# Failed test at t/09-licensecheck.t line 20.
# Compared $data->[0]{"file"}
#got : 'base'
# expect : 'base.h'
/usr/bin/licensecheck warning: cannot parse file 't/data/example/sample.png'
with mime type 'image/png; charset=binary'
# Failed test at t/09-licensecheck.t line 37.
# Compared $data->[0]{"file"}
#got : 'base'
# expect : 'base.h'
# Looks like you failed 2 tests of 7.
[...]
/usr/bin/licensecheck warning: cannot parse file 't/data/example/sample.png'
with mime type 'image/png; charset=binary'
/usr/bin/licensecheck warning: cannot parse file 't/data/example/sample.png'
with mime type 'image/png; charset=binary'
# Failed test at t/18-app.t line 159.
# Comparing $data as a Bag
# Missing: 2 references
# Extra: 2 references
# Looks like you failed 1 test of 41.
Test Summary Report
---
t/09-licensecheck.t (Wstat: 512 Tests: 7 Failed: 2)
Failed tests: 3, 6
Non-zero exit status: 2
t/18-app.t (Wstat: 256 Tests: 41 Failed: 1)
Failed test: 40
Non-zero exit status: 1
--
Niko Tyni nt...@debian.org
Bug#801610: libogg-vorbis-decoder-perl: FTBFS: Failed test 'raw_total'
On Mon, Oct 12, 2015 at 04:52:37PM +0300, Niko Tyni wrote: > Package: libogg-vorbis-decoder-perl > Version: 0.9-2 > Severity: serious > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > # Failed test 'raw_total' > # at t/basic.t line 20. > # got: '4414398' > # expected: '4418594' This test was broken by src:libvorbis (binary:libvorbisfile3 to be exact) upgrade from 1.3.4-2 to 1.3.4-3. I have no idea if it's an intended change or an accidental side effect. Copying the libvorbis maintainers, could you please comment on that? It looks like the raw_total() method in Decoder.xs just calls ov_raw_total() with i==-1. The test file is data/test.ogg in the libogg-vorbis-decoder-perl source package, and I see the expected value 4418594 is also the full size of the file. -- Niko Tyni nt...@debian.org
Bug#801499: libgit-repository-perl: FTBFS: t/24-errors.t broken by newer versions of git
Package: libgit-repository-perl
Version: 1.315-1
Severity: serious
Tags: upstream patch
User: debian-p...@lists.debian.org
Usertags: autopkgtest
Forwarded: https://rt.cpan.org/Ticket/Display.html?id=107219
This package fails to build on current sid/amd64:
# Failed test 'log -1: died'
# at t/24-errors.t line 204.
# 'fatal: your current branch 'master' does not have any
commits yet at t/24-errors.t line 203.
# '
# doesn't match '(?^:^fatal: bad default revision 'HEAD' )'
# Looks like you failed 1 test of 65.
t/24-errors.t ..
1..65
not ok 1 - log -1: died
[...]
Test Summary Report
---
t/24-errors.t(Wstat: 256 Tests: 65 Failed: 1)
Failed test: 1
Non-zero exit status: 1
This apparently broke with the git upgrade from 2.5.1-1 to 2.5.3-1. Quoting
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.5.2.txt
* "git init empty && git -C empty log" said "bad default revision 'HEAD'",
which was found to be a bit confusing to new users.
This is also [rt.cpan.org #107219], which has the attached patch
by Petr Šabata.
--
Niko Tyni nt...@debian.org
>From 05f7008aa3ae32c8556e7907c65d9d16bebaabd9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= <con...@redhat.com>
Date: Mon, 21 Sep 2015 16:47:51 +0200
Subject: [PATCH] git-2.5.2 test suite compatibility fix
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The latest version of git altered the error message `git log -1' prints
on empty repositories. This patch extends the test to deal with this
situation.
Signed-off-by: Petr Šabata <con...@redhat.com>
---
t/24-errors.t | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/24-errors.t b/t/24-errors.t
index 7d7f2ee..aeb2c58 100644
--- a/t/24-errors.t
+++ b/t/24-errors.t
@@ -56,7 +56,7 @@ my @tests = (
{ test_repo => [],
cmd => [qw( log -1 )],
exit => 128,
-dollar_at => qr/^fatal: bad default revision 'HEAD' /,
+dollar_at => qr/^fatal: (?:bad default revision 'HEAD' |your current branch 'master' does not have any commits yet)/,
},
# create the empty tree
--
2.4.3
Bug#789739: libdevel-ebug-perl: FTBFS in sid: test failures
Control: retitle -1 libdevel-ebug-perl: FTBFS in sid: test failures On Tue, Aug 11, 2015 at 08:48:20PM +0200, gregor herrmann wrote: > On Wed, 24 Jun 2015 00:59:37 +0100, Dominic Hargreaves wrote: > > > Source: libdevel-ebug-perl > > Version: 0.56-1 > > Severity: serious > > Justification: FTBFS > > > > This package FTBFS in a clean sid sbuild setup: > https://reproducible.debian.net/rbuild/unstable/amd64/libdevel-ebug-perl_0.56-1.rbuild.log > > JFTR: > At the moment it fails for me with: > Test Summary Report > --- > t/stack.t (Wstat: 1792 Tests: 29 Failed: 7) > Failed tests: 12, 14-15, 19, 27-29 > Non-zero exit status: 7 This stack.t failure is a different issue from the original ebug.t one. It was probably caused by libdevel-stacktrace-perl 2.-1. AFAICS the test is just hardcoding Devel::StackTrace output so it would probably be enough to just update it to correspond to the new version. This is https://rt.cpan.org/Ticket/Display.html?id=100615 FWIW. Not sure if it's worth having two bugs, retitling this for now. The silence upstream suggests this module might be abandoned? -- Niko Tyni nt...@debian.org
