On 21/02/2026 19:07, Samuel Thibault wrote:
There are also
haskell-lambdahack_0.11.0.1-2
haskell-http-semantics_0.3.0-1
Time is hard to find at the moment, but I've had a look at the above and
they also have corruptions to the shared libraries in a similar pattern
to the other haskell packages. ie. at offsets 0x50, 0x70 and 0xff0
within a page sized region of the file.
On 21/02/2026 23:26, Samuel Thibault wrote:
Mike Kelly, le sam. 21 févr. 2026 09:23:12 +0000, a ecrit:
1) Certain compilations refer to the contents of a header file that when parsed
find corrupt contents. This presents as compilation failure with error reports
like:
/usr/include/i386-gnu/bits/types/clock_t.h:1:3: error: stray ‘\2’ in program
This has previously been seen in qtcreator, sysprof and others. I found some
errors like this from build logs as far back as 2024 so it's not a recent
development. I've witnessed this on 1 occasion on my personal machine whilst
compiling gnumach.
It's not only headers, I also notice it on perl files:
I searched the logs associated with the builds that use Perl and the
errors are split into 2 forms:
1) The 4 packages below all show errors similar to:
dpkg-source: error: source package format '3.0 (quilt)' is not
supported: Unrecognized character \x02; marked by <-- HERE after ^@^@<--
HERE near column 3 at /usr/share/perl/5.40/File/Compare.pm line 1.
Compilation failed in require at /usr/share/perl5/Dpkg/Source/Patch.pm
line 40.
ismrmrd_1.15.0-1_hurd-amd64-2026-02-21T23:06:18Z
mothur_1.48.5-2_hurd-amd64-2026-02-11T06:22:31Z
ruby-sqlite3_2.9.0-1_hurd-amd64-2026-02-11T07:35:16Z
rust-glib_0.21.5-2_hurd-amd64-2026-02-11T07:31:12Z
This error looks as if similar to the C header corruption.
2) The remaining packages from the Perl list report an inability to load
Unicode::Normalize loadable object:
Can't locate loadable object for module Unicode::Normalize in @INC (@INC
contains: /usr/share/texi2any/lib/U\
nicode-EastAsianWidth/lib /usr/lib/texi2any /usr/share/texi2any
/usr/share/texi2any /etc/perl /usr/local/lib\
/i386-gnu/perl/5.40.1 /usr/local/share/perl/5.40.1
/usr/lib/i386-gnu/perl5/5.40 /usr/share/perl5 /usr/lib/i3\
86-gnu/perl-base /usr/lib/i386-gnu/perl/5.40 /usr/share/perl/5.40
/usr/local/lib/site_perl .) at /usr/share/\
texi2any/Texinfo/Indices.pm line 45
This error is reported for builds:
assimp_6.0.4+ds-1+b1_hurd-i386-2026-02-09T20:30:53Z
assimp_6.0.4+ds-1+b1_hurd-i386-2026-02-10T14:34:22Z
binutils-embedded_28_hurd-i386-2026-02-12T02:28:03Z
gcc-riscv64-unknown-elf_23_hurd-i386-2026-02-12T03:02:37Z
ginac_1.8.10-1_hurd-i386-2026-02-12T01:24:18Z
octave-tablicious_0.4.5-3_hurd-i386-2026-02-12T02:37:40Z
I can't make much sense of this report. I vandalized Normalize.so to
verify that attempting to load a broken shared library results in a
different error report. It seems therefore that the build genuinely
cannot find Normalize.so but that should be installed with
libperl5.40_5.40.1-7 which is reported installed by the log.
The double signal fix is included in libc0.3 (2.42-12). That helped the main
haskell compiler (ghc) package build but hasn't helped with issue 2. Does issue
1 also still occur in builds made with the latest glibc?
I haven't seen any issue in headers since then, but I have seen issues
on perl files.
Note that I have only seen issue 2 on amd64.
The problems are seen on the buildd machines more frequently than on mine. This
might be down to relatively poor performance of my machine or some subtle
difference in the machine or software configuration.
I will have a more modern machine available from the weekend with a hope
that its use will recreate these problems in my local sbuilds.
Mike.
