0.0.2-1.2 in the archive, ships a compiled extension
built,
ours is 0.0.2-1.3+py315.2,
waiting on scipy.
ahead of the archive (built from a source sid does not have)
Nothing recorded is waiting on this one.
published,
0.0.2-1.2+py315.2,
as work request 1208673.
Sent before this one:
0.0.2-1.2+py315.1.
A version that was sent is spent, whatever came of it.
| Question | Answer | Said by | As of |
|---|---|---|---|
| Why did the build fail? |
unknown
The log was read and says nothing this tool recognises. These are the failures somebody has to look at. |
deps/11 | not dated |
| Which known interpreter change does this failure show? |
module-not-importable
a dependency was not importable. Nothing here says the interpreter caused this. An import that failed usually means the testbed was assembled before the dependency had been rebuilt, which is ours to fix by running it again. ModuleNotFoundError: No module named 'distutils' could not import distutils |
deps/11 | not dated |
| does the archive build this version? |
archive ftbfs
Debian's own rebuild of the version the archive carries fails too, so this failure is not the new interpreter's doing. It still blocks the transition: nobody can rebuild it until that is fixed. amd64 arm64 |
tests.reproducible-builds.org | not dated |
| does Debian's own test suite pass? |
not tested by debian
Debian runs no autopkgtest for this, so we have no independent baseline: nothing here distinguishes a failure this interpreter caused from one the package always had |
ci.debian.net | not dated |
| does the release team track this? |
dependency level 5
The release team's own tracker lists it, and their dependency level is how the transition is sequenced: a level cannot be read as done while anything below it is outstanding. Their question is what a package's binaries depend on, not what it ships, so their verdict and ours can disagree without either being wrong. amd64 unknown, arm64 unknown, armhf unknown, i386 unknown, loong64 unknown, ppc64el unknown, riscv64 unknown, s390x unknown not in testing, so sid only |
release.debian.org, from their ben tracker | 2026-09-16 04:49 UTC |
| has anybody reported this under the usertag? |
1 bug
somebody has already reported this under the round's usertag, so it is tracked; the tag is the only record connecting what was sent to what this tracks #1067335 gnucap-python: FTBFS: _gnucap_swig.cxx:4535:10: fatal error: numpy/arrayobject.h: No such file or directory |
the BTS usertag | not dated |
| Version | Arch | Kind | Result | Binaries | Interpreters | Closure | Finished |
|---|---|---|---|---|---|---|---|
0.0.2-1.3+py315.2
|
arm64 | test | pass | rebuilt | named none | — | 2026-09-09 12:30 |
0.0.2-1.3+py315.2
|
amd64 | test | pass | rebuilt | named none | — | 2026-09-09 12:28 |
0.0.2-1.3+py315.2
|
arm64 | build | pass | unknown | not read yet | — | 2026-09-09 12:29 |
0.0.2-1.3+py315.2
|
amd64 | build | pass | unknown | not read yet | — | 2026-09-09 12:27 |
0.0.2-1.2+py315.2
|
arm64 | build | fail | unknown | not read yet | — | 2026-09-01 08:46 |
0.0.2-1.2+py315.2
|
amd64 | build | fail | unknown | not read yet | — | 2026-09-01 08:52 |
0.0.2-1.2
|
arm64 | test | fail | the archive's (reference arm) | named none | — | 2026-08-17 15:31 |
0.0.2-1.2
|
amd64 | test | fail | the archive's (reference arm) | named none | — | 2026-08-17 15:31 |
0.0.2-1.2+py315.1
|
amd64 | build | fail | unknown | not read yet | — | 2026-08-17 15:52 |