From samuel at unimelb.edu.au  Mon Oct  1 17:53:16 2012
From: samuel at unimelb.edu.au (Christopher Samuel)
Date: Tue, 02 Oct 2012 09:53:16 +1000
Subject: [torquedev] Torque Maui Communication during job submission
In-Reply-To: <076A035A-3C13-4021-94A3-DD263A1CB0E0@grs-sim.de>
References: <076A035A-3C13-4021-94A3-DD263A1CB0E0@grs-sim.de>
Message-ID: <506A2CEC.5010002@unimelb.edu.au>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/08/12 23:55, Suraj Prabhakaran wrote:

> Hello,

Hi Suraj,

> I have been looking into torque and maui communication for some
> days. I have a question regarding job submission. During a qsub
> command, does Maui get the information about the qsub only from
> torque or does it also get directly from the client?

The qsub command doesn't talk to the scheduler (Maui or otherwise) at
all, just to the pbs_server.  Maui will just be talking to pbs_server.

Does that help?

> Again, any pointers to torque-maui documentation with more
> descriptions could be very helpful!

There's a little bit of high level detail on page 30 of the PBS admin
guide, but that's quite old.  Otherwise I suspect you need to use the
source.. :-(

cheers,
Chris
- -- 
 Christopher Samuel        Senior Systems Administrator
 VLSCI - Victorian Life Sciences Computation Initiative
 Email: samuel at unimelb.edu.au Phone: +61 (0)3 903 55545
 http://www.vlsci.org.au/      http://twitter.com/vlsci

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBqLOwACgkQO2KABBYQAh+yQwCeKjPK6ZuATOvq43bKmcbKW+S6
w3gAnjtvcPw8+ykKAfKOcFQ2Gb8Za1eq
=xtPT
-----END PGP SIGNATURE-----

From jbristow at adaptivecomputing.com  Mon Oct  8 12:41:40 2012
From: jbristow at adaptivecomputing.com (Jared Bristow)
Date: Mon, 8 Oct 2012 12:41:40 -0600
Subject: [torquedev] mailinglists are working again
Message-ID: <CAAZtVDXZSV+GHDKS6cCDhxbp195m5Ug0=YoZuC=yLnyoYyiVGg@mail.gmail.com>

Jared Bristow  |  IT Manager : Adaptive Computing
www.adaptivecomputing.com
Direct Line: 801-717-3718 | Fax: 801-717-3738
1712 S. East Bay Blvd. Suite #300
Provo, UT 84606

All,

We recently moved the network on one of our servers which broke the mail
configuration for employees on all the mailing lists.  I believe emails
were still going out to all list members except for anyone with an
adaptivecomputing.com or clusterresources.com email address.  This also
included list administrators not being notified about posts that needed to
be moderated.

As of this morning, the issue has been fixed.  I also went through and
approved any messages that were still awaiting moderator approval.  I also
updated the "list run by" address on each of the list info pages, and the
contact info on the main list overview page:
http://www.supercluster.org/mailman/listinfo

Sorry for any inconvenience.  If you have any more trouble in the future,
please contact me at mailinglists at adaptivecomputing.com

Jared Bristow  |  IT Manager : Adaptive
Computing<http://www.adaptivecomputing.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.supercluster.org/pipermail/torquedev/attachments/20121008/bcf29d15/attachment.html 

From bugzilla-daemon at supercluster.org  Wed Oct 10 21:36:37 2012
From: bugzilla-daemon at supercluster.org (bugzilla-daemon at supercluster.org)
Date: Wed, 10 Oct 2012 21:36:37 -0600 (MDT)
Subject: [torquedev] [Bug 218] Jobs getting stuck in exiting "job recycled
 into exiting on SIGNULL/KILL"
In-Reply-To: <bug-218-38@http.www.clusterresources.com/bugzilla/>
References: <bug-218-38@http.www.clusterresources.com/bugzilla/>
Message-ID: <20121011033637.F257E4121434@http.supercluster.org>

http://www.clusterresources.com/bugzilla/show_bug.cgi?id=218

--- Comment #1 from Chris Samuel <chris at csamuel.org> 2012-10-10 21:36:36 MDT ---
I can confirm this is still happening with latest RHEL 5.8 updates. We did a
full reinstall of the affected cluster last week but it's still happening:

[root at merri-m ~]# xdsh compute -v 'fgrep -h "job recycled into exiting"
/var/spool/torque/mom_logs/201210*' | awk -F\; '{print $NF}' | sort | uniq -c
      2 job recycled into exiting on SIGNULL/KILL from substate 42
      1 job recycled into exiting on SIGNULL/KILL from substate 50
     19 job recycled into exiting on SIGNULL/KILL from substate 57

Any ideas please?    It's driving us (and our users) nuts..

-- 
Configure bugmail: http://www.clusterresources.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at supercluster.org  Thu Oct 11 12:11:15 2012
From: bugzilla-daemon at supercluster.org (bugzilla-daemon at supercluster.org)
Date: Thu, 11 Oct 2012 12:11:15 -0600 (MDT)
Subject: [torquedev] [Bug 218] Jobs getting stuck in exiting "job recycled
 into exiting on SIGNULL/KILL"
In-Reply-To: <bug-218-38@http.www.clusterresources.com/bugzilla/>
References: <bug-218-38@http.www.clusterresources.com/bugzilla/>
Message-ID: <20121011181115.705B041231E4@http.supercluster.org>

http://www.clusterresources.com/bugzilla/show_bug.cgi?id=218

Michael Jennings <mej at lbl.gov> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mej at lbl.gov

--- Comment #2 from Michael Jennings <mej at lbl.gov> 2012-10-11 12:11:15 MDT ---
Based on my reading of the code, the key factor here isn't just that signal 0
or 9 is being sent to the job, but specifically that there are no processes
which received it.  The job states you mention below vary widely (from RUNNING
to PREOBIT to EXITING and others), so I'm not sure that's really significant.

I think the key point is that the processes have vanished, though.

I can confirm that we were seeing it on one of our RHEL5-based clusters when it
was running 2.5.x, but after recently upgrading it to 4.1.1, we haven't seen
that message at all since then (i.e., in over a month).

-- 
Configure bugmail: http://www.clusterresources.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From l.flis at cyf-kr.edu.pl  Sat Oct 13 18:32:07 2012
From: l.flis at cyf-kr.edu.pl (Lukasz Flis)
Date: Sun, 14 Oct 2012 02:32:07 +0200
Subject: [torquedev] torque pbs_mom segfaults
Message-ID: <507A0807.8060304@cyf-kr.edu.pl>

Dear All,


We have observed few pbs_mom crashes which are related to mom-to-mom
communication. We haven't managed to replicate this issue but it seems
it is related to applications which are using TM interface on multiple
nodes (OpenMPI) and one of the processes segfaults.

Our torque version affected by this bug is: 2.5.12

We have filled support ticket for moab/torque, however I'd like to hear
from you if you have ever encountered such an error.

Please find the text file with more details in the attachment.


It's worth to note that even if your pbs_mom or server has crashed with
segfault and didn't dump core file - it is still possible to locate
place in the code where bad happened.

Just use /proc/<pid>/smaps of running mom to find which library or
program owns the page where RIP/EIP is pointing.
Calculate relative rip/eip address and use addr2line to find out line of
code where program crashed.
Binaries with debug symbols will be needed for that (torque-debug
package is sufficient)

Regards,
--
Lukasz Flis



-------------- next part --------------
A non-text attachment was scrubbed...
Name: torque-mom-crash-c.log
Type: text/x-log
Size: 10262 bytes
Desc: not available
Url : http://www.supercluster.org/pipermail/torquedev/attachments/20121014/e1b6bf1e/attachment.bin 

From chenry at ittc.ku.edu  Thu Oct 18 12:34:57 2012
From: chenry at ittc.ku.edu (Charles Henry)
Date: Thu, 18 Oct 2012 13:34:57 -0500 (CDT)
Subject: [torquedev] torque 4.1.2 login shells problem and bash -l workaround
In-Reply-To: <362815471.689888.1350585255643.JavaMail.root@ittc.ku.edu>
Message-ID: <228917449.689890.1350585297441.JavaMail.root@ittc.ku.edu>

Hi list,

I have been following the torque 4 development, and I'm currently using torque 4.1.2 on RHEL6.2.  I have found that I cannot get cluster jobs to run correctly without using "#!/bin/bash -l" in each script.  A few sites (academic and government) are listing this workaround in their cluster FAQs.

Our site uses mpi-selector and needs to source /etc/profile for every cluster job (interactive or not).  I'm going to get a million "why is mpiexec not found questions" if I have to rely on the workaround instead of addressing the problem.  I have looked for settings in the documentation and read the source code.  

The relevant settings are defined globally inside src/resmom/mom_main.c
... (line 205)
int      src_login_batch = TRUE;
int      src_login_interactive = TRUE;
...

and used in src/resmom/start_exec.c
... (line 3736)
void source_login_shells_or_not(
...
  if (((TJE->is_interactive == TRUE) && (src_login_interactive == FALSE)) ||
      ((TJE->is_interactive != TRUE) && (src_login_batch == FALSE)))
...

Where those values are declared as "extern int", so the values from mom_main.c are accessible once the binaries are linked.

There's no error message from the source_login_shells_or_not function, and the code looks very similar to the torque-3 code (except for being wrapped up into functions).  Can anyone shed some light on the problem?

Chuck

From chenry at ittc.ku.edu  Sun Oct 21 07:45:44 2012
From: chenry at ittc.ku.edu (Charles Henry)
Date: Sun, 21 Oct 2012 08:45:44 -0500 (CDT)
Subject: [torquedev] torque 4.1.2 login shells problem and bash -l
	workaround
In-Reply-To: <228917449.689890.1350585297441.JavaMail.root@ittc.ku.edu>
Message-ID: <1892811706.693907.1350827144304.JavaMail.root@ittc.ku.edu>

Sorry to reiterate, pero:

Please, let me know if you've had this issue with torque 4.  
It would be helpful just to confirm that someone else shares this problem in a particular version of torque 4, or for someone else to tell me their installation works correctly.  
It's very important to me and I'm currently under a time crunch to get things working right.  After simplifying and streamlining the cluster for a wider audience, I fear having to introduce ugly workarounds to the cluster users.

Thanks,
Chuck


----- Original Message -----
> From: "Charles Henry" <chenry at ittc.ku.edu>
> To: torquedev at supercluster.org
> Sent: Thursday, October 18, 2012 1:34:57 PM
> Subject: torque 4.1.2 login shells problem and bash -l workaround
> 
> Hi list,
> 
> I have been following the torque 4 development, and I'm currently
> using torque 4.1.2 on RHEL6.2.  I have found that I cannot get
> cluster jobs to run correctly without using "#!/bin/bash -l" in each
> script.  A few sites (academic and government) are listing this
> workaround in their cluster FAQs.
> 
> Our site uses mpi-selector and needs to source /etc/profile for every
> cluster job (interactive or not).  I'm going to get a million "why
> is mpiexec not found questions" if I have to rely on the workaround
> instead of addressing the problem.  I have looked for settings in
> the documentation and read the source code.
> 
> The relevant settings are defined globally inside
> src/resmom/mom_main.c
> ... (line 205)
> int      src_login_batch = TRUE;
> int      src_login_interactive = TRUE;
> ...
> 
> and used in src/resmom/start_exec.c
> ... (line 3736)
> void source_login_shells_or_not(
> ...
>   if (((TJE->is_interactive == TRUE) && (src_login_interactive ==
>   FALSE)) ||
>       ((TJE->is_interactive != TRUE) && (src_login_batch == FALSE)))
> ...
> 
> Where those values are declared as "extern int", so the values from
> mom_main.c are accessible once the binaries are linked.
> 
> There's no error message from the source_login_shells_or_not
> function, and the code looks very similar to the torque-3 code
> (except for being wrapped up into functions).  Can anyone shed some
> light on the problem?
> 
> Chuck

From tbaer at utk.edu  Sun Oct 21 08:33:21 2012
From: tbaer at utk.edu (Troy Baer)
Date: Sun, 21 Oct 2012 10:33:21 -0400
Subject: [torquedev] torque 4.1.2 login shells problem and bash -l
 workaround
In-Reply-To: <1892811706.693907.1350827144304.JavaMail.root@ittc.ku.edu>
References: <1892811706.693907.1350827144304.JavaMail.root@ittc.ku.edu>
Message-ID: <1350830002.9906.13.camel@ashitaka.baer.lan>

On Sun, 2012-10-21 at 08:45 -0500, Charles Henry wrote:
> Please, let me know if you've had this issue with torque 4.  
> It would be helpful just to confirm that someone else shares this
> problem in a particular version of torque 4, or for someone else to
> tell me their installation works correctly.  
> It's very important to me and I'm currently under a time crunch to get
> things working right.  After simplifying and streamlining the cluster
> for a wider audience, I fear having to introduce ugly workarounds to
> the cluster users.

Which job shell startup option did you configure your TORQUE install to
use, --enable-shell-pipe (which is the default IIRC),
--disable-shell-pipe, or --disable-shell-pipe --enable-shell-use-argv?

Also, if you need to prepend "#!$SHELL" to all your jobs, why not just
do that in your submit filter?

FWIW, we just went to TORQUE 4.1.2 on our production NUMA system last
week and have not seen anything like this AFAIK.  However, it's possible
that we're not hitting the problem you're seeing either because of the
job shell startup option we use (--disable-shell-pipe
--enable-shell-use-argv) or because we already had something in our
submit filter that works around the problem.  (Our submit filter always
prepends "#!$SHELL" to job scripts, using either the argument to -S, a
"#!$SHELL" line in the original script, or the user's login shell.)

	--Troy


From chenry at ittc.ku.edu  Mon Oct 22 08:57:50 2012
From: chenry at ittc.ku.edu (Charles Henry)
Date: Mon, 22 Oct 2012 09:57:50 -0500 (CDT)
Subject: [torquedev] torque 4.1.2 login shells problem and bash -l
 workaround
In-Reply-To: <1350830002.9906.13.camel@ashitaka.baer.lan>
Message-ID: <907171292.927.1350917869957.JavaMail.root@ittc.ku.edu>



----- Original Message -----
> From: "Troy Baer" <tbaer at utk.edu>
> To: "Torque Developers mailing list" <torquedev at supercluster.org>
> Sent: Sunday, October 21, 2012 9:33:21 AM
> Subject: Re: [torquedev] torque 4.1.2 login shells problem and bash -l workaround
> 
> On Sun, 2012-10-21 at 08:45 -0500, Charles Henry wrote:
> > Please, let me know if you've had this issue with torque 4.
> > It would be helpful just to confirm that someone else shares this
> > problem in a particular version of torque 4, or for someone else to
> > tell me their installation works correctly.
> > It's very important to me and I'm currently under a time crunch to
> > get
> > things working right.  After simplifying and streamlining the
> > cluster
> > for a wider audience, I fear having to introduce ugly workarounds
> > to
> > the cluster users.
> 
> Which job shell startup option did you configure your TORQUE install
> to
> use, --enable-shell-pipe (which is the default IIRC),
> --disable-shell-pipe, or --disable-shell-pipe
> --enable-shell-use-argv?

I had this issue when configuring none of those.  I also tried "--enable-shell-use-argv" but the symptom was the same.

> Also, if you need to prepend "#!$SHELL" to all your jobs, why not
> just
> do that in your submit filter?

Good idea--I'll keep that in mind as a fallback plan if I can't get it configured to run the login shells on all cluster jobs.

> FWIW, we just went to TORQUE 4.1.2 on our production NUMA system last
> week and have not seen anything like this AFAIK.  However, it's
> possible
> that we're not hitting the problem you're seeing either because of
> the
> job shell startup option we use (--disable-shell-pipe
> --enable-shell-use-argv) or because we already had something in our
> submit filter that works around the problem.  (Our submit filter
> always
> prepends "#!$SHELL" to job scripts, using either the argument to -S,
> a
> "#!$SHELL" line in the original script, or the user's login shell.)
> 
> 	--Troy

Thanks for the feedback.  I'll try adding the "--disable-shell-pipe" to the configuration.

Chuck

From samuel at unimelb.edu.au  Tue Oct 30 21:32:46 2012
From: samuel at unimelb.edu.au (Christopher Samuel)
Date: Wed, 31 Oct 2012 14:32:46 +1100
Subject: [torquedev] torque 4.1.2 login shells problem and bash -l
	workaround
In-Reply-To: <228917449.689890.1350585297441.JavaMail.root@ittc.ku.edu>
References: <228917449.689890.1350585297441.JavaMail.root@ittc.ku.edu>
Message-ID: <50909BDE.9090201@unimelb.edu.au>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19/10/12 05:34, Charles Henry wrote:

> I have been following the torque 4 development, and I'm currently 
> using torque 4.1.2 on RHEL6.2.  I have found that I cannot get 
> cluster jobs to run correctly without using "#!/bin/bash -l" in
> each script.

Just set:

BASH_ENV=/etc/profile

in /var/spool/torque/pbs_environment and that will force
non-interactive bash to run /etc/profile on startup.

In our environment we do:

BASH_ENV=/etc/profile.d/modules.sh

so only modules gets loaded, and then it's up to the users script to
load the right modules for their job..

cheers!
Chris
- -- 
 Christopher Samuel        Senior Systems Administrator
 VLSCI - Victorian Life Sciences Computation Initiative
 Email: samuel at unimelb.edu.au Phone: +61 (0)3 903 55545
 http://www.vlsci.org.au/      http://twitter.com/vlsci

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCQm94ACgkQO2KABBYQAh9h1wCfT/wfJrJ9pVpzjIIye/GujTXq
N0UAoIZkz2PCGeP4JQ0x1MMu6bYJbf60
=90RJ
-----END PGP SIGNATURE-----

From chenry at ittc.ku.edu  Wed Oct 31 08:01:21 2012
From: chenry at ittc.ku.edu (Charles Henry)
Date: Wed, 31 Oct 2012 09:01:21 -0500 (CDT)
Subject: [torquedev] torque 4.1.2 login shells problem and bash
	-l	workaround
In-Reply-To: <50909BDE.9090201@unimelb.edu.au>
References: <228917449.689890.1350585297441.JavaMail.root@ittc.ku.edu>
	<50909BDE.9090201@unimelb.edu.au>
Message-ID: <1265838242.16620.1351692081323.JavaMail.root@ittc.ku.edu>

Hi Chris

Thanks, that is by far the simplest solution.  

I was still trying to debug it yesterday.  I think I'll stop trying and just use that solution, which is compatible with all my other torque configurations, managed through puppet.

Chuck

----- Original Message -----
> From: "Christopher Samuel" <samuel at unimelb.edu.au>
> To: torquedev at supercluster.org
> Sent: Tuesday, October 30, 2012 10:32:46 PM
> Subject: Re: [torquedev] torque 4.1.2 login shells problem and bash -l	workaround
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 19/10/12 05:34, Charles Henry wrote:
> 
> > I have been following the torque 4 development, and I'm currently
> > using torque 4.1.2 on RHEL6.2.  I have found that I cannot get
> > cluster jobs to run correctly without using "#!/bin/bash -l" in
> > each script.
> 
> Just set:
> 
> BASH_ENV=/etc/profile
> 
> in /var/spool/torque/pbs_environment and that will force
> non-interactive bash to run /etc/profile on startup.
> 
> In our environment we do:
> 
> BASH_ENV=/etc/profile.d/modules.sh
> 
> so only modules gets loaded, and then it's up to the users script to
> load the right modules for their job..
> 
> cheers!
> Chris
> - --
>  Christopher Samuel        Senior Systems Administrator
>  VLSCI - Victorian Life Sciences Computation Initiative
>  Email: samuel at unimelb.edu.au Phone: +61 (0)3 903 55545
>  http://www.vlsci.org.au/      http://twitter.com/vlsci
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
> 
> iEYEARECAAYFAlCQm94ACgkQO2KABBYQAh9h1wCfT/wfJrJ9pVpzjIIye/GujTXq
> N0UAoIZkz2PCGeP4JQ0x1MMu6bYJbf60
> =90RJ
> -----END PGP SIGNATURE-----
> _______________________________________________
> torquedev mailing list
> torquedev at supercluster.org
> http://www.supercluster.org/mailman/listinfo/torquedev
> 

From bugzilla-daemon at supercluster.org  Wed Oct 31 11:46:41 2012
From: bugzilla-daemon at supercluster.org (bugzilla-daemon at supercluster.org)
Date: Wed, 31 Oct 2012 11:46:41 -0600 (MDT)
Subject: [torquedev] [Bug 219] New: datarootdir entry missing from
 Makefile.in in 4.1.3 tarball.
Message-ID: <bug-219-38@http.www.clusterresources.com/bugzilla/>

http://www.clusterresources.com/bugzilla/show_bug.cgi?id=219

           Summary: datarootdir entry missing from Makefile.in in 4.1.3
                    tarball.
           Product: TORQUE
           Version: 4.0.*
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Documentation
        AssignedTo: knielson at adaptivecomputing.com
        ReportedBy: griznog at gmail.com
                CC: torquedev at supercluster.org
   Estimated Hours: 0.0


Building torque-4.1.3 on CentOS 6.3 with --enable-drmaa results in these
warnings during ./configure:

configure: creating ./config.status
config.status: creating torque.spec
config.status: creating buildutils/pbs_mkdirs
config.status: creating buildutils/self-extract-head-sh
config.status: creating buildutils/modulefiles
config.status: WARNING:  'buildutils/modulefiles.in' seems to ignore the
--datarootdir setting
config.status: creating buildutils/modulefiles.vers
config.status: creating Makefile
config.status: WARNING:  'Makefile.in' seems to ignore the --datarootdir
setting
config.status: creating contrib/blcr/Makefile
config.status: creating contrib/init.d/Makefile
config.status: creating doc/Makefile
config.status: creating doc/man1/Makefile
config.status: creating doc/man3/Makefile
config.status: creating doc/man7/Makefile
config.status: creating doc/man8/Makefile
config.status: creating src/Makefile
config.status: creating src/cmds/Makefile
config.status: WARNING:  'src/cmds/Makefile.in' seems to ignore the
--datarootdir setting
config.status: creating src/daemon_client/Makefile
config.status: WARNING:  'src/daemon_client/Makefile.in' seems to ignore the
--datarootdir setting
config.status: creating src/gui/Makefile
config.status: WARNING:  'src/gui/Makefile.in' seems to ignore the
--datarootdir setting
config.status: creating src/gui/Ccode/Makefile
config.status: WARNING:  'src/gui/Ccode/Makefile.in' seems to ignore the
--datarootdir setting
config.status: creating src/include/Makefile
...

This appears to be the result of the tarball having it's Makefile.in and
modulefile.in files produced with an autoconf earlier that 2.60, see
http://www.gnu.org/software/autoconf/manual/autoconf.html#Changed-Directory-Variables.
A workaround that worked for me is:

# Add datarootdir to all Makefile.in files:
find . -name Makefile.in -exec sed -i 's/datadir = @datadir@/datadir =
@datadir@\ndatarootdir = @datarootdir@/g' {} \;

A more "correct" fix might be to produce the tarball on a host with newer
autoconf tools. When I check out the 4.1.3 branch and run autogen.sh on a clean
copy it produces correct *.in files to build on CentOS 6.3.

griznog

-- 
Configure bugmail: http://www.clusterresources.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at supercluster.org  Wed Oct 31 11:50:35 2012
From: bugzilla-daemon at supercluster.org (bugzilla-daemon at supercluster.org)
Date: Wed, 31 Oct 2012 11:50:35 -0600 (MDT)
Subject: [torquedev] [Bug 219] datarootdir entry missing from Makefile.in in
 4.1.3 tarball.
In-Reply-To: <bug-219-38@http.www.clusterresources.com/bugzilla/>
References: <bug-219-38@http.www.clusterresources.com/bugzilla/>
Message-ID: <20121031175035.1602D39E1BEC@http.supercluster.org>

http://www.clusterresources.com/bugzilla/show_bug.cgi?id=219

Michael Jennings <mej at lbl.gov> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mej at lbl.gov

--- Comment #1 from Michael Jennings <mej at lbl.gov> 2012-10-31 11:50:34 MDT ---
datarootdir is a little tricky to get right, so let me take a look at this. 
The Adaptive guys are pretty busy right now anyway.

Your suggested workaround is a little strange, though, since autogen.sh runs
automake which *should* be overwriting Makefile.in files.

But in any event, I'll take a look at holler back.

-- 
Configure bugmail: http://www.clusterresources.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at supercluster.org  Wed Oct 31 11:51:57 2012
From: bugzilla-daemon at supercluster.org (bugzilla-daemon at supercluster.org)
Date: Wed, 31 Oct 2012 11:51:57 -0600 (MDT)
Subject: [torquedev] [Bug 219] datarootdir entry missing from Makefile.in in
 4.1.3 tarball.
In-Reply-To: <bug-219-38@http.www.clusterresources.com/bugzilla/>
References: <bug-219-38@http.www.clusterresources.com/bugzilla/>
Message-ID: <20121031175157.7423B39E1C11@http.supercluster.org>

http://www.clusterresources.com/bugzilla/show_bug.cgi?id=219

--- Comment #2 from John Hanks <griznog at gmail.com> 2012-10-31 11:51:56 MDT ---
Sorry, I should add that make install fails when the install attempts to put
the torque-drmaa docs in /doc due to --prefix and datadir being ignored. 

jbh

(In reply to comment #0)
> Building torque-4.1.3 on CentOS 6.3 with --enable-drmaa results in these
> warnings during ./configure:
> 
> configure: creating ./config.status
> config.status: creating torque.spec
> config.status: creating buildutils/pbs_mkdirs
> config.status: creating buildutils/self-extract-head-sh
> config.status: creating buildutils/modulefiles
> config.status: WARNING:  'buildutils/modulefiles.in' seems to ignore the
> --datarootdir setting
> config.status: creating buildutils/modulefiles.vers
> config.status: creating Makefile
> config.status: WARNING:  'Makefile.in' seems to ignore the --datarootdir
> setting
> config.status: creating contrib/blcr/Makefile
> config.status: creating contrib/init.d/Makefile
> config.status: creating doc/Makefile
> config.status: creating doc/man1/Makefile
> config.status: creating doc/man3/Makefile
> config.status: creating doc/man7/Makefile
> config.status: creating doc/man8/Makefile
> config.status: creating src/Makefile
> config.status: creating src/cmds/Makefile
> config.status: WARNING:  'src/cmds/Makefile.in' seems to ignore the
> --datarootdir setting
> config.status: creating src/daemon_client/Makefile
> config.status: WARNING:  'src/daemon_client/Makefile.in' seems to ignore the
> --datarootdir setting
> config.status: creating src/gui/Makefile
> config.status: WARNING:  'src/gui/Makefile.in' seems to ignore the
> --datarootdir setting
> config.status: creating src/gui/Ccode/Makefile
> config.status: WARNING:  'src/gui/Ccode/Makefile.in' seems to ignore the
> --datarootdir setting
> config.status: creating src/include/Makefile
> ...
> 
> This appears to be the result of the tarball having it's Makefile.in and
> modulefile.in files produced with an autoconf earlier that 2.60, see
> http://www.gnu.org/software/autoconf/manual/autoconf.html#Changed-Directory-Variables.
> A workaround that worked for me is:
> 
> # Add datarootdir to all Makefile.in files:
> find . -name Makefile.in -exec sed -i 's/datadir = @datadir@/datadir =
> @datadir@\ndatarootdir = @datarootdir@/g' {} \;
> 
> A more "correct" fix might be to produce the tarball on a host with newer
> autoconf tools. When I check out the 4.1.3 branch and run autogen.sh on a clean
> copy it produces correct *.in files to build on CentOS 6.3.
> 
> griznog

-- 
Configure bugmail: http://www.clusterresources.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at supercluster.org  Wed Oct 31 15:55:11 2012
From: bugzilla-daemon at supercluster.org (bugzilla-daemon at supercluster.org)
Date: Wed, 31 Oct 2012 15:55:11 -0600 (MDT)
Subject: [torquedev] [Bug 219] datarootdir entry missing from Makefile.in in
 4.1.3 tarball.
In-Reply-To: <bug-219-38@http.www.clusterresources.com/bugzilla/>
References: <bug-219-38@http.www.clusterresources.com/bugzilla/>
Message-ID: <20121031215511.9495039E1C9B@http.supercluster.org>

http://www.clusterresources.com/bugzilla/show_bug.cgi?id=219

--- Comment #3 from Michael Jennings <mej at lbl.gov> 2012-10-31 15:55:11 MDT ---
I'm unable to reproduce this with the pristine tarball on SL6.3.  I get no
datarootdir warnings, and that variable doesn't occur anywhere in the source
tree.

Are you sure you didn't mistakenly run "autogen.sh" before building?

-- 
Configure bugmail: http://www.clusterresources.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.