[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Migration of emboss and embassy-* to testing?



Hi,

Apologies for the delay in getting back to you about this.

On Thu, 2012-07-05 at 08:55 +0200, Andreas Tille wrote:
> On Thu, Jul 05, 2012 at 07:33:13AM +0100, Adam D. Barratt wrote:
[...]
> > leading: emboss,embassy-domainatrix,embassy-domalign,embassy-domsearch
>> start: 30+0: i-4:a-0:a-0:a-5:i-0:k-6:k-6:m-0:m-0:p-0:s-1:s-6:s-2
>> orig: 30+0: i-4:a-0:a-0:a-5:i-0:k-6:k-6:m-0:m-0:p-0:s-1:s-6:s-2
>> easy: 31+0: i-4:a-1:a-0:a-5:i-0:k-6:k-6:m-0:m-0:p-0:s-1:s-6:s-2
> >     * amd64: embassy-phylip
> > 
> > FAILED
> 
> I admit I can not make any sense out of the numbers you are mentioning
> above but the reason embassy-phylip becomes obvious.

They're the number of uninstallable packages per architecture; the key
difference is the change from "a-0" to "a-1" indicating the newly
installable (if the hint had succeeded) package on amd64.

> Thanks for the
> explanation.  Would you consider to put a freeze exception on
> embassy-phylip (option 1 of my previous mail which is probably welcome
> to all Debian Med team members) or would you prefer falling back to
> those other options I have mentioned (and these probably need discussion
> in Debian Med team first).

Dropping the most obvious build noise from the diff together with what
could charitably be claimed as "documentation fixes" leaves a reasonably
small set of changes.  Given that the package is in non-free, I've
unblocked it and hoped nothing breaks; if it does, we might then lean
towards removal rather than another unblock.

Regards,

Adam


Reply to: