On 8 mrt 2011, at 16:53, Jeff Morriss wrote:
> Sake Blok wrote:
>> On 8 mrt 2011, at 15:55, Jeff Morriss wrote:
>>> This issue is tracked in https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5445 . There, Guy suggested:
>>>
>>>> The trick might be to have multiple types of taps, such as ones that produce no
>>>> output, and are allowed to be unconditionally run, and ones that produce
>>>> output, which are not allowed to be unconditionally run. Dissection will be
>>>> forced on in TShark if one of the latter type of taps is listening, but will
>>>> not be forced on if only the former type of taps is listening.
>>> That sounds similar to (2) above.
>> It does indeed. I checked the bug report. As long as it's kept open until there is a solution, we can skip the discussion here :-)
>
> Well, except that no progress has been made--discussion out here might change that. :-)
True!
>> In the mean time, should we disable these protocols by default until it has been sorted out? It's a shame to have the buildbots unavailable because of this.
>
> Except that having the buildbots red might eventually annoy someone enough to fix the underlying problem ;-). (More seriously: I think test.sh is the last step so they're only missing the other tests in the test suites. Or is something else being missed/lost?)
True again. I thought it also has an effect on the automated builds, but I see that the windows bots have a whole different issue...
@Gerald, what's with the win-bots?
Sake