But *do* get rid of the pre-launchd XQuartzFixer startup item; it's
probably not there, but we might as well leave things as clean as we
can.
Change-Id: Icfdbe6c0d022cde8cf30bd3c79fbf77896e6fe98
Reviewed-on: https://code.wireshark.org/review/30322
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Take away group write permission for stuff under
/Library/Application Support/Wireshark. For some reason, it's getting
set; it's not necessary.
Change-Id: I4280a635e0c171cf5ad17cb91fe20d746c2daf79
Reviewed-on: https://code.wireshark.org/review/30317
Reviewed-by: Guy Harris <guy@alum.mit.edu>
They don't need it; read permission suffices.
While we're at it, rename a variable to indicate that it's the path to
the plist for ChmodBPF, not the path to the executable for ChmodBPF.
Change-Id: Ib7537e26ae3f4477c4110759049a8cd7d2f09cf6
Reviewed-on: https://code.wireshark.org/review/30303
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Qt5CoreConfigExtras.cmake sets Qt5::qmake. Use it to find the
corresponding path to macdeployqt and use those in osx-app.sh.
Change-Id: I2e67f0126e272fc95d40476b9bfc83ab38d73cee
Reviewed-on: https://code.wireshark.org/review/28359
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
If it's run as "tshark", it should run TShark, not Wireshark.
Bug: 14643
Change-Id: I0d4e6fa64e42b7a2e2d4b89b53db62748b4f288d
Reviewed-on: https://code.wireshark.org/review/27245
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It has been replaced by cmake.
Change-Id: I83a5eddb8645dbbf6bca9f026066d2e995d8e87a
Reviewed-on: https://code.wireshark.org/review/26969
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Remove GTK+ entries from .gitignore and start removing it from
packaging.
Change-Id: I70391000906e983eab250c8158b486c3dc6d4a16
Reviewed-on: https://code.wireshark.org/review/26988
Reviewed-by: Gerald Combs <gerald@wireshark.org>
MaxMind is discontinuing its legacy databases in April in favor of
GeoIP2, which use a newer database format (MaxMind DB). The reference C
library (libmaxminddb) is available under the Apache 2.0 license which
isn't quite compatible with ours.
Add mmdbresolve, a utility that reads IPv4 and IPv6 addresses on stdin
and prints resolved information on stdout. Place it under a liberal
license (MIT) so that we can keep libmaxminddb at arm's length. Add
epan/maxmind_db.[ch], which spawns mmdbresolve and communicates with it
via stdio.
Migrate the preferences and documentation to MaxMindDB.
Change the IPv4 and IPv6 asnum fields to FT_UINT32s. Change the
geographic coordinate fields to FT_DOUBLEs.
Bug: 10658
Change-Id: I24aeed637bea1b41d173270bda413af230f4425f
Reviewed-on: https://code.wireshark.org/review/26214
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Remove the endpoint map and its button from the Qt and GTK+ UIs. It
depends on GeoIP Legacy for coordinate information and those databases
are being deprecated in favor of MaxMind DB. We *could* upgrade the code
to use mmdbresolve, but according to
https://dev.maxmind.com/geoip/geoip2/geolite2/ they're also going to
remove coordinate information from GeoLite2:
"In addition, in 2019, latitude and longitude coordinates in the
GeoLite2 databases will be removed.* Latitude and longitude coordinates
will continue to be provided in GeoIP2 databases. Please check back for
updates."
Change-Id: I43e1593d282a0f1aae897b1f4724117d1496b21e
Reviewed-on: https://code.wireshark.org/review/26229
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
See if that makes it possible for CrashReporter to fully symbolicate
crash dumps, so the user gets line numbers and the like in crash dumps
from the OS, and we get them if the user sends a crash dump to us.
Change-Id: I8bb48b2d2f6b3e23fea43c1a3bd3a5a9a97a5c2c
Reviewed-on: https://code.wireshark.org/review/26123
Reviewed-by: Guy Harris <guy@alum.mit.edu>
There's no Wireshark.app/Contents/Resources/bin directory; remove the
variable containing its path, and the part of an error message that
refers to it.
Change-Id: Id41cc00a2671925c50b2075dd3e9d0f84d5bd921
Reviewed-on: https://code.wireshark.org/review/26039
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Instead of using the never-defined $binpath (undefined going back to at
least Wireshark 1.0.0 - is it a leftover from the Inkscape version?),
use $bundle_binary_list, to strip all the executables with strip -ur.
(Not that we want to strip anything - we don't even want the debugging
symbols stripped! - but for cleanliness.)
Change-Id: I9c3520ffb418bf9dc206d3ccb55d347c208f3be2
Reviewed-on: https://code.wireshark.org/review/26033
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We no longer have the code to create a bundle, as we rely on CMake
having done so, at least to the extent of populating the bundle with all
the files we've generated. Get rid of the code that used to support it,
and the command-line options that are no longer necessary now that we no
longer build code bundles.
Don't have explicit lists of CLI or extcap binaries; instead, just look
for all plain files in Wireshark.app/Contents/MacOS that have read and
execute permissions for owner/group/user. That way, we don't have to
update the script if we add new binaries or new directories of binaries.
Change-Id: I047296a7889bea71165eebde10f34bec6ea96cc5
Reviewed-on: https://code.wireshark.org/review/26032
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It may find files that aren't Mach-O binary files. Instead, rename
cs_binary_list to bundle_binary_list, and use it when checking for
dependencies as well as when code-signing binaries.
Change-Id: I9d17a4ba137e494fbd38db1b62f5cc7e4b620fc9
Reviewed-on: https://code.wireshark.org/review/26028
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Just use "find" to find plain files under $pkglib and $pkgexec; this
avoids trying to run otool on directories, which can cause it to stop
looking in $pkgexec/* past the extcap directory, and does try to run it
on the Qt frameworks in subdirectories under $pkglib.
Add a comment giving more details about the big command to find
dependencies.
Change-Id: Ife3c3a8493ca0b6ea28f1bb108f63714366abeed
Reviewed-on: https://code.wireshark.org/review/26003
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Unstripped binaries should allow better stack traces in the
CrashReporter files.
Change-Id: Idb2f11cd664dc62331f3394dee09abcd4e88f897
Reviewed-on: https://code.wireshark.org/review/25977
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Some versions of otool print the file name as the first line when you
run it with -hv, so that the line containing the file type is the fourth
line; others don't print it, so that it's the third line. Instead, look
for the line that has MH_MAGIC.
Change-Id: Ib14f6b24f14069532263332e53a1e9895663641a
Reviewed-on: https://code.wireshark.org/review/25968
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That way we don't have to change the script if we add new plugin
subdirectories.
Change-Id: Ic788807c723306e461b7c1f8721b48a46d4fff96
Reviewed-on: https://code.wireshark.org/review/25584
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We now have "epan" and "wiretap" subdirectories of the plugin directory,
with the first containing libwireshark plugins and the second containing
libwiretap plugins. Look for plugins in those directories, rather than
in the top-level plugin directory.
Bug: 14389
Change-Id: Ia3bd4d27e82215207e7a7dcfc8f91042bbc61737
Reviewed-on: https://code.wireshark.org/review/25577
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Make plugins.c the source of truth for plugin names. Where plugins
reside and what they do are two different things, so split the plugin
directory and description into two separate elements.
CMake creates portable[1] builds on Windows and macOS. That is, the
build-time directory layout is the same as the installation directory
layout. Adjust various plugin paths macOS accordingly.
[1] You have to run osx-app.sh on macOS to prepare the application
bundle, but the goal is to create a directory/bundle that can be moved
or copied to a different system and run in the new location.
Change-Id: Icf9d02e61918fdf1404468baf52542910edf2743
Reviewed-on: https://code.wireshark.org/review/25166
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
At one point, I remember a discussion resulting in the official name of
the next-generation replacement for pcap format being changed to
"pcapng", with no hyphen.
Make Wireshark reflect that.
Change-Id: Ie66fb13a0fe3a8682143106dab601952e9154e2a
Reviewed-on: https://code.wireshark.org/review/25214
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Rename osx-app.sh to osx-app.sh.in and add the version to the plugin
path at configure time.
Instead up updating Autotools accordingly just remove the macOS
packaging targets. gf61c381b5a removed support for Autotools in
osx-app.sh and if anyone wants to build macOS packages I'd prefer that
they use the same toolchain as the buildbot.
Change-Id: Ide5205265bf8859a85b1afab68fa8f8285952bd3
Reviewed-on: https://code.wireshark.org/review/23839
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Remove Autotools-specific code from osx-app.sh. The official builders
have used CMake for a while and as far as I know no one else uses our
packaging scripts.
Change-Id: I6fc20114b42e10dacc69346c379055b68184b85c
Reviewed-on: https://code.wireshark.org/review/23833
Reviewed-by: Anders Broman <a.broman58@gmail.com>
rpathify_dir is not recursive so the plugin path fix in g94af9724d1
wasn't sufficient. Make sure $pkgplugin is set to the versioned plugin
subdirectory so that both rpathification and code signing work.
Find the Qt frameworks directory using qmake while we're here. This
should be more reliable than calling pkg-config (which doesn't work on
my laptop).
Bug: 14096
Change-Id: I0196015f849fd27994a439359cddd88c21106fde
Reviewed-on: https://code.wireshark.org/review/23832
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Use macOS when not referring to a particular release; use the
appropriate name when referring to a particular release.
Change-Id: I9293d4db7c91d7c859d7c067c0f0b3c9c482fcc5
Reviewed-on: https://code.wireshark.org/review/20935
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Avoid anachronisms, however; there was no "macOS 10.0" or even "OS X
10.0", for example. It was "Mac OS X" until 10.8 (although 10.7 was
sometimes called "OS X" and sometimes called "Mac OS X"), and it was "OS
X" from 10.8 to 10.11.
Change-Id: Ie4a848997dcc6c45c2245c1fb84ec526032375c3
Reviewed-on: https://code.wireshark.org/review/20933
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This reverts commit 3cfa4f7602.
Nope, *not* needed, and not wanted, either.
Change-Id: I71ac174a9b9b19980d0a6f44088d0a66f71ef99b
Reviewed-on: https://code.wireshark.org/review/19538
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We can't just symbolically link to the executables, as that means that
the executable won't be in Contents/MacOS, which means that all
@executable_path-relative references will go to the wrong place if we
run the executables using the symlink, which means that the executables
could fail (they *do* fail to find the Cocoa Qt plugin, for example).
So, instead, we go back to the old version of the utility launcher, and
put that in Contents/Resources/bin as well as, if the user requests the
CLI utilities, /usr/local/bin. Maybe PackageMaker will find that
acceptable and include them in the installer package.
Bug: 13270
Change-Id: I4016b58c9ce0df05d78525d35e53431750c2b4d9
Reviewed-on: https://code.wireshark.org/review/19536
Reviewed-by: Guy Harris <guy@alum.mit.edu>
PackageMaker appears not to put them into the installer package, so
construct them in the Wireshark post-install script.
Bug: 13270
Change-Id: Idfa10d4d123d2c0e2f7b3ad65888e075fbfd27a7
Reviewed-on: https://code.wireshark.org/review/19531
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Change-Id: I8ae8a1fdc8d0df0779ef119c527f41dac9e0dbdb
Reviewed-on: https://code.wireshark.org/review/19476
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Report that files /etc/paths.d/Wireshark and /etc/manpaths.d/Wireshark
are added and should be removed.
Change-Id: I2f9d3aea0dd4f86cb9a86065108a3948e28d3001
Reviewed-on: https://code.wireshark.org/review/19436
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
That way, $PATH points to .../Wireshark.app/Contents/Resources/bin, so
the man command will look in
.../Wireshark.app/Contents/Resources/share/man.
This also may obviate the need to install the wrapper scripts in
/usr/local/bin, although those scripts obviate the need to re-set PATH
after installing Wireshark.
Change-Id: I7202b5a0fe5d2b90c956dc0db2af073f6c08b00d
Reviewed-on: https://code.wireshark.org/review/19296
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Do for executables what we do for man pages.
Change-Id: I066f0199fd6064cae21e6ad079a1f344e1002c66
Reviewed-on: https://code.wireshark.org/review/18205
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Modify postinstall.sh script to add file /etc/manpaths.d/Wireshark
during installation.
Content of the file is the current path of the Wireshark manpages.
Bug: 12746
Change-Id: I1dc0dc9a2acf56c39c78c709294f1a6804c6ec5c
Reviewed-on: https://code.wireshark.org/review/17916
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Search the extcap binaries for shared libraries they require.
Treat libssh specially - for some reason, when built by macosx-setup.sh
(which just does a standard cmake build of libssh), libssh's shared
library has just libssh.4.dylib, not {installation
directory}/libssh.4.dylib, as its shared library ID, so we don't find
its binary using otool -L.
Bug: 12471
Change-Id: I3e5632d7520f1bbeca1a8faae3a012938ef9dee7
Reviewed-on: https://code.wireshark.org/review/16329
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Recompress PNGs using the current versions of various compressors:
optipng 0.7.6
advpng 1.20
advdef 1.20
pngcrush 1.8.1
Parallelize PNG compression. Note why we're not using a couple of other
compression utilities.
Change-Id: I52757d0bc2d424013e7f00b693a0f5378427cc31
Reviewed-on: https://code.wireshark.org/review/16209
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
(As pointed out by Gerald) .pfx files are (more commonly) PKCS#12 files.
People may be upset if we start grabbing them.
Change-Id: Iecf857d082b7f2a0ad4fdd1a932332fc3c9d9498
Reviewed-on: https://code.wireshark.org/review/15886
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
... at least for files for which have file extensions, including the gzip'd
versions of these files.
Add .pkt (Savvius) file extensions to our freedesktop.org registrations.
Change-Id: I0fb72909a1e9e3073451de06a64503fcfc6b57ed
Reviewed-on: https://code.wireshark.org/review/15694
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
This bug was introduced in g162edec9.
Change-Id: Ia7c6ab0ae35b9b0116c6c9396dfa6e5173967726
Reviewed-on: https://code.wireshark.org/review/15676
Reviewed-by: Stig Bjørlykke <stig@bjorlykke.org>
Register Wireshark for PacketLogger, ERF, IPFIX, and VWR files on
freedesktop.org, OS X, and Windows (we were already registered for ERF and VWR
files on Windows).
Change-Id: I8105997cb15ea06e1c078489fd88763d4ce9e40c
Reviewed-on: https://code.wireshark.org/review/15635
Petri-Dish: Jeff Morriss <jeff.morriss.ws@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
(Doing this for freedesktop.org-compliant systems requires adding a MIME type;
yes, I just made the application/x-micropross-mplog MIME type up.)
Change-Id: I11d8cc22571dd39984f8237d0ef995922bdfd15f
Reviewed-on: https://code.wireshark.org/review/15012
Petri-Dish: Jeff Morriss <jeff.morriss.ws@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
That lets the version of Wireshark built with autotools find the extcap
programs.
Don't install the extcap programs under ${datadir} - that puts it under
a share directory, and share directories are for platform-independent
files, which executable images aren't (they're instruction-set
dependent, hence platform-dependent).
Change-Id: I992eeb984bdbe6b3476777f7114628c83df6080f
Reviewed-on: https://code.wireshark.org/review/13943
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This new extcap is for testing and educational purpose.
It relies on rankpkt-core functions to generate random packets.
Change-Id: If6890f0673545682995a2079458108edc0913b30
Reviewed-on: https://code.wireshark.org/review/11764
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Make sshdump addition to the package conditional depending on whether
it is actually built.
Change-Id: Ifeaa134fdb3dcd88e48ff0c796f0c21c804eba77
Reviewed-on: https://code.wireshark.org/review/12023
Reviewed-by: Graham Bloice <graham.bloice@trihedral.com>
It can happen that the $binary_list contains apps that are not compiled
(eg. for the lack of a lib). In this case the binary can't be added to
the package. Fixed checking that the binary going to be signed is present.
Change-Id: Iefd9438de972302523ba28596e905b11513a4fea
Reviewed-on: https://code.wireshark.org/review/11968
Reviewed-by: Gerald Combs <gerald@wireshark.org>
sshdump is an extcap module that allows dumping from a remote host using an ssh connection.
It goes with the existing extcap plugin interface.
Change-Id: I8987614fdd817b8173a50130812bc643a4833bca
Reviewed-on: https://code.wireshark.org/review/11402
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
When creating a bundle using osx-app.sh (i.e. when we're using
Autotools), make sure we copy androiddump to the extcap subdirectory.
Change-Id: Iabb24ae969ae77856f15dd94120cc6e395311198
Reviewed-on: https://code.wireshark.org/review/11215
Reviewed-by: Gerald Combs <gerald@wireshark.org>
For libraries, instead of prefixing dependent library paths with
@executable_path/../Framework, prefix them with @rpath. This should let
us load them from different directory depths.
Remove any LC_RPATH not in an allowed list of prefixes. This should keep
us from leaking paths specific to the build environment and user, and
should make any portability problems more obvious.
Add either @executable_path/../Frameworks or
@executable_path/../../Frameworks as an LC_RPATH depending on which
actually exists. This lets us place androiddump in the extcap
subdirectory.
Add error checking in a few places and make sure we detect failures in
subshells.
Add a macdeployqt buglink.
Bug: 11620
Change-Id: I43ef02ecc6f741761fcb9827c0b0b7b2ef16fa9a
Reviewed-on: https://code.wireshark.org/review/11205
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Add a dmg_package_prep target as an alias to app_bundle. Rename the
osx-dmg target to dmg_package. This matches the Windows packaging
target names.
In osx-app.sh, make sure we rpathify the bundle plugin directory.
Change-Id: If41195c9d405ad6bff865625500a8227b77e8092
Reviewed-on: https://code.wireshark.org/review/10734
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Adding the additional rpath in the build process appears to have fixed
the problem I was trying to debug.
Change-Id: I518deea67837f7e084e503b8e5ae7c3f188df3c8
Reviewed-on: https://code.wireshark.org/review/9628
Reviewed-by: Guy Harris <guy@alum.mit.edu>
macdeployqt will stuff them into the bundle for us; exclude anything in
the Qt frameworks directory from the lists of dependencies for us to
copy or munge. (We don't copy them correctly - that results in the
underlying binary being copied to the Frameworks directory - and we
leave it up to macdeployqt to do the munging.)
Change-Id: I10cfb8dcb2abadde9d5c52252979267912710f80
Reviewed-on: https://code.wireshark.org/review/9627
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Qt 5.5 and later have @rpath-based install names for the frameworks,
which means that, if they're not installed in some frameworks directory
searched by default (such as /Library/Frameworks) - which is the default
case with the Qt installer - they won't be found by default.
Add the directory in which the frameworks exist as an rpath in the
Wireshark binary, so that they'll be found, and then remove it from the
Wireshark binary in the app bundle, as the directory in which the
frameworks exist on the machine on which Wireshark was built is
irrelevant to the machines on which it's being deployed - the frameworks
are included in the bundle, and we already add an rpath to find them
there.
Change-Id: I54e033743e7b17eab26976064dcd7cd000f97c78
Reviewed-on: https://code.wireshark.org/review/9625
Reviewed-by: Guy Harris <guy@alum.mit.edu>
I have some other hammers to try it hit it with to get it to actually
work with Qt 5.5.
Change-Id: Ie20ccbcee62fa48f768ba22478d07b9dc18d0139
Reviewed-on: https://code.wireshark.org/review/9623
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We need to preserve the full path of the framework binary.
Change-Id: I3a13eaffc07028a26fbd970db02cc1cce3fdcd5d
Reviewed-on: https://code.wireshark.org/review/9621
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That's easier than trying to carefully copy the relevant bits.
Change-Id: I2f174a735bf91f6434929c25ca33aced03e19597
Reviewed-on: https://code.wireshark.org/review/9620
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Copy only the stuff needed at run time; don't bother with all the
headers, etc..
Change-Id: Id9d2ec916b6742a6cb6e2ec3c0f7ed1a65a8a93c
Reviewed-on: https://code.wireshark.org/review/9617
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Do it in a loop, so we can change it to handle Qt 6 if, as, and when it
comes out (assuming they label its packages as Qt6Package).
Change-Id: I1d33d3e9726981b1940fb4409184c486628cb31b
Reviewed-on: https://code.wireshark.org/review/9615
Reviewed-by: Guy Harris <guy@alum.mit.edu>
When looking for Qt framework dependencies, look for dependencies that
begin either with @rpath or with the Qt framework directory.
Then, first transform @rpath/ to a path relative to the Qt framework
directory, and then strip off everything past the framework directory,
to get the absolute path of the framework directory (not of the
framework binary - we want to copy the whole framework).
In the loop looking for dependencies on things *other* than Qt
frameworks, exclude Qt framework references with absolute paths from the
dependencies we find; they get processed later. (We already excluded
those with @rpath paths.)
Change-Id: I1e345a5fb82c758d5c1541693b46cb36d2677fab
Reviewed-on: https://code.wireshark.org/review/9614
Reviewed-by: Guy Harris <guy@alum.mit.edu>
macdeployqt doesn't actually seem to deploy any of Qt into the app
bundle, probably because we're using it in a fashion they didn't intend
(i.e., not doing everything with *their* build tools), so we just extend
our dependency-binding stuff to handle the Qt libraries, and copy over
the Qt plugins ourselves.
We also add the rpaths to the executables and libraries as part of the
app bundle building process; I thought it'd fix macdeployqt's problem,
but it didn't, however, it's probably cleaner to do it there anyway.
Change-Id: I134c2b1a32e168e82de67f0b674d17167481d69a
Reviewed-on: https://code.wireshark.org/review/9612
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Determine what type of X11 (bundled from Apple, unbundled XQuartz) we
should have and what type we do have.
If we don't have any installed, don't tell X11 to do anything, as that
just pops up a "where is X11?" dialog; that's information the user
shouldn't need to tell the system if it is installed, and it's
information for which the user shouldn't be asked if it's not installed
- and if they're asked, they might answer incorrectly, leaving a system
that doesn't properly launch X11 for Wireshark. (See various
ask.wireshark.org questions about this, for example.)
Pick up some changes from newer versions of Inkscape, such as using
unsigned char *, not using FSSpecs, and adding some comments, while
we're at it.
Change-Id: Ic9a2b25938c4eec5628d1c16c7db28aa0714203e
Reviewed-on: https://code.wireshark.org/review/8559
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Reviewed-on: https://code.wireshark.org/review/8561
Make sure the target location for extcap executables and extcap_dir
match on OS X.
Set the extcap directory to Contents/MacOS/extcap. The Mac Developer
Library documentation doesn't explicitly define "Resources", but
examples include data files and not executables. It does state that
executables shouldn't go into PlugIns.
Make sure we rpathify androiddump.
Change-Id: If36c762e2a1991c26e5c01a870deaf191bcf9f94
Reviewed-on: https://code.wireshark.org/review/8093
Reviewed-by: Gerald Combs <gerald@wireshark.org>
The androiddump binary ends up in the top-level source directory, not
the extcap subdirectory.
Change-Id: Ia306b35211b885b817802a6a22ed9dbbe07f2532
Reviewed-on: https://code.wireshark.org/review/8037
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add missing androiddump stuff like:
- release notes
- documentation
- Windows nmake support
- running androiddump as a windows application instead of console on Windows
- addition of androiddump to the Windows installer
Change-Id: I3bc6cc70e4dc96c0cd776f3d965dd2aa0309995d
Reviewed-on: https://code.wireshark.org/review/7981
Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com>
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
the make that comes with *BSD and other systems now.
Change-Id: Ib2eee8d37e7029202675bac35839b1c0d5fc5131
Reviewed-on: https://code.wireshark.org/review/6320
Reviewed-by: Stephen Fisher <sfisher@sdf.org>
Look for the binary in various places, rather than looking for
particular directories and adding them to the path. That lets us use
the PackageMaker binary from the PackageMaker.app bundle (it can either
be run as a GUI app or from the command line), so you don't have to have
a symlink to it from one of the directories in question.
Change-Id: I1ad701291698544f96d419663f0b4a669876d2f1
Reviewed-on: https://code.wireshark.org/review/5077
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add a -cb/--create-bundle option to osx-app.sh which builds the
application bundle. Use it in Autotools. (CMake does this by default.)
Copy over linker flags from configure.ac to CMakeLists.txt to support
rpathification and code signing.
Add an osx-app custom target to CMake.
Change-Id: I6c20a1c27f8954aaea62904b7425b9312d994803
Reviewed-on: https://code.wireshark.org/review/4918
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Also, update a comment to more accurately describe what a loop is doing,
and get rid of an unused variable.
Change-Id: I948fc4ad758152b483450bf74f653087c892ad3a
Reviewed-on: https://code.wireshark.org/review/2360
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This reverts to the way we did it prior to the switch to Qt; with GTK+,
Contents/MacOS/Wireshark is just a launcher, and the Wireshark binary is
in Contents/Resources/bin/wireshark-bin, and the appropriate rpath entry
would be @executable_path/../lib - @executable_path/../Frameworks, which
works for the Qt version, in which Contents/MacOS/Wireshark is the
actual executable, doesn't work for the GTK+ version.
This should fix bug 10185.
Change-Id: I4e50a4ead8f29a742c97a9001c821aabe1fa5e65
Reviewed-on: https://code.wireshark.org/review/2347
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That way, if we crash in the middle, there's still something installed
that will try to set the permissions on the BPF devices.
Change-Id: Ie0c32f9eaca08bdbb359d07e47f20c664bc66411
Reviewed-on: https://code.wireshark.org/review/2023
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Only one is necessary; get rid of the startup item.
Change-Id: I0bd2dabb3fc286ccd0e6634bc112e20602624c86
Reviewed-on: https://code.wireshark.org/review/2016
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We're not using the Utilities directory; don't create it and don't fill
it in.
Change-Id: I7ba66b415a2e5a6aff77d4bdb57b2ca176bcd789
Reviewed-on: https://code.wireshark.org/review/2009
Reviewed-by: Guy Harris <guy@alum.mit.edu>
(Using sed : sed -i '/^\# \$Id\$/,+1 d') (start with dash)
Change-Id: Ia4b5a6c2302f6a531f6a86c1ec3a2f8205c8c2dd
Reviewed-on: https://code.wireshark.org/review/881
Reviewed-by: Anders Broman <a.broman58@gmail.com>
(Using sed : sed -i '/^ \$Id\$/,+1 d') (No star only 2 spaces before)
Change-Id: Id7b254031769a9dca2941304e4d3a0f4bdbc3f54
Reviewed-on: https://code.wireshark.org/review/883
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Issue found by rols
The installer puts the normal included plugins (e.g. mate, wimax) in
/Applications/Wireshark.app/Contents/Frameworks/wireshark/plugins,
however the global plugins directory is set to
/Applications/Wireshark.app/Contents/Resources/lib/wireshark/plugins
(as it was in previous versions) so no plugins load at startup.
In order to make them load you have to create this directory and
copy the plugins there, or put them in your personal directory.
From remark of Gerald, use recommandation of Bundle Programming Guide (use Contents/PlugIns for plugin)
https://developer.apple.com/library/mac/documentation/corefoundation/conceptual/cfbundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW19
Change-Id: Ib1ae7da48a8fa94f7037912cd44c05532a238b71
Closed-bug: 9854
Reviewed-on: https://code.wireshark.org/review/602
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Replace g_memmove with memmove
However there still one move g_memmove related code in "packaging/macosx/native-gtk/glibconfig.h".
svn path=/trunk/; revision=54472
Add a cli-preinstall script that creates missing parts of the
installation path and sets their permissions. Simply copy
"utility-launcher" to "wireshark" instead of renaming it at install
time. Explicitly set its ownership and permissions. Pretty-print some of
the PackageMaker XML files via `xmllint --format --recover`.
svn path=/trunk/; revision=53281
Specify "Application" or "Installer" code signing identities as needed.
Switch back to productbuild for the package. That seems to be the
correct utility to use. Give the package an ID. Package signing is still
broken but this appears to be closer to being correct.
svn path=/trunk/; revision=53211
Sign executables, libraries, frameworks, plugins, and bundles as per the
Code Signing Guide. Check our work with spctl. Use "bundle" to
differentiate what we're doing with the package script.
svn path=/trunk/; revision=52746
Guy Harris