Hi, I think I understand why it started failing. It must have started failing when you updated the version of OpenSSL. .travis.yml caches ~/opt folder between builds. After the update to 1.1.1f the build doesn't see the OpenSSL binaries in the cache anymore and tries to download it and build it. But as I've noticed in my attempt to build HAProxy with Docker+QEMU the build of OpenSSL is taking too long. The build of OpenSSL is wrapped with travis_wait to reduce the writes to stdout but the default time for travis_wait is 20 mins and this is not enough to build OpenSSL. Due to https://travis-ci.community/t/output-is-truncated-heavily-in-arm64-when-a-command-hangs/7630 TravisCI does not properly report that the problem is at build_ssl() step but shows the last chunk of the buffered response and this confuses us all. I think the build will become green if we extend travis_wait to a higher value ( https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received). I don't remember where I have read it but I think the upper limit is 120 mins. @Willy: could you please change https://github.com/haproxy/haproxy/blob/master/.travis.yml#L112 to:
travis_wait 120 bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' || (cat build-ssl.log && exit 1) i.e. add '120' after travis_wait This should give it the time to download and install OpenSSL 1.1.1f and to cache it. If the build passes once then the next builds should be much faster because OpenSSL will be used from the cache. Regards, Martin On Fri, May 8, 2020 at 9:18 AM Willy Tarreau <w...@1wt.eu> wrote: > Hi Martin, > > On Fri, May 08, 2020 at 08:56:07AM +0300, Martin Grigorov wrote: > > Unfortunately it is not good: > > https://travis-ci.com/github/haproxy/haproxy/jobs/329657180 > > Indeed it's still not fixed on Travis' side. However what Ilya did > actually worked, in that the status is not reported as a global > build failure anymore. This allows us to continue to monitor if > and when this issue finally resolves on the build infrastructure. > It's also possible that they're not aware of the problem due to > too few people using arm64. If someone has contacts there it might > be worth checking with them. All we know for now is that it seems > to stop moving while setting up libpcre2. Maybe there's a bug in > a script in this package, resulting in a prompt for a question > which never gets a response :-/ But that's something we can't > check since we don't have access to an interactive shell there > to diagnose. > > Willy >
