| << Back to previous view |
|
[QB-1572] AccuRev plugin doesn't work with AccuRev 5.7
|
|
| Status: | Closed |
| Project: | QuickBuild |
| Component/s: | None |
| Affects Version/s: | 4.0.90, 5.0.10 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Sten Rosendahl | Assigned To: | Robin Shen |
| Resolution: | Won't Fix | Votes: | 0 |
| Remaining Estimate: | Unknown | Time Spent: | Unknown |
| Original Estimate: | Unknown | ||
| Environment: | Windows 7 Enterprise SP1 | ||
| Description |
|
in Quickbuild 4/5 when running the checkout step with an AccuRev repository on a machine with AccuRev 5.7 installed, the step fails with the following output:
Failed to run command: accurev help security Command return code: 1 Command error output: iconv_open("(null)Fil??ú?LANG" [(null)Fil??ú?LANG], "(null)Fil??ú?LANG" [(null)Fil??ú?LANG]): errno=22 AccuRev does not recognize encoding (null)Fil??ú?LANG. |
| Comments |
| Comment by Robin Shen [ 02/Mar/13 12:43 AM ] |
| QB itself does not force any encoding. Can you please login to the server machine as the user running QB process, and run "accurev help security" to see if it works? |
| Comment by Sten Rosendahl [ 04/Mar/13 03:22 PM ] |
|
Running "accurev help security" works fine on the command line. Actually, older QB/AccuRev releases also failed on my machine so I guess some local setting is wrong. I was successful in making it work if I added this line to wrapper.conf:
wrapper.lang=en_US So I guess the language setting on my Win7/Java environment is messed up? |
| Comment by Robin Shen [ 05/Mar/13 12:40 AM ] |
| Thanks for the info. Is QB started via NT service or simply "server console"? |
| Comment by Sten Rosendahl [ 05/Mar/13 11:04 AM ] |
| I started it via the NT service. |
| Comment by Robin Shen [ 06/Mar/13 12:33 AM ] |
|
I guess the OS user running the NT service does not have exactly the same environment as the user you successfully run "accurev help security" from command line. To verify, you may start QB from the console directly and check if it works without the "wrapper.lang=en_US"
|
| Comment by Sten Rosendahl [ 06/Mar/13 03:23 PM ] |
|
Actually, it turns out it's a Windows bug: http://blogs.msdn.com/b/michkap/archive/2010/03/19/9980203.aspx
The Locale and LocaleName values in the registry was inconsistent; when I changed them to be the same language all is well. On our build servers, we only use en-US locale so these have always worked. |
| Comment by Robin Shen [ 07/Mar/13 01:58 AM ] |
| Thanks for findings. Closing now. |