The austinp tool (not austin itself) only ever produces invalid frame
captures on s390x. This is not a regression in Debian, because the
previous upload of austin did not include austinp. This is an upstream
issue and I've sent all that I know upstream. This Debian bug merely
duplicates the report to the Debian side and informs s390x porters of
the problem.

Helmut

Hi Helmut,

In the github issue it was mentioned that this is also failing on `armhf`.
Can you please confirm whether these were the same issues?
Meanwhile I am also checking the code. I will update you if I find something.

Thanks,
Pranav

Hi Pranav,

The scope of the issue was expanded upstream. Initially it looked as if
it were only affecting s390x. armhf and armel were affected by
https://github.com/P403n1x87/austin/issues/268 and 32bit architectures
generally were broken by https://github.com/P403n1x87/austin/pull/266.
Now that these have patches, we see that the scope of this issue is
wider and it also affects e.g. riscv64. At this time the austinp testing
has been restricted to amd64 arm64 ppc64el, which likely are the most
relevant architectures for profiling Python code. Consider all other
architectures as potentially affected.

Please consider how much time you want to spend on this issue. There are
multiple Python profilers available of which the only non-modifying one
packaged for Debian is austin. The most relevent architectures are
covered. Unlike austinp, austin cannot look into C stack frames, but it
seems to work on all architectures now. I argue that what is left is a
pretty niche use case.

How about removing the s390 usertag as it is now known to be more
generic? If you agree, please just remove it.

Helmut