Wednesday, July 07, 2010
PyCon India 2010
If you have experience in Python and interested in presenting paper, One can submit their proposal here http://in.pycon.org/2010/cfp. Call for proposal is open till July 31. You can find talks here.
http://in.pycon.org/2010/talks.
Python has been used with almost all the operating systems, Java environment, .NET, Embedded and Mobile devices. Whatever technology you are using or mastered, you should know at least one nice scripting language like Python or Ruby to solve your own problems. You can write 10 or 20 lines of code in 5 minutes and it can save you a day or week (that depends on your manual work complexity). Python would be useful for writing small throw away scripts to large enterprise applications.
Copy from BangPypers Mail Archive:
http://mail.python.org/pipermail/bangpypers/2010-July/004702.html
Tuesday, June 01, 2010
rBuilder 4.1.2 on Dell R710- fails to Boot with Kernel Panic
Error seems to be because of swiotlb initialization failure.
http://lists.xensource.com/archives/html/xen-devel/2007-11/msg00887.html
From above mail archive.
< mail archive >
Have you assigned any physical devices to this domU? If not then it is not allowed to request contiguous multi-page allocations, and this will cause swiotlb initialization to fail (and hence panic the kernel). If you do not assign any physical devices to the domU then there is no point in it having a swiotlb anyway
< mail archive >
Extract from the console log
< error >
.................
......................
...........................
Kernel panic - not syncing: No suitable physical memory available for SWIOTLB buffer!
Use dom0_mem Xen boot parameter to reserve
some DMA memory (e.g., dom0_mem=-128M).
...
.....
< /error >
Solution which worked for me.
Default installation of rbuilder4.1.2 on dell R710 have a kernel parameter "dom0_mem=2048MB" which when changed to dom0_mem=512MB made xen kernel to boot properly.
One needs to enter into edit mode at grub itself otherwise system will keep booting and rebooting in cycles.
After first boot edit /etc/grub.conf file with the kernel parameter as dom0_mem=512MB.
cheers,
make world open.
Monday, February 22, 2010
Scons: TypeError: coercing to Unicode: need string or buffer, NoneType found
TypeError: coercing to Unicode: need string or buffer, NoneType found
Error above is a common python error which occurs when one create a dictionary object(key,value) list with one or more keys with value as "None". We have to ensure that all the keys are having value to fix the above error.
Scons run without any failure when invoked being on cygwin 1.7.1 shell environment but fails with the TypeError as above in our case when invoked remotely through ssh.
Scons TypeError is as a result of USERPROFILE variable not getting set. Once USERPROFILE is set explicitly from .bashrc, scons run successfully.
As evident from the python error USERPROFILE was having value as "None", by setting appropriate value will resolve the issue.
USERPROFILE default value on WINNT is C:\Document And Settings\
export USERPROFILE="C:\Documents and Settings\build"
build is the user logged in in our case.
We had issues with other application run on cygwin bash shell when we had some junk/non-default value set to USERPROFILE. We had issues running BullsEye code coverage tool with non-default value.
BullsEye failed with an error as "Exception: SHGetFolderPath failure". Default USERPROFILE value in .bashrc fixed the BullsEye failure.
cheers,
make world open.
Wednesday, January 20, 2010
fatal error C1902: Program database manager mismatch; please check your installation
Build/Test automation of VC2005 project fails with the above error message in case automation scripts is having logic of *nix-win communication over ssh.
Scenario:
*nix ssh client connects to cygwin ssh server and executes make which uses CL(VC2005 compiler). Run fails with the error message in the subject line.
As evident from the link below.
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=123792
Workaround at the link above made our day and solved the issue.
Workaround: Run cygwin ssh server with the same user as that of *nix user through which one is connecting over ssh.
In our case user in question was "build". So we ran cygwin ssh server with "build" user and had *nix user as "build" to connect over ssh for script run.
By default cygwin ssh server run with user as LocalSystem Account. To make it run with "build" user we followed the steps below.
Create a user "build" with Administrative privilege on cygwin box.
Steps to run cygwin ssh server with "build" user.
1. Change the login ID of the Cygwin sshd service.
- From the Windows Start menu, click Settings > Control Panel > Administrative Tools > Services.
- From the Services window, right-click CYGWIN sshd, and select Properties.
- From the Properties window, select the General tab, and click Stop to stop the sshd service.
Next, select the Log on tab, Under the Log on as section or prompt, clear the Local System account radio button, and select This account. Type .\build as the ID and type the password for the account. Click Apply.
2. Grant additional rights to the build account so that "build" user has required privileges in addition to membership to the Administrators group.
- From the Windows Start menu, click Settings > Control Panel > Administrative Tools > Local Security Policy.
- From the Local Security Settings window, expand Local Policies, and select User Rights Assignment.
- From the resulting page that appears on the right, verify that the root account has the following four rights:
* Adjust memory quotas for a process
* Create a token object
* Log on as a service
* Replace a process level token
If not, add "build" as a user with the four rights.
For Win2000, the first item in the list above is displayed as Increase quotas instead of Adjust memory quotas for a process.
* Close Local Security Settings window.
3. From a Cygwin console panel, change ownership of the following directories and files to build:
* $ chown build /var/log/sshd.log
* $ chown -R build /var/empty
* $ chown build /etc/ssh*
4. Restart the Cygwin sshd server.
- From the Properties page of the Cygwin sshd server, select the General tab, and click Start. Verify that Cygwin is now running under the build user account.
- OR From cygwin prompt say $net start sshd.
Thanks to the IBM Knowledge Base for the above solution.