... since the gcc-8 ones seem to fail frequently.

Follow-up from b8520719

Closes #2886

Since they started to fail almost 100% since a few days.

Closes #2876

Closes https://github.com/curl/curl/pull/2869

... when curl is built from distribution tarball

Closes #2856

Follow-up to 2de63ab1 and
0b87c963.

Closes https://github.com/curl/curl/pull/2862

... as building on 10.13.x before 10.13.4 leads to link errors.

Assisted-by: Nick Zitzmann
Fixes #2835
Closes #2845

... to make sure the examples are all checked.

Closes #2811

... since default uses the threaded one and we test the c-ares build
already.

Closes #2689

... run a few more tortured based and run all tests event-based.

Closes #2664

Detected using the `codespell` tool (version 1.13.0).

Also secure and fix an URL.

Closes #2558

Assisted-by: Dan Fandrich

Closes #2528

Closes #2531

It seems to not be detected by default anymore (which is a bug I
believe)

Closes #2541

closes #2471

Extra-eye-on-this-by: Marcel Raad

Closes #2478

This works now and precise is in the process of being decommissioned.

Closes https://github.com/curl/curl/pull/2476

This is a workaround for an unsolved travis issue that is causing CI
instances to sporadically fail due to 'unable to connect' issues during
apt stage.

Ref: https://github.com/travis-ci/travis-ci/issues/8507
Ref: https://github.com/travis-ci/travis-ci/issues/9112#issuecomment-376305909

Update clang to version 3.9 and GCC to version 6.

Closes https://github.com/curl/curl/pull/2345

... to verify it builds and works fine.

Ref: https://curl.haxx.se/mail/lib-2017-09/0031.html

Closes #1872

.. since now mac osx image expects pip2 or pip3, and doesn't know pip:

0.01s$ pip install --user cpp-coveralls
/Users/travis/.travis/job_stages: line 57: pip: command not found

Ref: https://github.com/travis-ci/travis-ci/issues/8829

Closes https://github.com/curl/curl/pull/2133

Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>

Uses a separate build without --enable-debug and no valgrind.

The debug option causes far too many warnings in boringssl's headers
(C++ comments, trailing commas etc).  Valgrind triggers some false
positive errors in thread-local data used by boringssl.

Closes #2118

We don't expect any steps to fail in travis. Exit the script if they do.

Closes #1966

Use the external curl-fuzzer repository for fuzzing.

Closes #1923

- openssl is already installed and causes warnings when trying to
  install again

- libidn isn't used these days, and homebrew doesn't seem to have a
  libidn2 package to replace with easily

Closes #1895

Closes https://github.com/curl/curl/pull/1687

Closes #1868

Automake gets confused if you want to use C++ static libraries with C
code - basically we need to involve the clang++ linker. The easiest way
of achieving this is to rename the C code as C++ code. This gets us a
bit further along the path and ought to be compatible with Google's
version of clang.

- Start with the basic code from the ossfuzz project.
- Rewrite fuzz corpora to be binary files full of Type-Length-Value
  data, and write a glue layer in the fuzzing function to convert
  corpora into CURL options.
- Have supporting functions to generate corpora from existing tests
- Integrate with Makefile.am

Closes #1790

closes #1747

to make sure they keep building warning-free

Closes #1777

Could've prevented #1755

Help-by: Jay Satiro
Closes #1753

This makes the builds more reproducible as travis is currently rolling
out trusty as default dist [1]. Specifically, this avoids coverage
check failures when trusty is used as seen in [2] until we figure out
what's wrong.

[1] https://blog.travis-ci.com/2017-07-11-trusty-as-default-linux-is-coming
[2] https://github.com/curl/curl/pull/1692

Closes https://github.com/curl/curl/pull/1725

(to make the full line appear nicer on travis web UI)