This is a bad idea to remove the %{?dist} IMHO.
To generate a generic src.rpm, you should use the following command:
rpmbuild -ts tarball --define 'dist %{nil}'
or
rpmbuild -bs openmpi.spec --define 'dist %{nil}'
This can be put in the main Maikefile:
srpm: tarball_bz2
rpmbuild -ts openmpi
$#%@#%
Somehow the MTT submission password file just got truncated. I have asked IU
to restore a copy from their backups, but I don't know who's around over the
weekend.
As a result, MTT submissions may get rejected until the password file is
restored.
Sorry folks...
--
Jeff Squyres
jsquy.
you are right about setting 'dist %{nil}' will workaround about the src.rpm
filename issue.
but we are using contrib/dist/linux/buildrpm.sh script and not calling
rpmbuild directly.
I don`t mind having %{?dist} in the spec file, as long as this change is
backwards compatible:
You can change buil
Mike --
Did you contact the VT folks before making this change?
On Jul 12, 2014, at 8:38 AM,
wrote:
> Author: miked (Mike Dubman)
> Date: 2014-07-12 08:38:15 EDT (Sat, 12 Jul 2014)
> New Revision: 32225
> URL: https://svn.open-mpi.org/trac/ompi/changeset/32225
>
> Log:
> BUILD: support new
Nope
Are they on list?
On Jul 12, 2014 6:36 PM, "Jeff Squyres (jsquyres)"
wrote:
> Mike --
>
> Did you contact the VT folks before making this change?
>
>
>
> On Jul 12, 2014, at 8:38 AM, <
> svn-commit-mai...@open-mpi.org> wrote:
>
> > Author: miked (Mike Dubman)
> > Date: 2014-07-12 08:38:15 E
Yes, but they're a 3rd party -- they rarely pay attention to OMPI stuff unless
we ping them specifically (CC'ed).
They keep their tree in tight sync with the VT copy in the OMPI SVN -- they
should be consulted with these kinds of changes.
Andreas / Matthias -- any problems with this change?
The backups were sketchy, but I found an old password file that I think should
have all the correct MTT submission passwords.
Please let me know if you have problems submitting MTT results.
Sorry for the hassle.
On Jul 12, 2014, at 7:54 AM, Jeff Squyres wrote:
> $#%@#%
>
> Somehow the MTT s
Hello,
Just fyi: have forwarded the logs below to the VT mailing list
at Vampir-Support
Ticket number: 2014071241000219
-- Sid
Univ. of Houston
On 12 July 2014 17:51, Jeff Squyres (jsquyres) wrote:
> Yes, but they're a 3rd party -- they rarely pay attention to OMPI stuff
> unless we ping the
Mike --
Was this actually necessary in the libevent directory too? What version of
"new" automake are you referring to -- 1.14? (I'm not sure I've tried
1.14.x... my cluster version is still at 1.13.x)
On Jul 12, 2014, at 8:38 AM, svn-commit-mai...@open-mpi.org wrote:
> Author: miked (
Yep
On Jul 12, 2014 7:23 PM, "Jeff Squyres (jsquyres)"
wrote:
> Mike --
>
> Was this actually necessary in the libevent directory too? What version
> of "new" automake are you referring to -- 1.14? (I'm not sure I've tried
> 1.14.x... my cluster version is still at 1.13.x)
>
>
>
> On Jul 12
make[8]: Entering directory
`/hpc/newhome/hpcuser/workspace/hpc-internal-tools.git/build/dist-ompi-mellanox-v1.8-1.8/master/ompi/contrib/vt/vt/extlib/otf/tools/otfinfo'
make[8]: Leaving directory
`/hpc/newhome/hpcuser/workspace/hpc-internal-tools.git/build/dist-ompi-mellanox-v1.8-1.8/master/ompi/c
Okay, let's clarify a couple of things:
1. this wasn't "necessary" in the sense that OMPI won't build without the
change. It was "desirable" in terms of eliminating some long-standing warnings
coming from those areas due to changes in automake in anticipation of a
compatibility break when autom
Just checked out the tarball and it builds fine for me - did you build this
from the tarball, or from the repo?
On Jul 12, 2014, at 9:29 AM, Mike Dubman wrote:
> make[8]: Entering directory
> `/hpc/newhome/hpcuser/workspace/hpc-internal-tools.git/build/dist-ompi-mellanox-v1.8-1.8/master/ompi/
>From repo
On Jul 12, 2014 7:59 PM, "Ralph Castain" wrote:
> Just checked out the tarball and it builds fine for me - did you build
> this from the tarball, or from the repo?
>
>
> On Jul 12, 2014, at 9:29 AM, Mike Dubman wrote:
>
> make[8]: Entering directory
> `/hpc/newhome/hpcuser/workspace/h
Congrats - your Makefile.am change broke it :-)
I reverted it so the repo can build again
On Jul 12, 2014, at 10:23 AM, Mike Dubman wrote:
> From repo
>
> On Jul 12, 2014 7:59 PM, "Ralph Castain" wrote:
> Just checked out the tarball and it builds fine for me - did you build this
> from the
ohh... sorry about that.
will be more careful next time.
On Sat, Jul 12, 2014 at 8:43 PM, Ralph Castain wrote:
> Congrats - your Makefile.am change broke it :-)
>
> I reverted it so the repo can build again
>
> On Jul 12, 2014, at 10:23 AM, Mike Dubman
> wrote:
>
> From repo
> On Jul 12, 2014
okay, seems found the reason:
slurm-devel-14.03.4-2.el6.x86_64 comes with this:
$grep hwloc /usr/lib64/*la
/usr/lib64/libpmi.la:dependency_libs=' /usr/lib64/libslurm.la -L/usr/lib64
-ldl -lhwloc -lpthread'
/usr/lib64/libslurmdb.la:dependency_libs=' -L/usr/lib64 -ldl -lhwloc
-lpthread'
/usr/li
Dear developers and subscribers,
I'm not aware of information how open-mpi static build is being
validated. Is there any documentation about it?
For now I tested the static build on Debian Jessie (testing) amd64
with openmpi-1.6.5 and openmpi-1.8.1.
There are few issues with it.
- openmpi doesn
Hmmm... --enable-static works just fine (at least, for the 1.8.2rc) on CentOS,
so this may be a Debian thing. We have some protection in there for getpwuid on
the Cray, where static builds take similar exception to it, but that requires
you configure with --disable-getpwuid. I was unaware of p
The only one of those we link against is libpmi. Why they chose to link libpmi
against libslurm and libhwloc is beyond belief - not only are those libs
irrelevant to pmi, but they also contain fully GPL code.
Afraid you'll have to take it up with them. This isn't something we can solve.
NOTE: f
20 matches
Mail list logo
