Re: [Buildroot] [PATCH 1/1] support/testing: transfer config in environment instead of class variables

From: Peter Korsgaard <peter@korsgaard.com>
To: Fiona Klute <fiona.klute@gmx.de>
Cc: buildroot@buildroot.org,
	 Ricardo Martincoski <ricardo.martincoski@datacom.com.br>,
	 Julien Olivain <ju.o@free.fr>,
	Jimmy Durand Wesolowski <jimmy.wesolowski@mobileye.com>,
	guenther.harrasser@mobileye.com
Subject: Re: [Buildroot] [PATCH 1/1] support/testing: transfer config in environment instead of class variables
Date: Sun, 01 Mar 2026 11:10:13 +0100	[thread overview]
Message-ID: <87pl5noo6y.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <d5069f4c-565b-4111-8f11-67f31281f3f4@gmx.de> (Fiona Klute's message of "Sat, 28 Feb 2026 23:30:45 +0100")

>>>>> "Fiona" == Fiona Klute <fiona.klute@gmx.de> writes:

Hi,

 >> What we could also do is to only add the workaround for python >=
 >> 3.14.x
 >> (which is not yet in Debian), E.G.
 >> if sys.version_info >= (3,14):
 >> multiprocessing.set_start_method('fork')

 > That would fix the immediate issue, yes. If Debian updates to 3.14
 > before Nose is fixed we'll be back where we started, and I think it'd
 > be good not to rely on a specific start method in general. But I
 > suppose the version check would be a reasonable compromise for the
 > stable branches. :-)

Indeed. I started by reporting the issue to Debian so the package
(hopefully) does not transition to stable:

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

Another hacky workaround would be to monkey patch set_start_method() to
ignore the call from nose2, E.G.:

if multiprocessing.get_start_method() != 'fork':
   multiprocessing.set_start_method('fork')
   multiprocessing.set_start_method = = lambda *args: None

Which may be better than the python version check.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot