Re: [Wireshark-dev] Gerrit versus Buildbot

2014-03-26 Thread Bálint Réczey
2014-03-21 22:24 GMT+01:00 Bálint Réczey :
> Hi,
>
> 2014-03-20 23:11 GMT-01:00 Guy Harris :
>>
>> On Mar 20, 2014, at 2:24 PM, Chris Kilgour  wrote:
>>
>>> On 03/20/2014 01:07 PM, Gerald Combs wrote:

 If the build system had open access what would keep someone from
 uploading a shell script containing a box full of weasels wearing clown
 shoes?
>>>
>>> Isn't the same thing true for Jenkins/buildbot spawned from gerrit?  Surely 
>>> the build machines must be limited/sandboxed to prevent the circus from 
>>> taking over the town.
>>
>> Currently, it's limited to building stuff to which at least one core 
>> developer is willing to give +2.  That requires human judgement, so it's not 
>> as rigid as a hardware/software-implemented sandbox.
> Could it please be changed to build changes having at least _+1_ from
> a Core Developer? +2 has the meaning that it is ready for submitting
> and using +1 for triggering build-bot would be handy.
I have just checked and +2 did not trigger a build. I have updated
http://wiki.wireshark.org/Development/Workflow accordingly.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] unusual button text

2014-03-26 Thread Bálint Réczey
2014-03-22 21:03 GMT+01:00 Bálint Réczey :
> Hi,
>
> 2014-03-22 18:29 GMT-01:00 Anders Broman :
>> Balint's stock icon changes?
>>
>> Den 22 mar 2014 19:35 skrev "Guy Harris" :
>>
>>>
>>> On Mar 22, 2014, at 9:09 AM, Toralf Förster 
>>> wrote:
>>>
>>> > Got this with latest git tree while quitting w/o saving
>>>
>>> Probably a result of recent changes to avoid using some GTK+ APIs
>>> deprecated in later versions of GTK+ 3.  Anders?
> It looks like that you use GTK 3.10, the regression affects Wireshark
> only with GTK+ >= 3.10.
> I could not find a proper solution for that,  sorry.
I have just pushed a workaround.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] How to include new dissector wrriten in Lua (pure Lua) to Wireshark

2014-03-26 Thread Hadriel Kaplan

On Mar 26, 2014, at 1:29 AM, Nakayama Kenjiro  wrote:

> Recently I wrote new dissector by pure Lua[1] and I am thinking about 
> submitting a request to include the dissector to Wireshark.
> But as far as I checked upstream, there are no pure Lua dissector yet.

Right, none yet.

The challenge I think is that most of the core developers don't know Lua nearly 
as well as C, so it would be hard for them to fix any bugs, or enhance it in 
the future to support some new version of the protocol being dissected (JGroups 
in your case).

But as long as they're ok with the idea, I think it would be great to have 
such. It might even bring in more protocols, because it might be easier for 
some people to write one in Lua than deal with trying to figure out how to 
compile the source, or learn C if they don't know it already.

An alternative approach is to do what many other apps do: have a mechanism to 
find/retrieve/install/update/remove third-party plugins from a common 
repository site.  That way the plugins themselves aren't part of the 
application package and aren't officially maintained by the core application 
developers, but instead are maintained by the third-parties (or not, and they 
die off, which isn't a bad thing either).  Many good text editors/IDEs do that, 
for example, as do browsers, etc.  Some even do it with the ability to pull 
plugins from github directly, instead of storing the plugins in their own site.


> And I don't know where shoudld I put the code in and how to modify Makefiles.

Right now two Lua files are included with Wireshark: init.lua, and console.lua. 
 Both are in epan/wslua and copied in the global configuration directory for 
installs/packages. (well, init.lua is actually generated from a perl script 
using template-init.lua)  If you grep the code for "console.lua" you'll see the 
various files that move it around.

But the global configuration directory isn't the right place really for Lua 
dissectors, nor is epan/wslua for the source repository.  They should probably 
be put into the plugins/ source directory, and be installed into the global 
plugins directory.

But we can work out those details if/when there's consensus to include Lua 
dissectors.  For example we might wan to change the loading code a bit for 
plugins, to have it check if a file of the same name exists in the user's 
personal plugins directory, and if so then to load that one instead of the one 
in the global plugins dir.  Or use a filename version schema and load the 
newest one.


> So my question is
> Is there any guideline to include pure Lua dissector? If no guideline yet, 
> why don't we make it?
> 
> This is my personal opinion, now Lua became good for writing a new dissector 
> and samples like /test/lua/dissector.lua is really great. New dissector 
> written in Lua request will increase in the future.
> 
> [1] https://github.com/nak3/jgroups-wireshark-dissector
> 
> Thanks,
> 
> Kenjiro
> 
> -- 
> Kenjiro NAKAYAMA 
> GPG Key fingerprint = ED8F 049D E67A 727D 9A44  8E25 F44B E208 C946 5EB9
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

Re: [Wireshark-dev] new warning :/usr/include/gtk-3.0/gtk/gtkwidget.h:787:58: error: identifier "and" is a special operator name in C++ [-Werror=c++-compat]

2014-03-26 Thread Bálint Réczey
2014-03-09 15:43 GMT+01:00 Bálint Réczey :
> 2014-03-09 10:43 GMT+01:00 Alexis La Goutte :
>> On Sat, Mar 8, 2014 at 4:21 PM, Toralf Förster  
>> wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> Switching from gtk-3.8.7 to gtp-3.10.7 I do get with current wireshark git 
>>> tree at a stable 32 bit Gentoo Linux :
>>>
>>> make[2]: Entering directory `/home/tfoerste/devel/wireshark/ui/gtk'
>>>   CC   libgtkui_a-about_dlg.o
>>> In file included from /usr/include/gtk-3.0/gtk/gtkapplication.h:27:0,
>>>  from /usr/include/gtk-3.0/gtk/gtkwindow.h:33,
>>>  from /usr/include/gtk-3.0/gtk/gtkdialog.h:33,
>>>  from /usr/include/gtk-3.0/gtk/gtkaboutdialog.h:30,
>>>  from /usr/include/gtk-3.0/gtk/gtk.h:31,
>>>  from about_dlg.c:28:
>>> /usr/include/gtk-3.0/gtk/gtkwidget.h:787:58: error: identifier "and" is a 
>>> special operator name in C++ [-Werror=c++-compat]
>>> cc1: all warnings being treated as errors
>>> make[2]: *** [libgtkui_a-about_dlg.o] Error 1
>>>
>> Hi,
>>
>> For me, it is a GTK issue, the problem is gtk header (no in Wireshark
>> source code)
> Hi,
>
> I have already sent a patch to GTK list:
> https://mail.gnome.org/archives/gtk-list/2014-March/msg00019.html
>
> Cheers,
> Balint
The fix is included in GTK+ 3.12.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] How to include new dissector wrriten in Lua (pure Lua) to Wireshark

2014-03-26 Thread Nakayama Kenjiro
Thanks,

There are some problems to solve... It's my understanding that there are
following three main points.

 1. Now there is no Lua dissector yet. And the consensus to include Lua
dissectors is neccessary.
 2. If we will include Lua dissectors, there are two (or more) ways to
consider, a)include the dissector to Wireshark or
b)find/retrieve/install/update/remove plugins from a common repository site.
 3. In every case, we will need some enhancement to load the module, if Lua
dissector is included.

I will wait for other opinions a little more, and I will submit a request
to Bugzilla.

Thank you for your advice!


PS. I agree to the common repository style, it's great idea. JGroups has
many versions and if we can install by jgroups-$(VERSION), it is very
useful.

Kenjiro



On Wed, Mar 26, 2014 at 11:55 PM, Hadriel Kaplan
wrote:

>
> On Mar 26, 2014, at 1:29 AM, Nakayama Kenjiro 
> wrote:
>
> Recently I wrote new dissector by pure Lua[1] and I am thinking about
> submitting a request to include the dissector to Wireshark.
> But as far as I checked upstream, there are no pure Lua dissector yet.
>
>
> Right, none yet.
>
> The challenge I think is that most of the core developers don't know Lua
> nearly as well as C, so it would be hard for them to fix any bugs, or
> enhance it in the future to support some new version of the protocol being
> dissected (JGroups in your case).
>
> But as long as they're ok with the idea, I think it would be great to have
> such. It might even bring in more protocols, because it might be easier for
> some people to write one in Lua than deal with trying to figure out how to
> compile the source, or learn C if they don't know it already.
>
> An alternative approach is to do what many other apps do: have a mechanism
> to find/retrieve/install/update/remove third-party plugins from a common
> repository site.  That way the plugins themselves aren't part of the
> application package and aren't officially maintained by the core
> application developers, but instead are maintained by the third-parties (or
> not, and they die off, which isn't a bad thing either).  Many good text
> editors/IDEs do that, for example, as do browsers, etc.  Some even do it
> with the ability to pull plugins from github directly, instead of storing
> the plugins in their own site.
>
>
> And I don't know where shoudld I put the code in and how to modify
> Makefiles.
>
>
> Right now two Lua files are included with Wireshark: init.lua, and
> console.lua.  Both are in epan/wslua and copied in the global configuration
> directory for installs/packages. (well, init.lua is actually generated from
> a perl script using template-init.lua)  If you grep the code for
> "console.lua" you'll see the various files that move it around.
>
> But the global configuration directory isn't the right place really for
> Lua dissectors, nor is epan/wslua for the source repository.  They should
> probably be put into the plugins/ source directory, and be installed into
> the global plugins directory.
>
> But we can work out those details if/when there's consensus to include Lua
> dissectors.  For example we might wan to change the loading code a bit for
> plugins, to have it check if a file of the same name exists in the user's
> personal plugins directory, and if so then to load that one instead of the
> one in the global plugins dir.  Or use a filename version schema and load
> the newest one.
>
>
> So my question is
> Is there any guideline to include pure Lua dissector? If no guideline yet,
> why don't we make it?
>
> This is my personal opinion, now Lua became good for writing a new
> dissector and samples like /test/lua/dissector.lua is really great. New
> dissector written in Lua request will increase in the future.
>
> [1] https://github.com/nak3/jgroups-wireshark-dissector
>
> Thanks,
>
> Kenjiro
>
> --
> Kenjiro NAKAYAMA 
> GPG Key fingerprint = ED8F 049D E67A 727D 9A44  8E25 F44B E208 C946 5EB9
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> 
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>



-- 
Kenjiro NAKAYAMA 
GPG Key fingerprint = ED8F 049D E67A 727D 9A44  8E25 F44B E208 C946 5EB9
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ..