Hi, I noticed you have started a transition on the google-perftools side, which can be seen through the excuses[1]: | google-perftools (1.7-1 to 2.0-2) | | Maintainer: Daigo Moriwaki | 58 days old (needed 10 days) | out of date on i386: libgoogle-perftools0, libgoogle-perftools0-dbg, libtcmalloc-minimal0, libtcmalloc-minimal0-dbg (from 1.7-1) | out of date on amd64: libgoogle-perftools0, libgoogle-perftools0-dbg, libtcmalloc-minimal0, libtcmalloc-minimal0-dbg (from 1.7-1) | Not considered
1. http://release.debian.org/britney/update_excuses.html#google-perftools Getting rid of those old binaries would make your package a candidate for testing migration. Unfortunately, decrufting it (which we usually coordinate with ftpmasters) would lead to broken packages: | # Broken Depends: | google-perftools: google-perftools | gpsshogi: gpsshogi [amd64 i386] | mira: mira-assembler [amd64 i386] | | # Broken Build-Depends: | mira: libtcmalloc-minimal0 I'm adding the relevant maintainers to the Cc list accordingly. We usually schedule binNMUs for packages in such a state, hoping they successfully build and run. For a planned transition, you would be the one having checked that before uploading google-perftools to unstable. ;) [BTW, #673527 looks good, but should have been made serious by now, just fixed that through control@; but I also filed #674822] As first glance, mira can't be rebuilt anyway, because of its crazy build-dep on libtcmalloc-minimal0… which I'll file a bug about in a moment. For next transitions, the relevant documentation can be found at: https://wiki.debian.org/Teams/ReleaseTeam/Transitions Mraw, KiBi.
signature.asc
Description: Digital signature
