On Fri, Apr 12, 2019 at 10:23 PM Guy Harris wrote:
>
> Is Python 3 installed on the machine on which the test is being run?
>
>
It is. All the test suite is python3 based and it's working. That's why I
expected the extcap to work.
It looks like the extcap is not the only test script using
On Apr 12, 2019, at 1:22 PM, Roland Knall wrote:
> There seems to be an issue on mac, depending how the original Wireshark
> binary has been called. It seems to be, that by clicking on the icon, the
> system python interpreter get's loaded, which most certainly will let your
> script fail.
There seems to be an issue on mac, depending how the original Wireshark
binary has been called. It seems to be, that by clicking on the icon, the
system python interpreter get's loaded, which most certainly will let your
script fail. If you call Wireshark from a console context (by either
On Apr 12, 2019, at 1:14 PM, Dario Lombardo wrote:
> In commit c442ee056bc46bcda59e473c00d5741ea90a1453 I've introduced a test
> extcap (actually written by Peter) to test the correct parsing of extcap
> sentences. This extcap is python3 based.
...
> ... However I expected it to work
On Fri, Apr 12, 2019 at 10:14 PM Dario Lombardo wrote:
>
> https://travis-ci.org/crondaemon/wireshark/jobs/519284280
>
>
> This build actually comes from a tentative patch. A failing build on
master is at the following link.
https://travis-ci.org/crondaemon/wireshark/jobs/519168819
Hi
In commit c442ee056bc46bcda59e473c00d5741ea90a1453 I've introduced a test
extcap (actually written by Peter) to test the correct parsing of extcap
sentences. This extcap is python3 based.
Due to some limitations on script extcaps on windows
6) Remediating the known documentation issues in Bugzilla:
https://bugs.wireshark.org/bugzilla/buglist.cgi?component=Documentation_id=55638=Wireshark=---
Moshe
On Fri, Apr 12, 2019 at 9:32 AM Moshe Kaplan wrote:
> Some specific ideas from what I've noticed (mostly in the User Guide):
>
> 1)
Some specific ideas from what I've noticed (mostly in the User Guide):
1) There are 35 menu items that aren't documented in the User Guide. These
are indicated in the docs as " Not yet written. See
https://wiki.wireshark.org/Development/SubmittingPatches;
2) The User Guide references the Wiki
minor correction, it should not read "sullify" but pacify. It has been a
long week
Am Fr., 12. Apr. 2019 um 15:01 Uhr schrieb Roland Knall :
> Just my two cents, I like a clear indication, that I am working with a
> development version beyond the obvious changes of text. SO the versioning
>
Just my two cents, I like a clear indication, that I am working with a
development version beyond the obvious changes of text. SO the versioning
is usually the first thing I look at.
That being said, I could imagine adopting the Python versioning scheme as
an alternative to the current even/odd
On Thu, Apr 11, 2019 at 7:55 PM Gerald Combs wrote:
> We currently have three active release branches: 3.0, 2.6, and 2.4. This
> is because we support each release branch for a set amount of time
> (typically 24 months after the initial .0 release) and our last three .0
> releases were less than
On Fri, 12 Apr 2019 at 00:55, Gerald Combs wrote:
> We currently have three active release branches: 3.0, 2.6, and 2.4. This
> is because we support each release branch for a set amount of time
> (typically 24 months after the initial .0 release) and our last three .0
> releases were less than
I agree that even/odd is non-standard and confusing.
> I’m not sure. How would we label the development branch? It’s currently
3.1.0 or is it 3.1.0rc0? (Version 3.1.0 (v3.1.0rc0-521-gdba02458)) would
people understand?
> But I’m ok either way.
I think the Python developer guide
From: Wireshark-dev On Behalf Of
graham.shanks via Wireshark-dev
Sent: den 12 april 2019 09:04
To: Developer support list for Wireshark
Cc: graham.shanks
Subject: Re: [Wireshark-dev] Release lifetime and version number changes?
>I think dropping the even/odd scheme is a good idea.
I think dropping the even/odd scheme is a good idea.Personally I'd go down to
2 active branches but then my group wouldn't be adversely affected by dropping
the "old old stable" version since we invariably use the stable version. More
weight should be given to the opinions of people who do
15 matches
Mail list logo
