Bug#900051: libgnupg-interface-perl: t/get_public_keys.t fails with gnupg2/2.2.7-1
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#900051: libgnupg-interface-perl: t/get_public_keys.t fails with gnupg2/2.2.7-1
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#902281: libgsl23: ABI breakage due to removed symbols
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#901807: libmath-gsl-perl: incompatible with GSL >= 2.5
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#900051: libgnupg-interface-perl: t/get_public_keys.t fails with gnupg2/2.2.7-1
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#902281: libgsl23: ABI breakage due to removed symbols
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#899021: libembperl-perl: FTBFS with Perl 5.27, unmaintained upstream
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
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#901807: libmath-gsl-perl: incompatible with GSL >= 2.5
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#901807: libmath-gsl-perl: incompatible with GSL >= 2.5
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#902281: libgsl23: ABI breakage due to removed symbols
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
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#887687: libsmokeqt4-dev: broken symlinks and causes qt4-perl FTBFS
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#899021: libembperl-perl: FTBFS with Perl 5.27, unmaintained upstream
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#902623: libgsl23: missing shlibs information for 2.5 symbols
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#902625: libmath-gsl-perl: needs a versioned dependency on libgsl23 (>= 2.5) or so
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#887687: libsmokeqt4-dev: broken symlinks and causes qt4-perl FTBFS
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#902655: auto-multiple-choice: Build-Depends on pdftk which is uninstallable
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#903245: pgbackrest: FTBFS everywhere: keys at index 8 do not match
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&suite=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#908323: libgtk3-perl: FTBFS: t/overrides.t failure
Source: libgtk3-perl Version: 0.034-1 Severity: serious User: debian-p...@lists.debian.org Usertags: autopkgtest Control: block 902557 with -1 As noticed by the autopkgtest checks on ci.debian.net, this package fails its test suite on current sid, making it also fail to build from source. https://ci.debian.net/data/autopkgtest/unstable/amd64/libg/libgtk3-perl/953602/log.gz Undefined subroutine &Gtk3::Gdk::PIXDATA_HEADER_LENGTH called at /<>/blib/lib/Gtk3.pm line 2119. # Looks like your test exited with 255 just after 162. [...] Test Summary Report --- t/overrides.t(Wstat: 65280 Tests: 162 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 233 tests but ran 162. Files=22, Tests=843, 5 wallclock secs ( 0.18 usr 0.03 sys + 4.58 cusr 0.46 csys = 5.25 CPU) Result: FAIL I'm guessing this regressed with gdk-pixbuf 2.38.0+dfsg-1 or so, but I haven't verified that (and the ci.debian.net machinery doesn't seem to have pinpointed it yet either.) -- Niko Tyni nt...@debian.org
Bug#844239: [request-tracker-maintainers] Bug#844239: request-tracker4: FTBFS: t/web/gnupg-select-keys-on-update.t failure
On Sun, Nov 13, 2016 at 07:13:54PM +0200, Niko Tyni wrote:
> Package: request-tracker4
> Version: 4.2.13-3
> Severity: serious
>
> This package failed to build on the 'all' buildd:
>
>
> https://buildd.debian.org/status/fetch.php?pkg=request-tracker4&arch=all&ver=4.2.13-3&stamp=1477439960
>
> # Failed test 'problems with passphrase'
> # at t/web/gnupg-select-keys-on-update.t line 40.
> # searched: "\x{0a}\x{0a}\x{0a}
> \x{0a} # can't find: "unable to sign outgoing email messages"
> # LCSS: " message"
> # LCSS context: "
Bug#844239: request-tracker4: FTBFS: t/web/gnupg-select-keys-on-update.t failure
Control: severity -1 important
Control: tag -1 unreproducible
On Mon, Nov 21, 2016 at 12:45:19AM +0100, Emilio Pozuelo Monfort wrote:
> On 20/11/16 21:32, Niko Tyni wrote:
> > On Sun, Nov 13, 2016 at 07:13:54PM +0200, Niko Tyni wrote:
> >> Package: request-tracker4
> >> Version: 4.2.13-3
> >> Severity: serious
> >>
> >> This package failed to build on the 'all' buildd:
> >>
> >>
> >> https://buildd.debian.org/status/fetch.php?pkg=request-tracker4&arch=all&ver=4.2.13-3&stamp=1477439960
> >>
> >> # Failed test 'problems with passphrase'
> >> # at t/web/gnupg-select-keys-on-update.t line 40.
> >> # searched: "\x{0a}\x{0a}\x{0a}
> >> \x{0a} >> # can't find: "unable to sign outgoing email messages"
> >> # LCSS: " message"
> >> # LCSS context: " >
> > I can't reproduce this locally, and neither can others. It obviously
> > worked for Dominic when he uploaded it.
> >
> > @w-b-team: could you please give it back to see if this persists on
> > the buildds?
> >
> > gb request-tracker4_4.2.13-3 . all
>
> Given back.
Thanks. That worked, so downgrading & tagging for now.
I see it's in NEW now, seems like an arch:all glitch in dak...
--
Niko
Bug#842753: FTBFS: test failures
On Sun, Nov 27, 2016 at 03:21:41PM +0100, gregor herrmann wrote: > On Tue, 01 Nov 2016 02:27:33 +0100, gregor herrmann wrote: > > > 0.690-1 fails to build all over the place with more or less failing > > tests: > > The status with subsequent uploads is: > > - success on my laptop, on the buildd. on ci.debian.net > - failures on the reproducible build servers > Invalid argument at > /build/1st/libnet-sip-perl-0.702/blib/lib/Net/SIP/Simple/Call.pm line 700, > <$read> line 2. > Does anyone have any ideas? Both about what happens and what we should do? It's the IO::Socket::IP / getaddrinfo / AI_ADDRCONFIG problem with systems that don't have any network interfaces other than lo, like pbuilder with USENETWORK=NO. See #759799 and #813796. I suspect IO::Socket::IP should be smarter here but I'm not sure. The workaround is presumably to pass GetAddrInfoFlags => 0 to IO::Socket::IP constructors, at least where the address family is explicitly spelled out. Sorry, no patch atm. -- Niko Tyni nt...@debian.org
Bug#919773: libdbd-sqlite3-perl FTBFS on mips: test failure
Control: tag -1 patch
On Sat, Jan 19, 2019 at 03:44:43PM +0200, Adrian Bunk wrote:
> Source: libdbd-sqlite3-perl
> Version: 1.62-1
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/fetch.php?pkg=libdbd-sqlite3-perl&arch=mips&ver=1.62-1&stamp=1546291045&raw=0
> Test Summary Report
> ---
> t/65_db_config.t(Wstat: 11 Tests: 76
> Failed: 0)
> Non-zero wait status: 11
> Parse errors: Bad plan. You planned 79 tests but ran 76.
Hi, a standalone test case is
perl -Iblib/lib -Iblib/arch -MDBI -e
'DBI->connect("dbi:SQLite:dbname=:memory:", "","", { sqlite_defensive => 1})'
and the attached patch fixes it for me.
--
Niko Tyni nt...@debian.org
>From daf3153f7ad67edd7071886c866fe790a7875427 Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Wed, 13 Feb 2019 20:42:06 +
Subject: [PATCH] Fix SQLITE_DBCONFIG_DEFENSIVE parameter types
The sqlite3_db_config() function with SQLITE_DBCONFIG_DEFENSIVE
takes two 'int' parameters, but Perl integers may have a different
size. Passing a 64-bit argument ('long long int') has been observed
to cause a segmentation fault on 32-bit big-endian platforms.
Bug: https://github.com/DBD-SQLite/DBD-SQLite/issues/45
Bug-Debian: https://bugs.debian.org/919773
---
dbdimp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dbdimp.c b/dbdimp.c
index ee08425..f4523d7 100644
--- a/dbdimp.c
+++ b/dbdimp.c
@@ -463,7 +463,7 @@ sqlite_db_login6(SV *dbh, imp_dbh_t *imp_dbh, char *dbname, char *user, char *pa
if (hv_exists(hv, "sqlite_defensive", 16)) {
val = hv_fetch(hv, "sqlite_defensive", 16, 0);
if (val && SvIOK(*val)) {
-sqlite3_db_config(imp_dbh->db, SQLITE_DBCONFIG_DEFENSIVE, SvIV(*val), 0);
+sqlite3_db_config(imp_dbh->db, SQLITE_DBCONFIG_DEFENSIVE, (int)SvIV(*val), 0);
}
}
}
--
2.11.0
Bug#923223: XML::Parser::parsefile() uses 2-argument open
On Wed, Feb 27, 2019 at 05:16:03PM +0100, gregor herrmann wrote: > 2) This fix would also suite the documentation of tv_imdb which says: > > tv_imdb --imdbdir [--help] [--quiet] >[--with-keywords] [--with-plot] >[--movies-only] [--actors NUMBER] >[--stats] [--debug] >[--output FILE] [FILE...] > > (so: pass FILE as an argument, not: read from STDIN, as the testsuite > does) The convention in manual pages is that optional arguments are denoted with brackets. My expections from just the above synopsis would be precisely the old behaviour (which the test suite apparently relies on): FILE is optional and STDIN is used if FILE is not supplied. > So it seems that XML::Parser's parsefile was able to handle '-' with > the 2-args-open() and fails to do so with the 3-args-open(). This is > a regression at first glance; although the documentation for open() > only mentions "<-" or "-" for STDIN in the (one-args- and) > two-args-form. But yeah, this has the potential to break more code > out there … Not sure I follow but I agree with the last sentence at least :) Clearly '-' needs special handling in XML::Parser if 2-arg open is converted to 3-arg open. (Sorry, no tuits for providing a better patch for XML::Parser.) -- Niko Tyni nt...@debian.org
Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?
On Mon, Feb 25, 2019 at 11:31:14AM +0100, Gianfranco Costamagna wrote: > Package: libmarc-charset-perl > Version: 1.35-2 > Severity: serious > > Hello, for some reasons the package testsuite started to fail in Ubuntu for > this package and xml-perl reverse-dependency, > only on armhf and i386. > This happened when the new gdbm has been uploaded and rebuilds issued. > > I traced down the problem to some differences in the march8/utf8 Table > generation, I don't know how serious it is, but the > testsuite seems completely broken on armhf and i386 at least, and utf8 cjk > conversion seems to return wrong values. > This is the reason for me opening this bug as "serious". Thanks for noticing this. I've confirmed that this happens on at least Debian sid/i386 too. It's a bit unfortunate that we only have autopkgtest checks on amd64, so this wasn't spotted earlier. > after a no-change rebuild of the package, and installing it, the test goes > passing ok: Looks like src:gdbm has broken compatibility with old databases, much like #910911. I haven't extracted the details so not reassigning yet, but copying Dmitry as a heads-up. As I argued in #910911, the big issue with such a backcompat break is that user databases become unusable, and libmarc-charset-perl breakage is just a small detail that could be properly solved with the recipe in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910911#63 : > - update perl to build-depend on libgdbm-dev (>= 1.18-2) and Break > older versions of libmarc-charset-perl (and any other perl packages > bundling GDBM or NDBM databases) > > - update libmarc-charset-perl (and any other perl packages bundling > GDBM or NDBM databases) to build-depend and depend on the newer perl > > I assume other language bindings like python-gdbm will need something > similar. But ideally gdbm would restore compatibility and libmarc-charset-perl would not need any changes. -- Niko Tyni nt...@debian.org
Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?
On Thu, Feb 28, 2019 at 12:06:18PM +, Dmitry Bogatov wrote: > > [2019-02-27 21:20] Niko Tyni > > > - update perl to build-depend on libgdbm-dev (>= 1.18-2) and Break > > > older versions of libmarc-charset-perl (and any other perl packages > > > bundling GDBM or NDBM databases) > > > > > > - update libmarc-charset-perl (and any other perl packages bundling > > > GDBM or NDBM databases) to build-depend and depend on the newer perl > > > > > > I assume other language bindings like python-gdbm will need something > > > similar. > > > > But ideally gdbm would restore compatibility and libmarc-charset-perl would > > not need any changes. > > I believe upstream release 1.8.1 introduced change, that > made it possible to read old /usr/lib/libmarc-charset-perl/Table. Am I > missing something in current situation? I thought so too, but this new bug highlights the fact that the fix does not work on all architectures. This was missed earlier because Debian does not have autopkgtest checks on !amd64, so we're relying on user bug reports and haven't got any so far. I've now verified that creating GDBM files with Perl, Python 2 or Python 3 on stretch i386 and then upgrading to buster renders the old databases unusable with the corresponding software in buster. I can file a separate bug against src:gdbm if that makes things clearer. > By the way, I disagree about compability. If all we need to make > everything good is just a binNMU, I'd rather not introduce any > patches/hacks/compatibility layers/etc. binNMU'ing libmarc-charset-perl will only fix libmarc-charset-perl, not unpackaged local user databases. If those become unusable on stretch -> buster upgrades with no way to recover them, that seems like a major problem. binNMU'ing libmarc-charset-perl does not fix partial upgrades where perl that uses a newer libgdbm is upgraded before libmarc-charset-perl. Hence the need for Breaks and versioned build dependencies that I listed. > By the way, it is sad that libmarc-charset-perl uses gdbm, not cdb. Are you referring to https://cr.yp.to/cdb.html ? I see there's a CDB_File Perl module in libcdb-file-perl but I'm not familiar with it. Seems worth a wishlist bug. -- Niko Tyni nt...@debian.org
Bug#923223: XML::Parser::parsefile() uses 2-argument open
On Thu, Feb 28, 2019 at 11:50:04AM +0100, Xavier wrote:
> Patch is ready in salsa repo:
>
> if (ref $file or $file eq '-') {
> open(FILE, $file) or croak "Couldn't open $file:\n$!";
> } else {
> open(FILE, '<', $file) or croak "Couldn't open $file:\n$!";
> }
>
> Successfully tested with xmltv. I propose to push as this for now to
> close bug before freeze. This patch fixes security bug since strange
> filename are no more interpreted and autopkgtest regression is fixed.
What kind of references did you encounter that made it necessary to
fall back to 2-arg open on all references? They might still stringify
to nasty things.
% perl -e 'package Foo; use overload q{""} => sub { return ${$_[0]} }; 1;
package main; my $s = "> /etc/passwd"; my $foo = bless \$s, "Foo"; print
qq(value: "$foo" ref:) . ref($foo) . "\n"; open(my $fh, $foo) or die $!'
value: "> /etc/passwd" ref:Foo
Permission denied at -e line 1.
That said, this does seem quite far fetched. I expect the patch fixes
all the command line injection issues caused by the 2-arg open just fine
and doesn't make things any worse in these more obscure scenarios.
--
Niko Tyni nt...@debian.org
Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?
On Mon, Feb 25, 2019 at 02:58:09PM +0100, Didier 'OdyX' Raboud wrote: > === Resolution === > > The Technical Committee resolves to decline to override the debootstrap > maintainers. > > Furthermore, using its §6.1.5 "Offering advice" power, the Technical > Committee considers that the desirable solution at the time of `bullseye` is: > > * W: `weak`: both directory schemes are allowed, but packages should only > be built on hosts with classical directory schemes (or in such > chroots) > > * M: `middle`: both directory schemes are allowed, and packages (including >official packages) can be built on hosts with either classical >or "merged `/usr`" directory schemes > > * H: `hard`: both directory schemes are allowed, but packages should only > be built on hosts with "merged `/usr`" directory schemes (or in > such chroots) > > * FD: Further Discussion > > === End Resolution === I vote: M > H > W > FD -- Niko Tyni nt...@debian.org signature.asc Description: PGP signature
Bug#923358: libdist-inkt-perl: Stuffs full path into tarball
On Sat, Mar 02, 2019 at 01:45:19PM +0100, Jonas Smedegaard wrote:
> reassign -1 perl
> retitle -1 perl: breaks libdist-inkt-perl
> thanks
I don't think this worked. Presumably you forgot to bcc
control@bdo.
But never mind that, I think it's libdist-inkt-perl that needs
to change. See below.
> Quoting Jonas Smedegaard (2019-02-26 22:41:00)
> > The command distinkt-dist is completely useless: Produces tarballs
> > containing full path (not paths relative to build dir), and then
> > fails.
> >
> > Upstream bug: https://github.com/tobyink/p5-dist-inkt/issues/3
>
> Seems to be a bug not in libdist-inkt-perl but in recent perl - or one
> of the libraries upgraded in lockstep with perl.
>
> Testsuite does not reveal the bug (it is quite minimal). The following,
> however, should prove that the bug is not in libdist-inkt-perl itself,
> as it succeeds on stretch but fails on buster:
>
> apt install libfile-chdir-perl libpath-finddev-perl libmoose-perl
> liblist-moreutils-perl libtype-tiny-perl libtypes-path-tiny-perl
> libpath-iterator-rule-perl libnamespace-autoclean-perl libdata-dump-perl
> libsoftware-license-perl libmodule-cpanfile-perl libtext-sprintfn-perl
> libcpan-changes-perl librdf-doap-lite-perl
> dget
> http://deb.debian.org/debian/pool/main/libd/libdist-inkt-perl/libdist-inkt-perl_0.024-4.dsc
> cd libdist-inkt-perl-0.024/examples/p5-acme-example-dist/
> PERL5LIB=../../lib perl ../../script/distinkt-dist
It looks like this is due to this Archive-Tar change:
2.28 08/06/2018 (madroach, ARC, OCBNET, ppisar)
- allow archiving with absolute pathnames - fixes 97748
Dist::Inkt::BuildTarball() puts absolute file names in the generated
archive, then renames them to relative ones.
$tar->add_files($abs);
$tar->rename(substr("$abs", 1), "$pfx/".$abs->relative($root));
This is relying on Archive::Tar having removed the first slash,
which is no longer a valid assumption.
I expect Dist::Inkt needs to adapt. Once that is done, we should
probably add a Breaks on the perl side for older versions. Please
file a separate bug about that.
--
Niko Tyni nt...@debian.org
Bug#923609: libgdbm6: binary incompatibility with old databases on at least i386
Package: libgdbm6
Version: 1.18.1-3
Severity: serious
Control: block 923238 with -1
GDBM databases created on stretch (gdbm 1.8.3-14) are not
compatible with libgdbm in sid/buster (1.18.1-3) on at least
the i386 (32-bit x86) architecture, probably also armhf.
This means that any local user databases will break on upgrade from
stretch to buster. It also breaks a few Debian packages that use GDBM
files (known affected are libmarc-charset-perl and command-not-found).
Bug #910911 discussed a similar problem that applied to all architectures.
It seems probable that the fix for that never worked on i386 but this
was just not detected earlier. The incompatibility was reported recently
in bug #923238 and was found because Ubuntu has a better architecture
coverage on their autopkgtest setup.
Below are steps to reproduce, testing with Python 2, Python 3, and Perl.
We make a trivial GDBM database with each, containing just one key "foo"
with the value "bar". After upgrading to buster on i386, none of these
databases can be read and "Malformed database file header" is reported.
On amd64, everything works fine after the upgrade.
# start from stretch
# apt install python-gdbm python3-gdbm perl
python - <<'EOF'
import gdbm
gdbm.open("py2-stretch.gdbm", "c")["foo"] = "bar"
EOF
python3 <<'EOF'
import dbm.gnu
dbm.gnu.open("py3-stretch.gdbm", "c")["foo"] = "bar"
EOF
perl <<'EOF'
use GDBM_File;
tie %h, q(GDBM_File), "perl-stretch.gdbm", &GDBM_WRCREAT, 0640
or die "opening GDBM file failed: $!";
$h{foo} = "bar"
EOF
# ls -l *.gdbm
-rw-r- 1 root root 12294 Mar 2 19:04 perl-stretch.gdbm
-rw-r--r-- 1 root root 12294 Mar 2 19:04 py2-stretch.gdbm
-rw-r--r-- 1 root root 12294 Mar 2 19:04 py3-stretch.gdbm
# upgrade to buster
# sed -i s/stretch/buster/ /etc/apt/sources.list && apt update && apt
dist-upgrade && apt install gdbmtool
# test with gdbmtool
# gdbmtool py2-stretch.gdbm fetch foo
gdbmtool: stdin:1.1-10: cannot open database py2-stretch.gdbm: Malformed
database file header
# gdbmtool py3-stretch.gdbm fetch foo
gdbmtool: stdin:1.1-10: cannot open database py3-stretch.gdbm: Malformed
database file header
# gdbmtool perl-stretch.gdbm fetch foo
gdbmtool: stdin:1.1-10: cannot open database perl-stretch.gdbm: Malformed
database file header
# similar results with any of these:
perl <<'EOF'
use GDBM_File;
tie %h, q(GDBM_File), "perl-stretch.gdbm", &GDBM_READER, 0640
or die "opening GDBM file failed: $!";
print $h{foo}, "\n";
EOF
python <<'EOF'
import gdbm
print(gdbm.open("py2-stretch.gdbm", "r")["foo"])
EOF
python3 <<'EOF'
import dbm.gnu
print(dbm.gnu.open("py3-stretch.gdbm", "r")["foo"])
EOF
--
Niko Tyni nt...@debian.org
Bug#923609: libgdbm6: binary incompatibility with old databases on at least i386
On Sat, Mar 02, 2019 at 09:34:49PM +0200, Niko Tyni wrote: > # ls -l *.gdbm > -rw-r- 1 root root 12294 Mar 2 19:04 perl-stretch.gdbm > -rw-r--r-- 1 root root 12294 Mar 2 19:04 py2-stretch.gdbm > -rw-r--r-- 1 root root 12294 Mar 2 19:04 py3-stretch.gdbm These are all bit-by-bit identical; I'm attaching the file in case that helps. -- Niko Tyni nt...@debian.org perl-stretch-i386.gdbm Description: Binary data
Bug#839218: nama: FTBFS: Failed 1/7 test programs. 0/91 subtests failed.Bad plan. You planned 126 tests but ran 57.
On Tue, Mar 21, 2017 at 04:05:43PM +0100, Balint Reczey wrote:
> It looks like not all regression are fixed after the re-implementation
> and the one affecting nama is one of them.
Some effort on a reduced test case would have been appreciated; the nama
code base is rather big.
While I haven't made it to the bottom of this yet, I note that there's
this code in lib/Audio/Nama/Effect.pm:
my $perl_version = $^V;
my ($minor_version) = $perl_version =~ /^v5\.(\d+)/;
my @new_list = grep { $_ ne $id } @ops_list;
#say "new_list: @new_list";
if ($minor_version <= 14)
{$track->{ops} = [ @new_list ] }
else { @{ $track->{ops} } = @new_list}
and if I patch that to take the <= 14 code path, the segfault goes away
here and all tests pass. What's the history behind this version check?
--
Niko Tyni nt...@debian.org
Bug#903966: wine-development: FTBFS on most architectures
Package: wine-development
Version: 3.12-2
Severity: serious
This package failed to build on the build daemons
on amd64 and arm*.
On amd64:
row_server_p.c: In function '__finally_IWineRowServer_AddRefRows_Stub':
row_server_p.c:7751:35: error: passing argument 1 of
'__frame->_StubMsg.pfnFree' discards 'const' qualifier from pointer target type
[-Werror=discarded-array-qualifiers]
__frame->_StubMsg.pfnFree(__frame->rghRows);
^~~
row_server_p.c:7751:35: note: expected 'void *' but argument is of type
'const HROW (*)[] {aka const long unsigned int (*)[]}'
On arm*:
ptrace.c:167:12: error: 'get_ptrace_tid' defined but not used
[-Werror=unused-function]
static int get_ptrace_tid( struct thread *thread )
--
Niko Tyni nt...@debian.org
Bug#887687: libsmokeqt4-dev: broken symlinks and causes qt4-perl FTBFS
Control: tag -1 patch
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
>
> ...
> make[3]: *** No rule to make target '/usr/lib/libsmokeqt3support.so', needed
> by 'blib/arch/auto/Qt3Support4/Qt3Support4.so'. Stop.
> make[3]: Leaving directory '/build/1st/qt4-perl-4.8.4/obj-x86_64-linux-gnu'
> CMakeFiles/Makefile2:473: recipe for target
> 'qt3support/src/CMakeFiles/perl_qt3support4.dir/all' failed
> make[2]: *** [qt3support/src/CMakeFiles/perl_qt3support4.dir/all] Error 2
> make[2]: Leaving directory '/build/1st/qt4-perl-4.8.4/obj-x86_64-linux-gnu'
> Makefile:143: recipe for target 'all' failed
> make[1]: *** [all] Error 2
> make[1]: Leaving directory '/build/1st/qt4-perl-4.8.4/obj-x86_64-linux-gnu'
>
>
> /usr/lib/libsmokeqt3support.so and several other .so
> links are broken.
I believe the attached patch fixes this, allowing qt4-perl to build
again in my tests.
Please consider applying this as an interim fix even if qt4-perl is
going away, to unblock the Perl 5.28 transition.
--
Niko Tyni nt...@debian.org
>From 8d0f96e2b91a03476f509d75f6066d29d0124066 Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Tue, 17 Jul 2018 20:34:05 +0300
Subject: [PATCH] Disable building the libraries that aren't packaged anymore
This removes broken symlinks in libsmokeqt4-dev, making qt4-perl build
again at least for now.
Closes: #887687
---
CMakeLists.txt | 19 ---
1 file changed, 19 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 440dc3f..1ab7439 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -43,36 +43,17 @@ macro_log_feature(QSCINTILLA_FOUND "QScintilla2" "QScintilla2 libraries" "http:/
set(QTDEFINES_FILE ${CMAKE_CURRENT_BINARY_DIR}/qtdefines)
-if(WITH_QT3_SUPPORT)
-add_definitions(-DQT3_SUPPORT)
-endif(WITH_QT3_SUPPORT)
-
add_subdirectory(qtcore)
macro_optional_add_bindings(QT_QTNETWORK_FOUND "QtNetwork" qtnetwork)
-macro_optional_add_bindings(QT_QTDBUS_FOUND "QtDBus" qtdbus)
-macro_optional_add_bindings(QT_QTDECLARATIVE_FOUND "QtDeclarative" qtdeclarative)
macro_optional_add_bindings(QT_QTGUI_FOUND "QtGui" qtgui)
-macro_optional_add_bindings(QT_QTSVG_FOUND "QtSvg" qtsvg)
-macro_optional_add_bindings(QT_QTSQL_FOUND "QtSql" qtsql)
macro_optional_add_bindings(QT_QTXML_FOUND "QtXml" qtxml)
-macro_optional_add_bindings(QT_QTXMLPATTERNS_FOUND "QtXmlPatterns" qtxmlpatterns)
-macro_optional_add_bindings(QT_QTOPENGL_FOUND "QtOpenGL" qtopengl)
-macro_optional_add_bindings(QT_QTWEBKIT_FOUND "QtWebKit" qtwebkit)
-macro_optional_add_bindings(QT_QTSCRIPT_FOUND "QtScript" qtscript)
-macro_optional_add_bindings(QT_QTUITOOLS_FOUND "QtUiTools" qtuitools)
macro_optional_add_bindings(QT_QTTEST_FOUND "QtTest" qttest)
macro_optional_add_bindings(QT_QTMULTIMEDIA_FOUND "QtMultimedia" qtmultimedia)
-macro_optional_add_bindings(QT_QT3SUPPORT_FOUND "Qt3Support" qt3support)
-macro_optional_add_bindings(QT_QTHELP_FOUND "QtHelp" qthelp)
-
-macro_optional_add_bindings(PHONON_FOUND "Phonon" phonon)
macro_optional_add_bindings(QSCINTILLA_FOUND "QScintilla" qsci)
macro_optional_add_bindings(Qwt5_Qt4_FOUND "Qwt" qwt)
-macro_optional_add_bindings(QIMAGEBLITZ_FOUND "QImageBlitz" qimageblitz)
-
--
2.18.0
Bug#629405: debconf: libqtgui4-perl based frontend might need to be removed
On Sat, Jul 21, 2018 at 01:00:28AM +0200, gregor herrmann wrote: > On Fri, 29 Jun 2018 10:37:34 +0300, Niko Tyni wrote: > > > 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. > > I think this bug can be closes with debconf 1.5.68 if I'm reading its > changelog correctly? Not quite but we're close now (thanks again Colin!). The old Qt frontend and the corresponding build dependency on libqtgui4-perl are still there as Colin is seeking testers for the new frontend. See #631769 . I note that there's also a patch now for #887687 in src:smokeqt, so src:qt4-perl life support could still be extended a bit if necessary. -- Niko Tyni nt...@debian.org
Bug#904727: highlight: FTBFS: dh_installexamples: Cannot find (any matches for) "extras/plugins/dokuwiki/*"
Source: highlight Version: 3.41-1 Severity: serious Tags: ftbfs Control: block 902557 with -1 This package fails to build from source on current sid/amd64. dh_installexamples dh_installexamples: Cannot find (any matches for) "extras/plugins/dokuwiki/*" (tried in .) dh_installexamples: Cannot find (any matches for) "extras/plugins/movabletype/*" (tried in .) dh_installexamples: Cannot find (any matches for) "extras/plugins/wordpress/*" (tried in .) dh_installexamples: Cannot find (any matches for) "examples/swig/testmod.pl" (tried in .) make: *** [debian/rules:8: binary] Error 2 Looking at the history at https://tests.reproducible-builds.org/debian/history/highlight.html it regressed around 2017-07-01 which coincides with debhelper (11.3.5) unstable; urgency=medium . * Dh_Lib.pm: Introduce a new glob_expand error handler to better emulate the old style glob code to fail when a non-glob entry in the config file is missing. * dh_installdocs: Use the new glob_expand error handler to restore the behaviour to that of debhelper/10.5.1 and older. Thanks to Christoph Berg for reporting the issue. (Closes: #902355) * dh_installexamples: Ditto. [...] -- Niko Tyni nt...@debian.org
Bug#904735: libbio-samtools-perl: FTBFS: recompile with -fPIC
Source: libbio-samtools-perl Version: 1.43-1 Severity: serious Tags: ftbfs Control: block 902557 with -1 This package fails to build on sid/amd64: x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -shared -L/usr/local/lib -fstack-protector-strong -o blib/arch/auto/Bio/DB/Sam/Sam.so lib/Bio/DB/Sam.o c_bin/bam2bedgraph.o -L/usr/lib -lbam -lpthread -lz /usr/bin/ld: /usr/lib/libbam.a(bam_aux.o): relocation R_X86_64_PC32 against symbol `bam_verbose' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status error building blib/arch/auto/Bio/DB/Sam/Sam.so from lib/Bio/DB/Sam.o c_bin/bam2bedgraph.o at /usr/share/perl/5.26/ExtUtils/CBuilder/Base.pm line 321. dh_auto_build: perl Build returned exit code 2 make: *** [debian/rules:4: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 It seems to have built OK on test.reproducible-builds.org on 2018-07-12, so could be a binutils regression rather than libbam-dev? -- Niko Tyni nt...@debian.org
Bug#904737: uwsgi: FTBFS: unable to build gccgo plugin
Source: uwsgi Version: 2.0.17.1-2 Severity: serious Tags: ftbfs Control: block 902557 with -1 This package fails to build on sid/amd64: CFLAGS="-g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro" python uwsgiconfig.py -v --plugin plugins/gccgo debian/buildconf/uwsgi-plugin.ini gccgo x86_64-linux-gnu-gcc: error trying to exec 'go1': execvp: No such file or directory using profile: debian/buildconf/uwsgi-plugin.ini detected include path: ['/usr/lib/gcc/x86_64-linux-gnu/8/include', '/usr/local/include', '/usr/lib/gcc/x86_64-linux-gnu/8/include-fixed', '/usr/include/x86_64-linux-gnu', '/usr/include'] *** uWSGI building and linking plugin plugins/gccgo *** x86_64-linux-gnu-gcc -pthread -fPIC -shared -o ./gccgo_plugin.so -I. -O2 -I. -Wall -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -DUWSGI_HAS_IFADDRS -DUWSGI_ZLIB -DUWSGI_LOCK_USE_MUTEX -DUWSGI_EVENT_USE_EPOLL -DUWSGI_EVENT_TIMER_USE_TIMERFD -DUWSGI_EVENT_FILEMONITOR_USE_INOTIFY -DUWSGI_PCRE -DUWSGI_ROUTING -DUWSGI_CAP -DUWSGI_UUID -DUWSGI_VERSION="\"2.0.17.1-debian\"" -DUWSGI_VERSION_BASE="2" -DUWSGI_VERSION_MAJOR="0" -DUWSGI_VERSION_MINOR="17" -DUWSGI_VERSION_REVISION="1" -DUWSGI_VERSION_CUSTOM="\"debian\"" -DUWSGI_YAML -DUWSGI_LIBYAML -DUWSGI_JSON -DUWSGI_SSL -I/usr/include/libxml2 -DUWSGI_XML -DUWSGI_XML_LIBXML2 -DUWSGI_PLUGIN_DIR="\".\"" -g -Dgccgo_plugin=gccgo_plugin -Wno-error plugins/gccgo/gccgo_plugin.c plugins/gccgo/uwsgi.go -Wl,-z,relro -lgo *** unable to build gccgo plugin *** make: *** [debian/rules:450: debian/stamp-uwsgi-plugin-gccgo] Error 1 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 -- Niko Tyni nt...@debian.org
Bug#904740: libtext-bidi-perl: FTBFS: 'fribidi_uint32' undeclared
Source: libtext-bidi-perl Version: 2.12-1 Severity: serious Tags: ftbfs Control: block 902557 with -1 This package fails to build on sid/amd64: "/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- private.bs blib/arch/auto/Text/Bidi/private/private.bs 644 x86_64-linux-gnu-gcc -c -I/usr/include/fribidi -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DVERSION=\"2.12\" -DXS_VERSION=\"2.12\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.26/CORE" private.c private.c: In function '_wrap_get_par_direction': private.c:2392:41: error: 'fribidi_uint32' undeclared (first use in this function); did you mean 'fribidi_shape'? result = fribidi_get_par_direction((fribidi_uint32 const *)arg1,arg2); ^~ fribidi_shape private.c:2392:41: note: each undeclared identifier is reported only once for each function it appears in private.c:2392:55: error: expected ')' before 'const' result = fribidi_get_par_direction((fribidi_uint32 const *)arg1,arg2); ~ ^~ ) [...] make[1]: *** [Makefile:355: private.o] Error 1 make[1]: Leaving directory '/<>' dh_auto_build: make -j1 returned exit code 2 make: *** [debian/rules:22: build] Error 2 I see src:fribidi has had a couple of uploads recently, this probably regressed with those. -- Niko Tyni nt...@debian.org
Bug#904740: libtext-bidi-perl: FTBFS: 'fribidi_uint32' undeclared
On Sat, Jul 28, 2018 at 02:24:51AM +0200, gregor herrmann wrote: > Control: tag -1 + confirmed upstream > Control: forwarded -1 https://github.com/mkamensky/Text-Bidi/issues/8 > > On Fri, 27 Jul 2018 14:58:11 +0300, Niko Tyni wrote: > > > This package fails to build on sid/amd64: > [..] > > I see src:fribidi has had a couple of uploads recently, this > > probably regressed with those. > > Upstream acknowledges in the above cited issue that the module > currently doesn't work with fribidi >= 1. It works for me if I make sure that private.c gets regenerated (eg. by putting it to debian/clean) and add the patch from https://rt.cpan.org/Ticket/Display.html?id=124618 -- Niko
Bug#904914: libhtml-gumbo-perl: fails to build on mips
Control: tag -1 patch
Control: forwarded -1 https://github.com/ruz/HTML-Gumbo/pull/5/commits
On Sun, Jul 29, 2018 at 03:38:37PM +0200, gregor herrmann wrote:
> Source: libhtml-gumbo-perl
> Version: 0.18-1
> Severity: serious
> Tags: upstream ftbfs
> Justification: fails to build from source (but built successfully in the past)
> libhtml-gumbo-perl 0.18-1 fails to build on mips, both on the buildd
> and on a porterbox, due to a test failure:
>
> https://buildd.debian.org/status/fetch.php?pkg=libhtml-gumbo-perl&arch=mips&ver=0.18-1&stamp=1532865257&raw=0
>
>dh_auto_test -a
> perl Build test --verbose 1
>
> # Failed test at t/callback.t line 57.
> # Structures begin differing at:
> # $got->[4] = Does not exist
> # $expected->[4] = ARRAY(0x566c5308)
> # Looks like you failed 1 test of 3.
The attached patch seems to fix this. There's no regressing code change,
0.17-1 fails in the same way.
--
Niko Tyni nt...@debian.org
>From cc8d278d2737f55ac2ef262c89849597c5929f90 Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Mon, 30 Jul 2018 15:08:10 +0300
Subject: [PATCH] tree_to_callback: don't check document nodes for void
elements
walk_tree() will call this with PHG_ELEMENT_END for both document
and element nodes, but only the latter ones have tag types defined.
This fixes test failures seen on 32-bit big endian systems
such as mips and powerpc, when a document node happened
to have a valid (void) tag code at the same offset, triggering
an early return.
Bug-Debian: https://bugs.debian.org/904914
---
lib/HTML/Gumbo.xs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/HTML/Gumbo.xs b/lib/HTML/Gumbo.xs
index b7613a6..97dfc43 100644
--- a/lib/HTML/Gumbo.xs
+++ b/lib/HTML/Gumbo.xs
@@ -401,7 +401,7 @@ tree_to_callback(pTHX_ PerlHtmlGumboType type, GumboNode* node, void* ctx) {
dSP;
SV* cb = (SV*) ctx;
-if ( type == PHG_ELEMENT_END && PHG_IS_VOID_ELEMENT(node->v.element.tag) )
+if ( type == PHG_ELEMENT_END && node->type == GUMBO_NODE_ELEMENT && PHG_IS_VOID_ELEMENT(node->v.element.tag) )
return;
ENTER;
--
2.18.0
Bug#904735: libbio-samtools-perl: FTBFS: recompile with -fPIC
Control: retitle -1 libbam-dev: no longer built with -fPIC Control: reassign -1 libbam-dev 0.1.19-3 On Fri, Jul 27, 2018 at 01:12:01PM +0300, Niko Tyni wrote: > Source: libbio-samtools-perl > Version: 1.43-1 > Severity: serious > Tags: ftbfs > Control: block 902557 with -1 > > This package fails to build on sid/amd64: > > x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro > -shared -L/usr/local/lib -fstack-protector-strong -o > blib/arch/auto/Bio/DB/Sam/Sam.so lib/Bio/DB/Sam.o c_bin/bam2bedgraph.o > -L/usr/lib -lbam -lpthread -lz > /usr/bin/ld: /usr/lib/libbam.a(bam_aux.o): relocation R_X86_64_PC32 against > symbol `bam_verbose' can not be used when making a shared object; recompile > with -fPIC > /usr/bin/ld: final link failed: bad value > collect2: error: ld returned 1 exit status > error building blib/arch/auto/Bio/DB/Sam/Sam.so from lib/Bio/DB/Sam.o > c_bin/bam2bedgraph.o at /usr/share/perl/5.26/ExtUtils/CBuilder/Base.pm line > 321. > dh_auto_build: perl Build returned exit code 2 > make: *** [debian/rules:4: build] Error 2 > dpkg-buildpackage: error: debian/rules build subprocess returned exit > status 2 This is because libbam-dev is no longer built with -fPIC, even though /usr/share/doc/libbam-dev/README.Debian still claims so. Reassigning. > It seems to have built OK on test.reproducible-builds.org on 2018-07-12, > so could be a binutils regression rather than libbam-dev? This was on i386, where missing -fPIC doesn't cause a link error (I think), so a bad guess on my part. BTW, the Vcs-* entries of samtools-legacy don't seem to allow unauthenticated access. Could you please fix this. https://salsa.debian.org/med-team/samtools-legacy -- Niko Tyni nt...@debian.org
Bug#897790: liboping: ftbfs with GCC-8
Control: tag -1 patch On Fri, May 04, 2018 at 12:22:19PM +, Matthias Klose wrote: > Package: src:liboping > Version: 1.10.0-2 > Severity: normal > Tags: sid buster > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-8 > The package fails to build in a test rebuild on at least amd64 with > gcc-8/g++-8, but succeeds to build with gcc-7/g++-7. The > severity of this report will be raised before the buster release. There's an upstream patch for this at https://github.com/octo/liboping/commit/18ca43507b351f339ff23062541ee8d58e813a53 -- Niko Tyni nt...@debian.org
Bug#904737: uwsgi: FTBFS: unable to build gccgo plugin
Control: tag -1 patch On Fri, Jul 27, 2018 at 01:46:24PM +0300, Niko Tyni wrote: > Source: uwsgi > Version: 2.0.17.1-2 > Severity: serious > Tags: ftbfs > Control: block 902557 with -1 > > This package fails to build on sid/amd64: > *** unable to build gccgo plugin *** A trivial fix is to replace gccgo-7 with gccgo-8 or just gccgo in the build dependencies. Could you please look into this, it's one of the last few remaining blockers for the Perl 5.28 transition. -- Niko Tyni nt...@debian.org
Bug#897724: collectd: ftbfs with GCC-8
On Fri, May 04, 2018 at 12:21:07PM +, Matthias Klose wrote: > Package: src:collectd > Version: 5.8.0-4 > Severity: normal > Tags: sid buster > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-8 > src/aggregation.c: In function 'agg_lookup_class_callback': > src/aggregation.c:204:20: error: '%s' directive output may be truncated > writing 14 bytes into a region of size between 0 and 127 > [-Werror=format-truncation=] > "%s-%s", tmp_plugin, AGG_FUNC_PLACEHOLDER); > cc1: all warnings being treated as errors Dear maintainers, this is one of the few remaining blockers for the Perl 5.28 transition. I've forwarded the issue upstream at https://github.com/collectd/collectd/issues/2883 I see Fedora is configuring with --disable-werror, so these warnings does not cause a build failure there. Would you consider doing that until a solution is implemented upstream? Thanks for your work on Debian, -- Niko Tyni nt...@debian.org
Bug#905913: Don't install into testing
On Sat, Aug 11, 2018 at 05:09:15PM +0200, Jörg Frings-Fürst wrote: > Source: sane-backends > Version: 1.0.27-1~experimental6 > Severity: serious > don't install 1.0.27-1~experimental6 into testing. Hi, could you please elaborate a bit on the plan for this? The current state in sid is going to clash with other transitions. It looks like 1.0.27-1~experimental6 entered sid accidentally, do you intend to revert that or go ahead with the transition? Thanks for your work on Debian, -- Niko Tyni nt...@debian.org
Bug#906222: gdal: undeterministically broken python packages
Source: gdal
Version: 2.3.1+dfsg-2
Severity: serious
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
it looks like the build system of the gdal Python bindings will
undeterministically produce truncated or broken files.
I noticed this while debugging a python-stetl test rebuild failure
on Perl 5.28. The underlying reason was that our local rebuild of
gdal for Perl 5.28 was broken like this:
# python -c 'import gdal'
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/dist-packages/gdal.py", line 2, in
from osgeo.gdal import deprecation_warn
File "/usr/lib/python2.7/dist-packages/osgeo/__init__.py", line 21, in
_gdal = swig_import_helper()
File "/usr/lib/python2.7/dist-packages/osgeo/__init__.py", line 17, in
swig_import_helper
_mod = imp.load_module('_gdal', fp, pathname, description)
ImportError: dynamic module does not define init function (init_gdal)
Looking into it further, I rebuilt gdal ten times on current sid/amd64
and got
- seven almost empty Python 2.7 _gdal.x86_64-linux-gnu.so files
- five empty Python 2.7 ogr.py files
- two empty Python 2.7 gdal_array.py files
- three empty Python 2.7 gdal_array.py files
- four empty Python 3 ogr.py files
- three empty Python 3 gdal_array.py files (in different builds)
- four empty Python 3 gdal.py files
--rw-r--r-- root/root525360 2018-07-31 13:37
./usr/lib/python2.7/dist-packages/osgeo/_gdal.x86_64-linux-gnu.so
+-rw-r--r-- root/root 13952 2018-07-31 13:37
./usr/lib/python2.7/dist-packages/osgeo/_gdal.x86_64-linux-gnu.so
and so forth.
It looks like at least the s390x build in sid is broken this way, with
-rw-r--r-- root/root 0 2018-07-31 12:37
./usr/lib/python2.7/dist-packages/osgeo/gdal_array.py
The test history at
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gdal.html
seems rather sad too.
I haven't located the cause yet; diffing build logs makes me wonder if
the 'generate' target of swig/python/GNUmakefile is getting erroneously
run in parallel with targets compiling the files that 'generate' modifies.
So maybe it's just a case of fragility on parallel builds?
--
Niko Tyni nt...@debian.org
Bug#905913: Don't install into testing
On Wed, Aug 15, 2018 at 10:47:22AM +0200, Jörg Frings-Fürst wrote: > > On Sat, Aug 11, 2018 at 05:09:15PM +0200, Jörg Frings-Fürst wrote: > > > Source: sane-backends > > > Version: 1.0.27-1~experimental6 > > > Severity: serious > > > don't install 1.0.27-1~experimental6 into testing. > Sorry for this. I have ask my sponsor to upload into experimental, but > it was uploaded into sid. A day after upload I was in vacation. Oh well, accidents happen :) > If it's ok, I can prepare today an release without the experimental tag > and ask my sponsor to upload it. The experimental tag isn't that much of an issue in itself. The main thing now is that reverse dependencies of libsane have to be rebuilt for libsane1. That needs to be coordinated with the release team. Please ask the release team how they would prefer this to be handled. -- Niko Tyni nt...@debian.org
Bug#906222: gdal: undeterministically broken python packages
On Mon, Aug 20, 2018 at 08:52:04PM +0200, Sebastiaan Couwenberg wrote: > So far I've not been able to reproduce this issue. > > How massively parallel are your builds? Looks like they have parallel=4. But the sid s390x build that encountered this only has parallel=2. https://buildd.debian.org/status/fetch.php?pkg=gdal&arch=s390x&ver=2.3.1%2Bdfsg-2&stamp=1533051542 Also, the sid amd64 binNMU build today seems to have hit this with parallel=4. https://buildd.debian.org/status/fetch.php?pkg=gdal&arch=amd64&ver=2.3.1%2Bdfsg-2%2Bb1&stamp=1534766543 -rw-r--r-- root/root 0 2018-08-20 11:32 ./usr/lib/python2.7/dist-packages/osgeo/gdal_array.py -- Niko
Bug#916375: apache2: Segmentation fault when mod_perl.so is loaded
Control: reassign -1 libmariadbclient18 10.1.37-0+deb9u1 This reportedly regressed with DSA-4341-1, reassigning to the correct package. -- Niko Tyni nt...@debian.org
Bug#918435: Bug #918435 in libgit-raw-perl marked as pending
Control: tag -1 pending Hello, Bug #918435 in libgit-raw-perl reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/perl-team/modules/packages/libgit-raw-perl/commit/39a5e0ca9046cfe7153db125c10608288c1de031 Backport upstream patch disabling a failing test due to libgit2 changes Closes: #918435 (this message was generated automatically) -- Greetings https://bugs.debian.org/918435
Bug#918435: libgit-raw-perl: FTBFS (failing tests)
On Sun, Jan 06, 2019 at 12:14:33AM +, Santiago Vila wrote: > Package: src:libgit-raw-perl > Version: 0.79-5 > Severity: serious > Tags: ftbfs > Test Summary Report > --- > t/33-worktree.t (Wstat: 512 Tests: 11 Failed: 0) > Non-zero exit status: 2 > Parse errors: No plan found in TAP output This was fixed upstream with https://github.com/jacquesg/p5-Git-Raw/commit/30f7a4491ab453d28ae1fa1b393fcd023f6c344d which is in upstream 0.82 and just removes the failing test. However, the newer upstream releases rely on libgit2 bundled API changes, so they are not suitable for Debian (which uses the system libgit2, not the bundled one) at this point. Therefore I've just uploaded a backported targeted fix for this issue, versioned as 0.79-6. -- Niko Tyni nt...@debian.org
Bug#918623: dizzy: Your vendor has not defined OpenGL macro GL_FRAMEBUFFER_EXT
Control: reassign -1 libopengl-perl 0.7000+dfsg-1 Control: affects -1 dizzy On Mon, Jan 07, 2019 at 09:12:27PM +0100, Bernhard Übelacker wrote: > Package: dizzy > Version: 0.3-3 > Severity: normal > this is the output of dizzy when started > on a desktop PC with amd graphics > or a qemu amd64 VM, both running current buster: > > $ dizzy > GPU features: [x] GLSL [x] FBOs > Your vendor has not defined OpenGL macro GL_FRAMEBUFFER_EXT, used at > /usr/share/perl5/Dizzy/TextureGenerator.pm line 101. > > I tested the same qemu VM with stretch and there it was working. > After some tests I found it stopped working when > libopengl-perl in version 0.7000+dfsg-1 > entered testing in 2017-08-12. > But I am uncertain if the fault is > in package dizzy or libopengl-perl. I looked at this a bit, and I assume it regressed with https://sourceforge.net/p/pogl/code/ci/ad3508bed030b856a8c36c4900727bbd838212dd/ If I read this correctly, the constants used to be provided unconditionally, but are now excluded if things like NO_GL_EXT_framebuffer_object are defined. Now, our Debian packaging has https://sources.debian.org/src/libopengl-perl/0.7000+dfsg-1/debian/patches/add-gl_exclude.h/ which "adds back" these exclusions, apparently for xvfb compatibility and making the build result independent of the build machine hardware. My tentative conclusion is that the exclusions we patch in now affect things that they didn't earlier, and that we need to fix this on the libopengl-perl side somehow. So reassigning. Copying Florian, who added the patch back in 2012. Any interest in looking at this? :) -- Niko Tyni nt...@debian.org
Bug#919829: libatteanx-store-sparql-perl: FTBFS (failing tests)
On Sun, Jan 20, 2019 at 12:19:21AM +, Santiago Vila wrote: > Package: src:libatteanx-store-sparql-perl > Version: 0.010-1 > Severity: serious > Tags: ftbfs > Test Summary Report > --- > t/plan.t (Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > Parse errors: No plan found in TAP output > Files=2, Tests=1, 7 wallclock secs ( 0.05 usr 0.01 sys + 5.78 cusr 0.51 > csys = 6.35 CPU) > Result: FAIL $ perl -Iblib/lib t/plan.t Can't apply Attean::API::Model to AtteanX::Model::SPARQL - missing count_quads_estimate at /usr/share/perl5/Moo/Role.pm line 280. Compilation failed in require at t/plan.t line 5. BEGIN failed--compilation aborted at t/plan.t line 5. This seems to have broken with libattean-perl 0.020-1. The upstream changelog states: (Update) Expose count_quads_estimate method at the model level. -- Niko Tyni nt...@debian.org
Bug#919006: FTBFS: test failure with new DBD::SQLite
Control: tag -1 patch
On Fri, Jan 11, 2019 at 05:37:52PM +0100, gregor herrmann wrote:
> Source: libclass-dbi-plugin-type-perl
> Version: 0.02-8
> Severity: serious
> Tags: upstream buster sid ftbfs
> Justification: fails to build from source
> Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=128135
> ok 1 - use Class::DBI::Plugin::Type;
> not ok 2 - notes is text
> # Failed test 'notes is text'
> # at t/1.t line 28.
> # undef
> # doesn't match '(?^:text|blob)'
>From Class::DBI::Plugin::Type::import() :
@hash{@{$sth->{NAME}}} =
map {
my $info = scalar $self->db_Main->type_info($_);
if ($info) { $info->{TYPE_NAME} }
else { $_ } # Typeless databases (SQLite)
}
@{$sth->{TYPE}};
Looks like type_info() now returns more than it used to: with the older
libdbd-sqlite3-perl it gave just 'undef', but now it gives (somewhat
unhelpful)
$VAR1 = {
'CASE_SENSITIVE' => undef,
'MAXIMUM_SCALE' => undef,
'NUM_PREC_RADIX' => undef,
'MINIMUM_SCALE' => undef,
'SQL_DATETIME_SUB' => undef,
'NULLABLE' => undef,
'LOCAL_TYPE_NAME' => undef,
'LITERAL_PREFIX' => undef,
'INTERVAL_PRECISION' => undef,
'TYPE_NAME' => undef,
'DATA_TYPE' => 0,
'FIXED_PREC_SCALE' => undef,
'AUTO_UNIQUE_VALUE' => undef,
'SEARCHABLE' => undef,
'UNSIGNED_ATTRIBUTE' => undef,
'CREATE_PARAMS' => undef,
'COLUMN_SIZE' => undef,
'LITERAL_SUFFIX' => undef,
'SQL_DATA_TYPE' => undef
};
I'm not sure how intentional this is, but it seems to have changed
in DBD-SQLite 1.61_02 as noted in the upstream bug.
https://metacpan.org/diff/file?target=ISHIGAKI/DBD-SQLite-1.61_02/&source=ISHIGAKI/DBD-SQLite-1.61_01/
Checking that the value is defined seems to fix / work around this,
as seen in the attached patch. I'm not totally sure that this
won't break things on other DBD implementations though.
--
Niko Tyni nt...@debian.org
>From b8cd9d0d853fdca08488f261d5856801e2ce2771 Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Mon, 21 Jan 2019 21:07:59 +0200
Subject: [PATCH] Fix compatibility with DBD-SQLite >= 1.61_02
type_info() now returns an array of mostly undefined values, breaking
the t/1.t tests. Add a guard for definedness so we still take the other
branch in this case.
Bug: https://rt.cpan.org/Public/Bug/Display.html?id=128135
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919006
---
Type.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Type.pm b/Type.pm
index 688ca35..986fecd 100644
--- a/Type.pm
+++ b/Type.pm
@@ -29,7 +29,7 @@ sub import {
@hash{@{$sth->{NAME}}} =
map {
my $info = scalar $self->db_Main->type_info($_);
-if ($info) { $info->{TYPE_NAME} }
+if ($info and defined $info->{TYPE_NAME}) { $info->{TYPE_NAME} }
else { $_ } # Typeless databases (SQLite)
}
@{$sth->{TYPE}};
--
2.20.1
Bug#795741: libopengl-perl: FTBFS: undefined symbol: glResizeBuffersMESA
Package: libopengl-perl Version: 0.6704+dfsg-1 Severity: serious X-Debbugs-Cc: libgl1-mesa-...@packages.debian.org As noticed by the reproducible builds CI setup, this package fails to build on current sid. # Failed test 'require OpenGL;' # at t/00_require.t line 3. # Tried to require 'OpenGL'. # Error: Can't load '/«BUILDDIR»/libopengl-perl-0.6704+dfsg/blib/arch/auto/OpenGL/OpenGL.so' for module OpenGL: /«BUILDDIR»/libopengl-perl-0.6704+dfsg/blib/arch/auto/OpenGL/OpenGL.so: undefined symbol: glResizeBuffersMESA at /usr/lib/x86_64-linux-gnu/perl/5.20/DynaLoader.pm line 187. It looks like mesa 10.6 dropped a bunch of symbols without changing the SONAME. Copying the maintainer. Was this an intentional ABI break? On current sid, without rebuilding anything: # PERL_DL_NONLAZY=1 perl -e 'use OpenGL' Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.20/auto/OpenGL/OpenGL.so' for module OpenGL: /usr/lib/x86_64-linux-gnu/perl5/5.20/auto/OpenGL/OpenGL.so: undefined symbol: glResizeBuffersMESA at /usr/lib/x86_64-linux-gnu/perl/5.20/DynaLoader.pm line 187. This is also http://sourceforge.net/p/pogl/bugs/21/ https://bugzilla.redhat.com/show_bug.cgi?id=1224294 which have the attached patch that deletes references to the removed symbols. Even with that applied, I suppose at least some Breaks entries would be in order? -- Niko Tyni nt...@debian.org >From e83b9048c43cbcbdaeb287dd571ab7e277e19979 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Mon, 8 Jun 2015 17:06:52 +0200 Subject: [PATCH] Delete functions removed from Mesa MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit mesa-libGL between 10.6.0-0.devel.5.51e3453 and 10.6.0-0.devel.6.5a55f68 removed these functions: glWindowPos4dMESA glWindowPos4iMESA glWindowPos3iMESA glWindowPos2dMESA glWindowPos2iMESA glWindowPos3dMESA glResizeBuffersMESA <https://bugzilla.redhat.com/show_bug.cgi?id=1224738> <https://bugzilla.redhat.com/show_bug.cgi?id=1224294> Signed-off-by: Petr Písař --- pogl_gl_Vert_Multi.xs | 54 --- 1 file changed, 54 deletions(-) diff --git a/pogl_gl_Vert_Multi.xs b/pogl_gl_Vert_Multi.xs index e360e5c..4e8a010 100644 --- a/pogl_gl_Vert_Multi.xs +++ b/pogl_gl_Vert_Multi.xs @@ -359,60 +359,6 @@ glEdgeFlagPointerEXT_oga(oga) #endif -#ifdef GL_MESA_window_pos - -#// glWindowPos2iMESA($x, $y); -void -glWindowPos2iMESA(x, y) - GLint x - GLint y - -#// glWindowPos2dMESA($x, $y); -void -glWindowPos2dMESA(x, y) - GLdoublex - GLdoubley - -#// glWindowPos3iMESA($x, $y, $z); -void -glWindowPos3iMESA(x, y, z) - GLint x - GLint y - GLint z - -#// glWindowPos3dMESA($x, $y, $z); -void -glWindowPos3dMESA(x, y, z) - GLdoublex - GLdoubley - GLdoublez - -#// glWindowPos4iMESA($x, $y, $z, $w); -void -glWindowPos4iMESA(x, y, z, w) - GLint x - GLint y - GLint z - GLint w - -#// glWindowPos4dMESA($x, $y, $z, $w); -void -glWindowPos4dMESA(x, y, z, w) - GLdoublex - GLdoubley - GLdoublez - GLdoublew - -#endif - -#ifdef GL_MESA_resize_buffers - -#// glResizeBuffersMESA(); -void -glResizeBuffersMESA() - -#endif - #ifdef GL_ARB_draw_buffers #//# glDrawBuffersARB_c($n,(CPTR)buffers); -- 2.1.0
Bug#789093: libapache2-authcookie-perl: FTBFS: test failures
On Wed, Jun 17, 2015 at 07:50:28PM +, Damyan Ivanov wrote: > Package: libapache2-authcookie-perl > Version: 3.22-1 > Severity: serious > > libapache2-authcookie-perl fails to build from source in an up to date > pbuilder: > > Test Summary Report > --- > t/real.t (Wstat: 10240 Tests: 49 Failed: 40) > Failed tests: 3-26, 28-34, 39, 41-44, 46-49 > Non-zero exit status: 40 This was broken by libapache2-mod-perl2_2.0.9~rc1-1, which integrated the upstream fix for https://rt.cpan.org/Public/Bug/Display.html?id=87620 (Apache-Test: add -D APACHE24 if running under httpd 2.4). Unfortunately the upstream fix ended up using APACHE2_4 instead of APACHE24 which we had adopted from an earlier version of the fix, so the Apache-Test in jessie is now using a different definition from the rest of the world. The current libapache2-authcookie-perl package is relying on the jessie behaviour (APACHE24). While the fix for libapache2-authcookie-perl is a trivial sed -i s/APACHE24/APACHE2_4/ debian/patches/authcookie-httpd-24.patch I suppose it at least needs an additional versioned build-dependency on libapache2-mod-perl2 (>= 2.0.9~rc1-1). I wonder if it would be worthwhile to update libapache2-mod-perl2 in stable to define both APACHE24 and APACHE2_4, so that people could start using the latter now rather than have their configs broken by the next release. I also wonder how much this really matters, given Apache-AuthCookie is apparently the only one that needs this. -- Niko Tyni nt...@debian.org
Bug#795589: libmath-planepath-perl: FTBFS: Failed 1/103 test programs. 1/34754 subtests failed.
Control: reopen 795589 On Sat, Aug 15, 2015 at 05:26:44PM +0200, Salvatore Bonaccorso wrote: > On Sat, Aug 15, 2015 at 04:53:19PM +0200, gregor herrmann wrote: > > Control: tag -1 + unreproducible > > On Sat, 15 Aug 2015 14:34:29 +0100, Chris Lamb wrote: > > > > > Source: libmath-planepath-perl > > > Version: 119-1 > > > Severity: serious > > > Justification: fails to build from source > > > > > > Dear Maintainer, > > > > > > libmath-planepath-perl fails to build from source on unstable/amd64: > > > t/Base-Digits.t (Wstat: 0 Tests: 80 Failed: 1) > > > Failed test: 48 > > Can someone reprocude it or does anybody have an idea? > > It still builds fine for me (amd64 sid cowbuilder). > > JFTR, as well here for me both with pbuilder (amd64, sid, cowbuilder) > and with an sbuild chroot (but only done two testbuilds). Works for me too, but the failure is reproducible (heh) on the reproducible.debian.net CI system. Interesting. I'm reopening this for now, hope that's OK. I note that the failing logs have this extra line: # round_up_pow(555906056624,3) i=33 post 555906056623,16677181699666569 want 33,34 which comes from t/Base-Digits.t:198 and shows the failure point. So for some reason the failing builds thinks that the next power of three from 3^33 + 1 (which is 555906056624) is 3^33 (555906056623) rather than 3^34 (16677181699666569). This is clearly wrong. I see that the Changes file lists round_up_pow() as a new feature, so it's plausible that there's a problem with it. Maybe a CPU-specific rounding difference in float handling? reproducible.debian.net lists the CPU type as 'AMD Opteron 62xx class CPU' FWIW. I'm Cc'ing the upstream author, Kevin Ryde, who's probably interested. A current log of a failing build can be found at https://reproducible.debian.net/rb-pkg/unstable/amd64/libmath-planepath-perl.html I'll see if I can arrange access to a host where the failure is reproducible. -- Niko Tyni nt...@debian.org
Bug#795206: FTBFS: test failures (with libdate-manip-perl)
On Tue, Aug 11, 2015 at 08:39:24PM +0200, gregor herrmann wrote: > Source: libgedcom-perl > Version: 1.19-2 > Severity: serious > Tags: upstream > Justification: fails to build from source > Forwarded: https://github.com/pjcj/Gedcom.pm/issues/5 > As discovered by the reproducible build team and already noted in the > upstream bug tracker (and confirmed locally with and without > libdate-manip-perl installed), this package fails its tests if > libdate-manip-perl is installed: This goes away if the test suite is run with DATE_MANIP=DM5 in the environment. I see this enables an older Date::Manip interface that is no longer maintained, All the failures I'm seeing are of the type t/basic.t .. 9/1501 # Test 1464 got: "2 DATE Monday, 17th August 2015\n" (t/Basic.pm at line 32 fail #1464) # Expected: "2 DATE AFT1989\n" # t/Basic.pm line 32 is: &Test::ok(@a) t/basic.t .. Failed 1/1501 subtests -- Niko Tyni nt...@debian.org
Bug#795741: libopengl-perl: FTBFS: undefined symbol: glResizeBuffersMESA
On Sun, Aug 16, 2015 at 09:56:52PM +0200, Julien Cristau wrote: > On Sun, Aug 16, 2015 at 17:57:00 +0300, Niko Tyni wrote: > > As noticed by the reproducible builds CI setup, this package fails to > > build on current sid. > > > > # Failed test 'require OpenGL;' > > # at t/00_require.t line 3. > > # Tried to require 'OpenGL'. > > # Error: Can't load > > '/«BUILDDIR»/libopengl-perl-0.6704+dfsg/blib/arch/auto/OpenGL/OpenGL.so' > > for module OpenGL: > > /«BUILDDIR»/libopengl-perl-0.6704+dfsg/blib/arch/auto/OpenGL/OpenGL.so: > > undefined symbol: glResizeBuffersMESA at > > /usr/lib/x86_64-linux-gnu/perl/5.20/DynaLoader.pm line 187. > > > > It looks like mesa 10.6 dropped a bunch of symbols without changing the > > SONAME. Copying the maintainer. Was this an intentional ABI break? > No symbols from libGL other than the ones listed in the Linux libGL ABI > spec should be referenced directly, applications should go through > glXGetProcAddress (or eglGetProcAddress). Are these the only things > broken in libopengl-perl? Thanks. I'm afraid I don't know anything about libGL :) I know that the build succeeds with the patch, but I suppose you're asking if it references other symbols not listed in the ABI. I found https://www.opengl.org/registry/ABI/ but failed to distill a list of blessed symbols from that so far. Is there an easy list / tool to check this? -- Niko Tyni nt...@debian.org
Bug#795758: libmessage-passing-perl: FTBFS under some locales (eg. fr_CH.UTF-8)
Control: forwarded -1 https://rt.cpan.org/Public/Bug/Display.html?id=99463 On Sun, Aug 16, 2015 at 05:31:18PM +0100, Chris Lamb wrote: > Source: libmessage-passing-perl > Version: 0.116-1 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs locale > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > libmessage-passing-perl fails to build from source on unstable/amd64 > under some locales (eg. LANG="fr_CH.UTF-8"): > t/role_connectionmanager.t (Wstat: 512 Tests: 15 Failed: 2) > Failed tests: 12-13 > Non-zero exit status: 2 Are you sure it's a locale issue? I can't reproduce it here. This is also https://rt.cpan.org/Public/Bug/Display.html?id=99463 and upstream says there: It might be a timing problem because the timeout is set to 0.1 seconds and the async code waits for 0.11 seconds which might be too close and trigger a race condition. which sounds plausible. -- Niko
Bug#795741: libgl1-mesa-glx: please Break libopengl-perl (<< 0.6704+dfsg-2)
clone 795741 -1 retitle -1 libgl1-mesa-glx: please Break libopengl-perl (<< 0.6704+dfsg-2) severity -1 normal reassign -1 libgl1-mesa-glx 10.6.4-1 thanks On Sun, Aug 16, 2015 at 05:57:00PM +0300, Niko Tyni wrote: > Package: libopengl-perl > Version: 0.6704+dfsg-1 > Severity: serious > X-Debbugs-Cc: libgl1-mesa-...@packages.debian.org > > As noticed by the reproducible builds CI setup, this package fails to > build on current sid. > > # Failed test 'require OpenGL;' > # at t/00_require.t line 3. > # Tried to require 'OpenGL'. > # Error: Can't load > '/«BUILDDIR»/libopengl-perl-0.6704+dfsg/blib/arch/auto/OpenGL/OpenGL.so' for > module OpenGL: > /«BUILDDIR»/libopengl-perl-0.6704+dfsg/blib/arch/auto/OpenGL/OpenGL.so: > undefined symbol: glResizeBuffersMESA at > /usr/lib/x86_64-linux-gnu/perl/5.20/DynaLoader.pm line 187. > > It looks like mesa 10.6 dropped a bunch of symbols without changing the > SONAME. Copying the maintainer. Was this an intentional ABI break? [...] > This is also > http://sourceforge.net/p/pogl/bugs/21/ > https://bugzilla.redhat.com/show_bug.cgi?id=1224294 > > which have the attached patch that deletes references to the > removed symbols. Even with that applied, I suppose at least > some Breaks entries would be in order? I've uploaded libopengl-perl_0.6704+dfsg-2 with the patch. Cloning a bug against libgl1-mesa-glx, which should add a Breaks for the older versions AFAICS. -- Niko Tyni nt...@debian.org
Bug#851347: libjson-validator-perl: uses deprecated Mojo::Util::slurp, makes libswagger2-perl FTBFS
Package: libjson-validator-perl Version: 0.90+dfsg-1 Severity: serious User: debian-p...@lists.debian.org Usertags: autopkgtest Tags: fixed-upstream Control: affects -1 libswagger2-perl As noticed by ci.debian.net, libswagger2-perl recently started failing its test suite on current sid, making it fail to build from source. https://ci.debian.net/packages/libs/libswagger2-perl/unstable/amd64/ This was caused by libmojolicious-perl_7.18+dfsg-1, which deprecated Mojo::Util::slurp in favor of Mojo::File::slurp. The error really comes from libjson-validator-perl, which isn't obvious because the deprecation code in Mojo::Util fiddles with $Carp::CarpLevel. It seems to be fixed upstream in 0.91. Filing this against libjson-validator-perl at RC level, but if somebody wants to track these with separate bugs, be my guest. not ok 41 - no (unexpected) warnings (via done_testing) 1..41 Dubious, test returned 1 (wstat 256, 0x100) Failed 1/41 subtests Mojo::Util::slurp is DEPRECATED in favor of Mojo::File::slurp at /<>/blib/lib/Swagger2.pm line 38. Mojo::Util::slurp is DEPRECATED in favor of Mojo::File::slurp at /<>/blib/lib/Swagger2.pm line 38. Mojo::Util::slurp is DEPRECATED in favor of Mojo::File::slurp at /<>/blib/lib/Swagger2.pm line 38. [...] Test Summary Report --- t/bodytest.t(Wstat: 256 Tests: 41 Failed: 1) Failed test: 41 Non-zero exit status: 1 t/ensure-swagger-response.t (Wstat: 256 Tests: 12 Failed: 1) Failed test: 12 Non-zero exit status: 1 t/formdata.t(Wstat: 256 Tests: 15 Failed: 1) Failed test: 15 Non-zero exit status: 1 t/jv-formats.t (Wstat: 0 Tests: 23 Failed: 0) TODO passed: 7, 10-11 t/plugin.t (Wstat: 0 Tests: 38 Failed: 0) TODO passed: 38 t/validate-json-schema.t(Wstat: 256 Tests: 9 Failed: 1) Failed test: 9 Non-zero exit status: 1 -- Niko Tyni nt...@debian.org
Bug#839022: Bug fixed in NMU, attached formatpatch for your Git housekeeping
On Thu, Jan 12, 2017 at 07:25:06PM +0100, Andreas Tille wrote: > in case you want to update your private Git repository with the changes > I did to NMU this package I'm attaching format-patch formatted patches. Hi Andreas, your NMU for #839022 / libgraphics-colornames-perl seems to have been lost somewhere? The other one (#839023 / libgraphics-colorobject-perl) worked fine. Thanks for your work, -- Niko Tyni nt...@debian.org
Bug#851642: perl: FTBFS on mips64el: dist/threads/t/join.t failure
Package: perl Version: 5.24.1-1 Severity: serious X-Debbugs-Cc: debian-m...@lists.debian.org This package failed to build on mips64el: dist/threads/t/join ... Died at t/join.t line 134. FAILED--expected 20 tests, saw 10 This has now happened twice on different buildds so it doesn't seem to be transient. https://buildd.debian.org/status/logs.php?pkg=perl&arch=mips64el 5.24.1~rc5-1 built fine in experimental a couple of weeks ago, and there were no thread-related source changes between the versions (and a minimal set of changes overall as the debian/cross/ ones don't affect native builds). So either something changed in the toolchain / platform or this was a latent undeterministic bug and we're just unlucky now. Needs investigation. Cc'ing the mips porters; any help would be welcome. -- Niko Tyni nt...@debian.org
Bug#1026501: [request-tracker-maintainers] Bug#1026501: request-tracker4: FTBFS: make[1]: *** [Makefile:381: test-parallel] Error 1
Control: tag -1 upstream fixed-upstream patch
On Tue, Dec 20, 2022 at 05:54:40PM +0100, Lucas Nussbaum wrote:
> Source: request-tracker4
> Version: 4.4.6+dfsg-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221220 ftbfs-bookworm
> > # Failed test 'LocalizedDateTime format with defaults'
> > # at t/api/date.t line 100.
> > # got: 'Thu, Jan 1, 1970 12:00:00 AM'
> > # expected: 'Thu, Jan 1, 1970 12:00:00 AM'
This is fixed upstream in the 'maint' branch with
https://github.com/bestpractical/rt/commit/03868c7eaeea38cd9f9ebe588ee52df355b029cc
Update tests for EN datetime locale change to space
DateTime::Locale version 1.58 published CLDR 42.0.0 which changed
the space character in times before the AM and PM to be
U+202F NARROW NO-BREAK SPACE (aka NNBSP) from the previous
space (U+0020). This broke tests looking for a space character
for localized datetimes with an AM/PM.
Update to a like test to work for older versions of DateTime::Locale
and for new ones from 1.58 forward.
though I believe the breaking change was in DateTime-Locale version 1.37
and not 1.58 (which does not exist yet AFAICS.)
Attached as well for convenience.
--
Niko
>From 03868c7eaeea38cd9f9ebe588ee52df355b029cc Mon Sep 17 00:00:00 2001
From: Jim Brandt
Date: Mon, 7 Nov 2022 17:18:48 -0500
Subject: [PATCH] Update tests for EN datetime locale change to space
DateTime::Locale version 1.58 published CLDR 42.0.0 which changed
the space character in times before the AM and PM to be
U+202F NARROW NO-BREAK SPACE (aka NNBSP) from the previous
space (U+0020). This broke tests looking for a space character
for localized datetimes with an AM/PM.
Update to a like test to work for older versions of DateTime::Locale
and for new ones from 1.58 forward.
---
t/api/date.t | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/t/api/date.t b/t/api/date.t
index 19a0a0153..aee517d9c 100644
--- a/t/api/date.t
+++ b/t/api/date.t
@@ -81,6 +81,11 @@ my $current_user;
RT->Config->Set( Timezone => 'UTC' );
}
+# Note, starting with DateTime::Locale version 1.58,
+# RT::Date::LocalizedDateTime returns AM/PM with a
+# U+202F NARROW NO-BREAK SPACE (aka NNBSP) before them rather than
+# a plain space, thus the "like" tests below.
+
{
my $date = RT::Date->new(RT->SystemUser);
is($date->IsSet,0, "new date isn't set");
@@ -97,8 +102,8 @@ my $current_user;
is($date->Get(Format =>'RFC2822'),
'Thu, 01 Jan 1970 00:00:00 +',
"RFC2822 format with defaults");
-is($date->Get(Format =>'LocalizedDateTime'),
- 'Thu, Jan 1, 1970 12:00:00 AM',
+like($date->Get(Format =>'LocalizedDateTime'),
+ qr/Thu\, Jan 1\, 1970 12:00:00( |\x{202F})AM/,
"LocalizedDateTime format with defaults");
is($date->ISO(Time => 0),
@@ -123,8 +128,8 @@ my $current_user;
is($date->RFC2822(Date => 0),
'00:00:00 +',
"RFC2822 format without date part");
-is($date->LocalizedDateTime(Date => 0),
- '12:00:00 AM',
+like($date->LocalizedDateTime(Date => 0),
+ qr/12:00:00( |\x{202F})AM/,
"LocalizedDateTime format without date part");
is($date->ISO(Date => 0, Seconds => 0),
@@ -144,17 +149,17 @@ my $current_user;
'00:00:00 +',
"RFC2822 format without 'day of week' and date parts(corner case test)");
-is($date->LocalizedDateTime(AbbrDay => 0),
- 'Thursday, Jan 1, 1970 12:00:00 AM',
+like($date->LocalizedDateTime(AbbrDay => 0),
+ qr/Thursday\, Jan 1\, 1970 12:00:00( |\x{202F})AM/,
"LocalizedDateTime format without abbreviation of day");
-is($date->LocalizedDateTime(AbbrMonth => 0),
- 'Thu, January 1, 1970 12:00:00 AM',
+like($date->LocalizedDateTime(AbbrMonth => 0),
+ qr/Thu\, January 1\, 1970 12:00:00( |\x{202F})AM/,
"LocalizedDateTime format without abbreviation of month");
-is($date->LocalizedDateTime(DateFormat => 'date_format_short'),
- '1/1/70 12:00:00 AM',
+like($date->LocalizedDateTime(DateFormat => 'date_format_short'),
+ qr/1\/1\/70 12:00:00( |\x{202F})AM/,
"LocalizedDateTime format with non default DateFormat");
-is($date->LocalizedDateTime(TimeFormat => 'time_format_short'),
- 'Thu, Jan 1, 1970 12:00 AM',
+like($date->LocalizedDateTime(TimeFormat => 'time_format_short'),
+ qr/Thu\, Jan 1\, 1970 12:00( |\x{202F})AM/,
"LocalizedDateTime format with non default TimeFormat");
is($date->Date,
@@ -212,7 +217,7 @@ my $current_user;
is($date->ISO( Timezone => 'user' ), '2005-01-01 18:10:00', "ISO");
is($date->W3CDTF( Timezone => 'user' ), '2005-01-01T18:10:00+03:00', "W3C DTF");
is($date->RFC2822( Timezone => 'user' ), 'Sat, 01 Jan 2005 18:10:00 +0300', "RFC2822");
-is($date->LocalizedDateTime( Timezone => 'user' ), 'Sat, Jan 1, 2005 6:10:00 PM', "Lo
Bug#1026669: [request-tracker-maintainers] Bug#1026669: request-tracker5: FTBFS: can't locate java: No such file or directory
Control: clone -1 -2
Control: retitle -2 jexec: can't locate java: No such file or directory
Control: reassign -2 openjdk-17-jre-headless 17.0.5+8-2
On Wed, Jan 18, 2023 at 04:10:02AM +0100, Ángel wrote:
> The error here is that ./debian/build-final-ckeditor.sh fails with
> « can't locate java: No such file or directory »
>
> This script is actually calling ckbuilder ( jexec /usr/bin/ckbuilder --
> build ... )
>
> However, the package correctly lists ckbuilder as a build-dep, and
> ckbuilder itself depends on java ( default-jre | java{7..11}-runtime)
> > update-alternatives: using /usr/lib/jvm/java-17-openjdk-
> > amd64/lib/jexec to provide /usr/bin/jexec (jexec) in auto mode
Yeah, it looks to me like jexec from openjdk-17-jre-headless
is just broken on sid?
% jexec
can't locate java: No such file or directory
% ls -l /usr/bin/jexec /etc/alternatives/jexec
/usr/lib/jvm/java-17-openjdk-amd64/lib/jexec
lrwxrwxrwx 1 root root44 Oct 19 14:23 /etc/alternatives/jexec ->
/usr/lib/jvm/java-17-openjdk-amd64/lib/jexec
lrwxrwxrwx 1 root root23 Oct 19 14:23 /usr/bin/jexec ->
/etc/alternatives/jexec
-rwxr-xr-x 1 root root 14416 Oct 19 14:23
/usr/lib/jvm/java-17-openjdk-amd64/lib/jexec
% ls -l /usr/bin/java /etc/alternatives/java
/usr/lib/jvm/java-17-openjdk-amd64/bin/java
lrwxrwxrwx 1 root root43 Oct 19 14:23 /etc/alternatives/java ->
/usr/lib/jvm/java-17-openjdk-amd64/bin/java
lrwxrwxrwx 1 root root22 Oct 19 14:23 /usr/bin/java ->
/etc/alternatives/java
-rwxr-xr-x 1 root root 14424 Oct 19 14:23
/usr/lib/jvm/java-17-openjdk-amd64/bin/java
% java --version
openjdk 17.0.5 2022-10-18
OpenJDK Runtime Environment (build 17.0.5+8-Debian-2)
OpenJDK 64-Bit Server VM (build 17.0.5+8-Debian-2, mixed mode, sharing)
I'm cloning a separate bug about this.
Not sure why jexec is used here though. Just running /usr/bin/ckbuilder
works for me (but the request-tracker5 build fails later, presumably
due to a different bug.)
--
Niko Tyni nt...@debian.org
Bug#1040020: libtoml-parser-perl: FTBFS: cannot remove : No such file or directory
Source: libtoml-parser-perl Version: 0.91-2 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. Installing /<>/debian/libtoml-parser-perl/usr/share/man/man3/TOML::Parser.3pm rm --verbose /<>/debian/libtoml-parser-perl/usr/share/man/man3/TOML::Parser::Tokenizer.3pm rm: cannot remove '/<>/debian/libtoml-parser-perl/usr/share/man/man3/TOML::Parser::Tokenizer.3pm': No such file or directory make[1]: *** [debian/rules:11: override_dh_auto_install] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:7: binary] Error 2 I think this was broken by libmodule-build-tiny-perl 0.046-1 with this upstream change from 0.040: - Don't manify podless modules/scripts Example log at https://tests.reproducible-builds.org/debian/rbuild/trixie/arm64/libtoml-parser-perl_0.91-2.rbuild.log.gz -- Niko Tyni nt...@debian.org
Bug#1040021: libtext-findindent-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: libtext-findindent-perl Version: 0.11-4 Severity: serious Tags: ftbfs sid trixie Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=148296 This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:4: build] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040022: libtest-deep-fuzzy-perl: FTBFS: cannot remove : No such file or directory
Source: libtest-deep-fuzzy-perl Version: 0.01-2 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. Installing /<>/debian/libtest-deep-fuzzy-perl/usr/share/man/man3/Test::Deep::Fuzzy.3pm # remove empty manpage rm --verbose /<>/debian/libtest-deep-fuzzy-perl/usr/share/man/man3/Test::Deep::Fuzzy::Number.3pm rm: cannot remove '/<>/debian/libtest-deep-fuzzy-perl/usr/share/man/man3/Test::Deep::Fuzzy::Number.3pm': No such file or directory make[1]: *** [debian/rules:12: override_dh_auto_install] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:7: binary] Error 2 I think this was broken by libmodule-build-tiny-perl 0.046-1 with this upstream change from 0.040: - Don't manify podless modules/scripts Example log at https://tests.reproducible-builds.org/debian/rbuild/trixie/amd64/libtest-deep-fuzzy-perl_0.01-2.rbuild.log.gz -- Niko Tyni nt...@debian.org
Bug#1040023: libsms-send-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: libsms-send-perl Version: 1.06-4 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:4: binary] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040024: liborlite-statistics-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: liborlite-statistics-perl Version: 0.03-3 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:4: build] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040025: liborlite-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: liborlite-perl Version: 1.98-4 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:4: binary] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040026: liborlite-mirror-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: liborlite-mirror-perl Version: 1.24-3 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:4: binary] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040027: liborlite-migrate-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: liborlite-migrate-perl Version: 1.10-4 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:4: binary] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040028: liboauth-lite2-perl: FTBFS: cannot remove : No such file or directory
Source: liboauth-lite2-perl Version: 0.11-2 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. Installing /<>/debian/liboauth-lite2-perl/usr/bin/token.psgi # delete token.psgi, as it's moved to examples dir rm -f -v /<>/debian/liboauth-lite2-perl/usr/bin/token.psgi removed '/<>/debian/liboauth-lite2-perl/usr/bin/token.psgi' rm -f -v /<>/debian/liboauth-lite2-perl/usr/share/man/man1/token.psgi.1p rmdir --ignore-fail-on-non-empty --parents --verbose /<>/debian/liboauth-lite2-perl/usr/bin rmdir: removing directory, '/<>/debian/liboauth-lite2-perl/usr/bin' rmdir: removing directory, '/<>/debian/liboauth-lite2-perl/usr' rmdir --ignore-fail-on-non-empty --parents --verbose /<>/debian/liboauth-lite2-perl/usr/share/man/man1/ rmdir: removing directory, '/<>/debian/liboauth-lite2-perl/usr/share/man/man1/' rmdir: failed to remove '/<>/debian/liboauth-lite2-perl/usr/share/man/man1/': No such file or directory make[1]: *** [debian/rules:15: override_dh_auto_install] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:7: binary] Error 2 I think this was broken by libmodule-build-tiny-perl 0.046-1 with this upstream change from 0.040: - Don't manify podless modules/scripts -- Niko Tyni nt...@debian.org
Bug#1040029: libfile-localizenewlines-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: libfile-localizenewlines-perl Version: 1.12-2 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:7: binary] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040030: libcpandb-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: libcpandb-perl Version: 0.18-3 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 make: *** [debian/rules:4: build] Error 25 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040134: libaspect-perl: FTBFS: Can't locate inc/Module/Install/DSL.pm in @INC
Source: libaspect-perl Version: 1.04-2 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. dh_auto_configure /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 2 I think this was broken by libmodule-install-perl 1.21-1 with this upstream change from 1.20: - Module::Install::DSL has been removed, as its use is highly discouraged. -- Niko Tyni nt...@debian.org
Bug#1040219: libsyntax-keyword-dynamically-perl: circular build dependencies with libobject-pad-perl
Source: libsyntax-keyword-dynamically-perl Version: 0.12-1 Severity: serious Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package cannot be rebuilt for the next Perl transition because of circular build dependencies. Package: libsyntax-keyword-dynamically-perl Architecture: any Build-Depends: [...], libobject-pad-perl , [...] Package: libobject-pad-perl Architecture: any Build-Depends: [...], libsyntax-keyword-dynamically-perl , [...] So when the new perl makes the binaries uninstallable, they both need each other to be rebuilt first. Building with the 'nocheck' build profile would solve the issue, but I don't think the Debian binNMU machinery supports this. Filing against libsyntax-keyword-dynamically-perl but this could be fixed in either package. -- Niko Tyni nt...@debian.org
Bug#1040220: libsyntax-keyword-match-perl: circular build dependencies with libfuture-asyncawait-perl
Source: libsyntax-keyword-match-perl Version: 0.12-1 Severity: serious Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package cannot be rebuilt for the next Perl transition because of circular build dependencies. Package: libsyntax-keyword-match-perl Architecture: any Build-Depends: [...], libfuture-asyncawait-perl , [...] Package: libfuture-asyncawait-perl Architecture: any Build-Depends: [...], libsyntax-keyword-match-perl , [...] So when the new perl makes the binaries uninstallable, they both need each other to be rebuilt first. Building with the 'nocheck' build profile would solve the issue, but I don't think the Debian binNMU machinery supports this. Filing against libsyntax-keyword-match-perl but this could be fixed in either package. -- Niko Tyni nt...@debian.org
Bug#1040242: libdist-zilla-plugin-run-perl: FTBFS: cannot remove : No such file or directory
Source: libdist-zilla-plugin-run-perl Version: 0.048-1 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. Installing /<>/debian/libdist-zilla-plugin-run-perl/usr/share/man/man3/Dist::Zilla::Plugin::Run::BeforeBuild.3pm rm --verbose /<>/debian/libdist-zilla-plugin-run-perl/usr/share/man/man3/Dist::Zilla::Plugin::Run::Role::Runner.3pm rm: cannot remove '/<>/debian/libdist-zilla-plugin-run-perl/usr/share/man/man3/Dist::Zilla::Plugin::Run::Role::Runner.3pm': No such file or directory make[1]: *** [debian/rules:11: override_dh_auto_install] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:7: binary] Error 2 I think this was broken by libmodule-build-tiny-perl 0.046-1 with this upstream change from 0.040: - Don't manify podless modules/scripts -- Niko Tyni nt...@debian.org
Bug#1040244: librdf-ldf-perl: FTBFS: cannot remove : No such file or directory
Source: librdf-ldf-perl Version: 0.25.1-1 Severity: serious Tags: ftbfs sid trixie This package fails to build from source on current sid. debian/rules execute_after_dh_installman make[1]: Entering directory '/<>' rm debian/*/usr/share/man/man3/RDF::LDF::Error.3pm* rm: cannot remove 'debian/*/usr/share/man/man3/RDF::LDF::Error.3pm*': No such file or directory make[1]: *** [debian/rules:8: execute_after_dh_installman] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:4: binary] Error 2 I think this was broken by libmodule-build-tiny-perl 0.046-1 with this upstream change from 0.040: - Don't manify podless modules/scripts -- Niko Tyni nt...@debian.org
Bug#1040223: libimage-imlib2-perl: Creates empty package on bookworm upwards (maybe because of libimlib2-dev?)
Control: tag -1 patch
On Mon, Jul 03, 2023 at 06:00:44PM +0200, gregor herrmann wrote:
> Source: libimage-imlib2-perl
> Version: 2.03-1.1
> Severity: grave
> Tags: bookworm trixie sid
> Justification: renders package unusable
> While looking at Niko's and Dom's first rebuilds for perl 5.38, I
> noticed that libimage-imlib2-perl "successfully" builds but creates
> a basically empty package:
>
> http://perl.debian.net/rebuild-logs/perl-5.38/libimage-imlib2-perl_2.03-1.1/libimage-imlib2-perl_2.03-1.1.buildlog
>
> dh_auto_configure -a
> dh_auto_configure: warning: Compatibility levels before 10 are deprecated
> (level 8 in use)
> /usr/bin/perl -I. Build.PL --installdirs vendor
> You must install the imlib2 library before you can install
> Image::Imlib2. You can obtain imlib2 from
> http://sourceforge.net/projects/enlightenment/
[...]
> I've started to work on patch which uses pkg-config instead of
> imlib2-config; good news: The package builds (as in: actually builds
> code :)) in oldstable+stable+testing+sid and the
> perl-5.38-rebuild-repo; but the tests only pass in oldstable,
> starting with stable/bookworm (aka libimlib2-dev >= 1.10) they fail
> with:
> # Failed test at t/simple.t line 68.
> # got: '0'
> # expected: '1'
Hi, thanks for looking at this.
FWIW I found some prior art in NetBSD for the pkg-config part:
https://github.com/NetBSD/pkgsrc/blob/trunk/graphics/p5-Image-Imlib2/patches/patch-Build.PL
but yours looks good to me as well :)
I think the failing test is a bug in imlib2 1.10.0 and I've just filed #1041406
about it.
I'm attaching a workaround that might be appropriate at least until imlib2 is
fixed.
--
Niko Tyni nt...@debian.org
>From c2d646b9fa925ac2a91cb6cfb3fe6dad430c7927 Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Tue, 18 Jul 2023 15:16:21 +0100
Subject: [PATCH] Work around an imlib2 bug with alpha channel cloning
As discussed in https://bugs.debian.org/1041406 imlib2 1.10.0 introduced
a bug where imlib_clone_image() no longer copies the alpha flag. This
breaks test 12 of t/simple.t :
# Failed test at t/simple.t line 68.
# got: '0'
# expected: '1'
Work around this on our side by checking for any difference after
cloning and copying the alpha flag if necessary.
Bug-Debian: https://bugs.debian.org/1040223
---
lib/Image/Imlib2.xs | 11 +++
1 file changed, 11 insertions(+)
diff --git a/lib/Image/Imlib2.xs b/lib/Image/Imlib2.xs
index f48d4ec..cc54d2b 100644
--- a/lib/Image/Imlib2.xs
+++ b/lib/Image/Imlib2.xs
@@ -931,9 +931,20 @@ Imlib2_clone(image)
CODE:
{
Imlib_Image cloned;
+ char alpha_orig;
+ char alpha_cloned;
imlib_context_set_image(image);
cloned = imlib_clone_image();
+
+ /* imlib2 no longer clones the alpha flag since 1.10 */
+ alpha_orig = imlib_image_has_alpha();
+ imlib_context_set_image(cloned);
+ alpha_cloned = imlib_image_has_alpha();
+ if (alpha_orig != alpha_cloned) {
+ imlib_image_set_has_alpha(alpha_orig);
+ }
+ imlib_context_set_image(image);
RETVAL = cloned;
}
--
2.39.1
Bug#1040223: libimage-imlib2-perl: Creates empty package on bookworm upwards (maybe because of libimlib2-dev?)
On Tue, Jul 18, 2023 at 03:28:43PM +0100, Niko Tyni wrote: > FWIW I found some prior art in NetBSD for the pkg-config part: > > > https://github.com/NetBSD/pkgsrc/blob/trunk/graphics/p5-Image-Imlib2/patches/patch-Build.PL > > but yours looks good to me as well :) > > I think the failing test is a bug in imlib2 1.10.0 and I've just filed > #1041406 about it. > > I'm attaching a workaround that might be appropriate at least until imlib2 is > fixed. Hi Don, libimage-imlib2-perl misbuilding is somewhat hindering our Perl 5.38 testing. Would you be OK with an NMU with these patches, and/or moving the package to the pkg-perl group maintenance? -- Niko Tyni nt...@debian.org
Bug#1025722: duck fails with 'Can't close(GLOB(0x558bebc05958)) filehandle: 'Is a directory' at /usr/share/duck/lib/checks/patch_files.pm line 101'
On Thu, Dec 08, 2022 at 12:45:29AM +0100, gregor herrmann wrote:
> Package: duck
> Version: 0.14.0
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: p...@packages.debian.org
> As of today, duck (called in any source package directory) fails with
>
> Can't close(GLOB(0x558bebc05958)) filehandle: 'Is a directory' at
> /usr/share/duck/lib/checks/patch_files.pm line 101'
>
> 92# iterate over all patchdirs, process all files found
> 93foreach my $patchdir (@patchdirs) {
> 94my $dirhandle = dir($patchdir)->open;
> 95
> 96while (my $patchfile = $dirhandle->read) {
> 97open my $pf, "<", $patchdir . "/" . $patchfile;
> 98
> 99my @pf_raw = <$pf>;
>100
>101close($pf);
>
> This may or may not be caused by a recent change in src:perl [0], hence
> cc'in the perl maintainers
Thanks. It's definitely that change, but I think the bug is in duck.
The above code is treating directories as plain files under autodie,
so bailing out seems warranted. Earlier it just failed silently.
A straightforward fix would be inserting something like
next if -d $patchdir . "/" . $patchfile;
on line 97 or so (but using File::Spec->catfile() would feel cleaner
to me.)
Baptiste: please let us know if/when duck is fixed so we can add a
suitable Breaks entry on the perl side. (And obviously let us also know
if you disagree about the bug :)
BTW it seems like duck could use an autopkgtest test suite so things
like this would be detected automatically.
--
Niko Tyni nt...@debian.org
Bug#930671: libauthen-radius-perl: most basic usage stopped working
Control: tag -1 patch
Control: forwarded -1 https://rt.cpan.org/Ticket/Display.html?id=129869
On Wed, Jun 19, 2019 at 08:27:51PM +0300, Niko Tyni wrote:
> On Tue, Jun 18, 2019 at 10:52:03AM +0200, Ferenc Wágner wrote:
> > Package: libauthen-radius-perl
> > Version: 0.29-1
> > Severity: important
>
> > I recently upgraded to buster and noticed that our RADIUS test plugin
> > does not work anymore. Downgrading libauthen-radius-perl to 0.27-1
> > fixes the issue. Take the first example from the top of the man page:
> >
> > use Authen::Radius;
> > $r = new Authen::Radius(Host => 'myserver', Secret => 'mysecret');
> > print "auth result=", $r->check_pwd('myname', 'mypwd'), "\n";
> > unknown attr name 1 at /usr/share/perl5/Authen/Radius.pm line 865.
> This needs to be reported and fixed upstream; I'll look at it in the
> next few days unless someone else beats me to it.
I've reported this upstream with the attached proposed patch.
Will wait a bit before applying the patch for Debian in case upstream
has comments.
--
Niko Tyni nt...@debian.org
>From ba0078591c35d1d6a404828aab9d06fb43c4d5fc Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Thu, 20 Jun 2019 16:43:30 +0300
Subject: [PATCH] Fix 0.28 regression with check_pwd()
add_attributes() is documented to accept raw numeric attributes,
and check_pwd() uses those.
Bug-Debian: https://bugs.debian.org/930671
---
Radius.pm | 3 ++-
t/error.t | 13 -
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/Radius.pm b/Radius.pm
index fd0a6c9..3497e99 100644
--- a/Radius.pm
+++ b/Radius.pm
@@ -862,7 +862,8 @@ sub add_attributes {
$attr_name = $1;
}
-die 'unknown attr name '.$attr_name if (! exists $dict_name{$attr_name});
+die 'unknown attr name '.$attr_name
+if ($attr_name =~ /\D/ and ! exists $dict_name{$attr_name});
$id = $dict_name{$attr_name}{id} // int($attr_name);
$vendor = vendorID($attr);
diff --git a/t/error.t b/t/error.t
index 6a02cb3..e1c8f5f 100644
--- a/t/error.t
+++ b/t/error.t
@@ -1,6 +1,6 @@
use strict;
use warnings;
-use Test::More tests => 9;
+use Test::More tests => 12;
use Test::NoWarnings;
BEGIN { use_ok('Authen::Radius') };
@@ -17,3 +17,14 @@ ok( $auth->clear_attributes, 'clear attributes');
is($auth->get_error(), 'ENONE', 'error was reset');
is(Authen::Radius->get_error(), 'ENONE', 'global error also reset');
+
+my @attributes = (
+{ Name => 1, Value => 'user', Type => 'string' },
+{ Name => 2, Value => 'pass', Type => 'string' },
+{ Name => 4, Value => '127.0.0.1', Type => 'ipaddr' }
+);
+
+# called by check_pwd()
+ok( $auth->add_attributes(@attributes), 'add attributes');
+is($auth->get_error(), 'ENONE', 'no error with add_attributes');
+is(Authen::Radius->get_error(), 'ENONE', 'no global error either');
--
2.20.1
Bug#924657: console-setup | kbdnames-maker: Call `{bind,}textdomain` after switching locale (!2)
clone 924657 -1 reassign -1 perl 5.28.1-6 severity -1 important retitle -1 perl: switching locales no longer invalidates gettext translation cache thanks On Wed, Jun 19, 2019 at 08:01:01PM +, Iain Lane wrote: > Hi @MichaIng-guest - sorry, I've dropped the ball on this a bit. There's a > [corresponding Debian > bug](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924657) with some > discussion in it, but the status is that we're a bit stalled a the minute. I > agree that my proposal here in this MR is a workaround and maybe Perl should > do something about this itself (slightly less convinced that glibc can be > blamed since presumably this has always been the behaviour of `uselocale()`?). > > For Buster should we go ahead with this workaround? I'm not very confident in > pushing on it myself alone but maybe between me, @intrigeri and @ntyni we > have enough bravery? As I already noted on the bug, the workaround seems fine to me. I think it should be used for Buster, but I don't have a chance to do anything else about this right now. Sorry. I'm cloning a bug against perl and will try to take it upstream later when I find the time. -- Niko Tyni nt...@debian.org
Bug#924657: console-setup | kbdnames-maker: Call `{bind,}textdomain` after switching locale (!2)
On Wed, Jun 26, 2019 at 11:23:28PM +0300, Niko Tyni wrote: > clone 924657 -1 > reassign -1 perl 5.28.1-6 > severity -1 important > retitle -1 perl: switching locales no longer invalidates gettext translation > cache > thanks Forgot that the BTS doesn't like clones of merged bugs. I've filed #931139 instead. -- Niko
Bug#931730: libfile-stripnondeterminism-perl: build dependency cycle with libsub-identify-perl
Package: libfile-stripnondeterminism-perl Version: 1.2.0-2 Severity: serious User: debian-p...@lists.debian.org Usertags: perl-5.30-transition X-Debbugs-Cc: debhel...@packages.debian.org, debian-p...@lists.debian.org Hi, the recently added libmonkey-patch-perl dependency in libfile-stripnondeterminism-perl has unfortunately resulted in a build dependency cycle: libsub-identify-perl Build-Depends: debhelper debhelper Depends: dh-strip-nondeterminism dh-strip-nondeterminism Depends: libfile-stripnondeterminism-perl libfile-stripnondeterminism-perl Depends: libmonkey-patch-perl libmonkey-patch-perl Depends: libsuper-perl libsuper-perl Depends: libsub-identify-perl This is a problem for Perl major version transitions because libsub-identify-perl is arch:any and needs to be rebuilt against the new Perl, but its build dependencies will now be uninstallable until it is rebuilt. We need to break the cycle. I see this new dependency was introduced for normalizing zip archives (#858431) by changing the Archive::Zip behaviour on the fly. Is this fixable on the Archive::Zip side? Alternatively, would it be possible to weaken the cycle somehow, for instance by making this dependency optional and having the packages that actually need it declare an explicit build dependency ? Thanks for considering, -- Niko Tyni nt...@debian.org
Bug#931730: libfile-stripnondeterminism-perl: build dependency cycle with libsub-identify-perl
On Tue, Jul 09, 2019 at 04:08:18PM -0300, Chris Lamb wrote: > > the recently added libmonkey-patch-perl dependency in > > libfile-stripnondeterminism-perl has unfortunately resulted in a build > > dependency cycle > […] > > I see this new dependency was introduced for normalizing zip archives > > (#858431) by changing the Archive::Zip behaviour on the fly. Is this > > fixable on the Archive::Zip side? > > I guess in theory but if I recall the details correctly, I don't > /think/ this was going to be a trivial patch to Archive::Zip and my > Perl-fu is/was a bit weak. Would pkg-perl apply and upload a patch > anyway? I'm sorry I haven't had time to look at this properly (and still don't). Obviously features would be best developed upstream. Archive-Zip seems to be alive if quiet. But a bug against libarchive-zip-perl would be a good start (with or without a patch). We can then take it upstream if you'd prefer that. > > Alternatively, would it be possible to weaken the cycle somehow, for > > instance by making this dependency optional and having the packages that > > actually need it declare an explicit build dependency ? > > Would adding a restriction be of use to you? No, I'm afraid not. I was thinking of having libfile-stripnondeterminism-perl recommend libmonkey-patch-perl rather than depend on it, or something like that. The only Build-Depends that is relevant here is libsub-identify-perl -> debhelper. The problem is with runtime dependencies: debhelper needs to stay installable even when libsub-identify-perl has become uninstallable and needs a rebuild. One more alternative might be to make a derived class like Archive::Zip::Normalizing or Archive::Zip::DebianReproducible or whatever and package that separately, avoiding the "monkey patching" part. Not sure how feasible that is to implement though. Hope this clarifies, -- Niko
Bug#931730: libfile-stripnondeterminism-perl: build dependency cycle with libsub-identify-perl
On Thu, Jul 11, 2019 at 06:25:56PM -0300, Chris Lamb wrote:
> > > I guess in theory but if I recall the details correctly, I don't
> > > /think/ this was going to be a trivial patch to Archive::Zip and my
> > > Perl-fu is/was a bit weak. Would pkg-perl apply and upload a patch
> > > anyway?
> […]
> > Obviously features would be best developed upstream. Archive-Zip seems
> > to be alive if quiet. But a bug against libarchive-zip-perl would be a
> > good start (with or without a patch).
>
> Nod. I'll work on a proper patch to libarchive-zip-perl over the next
> few days.
Thanks.
Meanwhile, please consider the attached patch which should solve the
immediate concern by using Sub::Override (from libsub-override-perl)
instead.
--
Niko
>From 06cc575db2f6eb5336d00b93b9c8b2ceb4280867 Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Mon, 15 Jul 2019 09:30:11 +0300
Subject: [PATCH] Use Sub::Override for Archive::Zip workarounds
Monkey::Patch recursively depends on an XS binary Perl module, which
creates build cycle issues for Perl transitions.
Use Sub::Override instead, as it has no dependencies outside Perl core.
Closes: 931730
---
lib/File/StripNondeterminism/handlers/zip.pm | 23 +++-
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/lib/File/StripNondeterminism/handlers/zip.pm b/lib/File/StripNondeterminism/handlers/zip.pm
index a90a7e3..a15f5a8 100644
--- a/lib/File/StripNondeterminism/handlers/zip.pm
+++ b/lib/File/StripNondeterminism/handlers/zip.pm
@@ -24,7 +24,7 @@ use warnings;
use File::Temp;
use File::StripNondeterminism;
use Archive::Zip qw/:CONSTANTS :ERROR_CODES/;
-use Monkey::Patch qw/patch_class/;
+use Sub::Override;
# A magic number from Archive::Zip for the earliest timestamp that
# can be represented by a Zip file. From the Archive::Zip source:
@@ -231,21 +231,24 @@ sub normalize {
# stored value of localExtraField (!) and reload it again from the existing
# file handle in/around rewindData.
#
- # We therefore monkey-patch the accessor methods of the Member class to
+ # We therefore override the accessor methods of the Member class to
# ensure that normalised values are used in this final save.
#
# <https://salsa.debian.org/reproducible-builds/strip-nondeterminism/issues/4>
- my @patches = map {
- patch_class('Archive::Zip::Member', $_, sub {
- my $fn = shift;
- my $result = $fn->(@_);
- return defined($result) ?
-normalize_extra_fields($canonical_time, $result) : $result;
- });
+ my @overrides = map {
+ my $full_name = "Archive::Zip::Member::$_";
+ my $orig_sub = \&$full_name;
+ Sub::Override->new(
+ $full_name => sub {
+my $result = $orig_sub->(@_);
+return defined($result) ?
+ normalize_extra_fields($canonical_time, $result) : $result;
+ }
+ );
} qw(cdExtraField localExtraField);
return 0 unless $zip->overwrite() == AZ_OK;
- undef @patches; # Remove our monkey patches
+ $_->restore for @overrides;
chmod($old_perms, $zip_filename);
return 1;
}
--
2.20.1
Bug#932282: libnet-pcap-perl: FTBFS: error: redefinition of ‘struct pcap_rmtauth’
Source: libnet-pcap-perl
Version: 0.18-2
Severity: serious
Tags: ftbfs sid bullseye
X-Debbugs-Cc: libp...@packages.debian.org
This package fails to build from source on current sid/amd64.
Presumably this regressed with libpcap 1.9.0-2 so copying
the maintainer in case it's an oversight.
>From the build log:
x86_64-linux-gnu-gcc -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -Wall -Wwrite-strings -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DVERSION=\"0.18\"
-DXS_VERSION=\"0.18\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.28/CORE"
-DHAVE_BLANK -DHAVE_PCAP_LIB_VERSION -DHAVE_PCAP_BREAKLOOP
-DHAVE_PCAP_COMPILE_NOPCAP -DHAVE_PCAP_DATALINK_NAME_TO_VAL
-DHAVE_PCAP_DATALINK_VAL_TO_DESCRIPTION -DHAVE_PCAP_DATALINK_VAL_TO_NAME
-DHAVE_PCAP_DUMP_FILE -DHAVE_PCAP_DUMP_FLUSH -DHAVE_PCAP_FINDALLDEVS
-DHAVE_PCAP_GETNONBLOCK -DHAVE_PCAP_GET_SELECTABLE_FD -DHAVE_PCAP_LIB_VERSION
-DHAVE_PCAP_NEXT_EX -DHAVE_PCAP_OFFLINE_FILTER -DHAVE_PCAP_OPEN_DEAD
-DHAVE_PCAP_SENDPACKET -DHAVE_PCAP_SETNONBLOCK -DHAVE_PCAP_SET_DATALINK Pcap.c
In file included from Pcap.xs:43:
stubs.inc:187:2: warning: #warning "the function pcap_list_datalinks() is not
available" [-Wcpp]
#warning "the function pcap_list_datalinks() is not available"
^~~
stubs.inc:322:2: warning: #warning "the function pcap_createsrcstr() is not
available" [-Wcpp]
#warning "the function pcap_createsrcstr() is not available"
^~~
stubs.inc:337:2: warning: #warning "the function pcap_parsesrcstr() is not
available" [-Wcpp]
#warning "the function pcap_parsesrcstr() is not available"
^~~
stubs.inc:352:2: warning: #warning "the function pcap_open() is not
available" [-Wcpp]
#warning "the function pcap_open() is not available"
^~~
stubs.inc:357:8: error: redefinition of ‘struct pcap_rmtauth’
struct pcap_rmtauth {
^~~~
In file included from /usr/include/pcap.h:43,
from Pcap.xs:32:
/usr/include/pcap/pcap.h:788:8: note: originally defined here
struct pcap_rmtauth
^~~~
In file included from Pcap.xs:43:
stubs.inc:363:10: error: conflicting types for ‘pcap_open’
pcap_t * pcap_open(const char *source, int snaplen, int flags, int
read_timeout, struct pcap_rmtauth *auth, char *err);
^
In file included from /usr/include/pcap.h:43,
from Pcap.xs:32:
/usr/include/pcap/pcap.h:835:18: note: previous declaration of ‘pcap_open’
was here
PCAP_API pcap_t *pcap_open(const char *source, int snaplen, int flags,
^
--
Niko Tyni nt...@debian.org
Bug#932299: owfs: FTBFS: relocation R_X86_64_32 against symbol `_Py_NoneStruct' can not be used
Source: owfs Version: 3.2p3+dfsg1-2 Severity: serious Tags: ftbfs sid bullseye This package fails to build from source on current sid/amd64. x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -L/usr/lib/python3.7/config-3.7m-x86_64-linux-gnu -L/usr/lib -lpython3.7m -lcrypt -lpthread -ldl -lutil -lm -I/usr/include/python3.7m -I/usr/include/python3.7m -Wno-unused-result -Wsign-compare -g -fdebug-prefix-map=/build/python3.7-HWoauq/python3.7-3.7.4=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector -Wformat -Werror=format-security -DNDEBUG -g -fwrapv -O3 -Wall -I/usr/include/libusb-1.0 -D_REENTRANT -Wdate-time -D_FORTIFY_SOURCE=2 -D_DEFAULT_SOURCE build/temp.linux-x86_64-3.7/ow_wrap.o -L../../owlib/src/c/.libs -low -o build/lib.linux-x86_64-3.7/ow/_OW.cpython-37m-x86_64-linux-gnu.so /usr/bin/ld: /tmp/ccF8DL2E.ltrans0.ltrans.o: relocation R_X86_64_32 against symbol `_Py_NoneStruct' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: nonrepresentable section on output collect2: error: ld returned 1 exit status -- Niko Tyni nt...@debian.org
Bug#934384: libvma: FTBFS: some symbols or patterns disappeared
Source: libvma Version: 8.8.1.really.8.7.7-1 Severity: serious Tags: ftbfs This package fails to build on current sid/amd64. >From my build log: dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libvma8/DEBIAN/symbols doesn't match completely debian/libvma8.symbols --- debian/libvma8.symbols (libvma8_8.8.1.really.8.7.7-1_amd64) +++ dpkg-gensymbolsBhlY4G 2019-08-10 14:41:41.948238949 + @@ -542,7 +542,7 @@ _ZN12sockinfo_tcp2rxE9rx_call_tP5ioveclPiP8sockaddrPjP6msghdr@Base 8.8.1.really.8.7.7 _ZN12sockinfo_tcp2txE9tx_call_tPK5iovecliPK8sockaddrj@Base 8.8.1.really.8.7.7 _ZN12sockinfo_tcp30create_flow_tuple_key_from_pcbER10flow_tupleP7tcp_pcb@Base 8.8.1.really.8.7.7 - _ZN12sockinfo_tcp30return_reuse_buffers_postponedEv@Base 8.8.1.really.8.7.7 +#MISSING: 8.8.1.really.8.7.7-1# _ZN12sockinfo_tcp30return_reuse_buffers_postponedEv@Base 8.8.1.really.8.7.7 _ZN12sockinfo_tcp4bindEPK8sockaddrj@Base 8.8.1.really.8.7.7 _ZN12sockinfo_tcp5fcntlEim@Base 8.8.1.really.8.7.7 _ZN12sockinfo_tcp5ioctlEmm@Base 8.8.1.really.8.7.7 [...] dh_makeshlibs: failing due to earlier errors make: *** [debian/rules:15: binary] Error 255 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 -- Niko Tyni nt...@debian.org
Bug#953562: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
On Wed, Apr 14, 2021 at 08:50:46PM +0200, Paul Gevers wrote: > Hi Ivo, Marco, > > On 06-04-2021 22:10, Ivo De Decker wrote: > > I ran a number of (partial and full) upgrade tests, and they all seem to > > work > > fine. In all cases, libcrypt1 is installed before libc6, and there is no > > intermediate situations where libcrypt.so.1 is missing. > > The patch looks sensible after reading the discussion in these bugs. Can > we have an upload soon to have exposure? Hi, thanks for your work on this and sorry I'm chiming in so late. I'm concerned that AFAICS no change in src:libxcrypt can make sure that the new libc6 is never unpacked before libcrypt1. (buster-amd64)# dpkg --unpack libc6_2.31-11_amd64.deb (Reading database ... 12224 files and directories currently installed.) Preparing to unpack libc6_2.31-11_amd64.deb ... debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) debconf: falling back to frontend: Readline Unpacking libc6:amd64 (2.31-11) over (2.28-10) ... (buster-amd64)# perl perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory It may well be enough to make this improbable enough in practice. Ivo's testing certainly seems to indicate so. It still makes me a bit uneasy. I'm happy to be proved wrong of course. Do the Important or Protected fields in the patch affect apt's behaviour in this, for instance? The solution Aurelien mentioned of copying the old libcrypt in libc6.preinst and cleaning up in libc6.postinst would eliminate this failure mode totally. But I can see it's not very desirable and may be hard to make robust. Just wanted to bring this up explicitly. Not objecting if we deem the risk of remaining corner case issues small enough that it's worth taking. -- Niko
Bug#976704: po4a: Missing dependency on libpod-parser-perl
On Sun, Apr 25, 2021 at 09:40:02PM +0300, Adrian Bunk wrote: > Control: reassign -1 perl 5.32.0-6 > Control: retitle -1 perl needs Breaks on more perl-modules-* packages > Control: severity -1 serious > Control: affects -1 po4a > > On Mon, Dec 07, 2020 at 09:24:57AM +0100, Helge Kreutzmann wrote: > >... > > Versions of packages po4a depends on: > >... > > ii perl5.32.0-5 > > ii perl-modules-5.22 [libpod-parser-perl] 5.22.2-5 > >... > > 5.32 != 5.22 > > #97 already fixed the same problem for perl-modules-5.24. Indeed. As discussed there, certain versions of perl-modules-* in the past Provided virtual packages such as libpod-parser-perl, without making sure that those bundled modules were usable with the current /usr/bin/perl on the system. This property broke later when perl was upgraded. Versions earlier than 5.22 were not affected, and the issue was fixed in perl-modules-5.26 5.26.2-5 with #899110. 5.24 (which was in stretch) is already handled but I missed the other versions. So this only happens with packages that were never in a stable release. Not sure if that affects the severity. It should be easy to fix by adding Breaks: perl-modules-5.22, perl-modules-5.26 (<< 5.26.2-5) Any regressions seem improbable given these are leftovers from a time before the current stable release. Ubuntu has released with both 5.22 and an affected version of 5.26. Haven't heard of similar issues there but a fix would possibly help their users too (at least eventually.) In general the coinstallability of older libperl5.xx and perl-modules-5.xx packages with current ones is desirable to ease upgrades of packages linking against libperl, such as postgresql. -- Niko Tyni nt...@debian.org
Bug#988673: centreon-connectors: FTBFS: Could not find libgcrypt's headers
Source: centreon-connectors Version: 19.10.0-1 Severity: serious Tags: ftbfs sid This package fails to build from source on current sid/amd64. See for instance https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/centreon-connectors.html -- The CXX compiler identification is GNU 10.2.1 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/g++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2") CMake Error at CMakeLists.txt:110 (message): Could not find libgcrypt's headers (try WITH_LIBGCRYPT_INCLUDE_DIR). -- Configuring incomplete, errors occurred! See also "/<>/ssh/build/CMakeFiles/CMakeOutput.log". make[1]: *** [debian/rules:26: override_dh_auto_configure] Error 1 This seems to have regressed when libssh2-1-dev 1.9.0-3 dropped its dependency on libgcrypt20-dev. The libssh2 change is currently blocked from entering testing, so this issue only affects sid at least for now. -- Niko Tyni nt...@debian.org
Bug#988790: libhttp-lrdd-perl: FTBFS: Undefined subroutine &Scalar::Util::set_prototype called
Source: libhttp-lrdd-perl Version: 0.106-2 Severity: serious Tags: ftbfs This package fails to build from source on current sid. # Failed test 'use HTTP::LRDD;' # at t/01basic.t line 19. # Tried to use 'HTTP::LRDD'. # Error: Undefined subroutine &Scalar::Util::set_prototype called at /usr/share/perl5/Types/TypeTiny.pm line 360. Full logs available at https://tests.reproducible-builds.org/debian/libhttp-lrdd-perl According to the test history there, this regressed between 2020-10-29 and 2020-11-03, probably with libtype-tiny-perl 1.012000-1. #975208 looks similar and indicates this is probably an issue with an outdated Scalar::Util in inc/ . I don't know why libhttp-lrdd-perl wasn't spotted back then, but better late than never I guess. -- Niko Tyni nt...@debian.org
