3.38.0-4 in the archive
build failed,
ours is 3.38.0-4+py315.2.
Nothing recorded is waiting on this one.
aborted,
3.38.0-4+py315.2,
as work request 1346268,
which ended in work request 1346270.
Which turned out to be build-failed: the workflow ended: build-failed, work request 1346270.
Sent before this one:
3.38.0-4+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 |
| was the interpreter under test installed? |
no
its chroot had a different Python installed instead, so its failure is about whatever that one is: these take their interpreter from the default rather than from pybuild python3.14_3.14.7-4 |
the build log's installed set | 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 |
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 |
| 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 #1143328 FTBFS: module 'pkgutil' has no attribute 'get_loader' |
the BTS usertag | not dated |
| Version | Arch | Kind | Result | Binaries | Interpreters | Closure | Finished |
|---|---|---|---|---|---|---|---|
3.38.0-4+py315.2
|
all | build | fail | unknown | not read yet | — | 2026-09-25 00:18 |
3.38.0-4+py315.1
|
all | build | fail | unknown | not read yet | — | 2026-08-25 22:35 |