Your message dated Thu, 30 Apr 2026 12:52:15 +0200
with message-id <afM0XyMVTvl9ObvT@nuc>
and subject line Re: Bug#1108051: numba: FTBFS: The keyword argument 
'parallel=True' was specified but no transformation for parallel execution was 
possible.
has caused the Debian Bug report #1108051,
regarding numba: FTBFS: The keyword argument 'parallel=True' was specified but 
no transformation for parallel execution was possible.
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.)


-- 
1108051: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1108051
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: src:numba
Version: 0.61.2+dfsg-1
Severity: important
Tags: ftbfs trixie sid help

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:

[ please read the notes at the end ]

--------------------------------------------------------------------------------
[...]
======================================================================
FAIL: test_random_concurrent_vectorize_tbb 
(numba.tests.test_parallel_backend.TestSpecificBackend.test_random_concurrent_vectorize_tbb)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"/<<PKGBUILDDIR>>/.pybuild/cpython3_3.13_numba/build/numba/tests/test_parallel_backend.py",
 line 397, in test_template
    o, e = self.run_test_in_separate_process(injected_method, backend)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File 
"/<<PKGBUILDDIR>>/.pybuild/cpython3_3.13_numba/build/numba/tests/test_parallel_backend.py",
 line 375, in run_test_in_separate_process
    return self.run_cmd(cmdline, env_copy)
           ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File 
"/<<PKGBUILDDIR>>/.pybuild/cpython3_3.13_numba/build/numba/tests/test_parallel_backend.py",
 line 363, in run_cmd
    raise AssertionError(
        "process failed with code %s: stderr follows\n%s\n" %
        (popen.returncode, err.decode()))
AssertionError: process failed with code -9: stderr follows
.
----------------------------------------------------------------------
Ran 1 test in 5.803s

OK



----------------------------------------------------------------------
Ran 2103 tests in 1990.694s

FAILED (failures=1, skipped=101, expected failures=7)
E: pybuild pybuild:389: test: plugin custom failed with: exit code=1: ls 
/<<PKGBUILDDIR>>/.pybuild/cpython3_3.13_numba/build && cd 
/<<PKGBUILDDIR>>/.pybuild/cpython3_3.13_numba/build && MPLBACKEND=Agg 
python3.13 -Wd runtests.py --exclude-tags='long-running,gdb,compiled_caching' 
-v -m --random 0.2 -- numba.tests
dh_auto_test: error: pybuild --test -i python{version} -p 3.13 returned exit 
code 13
make[1]: *** [debian/rules:21: override_dh_auto_test-arch] Error 25
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:14: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
--------------------------------------------------------------------------------

The above is just how the build ends and not necessarily the most relevant part.
If required, the full build log is available here:

https://people.debian.org/~sanvila/build-logs/202506/

About the archive rebuild: The build was made on virtual machines from AWS,
using sbuild and a reduced chroot with only build-essential packages.

In this particular case, the build was made on AWS machines of type
m7a.medium and r7a.medium. Incidentally, those machines have a single CPU,
but at this point it's not clear yet if that's the condition which triggers
the build failure or, for example, the fact that they are overall slower
than other instance types, or maybe some other reason.

If you could not reproduce the bug using GRUB_CMDLINE_LINUX="nr_cpus=1"
please contact me privately, as I am willing to provide ssh access to a
virtual machine where the bug is fully reproducible.

Disclaimer: Please note that this is probably a violation of
Debian Policy 4.2, and the only reason I'm initially reporting
it as "important" is to avoid discussing about the severity.

If this is really a bug in one of the build-depends, please use
reassign and add an affects on src:numba, so that this is still
visible in the BTS web page for this package.

Note: In some similar cases the only reasonable fix is
to "import os" and skipif(os.cpu_count() == 1) the affected test.

Thanks.

--- End Message ---
--- Begin Message ---
Version: 0.63.1+dfsg-3

Closing by hand because I made a mistake in the bug number in d/changelog
(I've just fixed this in salsa so that at least d/changelog is correct
in the future). Thanks.

--- End Message ---
-- 
debian-science-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Reply via email to