1.19-1 fails to build on ppc64el and ppc64, and builds everywhere else:

https://buildd.debian.org/status/package.php?p=libipc-shareable-perl

https://buildd.debian.org/status/logs.php?pkg=libipc-shareable-perl&arch=ppc64el

   t/72-shm_segments.t  (Wstat: 6912 Tests: 47 Failed: 27)
   t/74-seg_map.t       (Wstat: 512  Tests: 12 Failed: 2)

lib/IPC/Shareable.pm unpacks struct shmid_ds at a hard-coded offset for
shm_segsz, assuming the asm-generic field order. PowerPC puts the three
time fields first, so on ppc64el/ppc64 the offset lands on shm_atime;
the oversized value makes the following shmread() fail and the segment
never reaches %segments. IPC/Shareable/SharedMem.pm has the same bug in
stat().

Reported upstream as #66, together with an alternative that drops the
offset tables entirely and reads the fields through IPC::SysV's XS
instead. Upstream has not replied yet, so the attached minimal fix is
what I would suggest for Debian; it is the least likely to conflict with
whichever route upstream takes.

Both solutions were built and tested on ppc64el under sbuild. No
upstream reply yet.

Filed separately from #1142815, which is the unrelated t/47-seg_size.t
memory problem (upstream #65).

Kind regards,

     Edmund Lodewijks

the time, energy, and confidence to understand the issue(s) :)

And since the issues and patches are spread across 2 bug reports, 2
upstream issues, 1 MR on salsa, and now this thread on the maintainer
mailing list (usually we use debian-perl@lists.debian.org for
discussions, and pkg-perl-maintainers@alioth-lists.debian.net only
for package names and BTS traffic and other automated mails, and the
BTS for discussions about bugs, so CC'd now), people might lack the
overview, so let's try:


For those not having followed along at home, we have:

* https://bugs.debian.org/1142815 (47-seg_size.t)
   Forwarded to https://github.com/stevieb9/ipc-shareable/issues/65

This bug should actually have been closed, as I disabled the test in
the last upload, but I wanted to wait for the package to build which
didn't happen on all architectures, and that's:

* https://bugs.debian.org/1146517 (ppc64el and ppc64)
   Forwarded to https://github.com/stevieb9/ipc-shareable/issues/66


And then we have (thanks for preparing them, Edmund!) different
patchsets in different places:

* Two for #1146517 (ppc64el and ppc64) in https://bugs.debian.org/1146517
   - not sure if they are still valid?

* The same (?) 2 patches fixing #1146517 (ppc64el and ppc64) in
https://salsa.debian.org/perl-team/modules/packages/libipc-shareable-perl/-/merge_requests/1
   but this commit also contains a third patch for fixing #1142815
   (47-seg_size.t).

* And at https://github.com/stevieb9/ipc-shareable/issues/66 we have
   2.5 patchsets, the same (?) two for fixing #1146517 (ppc64el and
   ppc64) as in the MR and the bug report, plus the third one fixing
   #1142815 (47-seg_size.t).
   And then a different pair of patches for #1146517 (ppc64el and
   ppc64), using IPC::SharedMem instead of special casing ppc64el and
   ppc64.

And all these patches/MRs contain a lot of text :) and
TTBOMK (partially) AI-assisted code.


My personal thoughts so far are (and others might disagree):
- I'd also like to see the two bugs fixed, rather sooner than later
   :)
- So it's good to have patches! (Thanks again.)
- There have been no upstream reactions so far; I'd like to keep
   whatever we apply now in Debian as minimal as possible.
- This means I'd rather leave 47-seg_size.t as it is now, and leave
   this fix to upstream. Even if the patch is correct, it needs time
   to review, increases the diff and our maintenance burden, and this
   test has annoyed as often enough already. (And close #1142815
   manually once a package builds everywhere and runs its
   autopackagetests.)
- As for #1146517 (ppc64el and ppc64) I'd rather take the more
   minimal versions of the 2 patches, aka the ones in MR!1 on salsa
   aka the "alternative_*" ones in the upstream issue. Reasoning
   again: less divergence from upstream, it's their decision to adopt
   the change to using IPC::SharedMem (although I like the idea; and I
   also think they have a bug but I'll have to try later …)

So my preliminary proposal is to work from MR!1 on salsa, trim it
down to just the necessary changes for #1146517 (ppc64el and ppc64),
i.e. drop the third patch for #1142815 (47-seg_size.t) and revert the
surrounding changes in debian/, _and_ then have someone with a better
understanding then me about architectures in Perl review those
changes.


And now I'm sorry that I've written a wall of text :) But maybe this
helps us to make progress here.

Happy to hear thoughts and find another pair of eyes!


Cheers,
gregor

Hi Gregor e.a.,

Yes, understood!

Oh my, I am making a complete mess of things, am I not? I am sorry,
Gregor! I didn't want to email you directly, thinking it would be unfair
to just heap my newbie questions all on you..

Thank you!

Indeed, since I investigated the problem, but don't write Perl. I do try
as best as I can to wrangle the AI into checking every angle and aspect
so that it will work, but I have since changed the way I use AI.
 > ...
Do you want me to trim that MR on Salsa down according to what you
wrote, and then we hope that someone will have a look at it? Let me
know, and I'll jump on it.

Thank you, as always, for your thorougness, time, and effort in keeping
Debian sane! It is much appreciated and I look up to you for it.

Kind regards,

     Edmund

No worries, finding the best forum for communication is not always
easy, and in this case there were just quite a few places :)

That's _my_ current idea, but maybe give others a day or three to
come up with their ideas.


Cheers,
gregor

Hi, thanks for looking at these issues.

FWIW I think the IPC::SharedMem approach looks like the right thing to do here.

I also agree with Gregor that the 'IPC::SharedMem::stat'->new->unpack($data)
part in the patch looks a bit out of place and should probably be replaced
with a call to IPC::SharedMem::stat() that does the same thing.

Upstream would probably find it easier to untangle all this with
separate actual pull requests rather than a patch dump with two different
approaches.

Hope this helps a bit, sorry for just another drive by contribution.

Thank you for your eyes and for your reply, Niko! Happy to receive your
feedback.

Let me see if I can untangle the upstream bug report.

As for the Debian situation, I am not sure what should be done. Gregor
feels for taking the one patch idea (minimal), you think the other one
would be the right thing to do, but perhaps only after a change.

Since I would have to ask AI to work out a rewrite of the longer patch,
perhaps I shouldn't suggest one?

Alternatively - just as a question - that architecture could just be
disabled for this package? Would that break any deployments that we know of?

Kind regards,

     Edmund

If Niko suggests to go the IPC::SharedMem path (and if we have one
clear upstream pull request that can be converted to a clean Debian
patch) I'm happy to go this way -- that's why I asked for additional
opinions from people who understand the situation better than me :)
(Thanks Niko!)

That's a very last-resort option; and breakage also occurs one other
(non-release but still) architectures.


Cheers,
gregor