Bug#760343: transition: protobuf 2.6.0
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
Reply to: