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: Sat, 28 Feb 2026 20:50:54 +0100	[thread overview]
Message-ID: <871pi4prz5.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <20260227192112.3792145-1-fiona.klute@gmx.de> (Fiona Klute's message of "Fri, 27 Feb 2026 20:21:12 +0100")

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

 > With Python 3.14 the default process start method in the
 > multiprocessing module for POSIX platfroms changed from "fork" to
 > "forkserver". Unlike with "fork" the new process does not inherit
 > loaded modules, classes, etc., instead it has to load any it
 > needs. This means that class variables modified in the parent process
 > are lost, which breaks the way support/testing/run-tests sets
 > configuration in BRConfigTest.

 > Instead add a method to serialize the configuration into an
 > environment variable, and read it during
 > BRConfigTest.__init__(). Reading is skipped if the environment
 > variable is not set so test discovery (not execution) works without
 > configuration (e.g. utils/get-developers uses this).

 > The (de-)serialization could be simpler using a dedicated
 > @dataclasses.dataclass class, but the dataclasses module was added
 > with Python 3.7, while support/dependencies/check-host-python3.mk
 > specifies 3.4 as the minimum for Buildroot.

 > Remove the "fork" method override added in
 > 3d2141bceefda32bef06ddda594eaf8665913276. This fixes a crash that
 > occured in combination with an incorrect [1] patch added to the Debian
 > python3-nose2 package with version 0.15.1-2 [2] because setting the
 > default multiprocessing start method twice is an error.

Looking at https://wiki.debian.org/Python, python 3.7+ was included
since Debian 10 (released July 2019, EOL September 2022), so I do think
that we can start relying on 3.7 for new releases, but for 2026.02 (and
2025.02.x) why not just change run-tests to do:

# set_start_method() may only be called once
if multiprocessing.get_start_method() != 'fork:
   multiprocessing.set_start_method('fork')

Wouldn't that work?

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