Your message dated Fri, 25 Sep 2026 15:20:57 +0200
with message-id <[email protected]>
and subject line Re: mypy: FTBFS on riscv64 due to timeout
has caused the Debian Bug report #1147413,
regarding mypy: FTBFS on riscv64 due to timeout
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1147413: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1147413
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: mypy
Version: 2.3.1-1
Severity: important
Tags: ftbfs patch
X-Debbugs-Cc: [email protected]
User: [email protected]
Usertags: riscv64
Dear Maintainer,
mypy in unstable and experimential both has ftbfs issue on riscv64, see
https://buildd.debian.org/status/fetch.php?pkg=mypy&arch=riscv64&ver=2.2.0-4&stamp=1788888404&raw=0
https://buildd.debian.org/status/fetch.php?pkg=mypy&arch=riscv64&ver=2.3.1-1&stamp=1788942084&raw=0
Increasing the value of WORKER_START_TIMEOUT to 30 can fix the below
timeout issue:
```
Traceback (most recent call last):
File "<frozen runpy>", line 203, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "/build/reproducible-path/mypy-2.3.1/mypy/__main__.py", line 52, in
<module>
console_entry()
File "/build/reproducible-path/mypy-2.3.1/mypy/__main__.py", line 16, in
console_entry
main()
~~~~^^
File "/build/reproducible-path/mypy-2.3.1/mypy/main.py", line 154, in main
res, messages, blockers = run_build(sources, options, fscache, t0, stdout,
stderr)
~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/build/reproducible-path/mypy-2.3.1/mypy/main.py", line 244, in
run_build
res = build.build(sources, options, None, flush_errors, fscache, stdout,
stderr)
File "/build/reproducible-path/mypy-2.3.1/mypy/build.py", line 422, in build
result = build_inner(
sources,
...<9 lines>...
metastore,
)
File "/build/reproducible-path/mypy-2.3.1/mypy/build.py", line 537, in
build_inner
graph = dispatch(sources, manager, stdout, connect_threads)
File "/build/reproducible-path/mypy-2.3.1/mypy/build.py", line 4145, in
dispatch
raise OSError(f"Cannot connect to build worker(s): {',
'.join(not_connected)}")
OSError: Cannot connect to build worker(s): 0, 1, 2, 3
```
But then the test suite will fail at
```
...
== Return code: 2 (diff)
Alignment of first line difference:
E: a.py:2: note: Revealed type is "str"
A: Traceback (most recent call last):
^
Update the test output using --update-data (implies -n0; you can additionally
use the -k selector to update only specific tests)
=========================== short test summary info ============================
FAILED
mypy/test/testcmdline.py::PythonCmdlineSuite::cmdline.test::testShadowFileWithNativeParserParallel
==== 1 failed, 14179 passed, 362 skipped, 12 xfailed in 7272.53s (2:01:12) =====
```
Running the full test suite with pytest -n8, parallel workers contend on a
shared
filelock while mypyc compiles the librt C extension during tests. On a loaded
riscv64 sbuild the C build takes >5 min, so a waiting worker hits
filelock.Timeout
and the build fails.
I have tested it on milk-v jupiter. Please let me know any issues.
--
Regards,
--
Bo YU
diff -Nru mypy-2.3.1/debian/changelog mypy-2.3.1/debian/changelog
--- mypy-2.3.1/debian/changelog 2026-08-31 11:33:52.000000000 +0000
+++ mypy-2.3.1/debian/changelog 2026-09-11 13:48:32.000000000 +0000
@@ -1,3 +1,10 @@
+mypy (2.3.1-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS on riscv64 due to timeout. (Closes: #-1)
+
+ -- Bo YU <[email protected]> Fri, 11 Sep 2026 13:48:32 +0000
+
mypy (2.3.1-1) experimental; urgency=medium
* New upstream version
diff -Nru mypy-2.3.1/debian/patches/series mypy-2.3.1/debian/patches/series
--- mypy-2.3.1/debian/patches/series 2026-08-31 11:33:05.000000000 +0000
+++ mypy-2.3.1/debian/patches/series 2026-09-11 07:51:43.000000000 +0000
@@ -2,3 +2,4 @@
hint-typeshed-package
verbose
intersphinx
+timeout-riscv64
diff -Nru mypy-2.3.1/debian/patches/timeout-riscv64
mypy-2.3.1/debian/patches/timeout-riscv64
--- mypy-2.3.1/debian/patches/timeout-riscv64 1970-01-01 00:00:00.000000000
+0000
+++ mypy-2.3.1/debian/patches/timeout-riscv64 2026-09-11 07:56:29.000000000
+0000
@@ -0,0 +1,28 @@
+Description: fix FTBFS issue on riscv64 due to timeout
+Author: Bo YU <[email protected]>
+Forwarded: not-needed
+Last-Update: 2026-09-11
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/mypy/defaults.py
++++ b/mypy/defaults.py
+@@ -50,7 +50,7 @@
+ # It looks like Windows is slow with processes, causing test flakiness even
+ # with our generous timeouts, so we set them higher.
+ WORKER_START_INTERVAL: Final = 0.01 if sys.platform != "win32" else 0.03
+-WORKER_START_TIMEOUT: Final = 3 if sys.platform != "win32" else 10
++WORKER_START_TIMEOUT: Final = 30 if sys.platform != "win32" else 10
+ WORKER_SHUTDOWN_TIMEOUT: Final = 1 if sys.platform != "win32" else 3
+
+ WORKER_CONNECTION_TIMEOUT: Final = 10
+--- a/mypyc/test/librt_cache.py
++++ b/mypyc/test/librt_cache.py
+@@ -164,7 +164,7 @@
+
+ binary_suffix = ".pyd" if sys.platform == "win32" else ".so"
+
+- with filelock.FileLock(lock_file, timeout=300): # 5 min timeout
++ with filelock.FileLock(lock_file, timeout=1200): # 20 min timeout
+ # Reuse the cache only if the build completed *and* the compiled
+ # binaries still exist. A repo-wide clean of .so/.pyd files can delete
+ # the cached binaries while leaving the marker behind.
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Version: 2.3.1-3
Fixed via patch sent upstream https://github.com/python/mypy/pull/21988
I wish I had seen your bug report sooner; it took a lot of debugging time on
the riscv64 porterbox to arrive at the same fix:
https://github.com/python/mypy/issues/21969
OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---
