wiretap and gtk+-1.1.x. I also added an #include to util.c to keep
it from complaining about a lack of a definition of vsnprintf when
compiling with gtk+-1.1.x.
svn path=/trunk/; revision=136
Tests for GTK versions are done during compilation, not during "./configure".
The big problems have been taken care of in this patch (functional change
in the packet clist and conversion of menu_factory to item_factory), but
plenty of smaller problems with dialogue boxes abound. I have fixed
a small problem with file_open*(), but have left 2 comments in just in case
I'm not going about this the right way. Can someone verify?
svn path=/trunk/; revision=127
for the queries or replies first, then create and add the subtree and
populate it, and, when that's done, set the length of the item
appropriately; if you add the subtree later, the subtree's top-level
node appears to have level 0, rather than 1 greater than the tree of
which it's a subtree, which causes those trees not to print correctly.
svn path=/trunk/; revision=122
in "get_nbns_name()", and have "get_nbns_name_type_class()" call it.
Use "get_nbns_name()" rather than "get_nbns_name_type_class()" in the
NBDS code, as there aren't any type or class fields in an NBDS packet.
Show the data in an NBDS datagram as raw data. (We don't have an SMB
parser yet.)
Don't dissect anything past the header if an NBDS packet is an unknown
packet type.
svn path=/trunk/; revision=117
entry.
Show, for each RIP entry, a summary line with, for IP routes, the
destination and metric, as well as showing the detailed breakdown below
it.
Dissect authentication entries.
svn path=/trunk/; revision=114
macro (modeled after similar macros provided with "autoconf") to check
whether "struct sockaddr" has an "sa_len" member, and defines or
undefines "HAVE_SA_LEN" appropriately. Use it instead of
"AC_LBL_SOCKADDR_SA_LEN", and use "HAVE_SA_LEN" instead of
"HAVE_SOCKADDR_SA_LEN".
svn path=/trunk/; revision=96
"wiretap" subdirectory, and thus leave a "config.status" file around so
that one of the "auto{make,configure,header}" guys doesn't complain when
rebuilding stuff that it can't open "config.status". (The
"automake"-generated Makefile will recurse into "wiretap", and, at least
if you're doing builds from a tree freshly checked out from CVS, "XXX"
files will probably have been checked out before "XXX.in", so "make"
will try to reconstruct the "XXX" files from the "XXX.in" files.)
That also obviates the need to make "wiretap/Makefile" here.
We can also re-delete "wiretap/Makefile" from CVS - the problem that
caused me to bring it back wasn't caused by its absence, it was caused
by the above. As "Makefile"s generated by "configure" scripts depend on
the particular system on which you ran "configure", there's no One True
Makefile so "Makefile" should'n't be under CVS.
svn path=/trunk/; revision=95
the many complaints you get if you do a "configure" followed by a "make"
in a freshly-checked-out Ethereal source tree (it bitches when, or maybe
after, "automake"ing it, complaining about not being able to open
"config.status" - the right fix might be to make the "configure" script
recurse).
svn path=/trunk/; revision=94
CVS; it's generated by the "configure" script, and the resulting
Makefile is platform-dependent, so there's no One True Makefile to put
under CVS.
svn path=/trunk/; revision=93