Bug#749560: transition: miniupnpc

[Thomas Goirand <zigo@debian.org>]

Hi Emilio,

Thanks a lot for your help and the advices. I hope to learn and know
well how to manage transitions after this one (as I did a poor job with
them before). :)

On 06/10/2014 02:13 AM, Emilio Pozuelo Monfort wrote:
>>> In the meantime, please upload to experimental so that it goes through NEW.
>>
>> This was done.
> 
> Good. I see there are build failures on kfreebsd.

After I pinged upstream it was fixed in the last version, which I just
uploaded.

>> Though there's FTBFS issues seemingly related to the new version of
>> miniupnpc with these:
>>
>> - 0ad: see [1] below
>> - megaglest: see [2] below
>> - warzone2100: see [3] below
> 
> Open bugs with severity important. Bonus points if you provide patches (that
> will greatly help get this transition started (and finished)).

Bugs open with patches (with help from upstream of MiniUPnPc):

0ad: #751224
megaglest: #751225
warzone2100: #751229

I have checked the build with newer MiniUPnP client, and no issues as
far as I can tell.

>> And then these seem to have unrelated FTBFS in Sid:
>>
>> - eiskaltdcpp: FTBFS (in eiskaltdcpp-qt/src/ChatEdit.cpp which doesn't
>> have UPNP stuff)
>> - litecoin: FTBFS (but package not in Testing anyway)
> 
> Try to reproduce in a clean sid environment and report bugs with severity serious.

I have no time to do that right now, will try to do so later on.

> Open those bugs and make them block this one. If you provide patches, at least
> for the ones caused by miniupnpc, we could start the transition and then ask for
> the patches to be applied, NMU-ing if that doesn't happen.

What's the reasonable amount of time after which we can NMU (to the
delayed queue?) for such a transition?

Cheers,

Thomas Goirand (zigo)