Bug#1051649: libportal: FTBFS on riscv64 due to test timeout

2023-09-15 Thread Aurelien Jarno
Hi,

On 2023-09-15 13:31, Simon McVittie wrote:
> Control: tags 1051649 + pending
> 
> On Mon, 11 Sep 2023 at 00:17:31 +0200, Aurelien Jarno wrote:
> > libportal fails to build from source on riscv64 (and a few other slow
> > architectures) with a timeout in a test
> ...
> > After investigation, it appeared the test actually passes, but needs
> > 85 seconds instead of the 60 seconds it got allocated. The
> > following patch uses the --timeout-multiplier feature of meson to
> > increase the timeout.
> 
> Thanks, I'll upload a similar fix after the current version has migrated
> to testing (it's only 1 day off, so it would seem a shame to reset the
> clock for this). I increased the timeout by a factor of 3 rather than 2,
> to give some margin of error.

Thanks!

> However, I'm concerned that this implies riscv64 might be our new slowest
> release architecture, even slower than mips64el, which is going to put
> it at risk of delaying migrations, security fixes and other release
> stuff (as a result of builds taking a long time, arbitrary timeouts in
> build-time tests becoming insufficient, or race conditions in build-time
> tests being hit when they wouldn't have been seen on faster buildds).

It depends how you count. While the build time for a single package
takes longer than some mips64el buildds, we plan to use more buildds. We
currently have 7 buildds, and 2 more are waiting to be installed. This
should ensure that build queues do not fill up, at least once the whole
set of packages has been rebuilt.

> Do you expect faster riscv64 buildds to become available by the time
> trixie is the stable release, or is what we have now what we are going
> to continue to have?

We do have a set of faster buildds available for a few months already,
using the VisionFive 2 boards. They are around 80% faster than the
current HiFive Unmatched based buildds for building packages, and
libportal's testsuite passes on them without changing the timeout
factor.  Unfortunately they lack kernel support in mainline, so they
can't be used and thus are just stored in a box. With the kernel
6.6-rc1, we are down to 19 missing patches to support these boards, we
expect full support will arrive in linux 6.7 or 6.8.

We also hope that the Milk-V Pioneer board (already released) and HiFive
Pro P550 board (planned) will enable us to get way faster riscv64
buildds, but it is still uncertain until they get mainline support, they
get tested in a configuration similar to the buildds and that we are
sure that we can host them in a datacenter.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net



Bug#1051649: libportal: FTBFS on riscv64 due to test timeout

2023-09-15 Thread Simon McVittie
Control: tags 1051649 + pending

On Mon, 11 Sep 2023 at 00:17:31 +0200, Aurelien Jarno wrote:
> libportal fails to build from source on riscv64 (and a few other slow
> architectures) with a timeout in a test
...
> After investigation, it appeared the test actually passes, but needs
> 85 seconds instead of the 60 seconds it got allocated. The
> following patch uses the --timeout-multiplier feature of meson to
> increase the timeout.

Thanks, I'll upload a similar fix after the current version has migrated
to testing (it's only 1 day off, so it would seem a shame to reset the
clock for this). I increased the timeout by a factor of 3 rather than 2,
to give some margin of error.

However, I'm concerned that this implies riscv64 might be our new slowest
release architecture, even slower than mips64el, which is going to put
it at risk of delaying migrations, security fixes and other release
stuff (as a result of builds taking a long time, arbitrary timeouts in
build-time tests becoming insufficient, or race conditions in build-time
tests being hit when they wouldn't have been seen on faster buildds).

Do you expect faster riscv64 buildds to become available by the time
trixie is the stable release, or is what we have now what we are going
to continue to have?

This might also resolve #1051702, but obviously I haven't tested on
hppa hardware to find out how long this test actually takes there,
so I'm not marking that one as pending.

smcv



Bug#1051649: libportal: FTBFS on riscv64 due to test timeout

2023-09-10 Thread Aurelien Jarno
Source: libportal
Version: 0.7.1-1
Severity: important
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear maintainer,

libportal fails to build from source on riscv64 (and a few other slow
architectures) with a timeout in a test:

|  2/2 =
| test: pytest
| start time:   16:03:45
| duration: 60.05s
| result:   killed by signal 15 SIGTERM
| command:  MALLOC_PERTURB_=44 
LD_LIBRARY_PATH=/<>/obj-riscv64-linux-gnu/libportal 
GI_TYPELIB_PATH=/<>/obj-riscv64-linux-gnu/libportal 
/usr/bin/pytest-3 --verbose --log-level=DEBUG
| --- stdout ---
| = test session starts 
==
| platform linux -- Python 3.11.5, pytest-7.4.1, pluggy-1.3.0 -- 
/usr/bin/python3
| cachedir: .pytest_cache
| rootdir: /<>/tests
| collecting ... collected 30 items
| 
| pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_close_session 
PASSED [  3%]
| pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_connect_to_eis 
PASSED [  6%]
| 
pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_connect_to_eis_fail_connect_before_start
 PASSED [ 10%]
| 
pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_connect_to_eis_fail_reconnect
 PASSED [ 13%]
| pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_connect_to_eis_v1 
PASSED [ 16%]
| pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_create_session 
PASSED [ 20%]
| 
pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_create_session_no_outputs
 PASSED [ 23%]
| pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_notify_axis 
PASSED [ 26%]
| 
pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_notify_axis_discrete
 PASSED [ 30%]
| pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_notify_button 
PASSED [ 33%]
| pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_notify_key PASSED 
[ 36%]
| pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_notify_motion 
PASSED [ 40%]
| 
pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_notify_motion_absolute
 PASSED [ 43%]
| pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_notify_touch 
PASSED [ 46%]
| pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_session_start 
PASSED [ 50%]
| pyportaltest/test_remotedesktop.py::TestRemoteDesktop::test_version PASSED [ 
53%]
| pyportaltest/test_screencast.py::TestScreenCast::test_close_session PASSED [ 
56%]
| pyportaltest/test_screencast.py::TestScreenCast::test_create_session PASSED [ 
60%]
| pyportaltest/test_screencast.py::TestScreenCast::test_create_session_v3
| ==
| 
| 
| Summary of Failures:
| 
| 2/2 pytest   TIMEOUT60.05s   killed by signal 15 SIGTERM
| 
| Ok: 1
| Expected Fail:  0
| Fail:   0
| Unexpected Pass:0
| Skipped:0
| Timeout:1
| dh_auto_test: error: cd obj-riscv64-linux-gnu && 
DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test 
returned exit code 1
| make[1]: *** [debian/rules:60: override_dh_auto_test] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:51: binary-arch] Error 2
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=libportal&arch=riscv64&ver=0.7.1-1&stamp=1694361910&raw=0

After investigation, it appeared the test actually passes, but needs
85 seconds instead of the 60 seconds it got allocated. The
following patch uses the --timeout-multiplier feature of meson to
increase the timeout. I didn't try to use a different multiplier
depending on the architecture as it has no impact on working tests
anyway.

--- libportal-0.7.1/debian/rules
+++ libportal-0.7.1/debian/rules
@@ -57,4 +57,4 @@
$(NULL)
 
 override_dh_auto_test:
-   xvfb-run -a dh_auto_test
+   xvfb-run -a dh_auto_test -- --timeout-multiplier 2


Regards
Aurelien