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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
