Your message dated Sun, 30 Nov 2025 15:37:12 +0100
with message-id <[email protected]>
and subject line Re: Bug#1121084: perl built with new IEEE long doubles on
ppc64el breaks pdl
has caused the Debian Bug report #1121084,
regarding pdl: please build-depend on gcc (>= 4:15) [ppc64el] for IEEE long
double transition
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1121084: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121084
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: perl-base
Version: 5.40.1-7
Severity: serious
User: [email protected]
Usertags: ieee-long-double
X-Debbugs-Cc: [email protected], Matthias Klose
<[email protected]>, [email protected]
As seen at https://ci.debian.net/packages/p/pdl/testing/ppc64el/
perl_5.40.1-7 in unstable breaks the pdl_1:2.100-1 test suite.
70s not ok 540 - right answer from no supplied output ldouble
70s
70s # Failed test 'right answer from no supplied output ldouble'
70s # at t/core.t line 926.
70s # 1/1 values do not match
70s # got: CLDouble D [] (P ) 2.0625
70s # expected: CLDouble D [] (P ) 3+2i
70s # First <=5 values differ at: 0
70s # Those 'got' values: 2.0625
70s # Those 'expected' values: 3+2i
[...]
101s Test Summary Report
101s -------------------
101s t/core.t (Wstat: 1024 (exited 4) Tests: 549
Failed: 4)
101s Failed tests: 540-543
101s Non-zero exit status: 4
101s t/math.t (Wstat: 256 (exited 1) Tests: 74 Failed:
1)
101s Failed test: 2
101s Non-zero exit status: 1
There are no related source code changes. I believe
this is about the long double transition on ppc64el, see
https://wiki.debian.org/ToolChain/IEEELongDouble .
I tested a bit on platti.d.o, and it looks like perl and pdl must be
built with the same kind of long doubles or the tests will fail. So it
would also have happened if pdl had been uploaded first.
This smells like an ABI change in the interface between perl and binary
("XS") modules. I wonder if we can (or should) get away with just
handling pdl, or if we need to bump the Provides: perlapi-5.40.1
and force rebuilds of all binary modules.
If we target just the pdl case, I suppose we could add a Build-Depends:
gcc (>= 15) or somesuch to src:perl and src:pdl, and make perl-base Break
earlier versions of pdl. That should ensure that they get upgraded in
lockstep (I think.) Also, there's a dozen libpdl-*-perl packages in the
archive. Not sure if/how they would be affected.
If we need to rebuild all binary modules to be safe, we could "just"
change Provides: perlapi-5.40.1 to (say) perlapi-5.40.1d on ppc64el, and
schedule binNMUs of all the reverse dependencies. Possibly libperl5.40
should also change its name, not sure about that. We've done this kind
of thing in the past once or twice.
The binary interface change is going to happen soonish anyway for Perl
5.42, but things are not quite ready there (and I sorely lack the spoons
to drive that transition.) So I suppose tying these things together
would not be advisable.
Copying the pdl maintainers, the debian-powerpc list, and Matthias as
the driver of the ppc64el long double transition. Please advise.
--
Niko Tyni [email protected]
--- End Message ---
--- Begin Message ---
On 11/30/25 3:17 PM, Niko Tyni wrote:
On Thu, Nov 20, 2025 at 08:03:54PM +0100, Sebastiaan Couwenberg wrote:
On 11/20/25 7:42 PM, Niko Tyni wrote:
This smells like an ABI change in the interface between perl and binary
("XS") modules. I wonder if we can (or should) get away with just
handling pdl, or if we need to bump the Provides: perlapi-5.40.1
and force rebuilds of all binary modules.
It's unlikely that there are actual users of pdl on ppc64el, so I don't think
this warrants great effort.
If rebuilding pdl resolves the issue, let's leave it at that.
Unless you really want to spend the time for the sake of correctness.
I acknowledge that pdl could just be the canary and wereas it is not important
on ppc64el, perl itself is.
Thanks Bas, and sorry for the delay.
I propose that we add an explicit Build-Depends: gcc (>= 4:15) [ppc64el]
to src:pdl (say) 1:2.100-2, and then a Breaks: pdl (<< 1:2.100-2) [ppc64el]
to perl-base. That should ensure that partial upgrades stay working AFAICS,
and I hope the testing migration checks will automatically pick up the
hint about migrating them together.
I consider these architecture specific controls are very ugly, while they may
be correct.
Hope that makes sense. It doesn't seem like great effort to me, and is
IMO cleaner than just papering over this with a no-change rebuild. If
you think it's badly overkill, feel free to just rebuild src:pdl and
then close the pdl bug.
Having the release team schedule binNMUs for pdl should be sufficient.
BinNMU requested in: #1121680
Kind Regards,
Bas
--
PGP Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
--- End Message ---
