py-asterisk REMOVED from testing

[Faidon Liambotis]

Luk Claes wrote:
>> Unfortunately, asterisk in lenny was FTBFSing because of missing or
>> changed dependencies so I couldn't make an upload to testing-security,
>> even though the version is exactly the same as of etch.
> 
> It was FTBFSing because of a removed build dependency which apparantly 
> was fixed in unstable but not in testing...
There were other issues too, regarding zaptel; different libtonezone-dev
for example.

>> Asterisk is quite hard to get to testing because of the vast amount of
>> build-deps. Right now, it's blocked by net-snmp, perl, krb5 and gtk-2.0.
> 
> That means you should try to get a stable version into testing and keep 
> that maintained for library transitions while you prepare and stabilise 
> a next candidate for stable (new upstream and/or less important changes) 
> in experimental and coordinate with maintainers of these build-deps on 
> when it's a good time to upload it to unstable... IMHO
Remember, we're not having issues with RC bugs of asterisk; if anything,
many bugs are *closed* with each version.
Upstream has freezed new features for the 1.4 series and are focusing on
1.5/1.6 and we don't have ground-breaking changes with new versions.
These are being carefully examined and packaged because they solve bugs
(1.4.13.1 fixed a few memory corruption bugs and some deadlock bugs,
1.4.13 and 1.4.12 fixed security bugs).

And coordinating *at the same time* with the maintainers of net-snmp,
perl, krb5 and gtk-2.0 is impossible, IMHO.
BTW, I'm subscribed to d-d-a and d-release. Noone informed anyone about
these transitions -- net-snmp even broke the build-dep in a way that
wasn't easily spotted (pbuilder worked while sbuild failed) and didn't
say anything. But I'm sure you know about these things.

>> If you think there are some other pending issues, please say so and I
>> will handle them personally.
> 
> The issue now is that people cannot install asterisk in testing and 
> people who already have it installed have a vulnerable version... though 
> I'm confident you'll try to fix that ;-)
You're right and I feel bad about it.
And for those people, I can only suggest to add *stable* security to
their sources.list to get a non-vulnerable version, unfortunately.

Everyone is breaking stuff in unstable uncoordinated at a rate that it's
hard to get complicated packages to migrate, though I'm confident you
know that and you're trying to fix it ;-)

Thanks,
Faidon