1.2.0-1 in the archive
build failed,
ours is 1.2.0-1+py315.1.
Nothing recorded is waiting on this one.
aborted,
1.2.0-1+py315.1,
as work request 1210570,
which ended in work request 1210582.
Which turned out to be build-failed: the build failed: work request 1210582.
| 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 |
| 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 |
| do Debian's own tests pass? |
archive tests fail
Debian's own tests for this package fail in unstable, so this failure is not the new interpreter's doing. debci answers about the source rather than about the version we rebuilt, which is why the date its run happened is shown. arm64, last run 2026-08-21 |
ci.debian.net | not dated |
| does the release team track this? |
dependency level 7
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 |
| Version | Arch | Kind | Result | Binaries | Interpreters | Closure | Finished |
|---|---|---|---|---|---|---|---|
1.2.0-1
|
amd64 | test | fail | archive | 3.14, 3.15 | — | 2026-09-01 09:31 |
1.2.0-1+py315.1
|
all | build | fail | unknown | not read yet | — | 2026-09-01 13:00 |