Bug#679041: transition: wireshark
2012/6/27 Adam D. Barratt <firstname.lastname@example.org>:
> tag 679041 + pending
> On Tue, 2012-06-26 at 19:16 +0200, Bálint Réczey wrote:
>> 2012/6/26 Mehdi Dogguy <email@example.com>:
>> > On 26/06/2012 00:10, Bálint Réczey wrote:
>> >> I'd like to upload the latest version of wireshark to unstable.
>> >> Updating from 1.6.8 to 1.8.0 brings a new ABI with a new soname for
>> >> all the libs. Having Wireshark 1.8.x in Wheezy is important because
>> >> upstream's support for 1.6.x ends on June 7, 2013  and Wireshark
>> >> needs regular security updates.
>> > Thanks for letting us know. Unfortunately, we think that this update
>> > came a tad late because we are >that< near to freeze and the update
>> > seems quite large.
>> This is why i don't want to risk backporting security fixes from 1.8.x to 1.6.x.
> I have to admit to not being happy with the size of the diff at this
> late stage, but it seems the lesser of the available evils. The 1.8
> package was accepted from NEW a short while ago by our friendly
The Wireshark project uses pretty advanced techniques for ensuring
code quality including three different static code analyzers,
building for platforms
and fuzz testing every build.
There are still security issues found in the code base time to time,
but with more than
2 million lines of C code it would be hard to avoid those completely.
All in all I'm convinced that having 1.8.x in Wheezy in the right decision.
> Can we schedule binNMUs for netexpect, or does it require any source
Eloy will upload the new netexpect package soon.
>> Note that 1.8.0~rc1-1 has been uploaded to the NEW queue weeks ago... 
> In that case, I'm not entirely sure why the transition bug wasn't raised
> "weeks ago"... nor what the logic is behind not having uploaded the
> release version already, given that the upstream schedule claims it was
> released a week ago.
In the past we managed the "transition" ourselves by quickly updating
netexpect after wireshark.
Since netexpect does not have too many users yet and netexpect is the
depending on wireshark it seemed to be a better solution over
involving the release team.
Should we always open a transition bug?