Dear Maintainer,

   * What led up to the situation?

I observed the failure for this package to buildd with powerpc architecture.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Attempted to sbuild it locally and saw the same result.

   * What was the outcome of this action?

The package does not build successfully on this platform due to a segmentation fault in 'libcapsotest'.
A debug session with gdb shows that the segmentation fault occurs when it attempts to call 'printf'.
gdb shows the 'printf' symbol to be NULL.

   * What outcome did you expect instead?

A successful package build including running the test suite.
It works on ppc64 and ppc64el.

Control: retitle -1 libcap2: FTBFS due to test suite failure on mips64el, powerpc

While the failure on powerpc is not release-critical, a similar
failure can be seen on mips64el, which is a release arch.

https://buildd.debian.org/status/fetch.php?pkg=libcap2&arch=mips64el&ver=1%3A2.66-5%2Bb1&stamp=1730219325&raw=0

Here's my gdb session

$ gdb ./libcap/libcap.so
GNU gdb (Debian 15.2-1) 15.2
<...snipped for brevity...>
Reading symbols from ./libcap/libcap.so...
(gdb) b 42
Breakpoint 1 at 0xaa70: file execable.c, line 42.
(gdb) r
Starting program: libcap2-2.66/libcap/libcap.so

Breakpoint 1, __execable_main (argc=1, argv=0x421310) at execable.c:42
42          if (argv != NULL && argv[0] != NULL) {
(gdb) info symbol printf
No symbol "printf" in current context.
(gdb) info symbol strcmp
strcmp in section .text of /lib/ld.so.1

Surely these symbols should be coming from the .text section of
libcap.so itself?

The first test for mips64el appears to succeed so I wonder if it is
crashing instead on one of the the strcmp()
calls in SO_MAIN.

Hi,

thank you both for the report and the analysis so far. I managed to
reproduce this on a porter box.

Sadly, I haven't found the underlying issue yet, nor do I know why this
would appear (only) on powerpc and mips64el.

My gut says it's a toolchain issue, as the current version 1:2.66-5
previously built on these architectures (though logs are no longer
accessible, the binaries are there). And if it were some more general
issue with a toolchain update, we'd see broader failures.

I've just uploaded a new version 2.73. This did not fix the issue for
me, but being up to date might help down the road.

Best,
Christian

Control: clone -1 -2
Control: severity -2 normal

I still haven't found the root cause.

Since this test is about functionality (executable shared library) that
is currently not enabled anyway, I'm going to skip the offending test to
close the FTBFS and allow libcap2 to migrate to testing.

I'll track the bug in a cloned report, though with reduced severity.

Best,
Christian