How to handle Chinese file name correctly in Mldonkey

1. I have Mandriva and locale of Mldonkey isn't printed in log file. Therefore I checked the command that starts mldonkey service (default is /etc/init.d/mldonkey). I saw the following
   daemon --user mldonkey --check mlnet $NICE $mldonkey $params >/dev/null 2>&1 &
   and I changed it to
daemon --user mldonkey --check mlnet $NICE $mldonkey $params >/dev/null 2>$LOGFILE &
   
2. After I restart Mldonkey servcie, I check the log file again(default is /var/log/mldonkey.log). I saw the following
   [cO] Language en_US, locale ISO88591, ulimit for open files 1024
3. The function daemon is defined in /etc/init.d/functions and the following is invoked
   su -s /bin/bash - $user -c "$corelimit > /dev/null 2>&1 ; $*"
   which means mldonkey service is started in a login bash shell of user mldonkey and the file .bash_profile in its home directory should have the correct environment variables set.
4. I added the following line to the file /var/lib/mldonkey/.bash_profile (or ~/.i18n)
   export LC_ALL=zh_CN.GBK
   I didn't set the above to zh_CN.utf8 since my samba also had the line unix charset = GBK in smb.conf
5. After restarting the mldonkey service, the following is shown in the log file and Chinese file names are handled correctly (instead of using underscores everywhere)
   [cO] Language ZH_CN, locale GBK, ulimit for open files 1024
   

Upgrade error 3211266 from vista to windows 7

At ~63-66% of the last stage of the upgrade, if there's a message "Setup can't continue. Your computer will now restart, and your previous version of Windows will be restored.", one should check logs in the folder $WINDOWS.~BT\Sources\Panther 
setuperr.log
setupact.log 

If the following line is appearing in setupact.log
InstallWindows:Error Type = 3211266. Check whether the following lines are found in the same file
MIG Calling IDiscovery::Discover for Plugin={ServerPath="%SYSTEM32%\migration\commig.dll", CLSID={AB1D4748-682E-40AE-8CFA-6E3F8A5ED6BC}, ThreadingModel=Apartment}, UserContext:System
COutOfProcPluginFactory::LaunchSurrogateHost: WaitForSingleObject for hInitCompletionEvent timeout. There's typically a FatalError in the next few lines.

Implement all the following steps can fix the error and finish the upgrade:

• Uninstall TightVNC
• Uninstall Pure Codec
• System locale set to English

It's recommended to uninstall any Anti-virus programs before the upgrade but I didn't uninstall mine.

Ref: Windows 7 upgrade fails during migration (63%-66%)

pygooglevoice 0.5

When I tried to run gvoice within Asterisk 1.6 by System command, I always got an error after using the method described here.

After some digging, I found the following were not clear to me:

1. The configuration file ~/.gvoice is unavaible to Asterisk. I need to invoke gvoice with all necessary arguments.
2. The phoneType argument is required for a Gizmo5 ringback number, which is 7. I found the declaration of call in voice.py.
   def call(self, outgoingNumber, forwardingNumber=None, phoneType=None, subscriberNumber=None). Therefore if I invoke gvoice like this
   exten => _X.,n,Set(DB(gv_dialout/channel)=${CHANNEL})
exten => _X.,n,System(/usr/bin/gvoice -e ${ACCTNAME} -p ${ACCTPASS} call ${EXTEN} ${RINGBACK} ${PHONETYPE})
Then it succeeds. RINGBACK is my Gizmo5 747 number and PHONETYPE is 7.
3. It's important to set the key gv_dialout/channel in the Asterisk database before calling the system(gvoice) command in [gv-outbound] since it may take a second or two for the System command to return and the chance is good that Asterisk might receive the ring back call from gvoice before the key gv_dialout/channel is set, which caused the bridge command to fail.