Bug#1071129: perl: crash in freelocale()
: Perl_call_sv (perl.c:3150) ==794839== Block was alloc'd at ==794839==at 0x4840808: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==794839==by 0x496C52A: newlocale (newlocale.c:199) ==794839==by 0x39DD9B: S_emulate_setlocale_i (locale.c:1301) ==794839==by 0x3A0936: Perl_set_numeric_standard (locale.c:2031) ==794839==by 0x39D76D: S_new_LC_ALL (locale.c:2518) ==794839==by 0x3A5F20: Perl_init_i18nl10n (locale.c:5637) ==794839==by 0x14E492: main (perlmain.c:102) ==794839== ==794839== ==794839== HEAP SUMMARY: ==794839== in use at exit: 116,898 bytes in 78 blocks ==794839== total heap usage: 13,878 allocs, 13,801 frees, 3,178,315 bytes allocated ==794839== ==794839== LEAK SUMMARY: ==794839==definitely lost: 0 bytes in 0 blocks ==794839==indirectly lost: 0 bytes in 0 blocks ==794839== possibly lost: 0 bytes in 0 blocks ==794839==still reachable: 116,898 bytes in 78 blocks ==794839== suppressed: 0 bytes in 0 blocks ==794839== Rerun with --leak-check=full to see details of leaked memory ==794839== ==794839== For lists of detected and suppressed errors, rerun with: -s ==794839== ERROR SUMMARY: 13 errors from 2 contexts (suppressed: 0 from 0) -- Niko Tyni nt...@debian.org
Bug#1069247: libconfig-model-dpkg-perl: test failures
[Copying Julian as the apt maintainer.] On Sat, Apr 20, 2024 at 09:02:35PM +0300, Niko Tyni wrote: > On Sat, Apr 20, 2024 at 11:09:17AM +0200, Dominique Dumont wrote: > > On Thursday, 18 April 2024 19:21:55 CEST you wrote: > > > Source: libconfig-model-dpkg-perl > > > Version: 3.004 > > > Severity: serious > > > Tags: ftbfs > > > Justification: fails to build from source > > > > This really looks like a bug with prove: > > > > $ perl t/reorder.t > > ok 1 - test re-ordered list > > 1..1 > > > I can't see what's wrong with the output of reorder test... > > Looks like something is injecting apt progress messages to stdout with > CR characters hiding it on the terminal but obviously not from `prove`. > > $ perl t/reorder.t |od -c > 460 f o r m a t i o n . . . 0 % \r > 500 > * > 540 \r o k 1 - t e s t r e > 560 - o r d e r e d l i s t \n 1 . > 600 . 1 \n These come from apt, via libapt-pkg-perl which I don't think has ever filtered them away. The thing that broke this is surely output changes in apt 2.9. The crucial difference wrt. at least bookworm seems to be that the apt messages used to end with a line feed "\n" before the actual TAP format started. Now it only has a carriage return "\r" there. Apparently `prove` ignores unknown lines, but now interprets all the apt output to be part of the first line that ends with the 'ok 1' part. So that gets ignored as well. I see the TAP format spec says at https://testanything.org/tap-version-14-specification.html A Harness should normalize line endings by replacing any instances of \r\n or \r in the TAP document with \n. so I suppose this might be a normal/wishlist bug in `prove`. In that case, please note that it needs to be fixed in libtest-harness-perl first as src:perl just bundles an older version of it. Not sure if apt should go back to ending its output with a line feed. Julian, what do you think? -- Niko
Bug#1069247: libconfig-model-dpkg-perl: test failures
On Sat, Apr 20, 2024 at 11:09:17AM +0200, Dominique Dumont wrote: > On Thursday, 18 April 2024 19:21:55 CEST you wrote: > > Source: libconfig-model-dpkg-perl > > Version: 3.004 > > Severity: serious > > Tags: ftbfs > > Justification: fails to build from source > > This really looks like a bug with prove: > > $ perl t/reorder.t > ok 1 - test re-ordered list > 1..1 > I can't see what's wrong with the output of reorder test... Looks like something is injecting apt progress messages to stdout with CR characters hiding it on the terminal but obviously not from `prove`. $ perl t/reorder.t |od -c 000 \r R e a d i n g p a c k a g e 020 l i s t s . . . 0 % \r \r R e 040 a d i n g p a c k a g e l i 060 s t s . . . 1 0 0 % \r 100 120 \r \r B u i l 140 d i n g d e p e n d e n c y 160 t r e e . . . 0 % \r \r B u i l 200 d i n g d e p e n d e n c y 220 t r e e . . . 0 % \r \r B u i l 240 d i n g d e p e n d e n c y 260 t r e e . . . 5 0 % \r \r B u i 300 l d i n g d e p e n d e n c y 320 t r e e . . . 5 0 % \r 340 360 \r \r R 400 e a d i n g s t a t e i n f 420 o r m a t i o n . . . 0 % \r \r 440 R e a d i n g s t a t e i n 460 f o r m a t i o n . . . 0 % \r 500 * 540 \r o k 1 - t e s t r e 560 - o r d e r e d l i s t \n 1 . 600 . 1 \n 603 HTH, -- Niko
Bug#1068934: perl: autopkgtest failure due to the t64 package rename
Source: perl
Version: 5.38.2-3.2
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: time-t
X-Debbugs-Cc: Steve Langasek
perl is failing its own autopkgtest checks in sid because of the
libperl5.38 rename to libperl5.38t64.
https://ci.debian.net/packages/p/perl/unstable/amd64/45047732/
autopkgtest [15:18:55]: test control: prove debian/t/control.t
autopkgtest [15:18:55]: test control: [---
control.t: warning: can't parse dependency ${t64:Provides}
# Failed test 'Breaks for libfilter-perl in libperl5.38t64 implies
Provides'
# at debian/t/control.t line 267.
# Failed test 'Breaks for libfilter-perl in libperl5.38t64 implies
Replaces'
# at debian/t/control.t line 269.
Use of uninitialized value $replaced_version in substitution (s///) at
debian/t/control.t line 273.
[...]
The main issue is solved with just a
sed -i 's/libperl5.38//' debian/t/control.t
but there's also the "can't parse dependency ${t64:Provides}" warning
coming from Dpkg::Deps which cannot handle unsubstituted substvars. We
already fix a similar ${perlapi:Provides} case, so that can be extended
to tackle this as well.
Patch attached. The test passes for me with this on amd64 at least.
--
Niko Tyni nt...@debian.org
>From 81649053d3b4ecf857977c797100c024a25c04de Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Sat, 13 Apr 2024 20:51:17 +0300
Subject: [PATCH] Fix autopkgtest test after t64 changes
---
debian/t/control.t | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/debian/t/control.t b/debian/t/control.t
index 977338ee5..56608ea4e 100755
--- a/debian/t/control.t
+++ b/debian/t/control.t
@@ -77,7 +77,7 @@ my %known_epochs = (
# Replaces+Provides
my %triplet_check_skip = (
"perl-base" => [ "libfile-spec-perl" ],
- "libperl5.38" => [ "libfilter-perl" ],
+ "libperl5.38t64" => [ "libfilter-perl" ],
);
# list special cases where the name of the Debian package does not
@@ -162,8 +162,8 @@ for my $perl_package_info ($control->get_packages) {
for my $deptype ($breaksname, "Replaces", "Provides") {
next if !exists $perl_package_info->{$deptype};
- # Dpkg::Deps cannot parse unsubstituted substvars so remove this
- $perl_package_info->{$deptype} =~ s/\$\{perlapi:Provides}//;
+ # Dpkg::Deps cannot parse unsubstituted substvars so remove those
+ $perl_package_info->{$deptype} =~ s/\$\{\w+:Provides}//;
my $parsed = deps_parse($perl_package_info->{$deptype});
next if !defined $parsed;
--
2.39.2
Bug#1067305: libjson-schema-modern-perl: FTBFS: dh_auto_test: error: /usr/bin/perl Build test --verbose 1 returned exit code 3
On Wed, Mar 20, 2024 at 11:17:54PM +0100, gregor herrmann wrote:
> On Wed, 20 Mar 2024 22:00:40 +0100, Lucas Nussbaum wrote:
>
> > Source: libjson-schema-modern-perl
> > Version: 0.582-1
> > Severity: serious
> > Justification: FTBFS
> > Tags: trixie sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20240319 ftbfs-trixie
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> Same failure in all 3 tests:
> t/additional-tests-draft2019-09.t .. 1/? # Failed test 'evaluation result
> is incorrect'
> # at t/additional-tests-draft2019-09.t line 36.
> # expected false; got true
> # {
> # "valid": true
> # }
Indeed. It seems to have regressed with
libtest-json-schema-acceptance-perl_1.022-1, and specifically
by the removal of some of its dependencies. Just installing
libcpanel-json-xs-perl makes it pass again.
HTH,
--
Niko
Bug#1067241: perl: time64 build flags should go in $Config{ccflags}
Package: perl
Version: 5.38.2-3.2
Tags: patch
User: debian-...@lists.debian.org
Usertags: time-t
X-Debbugs-Cc: Steve Langasek
[ Steve: I'm sure you have bigger fish to fry but FYI anyway.
Apologies for the imbalance between verbosity and importance.
Comments welcome of course. ]
On the architectures affected by the time64 transition (32-bit !*i386),
I think we should store the relevant build flags[*] in %Config to make
sure XS (binary) modules get built with them.
[*] just -D_TIME_BITS=64 I think as the LFS flags are included already
This would have been critical if we were still relying on just
dpkg-buildflags to inject the flags: in that case, modules installed
from CPAN outside dpkg package management would have got misbuilt and
incompatible with the Perl interpreter (because the Perl interpreter
C structure includes a time_t field so its size affects the binary
interface between Perl and its modules.)
However, I understand gcc now sets the time64 flags by default. With
that I think this is mostly cosmetic as long as people use the normal
system compiler. So filing at severity:normal.
I'd still like to fix it so that %Config includes flags required for
binary compatibility between Perl and its binary modules, for transparency
and robustness. For instance, I can imagine someone trying to build CPAN
modules with a non-default compiler and wasting a lot of time because
we currently hide the flags.
I'm attaching an untested simple patch that I think should do it.
Full disclosure: it affects the flags that all XS modules get built
with, although those flags were in my understanding already implied for
current builds. Even so, I'm not quite sure if I should refrain from
adding them at this stage of the time64 transition.
If we decide not to do this at this time, I'm fine with postponing this
for the upcoming Perl 5.40 transition later this year, where all those
packages will get rebuilt anyway for Debian trixie. The downside with
that is that the upcoming Ubuntu LTS release will not have them (and
possibly it's too late for that now anyway.)
Some more detailed background follows.
Perl generally stores its C compiler and linker flags in
$Config{ccflags} and $Config{lddlflags} respectively.
% perl -V:ccflags
ccflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing
-pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64';
% perl -V:lddlflags
lddlflags='-shared -L/usr/local/lib -fstack-protector-strong';
These are passed on to XS module builds by ExtUtils::MakeMaker and
Module::Build to ensure that the resulting binary modules are compatible
with the Perl interpreter they were built for.
However, this mechanism is somewhat at odds with opt-in build flags such
as hardening, where we generally want to build perl itself with them but
don't want to force them on all XS module packages because they might
not be ready for them. We discussed this at length back in #657853 and
ended up with a solution where we filter away dpkg-buildflags induced
flags and don't store them in %Config, assuming that XS module packages
will get them from dpkg-buildlags themselves.
This was all fine until now, but the time64 flags are not opt-in like the
hardening flags because they affect the binary interface between Perl
and binary modules. So these flags need to be active in all XS module
builds, whether they want them or not, and therefore I don't think we
should filter them away like the others.
--
Niko Tyni nt...@debian.org
>From e1e5a411e58ec6120bddbe31a2d460673ef2961c Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Wed, 20 Mar 2024 18:25:26 +
Subject: [PATCH] Include time64 build flags in $Config{ccflags}
We should only filter away those dpkg-buildflags that are not mandatory
for binary compatibility.
---
debian/rules | 1 +
1 file changed, 1 insertion(+)
diff --git a/debian/rules b/debian/rules
index bd750b9c5..abb4890dd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -187,6 +187,7 @@ endif
$(shell dpkg-buildflags --get CFLAGS) \
; do \
case "$$flag" in -fstack-protector) ;; \
+ -D_TIME_BITS=64) ;; \
*) export flag; $(PERL_TO_USE) -i -pe "/^(cc|cpp)flags/ and \
s/(['\s])\Q\$$ENV{flag}\E(['\s])/\1\2/ and s/ +/ /" \
$(tmp)/$(lib)/$$file ;; \
--
2.43.0
Bug#1066249: libmediascan: FTBFS: api_test.c:80:3: error: implicit declaration of function ‘gettimeofday’ [-Werror=implicit-function-declaration]
[Paul: copying you for eyeballs as this seems to have been your pet
package at some point :)]
On Thu, Mar 14, 2024 at 06:21:35PM +0100, gregor herrmann wrote:
> On Wed, 13 Mar 2024 12:41:10 +0100, Lucas Nussbaum wrote:
> > > test_background.c: In function ‘test_background_api’:
> > > test_background.c:12:16: error: implicit declaration of function ‘mkdir’;
> > > did you mean ‘_mkdir’? [-Werror=implicit-function-declaration]
> > >12 | #define _mkdir mkdir
> I've pushed a patch to git which make the package compile without
> errors.
>
> Not going to upload as-is, as I hardly speak any C and don't really
> know what I'm doing and this is more than adding a missing #include
> or prototype and I don't understand the code.
I assume you mean the '#define _mkdir mkdir' part? The rest
seems straightforward.
AFAICS the code used to call mkdir(2) without the mode argument.
A simple test [1] indicates that will just put random garbage there,
so the resulting directory will have a different mode every time. Surely
that was always buggy.
I'm not convinced that affected functions in test/test_defects.c
or test/test_background.c ever get executed for us though? They have
unpatched horrific things like
const char *test_path = "C:\\Siojej3";
const char start_dir[] = "C:\\logitest";
In any case, your change
+int _mkdir(const char *pathname)
+{
+mkdir(*pathname, 0775);
+}
is not quite correct: I think it should read something like
int _mkdir(const char *pathname)
{
return mkdir(pathname, 0775)
}
to work properly.
But I think it would be easier to stick with the preprocessor and do
-#define _mkdir mkdir
+#include
+#define _mkdir(x) mkdir((x), 0755)
instead.
Hope this helps :)
[1] echo 'int main(void) { mkdir("ttt"); }' | gcc -xc - && strace -e mkdir
./a.out
--
Niko
Bug#1066498: dh-make-perl: autopkgtest regression due to time_t transition
On Thu, Mar 14, 2024 at 05:14:17PM +0100, gregor herrmann wrote: > After some thinking, I think I makes to (temporarily) allow both > libperl5.XXt64 and libperl5.XX, otherwise we'll have a mess during > the 5.40 transition. > (After that we can get rid of the option with the suffix again.) Sure we need to allow for libperl5.XX to stay future-proof. I was just thinking of hardcoding libperl5.38t64 as the (temporary) other option rather than using a generic libperl5.XXt64 name. But no worries :) -- Niko
Bug#1066498: dh-make-perl: autopkgtest regression due to time_t transition
On Wed, Mar 13, 2024 at 05:39:49PM +0100, gregor herrmann via pkg-perl-maintainers wrote: > On Wed, 13 Mar 2024 13:34:57 +0100, gregor herrmann wrote: > > > > 80s not ok 5 - Errno is in libperl5.38 or perl-base (or only perl-base > > > for perl < 5.22) > > libperl5.38 or as it's called nowadays: libperl5.38t64, that's the > > point probably … > > Fix committed in git. > > Reviews welcome; I'm not sure it's the most elegant and safe solution, > and also if this libperl5.38t64 naming has other effects. Thanks for fixing this. Didn't dig deeply into what the test is actually doing, but I think it'd be fine to just hardcode libperl5.38t64 FWIW. We can get rid of the suffix with 5.40, and I doubt any other distro will go through this than Ubuntu who we're syncing with anyway (for better or worse). But whatever works is good of course. -- Niko
Bug#1065759: Retitle libbio-samtools-perl: FTBFS on arm{el,hf}: lib/Bio/DB/Sam.xs:324:4: error: implicit declaration of function ‘bam_sort_core’; did you mean ‘bam_format1_core’? [-Werror=implicit-fu
Control: tag -1 patch On Tue, Mar 12, 2024 at 06:31:20PM +0100, Andreas Tille wrote: > I can confirm that this bug also occures on amd64 thus removing the > arm-restriction from the title. Unfortunately I have no idea how to fix > this (except by possibly suppressing the -Werror=implicit-function-declaration > option). Thus tagging 'help' Looks like bam_view1() and bam_sort_core() don't have prototypes in any header file in libbam-dev. Copying them from the actual .c files in samtools-legacy seems to work. Patch attached, this builds and passes the test suite for me. -- Niko >From 3ddc905c9ceb635c6c876de1d372eedaa45de425 Mon Sep 17 00:00:00 2001 From: Niko Tyni Date: Tue, 12 Mar 2024 20:53:33 + Subject: [PATCH] Lift prototypes of bam_view1 and bam_sort_core from bam.c in samtools-legacy This fixes builds with gcc -Werror=implicit-function-declaration . Bug-Debian: https://bugs.debian.org/1065759 --- lib/Bio/DB/Sam.xs | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/Bio/DB/Sam.xs b/lib/Bio/DB/Sam.xs index 023f655..2231477 100644 --- a/lib/Bio/DB/Sam.xs +++ b/lib/Bio/DB/Sam.xs @@ -32,6 +32,11 @@ /* stolen from bam_aux.c */ #define MAX_REGION 1<<29 +/* stolen from bam.c */ +extern void bam_view1(const bam_header_t *header, const bam1_t *b); +/* stolen from bam_sort.c */ +extern void bam_sort_core(int is_by_qname, const char *fn, const char *prefix, size_t max_mem); + typedef tamFile Bio__DB__Tam; typedef faidx_t*Bio__DB__Sam__Fai; typedef bamFile Bio__DB__Bam; -- 2.43.0
Bug#1060246: perl: proposed patch for perl ABI change due to 64-bit time_t
On Sat, Mar 02, 2024 at 11:51:16AM -0800, Steve Langasek wrote: > My sincerest apologies for having failed to reply to this email for so long. Thanks, appreciated. > On Sat, Jan 27, 2024 at 12:50:40PM +0200, Niko Tyni wrote: > > What about the libperl5.38 SONAME and package name? Is it OK for them > > to stay unchanged? I expect the interpreter struct size changing will > > affect the libperl ABI as well. > > I had been assuming that changing it in the one place is sufficient because > the packages would be updated in lockstep, but I see there are a few > packages depending on the lib without also depending on perlapi: Yes. The packages linking against libperl5.38 are typically programs that embed a Perl interpreter. OTOH the packages depending on perlapi-* provide Perl plugins (= loadable binary Perl modules). These two are somewhat orthogonal things. It's not clear to me if the perl interpreter structure size change changes the libperl ABI, but that seems probable. Anyway I agree it's better to err on the safe side. As you've noticed, the libperl package name change is not quite trivial. I don't think we've done that in the past except with full upstream version changes so there might be some sharp edges. I'm sorry about that. > Well, this hasn't happened but now I think it's urgent that it happens. As > I mentioned on IRC, we're entangled with gdbm and db5.3 time_t transitions, > and we can't safely rebuild perl on armhf *without* bumping the ABI > declarations. > > I can NMU this today if you want or I can leave it to you, please let me > know. As I already told Julian a few days ago on this bug, any necessary NMUs are welcome. Given the urgency we've ended up with, I'd prefer you do the upload and take responsibility for any bugs possibly introduced. > Yes we will be putting out fires as quickly as possible :) Thanks again for your work on this. -- Niko
Bug#1060246: perl: diff for NMU version 5.38.2-3.1
On Thu, Feb 29, 2024 at 10:24:06AM +0100, Julian Andres Klode wrote: > Control: tags 1060246 + patch > Control: tags 1060246 + pending > > Dear maintainer, > > I have prepared the following NMU, taking into consideration the > feedback to only override the ABI on the affected architectures. > > I'm not sure I want to upload it now, but as it stands, anything > build-depending on libapt-pkg-perl and other perl bindings to t64 > libraries will FTBFS. > > I uploaded it to Ubuntu but it's stuck waiting for db5.3; I believe > vorlon has done binary-uploads for db5.3 in Debian to unblock it > there though. > > Let me know what you think. Thanks. It's clear that the perlapi names need to be bumped on the affected ports like this patch does. Just binNMU'ing perl as-is would lead to a perl that can't load the binary modules in arch:any lib*-perl packages in the archive. I'm much less clear on whether a libperl5.38t64 package will be needed. Any necessary NMUs are welcome (assuming the uploader takes the normal responsibility of course). I don't intend to upload time64 related changes myself (at least not on any kind of a short notice after waiting a month for comments.) No idea if the test failures mentioned in this bug will block things, but I'm sure the uploader will find out. That said, > +ifeq (,$(findstring $(DEB_HOST_ARCH), amd64 arm64 hurd-i386 i386 mips64el > ppc64el riscv64 s390x)) isn't this a substring match where i386 already covers hurd-i386? Guess that doesn't matter much though and none of those words match any intended port architectures. -- Niko
Bug#1063819: dh-sysuser: uses deprecated given/when
On Tue, Feb 13, 2024 at 01:07:59AM +0100, Lorenzo Puliti wrote: > Package: dh-sysuser > Version: 1.3.10+really1.4.4 > Severity: normal > Tags: patch > X-Debbugs-Cc: Niko Tyni , plore...@disroot.org > > Building runit package I have >dh_sysuser -O--sourcedirectory=runit-2.1.2/src > given is deprecated at /usr/bin/dh_sysuser line 37. > when is deprecated at /usr/bin/dh_sysuser line 38. > when is deprecated at /usr/bin/dh_sysuser line 39. > when is deprecated at /usr/bin/dh_sysuser line 46. >dh_install -O--sourcedirectory=runit-2.1.2/src >dh_installdocs -O--sourcedirectory=runit-2.1.2/src >dh_buildinfo -O--sourcedirectory=runit-2.1.2/src > > so I guess it needs an update like in dh-runit's #1060709 > What I'm not sure is if this need to be fixed in unstable as > possible or it can wait longer. The autopkgtest covers only > sysuser-helper, so the package does not fail to build. > Patch at the bottom. > > Dear Niko, please bump the severity if this is urgent. No particular urgency from my side, but thanks for asking. The similar ones I filed at severity:serious for the Perl 5.38 transition were precisely because they were causing build or autopkgtest failures. Those were technical blockers for getting the new perl into testing. By your description this one is "just" cosmetic. Of course it would be nice to fix it but it can wait :) Thanks for your work on Debian, -- Niko
Bug#1060246: perl: proposed patch for perl ABI change due to 64-bit time_t
On Sun, Jan 21, 2024 at 09:41:26AM -0800, Steve Langasek wrote: > On Tue, Jan 09, 2024 at 12:06:40AM +0200, Niko Tyni wrote: > > ifeq (s390x-linux-gnu,$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)) > > perlabi = 5.18.2d > > else > > perlabi = > > endif > > > as per > > https://salsa.debian.org/perl-team/interpreter/perl/-/commit/a66f196c13108b04909f9ec0e05986983cb2ed19 > > That's a very good point that I didn't think of, I'm +1 for doing it this > way. OK, great! > > > This is entirely optional anyway, as perl > > > 5.38 is just around the corner, at which point this patch should be > > > dropped > > > completely (assuming time_t lands before perl 5.38 does). > > > > TBH I was hoping 5.38 would land first :) > > And it has \o/ > > Do you want me to provide an updated patch, or will you integrate this on > your side? I'd like to understand the plan and expectations first. Apologies if I'm just slow and this should all be obvious. Do you want an upload to experimental with this right away? Or will there be a set of source uploads switching the affected architectures to 64-bit time_t at one point and this should be part of that? If you want it right away, perl will initially still use the 32-bit time_t but declare it Provides perlapi-5.38.2-t64. Should it also Provide the old perlapi-5.38.2 so that the affected (~500, mostly lib*-perl) binary packages stay installable before they are rebuilt? What about the libperl5.38 SONAME and package name? Is it OK for them to stay unchanged? I expect the interpreter struct size changing will affect the libperl ABI as well. Will somebody else upload perl to sid on the flag day? Is that expected to be a no-change upload of the version in experimental, or should there be versioned build dependencies ensuring that time64 builds of libc, libdb et al. get picked up? Also wrt. the exact patch: now that we've established the perlapi name change will be only be done for the affected architectures, I suppose I'll need a list of those. Should the 32-bit archs on debian-ports be included? Could I just use DEB_HOST_ARCH_BITS (except i386?)? > > Failed 7 tests out of 2623, 99.73% okay. > > ../cpan/DB_File/t/db-btree.t > > ../cpan/DB_File/t/db-hash.t > > ../cpan/DB_File/t/db-recno.t > > ../cpan/DB_File/t/db-threads.t > > ../cpan/Memoize/t/errors.t > > ../cpan/Memoize/t/tie.t > > porting/libperl.t > > > but I guess that's because things like libdb5.3 need to be rebuilt first? > > Sorry, haven't tried anything like this yet. ABI skew with dependencies > could certainly explain test suite failures! I'm concerned that this may be a blocker on the flag day if not tackled earlier. My intuition is the DB_File failures will probably go away once libdb is built with 64-bit time, but I'm less optimistic about the Memoize or libperl tests. I'm also concerned that the binNMUs of the perlapi-* reverse dependencies might FTBFS in sid with the 64-bit time_t change if not tested beforehand, and in the worst case render much of sid uninstallable. Is the plan to just put out any fires as they are spotted, and how much urgency will there be at that point? So many questions :) Many thanks for working on this. -- Niko
Bug#1060759: resource-agents: autopkgtest failure: MailTo hanging
Package: resource-agents Version: 1:4.13.0-1 Hi, the perl_5.38.2-3 migration checks for resource-agents are currently failing on ci.debian.net. https://ci.debian.net/data/autopkgtest/testing/amd64/r/resource-agents/41787962/log.gz 250s Running: ocft test -v MailTo 250s Starting '[33mMailTo[0m' case 0 '[33mcheck base env[0m': 250s Setting agent environment:export OCF_RESKEY_email=root@localhost 251s Running agent:./MailTo start 274s ERROR: The agent was hanging, killed it, maybe you damaged the agent or system's environment, see details below: 274s (No further details are provided AFAICS.) I cannot reproduce this, but I *think* what happens is that autopkgtest is choosing sendmail over exim4 when mixing packages from testing and unstable, and sendmail tries to connect to localhost:25 and hangs due to firewall settings. This is a guess based on my tests in a chroot where the mails ended up in /var/mail with exim4 but actually got sent to the root alias of the underlying host with sendmail. Not sure what to do about this. Perhaps make the test depend on exim4 or something even simpler that can be relied to deliver locally? Thanks for your work on Debian, -- Niko Tyni nt...@debian.org
Bug#1060758: texinfo: please allow-stderr for debian/tests/test-suite
Package: texinfo Version: 7.1-2 X-Debbugs-Cc: Sebastian Ramacher Hi, the perl_5.38.2-3 migration checks for texinfo are currently failing on ci.debian.net. https://ci.debian.net/packages/t/texinfo/testing/amd64/41788013/ 160s autopkgtest [07:52:27]: summary 160s test-suite FAIL stderr: In file included from ../system.h:53, What happens here is that the package build (as requested with build-needed) gets done with both perl and linux-libc-dev from unstable, but the actual tests are run with perl from unstable and linux-libc-dev from testing. This leads to 'make check' noticing that dependencies have changed and rebuilding (at least part) of the source. The rebuild produces compiler warnings on stderr, making the test fail. Please consider adding 'allow-stderr' to the test definition to make it survive this corner case. The root cause here is presumably the autopkgtest fallback to install more things from unstable than strictly needed in case of installability problems, but 'allow-stderr' would help as a workaround. Sebastian (cc'd) said he'd ignore the test for Perl 5.38 migration but asked me to file this. Thanks for your work on Debian, -- Niko Tyni nt...@debian.org
Bug#1060740: regripper: autopkgtest failure with Perl 5.38: changed diagnostics
Package: regripper Version: 3.0~git20221205.d588019+dfsg-1 Severity: serious Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails its autopkgtest checks with Perl 5.38 (currently in unstable.) https://ci.debian.net/packages/r/regripper/testing/amd64/41787955/ 27s autopkgtest [07:40:54]: test listplugins: [--- 28s autopkgtest [07:40:55]: test listplugins: ---] 28s autopkgtest [07:40:55]: test listplugins: - - - - - - - - - - results - - - - - - - - - - 28s listplugins FAIL non-zero exit status 1 This is unfortunately terse, but looking into it, it boils down to a changed diagnostic when calling require() on a plugin with a syntax error: trixie# perl -E 'say $^V; eval "require q(/usr/lib/regripper/plugins/clsid_tln.pl)"; die $@' v5.36.0 syntax error at /usr/lib/regripper/plugins/clsid_tln.pl line 112, near "$scriptlet)" Compilation failed in require at (eval 1) line 1. vs. sid# perl -E 'say $^V; eval "require q(/usr/lib/regripper/plugins/clsid_tln.pl)"; die $@' v5.38.2 syntax error at /usr/lib/regripper/plugins/clsid_tln.pl line 112, near "$scriptlet)" Execution of /usr/lib/regripper/plugins/clsid_tln.pl aborted due to compilation errors. Compilation failed in require at (eval 1) line 1. Presumably the best fix is to correct the (longstanding) syntax error in the plugin. Sorry for not catching this earlier. I only checked packages with Testsuite: autopkgtest-pkg-perl or Testsuite-Triggers: perl. I suppose I should have looked at Depends:perl too. -- Niko Tyni nt...@debian.org
Bug#1060713: libhttp-tiny-perl: current version superseded by Perl 5.38
Package: libhttp-tiny-perl Version: 0.082-2 Severity: serious Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition The version of this separate package in unstable is older than the one bundled with Perl 5.38, so they are uninstallable together. The separate package should be either updated to a newer version or removed as unnecessary. -- Niko Tyni nt...@debian.org
Bug#1060712: libextutils-cbuilder-perl: current version superseded by Perl 5.38
Package: libextutils-cbuilder-perl Version: 0.280236-2 Severity: serious Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition The version of this separate package in unstable is older than the one bundled with Perl 5.38, so they are uninstallable together. The separate package should be either updated to a newer version or removed as unnecessary. -- Niko Tyni nt...@debian.org
Bug#1060710: dnsenum: autopkgtest failure with Perl 5.38: Smartmatch is deprecated
Package: dnsenum Version: 1.3.1-1 Severity: serious User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails its autopkgtest checks with Perl 5.38 (currently in unstable.) 28s autopkgtest [21:35:23]: test command1: - - - - - - - - - - results - - - - - - - - - - 28s command1 FAIL stderr: Smartmatch is deprecated at /usr/bin/dnsenum line 749. 29s autopkgtest [21:35:24]: test command1: - - - - - - - - - - stderr - - - - - - - - - - 29s Smartmatch is deprecated at /usr/bin/dnsenum line 749. 29s Smartmatch is deprecated at /usr/bin/dnsenum line 751. Sorry for not catching this earlier. I only checked packages with Testsuite: autopkgtest-pkg-perl or Testsuite-Triggers: perl. I suppose I should have looked at Depends:perl too. -- Niko Tyni nt...@debian.org
Bug#1060707: dh-make-elpa: autopkgtest failure with Perl 5.38: smartmatch is deprecated
Package: dh-make-elpa Version: 0.19.2 Severity: serious User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails its autopkgtest checks with Perl 5.38 (currently in unstable.) autopkgtest [11:06:58]: test test-dh-make-elpa: ---] autopkgtest [11:06:58]: test test-dh-make-elpa: - - - - - - - - - - results - - - - - - - - - - test-dh-make-elpaFAIL stderr: Smartmatch is deprecated at /usr/share/perl5/DhMakeELPA/Command/make.pm line 99. autopkgtest [11:06:58]: test test-dh-make-elpa: - - - - - - - - - - stderr - - - - - - - - - - Smartmatch is deprecated at /usr/share/perl5/DhMakeELPA/Command/make.pm line 99. autopkgtest [11:06:58]: summary test-dh-make-elpaFAIL stderr: Smartmatch is deprecated at /usr/share/perl5/DhMakeELPA/Command/make.pm line 99. Sorry for not catching this earlier. I only checked packages with Testsuite: autopkgtest-pkg-perl or Testsuite-Triggers: perl. I suppose I should have looked at Depends:perl too. -- Niko Tyni nt...@debian.org
Bug#1060709: dh-runit: autopkgtest failure with Perl 5.38: given is deprecated
Package: dh-runit Version: 2.15.2 Severity: serious User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails its autopkgtest checks with Perl 5.38 (currently in unstable.) autopkgtest [21:33:45]: test command1: - - - - - - - - - - results - - - - - - - - - - command1 FAIL stderr: given is deprecated at /usr/bin/dh_runit line 50. autopkgtest [21:33:45]: test command1: - - - - - - - - - - stderr - - - - - - - - - - Sorry for not catching this earlier. I only checked packages with Testsuite: autopkgtest-pkg-perl or Testsuite-Triggers: perl. I suppose I should have looked at Depends:perl too. -- Niko Tyni nt...@debian.org
Bug#1060456: rxvt-unicode: 9.31-1+b1 breaks UTF-8 display
On Fri, Jan 12, 2024 at 04:35:04PM +0100, Sven Joachim wrote: > Speaking of Perl 5.38, this bug is actually a problem in Perl. The > rxvt-unicode patch just works around it. According to the Perl upstream > bug (https://github.com/Perl/perl5/issues/21366), at least one other > application (irssi) is affected. > > Fedora has apparently reverted a commit in Perl to fix the problem, see > https://src.fedoraproject.org/rpms/perl/c/dee564d443debbf47127d668f0982165835d873b. Thanks! I've done the same in perl_5.38.2-3, just uploaded. -- Niko
Bug#1060653: os-autoinst: FTBFS on i386: t/01-test_needle.t failure
Source: os-autoinst Version: 4.6.1699947509.970d0609-1 Severity: serious Tags: ftbfs This package failed to build against Perl 5.38 in sid on i386 with three retries so far. The issue is currently a blocker for the ongoing Perl 5.38 transition. Latest log is at https://buildd.debian.org/status/fetch.php?pkg=os-autoinst=i386=4.6.1699947509.970d0609-1=1704966657=0 3: # Failed test 'found area is the original one too' 3: # at ./t/01-test_needle.t line 95. 3: # got: '944' 3: # expected: '108' 3: # Looks like you failed 1 test of 84. [...] 3: Test Summary Report 3: --- 3: ./t/01-test_needle.t (Wstat: 256 (exited 1) Tests: 84 Failed: 1) 3: Failed test: 16 3: Non-zero exit status: 1 3: Files=52, Tests=1222, 126 wallclock secs ( 0.68 usr 0.14 sys + 110.76 cusr 12.18 csys = 123.76 CPU) 3: Result: FAIL 3/3 Test #3: test-perl-testsuite ..***Failed 125.71 sec The following tests passed: test-installed-files test-doc-testapi-spellchecking 67% tests passed, 1 tests failed out of 3 Total Test time (real) = 126.44 sec The following tests FAILED: 3 - test-perl-testsuite (Failed) Errors while running CTest Output from these tests are in: /<>/build/Testing/Temporary/LastTest.log Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely. FAILED: CMakeFiles/check-pkg-build /<>/build/CMakeFiles/check-pkg-build cd /<>/build && /usr/bin/ctest -V -E test-local-.* ninja: build stopped: subcommand failed. make[1]: *** [debian/rules:46: override_dh_auto_test] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:6: binary-arch] Error 2 -- Niko Tyni nt...@debian.org
Bug#1026046: FTBFS: test failures on some architectures
Control: found -1 0.51-1 Control: severity -1 serious Control: block 1055955 with -1 On Tue, Dec 13, 2022 at 07:33:46PM +0100, gregor herrmann wrote: > Source: libdevel-mat-perl > Version: 0.49-1 > Severity: important > Tags: upstream > Forwarded: https://rt.cpan.org/Ticket/Display.html?id=134117 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > According to https://buildd.debian.org/status/package.php?p=libdevel-mat-perl > the package has a test failure on at least i386 and mipsel64el but > maybe the architectures are just random. Either it's gotten worse or it's just bad luck, but previously built archs (armhf and armel) are now failing, making this release critical and blocking the Perl 5.38 transition. armel has had three retries so far but let's hope it will succeed eventually. Even in that case I think this should stay RC until some action is taken. Guess we could just skip / ignore t/02context.t, or alternatively make the build fail deterministically on the affected architectures and remove the existing binaries... -- Niko
Bug#1060458: perl-tk: FTBFS with Perl 5.38 on big-endian 64-bit: test failures
Source: perl-tk
Version: 1:804.036+dfsg1-1
Severity: serious
Tags: ftbfs patch
User: debian-p...@lists.debian.org
Usertags: perl-5.38-transition
This package failed to build against Perl 5.38 on s390x, ppc64, sparc64,
and alpha.
This is because Perl upstream changed the implementation of SvPV() et
al., triggering a latent bug in perl-tk that bites on big endian 64-bit
architectures. The attached patch fixes this, see the commit message
for more detail. I've tested that it works on both s390x and amd64,
on Perl 5.36 (trixie) and 5.38 (sid).
Not sure why alpha is failing too, but it has a slightly different
failure mode. I suspect alignment issues.
This is currently a hard blocker for the ongoing Perl 5.38 transition as
perl-tk has quite a few reverse dependencies that are now uninstallable
on s390x.
# Failed test 'Creating Balloon widget'
# at t/balloon.t line 31.
# got: 'couldn't recognize image data at
/<>/blib/lib/Tk/Image.pm line 21.
# at /<>/blib/lib/Tk/Balloon.pm line 62.
# '
# expected: ''
[...]
Test Summary Report
---
t/balloon.t(Wstat: 512 (exited 2) Tests: 12 Failed: 11)
Failed tests: 2-12
Non-zero exit status: 2
Parse errors: Bad plan. You planned 14 tests but ran 12.
t/canvas.t (Wstat: 0 Tests: 166 Failed: 0)
TODO passed: 124
t/canvas2.t(Wstat: 65280 (exited 255) Tests: 0 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 87 tests but ran 0.
t/listbox.t(Wstat: 0 Tests: 537 Failed: 0)
TODO passed: 320-322, 328, 502
t/photo.t (Wstat: 65280 (exited 255) Tests: 100 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 111 tests but ran 100.
t/text.t (Wstat: 0 Tests: 415 Failed: 0)
TODO passed: 121
t/wm-tcl.t (Wstat: 0 Tests: 315 Failed: 0)
TODO passed: 86-87, 154-157, 164-165, 175-178, 221-224
237-239, 264-265, 275-276, 280-283
t/zzScrolled.t (Wstat: 0 Tests: 94 Failed: 0)
TODO passed: 52, 66, 80, 94
Files=76, Tests=4267, 36 wallclock secs ( 0.23 usr 0.05 sys + 6.02 cusr
0.69 csys = 6.99 CPU)
Result: FAIL
--
Niko Tyni nt...@debian.org
>From a26233c844c52f49ef9cca5f88dd9063aac60d0f Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Thu, 11 Jan 2024 18:28:58 +
Subject: [PATCH] Fix STRLEN vs int pointer confusion in
Tcl_GetByteArrayFromObj()
Perl 5.37.2, more precisely commit
https://github.com/Perl/perl5/commit/1ef9039bccbfe64f47f201b6cfb7d6d23e0b08a7
changed the implementation of SvPV() et al., breaking t/balloon.t,
t/canvas2.t and t/photo.t on big-endian 64-bit architectures such as
ppc64 and s390x because StringMatchGIF() no longer recognized GIF files.
This is because Tcl_GetByteArrayFromObj() was calling SvPV() with an int
pointer instead of a correct STRLEN pointer, and the new implementation
is more sensitive to this: it assigns the pointers as-is, resulting in
the int pointer pointing at the wrong end of the 64-bit length.
Other functions taking a length pointer, at least Tcl_GetStringFromObj()
already seem to do things correctly, so presumably this is not a
systematic issue.
---
objGlue.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/objGlue.c b/objGlue.c
index d4927ea..dbd6a50 100644
--- a/objGlue.c
+++ b/objGlue.c
@@ -627,7 +627,10 @@ Tcl_GetByteArrayFromObj(Tcl_Obj * objPtr, int * lengthPtr)
sv_utf8_downgrade(objPtr, 0);
if (lengthPtr)
{
- return (unsigned char *) SvPV(objPtr, *lengthPtr);
+ STRLEN len;
+ unsigned char *s = SvPV(objPtr, len);
+ *lengthPtr = len;
+ return s;
}
else
{
--
2.30.2
Bug#1060404: libdata-streamserializer-perl: FTBFS on ppc64el: t/05_memory_leak.t failure
Control: severity -1 normal On Wed, Jan 10, 2024 at 09:00:27PM +0200, Niko Tyni wrote: > Source: libdata-streamserializer-perl > Source Version: 0.07-1 > Severity: serious > Tags: ftbfs > Control: block 1055955 with -1 > > This package failed to build from source on ppc64el against Perl 5.38. > > After two failures it looks deterministic but giving it back for a retry > might still be worth a try. It built on the third try, so lowering severity. > This is currently a blocker for the Perl 5.38 transition. Happily no longer :) -- Niko
Bug#1060404: libdata-streamserializer-perl: FTBFS on ppc64el: t/05_memory_leak.t failure
Source: libdata-streamserializer-perl Source Version: 0.07-1 Severity: serious Tags: ftbfs Control: block 1055955 with -1 This package failed to build from source on ppc64el against Perl 5.38. After two failures it looks deterministic but giving it back for a retry might still be worth a try. This is currently a blocker for the Perl 5.38 transition. https://buildd.debian.org/status/fetch.php?pkg=libdata-streamserializer-perl=ppc64el=0.07-1%2Bb10=1704894151=0 # Failed test 'Check memory leak (196608 bytes)' # at t/05_memory_leak.t line 63. # Looks like you failed 1 test of 3. t/05_memory_leak.t 1..3 ok 1 - use Data::StreamSerializer; not ok 2 - Check memory leak (196608 bytes) # 5100 iterations were done, 2668237 bytes were produced ok 3 - Check memory checker Dubious, test returned 1 (wstat 256, 0x100) Failed 1/3 subtests Test Summary Report --- t/05_memory_leak.t (Wstat: 256 (exited 1) Tests: 3 Failed: 1) Failed test: 2 Non-zero exit status: 1 Files=5, Tests=70, 4 wallclock secs ( 0.03 usr 0.00 sys + 3.83 cusr 0.05 csys = 3.91 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#1060402: liblinux-termios2-perl: FTBFS on ppc64el: OS unsupported - no struct termios2
On Wed, Jan 10, 2024 at 08:30:21PM +0200, Niko Tyni wrote: > Source: liblinux-termios2-perl > Version: 0.01-2 > Severity: important > Tags: ftbfs > User: debian-ri...@lists.debian.org > Usertags: riscv64 > > This package has never built on riscv64. Sorry, s/riscv64/ppc64el/ here. > perl Build.PL --installdirs vendor --config "optimize=-g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --config > "ld=powerpc64le-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" >test-8985-0.c: In function ‘main’: >test-8985-0.c:4:19: error: storage size of ‘t’ isn’t known >4 | struct termios2 t; > | ^ >OS unsupported - no struct termios2 -- Niko
Bug#1060403: libxml-hash-xs-perl: FTBFS on s390x (big endian?): test failures
Source: libxml-hash-xs-perl Version: 0.56-1 Severity: important Tags: ftbfs This package has never built on s390x. Looking at debian-ports results, it's probably a big endian architecture issue. Latest s390x build log is at https://buildd.debian.org/status/fetch.php?pkg=libxml-hash-xs-perl=s390x=0.56-1=1613669844=0 # Testing XML::Hash::XS 0.56, Perl 5.032001, /usr/bin/perl # XML::LibXML 2.0134, libxml2 20910 t/00-load.t 1..1 ok 1 - use XML::Hash::XS; ok Invalid parameter 'canonical' at t/01-h2x.t line 21. # Looks like your test exited with 255 just after 1. t/01-h2x.t . 1..24 ok 1 - default Dubious, test returned 255 (wstat 65280, 0xff00) Failed 23/24 subtests t/02-h2d.t . skipped: Option 'doc' is not supported t/03-h2x-oop.t . 1..2 ok 1 - code reference ok 2 - code reference ok Invalid parameter 'attr' at t/04-h2x-lx.t line 36. # Looks like your test exited with 255 just after 3. [...] Test Summary Report --- t/01-h2x.t (Wstat: 65280 Tests: 1 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 24 tests but ran 1. t/04-h2x-lx.t(Wstat: 65280 Tests: 3 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 15 tests but ran 3. t/06-x2h.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 10 tests but ran 0. t/07-x2h_filter.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 6 tests but ran 0. Files=8, Tests=7, 0 wallclock secs ( 0.01 usr 0.00 sys + 0.28 cusr 0.02 csys = 0.31 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#1060402: liblinux-termios2-perl: FTBFS on ppc64el: OS unsupported - no struct termios2
Source: liblinux-termios2-perl Version: 0.01-2 Severity: important Tags: ftbfs User: debian-ri...@lists.debian.org Usertags: riscv64 This package has never built on riscv64. Latest build log is at https://buildd.debian.org/status/fetch.php?pkg=liblinux-termios2-perl=ppc64el=0.01-2=1600683841=0 dh_auto_configure -a perl Build.PL --installdirs vendor --config "optimize=-g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --config "ld=powerpc64le-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" test-8985-0.c: In function ‘main’: test-8985-0.c:4:19: error: storage size of ‘t’ isn’t known 4 | struct termios2 t; | ^ OS unsupported - no struct termios2 dh_auto_configure: error: perl Build.PL --installdirs vendor --config "optimize=-g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --config "ld=powerpc64le-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" returned exit code 25 make: *** [debian/rules:4: build-arch] Error 25 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 -- Niko Tyni nt...@debian.org
Bug#1060400: libapp-stacktrace-perl: FTBFS on riscv64: unthreaded.t failure
Source: libapp-stacktrace-perl Version: 0.09-5 Severity: important Tags: ftbfs User: debian-ri...@lists.debian.org Usertags: riscv64 This package has never built on riscv64. Latest build log is at https://buildd.debian.org/status/fetch.php?pkg=libapp-stacktrace-perl=riscv64=0.09-5=1694400120=0 Child exited at t/unthreaded.t line 9. # Looks like your test exited with 1 before it could output anything. t/unthreaded.t 1..5 Dubious, test returned 1 (wstat 256, 0x100) Failed 5/5 subtests Test Summary Report --- t/unthreaded.t (Wstat: 256 (exited 1) Tests: 0 Failed: 0) Non-zero exit status: 1 Parse errors: Bad plan. You planned 5 tests but ran 0. Files=4, Tests=1, 7 wallclock secs ( 0.12 usr 0.04 sys + 5.28 cusr 0.96 csys = 6.40 CPU) Result: FAIL -- NIko Tyni nt...@debian.org
Bug#1060399: libbson-xs-perl: FTBFS on riscv64: double.t failures
Source: libbson-xs-perl Version: 0.8.4-2 Severity: important Tags: ftbfs User: debian-ri...@lists.debian.org Usertags: riscv64 This package has never built on riscv64. Latest build log is at https://buildd.debian.org/status/fetch.php?pkg=libbson-xs-perl=riscv64=0.8.4-2=1690811919=0 # Failed test 'native_to_bson(bson_to_native(cB)) = cB' # at t/lib/CorpusTest.pm line 144. # Got: # 116400f87f00 # Expected: # 1164001200f87f00 # Looks like you failed 1 test of 5. # Failed test 'case: NaN with payload' # at t/corpus/double.t line 13. # Looks like you failed 1 test of 14. [...] Test Summary Report --- t/corpus/double.t (Wstat: 256 (exited 1) Tests: 14 Failed: 1) Failed test: 11 Non-zero exit status: 1 t/mapping/double.t (Wstat: 768 (exited 3) Tests: 39 Failed: 3) Failed tests: 23, 29, 35 Non-zero exit status: 3 Files=59, Tests=1342, 97 wallclock secs ( 2.74 usr 0.35 sys + 84.38 cusr 11.55 csys = 99.02 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#1060397: libsys-syscall-perl: FTBFS on riscv64: t/01-epoll.t failure
Source: libsys-syscall-perl Version: 0.25-7 Severity: important Tags: ftbfs User: debian-ri...@lists.debian.org Usertags: riscv64 This package has never built on riscv64. Latest build log is at https://buildd.debian.org/status/fetch.php?pkg=libsys-syscall-perl=riscv64=0.25-7=1691061212=0 # Failed test 'have epoll' # at t/01-epoll.t line 15. [...] Test Summary Report --- t/01-epoll.t (Wstat: 3840 (exited 15) Tests: 20 Failed: 15) Failed tests: 1-2, 5-12, 15-19 Non-zero exit status: 15 Files=3, Tests=23, 3 wallclock secs ( 0.14 usr 0.02 sys + 1.99 cusr 0.33 csys = 2.48 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#1024636: perl: add cross build support files for loongarch64
On Wed, Dec 13, 2023 at 03:47:05PM +0800, Bo YU wrote: > Package: perl > Version: 5.36.0-10 > Followup-For: Bug #1024636 > Tags: patch > X-Debbugs-Cc: rabenda...@gmail.com > > Dear Maintainer, > > I have followed the instructions from debian/cross/README to generate > these files which support cross build from native build on loong64 host. > but it is unclear to me how to verify if this binary works like you > comment on -1[#10]. Could you give me a little hint? > > But I think it should be no problem. > > [#10]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024636#10 Hi, thanks for your efforts. I only saw your message now as you mailed 1024636-qu...@bugs.debian.org which is not forwarded to the maintainer. Please use just 1024...@bugs.debian.org in the future. If the files are from a native build that passed the Perl test suite during the build, that's totally acceptable. My concern was about the previous hand crafted cross config files that looked like nobody had ever tested them at all. For such hand crafting, I suppose a minimal test would be to install the cross built binary perl packages on an actual loong64 host and run 'perl -V' or something like that. However, I'm afraid we have missed the train here: your patch is for Perl 5.36 but we're now moving to 5.38 (with perl_5.38.2-2 building in Debian unstable right now.) It makes little sense to include the 5.36 config files now, so unfortunately you'll have to redo the process with the 5.38 package. Apologies for the awkward process. It's all workarounds for perl upstream not supporting cross configuration properly due to lots of historical baggage. -- Niko Tyni nt...@debian.org
Bug#1055955: transition: perl 5.38
On Mon, Jan 08, 2024 at 11:23:36PM +0100, Sebastian Ramacher wrote: > On 2024-01-09 00:08:09 +0200, Niko Tyni wrote: > > On Sat, Dec 09, 2023 at 01:15:26PM +0200, Niko Tyni wrote: > > > On Tue, Nov 14, 2023 at 08:28:01PM +0200, Niko Tyni wrote: > > > > > > > this has taken me much longer than necessary for various reasons, but I > > > > think we're almost ready to push Perl 5.38 to sid now. > > > > > > > > > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.38-transition;users=debian-p...@lists.debian.org > > > > > I think we're as ready as can reasonably be, assuming you're OK with the > > > above testing removals. Please let me know when a suitable transition > > > slot becomes available. > > > > Hi, gentle ping on this? > > Please go ahead. Thanks. Just uploaded 5.38.2-2 targeting unstable. FTR, my last minute rebuild tests found #1060323 in opensp making libsgml-parser-opensp-perl ftbfs, so that one is going to fail binNMUs. But opensp should be trivial to fix and the count of reverse deps looked minimal, so not a showstopper. -- Niko
Bug#1060323: libosp-dev: missing dependency on libosp5
Package: libosp-dev Version: 1.5.2-14 Severity: serious Hi, the libosp-dev package in sid is missing a dependency on libosp5, leaving /usr/lib/libosp.so a dangling symlink and making at least libsgml-parser-opensp-perl (and probably other packages build-depending on libosp-dev) fail to build. -- Niko Tyni nt...@debian.org
Bug#1060246: perl: proposed patch for perl ABI change due to 64-bit time_t
On Mon, Jan 08, 2024 at 12:35:32AM -0800, Steve Langasek wrote: > Package: perl > Version: 5.36.0-10 > Severity: normal > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu noble ubuntu-patch > > Hi Niko, Dominic, > > Please find attached a prospective patch for perl that would annotate the > perlapi provides for perl-base after a 64-bit time_t transition for 32-bit > architectures, on perl 5.36.0. I've tested that this does what's expected, > both for the Provides: of perl-base and the behavior of dh_perl. Thanks! Glad the perlabi thing is still working. It hasn't had much use. > It tries to retain compatibility with perlapi-5.36.0 on architectures where > this is appropriate (64-bit architectures + i386); it covers Debian release > architectures + riscv64, but does not attempt to be complete for all > architectures dpkg knows about. Is there a reason you're bumping the abi for all the architectures rather than just the affected ones? I'd expect this to be "opt in" so perlabi would be defined just for armhf, hppa and so forth. I'm thinking something like what we did for the s390x jmp_buf thing ifeq (s390x-linux-gnu,$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)) perlabi = 5.18.2d else perlabi = endif as per https://salsa.debian.org/perl-team/interpreter/perl/-/commit/a66f196c13108b04909f9ec0e05986983cb2ed19 > This is entirely optional anyway, as perl > 5.38 is just around the corner, at which point this patch should be dropped > completely (assuming time_t lands before perl 5.38 does). TBH I was hoping 5.38 would land first :) I'm just waiting for a transition slot. (Hm, it's been a month now, guess I should ping the bug.) OOC, have you got the perl test suite passing with time64? I just did a quick try on i386 with just DEB_BUILD_OPTIONS=abi=+time64 and I'm seeing Failed 7 tests out of 2623, 99.73% okay. ../cpan/DB_File/t/db-btree.t ../cpan/DB_File/t/db-hash.t ../cpan/DB_File/t/db-recno.t ../cpan/DB_File/t/db-threads.t ../cpan/Memoize/t/errors.t ../cpan/Memoize/t/tie.t porting/libperl.t but I guess that's because things like libdb5.3 need to be rebuilt first? -- Niko
Bug#1055955: transition: perl 5.38
On Sat, Dec 09, 2023 at 01:15:26PM +0200, Niko Tyni wrote: > On Tue, Nov 14, 2023 at 08:28:01PM +0200, Niko Tyni wrote: > > > this has taken me much longer than necessary for various reasons, but I > > think we're almost ready to push Perl 5.38 to sid now. > > > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.38-transition;users=debian-p...@lists.debian.org > I think we're as ready as can reasonably be, assuming you're OK with the > above testing removals. Please let me know when a suitable transition > slot becomes available. Hi, gentle ping on this? -- Niko
Bug#1055955: transition: perl 5.38
On Tue, Nov 14, 2023 at 08:28:01PM +0200, Niko Tyni wrote: > this has taken me much longer than necessary for various reasons, but I > think we're almost ready to push Perl 5.38 to sid now. > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.38-transition;users=debian-p...@lists.debian.org > > There's a few packages that are nontrivially broken and will probably > need to be removed from testing. > > libapache-db-perl #1040396 > > libembperl-perl #1042845 > > polymake #1042521 The polymake bug was fixed recently (yay!). The other two remain, but libapache-db-perl got removed from testing already. I don't see any rdeps for libembperl-perl so presumably it can be removed as well. We have one new blocker, not related to Perl 5.38 but preventing the necessary rebuild: libgit-raw-perl #1057318 The only reverse dependencies I can see are libgit-objectstore-perl and torrus-common, so seems like testing removal is a viable option here as well. I uploaded 5.38.2 to experimental in the meantime, and have re-run the rebuild and autopkgtest checks. I found no new Perl 5.38 related regressions, and the new rebuild blockers I found are already fixed. The (unrelated) pandoc mess causes quite a few failures in sid that interfered with the testing though. I think we're as ready as can reasonably be, assuming you're OK with the above testing removals. Please let me know when a suitable transition slot becomes available. Thanks for your work, -- Niko
Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure
On Tue, Dec 05, 2023 at 10:01:17PM +0100, Salvatore Bonaccorso wrote: > On Sun, Dec 03, 2023 at 03:05:09PM +0200, Niko Tyni wrote: > > While the stable update tiff_4.5.0-6+deb12u1 has security fixes, it does > > not include the change for CVE-2023-6277. The security tracker mentions > > it as a minor issue. I also checked earlier that stable is not affected. > > But would mean once we will pick CVE-2023-6277 libimager-perl in > bookworm or bullseye will break, correct? Yes, I think so. -- Niko
Bug#1057424: libmodule-build-perl: Multi-Arch: foreign makes other packages FTBFS
(dropped d-cross@) On Mon, Dec 04, 2023 at 10:04:42PM +0100, gregor herrmann wrote: > On Mon, 04 Dec 2023 21:59:12 +0200, Niko Tyni wrote: > > Filing against libmodule-build-perl for now to prevent it from entering > > trixie before the other two are changed. Feel free to reassign or clone > > or whatever if you like. > > Both fixed (by removing the :native) and uploaded. Thanks! > I guess we could upload libmodule-build-perl with versioned Breaks on > the 2 packages (and close this bug with the upload) to get the > migration/upgrade order right? Breaks seems a bit much given it's not runtime breakage. And it doesn't actually prevent trying to build with a broken combination of the packages. And Build-Conflicts works in the other direction, no help there AFAICS (and I don't think britney even looks at build dependencies for testing migration.) Maybe just wait a couple of days and close this when the two packages have migrated? -- Niko
Bug#1057424: libmodule-build-perl: Multi-Arch: foreign makes other packages FTBFS
Package: libmodule-build-perl Version: 0.423400-2 Severity: serious Tags: ftbfs Control: affects -1 libnet-cidr-set-perl libparams-validate-perl X-Debbugs-Cc: debian-cr...@lists.debian.org Control: block 1055955 with -1 The libnet-cidr-set-perl and libparams-validate-perl packages fail to build from source in current unstable. >From a full build log at http://perl.debian.net/rebuild-logs/sid/libparams-validate-perl_1.31-1/libparams-validate-perl_1.31-1.buildlog Command: dpkg-buildpackage --sanitize-env -us -uc -rfakeroot -Zxz dpkg-buildpackage: info: source package libparams-validate-perl dpkg-buildpackage: info: source version 1.31-1 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by gregor herrmann dpkg-source -Zxz --before-build . dpkg-buildpackage: info: host architecture amd64 dpkg-checkbuilddeps: error: Unmet build dependencies: libmodule-build-perl:native dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) This is because libmodule-build-perl was recently marked Multi-Arch:foreign, but dpkg-checkbuilddeps does not consider that as satisfying :native build dependencies, see #1023438. My understanding is that M-A:foreign is probably the right thing to do here, but we need to remove the :native build dependency in other packages first. Fortunately I see only two in the archive, libnet-cidr-set-perl and libparams-validate-perl. grep-dctrl -sPackage,Build-Depends,Build-Depends-Indep -FBuild-Depends,Build-Depends-Indep -r 'libmodule-build-perl[^,]*:native' /var/lib/apt/lists/*_main_source_Sources Filing against libmodule-build-perl for now to prevent it from entering trixie before the other two are changed. Feel free to reassign or clone or whatever if you like. As libparams-validate-perl is an arch:any XS module, we need to fix it one way or another before the Perl 5.38 transition. So marking this as a blocker. Copying the debian-cross list in case I got something wrong :) -- Niko Tyni nt...@debian.org
Bug#1057326: libtiff6: please Break older versions of libimager-perl due to #1057270
Package: libtiff6 Version: 4.5.1+git230720-2 X-Debbugs-Cc: libimager-p...@packages.debian.org As discussed in #1057270, the CVE-2023-6277 related change in 4.5.1+git230720-2 broke libimager-perl at runtime, making it unable to read TIFF files. This is fixed now, so please add Breaks: libimager-perl (<< 1.022+dfsg) to libtiff6 to make sure partial upgrades pull in the fixed version. -- Niko Tyni nt...@debian.org
Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure
On Sun, Dec 03, 2023 at 01:31:19AM +0100, gregor herrmann wrote: > On Sun, 03 Dec 2023 10:46:50 +1100, Tony Cook wrote: > > > > https://github.com/tonycoz/imager/issues/522 > > Fixed in 1.022, please let me know if you have any more problems. > > Thank you! > 1.022 builds fine in Debian unstable, so I've uploaded it. Thanks! > > d54ea521f63ec1ed7d8c0fd11c23507600d51143 should be safe to cherry pick > > back to 1.020 if you don't want all of the 1.021 TIFF changes in > > the debian stable libimager-perl. > > Hm, Debian stable (which has 1.019) is a good question. If libtiff is > updated there too [0] we might see the same issue there. While the stable update tiff_4.5.0-6+deb12u1 has security fixes, it does not include the change for CVE-2023-6277. The security tracker mentions it as a minor issue. I also checked earlier that stable is not affected. > So I guess we don't have to do anything here, and if reality is > different than my tests, we can pull in > d54ea521f63ec1ed7d8c0fd11c23507600d51143 -- thanks for the pointer! Agreed & thanks again :) -- Niko
Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure
Control: forwarded -1 https://github.com/tonycoz/imager/issues/522
On Sat, Dec 02, 2023 at 07:24:39PM +0200, Niko Tyni wrote:
> On Sat, Dec 02, 2023 at 01:40:51PM +0100, gregor herrmann wrote:
> > On Sat, 02 Dec 2023 14:24:01 +0200, Niko Tyni wrote:
> It can be reproduced like this with the libimager-perl binaries
> currently in sid and every tiff file I tried with, for example
> test/images/palette-1c-8b.tiff in src:tiff.
Further simplifying, this fails in the exact same way:
$ perl -MImager -e '$i=Imager->new; Imager::init_log(); $i->read(file =>
shift) or die $i->_error_as_msg()' tiff/test/images/palette-1c-8b.tiff
> I note it says "filesize 0". The patch determines the file size with
>
> uint64_t filesize = TIFFGetFileSize(tif);
>
> and TIFFGetFileSize() is in src:tiff libtiff/tiffiop.h as follows:
>
> #define TIFFGetFileSize(tif) ((*(tif)->tif_sizeproc)((tif)->tif_clientdata))
>From http://www.simplesystems.org/libtiff/functions/TIFFOpen.html
TIFFClientOpen() is like TIFFOpen() except that the caller supplies a
collection of functions that the library will use to do UNIX-like I/O
operations. The readproc and writeproc functions are called to read and
write data at the current file position. seekproc is called to change
the current file position à la lseek() (2). closeproc is invoked to
release any resources associated with an open file. sizeproc is invoked
to obtain the size in bytes of a file. mapproc and unmapproc are called
to map and unmap a file's contents in memory; c.f. mmap() (2) and
munmap() (2). The clientdata parameter is an opaque "handle" passed to
the client-specified routines passed as parameters to TIFFClientOpen().
>From
>https://sources.debian.org/src/libimager-perl/1.020%2Bdfsg-1/TIFF/imtiff.c/#L302
static toff_t sizeproc(thandle_t x) {
return 0;
}
which is used as the TIFFClientOpen() argument in i_readtiff_wiol():
https://sources.debian.org/src/libimager-perl/1.020%2Bdfsg-1/TIFF/imtiff.c/#L710
So it looks like libimager-perl is always saying the file size is 0,
and this hasn't hurt earlier but now does with the src:tiff CVE-2023-6277
patch.
Not sure where this leaves us, but I've just reported it at
https://github.com/tonycoz/imager/issues/522
--
Niko
Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure
(re-adding Cc: tiff@pdo) On Sat, Dec 02, 2023 at 01:40:51PM +0100, gregor herrmann wrote: > On Sat, 02 Dec 2023 14:24:01 +0200, Niko Tyni wrote: > > > It regressed with tiff_4.5.1+git230720-2 which is currently blocked from > > migrating to trixie because libimager-perl autopkgtests are failing too. > > > > Changes: > > tiff (4.5.1+git230720-2) unstable; urgency=high > > . > >* Backport security fix for CVE-2023-6277, passing a crafted tiff file to > > TIFFOpen() API may allow a remote attacker to cause a denial of service > > (closes: #1056751). > > > > I see libimager-perl upstream has released 1.021 with some tiff related > > changes. I haven't checked if those fix the issue, or whether libtiff > > is actually broken. Feel free to reassign as needed. > > I've imported 1.021 into our git repo yesterday, and there it fails > the same way (I hadn't nticed that 1.020 in sid also fails …) > > So -- is this a bug in Imager or in tiff? Can't quite say, but sharing what I found: The test creates TIFF/testout/t106.tiff with Imager::File::TIFF::i_writetiff_wiol() and then tries to read it back with open(FH,"testout/t106.tiff") or die "cannot open testout/t106.tiff\n"; binmode(FH); $IO = Imager::io_new_fd(fileno(FH)); my $cmpimg = Imager::File::TIFF::i_readtiff_wiol($IO); Adding an Imager->_error_as_msg() call after that gives Error opening file: Failed to read directory at offset 37014 at TIFF/t/t10tiff.t line 49. Also there's t106tiff.log with plenty of diagnostics including [2023/12/02 16:29:42] imtiff.c:237 1: tiff warning Requested memory size for TIFF directory of 168 is greather than filesize 0. Memory not allocated, TIFF directory not read which matches the CVE-2023-6277 changes in libtiff, see https://sources.debian.org/src/tiff/4.5.1%2Bgit230720-2/debian/patches/CVE-2023-6277.patch/ It can be reproduced like this with the libimager-perl binaries currently in sid and every tiff file I tried with, for example test/images/palette-1c-8b.tiff in src:tiff. https://sources.debian.org/src/tiff/4.5.1%2Bgit230720-2/test/images/palette-1c-8b.tiff/ $ perl -MImager::File::TIFF -E '$i = Imager::io_new_fd(*STDIN); Imager::init_log(); Imager::File::TIFF::i_readtiff_wiol($i) or die Imager->_error_as_msg' < tiff/test/images/palette-1c-8b.tiff [2023/12/02 17:16:03] log.c:56 0: Imager - log started (level = 1) [2023/12/02 17:16:03] Imager.xs:267 1: Imager 1.020 starting [2023/12/02 17:16:03] imtiff.c:700 1: i_readtiff_wiol(ig 0x55a6ece33890, allow_incomplete 0, page 0) [2023/12/02 17:16:03] io.c:242 1: mymalloc(size 8192) -> 0x55a6ed426e70 [2023/12/02 17:16:03] imtiff.c:237 1: tiff warning Requested memory size for TIFF directory of 180 is greather than filesize 0. Memory not allocated, TIFF directory not read [2023/12/02 17:16:03] io.c:266 1: myrealloc(block (nil), size 124) [2023/12/02 17:16:03] imtiff.c:201 1: tiff error fmt Failed to read directory at offset %lu [2023/12/02 17:16:03] io.c:242 1: mymalloc(size 41) -> 0x55a6ece1d480 [2023/12/02 17:16:03] imtiff.c:715 1: i_readtiff_wiol: Unable to open tif file [2023/12/02 17:16:03] io.c:242 1: mymalloc(size 19) -> 0x55a6ed36be90 [2023/12/02 17:16:03] io.c:253 1: myfree(p 0x55a6ed42e250) Error opening file: Failed to read directory at offset 23716 at -e line 1. [2023/12/02 17:16:03] iolayer.c:424 1: io_glue_DESTROY(ig 0x55a6ece33890) I note it says "filesize 0". The patch determines the file size with uint64_t filesize = TIFFGetFileSize(tif); and TIFFGetFileSize() is in src:tiff libtiff/tiffiop.h as follows: #define TIFFGetFileSize(tif) ((*(tif)->tif_sizeproc)((tif)->tif_clientdata)) which is where I called it a day :) So I suppose the way Imager reads the file here does not initialize the data structure in a way that the patched libtiff expects? -- Niko
Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure
Source: libimager-perl Version: 1.020+dfsg-1 Severity: serious Tags: ftbfs Control: block 1055955 with -1 X-Debbugs-Cc: t...@packages.debian.org This package fails to build from source on current sid. It regressed with tiff_4.5.1+git230720-2 which is currently blocked from migrating to trixie because libimager-perl autopkgtests are failing too. Changes: tiff (4.5.1+git230720-2) unstable; urgency=high . * Backport security fix for CVE-2023-6277, passing a crafted tiff file to TIFFOpen() API may allow a remote attacker to cause a denial of service (closes: #1056751). I see libimager-perl upstream has released 1.021 with some tiff related changes. I haven't checked if those fix the issue, or whether libtiff is actually broken. Feel free to reassign as needed. I'm marking this as a blocker for the Perl 5.38 transition as we need to be able to rebuild libimager-perl for that. >From the build log: # libtiff release 4.5.1 # Failed test 'read low-level' # at t/t10tiff.t line 49. Use of uninitialized value in subroutine entry at t/t10tiff.t line 53. Use of uninitialized value in subroutine entry at t/t10tiff.t line 53. im2 is not of type Imager::ImgRaw at t/t10tiff.t line 53. # Looks like your test exited with 25 just after 4. t/t10tiff.t .. 1..247 ok 1 - use Imager::File::TIFF; ok 2 - extract library version ok 3 - write low level not ok 4 - read low-level Dubious, test returned 25 (wstat 6400, 0x1900) Failed 244/247 subtests Test Summary Report --- t/t10tiff.t (Wstat: 6400 (exited 25) Tests: 4 Failed: 1) Failed test: 4 Non-zero exit status: 25 Parse errors: Bad plan. You planned 247 tests but ran 4. Files=1, Tests=4, 0 wallclock secs ( 0.01 usr 0.01 sys + 0.10 cusr 0.02 csys = 0.14 CPU) Result: FAIL A full build log is at http://perl.debian.net/rebuild-logs/sid/libimager-perl_1.020%2Bdfsg-1/libimager-perl_1.020%2Bdfsg-1_amd64-2023-12-02T11%3A49%3A48Z.build -- Niko Tyni nt...@debian.org
Bug#1056918: bullseye-pu: package perl/5.32.1-4+deb11u3
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: p...@packages.debian.org, Salvatore Bonaccorso
Control: affects -1 + src:perl
[ Reason ]
I'd like to fix #1056746 / CVE-2023-47038 in perl for bullseye. It's a
non-DSA security issue that was made public yesterday and fixed upstream
in 5.34.2.
[ Impact ]
CVE-2023-47038 has security impact for applications that use untrusted
regular expressions to match input.
[ Tests ]
The fix augments the test suite to check for this issue. I have also
checked manually that the crash is gone with the patch. I reviewed amd64
binary debdiffs too and did some installation tests.
[ Risks ]
The fix is minimal and was trivially backported from the upstream fix in
5.34.1. It only differs from the one in sid / 5.36.0-10 by some fuzz. I
don't expect any fallout, but obviously I'll report here if any problems
are found in the 5.36.0-10 testing migration checks.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
The only change is a patch to the regexp engine in regcomp.c
and the associated new tests. The patch description has
a long explanation of the issue.
[ Other info ]
I'm uploading right away as I don't expect any of this to be
controversial. Hope that's fine by you.
Thanks for your work on Debian.
diff -Nru perl-5.32.1/debian/changelog perl-5.32.1/debian/changelog
--- perl-5.32.1/debian/changelog2021-09-24 19:10:58.0 +0300
+++ perl-5.32.1/debian/changelog2023-11-25 23:03:14.0 +0200
@@ -1,3 +1,10 @@
+perl (5.32.1-4+deb11u3) bullseye; urgency=medium
+
+ * [SECURITY] CVE-2023-47038: Write past buffer end via illegal
+user-defined Unicode property. (Closes: #1056746)
+
+ -- Niko Tyni Sat, 25 Nov 2023 23:03:14 +0200
+
perl (5.32.1-4+deb11u2) bullseye; urgency=medium
* Apply upstream patch fixing a regexp memory leak. (Closes: #994834)
diff -Nru perl-5.32.1/debian/patches/fixes/CVE-2023-47038.diff
perl-5.32.1/debian/patches/fixes/CVE-2023-47038.diff
--- perl-5.32.1/debian/patches/fixes/CVE-2023-47038.diff1970-01-01
02:00:00.0 +0200
+++ perl-5.32.1/debian/patches/fixes/CVE-2023-47038.diff2023-11-25
23:03:14.0 +0200
@@ -0,0 +1,119 @@
+From: Karl Williamson
+Date: Sat, 9 Sep 2023 11:59:09 -0600
+Subject: Fix read/write past buffer end: perl-security#140
+
+A package name may be specified in a \p{...} regular expression
+construct. If unspecified, "utf8::" is assumed, which is the package
+all official Unicode properties are in. By specifying a different
+package, one can create a user-defined property with the same
+unqualified name as a Unicode one. Such a property is defined by a sub
+whose name begins with "Is" or "In", and if the sub wishes to refer to
+an official Unicode property, it must explicitly specify the "utf8::".
+S_parse_uniprop_string() is used to parse the interior of both \p{} and
+the user-defined sub lines.
+
+In S_parse_uniprop_string(), it parses the input "name" parameter,
+creating a modified copy, "lookup_name", malloc'ed with the same size as
+"name". The modifications are essentially to create a canonicalized
+version of the input, with such things as extraneous white-space
+stripped off. I found it convenient to strip off the package specifier
+"utf8::". To to so, the code simply pretends "lookup_name" begins just
+after the "utf8::", and adjusts various other values to compensate.
+However, it missed the adjustment of one required one.
+
+This is only a problem when the property name begins with "perl" and
+isn't "perlspace" nor "perlword". All such ones are undocumented
+internal properties.
+
+What happens in this case is that the input is reparsed with slightly
+different rules in effect as to what is legal versus illegal. The
+problem is that "lookup_name" no longer is pointing to its initial
+value, but "name" is. Thus the space allocated for filling "lookup_name"
+is now shorter than "name", and as this shortened "lookup_name" is
+filled by copying suitable portions of "name", the write can be to
+unallocated space.
+
+The solution is to skip the "utf8::" when reparsing "name". Then both
+"lookup_name" and "name" are effectively shortened by the same amount,
+and there is no going off the end.
+
+This commit also does white-space adjustment so that things align
+vertically for readability.
+
+This can be easily backported to earlier Perl releases.
+
+Bug-Debian: https://bugs.debian.org/1056746
+Origin: backport,
https://github.com/Perl/perl5/commit/12c313ce49b36160a
Bug#1056917: bookworm-pu: package perl/5.36.0-7+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: p...@packages.debian.org, Salvatore Bonaccorso
Control: affects -1 + src:perl
[ Reason ]
I'd like to fix #1056746 / CVE-2023-47038 in perl for bookworm. It's a
non-DSA security issue that was made public yesterday and fixed upstream
in 5.36.2.
[ Impact ]
CVE-2023-47038 has security impact for applications that use untrusted
regular expressions to match input.
[ Tests ]
The fix augments the test suite to check for this issue. I have also
checked manually that the crash is gone with the patch. I reviewed amd64
binary debdiffs too and did some installation tests.
[ Risks ]
The fix is minimal and identical to the one in sid / 5.36.0-10. I don't
expect any fallout, but obviously I'll report here if any problems are
found in the testing migration checks.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
The only change is a patch to the regexp engine in regcomp.c
and the associated new tests. The patch description has
a long explanation of the issue.
[ Other info ]
I'm uploading right away as I don't expect any of this to be
controversial. Hope that's fine by you.
Thanks for your work on Debian.
diff -Nru perl-5.36.0/debian/changelog perl-5.36.0/debian/changelog
--- perl-5.36.0/debian/changelog2023-01-08 23:28:47.0 +0200
+++ perl-5.36.0/debian/changelog2023-11-25 22:59:54.0 +0200
@@ -1,3 +1,10 @@
+perl (5.36.0-7+deb12u1) bookworm; urgency=medium
+
+ * [SECURITY] CVE-2023-47038: Write past buffer end via illegal
+user-defined Unicode property. (Closes: #1056746)
+
+ -- Niko Tyni Sat, 25 Nov 2023 22:59:54 +0200
+
perl (5.36.0-7) unstable; urgency=medium
* Break backuppc (<< 4.4.0-7~) due to Data::Dumper changes in 5.36
diff -Nru perl-5.36.0/debian/patches/fixes/CVE-2023-47038.diff
perl-5.36.0/debian/patches/fixes/CVE-2023-47038.diff
--- perl-5.36.0/debian/patches/fixes/CVE-2023-47038.diff1970-01-01
02:00:00.0 +0200
+++ perl-5.36.0/debian/patches/fixes/CVE-2023-47038.diff2023-11-25
22:59:54.0 +0200
@@ -0,0 +1,119 @@
+From: Karl Williamson
+Date: Sat, 9 Sep 2023 11:59:09 -0600
+Subject: Fix read/write past buffer end: perl-security#140
+
+A package name may be specified in a \p{...} regular expression
+construct. If unspecified, "utf8::" is assumed, which is the package
+all official Unicode properties are in. By specifying a different
+package, one can create a user-defined property with the same
+unqualified name as a Unicode one. Such a property is defined by a sub
+whose name begins with "Is" or "In", and if the sub wishes to refer to
+an official Unicode property, it must explicitly specify the "utf8::".
+S_parse_uniprop_string() is used to parse the interior of both \p{} and
+the user-defined sub lines.
+
+In S_parse_uniprop_string(), it parses the input "name" parameter,
+creating a modified copy, "lookup_name", malloc'ed with the same size as
+"name". The modifications are essentially to create a canonicalized
+version of the input, with such things as extraneous white-space
+stripped off. I found it convenient to strip off the package specifier
+"utf8::". To to so, the code simply pretends "lookup_name" begins just
+after the "utf8::", and adjusts various other values to compensate.
+However, it missed the adjustment of one required one.
+
+This is only a problem when the property name begins with "perl" and
+isn't "perlspace" nor "perlword". All such ones are undocumented
+internal properties.
+
+What happens in this case is that the input is reparsed with slightly
+different rules in effect as to what is legal versus illegal. The
+problem is that "lookup_name" no longer is pointing to its initial
+value, but "name" is. Thus the space allocated for filling "lookup_name"
+is now shorter than "name", and as this shortened "lookup_name" is
+filled by copying suitable portions of "name", the write can be to
+unallocated space.
+
+The solution is to skip the "utf8::" when reparsing "name". Then both
+"lookup_name" and "name" are effectively shortened by the same amount,
+and there is no going off the end.
+
+This commit also does white-space adjustment so that things align
+vertically for readability.
+
+This can be easily backported to earlier Perl releases.
+
+Bug-Debian: https://bugs.debian.org/1056746
+Origin: backport,
https://github.com/Perl/perl5/commit/7047915eef37fccd93e7cd985c29fe6be54650b6
+---
+ regcomp.c | 17 +++--
+ t/re/p
Bug#1056746: perl: CVE-2023-47038: Write past buffer end via illegal user-defined Unicode property
Package: perl
Version: 5.30.0-1
Severity: important
Tags: security patch fixed-upstream bullseye bookworm trixie
X-Debbugs-Cc: t...@security.debian.org
Perl upstream released 5.34.2, 5.36.2 and 5.38.1 today with coordinated
fixes for two security issues. One of these (CVE-2023-47039) is specific
to Windows, but the other one (CVE-2023-47038) concerns us.
We discussed this earlier with Salvatore from the security team and
decided that CVE-2023-47038 is non-DSA like other "crafted regular
expression crashes" we've handled in the past. It will hence be fixed
via point releases for stable and oldstable.
CVE-2023-47038 - Write past buffer end via illegal user-defined Unicode property
A test case is
perl -e 'qr/\p{utf8::_perl_surrogate}/'
which crashes on oldstable (bullseye, 5.32), stable (bookworm, 5.36),
unstable / testing (5.36) and experimental (5.38).
The issue was introduced in the 5.30 cycle, so LTS (buster, 5.28) is
not affected.
The upstream fixes are at
5.34
https://github.com/Perl/perl5/commit/12c313ce49b36160a7ca2e9b07ad5bd92ee4a010
5.36
https://github.com/Perl/perl5/commit/7047915eef37fccd93e7cd985c29fe6be54650b6
5.38
https://github.com/Perl/perl5/commit/92a9eb3d0d52ec7655c1beb2a5a5219be664
The 5.34 fix applies to 5.32 as well.
I'll start with sid/trixie and handle the *stable updates after that,
mainly targeting next bookworm point update on 2023-12-09 as per
https://lists.debian.org/debian-project/2023/11/msg3.html
For experimental/5.38, I intend to push 5.38.1 instead of cherry
picking the patch.
--
Niko Tyni nt...@debian.org
Bug#1056143: libeval-context-perl: t/012_safe.t fails
On Fri, Nov 17, 2023 at 06:28:30PM +0100, gregor herrmann wrote: > Source: libeval-context-perl > Version: 0.09.11-5 > Severity: serious > Tags: ftbfs trixie sid > Justification: fails to build from source > As noted by ci.debian.net, t/012_safe.t started to fail recently: This seems to have been broken by libdata-treedumper-perl_0.41-1. Downgrading to 0.40-5 makes it go away. -- Niko
Bug#1055955: transition: perl 5.38
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: p...@packages.debian.org Hi release team, this has taken me much longer than necessary for various reasons, but I think we're almost ready to push Perl 5.38 to sid now. We should aim to release trixie with 5.40 (which will be released in May 2024 or so), but it's still better to do these transitions one at a time. TL;DR: - can we raise the remaining bugs to severity:serious? - I'll request a transition slot once the easy ones are fixed - should we worry about time64? Perl 5.38 been in experimental since July, and we've been running continuous amd64 rebuilds on perl.debian.net all the time. I also checked for related autopkgtest regressions back in August/September in all packages declaring Testsuite: autopkgtest-pkg-perl or having Testsuite-Triggers: perl. The bugs we found are tracked with the usual usertags: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.38-transition;users=debian-p...@lists.debian.org There's a few packages that are nontrivially broken and will probably need to be removed from testing. libapache-db-perl #1040396 libembperl-perl #1042845 polymake #1042521 AFAICS polymake has one reverse dependency (gap-polymaking) and the others have none, so removal shouldn't be too difficult. Then there's some that already have patches or where the fixes are trivial, but just need an upload: docknot #1042853 elinks #1042844 libgtk3-imageview-perl #1050445 libperl-languageserver-perl #1050451 libregexp-debuggperl-perl #1050454 localehelper #1042525 I haven't checked reverse dependencies as I'm hoping they will be fixed. Can we raise these bugs to severity:serious? I can report back when these are fixed and request a transition slot. Finally I just ran one more rebuild test for all the packages that will need binNMUs, and found a couple of unrelated FTBFS bugs. These would block binNMUs. cod-tools #1055896 (fixed in sid today, needs to migrate) os-autoinst #1054776 libprelude #1054793 libauthen-sasl-cyrus-perl #1052871 (not in testing) I haven't checked for version skew between testing and unstable, or for any architecture specific issues on !amd64 as I don't have any good tools for those. I suppose we'll need to handle them during the transition if we hit any. One more thing to mention: I'm slightly worried about the time64 transition that I think was supposed to happen this release cycle. As I mentioned in July [1] I think it will need a perlapi-* bump and the related binNMUs of the same set of packages. [1] https://lists.debian.org/debian-devel/2023/07/msg00302.html But things seem to be quiet and I still haven't looked at the perl side of that at all. (I also have no idea how it can be done without a flag day but I hope somebody does.) I don't think we should block on this unless there's some activity that I've missed? Ben file proposal, just copy-pasting from last year: title = "perl"; is_affected = .depends ~ "libperl5.36|perlapi-5.36" | .pre-depends ~ "libperl5.36|perlapi-5.36"; is_good = .depends ~ "libperl5.38|perlapi-5.38" | .pre-depends ~ "libperl5.38|perlapi-5.38"; is_bad = .depends ~ "libperl5.36|perlapi-5.36" | .pre-depends ~ "libperl5.36|perlapi-5.36"; Thanks for your work on Debian, -- Niko
Bug#1042521: Will Trixie be on Perl 5.38?
On Mon, Oct 02, 2023 at 03:39:59PM +0200, Joachim Zobel wrote: > Will Trixie be with Perl 5.38? If so it is ponitless to put any effort > into the polymake package. If not there might be enough time for the > transition to Julia. I'm aiming to get Perl 5.38 into testing (trixie) in the next month or two. I expect trixie will eventually release with Perl 5.40, but we'll see how the timing works out. -- Niko Tyni nt...@debian.org
Bug#1051609: libapp-stacktrace-perl: FTBFS with Perl 5.38: test failures
Source: libapp-stacktrace-perl
Version: 0.09-4
Severity: important
Tags: ftbfs patch
User: debian-p...@lists.debian.org
Usertags: perl-5.38-transition
This package fails to build with Perl 5.38 (currently in experimental.)
http://perl.debian.net/rebuild-logs/perl-5.38/libapp-stacktrace-perl_0.09-4/libapp-stacktrace-perl_0.09-4+b2_amd64-2023-07-05T10:35:24Z.build
# Failed test at t/unthreaded.t line 55.
# '[Thread debugging using libthread_db enabled]
# Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
# 0x7fa9c059a0d4 in select () from /lib/x86_64-linux-gnu/libc.so.6
# /tmp/GvLM6dPQSV.gdb:1761: Error in sourced command file:
# No symbol "Perl_get_context" in current context.
# [Inferior 1 (process 2683997) detached]
# '
# doesn't match '(?^mx:
# (?:
# ^t/unthreaded\.t:\d+\n
# ){10}
# )'
# Failed test 'exit(0)'
# at t/unthreaded.t line 66.
# got: '1'
# expected: '0'
# Looks like you failed 2 tests of 5.
This seems to be because Perl_get_context is now hidden because it
is not part of the official API.
A fix/workaround is to use PL_current_context instead. Patch attached.
I'm just copycatting here really but this passes the tests on both 5.36
and 5.38. We're only using threaded Perl in Debian so I haven't tested
with an unthreaded one.
--
Niko Tyni nt...@debian.org
>From c0e12b98fe37ada2361853c595b53aa05cbab94a Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Thu, 27 Jul 2023 07:31:29 +0100
Subject: [PATCH] Perl 5.38 compatibility
Perl_get_context() is no longer a public symbol, so we
need to use PL_current_context instead.
---
lib/App/Stacktrace.pm | 1 +
lib/App/Stacktrace/perl_backtrace_raw.txt | 8
lib/App/Stacktrace/perl_backtrace_symbols.txt | 14 ++
3 files changed, 23 insertions(+)
diff --git a/lib/App/Stacktrace.pm b/lib/App/Stacktrace.pm
index 6958a7c..aa3c3d1 100644
--- a/lib/App/Stacktrace.pm
+++ b/lib/App/Stacktrace.pm
@@ -218,6 +218,7 @@ INVOKE
sub _command_for_version {
return
+$] >= 5.038 ? 'perl_backtrace_5_38_x' :
$] >= 5.014 ? 'perl_backtrace_5_14_x' :
$] >= 5.012 ? 'perl_backtrace_5_12_x' :
$] >= 5.010 ? 'perl_backtrace_5_10_x' :
diff --git a/lib/App/Stacktrace/perl_backtrace_raw.txt b/lib/App/Stacktrace/perl_backtrace_raw.txt
index 41cf4e6..b0fe842 100644
--- a/lib/App/Stacktrace/perl_backtrace_raw.txt
+++ b/lib/App/Stacktrace/perl_backtrace_raw.txt
@@ -1572,6 +1572,14 @@ end
define perl_backtrace_5_14_x
perl_backtrace_5_12_x
end
+define perl_backtrace_5_38_x
+set $interpreter = (long) PL_current_context
+if $interpreter
+perl_backtrace_5_12_threads
+else
+perl_backtrace_nothreads
+end
+end
define perl_backtrace_5_14_x_x86_64
# 5.14.0-linux-x86_64-linux: 3
# 5.13.11-linux-x86_64-linux: 3
diff --git a/lib/App/Stacktrace/perl_backtrace_symbols.txt b/lib/App/Stacktrace/perl_backtrace_symbols.txt
index a64261d..efe2a63 100644
--- a/lib/App/Stacktrace/perl_backtrace_symbols.txt
+++ b/lib/App/Stacktrace/perl_backtrace_symbols.txt
@@ -429,3 +429,17 @@ define perl_backtrace_5_14_x
perl_backtrace_nothreads
end
end
+
+define perl_backtrace_5_38_x
+set $CXt_SUB = 8
+set $CXt_FORMAT = 9
+set $CXt_EVAL = 10
+set $interpreter = (PerlInterpreter*)PL_current_context
+if $interpreter
+set $POOL_KEY = "threads::_pool1.83"
+set $POOL_KEY_LEN = 18
+perl_backtrace_5_12_threads
+else
+perl_backtrace_nothreads
+end
+end
--
2.39.1
Bug#1051427: perl: libperl symbols for strlcat and strlcpy lost with glibc 2.38
Source: perl Version: 5.36.0-7 Severity: important Tags: ftbfs patch As noticed by Ubuntu and reported by doko on IRC, this package fails to build from source with glibc 2.38 (currently in experimental.) dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libperl5.36/DEBIAN/symbols doesn't match completely debian/libperl5.36.symbols --- debian/libperl5.36.symbols (libperl5.36_5.36.0-8_amd64) +++ dpkg-gensymbolszhalIX 2023-09-07 18:42:16.688071199 + @@ -925,8 +925,8 @@ Perl_my_stat_flags@Base 5.36.0 Perl_my_strerror@Base 5.36.0 Perl_my_strftime@Base 5.36.0 - Perl_my_strlcat@Base 5.36.0 - Perl_my_strlcpy@Base 5.36.0 +#MISSING: 5.36.0-8# Perl_my_strlcat@Base 5.36.0 +#MISSING: 5.36.0-8# Perl_my_strlcpy@Base 5.36.0 Perl_my_strtod@Base 5.36.0 Perl_my_unexec@Base 5.36.0 Perl_my_vsnprintf@Base 5.36.0 This is because glibc added strlcpy and strlcat in https://sourceware.org/git/?p=glibc.git;a=commit;h=454a20c8756c9c1d55419153255fc7692b3d2199 so the Configure script now detects them and disables the replacement implementations inside src:perl, losing the corresponding libperl symbols in the process. I suspect nothing external actually uses the lost symbols, but it's best to be on the safe side. The attached patch tells Configure to ignore the new glibc functions, so that libperl keeps binary compatibility. We will need this for whichever version of perl is in sid when glibc 2.38 enters it. I'll upload it soon for 5.36, and see what to do with 5.38 when the transition is ready to start. -- Niko Tyni nt...@debian.org >From edd4457e4f61460f32a04c566e1da68dcf238d98 Mon Sep 17 00:00:00 2001 From: Niko Tyni Date: Thu, 7 Sep 2023 19:16:29 +0100 Subject: [PATCH] Explicitly do not use strlcpy and strlcat from glibc 2.38 This keeps libperl symbols stable --- debian/config.debian | 2 ++ 1 file changed, 2 insertions(+) diff --git a/debian/config.debian b/debian/config.debian index 7afc379e7..300416ae2 100644 --- a/debian/config.debian +++ b/debian/config.debian @@ -119,6 +119,8 @@ then -Ui_libutil \ -Ui_xlocale \ -Uversiononly \ +-Ud_strlcpy \ +-Ud_strlcat \ -DDEBUGGING=$debugging \ -Doptimize=\"$optimize\" \ $extra_path \ -- 2.39.1
Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl
Control: reassign -1 libc6-dev 2.37-2 Control: found -1 2.36-9+deb12u1 Control: tag -1 bookworm On Mon, Aug 28, 2023 at 11:46:14PM +0200, Aurelien Jarno wrote: > > I think it's an ABI breakage that should be fixed, but just reverting > > the patch will break the case without -D_FILE_OFFSET_BITS=64. I'll check > > with upstream and try to get the issue fixed in both testing/sid and > > stable. I'll keep you updated. In the meantime feel free to reassign the > > bug to the glibc. > > I have opened a bug upstream: > https://sourceware.org/bugzilla/show_bug.cgi?id=30804 > > And submitted a possible patch: > https://sourceware.org/pipermail/libc-alpha/2023-August/151199.html Many thanks! I'm reassigning this. Hope I got the versions right. Looks like the discussion upstream has quieted down now. My understanding is that for sid/trixie we'll just need a binNMU of perl on ppc64el afterwards. I'll request that once glibc has the fix. For stable I don't think anything needs to be done on the perl side. Both perl and libfile-fcntllock-perl were build with the old constants before the regression. So just fixing glibc should be enough. -- Niko
Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl
(full quote for the benefit of the Aurelien and other glibc maintainers) On Sat, Aug 26, 2023 at 09:07:38PM +0300, Niko Tyni wrote: > Package: perl > Version: 5.36.0-8 > Severity: serious > X-Debbugs-Cc: debian-powe...@lists.debian.org > Control: affects -1 libfile-fcntllock-perl > > Hi, > > debugging an unexpected autopkgtest failure of > libfile-fcntllock-perl_0.22-4+b1 with perl_5.36.0-8 on ppc64el [1] I found > it's because the old perl binary (5.36.0-7) was built with the fcntl(2) > constant F_GETLK == 12, but the new one with F_GETLK == 5 [2]. > > There are no source or build system changes in perl that would have caused > this change. The failure is currently blocking perl testing migration, > so filing at 'serious'. > > Perl is built with -D_FILE_OFFSET_BITS=64, and I see that on bullseye > this causes F_GETLK == F_GETLK64 == 12, but on bookworm and later > F_GETLK == 5 while F_GETLK64 == 12 [3]. I didn't find the exact > change that caused this yet. > > As can be expected from the above, building libfile-fcntllock-perl on > bookworm against perl_5.36.0-7 makes it fail its test suite in a similar > way. And rebuilding it on sid against perl_5.36.0-8 makes it pass. > > On amd64 the constants have stayed equal (== 5) from bullseye to sid, > and _FILE_OFFSET_BITS=64 doesn't affect them. What's the deal on ppc64el? > > Copying the powerpc porters list. Could you please look into this? > > [1] > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/libf/libfile-fcntllock-perl/34669085/log.gz > [2] perl -MPOSIX -E 'say F_GETLK' > [3] printf '#include \nF_GETLK\nF_GETLK64\n' | cpp > -D_FILE_OFFSET_BITS=64 | tail -2 I think the relevant change here is this in libc6-dev_2.36-9+deb12u1 for bookworm: --- libc6-dev_2.36-9/usr/include/powerpc64le-linux-gnu/bits/fcntl.h 2023-04-10 09:35:16.0 +0100 +++ libc6-dev_2.36-9+deb12u1/usr/include/powerpc64le-linux-gnu/bits/fcntl.h 2023-07-13 19:07:47.0 +0100 @@ -33,6 +33,12 @@ # define __O_LARGEFILE 020 #endif +#if __WORDSIZE == 64 +# define F_GETLK 5 +# define F_SETLK 6 +# define F_SETLKW 7 +#endif + and a similar one in 2.37-2 for trixie/sid. The applicable changelog entry is presumably [ Aurelien Jarno ] * debian/patches/git-updates.diff: update from upstream stable branch: [...] - Not affecting bookworm release architectures: - Fix LFS POSIX lock constants for powerpc64. Aurelien, it seems that there's an oversight as ppc64el is a release architecture? I can see that this changed for the better, but what should I do with the above breakage? Rebuild perl and libfcntl-fcntllock-perl and declare some Breaks? Do we want to do that for stable too? -- Niko Tyni nt...@debian.org
Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl
Package: perl Version: 5.36.0-8 Severity: serious X-Debbugs-Cc: debian-powe...@lists.debian.org Control: affects -1 libfile-fcntllock-perl Hi, debugging an unexpected autopkgtest failure of libfile-fcntllock-perl_0.22-4+b1 with perl_5.36.0-8 on ppc64el [1] I found it's because the old perl binary (5.36.0-7) was built with the fcntl(2) constant F_GETLK == 12, but the new one with F_GETLK == 5 [2]. There are no source or build system changes in perl that would have caused this change. The failure is currently blocking perl testing migration, so filing at 'serious'. Perl is built with -D_FILE_OFFSET_BITS=64, and I see that on bullseye this causes F_GETLK == F_GETLK64 == 12, but on bookworm and later F_GETLK == 5 while F_GETLK64 == 12 [3]. I didn't find the exact change that caused this yet. As can be expected from the above, building libfile-fcntllock-perl on bookworm against perl_5.36.0-7 makes it fail its test suite in a similar way. And rebuilding it on sid against perl_5.36.0-8 makes it pass. On amd64 the constants have stayed equal (== 5) from bullseye to sid, and _FILE_OFFSET_BITS=64 doesn't affect them. What's the deal on ppc64el? Copying the powerpc porters list. Could you please look into this? [1] https://ci.debian.net/data/autopkgtest/unstable/ppc64el/libf/libfile-fcntllock-perl/34669085/log.gz [2] perl -MPOSIX -E 'say F_GETLK' [3] printf '#include \nF_GETLK\nF_GETLK64\n' | cpp -D_FILE_OFFSET_BITS=64 | tail -2 -- Niko Tyni nt...@debian.org
Bug#1043344: perl: Use of freed value in iteration with base.pm dotless-INC guard when looping over @INC
found 1043344 5.26.0-3 severity 1043344 normal affects 1043344 = user debian-p...@lists.debian.org usertags 1043344 = thanks On Wed, Aug 09, 2023 at 01:53:53PM +0300, Niko Tyni wrote: > Package: perl > Version: 5.38.0-1 > Severity: important > Tags: upstream > User: debian-p...@lists.debian.org > Usertags: perl-5.38-transition > Control: affects -1 libhtml-widget-perl > ># Tried to use 'HTML::Widget'. ># Error: Use of freed value in iteration at > /usr/share/perl5/Module/Pluggable/Fast.pm line 74. This has been worked around in libhtml-widget-perl and is a long standing issue, so not relevant to the 5.38 transition. Updating metadata accordingly. Still haven't got around to filing an upstream report... -- Niko
Bug#1050458: apache2: given is deprecated at /usr/sbin/a2enmod
Package: apache2 Version: 2.4.57-2 Severity: important Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition autopkgtest Control: affects -1 munin Installing this package spews warnings with Perl 5.38 (currently in experimental) because a2enmod uses the deprecated 'given' and 'when' Perl keywords. Setting up apache2 (2.4.57-2) ... given is deprecated at /usr/sbin/a2enmod line 577. when is deprecated at /usr/sbin/a2enmod line 578. when is deprecated at /usr/sbin/a2enmod line 586. Enabling module mpm_event. given is deprecated at /usr/sbin/a2enmod line 577. when is deprecated at /usr/sbin/a2enmod line 578. when is deprecated at /usr/sbin/a2enmod line 586. [...] This breaks at least the munin autopkgtest checks as seen at https://ci.debian.net/data/autopkgtest/unstable/amd64/m/munin/37098324/log.gz 429s master-cgi-systemd FAIL stderr: given is deprecated at /usr/sbin/a2enmod line 577. so filing at 'important' (but feel free to adjust.) -- Niko Tyni nt...@debian.org
Bug#1050456: prolix: autopkgtest failure with Perl 5.38: when is deprecated
Source: prolix Version: 0.03-2 Severity: important Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition autopkgtest This package fails its autopkgtest checks with Perl 5.38 (currently in experimental.) https://ci.debian.net/data/autopkgtest/unstable/amd64/p/prolix/37098325/log.gz 56s # Failed test ' /usr/bin/perl -w -M"App::Prolix" -e 1 2>&1 produced no (non-whitelisted) output' 56s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 56s # Structures begin differing at: 56s # $got->[0] = 'when is deprecated at /usr/share/perl5/App/Prolix.pm line 207. 56s # ' 56s # $expected->[0] = Does not exist 57s 57s # Failed test 'env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"App::Prolix" -e 1 2>&1 produced no (non-whitelisted) output' 57s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 57s # Structures begin differing at: 57s # $got->[0] = 'when is deprecated at /usr/share/perl5/App/Prolix.pm line 207. 57s # ' 57s # $expected->[0] = Does not exist 57s # Looks like you failed 2 tests of 4. -- Niko Tyni nt...@debian.org
Bug#1050455: libtravel-routing-de-vrr-perl: autopkgtest failure with Perl 5.38: given is deprecated
Source: libtravel-routing-de-vrr-perl Version: 2.21-1 Severity: important Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition autopkgtest This package fails its autopkgtest checks with Perl 5.38 (currently in experimental.) https://ci.debian.net/data/autopkgtest/unstable/amd64/libt/libtravel-routing-de-vrr-perl/37098320/log.gz 82s # Failed test ' /usr/bin/perl -w -M"Travel::Routing::DE::VRR" -e 1 2>&1 produced no (non-whitelisted) output' 82s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 82s # Structures begin differing at: 82s # $got->[0] = 'given is deprecated at /usr/share/perl5/Travel/Routing/DE/EFA.pm line 179. 82s # ' 82s # $expected->[0] = Does not exist 82s 82s # Failed test 'env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Travel::Routing::DE::VRR" -e 1 2>&1 produced no (non-whitelisted) output' 82s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 82s # Structures begin differing at: 82s # $got->[0] = 'given is deprecated at /usr/share/perl5/Travel/Routing/DE/EFA.pm line 179. 82s # ' 82s # $expected->[0] = Does not exist 82s # Looks like you failed 2 tests of 4. -- Niko Tyni nt...@debian.org
Bug#1050454: libregexp-debugger-perl: autopkgtest failure with Perl 5.38: Smartmatch is deprecated
Package: libregexp-debugger-perl Version: 0.002006-2 Severity: important Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition autopkgtest This package fails its autopkgtest checks with Perl 5.38 (currently in experimental.) https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libregexp-debugger-perl/37098316/log.gz 73s # Failed test ' /usr/bin/perl -w -M"Regexp::Debugger" -e 1 2>&1 produced no (non-whitelisted) output' 73s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 73s # Structures begin differing at: 73s # $got->[0] = 'Smartmatch is deprecated at /usr/share/perl5/Regexp/Debugger.pm line 231. 73s # ' 73s # $expected->[0] = Does not exist 73s 73s # Failed test 'env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Regexp::Debugger" -e 1 2>&1 produced no (non-whitelisted) output' 73s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 73s # Structures begin differing at: 73s # $got->[0] = 'Smartmatch is deprecated at /usr/share/perl5/Regexp/Debugger.pm line 231. 73s # ' 73s # $expected->[0] = Does not exist 73s # Looks like you failed 2 tests of 4. -- Niko Tyni nt...@debian.org
Bug#1050452: libpoe-component-jabber-perl: autopkgtest failure with Perl 5.38: given is deprecated
Source: libpoe-component-jabber-perl Version: 3.00-5 Severity: important Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition autopkgtest This package fails its autopkgtest checks with Perl 5.38 (currently in experimental.) https://ci.debian.net/data/autopkgtest/unstable/amd64/libp/libpoe-component-jabber-perl/37098315/log.gz 63s # Failed test ' /usr/bin/perl -w -M"POE::Component::Jabber" -e 1 2>&1 produced no (non-whitelisted) output' 63s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 63s # Structures begin differing at: 63s # $got->[0] = 'given is deprecated at /usr/share/perl5/POE/Component/Jabber/XMPP.pm line 141. 63s # ' 63s # $expected->[0] = Does not exist 63s 63s # Failed test 'env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"POE::Component::Jabber" -e 1 2>&1 produced no (non-whitelisted) output' 63s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 63s # Structures begin differing at: 63s # $got->[0] = 'given is deprecated at /usr/share/perl5/POE/Component/Jabber/XMPP.pm line 141. 63s # ' 63s # $expected->[0] = Does not exist 63s # Looks like you failed 2 tests of 4. -- Niko Tyni nt...@debian.org
Bug#1050451: libperl-languageserver-perl: autopkgtest failure with Perl 5.38: given is deprecated
Source: libperl-languageserver-perl Version: 2.5.0-1 Severity: important Tags: trixie sid upstream User: debian-p...@lists.debian.org Usertags: perl-5.38-transition autopkgtest Forwarded: https://github.com/richterger/Perl-LanguageServer/issues/190 This package fails its autopkgtest checks with Perl 5.38 (currently in experimental.) https://ci.debian.net/data/autopkgtest/unstable/amd64/libp/libperl-languageserver-perl/37098313/log.gz 61s # Failed test ' /usr/bin/perl -w -M"Perl::LanguageServer" -e 1 2>&1 produced no (non-whitelisted) output' 61s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 61s # Structures begin differing at: 61s # $got->[0] = 'given is deprecated at /usr/share/perl5/Perl/LanguageServer/Parser.pm line 136. 61s # ' 61s # $expected->[0] = Does not exist 61s 61s # Failed test 'env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Perl::LanguageServer" -e 1 2>&1 produced no (non-whitelisted) output' 61s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 61s # Structures begin differing at: 61s # $got->[0] = 'given is deprecated at /usr/share/perl5/Perl/LanguageServer/Parser.pm line 136. 61s # ' 61s # $expected->[0] = Does not exist 61s # Looks like you failed 2 tests of 4. -- Niko Tyni nt...@debian.org
Bug#1050450: libje-perl: autopkgtest failure with Perl 5.38: Old package separator "'" deprecated
Source: libje-perl Version: 0.066-3 Severity: important Tags: trixie sid upstream patch User: debian-p...@lists.debian.org Usertags: perl-5.38-transition autopkgtest Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=146685 This package fails its autopkgtest checks with Perl 5.38 (currently in experimental.) https://ci.debian.net/data/autopkgtest/unstable/amd64/libj/libje-perl/37098308/log.gz 73s # Failed test ' /usr/bin/perl -w -M"JE" -e 1 2>&1 produced no (non-whitelisted) output' 73s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 73s # Structures begin differing at: 73s # $got->[0] = 'Old package separator "'" deprecated at /usr/share/perl5/JE/Code.pm line 181. 73s # ' 73s # $expected->[0] = Does not exist 73s 73s # Failed test 'env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"JE" -e 1 2>&1 produced no (non-whitelisted) output' 73s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 73s # Structures begin differing at: 73s # $got->[0] = 'Old package separator "'" deprecated at /usr/share/perl5/JE/Code.pm line 181. 73s # ' 73s # $expected->[0] = Does not exist 73s # Looks like you failed 2 tests of 4. There's a patch by Yves Orton in the upstream ticket. -- Niko Tyni nt...@debian.org
Bug#1050449: libweb-api-perl: autopkgtest failure with Perl 5.38: given is deprecated
Source: libweb-api-perl Version: 2.7-2 Severity: important Tags: trixie sid fixed-upstream User: debian-p...@lists.debian.org Usertags: perl-5.38-transition autopkgtest Forwarded: https://github.com/nupfel/Web-API/issues/31 This package fails its autopkgtest checks with Perl 5.38 (currently in experimental.) https://ci.debian.net/data/autopkgtest/unstable/amd64/libw/libweb-api-perl/37098321/log.gz 69s # Failed test ' /usr/bin/perl -w -M"Web::API" -e 1 2>&1 produced no (non-whitelisted) output' 69s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 69s # Structures begin differing at: 69s # $got->[0] = 'given is deprecated at /usr/share/perl5/Web/API.pm line 376. 69s # ' 69s # $expected->[0] = Does not exist 69s 69s # Failed test 'env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Web::API" -e 1 2>&1 produced no (non-whitelisted) output' 69s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 69s # Structures begin differing at: 69s # $got->[0] = 'given is deprecated at /usr/share/perl5/Web/API.pm line 376. 69s # ' 69s # $expected->[0] = Does not exist 69s # Looks like you failed 2 tests of 4. This seems to be fixed upstream with https://github.com/nupfel/Web-API/pull/32 -- Niko Tyni nt...@debian.org
Bug#1050447: libsub-delete-perl: autopkgtest failure with Perl 5.38: Old package separator "'" deprecated
Source: libsub-delete-perl Version: 1.2-3 Severity: important Tags: trixie sid upstream patch User: debian-p...@lists.debian.org Usertags: perl-5.38-transition autopkgtest Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=146682 This package fails its autopkgtest checks with Perl 5.38 (currently in experimental.) https://ci.debian.net/data/autopkgtest/unstable/amd64/libs/libsub-delete-perl/37098317/log.gz 54s # Failed test ' /usr/bin/perl -w -M"Sub::Delete" -e 1 2>&1 produced no (non-whitelisted) output' 54s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 54s # Structures begin differing at: 54s # $got->[0] = 'Old package separator "'" deprecated at /usr/share/perl5/Sub/Delete.pm line 47. 54s # ' 54s # $expected->[0] = Does not exist 54s 54s # Failed test 'env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Sub::Delete" -e 1 2>&1 produced no (non-whitelisted) output' 54s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 54s # Structures begin differing at: 54s # $got->[0] = 'Old package separator "'" deprecated at /usr/share/perl5/Sub/Delete.pm line 47. 54s # ' 54s # $expected->[0] = Does not exist 54s # Looks like you failed 2 tests of 4. There's a patch by Yves Orton in the upstream ticket. -- Niko Tyni nt...@debian.org
Bug#1050445: libgtk3-imageview-perl: autopkgtest failure with Perl 5.38: given is deprecated
Source: libgtk3-imageview-perl Version: 10-1 Severity: important Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition autopkgtest This package fails its autopkgtest checks with Perl 5.38 (currently in experimental.) https://ci.debian.net/data/autopkgtest/unstable/amd64/libg/libgtk3-imageview-perl/37098305/log.gz 110s # Failed test ' /usr/bin/perl -w -M"Gtk3::ImageView" -e 1 2>&1 produced no (non-whitelisted) output' 110s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 110s # Structures begin differing at: 110s # $got->[0] = 'given is deprecated at /usr/share/perl5/Gtk3/ImageView.pm line 179. 110s # ' 110s # $expected->[0] = Does not exist 110s 110s # Failed test 'env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Gtk3::ImageView" -e 1 2>&1 produced no (non-whitelisted) output' 110s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 110s # Structures begin differing at: 110s # $got->[0] = 'given is deprecated at /usr/share/perl5/Gtk3/ImageView.pm line 179. 110s # ' 110s # $expected->[0] = Does not exist 110s # Looks like you failed 2 tests of 4. -- Niko Tyni nt...@debian.org
Bug#1050444: libio-prompter-perl: autopkgtest failure with Perl 5.38: Smartmatch is deprecated
Package: libio-prompter-perl Version: 0.004015-2 Severity: important Tags: trixie sid fixed-upstream User: debian-p...@lists.debian.org Usertags: perl-5.38-transition autopkgtest This package fails its autopkgtest checks with Perl 5.38 (currently in experimental.) https://ci.debian.net/data/autopkgtest/unstable/amd64/libi/libio-prompter-perl/37098307/log.gz 75s # Failed test ' /usr/bin/perl -w -M"IO::Prompter" -e 1 2>&1 produced no (non-whitelisted) output' 75s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 75s # Structures begin differing at: 75s # $got->[0] = 'Smartmatch is deprecated at /usr/share/perl5/IO/Prompter.pm line 245. 75s # ' 75s # $expected->[0] = Does not exist 75s 75s # Failed test 'env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"IO::Prompter" -e 1 2>&1 produced no (non-whitelisted) output' 75s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 75s # Structures begin differing at: 75s # $got->[0] = 'Smartmatch is deprecated at /usr/share/perl5/IO/Prompter.pm line 245. 75s # ' 75s # $expected->[0] = Does not exist 75s # Looks like you failed 2 tests of 4. This seems to be fixed upstream in 0.005000. -- Niko Tyni nt...@debian.org
Bug#1050307: libdata-format-html-perl: autopkgtest failure with Perl 5.38: given is deprecated
Source: libdata-format-html-perl Version: 0.5.1-2 Severity: important Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition autopkgtest This package fails its autopkgtest checks with Perl 5.38 (currently in experimental.) https://ci.debian.net/data/autopkgtest/unstable/amd64/libd/libdata-format-html-perl/37062112/log.gz 56s autopkgtest [20:13:39]: test autodep8-perl: /usr/share/pkg-perl-autopkgtest/runner runtime-deps 56s autopkgtest [20:13:39]: test autodep8-perl: [--- 56s 56s # Failed test ' /usr/bin/perl -w -M"Data::Format::HTML" -e 1 2>&1 produced no (non-whitelisted) output' 56s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 56s # Structures begin differing at: 56s # $got->[0] = 'given is deprecated at /usr/share/perl5/Data/Format/HTML.pm line 193. 56s # ' 56s # $expected->[0] = Does not exist 56s 56s # Failed test 'env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Data::Format::HTML" -e 1 2>&1 produced no (non-whitelisted) output' 56s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 56s # Structures begin differing at: 56s # $got->[0] = 'given is deprecated at /usr/share/perl5/Data/Format/HTML.pm line 193. 56s # ' 56s # $expected->[0] = Does not exist 56s # Looks like you failed 2 tests of 4. 56s /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t .. 56s 1..4 56s # given is deprecated at /usr/share/perl5/Data/Format/HTML.pm line 193. 56s # when is deprecated at /usr/share/perl5/Data/Format/HTML.pm line 194. 56s # when is deprecated at /usr/share/perl5/Data/Format/HTML.pm line 195. 56s # when is deprecated at /usr/share/perl5/Data/Format/HTML.pm line 196. 56s # when is deprecated at /usr/share/perl5/Data/Format/HTML.pm line 197. 56s # when is deprecated at /usr/share/perl5/Data/Format/HTML.pm line 199. 56s ok 1 - /usr/bin/perl -w -M"Data::Format::HTML" -e 1 2>&1 exited successfully 56s not ok 2 - /usr/bin/perl -w -M"Data::Format::HTML" -e 1 2>&1 produced no (non-whitelisted) output 56s # given is deprecated at /usr/share/perl5/Data/Format/HTML.pm line 193. 56s # when is deprecated at /usr/share/perl5/Data/Format/HTML.pm line 194. 56s # when is deprecated at /usr/share/perl5/Data/Format/HTML.pm line 195. 56s # when is deprecated at /usr/share/perl5/Data/Format/HTML.pm line 196. 56s # when is deprecated at /usr/share/perl5/Data/Format/HTML.pm line 197. 56s # when is deprecated at /usr/share/perl5/Data/Format/HTML.pm line 199. 56s ok 3 - env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Data::Format::HTML" -e 1 2>&1 exited successfully 56s not ok 4 - env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Data::Format::HTML" -e 1 2>&1 produced no (non-whitelisted) output 56s Dubious, test returned 2 (wstat 512, 0x200) 56s Failed 2/4 subtests -- Niko Tyni nt...@debian.org
Bug#1050306: libautobox-junctions-perl: autopkgtest failure with Perl 5.38: Smartmatch is deprecated
Source: libautobox-junctions-perl Version: 0.002-2 Severity: important Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition autopkgtest This package fails its autopkgtest checks with Perl 5.38 (currently in experimental.) https://ci.debian.net/data/autopkgtest/unstable/amd64/liba/libautobox-junctions-perl/37060385/log.gz 79s autopkgtest [18:52:20]: test autodep8-perl: /usr/share/pkg-perl-autopkgtest/runner runtime-deps 79s autopkgtest [18:52:20]: test autodep8-perl: [--- 80s 80s # Failed test ' /usr/bin/perl -w -M"autobox::Junctions" -e 1 2>&1 produced no (non-whitelisted) output' 80s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 80s # Structures begin differing at: 80s # $got->[0] = 'Smartmatch is deprecated at (eval 5) line 8. 80s # ' 80s # $expected->[0] = Does not exist 80s 80s # Failed test 'env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"autobox::Junctions" -e 1 2>&1 produced no (non-whitelisted) output' 80s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 80s # Structures begin differing at: 80s # $got->[0] = 'Smartmatch is deprecated at (eval 5) line 8. 80s # ' 80s # $expected->[0] = Does not exist 80s # Looks like you failed 2 tests of 4. 80s /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t .. 80s 1..4 80s # Smartmatch is deprecated at (eval 5) line 8. 80s # Smartmatch is deprecated at (eval 5) line 15. 80s # Smartmatch is deprecated at (eval 6) line 8. 80s # Smartmatch is deprecated at (eval 6) line 15. 80s # Smartmatch is deprecated at (eval 7) line 8. 80s # Smartmatch is deprecated at (eval 7) line 15. 80s # Smartmatch is deprecated at (eval 8) line 11. 80s # Smartmatch is deprecated at (eval 8) line 21. 80s ok 1 - /usr/bin/perl -w -M"autobox::Junctions" -e 1 2>&1 exited successfully 80s not ok 2 - /usr/bin/perl -w -M"autobox::Junctions" -e 1 2>&1 produced no (non-whitelisted) output 80s # Smartmatch is deprecated at (eval 5) line 8. 80s # Smartmatch is deprecated at (eval 5) line 15. 80s # Smartmatch is deprecated at (eval 6) line 8. 80s # Smartmatch is deprecated at (eval 6) line 15. 80s # Smartmatch is deprecated at (eval 7) line 8. 80s # Smartmatch is deprecated at (eval 7) line 15. 80s # Smartmatch is deprecated at (eval 8) line 11. 80s # Smartmatch is deprecated at (eval 8) line 21. 80s ok 3 - env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"autobox::Junctions" -e 1 2>&1 exited successfully 80s not ok 4 - env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"autobox::Junctions" -e 1 2>&1 produced no (non-whitelisted) output 80s Dubious, test returned 2 (wstat 512, 0x200) 80s Failed 2/4 subtests -- Niko Tyni nt...@debian.org
Bug#1050304: dizzy: autopkgtest failure with Perl 5.38: Smartmatch is deprecated
Source: dizzy Version: 0.3-4 Severity: important Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition autopkgtest This package fails its autopkgtest checks with Perl 5.38 (currently in experimental.) https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dizzy/37060138/log.gz 78s autopkgtest [18:02:48]: test autodep8-perl: /usr/share/pkg-perl-autopkgtest/runner runtime-deps 78s autopkgtest [18:02:48]: test autodep8-perl: [--- 79s 79s # Failed test ' /usr/bin/perl -w -M"Dizzy::Core" -e 1 2>&1 produced no (non-whitelisted) output' 79s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 79s # Structures begin differing at: 79s # $got->[0] = 'Smartmatch is deprecated at /usr/share/perl5/Dizzy/Perl2GLSL.pm line 18. 79s # ' 79s # $expected->[0] = Does not exist 79s 79s # Failed test 'env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Dizzy::Core" -e 1 2>&1 produced no (non-whitelisted) output' 79s # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 110. 79s # Structures begin differing at: 79s # $got->[0] = 'Smartmatch is deprecated at /usr/share/perl5/Dizzy/Perl2GLSL.pm line 18. 79s # ' 79s # $expected->[0] = Does not exist 79s # Looks like you failed 2 tests of 4. 79s /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t .. 79s 1..4 79s # Smartmatch is deprecated at /usr/share/perl5/Dizzy/Perl2GLSL.pm line 18. 79s # Smartmatch is deprecated at /usr/share/perl5/Dizzy/Perl2GLSL.pm line 182. 79s ok 1 - /usr/bin/perl -w -M"Dizzy::Core" -e 1 2>&1 exited successfully 79s not ok 2 - /usr/bin/perl -w -M"Dizzy::Core" -e 1 2>&1 produced no (non-whitelisted) output 79s # Smartmatch is deprecated at /usr/share/perl5/Dizzy/Perl2GLSL.pm line 18. 79s # Smartmatch is deprecated at /usr/share/perl5/Dizzy/Perl2GLSL.pm line 182. 79s ok 3 - env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Dizzy::Core" -e 1 2>&1 exited successfully 79s not ok 4 - env PERL_DL_NONLAZY=1 /usr/bin/perl -w -M"Dizzy::Core" -e 1 2>&1 produced no (non-whitelisted) output 79s Dubious, test returned 2 (wstat 512, 0x200) 79s Failed 2/4 subtests -- Niko Tyni nt...@debian.org
Bug#1042238: devscripts: FTBFS: dh_auto_test: error: make -j8 test returned exit code 2
Control: tag -1 pending On Wed, Jul 26, 2023 at 10:19:53PM +0200, Lucas Nussbaum wrote: > Source: devscripts > Version: 2.23.5 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230726 ftbfs-trixie > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Undefined subroutine ::to_json called at ./t/salsa.pm line 49. > > # Tests were run but no plan was declared and done_testing() was not seen. > > # Looks like your test exited with 255 just after 1. > > test_comments_in_quoted_strings2 > > t/salsa.t . > > Dubious, test returned 255 (wstat 65280, 0xff00) This regressed with libgitlab-api-v4-perl 0.27-1, which is not migrating to testing because of the same failure on the autopkgtest side. The problem is that t/salsa.pm uses JSON::to_json() without loading the JSON module. This was always wrong, but GitLab::API::v4::RESTClient used to bring it in transitively. That has now changed as libgitlab-api-v4-perl has switched from the JSON module to JSON::MaybeXS. Umh. After patching this and another thing locally I see now that it's also #1041220 / #1038486, which were incorrectly merged resulting in confused metadata that makes it look like it's all a thing of the past. FWIW I think #1041220 should not have been reassigned + merged. It was about libgitlab-api-v4-perl 0.26-3 being seriously buggy because it is out of sync with unstable. When devscripts is fixed, libgitlab-api-v4-perl 0.27-1 will then migrate and #1041220 would have stopped affecting testing without any other action on that bug. But undoing the merge now would probably make things even more confusing. Copying Yadd and Gregor who were involved. It looks like devscripts.git has the necessary patches (including a perltidy fix) but somebody just needs to upload it (and possibly fix the BTS mess afterwards if it becomes a problem.) -- Niko
Bug#1043425: libmethod-signatures-perl: FTBFS with Perl 5.38: Smartmatch is deprecated
Control: tag -1 patch
On Thu, Aug 10, 2023 at 09:20:42PM +0300, Niko Tyni wrote:
> Source: libmethod-signatures-perl
> Version: 20170211-3
> Severity: important
> Tags: ftbfs trixie sid
> User: debian-p...@lists.debian.org
> Usertags: perl-5.38-transition
>
> This package fails to build from source with Perl 5.38 (currently in
> experimental.)
>
>
> http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/libmethod-signatures-perl_20170211-3/libmethod-signatures-perl_20170211-3_amd64-2023-08-04T06:11:02Z.build
>
> # Failed test 'no warnings for using smartmatch'
> # at t/where.t line 21.
> # found warning: Smartmatch is deprecated at (eval 34) line 1.
> # didn't expect to find a warning
Here's a patch for this issue.
--
Niko Tyni nt...@debian.org
>From 958378982f9a046708cdd69b1c5e1189700f5273 Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Sun, 20 Aug 2023 20:19:59 +0100
Subject: [PATCH] Skip smartmatch warnings test for newer perls
Bug-Debian: http://bugs.debian.org/1043425
---
t/where.t | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/t/where.t b/t/where.t
index 09f027d..511860c 100644
--- a/t/where.t
+++ b/t/where.t
@@ -18,8 +18,10 @@ use Method::Signatures;
my $where_func = q{ func silly_test ($x where { $_ == 3 }) {} };
-warning_is { eval $where_func } undef, 'no warnings for using smartmatch';
-
+SKIP: {
+skip "Smartmatch should warn for Perl >= 5.37.10", 1 if $] >= 5.037010;
+warning_is { eval $where_func } undef, 'no warnings for using smartmatch';
+}
subtest 'where { block() }' => sub {
plan tests => 3;
@@ -152,15 +154,15 @@ subtest 'where with placeholders' => sub {
ok eval { constrained_placeholder(2) }, 'constrained_placeholder() called as expected'
or note $@;
-# line 155
+# line 157
throws_ok { constrained_placeholder() }
-required_placeholder_error('main', 0, 'constrained_placeholder', LINE => 156),
+required_placeholder_error('main', 0, 'constrained_placeholder', LINE => 158),
'missing requierd constrained placeholder';
throws_ok { constrained_placeholder('foo') }
-placeholder_badval_error('main', 0, 'Int' => 'foo', 'constrained_placeholder', LINE => 159),
+placeholder_badval_error('main', 0, 'Int' => 'foo', 'constrained_placeholder', LINE => 161),
'placeholder value wrong type';
throws_ok { constrained_placeholder(99) }
-placeholder_failed_constraint_error('main', 0, 99 => '{$_<10}', 'constrained_placeholder', LINE => 162),
+placeholder_failed_constraint_error('main', 0, 99 => '{$_<10}', 'constrained_placeholder', LINE => 164),
'placeholder value wrong type';
};
--
2.39.1
Bug#1040655: liblmdb-file-perl: FTBFS with Perl 5.38: undefined reference to `Perl_do_vecget'
Control: tag -1 patch
On Sat, Jul 08, 2023 at 07:17:23PM +0300, Niko Tyni wrote:
> Source: liblmdb-file-perl
> Version: 0.12-4
> Severity: important
> Tags: ftbfs trixie sid upstream
> Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=148421
> User: debian-p...@lists.debian.org
> Usertags: perl-5.38-transition
>
> This package fails to build with Perl 5.38 (currently in experimental).
> /usr/bin/ld: LMDB.o: in function `XS_LMDB_File__cmp':
> ././LMDB.c:2731: undefined reference to `Perl_do_vecget'
Here's a patch I just sent upstream that works around this by copying
a simplified version of Perl_do_vecget into this module.
--
Niko Tyni nt...@debian.org
>From 1469c3d13a99f401ac2457b37564bc7aedcf050a Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Sat, 19 Aug 2023 21:08:33 +0100
Subject: [PATCH] Lift vecget function from Perl core for 5.38 compatibility
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
As suggested by Petr Písař.
Simplified to only handle size <= 8 as the module only needs size==2.
Bug: https://rt.cpan.org/Ticket/Display.html?id=148421
Bug-Debian: https://bugs.debian.org/1040655
---
LMDB.xs | 45 -
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/LMDB.xs b/LMDB.xs
index f474abb..647e463 100644
--- a/LMDB.xs
+++ b/LMDB.xs
@@ -110,6 +110,49 @@ S_mySvPVutf8(pTHX_ SV *sv, STRLEN *const len) {
typedef IV MyInt;
+/* lifted from Perl core and simplified [rt.cpan.org #148421] */
+STATIC UV
+my_do_vecget(pTHX_ SV *sv, STRLEN offset, int size)
+{
+STRLEN srclen;
+const I32 svpv_flags = ((PL_op->op_flags & OPf_MOD || LVRET)
+ ? SV_UNDEF_RETURNS_NULL : 0);
+unsigned char *s = (unsigned char *)
+SvPV_flags(sv, srclen, (svpv_flags|SV_GMAGIC));
+UV retnum = 0;
+
+if (!s) {
+ s = (unsigned char *)"";
+}
+
+/* aka. PERL_ARGS_ASSERT_DO_VECGET */
+assert(sv);
+/* sanity checks to make sure the premises for our simplifications still hold */
+assert(LMDB_OFLAGN <= 8);
+if (size != LMDB_OFLAGN)
+Perl_croak(aTHX_ "This is a crippled version of vecget that supports size==%d (LMDB_OFLAGN)", LMDB_OFLAGN);
+
+if (SvUTF8(sv)) {
+if (Perl_sv_utf8_downgrade_flags(aTHX_ sv, TRUE, 0)) {
+/* PVX may have changed */
+s = (unsigned char *) SvPV_flags(sv, srclen, svpv_flags);
+}
+else {
+Perl_croak(aTHX_ "Use of strings with code points over 0xFF"
+ " as arguments to vec is forbidden");
+}
+}
+
+STRLEN bitoffs = ((offset % 8) * size) % 8;
+STRLEN uoffset = offset / (8 / size);
+
+if (uoffset >= srclen)
+return 0;
+
+retnum = (s[uoffset] >> bitoffs) & nBIT_MASK(size);
+return retnum;
+}
+
static void
populateStat(pTHX_ HV** hashptr, int res, MDB_stat *stat)
{
@@ -152,7 +195,7 @@ typedef struct {
START_MY_CXT
-#define LMDB_OFLAGS TOHIWORD(Perl_do_vecget(aTHX_ MY_CXT.OFlags, dbi, LMDB_OFLAGN))
+#define LMDB_OFLAGS TOHIWORD(my_do_vecget(aTHX_ MY_CXT.OFlags, dbi, LMDB_OFLAGN))
#define MY_CMP *av_fetch(MY_CXT.Cmps, MY_CXT.curdb, 1)
#define MY_DCMP *av_fetch(MY_CXT.DCmps, MY_CXT.curdb, 1)
--
2.39.1
Bug#1043234: libmath-bigint-perl: subclassing breaks numeric comparison
Control: forwarded -1 https://github.com/pjacklam/p5-Math-BigInt/issues/8 Control: tag -1 patch Control: affects -1 libpgobject-type-bigfloat-perl On Mon, Aug 07, 2023 at 08:06:09PM +0100, Niko Tyni wrote: > Package: libmath-bigint-perl > Version: 1.999838-1 > Severity: important > Tags: ftbfs upstream > User: debian-p...@lists.debian.org > Usertags: perl-5.38-transition > Control: affects -1 ledgersmb > I was able to narrow it down to this test, which fails with newer versions: > > --- > package MyFloat; > use base qw(Math::BigFloat); > 1; > > print MyFloat->new(.99) == Math::BigFloat->new(.99) ? "ok\n": "not > ok\n"; > --- > > It bisects down to upstream commit > > > https://github.com/pjacklam/p5-Math-BigInt/commit/46d1252c98f565ae787c840173e5f98acf8953f1 > > so it regressed with upstream version 1.999836. I've filed an upstream bug at https://github.com/pjacklam/p5-Math-BigInt/issues/8 and sent a proposed patch at https://github.com/pjacklam/p5-Math-BigInt/pull/9 -- Niko
Bug#1043425: libmethod-signatures-perl: FTBFS with Perl 5.38: Smartmatch is deprecated
Source: libmethod-signatures-perl Version: 20170211-3 Severity: important Tags: ftbfs trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental.) http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/libmethod-signatures-perl_20170211-3/libmethod-signatures-perl_20170211-3_amd64-2023-08-04T06:11:02Z.build # Failed test 'no warnings for using smartmatch' # at t/where.t line 21. # found warning: Smartmatch is deprecated at (eval 34) line 1. # didn't expect to find a warning Any::Moose is deprecated. Please use Moo instead at /<>/blib/lib/Method/Signatures.pm line 1293. # Looks like you failed 1 test of 6. t/where.t not ok 1 - no warnings for using smartmatch [...] Test Summary Report --- t/role_check_basic.t (Wstat: 0 Tests: 2 Failed: 0) TODO passed: 1-2 t/syntax_errors.t (Wstat: 0 Tests: 3 Failed: 0) TODO passed: 2 t/where.t (Wstat: 256 (exited 1) Tests: 6 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=68, Tests=446, 9 wallclock secs ( 0.18 usr 0.07 sys + 7.81 cusr 1.39 csys = 9.45 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#1043344: perl: Use of freed value in iteration with base.pm dotless-INC guard when looping over @INC
Package: perl
Version: 5.38.0-1
Severity: important
Tags: upstream
User: debian-p...@lists.debian.org
Usertags: perl-5.38-transition
Control: affects -1 libhtml-widget-perl
The libhtml-widget-perl package fails to build with Perl 5.38 on
perl.debian.net:
http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/libhtml-widget-perl_1.11-6/libhtml-widget-perl_1.11-6_amd64-2023-08-09T09:20:08Z.build
# Failed test 'use HTML::Widget;'
# at t/01use.t line 6.
# Tried to use 'HTML::Widget'.
# Error: Use of freed value in iteration at
/usr/share/perl5/Module/Pluggable/Fast.pm line 74.
# Compilation failed in require at t/01use.t line 6.
# BEGIN failed--compilation aborted at t/01use.t line 6.
# Looks like you failed 1 test of 1.
[...]
The build fails deterministically every time on that host, but not on
my local workstation (and neither on Gregor's according to his report on
IRC.) It also fails if I run the test suite manually on perl.debian.net.
After a few nights of glaring at this, I think it's probably an instance
of the longstanding stack-not-refcounted issue (see #582925) and has
been present ever since '.' was removed from the default @INC and base.pm
acquired the "dotless-INC guard" in
https://github.com/Perl/perl5/commit/fa71f6670dda393818d17f2f3bd2bee165347849
As I understand it, Module::Pluggable::Fast is looping over @INC and
ends up calling base.pm which fiddles with @INC under the hood if
it contains cwd (dot). This results in rather undefined behaviour,
sometimes triggering the fatal "Use of freed value in iteration" error.
The undefined behaviour is very sensitive to @INC contents and
length, making this something of a heisenbug. It's easier to trigger with
Perl 5.38 than earlier versions but that's probably just by chance.
I'm able to trigger it in the HTML-Widget build on my local workstation
with Perl 5.38 by running "PERL5LIB=.:. make test". It also triggers on
sid / Perl 5.36 both on my workstation and perl.debian.net with something
silly like
PERL5LIB=$(perl -e "print 'x:'x40")x make test
The HTML-Widget build runs the test suite with Test::Harness, which
sets PERL_USE_UNSAFE_INC=1, putting cwd on @INC and activating the
base.pm guard. A workaround seems to be explicitly running
PERL_USE_UNSAFE_INC=0 make test
as Test::Harness respects that. This does make libhtml-widget-perl
test suite pass me on perl.debian.net with Perl 5.38, so maybe it
can be used to mitigate the immediate issue in Debian.
I was able to narrow the thing down to this test case, which fails
deterministically everywhere I've tried, with every Perl version since
the dot-on-INC removal including current upstream bleadperl:
% tree
.
|-- lib
| `-- Plugins
| `-- B.pm
`-- test.t
3 directories, 2 files
% cat test.t
#!/usr/bin/perl
BEGIN { print "1..3\n"; }
push @INC, './lib'; # plugin path
push @INC, '.'; # needed to trigger 'Use of freed value in iteration'
package MyPlugin;
sub new { print "ok 1 - new() called for plugin $_[0]\n"; }
1;
package A;
use Module::Pluggable::Fast search => [qw/Plugins/];
print scalar A->plugins ?
"ok 2 - found plugins\n" :
"not ok 2 - no plugins found\n";
1;
print "ok 3 - all done\n";
% cat lib/Plugins/B.pm
package Plugins::B;
use base qw/MyPlugin/;
1;
% /opt/perl/bin/perl5.39.2 test.t
1..3
ok 1 - new() called for plugin Plugins::B
Use of freed value in iteration at
/opt/perl/lib/site_perl/5.39.2/Module/Pluggable/Fast.pm line 74.
and further down to this, which is sillier but more self contained as
it only uses base.pm:
% cat test2.t
BEGIN { print "1..1\n"; }
package X;
sub x { }
1;
package main;
require base;
push @INC, '.';
foreach my $dir ( grep /./, @INC)
{
base->import('X');
}
print "ok 1\n";
% /opt/perl/bin/perl5.39.2 test2.t
1..1
Use of freed value in iteration at test2.t line 13.
This whole wall of text should be reported upstream too. Things are
complicated a bit by the fact that HTML-Widget, which prominently exhibits
this behaviour, is dead upstream and rather heavily patched in Debian
to make it able to build at all. But maybe the shorter test case with
Module::Pluggable::Fast is enough to show it's an actual issue.
--
Niko
Bug#1043239: lemonldap-ng: FTBFS with Perl 5.38: test failures
Source: lemonldap-ng Version: 2.16.1+ds-2 Severity: important Tags: ftbfs trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental.) http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/lemonldap-ng_2.16.1+ds-2/lemonldap-ng_2.16.1+ds-2_amd64-2023-08-04T06:12:12Z.build # Failed test 'Found correct error message' # at t/12-Lemonldap-NG-Handler-Jail.t line 114. # 'syntax error at (eval 52) line 1, at EOF # Execution of (eval 52) aborted due to compilation errors. # ' # doesn't match '(?^:Missing right curly or square bracket)' # Looks like you failed 1 test of 22. # Failed test 'Found correct error message' # at t/13-Lemonldap-NG-Handler-Fake-Safe.t line 107. # 'syntax error at (eval 47) line 1, at EOF # Execution of (eval 47) aborted due to compilation errors. # ' # doesn't match '(?^:Missing right curly or square bracket)' # Looks like you failed 1 test of 16. Test Summary Report --- t/12-Lemonldap-NG-Handler-Jail.t (Wstat: 256 (exited 1) Tests: 22 Failed: 1) Failed test: 22 Non-zero exit status: 1 t/13-Lemonldap-NG-Handler-Fake-Safe.t(Wstat: 256 (exited 1) Tests: 16 Failed: 1) Failed test: 16 Non-zero exit status: 1 Files=25, Tests=405, 7 wallclock secs ( 0.08 usr 0.03 sys + 4.03 cusr 0.70 csys = 4.84 CPU) Result: FAIL This looks like just an issue of changed diagnostics, but please don't hesitate to file a bug against perl in case it turns out to have runtime effects that warrant a Breaks entry. -- Niko Tyni nt...@debian.org
Bug#1040659: libtest-strict-perl: FTBFS with Perl 5.38: test failures
Control: tag -1 patch On Sat, Jul 08, 2023 at 08:47:21PM +0300, Niko Tyni wrote: > Source: libtest-strict-perl > Version: 0.52-2 > Severity: important > Tags: ftbfs trixie sid > Forwarded: https://github.com/manwar/Test-Strict/issues/32 > User: debian-p...@lists.debian.org > Usertags: perl-5.38-transition > > This package fails to build with Perl 5.38 (currently in experimental). > ># Failed test 'Syntax check /tmp/RsMORA8Sdy/G9eCGgt__c.pl' ># at /<>/blib/lib/Test/Strict.pm line 435. > The upstream ticket suggests a fix of separating runs with the -v and > -c switches. There's a patch at https://github.com/manwar/Test-Strict/pull/33 -- Niko Tyni nt...@debian.org
Bug#1043234: libmath-bigint-perl: subclassing breaks numeric comparison
Package: libmath-bigint-perl Version: 1.999838-1 Severity: important Tags: ftbfs upstream User: debian-p...@lists.debian.org Usertags: perl-5.38-transition Control: affects -1 ledgersmb ledgersmb fails to build with new versions of Math-BigInt, including the one separately packaged (both in stable and unstable) as libmath-bigint-perl, and the one bundled with Perl 5.38 (currently in experimental.) # Failed test 'form: 9.999,99 parsed as 1.000,00 - .99' # at t/02-number-handling.t line 224. # got: .99 # expected: .99 [...] Test Summary Report --- t/02-number-handling.t(Wstat: 5120 (exited 20) Tests: 374 Failed: 20) Failed tests: 336-340, 345-349, 354-358, 365-369 Non-zero exit status: 20 Files=20, Tests=1802, 17 wallclock secs ( 0.39 usr 0.06 sys + 14.92 cusr 1.89 csys = 17.26 CPU) Result: FAIL I was able to narrow it down to this test, which fails with newer versions: --- package MyFloat; use base qw(Math::BigFloat); 1; print MyFloat->new(.99) == Math::BigFloat->new(.99) ? "ok\n": "not ok\n"; --- It bisects down to upstream commit https://github.com/pjacklam/p5-Math-BigInt/commit/46d1252c98f565ae787c840173e5f98acf8953f1 so it regressed with upstream version 1.999836. -- Niko Tyni nt...@debian.org
Bug#1043230: perl: break libgnupg-interface-perl (<< 1.02-4)
Package: perl Version: 5.38.0-1 As discussed in #1042985, we should add a Breaks: libgnupg-interface-perl (<< 1.02-4) to support partial upgrades to 5.38. -- Niko
Bug#1043228: adequate: FTBFS with Perl 5.38: deprecated keywords
Source: adequate Version: 0.15.7 Severity: important Tags: ftbfs sid trixie User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental.) http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/adequate_0.15.7/adequate_0.15.7_amd64-2023-08-04T06:16:05Z.build TESTING: ./adequate --version given is deprecated at ./adequate line 93. when is deprecated at ./adequate line 94. when is deprecated at ./adequate line 97. when is deprecated at ./adequate line 100. Smartmatch is deprecated at ./adequate line 647. when is deprecated at ./adequate line 710. when is deprecated at ./adequate line 713. when is deprecated at ./adequate line 716. when is deprecated at ./adequate line 730. when is deprecated at ./adequate line 738. when is deprecated at ./adequate line 743. when is deprecated at ./adequate line 751. when is deprecated at ./adequate line 754. when is deprecated at ./adequate line 782. when is deprecated at ./adequate line 785. when is deprecated at ./adequate line 829. Smartmatch is deprecated at ./adequate line 929. make[1]: *** [debian/rules:17: override_dh_auto_test] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:6: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 -- Niko Tyni nt...@debian.org
Bug#1042847: libstring-license-perl: broken with Perl 5.38: syntax error near "class String::License::Naming::Custom :"
Control: found -1 0.0.9-1 Control: tag -1 patch On Tue, Aug 01, 2023 at 10:25:04PM +0300, Niko Tyni wrote: > Package: libstring-license-perl > Version: 0.0.2-1 > Severity: important > Tags: ftbfs trixie sid > Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=148507 > User: debian-p...@lists.debian.org > Usertags: perl-5.38-transition > Control: affects -1 licensecheck > > Some modules in this package report syntax errors with Perl 5.38 > (currently in experimental.) > > This also makes the test suite fail, so the package fails to build > from source. > > When this is fixed, please file a bug on the perl package > to add a Breaks entry for earlier versions so that partial > upgrades cannot end up with a broken combination. As seen in http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/libstring-license-perl_0.0.9-1/libstring-license-perl_0.0.9-1_amd64-2023-08-05T15:35:07Z.build this has now turned into Class :isa attribute requires a class but "String::License::Naming" is not one at /home/ntyni/tmp/libstring-license-perl/blib/lib/String/License/Naming/Custom.pm line 64. This looks like a bug in the current (still experimental) Perl core implementation of the class feature. I've just filed https://github.com/Perl/perl5/issues/21332 about it. Working around that reveals new errors: Bareword "__CLASS__" not allowed while "strict subs" in use at lib/String/License.pm line 59. Attempt to access disallowed key '__ANON__' in a restricted hash at lib/String/License.pm line 64. String::License using the __CLASS__ keyword, which was not yet implemented in the core version for 5.38. A quick fix is to just use Object::Pad instead of Feature::Compat::Class, which fixes the other error as well. Doing that shows one more instance of the first issue: Class :isa attribute requires a class but "String::License::Naming" is not one at /home/ntyni/tmp/libstring-license-perl/blib/lib/String/License/Naming/SPDX.pm line 57. The attached patch has workarounds for all of these. It passes the test suite for me on both Perl 5.36 (Debian sid) and 5.38 (Debian experimental.) Hope this helps, -- Niko Tyni nt...@debian.org >From c266d3f0983eaf2155de693bf5d0efb90bfc1145 Mon Sep 17 00:00:00 2001 From: Niko Tyni Date: Mon, 7 Aug 2023 18:32:10 +0100 Subject: [PATCH] Workarounds for the class feature on Perl 5.38 __CLASS__ is not implemented in 5.38 yet, so we need to use Object::Pad for String::License instead of Feature::Compat::Class. Hierarchical naming currently has a quirk with :isa(), see https://github.com/Perl/perl5/issues/21332 Bug-Debian: https://bugs.debian.org/1042847 --- lib/String/License.pm | 2 +- lib/String/License/Naming/Custom.pm | 1 + lib/String/License/Naming/SPDX.pm | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/String/License.pm b/lib/String/License.pm index dd3d9aa..cdf27c2 100644 --- a/lib/String/License.pm +++ b/lib/String/License.pm @@ -4,7 +4,7 @@ use warnings; use feature qw(signatures); no warnings qw(experimental::signatures); -use Feature::Compat::Class 0.04; +use Object::Pad; =head1 NAME diff --git a/lib/String/License/Naming/Custom.pm b/lib/String/License/Naming/Custom.pm index 28e2941..b00de17 100644 --- a/lib/String/License/Naming/Custom.pm +++ b/lib/String/License/Naming/Custom.pm @@ -59,6 +59,7 @@ use Log::Any (); use List::Util qw(uniq); use Regexp::Pattern::License 3.4.0; +use String::License::Naming (); use namespace::clean; class String::License::Naming::Custom : isa(String::License::Naming); diff --git a/lib/String/License/Naming/SPDX.pm b/lib/String/License/Naming/SPDX.pm index b40ddf6..2b64598 100644 --- a/lib/String/License/Naming/SPDX.pm +++ b/lib/String/License/Naming/SPDX.pm @@ -54,6 +54,7 @@ use Regexp::Pattern::License 3.4.0; use namespace::clean; +use String::License::Naming (); class String::License::Naming::SPDX : isa(String::License::Naming); field $log; -- 2.39.1
Bug#1043028: libtest-valgrind-perl: FTBFS with Perl 5.38: t/20-bad.t failure
Source: libtest-valgrind-perl Version: 1.19-4 Severity: important Tags: ftbfs trixie sid patch Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=149286 User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental.) http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/libtest-valgrind-perl_1.19-4/libtest-valgrind-perl_1.19-4_amd64-2023-08-04T06:09:38Z.build # Using valgrind 3.19.0 located at /usr/bin/valgrind # Using suppressions from /<>/debian/.debhelper/generated/_source/home/.perl/Test-Valgrind/suppressions/1.19/memcheck-3.19.0-bd70d6cc6d8860d399045326be838ffd.supp # # leaking some bytes! # 10,000 bytes in 1 blocks are still reachable in loss record 18 of 18 # malloc (/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) [?:?] # tv_leak (/<>/blib/arch/auto/Test/Valgrind/Valgrind.so) [Valgrind.xs:34] # XS_Test__Valgrind_leak (/<>/blib/arch/auto/Test/Valgrind/Valgrind.so) [Valgrind.xs:54] # ? (/usr/bin/perl) [?:?] # Perl_runops_standard (/usr/bin/perl) [?:?] # perl_run (/usr/bin/perl) [?:?] # main (/usr/bin/perl) [?:?] # Failed test 'Leak_StillReachable' # at /<>/blib/lib/Test/Valgrind/Session.pm line 598. # got: 1 # expected: 0 # Failed test 'caught one extra leak' # at /<>/blib/lib/Test/Valgrind.pm line 307. # got: '0' # expected: '1' # Failed test 'no extra leak caught, hence no bytes leaked' # at /<>/blib/lib/Test/Valgrind.pm line 307. # Failed test 'no extra leak caught, hence no block leaked' # at /<>/blib/lib/Test/Valgrind.pm line 307. # Looks like your test exited with 1 just after 18. [...] Test Summary Report --- t/20-bad.t (Wstat: 256 (exited 1) Tests: 18 Failed: 4) Failed tests: 15-18 Non-zero exit status: 1 Files=10, Tests=200, 21 wallclock secs ( 0.05 usr 0.01 sys + 19.96 cusr 0.49 csys = 20.51 CPU) Result: FAIL There's a patch/workaround in the upstream ticket (but I haven't tested it.) -- Niko Tyni nt...@debian.org
Bug#1042985: libgnupg-interface-perl: FTBFS with Perl 5.38: Insecure directory in $ENV{PATH} while running with -T switch
Source: libgnupg-interface-perl
Version: 1.02-3
Severity: important
Tags: ftbfs trixie sid
User: debian-p...@lists.debian.org
Usertags: perl-5.38-transition
X-Debbugs-Cc: Andrew Ruthven
This package fails to build from source with Perl 5.38 (currently in
experimental.)
http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/libgnupg-interface-perl_1.02-3/libgnupg-interface-perl_1.02-3_amd64-2023-07-06T13:45:16Z.build
Insecure directory in $ENV{PATH} while running with -T switch at
/<>/blib/lib/GnuPG/Interface.pm line 355.
Use of uninitialized value $line in pattern match (m//) at
/<>/blib/lib/GnuPG/Interface.pm line 828.
Use of uninitialized value $a in split at
/<>/blib/lib/GnuPG/Interface.pm line 842.
Use of uninitialized value $a in split at
/<>/blib/lib/GnuPG/Interface.pm line 842.
GnuPG Version 1.4 or 2.2+ required at (eval 208) line 83.
t/taint.t ..
1..2
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 2/2 subtests
This is a Debian specific test file (debian/patches/detect-taint-mode)
but it seems to flag a real upstream issue.
lib/GnuPG/Interface.pm has this:
local $ENV{PATH} if tainted $ENV{PATH};
exec @command or die "exec() error: $ERRNO";
which broke with
https://github.com/Perl/perl5/commit/5ede4453c4877110eb5214ff400c173210b101b1
for a good reason: an empty $ENV{PATH} is equivalent to '.' (cwd).
Andrew, I'm copying you as you were involved in this stuff a few years
back so you might still be interested :)
Hm, possibly perl should add a Breaks for earlier versions once this is fixed.
--
Niko Tyni nt...@debian.org
Bug#1040387: libb-perlreq-perl: FTBFS with Perl 5.38: t/01-B-PerlReq.t failure
Control: forwarded -1 https://rt.cpan.org/Public/Bug/Display.html?id=148982 Control: tag -1 patch On Wed, Jul 05, 2023 at 01:26:54PM +0300, Niko Tyni wrote: > Source: libb-perlreq-perl > Version: 0.82-7 > Severity: important > Tags: ftbfs trixie sid > User: debian-p...@lists.debian.org > Usertags: perl-5.38-transition > > This package fails to build from source with Perl 5.38 (currently in > experimental): There's a patch by Petr Písař in [rt.cpan.org #148982]. -- Niko
Bug#1042854: libcss-dom-perl: FTBFS with Perl 5.38: Old package separator "'" deprecated
Source: libcss-dom-perl Version: 0.17-2 Severity: important Tags: ftbfs sid trixie patch Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=146661 User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental.) There's a patch by Yves Orton in the upstream ticket. http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/libcss-dom-perl_0.17-2/libcss-dom-perl_0.17-2_amd64-2023-07-06T13:44:23Z.build # Failed test 'no warnings for style belonging to element itself' # at t/css-dom.t line 34. # got: 'Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Style.pm line 174. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Style.pm line 175. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Style.pm line 176. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Rule.pm line 49. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Rule/Style.pm line 96. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Rule/Style.pm line 97. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Rule/Style.pm line 133. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Rule/Style.pm line 141. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Rule/Style.pm line 146. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Rule/Style.pm line 154. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Rule/Style.pm line 155. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Rule/Style.pm line 161. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Rule/Style.pm line 169. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Rule/Style.pm line 170. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Rule/Style.pm line 177. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Rule/Style.pm line 178. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Parser.pm line 372. # Old package separator "'" deprecated at /<>/blib/lib/CSS/DOM/Parser.pm line 416. # ' # expected: undef # Looks like you failed 1 test of 3. [...] Test Summary Report --- t/css-dom.t(Wstat: 256 (exited 1) Tests: 3 Failed: 1) Failed test: 3 Non-zero exit status: 1 Files=31, Tests=3203, 4 wallclock secs ( 0.33 usr 0.06 sys + 3.09 cusr 0.48 csys = 3.96 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#1042853: docknot: FTBFS with Perl 5.38: t/spin/errors.t failure
Source: docknot Version: 7.01-1 Severity: important Tags: ftbfs sid trixie Forwarded: https://github.com/rra/docknot/issues/6 User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental.) This looks like just a test-only diagnostics change, but please file a bug against perl to add a Breaks entry if there's actual runtime breakage after all. http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/docknot_7.01-1/docknot_7.01-1_amd64-2023-07-06T13:37:26Z.build # Failed test 'errors are correct' # at t/spin/errors.t line 46. # got: 'errors.th:1: cannot find argument 2: Did not find opening bracket after prefix: "(?^:\G\s*)", detected at offset 2 # errors.th:3: invalid macro placeholder \2 (greater than 1) # errors.th:5: invalid macro argument count for \badcount # errors.th:9: unknown variable \=UNKNOWN # errors.th:11: unknown command or macro \unknown # errors.th:14: space in anchor "#foo bar" # errors.th:15: no package release information available # errors.th:16: no sitemap file found # errors.th:17: no package version information available # errors.th:17: cannot stat file nonexistent-file # ' # expected: 'errors.th:1: cannot find argument 2: Did not find opening bracket after prefix: "\s*", detected at offset 2 # errors.th:3: invalid macro placeholder \2 (greater than 1) # errors.th:5: invalid macro argument count for \badcount # errors.th:9: unknown variable \=UNKNOWN # errors.th:11: unknown command or macro \unknown # errors.th:14: space in anchor "#foo bar" # errors.th:15: no package release information available # errors.th:16: no sitemap file found # errors.th:17: no package version information available # errors.th:17: cannot stat file nonexistent-file # ' # Looks like you failed 1 test of 2. [...] Test Summary Report --- t/spin/errors.t (Wstat: 256 (exited 1) Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 1 Files=32, Tests=872, 24 wallclock secs ( 0.14 usr 0.05 sys + 20.32 cusr 2.82 csys = 23.33 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#1042852: liblexical-failure-perl: FTBFS with Perl 5.38: test failures
Source: liblexical-failure-perl Version: 0.07-3 Severity: important Tags: ftbfs trixie sid fixed-upstream Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=148315 User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental.) It seems to be fixed upstream in 0.001000 according to the Changes file, though the upstream bug is still open. It's not clear to me if this is just a test diagnostics issue, or if the current version is actually broken with Perl 5.38. Most of the test failures are about deprecations warnings, but at least the t/aliased.t failure looks different. It would probably be prudent to add a Breaks entry on the perl side just in case, so please file a bug about that when this issue is fixed. http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/liblexical-failure-perl_0.07-3/liblexical-failure-perl_0.07-3_amd64-2023-07-06T13:46:41Z.build Test Summary Report --- t/aliased.t (Wstat: 256 (exited 1) Tests: 13 Failed: 1) Failed test: 3 Non-zero exit status: 1 t/inner_scalar.t(Wstat: 1536 (exited 6) Tests: 21 Failed: 11) Failed tests: 2-6, 16-21 Non-zero exit status: 6 Parse errors: Bad plan. You planned 15 tests but ran 21. t/simple.t (Wstat: 256 (exited 1) Tests: 14 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=9, Tests=59, 1 wallclock secs ( 0.05 usr 0.00 sys + 0.71 cusr 0.15 csys = 0.91 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#1042850: libdatabase-dumptruck-perl: FTBFS with Perl 5.38: t/dumptruck.t failure
Source: libdatabase-dumptruck-perl
Version: 1.2-3
Severity: important
Tags: ftbfs trixie sid patch
Forwarded: https://github.com/lkundrak/perl-database-dumptruck/issues/2
User: debian-p...@lists.debian.org
Usertags: perl-5.38-transition
This package fails to build from source with Perl 5.38 (currently in
experimental.)
The upstream ticket points to a possible patch at
https://src.fedoraproject.org/rpms/perl-Database-DumpTruck/raw/20e8880e98b146200c20f379edd847b49f4aea0d
Build log at
http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/libdatabase-dumptruck-perl_1.2-3/libdatabase-dumptruck-perl_1.2-3_amd64-2023-07-06T13:44:51Z.build
dh_auto_test
/usr/bin/perl Build test --verbose 1
# Failed test 'Proper data was retrieved from the database'
# at t/dumptruck.t line 189.
# Structures begin differing at:
# $got->[0]{random}{yes} = 1
# $expected->[0]{random}{yes} = '1'
# Looks like you failed 1 test of 43.
[...]
Test Summary Report
---
t/dumptruck.t (Wstat: 256 (exited 1) Tests: 43 Failed: 1)
Failed test: 43
Non-zero exit status: 1
Files=2, Tests=44, 0 wallclock secs ( 0.01 usr 0.01 sys + 0.25 cusr 0.06
csys = 0.33 CPU)
Result: FAIL
--
Niko Tyni nt...@debian.org
Bug#1042849: libmodule-reader-perl: FTBFS with Perl 5.38: t/memory.t failure
Source: libmodule-reader-perl Version: 0.003003-3 Severity: important Tags: ftbfs sid trixie Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=148979 User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental.) http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/libmodule-reader-perl_0.003003-3/libmodule-reader-perl_0.003003-3_amd64-2023-07-06T13:48:09Z.build # Failed test 'regex fails the same as require' # at t/memory.t line 99. # got: 'Can't locate object method "INC" via package "Regexp"' # expected: 'Can't locate object method "INC", nor "INCDIR" nor string overload via package "Regexp" in object hook in @INC' # Failed test 'class without INC fails the same as require' # at t/memory.t line 99. # got: 'Can't locate object method "INC" via package "NonHook"' # expected: 'Can't locate object method "INC", nor "INCDIR" nor string overload via package "NonHook" in object hook in @INC' # Looks like you failed 2 tests of 18. t/memory.t .. ok 1 - correctly load module from sub @INC hook ok 2 - loads overridden module from sub @INC hook ok 3 - found => \%INC loads mod as it was required ok 4 - calculated file matches loaded filename ok 5 - hook returning an array ref is ignored ok 6 - hook returning a hash ref is ignored ok 7 - hash ref fails the same as require ok 8 - scalar ref fails the same as require not ok 9 - regex fails the same as require not ok 10 - class without INC fails the same as require ok 11 - class with INC hook works the same as require ok 12 - child class of INC hook works the same as require ok 13 - array ref without code fails the same as require ok 14 - array ref with string fails the same as require ok 15 - array ref with stringy main sub fails the same as require ok 16 - array ref with stringy fully qualified sub fails the same as require ok 17 - array ref with hash ref fails the same as require ok 18 - array ref with code fails the same as require 1..18 Dubious, test returned 2 (wstat 512, 0x200) Failed 2/18 subtests Test Summary Report --- t/memory.t(Wstat: 512 (exited 2) Tests: 18 Failed: 2) Failed tests: 9-10 Non-zero exit status: 2 Files=3, Tests=119, 1 wallclock secs ( 0.03 usr 0.02 sys + 0.24 cusr 0.06 csys = 0.35 CPU) Result: FAIL Failed 1/3 test programs. 2/119 subtests failed. make[1]: *** [Makefile:826: test_dynamic] Error 2 make[1]: Leaving directory '/<>' dh_auto_test: error: make -j4 test TEST_VERBOSE=1 returned exit code 2 make: *** [debian/rules:4: build] Error 25 -- Niko Tyni nt...@debian.org
Bug#1042847: libstring-license-perl: broken with Perl 5.38: syntax error near "class String::License::Naming::Custom :"
Package: libstring-license-perl Version: 0.0.2-1 Severity: important Tags: ftbfs trixie sid Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=148507 User: debian-p...@lists.debian.org Usertags: perl-5.38-transition Control: affects -1 licensecheck Some modules in this package report syntax errors with Perl 5.38 (currently in experimental.) This also makes the test suite fail, so the package fails to build from source. When this is fixed, please file a bug on the perl package to add a Breaks entry for earlier versions so that partial upgrades cannot end up with a broken combination. http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/libstring-license-perl_0.0.2-1/libstring-license-perl_0.0.2-1_amd64-2023-07-06T13:51:44Z.build dh_auto_test make -j4 test TEST_VERBOSE=1 make[1]: Entering directory '/<>' PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch')" t/*.t syntax error at /<>/blib/lib/String/License/Naming/Custom.pm line 62, near "class String::License::Naming::Custom :" Execution of /<>/blib/lib/String/License/Naming/Custom.pm aborted due to compilation errors. Compilation failed in require at /<>/blib/lib/String/License.pm line 45. BEGIN failed--compilation aborted at /<>/blib/lib/String/License.pm line 45. Compilation failed in require at t/basic-lib-no-RE2.t line 7. BEGIN failed--compilation aborted at t/basic-lib-no-RE2.t line 7. [...] dh_auto_test make -j4 test TEST_VERBOSE=1 make[1]: Entering directory '/<>' PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch')" t/*.t syntax error at /<>/blib/lib/String/License/Naming/Custom.pm line 62, near "class String::License::Naming::Custom :" Execution of /<>/blib/lib/String/License/Naming/Custom.pm aborted due to compilation errors. Compilation failed in require at /<>/blib/lib/String/License.pm line 45. BEGIN failed--compilation aborted at /<>/blib/lib/String/License.pm line 45. Compilation failed in require at t/basic-lib-no-RE2.t line 7. BEGIN failed--compilation aborted at t/basic-lib-no-RE2.t line 7. -- Niko Tyni nt...@debian.org
Bug#1042846: sdf: FTBFS with Perl 5.38: Old package separator "'" deprecated
Source: sdf Version: 2.001+1-8 Severity: important Tags: ftbfs trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental.) http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/sdf_2.001+1-8/sdf_2.001+1-8_amd64-2023-07-06T15:02:55Z.build dh_auto_test make -j4 test TEST_VERBOSE=1 make[1]: Entering directory '/<>' make[2]: Entering directory '/<>/bin' Manifying 1 pod document make[2]: Leaving directory '/<>/bin' make[2]: Entering directory '/<>/perllib' make[2]: Leaving directory '/<>/perllib' "/usr/bin/perl" t/TEST 1 Old package separator "'" deprecated at ../../blib/script/sdf line 607. Old package separator "'" deprecated at ../../blib/script/sdf line 608. Old package separator "'" deprecated at ../../blib/script/sdf line 608. Old package separator "'" deprecated at ../../blib/script/sdf line 609. Old package separator "'" deprecated at ../../blib/script/sdf line 610. Old package separator "'" deprecated at ../../blib/script/sdf line 610. [...] filter/table.t . 1..2 # table.sdf: output file ok ok 1 # table.sdf: log file FAILED not ok 2 Failed 1/2 subtests Test Summary Report --- general/expr.t (Wstat: 0 Tests: 2 Failed: 1) Failed test: 2 general/formats.t (Wstat: 0 Tests: 2 Failed: 1) Failed test: 2 [...] filter/table.t (Wstat: 0 Tests: 2 Failed: 1) Failed test: 2 Files=50, Tests=100, 15 wallclock secs ( 0.27 usr 0.19 sys + 4.88 cusr 0.99 csys = 6.33 CPU) Result: FAIL Failed 50/50 test programs. 50/100 subtests failed. make[1]: *** [Makefile:812: test] Error 255 -- Niko Tyni nt...@debian.org
Bug#1042845: libembperl-perl: FTBFS with Perl 5.38: test failures
Source: libembperl-perl Version: 2.5.0-17 Severity: important Tags: ftbfs sid trixie User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental.) I assume the diagnostics have changed again and it's just the tests that need adjusting, but I haven't checked properly. http://perl.debian.net/rebuild-logs/perl-5.38/libembperl-perl_2.5.0-17/libembperl-perl_2.5.0-17+b1_amd64-2023-07-21T10:56:05Z.build PERL_DL_NONLAZY=0 "/usr/bin/perl" "-Iblib/lib" "-Iblib/arch" test.pl loading...ok Testing offline mode... #0 ascii... ok #1 pure.htm...ok #2 nooutput.htm...ok #3 nooutput.htm...ok #4 plain.htm... ok #5 plain.htm... ok #6 plain.htm... ok #7 plainblock.htm... ok #8 plainblock.htm... ok #15 error.htm... Expected 4 more error(s) in logfile Input: test/html/error.htm Output: test/tmp/out.htm Log: test/tmp/test.log Testparameter: errors = 6 condition = $] >= 5.01 version = 2 cgi = 0 repeat = 3 ERRORS detected! NOT all tests have been passed successfully cat: test/tmp/httpd.pid: No such file or directory make[1]: *** [Makefile:1462: test_dynamic] Error 1 make[1]: Leaving directory '/<>' dh_auto_test: error: make -j1 test TEST_VERBOSE=1 returned exit code 2 make: *** [debian/rules:19: binary-arch] Error 25 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 -- Niko Tyni nt...@debian.org
Bug#1042844: elinks: FTBFS with Perl 5.38: error: redefinition of ‘struct object’
Source: elinks
Version: 0.16.1.1-4
Severity: important
Tags: ftbfs sid trixie fixed-upstream
Forwarded: https://github.com/rkd77/elinks/pull/243
User: debian-p...@lists.debian.org
Usertags: perl-5.38-transition
This package fails to build from source with Perl 5.38 (currently in
experimental.)
http://perl.debian.net/rebuild-logs/perl-5.38/elinks_0.16.1.1-4/elinks_0.16.1.1-4+b1_amd64-2023-07-01T14:49:32Z.build
FAILED: src/elinks.p/scripting_perl_core.c.o
cc -Isrc/elinks.p -Isrc -I../src -I. -I.. -I/usr/include/p11-kit-1
-I/usr/include/lua5.3 -I/usr/local/include
-I/usr/lib/x86_64-linux-gnu/perl/5.38/CORE -fdiagnostics-color=always -Wall
-Winvalid-pch '-DGETTEXT_PACKAGE="elinks"' '-DBUILD_ID=""' -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600
-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -isystem /usr/include/mit-krb5
-Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H -fno-strict-aliasing
-Wno-address -Wno-builtin-declaration-mismatch -Wc++-compat -MD -MQ
src/elinks.p/scripting_perl_core.c.o -MF src/elinks.p/scripting_perl_core.c.o.d
-o src/elinks.p/scripting_perl_core.c.o -c ../src/scripting/perl/core.c
In file included from /usr/lib/x86_64-linux-gnu/perl/5.38/CORE/perl.h:4530,
from ../src/scripting/perl/core.h:6,
from ../src/scripting/perl/core.c:16:
/usr/lib/x86_64-linux-gnu/perl/5.38/CORE/sv.h:285:8: error: redefinition of
‘struct object’
285 | struct object {
|^~
In file included from ../src/config/options.h:4,
from ../src/intl/libintl.h:4,
from ../src/scripting/perl/core.c:13:
../src/main/object.h:14:8: note: originally defined here
14 | struct object {
|^~
This seems to be fixed upstream with the PR at
https://github.com/rkd77/elinks/pull/243
--
Niko Tyni nt...@debian.org
Bug#1042843: libimage-sane-perl: FTBFS with Perl 5.38: given is deprecated
Source: libimage-sane-perl Version: 5-1 Severity: important Tags: ftbfs sid trixie upstream patch Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=148487 User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental.) http://perl.debian.net/rebuild-logs/perl-5.38/libimage-sane-perl_5-1/libimage-sane-perl_5-1+b4_amd64-2023-06-29T01:43:33Z.build # Failed test '--device=test --test 2>&1' # at t/81_scanimage-perl.t line 41. # got: 'scanimage: scanning image of size 157x196 pixels at 8 bits/pixel [...] # ' # expected: 'given is deprecated at examples/scanimage line 125. # when is deprecated at examples/scanimage line 126. [...] Test Summary Report --- t/81_scanimage-perl.t (Wstat: 1280 (exited 5) Tests: 6 Failed: 5) Failed tests: 2-6 Non-zero exit status: 5 Files=11, Tests=341, 7 wallclock secs ( 0.05 usr 0.01 sys + 1.18 cusr 0.30 csys = 1.54 CPU) Result: FAIL There's a patch by Petr Písař in the upstream ticket. -- Niko Tyni nt...@debian.org
Bug#1042526: libb-keywords-perl: FTBFS with Perl 5.38: Failed test 'keyword: ADJUST'
Source: libb-keywords-perl Version: 1.24-2 Severity: important Tags: ftbfs sid trixie fixed-upstream Forwarded: https://github.com/rurban/b-keywords/pull/8 User: debian-p...@lists.debian.org Usertags: perl-5.38-transition This package fails to build from source with Perl 5.38 (currently in experimental.) http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/libb-keywords-perl_1.24-2/libb-keywords-perl_1.24-2_amd64-2023-07-06T13:42:55Z.build # Failed test 'keyword: ADJUST' # at t/11keywords.t line 71. # # Failed test 'keyword: class' # at t/11keywords.t line 71. # # Failed test 'keyword: field' # at t/11keywords.t line 71. # # Failed test 'keyword: method' # at t/11keywords.t line 71. # # Looks like you failed 4 tests of 547. This seems to be fixed upstream in 1.25. -- Niko Tyni nt...@debian.org
