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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
