centos 5 builders seem a little broken

[tkelman]

The linux nightly tarballs are having some strange issues, I guess since the power outage? Did they need to recompile the source build of gcc they've been using from scratch or something?

[staticfloat]

I sure hope not. I nuked the build directories, we'll see if something strange happened that botched that, but if that doesn't work, I'll restore from one of my saved images.

[tkelman]

If you do need to rebuild gcc, probably worth using 4.9 or 5.1 so things are copacetic on bleeding-edge ubuntu: https://github.com/JuliaLang/ZMQ.jl/issues/81#issuecomment-103662471

[staticfloat]

I'm building 5.1 now to see if that helps. Also, working on a set of Ansible scripts that should make this provisioning easier, with way less investment necessary as compared to the vagrant/packer approach I had earlier.

[tkelman]

Does your ansible stuff upgrade the cygwin packages on the windows buildbots? I posted my powershell update snippet in a few other places, can dig it up again if you can't find it.

[staticfloat]

alright, I think I've got the centos 5 guys up and running. You know, I looked around for the update script 'cause I know you posted it, but I can't find it. :( If you could post it here again, that'd be great.

[tkelman]

In powershell, the cygwin-package-updating bit is this:

mkdir -Force C:\cygwin | Out-Null
(new-object net.webclient).DownloadFile(
  "http://cygwin.com/setup-x86_64.exe", "C:\cygwin\setup-x86_64.exe")
foreach ($pkg in @("git,make,curl,patch,python,gcc-g++,m4,cmake,p7zip",
    "mingw64-i686-gcc-g++,mingw64-i686-gcc-fortran",
    "mingw64-x86_64-gcc-g++,mingw64-x86_64-gcc-fortran")) {
  C:\cygwin\setup-x86_64.exe -q -n -R C:\cygwin -l C:\cygwin\packages `
    -s http://mirrors.chauf.net/cygwin -g -P $pkg | Where-Object `
    -FilterScript {$_ -notlike "Installing file *"} | Write-Output
}

The mirror choice (mirrors.chauf.net/cygwin above) may need to be tweaked occasionally, I've yet to figure out the absolute most reliable long-term choice.

CentOS 5 builders do appear to be back in business though, so closing this issue. Thanks!

[staticfloat]

As far as mirrors for this go, there's an easy no-brainer: http://mirrors.mit.edu/cygwin/

[tkelman]

Indeed. I'm blind apparently.

[tkelman]

cc1: error: -fno-gnu89-inline is not supported http://buildbot.e.ip.saba.us:8010/builders/package_tarball32/builds/1003/steps/make%20binary-dist/logs/stdio ?

[tkelman]

I'm gonna take a wild guess and say that the buildbot was refreshed but the new gcc wasn't rebuilt yet?

[staticfloat]

It looks like the PATH wasn't set right after installing the new stuff; retrying.

[tkelman]

Better, thanks. Looks like I need another libgit2 patch for old openssl. https://github.com/JuliaLang/julia/commit/e87bf5325db494aed02b2efa12a67a8f27aa679a

[tkelman]

What did I manage to break this time? libunwind error: 'REG_FS' undeclared ?

http://buildbot.e.ip.saba.us:8010/builders/package_tarball32/builds/1007/steps/make%20binary-dist/logs/stdio

[tkelman]

aha. your CLOEXEC thing clobbered _GNU_SOURCE - I'm going to comment it out to just see if we can get a green nightly first, then we'll keep experimenting with where to put it to make lldb happy

[staticfloat]

how did it clobber it?

[tkelman]

Guessing, but it probably gets added somewhere in libunwind's configure unless CPPFLAGS is set externally. Maybe we could do CPPFLAGS="-D_GNU_SOURCE -DO_CLOEXEC=0" but who knows how many other secretly necessary flags are getting set like that throughout all the deps

[tkelman]

Am I running afoul of python syntax, or does the buildbot configuration take some time/manual intervention to update?

[staticfloat]

Unfortunately, there is a manual command that I typically run. I should add that to the rundeck thingy.

[tkelman]

Buttons are good. Looks like my manual build with one more libgit2 patch fixed things, though the auto-nightlies are stalled because of 12 pending builds on the ubuntu14.04-x86 builder?

[staticfloat]

Indeed. For some reason it looks like that buildslave just decided to get stuck on something; it wasn't even building anything. I'm pretty sure it would have timed out eventually, but I have added a "kick_buildslave" job on Rundeck that allows you to stop and then start the buildslave process on any of the buildbots.

[tkelman]

Looks like we're back in business, thanks as always

[tkelman]

I found the "build gcc" button on rundeck, but looks like it's missing the "add to path" step since I still occasionally get -fno-gnu89-inline is not supported

[staticfloat]

There's a small bug in one of the scripts where it starts the buildslave process with the wrong environment variables. It should be running properly now.