[#QB-1572] AccuRev plugin doesn't work with AccuRev 5.7

QuickBuild

AccuRev plugin doesn't work with AccuRev 5.7

Created: 01/Mar/13 01:46 PM Updated: 07/Mar/13 01:58 AM

Component/s:

None

Affects Version/s:

4.0.90, 5.0.10

Fix Version/s:

None

Original Estimate:	Unknown	Remaining Estimate:	Unknown	Time Spent:	Unknown
Environment:	Windows 7 Enterprise SP1

Description

« Hide

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.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

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?

[ Permlink | « Hide ]

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?

[ Permlink | « Hide ]

Robin Shen [05/Mar/13 12:40 AM]

Thanks for the info. Is QB started via NT service or simply "server console"?

[ Permlink | « Hide ]

Sten Rosendahl [05/Mar/13 11:04 AM]

I started it via the NT service.

[ Permlink | « Hide ]

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"

[ Permlink | « Hide ]

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.

[ Permlink | « Hide ]

Robin Shen [07/Mar/13 01:58 AM]

Thanks for findings. Closing now.