On 14/09/14 15:26, Emilio Pozuelo Monfort wrote: > On 13/09/14 20:46, Robert Edmonds wrote: >> Emilio Pozuelo Monfort wrote: >>> On 03/09/14 05:27, Robert Edmonds wrote: >>>> node-mapnik >>>> ----------- >>>> >>>> This package Build-Depends against mapnik-vector-tile, which ships a >>>> .pb.h file in /usr/include (a bad upstream practice). >>>> mapnik-vector-tile needs to be binNMU'd first before node-mapnik can >>>> be binNMU'd. >>> >>> mapnik-vector-tile is arch:all, so I can't binNMU it. >> >> OK, I will open a bug and upload an NMU to DELAYED. >> >> I see on the NmuDep wiki page: >> >> Unless you have an excellent reason not to do so, you must then give >> some time to the maintainer to react (for example, by uploading to >> the DELAYED queue). Here are some delays that you could use as >> default values: >> >> * Upload fixing only release-critical bugs older than 7 days: 2 days >> * Upload fixing only release-critical and important bugs: 5 days >> * Other NMUs: 10 days >> >> Those delays are only examples. In some cases (uploads fixing >> security issues, trivial bugfixes blocking a transition, ...), it is >> desirable that the fixed package reaches unstable sooner. >> >> I would guess that blocking a transition would count as at least >> "important" severity, and an NMU with no actual changes would count as a >> "trivial bugfix blocking a transition". Would DELAYED/3 be appropriate? > > Yes, I think DELAYED/2 or 3 would be appropriate.
The delay ended but the signature seems invalid: 20140919160333|process-upload|dak|mapnik-vector-tile_0.5.1+dfsg-1.1_multi.changes|Error while loading changes: No valid signature found. (GPG exited with status code 512) Can you re-upload with a good signature (and without a delay of course). You may need to dcut the previous upload first. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org