Hi Deji, I'm afraid this package needs a bit more work and here are the 
specific comments:

needswork:
 - I'm afraid I don't understand the with_jvm %define -- what 
     does it accomplish?
 - rpmlint reports:
   - a lot of ignorable "devel-file-in-non-devel-package" 
       warnings
   - more ignorable "non-executable-script" and 
       "non-conffile-in-etc" warnings/errors related to conf
       files that are in bash syntax and have a shebang
   - are the following files really needed [what purpose
       do they serve?] and perhaps can be deleted:
        W: mpich2 unstripped-binary-or-object 
            /usr/lib/debug/usr/bin/clog2_print.debug
        E: mpich2 statically-linked-binary 
            /usr/lib/debug/usr/bin/clog2_print.debug
        W: mpich2 unstripped-binary-or-object  
            /usr/lib/debug/usr/bin/mpdroot.debug
        E: mpich2 statically-linked-binary  
            /usr/lib/debug/usr/bin/mpdroot.debug
        W: mpich2 unstripped-binary-or-object  
            /usr/lib/debug/usr/share/mpich2/examples/cpi.debug
        E: mpich2 statically-linked-binary  
            /usr/lib/debug/usr/share/mpich2/examples/cpi.debug
   - what is this error?  Can we simply delete this file? :
        E: mpich2 arch-dependent-file-in-usr-share 
            /usr/share/mpich2/examples/cpi
 - The files in, for instance, /usr/include/* "pollute" the 
     standard name-space and should probably be placed in 
     something like /usr/include/mpich2/* or 
     /usr/lib/mpich2/include/* since they already conflict 
     with the "lam" package in Core.  Please note that this 
     is a fairly critical bug since Extras packages should not 
     (AFAIK) conflict with any Core packages.

good:
 + source matches upstream
 + license looks OK and correctly included
 + specfile is clean and readable
 
So I think, at a min, a number of the rpmlint errors should be corrected 
and a file layout should be chosen that allows mpich2 to be installed 
concurrently (no conflicts) with the lam package already in Core.

(In reply to comment #1)
> Hi Deji, I'm afraid this package needs a bit more work and here are the 
> specific comments:

Thanks for reviewing it.
> 
> needswork:
>  - I'm afraid I don't understand the with_jvm %define -- what 
>      does it accomplish?

Some portion of the package (slog2 and clog tools and utilities) needs the Sun
java sdk to build them. I should have actually remove that definition before
submitting the spec file, I'll clean it up for the iteration of the spec file.

>  - rpmlint reports:
>    - a lot of ignorable "devel-file-in-non-devel-package"

i guess this can be ignored, the whole package is a development package imho.
 
>        warnings
>    - more ignorable "non-executable-script" and 
>        "non-conffile-in-etc" warnings/errors related to conf
>        files that are in bash syntax and have a shebang

I don't know exactly what to say about this, I however believe it should be
ignored; mpich executables needs these conf files at the installed location.

>    - are the following files really needed [what purpose
>        do they serve?] and perhaps can be deleted:
>         W: mpich2 unstripped-binary-or-object 
>             /usr/lib/debug/usr/bin/clog2_print.debug
>         E: mpich2 statically-linked-binary 
>             /usr/lib/debug/usr/bin/clog2_print.debug
>         W: mpich2 unstripped-binary-or-object  
>             /usr/lib/debug/usr/bin/mpdroot.debug
>         E: mpich2 statically-linked-binary  
>             /usr/lib/debug/usr/bin/mpdroot.debug
>         W: mpich2 unstripped-binary-or-object  
>             /usr/lib/debug/usr/share/mpich2/examples/cpi.debug
>         E: mpich2 statically-linked-binary  
>             /usr/lib/debug/usr/share/mpich2/examples/cpi.debug

I didn't noticed these while building because I had turned off packaging
debuginfo in my rpmmacros. Incidentally mpich2 has a debuginfo option too (which
is disabled by default) that builds these .debugs. I'll be explicitly disabling
the debuginfo option in the spec file.
 
>    - what is this error?  Can we simply delete this file? :
>         E: mpich2 arch-dependent-file-in-usr-share 
>             /usr/share/mpich2/examples/cpi

I think this can be ignored too as the. i personally used to make use of this
file to test my mpich installations.

>  - The files in, for instance, /usr/include/* "pollute" the 
>      standard name-space and should probably be placed in 
>      something like /usr/include/mpich2/* or 
>      /usr/lib/mpich2/include/* since they already conflict 
>      with the "lam" package in Core.  Please note that this 
>      is a fairly critical bug since Extras packages should not 
>      (AFAIK) conflict with any Core packages.
> 
You're right, I've not thought of lam. Taken care in the next spec file.

Thanks.

I've put up updated package here;
Spec Name or Url: ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.2p1-2.src.rpm
SRPM Name or Url: ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

Disabling the debuginfo option in the configure flag doesn't seem to work, so I
resorted to removing /usr/lib/debug* from the buildroot.

debuginfo should not be removed in this way. Your problems are caused by

| %{_libdir}/*

you should either add an

| %exclude %_libdir/debug

or enumerate the files in %_libdir (should be doable with wildcards).


When mpich2 ships libraries which can be used by applications, the package
should be splitted into a main and a -devel subpackage. Or, at least you should
'Provide: %name-devel = %version-%release'

(In reply to comment #4)

> you should either add an
> 
> | %exclude %_libdir/debug

Thanks, I've done this and also not package the binary examples.

> 
> When mpich2 ships libraries which can be used by applications, the package
> should be splitted into a main and a -devel subpackage. Or, at least you should
> 'Provide: %name-devel = %version-%release'

I've taken a look at lam (in fedora core), and it doesn't provide a -devel
subpackage too. The two (mpich and lam) are alternative implementation of MPI
protocol and are very similar both in use and in packaging. 
I really don't know how the split into a -devel subpackage should be done (if at
all necessary), i mean which files should remain in the package and what goes
into the -devel subpackage.

Spec Name or Url: ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.2p1-3.src.rpm
SRPM Name or Url: ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

Hi Deji, I agree that it makes little sense to split either lam or mpich2 
into separate -devel packages.  But it also doesn't hurt to add a Provides: 
mpich2-devel as suggested in comment #4 above.  I'll review your new srpm 
as soon as I get a chance.

Hi Deji, your 1.0.2p1-3 srpm is certainly an improvement but there is still a 
bit more work to do.  The main thing that needs to be fixed are the conflicts 
with lam.  Putting the include files in /usr/include/mpich2 helped but there
are still many conflicting files such as /usr/bin/mpicc, /usr/bin/mpif77,
/usr/share/man/man1/mpicc.1.gz, etc.

As I see it, you have at least two options.  Option #1 would be to put:

  includes in --> /usr/include/mpich2
  binaries in --> /usr/bin/mpich2 or similar
  libs in     --> /usr/libs/mpich2 or similar
  man files in--> ???

and Option #2 would be to put things in /usr/lib/mpich2:

  includes in --> /usr/lib/mpich2/include
  binaries in --> /usr/lib/mpich2/bin or similar
  libs in     --> /usr/lib/mpich2/lib or similar
  man files in--> /usr/lib/mpich2/man or similar

which is similar to having /usr/lib/mpich2 as your "prefix".

I prefer layout #2.  However, since you're the packager, you get to choose 
which is best.  But please keep in mind that its important not to conflict 
with lam since its in Core.  And it would be very nice to create a layout 
that allows for the simultaneous installation of multiple (not just lam 
and mpich2) MPI implementations since there are others (some of which are 
variants of the above) available and actively used.

(In reply to comment #7)
> Hi Deji, your 1.0.2p1-3 srpm is certainly an improvement but there is still a 
> bit more work to do.  The main thing that needs to be fixed are the conflicts 
> with lam.  

Thanks Ed for the review. My understanding previously was that extras package
cannot replace core ones, i.e. there can't be conflict in file names.
While i may be very wrong, i thought in the particular case of mpich and lam
(or/and any other MPI implementation), one cannot have simultaneously install
and use more than one implementation. If more than one is installed in parallel
in a rpm based system, amd their paths properly set in the system environment,
if I run 'mpirun' how would the system know which implementation to use.
I'm not so versed on how to deal with situation like this, any advice and
directions will be appreciated.    

> My understanding previously was that extras package cannot replace 
> core ones

Yes, I think thats correct but I can't locate any references in the 
Wiki that spell it out.  Maybe I just need to look harder?  ;-)

> in the particular case of mpich and lam (or/and any other MPI 
> implementation), one cannot have simultaneously install and use 
> more than one implementation

Actually, you can!  One of our clusters at work has no less than five 
MPI versions installed, each of which has been built with multiple 
different compiler suites (GCC, Intel, PGI, etc.).  To visualize the 
layout, imagine a directory structure such as:

  /opt/mpich/{gcc,intel,pgi}
  /opt/mpich2/{gcc,intel,pgi}
  /opt/mpich-vmi/{gcc,intel,pgi}
  /opt/lam/{gcc,intel,pgi}

where each of the above directories contains a complete install with 
bin, include, lib, and man subdirs that contain, respectively, all the 
necessary binaries, headers, libs, and man pages.

With the above directory layout, all users can manipulate their PATH, 
MANPATH, and other environment variables to select the desired combination 
of MPI and compiler, etc.  And all the environment variable manipulation 
can be done in a rather user-friendly way with the "modules" system:

  http://modules.sourceforge.net/

which would also be a nice thing to add to Fedora Extras.  So, please 
consider installing essentially all of the mpich2 binaries, headers, libs, 
man pages, etc. in

  /usr/lib/mpich2

since, that way, it will not conflict with lam and one can readily add 
additional MPI implementations such as mpich v1 (/usr/lib/mpich) by 
following the same pattern.

Hi Ed,

This is getting more complicated than i set out to do ;). I'm quite aware of
such multiple installations in /opt, we actually have a setup similar to what
you described. But i was confused on how it could be done in a Fedora-extras rpm
packaging stlye.
Your suggestion of putting it in /usr/lib/mpich2 is very interesting, it reminds
me of what is being done with java sdk/jre stuff and alternatives in fedora and
jpackage. I'm trying to study the use of update-alternatives to see if it will
be useful in this situation.
Also using the layout above (/usr/lib/mpich2), I'm stuck with the man pages. The
packaging guildlines stipulates arch-independent data to be put in /usr/share;
what do you think i should do here, put the man pages in /usr/share/mpich2 ?

Hi Deji, I'd put the man pages in /usr/lib/mpich2 along with headers, libs,
binaries, etc.  But thats just my opinion.  I'll send an email to the fedora
extras list requesting input from others who may have better ideas...

For some wierd reason I need to install MPICH on Fedora Core 4 instead of 
MPICH2, but I could not get to compile it completely using gfortran default 
Fedora FORTRAN compiler. Infact mpipcc and mpif77 works perfectly, but mpif90 
does not seem to work. Could anyone guide me how to compile mpi correctly in 
Fedora.

Thanks in advance and best regards.

Yours Sincerely,
Sabih D. Khan
Email: sabih

I've got a heavily updated version here:

http://www.cora.nwra.com/~orion/fedora/mpich2-1.0.3-1.fc5.src.rpm

How do we want to proceed?  Deji - do you still want to be the maintainer?

(In reply to comment #13)
> I've got a heavily updated version here:
> 
> http://www.cora.nwra.com/~orion/fedora/mpich2-1.0.3-1.fc5.src.rpm
>
I can't each the above file
 
> How do we want to proceed?  Deji - do you still want to be the maintainer?
Actually, i have another heavily updated version somewhere too. But it can't go
in until openmpi/lam gets re-worked a bit (to allow for their co-existence).
Hopefully i submit patches for openmpi and lam by weekend and try to get this
moving forward.
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.3-3.src.rpm

(In reply to comment #14)
> (In reply to comment #13)
> > I've got a heavily updated version here:
> > 
> > http://www.cora.nwra.com/~orion/fedora/mpich2-1.0.3-1.fc5.src.rpm
> >
> I can't each the above file
>  
Whoops, fixed.

> Actually, i have another heavily updated version somewhere too. But it can't go
> in until openmpi/lam gets re-worked a bit (to allow for their co-existence).
> Hopefully i submit patches for openmpi and lam by weekend and try to get this
> moving forward.
> ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.3-3.src.rpm

I'll take a look.  What do you think needs changing in lam and openmpi?

Interesting how close are spec files are, really.  You seem to be further along
so I'll drop mine for the most part.

Trying to build yours I get:
+ mv /var/tmp/mpich2-1.0.3-3-root-mockbuild/usr/logfiles
/var/tmp/mpich2-1.0.3-3-root-mockbuild/usr/share/mpich2
mv: cannot stat `/var/tmp/mpich2-1.0.3-3-root-mockbuild/usr/logfiles': No such
file or directory

when compiling in mock on FC5/x86_64.  

Looks like you don't have BRs for the needed java stuff.  Looks like java-devel
and libgcj-devel

Also:

< checking for etags... etags
< checking for etags argument to specify language... --language=c
---
> checking for etags... no

so maybe a BR for emacs-common?  Not sure what effect this has yet.

Also:

< checking for library containing uuid_generate... -luuid
---
> checking for library containing uuid_generate... no

BR e2fsprogs-devel

Thanks for the review Orion. I've added the BRs and re-word the changelogs. The
package is now properly put up for (more) review here;
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.3-3.src.rpm
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec.

However it can really pass Extras' review now until some changes are made to the
alternatives configuration in both openmpi and lam, to avoid conflicts. I hope
to soon submit a patch to openmpi to effect such change.

Checking for unpackaged file(s): /usr/lib/rpm/check-files
/var/tmp/mpich2-1.0.3-3-root-root
error: Installed (but unpackaged) file(s) found:
   /usr/lib/libTraceInput.la
   /usr/lib/libTraceInput.so

That was when I did an rpmbuild --rebuild mpich2-1.0.3-3.src.rpm

#18

The .la file shouldn't be there (needs to be deleted in the %install stage) and
IIRC, the .so should be in a -devel package

I was wondering more if they were actually supposed to be in /usr/lib/mpich2
with the rest of the libs?

Unless there is a *damned good reason*, there should be no .la and no .a files
packaged.

Normally, the .so is a devel file with .so.0.0.x being the runtime lib (or
something like that).

In answer to #21, the .so file would be installed to %{_libdir}/mpich2, but only
if you install the -devel file.

(In reply to comment #18)
> Checking for unpackaged file(s): /usr/lib/rpm/check-files
> /var/tmp/mpich2-1.0.3-3-root-root
> error: Installed (but unpackaged) file(s) found:
>    /usr/lib/libTraceInput.la
>    /usr/lib/libTraceInput.so

This means I've been missing a BuildRequires, can you please capture and attach
(or send me) your configure log.
Thanks.

Um, possibly. What it's more likely meaning is that a the .la and .so files are
not present in the %files section

I think I know where libTraceInput is coming from now; they are truly not
present in the %files section as they don't get built. The trace_sample in
mpich2 is left out because the default Java setup in Fedora can't handle it
(I've forgotten exact details now), Mark Chappell probably has Sun's java
installed on his system.

Yes I do have Suns Java installed, however I'm a little surprised that that's
caused extra files to turn up in the MPICH /usr/lib rather than /usr/lib/mpich2 

mpich2-1.0.3 build setup is broken in a couple of place which might explain
that, had to patch it myself to build properly on Fedora. However ver. 1.0.4
seems to be much better, I'm uploading it now you can give it a try.
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.4-1.src.rpm
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

I seem to have gained an unpacked log file too this time...

Checking for unpackaged file(s): /usr/lib/rpm/check-files
/var/tmp/mpich2-1.0.4-1-root-root
error: Installed (but unpackaged) file(s) found:
   /usr/lib/libTraceInput.la
   /usr/lib/libTraceInput.so
   /usr/share/logfiles/barrier.rlog

Note that the MPICH2 site now says:

The current version of MPICH2 is 1.0.4p1, released on August 11, 2006. 1.0.4p1
is a patch release that fixes some problems in the 1.0.4 release, such as the
Nemesis configure problem and a few other minor bugs. If you already have a
working 1.0.4, you need not switch to 1.0.4p1. The Windows version is still at
1.0.3.

Doesn't the java part build with current GCJ?

(In reply to comment #30)
> Doesn't the java part build with current GCJ?
Yes.

For other folks watching this package, I've uploaded src rpm for mpich-1.0.4p1
and tidy up the spec so that its now installable side by side with openmpi in FC.

Mark (Chappell), those unpackaged files are now taken care of. GCJ actually
build them fine with appropriate configure option (see the spec for details)

ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.4p1-2.src.rpm
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

Builds fine in mock devel/x86_64.

Any progress on this package?  It's been nearly six months since the last comment.

It's currently waiting on some fixes going into openmpi package to avoid file
conflicts. I had a private discussion about the conflict and this review with
the openmpi maintainer about a month ago, and he assured me he's working on a
better solution than what I proposed then. 

Cool; thanks for the update.

With the recent changes that to openmpi in rawhide, I believe this package is
now OK to enter Fedora. Latest version for reviews below;

ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.5p4-1.fc8.src.rpm
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

First glance (then I'm off on vacation for a week):

Requires(post): /usr/sbin/alternatives
Requires(preun):/usr/sbin/alternatives

not

Requires(post): /usr/sbin/alternative
Requires(preun):/usr/sbin/alternative

Don't need BR on libX11-devel, libXt-devel pulls it in (at least on EL-5).

While not incompatible with openmpi-1.2.3 in rawhide (I was able to install
both), we've got some different naming conventions that I'll have to sort out.

Also, the following should allow you to change the name of the package when
using different compilers:

--- mpich2.spec 2007-07-12 16:15:52.000000000 -0600
+++ /data/sw1/test/mpich2.spec  2007-07-12 16:33:28.000000000 -0600
@@ -116,7 +116,7 @@
 cp -pr CHANGES COPYRIGHT README README.testing README.romio
%{buildroot}%{_docdir}/%{name}-%{version}/

 # Silence rpmlint
-sed -i '/^#! \//,1 d'
%{buildroot}%{_sysconfdir}/mpich2-%{mode}/{mpi*.conf,mpe_help.*}
+sed -i '/^#! \//,1 d'
%{buildroot}%{_sysconfdir}/%{name}-%{mode}/{mpi*.conf,mpe_help.*}

 # The uninstall script that is installed in this directory is not needed in rpm
packaging
 rm -rf %{buildroot}%{_sbindir}/mpe*
@@ -171,7 +171,7 @@
 %exclude %{_bindir}/mp%{mode}-mpicxx
 %exclude %{_bindir}/mp%{mode}-mpif90
 %exclude %{_bindir}/mp%{mode}-mpif77
-%{_docdir}/mpich2-%{version}/
+%{_docdir}/%{name}-%{version}/
 %{_mandir}/man1/*
 %dir %{_datadir}/%{name}
 %{_datadir}/%{name}/log*
@@ -181,7 +181,7 @@
 %dir %{_libdir}/%{name}
 %{_libdir}/%{name}/*.jar
 %{_libdir}/%{name}/*.o
-%config %{_sysconfdir}/mpich2-%{mode}/
+%config %{_sysconfdir}/%{name}-%{mode}/

 %files devel
 %defattr(-,root,root,-)

(Let's see if we can get this done in under 2 years!)

srpm and spec files with fixes from the last comment;

ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.5p4-2.fc8.src.rpm
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

Fixes to use a more generic name for the java BR, and to handle upgrades
properly in the post scripts.
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.5p4-3.fc8.src.rpm
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

There is still a clash between LAM and MPICH in that the manual files are the
same between packages.

Thanks!

(In reply to comment #40)
> There is still a clash between LAM and MPICH in that the manual files are the
> same between packages.
> 
> Thanks!
I've had an idea of splitting out a mpi-manpages subpackage from the main
package to contain these manuals (they are MPI routines manuals and are the same
for mpich2, lam and openmpi). For the split to be effective, both lam and
openmpi will need to create similar subpackage and have it conflict each other.
I have a package with this split at
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.5p4-4.fc8.src.rpm

A new release is out, I've packaged it up and it's available below. I'll really
appreaciate it if one the folks watching this will step up to formally review
this package, so it can go into Fedora repo asap. It seems Ed Hill is rather too
busy to attend to this now.
Thanks.
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.6-1.fc8.src.rpm
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

The links in comment #42 appear dead.

(In reply to comment #43)
> The links in comment #42 appear dead.
No, its not dead; please try again.

Thanks, downloading now!

It must have been my uni's firewall, which blocks FTP requests *silently* when
you haven't logged into VPN properly... I forgot, and it looked like the server
was down from my end.

I got a SELinux denial when building (at the very end), but it seems to have
finished OK (exit 0).

Info from "setroubleshoot browser":

Summary
SELinux is preventing /sbin/ldconfig (ldconfig_t) "search" to src (src_t).

Detailed Description
SELinux denied access requested by /sbin/ldconfig. It is not expected that this
access is required by /sbin/ldconfig and this access may signal an intrusion
attempt. It is also possible that the specific version or configuration of the
application is causing it to require additional access.

Allowing Access
Sometimes labeling problems can cause SELinux denials. You could try to restore
the default system file context for src, restorecon -v src If this does not
work, there is currently no automatic way to allow this access. Instead, you can
generate a local policy module to allow this access - see FAQ Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report against this package.

Additional Information
Source Context:  user_u:system_r:ldconfig_t
Target Context:  system_u:object_r:src_t
Target Objects:  src [ dir ]
Affected RPM Packages:  glibc-2.6-4 [application]
Policy RPM:  selinux-policy-2.6.4-43.fc7
Selinux Enabled:  True
Policy Type:  targeted
MLS Enabled:  True
Enforcing Mode:  Enforcing
Plugin Name:  plugins.catchall_file
Host Name:  sinus
Platform:  Linux sinus 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 23:10:59 EDT 2007 i686 i686
Alert Count:  1
First Seen:  tir 02-10-2007 10:02:20 CEST
Last Seen:  tir 02-10-2007 10:02:20 CESTLocal
ID:  f9b885b4-1f4c-426d-bdef-50d6c2bec85e
Line Numbers:  

Raw Audit Messages :
avc: denied { search } for comm="ldconfig" dev=sda6 egid=0 euid=0
exe="/sbin/ldconfig" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="src" pid=20162
scontext=user_u:system_r:ldconfig_t:s0 sgid=0 subj=user_u:system_r:ldconfig_t:s0
suid=0 tclass=dir tcontext=system_u:object_r:src_t:s0 tty=pts0 uid=0

This is the oldest open review ticket around and it looks like it's been all of
26 months since the last comment from the assigned reviewer, not to mention well
over three months since the last comment.

I'm clearing out all of the flags and setting things so that it appears back on
the list of open review tickets.  I really hope that the original submitter
still has the will to work on this package, and that least one of the other
commenters will be willing to give this a proper review.  However, if this goes
another month without comment from anyone then I'll go ahead and close it out.

(In reply to comment #47)

> the list of open review tickets.  I really hope that the original submitter
> still has the will to work on this package,
Yes I do have the will to work on the package, it's a software I'm using
actively for my personal work. I believe I've resolved the major issue of some
of it installed files clashing with openmpi's, the package should be good to go
in now. Update package is at;

ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.6p1-1.fc8.src.rpm
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

> and that least one of the other
> commenters will be willing to give this a proper review.  However, if this goes
> another month without comment from anyone then I'll go ahead and close it out.

I wish I could help but there seem to be several issues and I'd really prefer
that someone who actually understands them complete this review.  Orion?  Mark?
 Paul?  You folks have any time to go over this?

One thing that I do see is that "Freely redistributable without restriction"
isn't   an acceptable license tag; if the license isn't one of the ones listed
on http://fedoraproject.org/wiki/Licensing, then have this ticket block FE-Legal
and someone will have a look.

The license:
The following is a notice of limited availability of the code, and disclaimer
which must be included in the prologue of the code and in all source listings
of the code.

Copyright Notice
 + 2002 University of Chicago

Permission is hereby granted to use, reproduce, prepare derivative works, and
to redistribute to others.  This software was authored by:
Argonne National Laboratory Group
W. Gropp: (630) 252-4318; FAX: (630) 252-5986; e-mail: gropp.gov
E. Lusk:  (630) 252-7852; FAX: (630) 252-5986; e-mail: lusk.gov
Mathematics and Computer Science Division
Argonne National Laboratory, Argonne IL 60439

There's also a license statement for the US government.

(In reply to comment #49)

> 
> One thing that I do see is that "Freely redistributable without restriction"
> isn't   an acceptable license tag; if the license isn't one of the ones listed

It's actually acceptable, please check the 'Distributable' section of
http://fedoraproject.org/wiki/Packaging/LicensingGuidelines


> on http://fedoraproject.org/wiki/Licensing, then have this ticket block FE-Legal
> and someone will have a look.
> 
> The license:
> The following is a notice of limited availability of the code, and disclaimer
> which must be included in the prologue of the code and in all source listings
> of the code.
> 
> Copyright Notice
>  + 2002 University of Chicago
> 
> Permission is hereby granted to use, reproduce, prepare derivative works, and
> to redistribute to others.  This software was authored by:
> Argonne National Laboratory Group
> W. Gropp: (630) 252-4318; FAX: (630) 252-5986; e-mail: gropp.gov
> E. Lusk:  (630) 252-7852; FAX: (630) 252-5986; e-mail: lusk.gov
> Mathematics and Computer Science Division
> Argonne National Laboratory, Argonne IL 60439
> 
> There's also a license statement for the US government.
> 

You may note that the license text I included above does indeed constitute a
license, so the text that you've referred me to, quoted below, does not seem to
apply.

"
If your package contains content which is freely redistributable without
restrictions, but does not contain any license other than explicit permission
from the content owner/creator, then that package can use "Freely
redistributable without restriction" as its License: identifier.
"

What you quoted is not a license text, but a copyright notice. If I'm not
mistaken the two are very different; and to me the package seems to rightly suit
the 'Distributable' clause in
http://fedoraproject.org/wiki/Packaging/LicensingGuidelines .I'm going to make
it block FE-Legal though. 

No, you can't use "Distributable" in the License tag.

"Fedora no longer permits packages to use "Distributable" as a valid License."

I'm looking into this issue in more depth now.

This license is functionally equivalent to MIT. The Licensing page has been
updated to list the mpich2 license as "MIT". Please use:

License: MIT

Lifting FE-Legal.

Thank you Tom for resolving the license issue.

Updated package with the clarified license and latest upstream release is
available below, please review. 

ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.7-1.fc9.src.rpm
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

Somehow the fedora-review was set to '-' so that it did not show up on the open
review ticket.  Do any of the CC'd folks want to finish this up?

Source needs to be: 
      
http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/%{name}-%{version}.tar.gz

Also, is not building in current rawhide mock:

gcc -fPIC -DHAVE_CONFIG_H -I.
-I/builddir/build/BUILD/mpich2-1.0.7/src/mpid/ch3/channels/dllchan/../ssm/src
-I../../../../../include -I/builddir/build/BUILD/mpich2-1.0.7/src/include 
-I/builddir/build/BUILD/mpich2-1.0.7/src/mpid/ch3/util/sock
-I/builddir/build/BUILD/mpich2-1.0.7/src/mpid/ch3/include
-I/builddir/build/BUILD/mpich2-1.0.7/src/mpid/ch3/util/sock
-I/builddir/build/BUILD/mpich2-1.0.7/src/mpid/ch3/util/sock
-I/builddir/build/BUILD/mpich2-1.0.7/src/mpid/common/datatype
-I/builddir/build/BUILD/mpich2-1.0.7/src/mpid/common/sock
-I/builddir/build/BUILD/mpich2-1.0.7/src/mpid/common/sock/poll
-I../../../../common/sock -I../../../../common/sock/poll -I../include
-I../../../include
-I/builddir/build/BUILD/mpich2-1.0.7/src/mpid/ch3/channels/ssm/include
-I../../../../common/locks
-I/builddir/build/BUILD/mpich2-1.0.7/src/mpid/common/locks -c ch3_finalize.c -o
_sch3_finalize.o
In file included from
/builddir/build/BUILD/mpich2-1.0.7/src/mpid/ch3/include/mpidpre.h:31,
                 from ../../../../../include/mpiimpl.h:99,
                 from
/builddir/build/BUILD/mpich2-1.0.7/src/mpid/ch3/include/mpidimpl.h:22,
                 from ../include/mpidi_ch3_impl.h:12,
                 from ch3_finalize.c:7:
../include/mpidi_ch3_pre.h:39:2: error: #error No shared memory subsystem defined
In file included from ch3_finalize.c:7:
../include/mpidi_ch3_impl.h:233:2: error: #error *** No shared memory mapping
variables specified ***
make[7]:
*** [ch3_finalize.lo] Error 1

(In reply to comment #57)
> Source needs to be: 
>       
>
http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/%{name}-%{version}.tar.gz
> 
Noted, thanks.

> Also, is not building in current rawhide mock:
>
Please make sure you're updated to the latest mock in rawhide
(mock-0.9.8-1.fc9), earlier version may contain a bug causing this build
failure. It builds succesfully for me on x86_64 rawhide with mock-0.9.8.

It doesn't build in koji:

http://koji.fedoraproject.org/koji/taskinfo?taskID=566788

(In reply to comment #59)
> It doesn't build in koji:
> 
Known issue caused by a regression in mock (bug #442484), which I believe will
be resolved soon. I will be pleased if you can continue with the review the
package using local mock build for now (your resources permitting of course).

I've uploaded a new src.rpm and spec file with the url fix;
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.7-1.fc9.src.rpm
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

Sorry the link should be;

ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.7-2.fc9.src.rpm
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

Need to change:

< %{_datadir}/%{name}/*log*
---
> %{_datadir}/%{name}/*.*log*

to avoid having example_logging going into the base mpich2 package.

mpich2-devel.i386: W: symlink-should-be-relative
/usr/share/mpich2/bin32/mpif90/usr/bin/mp32-mpif90
(and same for mpif77, mpicc, mpicxx).

Lots of:

mpich2-libs.i386: W: conffile-without-noreplace-flag
/etc/mpich2-32/mpe_callstack_ldflags.conf


I also think a note should be made in the description of the package that this
was compiled with the default options and so uses the mpd process manager and
the ch3:sock communication device.


Another thing to think about it who should take precedence among lam, openmpi,
and mpich2 when they are all installed.

(In reply to comment #62)
> Need to change:
> 
> < %{_datadir}/%{name}/*log*
> ---
> > %{_datadir}/%{name}/*.*log*
> 
> to avoid having example_logging going into the base mpich2 package.
>
Fixed, thanks.
 
> mpich2-devel.i386: W: symlink-should-be-relative
> /usr/share/mpich2/bin32/mpif90/usr/bin/mp32-mpif90
> (and same for mpif77, mpicc, mpicxx).
> 
I've fought with this in the past, I can't find a means of dealing with it
sanely, suggestions welcomed. I believe it can be ignored.

> Lots of:
> 
> mpich2-libs.i386: W: conffile-without-noreplace-flag
> /etc/mpich2-32/mpe_callstack_ldflags.conf
> 
I think these can be safely ignored too, as most of them are constructed at
build-time.

> 
> I also think a note should be made in the description of the package that this
> was compiled with the default options and so uses the mpd process manager and
> the ch3:sock communication device.
>
Good point. It seems you've not noticed I did enabled dynamically loading sock,
ssm, and shm channels; the default is still the sock channel though.
I'm actually considering configuring the package to use ch3:nemesis on x86*,
since it said to offer the best performance, thoughts?

> 
> Another thing to think about it who should take precedence among lam, openmpi,
> and mpich2 when they are all installed.
It really shouldn't matter, anyone who will knowingly install the three, should
be knowledgeable enough to set the default implementation, IMHO.

ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.7-3.fc9.src.rpm
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

(In reply to comment #63)
> (In reply to comment #62)
>  
> > mpich2-devel.i386: W: symlink-should-be-relative
> > /usr/share/mpich2/bin32/mpif90/usr/bin/mp32-mpif90
> > (and same for mpif77, mpicc, mpicxx).
> > 
> I've fought with this in the past, I can't find a means of dealing with it
> sanely, suggestions welcomed. I believe it can be ignored.
>
> > Lots of:
> > 
> > mpich2-libs.i386: W: conffile-without-noreplace-flag
> > /etc/mpich2-32/mpe_callstack_ldflags.conf
> > 
> I think these can be safely ignored too, as most of them are constructed at
> build-time.

See the patch I'll be attaching to fix these, and do proper line wrapping of the
description.
 
> Good point. It seems you've not noticed I did enabled dynamically loading sock,
> ssm, and shm channels; the default is still the sock channel though.
> I'm actually considering configuring the package to use ch3:nemesis on x86*,
> since it said to offer the best performance, thoughts?

Hadn't notice, but that's nice.  Can you build nemesis as another option but not
as the default?  Otherwise, I'd skip it for now.
 
> > Another thing to think about it who should take precedence among lam, openmpi,
> > and mpich2 when they are all installed.
>
> It really shouldn't matter, anyone who will knowingly install the three, should
> be knowledgeable enough to set the default implementation, IMHO.

Willing to agree, but I'm going to CC the lam/openmpi maintainer to get his take.

Created attachment 302656 [details]
Patch to spec file to fix rpmlint warnings

I should note that I've made significant changes to lam/openmpi that aren't
reflected in Fedora yet.  The most important of which is dumping the
alternatives usage entirely.  It has proven to be unwieldy at best, a nightmare
at worst.  Instead, my current packages use mpi-selector.  You can find
mpi-selector, openmpi, and lam packages for the upcoming rhel5.2 release that
demonstrate what I'm talking about (and intending to bring into fedora after f9
is released) at my Infiniband package page:

http://people.redhat.com/dledford/Infiniband/rhel5.2

Also of note is that, in line with the comments in comment #7 and comment #8, my
current packages use %{_libdir}/%{name} as the prefix for all files in the lam
package, and %{_libdir}/%{name}/%{version}-%{opt_cc} as the prefix for all files
in openmpi (the difference being because I've never been given any requests to
have more than one version or compiler of lam installed at a time, but I have
been given requests to have multiple versions and multipler compilers of openmpi
at the same time).

Another item of note is that I have outstanding requests to also include
mvapich/mvapich2 in the distro for use over infiniband.  I've not gotten any
requests for mpich, but then I'm not fully aware of the relationship between
mpich and mvapich.  However, that does raise the question in my mind of
redundancy (I'm not talking about redundant MPI implementations...we're already
at the stage of ludicrous there, I'm wondering is mvapich a later version of
mpich, are they the same code base, or is the naming similarity coincidence). 
If these packages are redundant, then would it not be better to use mvapich
(which I think supports more of the high speed interconnects natively, but I
could be wrong)?  If they aren't, then ignore that issue.

(In reply to comment #66)
> I should note that I've made significant changes to lam/openmpi that aren't
> reflected in Fedora yet.  The most important of which is dumping the
> alternatives usage entirely.  It has proven to be unwieldy at best, a nightmare
> at worst.  Instead, my current packages use mpi-selector.

Ah, great, yet another tool for manipulating environment variables.  And one
with a domain specific name.  I'm all for dropping alternatives, it's definitely
crap for situations like this.  But have you thought about using Modules
(environment-modules in Fedora)?  It's a general purpose environment
manipulation tool.

> Also of note is that, in line with the comments in comment #7 and comment #8, my
> current packages use %{_libdir}/%{name} as the prefix for all files in the lam
> package, and %{_libdir}/%{name}/%{version}-%{opt_cc} as the prefix for all files
> in openmpi (the difference being because I've never been given any requests to
> have more than one version or compiler of lam installed at a time, but I have
> been given requests to have multiple versions and multipler compilers of openmpi
> at the same time).

That's good.  However for such a scheme makes it into Fedora, I think it's going
to need to go through the packaging committee.  You run into all kinds of FHS
violations as enforced by rpmlint like:

openmpi.i386: E: file-in-usr-marked-as-conffile
/usr/lib/openmpi/1.2.5-gcc/etc/openmpi-default-hostfile
openmpi-libs.i386: E: postin-without-ldconfig
/usr/lib/openmpi/1.2.5-gcc/lib/libmpi_cxx.so.0.0.0
openmpi-libs.i386: E: library-without-ldconfig-postun
/usr/lib/openmpi/1.2.5-gcc/lib/libmpi_cxx.so.0.0.0

> Another item of note is that I have outstanding requests to also include
> mvapich/mvapich2 in the distro for use over infiniband.  
 
> If these packages are redundant, then would it not be better to use mvapich
> (which I think supports more of the high speed interconnects natively, but I
> could be wrong)?  

Well the FAQ says:

What is MVAPICH/MVAPICH2?

MVAPICH is a high performance implementation of MPI-1 over InfiniBand based on
MPICH1. MVAPICH2 is a high performance MPI-2 implementation based on MPICH2.
High performance and scalable support over the Verbs Level Interface (VAPI) are
provided by these packages. These packages also support other underlying
transport interfaces (such as the emerging uDAPL, OpenIB/Gen2 and the standard
TCP/IP) for portability across multiple networks. 

And the download pages says:

MVAPICH2 1.0.2p1 is available as a single integrated package (with MPICH2
1.0.5p4) for download. 

Now, whether and an installed MVAPICH2 provides a pure superset of MPICH2
capabilities remains to be seen.

Both the lam and openmpi packages on my site support environment-modules in
addition to the mpi-selector functionality.

And yes, the file layout violates FHS.  However, this layout seems to violate it
the least while not creating a hodgepodge of binary names and symlinks in
/usr/bin and other nasties like that.  If it weren't forbidden for a
distribution to ship software that installs in /opt, I would say that we should
can the whole idea of putting this stuff in /usr and just use
/opt/%{name}/%{version}/%{opt_cc} for these things.  They are built by upstream
with many assumptions that lend them to that layout well, and make a FHS layout
a nightmare.  It's a case of what's the least evil way to solve the problem.

(In reply to comment #64)

> >
> > > Lots of:
> > > 
> > > mpich2-libs.i386: W: conffile-without-noreplace-flag
> > > /etc/mpich2-32/mpe_callstack_ldflags.conf
> > > 
> > I think these can be safely ignored too, as most of them are constructed at
> > build-time.
> 
> See the patch I'll be attaching to fix these, and do proper line wrapping of the
> description.
> 
Thanks for the patch. However, I want the *.conf to be without noreplace; those
configurations are supposed to change on version upgrades. 
I've already tried to wrapped the description around at column 80, I'll take
your patch for it anyways.
 
> > Good point. It seems you've not noticed I did enabled dynamically loading sock,
> > ssm, and shm channels; the default is still the sock channel though.
> > I'm actually considering configuring the package to use ch3:nemesis on x86*,
> > since it said to offer the best performance, thoughts?
> 
> Hadn't notice, but that's nice.  Can you build nemesis as another option but not
> as the default?  Otherwise, I'd skip it for now.
>
No, the dynamic loading scheme doesn't support the nemesis channel for now.

ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.7-4.fc9.src.rpm
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

  

(In reply to comment #66)
> I should note that I've made significant changes to lam/openmpi that aren't
> reflected in Fedora yet.  The most important of which is dumping the
> alternatives usage entirely.  It has proven to be unwieldy at best, a nightmare
> at worst.  Instead, my current packages use mpi-selector.  You can find
> mpi-selector, openmpi, and lam packages for the upcoming rhel5.2 release that
> demonstrate what I'm talking about (and intending to bring into fedora after f9
> is released) at my Infiniband package page:
> 
> http://people.redhat.com/dledford/Infiniband/rhel5.2
> 
I'll work on implementing it for mpich2 once its available in fedora.

> Also of note is that, in line with the comments in comment #7 and comment #8, my
> current packages use %{_libdir}/%{name} as the prefix for all files in the lam
> package, and %{_libdir}/%{name}/%{version}-%{opt_cc} as the prefix for all files

Do you actually ship openmpi with multiple versions and compilers on RHEL? I saw
your use of the %{opt_cc} sometimes ago and copied it for mpich2, but I don't
think its necessary for Fedora builds, as one can build with gcc and we can only
carry a version at a time. I believe the second option in comment #7 (which is
what I'm using now) works fine for the multilib situation, which is farthest
multiple instance Fedora can allow now.  

> in openmpi (the difference being because I've never been given any requests to
> have more than one version or compiler of lam installed at a time, but I have
> been given requests to have multiple versions and multipler compilers of openmpi
> at the same time).
> 
> Another item of note is that I have outstanding requests to also include
> mvapich/mvapich2 in the distro for use over infiniband.  I've not gotten any
> requests for mpich, but then I'm not fully aware of the relationship between
> mpich and mvapich.

mvapich is one of several other projects that are built on top of mpich2. There
is no reason why it can be packaged/shipped independently of mpich2.

(In reply to comment #70)
> > Also of note is that, in line with the comments in comment #7 and comment #8, my
> > current packages use %{_libdir}/%{name} as the prefix for all files in the lam
> > package, and %{_libdir}/%{name}/%{version}-%{opt_cc} as the prefix for all files
> 
> Do you actually ship openmpi with multiple versions and compilers on RHEL?

With multiple compilers, no, and I never will.  It's there as a convenience item
for those people that want to build their own version with a different compiler.
 Although, in order to have both the mainline and another compiler version
installed at the same time they should really add the %{opt_cc} marker into
Name: as well (I didn't do that for gcc since I consider that the default).

> I saw
> your use of the %{opt_cc} sometimes ago and copied it for mpich2, but I don't
> think its necessary for Fedora builds, as one can build with gcc and we can only
> carry a version at a time.

We can only carry a version at a time in the repo, but that doesn't mean that a
user can't configure yum/rpm to treat openmpi as an installonly item (like the
kernel).  Since I've had people tell me they need the ability to install
specific versions for certain certified apps, but also want the most up to date
version for their own apps, that's the rationale behind keeping the version tag
in the directory path for the prefix.

> I believe the second option in comment #7 (which is
> what I'm using now) works fine for the multilib situation, which is farthest
> multiple instance Fedora can allow now.  
> 
> > in openmpi (the difference being because I've never been given any requests to
> > have more than one version or compiler of lam installed at a time, but I have
> > been given requests to have multiple versions and multipler compilers of openmpi
> > at the same time).
> > 
> > Another item of note is that I have outstanding requests to also include
> > mvapich/mvapich2 in the distro for use over infiniband.  I've not gotten any
> > requests for mpich, but then I'm not fully aware of the relationship between
> > mpich and mvapich.
> 
> mvapich is one of several other projects that are built on top of mpich2. There
> is no reason why it can be packaged/shipped independently of mpich2.

Well, that wasn't really my point. My question was, assuming you have
mvapich/mvapich2 available in fedora, then do we need mpich/mpich2?  Is there
any compelling reason for it?  (Not that I object if you want to do the work,
just asking)

(In reply to comment #71)

> 
> Well, that wasn't really my point. My question was, assuming you have
> mvapich/mvapich2 available in fedora, then do we need mpich/mpich2?  Is there
> any compelling reason for it?

I've just browse through its source and notice mvapich2 really seems to be a
superset of mpich2, but I'm not so sure how much it support the commodity tcp/ip
stack. I guess if we have mvapich2, mpich2 wouldn't be so necessary then; only
that mvapich2 release will always be lagging behind mpich2's. The current
mvapich2-1.0.2p1 ships with mpich2-1.0.5p4, while the latest upstream is at
mpich2-1.0.7 .

>  (Not that I object if you want to do the work,
> just asking)

Hi Orion and all,

Package now builds in koji 
(http://koji.fedoraproject.org/koji/taskinfo?taskID=605687).
Anything else left to pass review?

Hello,Thanks for your efforts to contribute the src.rpm.  
I just have a question. If I am correct I think we can change the compile
options to compile the source code,e.g. the different fortran compiler we can
use. When building from src.rpm,can I also set the different compiler to get the
final rpm?

(In reply to comment #74)
> Hello,Thanks for your efforts to contribute the src.rpm.  
> I just have a question. If I am correct I think we can change the compile
> options to compile the source code,e.g. the different fortran compiler we can
> use. When building from src.rpm,can I also set the different compiler to get the
> final rpm?
A macro to allow building with a different compiler/compiler flag have been in
the spec file for a while. I've now modify it to allow overriding from the
command-line. Say you want to rebuild the src.rpm with a pgf90 fortran compiler
and fflag '-O3', you'll need to run rpmbuild like 'rpmbuild --rebuild --define
"opt_fc pgf90" --define "opt_fc_fflags -O3" mpich2-1.0.7-5.fc9.src.rpm'

ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.7-5.fc9.src.rpm
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec
 

Thank you ,Deji Akingunola,That indeed what I want to know.

Hello,just a feedback.Fedora 9,it compiles ok,and I test a simple problem,it
also seems to work. but when I run mp32-mpif77 or mp32-mpicc directly,it cause
errors.

 mp32-mpicc 
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: ld 返回 1

$ mp32-mpif77 
/opt/intel/fc/10.1.015/lib/for_main.o: In function `main':
/users/nbtester/x86linux_nightly/branch-10_1/20080313_000000/libdev/frtl/src/libfor/for_main.c:(.text+0x39):
undefined reference to `MAIN__'


--------------------------
the output of mpich2version 
MPICH2 Version:    	1.0.7
MPICH2 Release date:	Unknown, built on Sun May 25 07:45:10 CEST 2008
MPICH2 Device:    	ch3:dllchan
MPICH2 configure: 	--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com
--mandir=/usr/share/man --infodir=/usr/share/info --enable-f90
--enable-sharedlibs=gcc --sysconfdir=/etc/mpich2-32
--includedir=/usr/include/mpich2 --libdir=/usr/lib/mpich2
--datadir=/usr/share/mpich2 --with-htmldir=/usr/share/doc/mpich2-1.0.7/www
--with-docdir=/usr/share/doc/mpich2-1.0.7 --with-java=/etc/alternatives/java_sdk
--with-device=ch3:dllchan:sock,shm,ssm F90=ifort F77=ifort CFLAGS=-O2 -g -pipe
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables CXXFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386
-mtune=generic -fasynchronous-unwind-tables F90FLAGS=-O3 FFLAGS=-O3
LDFLAGS=-Wl,-z,noexecstack
MPICH2 CC: 	gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables  -O2
MPICH2 CXX: 	c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables  -O2
MPICH2 F77: 	ifort -O3 
MPICH2 F90: 	ifort -O3 

(In reply to comment #77)
> Hello,just a feedback.Fedora 9,it compiles ok,and I test a simple problem,it
> also seems to work. but when I run mp32-mpif77 or mp32-mpicc directly,it cause
> errors.
>
>  mp32-mpicc 
> /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../crt1.o: In function `_start':
> (.text+0x18): undefined reference to `main'
> collect2: ld 返回 1
>
NOTABUG. You need to run them (mp32-mpif77 or mp32-mpicc) on an appropriate
source code; running mp32-mpicc is like just running ;
"gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -mtune=generic -Wl,-z,noexecstack
-Wl,-z,noexecstack -ldl -lrt".
   

# rpm -ivh mpich2-1.0.6p1-1.fc8.src.rpm
   1:mpich2                 warning: user deji does not exist - using root
warning: group deji does not exist - using root
########################################### [100%]
warning: user deji does not exist - using root
warning: group deji does not exist - using root
warning: user deji does not exist - using root
warning: group deji does not exist - using root
warning: user deji does not exist - using root
warning: group deji does not exist - using root
[root@local3 wzhy]# rpm -q mpich2
package mpich2 is not installed

^^^^^^^^^^^^^^^^
I failed? I run it on Fedora7.Could you offer a rpm for fc7?

Thank you very much!

Please search to find how to install packages using src.rpm,which is different
from rpm.

Thank you! I have learn more about file.rpm and file.src.rpm.
I follow the steps:
                                 #rpm -ivh mpich2-1.0.7-5.fc9.src.rpm
                                # ls  /usr/src/redhat/SOURCES/mpich2*
                              /usr/src/redhat/SOURCES/mpich2-1.0.7.tar.gz
                           /usr/src/redhat/SOURCES/mpich2.module.in
                        /usr/src/redhat/SOURCES/mpich2-rpmbuild.patch
                       #rpmbuild --ba mpich2.spec
Errors occured!

      mpidtime.c: In function 'MPID_Wtime_diff':
      mpidtime.c:113: error: 'MPID_Time_t' has no member named 'tv_usec'
      mpidtime.c:113: error: 'MPID_Time_t' has no member named 'tv_usec'
      mpidtime.c: In function 'MPID_Wtime_todouble':
      mpidtime.c:117: error: 'MPID_Time_t' has no member named 'tv_usec'
      mpidtime.c: In function 'MPID_Wtime_acc':
      mpidtime.c:123: error: 'MPID_Time_t' has no member named 'tv_usec'
      mpidtime.c:123: error: 'MPID_Time_t' has no member named 'tv_usec'
      mpidtime.c:125: error: 'MPID_Time_t' has no member named 'tv_usec'
      mpidtime.c:128: error: 'MPID_Time_t' has no member named 'tv_usec'
      mpidtime.c:129: error: 'MPID_Time_t' has no member named 'tv_usec'
      make[3]: *** [mpidtime.o] Error 1
      make[3]: Leaving directory `/usr/src/redhat/BUILD/mpich2-1.0.7/src/mpi/timer'
      make[2]: *** [all-redirect] Error 2
      make[2]: Leaving directory `/usr/src/redhat/BUILD/mpich2-1.0.7/src/mpi'
      make[1]: *** [all-redirect] Error 2
      make[1]: Leaving directory `/usr/src/redhat/BUILD/mpich2-1.0.7/src'
      make: *** [all-redirect] Error 2
      error: Bad exit status from /var/tmp/rpm-tmp.84707 (%build)

No file.rpm  was created in  /usr/src/redhat/SOURCES/

Any suggestion is appreciated!

PS.my system information :
Linux local3 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:35:01 EDT 2007 i686 i686 i386 
GNU/Linux

Thank you and best regards!

Is anyone actually reviewing this ticket?  When Ed stopped reviewing it I had cleared the flag but for some reason people kept setting it to other random values.  Six months ago Orion indicated that the package is under review again but didn't assign the ticket to himself so honestly I can't figure out what's going on.

It isn't assigned to anyone, so I'm clearing the flag to NEW.

On another note, the spec should be modified to use mpi-selector in RHEL and environment-modules in Fedora so that users can easily select which environment to use. Alternatives is system-wide, and should not be used.

Deji, are you still interested on working on the package?

(In reply to comment #84)
> It isn't assigned to anyone, so I'm clearing the flag to NEW.
> 
> On another note, the spec should be modified to use mpi-selector in RHEL and
> environment-modules in Fedora so that users can easily select which environment
> to use. Alternatives is system-wide, and should not be used.
>
For one, mpi-selector in not in Fedora. And I've included support for using environment-modules in the package since a long time ago. I prefer using alternatives on my workstation, so I don't think support for that should be removed.

> Deji, are you still interested on working on the package?
srpm and rpm spec files for the latest release are available below;
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.8-1.fc10.src.rpm
ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

(In reply to comment #85)
> (In reply to comment #84)
> > On another note, the spec should be modified to use mpi-selector in RHEL and
> > environment-modules in Fedora so that users can easily select which environment
> > to use. Alternatives is system-wide, and should not be used.
> >
> For one, mpi-selector in not in Fedora. And I've included support for using
> environment-modules in the package since a long time ago. I prefer using
> alternatives on my workstation, so I don't think support for that should be
> removed.

Well, I was referring to mpi-selector in EPEL. You're not interested in EPEL?
Also, you're not requiring the environment-modules package in Fedora.

> > Deji, are you still interested on working on the package?
> srpm and rpm spec files for the latest release are available below;
> ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.8-1.fc10.src.rpm
> ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

OK.

Could you add some comments on the BRs? To me BR emacs-common and gdb are a bit odd..

According to GCC man page, -fPIC only makes a difference on the m68k, PowerPC and SPARC (compared to -fpic?). Thus, should you have -fPIC also on ppc architectures?

Why don't you have --enable-f77 in the configure phase?

Since the package has Java functionality, you must follow the Java Packaging guidelines:

MUST have: 
BuildRequires: java-devel [>= specific_version] 
BuildRequires:  jpackage-utils
Requires:  java >= specific_version
Requires:  jpackage-utils

Also, in the setup phase, clean out old .jar files:
find -name '*.jar' -o -name '*.class' -exec rm -f '{}' \;

Otherwise the spec file seems quite clean to me. This is really an embarrassment, having had the package on review for 3 years.

Deji,

> For one, mpi-selector in not in Fedora. And I've included support for using
> environment-modules in the package since a long time ago. I prefer using
> alternatives on my workstation, so I don't think support for that should be
> removed.
> 
> > Deji, are you still interested on working on the package?
> srpm and rpm spec files for the latest release are available below;
> ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.8-1.fc10.src.rpm
> ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

I'm curious if there is any plan to include mpi-selector support at all.  I'm recompiling your rpms on a few RHEL5 boxes.  Up until recently, it was the only mpi compiler on them, but I just got a request to install openmpi alongside it.  I'd like to use RH's openmpi rpms and have them coexist correctly next to your mpich2 rpms.

I"m trying to use Doug Ledford's openmpi spec file to hack in mpi-selector support, but I wanted to check if you'd planned on putting any work in on this.

TIA.

(In reply to comment #87)
> Deji,
> 

> 
> I'm curious if there is any plan to include mpi-selector support at all.  I'm
> recompiling your rpms on a few RHEL5 boxes.  Up until recently, it was the only
> mpi compiler on them, but I just got a request to install openmpi alongside it.
>  I'd like to use RH's openmpi rpms and have them coexist correctly next to your
> mpich2 rpms.
> 
> I"m trying to use Doug Ledford's openmpi spec file to hack in mpi-selector
> support, but I wanted to check if you'd planned on putting any work in on this.
>
I have no immediate plans on adapting the mpich2 spec to mpi-selector. I'll likely work on supporting it once it is included Fedora.

mpi-selector looks like a quick hack added into RHEL instead of environment-modules, hence it'll probably never make it into Fedora, as environment-modules already surpasses it in terms of functionality.

Correct.  I have every intention of sticking with environment-modules for Fedora and never bringing in mpi-selector.

The links to the rpm and spec files below seem to be unreachable.

> ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.8-1.fc10.src.rpm
> ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec

Does anyone have a mirror available or is there an "official" version somewhere?

(In reply to comment #91)
> The links to the rpm and spec files below seem to be unreachable.
> 
> > ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.8-1.fc10.src.rpm
> > ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec
> 
> Does anyone have a mirror available or is there an "official" version
> somewhere?
You can now get them at;

http://deji.fedorapeople.org/mpich2-1.0.8-1.fc10.src.rpm
http://deji.fedorapeople.org/mpich2.spec

Note: It is not an official Fedora package yet.

Can someone please review this package, pretty please ;).

@Orion, You were once trying to do the review, anything holding it back.

mock built the srpm without errors:

$ mock -r fedora-10-i386 --rebuild mpich2-1.0.8-1.fc10.src.rpm

...
Wrote: /builddir/build/RPMS/mpich2-1.0.8-1.fc10.i386.rpm
Wrote: /builddir/build/RPMS/mpich2-devel-1.0.8-1.fc10.i386.rpm
Wrote: /builddir/build/RPMS/mpich2-libs-1.0.8-1.fc10.i386.rpm
Wrote: /builddir/build/RPMS/mpich2-debuginfo-1.0.8-1.fc10.i386.rpm
...

mock rebuilt into f11 without errors:

http://fedorapeople.org/~cchance/packaging/mpich2-1.0.8-1.fc11.src.rpm

== REVIEW ==

- rpmlint checks return:
mpich2-libs.x86_64: W: no-documentation
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpe_callstack_ldflags.conf
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpe_f77env.conf
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpe_graphics.conf
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpe_help.conf
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpe_log.conf
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpe_log_postlib.conf
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpe_mpianim.conf
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpe_mpicheck.conf
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpe_mpilog.conf
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpe_mpitrace.conf
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpe_nolog.conf
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpicc.conf
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpicxx.conf
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpif77.conf
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpif90.conf
mpich2-libs.x86_64: W: conffile-without-noreplace-flag /etc/mpich2-64/mpixxx_opts.conf

Please make those files be %config(noreplace), so if the user makes local changes, they aren't overwritten on an update.

- package meets naming guidelines
- package meets packaging guidelines
- license (MIT) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream (41d6f6ce1034ecec5c14fb03592730ae2dd071e5)

However, your Source0: URL is wrong, it should be :

http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/%{version}/%{name}-%{version}.tar.gz

- package compiles on devel (x86_64)
- no missing BR
- no unnecessary BR
- no locales
- not relocatable
- owns all directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- no need for -docs
- nothing in %doc affects runtime
- no need for .desktop file

Show me a spec with the two items I noted resolved and I will approve this package.

(In reply to comment #95)
> == REVIEW ==
> 
...
> mpich2-libs.x86_64: W: conffile-without-noreplace-flag
> /etc/mpich2-64/mpicxx.conf
> mpich2-libs.x86_64: W: conffile-without-noreplace-flag
> /etc/mpich2-64/mpif77.conf
> mpich2-libs.x86_64: W: conffile-without-noreplace-flag
> /etc/mpich2-64/mpif90.conf
> mpich2-libs.x86_64: W: conffile-without-noreplace-flag
> /etc/mpich2-64/mpixxx_opts.conf
> 
> Please make those files be %config(noreplace), so if the user makes local
> changes, they aren't overwritten on an update.
> 
I actually want to make it so that they are overwritten on an update. These .conf files created at build-time based compilation options and other scenarios which may change during update/upgrade. We want people to go over their changes to the conf files after updates.
 

> 
> However, your Source0: URL is wrong, it should be :
> 
> http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/%{version}/%{name}-%{version}.tar.gz
> 
Fixed.


> 
> Show me a spec with the two items I noted resolved and I will approve this
> package. 
> 
http://deji.fedorapeople.org/mpich2.spec

Thanks.

Okay, it looks good, just remember that whenever you make a spec file change, even during a review, you should bump Release and add a changelog entry.

APPROVED.

New Package CVS Request
=======================
Package Name: mpich2
Short Description: A high performance implementation of Message Passing Interface (MPI)
Owners: deji
Branches: F-9 F-10
InitialCC:
Cvsextras Commits: yes

cvs done.

Thanks to everyone who have helped with the package review. Closing.

Deji -

  Are you planning on supporting EPEL?  If not, I'd be willing to manage the EL builds.

(In reply to comment #101)
> Deji -
> 
>   Are you planning on supporting EPEL?  If not, I'd be willing to manage the EL
> builds.  

Yes I am. You're invited to co-maintain the package with me though.

Package Change Request
=======================
Package Name: mpich2
Short Description: A high performance implementation of Message Passing
Interface (MPI)
Owners: deji
Branches: EL-4 EL-5
InitialCC:
Cvsextras Commits: yes

cvs done.