Bug#1145777: nmu: libpsl_0.21.2-1.1, zlib_1:1.3.dfsg+really1.3.1-1, gmp_2:6.3.0+dfsg-3 (armhf/armel, trixie)

Correction to my original report: it understates the problem, because the
diagnosis I gave was incomplete.

glibc refuses such objects for two distinct reasons, and both are reported
with the same message, which is what misled me:

   1. elf/dl-load.c
          ((ph->p_vaddr - ph->p_offset) & (GLRO(dl_pagesize) - 1)) != 0
   2. elf/dl-map-segments.h
          loadcmds[nloadcmds - 1].mapstart < c->mapend
      i.e. rounded out to whole pages, two consecutive PT_LOAD segments 
share
      a page.

   -> "ELF load command address/offset not page-aligned"

My report quoted only (1) and therefore listed only the packages failing it.
One more package in the very same closure fails (2) on its own:

   librtmp1 2.4+20151223.gitfa8646d.1-2+b5 (source: rtmpdump), armhf
       LOAD 0  p_offset=0x000000  p_vaddr=0x00000000 p_filesz=0x12d14
               -> page extent 0x00000..0x14000
       LOAD 1  p_offset=0x013a18  p_vaddr=0x00013a18
               -> page extent 0x10000..0x18000

   p_vaddr == p_offset in both segments, so condition (1) is satisfied 
and the
   file looks fine if only that test is applied; but the two page extents
   overlap at 16k and ld.so refuses to map it.  Confirmed on a 16k-page 
kernel:
   reverting librtmp1 to this trixie build makes every libcurl-linked 32-bit
   binary fail to start again, with the message above naming librtmp.so.1.

So the corrected summary for the closure I surveyed (DT_NEEDED closure of
libcurl4t64 + libgdk-pixbuf-2.0-0 + libssl3t64 + libc6 in trixie/armhf, 48
libraries) is four failing libraries, not three: libpsl.so.5, libz.so.1,
libgmp.so.10 and librtmp.so.1.

Additional request, in the same form as the others:

nmu rtmpdump_2.4+20151223.gitfa8646d.1-2 . armhf . trixie . -m "Rebuild 
for 64k section alignment on 32-bit ARM (#1089822): binaries built 
before binutils 2.43.50.20241215-1 cannot be loaded on kernels with 
pages larger than 4k"

armel is not affected for rtmpdump.

Outside the surveyed closure I also see liblerc4 4.0.0+ds-5 (source: lerc,
built 2024-11-05) failing condition (2); it reaches libtiff6 users.  Since
condition (2) can fail on its own, any wider sweep of stale armhf/armel
binaries should test both conditions rather than congruence alone.

Verification from the archive, without 16k-page hardware:

   wget 
https://deb.debian.org/debian/pool/main/r/rtmpdump/librtmp1_2.4+20151223.gitfa8646d.1-2+b5_armhf.deb
   dpkg-deb -x librtmp1_*.deb x
   readelf -lW x/usr/lib/arm-linux-gnueabihf/librtmp.so.1 | grep LOAD
   # LOAD 0 ends at 0x12d14 -> rounds up to 0x14000 at 16k pages
   # LOAD 1 starts at 0x13a18 -> rounds down to 0x10000: the two overlap

Apologies for the incomplete initial analysis.
--
Nenad