[Debian-med-packaging] Uncoordinated google-perftools transition

[Cyril Brulebois]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20120528/5fffdd95/attachment.pgp>