23 January 2013

325. Compiling ECCE 6.4 on Debian Testing

!NOTE! If you provide ECCE with 'localhost' as the hostname, be aware that this will block outside access: http://www.nwchem-sw.org/index.php/Special:AWCforum/st/id858/#post_3178

There's a new release of ECCE 6.4 out which fixes the following bug: http://verahill.blogspot.com.au/2012/11/minor-bug-in-ecce.html


A note on Java: I've only had luck with the openjdk packages -- not with the Oracle/sun java ones (see here: http://verahill.blogspot.com.au/2012/06/building-ecce-on-debian-testingwheezy.html).

This build was tested in a chrooted Testing/Wheezy i.e. I should've caught most of the necessary packages.


Compiling:
Download the source to ecce from http://ecce.emsl.pnl.gov/using/download.shtml, and put it in e.g. ~/tmp

sudo apt-get install bzip2 build-essential autoconf libtool ant pkg-config gtk+-2.0-dev libxt-dev csh gfortran openjdk-7-jdk python-dev libjpeg-dev imagemagick xterm
cd ~/tmp
tar xvf ecce-v6.4-src.tar.bz2
cd ecce-v6.4/
export ECCE_HOME=`pwd`
cd build/
./build_ecce
Hit return if xterm was found... The /home/sandbox/tmp/ecce-v6.4/scripts/sysdir script identifies the build platform directory as: empty Because this value is empty no platform-specific parent directory will be created for ECCE executables, libraries, etc. This works fine unless your site needs support for multiple platforms. Finished checking prerequisites for building ECCE. Do you want to skip these checks for future build_ecce invocations (y/n)? Y
./build_ecce
Xerces built
./build_ecce
Mesa OpenGL built
./build_ecce
wxWidgets built
./build_ecce
running build_ext wxPython built
./build_ecce
Apache HTTP server built
./build_ecce
Making combined tar file ecce.v6.4.tar Copying NWChem binary distribution nwchem-6.1.1-binary-rhel5-gcc4.1.2-m64.tar.bz2 Copying NWChem common distribution nwchem-6.1.1-binary-common.tar.bz2 Concatenating install script and combined tar file ecce.v6.4.tar create_ecce_bin finished ECCE built and distribution created in /home/sandbox/tmp/ecce-v6.4
cd ../ ./install_ecce.v6.4.csh

And see the next section for the installation steps.
The compilation steps take progressively longer and longer, so be patient during the build.

Installing:
Digital ink is cheap, so I'll show the whole process:
./install_ecce.v6.4.csh
Main ECCE installation menu =========================== 1) Help on main menu options 2) Prerequisite software check 3) Full install 4) Full upgrade 5) Application software install 6) Application software upgrade 7) Server install 8) Server upgrade IMPORTANT: If you are uncertain about any aspect of installing or running ECCE at your site, please refer to the detailed ECCE Installation and Administration Guide at http://ecce.pnl.gov/docs/installation/2864B-Installation.pdf Hit at prompts to accept the default value in brackets. Selection: [1] 3 Host name: [beryllium] localhost Application installation directory: [/home/sandbox/tmp/ecce-v6.4/ecce-v6.4/apps] /home/sandbox/.ecce/apps Server installation directory: [/home/sandbox/.ecce/server] ECCE v6.4 will be installed using the settings: Installation type: [full install] Host name: [localhost] Application installation directory: [/home/sandbox/.ecce/apps] Server installation directory: [/home/sandbox/.ecce/server] Are these choices correct (yes/no/quit)? [yes] Installing ECCE application software in /home/sandbox/.ecce/apps... Extracting application distribution... Extracting NWChem binary distribution... Extracting NWChem common distribution... Extracting client WebHelp distribution... Configuring application software... Configuring NWChem... Installing ECCE server in /home/sandbox/.ecce/server... Extracting data server in /home/sandbox/.ecce/server/httpd... Extracting data libraries in /home/sandbox/.ecce/server/data... Extracting Java Messaging Server in /home/sandbox/.ecce/server/activemq... Configuring ECCE server... ECCE installation succeeded. *************************************************************** !! You MUST perform the following steps in order to use ECCE !! -- Unless only the user 'sandbox' will be running ECCE, start the ECCE server as 'sandbox' with: /home/sandbox/.ecce/server/ecce-admin/start_ecce_server -- To register machines to run computational codes, please see the installation and compute resource registration manuals at http://ecce.pnl.gov/using/installguide.shtml -- Before running ECCE each user must source an environment setup script. For csh/tcsh users add this to ~/.cshrc: if ( -e /home/sandbox/.ecce/apps/scripts/runtime_setup ) then source /home/sandbox/.ecce/apps/scripts/runtime_setup endif For sh/bash users, add this to ~/.profile or ~/.bashrc: if [ -e /home/sandbox/.ecce/apps/scripts/runtime_setup.sh ]; then . /home/sandbox/.ecce/apps/scripts/runtime_setup.sh fi ***************************************************************

Instead of following the instructions above I normally do:
echo 'export ECCE_HOME=/home/sandbox/.ecce/apps' >> ~/.bashrc
echo 'PATH=$PATH:/home/sandbox/.ecce/server/ecce-admin/:/home/sandbox/.ecce/apps/scripts/' >> ~/.bashrc
echo 
source ~/.bashrc

You can now start ecce by either doing
ecce

or if that complains, do
start_ecce_server

then waiting a little while (10 s), followed by
ecce


Apppendix:

Selecting Java version
sudo update-alternatives --config java
There are 7 choices for the alternative java (providing /usr/bin/java). Selection Path Priority Status ------------------------------------------------------------ 0 /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java 1061 auto mode 1 /usr/bin/gij-4.4 1044 manual mode 2 /usr/bin/gij-4.6 1046 manual mode 3 /usr/bin/gij-4.7 1047 manual mode 4 /usr/lib/jvm/j2re1.6-oracle/bin/java 314 manual mode 5 /usr/lib/jvm/j2sdk1.6-oracle/jre/bin/java 315 manual mode 6 /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java 1061 manual mode * 7 /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java 1051 manual mode

I've got ECCE running fine with openjdk 7 as well as openjdk 6.

22 January 2013

324. Setting up a private git server

Update 11 Feb 2013: fixed a typo that ruined everything.

I've recently moved one of my more mature projects to sourceforge.net, which allowed me to re-discover the joys of using a version management system, in this case git. While I've spent some time playing with SVN in the past, git feels more natural to me. That's it's used widely in the FOSS community certainly doesn't hurt either.

So that got me interested in setting up a local git server for projects that may or may not result in anything tangible i.e. projects that I don't want to put online, but are under so much flux that they may break anytime (and I thus want to be able to roll back).

[A pointer to my students: you can obviously use git to maintain versions of your .tex documents as well...]

In this particular case the development machine and the git host are the same. The project is called shellnmr (an attempt to make a bash-like shell in python for NMR processing)

This is very much inspired by/stolen from: http://tumblr.intranation.com/post/766290565/how-set-up-your-own-private-git-server-linux


Getting set up:

On the git host (which has not yet got a copy of the source code)
sudo apt-get install git
mkdir ~/work/programming/var -p
cd ~/work/programming/var
mkdir shellnmr
cd shellnmr/
git init --bare
Initialized empty Git repository in /home/me/work/programming/var/shellnmr
First time:
I''ll use localhost below because in this particular example the git host and the development machine is the same.

On the/a development machine, where we keep the already existing project in ~/work/shellnmr


cd ~/work/shellnmr
git init
Initialized empty Git repository in /home/me/work/shellnmr/.git/
git add . git commit -m 'initial commit'
[master (root-commit) 5214860] initial commit 2 files changed, 178967 insertions(+) create mode 100644 functions.py create mode 100755 main.py
git remote rm origin git remote add origin me@localhost:/home/me/work/programming/var/shellnmr git push origin master
Counting objects: 2, done. Delta compression using up to 3 threads. Compressing objects: 100% (18/18), done. Writing objects: 100% (2/2), 339.14 KiB, done. Total 2 (delta 5), reused 0 (delta 0) To me@localhost:/home/me/work/programming/var/shellnmr * [new branch] master -> master


Everyday usage:

Say you've edited the code on your development machine and want to commit the changes:
git commit -a
git push

Easy.

Let's say you go home and want to continue editing the code there and that this is the first time you're doing so:
git clone user@githost:/home/me/work/programming/var/nmrshell nmrshell-code

When you're done editing, just commit as normal;
git commit -a
git push

Let's say you've edited the code on another computer, committed the code, and then want to get the latest updates on your regular development machine again:
git pull origin master

And that's about it.

GUI - gitk:
The debian repos have a git GUI as well. To install do
sudo apt-get install git-gui gitk

Start it by launching gitk from the directory where you keep your files (on the development machine)

20 January 2013

323. Wine 1.5.22 on Debian Testing/Wheezy. Compiling using multiarch

UPDATE 16 May 2013: See here for Wine 1.5.30: http://verahill.blogspot.com.au/2013/05/416-wine-1530-in-chroot.html

Another update: It seems like your mileage in terms of how well Wine will work for you will vary using this method. It works fine for me and I suspect it's because I've built earlier Wine versions of my systems and have ia32-libs-dev installed. This package is no longer available in Testing. ia32-libs installs the libs you need, but does not provide symlinks between .so and .so.X files -- you can probably do that by hand if necessary though. It's not for beginners.

An additional thing to remember is that the 1.5 series of Wine is a development series -- 1.4 is the stable series which is meant for end users. Progress made in 1.5 will be included in 1.6.

NOTE: there are a couple of issues, and they will depend on how your system is set up.
* libosmesa6-dev:i386 will require mesa-common-dev:i386 which will remove libosmesa6-dev:amd64 and more, which is bad.
* libglu1-mesa-dev:i386 depends on libgl1-mesa-dev:i386 which will remove libgl1-mesa-dev:amd64 and more, which is bad.
*  libgstreamer-plugins-base0.10-dev:i386 depends on libgstreamer0.10-dev:i386 which depends on gir1.2-gstreamer-0.10:i386 which depends on gir1.2-freedesktop:i386 which depends on gir1.2-glib-2.0:i386 which depends on libgirepository-1.0-1:i386 which will remove a whole lot of packages (132 on one of my systems, including gnome, gdm3 etc.)

I'm working on figuring out what's triggering this on some systems but not others.
In the mean time see http://verahill.blogspot.com.au/2013/01/308-compiling-wine-1521-on-debian.html to see how to build wine in a chroot, which is safe. You can then install that .deb package on your normal system and HOPEFULLY there won't be any broken dependencies. You won't need the -dev:i386 packages on the install target.

ldd `which wine` 
linux-gate.so.1 => (0x55573000) libwine.so.1 => /usr/local/lib/libwine.so.1 (0x55576000) libpthread.so.0 => /lib32/libpthread.so.0 (0x556ec000) libc.so.6 => /lib32/libc.so.6 (0x55705000) libdl.so.2 => /lib32/libdl.so.2 (0x55867000)
so you really don't seem to need much in the way of shared libs installed.

A new incremental version of wine is out.

There's little difference between building 1.5.21 and 1.5.22 but here it is anyway. The build is very easy on an up-to-date installation of Testing/Wheezy. If you are on stable, the list over needed packages can be found in this post.

See here for recent changes between different Wine versions: http://linux.softpedia.com/progChangelog/Wine-Changelog-148.html

Compiling
sudo dpkg --add-architecture i386
sudo apt-get update

sudo apt-get install libx11-dev:i386 libfreetype6-dev:i386 libxcursor-dev:i386 libxi-dev:i386 libxxf86vm-dev:i386 libxrandr-dev:i386 libxinerama-dev:i386 libxcomposite-dev:i386 libglu-dev:i386 libosmesa-dev:i386 libglu-dev:i386 libosmesa-dev:i386 libdbus-1-dev:i386 libgnutls-dev:i386 libncurses-dev:i386 libsane-dev:i386 libv4l-dev:i386 libgphoto2-2-dev:i386 liblcms-dev:i386 libgstreamer-plugins-base0.10-dev:i386 libcapi20-dev:i386 libcups2-dev:i386 libfontconfig-dev:i386 libgsm1-dev:i386 libtiff-dev:i386 libpng-dev:i386 libjpeg-dev:i386 libmpg123-dev:i386 libopenal-dev:i386 libldap-dev:i386 libxrender-dev:i386 libxml2-dev:i386 libxslt-dev:i386 libhal-dev:i386 libcurl4-openssl-dev:i386 gettext prelink bzip2 bison flex oss4-dev checkinstall ocl-icd-libopencl1:i386 opencl-headers gcc-multilib

mkdir ~/tmp
cd ~/tmp
wget http://prdownloads.sourceforge.net/wine/wine-1.5.22.tar.bz2
tar xvf wine-1.5.22.tar.bz2
cd wine-1.5.22/
./configure
config.status: executing include/wine commands config.status: executing Makefile commands configure: Finished. Do 'make' to compile Wine.
time make -j4 sudo checkinstall --install=no
***************************************** **** Debian package creation selected *** ***************************************** This package will be built according to these values: 0 - Maintainer: [ root@lithium ] 1 - Summary: [ wine 1.5.22 ] 2 - Name: [ wine ] 3 - Version: [ 1.5.22 ] 4 - Release: [ 1 ] 5 - License: [ GPL ] 6 - Group: [ checkinstall ] 7 - Architecture: [ amd64 ] 8 - Source location: [ wine-1.5.22 ] 9 - Alternate source location: [ ] 10 - Requires: [ ] 11 - Provides: [ wine ] 12 - Conflicts: [ ] 13 - Replaces: [ ] [..] Copying files to the temporary directory...
sudo dpkg -i wine_1.5.22-1_amd64.deb

where 4 is the number of cores on your build machine (see here and here for -jN). The build took 13 minutes on a three-core AMD Athlon II X3 445 (3.1 GHz) with -j4. The 'Copying files to...' can take quite a while, so let it run to completion.

Anyway, that's it. An easy build.