[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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
  package: grass
  version: 7.0.5-2
  architecture: all
  essential: false
  source: grass (= 7.0.5-2)
  status: broken
      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.



Reply to: