Reprozip does not preserve PATH

[gdevenyi]

In the experiment I'm testing with, the first command is a perl script which starts with

#! /usr/bin/env perl

This is intended to launch the script using the perl interpreter. Since script.sh includes this

MODULE_VERSION_STACK=3.2.9 PATH=. myprogram

PATH from the original running system isn't preserved, and env can't find perl, so the experiment doesn't run.

[remram44]

(assuming you are using the 'directory' unpacker, it is the only one which changes the PATH)

I'm actually not sure what this is. What was the original PATH? I went over the code but didn't find anything that looked like what you encountered, in any case can you try the latest build: reprounzip-0.3.1-7-g51dc0a1.tar.gz? (should also fix your other issues)

[gdevenyi]

Original PATH was

PATH=/home/m/mchakrav/gdevenyi/myENV/bin:/home/m/mchakrav/pipitone/CIVET-1.1.12/Linux-x86_64/CIVET-1.1.12/progs:/home/m/mchakrav/pipitone/CIVET-1.1.12/Linux-x86_64/CIVET-1.1.12:/home/m/mchakrav/pipitone/CIVET-1.1.12/Linux-x86_64/bin:/home/m/mchakrav/pipitone/CIVET-1.1.12/bin:/scinet/gpc/graphics/ffmpeg-0.8.2-centos6/bin:/scinet/gpc/graphics/ImageMagick-6.6.7-7-centos6/bin:/scinet/gpc/x11/6/bin:/scinet/gpc/tools/Python/Python272-shared/bin:/scinet/gpc/compilers/gcc-4.6.1/bin:/scinet/gpc/intel/ics/composer_xe_2011_sp1.9.293/bin/intel64:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/lpp/mmfs/bin:/opt/torque/bin:/opt/torque/sbin:/scinet/gpc/tools/editors/nano/nano-2.2.4/bin:/scinet/gpc/bin6:/scinet/gpc/tools/gnuparallel/20140622/bin:/scinet/gpc/x11/6/bin/old:/home/m/mchakrav/gdevenyi/.local/bin

[gdevenyi]

Here's the full script.sh the system produces

#!/bin/sh

export LD_LIBRARY_PATH=/home/ace/test/root/usr/lib/x86_64-linux-gnu/libfakeroot:/home/ace/test/root/lib/i386-linux-gnu:/home/ace/test/root/usr/lib/i386-linux-gnu:/home/ace/test/root/usr/local/lib:/home/ace/test/r$

cd /home/ace/test/root/scratch/m/mchakrav/gdevenyi/civet-test && MODULE_VERSION_STACK=3.2.9 PATH=. /home/m/mchakrav/pipitone/CIVET-1.1.12/Linux-x86_64/CIVET-1.1.12/CIVET_Processing_Pipeline

You can see immediate the command it tries to run will fail because that path doesn't exist, but if I prefix it with /home/ace/test/root then it tries to run, and falls over on the perl call immediately

[gdevenyi]

I also just noticed, this was the command i submitted to reprozip, all of my options are missing in the script.sh

reprozip trace CIVET_Processing_Pipeline -sourcedir /home/m/mchakrav/gdevenyi/scratch/civet-test/input -targetdir /home/m/mchakrav/gdevenyi/scratch/civet-test/output -prefix dtig -N3-distance 200 -lsq12 -resample-surfaces -thickness tlink 20 -combine-surface -granular -no-VBM -spawn -run  H001_CAMH

[remram44]

Wait... Are you using Python 2.6?

[gdevenyi]

(myENV)gpc-f103n084-$ python -V Python 2.7.2

ace@delta:~/test$ python -V Python 2.7.8 :: Anaconda 2.0.1 (64-bit)

[remram44]

Python bug 13676 is the reason we don't support Python 2.6; it will make you lose every entries but one in the arguments and environment lists.

[remram44]

Looking at your configuration (posted in #55) it looks like the machine you are packing on is affected. I thought this only affected Python 2.6 though; if it affects some 2.7 versions I might have to work around that bug...

[remram44]

Confirmed, this is fixed in 2.7.3 onwards. This was released in April 2012 and even Debian stable shouldn't run into it.

I'm going to mark as wontfix for now, since working around this would require quite the effort.

[gdevenyi]

I'm running on a supercomputing cluster, which as one might expect, is very conservative about updates. I'll have to do a user-install of a more recent python. Thanks.

[gdevenyi]

Confirmed that updating python fixes this problem.

Can reprozip do a version check somewhere?

[remram44]

Yes, the next release will refuse to run on an incompatible Python (634ca22c). The Python bug page just didn't state that some 2.7.x versions were affected.