| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
There are a ton of "hey, that snprintf might truncate output!" warnings
(yes, we know, the API has a bunch of hard length limits, so we'll have
to have a different API, with mallocated message buffers, to eliminate
them, and suppressing the warnings runs the risk of turning into a game
of Whack-A-Mole), as well as some breakloop warnings on Linux that need
an API change to add a version of pcap_breakloop() that can return an
error indication.
|
|
|
|
|
| |
See if there are any remaining warnings. If there are, we'll try to
squash them; if not, we'll hope this keeps more from coming in.
|
|
|
|
|
|
|
| |
For some reason, on the 64-bit PowerPC/Power API, z/Architecture, and
64-bit ARM buildbots, the Coverity bilds time out after the "if this is
a Coverity branch, quit before doing anything" step. Print a line, to
see whether that satisfies Travis.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1)
Don't bother with "GCC" on macOS.
The "gcc" on the Travis buildbots is just Apple's "gcc", which is an
alternate front end to Clang, rather than being GCC-for-macOS.
2)
Only do 64-bit x86 Coverity build.
If we're doing a Coverity build, only do it once. Now that we're
building for multiple instruction sets, we need to check the instruction
set to ensure that.
3)
Cut down the build matrix for macOS.
macOS currently runs only on 64-bit x86, so eliminate all the other
architecture builds for it. (It may run on 64-bit ARM in the future,
but is unlikely ever to run on z/Architecture, and probably won't be
re-introduced to the world of the Power ISA, much less little-endian
Power ISA.)
|
|
|
|
| |
It is not needed for usbmon USB capture support on Linux.
|
|
|
|
|
|
| |
The workaround for 'Disallowing packages: libdbus-1-dev' is now useless.
This reverts commit b8056c38e7512a6282f2e8806cead97042b2e8da.
|
|
|
|
|
|
| |
Add ppc64le, s390x and arm64 architectures.
https://docs.travis-ci.com/user/multi-cpu-architectures/
|
|
|
|
| |
This change improves readability.
|
|
|
|
| |
It seems no longer needed.
|
|
|
|
|
| |
I need to further tweak the configure script to detect the failure on
Mojave/Xcode 11.
|
| |
|
|
|
|
| |
gcc 7.4.0 (on Xenial was 5.4.0)
|
|
|
|
|
| |
The error message was:
"curl: (60) server certificate verification failed."
|
|
|
|
|
|
|
| |
From Travis CI documentation:
Container-based infrastructure has been fully deprecated. Please remove
any "sudo: false" keys in your .travis.yml file to use the
fully-virtualized Linux infrastructure.
|
| |
|
| |
|
|
|
|
|
|
| |
Add a folded 'cat Makefile' (without the mkdep part for autotools).
Add a folded 'cat config.h'.
Add a folded 'cat config.log' (for autotools).
|
| |
|
|
|
|
|
|
| |
Trailing newlines are now needed in travis_fold:start:* strings, because
of a Travis change.
Based on Travis support proposal.
|
|
|
|
|
|
|
|
|
| |
With this change the apt-get command installs again theses libraries:
libusb-1.0-0-dev
libdbus-glib-1-dev
libbluetooth-dev
libnl-genl-3-dev
libibverbs-dev
|
|
|
|
|
| |
Thanks and a tip of the Hatlo hat to Anders Broman for the suggestion to
use a Debian repository and for this suggestion.
|
|
|
|
|
|
|
|
|
| |
Either it or Travis or both appear to require a GPG key to verify the
packages, and Debian appears not to make it easy to determine what the
URL is to get it (or don't make it available via HTTP).
Thanks, fellas. I really appreciate how easy you made it to test
building libpcap with a sufficently-modern DPDK on Travis.
|
| |
|
|
|
|
|
|
|
|
| |
The only reason for trying it was to try building DPDK, and the version
of DPDK that comes with it is too old to work with libpcap, so just go
back to the old matrix for now. (We may want to revive it to test with
newer compilers on Linux and to test with real GCC, not "clang is
claiming to be GCC", on macOS.)
|
|
|
|
|
|
|
|
|
|
|
| |
It appears that having multiple distributions in dist: causes the build
to hang forever in the queueing stage. Go back to the explicit matrix
as a way to get both Trusty and Xenial builds.
If you have an item in some matrix entries and the same item outside the
matrix, the one in the matrix entry overrides the item outside the
matrix, so we have to have the APT add-on packages in each matrix entry.
Do so.
|
| |
|
| |
|
|
|
|
|
|
|
| |
That's a bit simpler.
Hopefully, that won't cause Travis to get confused because we're
building on macOS as well as Ubuntu.
|
| |
|
|
|
|
|
| |
Add some comments, and get rid of some no-longer-needed stuff, while
we're at it.
|
| |
|
| |
|
|
|
|
|
|
|
| |
I *suspect* that the custom matrix isn't setting custom environment
variables, so CMAKE is neither "yes" nor "no", and we are neither
running the configure script nor CMake. See what happens *without* the
custom matrix, so we can compare them.
|
|
|
|
|
|
|
|
|
|
|
| |
The syntax, including the indentation, is taken from a .travis.yml file
for a GitHub repository for a project being maintained by "Twisted
Matrix Labs", who are apparently responsible for some obscure product
called "Twisted". :-)
Presumably *that* works. The only things they're *not* doing are 1)
tweaking the distribution and compiler and 2) setting multiple
environment variables. If Travis can't parse *that*, what's the issue?
|
| |
|
| |
|
| |
|
|
|
|
| |
That's what the examples in the Travis documentation do.
|
| |
|
|
|
|
| |
That's something in a Travis CI documentation page.
|
|
|
|
| |
This is what some Travis documentation suggests; see if that works.
|
|
|
|
|
|
|
|
|
|
|
| |
Try building with both Xenial and Trusty on Ubuntu, so we can try
testing builds with DPDK, which is only available on Xenial.
Don't build with both gcc and clang on macOS for now; according to the
Trusty documentation, gcc is just an alias for clang, and to really
compile with *GCC*, you'd have to set CC in the environment to a
specific GCC version, and you'd have to use "brew install" to get
versions other than 4.9.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|