Bug#841661: release.debian.org: grass not migrating to testing
On Sat, 2016-10-22 at 13:12 +0200, Sebastiaan Couwenberg wrote:
> Removing grass from the problematic architectures where actual users of
> grass are unlikely since almost everyone is using amd64 is the road of
> least resistance to not block testing migration of grass. Which britney
> unhelpfully hadn't performed despite it being a valid candidate.
It would be appreciated if you would please stop framing this as "my
packages are fine, why isn't britney doing as she's told?". It's really
unhelpful, particularly when the issue is explicitly the result of the
removals from "problematic architectures" (well, one of them).
(Also, for avoidance of doubt, "valid candidate" purely means that the
package doesn't have RC bugs, has spent enough days in unstable since
upload, etc. It doesn't mean "can immediately migrate without issue",
and expecting that to necessarily be the case will lead to
disappointment.)
For the record, the logs are public, and analysing this situation is
quite simple:
[britney log]
trying: grass
skipped: grass (119, 0, 24)
got: 81+0: a-3:i-23:a-0:a-1:a-0:m-0:m-17:m-0:p-36:p-0:s-1
* i386: grass, libgdal-grass, libgdal20-2.1.1-grass, libqgis-dev, qgis-plugin-grass
[check why]
zcat /srv/mirrors/debian/dists/unstable/main/binary-i386/Packages.gz | grep-dctrl -S grass | dose-debcheck --explain --failures --checkonly grass
report:
-
package: grass
version: 7.0.5-2
architecture: all
essential: false
source: grass (= 7.0.5-2)
status: broken
reasons:
-
missing:
pkg:
package: grass
version: 7.0.5-2
architecture: all
essential: false
unsat-dependency: grass-core
The "grass" binary package is architecture-independent. britney
therefore expects it to be installable on i386 and am64. With the
removal of the architecture-specific packages on i386, that is no longer
the case.
Allowing the package to migrate in that circumstance requires using the
biggest hammer britney has (the "force-hint") which says "ignore any and
all installability issues that this migration might create". That's
something I'm not personally prepared to do in this case, but other team
members may have different opinions.
Regards,
Adamj
Reply to: