Hi,

During a rebuild of all packages in sid, your package failed to build
on armhf.


Relevant part (hopefully):
The full build log is available from:
http://qa-logs.debian.net/2024/04/20/parsinsert_1.04-15_unstable-armhf.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240420;users=lucas@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20240420&fusertaguser=lucas@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Control: tags -1 + confirmed

Hi,

parsinsert is making a lot of assumptions on certain compiler
optimisation behaviors, which have evolved in time.  This has
caused an increasing number of ftbfs bugs affecting a range of
CPU architectures, for which the resolution consisted in
dropping optimization levels, e.g. #964082.

I could reproduce the present bug on armhf.  This architecture
was already built with -O1 optimisation, so I attempted a drop
to -O0 which resolved the segmentation fault, but caused other
computation errors anyway.  parsinsert has not seen any newer
upstream version for about twelve years, so I think we don't
have much options but lookup on which CPU architectures build is
broken, request for removal on such targets, then reduce the bug
severity, and move on.

At least the package still seems to operate properly on amd64,
so we can still get away without a removal of the package.

Have a nice day,  :)

Some further results on parsinsert: after rebuilding on all
release architectures, it turned out the other affected platform
was armel, in addition to armhf.  This suggests possibly a
regression introduced by time_t migration to 64-bit size.  Or
this could be something else I have no clue of yet.

The other architectures: amd64, arm64, i386, mips64el, ppc64el,
s390x, and risv64, built all fine and would not require removal.

Hope this helps,

Étienne Mollier, on 2024-06-28:

I opened #1074598 to request removal of parsinsert from armel
and armhf.  Once this is done, the severity of the bug can be
reduced, and in case someone comes up with a proper fix in the
future, the issue can be closed and the package may be
reintroduced for those architectures.

Control: severity -1 normal

I reduce the severity of the bug, as parsinsert has been removed
from armel and armhf platforms.

Have a nice day,  :)