Upgrade cmake on all buildbots

[staticfloat]

Once 0.5.0 is out the door, upgrade cmake on all the buildbots to at least 3.4.3. This script, newly updated, should work just fine.

Note; do NOT upgrade mingw cross-compilers to 5.4, we need to keep those held back to 4.9 until we have a solution for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333

[tkelman]

Can we upgrade cmake just on power for now, so JuliaLang/julia#18557 can be merged? Since the power buildbot is so new it's not a huge deal if the power build of an upcoming release gets delayed a tiny bit.

[staticfloat]

Should be done. Feel free to try it out. Done via:

$ ansible-playbook -i ./hosts -v cmake_install.yml -l buildslave_centos7.2-ppc64le

[tkelman]

I don't think it's on the path yet? https://build.julialang.org/builders/package_tarballppc64le/builds/88/steps/make/logs/stdio

[staticfloat]

Needed to shuffle around the PATH priorities in .bash_profile. Restarted as https://build.julialang.org/builders/package_tarballppc64le/builds/89

[tkelman]

did that also result in a different compiler getting used? missing glibcxx version symbols?

[staticfloat]

Yes it did! Apparently we weren't using the GCC 6.2 that I custom built on there before now. I'll just nuke and restart.

[staticfloat]

New build: https://build.julialang.org/builders/package_tarballppc64le/builds/92

[tkelman]

oh you had done a gcc build there? didn't realize. this is a system we share with people right? so not feasible to run on some older centos 6 (if that works on power)? do we have permissions to run in a vm? might be a little slower but it's already our fastest buildbot

[staticfloat]

I don't think we have any virtualization software installed. Would Docker be enough?

[tkelman]

yes, if that works on power. then we'd need to port your ansible scripts to dockerfiles which I'd kind of prefer myself, at least for linux

[tkelman]

or install ansible in the docker image I suppose

[staticfloat]

The ansible scripts have the advantage of being the same across all platforms, I'd kind of like to not split the configuration.

[tkelman]

Looks like it's missing one of the environment variables or make flags that we had to be careful about, to point at the right libstdc++ from the built gcc?

[staticfloat]

Fixed via

PATH=$HOME/local/bin:$HOME/bin:$PATH
LD_LIBRARY_PATH=$HOME/local/lib64:$HOME/local/lib:$LD_LIBRARY_PATH

export PATH
export LD_LIBRARY_PATH

In ~/.bash_profile. Silly me for forgetting. New build going through here.

[tkelman]

This will need doing on the centos 5 intel buildbots before we can merge JuliaLang/julia#19123 JuliaLang/julia#19678

[staticfloat]

Done, let's go ahead and test it.

[tkelman]

windows buildbots need this too, they're on the 3.3 cygwin package - be very careful if you upgrade this through cygwin setup though, need to manually switch to "keep" on all the mingw cross compilers to stay at 4.9

Note; do NOT upgrade mingw cross-compilers to 5.4, we need to keep those held back to 4.9

[staticfloat]

Note; do NOT upgrade mingw cross-compilers to 5.4, we need to keep those held back to 4.9

Thanks for reminding me of that, I do not remember writing that, and would have thought it was a good idea to upgrade everything. :P Windows buildslaves are updated as well now.

[tkelman]

I think something's broken about the cmake you just installed, it doesn't run cmake --version. And I'm having trouble finding where the buildbot clone lives to get 22eb073 to take effect

[staticfloat]

I did notice that myself, but I seemed to remember something about windows cmake acting very strangely. The buildbot instance on ubuntu@build.julialang.org, in ~/buildbot. I've reloaded it.

[tkelman]

"very strangely" doesn't usually involve exit status of 127. How did you install it? Adding cygwin gdb might be useful for this.

[staticfloat]

I installed it through the cygwin setup, selecting keep for everything except cmake and cmake dependencies. I'll add gdb.

[tkelman]

oh, should allow the other stuff like the cygwin dll etc to get upgraded, the cross-compilers should be the only thing you need to hold back

[staticfloat]

Looks like it needed a reboot. cmake is much happier now and everything non-mingw is upgraded:

$ cmake --version
cmake version 3.6.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).

[tkelman]

Ah, maybe the buildbot process or something was keeping some old library loaded. Something is still a bit flaky, jobs are pending for way longer than they should be...

[tkelman]

The win32 builder is going to need another shutdown, reboot, and rebaseall of all cygwin processes, buildbot was dying in fork failures. Once that's back up I think we can call this closed.

[staticfloat]

Done. -E

…

On Thu, Dec 22, 2016 at 7:40 AM, Tony Kelman ***@***.***> wrote: The win32 builder is going to need another shutdown, reboot, and rebaseall of all cygwin processes, buildbot was dying in fork failures. Once that's back up I think we can call this closed. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#54 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH_aO15OKDEkFUQS6z0ZSxmFAWbak2Bks5rKpn2gaJpZM4J_qAZ> .

[tkelman]

still having trouble? https://build.julialang.org/builders/package_win6.2-x86/builds/1017/steps/Julia%20checkout/logs/stdio

[staticfloat]

For future reference, rebasing, enabling ASLR on all cygwin executables, and removing/recreating the python virtualenv and restarting seems to have done the trick.

[tkelman]

You forgot to not upgrade the cross compiler. Need to use cygwin time machine to downgrade back to 4.9

[staticfloat]

Shoot, on the very last invocation I must have forgotten to check "keep" for those packages. Urgh. I'm unable to get manual package installation or the time machine to work. The time machine looks to be down today, not sure what other choices we have. My dislike for cygwin increases, despite this problem being my own fault. -E

…

On Thu, Dec 22, 2016 at 2:36 PM, Tony Kelman ***@***.***> wrote: You forgot to not upgrade the cross compiler. Need to use cygwin time machine to downgrade back to 4.9 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#54 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH_aLhjT9fLLays8EigS-0qQxbJmn1Fks5rKvtigaJpZM4J_qAZ> .

[tkelman]

if you still have the downloads locally, it's possible to manually modify the setup.ini listing and use a local copy to act like 4.9.2 is the latest version, from your local files. if you don't have them locally, I can put my copy somewhere along with a setup.ini that I had used.

[staticfloat]

Yes, looks like I still have the old files cached locally. What do I need to do with my setup.ini file?

[tkelman]

IIRC, change the version numbers and checksums for the mingw packages to match 4.9.2 instead of 5.4

[tkelman]

cygwin makes everything a bit of an ordeal, but calling this done now. thanks!

[tkelman]

I attempted to run the ansible script on buildslave_centos7.1-x64 (which we missed), but didn't succeed - ERROR: become is not a legal parameter in an Ansible Playbook. Could you run that?

[staticfloat]

Sure thing. That error means, (I believe) that your ansible version is too old. -E

…

On Thu, Dec 29, 2016 at 12:52 PM, Tony Kelman ***@***.***> wrote: I attempted to run the ansible script on buildslave_centos7.1-x64 (which we missed), but didn't succeed - ERROR: become is not a legal parameter in an Ansible Playbook. Could you run that? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#54 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH_aEmIzaMAceIfsMeQdr5V8MHvv7fyks5rNB2mgaJpZM4J_qAZ> .