![[Buildbot Logo]](/chrome/site/header-text-transparent.png)
Ticket #91 (closed defect: invalid)
Mac OSX buildbot slave confused by "cvs" on path
| Reported by: | joduinn | Owned by: | joduinn |
|---|---|---|---|
| Priority: | major | Milestone: | 0.8.+ |
| Version: | 0.7.5 | Keywords: | |
| Cc: | bhearsum@… |
Description
When a Mac OSX buildbot slave runs cvs, it behaves differently if a directory named "cvs" is found on the path.
For example, $ export | grep PATH declare -x PATH="/foo/cvs:/opt/local/bin:/tools/buildbot/bin:/tools/twisted/bin:/tools/twisted-core/bin:/tools/python/bin:/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin"
...will cause buildbot to attempt to run a program called "/foo/cvs", which doesnt work. Instead, buildbot should run a program called "/foo/bar/cvs/cvs".
To work around this, rename "/foo/cvs" to be "/foo/bar", adjust the PATH to match, and restart buildbot slave. Now, buildbot will run a program called "/foo/bar/cvs", which works.
Change History
comment:2 Changed 6 years ago by warner
- Owner set to warner
- Status changed from new to assigned
that's.. weird. There's a function named 'which' that is used to locate a given command on $PATH, and I know it has some weird code to deal with windows command-extension issues.. I wonder if that's interacting with something here?
Now that I've got an OSX box of my own, I'll take a look at this.
comment:3 Changed 5 years ago by warner
- Owner changed from warner to joduinn
- Status changed from assigned to new
I can't reproduce this simply. Could you confirm that it's still happening? Also, if you could provide me with the top of the failing step's stdout (the one where it shows the environment and the command being run), that would help.
Also, what version of twisted is this using? (just include the output of 'buildbot --version' on that buildslave)
comment:5 Changed 5 years ago by warner
- Milestone changed from 0.7.7 to 0.7.8
I tried to reproduce this again (OS-X Tiger, buildbot 0.7.6+, twisted 2.5.0), and wasn't able to. I moved the system /usr/bin/cvs into a local directory named 'cvs', moved the original to 'cvs.OFF' so it wouldn't be found, added the local 'cvs' directory to PATH, and restarted the buildslave. That slave was able to find the new local/cvs/cvs binary and use it for an update operation.
Failing a way to reproduce this locally, I'm going to push this out of 0.7.7 and into the next release. If you can reproduce the problem on your end, please let me know.. we can compare notes and figure out what's going on.