[Rivet] rivet-mkhtml in 67b

[Dmitri Konstantinov]

Hi Andy,

Good news, It looks like there is a bug in new genser environment 
scripts for rivet.

It seems that latex auxiliary paths can not contain double slash:

TEXINPUTS=/tmp/dkonst/rivet/RIVET//MCGenerators_lcgcmt67b/rivet/2.1.2/x86_64-slc6-gcc48-opt/share/Rivet/texmf/tex::/afs/cern.ch/group/zh/latex/styles:/tmp/dkonst/rivet/RIVET/MCGenerators_lcgcmt67b/rivet/2.1.2/share/sources/doc
HOMETEXMF=/tmp/dkonst/rivet/RIVET//MCGenerators_lcgcmt67b/rivet/2.1.2/x86_64-slc6-gcc48-opt/share/Rivet/texmf:
LATEXINPUTS=/tmp/dkonst/rivet/RIVET//MCGenerators_lcgcmt67b/rivet/2.1.2/x86_64-slc6-gcc48-opt/share/Rivet/texmf/tex::/tmp/dkonst/rivet/RIVET/MCGenerators_lcgcmt67b/rivet/2.1.2/share/sources/doc
TEXMFHOME=/tmp/dkonst/rivet/RIVET//MCGenerators_lcgcmt67b/rivet/2.1.2/x86_64-slc6-gcc48-opt/share/Rivet/texmf:
TEXMFCNF=/tmp/dkonst/rivet/RIVET//MCGenerators_lcgcmt67b/rivet/2.1.2/x86_64-slc6-gcc48-opt/share/Rivet/texmf/cnf:

In this case kpsewhich (used in make-plots) trancates path up to this 
"//" and as result we have wrong search paths....

In my latex case search path was truncated to 
/afs/cern.ch/sw/lcg/external/ and therefore search takes enormous amount 
of time.

We will fix it asap.

Cheers,
     Dima


On 7/22/14 11:22 AM, Andy Buckley wrote:
> On 22/07/14 09:45, Dmitri Konstantinov wrote:
>> Hi Andy,
>>
>> I am wondering if you aware of any problem with rivet-mkhtml within
>> MCGenerators_lcgcmt67b instillation:
>>
>> When I run "rivet-mkhtml Rivet.yoda" it becomes frozen and Ctrl-C gives
>> the following output:
>>
>> ^CTraceback (most recent call last):
>>    File
>> "/afs/.cern.ch/sw/lcg/external//MCGenerators_lcgcmt67b/rivet/2.1.2/x86_64-slc6-gcc48-opt/bin/rivet-mkhtml",
>> line 306, in <module>
>> Traceback (most recent call last):
>>    File
>> "/afs/.cern.ch/sw/lcg/external//MCGenerators_lcgcmt67b/rivet/2.1.2/x86_64-slc6-gcc48-opt/bin/make-plots",
>> line 2482, in <module>
>>      p.wait()
>>    File
>> "/afs/.cern.ch/sw/lcg/external/Python/2.7.4/x86_64-slc6-gcc48-opt/lib/python2.7/subprocess.py",
>> line 1357, in wait
>>      Popen(mp_cmd).wait()
>>    File
>> "/afs/.cern.ch/sw/lcg/external/Python/2.7.4/x86_64-slc6-gcc48-opt/lib/python2.7/subprocess.py",
>> line 1357, in wait
>>      pid, sts = _eintr_retry_call(os.waitpid, self.pid, 0)
>>    File
>> "/afs/.cern.ch/sw/lcg/external/Python/2.7.4/x86_64-slc6-gcc48-opt/lib/python2.7/subprocess.py",
>> line 478, in _eintr_retry_call
>>      return func(*args)
>> KeyboardInterrupt
>>      pid, sts = _eintr_retry_call(os.waitpid, self.pid, 0)
>>    File
>> "/afs/.cern.ch/sw/lcg/external/Python/2.7.4/x86_64-slc6-gcc48-opt/lib/python2.7/subprocess.py",
>> line 478, in _eintr_retry_call
>>      return func(*args)
>> KeyboardInterrupt
>>
>>
>> The 67b rivet has the following dependencies:
>>
>> Boost=1.53.0_python2.7/GSL=1.10/HepMC=2.06.08/Python=2.7.4/cython=0.19.1/fastjet=3.0.3/rivet=2.1.2/swig=1.3.40/yamlcpp=0.3.0/yoda=1.1.0
>>
>>
>> While it works fine for rivet from 68.
>>
>> If it is unknown issue then we will try to investigate it.
> Hi Dima,  CC Rivet dev list,
>
> It's an unknown issue as far as I'm aware. By the looks of things it's
> getting stuck somewhere in the subprocess execution that runs latex,
> pdf2png, etc. -- that is pure Python and I don't think any of the
> dependencies should be involved. I never saw this myself, but strange
> that it works with 68 but not 67b... is the Python version/build different?
>
> Andy
>