[Wireshark-dev] Wireshark on Android

2012-01-15 Thread Mark Sunders
I'm new to the list.  In searching through the archives, I've noticed that 
there have been several cases where people have successfully cross-compiled 
Wireshark (or actually, tshark) for the Android platform.  I've been attempting 
to do this, but without success.  Would anyone that has been successful in 
doing this be willing to contact me off-line to help me out?

I have successfuly ported libpcap and tcpdump to Android, but able failing to 
get past the ./configure stage with this.

Thanks in advance for any help.

Mark___
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

[Wireshark-dev] Getting a pcap filename from a Lua script

2012-01-15 Thread Maayan Zadik
 

Hi,

 

I have several Lua scripts that display different analyses on a
displayed capture file (*.pcap extension). 

That is, the capture is opened from outside the script, and only after
that can the scripts be run.

 

I want to save these analyses to a log file. Current I save the log file
under the name log_timestamp, where timestamp is the time I
created the log.

But the timestamp still makes it hard to know for which pcap the log was
created, if I run the analyses for several files sequentially. 

 

Is there a way to retrieve the capture file name from inside the Lua
script, that way I can name the log: filename_log?

This will make is easier to link between the log and the pcap it was
created for.

 

 

Regards,

Maayan Zadik

maay...@designartnetworks.com

___
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

Re: [Wireshark-dev] [Wireshark-commits] buildbot failure in Wireshark (development) on Visual-Studio-Code-Analysis

2012-01-15 Thread Ed Beroset
Jeorg, 

eax.c(32) : fatal error C1083: Cannot open include file: 'gcrypt.h': No such 
file or directory

Ideas anyone?

I see you already found and fixed the problem in version 40502.  I apologize 
for accidentally deleting that change from the patch I submitted, Joerg.  
Thanks for doing that.  

Also, there's a problem introduced by commenting out some of the code.  You 
noted that you made fixes for these:

[ 64%] Building C object epan/CMakeFiles/epan.dir/dissectors/packet-c1222.c.o   
 
../../asn1/c1222/packet-c1222-template.c: In function ‘dissect_epsem’:  
 
../../asn1/c1222/packet-c1222-template.c:860:15: error: variable ‘ft’ set but 
not used [-Werror=unused-but-set-variable]

[  5%] Building C object epan/CMakeFiles/epan.dir/dissectors/packet-c1222.c.o
../../asn1/c1222/packet-c1222-template.c:103:19: error: ‘c1222_flags’ defined 
but not used [-Werror=unused-variable]

and I see the code you've commented out.  However, that also eliminates some 
functionality.  Specifically that causes autogenerated code to parse the flags. 
 With the code intact, we get this (an extract from tshark):

user-information
C12.22 EPSEM Flags: 0x88, C12.22 Reserved Flag, C12.22 Security 
Mode Flags: Ciphertext with authentication, C12.22 Response Control Flags: 
Always respond
1...  = C12.22 Reserved Flag: True
.0..  = C12.22 Recovery Flag: False
..0.  = C12.22 Proxy Service Used Flag: False
...0  = C12.22 ED Class Flag: False
 10.. = C12.22 Security Mode Flags: Ciphertext with 
authentication (0x02)
 ..00 = C12.22 Response Control Flags: Always respond (0x00)
C12.22 EPSEM: OK
C12.22 Response: OK (0x00)

Without the code, we get this:

user-information
C12.22 EPSEM: OK
C12.22 Response: OK (0x00)

I don't seem to get the same warning using MSC2008EE here.  There must be some 
way to eliminate the warning without sacrificing the feature.  Can you tell me 
how you got those warnings?  I may be able to help.

Ed
___
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

[Wireshark-dev] running a lua function via tshark

2012-01-15 Thread Maayan Zadik
HI,

 

I have a lua script range_check.lua 

It has a function range_check(), which checks the ranges of the fields
of each packet in a pcap file, and it is registered to the menu
MENU_TOOLS_UNSORTED

It runs different tests on each packet and saves to a file the Error
Log, using a Listener and Field Extractors.

This works great in wireshark. 

 

I tried running:

tshark -X lua_script:range_check.lua -q -r my_capture.pcap

but -X lua_script:range_check.lua just loads reange_check, it does no
run the function range_check() on the pcap.

 

Is there a way to run range_check()on a given pcap file via tshark?

 

 

 

Regards,

Maayan Zadik

maay...@designartnetworks.com

___
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

Re: [Wireshark-dev] Getting a pcap filename from a Lua script

2012-01-15 Thread Tony Trinh
On Sun, Jan 15, 2012 at 6:34 AM, Maayan Zadik maay...@designartnetworks.com
 wrote:

 **

 Is there a way to retrieve the capture file name from inside the Lua
 script, that way I can name the log: “filename_log”?



Someone 
askedhttp://www.wireshark.org/lists/wireshark-users/201109/msg00095.html
about
this a few months ago. No, the Lua API currently does not support this, but
there might be other ways to accomplish the same goal:

1) Pass environment variable, containing the filename, to the Lua script

   echo print('\$PCAP:', os.getenv('PCAP'))  foo.lua
   PCAP=foo.pcap tshark -r foo.pcap -Xlua_script:foo.lua -q

2) Print to stdout from Lua, and redirect to file

   tshark -r foo.pcap -Xlua_script:foo.lua -q  foo.pcap.analysis.txt
___
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

Re: [Wireshark-dev] running a lua function via tshark

2012-01-15 Thread Tony Trinh
On Sun, Jan 15, 2012 at 11:04 AM, Maayan Zadik 
maay...@designartnetworks.com wrote:

 I have a lua script range_check.lua

 It has a function range_check(), which checks the ranges of the fields of
 each packet in a pcap file, and it is registered to the menu
 “MENU_TOOLS_UNSORTED”



 I tried running:

 tshark -X lua_script:range_check.lua -q -r my_capture.pcap

 but “-X lua_script:range_check.lua” just loads reange_check, it does no
 run the function “range_check()” on the pcap.

 ** **

 Is there a way to run “range_check()“on a given pcap file via tshark?


I'm guessing the Listener/Tap is only registered in the menu callback. In
TShark, you want the tap to auto-register. If you're indeed doing this
already, please provide a snippet.

Your script should check
gui_enabledhttp://wiki.wireshark.org/LuaAPI/GUI#gui_enabled.28.29
() (or the variable GUI_ENABLED) to determine whether the tap registration
should occur by menu or automatically (see similar
examplehttp://www.wireshark.org/lists/wireshark-users/201201/msg00048.html
).
___
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

Re: [Wireshark-dev] [Wireshark-commits] buildbot failure in Wireshark (development) on Visual-Studio-Code-Analysis

2012-01-15 Thread Joerg Mayer
On Sun, Jan 15, 2012 at 10:55:33AM -0500, Ed Beroset wrote:
 and I see the code you've commented out.  However, that also eliminates some 
 functionality.  Specifically that causes autogenerated code to parse the 
 flags.  With the code intact, we get this (an extract from tshark):

I overdid things: I should have only removed the variable ft and all would
have been fine. I've corrected that in commit 40516.

Sorry
   Joerg
-- 
Joerg Mayer   jma...@loplof.de
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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


[Wireshark-dev] Buildbot status (Ubuntu-10.04-x64)

2012-01-15 Thread Joerg Mayer
The biuldbot Ubuntu-10.04-x64 is not doing anything and hasn't for two days.
Pinging works, triggering a build doesn't work. I tried to stop the current
build (although it doesn't look like there is one going on) but the system
requested a password to do that - and I'm not aware that I have such a password.

Can someone who has the necessary permissions please take a look (or let me
know how to do it myself)?

Thanks
Joerg
-- 
Joerg Mayer   jma...@loplof.de
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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


[Wireshark-dev] Use of deprecated glib function

2012-01-15 Thread Joerg Mayer
Hello,

compiling with current glib (2.31.6) dies with:

[ 95%] Building C object plugins/mate/CMakeFiles/mate.dir/mate_runtime.c.o
cc1: warnings being treated as errors
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 
'destroy_mate_pdus':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:64: warning: 
'g_mem_chunk_free' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:57)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 
'destroy_mate_gops':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:81: warning: 
'g_mem_chunk_free' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:57)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 
'destroy_mate_gogs':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:99: warning: 
'g_mem_chunk_free' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:57)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 
'initialize_mate_runtime':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:143: warning: 
'g_mem_chunk_new' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:48)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 'new_gop':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:176: warning: 
'g_mem_chunk_alloc' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:52)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 'new_gog':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:240: warning: 
'g_mem_chunk_alloc' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:52)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 'new_pdu':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:712: warning: 
'g_mem_chunk_alloc' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:52)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 
'mate_analyze_frame':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:883: warning: 
'g_mem_chunk_free' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:57)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:894: warning: 
'g_mem_chunk_free' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:57)
make[2]: *** [plugins/mate/CMakeFiles/mate.dir/mate_runtime.c.o] Error 1
make[1]: *** [plugins/mate/CMakeFiles/mate.dir/all] Error 2
make: *** [all] Error 2

The only places where g_mem_chunk_free is still used seem to be
plugins/mate/mate_runtime.c and plugins/mate/mate_util.c. Someone
willing to fix this?

Ciao
   Joerg

-- 
Joerg Mayer   jma...@loplof.de
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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


Re: [Wireshark-dev] Use of deprecated glib function

2012-01-15 Thread Bill Meier

On 1/15/2012 12:41 PM, Joerg Mayer wrote:

Hello,

compiling with current glib (2.31.6) dies with:

[ 95%] Building C object plugins/mate/CMakeFiles/mate.dir/mate_runtime.c.o
cc1: warnings being treated as errors
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 
'destroy_mate_pdus':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:64: warning: 
'g_mem_chunk_free' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:57)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 
'destroy_mate_gops':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:81: warning: 
'g_mem_chunk_free' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:57)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 
'destroy_mate_gogs':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:99: warning: 
'g_mem_chunk_free' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:57)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 
'initialize_mate_runtime':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:143: warning: 
'g_mem_chunk_new' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:48)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 'new_gop':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:176: warning: 
'g_mem_chunk_alloc' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:52)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 'new_gog':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:240: warning: 
'g_mem_chunk_alloc' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:52)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 'new_pdu':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:712: warning: 
'g_mem_chunk_alloc' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:52)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c: In function 
'mate_analyze_frame':
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:883: warning: 
'g_mem_chunk_free' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:57)
/Users/jmayer/wireshark/svn/plugins/mate/mate_runtime.c:894: warning: 
'g_mem_chunk_free' is deprecated (declared at 
/usr/local/include/glib-2.0/glib/deprecated/gallocator.h:57)
make[2]: *** [plugins/mate/CMakeFiles/mate.dir/mate_runtime.c.o] Error 1
make[1]: *** [plugins/mate/CMakeFiles/mate.dir/all] Error 2
make: *** [all] Error 2

The only places where g_mem_chunk_free is still used seem to be
plugins/mate/mate_runtime.c and plugins/mate/mate_util.c. Someone
willing to fix this?

Ciao
Joerg



Funny you should ask...

I'm actually just in the midst of making the changes (and learning about 
MATE).


Bill



___
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


Re: [Wireshark-dev] Use of deprecated glib function

2012-01-15 Thread Joerg Mayer
On Sun, Jan 15, 2012 at 06:41:33PM +0100, Joerg Mayer wrote:
 compiling with current glib (2.31.6) dies with:

Correction: 2.31.8

-- 
Joerg Mayer   jma...@loplof.de
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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


Re: [Wireshark-dev] [Wireshark-commits] rev 40518: /trunk/ /trunk/epan/: plugins.c timestamp.c /trunk/gtk/: CMakeLists.txt Makefile.am Makefile.common Makefile.nmake Makefile_custom.common STATUS.gtk3

2012-01-15 Thread Guy Harris

On Jan 15, 2012, at 1:59 PM, jma...@wireshark.org wrote:

 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=40518
 
 User: jmayer
 Date: 2012/01/15 01:59 PM
 
 Log:
 Move gtk to ui/gtk.

Should those files in the top-level images directory that are only used by UI 
code be moved a ui/images directory?

A quick scan of the source finds a bunch of includes of XPM files from 
ui/gtk/*.c files; I'm guessing that they - the .xpm files - would only be used 
by UI code, making them candidates to be moved.

I'm not sure where the .png files are used - are they used as source to 
generate files such as ui/gtk/expert_indicators.h?  If so, they'd be candidates 
as well.  (And, if so, what tool is used to generate them?)

The same applies for expert_indicators.svg.

Should anything used only by packaging/installer tools be put into 
packaging/images or, if they're specific to a particular package 
type/installer, an images subdirectory or the top-level directory for that 
packaging/installer tool?
___
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


Re: [Wireshark-dev] [Wireshark-commits] rev 40518: /trunk/ /trunk/epan/: plugins.c timestamp.c /trunk/gtk/: CMakeLists.txt Makefile.am Makefile.common Makefile.nmake Makefile_custom.common STATUS.gtk3

2012-01-15 Thread Joerg Mayer
On Sun, Jan 15, 2012 at 03:05:41PM -0800, Guy Harris wrote:
 
 On Jan 15, 2012, at 1:59 PM, jma...@wireshark.org wrote:
 
  http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=40518
  
  User: jmayer
  Date: 2012/01/15 01:59 PM
  
  Log:
  Move gtk to ui/gtk.
 
 Should those files in the top-level images directory that are only used by UI 
 code be moved a ui/images directory?
 
 A quick scan of the source finds a bunch of includes of XPM files from 
 ui/gtk/*.c files; I'm guessing that they - the .xpm files - would only be 
 used by UI code, making them candidates to be moved.
 
 I'm not sure where the .png files are used - are they used as source to 
 generate files such as ui/gtk/expert_indicators.h?  If so, they'd be 
 candidates as well.  (And, if so, what tool is used to generate them?)
 
 The same applies for expert_indicators.svg.
 
 Should anything used only by packaging/installer tools be put into 
 packaging/images or, if they're specific to a particular package 
 type/installer, an images subdirectory or the top-level directory for that 
 packaging/installer tool?

Moving the .xpms into ui/ makes sense to me. I'm not sure whether separating
the different image type is useful, but from a usage point of view moving the
relevant files to packaging/images/ sounds better to me - hmm, or not: If
icons/pictures are used in more than one place, we will run into consistency
problems - iff they are used in more than one place.
And eventually tshark should probably go into ui/text/ as well as all the
non-interactive text tools like editcap, dumpcap etc.

But I will call it a day (or night) for now.

Ciao
 Jörg
-- 
Joerg Mayer   jma...@loplof.de
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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

Re: [Wireshark-dev] GTK3 for OSX

2012-01-15 Thread Joerg Mayer
On Fri, Dec 30, 2011 at 05:11:41PM +0100, Michael Tuexen wrote:
 On Dec 30, 2011, at 12:41 PM, Joerg Mayer wrote:
 
  Just a question I've been toying with:
  Would it be ok/make sense to move the official builds on OSX from GTK2 to
  GTK3?
 Depends on:
 * Does GTK3 compile? For GTK2 we need some patches?
 * Is it stable for releases?
 I haven't tried it yet?

OK, here's the state of GTK3 on OSX: You can try for yourself by running
the current version of the macos-setup.sh script (with the variable GTK3=1
(and optionally CMAKE=1).
The autotool path will compile.
With the cmake path there is a problem that -lfreetype is linked against but
-L/usr/X11/lib is missing. If you work around that by manually adjusting the
link.txt file for wireshark, wireshark will compile. The only thing that fails
to build it the mate plugin because the cmake stuff is set up to treat the
use of deprecated glib functions as errors.

Testers welcome!

 Ciao
Jörg
-- 
Joerg Mayer   jma...@loplof.de
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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

Re: [Wireshark-dev] Buildbot status (Ubuntu-10.04-x64)

2012-01-15 Thread Gerald Combs
On 1/15/12 9:33 AM, Joerg Mayer wrote:
 The biuldbot Ubuntu-10.04-x64 is not doing anything and hasn't for two days.
 Pinging works, triggering a build doesn't work. I tried to stop the current
 build (although it doesn't look like there is one going on) but the system
 requested a password to do that - and I'm not aware that I have such a 
 password.
 
 Can someone who has the necessary permissions please take a look (or let me
 know how to do it myself)?

It (and the Win 7 builder) have been nudged.
___
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


Re: [Wireshark-dev] [Wireshark-commits] rev 40518: /trunk/ /trunk/epan/: plugins.c timestamp.c /trunk/gtk/: CMakeLists.txt Makefile.am Makefile.common Makefile.nmake Makefile_custom.common STATUS.gtk3

2012-01-15 Thread Gerald Combs
On 1/15/12 3:05 PM, Guy Harris wrote:
 
 On Jan 15, 2012, at 1:59 PM, jma...@wireshark.org wrote:
 
 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=40518

 User: jmayer
 Date: 2012/01/15 01:59 PM

 Log:
 Move gtk to ui/gtk.
 
 Should those files in the top-level images directory that are only used by UI 
 code be moved a ui/images directory?

Probably.

 A quick scan of the source finds a bunch of includes of XPM files from 
 ui/gtk/*.c files; I'm guessing that they - the .xpm files - would only be 
 used by UI code, making them candidates to be moved.

N. B. Moving forward I'd prefer to migrate away from XPM to formats with
better alpha transparency support.

 I'm not sure where the .png files are used - are they used as source to 
 generate files such as ui/gtk/expert_indicators.h?  If so, they'd be 
 candidates as well.  (And, if so, what tool is used to generate them?)
 
 The same applies for expert_indicators.svg.

expert_indicators.h is generated from expert*.png using
gdk-pixbuf-csource. The .png files were exported manually from
expert_indicators.svg.

 Should anything used only by packaging/installer tools be put into 
 packaging/images or, if they're specific to a particular package 
 type/installer, an images subdirectory or the top-level directory for that 
 packaging/installer tool?

Sounds reasonable. It might help make things more obvious for downstream
packagers.
___
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