Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: libibcommon - OpenFabrics Alliance InfiniBand management common library https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246387 dledford@xxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: libibcommon |Review Request: libibcommon | |- OpenFabrics Alliance | |InfiniBand management common | |library ------- Additional Comments From dledford@xxxxxxxxxx 2007-07-03 00:31 EST ------- That can be added, but needs to be added by upstream. The spec file is autogenerated from the actual code repo, so any changes to the spec file that aren't done in the upstream repo would be lost. In the actual tarball is the file libibcommon.spec.in that is used to generate the actual spec file. Yes, www.openfabrics.org is the right URL. The lack of mention of this particular package is because they really don't talk a lot about the individual packages on their web site, they tend to only talk about their largish (40MB+ src.rpm) Open Fabrics Enterprise Distribution, which includes this package and about 15 others in one single src.rpm. To see how that rpm builds out, look at http://people.redhat.com/dledford/Infiniband/openib/1.2/1.el5/ and see for yourself just how much crap they pack into one rpm. I didn't think that was suitable for Fedora, so I'm breaking it back out into individual rpms based upon their git repos with properly crafted spec files (in terms of BuildRequires: and such, little details they get to skip entirely by putting it all into one rpm) and then pushing the changes upstream. The maintainer of the repo that this package comes from has accepted my changes in, but that doesn't mean he's gotten around to making any official releases of this package separate from the larger conglomerate package yet. Hence why the URL doesn't say much about this package, but only talks about their mondo package instead. As for the git snapshot, I created a make.dist script for the person that maintains this repo, and that script will spit out either a libibcommon-git.tgz file or a libibcommon-%{version}.tgz file and tags the version in the repo and does some other checking. It's not my place to spit out that versioned, tagged, official tarball, and since he doesn't have any up on the web site outside of the mondo rpm, I created this with a git snapshot. Once we've worked through the review process and have things on track, I'm going to be helping the upstream maintainer through the process of becoming a Fedora contributor and then through the process of taking over the maintenance of this package. He can readily create the official tarball and official release package instead of a git snapshot where as I can't. As for the static library, that's a common request of the people that make use of this code. The customers I here from most are people running anywhere from 256 to 8000 node clusters with Infiniband hardware and they have been requesting we make static libs available. Thanks for the suggestions on the reviewing, I'll make sure and do those things in the future. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review