Re: [PATCH 3/3] bitbake: Update to 2.8.1 release

["'MOESSBAUER, Felix' via isar-users" <isar-users@googlegroups.com>]

On Fri, 2026-03-06 at 11:10 +0100, Zhihang Wei wrote:
> On 3/4/26 14:31, 'Felix Moessbauer' via isar-users wrote:
> > Upstream commit 1c9ec1ffde75809de34c10d3ec2b40d84d258cb4.
> > 
> > This makes bitbake compatible with Python 3.14 and fixes a critical
> > error on Debian Trixie hosts where no stacktrace was shown on a
> > parser exception.
> > 
> > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> > ---

[shortening the thread]

> > 
> >   
> > +# Recomputing the sets in signal.py is expensive (bitbake -pP idle)
> > +# so try and use _signal directly to avoid it
> > +valid_signals = signal.valid_signals()
> Hi,
> 
> I tested this patch set on CI with the patch "bitbake: Downgrade python 
> requirements" re-applied.
> 
> However, errors still occur. The function "valid_signals()" here was 
> added to the signal module in Python 3.8, but Buster only has 3.7.3. Not 
> sure how many other similar problems we might encounter, as the test 
> fails at this point. Zhihang

Too bad. So either we have to drop buster support or we have to
maintain our own bitbake stable branch or we must re-implement the
imaging plugins to not run inside the chroot. The eLTS of buster lives
until 30. Juni 2029 [1], so I also don't like the idea of dropping
buster support.

However, we can't hold the fixes we need for trixie back that long. We
already got complains that simple bitbake syntax errors are basically
impossible to debug on trixie as the parser just crashes without any
indication what went wrong. So we have to make a decision.

PS: The only fix we really need is [2]. Maybe we can just cherry-pick
that prior to the isar release to buy us some time.

[1] https://wiki.debian.org/de/LTS/Extended
[2]
https://github.com/openembedded/bitbake/commit/c25e7ed128b9fd5b53d28d678238e2f3af52ef8b

Felix

> > +try:
> > +    import _signal
> > +    sigmask = _signal.pthread_sigmask
> > +except ImportError:
> > +    sigmask = signal.pthread_sigmask
> > +
> >   # If we don't have a timeout of some kind and a process/thread exits badly (for example
> >   # OOM killed) and held a lock, we'd just hang in the lock futex forever. It is better
> >   # we exit at some point than hang. 5 minutes with no progress means we're probably deadlocked.
> > +# This function can still deadlock python since it can't signal the other threads to exit
> > +# (signals are handled in the main thread) and even os._exit() will wait on non-daemon threads
> > +# to exit.
> >   @contextmanager


-- 
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/7950524b9019758caf739148e1a51e65c9340f98.camel%40siemens.com.