On Fri, May 8, 2020 at 10:54 AM Илья Шипицин <chipits...@gmail.com> wrote:
> > > пт, 8 мая 2020 г. в 12:26, Willy Tarreau <w...@1wt.eu>: > >> On Fri, May 08, 2020 at 09:34:32AM +0300, Martin Grigorov wrote: >> > 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. >> >> That's very likely indeed. >> > > > it is not :) > I provided link to my fork, openssl build takes 640 sec > > >> >> > 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. >> >> Ah, excellent, precisely what I was looking for. And some indicate >> that the buffering further causes issues in the build system itself! >> >> > 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 >> >> We could, but 120 (2 hours) seems a bit extreme. It also means we can >> steal >> 2 hours of CPU there in case something goes wrong. >> > > travis-ci limits build at 60 min. > > >> >> > 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. >> >> I'm wondering why instead we don't fallback on an already packaged version >> of OpenSSL for this platform. I mean, sure it's convenient to test the >> latest version but it's already tested on x86 and we could very well use >> any other version already packaged on the distro present there. This would >> solve the problem and even increase versions coverage. >> >> Ilya, what do you think ? >> > > yes, there are few options to think about. > I also provided options (numbered 1..4), Hopefully, I think on your > suggestions, Martin will think on my suggestion ... and we will decide what > next would be. > I still believe the problem is in the time needed to build OpenSSL, not in apt[-get]. We can increase temporarily the travis_wait to 60 just to cache the build of 1.1.1f and then remove '60' again. Although if this is the problem then 'travis_wait 60 ...' won't do any harm for the next builds because it will use the cache and return in few secs. I like the idea to install openssl with apt but I am not sure whether we can do this *only* for ARM64. > > >> >> Thanks, >> Willy >> >
