On Wed, Sep 02, 2026 at 08:56:25PM +0200, Edmund Lodewijks wrote: > Source: libipc-shareable-perl > Version: 1.19-1 > Severity: serious > Tags: ftbfs patch upstream > Justification: fails to build from source > Forwarded: https://github.com/stevieb9/ipc-shareable/issues/66 > X-Debbugs-Cc: [email protected] > > > 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.
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. -- Niko Tyni [email protected]
