Bug#903300: libbusiness-onlinepayment-ippay-perl: probably needs a dependency on liblocale-codes-perl

[Niko Tyni]

Package: libbusiness-onlinepayment-ippay-perl
Version: 0.09-1
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

It looks like this package uses Locale::Country, part of Locale-Codes
which is being removed from the Perl core. Please add dependencies on
liblocale-codes-perl if appropriate or just close this bug otherwise.

  libbusiness-onlinepayment-ippay-perl-0.09/IPPay.pm:use Locale::Country;

-- 
Niko Tyni   nt...@debian.org

Bug#903298: gcstar: probably needs a dependency on liblocale-codes-perl

[Niko Tyni]

Package: gcstar
Version: 1.7.1+repack-1
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

It looks like this package uses Locale::Country, part of Locale-Codes
which is being removed from the Perl core. Please add dependencies on
liblocale-codes-perl if appropriate or just close this bug otherwise.

  gcstar-1.7.1+repack/lib/gcstar/GCPlugins/GCmusics/GCMusicBrainz.pm:use 
Locale::Country;

-- 
Niko Tyni   nt...@debian.org

Bug#903297: libdatetime-timezone-perl: probably needs a dependency on liblocale-codes-perl

[Niko Tyni]

Package: libdatetime-timezone-perl
Version: 1:2.19-1+2018e
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

It looks like this package uses Locale::Country, part of Locale-Codes
which is being removed from the Perl core. Please add dependencies on
liblocale-codes-perl if appropriate or just close this bug otherwise.

  libdatetime-timezone-perl-2.19/tools/parse_olson:use Locale::Country 3.11 qw( 
code2country );

-- 
Niko Tyni   nt...@debian.org

Bug#903296: libhtml-microformats-perl: probably needs a dependency on liblocale-codes-perl

[Niko Tyni]

Package: libhtml-microformats-perl
Version: 0.105-4
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

It looks like this package uses Locale::Country, part of Locale-Codes
which is being removed from the Perl core. Please add dependencies on
liblocale-codes-perl if appropriate or just close this bug otherwise.

  libhtml-microformats-perl-0.105/lib/HTML/Microformats/Format/adr.pm:use 
Locale::Country qw(country2code LOCALE_CODE_ALPHA_2);
  libhtml-microformats-perl-0.105/lib/HTML/Microformats/Format/figure.pm:use 
Locale::Country qw(country2code LOCALE_CODE_ALPHA_2);

-- 
Niko Tyni   nt...@debian.org

Bug#903294: libbio-asn1-entrezgene-perl: Unescaped left brace in regex is deprecated

[Niko Tyni]

Package: libbio-asn1-entrezgene-perl
Version: 1.720-1
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition autopkgtest

This package fails its autopkgtest checks with Perl 5.28
(currently in experimental.)

  #   Failed test ' /usr/bin/perl -w -M"Bio::ASN1::EntrezGene" -e 1 2>&1 
produced no (non-whitelisted) output'
  #   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 108.
  #   Failed test 'env PERL_DL_NONLAZY=1  /usr/bin/perl -w 
-M"Bio::ASN1::EntrezGene" -e 1 2>&1 produced no (non-whi
  telisted) output'
  #   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 108.
  # Looks like you failed 2 tests of 4.
  /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t .. 
  1..4
  # Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
5.32), passed through in regex; mar
  ked by <-- HERE in m/^\s*Entrezgene(-Set)? ::= ({ <-- HERE .*)/ at 
/usr/share/perl5/Bio/ASN1/EntrezGene.pm line 9
  1.
  ok 1 -  /usr/bin/perl -w -M"Bio::ASN1::EntrezGene" -e 1 2>&1 exited 
successfully
  not ok 2 -  /usr/bin/perl -w -M"Bio::ASN1::EntrezGene" -e 1 2>&1 produced no 
(non-whitelisted) output
  # Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
5.32), passed through in regex; mar
  ked by <-- HERE in m/^\s*Entrezgene(-Set)? ::= ({ <-- HERE .*)/ at 
/usr/share/perl5/Bio/ASN1/EntrezGene.pm line 9
  1.
  ok 3 - env PERL_DL_NONLAZY=1  /usr/bin/perl -w -M"Bio::ASN1::EntrezGene" -e 1 
2>&1 exited successfully
  not ok 4 - env PERL_DL_NONLAZY=1  /usr/bin/perl -w -M"Bio::ASN1::EntrezGene" 
-e 1 2>&1 produced no (non-whitelist
  ed) output
  Dubious, test returned 2 (wstat 512, 0x200)
  Failed 2/4 subtests 
  
-- 
Niko Tyni   nt...@debian.org

Bug#903278: w3c-linkchecker: probably needs a dependency on liblocale-codes-perl

[Niko Tyni]

On Sun, Jul 08, 2018 at 03:38:39PM +0200, gregor herrmann wrote:
> On Sun, 08 Jul 2018 15:21:59 +0300, Niko Tyni wrote:
> 
> > It looks like this package uses Locale::Language, part of Locale-Codes
> > which is being removed from the Perl core. Please add dependencies on
> > liblocale-codes-perl if appropriate or just close this bug otherwise.
> 
> Just curious:
> Locale::Language seems to be shipped with 5.28.0 and is in 5.29.0
> (according to corelist), and is also not mentioned in
> https://metacpan.org/pod/distribution/perl/pod/perldeprecation.pod or
> https://perl5.git.perl.org/perl.git/blob/HEAD:/pod/perldeprecation.pod
> 
> Is there another source of information that explains when Locale::Language
> will be removed from core?

Looks like it's only in perldelta.pod. Removal seems to be targeted for 5.30.

  https://metacpan.org/pod/distribution/perl/pod/perldelta.pod#Module-removals

  
https://metacpan.org/pod/distribution/perl/pod/perldelta.pod#Updated-Modules-and-Pragmata

Using these modules issues a deprecation warning in 5.28, and I'd expect
them to get eject soon in the 5.29 series.
-- 
Niko Tyni   nt...@debian.org

Bug#903280: libapp-cache-perl: autopkgtest checks write to $HOME

[Niko Tyni]

Package: libapp-cache-perl
Version: 0.37-2

The autopkgtest checks of this package fail is $HOME
is not set or writable.

  t/simple.t .. 
  1..45
  ok 1 - use App::Cache;
  ok 2 - use App::Cache::Test;
  mkdir /.app_cache_test: Permission denied at /usr/share/perl5/App/Cache.pm 
line 32.
  # Looks like your test exited with 13 just after 2.
  Dubious, test returned 13 (wstat 3328, 0xd00)
  Failed 43/45 subtests 
  
  Test Summary Report
  ---
  t/simple.t (Wstat: 3328 Tests: 2 Failed: 0)
Non-zero exit status: 13
Parse errors: Bad plan.  You planned 45 tests but ran 2.
  Files=1, Tests=2,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.06 cusr  0.02 
csys =  0.10 CPU)
  Result: FAIL

-- 
Niko Tyni   nt...@debian.org

Bug#903277: qgis: probably needs a dependency on liblocale-codes-perl

[Niko Tyni]

Package: qgis
Version: 2.18.21+dfsg-2
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

It looks like this package uses Locale::Language, part of Locale-Codes
which is being removed from the Perl core. Please add dependencies on
liblocale-codes-perl if appropriate or just close this bug otherwise.

  qgis-2.18.21+dfsg/scripts/tsstat.pl:use Locale::Language;

-- 
Niko Tyni   nt...@debian.org

Bug#903278: w3c-linkchecker: probably needs a dependency on liblocale-codes-perl

[Niko Tyni]

Package: w3c-linkchecker
Version: 4.81-9
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

It looks like this package uses Locale::Language, part of Locale-Codes
which is being removed from the Perl core. Please add dependencies on
liblocale-codes-perl if appropriate or just close this bug otherwise.

  w3c-linkchecker-4.81/bin/checklink:require Locale::Language;   

-- 
Niko Tyni   nt...@debian.org

Bug#903275: makehuman: probably needs a dependency on liblocale-codes-perl

[Niko Tyni]

Package: makehuman
Version: 1.1.1-1
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

It looks like this package uses Locale::Language, part of Locale-Codes
which is being removed from the Perl core. Please add dependencies on
liblocale-codes-perl if appropriate or just close this bug otherwise.

  makehuman-1.1.1/buildscripts/translation-staging/update.pl:use 
Locale::Language;

-- 
Niko Tyni   nt...@debian.org

Bug#903276: publican: probably needs a dependency on liblocale-codes-perl

[Niko Tyni]

Package: publican
Version: 4.3.2-2
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

It looks like this package uses Locale::Language, part of Locale-Codes
which is being removed from the Perl core. Please add dependencies on
liblocale-codes-perl if appropriate or just close this bug otherwise.

  publican-4.3.2/lib/Publican/Builder.pm:use Locale::Language;
  publican-4.3.2/lib/Publican/Builder/DocBook5.pm:use Locale::Language;
  publican-4.3.2/lib/Publican/Builder/DocBook4.pm:use Locale::Language;
  publican-4.3.2/lib/Publican/Builder/DocBook.pm:use Locale::Language;
  publican-4.3.2/lib/Publican/WebSite.pm:use Locale::Language;

-- 
Niko Tyni   nt...@debian.org

Bug#903274: rtpg: probably needs a dependency on liblocale-codes-perl

[Niko Tyni]

Package: rtpg
Version: 0.2.11-3
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

It looks like this package uses Locale::Language, part of Locale-Codes
which is being removed from the Perl core. Please add dependencies on
liblocale-codes-perl if appropriate or just close this bug otherwise.

  rtpg-0.2.11/lib/RTPG/WWW/Locale.pm:use Locale::Language;

-- 
Niko Tyni   nt...@debian.org

Bug#903272: dl10n: probably needs a dependency on liblocale-codes-perl

[Niko Tyni]

Package: dl10n
Version: 3.00
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

It looks like this package uses Locale::Language, part of Locale-Codes
which is being removed from the Perl core. Please add dependencies on
liblocale-codes-perl if appropriate or just close this bug otherwise.

 dl10n-3.00/dl10n-check:use Locale::Language;

-- 
Niko Tyni   nt...@debian.org

Bug#903273: ledgersmb: probably needs a dependency on liblocale-codes-perl

[Niko Tyni]

Package: ledgersmb
Version: 1.4.42+ds-2
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

It looks like this package uses Locale::Language, part of Locale-Codes
which is being removed from the Perl core. Please add dependencies on
liblocale-codes-perl if appropriate or just close this bug otherwise.

 ledgersmb-1.4.42+ds/LedgerSMB/DBObject/User.pm:use Locale::Language;
 ledgersmb-1.4.42+ds/tools/generate-language-table-contents.pl:use 
Locale::Language;

-- 
Niko Tyni   nt...@debian.org

Bug#903271: libdist-zilla-localetextdomain-perl: needs a dependency on liblocale-codes-perl

[Niko Tyni]

Package: libdist-zilla-localetextdomain-perl
Version: 0.91-2
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

It looks like this package uses Locale::Language, part of Locale-Codes
which is being removed from the Perl core. Please add dependencies on
liblocale-codes-perl if appropriate or just close this bug otherwise.

 lib/Dist/Zilla/App/Command/msg_init.pm:require Locale::Language;

-- 
Niko Tyni   nt...@debian.org

Bug#903268: hugin: autopkgtest checks write to $HOME and don't clean themselves

[Niko Tyni]

Package: hugin
Version: 2018.0.0+dfsg-1

The autopkgtest checks of this package write to $HOME, and fail if that
is not writable. They don't clean after themselves properly but leave
~/.hugindata/camlens.db around.
-- 
Niko Tyni   nt...@debian.org

Bug#903259: libdatetime-locale-perl: not built from source

[Niko Tyni]

Package: libdatetime-locale-perl
Version: 1:1.22-1

The code and documentation in this package is not built from source
in Debian. We're using upstream pregenerated files and not shipping
their sources.

It looks like tools/generate-modules needs Path-Tiny-Rule
from CPAN and lots of source data, see

 https://github.com/houseabsolute/DateTime-Locale/tree/master/.gitmodules

Also

 
https://github.com/houseabsolute/DateTime-Locale/tree/master/source-data/glibc-locales

is presumably copied from the glibc sources.

There's a unicode-cldr-core package in Debian but the rest probably
need to be packaged?

I was able to regenerate almost everything in share/ and
lib/DateTime/Locale/ bit-by-bit using the above sources, so things are
not quite hopeless.

This should probably be serious but it's also very long-standing.
I'll punt on that for now.
-- 
Niko Tyni   nt...@debian.org

Bug#903254: auto-multiple-choice: needs a dependency on liblocale-codes-perl core

[Niko Tyni]

Package: auto-multiple-choices
Version: 1.3.0-5
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

While checking autopkgtest results of packages against Perl 5.28
(currently in experimental), we noticed a regression with this package.

 simple   PASS
 gui  FAIL non-zero exit status 2

This seems to be due to these new stderr warnings:

  Locale::Language will be removed from the Perl core distribution in the next 
major release. Please install it from CPAN. It is being used at 
/usr/lib/AMC/perl/AMC-gui.pl, line 43.
  Locale::Codes will be removed from the Perl core distribution in the next 
major release. Please install the separate liblocale-codes-perl package. It is 
being used at /usr/share/perl/5.28/Locale/Language.pm, line 22.

It looks like this package uses Locale::Language, part of Locale::Codes
which is moving away from the Perl core distribution. It is now separately
packaged as liblocale-codes-perl. Please declare a dependency on that
-- 
Niko Tyni   nt...@debian.org

Bug#902779: perl-debug: XS code built for perl doesn't work with debugperl

[Niko Tyni]

Control: unblock 902557 with -1

On Mon, Jul 02, 2018 at 09:57:26PM +0300, Niko Tyni wrote:
> On Sat, Jun 30, 2018 at 10:06:34PM +0300, Niko Tyni wrote:
> > Package: perl-debug
> > Version: 5.28.0-1
> > Severity: normal
> > User: debian-p...@lists.debian.org
> > Usertags: perl-5.28-transition
> > 
> > I noticed that many of our XS module packages are incompatible
> > with debugperl after being rebuilt for 5.28. Consider:

> I see two obvious avenues for fixing this:
> 
> A) move the -DDEBUGGING check in EXTEND to run time, for instance by
>calling a function that's a no-op in non-DEBUGGING interpreters. This
>has a runtime cost, but I'm not sure how significant. We need to ask
>upstream.

Upstream says runtime costs for non-DEBUGGING builds are unacceptable.

> B) disable the check on the DEBUGGING side altogether. There's currently
>no facility to do this short of patching the code.

So we need to do this. Should be just a matter of #ifdef'ing out the
two places where the 'failed to extend arg stack' panic is triggered.

I don't see a compelling need to patch away all the hwm handling -
it does slow down debugperl a bit but that's not a concern I think.

> If A) is judged adequate upstream, we should do that before the 5.28 >
transition so that we don't have to rebuild all the XS modules afterwards.
> I'm therefore marking this as a transition blocker for now.

Since we're taking B), it doesn't matter if it's done before or after
the transition: the change only affects the debugperl side and not the
XS modules. I'm therefore removing the blocker mark.

Longer term, it looks possible that we can't keep debugperl able to load
non-DEBUGGING XS modules. Such a combination isn't properly supported
or tested upstream. I'm not sure how much of a concern this really is
for our users, and how hard we should try.
-- 
Niko

Bug#903245: pgbackrest: FTBFS everywhere: keys at index 8 do not match

[Niko Tyni]

Package: pgbackrest
Version: 2.04-1
Severity: serious

This package failed to build on all buildds.

  https://buildd.debian.org/status/package.php?p=pgbackrest=unstable

>From one of the logs:

  2018-07-06 15:05:20.977 P00  ERROR: [028]: keys at index 8 do not match, 
cache is invalid.
  cache key: 
{"bash-wrap":true,"cmd":["adduser --disabled-password --gecos \"\" 
vagrant"],"host":"build","load-env":true,"output":false,"run-as-user":"root"}
  current key: 
{"bash-wrap":true,"cmd":["adduser --disabled-password --gecos \"\" 
buildd"],"host":"build","load-env":true,"output":false,"run-as-user":"root"}
  2018-07-06 15:05:20.981 P00  ERROR: [125]: Cache reset disabled by 
--cache-only option
  debian/rules:15: recipe for target 'override_dh_auto_build' failed
  make[1]: *** [override_dh_auto_build] Error 125
 
-- 
Niko Tyni   nt...@debian.org

Bug#903000: autopkgtest: regression on arch-specific packages with '@' in their test dependencies

[Niko Tyni]

Package: autopkgtest
Version: 5.4 
Severity: important

As seen in at least

 https://ci.debian.net/data/autopkgtest/testing/amd64/n/nftables/556352/log.gz

autopkgtest has regressed for packages that are not Architecture: all or
Architecture: any and have '@' in their test dependencies.

This seems to be due to

 
https://salsa.debian.org/ci-team/autopkgtest/commit/7cc976b02a881e5f2a43945fde87d8b8679ff442

which results in an erroneous 'apt-get install package [linux-any]' call.

The code in  _debian_packages_from_source() adds an architecture qualifier
for non-{any,all} packages, so it's not suitable for feeding to 'apt-get
install' as-is.

Fixes / workarounds we've discussed with Paul include

- parse the architecture list, pass the package to 'apt-get install'
  (without the arch qualifier) if and only we're on a matching
  architecture. (The matching check can be done with dpkg-architecture(1)
  but still leaves parsing the specification.)

- don't try to 'apt-get install' non-{any,all} packages; this can result
  in a Provided package satisfying the dependency so the semantics of '@'
  are not guaranteed

- as above, but mitigate the risk of a Provided package satisfying the 
dependency
  by limiting it only to versioned Provides. This could be done by reverting

   
https://salsa.debian.org/ci-team/autopkgtest/commit/9199bbd3dc4ce845f6739dfebee264111c09fdad

-- 
Niko Tyni   nt...@debian.org

Bug#901082: libpgobject-type-json-perl: FTBFS with Perl 5.28: t/02-serialization.t failure

[Niko Tyni]

On Sun, Jun 10, 2018 at 12:36:09AM +0300, Niko Tyni wrote:

> This bisects to
>   
> https://github.com/makamaka/JSON-PP/commit/87bd6a49bacc3a2634cbb1dd0ce9cc75675bb524
> and I've filed
>   https://github.com/makamaka/JSON-PP/issues/39
> about it.
> 
> Not sure yet if it's a bug or if others need to adapt.

Upstream(s) are somewhat quiet, so just noting that this can be worked
around with a build dependency on libjson-xs-perl if there's no better
fix.

For runtime, maybe a Recommends entry would be appropriate?
-- 
Niko Tyni   nt...@debian.org

Bug#758100: versioned Provides reverted in src:perl for now

[Niko Tyni]

On Sun, Jul 09, 2017 at 08:27:57PM +0300, Niko Tyni wrote:
 
> I have reverted the versioned Provides in src:perl for now because
> wanna-build is leaving some packages in B-D-Uninstallable (#867104)
> due to no fault of their own.
> 
> The versioned Provides were introduced in sid with perl_5.24.1-5 a week
> ago, and in the meantime a separate issue (that we could probably have
> lived with for a bit longer at least) was found in autopkgtest and is
> tracked as #867081.

These bugs are now fixed (and deployed on the Debian infrastructure),
so we could try again.

I think I want to do the 5.28 transition first, though. There should
still be ample time before buster freezes.
-- 
Niko

Bug#902925: perl: in-place edit regression in 5.28: exhausts open file descriptor limit

[Niko Tyni]

Package: perl
Version: 5.28.0-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition
Forwarded: https://rt.perl.org/Ticket/Display.html?id=133314

As reported in the upstream bug by Mike Miller:

  The in-place editing feature in perl 5.28 dies with an error if called
  with 1020 or more files on the command line. This is a regression from
  5.26, which was able to operate on any number of files on its command
  line.

I've confirmed this with our 5.28 packages (though the exact limit
depends on the number of available file descriptors.)

There's a patch in the upstream ticket that we could use.
-- 
Niko Tyni   nt...@debian.org

Bug#902779: perl-debug: XS code built for perl doesn't work with debugperl

[Niko Tyni]

Control: block 902557 with -1

On Sat, Jun 30, 2018 at 10:06:34PM +0300, Niko Tyni wrote:
> Package: perl-debug
> Version: 5.28.0-1
> Severity: normal
> User: debian-p...@lists.debian.org
> Usertags: perl-5.28-transition
> 
> I noticed that many of our XS module packages are incompatible
> with debugperl after being rebuilt for 5.28. Consider:
> 
>  # debugperl -MDateTime -e 'print DateTime->today'
>  panic: XSUB DateTime::_rd2ymd (DateTime.c) failed to extend arg stack: 
> base=55b63e6b3b48, sp=55b63e6b3b80, hwm=55b63e6b3b68
> 
> This panic is due to a new -DDEBUGGING check that guards the XS function
> argument stack, making sure that XS code extends the stack properly when
> it pushes elements there.
> 
> However, I believe the check isn't currently working properly when
> the XS code is built with a non-DDEBUGGING perl.h and then run with a
> -DDEBUGGING perl build.

So, I see the EXTEND macro in pp.h is instrumented to make a note of
how far the stack is supposed to extend, and this 'high-water mark'
(hwm) is compared to the stack pointer after calling an XSUB. If the
XSUB has pushed more elements than it declared with EXTEND (or didn't
call EXTEND at all), the above panic will result.

The problem is that EXTEND only updates the high-water mark when the
DEBUGGING preprocessor symbol is defined (i.e. the choice is done at
compile time.) If the XS module is built without -DDEBUGGING in ccflags
(as is the case for Debian XS module packages), the high-water mark
doesn't get updated.  If the interpreter side is built with -DDEBUGGING
(as our debugperl is), it will still check the hwm.

I see two obvious avenues for fixing this:

A) move the -DDEBUGGING check in EXTEND to run time, for instance by
   calling a function that's a no-op in non-DEBUGGING interpreters. This
   has a runtime cost, but I'm not sure how significant. We need to ask
   upstream.

B) disable the check on the DEBUGGING side altogether. There's currently
   no facility to do this short of patching the code.

If A) is judged adequate upstream, we should do that before the 5.28
transition so that we don't have to rebuild all the XS modules afterwards.
I'm therefore marking this as a transition blocker for now.

Otherwise we need to do B) and lose some useful debugging checks.
-- 
Niko Tyni   nt...@debian.org

Bug#902779: perl-debug: XS code built for perl doesn't work with debugperl

[Niko Tyni]

Package: perl-debug
Version: 5.28.0-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

I noticed that many of our XS module packages are incompatible
with debugperl after being rebuilt for 5.28. Consider:

 # debugperl -MDateTime -e 'print DateTime->today'
 panic: XSUB DateTime::_rd2ymd (DateTime.c) failed to extend arg stack: 
base=55b63e6b3b48, sp=55b63e6b3b80, hwm=55b63e6b3b68

 # printf '\n\n\n' | debugperl 
-MXML::LibXML -e 
'XML::LibXML->new->parse_fh(*STDIN)->documentElement->childNodes; '
 panic: XSUB XML::LibXML::Node::_childNodes (LibXML.c) failed to extend arg 
stack: base=561827c61b48, sp=561827c61b68, hwm=561827c61b60

This panic is due to a new -DDEBUGGING check that guards the XS function
argument stack, making sure that XS code extends the stack properly when
it pushes elements there.

However, I believe the check isn't currently working properly when
the XS code is built with a non-DDEBUGGING perl.h and then run with a
-DDEBUGGING perl build.

Will take this upstream once I've investigated it properly.
-- 
Niko Tyni   nt...@debian.org

Bug#902772: texinfo: missing debug symbols and DEB_BUILD_OPTIONS support for Perl XS code

[Niko Tyni]

Package: texinfo
Version: 6.5.0.dfsg.1-3
Severity: minor

Dear maintainer,

I noticed that the Perl XS code in this package gets built without
debugging symbols, so they are not in the -dbgsym package. Furthermore,
the XS build doesn't honor DEB_BUILD_OPTIONS=noopt. These glitches make
debugging unnecessarily hard.

Snippet from a build log, note that the default '-g -O2' are missing.

  make[6]: Entering directory '/<>/tp/Texinfo/Convert/XSParagraph'
  /usr/bin/xsubpp -typemap /usr/share/perl/5.26/ExtUtils/typemap XSParagraph.xs 
> XSParagraph.xsc && mv XSParagraph.xsc XSParagraph.c
  /bin/bash ./libtool  --tag=CC   --mode=compile aarch64-linux-gnu-gcc 
-DHAVE_CONFIG_H -I.  -I. -I./lib -I./lib  -D_REENTRANT -D_GNU_SOURCE -DDEBIAN 
-fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -DVERSION=\"0\" -DXS_VERSION=\"1\" 
"-I/usr/lib/aarch64-linux-gnu/perl/5.26/CORE"  -MT 
XSParagraph_la-XSParagraph.lo -MD -MP -MF .deps/XSParagraph_la-XSParagraph.Tpo 
-c -o XSParagraph_la-XSParagraph.lo `test -f 'XSParagraph.c' || echo 
'./'`XSParagraph.c
  libtool: compile:  aarch64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I./lib 
-I./lib -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe 
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DVERSION=\"0\" 
-DXS_VERSION=\"1\" -I/usr/lib/aarch64-linux-gnu/perl/5.26/CORE -MT 
XSParagraph_la-XSParagraph.lo -MD -MP -MF .deps/XSParagraph_la-XSParagraph.Tpo 
-c XSParagraph.c  -fPIC -DPIC -o .libs/XSParagraph_la-XSParagraph.o
  libtool: compile:  aarch64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I./lib 
-I./lib -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe 
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DVERSION=\"0\" 
-DXS_VERSION=\"1\" -I/usr/lib/aarch64-linux-gnu/perl/5.26/CORE -MT 
XSParagraph_la-XSParagraph.lo -MD -MP -MF .deps/XSParagraph_la-XSParagraph.Tpo 
-c XSParagraph.c -o XSParagraph_la-XSParagraph.o >/dev/null 2>&1

-- 
Niko Tyni   nt...@debian.org

Bug#902771: texinfo: makeinfo busy looping with Perl 5.28 due to locale handling

[Niko Tyni]

Package: texinfo
Version: 6.5.0.dfsg.1-3
Severity: important
Tags: patch
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition
Control: block 902557 with -1

Dear maintainer,

we noticed in our Perl 5.28 test rebuilds that the build of notmuch
would hang. Investigation showed that makeinfo goes in a busy loop
for certain documents, and I was able to reduce a test case to just
these two lines:

  @documentencoding UTF-8
  @indicateurl{foo}

The hang only happens when makeinfo is run in a non-UTF8 locale.

This is discussed upstream at

 http://lists.gnu.org/archive/html/bug-texinfo/2018-06/msg00029.html

and I've just sent the attached proposed patch there as well.
-- 
Niko Tyni   nt...@debian.org
>From 9031aefb7f180f718db83aec5e2782079455a32f Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sat, 30 Jun 2018 16:51:13 +0100
Subject: [PATCH] Update locale handling for Perl 5.28

Perl 5.28 introduced thread-safe locales, where setlocale()
only affects the locale of the current thread. External code
like mbrtowc(3) isn't aware of this thread specific locale,
so we need to explicitly modify the global one instead.

Without this we could enter a busy loop in xspara__add_next()
(Texinfo::Convert::XSParagraph) for UTF-8 documents when mbrtowc(3)
returned -1.
---
 tp/Texinfo/Convert/XSParagraph/xspara.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tp/Texinfo/Convert/XSParagraph/xspara.c b/tp/Texinfo/Convert/XSParagraph/xspara.c
index 51eea4a..f2d6d1c 100644
--- a/tp/Texinfo/Convert/XSParagraph/xspara.c
+++ b/tp/Texinfo/Convert/XSParagraph/xspara.c
@@ -248,6 +248,11 @@ xspara_init (void)
 
   dTHX;
 
+#if PERL_VERSION > 27 || (PERL_VERSION == 27 && PERL_SUBVERSION > 8)
+  /* needed due to thread-safe locale handling in newer perls */
+  switch_to_global_locale();
+#endif
+
   if (setlocale (LC_CTYPE, "en_US.UTF-8")
   || setlocale (LC_CTYPE, "en_US.utf8"))
 goto success;
@@ -320,6 +325,10 @@ failure:
 {
 success: ;
   free (utf8_locale);
+#if PERL_VERSION > 27 || (PERL_VERSION == 27 && PERL_SUBVERSION > 8)
+  /* needed due to thread-safe locale handling in newer perls */
+  sync_locale();
+#endif
   /*
   fprintf (stderr, "tried to set LC_CTYPE to UTF-8.\n");
   fprintf (stderr, "character encoding is: %s\n",
-- 
2.17.0

Bug#901085: libur-perl: FTBFS with Perl 5.28: test failures

[Niko Tyni]

Control: clone -1 -2
Control: retitle -1 libur-perl: FTBFS with Perl 5.28: t/URT/t/41_rpc_* failures
Control: retitle -2 libur-perl: FTBFS with newer versions of JSON::PP: 
t/URT/t/63c_view_with_subviews.t failure
Control: forwarded -1 https://github.com/genome/UR/issues/136
Control: forwarded -2 https://github.com/genome/UR/issues/142

On Sat, Jun 09, 2018 at 10:16:40AM +0300, Niko Tyni wrote:
> On Fri, Jun 08, 2018 at 10:30:07PM +0300, Niko Tyni wrote:
> > On Fri, Jun 08, 2018 at 10:18:49PM +0300, Niko Tyni wrote:
> > > Source: libur-perl
> > > Version: 0.450-1
> > > Severity: important
> > > User: debian-p...@lists.debian.org
> > > Usertags: perl-5.28-transition
> 
> > >   #   Failed test 'content matches!'
> > >   #   at t/URT/t/63c_view_with_subviews.t line 151.
> 
> > This looks similar to #901082 and doesn't seem to show in the CPAN
> > test reports. I wonder what's different for us.
> 
> They are indeed the same issue, specific to newer versions of
> JSON::PP. I've verified that it also happens with Perl 5.26 and
> libjson-pp-perl 2.97001-1.

I'm cloning a separate bug about this as it's not 5.28 specific.
I've forwarded it upstream as well.
-- 
Niko Tyni   nt...@debian.org

Bug#900832: libdbd-csv-perl: FTBFS with Perl 5.28: t/82_free_unref_scalar.t failure

[Niko Tyni]

Control: reassign -1 libtext-csv-xs-perl 1.35-1
Control: close -1 1.36-1

On Wed, Jun 27, 2018 at 10:26:05PM +0200, gregor herrmann wrote:
> On Wed, 27 Jun 2018 22:41:35 +0300, Niko Tyni wrote:
> 
> > We should probably update libtext-csv-xs-perl and see if that
> > is enough to resolve the libdbd-csv-perl build issues.
> 
> libtext-csv-xs-perl 1.36-1 uploaded.
> Let's see how that goes :)

Thanks. Looks good, I can't reproduce the libdbd-csv-perl failure anymore
with this. Reassigning and closing.
-- 
Niko Tyni   nt...@debian.org

Bug#902655: auto-multiple-choice: Build-Depends on pdftk which is uninstallable

[Niko Tyni]

Source: auto-multiple-choice
Version: 1.3.0-5 
Severity: serious

This package Build-Depends on pdftk, which has been uninstallable in
unstable and gone from testing for a couple of months now due to #892539.
-- 
Niko Tyni   nt...@debian.org

Bug#629405: debconf: libqtgui4-perl based frontend might need to be removed

[Niko Tyni]

Control: severity -1 serious
Control: block 902557 with -1

On Thu, Jun 30, 2011 at 02:11:47AM +0300, Modestas Vainius wrote:
> severity 629405 wishlist
> retitle 629405 libqtgui4-perl based frontend might need to be removed
> thanks

> let's delay this for now. When there is a need (if qt4-perl fails to survive) 
> or decision to remove this frontend, I will get back to you with the patch. 
> As 
> long as debconf-kde-helper based one is introduced (#631769) and working 
> well, 
> removal of this one won't be a loss at all.

Seven years later it looks like qt4-perl is finally dying, see #887687.

As libqtgui4-perl can't be rebuilt for Perl 5.28 in its current state
and is not going to be fixed, removal of this debconf frontend has become
a blocker for the Perl 5.28 transition and needs to be done in any case
before buster releases. Updating the bug metadata accordingly.

Colin and others: please let us know if you have better ideas or if we
can help in any way.
-- 
Niko Tyni   nt...@debian.org

Bug#887687: libsmokeqt4-dev: broken symlinks and causes qt4-perl FTBFS

[Niko Tyni]

On Fri, Jun 29, 2018 at 12:55:50AM +, Scott Kitterman wrote:
> I had hoped to work on this this week.  It hasn't happened and it's not going 
> to.
> 
> In the end, I the Qt4 stuff has to go, so I wouldn't wait on this for the 
> transition.

Okay, thanks. The problem is that we can't really get Perl 5.28 into
testing if that makes debconf fail to build. So something needs to
be done.

I think I'll try to push debconf #629405 ("libqtgui4-perl based frontend
might need to be removed") then.
-- 
Niko Tyni   nt...@debian.org

Bug#902625: libmath-gsl-perl: needs a versioned dependency on libgsl23 (>= 2.5) or so

[Niko Tyni]

Package: libmath-gsl-perl
Version: 0.39-2
Severity: serious
Control: block -1 with 902623
User: debian-p...@lists.debian.org
Usertags: autopkgtest

This package uses symbols from libgsl23 >= 2.5, but that isn't
reflected in the package dependencies because of #902623 (libgsl23
missing shlibs information). Once that bug is fixed, libmath-gsl-perl
needs a rebuild so that the package dependencies get updated. A binNMU
should be enough but we might as well make a sourceful one and declare
a build dependency on fixed gsl versions.

(This was noticed by the awesome ci.debian.net autopkgtest migration
 checks, which highlighted that the package is installable but broken
 with the libgsl23 version currently in testing.)

 https://ci.debian.net/packages/libm/libmath-gsl-perl/testing/amd64/
-- 
Niko Tyni   nt...@debian.org

Bug#902623: libgsl23: missing shlibs information for 2.5 symbols

[Niko Tyni]

Package: libgsl23
Version: 2.5+dfsg-3
Severity: serious

The 2.5 versions of this package introduced new symbols, but that isn't
reflected in the shlibs file. It looks like this is caused by a simple
typo: debian/libgsl23.shlib should be named debian/libgsl23.shlibs .
So its contents aren't currently reflected in the binary package.

(This is showing up in the autopkgtest checks of the new libmath-gsl-perl
 package, which was built in sid against the new libgsl23 versions but
 didn't gain a corresponding versioned dependency, so it's installable
 but broken with the old libgsl23 in testing.)
-- 
Niko Tyni   nt...@debian.org

Bug#899021: libembperl-perl: FTBFS with Perl 5.27, unmaintained upstream

[Niko Tyni]

On Wed, Jun 27, 2018 at 10:34:08PM +0200, Axel Beckert wrote:
 
> Perl 5.26:
> 
> → perl -E 'my $i = 0 ; while ($i < 10) { $ii[$i++] = "ii[$i] = $i" ; say 
> $ii[$i-1]; } '
> ii[0] = 0
> ii[1] = 1

[...]
 
> Perl 5.28:
> 
> → perl -E 'my $i = 0 ; while ($i < 10) { $ii[$i++] = "ii[$i] = $i" ; say 
> $ii[$i-1]; } '
> ii[1] = 1
> ii[2] = 2

> I've skimmed through perl5280delta, but haven't noticed anything which
> explains that difference.
> 
> Anyone can enlighten me if this is a perl bug or, if not, which change
> caused this difference?

Seems related to

 https://rt.perl.org/Public/Bug/Display.html?id=133301

so undefined behaviour that happened to change now?
-- 
Niko

Bug#900832: libdbd-csv-perl: FTBFS with Perl 5.28: t/82_free_unref_scalar.t failure

[Niko Tyni]

On Sat, Jun 09, 2018 at 02:56:04PM +0300, Niko Tyni wrote:
> On Tue, Jun 05, 2018 at 07:57:47PM +0300, Niko Tyni wrote:
> > Package: libdbd-csv-perl
> > Version: 0.5300-1
> > Severity: important
> > User: debian-p...@lists.debian.org
> > Usertags: perl-5.28-transition
> > Tags: upstream
> > 
> > This package fails to build with Perl 5.28 (currently in experimental.)
> > 
> >   
> > http://perl.debian.net/rebuild-logs/perl-5.28-throwaway/libdbd-csv-perl_0.5300-1/libdbd-csv-perl_0.5300-1_amd64-2018-06-05T12:44:50Z.build
> > 
> >  #   Failed test 'there was an attempt to free unreferenced scalar'
> >  #   at /usr/share/perl/5.28/Test/Builder.pm line 158.
> >  # Attempt to free unreferenced scalar: SV 0x55afb1de20c0, Perl 
> > interpreter: 0x55afb02b7260 during global destruction.
> 
> >  Test Summary Report
> >  ---
> >  t/82_free_unref_scalar.t (Wstat: 0 Tests: 409 Failed: 4)
> >Failed tests:  406-409
> >Parse errors: Plan (1..405) must be at the beginning or end of the TAP 
> > output
> >  Bad plan.  You planned 405 tests but ran 409.
> >  Files=24, Tests=1158,  4 wallclock secs ( 0.10 usr  0.03 sys +  3.32 cusr  
> > 0.53 csys =  3.98 CPU)
> >  Result: FAIL
> 
> This is now also https://rt.perl.org/Ticket/Display.html?id=133270

... which resulted in

  https://rt.cpan.org/Ticket/Display.html?id=125589 in Text-CSV_XS
   (already fixed on CPAN)

  and

  https://rt.cpan.org/Ticket/Display.html?id=125590 in DBI

We should probably update libtext-csv-xs-perl and see if that
is enough to resolve the libdbd-csv-perl build issues.
-- 
Niko Tyni   nt...@debian.org

Bug#902557: transition: Perl 5.28

[Niko Tyni]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Forwarded: https://release.debian.org/transitions/html/perl5.28.html
X-Debbugs-Cc: p...@packages.debian.org
Control: block -1 with 899021 900832 901080 901082 901085 887687 862678 900232 
902556

Dear release team,

Perl 5.28 is in experimental and we'd like to get it into buster
at some point, so filing this a bit pre-emptively.

We've been doing test rebuilds of all reverse build dependencies of perl
for a while on perl.debian.net, and things are looking pretty good,
with the hairiest issue being #887687 (debconf needs qt4-perl which
doesn't seem to have a bright future at all).

I'm marking this bug as blocked by the handful of 5.28 related regressions
we've spotted, and another handful of unrelated build failures in current
sid that would prevent the necessary binNMUs. I've excluded packages
not in testing, with the exception of libembperl-perl which Axel said
he'll be looking at soon.

We still want to do a full archive test rebuild soonish: as perl-base is
essential and perl is transitively build essential, there are implicit
build dependencies in the archive that we haven't covered yet. I don't
expect much fallout though. I'll update this bug once we have more data.

As usual, bugs are being filed with the usertag
debian-p...@lists.debian.org / perl-5.28-transition . See

 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.28-transition;users=debian-p...@lists.debian.org

Thanks for your work,
-- 
Niko Tyni   nt...@debian.org

Bug#887687: libsmokeqt4-dev: broken symlinks and causes qt4-perl FTBFS

[Niko Tyni]

On Tue, Jun 19, 2018 at 10:05:09AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> El jueves, 14 de junio de 2018 14:45:59 -03 Niko Tyni escribió:
> > On Fri, Jan 19, 2018 at 06:23:25AM +0200, Adrian Bunk wrote:
> > > Package: libsmokeqt4-dev
> > > Version: 4:4.14.3-1.2
> > > Severity: serious
> > > Control: affects -1 src:qt4-perl
> > > 
> > > qt4-perl FTBFS:
> > > 
> > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/qt4-per
> > > l.html
> > > 
> > > /usr/lib/libsmokeqt3support.so and several other .so
> > > links are broken.
> > 
> > Just a note that this is going to be a blocker for Perl 5.28 transition,
> > which is expected to happen in the next few months.
> > 
> > debconf Build-Depends: libqtgui4-perl which is going to need a binNMU for
> > Perl 5.28 but FTBFS because of this bug.
> > 
> > Dear Qt/KDE maintainers: do you think qt4-perl should still be kept alive,
> > or should the support in debconf be finally removed (see #629405) ?
> > I see there's a prospective alternative KDE debconf frontend (#631769)
> > but that seems stalled unfortunately.
> > 
> > Copying the debconf maintainers as well.
> 
> Hi! I have just pinged the rest of the Qt/KDE team for thoughts, as I have 
> never used this myself so I might not have a good view on the issue.
> 
> I'll try to follow up soon, but please ping me again (IRC is valid too) if I 
> don't cam up with a reply in, let's say, 5 to 7 days.

Hi, any news here? FWIW Perl 5.28.0 final was released recently and is
now in experimental. It would be great to get this issue moving forward
one way or another.

Many thanks for your work on Debian,
-- 
Niko Tyni   nt...@debian.org

Bug#902556: libperl-apireference-perl: missing Perl 5.28 support

[Niko Tyni]

Package: libperl-apireference-perl
Version: 0.22-8 
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

This package fails to build with Perl 5.28 (currently in experimental).

  
http://perl.debian.net/rebuild-logs/perl-5.28-throwaway/libperl-apireference-perl_0.22-8/libperl-apireference-perl_0.22-8_amd64-2018-06-08T18:29:44Z.build

  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_028_000.pm
  test -f lib/Perl/APIReference/V`perl -MConfig -we'printf("%d_%03d_%03d.pm", 
$Config{PERL_REVISION}, $Config{PERL_VERSION}, $Config{PERL_SUBVERSION})'`
  make[1]: *** [debian/rules:16: regenerated-stamp] Error 1
  make[1]: Leaving directory '/<>'
  make: *** [debian/rules:4: build] Error 2

-- 
Niko Tyni   nt...@debian.org

Bug#901807: libmath-gsl-perl: incompatible with GSL >= 2.5

[Niko Tyni]

On Wed, Jun 27, 2018 at 05:34:50PM +0200, gregor herrmann wrote:
> On Tue, 26 Jun 2018 10:25:06 +0300, Niko Tyni wrote:

> When I `touch xs/*' before dh_auto_build, indeed re-swig-ification is
> skipped for all files; so on the other hand, touching swig/* should
> make sure that it happens. -- Does this make sense? Committed in git
> and pushed.

Yes, I think that makes sense, though explicitly cleaning xs/* away before
the build would be more clear IMO. But I'm fine with the current solution.

> I'm a bit confused here; the current upload of gsl activates the
> patch which reinstates them but the maintainer sounded like he'd
> prefer to disable the patch again? If I understood this correctly we
> should probably keep our patch, right?

Yes, agreed (even if I was confused myself earlier :)

Dirk mainly wants to get rid of the divergence from upstream, and
upstream is not including the deprecated functions by default. We'll
see if libgsl is going to get an SONAME bump in Debian just for this
(effectively creating another divergence...) or if it will be deferred
to a future upstream SONAME bump.

In any case, if we keep the patch we should be compatible with whatever
happens. And as the deprecated functions are going away at some point,
we shouldn't expose them through the Perl bindings anymore.
 
> And I guess at least if we keep "our" patch, we don't need a
> versioned build dependency?

That's what I think too.
-- 
Niko

Bug#902281: libgsl23: ABI breakage due to removed symbols

[Niko Tyni]

On Tue, Jun 26, 2018 at 08:37:58AM -0500, Dirk Eddelbuettel wrote:
> On 26 June 2018 at 10:12, Niko Tyni wrote:

> | For the record, the Perl GSL bindings package libmath-gsl-perl (can be
> | made to) work without the deprecated symbols too. It just needs a rebuild,
> | and forcing that rebuild (and the associated dependency metadata updates)
> | is the main point of SONAME bumps. 
> | 
> | So please don't feel obliged to carry those symbols forever because of us.
> 
> I like to be similar to upstream, so consider this to be a simple but
> forceful nudge towards that rebuild on your side.

The way to remove symbols from a shared library in Debian (or otherwise
change its ABI in an incompatible way) is to upload a version with SONAME
bumped to experimental, check that reverse dependencies still build,
file bugs if they don't, and when everything is ready enough ask for a
transition slot from the release team. They will then handle the rebuilds.

The libmath-gsl-perl package does need a bit of work to become source
compatible with the removal of the deprecated functions. We're already
handling that in #901807 now that this issue brought it to our attention.

> Do we know if any other packages depending on GSL use these?

codesearch.debian.net does give some hits for at least
gsl_sf_legendre_array_size and gsl_linalg_hessenberg. I didn't check
whether they are false positives.

Test rebuilds with the new library version need to be done anyway and
should pinpoint any such issues.

Hope this helps,
-- 
Niko

Bug#901807: libmath-gsl-perl: incompatible with GSL >= 2.5

[Niko Tyni]

On Tue, Jun 26, 2018 at 10:25:06AM +0300, Niko Tyni wrote:

> It looks like the deprecated symbols will be reinstated for now.
> Not sure if we still want to disable them on our side. Probably not.

The gsl maintainer seems keen to remove those symbols in a (near?) future
SONAME bump. Probably best to disable them now on our side after all so
we can handle any resulting fallout sooner.
-- 
Niko

Bug#901807: libmath-gsl-perl: incompatible with GSL >= 2.5

[Niko Tyni]

On Sun, Jun 24, 2018 at 04:02:06PM +0200, gregor herrmann wrote:

> -my $ver2func = do(catfile(qw/inc ver2func/));
> +my $ver2func = do('./' . catfile(qw/inc ver2func/));

Yeah, that's better than -I. (hardcoding '/' as the directory separator is
a bit ugly but works for us, and I see catfile is rather eager to remove
'./' if it sees it.)

>  sub is_release {
> -return -e '.git' ? 0 : 1;
> +return 0;
>  }

I think I was testing all the time with inside a git checkout,
that probably explains it. Happy if that's enough to trigger
the rebuild. Not sure if it still looks at file mtime stamps
and would need an explicit clean first?

> > The latter one may not turn out to be
> > necessary if the deprecated functions get reinstated with #902281.
> 
> Ack.

It looks like the deprecated symbols will be reinstated for now.
Not sure if we still want to disable them on our side. Probably not.

In any case, I think we should still do a swig rebuild every
time as part of the normal package build.
 
> I've pushed your and my patches, but I'd rather have another
> doublecheck before uploading.

Looks good to me, thanks!
-- 
Niko

Bug#902281: libgsl23: ABI breakage due to removed symbols

[Niko Tyni]

On Mon, Jun 25, 2018 at 06:37:21AM -0500, Dirk Eddelbuettel wrote:
 
> I seem to have confused myself. I have new 2.5-2 packages which should carry
> the deprecated symbols, brought back for our use in the eg the Perl GSL 
> package.
 
Thanks! I can confirm that libmath-gsl-perl works fine again with
libgsl23_2.5+dfsg-2 from experimental. Please upload the fix to unstable
too :)

For the record, the Perl GSL bindings package libmath-gsl-perl (can be
made to) work without the deprecated symbols too. It just needs a rebuild,
and forcing that rebuild (and the associated dependency metadata updates)
is the main point of SONAME bumps. 

So please don't feel obliged to carry those symbols forever because of us.

Any user code compiled against libgsl23 and using those symbols would
of course be similarly affected, and the SONAME bump makes that visible,
which is preferable to silent breakage at runtime.

> You have really helpful on this -- much appreciated.

My pleasure!
-- 
Niko

Bug#899021: libembperl-perl: FTBFS with Perl 5.27, unmaintained upstream

[Niko Tyni]

On Tue, Jun 26, 2018 at 08:23:54AM +0200, gregor herrmann wrote:
> On Tue, 26 Jun 2018 04:24:59 +0200, Axel Beckert wrote:
> 
> > Dominic Hargreaves wrote:
> > > The upstream version of this package has not worked since 5.18, and we
> > > have had to apply several fixes in Debian since. The build has now
> > > broken again with Perl 5.27:
> > > 
> > > http://perl.debian.net/rebuild-logs/perl-5.27-throwaway/libembperl-perl_2.5.0-11/libembperl-perl_2.5.0-11_amd64-2018-05-18T08:09:28Z.build
> > 
> > Is there an APT repo where I can get all the build-dependencies
> > necessary to debug this?
> 
> Yup, at the same server. Details and key at the start page of
> http://perl.debian.net/

Indeed. Alternatively, I believe locally rebuilding

libhtml-parser-perl
libnet-ssleay-perl
libbsd-resource-perl
libapache2-mod-perl2

against 5.28 should suffice.

> gregor, hoping that all build-deps for _this_ package are included
> but so far this has worked flawlessly for me

The system is pretty well automated nowadays (thanks Dom!) and shouldn't
lag behind sid for more than half a day at most.
-- 
Niko

Bug#902281: libgsl23: ABI breakage due to removed symbols

[Niko Tyni]

On Sun, Jun 24, 2018 at 08:38:00AM -0500, Dirk Eddelbuettel wrote:

>   GSL_CURRENT=24
>   GSL_REVISION=0
>   GSL_AGE=1

> I am stumped.  Why does the '24' version not get through?

I think you'd need to reset the age to zero, as explained in the
configure.ac comments and

 
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html

Reading those comments, it looks to me like upstream will never
end up with an SONAME of libgsl.so.24 so you'd be free to use that.

But wouldn't it be smoother to reinstate the deprecated symbols for now,
and remove them at the next upstream SONAME bump or a Debian specific
transition?
-- 
Niko Tyni   nt...@debian.org

Bug#900051: libgnupg-interface-perl: t/get_public_keys.t fails with gnupg2/2.2.7-1

[Niko Tyni]

Control: tag -1 patch

On Wed, Jun 20, 2018 at 11:39:27PM +0300, Niko Tyni wrote:

> There's still the 2.2.8 / --ignore-mdc-error regression to fix.

Here's a patch for adapting the test suite to that one too.

I can't see an easy way to inject --ignore-mdc-error to the
decrypt() call, and possibly that's for the best. I don't
really want to add a secret method for doing that, so
I've just mangled the test suite instead.

Possibly we should test for an exit code != 0 rather than
the specific 2 we get at the moment but oh well.
-- 
Niko
>From 958e8aa6812b4d6c2e9d66203073dd348c3d8f04 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sun, 24 Jun 2018 16:19:25 +0300
Subject: [PATCH] Fix test suite for GnuPG >= 2.2.8 compatibility

GnuPG 2.2.8 onwards issues a hard failure when decrypting
messages not using the MDC mode.

Bug-Debian: https://bugs.debian.org/900051
---
 t/decrypt.t | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/t/decrypt.t b/t/decrypt.t
index b2639ed..f7d9132 100644
--- a/t/decrypt.t
+++ b/t/decrypt.t
@@ -6,6 +6,7 @@
 use strict;
 use English qw( -no_match_vars );
 use File::Compare;
+use version;
 
 use lib './t';
 use MyTest;
@@ -13,6 +14,8 @@ use MyTestSpecific;
 
 my $compare;
 
+my $gnupg_version = version->parse($gnupg->version);
+
 TEST
 {
 reset_handles();
@@ -26,7 +29,13 @@ TEST
 close $stdout;
 waitpid $pid, 0;
 
-return $CHILD_ERROR == 0;;
+if ($gnupg_version < version->parse('2.2.8')) {
+return $CHILD_ERROR == 0;;
+} else {
+local $/ = undef;
+my $errstr = <$stderr>;
+return (($CHILD_ERROR >> 8 == 2) and ($errstr =~ /ignore-mdc-error/));
+}
 };
 
 
@@ -50,7 +59,13 @@ TEST
 
 waitpid $pid, 0;
 
-return $CHILD_ERROR == 0;
+if ($gnupg_version < version->parse('2.2.8')) {
+return $CHILD_ERROR == 0;
+} else {
+local $/ = undef;
+my $errstr = <$stderr>;
+return (($CHILD_ERROR >> 8 == 2) and ($errstr =~ /ignore-mdc-error/));
+}
 };
 
 
-- 
2.17.1

Bug#901807: libmath-gsl-perl: incompatible with GSL >= 2.5

[Niko Tyni]

On Mon, Jun 18, 2018 at 05:40:34PM +0200, gregor herrmann wrote:
> Source: libmath-gsl-perl
> Version: 0.39-1
> Severity: serious
> Tags: upstream buster sid
> Justification: fails to build from source (but built successfully in the past)
> Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=123306

>dh_auto_build
>   perl Build
> Building Math-GSL
> VERSION MISMATCH: Let's hope for the best.
> Processing 2.2.1 XS files, GSL 2.5 (via gsl-config) at /usr
> [build warnings]
>dh_auto_test
>   perl Build test --verbose 1
> VERSION MISMATCH: Let's hope for the best.
> Processing 2.2.1 XS files, GSL 2.5 (via gsl-config) at /usr
> […]
> #   Failed test 'use Math::GSL::Linalg;'
> #   at t/00-load.t line 11.
> # Tried to use 'Math::GSL::Linalg'.
> # Error:  Can't load 
> '/build/libmath-gsl-perl-0.39/blib/arch/auto/Math/GSL/Linalg/Linalg.so' for 
> module Math::GSL::Linalg: 
> /build/libmath-gsl-perl-0.39/blib/arch/auto/Math/GSL/Linalg/Linalg.so: 
> undefined symbol: gsl_linalg_hessenberg at 
> /usr/lib/x86_64-linux-gnu/perl/5.26/DynaLoader.pm line 187.
> #  at /build/libmath-gsl-perl-0.39/blib/lib/Math/GSL/Linalg.pm line 11.
> # Compilation failed in require at t/00-load.t line 11.
> # BEGIN failed--compilation aborted at t/00-load.t line 11.

There seem to be multiple problems here.

One issue is that libgsl23 broke its ABI in 2.5+dfsg-1. I've filed #902281
about that.

Another is that the code in xs/ should really be rebuilt from the
sources in swig/, but this is currently skipped; Build.PL has

 my $ver2func = do(catfile(qw/inc ver2func/));

which breaks silently now that cwd is not on @INC anymore.

I was able to cobble a working rebuild together with something like this:

 perl -I. Build.PL
 perl Build clean  # removes xs/*
 perl -I. Build.PL
 perl Build # regenerates xs/*
 perl Build test

and the attached two patches. The latter one may not turn out to be
necessary if the deprecated functions get reinstated with #902281.
-- 
Niko Tyni   nt...@debian.org
>From b93eda2b6edcbbcb999c4aa28ad728a46db9631d Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sun, 24 Jun 2018 15:26:52 +0300
Subject: [PATCH 1/2] Fix a swig syntax error in Integration.i

This fixes

 swig/IEEEUtils.i:11: Warning 453: Can't apply (char const *format). No typemaps are defined.
 Creating xs/Integration_wrap.1.15.c
 /usr/include/gsl/gsl_integration.h:363: Error: Syntax error - possibly a missing semicolon.
 error : No such file or directory while building ( -I/usr/include ) xs/Integration_wrap.1.15.c in pm/Math/GSL from 'swig/Integration.i' at inc/GSLBuilder.pm line 244.

and is needed at least on libgsl 2.4 / 2.5 and SWIG 3.0.12.
---
 swig/Integration.i | 1 +
 1 file changed, 1 insertion(+)

diff --git a/swig/Integration.i b/swig/Integration.i
index 0272059..0933037 100644
--- a/swig/Integration.i
+++ b/swig/Integration.i
@@ -7,6 +7,7 @@
 #include "gsl/gsl_integration.h"
 #include "gsl/gsl_math.h"
 %}
+%include "gsl/gsl_types.h"
 %include "gsl/gsl_integration.h"
 %include "gsl/gsl_math.h"
 %include "../pod/Integration.pod"
-- 
2.17.1

>From fc9ab21c646f60878ab0bfb8eb568e049cb91655 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sun, 24 Jun 2018 15:32:08 +0300
Subject: [PATCH 2/2] Disable deprecated function usage in SF.i

A few sf_coupling related functions are being removed in gsl 2.5 or so,
see https://bugs.debian.org/902281
---
 swig/SF.i | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/swig/SF.i b/swig/SF.i
index 07bfa3c..068c73d 100644
--- a/swig/SF.i
+++ b/swig/SF.i
@@ -4,6 +4,8 @@
 %include "renames.i"
 %include "system.i"
 
+#define  GSL_DISABLE_DEPRECATED 1
+
 %apply double *OUTPUT { double * sn, double * cn, double * dn, double * sgn };
 
 %ignore gsl_sf_ellint_D_e;
-- 
2.17.1

Bug#902281: libgsl23: ABI breakage due to removed symbols

[Niko Tyni]

Package: libgsl23
Version: 2.5+dfsg-1
Severity: serious

libgsl23 changed it's ABI without an SONAME bump in 2.5+dfsg-1.

Missing symbols:

% diff -u <(objdump -T libgsl.so.23-buster| cut -c50-) <(objdump -T 
libgsl.so.23-sid| cut -c50-)|grep ^-
--- /proc/self/fd/132018-06-23 18:24:03.211641309 +0300
-Basegsl_sf_legendre_Plm_deriv_array
-Basegsl_sf_legendre_Plm_array
-Basegsl_sf_legendre_sphPlm_array
-Basegsl_sf_legendre_array_size
-Basegsl_multifit_fdfsolver_dif_fdf
-Basegsl_sf_coupling_6j_INCORRECT
-Basegsl_linalg_hessenberg
-Basegsl_sf_coupling_6j_INCORRECT_e
-Basegsl_sf_legendre_sphPlm_deriv_array

This broke at least libmath-gsl-perl, which now fails
due to missing symbols.

  https://ci.debian.net/packages/libm/libmath-gsl-perl/unstable/amd64/

  # perl -e 'use Math::GSL::Linalg'
  Can't load 
'/usr/lib/x86_64-linux-gnu/perl5/5.26/auto/Math/GSL/Linalg/Linalg.so' for 
module Math::GSL::Linalg: 
/usr/lib/x86_64-linux-gnu/perl5/5.26/auto/Math/GSL/Linalg/Linalg.so: undefined 
symbol: gsl_linalg_hessenberg at 
/usr/lib/x86_64-linux-gnu/perl/5.26/DynaLoader.pm line 187.
   at /usr/lib/x86_64-linux-gnu/perl5/5.26/Math/GSL/Linalg.pm line 11.
  Compilation failed in require at -e line 1.
  BEGIN failed--compilation aborted at -e line 1.
  
  # perl -e 'use Math::GSL::SF'
  Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.26/auto/Math/GSL/SF/SF.so' for 
module Math::GSL::SF: 
/usr/lib/x86_64-linux-gnu/perl5/5.26/auto/Math/GSL/SF/SF.so: undefined symbol: 
gsl_sf_coupling_6j_INCORRECT_e at 
/usr/lib/x86_64-linux-gnu/perl/5.26/DynaLoader.pm line 187.
   at /usr/lib/x86_64-linux-gnu/perl5/5.26/Math/GSL/SF.pm line 11.
  Compilation failed in require at -e line 1.
  BEGIN failed--compilation aborted at -e line 1.

Please reinstate the symbols or bump the SONAME (which would normally
require a proper library transition.)
-- 
Niko Tyni nt...@debian.org

Bug#900051: libgnupg-interface-perl: t/get_public_keys.t fails with gnupg2/2.2.7-1

[Niko Tyni]

On Fri, May 25, 2018 at 11:05:58AM +0200, intrig...@debian.org wrote:
> Package: libgnupg-interface-perl
> Version: 0.52-9
> Severity: important
> X-Debbugs-Cc: d...@debian.org
 
> ci.d.n alerted us about a regression in libgnupg-interface-perl test
> suite since the upload of gnupg2/2.2.7-1:

> gpg: Check that a key may do certifications.
> + commit 1a5d95e7319e7e6f0dd11064a26cbbc371b05214
> * g10/sig-check.c (check_signature_end_simple): Check key usage for
> certifications.
> (check_signature_over_key_or_uid): Request usage certification.

I've bisected it to that one. The code checking the sigs now sets
  signer->req_usage = PUBKEY_USAGE_CERT
which makes finish_lookup() in g10/getkey.c also check that the
signing key has not expired, which fails here.

Log excerpts from

  GNUPGHOME=~/tmp/libgnupg-interface-perl-0.52/test/gnupghome gpg --debug-level 
guru --check-sigs 93AFC4B1B0288A104996B44253AE596EF950DA9C

before the regression:

  gpg: DBG: finish_lookup: checking key 260C4FA3 (one)(req_usage=0)
  gpg: DBG: using key 260C4FA3
  [...]
  gpg: 9 good signatures

but after the regression:

  gpg: DBG: finish_lookup: checking key 260C4FA3 (one)(req_usage=4)
  gpg: DBG:   primary key has expired
  gpg: DBG:   no suitable key found -  giving up
  [...]
  gpg: 7 good signatures
  gpg: 2 signatures not checked due to missing keys

The new behaviour of rejecting signatures from an expired key seems
sensible, so the attached patch adapts the test suite to that.

There's still the 2.2.8 / --ignore-mdc-error regression to fix.
Happy if someone else can look at that, won't be able to do that
for a few days myself.
-- 
Niko
>From 46ccc0a68d9f8d9c62d3fe3343dfd624065fc6b9 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Wed, 20 Jun 2018 21:57:50 +0300
Subject: [PATCH] Fix test suite for GnuPG >= 2.2.6 compatibility

GnuPG 2.2.6 (commit 1a5d95e7319e7e6f) started marking signatures
with an expired key with '?', as seen with for instance

 GNUPGHOME=./test/gnupghome/ gpg --list-sigs 0xF950DA9C

Adapt the test suite accordingly.

See https://dev.gnupg.org/rG1a5d95e7319e7e6f0dd11064a26cbbc371b05214

Bug-Debian: https://bugs.debian.org/900051
---
 t/get_public_keys.t | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/t/get_public_keys.t b/t/get_public_keys.t
index 9e96f7d6b..f81fd1fab 100644
--- a/t/get_public_keys.t
+++ b/t/get_public_keys.t
@@ -13,8 +13,12 @@ use MyTestSpecific;
 use GnuPG::PrimaryKey;
 use GnuPG::SubKey;
 
+use version;
+
 my ( $given_key, $handmade_key );
 
+my $gnupg_version = version->parse($gnupg->version);
+
 TEST
 {
 reset_handles();
@@ -74,7 +78,7 @@ TEST
 date_string => '2000-03-16',
 hex_id => '56FFD10A260C4FA3',
 sig_class => 0x10,
-validity => '!'),
+validity => $gnupg_version < version->parse('2.2.6') ? '!' : '?'),
   GnuPG::Signature->new(
 date => 949813093,
 algo_num => 17,
@@ -115,7 +119,7 @@ TEST
 date_string => '2000-03-16',
 hex_id => '56FFD10A260C4FA3',
 sig_class => 0x10,
-validity => '!'),
+validity => $gnupg_version < version->parse('2.2.6') ? '!' : '?'),
   GnuPG::Signature->new(
 date => 953179891,
 algo_num => 17,
-- 
2.17.1

Bug#900051: libgnupg-interface-perl: t/get_public_keys.t fails with gnupg2/2.2.7-1

[Niko Tyni]

On Fri, May 25, 2018 at 05:06:21PM +0300, Niko Tyni wrote:
> Control: severity -1 serious
> 
> On Fri, May 25, 2018 at 11:05:58AM +0200, intrig...@debian.org wrote:
> > Package: libgnupg-interface-perl
> > Version: 0.52-9
> > Severity: important
> > X-Debbugs-Cc: d...@debian.org
>  
> > ci.d.n alerted us about a regression in libgnupg-interface-perl test
> > suite since the upload of gnupg2/2.2.7-1:
> 
> >   Test Summary Report
> >   ---
> >   t/get_public_keys.t (Wstat: 0 Tests: 3 Failed: 1)
> > Failed test:  3
> 
> This makes the package fail to build, so raising the severity.

In addition to the above, gnupg2/2.2.8-1 also introduced new failures:

  t/decrypt.t  
  1..6
  not ok 1
  ok 2
  not ok 3
  ok 4
  ok 5
  ok 6
  Failed 2/6 subtests 

gpg --decrypt now exits with code 2. strace reveals

  690   write(2, "WARNING: message was not integrity protected\n", 45) = 45
  690   write(2, "gpg: ", 5)  = 5
  690   write(2, "Hint: If this message was created before the year 2003 it 
is\n", 61) = 61
  690   write(2, " ", 5)  = 5
  690   write(2, "likely that this message is legitimate.  This is because 
back\n", 62) = 62
  690   write(2, " ", 5)  = 5
  690   write(2, "then integrity protection was not widely used.\n", 47) = 47
  690   write(2, "gpg: Use the option '--ignore-mdc-error", 39) = 39
  690   write(2, "' to decrypt anyway.\n", 21) = 21
  690   write(2, "gpg: ", 5)  = 5
  690   write(2, "decryption forced to fail!\n", 27) = 27
 
so this seems to be due to

  Noteworthy changes in version 2.2.8
  ===

  * gpg: Decryption of messages not using the MDC mode will now lead
to a hard failure even if a legacy cipher algorithm was used.  The
option --ignore-mdc-error can be used to turn this failure into a
warning.  Take care: Never use that option unconditionally or
without a prior warning.

-- 
Niko Tyni   nt...@debian.org

Bug#901822: ocaml-flac: FTBFS: Unbound type constructor Ogg.Stream.t

[Niko Tyni]

Package: ocaml-flac
Version: 0.1.1-4
Severity: serious

BinNMUs of this package failed to build on almost all architectures back
in May.

It also fails to build for me on current sid/amd64.

 https://buildd.debian.org/status/package.php?p=ocaml-flac

  ar rcs libflac_stubs.a  flac_stubs.o ogg_flac_stubs.o
  ocamlc.opt -c -g -I /usr/lib/ocaml/ogg flac.mli
  ocamlc.opt -c -g -I /usr/lib/ocaml/ogg flac.ml
  File "flac.ml", line 108, characters 8-24:
  Warning 3: deprecated: String.uppercase
  Use String.uppercase_ascii instead.
  File "flac.ml", line 166, characters 16-29:
  Warning 3: deprecated: String.create
  Use Bytes.create instead.
  ocamlc.opt -c -g -I /usr/lib/ocaml/ogg ogg_flac.mli
  File "ogg_flac.mli", line 62, characters 36-48:
  Error: Unbound type constructor Ogg.Stream.t
  make[3]: *** [OCamlMakefile:934: ogg_flac.cmi] Error 2
  make[3]: Leaving directory '/<>/src'
  make[2]: *** [OCamlMakefile:717: byte-code-library] Error 2
  make[2]: Leaving directory '/<>/src'
  make[1]: *** [Makefile:12: all] Error 2
  make[1]: Leaving directory '/<>'
  make: *** [/usr/share/cdbs/1/class/makefile.mk:77: 
debian/stamp-makefile-build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
 
-- 
Niko Tyni   nt...@debian.org

Bug#901567: unburden-home-dir: FTBFS: No such file or directory: '/usr/lib/python3/dist-packages/mkdocs/themes/readthedocs/fonts/fontawesome-webfont.woff'

[Niko Tyni]

Source: unburden-home-dir
Version: 0.4.1
Severity: serious

This package fails to build on current sid/amd64.

It probably regressed due to mkdocs changes (currently at 0.17.4+dfsg-1),
please reassign + set affects if it's a bug there.


  make[1]: Entering directory '/<>'
  env LC_ALL=C.UTF-8 mkdocs build --clean
  ronn --manual="Unburden Your Home Directory" -r --pipe 
docs/unburden-home-dir.1.md > unburden-home-dir.1
  INFO-  Cleaning site directory 
  INFO-  Building documentation to directory: /<>/html 
  Traceback (most recent call last):
File "/usr/bin/mkdocs", line 6, in 
  cli()
File "/usr/lib/python3/dist-packages/click/core.py", line 722, in __call__
  return self.main(*args, **kwargs)
File "/usr/lib/python3/dist-packages/click/core.py", line 697, in main
  rv = self.invoke(ctx)
File "/usr/lib/python3/dist-packages/click/core.py", line 1066, in invoke
  return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/lib/python3/dist-packages/click/core.py", line 895, in invoke
  return ctx.invoke(self.callback, **ctx.params)
File "/usr/lib/python3/dist-packages/click/core.py", line 535, in invoke
  return callback(*args, **kwargs)
File "/usr/lib/python3/dist-packages/mkdocs/__main__.py", line 156, in 
build_command
  ), dirty=not clean)
File "/usr/lib/python3/dist-packages/mkdocs/commands/build.py", line 276, 
in build
  theme_dir, config['site_dir'], exclude=['*.py', '*.pyc', '*.html', 
'mkdocs_theme.yml'], dirty=dirty
File "/usr/lib/python3/dist-packages/mkdocs/utils/__init__.py", line 179, 
in copy_media_files
  copy_file(source_path, output_path)
File "/usr/lib/python3/dist-packages/mkdocs/utils/__init__.py", line 113, 
in copy_file
  shutil.copyfile(source_path, output_path)
File "/usr/lib/python3.6/shutil.py", line 120, in copyfile
  with open(src, 'rb') as fsrc:
  FileNotFoundError: [Errno 2] No such file or directory: 
'/usr/lib/python3/dist-packages/mkdocs/themes/readthedocs/fonts/fontawesome-webfont.woff'
  make[1]: *** [Makefile:10: html/index.html] Error 1
  make[1]: Leaving directory '/<>'
  dh_auto_build: make -j4 returned exit code 2
  make: *** [debian/rules:8: binary] Error 2
 
Thanks for your work,
-- 
Niko Tyni   nt...@debian.org

Bug#897555: subversion: FTBFS: /bin/bash: /usr/lib/jvm/default-java/bin/javah: No such file or directory

[Niko Tyni]

On Wed, May 16, 2018 at 08:33:58AM -0400, James McCoy wrote:
> On Fri, May 11, 2018 at 04:27:39PM +0200, Emmanuel Bourg wrote:
> > Control: tags -1 + patch
> > 
> > Le 06/05/2018 à 02:13, James McCoy a écrit :
> > 
> > > It looks like that will do the right thing.  Now I just need to figure
> > > out the larger issue of adapting upstream's build system.
> > 
> > I've managed to patch the EZT Make template to use 'javac -h' instead of
> > javah. A few classes with no native methods but static fields used in
> > native code also required the addition of the @Native annotation.
> 
> Thanks!  I'll get the annotations upstreamed soon, since those seem like
> obvious fixes.  I'm pretty close to having a more general fix for the
> Java templates, but if subversion starts getting in the way of other
> packages it's good to have your patch to fall back on.

Hi, any news on this? It's blocking parts of our Perl 5.28 rebuild
testing, and will obviously block the transition as well when we get
that far.

Thanks for your work,
-- 
Niko Tyni   nt...@debian.org

Bug#887687: libsmokeqt4-dev: broken symlinks and causes qt4-perl FTBFS

[Niko Tyni]

On Fri, Jan 19, 2018 at 06:23:25AM +0200, Adrian Bunk wrote:
> Package: libsmokeqt4-dev
> Version: 4:4.14.3-1.2
> Severity: serious
> Control: affects -1 src:qt4-perl
> 
> qt4-perl FTBFS:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/qt4-perl.html

> /usr/lib/libsmokeqt3support.so and several other .so
> links are broken.

Just a note that this is going to be a blocker for Perl 5.28 transition,
which is expected to happen in the next few months.

debconf Build-Depends: libqtgui4-perl which is going to need a binNMU for
Perl 5.28 but FTBFS because of this bug.

Dear Qt/KDE maintainers: do you think qt4-perl should still be kept alive,
or should the support in debconf be finally removed (see #629405) ?
I see there's a prospective alternative KDE debconf frontend (#631769)
but that seems stalled unfortunately.

Copying the debconf maintainers as well.
-- 
Niko Tyni   nt...@debian.org

Bug#901542: sreview: FTBFS: unable to load addon sysuser

[Niko Tyni]

Source: sreview
Version: 0.3.1-1
Severity: serious

This package fails to build in a clean sid/amd64 chroot.

>From the build log:

  dpkg-buildpackage: info: host architecture amd64
   fakeroot debian/rules clean
  dh clean --with apache2,sysuser
  dh: unable to load addon sysuser: Can't locate 
Debian/Debhelper/Sequence/sysuser.pm in @INC (you may need to install the 
Debian::Debhelper::Sequence::sysuser module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 
/usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at (eval 11) line 
1.
  BEGIN failed--compilation aborted at (eval 11) line 1.
  
  make: *** [debian/rules:4: clean] Error 2
  dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned 
exit status 2
 
-- 
Niko Tyni   nt...@debian.org

Bug#901540: vnlog: FTBFS: test failures

[Niko Tyni]

Source: vnlog
Version: 1.9-1
Severity: serious

This package failed to build on many architectures where previous versions
have built.

  https://buildd.debian.org/status/package.php?p=vnlog

From the i386 build log:

Test failed. Expected success, but got failure.
Ran 'perl /<>/test/../vnl-sort -k a data1 data2'.
STDERR: 'All input legends must match! Instead files 'data1' and 'data2' have 
keys 'a b e' and 'a b' respectively at /<>/lib/Vnlog/Util.pm line 
234.
Vnlog::Util::ensure_all_legends_equivalent(ARRAY(0x58855cfc)) called at 
/<>/test/../vnl-sort line 131
' at /<>/test/TestHelpers.pm line 95.
TestHelpers::check("# a b\x{a}1 1.69\x{a}20 0.09\x{a}3 0.49\x{a}4 
2.89\x{a}5 -10\x{a}5 7.29\x{a}6 -8\x{a}7 -6\x{a}8 -"..., "-k", "a", "\$data1", 
"\$data2") called at test/test_vnl-sort.pl line 82
[...]
11 tests failed!
Makefile:79: recipe for target 'test/test_vnl-sort.pl.RUN' failed
make[1]: *** [test/test_vnl-sort.pl.RUN] Error 1
make[1]: *** Waiting for unfinished jobs
All tests passed!
All tests passed!
make[1]: Leaving directory '/<>'
dh_auto_test: make -j4 test returned exit code 2
debian/rules:6: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

-- 
Niko Tyni   nt...@debian.org

Bug#901327: tigervnc: FTBFS: Hunk #1 FAILED

[Niko Tyni]

Source: tigervnc
Version: 1.7.0+dfsg-8
Severity: serious

This package fails to build from source on current sid/amd64.

>From the build log:

  touch debian/stamp-patched
  /usr/bin/make -f debian/rules update-config
  make[1]: Entering directory '/<>/tigervnc-1.7.0+dfsg'
  make[1]: 'update-config' is up to date.
  make[1]: Leaving directory '/<>/tigervnc-1.7.0+dfsg'
  cd ./unix/xserver && \
{ tar --strip-components 1 -xvJf /usr/src/xorg-server.tar.xz | \
sed -e 's@^[^/]*/@@' > .apply-patches-unify-xorg-and-vnc-tree.files; } 
&& \
touch .apply-patches-unify-xorg-and-vnc-tree.stamp
  cd ./unix/xserver && { \
patch --no-backup-if-mismatch -p1 < 
/<>/tigervnc-1.7.0+dfsg/debian/xserver119.patch && \
touch .apply-patches-vnc-patch-xorg.stamp; \
  }
  patching file configure.ac
  Hunk #2 succeeded at 1778 (offset -86 lines).
  Hunk #3 succeeded at 1817 (offset -86 lines).
  Hunk #4 succeeded at 2036 (offset -87 lines).
  Hunk #5 succeeded at 2571 (offset -126 lines).
  patching file hw/Makefile.am
  patching file mi/miinitext.c
  Hunk #1 FAILED at 114.
  Hunk #2 succeeded at 109 (offset -129 lines).
  1 out of 2 hunks FAILED -- saving rejects to file mi/miinitext.c.rej
  patching file include/os.h
  Hunk #1 succeeded at 633 (offset 12 lines).
  make: *** [debian/rules:129: 
unix/xserver/.apply-patches-vnc-patch-xorg.stamp] Error 1
 
-- 
Niko Tyni   nt...@debian.org

Bug#901323: pkg-haskell-tools: unsatisfiable build dependency: libghc-shake-dev (<< 0.16)

[Niko Tyni]

Package: pkg-haskell-tools
Version: 0.11.1
Severity: serious

This package can't be built from source on current sid/amd64: it build
depends on libghc-shake-dev (< 0.16) but sid has 0.16.4-2.

  # apt build-dep pkg-haskell-tools
  Reading package lists... Done
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:
  
  The following packages have unmet dependencies:
   builddeps:pkg-haskell-tools : Depends: libghc-shake-dev (< 0.16) but 
0.16.4-2 is to be installed
  E: Unable to correct problems, you have held broken packages.

-- 
Niko Tyni   nt...@debian.org

Bug#901085: libur-perl: FTBFS with Perl 5.28: test failures

[Niko Tyni]

On Sat, Jun 09, 2018 at 02:28:29PM +0200, gregor herrmann wrote:
> On Sat, 09 Jun 2018 10:44:17 +0300, Niko Tyni wrote:
> 
> > > Confirmed, and I can offer even more failures:
> > > # died: Error while autoloading with 'use 
> > > CmdTest::Thing::/build/libur-perl-0.460+ds/t//CmdTest/Thing/Create': 
> > > Unknown regexp modifier "/b" at (eval 234) line 1, at end of line
> > You seem to be testing 0.460+ds while sid has 0.450?
> 
> Oh, right, I was just building from what we have in git, sorry for
> not checking the versions.

These were #901241, should be fixed in 0.460+ds-1 I just uploaded.
-- 
Niko

Bug#901242: libur-perl: should build-depend and recommend libxml-libxml-perl and libxml-libxslt-perl

[Niko Tyni]

Package: libur-perl
Version: 0.450-1

This package uses XML::LibXML and Xml::LibXSLT if available, and currently
skips some related tests during build.

README.Debian points to https://rt.cpan.org/Ticket/Display.html?id=83479
which is fixed long ago, and my quick test shows no build failures
when libxml-libxml-perl and libxml-libxslt-perl are installed.

We should probably Recommend those at run time.
-- 
Niko Tyni   nt...@debian.org

Bug#901241: libur-perl: test failures when build dir has regexp metacharacters

[Niko Tyni]

Package: libur-perl
Version: 0.450-1
Tags: patch

This package fails to build in a directory with regexp
metacharacters like a plus sign ('+').

Test Summary Report
---
t/URT/t/70d_command_sub_command_factory.t   (Wstat: 
768 Tests: 6 Failed: 3)
  Failed tests:  3-5
  Non-zero exit status: 3
t/class_browser/internal.t  (Wstat: 
65280 Tests: 8 Failed: 2)
  Failed tests:  2, 8
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 38 tests but ran 8.

Patch attached.
-- 
Niko Tyni   nt...@debian.org
>From 2686c8d1e3c556a40e44a54e41d7d458490080d4 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sun, 10 Jun 2018 15:45:33 +0300
Subject: [PATCH] Fix test failures when cwd contains regexp metacharacters

t/URT/t/70d_command_sub_command_factory.t and t/class_browser/internal.t
fail without this when run in a directory containing regexp metacharacters
like a plus ('+').
---
 lib/Command/SubCommandFactory.pm | 2 +-
 lib/UR/Namespace/Command/Sys/ClassBrowser.pm | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/Command/SubCommandFactory.pm b/lib/Command/SubCommandFactory.pm
index da1219da..a3bff107 100644
--- a/lib/Command/SubCommandFactory.pm
+++ b/lib/Command/SubCommandFactory.pm
@@ -61,7 +61,7 @@ sub _build_sub_command_mapping {
 my @target_class_names;
 for my $target_path (@target_paths) { 
 my $target = $target_path;
-$target =~ s#$base_path\/$ref_path/##; 
+$target =~ s#\Q$base_path\E\/$ref_path/##;
 $target =~ s/\.pm//;
 
 my $target_base_class = $class->_target_base_class;
diff --git a/lib/UR/Namespace/Command/Sys/ClassBrowser.pm b/lib/UR/Namespace/Command/Sys/ClassBrowser.pm
index 2ba06a7b..7f9e69b4 100644
--- a/lib/UR/Namespace/Command/Sys/ClassBrowser.pm
+++ b/lib/UR/Namespace/Command/Sys/ClassBrowser.pm
@@ -200,7 +200,7 @@ sub _generate_class_name_cache {
 my $cwd = Cwd::getcwd . '/';
 my $namespace_meta = $namespace->__meta__;
 my $namespace_dir = $namespace_meta->module_directory;
-(my $path = $namespace_meta->module_path) =~ s/^$cwd//;
+(my $path = $namespace_meta->module_path) =~ s/^\Q$cwd\E//;
 my $by_class_name = {  $namespace => {
 name  => $namespace,
 is=> $namespace_meta->is,
@@ -226,7 +226,7 @@ sub _class_name_cache_data_for_class_name {
 }
 my $namespace_dir = $class_meta->namespace->__meta__->module_directory;
 my $module_path = $class_meta->module_path;
-(my $relpath = $module_path) =~ s/^$namespace_dir//;
+(my $relpath = $module_path) =~ s/^\Q$namespace_dir\E//;
 return {
 name=> $class_meta->class_name,
 relpath => $relpath,
-- 
2.17.1

Bug#901080: libtest-differences-perl: FTBFS with Perl 5.28: t/column-headers.t failure with verbose tests

[Niko Tyni]

On Sun, Jun 10, 2018 at 11:38:43AM +0300, Niko Tyni wrote:
> On Fri, Jun 08, 2018 at 11:23:04PM +0200, gregor herrmann wrote:

> > Confirmed, both the failure and the correlation with test verbosity.
> 
> This is triggered by newer versions of Test-Simple and happens
> on sid as well with the separate libtest-simple-perl package
> installed.

It bisects to

 
https://github.com/Test-More/test-more/commit/b9c8b098fcb6be510d418b9356c3437b3660d67f

and I've filed

 https://github.com/Test-More/test-more/issues/810

about it. We'll see where it needs fixing.
-- 
Niko Tyni   nt...@debian.org

Bug#901080: libtest-differences-perl: FTBFS with Perl 5.28: t/column-headers.t failure with verbose tests

[Niko Tyni]

Control: retitle -1 libtest-differences-perl: FTBFS with newer versions of 
libtest-simple-perl: t/column-headers.t failure with verbose tests

On Fri, Jun 08, 2018 at 11:23:04PM +0200, gregor herrmann wrote:
> On Fri, 08 Jun 2018 21:28:37 +0300, Niko Tyni wrote:
> 
> > Source: libtest-differences-perl
> > Version: 0.64-1
> > Severity: important
> > User: debian-p...@lists.debian.org
> > Usertags: perl-5.28-transition
> > 
> > This package fails to build with perl 5.28.0-RC1 (currently in
> > experimental).
> > 
> >  
> > http://perl.debian.net/rebuild-logs/perl-5.28-throwaway/libtest-differences-perl_0.64-1/libtest-differences-perl_0.64-1_amd64-2018-06-08T17:52:42Z.build
> > 
> > This seems to be related to verbose test output. 

> Confirmed, both the failure and the correlation with test verbosity.

This is triggered by newer versions of Test-Simple and happens
on sid as well with the separate libtest-simple-perl package
installed.
-- 
Niko Tyni   nt...@debian.org

Bug#901082: libpgobject-type-json-perl: FTBFS with Perl 5.28: t/02-serialization.t failure

[Niko Tyni]

On Sat, Jun 09, 2018 at 10:14:22AM +0300, Niko Tyni wrote:
> On Fri, Jun 08, 2018 at 11:14:35PM +0200, gregor herrmann wrote:
> > On Fri, 08 Jun 2018 21:38:12 +0300, Niko Tyni wrote:
> > 
> > > Source: libpgobject-type-json-perl
> > > Version: 2.01-1
> > > Severity: important
> > > User: debian-p...@lists.debian.org
> > > Usertags: perl-5.28-transition
> > > 
> > > This package fails to build with Perl 5.28 (currently in experimental.)
> > > 
> > >   
> > > http://perl.debian.net/rebuild-logs/perl-5.28-throwaway/libpgobject-type-json-perl_2.01-1/libpgobject-type-json-perl_2.01-1_amd64-2018-06-08T17:55:53Z.build
> > > 
> > >   #   Failed test 'Literal serializes correctly'
> > >   #   at t/02-serialization.t line 49.
> > >   #  got: '123'
> > >   # expected: '"123"'
> > >   # Looks like you failed 1 test of 23.
> > >  
> > > I don't see an upstream bug or a failing CPAN test report
> > > but it fails consistently for me.
> > 
> > I can confirm the failure with 5.28, and it still passes the tests
> > with 5.26.
> > 
> > No idea which JSON thing in which part adds/removes the quotation
> > marks. All I can think of is the different version of JSON::PP but
> > then the problem should show up elsewhere as well.
> 
> It's indeed to do with JSON::PP and not specific to Perl 5.28.
> 
> Reduced to
> 
>  perl -MJSON::PP -le '$p=123; "". $p; print 
> JSON::PP->new->allow_nonref->encode($p)'
> 
> which gives the string "123" on older versions of JSON::PP and the number 123
> on newer ones (at least 2.97001-1).

This bisects to
  
https://github.com/makamaka/JSON-PP/commit/87bd6a49bacc3a2634cbb1dd0ce9cc75675bb524
and I've filed
  https://github.com/makamaka/JSON-PP/issues/39
about it.

Not sure yet if it's a bug or if others need to adapt.
-- 
Niko Tyni   nt...@debian.org

Bug#901158: postgis: FTBFS: testsuite failure

[Niko Tyni]

Package: postgis
Version: 2.4.4+dfsg-1
Severity: serious

This package fails to build from source on current sid/amd64.

   ### /tmp/pgis_reg/test_50_diff ###
  --- rt_gdalwarp_expected  2018-04-06 05:05:52.0 +
  +++ /tmp/pgis_reg/test_50_out 2018-06-09 14:27:15.049036062 +
  @@ -19,8 +19,8 @@
   0.17|993309|243|243|1|50.000|50.000|0.000|0.000|950760.000|1396957.000|t|t|t
   
0.18|992163|10|10|1|1000.000|-1000.000|3.000|3.000|-500030.000|60.000|t|t|t
   
0.19|993310|12|12|1|1009.894|-1009.894|3.000|3.000|950691.792|1409281.783|t|t|t
  
-0.2|993309|12|12|1|1009.916|-1009.916|0.000|0.000|950762.305|1409088.896|t|t|t
  
-0.20|993309|12|12|1|1009.916|-1009.916|1.000|3.000|950742.107|1409088.896|t|t|t
  
+0.2|993309|12|12|1|1009.876|-1009.876|0.000|0.000|950808.447|1409091.640|t|t|t
  
+0.20|993309|12|12|1|1009.876|-1009.876|1.000|3.000|950788.250|1409091.640|t|t|t
   0.21|993310|24|24|1|500.000|500.000|3.000|3.000|950657.188|1397356.783|t|t|t
   0.22|993310|26|26|1|500.000|500.000|0.000|6.000|950452.000|1396632.000|t|t|t
   0.23|984269|12|8|1|0.012|-0.012|0.000|0.000|-107.029|50.206|t|t|t
  @@ -63,12 +63,12 @@
   
1.9|992163|11|10|1|1000.000|-1000.000|0.000|0.000|-51.000|60.000|t|t|t
   
2.1|993310|12|12|1|1009.894|-1009.894|0.000|0.000|950732.188|1409281.783|t|t|t
   2.10|993310|24|24|1|500.000|500.000|0.000|0.000|950732.188|1397281.783|t|t|t
  
-2.11|993309|121|121|1|100.000|100.000|0.000|0.000|950762.305|1396988.896|t|t|t
  
+2.11|993309|121|121|1|100.000|100.000|0.000|0.000|950808.447|1396991.640|t|t|t
   2.12|993310|6|6|1|2000.000|2000.000|0.000|0.000|950732.188|1397281.783|t|t|t
   2.13|993310|8|8|1|1500.000|1500.000|0.000|0.000|950732.188|1397281.783|t|t|t
   2.14|993310|24|24|1|500.000|500.000|0.000|0.000|950732.188|1397281.783|t|t|t
   2.15|993310|16|16|1|750.000|750.000|0.000|0.000|950732.188|1397281.783|t|t|t
  
-2.2|993309|12|12|1|1009.916|-1009.916|0.000|0.000|950762.305|1409088.896|t|t|t
  
+2.2|993309|12|12|1|1009.876|-1009.876|0.000|0.000|950808.447|1409091.640|t|t|t
   2.3|994269|12|8|1|0.012|-0.012|0.000|0.000|-107.029|50.206|t|t|t
   2.4|
   
2.5|993310|12|12|1|1009.894|-1009.894|0.000|0.000|950732.188|1409281.783|t|t|t
   ### end of log dumps ###
  make[1]: *** [debian/rules:200: override_dh_auto_test] Error 2
  make[1]: Leaving directory '/<>/postgis-2.4.4+dfsg'
  make: *** [debian/rules:111: build] Error 2
 
Full build log attached.
-- 
Niko Tyni   nt...@debian.org


postgis_amd64-2018-06-09T14:19:48Z.build.gz
Description: application/gzip

Bug#900832: libdbd-csv-perl: FTBFS with Perl 5.28: t/82_free_unref_scalar.t failure

[Niko Tyni]

On Tue, Jun 05, 2018 at 07:57:47PM +0300, Niko Tyni wrote:
> Package: libdbd-csv-perl
> Version: 0.5300-1
> Severity: important
> User: debian-p...@lists.debian.org
> Usertags: perl-5.28-transition
> Tags: upstream
> 
> This package fails to build with Perl 5.28 (currently in experimental.)
> 
>   
> http://perl.debian.net/rebuild-logs/perl-5.28-throwaway/libdbd-csv-perl_0.5300-1/libdbd-csv-perl_0.5300-1_amd64-2018-06-05T12:44:50Z.build
> 
>  #   Failed test 'there was an attempt to free unreferenced scalar'
>  #   at /usr/share/perl/5.28/Test/Builder.pm line 158.
>  # Attempt to free unreferenced scalar: SV 0x55afb1de20c0, Perl interpreter: 
> 0x55afb02b7260 during global destruction.

>  Test Summary Report
>  ---
>  t/82_free_unref_scalar.t (Wstat: 0 Tests: 409 Failed: 4)
>Failed tests:  406-409
>Parse errors: Plan (1..405) must be at the beginning or end of the TAP 
> output
>  Bad plan.  You planned 405 tests but ran 409.
>  Files=24, Tests=1158,  4 wallclock secs ( 0.10 usr  0.03 sys +  3.32 cusr  
> 0.53 csys =  3.98 CPU)
>  Result: FAIL

This is now also https://rt.perl.org/Ticket/Display.html?id=133270

-- 
Niko Tyni   nt...@debian.org

Bug#901085: libur-perl: FTBFS with Perl 5.28: test failures

[Niko Tyni]

On Fri, Jun 08, 2018 at 10:58:07PM +0200, gregor herrmann wrote:
> On Fri, 08 Jun 2018 22:18:49 +0300, Niko Tyni wrote:
> 
> > Source: libur-perl
> > Version: 0.450-1
> > Severity: important
> > User: debian-p...@lists.debian.org
> > Usertags: perl-5.28-transition
> > 
> > This package fails to build with Perl 5.28 (currently in experimental.)

> Confirmed, and I can offer even more failures:

> # died: Error while autoloading with 'use 
> CmdTest::Thing::/build/libur-perl-0.460+ds/t//CmdTest/Thing/Create': Unknown 
> regexp modifier "/b" at (eval 234) line 1, at end of line

You seem to be testing 0.460+ds while sid has 0.450?
-- 
Niko

Bug#901085: libur-perl: FTBFS with Perl 5.28: test failures

[Niko Tyni]

On Fri, Jun 08, 2018 at 10:30:07PM +0300, Niko Tyni wrote:
> On Fri, Jun 08, 2018 at 10:18:49PM +0300, Niko Tyni wrote:
> > Source: libur-perl
> > Version: 0.450-1
> > Severity: important
> > User: debian-p...@lists.debian.org
> > Usertags: perl-5.28-transition

> >   #   Failed test 'content matches!'
> >   #   at t/URT/t/63c_view_with_subviews.t line 151.

> This looks similar to #901082 and doesn't seem to show in the CPAN
> test reports. I wonder what's different for us.

They are indeed the same issue, specific to newer versions of
JSON::PP. I've verified that it also happens with Perl 5.26 and
libjson-pp-perl 2.97001-1.

As with #901082, I still don't know why it doesn't show on CPAN testers.
Maybe JSON::XS masking it or something.
-- 
Niko

Bug#901082: libpgobject-type-json-perl: FTBFS with Perl 5.28: t/02-serialization.t failure

[Niko Tyni]

Control: retitle -1 libpgobject-type-json-perl: FTBFS with newer versions of 
JSON::PP: t/02-serialization.t failure
On Fri, Jun 08, 2018 at 11:14:35PM +0200, gregor herrmann wrote:
> On Fri, 08 Jun 2018 21:38:12 +0300, Niko Tyni wrote:
> 
> > Source: libpgobject-type-json-perl
> > Version: 2.01-1
> > Severity: important
> > User: debian-p...@lists.debian.org
> > Usertags: perl-5.28-transition
> > 
> > This package fails to build with Perl 5.28 (currently in experimental.)
> > 
> >   
> > http://perl.debian.net/rebuild-logs/perl-5.28-throwaway/libpgobject-type-json-perl_2.01-1/libpgobject-type-json-perl_2.01-1_amd64-2018-06-08T17:55:53Z.build
> > 
> >   #   Failed test 'Literal serializes correctly'
> >   #   at t/02-serialization.t line 49.
> >   #  got: '123'
> >   # expected: '"123"'
> >   # Looks like you failed 1 test of 23.
> >  
> > I don't see an upstream bug or a failing CPAN test report
> > but it fails consistently for me.
> 
> I can confirm the failure with 5.28, and it still passes the tests
> with 5.26.
> 
> No idea which JSON thing in which part adds/removes the quotation
> marks. All I can think of is the different version of JSON::PP but
> then the problem should show up elsewhere as well.

It's indeed to do with JSON::PP and not specific to Perl 5.28.

Reduced to

 perl -MJSON::PP -le '$p=123; "". $p; print 
JSON::PP->new->allow_nonref->encode($p)'

which gives the string "123" on older versions of JSON::PP and the number 123
on newer ones (at least 2.97001-1).

I don't know why CPAN testers don't see this. Maybe there's JSON::XS installed
underneath that masks it?
-- 
Niko Tyni   nt...@debian.org

Bug#901087: libcatalyst-plugin-session-store-dbi-perl: FTBFS: Base class package "Class::Data::Inheritable" is empty.

[Niko Tyni]

Source: libcatalyst-plugin-session-store-dbi-perl
Version: 0.16-2 
Severity: serious
Tags: buster sid

This package fails to build on current sid/amd64.  The autopkgtest
checks are broken too, though ci.debian.net hasn't noticed yet (seems
wedged somehow?)

It looks like it's just missing an explicit build and runtime dependency
on libclass-data-inheritable-perl. It was probably pulled in earlier by
libcatalyst-perl which dropped it in 5.90118-1:

 
https://salsa.debian.org/perl-team/modules/packages/libcatalyst-perl/commit/ba916b4447ac328c13f1fa872e9fd00fd8508e2c

   dh_auto_test
dh_auto_test: Compatibility levels before 9 are deprecated (level 8 in use)
make -j1 test TEST_VERBOSE=1
make[1]: Entering directory '/<>'
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" 
"-e" "undef *Test::Harness::Switches; test_harness(1, 'inc', 'blib/lib', 
'blib/arch')" t/01use.t t/02pod.t t/03podcoverage.t t/04critic.t t/04dbi.t 
t/05cdbi.t t/06dbic.t t/07dbic_schema.t

#   Failed test 'use Catalyst::Plugin::Session::Store::DBI;'
#   at t/01use.t line 3.
# Tried to use 'Catalyst::Plugin::Session::Store::DBI'.
# Error:  Base class package "Class::Data::Inheritable" is empty.
# (Perhaps you need to 'use' the module which defines that package first,
# or make that module available in @INC (@INC contains: 
/<>/inc /<>/blib/lib /<>/blib/arch 
/etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 
/usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .).
#  at /<>/blib/lib/Catalyst/Plugin/Session/Store/DBI.pm line 5.
# BEGIN failed--compilation aborted at 
/<>/blib/lib/Catalyst/Plugin/Session/Store/DBI.pm line 5.
# Compilation failed in require at t/01use.t line 3.
# BEGIN failed--compilation aborted at t/01use.t line 3.
# Looks like you failed 1 test of 1.
t/01use.t .. 
1..1
not ok 1 - use Catalyst::Plugin::Session::Store::DBI;
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 
t/02pod.t .. skipped: Test::Pod 1.14 required
t/03podcoverage.t .. skipped: Test::Pod::Coverage 1.04 required
t/04critic.t ... skipped: Critic test only for developers.
t/04dbi.t .. skipped: Catalyst::Plugin::Session::State::Cookie is 
required for this test
t/05cdbi.t . skipped: Catalyst::Plugin::Session::State::Cookie is 
required for this test
t/06dbic.t . skipped: Catalyst::Plugin::Session::State::Cookie is 
required for this test
t/07dbic_schema.t .. skipped: Catalyst::Plugin::Session::State::Cookie is 
required for this test

Test Summary Report
---
t/01use.t(Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=8, Tests=1,  1 wallclock secs ( 0.04 usr  0.01 sys +  0.47 cusr  0.05 
csys =  0.57 CPU)
Result: FAIL

-- 
Niko Tyni   nt...@debian.org

Bug#901085: libur-perl: FTBFS with Perl 5.28: test failures

[Niko Tyni]

On Fri, Jun 08, 2018 at 10:18:49PM +0300, Niko Tyni wrote:
> Source: libur-perl
> Version: 0.450-1
> Severity: important
> User: debian-p...@lists.debian.org
> Usertags: perl-5.28-transition
> 
> This package fails to build with Perl 5.28 (currently in experimental.)
> 
>   
> http://perl.debian.net/rebuild-logs/perl-5.28-throwaway/libur-perl_0.450-1/libur-perl_0.450-1_amd64-2018-06-08T17:53:04Z.build
> 
>   #   Failed test 'Response excpetion correctly reflects calling an undefined 
> function'
>   #   at t/URT/t/41_rpc_basic.t line 103.
>   # Looks like you failed 1 test of 40.
> 
> [...]
> 
>   #   Failed test 'Response excpetion correctly reflects calling an undefined 
> function'
>   #   at t/URT/t/42_rpc_between_processes.t line 126.
>   # Looks like you failed 1 test of 35.

These parts seem to be

 https://github.com/genome/UR/issues/136

>   #   Failed test 'content matches!'
>   #   at t/URT/t/63c_view_with_subviews.t line 151.
>   #  got: '{
>   #"id" : "Acme::Cat/And/owner_id/O:\u001dO:111\u001e",
>   #"members" : [
>   #   {
>   #  "id" : 222
>   #   },
>   #   {
>   #  "id" : 333
>   #   }
>   #]
>   # }
>   # '
>   # expected: '{
>   #"id" : "Acme::Cat/And/owner_id/O:\u001dO:111\u001e",
>   #"members" : [
>   #   {
>   #  "id" : "222"
>   #   },
>   #   {
>   #  "id" : "333"
>   #   }
>   #]
>   # }
>   # '

This looks similar to #901082 and doesn't seem to show in the CPAN
test reports. I wonder what's different for us.
-- 
Niko

Bug#901085: libur-perl: FTBFS with Perl 5.28: test failures

[Niko Tyni]

Source: libur-perl
Version: 0.450-1
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

This package fails to build with Perl 5.28 (currently in experimental.)

  
http://perl.debian.net/rebuild-logs/perl-5.28-throwaway/libur-perl_0.450-1/libur-perl_0.450-1_amd64-2018-06-08T17:53:04Z.build

  #   Failed test 'Response excpetion correctly reflects calling an undefined 
function'
  #   at t/URT/t/41_rpc_basic.t line 103.
  # Looks like you failed 1 test of 40.

[...]

  #   Failed test 'Response excpetion correctly reflects calling an undefined 
function'
  #   at t/URT/t/42_rpc_between_processes.t line 126.
  # Looks like you failed 1 test of 35.

[...]

  #   Failed test 'content matches!'
  #   at t/URT/t/63c_view_with_subviews.t line 151.
  #  got: '{
  #"id" : "Acme::Cat/And/owner_id/O:\u001dO:111\u001e",
  #"members" : [
  #   {
  #  "id" : 222
  #   },
  #   {
  #  "id" : 333
  #   }
  #]
  # }
  # '
  # expected: '{
  #"id" : "Acme::Cat/And/owner_id/O:\u001dO:111\u001e",
  #"members" : [
  #   {
  #  "id" : "222"
  #   },
  #   {
  #  "id" : "333"
  #   }
  #]
  # }
  # '

[...]

  Test Summary Report
  ---
  t/URT/t/41_rpc_basic.t  
(Wstat: 256 Tests: 40 Failed: 1)
Failed test:  27
Non-zero exit status: 1
  t/URT/t/42_rpc_between_processes.t  
(Wstat: 256 Tests: 35 Failed: 1)
Failed test:  24
Non-zero exit status: 1
  t/URT/t/63c_view_with_subviews.t
(Wstat: 512 Tests: 23 Failed: 2)
Failed tests:  11, 19
Non-zero exit status: 2
  Files=273, Tests=7420, 145 wallclock secs ( 0.96 usr  0.30 sys + 125.43 cusr  
8.59 csys = 135.28 CPU)
  Result: FAIL
 
-- 
Niko Tyni   nt...@debian.org

Bug#901082: libpgobject-type-json-perl: FTBFS with Perl 5.28: t/02-serialization.t failure

[Niko Tyni]

Source: libpgobject-type-json-perl
Version: 2.01-1
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

This package fails to build with Perl 5.28 (currently in experimental.)

  
http://perl.debian.net/rebuild-logs/perl-5.28-throwaway/libpgobject-type-json-perl_2.01-1/libpgobject-type-json-perl_2.01-1_amd64-2018-06-08T17:55:53Z.build

  #   Failed test 'Literal serializes correctly'
  #   at t/02-serialization.t line 49.
  #  got: '123'
  # expected: '"123"'
  # Looks like you failed 1 test of 23.
 
I don't see an upstream bug or a failing CPAN test report
but it fails consistently for me.
-- 
Niko Tyni   nt...@debian.org

Bug#901080: libtest-differences-perl: FTBFS with Perl 5.28: t/column-headers.t failure with verbose tests

[Niko Tyni]

Source: libtest-differences-perl
Version: 0.64-1
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

This package fails to build with perl 5.28.0-RC1 (currently in
experimental).

 
http://perl.debian.net/rebuild-logs/perl-5.28-throwaway/libtest-differences-perl_0.64-1/libtest-differences-perl_0.64-1_amd64-2018-06-08T17:52:42Z.build

This seems to be related to verbose test output. 

$ prove -b t/column-headers.t 
t/column-headers.t .. ok   
All tests successful.
Files=1, Tests=2,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.13 cusr  0.02 
csys =  0.17 CPU)
Result: PASS

$ prove -v -b t/column-headers.t 
t/column-headers.t .. 
not ok 1 - got expected error output
#   Failed test 'got expected error output'
#   at t/column-headers.t line 14.
#  got: '#   Failed test 'both the same'
# #   at t/script/default-headers line 8.
# # ++++
# # | Elt|Got |Expected|
# # ++++
# # |   0|{   |{   |
# # *   1|  foo => 'bar'  |  foo => 'baz'  *
# # |   2|}   |}   |
# # ++++
# # Looks like you failed 1 test of 1.
# '
# expected: '
# #   Failed test 'both the same'
# #   at t/script/default-headers line 8.
# # ++++
# # | Elt|Got |Expected|
# # ++++
# # |   0|{   |{   |
# # *   1|  foo => 'bar'  |  foo => 'baz'  *
# # |   2|}   |}   |
# # ++++
# # Looks like you failed 1 test of 1.
# '
not ok 2 - got expected error output
#   Failed test 'got expected error output'
#   at t/column-headers.t line 36.
#  got: '#   Failed test 'both the same'
# #   at t/script/custom-headers line 8.
# # ++++
# # | Elt|Lard|Chips   |
# # ++++
# # |   0|{   |{   |
# # *   1|  foo => 'bar'  |  foo => 'baz'  *
# # |   2|}   |}   |
# # ++++
# # Looks like you failed 1 test of 1.
# '
# expected: '
# #   Failed test 'both the same'
# #   at t/script/custom-headers line 8.
# # ++++
# # | Elt|Lard|Chips   |
# # ++++
# # |   0|{   |{   |
# # *   1|  foo => 'bar'  |  foo => 'baz'  *
# # |   2|}   |}   |
# # ++++
# # Looks like you failed 1 test of 1.
# '
1..2
# Looks like you failed 2 tests of 2.
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/2 subtests 

Test Summary Report
---
t/column-headers.t (Wstat: 512 Tests: 2 Failed: 2)
  Failed tests:  1-2
  Non-zero exit status: 2
Files=1, Tests=2,  1 wallclock secs ( 0.01 usr  0.01 sys +  0.14 cusr  0.01 
csys =  0.17 CPU)
Result: FAIL

-- 
Niko Tyni   nt...@debian.org

Bug#900832: libdbd-csv-perl: FTBFS with Perl 5.28: t/82_free_unref_scalar.t failure

[Niko Tyni]

On Tue, Jun 05, 2018 at 07:37:04PM +0200, gregor herrmann wrote:
> Control: forwarded -1 https://github.com/perl5-dbi/DBD-CSV/issues/4
> 
> On Tue, 05 Jun 2018 19:57:47 +0300, Niko Tyni wrote:
> 
> > Package: libdbd-csv-perl
> > Version: 0.5300-1
> > Severity: important
> > User: debian-p...@lists.debian.org
> > Usertags: perl-5.28-transition
> > Tags: upstream
> > 
> > This package fails to build with Perl 5.28 (currently in experimental.)
> > 
> >   
> > http://perl.debian.net/rebuild-logs/perl-5.28-throwaway/libdbd-csv-perl_0.5300-1/libdbd-csv-perl_0.5300-1_amd64-2018-06-05T12:44:50Z.build
> 
> > This can also be seen in some (but not all?) CPAN Tester reports for 5.28.*:
> >  http://www.cpantesters.org/cpan/report/75f506fe-63dd-11e8-8ea5-24704564fd0c
> >  http://www.cpantesters.org/cpan/report/6c6ace4c-60c8-11e8-8282-5b5a56c0b386
> > but I don't see an upstream bug.
> 
> Hm, builds for me (cowbuilder amd64), with 5.28 from experimental (or
> from perl.d.n which has a higher priority? I guess it's the same?)

Yeah, it's the same. I just had to disable experimental because of
APT resolver issues.

It seems to be transient, a rebuild worked fine (and seems to have trashed
the failing log, *grumble*).
-- 
Niko

Bug#900836: altree: FTBFS: fig2dev: not found

[Niko Tyni]

Source: altree
Version: 1.3.1-6
Severity: serious

This package fails to build from source on current sid/amd64.

   ==> building  fig/overview.pdftex <==
  /bin/sh: 1: fig2dev: not found
  make[4]: *** [LaTeX.mk:859: fig/overview.pdftex] Error 127
  make[4]: Leaving directory '/<>/Documentation'
  make[3]: *** [LaTeX.mk:805: manual.pdf_NEED_REBUILD] Error 2
  make[3]: Leaving directory '/<>/Documentation'
  make[2]: *** [LaTeX.mk:807: manual.pdf] Error 2
  make[2]: Leaving directory '/<>/Documentation'
  make[1]: *** [debian/rules:15: override_dh_auto_build] Error 2
  make[1]: Leaving directory '/<>'
  make: *** [debian/rules:8: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

This was probably caused by

  latex-make (2.2.4-1) unstable; urgency=medium
   .
 * Replace transfig by fig2dev (package renamed) (Closes: #866153)
 * Move some dependency to recommends (not required if not using
   figlatex.sty or PS)
 * New upstream version
   + Reorganize pdfswitch
   + Fix python synxtax to be valid in 2.7 and 3
 
which relaxed its dependency on fig2dev to a recommendation.

 
https://salsa.debian.org/debian/latex-make/commit/4ed84338b64b7bd2fff6d6764f3236625c092043

-- 
Niko Tyni   nt...@debian.org

Bug#900832: libdbd-csv-perl: FTBFS with Perl 5.28: t/82_free_unref_scalar.t failure

[Niko Tyni]

Package: libdbd-csv-perl
Version: 0.5300-1
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition
Tags: upstream

This package fails to build with Perl 5.28 (currently in experimental.)

  
http://perl.debian.net/rebuild-logs/perl-5.28-throwaway/libdbd-csv-perl_0.5300-1/libdbd-csv-perl_0.5300-1_amd64-2018-06-05T12:44:50Z.build

 #   Failed test 'there was an attempt to free unreferenced scalar'
 #   at /usr/share/perl/5.28/Test/Builder.pm line 158.
 # Attempt to free unreferenced scalar: SV 0x55afb1de20c0, Perl interpreter: 
0x55afb02b7260 during global destruction.
 #   Failed test 'there was an attempt to free unreferenced scalar'
 #   at /usr/share/perl/5.28/Test/Builder.pm line 158.
 # Attempt to free unreferenced scalar: SV 0x55afb1da52d0, Perl interpreter: 
0x55afb02b7260 during global destruction.
 #   Failed test 'there was an attempt to free unreferenced scalar'
 #   at /usr/share/perl/5.28/Test/Builder.pm line 158.
 # Attempt to free unreferenced scalar: SV 0x55afb1a88210, Perl interpreter: 
0x55afb02b7260 during global destruction.
 #   Failed test 'there was an attempt to free unreferenced scalar'
 #   at /usr/share/perl/5.28/Test/Builder.pm line 158.
 # Attempt to free unreferenced scalar: SV 0x55afb1a52e40, Perl interpreter: 
0x55afb02b7260 during global destruction.
 [...]
 Test Summary Report
 ---
 t/82_free_unref_scalar.t (Wstat: 0 Tests: 409 Failed: 4)
   Failed tests:  406-409
   Parse errors: Plan (1..405) must be at the beginning or end of the TAP output
 Bad plan.  You planned 405 tests but ran 409.
 Files=24, Tests=1158,  4 wallclock secs ( 0.10 usr  0.03 sys +  3.32 cusr  
0.53 csys =  3.98 CPU)
 Result: FAIL

This can also be seen in some (but not all?) CPAN Tester reports for 5.28.*:
 http://www.cpantesters.org/cpan/report/75f506fe-63dd-11e8-8ea5-24704564fd0c
 http://www.cpantesters.org/cpan/report/6c6ace4c-60c8-11e8-8282-5b5a56c0b386

but I don't see an upstream bug.
-- 
Niko Tyni   nt...@debian.org

Bug#900829: perl/experimental: FTBFS on hppa: t/re/regexp_qr_embed_thr.t failure

[Niko Tyni]

Source: perl
Version: 5.28.0~rc1-1
X-Debbugs-Cc: debian-h...@lists.debian.org

This package failed to build on hppa (only).

 
https://buildd.debian.org/status/fetch.php?pkg=perl=hppa=5.28.0%7Erc1-1=1528117759

 t/re/regexp_qr_embed_thr ... free(): 
invalid pointer
 FAILED--no leader found

Copying the debian-hppa list. Could somebody please investigate?
If it's a Perl regression from 5.26, I'm sure upstream would be
interested in fixing it before the 5.28.0 release.
-- 
Niko Tyni   nt...@debian.org

Bug#900702: libtest2-suite-perl: invalid alternative dependency on libtest-simple-perl

[Niko Tyni]

Package: libtest2-suite-perl
Version: 0.000114-1
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition
Affects: src:libhash-storediterator-perl

This package has a dependency on

 libtest-simple-perl (>= 1.302136) | perl (>= 5.27.12)

but Perl 5.28.0-RC1 (currently in NEW, soon in experimenta)
only bundles Test-Simple-1.302133.

This makes libhash-storediterator-perl fail its test suite with Perl
5.28 because its build dependencies don't pull in the newer Test-Simple
anymore.

 dh_auto_test -a
  perl Build test --verbose 1
  "test2_add_callback_testing_done" is not exported by the Test2::API module
  Can't continue after import errors at /usr/share/perl5/Test2/Tools/Spec.pm 
line 10.
  BEGIN failed--compilation aborted at /usr/share/perl5/Test2/Tools/Spec.pm 
line 10.
  Compilation failed in require at t/Hash-StoredIterator.t line 2.
  BEGIN failed--compilation aborted at t/Hash-StoredIterator.t line 2.
  t/Hash-StoredIterator.t .. 
  Dubious, test returned 255 (wstat 65280, 0xff00)
 
-- 
Niko Tyni   nt...@debian.org

Bug#900232: collectd: FTBFS: sed: can't read /usr/lib/pkgconfig/OpenIPMIpthread.pc: No such file or directory

[Niko Tyni]

Source: collectd
Version: 5.8.0-5
Severity: serious

This package fails to build from source on current sid.

It probably broke with

openipmi (2.0.25-1) unstable; urgency=medium

  [...]
  * move pkg-config files to a multiarch location. Thanks Helmut
closes: Bug#852739
  [...]

 -- Noël Köthe <n...@debian.org>  Fri, 18 May 2018 13:44:36 +0200


>From the build log:

  # This is a work-around for #474087 (broken openipmi .pc files).
  mkdir debian/pkgconfig
  sed -re 's/^(Requires:.*) pthread(.*)$/\1\2/' \
/usr/lib/pkgconfig/OpenIPMIpthread.pc \
> debian/pkgconfig/OpenIPMIpthread.pc
  sed: can't read /usr/lib/pkgconfig/OpenIPMIpthread.pc: No such file or 
directory
  make: *** [debian/rules:205: build-stamp] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
 
-- 
Niko Tyni   nt...@debian.org

Bug#900051: libgnupg-interface-perl: t/get_public_keys.t fails with gnupg2/2.2.7-1

[Niko Tyni]

Control: severity -1 serious

On Fri, May 25, 2018 at 11:05:58AM +0200, intrig...@debian.org wrote:
> Package: libgnupg-interface-perl
> Version: 0.52-9
> Severity: important
> X-Debbugs-Cc: d...@debian.org
 
> ci.d.n alerted us about a regression in libgnupg-interface-perl test
> suite since the upload of gnupg2/2.2.7-1:

>   Test Summary Report
>   ---
>   t/get_public_keys.t (Wstat: 0 Tests: 3 Failed: 1)
> Failed test:  3

This makes the package fail to build, so raising the severity.
-- 
Niko Tyni   nt...@debian.org

Bug#867081: autopkgtest: @ no longer pulls in packages with versioned Provides

[Niko Tyni]

On Thu, Apr 26, 2018 at 06:20:33PM +0200, Paul Gevers wrote:
> On Fri, 5 Jan 2018 05:01:55 +0100 gregor herrmann  wrote:
> > AFAIK, this bug is the last blocker for using versioned provides in
> > the perl world, which would be a big help for us.
> > 
> > Did you have a chance to take a look? Is there anything we could do
> > to help?
> 
> Coming up with a (even untested) patch (or better merge request on
> https://salsa.debian.org/ci-team/autopkgtest) would be a great way of
> moving this forward. Even a merge request that says, "# autopkgtest
> should now do something like 'apt blalbla' here" is already easier to
> discuss than by words in this thread.

Just submitted https://salsa.debian.org/ci-team/autopkgtest/merge_requests/14
for this. Hope that clears things up.
 
> By the way, do we have any feeling is the aspcud solver for APT does
> better (or worse) in this case? I am still wondering if we want that
> solver as a fall-back or if we could even use that by default (that
> would be more tempting if this bug would be solved by it as well).

No hunch here, sorry.
-- 
Niko

Bug#899110: perl: Provides entries in old versions of perl-modules-5.xx and libperl5.xx erroneously satisfy dependencies

[Niko Tyni]

On Sat, May 19, 2018 at 12:43:11PM +0300, Niko Tyni wrote:
> Package: perl
> Version: 5.26.2-4
> Severity: important
> User: debian-p...@lists.debian.org
> Usertags: hh2018

> The fix is probably to move the Provides (and probably Replaces and
> Breaks too?) to the perl binary package, which pulls in libperl5.xx
> and perl-modules-5.xx. I'm slightly worried about upgrades from stretch,
> but assuming there are no other dual life module changes than B::Debug
> for buster, the effect is probably minor.

On the other hand, it's possible to get the system in a state where
libperl5.26 and perl-modules-5.26 are installed but perl is not.
If we move the Breaks into perl, it becomes possible to have an older
version of a separate module package override a newer one in the standard
library (libperl5.26 or perl-modules-5.26), which is undesirable.

I'm therefore inclined to move just the Provides.
-- 
Niko Tyni   nt...@debian.org

Bug#899110: perl: Provides entries in old versions of perl-modules-5.xx and libperl5.xx erroneously satisfy dependencies

[Niko Tyni]

Package: perl
Version: 5.26.2-4
Severity: important
User: debian-p...@lists.debian.org
Usertags: hh2018

We currently have Provides entries for dual life module packages in
perl-modules-5.26 and libperl5.26, because the corresponding modules
are shipped in those packages. These packages are versioned and
coinstallable between major versions: a system upgraded to Perl 5.26
can still have perl-modules-5.24 and libperl5.24 installed in addition
to perl-modules-5.26 and libperl5.26.

This can be a problem when these Provides differ between the versioned
packages, as the old package lying around still satisfies dependencies
even though /usr/bin/perl doesn't see the modules.

We will be hitting this with Perl 5.28: B::Debug has been deprecated after
5.26, so perl-modules-5.26 Provides libb-debug-perl but perl-modules-5.28
will not. This made libdevel-cover-perl_1.29-2 fail to build in our
rebuild tests because perl-modules-5.26 was still lying around in the
build chroot so the separate libb-debug-perl did not get installed.

The fix is probably to move the Provides (and probably Replaces and
Breaks too?) to the perl binary package, which pulls in libperl5.xx
and perl-modules-5.xx. I'm slightly worried about upgrades from stretch,
but assuming there are no other dual life module changes than B::Debug
for buster, the effect is probably minor.
-- 
Niko Tyni   nt...@debian.org

Bug#899017: libprotocol-acme-perl: FTBFS with newer versions of ExtUtils::MakeMaker: cannot remove README.pod

[Niko Tyni]

Package: libprotocol-acme-perl
Version: 1.01-2
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition hh2018

This package fails to build with newer versions of ExtUtils::MakeMaker,
including those shipped in the Perl core with 5.27.11. This is because
EU::MM has changed its behaviour and is no longer installing README.pod
by default.

>From a build log at
 
http://perl.debian.net/rebuild-logs/perl-5.27-throwaway/libprotocol-acme-perl_1.01-2/libprotocol-acme-perl_1.01-2_amd64-2018-05-18T13:24:56Z.build

  WARNING: Older versions of ExtUtils::MakeMaker may errantly install 
README.pod as part of this distribution. It is recommended to avoid using this 
path in CPAN modules.
  [...]
  make[2]: Leaving directory '/<>'
  rm --verbose 
/<>/debian/libprotocol-acme-perl/usr/share/perl5/Protocol/README.pod
  rm: cannot remove 
'/<>/debian/libprotocol-acme-perl/usr/share/perl5/Protocol/README.pod':
 No such file or directory
  make[1]: *** [debian/rules:14: override_dh_auto_install] Error 1
 
I'll fix this shortly.
-- 
Niko Tyni   nt...@debian.org

Bug#898994: texinfo: Unescaped left brace in regex is deprecated, FTBFS with Perl 5.27/5.28

[Niko Tyni]

Package: texinfo
Version: 6.5.0.dfsg.1-2
Tags: patch
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition hh2018

In our first test rebuilds for the upcoming Perl 5.28, we noticed that
this package fails to build under Perl 5.27.11 (unfortunately not quite
yet in Debian experimental) because of a new deprecation message that
is not on the expected output list of the test suite.

The attached patch fixes this while keeping the package building
on current sid. Please consider applying it as that would unblock
further early testing of reverse build dependencies of texinfo.

A failed build log is at

  
http://perl.debian.net/rebuild-logs/perl-5.27/texinfo_6.5.0.dfsg.1-2/texinfo_6.5.0.dfsg.1-2+b2_amd64-2018-05-17T19:53:07Z.build

and the unexpected message in test output is

  Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
5.32), passed through in regex; marked by <-- HERE in 
m/^\s+@([[:alnum:]][[:alnum:]\-]*)({ <-- HERE })?\s*/ at 
../../tp/Texinfo/Parser.pm line 5481.

Thanks for your work on Debian, and greetings from the Debian Perl sprint
in Hamburg!
-- 
Niko Tyni   nt...@debian.org
>From 1f27900352e04ff4f19bec1c1e9635adad2be31c Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Fri, 18 May 2018 10:40:00 +0100
Subject: [PATCH] Fix unescaped left braces in regexps, deprecated since Perl
 5.27.8

This fixes test failures on recent Perl versions.
---
 tp/Texinfo/Parser.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tp/Texinfo/Parser.pm b/tp/Texinfo/Parser.pm
index dc32ca2..c577aa9 100644
--- a/tp/Texinfo/Parser.pm
+++ b/tp/Texinfo/Parser.pm
@@ -5478,11 +5478,11 @@ sub _parse_special_misc_command()
 }
   } elsif ($command eq 'clickstyle') {
 # REMACRO
-if ($line =~ /^\s+@([[:alnum:]][[:alnum:]\-]*)({})?\s*/) {
+if ($line =~ /^\s+@([[:alnum:]][[:alnum:]\-]*)(\{\})?\s*/) {
   $args = ['@'.$1];
   $self->{'clickstyle'} = $1;
   $remaining = $line;
-  $remaining =~ s/^\s+@([[:alnum:]][[:alnum:]\-]*)({})?\s*(\@(c|comment)((\@|\s+).*)?)?//;
+  $remaining =~ s/^\s+@([[:alnum:]][[:alnum:]\-]*)(\{\})?\s*(\@(c|comment)((\@|\s+).*)?)?//;
   $has_comment = 1 if (defined($4));
 } else {
   $self->line_error (sprintf($self->__(
-- 
2.17.0

Bug#898977: libnet-dns-zonefile-fast-perl: FTBFS: You are missing required modules for NSEC3 support

[Niko Tyni]

Package: libnet-dns-zonefile-fast-perl
Version: 1.24-3
Severity: serious
User: debian-p...@lists.debian.org
Usertags: autopkgtest hh2018

As noticed by ci.debian.net, this package recently started
failing its test suite on sid, also making it fail to build
from source.

 
https://ci.debian.net/packages/libn/libnet-dns-zonefile-fast-perl/unstable/amd64/

This was probably broken by 

-libnet-dns-sec-perl 1.03-1
+libnet-dns-sec-perl 1.08-1

>From my build log:

  You are missing required modules for NSEC3 support, line 1
  ...propagated at /<>/blib/lib/Net/DNS/ZoneFile/Fast.pm 
line 195.
  # Looks like your test exited with 2 just after 10.
  [...]
  Test Summary Report
  ---
  t/rr-dnssec.t (Wstat: 512 Tests: 10 Failed: 0)
Non-zero exit status: 2
Parse errors: Bad plan.  You planned 38 tests but ran 10.
 
-- 
Niko Tyni   nt...@debian.org

Bug#898946: sbuild: --make-binNMU should imply --no-arch-all

[Niko Tyni]

Package: sbuild
Version: 0.76.0-1
User: debian-p...@lists.debian.org
Usertags: hh2018

When building a binNMU, it makes no sense to build architecture:all
packages.  So the default of $build_arch_all=1 should be overridden in
this case, as if --no-arch-all had been passed.
-- 
Niko Tyni   nt...@debian.org

Bug#898561: libmarc-transform-perl: FTBFS with libyaml-perl >= 1.25-1 (test failures)

[Niko Tyni]

On Thu, May 17, 2018 at 01:16:17AM +0300, Niko Tyni wrote:
> On Sun, May 13, 2018 at 04:52:06PM +0200, gregor herrmann wrote:
> > Source: libmarc-transform-perl
> > Version: 0.003006-2
> > Severity: serious
> > Tags: upstream buster sid
> > Justification: fails to build from source
> 
> > libmarc-transform-perl's testsuite fails, both during build and
> > autopkgtest, with libyaml-perl >= 1.25-1:
> > 
> > 
> > perl Build test --verbose 1
> > Hexadecimal number > 0x non-portable at (eval 28) line 1.
> > Number found where operator expected at (eval 29) line 8, near ""I want) 
> > {$boolcond=1;$boolcondint=1; eval{ create("605"
> > (Missing operator before 605?)
> 
> This regressed with
> 
>  
> https://github.com/ingydotnet/yaml-pm/commit/a2231746743e9bb2939c063ab440ac658c226c4e

It looks to me like this is something that needs to be fixed in
MARC::Transform. It is about YAML quoting: documents like

---
foo: bar "foobar #"

get parsed differently with the new YAML.pm than the old one.
AFAICS MARC::Transform uses the hash sign as an escape character
and relies on the old behaviour.

  # old
  % perl -MYAML=Load -le 'print Load(qq(---\nfoo: bar "foobar #"))->{foo}'
  bar "foobar #"

  # new
  % perl -MYAML=Load -le 'print Load(qq(---\nfoo: bar "foobar #"))->{foo}'
  bar "foobar

The new behaviour seems to be consistent with YAML::XS, YAML::Tiny and
yaml.py in python3.

  % perl -MYAML::XS=Load -le 'print Load(qq(---\nfoo: bar "foobar #"))->{foo}'
  bar "foobar

  % perl -MYAML::Tiny=Load -le 'print Load(qq(---\nfoo: bar "foobar #"))->{foo}'
  bar "foobar

  % python3
  Python 3.6.5 (default, Apr  1 2018, 05:46:30) 
  [GCC 7.3.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import yaml
  >>> print(yaml.load('---\nfoo: bar "foobar #"')['foo'])
  bar "foobar

-- 
Niko Tyni   nt...@debian.org

Bug#898561: libmarc-transform-perl: FTBFS with libyaml-perl >= 1.25-1 (test failures)

[Niko Tyni]

On Sun, May 13, 2018 at 04:52:06PM +0200, gregor herrmann wrote:
> Source: libmarc-transform-perl
> Version: 0.003006-2
> Severity: serious
> Tags: upstream buster sid
> Justification: fails to build from source

> libmarc-transform-perl's testsuite fails, both during build and
> autopkgtest, with libyaml-perl >= 1.25-1:
> 
> 
>   perl Build test --verbose 1
> Hexadecimal number > 0x non-portable at (eval 28) line 1.
> Number found where operator expected at (eval 29) line 8, near ""I want) 
> {$boolcond=1;$boolcondint=1; eval{ create("605"
>   (Missing operator before 605?)

This regressed with

 
https://github.com/ingydotnet/yaml-pm/commit/a2231746743e9bb2939c063ab440ac658c226c4e

-- 
Niko Tyni   nt...@debian.org

Bug#898578: libyaml-perl/1.25-1 breaks rex/1.6.0-1 test suite (FTBFS and autopkgtest failure)

[Niko Tyni]

On Sun, May 13, 2018 at 11:17:58PM +0200, gregor herrmann wrote:
> Source: rex
> Version: 1.6.0-1
> Severity: serious
> Control: affects -1 src:libyaml-perl
> User: debian...@lists.debian.org
> Usertags: needs-update
> Tags: upstream buster sid
> Justification: fails to build from source

> YAML Error: Invalid element in map
>Code: YAML_LOAD_ERR_BAD_MAP_ELEMENT
>Line: 6
>Document: 1
>  at /usr/share/perl5/YAML/Loader.pm line 361.
> # Looks like your test exited with 255 just after 1.
> t/report.t ... 
> 1..3
> ok 1 - 'created report class' isa 'Rex::Report::Base'
> Dubious, test returned 255 (wstat 65280, 0xff00)
> Failed 2/3 subtests 

This can be reduced to

  % perl -MYAML=Load -e "Load(qq(---\nfoo:\n - 'a: b'))"
  YAML Error: Invalid element in map
 Code: YAML_LOAD_ERR_BAD_MAP_ELEMENT
 Line: 3
 Document: 1
   at /usr/share/perl5/YAML/Loader.pm line 361.

The YAML code is accepted by YAML::XS and YAML::Tiny, so this seems like
a probable regression in libyaml-perl to me.

Bisecting gives

 
https://github.com/ingydotnet/yaml-pm/commit/1976972cd399a7082f66bbad9c54ff95fa4f452a

as the first bad commit.
-- 
Niko Tyni   nt...@debian.org

Bug#898763: pinto: new upstream version available, version numbering issues

[Niko Tyni]

Package: pinto
Version: 0.97+dfsg-4
Severity: wishlist

The latest version of Pinto on CPAN is 0.14, released 2017-08-06.
It looks like there's a version numbering problem with the Debian
package, so presumably uscan et al. aren't spotting the new
upstream version.

The easy fix is probably to version the new one as 0.140 and
add some version mangling to debian/watch. Alternatively,
an epoch wouldn't seem wrong to me either in this case.

(I suspect that no one is actually using this module, given
the original maintainer has left and the package has a popcon
of nine installations...)
-- 
Niko Tyni   nt...@debian.org

Bug#898754: libcatalyst-controller-html-formfu-perl: FTBFS: Can't locate MooseX/Attribute/FormFuChained.pm in @INC

[Niko Tyni]

Source: libcatalyst-controller-html-formfu-perl
Version: 2.02-1
Severity: serious
User: debian-p...@lists.debian.org
Usertags: autopkgtest
Tags: fixed-upstream
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=125102

As noticed by ci.debian.net, this package fails its test suite on current
sid, making it fail to build from source.

 https://ci.debian.net/packages/libc/libcatalyst-controller-html-formfu-perl/

It looks like libhtml-formfu-perl_2.06-1 dropped the
MooseX::Attribute::FormFuChained module, but at least this package is
still using it. This seems to be fixed upstream in 2.03.

Once this is fixed, please also make libhtml-formfu-perl Break the earlier
versions so that partial upgrades cannot end up with broken combinations.
I hope this is also be enough to inform the britney autopkgtest integration
that the packages need to migrate together.

(I see libhtml-formfu-model-dbic-perl was similarly affected but is already
fixed; please consider adding a Breaks entry for that one too if applicable.)

>From my build log:

  [error] Caught exception in TestApp::Controller::Token->form "Can't locate 
MooseX/Attribute/FormFuChained.pm in @INC (you may need to install the 
MooseX::Attribute::FormFuChained module) (@INC contains: t/lib 
/<>/blib/lib /<>/blib/arch /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 
/usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at 
/<>/blib/lib/HTML/FormFu/Plugin/RequestToken.pm line 8.
  BEGIN failed--compilation aborted at 
/<>/blib/lib/HTML/FormFu/Plugin/RequestToken.pm line 8.
  Compilation failed in require at /usr/share/perl5/HTML/FormFu/Util.pm line 
390.
   at /usr/share/perl5/HTML/FormFu/Role/FormAndElementMethods.pm line 235."
  
  #   Failed test 'GET http://localhost/token/form'
  #   at t/01basic-token.t line 11.
  # 500
  # Internal Server Error
  
  #   Failed test 'Found form'
  #   at t/01basic-token.t line 15.
  Can't call method "find_input" on an undefined value at t/01basic-token.t 
line 17.
  # Tests were run but no plan was declared and done_testing() was not seen.
  # Looks like your test exited with 255 just after 2.
  t/01basic-token.t  
  not ok 1 - GET http://localhost/token/form
  not ok 2 - Found form
  Dubious, test returned 255 (wstat 65280, 0xff00)
  Failed 2/2 subtests 
 
-- 
Niko Tyni   nt...@debian.org

Bug#842464: use.t fixed with a whitelist

[Niko Tyni]

I've whitelisted the known warnings discussed in these bugs in alice_0.19-2,
for the benefit of getting autopkgtest checks to pass.

  % cat debian/tests/pkg-perl/use-whitelist 
  # see #898125 and #842464
  (Any::Moose|JSON::PP::Boolean)

-- 
Niko Tyni   nt...@debian.org

Bug#898125: alice: uses deprecated Any::Moose

[Niko Tyni]

Package: alice
Version: 0.19-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: any-moose autopkgtest

This package uses Any::Moose, which is deprecated. Since
libany-moose-perl_0.27-1, a deprecation warning is issued on usage.

  # perl -MApp::Alice -e1
  Any::Moose is deprecated. Please use Moo instead at 
/usr/share/perl5/App/Alice/MessageBuffer.pm line 3.

This (along with #842464) makes the package fail its autopkgtest checks, see

 http://ci.debian.net/packages/a/alice/unstable/amd64/

There's a related thread around

 https://lists.debian.org/debian-perl/2016/11/msg00035.html  

and I don't think we ever decided if the deprecation warning should be
disabled one way or another...

The primary bug of using Any::Moose still remains of course.
-- 
Niko Tyni   nt...@debian.org

Bug#877093: libdata-dpath-perl: autopkgtest failure: use.t: Name "main::INC" used only once: possible typo at /usr/share/perl/5.26/Safe.pm line 372.

[Niko Tyni]

On Thu, Sep 28, 2017 at 05:35:48PM +0200, gregor herrmann wrote:
> Package: libdata-dpath-perl
> Version: 0.57-1
> Severity: important
> User: debian-p...@lists.debian.org
> Usertags: autopkgtest

> autopkgtest-pkg-perl's use.t fails with:
> 
> #   Failed test ' /usr/bin/perl -w -M"Data::DPath" -e 1 2>&1 produced no 
> (non-whitelisted) output'
> #   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 108.

> # Name "main::INC" used only once: possible typo at 
> /usr/share/perl/5.26/Safe.pm line 372.

I've disabled use.t for now in 0.57-2 (though possibly just whitelisting
this specific warning would have been more appropriate.)
-- 
Niko

Bug#897963: libconfig-model-systemd-perl: FTBFS: Can't locate object method "exists" via package

[Niko Tyni]

Package: libconfig-model-systemd-perl
Version: 0.238.1-1
Severity: serious
User debian-p...@lists.debian.org
Usertags: autopkgtest

As noticed by ci.debian.net, this package has started failing its
test suite on current sid, probably because of

 -libconfig-model-perl 2.122-1
 +libconfig-model-perl 2.123-1

This also makes the package fail to build from source.

  
https://ci.debian.net/packages/libc/libconfig-model-systemd-perl/unstable/amd64/

  # dump_warnings parameter is DEPRECATED
  Backend error: Can't locate object method "exists" via package 
"wr_root/test-sshd-service/etc/systemd/system/sshd.service.d/override.conf" 
(perhaps you forgot to load 
"wr_root/test-sshd-service/etc/systemd/system/sshd.service.d/override.conf"?) 
at /usr/share/perl5/Config/Model/Backend/IniFile.pm line 37,  line 220.
  # Tests were run but no plan was declared and done_testing() was not seen.
  # Looks like your test exited with 25 just after 48.
  Dubious, test returned 25 (wstat 6400, 0x1900)
  All 48 subtests passed 
  
  Test Summary Report
  ---
  t/model_tests.t (Wstat: 6400 Tests: 48 Failed: 0)
Non-zero exit status: 25
Parse errors: No plan found in TAP output
  Files=2, Tests=50,  2 wallclock secs ( 0.03 usr  0.00 sys +  1.34 cusr  0.07 
csys =  1.44 CPU)
  Result: FAIL

-- 
Niko Tyni   nt...@debian.org

Bug#897962: libconfig-model-dpkg-perl: FTBFS: io_handle backend parameter is deprecated, please use file_path parameter

[Niko Tyni]

Package: libconfig-model-dpkg-perl
Version: 2.110
Severity: serious
User debian-p...@lists.debian.org
Usertags: autopkgtest

As noticed by ci.debian.net, this package has started failing its
test suite on current sid, probably because of

 -libconfig-model-perl 2.122-1
 +libconfig-model-perl 2.123-1

This also makes the package fail to build from source.

  https://ci.debian.net/packages/libc/libconfig-model-dpkg-perl/unstable/amd64/


  not ok 2 - test BDI warn on unittest instance
  
  #   Failed test 'test BDI warn on unittest instance'
  #   at t/dependency-check.t line 110.
  # Message 1 logged wasn't what we expected:
  #  category was 'BackendMgr'
  #   not 'User'
  #   message was 'io_handle backend parameter is deprecated, please use 
file_path parameter. (/usr/share/perl5/Config/Model/Backend/DpkgSyntax.pm:26)'
  #  not like '(?^:is unknown)'
  #  (Offending log call from line 546 in 
/usr/share/perl5/Config/Model/BackendMgr.pm)
  [...]
  Test Summary Report
  ---
  t/dependency-check.t   (Wstat: 256 Tests: 112 Failed: 1)
Failed test:  2
Non-zero exit status: 1
  t/model_tests.t(Wstat: 6912 Tests: 859 Failed: 27)
Failed tests:  3, 65, 77, 87, 186, 197, 239, 273, 288
  301, 326, 338, 350, 361, 386, 400, 435
  445, 460, 473, 486, 498, 523, 565, 579
  679, 693
Non-zero exit status: 27
  Files=12, Tests=1082, 75 wallclock secs ( 0.16 usr  0.02 sys + 73.54 cusr  
0.94 csys = 74.66 CPU)
  Result: FAIL
  
-- 
Niko Tyni   nt...@debian.org