Ridiculous failures...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Ridiculous failures...

Nicolas Cellier
 
Hi all,
the legacy pharo builds in root opensmalltalk-vm repository are failing randomly.

I suspect that the build should have failed since the upgrade of openSSL to 1.1
It failed in libssh2-1.17.0 because it was incompatible with this openSSL version.
It did not fail immediately *thanks* to the wonderful travis cache features.

Apparently the official fork still depends on OpenSSL 1.0.2, which is evidence that division of forces pay off!

I think I mostly fixed the builds by upgrading libssh2 to 1.9.0.
But the last builds got the most ridiculous failures I've ever seen.

> The job exceeded the maximum log length, and has been terminated.
Recompiling those libraries is ridiculous, does indeed spit ridiculous amount of log (27500 lines), and might fail for many reasons including timeout. Nobody cares, but it's also bad for the planet !

We know the solution for long: either build the libraries in their respective projects, publish as github release, then download the binaries (we can clone the repository as needed); or download pre-build binaries for the distro (yeah, the CI bots build on a specific distro anyway, so at least on linux and windows, the binaries are available unless we really insist on using a really old version).

Many thanks to the Pharo team which has legated this mess, and did fix the problem meanwhile in their own fork. A very appreciated spirit and attitude...

By respect toward the pharo community, the root opensmalltalk-vm still build the pharo binaries. But I really have the impression to clean-up after the dog of someone else. Respect has to be mutual, or it's not respect, it's slavery.

Due to this lack of support, I had to put all the pharo builds in the list of authorized failures in .travis.yml.

I kindly ask interested parties to help implement an equivalent solution in the root repository, if those builds still have a value. Without community support, you know that those bits will inevitably rot (the more the dependencies, the faster the rot).