Netbook Redux: rescuing my Asus EeePC 1000HA

So a while back I killed the linux installation on my EeePC 1000HA Netbook. So this weekend I decided rather than fix it... I would just remove it. Well that was a good idea (sarcasm). Not the decision to leave linux off the netbook, that decision was okay... it was my hastiness in removing Linux... Needless to say, I forgot that I was using Grub as my boot loader, so when I removed my linux partition using the live Gparted USB... well bye-bye grub. So the solution....google, which resulted in the following site:

http://forum.eeeuser.com/viewtopic.php?id=59032

The site was very helpful and thankfully the other day I was cleaning up my tech supplies and located the DVD that came with the system. Anyways... I purchased a new USB drive [8GB] (I was surprised to find that my largest drive was only 1GB), and went to work. First I installed the live CD/USB version of Mint Linux on a 1GB stick, booted up the machine and backed up my files. Then I booted off the 8GB stick and followed the instructions on the above linked post. So after hours of prep and figuring out a solution it only took about 30 minutes to get the system restored to its original state. Then came 2 hrs of software updates.... and now the process of getting all my software all loaded up.

So what gets installed.... first off AVG (free), then Firefox (this time 4 RC1), and via the Google Updater: Chrome, Picasa, Gtalk, and updates of Skype, Real, and Acrobat Reader. Then the biggies... OpenOffice (well this time LibreOffice), Java, and Eclipse. Followed by the next item... the reason I decided I would remove the dual boot linux partition... Cygwin. Now I could go through and list what I installed in cygwin, but that would be a long list... but basically C++/GCC and Python plus SVN, then there are a bunch of libraries....

Now lets see how long before I decide to put linux back on my EeePC.

Python2.6, Trac0.11.x, mod_wsgi and mod_python on RHEL5.x

New server and new problems.

Late last year my patched along circa 1999 Dell server decided to go belly up. That server was running Centos-5.2 and hosted my Trac installation running Trac-0.11b, running in Apache using mod_wsgi. So recently we finally replaced the server with a brand spanking new Dell server (heck if its predecessor lasted almost 10years, I hope this new one lasts at least 5years). I installed RHEL5.3 on this server instead of Centos since we (the IT group at work) want to simplify our OS variations and stick with the commercially available RedHat Enterprise Linux. And that is where my problems began.....

Well as we all know RHEL5.x still only includes Python2.4 with the distribution. Centos and other variant have started to include or at least are upgradable to Python2.5. While RHEL5 does include mod_python, mod_wsgi, Python2.4 and Trac0.10.x... I needed Trac0.11.x

Solution: drop RHEL and go with Centos... just kidding

So actually it turns out not to be that bad... you just have to do a lot of manual compliations... so here is my step by step solution:

Step 1. install Python from source, I went with the latest 2.6.1 (not 3 yet since on my Mac I've had backwards compitibility issues and didn't want to deal with them)

./configure --with-threads --enable-shared
make
make altinstall
ldconfig

the 2 key steps: --enable-shared in the configure statement does the work needed later by mod_wsgi and mod_python, and 'make altinstall'  which tells the installation to use /usr/local and to appended the 2.6 to the commands to prevent messing up system scripts which are based on Python 2.4 and in many cases (yum included) do not work with Pytohn2.6. The last step 'ldconfig' simply refreshes the library information which is needed before compiling mod_wsgi or mod_python from source.

optionally required step: if the shared library for Python is not seen in the '.../python2.6/config/' you'll need to add a symbolic link

ln -s ../../libpython2.5.so .

now on my server, the python config directory was at:  /usr/local/lib/python2.6/config

Step 2. install 'mod_wsgi' from source.

./configure --with-python=/usr/local/bin/python2.6
make
make install

here the only statement of difference is to tell mod_wsgi to use python2.6 instead of the system default 2.4, now if you have installation errors check out http://code.google.com/p/modwsgi/wiki/InstallationIssues this page also explains the optional step after the Python installation.


Step 3. install 'mod_python' from source.

./configure --with-python=/usr/local/bin/python2.6
make
make install

as you can see, there is no difference between the methods for compiling mod_python and mod_wsgi. And again the main reason for compiling from source is to enable the use of Python2.6. And since both of these modules will be using Python, this is the reason of compiling Python2.6 with the '--enable-shared' flag.

Step 4. download and install the python setuptools for python 2.6 using the py26.egg.


Step 5.  using easy_install tool from the setuptools in Step 4, install Trac.

easy_install-2.6 trac

this will automatically install Trac.11.x since it is the latest version compatible with Python2.6, and using 'easy_install-2.6' will ensure that you are using Python 2.6

Step 6. configure Apache like instructed by TracModWSGI.

Now that wasn't to painful, the only clevat... now since all these packages have been installed from source, for security purposes, you have to remember on your own to update/patch these installs.

update: I've run into a slight problem where Trac can't access SVN since the libraries aren't 'accessible' by Python2.6, I'l update again when this is solved

update2:  Solution to get the SVN-SWIG installation to work with Python2.6... recompile subversion, only 'change' needed was manually hard coding the version of Python in the './configure' file

# Python: Used for testsuite, and bindings

#PYTHON="`$abs_srcdir/build/find_python.sh`"
PYTHON="/usr/local/bin/python2.6"

 Only remaining issue was where the files were installed to. Presumingly there is another line in the ./configure file to correct this, but I went the 'quick' way... symbolic links.

cd /usr/local/lib/python2.6
ln -s /usr/local/lib/svn-python/* .

I'm really liking SVN with Subversive in Eclipse

Don't get me wrong, I've always been a fan of revision control packages. Many years ago I played with RCS, then moved to CVS. Both worked and did thier jobs, but I never really used themto their peak usuage. Then a few years ago we moved our repositories to Subversion (SVN).... well I wouldn't save move, more as we started from scratch when we realized that no one had commited code to the CVS server for over a year (we also realized that the server had been down almost that long). So any ways we started using SVN. We liked it, it did its job, plus when we started using Trac, it had a nice SVN browser built in.

Anyways, so initially being that I was a fan of Eclipse, I began looking for a plugin. Back then the one I found was Subclipse by Tigris Software. Not surprisingly it work great for my needs at the time, it didn't hurt that it was being developed by Tigris since they also developed SVN.

So SVN it was, we liked it and we've stuck with it. Then when Eclipse Ganymede came out, surprisingly, I couldn't get Subclipse to work. I probably could of made it work, but I didn't feel like figuring it out and I read that the Eclipse team had tapped Polarion's Subversive as the SVN-Team provider. I had trouble there too, and you can read my solution here.

So anyways with the entire group moved to Subversive and all happy with the client, we finally decided to start utilizing one of the start features behind revision control systems... we decided to finally start using trunks and branches.... And why this post.... well I greated my first patch for updating my other trunk....

It was so simple... right click my project in Eclipse, select 'Team'/'Create Patch' it then simply asked me what to compare against, I selected my Trunk, and poof, there was my Patch... so simple, I don't know why we didn't start using these features sooner...