a theme-specific icon (and as such hicolor is where applications should
install their icons). So: don't install some of our icons in the gnome area,
install them all in hicolor.
While we're at it, go ahead and install all the icon sizes we have.
If we're on SuSE, use their desktop-file-updater macro; without that they
won't recognize our desktop file.
Fix bug which prevented the MIME database from being updated if our install
prefix is not /usr .
svn path=/trunk/; revision=48204
The problem with listing these package names (which I think is convenient)
is that different distros have different names for some packages. So:
update to work on OpenSuSE.
svn path=/trunk/; revision=48160
Use the prefix from 'configure' in the RPM (so: to build an RPM which installs
in /opt do "./configure --prefix=/opt && make rpm-package").
(Maybe this approach should also be used for the other options in the .spec
file.)
Only clean up if building the RPM was successful.
svn path=/trunk/; revision=47957
install in a non-standard location.
Assume the desktop-integration stuff goes in /usr (regardless of our prefix).
This (with r47914) fixes RPM generation when someone uses a prefix other than
/usr .
Also: run desktop-file-validate on the wireshark.desktop file (just in case it
wasn't installed with desktop-file-install).
svn path=/trunk/; revision=47916
both the installer and uninstaller. Roll the .exe removal code into a
loop and add missing executables.
Add modelines and adjust accordingly.
svn path=/trunk/; revision=47785
mutex may not be visible to other sessions and we may not be able to
create a global mutex. Try to create both, and make each one accessible
to all users. Update the NSIS installer to check for both global and
session mutexes.
svn path=/trunk/; revision=47773
is running" mutex. Have the NSIS installer check for this mutex and ask
the user to close Wireshark if it's found. While not perfect this makes
the WinSparkle update process much less annoying.
svn path=/trunk/; revision=47758
preferences (currently hidden) to disable updates, set the update
frequency, and set the update "channel" (stable vs development). Add a
"Help" menu item to manually check for updates.
svn path=/trunk/; revision=47748
Fedora's .spec file. Changes include:
- Create a separate wireshark-gnome package (like Redhat).
- Control some things with variables set at the top of the file.
- Allow the user to configure how dumpcap is installed.
- Allow the user to choose some options including GTK2 or GTK3.
- Greatly expand the BuildRequires entries; get the minimum versions of some
things from 'configure'.
- Install freedesktop files for better (free)desktop integration.
svn path=/trunk/; revision=47528
/Applications/Xcode.app/Developer first (for Xcode 4 and later) and, if
we don't find that, look for /Developer.
Don't assume packagemaker is under $developer_path/usr/bin - with Xcode
4, you need to install Auxiliary Tools for Xcode to get PackageMaker,
and even that doesn't directly install the packagemaker command, so we
currently advise people to copy the PackageMaker binary to
/usr/bin/packagemaker.
svn path=/trunk/; revision=46957
puts them. If you choose to use MacPorts versions of the library, edit
the script or run it with -l.
Update the usage message and fix a typo.
svn path=/trunk/; revision=46955
appears at the end - if the user's installed an up-to-date version of
file to, for example, get pcap-ng files identified (Apple hasn't updated
file in *ages* - they're still in file 5.04!), it will report, for
example, "Mach-O 64-bit x86_64 executable" rather than "Mach-O 64-bit
executable x86_64" for an x86-64 binary.
svn path=/trunk/; revision=46954
lines rather than 2. Add 2 new extensions to common.nsh.
Not sure if changes to wireshark.ini are necessary, copied what was done
for "Field 7", which is also just a label.
svn path=/trunk/; revision=46337
If the source codes are checked out using TortoiseSVN on Windows,
"nmake -f Makefile.nmake packaging_papps" fails in the middle.
This is because the line end of packaging\nsis\wireshark.nsi is CRLF in
this case, and ws-manifest.pl cannot handle such case.
svn path=/trunk/; revision=45798
defined/undefined checks. Create a bunch of them corresponding to the
various components that GTK2 and GTK3 need and plumb the packaging files
accordingly. Tested only with GTK2 but GTK3 *should* work.
svn path=/trunk/; revision=45659
- Make it possible to set PROGRAM_NAME in environment.
- Update the comment about setting program name it *should* work now.
svn path=/trunk/; revision=45582
Detect if ./wireshark-qt/qtshark.exe is present and add a option to install Qtshark (Experimental), also add a shortcut.
The option to install qtshark is disable by default (for the moment...)
Now qtshark is (normally) available in automated build !
svn path=/trunk/; revision=45485
wireshark-win{32,64}-libs instead. In win-setup.sh only try to unzip
files ending in .zip. PortableApps and U3 packaging changes are untested.
svn path=/trunk/; revision=44888
/d" instead of "copy" in Makefile.nmake. Fix the uninstall.exe path in
packaging\nsis\Makefile.nmake. This keeps us from clobbering existing
files in wireshark-gt2 unnecessarily.
svn path=/trunk/; revision=43976
http://blogs.msdn.com/b/astebner/archive/2010/10/20/10078468.aspx
and bug 7507 the Visual C++ 2010 redistributable installer might want
to reboot the system. Tell it not to do that and request a reboot at
the end of the installation process if needed.
svn path=/trunk/; revision=43864
common parts to common.nsh. Creating an installer now requires two
NSIS runs:
- uninstaller.nsi, which creates an installer (uninstall_installer.exe)
that only writes uninstall.exe to ../../wireshark-gtk2.
- wireshark.nsi, which bundles uninstall.exe along with the rest of
our installation files.
If we ever get around to signing our executables this will let us sign
all of them. It also cleans up the .nsi file contents a bit.
Instead of keeping separate list of file extensions, manage them from
a single macro. Print the extensions we register / deregister in the
detail pane.
svn path=/trunk/; revision=43236
Say "Pcap" rather than "Libpcap" - pcap format is used by WinPcap as
well (and it's also read and written by this library called Wiretap
:-)).
Add an additional entry for pcap-NG.
svn path=/trunk/; revision=42328
keys. Sort the keys by name. Calculate the installation size after all
of the files have been installed and add that in the "EstimatedSize"
key. Fix the display icon. Add a hint about our target platform. Add
version information.
We now look like a grown-up application in the Programs and Features
control panel.
svn path=/trunk/; revision=41914
Alcatel (now Alcatel-Lucent) buy Xylan in 1999...
And now Attributs RADIUS is used in Alcatel-Lucent Omniswitch Product.
svn path=/trunk/; revision=41474
distribution.
To do this, however, requires renaming that directory because automake can't
handle files with spaces in their names.
svn path=/trunk/; revision=41040
Cisco and Vodafone Diameter AVP:s
I have axtracted the relevant vendor AVP:s and separated them out in Vendor specific xml files.
Part of https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5972
svn path=/trunk/; revision=37627
My attachment adds a link to a XSLT file to the preamble of the PDML.
The XSLT will transform the PDML to a HTML page, and the HTML page
features a look similar to Wireshark. See
http://cubic.org/~doj/ebay/a.pdml for an example.
The patch also contains a small perl program which converts the
Wireshark colortable into javascript code which is used in the XSLT
file. If you want to use a different color scheme you would execute the
perl program and insert the generated javascript function into your XSLT
file.
To view the HTML you could either place the PDML and XSLT file on your
webserver and verify that your webserver sends the PDML file as
"text/xml". Then your webbrowser will find the linked XSLT file,
download that as well and convert the PDML to HTML on the fly.
You could also use an XSLT processor like xsltproc to convert the PDML
and XSLT into a static HTML file.
From me:
Minor fixups.
svn path=/trunk/; revision=37298
PackageMaker would be a more correct fix. Replacing PackageMaker with
something that fits our development and deployment model would be an
even more correct fix.
svn path=/trunk/; revision=37167