Hide Forgot
Spec Name or Url: ftp://czar.eas.yorku.ca/pub/mpich2/mpich2-1.0.2p1-1.src.rpm SRPM Name or Url: ftp://czar.eas.yorku.ca/pub/mpich2/mpich2.spec Description: MPICH2 is an all-new implementation of MPI from the group at Argonne National Laboratory. It shares many goals with the original MPICH but no actual code. It is a portable, high-performance implementation of the entire MPI-2 standard. This release has all MPI-2 functions and features required by the standard with the exeption of support for the "external32" portable I/O format. It also currently supports only a few communication methods
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@lahorebiz.com
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@mcs.anl.gov E. Lusk: (630) 252-7852; FAX: (630) 252-5986; e-mail: lusk@mcs.anl.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@mcs.anl.gov > E. Lusk: (630) 252-7852; FAX: (630) 252-5986; e-mail: lusk@mcs.anl.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