Anders Broman | 1 Jun 01:01 2009
Picon

Re: [Wireshark-commits] rev 28551: /trunk/gtk//trunk/gtk/: rtp_analysis.c

Hi,
>My apologies for not indicating what I decided to do to save you some 
>editing.   :)
No worries, I got frustrated with the windows because of other stuff I'm
trying to do.
Regards
Anders

-----Ursprungligt meddelande-----
Från: wireshark-dev-bounces@...
[mailto:wireshark-dev-bounces@...] För Bill Meier
Skickat: den 31 maj 2009 22:45
Till: wireshark-dev@...
Ämne: Re: [Wireshark-dev] [Wireshark-commits] rev 28551:
/trunk/gtk//trunk/gtk/: rtp_analysis.c

etxrab@... wrote:
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=28551
> 
> User: etxrab
> Date: 2009/05/31 12:55 PM
> 
> Log:
>  Copy the changes from:
>  http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=28534
>  
>  User: wmeier
>  Date: 2009/05/30 11:07 AM
>  
>  Log:
(Continue reading)

Stig Bjørlykke | 1 Jun 02:06 2009

Re: Extending wireshark with Python

I just gave it a quick try on a protocol registering to "udp.port".

The first problem occurred in an assert in splash_update, proposed
patch attached.

Now I get this error when opening a capture with my protocol (based on
the skeleton from the wiki page):

01:40:41          Warn Dissector bug, protocol MyProtocol, in packet
17: tvbuff.c:600: failed assertion "tvb && tvb->initialized"
Bus error

Some different questions:
- Do we need two different places to put plugins and python plugins?
What if we could reuse the plugins directory for both compiled plugins
and python scripts?  (and maybe even for auto loading lua scripts?)
- Do you plan making it possible to have python scripts in a personal directory?

--

-- 
Stig Bjørlykke
Attachment (python-about_dlg.patch): application/octet-stream, 822 bytes
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
Luis EG Ontanon | 1 Jun 03:01 2009

Re: Extending wireshark with Python

I made the Lua bindings an application of the C API, not a simple
export. (e.g. proto_item and proto_tree are combined instead of dealt
individually, objects are managed in their scope so that deleted
objects are not accessed by Lua).

The reasons why I avoided just mapping the C API were many but all
focused on a single point: to make sure that a bug in lua code was
hanlded by lua's handler, not by a crash.

That meant mainly:

To deal with the destruction of objects in a way that is "transparent"
to the Lua program.
objects like TVBs that go out of scope would have a destructor
invoked, and if a TVB used by libwireshark got destroyed by the lua
program you would have a crash, same thing would happen if you
preserved a pointer to an object that libwireshark had destroyed and
you attempted to use it again (e.g. a tvb from the previous frame).

To avoid signals THROWn from libwireshark popping the frames in the Lua stack.
 This is an issue that caused me serious pain, if an exception got
thrown from the API function lua's signal stack got corrupted.

Another drive was simplyfing some wireshark concepts to make coding in
lua leaner, if it will take me the same number of lines to write code
in lua than it takes me to write it in C why not just write it in C.

My choice of Lua was both for simplicity (easier to embed, because at
the time there wasn't accessible docs on embeding python) and speed
(lua is way faster than perl or python).
(Continue reading)

Leonardo | 1 Jun 10:34 2009
Picon

Re: Linking wireshark.exe --- Error

Hi Guy,
 
perfect!!!
 
you have resolve my problem!!!!!
 
you are awesome!
 
For a simple "&" the linker crashed.
 
i could think that "&"  was a   special character for the script!!!!!
 
However,  thanks,thanks,thanks a lot!!!!!!

2009/5/31 Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>

On May 31, 2009, at 12:14 PM, Anders Broman wrote:

> It may be a problem with your path, cygwin link chosen before MS
> studio.

I doubt it's getting the wrong version of "link"; it appears to be
running Microsoft's "link":

>         link <at> C:\DOCUME~1\leo&mik\IMPOST~1\Temp\nm116.tmp
> Microsoft (R) Incremental Linker Version 9.00.30729.01
> Copyright (C) Microsoft Corporation.  All rights reserved.
> LINK : fatal error LNK1104: impossibile aprire il file 'C:
> \DOCUME~1\leo'
> Impossibile trovare il percorso specificato.

However, if Leonardo's "home directory" (or whatever it's called in
Windowsland) is really C:\Documents and Settings\leo&mik or something
with an "&" in it, some program might be treating the "&" as a token
separator and looking for C:\DOCUME~1\leo rather than C:
\DOCUME~1\leo&mik.

This appears to be a bit of a botch in Microsoft's nmake, as I think
" <at> <<" is sort of like a "here document" in UN*X shells, i.e.

        <at> <<
blah blah blah
<<

means it copies the text between the " <at> <<" and the "<<" into a file,
and passes the name of the file as an argument; perhaps it needs to
quote the file name?
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A@public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A@public.gmane.org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
Sébastien Tandel | 1 Jun 15:31 2009
Picon

Re: Extending wireshark with Python

Hi Luis,



I'm happy to see you're enthusiast! :)


On Sun, May 31, 2009 at 22:01, Luis EG Ontanon <luis-Ag8lxUO3V95AfugRpC6u6w@public.gmane.org> wrote:
I made the Lua bindings an application of the C API, not a simple
export. (e.g. proto_item and proto_tree are combined instead of dealt
individually, objects are managed in their scope so that deleted
objects are not accessed by Lua).

As a rule of thumb, I'm trying to follow the C API but the main idea is of course to simplify whenever possible and write less code.
That's why I'm not against following some parts of the LUA API. My main goal is to ease development for others people.


The reasons why I avoided just mapping the C API were many but all
focused on a single point: to make sure that a bug in lua code was
hanlded by lua's handler, not by a crash.
For sure, that's something I have to work on :)
Maybe I did not insist sufficiently on it but it's the *first step* to have a python binding with wireshark. There are a lot of things to do , features to add,  bugs to fix, etc...

Another drive was simplyfing some wireshark concepts to make coding in
lua leaner, if it will take me the same number of lines to write code
in lua than it takes me to write it in C why not just write it in C.
That's something I want to avoid too. And it's already rather concise, maybe not as concise as LUA is right now? maybe.


I had no python experience at the time and I had heard many good
things of it... Having dealt way too much (for my taste) with python
latelly now IMHO the only think which python does better than perl is
well indented code (the thing cannot even help you find a typo in the
name of a variable, closures are cumbersome, global variable usage is
painful at very least... as for java I do not understand why so many
people like it).

OK, perl lover ... I was working with perl some years ago and I'm really happy to be able to avoid its use today!
BUT my point is that if there were a binding in perl, it would be a good thing for wireshark because there are a lot of people using it. I just won't do it myself. In the same way, I do think that python is a good thing for wireshark too. At the end of the day, just a few people knows LUA. Even being in Brazil, country of origin of LUA, working for one of the largest brazilian IT company, people knows LUA because it's brazilian but nobody can (or want to) develop with it.
After all, having a binding is not only for me or for other core people. Having a binding is to ease wirehark extension development for the rest of the community (mainly sysadmin and net guys). If we use an unknown language, like let's say D, it is of little interest because just an elite knows it. (and probably this elite won't even take a look at wireshark). I know that at the company I'm working in, sysadmin and net guys are using a way lot more python than perl, do not even think they could one day extend wireshark in C and as I already said LUA is just known by its name because of its origin. Therefore, what would you choose?


Regards,
Sebastien Tandel
 
On Sun, May 31, 2009 at 10:41 PM, Sébastien Tandel <sebastien-V68y5HPEe52zQB+pC5nmwQ@public.gmane.org> wrote:
> Hi Stig,
>
> First, I have to admit that I'm not really aware of the details of the
> defined LUA API. But as a rule of thumb, I tried to be close as possible to
> what exists in the C API (not LUA).
> Here is an informal description of what rules I tried to follow to create
> this API :
> 1) create objects as close as possible to the ones known in libwireshark
> There are three "obvious" objects until now : Dissector, Tree, TVB.
> 2) method name of each object as close as possible as the ones defined in
> libwireshark. I however modify the name because as C is not object, most of
> the time, a function includes in its name the conceptual "object" name
> related to it. This way, it avoids redundance in python API. For example :
> "proto_tree_add_item" is one method of the "tree" object in the C API. in
> the python API, the Tree class defines a "add_item" method. With the same
> idea for "tvb_get_ntohl", the method is defined in the TVB class with the
> name "get_ntohl".
> 3) formal parameters of functions :
>   a) first parameter is in general the "C object" and it does not make any
> sense to include it for the method defined in a python object. (in fact, in
> python it appears in the definition and "disappears" when called)
>   b) it might happen that some other parameters are always defined in the
> formal parameters of the C API but are not manipulated by the user and might
> be included automatically by the python API. For these ones, they also
> disappear from the formal parameters list of the python API.
>   c) if the parameter takes most of the time one value but sometimes can
> take another value, it is defined as an optional parameter.
>   d) if the parameter is totally or partially managed by the python API, it
> is defined as an optional parameter.
>   a good example is Tree.add_item(self, field, offset=0, length=-1,
> little_endian=False, adv=True)
>   the C API counterpart is : proto_tree_add_item(proto_tree, hfindex, tvb,
> start, length, little_endian)
>     - As of rule a), proto_tree is in fact the Tree object => disappear from
> the formal parameter list
>     - As of rule b), tvb is not directly manipulated by the user and
> therefore disappear from the formal parameter list
>     - As of rule c), little_endian has two possible value False or True. It
> becomes an optional parameter with the default value set to False.
>     - As of rule d), "offset" is totally managed by the API with the help of
> the last *added* parameter which indicates whether offset should be
> incremented or not. This last parameter is itself an optional parameter with
> a value of True ("offset" is incremented by "length"). Though, offset is
> totally managed by the python API, it is possible to increment manually the
> offset.
>
> There is already two notable exceptions to what I described here above.
> There exists two others objects (register_info and Subtrees). It is likely
> that in the future this list of objects will increase because they've
> initially have been created because of a "ctypes" (python module)
> limitation.
> At the end, they almost serve only as a special dictionary of elements.
> For these objects, I used a so interesting feature of python, definition of
> dynamic attributes.You have a first step in which you add items in this
> "dictionary" (hf_register_info fields and trees). When you have to refer to
> one of these while dissecting, you can refer to them as if they were
> attributes of the related object.
> For example, let's say "hf" is a register_info object, you can add something
> to it by doing :
>   hf.add("Imaginary Protocol Length", "imaginary.length", FT_UINT8)   => Not
> that you have a lot of optional parameters in here!
> and you can refer to this field while dissecting with
>   hf.imaginary_length
> the name of the attribute is the second parameter passed with every '.'
> changed to '_'
>
>
> That's all for now .. I'll add this mail to the wiki documentation.
> Of course, I'll enjoy any comments (from you or anyone else) to improve the
> python API whatever it be following the LUA API or not. :)
>
>
> Regards,
> Sebastien Tandel
>
> 2009/5/31 Stig Bjørlykke <stig.bjorlykke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>
>> Hi,
>>
>> Do you use the same naming scheme in the Python bindings as we use in
>> Lua?
>> I think we should have the same names for equal functionality in both
>> Python and Lua.
>>
>>
>> --
>> Stig Bjørlykke
>>
>>
>>
>> ___________________________________________________________________________
>> Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A@public.gmane.org>
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A@public.gmane.org?subject=unsubscribe
>>
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A@public.gmane.org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A@public.gmane.org?subject=unsubscribe
>



--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A@public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A@public.gmane.org?subject=unsubscribe


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
Luis EG Ontanon | 1 Jun 16:56 2009

Re: Extending wireshark with Python

I wanted to add python support at first I just did not find the right
docs to do it. Perl is simply off... I do not think is a good
language for embeddng at all...

But perl is at lesat for me the most versatile language I've found.
It's true that it's too versatile that you often end up writing code
that just one day later you cannot read :) .

After having to deal with it for a while I just hapen not to like
python at all :). I do not like the extremely slow compilation, I do
not like the way scopes and variables are handled. But I  do like
ipython, I use it as my desk calculator on an everyday basis.

Keep on the good work.

On Mon, Jun 1, 2009 at 3:31 PM, Sébastien Tandel
<sebastien@...> wrote:
> Hi Luis,
>
> I'm happy to see you're enthusiast! :)
>
>
> On Sun, May 31, 2009 at 22:01, Luis EG Ontanon <luis@...> wrote:
>>
>> I made the Lua bindings an application of the C API, not a simple
>> export. (e.g. proto_item and proto_tree are combined instead of dealt
>> individually, objects are managed in their scope so that deleted
>> objects are not accessed by Lua).
>
> As a rule of thumb, I'm trying to follow the C API but the main idea is of
> course to simplify whenever possible and write less code.
> That's why I'm not against following some parts of the LUA API. My main goal
> is to ease development for others people.
>
>> The reasons why I avoided just mapping the C API were many but all
>> focused on a single point: to make sure that a bug in lua code was
>> hanlded by lua's handler, not by a crash.
>
> For sure, that's something I have to work on :)
> Maybe I did not insist sufficiently on it but it's the *first step* to have
> a python binding with wireshark. There are a lot of things to do , features
> to add,  bugs to fix, etc...
>>
>> Another drive was simplyfing some wireshark concepts to make coding in
>> lua leaner, if it will take me the same number of lines to write code
>> in lua than it takes me to write it in C why not just write it in C.
>
> That's something I want to avoid too. And it's already rather concise, maybe
> not as concise as LUA is right now? maybe.
>
>> I had no python experience at the time and I had heard many good
>> things of it... Having dealt way too much (for my taste) with python
>> latelly now IMHO the only think which python does better than perl is
>> well indented code (the thing cannot even help you find a typo in the
>> name of a variable, closures are cumbersome, global variable usage is
>> painful at very least... as for java I do not understand why so many
>> people like it).
>
> OK, perl lover ... I was working with perl some years ago and I'm really
> happy to be able to avoid its use today!
> BUT my point is that if there were a binding in perl, it would be a good
> thing for wireshark because there are a lot of people using it. I just won't
> do it myself. In the same way, I do think that python is a good thing for
> wireshark too. At the end of the day, just a few people knows LUA. Even
> being in Brazil, country of origin of LUA, working for one of the largest
> brazilian IT company, people knows LUA because it's brazilian but nobody can
> (or want to) develop with it.
> After all, having a binding is not only for me or for other core people.
> Having a binding is to ease wirehark extension development for the rest of
> the community (mainly sysadmin and net guys). If we use an unknown language,
> like let's say D, it is of little interest because just an elite knows it.
> (and probably this elite won't even take a look at wireshark). I know that
> at the company I'm working in, sysadmin and net guys are using a way lot
> more python than perl, do not even think they could one day extend wireshark
> in C and as I already said LUA is just known by its name because of its
> origin. Therefore, what would you choose?
>
> Regards,
> Sebastien Tandel
>
>>
>> On Sun, May 31, 2009 at 10:41 PM, Sébastien Tandel <sebastien <at> tandel.be>
>> wrote:
>> > Hi Stig,
>> >
>> > First, I have to admit that I'm not really aware of the details of the
>> > defined LUA API. But as a rule of thumb, I tried to be close as possible
>> > to
>> > what exists in the C API (not LUA).
>> > Here is an informal description of what rules I tried to follow to
>> > create
>> > this API :
>> > 1) create objects as close as possible to the ones known in libwireshark
>> > There are three "obvious" objects until now : Dissector, Tree, TVB.
>> > 2) method name of each object as close as possible as the ones defined
>> > in
>> > libwireshark. I however modify the name because as C is not object, most
>> > of
>> > the time, a function includes in its name the conceptual "object" name
>> > related to it. This way, it avoids redundance in python API. For example
>> > :
>> > "proto_tree_add_item" is one method of the "tree" object in the C API.
>> > in
>> > the python API, the Tree class defines a "add_item" method. With the
>> > same
>> > idea for "tvb_get_ntohl", the method is defined in the TVB class with
>> > the
>> > name "get_ntohl".
>> > 3) formal parameters of functions :
>> >   a) first parameter is in general the "C object" and it does not make
>> > any
>> > sense to include it for the method defined in a python object. (in fact,
>> > in
>> > python it appears in the definition and "disappears" when called)
>> >   b) it might happen that some other parameters are always defined in
>> > the
>> > formal parameters of the C API but are not manipulated by the user and
>> > might
>> > be included automatically by the python API. For these ones, they also
>> > disappear from the formal parameters list of the python API.
>> >   c) if the parameter takes most of the time one value but sometimes can
>> > take another value, it is defined as an optional parameter.
>> >   d) if the parameter is totally or partially managed by the python API,
>> > it
>> > is defined as an optional parameter.
>> >   a good example is Tree.add_item(self, field, offset=0, length=-1,
>> > little_endian=False, adv=True)
>> >   the C API counterpart is : proto_tree_add_item(proto_tree, hfindex,
>> > tvb,
>> > start, length, little_endian)
>> >     - As of rule a), proto_tree is in fact the Tree object => disappear
>> > from
>> > the formal parameter list
>> >     - As of rule b), tvb is not directly manipulated by the user and
>> > therefore disappear from the formal parameter list
>> >     - As of rule c), little_endian has two possible value False or True.
>> > It
>> > becomes an optional parameter with the default value set to False.
>> >     - As of rule d), "offset" is totally managed by the API with the
>> > help of
>> > the last *added* parameter which indicates whether offset should be
>> > incremented or not. This last parameter is itself an optional parameter
>> > with
>> > a value of True ("offset" is incremented by "length"). Though, offset is
>> > totally managed by the python API, it is possible to increment manually
>> > the
>> > offset.
>> >
>> > There is already two notable exceptions to what I described here above.
>> > There exists two others objects (register_info and Subtrees). It is
>> > likely
>> > that in the future this list of objects will increase because they've
>> > initially have been created because of a "ctypes" (python module)
>> > limitation.
>> > At the end, they almost serve only as a special dictionary of elements.
>> > For these objects, I used a so interesting feature of python, definition
>> > of
>> > dynamic attributes.You have a first step in which you add items in this
>> > "dictionary" (hf_register_info fields and trees). When you have to refer
>> > to
>> > one of these while dissecting, you can refer to them as if they were
>> > attributes of the related object.
>> > For example, let's say "hf" is a register_info object, you can add
>> > something
>> > to it by doing :
>> >   hf.add("Imaginary Protocol Length", "imaginary.length", FT_UINT8)   =>
>> > Not
>> > that you have a lot of optional parameters in here!
>> > and you can refer to this field while dissecting with
>> >   hf.imaginary_length
>> > the name of the attribute is the second parameter passed with every '.'
>> > changed to '_'
>> >
>> >
>> > That's all for now .. I'll add this mail to the wiki documentation.
>> > Of course, I'll enjoy any comments (from you or anyone else) to improve
>> > the
>> > python API whatever it be following the LUA API or not. :)
>> >
>> >
>> > Regards,
>> > Sebastien Tandel
>> >
>> > 2009/5/31 Stig Bjørlykke <stig.bjorlykke@...>
>> >>
>> >> Hi,
>> >>
>> >> Do you use the same naming scheme in the Python bindings as we use in
>> >> Lua?
>> >> I think we should have the same names for equal functionality in both
>> >> Python and Lua.
>> >>
>> >>
>> >> --
>> >> Stig Bjørlykke
>> >>
>> >>
>> >>
>> >>
>> >> ___________________________________________________________________________
>> >> Sent via:    Wireshark-dev mailing list <wireshark-dev <at> wireshark.org>
>> >> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> >>
>> >> mailto:wireshark-dev-request@...?subject=unsubscribe
>> >>
>> >
>> >
>> >
>> > ___________________________________________________________________________
>> > Sent via:    Wireshark-dev mailing list <wireshark-dev <at> wireshark.org>
>> > Archives:    http://www.wireshark.org/lists/wireshark-dev
>> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> >
>> > mailto:wireshark-dev-request@...?subject=unsubscribe
>> >
>>
>>
>>
>> --
>> This information is top security. When you have read it, destroy yourself.
>> -- Marshall McLuhan
>>
>> ___________________________________________________________________________
>> Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>             mailto:wireshark-dev-request@...?subject=unsubscribe
>>
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request@...?subject=unsubscribe
>

--

-- 
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

buildbot | 1 Jun 19:29 2009

buildbot failure in Wireshark (development) on OSX-10.5-x86

The Buildbot has detected a new failure of OSX-10.5-x86 on Wireshark (development).
Full details are available at:
 http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/2540

Buildbot URL: http://buildbot.wireshark.org/trunk/

Buildslave for this Build: osx-10.5-x86

Build Reason: 
Build Source Stamp: HEAD
Blamelist: etxrab,martinm,wmeier

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

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

buildbot | 1 Jun 19:55 2009

buildbot failure in Wireshark (development) on OSX-10.5-ppc

The Buildbot has detected a new failure of OSX-10.5-ppc on Wireshark (development).
Full details are available at:
 http://buildbot.wireshark.org/trunk/builders/OSX-10.5-ppc/builds/1246

Buildbot URL: http://buildbot.wireshark.org/trunk/

Buildslave for this Build: osx-10.5-ppc

Build Reason: 
Build Source Stamp: HEAD
Blamelist: etxrab,martinm,stig,wmeier

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

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

buildbot | 1 Jun 20:30 2009

buildbot failure in Wireshark (development) on Windows-XP-Win64

The Buildbot has detected a new failure of Windows-XP-Win64 on Wireshark (development).
Full details are available at:
 http://buildbot.wireshark.org/trunk/builders/Windows-XP-Win64/builds/626

Buildbot URL: http://buildbot.wireshark.org/trunk/

Buildslave for this Build: windows-xp-win64

Build Reason: 
Build Source Stamp: HEAD
Blamelist: martinm,stig,wmeier

BUILD FAILED: failed nmake all

sincerely,
 -The Buildbot

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

Bryant Eastham | 1 Jun 20:43 2009

Is anonsvn.wireshark.org Sick?

All-

 

I have been having a horrible time trying to use svn/wget from Wireshark.org since last week. Just trying to do an “svn co” of trunk-1.2 took EIGHT attempts just now. Luckily svn keeps track of where it was…

 

However, the “setup” feature of the makefile is having the same problem (using wget). It is not so forgiving, making it almost impossible to build.

 

The symptom (using Wireshark to debug, of course) is that Wireshark.org just stops responding – or it slows down to sending a packet every 30 seconds or so. It also fails to respond to the session being closed (ctrl-c on my side). Trying the operation again goes back to normal speed for a while, and then it just stops again.

 

If nobody else is seeing problems then I will have our IT guys take a look…

 

Thanks,

-Bryant

 

Panasonic Electric Works Laboratory of America - SLC Lab
4525 So. Wasatch Blvd., Suite 100, 84124
Salt Lake City, UT 84124

T 801.993.7124
F 801.993.7269
beastham-kVk2TsMAJTKSQyyjIK0hZK1d+YSPtxow0E9HWUfgJXw@public.gmane.org

Bryant Eastham
Chief Architect

 

 

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

Gmane