ci: install P4 from package

[szeder]

To test 'git-p4' in the Linux Clang and GCC build jobs we used to
install the 'p4' and 'p4d' binaries by directly downloading those
binaries from a Perforce filehost. This has worked just fine ever
since we started using Travis CI [1], but during the last day or so
that filehost appeared to be gone: while its hostname still resolves,
the host doesn't seem to reply to any download request, it doesn't
even refuse the connection, and eventually our build jobs time out
[2].

Now, this might be just a temporary glitch, but I'm afraid that it
isn't. The "Helix Core Server Administrator Guide" [3] describes two
ways to install these binaries on Linux, and none of them mentions the
filehost that we've been downloading from in the past:

• non-package installation: open the website's download page in your
  web browser, select OS and platform, click on the download link,
  and eventually you get a .tar.gz archive containing, among other
  things, the necessary 'p4' and 'p4d' binaries.

  Now, we could use the URL of this archive to download it in our CI
  scripts with 'wget', but nobody said that that URL remains stable,
  and we would still need to extract the archive and copy the
  binaries to $PATH.

• package installation for various distros, including Ubuntu 16.04
  (i.e. the Ubuntu version used both in our Travis CI and Azure
  Pipelines builds): add a package repository and its pubkey,
  'apt-get update && apt-get install', and ready to go.

Let's install P4 from the package repository, because this approach
seems to be simpler and more future proof.

Note that we used to install an old P4 version (16.2) in the Linux
build jobs, but with this change we'll install the most recent version
available in the Perforce package repository (currently 19.1).

[1] 522354d (Add Travis CI support, 2015-11-27).
[2] https://travis-ci.org/git/git/jobs/581429927#L422
[3] https://www.perforce.com/manuals/p4sag/Content/P4SAG/chapter.install.html

---

Let's see whether this works on Azure Pipelines.

[gitgitgadget]

Welcome to GitGitGadget

Hi @szeder, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests.

Please make sure that this Pull Request has a good description, as it will be used as cover letter.

Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:

• the lines should not exceed 76 columns,
• the first line should be like a header and typically start with a prefix like "tests:" or "commit:", and
• the commit messages' body should be describing the "why?" of the change.
• Finally, the commit messages should end in a Signed-off-by: line matching the commits' author.

It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code.

Contributing the patches

Before you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a PR comment of the form /allow <username>.

Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment /submit.

After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions.

If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox ("raw") file corresponding to the mail you want to reply to from the Git mailing list. If you use GMail, you can upload that raw mbox file via:

curl -g --user "<EMailAddress>:<Password>" --url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt

[dscho]

/allow szeder

[gitgitgadget]

User szeder is now allowed to use GitGitGadget.