Bug#733343: reconserver FTBFS on all architectures

[Daniel Pocock]

On 29/12/13 01:41, Ivo De Decker wrote:
> Control: reassign -1 reconserver 0.9.1-1
>
> Hi Daniel,
>
> On Sat, Dec 28, 2013 at 11:31:18PM +0100, Daniel Pocock wrote:
>> reassign 733343 librecon-1.9-dev 1.9.0~beta8-1
>> fixed 733343 1.9.0~beta8-2
>> stop
>>
>> reconserver is not really at fault here, I believe librecon-1.9-dev
>> should depend on the related libresiprocate-1.9-dev and so the bug is
>> being reassigned there, fix is being uploaded.
> Not really. The new resiprocate upload just gets you to the next error:
> https://buildd.debian.org/status/fetch.php?pkg=reconserver&arch=i386&ver=0.9.1-1&stamp=1388277038

That was also an error with reSIProcate dev package dependencies

>
> I added a block hint to make sure this version of reconserver can't migrate to
> testing (even if this bug gets reassigned). Please let me know when the issues
> has been dealt with for real, and I will remove the block hint.

All the issues in reSIProcate have been fixed and the reConServer
package is now building fine


>> What is the best way to force another attempt at building reconserver
>> after the new librecon-1.9-dev is available in unstable?
> In normal circumstances (when the new upload of a build-dep would fix the
> issue for real), you could do a new upload with a versioned build-dependency
> on the new library you uploaded, or you could ask
> debian-wb-team at lists.debian.org for a rebuild (in this case, with added
> 'dep-wait' on the new lib). I happened to notice this bug by chance (because
> aba mentioned it on irc), but normally, you should explicitly ask for
> rebuilds on the mailing list.

I want to avoid a versioned build dependency because it is quite
possible for somebody to build a local version of the reconserver
package with an older resiprocate library, they just have to install the
build dependencies manually