0.1.1-3 in the archive
build failed,
ours is 0.1.1-3+py315.2.
Nothing recorded is waiting on this one.
aborted,
0.1.1-3+py315.2,
as work request 1346621,
which ended in work request 1346623.
Which turned out to be build-failed: the workflow ended: build-failed, work request 1346623.
Sent before this one:
0.1.1-3+py315.1.
A version that was sent is spent, whatever came of it.
| Question | Answer | Said by | As of |
|---|---|---|---|
| Why did the build fail? |
superseded-dependency
Built against our own rebuild of a dependency, one generation back. The run is evidence, unlike an archive copy: re-run it against the current suite before reading the failure. python3-psutil 7.1.0-1.1+py315.2: we publish 7.2.2-1+py315.1 |
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 |
| 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 #1144305 pigx-rnaseq: FTBFS: ERROR: could not find report for SALMON at transcript level |
the BTS usertag | not dated |
| Version | Arch | Kind | Result | Binaries | Interpreters | Closure | Finished |
|---|---|---|---|---|---|---|---|
0.1.1-3+py315.2
|
all | build | fail | unknown | not read yet | — | 2026-09-25 01:52 |
0.1.1-3+py315.1
|
all | build | fail | unknown | not read yet | — | 2026-09-17 10:49 |