Re: [Buildroot] [PATCH] support/testing/run-tests: unbreak on Debian testing/unstable

Peter Korsgaard
2026-03-02T12:21:29Z

>>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:

> Commit 3d2141bcee("support/testing/run-tests: specify multiprocessing
> method") added a call to multiprocessing.set_start_method('fork') as a
> workaround for python 3.14, which changed the default start method to
> forkserver - Which is incompatible with the nose2 setup.

> multiprocessing.set_start_method() is only supposed to be called a maximum
> of 1 time per process and throws a RuntimeError if called more than that
> (even with the same arguments):

>>>> import multiprocessing
>>>> multiprocessing.set_start_method('fork')
>>>> multiprocessing.set_start_method('fork')
> Traceback (most recent call last):
> File "<python-input-2>", line 1, in <module>
> multiprocessing.set_start_method('fork')
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^
> File "/usr/lib/python3.13/multiprocessing/context.py", line 247, in set_start_method
> raise RuntimeError('context has already been set')

> Debian included a similar patch in python3-nose2 0.51.1-2 (currently in
> testing/unstable) which adds its own call to set_start_method():

> https://salsa.debian.org/python-team/packages/nose2/-/blob/debian/0.15.1-2/debian/patches/0004-plugins-mp-set-context-to-fork-for-Python-3.14-mp-AP.patch?ref_type=tags

> Which comes from:
> https://github.com/nose-devs/nose2/pull/644

> As discussed in the upstream PR, this is not a correct fix is wrong and
> breaks various use cases. An issue has been opened to get this fixed in the
> Debian packaging at:

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1129350

> But until that is done, rework the patch to:

> - Only override set_start_method() if needed to limit impact
> - Monkey patch set_start_method() so additional calls are ignored

> To unbreak run-test on affected Debian systems and add some documentation to
> make it clear why this is done.

> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

Committed after changing the logic to use the optional allow_none /
force arguments as pointed out by Julien, thanks.

--
Bye, Peter Korsgaard