On Tue, Sep 10, 2019 at 12:51:01AM +0200, Johannes Schindelin wrote: > On Fri, 6 Sep 2019, SZEDER Gábor wrote: > > > On Fri, Sep 06, 2019 at 12:27:11PM +0200, SZEDER Gábor wrote: > > > 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. > > > > Well, now would you believe it, while I was testing this patch (I even > > made a gitgitgadget PR to run it on Azure Pipelines! :) and touching > > up its log message the good old Perforce filehost sprang back to life, > > and the CI build jobs now succeed again even without this patch. > > Sorry for being so slow with granting you access to GitGitGadget. FWIW > _anybody_ who already was granted access can issue `/allow` commands, it > is not just me. No problem; I was only interested in the results of the Azure Pipelines build, and that seemed to go well even without access. > > > 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 (2016.2) in the Linux > > > build jobs, but with this change we'll install the most recent version > > > available in the Perforce package repository (currently 2019.1). > > > > So I'm not quite sure whether we really want this patch. It depends > > on how important it is to test 'git-p4' with an old P4 version, but I > > don't really have an opinion on that. > > I'd rather have that patch. It seems to be a much better idea to use the > package management system than to rely on one host, especially when said > host already displayed hiccups. Well, I'm not so sure. As far as I remember this was the first time that this Perforce filehost was inaccessible and a simple "Restart job" could not rectify the situation, because it was inaccessible for about a day or more. OTOH, transient errors or timeouts from 'apt-get update' or 'install' from the official Ubuntu package repositories are not uncommon (at least on Travis CI), although in those cases it's usually enough to just restart the errored job.
