Basabi Bhattacharya wrote: > Mark, > > Here is what you've asked:
Not completely, but enough to confirm my earlier assertion that you're using old tools. > waldorf:/export/basabi: hg-active -w onnv > Password: > remote: Not trusting file /export/onnv-clone/.hg/hgrc from untrusted > user onhg, group gk > HG_PARENT=15f1d0c1d28fba4c701bb3129f36527849e95f24 > usr/src/lib/fm/libfmd_snmp/Makefile.com > > 6761986 Update pathname for libfmd_snmp Makefile.com This would have been more useful if you had separated stdout and stderr, as I asked, but it's no longer needed. > waldorf:/export/basabi: which hg-active > /ws/onnv-tools/onbld/bin/hg-active And what about webrev? Answer: it's coming NOT from /ws/onnv-tools, but instead from /ws/onnv-gate/public/bin, and that version is out of date. I was under the impression that the gatekeepers had fixed this a while back, so I cc'd them above. In the mean time, as you already figured out, there's nothing wrong with the webrev, but you may certainly use the up-to-date version from /ws/onnv-tools, or from a local installation, to avoid seeing the error. --Mark > waldorf:/export/basabi/onnv: which hg > /usr/bin/hg > waldorf:/export/basabi/onnv: uname -a > SunOS waldorf 5.11 snv_100 sun4u sparc SUNW,Sun-Blade-1000 > > > The webrev is at, > > file:///net/waldorf.sfbay/export/basabi/onnv/webrev/index.html > > Please let me know if you need any further information. > > Thanks, > Basabi > > Mark J. Nelson wrote: >> I asked: >> >> >> What version of SUNWonbld are you using? >> >> You replied: >>> I had installed the latest from >>> /net/onnv.sfbay/export/onnv-gate/public/packages >> >> But the bug in question really WAS fixed in snv_97, and the version of >> SUNWonbld in the public/packages directory really has been fixed for >> several weeks. >> >> Can you invoke hg-active by hand, and capture stdout and stderr >> separately? What does "which hg-active" report? The only ways you >> should be seeing "remote:" in your active list are: >> >> 1) Possibly due to $PATH settings or being logged in to a different >> machine, maybe you're NOT using the updated tools, so the "remote:" >> that goes to stderr is being captured incorrectly. (That's the bug >> that we fixed.) >> >> 2) Our fix could have been incomplete, and you've encountered a case >> where "remote:" is going to stdout, in which case we would want to >> know what's special about your setup. >> >> 3) Our fix could have been incorrect, but it's reasonably >> straightforward, and has been in place for quite a while now, so again >> we would want to know what was different about your repository and/or >> its parent or parent path. >> >> We can't tell the difference without a pointer to the webrev in >> question, and/or more info about your environment. >> >> --Mark >
