On Fri, May 08, 2020 at 12:54:14PM +0500, ???? ??????? wrote:
> > > 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

But we don't even know if we all end up on the same build nodes, and
it's likely that it's not the case since yours finishes.

> > 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.

OK.

> > 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.

Well, for #1 I don't think that changing pcre2 will have any impact there
because it's obvious that we're facing output buffer truncation and that
the problem happens after though we don't know how far after. For #2, not
using travis' apt, maybe we'd gain slightly better control, but it's not
even certain and it's possible we might not benefit from certain caches,
so I'm having doubts. For #3, interacting with their support channel, why
not, if you're willing to engage into this. If at least they can bring us
a complete untruncated output of a failed build, that would help.

I continue to think that avoiding building standard packages in the VMs
should be the priority. Our goal is not to test if openssl can be built
and used there but if haproxy can be built and used there. When it's the
only option to test integration with certain components, that's fine.
Here I think that openssl is sufficiently covered on other platforms so
we don't necessarily need to rebuild it ourselves and we can use the
distro's version.

Thanks,
Willy

Reply via email to