Bug#1099085: apparmor: FTBFS on riscv64: subprocess.TimeoutExpired

[Bo YU]

Package: apparmor
Version: 4.1.0~beta5-2
Severity: serious
Tags: ftbfs patch
User: debian-***@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-***@lists.debian.org

Dear Maintainer,

Now apparmor has one FTBFS issue on riscv64 due to timeout on test case:

```
...
ERROR: test_allow_all (__main__.TestLogprof.test_allow_all)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/build/reproducible-path/apparmor-4.1.0~beta5/utils.python3.13/test/test-logprof.py",
line 129, in test_allow_all
self.process.wait(timeout=0.3)
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
File "/usr/lib/python3.13/subprocess.py", line 1276, in wait
return self._wait(timeout=timeout)
~~~~~~~~~~^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.13/subprocess.py", line 2060, in _wait
raise TimeoutExpired(self.args, timeout)
subprocess.TimeoutExpired: Command '['/usr/bin/python3.13', '../aa-logprof', '--allow-all', '--configdir', './', '-f', './logprof/ping.auditlog', '-d', '/tmp/aa-test-aj9tsnoi/profiles', '--no-check-mountpoint', '--output-dir', '/tmp/aa-test-aj9tsnoi']' timed out after 0.3 seconds
...

```

Full log please to see here:
https://buildd.debian.org/status/fetch.php?pkg=apparmor&arch=riscv64&ver=4.1.0%7Ebeta5-2&stamp=1740485392&raw=0

The fixing is very easy and it works on my local Unmatched board, but I
am not sure if it's appropriate to send this patch given there is one
beta hint on uploading. Unfortunately, it was failed to build again
during python3.13, this may block something. So could you have a look at
this? Please let me know if any issues.

[intrigeri]

Hi,

Post by Bo YU
The fixing is very easy and it works on my local Unmatched board, but I
am not sure if it's appropriate to send this patch given there is one
beta hint on uploading.

The affected version is the one I want to see in Trixie, so yeah,
a patch to fix this is useful and greatly appreciated, thanks!

I'll upload with this patch applied later this week.

Do you want to submit your patch upstream
(https://gitlab.com/apparmor/apparmor/) or should I?

Post by Bo YU
Unfortunately, it was failed to build again during python3.13, this
may block something.

I'm afraid I did not understand this sentence. Could you please rephrase?

Cheers,

[Bo YU]

Hi Christian and intrigeri,

Hello,

Post by intrigeri
Do you want to submit your patch upstream
(https://gitlab.com/apparmor/apparmor/) or should I?

In general, I should forward the patch to upstream. But here I am
not
sure if this makes sense or not because this is just increasing the
timeout on special architecture. [...]

If possible, I'd rather not carry this as a Debian-only patch for too
long, so please consider submitting this patch upstream, else I'll
do it.

Yes, please submit it upstream.
I'd even drop the "if risc64" condition and increase the timeout for all
architectures.
In case you wonder: the timeout is basically meant as a safety net to
avoid a "hangs forever" case (but not for performance checks).
The initial timeouts were based on "works for me/on my laptop", and
we've since increased the timeout for several tests in test-logprof.py
so that it has enough time to finish on all architectures.
So if another test needs an increased timeout, no problem ;-)

Thanks for the hint, now I have the confidence to submit the patch to
the upstream[0], let's wait for feedback from the upstream.

[0]: https://gitlab.com/apparmor/apparmor/-/merge_requests/1567

BR,
Bo