#52543 closed defect (fixed)
snowleopard-x86_64-legacy buildbot worker: xcodebuild exists but failed to execute
| Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | ryandesign (Ryan Carsten Schmidt) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | server/hosting | Version: | |
| Keywords: | Cc: | dbevans (David B. Evans), neverpanic (Clemens Lang) | |
| Port: |
Description
https://build.macports.org/builders/ports-10.6_x86_64_legacy-builder/builds/7064
I see in the log:
Warning: xcodebuild exists but failed to execute
and
Warning: Xcode does not appear to be installed; most ports will likely fail to build.
Which causes "System cc" to be the compiler that's used:
DEBUG: Using compiler 'System cc'
Which causes at-spi2-core to fail to build with the universal variant:
lipo: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_gnome_at-spi2-core/at-spi2-core/work/.tmp/cc3UStyY.out and /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_gnome_at-spi2-core/at-spi2-core/work/.tmp/ccyIbdDh.out have the same architectures (x86_64) and can't be in the same fat output file
Which causes wine to be unable to be installed.
I am seeing this only on snowleopard-x86_64-legacy, not on snowleopard-i386-legacy nor snowleopard-x86_64 nor the other workers.
It was my intention to set up all the buildbot workers the same way.
This problem appears to have started in build 6874. Build 6873 says:
DEBUG: Using compiler 'Xcode GCC 4.2'
but as of build 6874 we start to see:
DEBUG: Using compiler 'System cc'
I don't know what caused this.
We ran into the same problem on the previous Snow Leopard buildbot worker a couple years ago; see #46099. I couldn't figure out what caused that either; it solved itself.
Change History (5)
comment:1 Changed 8 years ago by dbevans (David B. Evans)
| Cc: | devans@… added |
|---|
comment:2 follow-up: 3 Changed 8 years ago by ryandesign (Ryan Carsten Schmidt)
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Not knowing what else to try, I've rebooted this worker. This appears to have helped: build 7092 shows:
DEBUG: Using compiler 'Xcode GCC 4.2'
Short of committing a change to the at-spi2-core portfile, I don't know how to get the buildbot to clear the failed build from the failcache. Just forcing a build of at-spi2-core on the buildbot web site will presumably only clear the non-universal build from the failcache, and forcing a build of wine again will not attempt to build at-spi2-core again because it's in the failcache.
comment:3 follow-up: 4 Changed 8 years ago by dbevans (David B. Evans)
| Cc: | cal@… added |
|---|
Replying to ryandesign@…:
Short of committing a change to the at-spi2-core portfile, I don't know how to get the buildbot to clear the failed build from the failcache. Just forcing a build of at-spi2-core on the buildbot web site will presumably only clear the non-universal build from the failcache, and forcing a build of wine again will not attempt to build at-spi2-core again because it's in the failcache.
If I'm looking at the relevant code, it appears that, if you could generate/determine the failcache hash for the given port and variant, you could manually remove the corresponding entry from the failcache directory. This is essentially what failcache_success() in contrib/mp-buildbot/functions does. Maybe it would be useful for admin purposes to have a tool that would do this or, even more elegantly, add something to an appropriate buildbot display that would allow someone with login access to do this for a given failed build.
comment:4 follow-up: 5 Changed 8 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to devans@…:
If I'm looking at the relevant code, it appears that, if you could generate/determine the failcache hash for the given port and variant, you could manually remove the corresponding entry from the failcache directory. This is essentially what failcache_success() in contrib/mp-buildbot/functions does.
True. From build 7085:
port at-spi2-core +universal 942bd1ec04930577a3b0c8857ada6c840e6f793a2a65f0a52bfcb03b624f6c7b previously failed in build https://build.macports.org/builders/ports-10.6_x86_64_legacy-builder/builds/7064
I removed that file from the failcache and started build 7107.
Maybe it would be useful for admin purposes to have a tool that would do this or, even more elegantly, add something to an appropriate buildbot display that would allow someone with login access to do this for a given failed build.
I think the intention is that you can force a new build of the port, which ignores the failcache. The problem is that here the failed build is universal, and we don't have a way to specify variants when forcing a build. Maybe we should add that, though I'm wary of letting people build arbitrary variants on the buildbot. Maybe we can add checkboxes for the two specific variants that we're considering making the buildbot build automatically: universal and quartz. Though I'm not sure how much we can customize the web pages.
comment:5 Changed 8 years ago by neverpanic (Clemens Lang)
The scripts already support building arbitrary variants, we just haven't made this option available to developers in the buildbot web interface. We already trust our devs to not build weird things on the buildbot, I don't see how the variants are different. If somebody abuses building of variants, we can still shout at them.
Cc Me!