Re: [Wireshark-dev] [Wireshark-commits] master 7f3d97c: Include the gnm dissector.
Den 1 aug 2014 01:23 skrev Guy Harris g...@alum.mit.edu: On Jul 31, 2014, at 3:21 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: The commit message there says it was removed because it was never used. Never used in what sense? Nobody ever read a capture file that used it? I created the dissector while doing other ITU asn1 dissectors in the hope it would be useful, I have never seen a trace whit it or seen a bug report so I removed it from the makefile but left the files to give a grace period before removing it completely. The same reasoning goes for the asn1 plugin. If it were to be still used ideally it should be rewritten to use the ber accessors. But I think we now provide adequate tools to convert asn1 documents to c dissectors obsoleted the plugin. Regards Anders Or nothing will ever use the OIDs for which it registers? ___ 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 ___ 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] master 43a81b6: Add some information on running from the build directory.
On Thursday 31 July 2014 16:40:53 Guy Harris wrote:
On Jul 31, 2014, at 3:11 PM, Peter Wu pe...@lekensteyn.nl wrote:
[..]
Oh my, that filesystem.c code is really ugly and relying on a lot of
assumptions. Why does it need to distinguish build dirs from other dirs in
the first place?
So that you can just type ./wireshark or ./tshark after you've done a
build, and have it Just Work, rather than having to install Wireshark or
TShark before you can run it. Note that we run TShark to generate some man
pages.
The binaries themselves already Just Work(tm) without libtool because CMake
sets RPATH. (If it still tries to search for globally installed WS, note that
there existed a bug in CMake 2.8[1] that set the wrong RPATH when linked
against libraries in `/lib64`. That got fixed in CMake 3.0)
[1]: http://www.cmake.org/Bug/view.php?id=14875
From the comments, it seems to that for security/stability
reasons,
From one of the comments:
/*
* Check whether WIRESHARK_RUN_FROM_BUILD_DIRECTORY is set in the
* environment; if so, set running_in_build_directory_flag if we
* weren't started with special privileges. (If we were started
* with special privileges, it's not safe to allow the user to point
* us to some other directory; running_in_build_directory_flag, when
* set, causes us to look for plugins and the like in the build
* directory.)
*/
So the code that sets the running from the build directory flag takes into
account security issues, but it doesn't *exist* for security reasons.
On the other hand, from doc/README.packaging:
WIRESHARK CONTAINS OVER TWO MILLION LINES OF SOURCE CODE. DO NOT RUN
THEM
AS ROOT.
That was indeed the reason for comments on security reasons, together with
ignoring plugins from the env vars. Fun fact: currently there are over 3.5M
lines of code (only counting *.h and *.c, surely I missed some cpp and py
files). I would like to get rid of the WIRESHARK_RUN_FROM_BUILD_DIRECTORY if
possible, not treating it specially and instead rely on environment variables
to configure stuff.
and another reason is to make plugins get loaded from the build dir.
Not just plugins, but also global configuration files, etc..
Currently the configuration cannot be overridden when ran from the confdir,
but that seems to be a useless restriction. Setting WIRESHARK_DATA_DIR should
work without surprises (this behavior is not even documented, only root/setuid
should have this special behavior).
What about solely relying on envvars?
Sure, as long as the user doesn't have to do anything to set the environment
variable. Otherwise, it doesn't Just Work.
Then there can be a shell-script if you
like the wrapper provided by libtool:
#!/bin/bash
# tools/run.sh - Wrapper for binaries
# since Mac does not have `readlink -f`, this is an alternative:
Neither do older versions of other BSD-flavored OSes. I guess Apple just
haven't updated readlink in a while.
Apple has a greadlink (GNU readlink), but I don't think that is installed by
default either. Actually, since `$0` is expected to be a symlink, it should be
fine to use just `readlink $0`, and exit in other cases (printing a help
message instead?).
rundir=$(cd $(dirname $0) pwd)
#rundir=$(dirname $(readlink -f $0))
export WIRESHARK_DATA_DIR=$rundir
export WIRESHARK_PLUGIN_DIR=$rundir
#etc.
exec $rundir/${0##*/} $@
With links:
tmpbin/tshark - ../tools/run.sh
tmpbin/wireshark - ../tools/run.sh
etc.
So tmpbin is the top-level source directory, so running ./tshark,
./wireshark, etc. from the top-level CMake build directory would be
sufficient?
The object (output) directory. For top-level directories, the symlink would
appear as `./tshark - tools/run.sh` (assuming that run.sh is copied over). If
this approach is taken, an option must be added to support the use of GDB /
valgrind.
Kind regards,
Peter
https://lekensteyn.nl
___
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] master 43a81b6: Add some information on running from the build directory.
On Thursday 31 July 2014 20:04:52 Evan Huus wrote: FWIW this issue also makes it impossible to run parts of the test suite from an out-of-tree build, which can be problematic. Which part exactly? I can run most of the test-suite with an OOT build using: WS_BIN_PATH=/tmp/wsbuild/run ./test.sh -s $suite Some things fail for me, but that seems unrelated to the build dir: clopts testing because unprivileged users still have a dbus capture interface) 2.4.1 Step: Invalid permissions for dumpcap parameter -D, exit status must be 2 Invalid permissions for dumpcap parameter -D, exit status must be 2 Failed! exit status: 0 ./testout.txt:1. dbus-system ./testout.txt:2. dbus-session 1.1 Step: Name resolution, no external, no profile hosts, global profile Name resolution, no external, no profile hosts, global profile Failed! Failed to resolve 8.8.8.8 using global hosts file. This fails because the hosts file is copied to /tmp/wsbuild/run/, but Wireshark is looking in the source directory: open(/tmp/wireshark/hosts, O_RDONLY) = -1 ENOENT (No such file or directory) LUA? Testing Dir.open tshark: Lua: Error during loading: [string /home/peter/projects/wireshark/test/lua/dir.l...]:130: attempt to call global 'typeof' (a nil value) test Dir.open-31...passed test Dir.open-32...passed wslua dir Failed! didn't find pass marker ./temp/file3.txt:fooobarrloo ./temp/file2.txt:fooobarrloo ./temp/file1.txt:fooobarrloo Kind regards, Peter https://lekensteyn.nl ___ 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-announce] Wireshark 1.12.0rc3 is now available
The x86 CMake build now completes :-) The x64 build is failing due to the lack of an acceptable Python and some dumpcap link errors. On 1 August 2014 00:28, Gerald Combs ger...@wireshark.org wrote: On 7/31/14 2:19 PM, Graham Bloice wrote: On 31 July 2014 22:14, Graham Bloice graham.blo...@trihedral.com mailto:graham.blo...@trihedral.com wrote: On 31 July 2014 17:34, Gerald Combs ger...@wireshark.org mailto:ger...@wireshark.org wrote: On 7/31/14 6:08 AM, Graham Bloice wrote: On 31 July 2014 11:42, Bálint Réczey bal...@balintreczey.hu mailto:bal...@balintreczey.hu mailto:bal...@balintreczey.hu mailto:bal...@balintreczey.hu wrote: +1 for dropping autotools in favor of CMake. CMake already covers all my use cases. Same here except for Windows. I've been doing most of my Qt development using Qt Creator + CMake. It doesn't have all the conveniences of Qt Creator + QMake but it works well enough. I also support dropping nmake, but since I'm not building on Windows I can't tell if CMake is complete enough. Not yet. Working on it though. I added msbuild steps to the Windows buildslaves after the cmake steps. The 32-bit build succeeds although I haven't tried running it. The 64-bit build passes /MACHINE:X86 to the linker which then fails. The buildslaves are failing to build the solution. I think the arguments to the msbuild step should be modified to be msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln. Done. And the x86 buildslave CMake still isn't locating a viable Python Interpreter. The machine has the official Python 2.6 installed in c:\Python26 and Cygwin's Python 2.7 installed in c:\cygwin\usr\bin. According to http://www.cmake.org/pipermail/cmake/2010-February/035404.html CMake looks for numbered Pythons executables (python2.7, python2.6, ...) before looking for the plain executable. In our case this means it's finding Cygwin's Python before the official version. The version detection then fails for some reason. I'm going to try installing the official Python 2.7. Hopefully it will be found before Cygwin's. ___ 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 -- Graham Bloice Software Developer Trihedral UK Limited ___ 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] master 43a81b6: Add some information on running from the build directory.
On Aug 1, 2014, at 5:12, Peter Wu pe...@lekensteyn.nl wrote: On Thursday 31 July 2014 20:04:52 Evan Huus wrote: FWIW this issue also makes it impossible to run parts of the test suite from an out-of-tree build, which can be problematic. Which part exactly? I can run most of the test-suite with an OOT build using: WS_BIN_PATH=/tmp/wsbuild/run ./test.sh -s $suite Some things fail for me, but that seems unrelated to the build dir: Name resolution and lua failures are both due to the out-of-tree build. clopts testing because unprivileged users still have a dbus capture interface) 2.4.1 Step: Invalid permissions for dumpcap parameter -D, exit status must be 2 Invalid permissions for dumpcap parameter -D, exit status must be 2 Failed! exit status: 0 ./testout.txt:1. dbus-system ./testout.txt:2. dbus-session 1.1 Step: Name resolution, no external, no profile hosts, global profile Name resolution, no external, no profile hosts, global profile Failed! Failed to resolve 8.8.8.8 using global hosts file. This fails because the hosts file is copied to /tmp/wsbuild/run/, but Wireshark is looking in the source directory: open(/tmp/wireshark/hosts, O_RDONLY) = -1 ENOENT (No such file or directory) LUA? Testing Dir.open tshark: Lua: Error during loading: [string /home/peter/projects/wireshark/test/lua/dir.l...]:130: attempt to call global 'typeof' (a nil value) test Dir.open-31...passed test Dir.open-32...passed wslua dir Failed! didn't find pass marker ./temp/file3.txt:fooobarrloo ./temp/file2.txt:fooobarrloo ./temp/file1.txt:fooobarrloo Kind regards, Peter https://lekensteyn.nl ___ 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] master 43a81b6: Add some information on running from the build directory.
On Aug 1, 2014, at 2:00 AM, Peter Wu pe...@lekensteyn.nl wrote:
On Thursday 31 July 2014 16:40:53 Guy Harris wrote:
On Jul 31, 2014, at 3:11 PM, Peter Wu pe...@lekensteyn.nl wrote:
[..]
Oh my, that filesystem.c code is really ugly and relying on a lot of
assumptions. Why does it need to distinguish build dirs from other dirs in
the first place?
So that you can just type ./wireshark or ./tshark after you've done a
build, and have it Just Work, rather than having to install Wireshark or
TShark before you can run it. Note that we run TShark to generate some man
pages.
The binaries themselves already Just Work(tm) without libtool because CMake
sets RPATH.
Presumably by the binaries themselves already Just Work you mean the
binaries are, at least, capable of finding the relevant shared libraries, even
if the code *in* those binaries, and the shared libraries in question, fails to
find the data files such as RADIUS dictionaries, DIAMETER dictionaries, FIX
field description files, etc., and thus doesn't Just Work, as that's a more
precise description of the situation.
I.e., the problem has nothing to do with finding the *shared libraries*, it has
to to with finding the *data files*.
For autotools builds, the data files *are* found, without any need for the user
to specify anything themselves, for in-tree builds; the code determines the
location of those data files based on the location of the executable image, so
that it picks up the data files from the source tree.
For out-of-tree builds, however, that obviously doesn't work, as the executable
isn't in the source tree.
I would like to get rid of the WIRESHARK_RUN_FROM_BUILD_DIRECTORY if
possible, not treating it specially and instead rely on environment variables
to configure stuff.
As long as the user has to set precisely none of those environment variables
themselves when running from the build directory, that would be OK.
If the user has to set any of them himself or herself, that no longer Just
Works.
Setting WIRESHARK_DATA_DIR should work without surprises
Note that the source tree doesn't have exactly the same layout as the directory
tree of global configuration files; if we're not going to have the code know
whether we're running from the build directory or not, the build process will
probably have to collect all the files that would be installed as global
configuration files (RADIUS dictionaries, DIAMETER dictionaries, Lua files,
AUTHOR-SHORT file, etc., etc.) and copy them to a tree with that layout, with
WIRESHARK_DATA_DIR pointed at the root of that tree.
(this behavior is not even documented, only root/setuid should have this
special behavior).
The fact that we ignore environment variables when run with special privileges
isn't documented? Yes, it should be, although we should perhaps extend the
notion of special privileges to include, for example, process capabilities.
rundir=$(cd $(dirname $0) pwd)
#rundir=$(dirname $(readlink -f $0))
export WIRESHARK_DATA_DIR=$rundir
export WIRESHARK_PLUGIN_DIR=$rundir
Either
1) those would need to set those to the *source* directory, *and* the
code would need to know that some files (such as init.lua) aren't in their
normal locations (i.e., that we're running from the build directory)
or
2) the build process will need to make a copy of the data files, in the
same fashion that installation does, and the script should point to the copied
tree.
If this approach is taken, an option must be added to support the use of GDB
/
valgrind.
.../otool/etc., along the lines of ./libtool --mode=execute {command}
{program}.
___
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] master 43a81b6: Add some information on running from the build directory.
On 08/01/14 13:54, Guy Harris wrote: On Aug 1, 2014, at 2:00 AM, Peter Wu pe...@lekensteyn.nl wrote: On Thursday 31 July 2014 16:40:53 Guy Harris wrote: On Jul 31, 2014, at 3:11 PM, Peter Wu pe...@lekensteyn.nl wrote: [..] Oh my, that filesystem.c code is really ugly and relying on a lot of assumptions. Why does it need to distinguish build dirs from other dirs in the first place? So that you can just type ./wireshark or ./tshark after you've done a build, and have it Just Work, rather than having to install Wireshark or TShark before you can run it. Note that we run TShark to generate some man pages. The binaries themselves already Just Work(tm) without libtool because CMake sets RPATH. Presumably by the binaries themselves already Just Work you mean the binaries are, at least, capable of finding the relevant shared libraries, even if the code *in* those binaries, and the shared libraries in question, fails to find the data files such as RADIUS dictionaries, DIAMETER dictionaries, FIX field description files, etc., and thus doesn't Just Work, as that's a more precise description of the situation. I.e., the problem has nothing to do with finding the *shared libraries*, it has to to with finding the *data files*. For autotools builds, the data files *are* found, without any need for the user to specify anything themselves, for in-tree builds; the code determines the location of those data files based on the location of the executable image, so that it picks up the data files from the source tree. For out-of-tree builds, however, that obviously doesn't work, as the executable isn't in the source tree. Actually out-of-tree builds can find the data files in out-of-tree builds due to another hack that I put in (bug 5664/r38070). ___ 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] master 43a81b6: Add some information on running from the build directory.
On Fri, Aug 1, 2014 at 1:58 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: On 08/01/14 13:54, Guy Harris wrote: On Aug 1, 2014, at 2:00 AM, Peter Wu pe...@lekensteyn.nl wrote: On Thursday 31 July 2014 16:40:53 Guy Harris wrote: On Jul 31, 2014, at 3:11 PM, Peter Wu pe...@lekensteyn.nl wrote: [..] Oh my, that filesystem.c code is really ugly and relying on a lot of assumptions. Why does it need to distinguish build dirs from other dirs in the first place? So that you can just type ./wireshark or ./tshark after you've done a build, and have it Just Work, rather than having to install Wireshark or TShark before you can run it. Note that we run TShark to generate some man pages. The binaries themselves already Just Work(tm) without libtool because CMake sets RPATH. Presumably by the binaries themselves already Just Work you mean the binaries are, at least, capable of finding the relevant shared libraries, even if the code *in* those binaries, and the shared libraries in question, fails to find the data files such as RADIUS dictionaries, DIAMETER dictionaries, FIX field description files, etc., and thus doesn't Just Work, as that's a more precise description of the situation. I.e., the problem has nothing to do with finding the *shared libraries*, it has to to with finding the *data files*. For autotools builds, the data files *are* found, without any need for the user to specify anything themselves, for in-tree builds; the code determines the location of those data files based on the location of the executable image, so that it picks up the data files from the source tree. For out-of-tree builds, however, that obviously doesn't work, as the executable isn't in the source tree. Actually out-of-tree builds can find the data files in out-of-tree builds due to another hack that I put in (bug 5664/r38070). Well it's not finding all of them or the out-of-tree test suite would work (right now it fails to find init.lua and the name-resolutions settings, so those tests fail). ___ 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] master 43a81b6: Add some information on running from the build directory.
On 08/01/14 14:04, Evan Huus wrote: On Fri, Aug 1, 2014 at 1:58 PM, Jeff Morriss jeff.morriss...@gmail.com mailto:jeff.morriss...@gmail.com wrote: On 08/01/14 13:54, Guy Harris wrote: On Aug 1, 2014, at 2:00 AM, Peter Wu pe...@lekensteyn.nl mailto:pe...@lekensteyn.nl wrote: On Thursday 31 July 2014 16:40:53 Guy Harris wrote: On Jul 31, 2014, at 3:11 PM, Peter Wu pe...@lekensteyn.nl mailto:pe...@lekensteyn.nl wrote: [..] Oh my, that filesystem.c code is really ugly and relying on a lot of assumptions. Why does it need to distinguish build dirs from other dirs in the first place? So that you can just type ./wireshark or ./tshark after you've done a build, and have it Just Work, rather than having to install Wireshark or TShark before you can run it. Note that we run TShark to generate some man pages. The binaries themselves already Just Work(tm) without libtool because CMake sets RPATH. Presumably by the binaries themselves already Just Work you mean the binaries are, at least, capable of finding the relevant shared libraries, even if the code *in* those binaries, and the shared libraries in question, fails to find the data files such as RADIUS dictionaries, DIAMETER dictionaries, FIX field description files, etc., and thus doesn't Just Work, as that's a more precise description of the situation. I.e., the problem has nothing to do with finding the *shared libraries*, it has to to with finding the *data files*. For autotools builds, the data files *are* found, without any need for the user to specify anything themselves, for in-tree builds; the code determines the location of those data files based on the location of the executable image, so that it picks up the data files from the source tree. For out-of-tree builds, however, that obviously doesn't work, as the executable isn't in the source tree. Actually out-of-tree builds can find the data files in out-of-tree builds due to another hack that I put in (bug 5664/r38070). Well it's not finding all of them or the out-of-tree test suite would work (right now it fails to find init.lua and the name-resolutions settings, so those tests fail). I posted fixes for the nameres failure (change 3334) and the wslua failure (change 3337). The wslua failure wasn't because init.lua wasn't being found (it was) it was because taps_wslua.c was empty in an out-of-source-tree build. ___ 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] Ping-Bug?
On 8/1/14 9:08 AM, Jeff Morriss wrote: On 07/13/14 14:05, Alexis La Goutte wrote: On Fri, Jul 11, 2014 at 10:06 PM, Evan Huus eapa...@gmail.com wrote: On Fri, Jul 11, 2014 at 4:03 PM, Gerald Combs ger...@wireshark.org wrote: On 7/7/14 9:10 PM, Evan Huus wrote: On Sun, Jul 6, 2014 at 12:59 PM, Alexis La Goutte alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:49 PM, Evan Huus eapa...@gmail.com It would be nice to have different tags for Refs-Bug and Fixes-Bug, and have the bugzilla integration do The Right Thing for changes that refer to but do not fix a bug. Gerald, how easy is this? I believe OpenStack has a set of tags they use which we might look to for inspiration? +1 I like OpenStack tags : Closes-Bug: #1234567 -- use 'Closes-Bug' if the commit is intended to fully fix and close the bug being referenced. Partial-Bug: #1234567 -- use 'Partial-Bug' if the commit is only a partial fix and more work is needed. Related-Bug: #1234567 -- use 'Related-Bug' if the commit is merely related to the referenced bug. https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references How would Partial-Bug and Related-Bug differ for our purposes? Wouldn't they do the same thing (i.e. add a comment to the bug)? Could we get away with two tags: Ping-Bug: 12345 -- Add a comment to bug 12345 Bug (or Closes-Bug): 12345 -- Add a comment and mark it RESOLVED FIXED. Just Ping-Bug and Bug works for me. +1 (or Comment-Bug and Closes-Bug ?) So what are the current set of tags for this? I tried using Ping-Bug (on change 3314) and it ended up closing the bug on me... Until a few minutes ago any time bug followed by a number appeared in the commit message Gerrit would add a comment and close it. The specific JavaScript RE was \b[Bb]ug:?\s*#?(\d+)\b. As of now Gerrit should update Bugzilla only for the following footers. The RE is now \b(?:[Pp]ing-)?[Bb]ug:?\s*#?(\d+)\b: Ping-Bug: 12345 -- Only add a comment. Bug: 12345 -- Add a comment to the bug and close it. ___ 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] Ping-Bug?
On Fri, Aug 1, 2014 at 6:52 PM, Gerald Combs ger...@wireshark.org wrote: On 8/1/14 9:08 AM, Jeff Morriss wrote: On 07/13/14 14:05, Alexis La Goutte wrote: On Fri, Jul 11, 2014 at 10:06 PM, Evan Huus eapa...@gmail.com wrote: On Fri, Jul 11, 2014 at 4:03 PM, Gerald Combs ger...@wireshark.org wrote: On 7/7/14 9:10 PM, Evan Huus wrote: On Sun, Jul 6, 2014 at 12:59 PM, Alexis La Goutte alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:49 PM, Evan Huus eapa...@gmail.com It would be nice to have different tags for Refs-Bug and Fixes-Bug, and have the bugzilla integration do The Right Thing for changes that refer to but do not fix a bug. Gerald, how easy is this? I believe OpenStack has a set of tags they use which we might look to for inspiration? +1 I like OpenStack tags : Closes-Bug: #1234567 -- use 'Closes-Bug' if the commit is intended to fully fix and close the bug being referenced. Partial-Bug: #1234567 -- use 'Partial-Bug' if the commit is only a partial fix and more work is needed. Related-Bug: #1234567 -- use 'Related-Bug' if the commit is merely related to the referenced bug. https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references How would Partial-Bug and Related-Bug differ for our purposes? Wouldn't they do the same thing (i.e. add a comment to the bug)? Could we get away with two tags: Ping-Bug: 12345 -- Add a comment to bug 12345 Bug (or Closes-Bug): 12345 -- Add a comment and mark it RESOLVED FIXED. Just Ping-Bug and Bug works for me. +1 (or Comment-Bug and Closes-Bug ?) So what are the current set of tags for this? I tried using Ping-Bug (on change 3314) and it ended up closing the bug on me... Until a few minutes ago any time bug followed by a number appeared in the commit message Gerrit would add a comment and close it. The specific JavaScript RE was \b[Bb]ug:?\s*#?(\d+)\b. As of now Gerrit should update Bugzilla only for the following footers. The RE is now \b(?:[Pp]ing-)?[Bb]ug:?\s*#?(\d+)\b: Ping-Bug: 12345 -- Only add a comment. Bug: 12345 -- Add a comment to the bug and close it. Awesome, thanks! Just wondering, in hindsight, if we should reverse it so Closes-Bug closes and Bug just posts a comment. Otherwise I I'm sure somebody will do blah blah blah like in bug in a commit message and accidentally close that bug. Thoughts? Evan ___ 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] Ping-Bug?
On 8/1/14 3:58 PM, Evan Huus wrote: On Fri, Aug 1, 2014 at 6:52 PM, Gerald Combs ger...@wireshark.org mailto:ger...@wireshark.org wrote: On 8/1/14 9:08 AM, Jeff Morriss wrote: On 07/13/14 14:05, Alexis La Goutte wrote: On Fri, Jul 11, 2014 at 10:06 PM, Evan Huus eapa...@gmail.com mailto:eapa...@gmail.com wrote: On Fri, Jul 11, 2014 at 4:03 PM, Gerald Combs ger...@wireshark.org mailto:ger...@wireshark.org wrote: On 7/7/14 9:10 PM, Evan Huus wrote: On Sun, Jul 6, 2014 at 12:59 PM, Alexis La Goutte alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:49 PM, Evan Huus eapa...@gmail.com mailto:eapa...@gmail.com It would be nice to have different tags for Refs-Bug and Fixes-Bug, and have the bugzilla integration do The Right Thing for changes that refer to but do not fix a bug. Gerald, how easy is this? I believe OpenStack has a set of tags they use which we might look to for inspiration? +1 I like OpenStack tags : Closes-Bug: #1234567 -- use 'Closes-Bug' if the commit is intended to fully fix and close the bug being referenced. Partial-Bug: #1234567 -- use 'Partial-Bug' if the commit is only a partial fix and more work is needed. Related-Bug: #1234567 -- use 'Related-Bug' if the commit is merely related to the referenced bug. https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references How would Partial-Bug and Related-Bug differ for our purposes? Wouldn't they do the same thing (i.e. add a comment to the bug)? Could we get away with two tags: Ping-Bug: 12345 -- Add a comment to bug 12345 Bug (or Closes-Bug): 12345 -- Add a comment and mark it RESOLVED FIXED. Just Ping-Bug and Bug works for me. +1 (or Comment-Bug and Closes-Bug ?) So what are the current set of tags for this? I tried using Ping-Bug (on change 3314) and it ended up closing the bug on me... Until a few minutes ago any time bug followed by a number appeared in the commit message Gerrit would add a comment and close it. The specific JavaScript RE was \b[Bb]ug:?\s*#?(\d+)\b. As of now Gerrit should update Bugzilla only for the following footers. The RE is now \b(?:[Pp]ing-)?[Bb]ug:?\s*#?(\d+)\b: Ping-Bug: 12345 -- Only add a comment. Bug: 12345 -- Add a comment to the bug and close it. Awesome, thanks! Just wondering, in hindsight, if we should reverse it so Closes-Bug closes and Bug just posts a comment. Otherwise I I'm sure somebody will do blah blah blah like in bug in a commit message and accidentally close that bug. The current actions should be limited to footers, so we should be safe from bug elsewhere in the commit message. ___ 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] Ping-Bug?
On Fri, Aug 1, 2014 at 7:03 PM, Gerald Combs ger...@wireshark.org wrote: On 8/1/14 3:58 PM, Evan Huus wrote: On Fri, Aug 1, 2014 at 6:52 PM, Gerald Combs ger...@wireshark.org mailto:ger...@wireshark.org wrote: On 8/1/14 9:08 AM, Jeff Morriss wrote: On 07/13/14 14:05, Alexis La Goutte wrote: On Fri, Jul 11, 2014 at 10:06 PM, Evan Huus eapa...@gmail.com mailto:eapa...@gmail.com wrote: On Fri, Jul 11, 2014 at 4:03 PM, Gerald Combs ger...@wireshark.org mailto:ger...@wireshark.org wrote: On 7/7/14 9:10 PM, Evan Huus wrote: On Sun, Jul 6, 2014 at 12:59 PM, Alexis La Goutte alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:49 PM, Evan Huus eapa...@gmail.com mailto:eapa...@gmail.com It would be nice to have different tags for Refs-Bug and Fixes-Bug, and have the bugzilla integration do The Right Thing for changes that refer to but do not fix a bug. Gerald, how easy is this? I believe OpenStack has a set of tags they use which we might look to for inspiration? +1 I like OpenStack tags : Closes-Bug: #1234567 -- use 'Closes-Bug' if the commit is intended to fully fix and close the bug being referenced. Partial-Bug: #1234567 -- use 'Partial-Bug' if the commit is only a partial fix and more work is needed. Related-Bug: #1234567 -- use 'Related-Bug' if the commit is merely related to the referenced bug. https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references How would Partial-Bug and Related-Bug differ for our purposes? Wouldn't they do the same thing (i.e. add a comment to the bug)? Could we get away with two tags: Ping-Bug: 12345 -- Add a comment to bug 12345 Bug (or Closes-Bug): 12345 -- Add a comment and mark it RESOLVED FIXED. Just Ping-Bug and Bug works for me. +1 (or Comment-Bug and Closes-Bug ?) So what are the current set of tags for this? I tried using Ping-Bug (on change 3314) and it ended up closing the bug on me... Until a few minutes ago any time bug followed by a number appeared in the commit message Gerrit would add a comment and close it. The specific JavaScript RE was \b[Bb]ug:?\s*#?(\d+)\b. As of now Gerrit should update Bugzilla only for the following footers. The RE is now \b(?:[Pp]ing-)?[Bb]ug:?\s*#?(\d+)\b: Ping-Bug: 12345 -- Only add a comment. Bug: 12345 -- Add a comment to the bug and close it. Awesome, thanks! Just wondering, in hindsight, if we should reverse it so Closes-Bug closes and Bug just posts a comment. Otherwise I I'm sure somebody will do blah blah blah like in bug in a commit message and accidentally close that bug. The current actions should be limited to footers, so we should be safe from bug elsewhere in the commit message. The current RE are bounded by \b which is just a word boundary. Is it safe because the RE are only run against the footers in the first place (Gerrit does that for us?) or did you mean to bound them with ^ and $ (which might be safer anyways). ___ 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] Ping-Bug?
On 8/1/14 4:06 PM, Evan Huus wrote: On Fri, Aug 1, 2014 at 7:03 PM, Gerald Combs ger...@wireshark.org mailto:ger...@wireshark.org wrote: On 8/1/14 3:58 PM, Evan Huus wrote: On Fri, Aug 1, 2014 at 6:52 PM, Gerald Combs ger...@wireshark.org mailto:ger...@wireshark.org mailto:ger...@wireshark.org mailto:ger...@wireshark.org wrote: On 8/1/14 9:08 AM, Jeff Morriss wrote: On 07/13/14 14:05, Alexis La Goutte wrote: On Fri, Jul 11, 2014 at 10:06 PM, Evan Huus eapa...@gmail.com mailto:eapa...@gmail.com mailto:eapa...@gmail.com mailto:eapa...@gmail.com wrote: On Fri, Jul 11, 2014 at 4:03 PM, Gerald Combs ger...@wireshark.org mailto:ger...@wireshark.org mailto:ger...@wireshark.org mailto:ger...@wireshark.org wrote: On 7/7/14 9:10 PM, Evan Huus wrote: On Sun, Jul 6, 2014 at 12:59 PM, Alexis La Goutte alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com mailto:alexis.lagou...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:49 PM, Evan Huus eapa...@gmail.com mailto:eapa...@gmail.com mailto:eapa...@gmail.com mailto:eapa...@gmail.com It would be nice to have different tags for Refs-Bug and Fixes-Bug, and have the bugzilla integration do The Right Thing for changes that refer to but do not fix a bug. Gerald, how easy is this? I believe OpenStack has a set of tags they use which we might look to for inspiration? +1 I like OpenStack tags : Closes-Bug: #1234567 -- use 'Closes-Bug' if the commit is intended to fully fix and close the bug being referenced. Partial-Bug: #1234567 -- use 'Partial-Bug' if the commit is only a partial fix and more work is needed. Related-Bug: #1234567 -- use 'Related-Bug' if the commit is merely related to the referenced bug. https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references How would Partial-Bug and Related-Bug differ for our purposes? Wouldn't they do the same thing (i.e. add a comment to the bug)? Could we get away with two tags: Ping-Bug: 12345 -- Add a comment to bug 12345 Bug (or Closes-Bug): 12345 -- Add a comment and mark it RESOLVED FIXED. Just Ping-Bug and Bug works for me. +1 (or Comment-Bug and Closes-Bug ?) So what are the current set of tags for this? I tried using Ping-Bug (on change 3314) and it ended up closing the bug on me... Until a few minutes ago any time bug followed by a number appeared in the commit message Gerrit would add a comment and close it. The specific JavaScript RE was \b[Bb]ug:?\s*#?(\d+)\b. As of now Gerrit should update Bugzilla only for the following footers. The RE is now \b(?:[Pp]ing-)?[Bb]ug:?\s*#?(\d+)\b: Ping-Bug: 12345 -- Only add a comment. Bug: 12345 -- Add a comment to the bug and close it. Awesome, thanks! Just wondering, in hindsight, if we should reverse it so Closes-Bug closes and Bug just posts a comment. Otherwise I I'm sure somebody will do blah blah blah like in bug in a commit message and accidentally close that bug. The current actions should be limited to footers, so we should be safe from bug elsewhere in the commit message. The current RE are bounded by \b which is just a word boundary. Is it safe because the RE are only run against the footers in the first place (Gerrit does that for us?) or did you mean to bound them with ^ and $ (which might be safer anyways). I tried ^ in the RE but it didn't work. Apparently the multiline option isn't enabled in commentlinks and I didn't see a way to enable it. Footers are enforced elsewhere. ___ 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] Ping-Bug?
On 08/01/2014 06:52 PM, Gerald Combs wrote: Until a few minutes ago any time bug followed by a number appeared in the commit message Gerrit would add a comment and close it. The specific JavaScript RE was \b[Bb]ug:?\s*#?(\d+)\b. Ah, OK, I could have sworn I had seen it working before. Maybe I was just hallucinating... ___ 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] master 6b11cd9: Make Lua taps work in out-of-source-tree builds.
Thanks Jeff, this gets me farther however lua out-of-tree is still failing
for me, and it's actually because it can't find init.lua this time :)
The error I am getting is: attempt to call global 'typeof' (a nil value)
typeof is a function defined in init.lua (which is in ${BUILD_DIR}/epan/
for me using cmake).
On Fri, Aug 1, 2014 at 9:00 PM, Wireshark code review
code-review-do-not-re...@wireshark.org wrote:
URL:
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=6b11cd97f2153bb015ade6efd0592de85457
Submitter: Evan Huus (eapa...@gmail.com)
Changed: branch: master
Repository: wireshark
Commits:
6b11cd9 by Jeff Morriss (jeff.morriss...@gmail.com):
Make Lua taps work in out-of-source-tree builds.
make-taps.pl needs to know where to find the source files otherwise
none of
the tap data gets built correctly.
This makes the wslua test suite run in out-of-source-tree builds too.
Change-Id: I059474d90d59e87bd57dba18530a66a927a014cf
Reviewed-on: https://code.wireshark.org/review/3337
Reviewed-by: Evan Huus eapa...@gmail.com
Actions performed:
from 69d0788 CompiledFilterOutput dialog fixes and updates.
adds 6b11cd9 Make Lua taps work in out-of-source-tree builds.
Summary of changes:
epan/wslua/CMakeLists.txt |1 +
epan/wslua/Makefile.am|8
epan/wslua/make-taps.pl | 16 +---
3 files changed, 14 insertions(+), 11 deletions(-)
___
Sent via:Wireshark-commits mailing list
wireshark-comm...@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-commits
Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
mailto:wireshark-commits-requ...@wireshark.org
?subject=unsubscribe
___
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] master 6b11cd9: Make Lua taps work in out-of-source-tree builds.
Ahhh... The problem is cmake puts the generated files in the wrong
directory (epan/ instead of epan/wslua/).
/* load system's init.lua */
if (running_in_build_directory()) {
/* Running from build directory, load generated file */
filename = g_strdup_printf(%s G_DIR_SEPARATOR_S epan G_DIR_SEPARATOR_S
wslua
G_DIR_SEPARATOR_S init.lua,
get_progfile_dir());
I saw that when doing this change (I even tried to move the output of
make-taps.pl into the wslua directory when making the below change only
to find that the directory doesn't even exist in the build directory).
I'll leave that to someone who understands cmake...
On 08/01/2014 09:10 PM, Evan Huus wrote:
Thanks Jeff, this gets me farther however lua out-of-tree is still
failing for me, and it's actually because it can't find init.lua this
time :)
The error I am getting is: attempt to call global 'typeof' (a nil value)
typeof is a function defined in init.lua (which is in ${BUILD_DIR}/epan/
for me using cmake).
On Fri, Aug 1, 2014 at 9:00 PM, Wireshark code review
code-review-do-not-re...@wireshark.org
mailto:code-review-do-not-re...@wireshark.org wrote:
URL:
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=6b11cd97f2153bb015ade6efd0592de85457
Submitter: Evan Huus (eapa...@gmail.com mailto:eapa...@gmail.com)
Changed: branch: master
Repository: wireshark
Commits:
6b11cd9 by Jeff Morriss (jeff.morriss...@gmail.com
mailto:jeff.morriss...@gmail.com):
Make Lua taps work in out-of-source-tree builds.
make-taps.pl http://make-taps.pl needs to know where to find the
source files otherwise none of
the tap data gets built correctly.
This makes the wslua test suite run in out-of-source-tree
builds too.
Change-Id: I059474d90d59e87bd57dba18530a66a927a014cf
Reviewed-on: https://code.wireshark.org/review/3337
Reviewed-by: Evan Huus eapa...@gmail.com
mailto:eapa...@gmail.com
Actions performed:
from 69d0788 CompiledFilterOutput dialog fixes and updates.
adds 6b11cd9 Make Lua taps work in out-of-source-tree builds.
___
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
