Spec URL: http://svn.debroglie.net/specs/trunk/libnewmat.spec
SRPM URL: http://fedora.debroglie.net/fedora-test/SRPMS/10/libnewmat-10D-1.fc10.debroglie.src.rpm
Description:
This C++ library is intended for scientists and engineers who need to
manipulate a variety of types of matrices using standard matrix
operations. Emphasis is on the kind of operations needed in statistical
calculations such as least squares, linear equation solve and
eigenvalues.
rpmlint gives the following warnings:
- libnewmat-devel.x86_64: W: no-documentation (the documentation is in the libnewmat package)
- libnewmat.spec: W: mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 41) (the tabulation is within a echo string)
- libnewmat.x86_64: W: shared-lib-calls-exit /usr/lib64/libnewmat.so.10.4 exit@GLIBC_2.2.5
The package has been successfully built in mock.
It's my first package and I am seeking for a sponsor.
Cheers,
Pascal

As the FE-LEGAL dependency has been added, here is the corresponding discussion:
No license file is provided by upstream, and no mention of any license appears in the upstream site (http://www.robertnz.net) and files (readme.txt and source code), except the following statement in readme.txt: "This library is freeware."
I would suggest to contact upstream to add an explicit license file (and to choose an explicit license, such as GPLv2+ or LGPLv2+). But "Public Domain" may just be fine?

Upstream answer:
"The conditions of use are at the beginning of the main documentation file.
You can make that change, if you like. Put a note in the code that you
have made this change as I want to look a little more closely as to what
should be done in my version before I make any change."
Effectively, in nm11.htm:
1.1 Conditions of use
I place no restrictions on the use of newmat except that I take no liability for any problems that may arise from its use, distribution or other dealings with it.
You can use it in your commercial projects (as well as your non-commercial projects).
You can make and distribute modified or merged versions. You can include parts of it in your own software.
If you distribute modified or merged versions, please make it clear which parts are mine and which parts are modified.
[...]
Is it not enough ?

I am not a legal expert, but as stated here: http://fedoraproject.org/wiki/Licensing#SoftwareLicenses , "all software in Fedora MUST be under licenses in the Fedora licensing list. This list is based on the licenses approved by the Free Software Foundation , OSI and consultation with Red Hat Legal".
Debian packagers raised the same type of concerns about licensing of that package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335185 , but they became eventually fine with the re-worded version of the license.
It is a custom license, and the author does not appear to be ready to switch to a standard, OSI-approved, license. So, Fedora legal people may not accept that license. I prefer to let them have a look at it and decide.

(In reply to comment #6)
> 2. Use of the exit() function in the upstream code (myexcept.cpp). 'rpmlint
> -i' states:
> "newmat.x86_64: W: shared-lib-calls-exit /usr/lib64/libnewmat.so.11.1
> exit@GLIBC_2.2.5
> This library package calls exit() or _exit(), probably in a non-fork()
> context. Doing so from a library is strongly discouraged - when a library
> function calls exit(), it prevents the calling program from handling the
> error, reporting it to the user, closing files properly, and cleaning up any
> state that the program has. It is preferred for the library to return an
> actual error code and let the calling program decide how to handle the
> situation."
> I have thus written a patch
> (http://denisarnaud.fedorapeople.org/newmat/11/1/newmat-11-fix-exit-issue.patch)
> fixing that issue. That patch should be submitted/proposed upstream (as I have
> just coded a work-around, which upstream may not find appropriate).
For good or worse, this is quite common behaviour in scientific packages. The rpmlint warning can be safely omitted, one can ask upstream to fix it but any Fedora specific hacks are out of the question since they break compatibility.
**
- It seems you have added the functionality to build the shared library yourself. In this case no soname should be set (just produce an unversioned .so file). You should ask upstream to provide the option to build soname'd shared libraries.
Denis: please don't post spec files of your own as this makes the review rather confusing. I almost mistook your spec file for that of Pascal. If you want to suggest changes, do so with an attached patch.
Pascal: please fill your whole name in bugzilla.

> - It seems you have added the functionality to build the shared library
> yourself. In this case no soname should be set (just produce an unversioned .so
> file). You should ask upstream to provide the option to build soname'd shared
> libraries.
ok, I'll fix the spec file.
And add the license as well.
>
> Pascal: please fill your whole name in bugzilla.
Done

(In reply to comment #17)
> (In reply to comment #16)
> > version soname is removed
> Very bad idea. Could it be you haven't understood the purpose of SONAMEs?
AFAIK we don't add soname's, since that really should be done by upstream. Or is there some policy I am blissfully unaware of?

AFAIS, (In reply to comment #18)
> AFAIK we don't add soname's, since that really should be done by upstream.
It's correct that it's hardly possible to invent SONAMEs if upstream doesn't, but shipping a shared library without any SONAME doesn't work either.
Or differently: Letting both the base package and the *-devel package contain *.so, doesn't work.

(In reply to comment #19)
> AFAIS, (In reply to comment #18)
> > AFAIK we don't add soname's, since that really should be done by upstream.
> It's correct that it's hardly possible to invent SONAMEs if upstream doesn't,
> but shipping a shared library without any SONAME doesn't work either.
>
> Or differently: Letting both the base package and the *-devel package contain
> *.so, doesn't work.
The guidelines are quite clear on that one:
MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.
http://fedoraproject.org/wiki/Packaging/Guidelines#DevelPackages
Unversioned shared libraries are placed in the main package.

Well, deciding on where to place the library file is not an issue.
Publishing a SONAME-less library, which other components will link with, is the issue. It leads to either silent ABI breakage during library upgrades (worse-case) or explicit dependencies on package name+version, which increase the package maintenance requirements.
One ought not invent SONAMEs, which bear a risk of conflicting with upstream's future SONAMEs, but one can choose versioned SONAMEs, which would change whenever the library version changes. e.g. libfoo-1.0.so.0, libfoo-1.1.so.0 and so on (alternatively, one maps the API/ABI to a build id, which may change more slowly than the library version). That way library upgrades require rebuilds of dependencies or else there would be broken RPM dependencies. The remaining problem is that these SONAMEs also differ from upstream and any other source of builds made for upstream's library. Still, such a work-around is better than shipping a library without a versioned SONAME.

The answer:
"Sorry, I don't know a lot about Linux so you are going to have to
give me more details.
All the make files I provide are produced automatically with my genmake
program. It may be possible to modify this to produce the changes you
want, but only if you explain exactly what is required."
I don't know genmake, it doesn't seem to handle versioned soname ?
If anyone has any idea to deal with the situation, you are welcome :)

(In reply to comment #23)
> [upstream is clueless]
OK, upstream's answer doesn't actually surprize me ;-)
> If anyone has any idea to deal with the situation, you are welcome :)
I would introduce an SONAME of libnewmat.so.0.

I see this very old ticket has recently re-entered the review queue.
First, are you still interested in submitting this to Fedora?
Have you done any review work as detailed in the link Michael sent?
Could you address the fillowing rpmlint issues?
newmat-devel.x86_64: W: spurious-executable-perm /usr/include/newmat/newmatrm.h
newmat-devel.x86_64: W: spurious-executable-perm /usr/include/newmat/newmat.h
newmat-devel.x86_64: W: spurious-executable-perm /usr/include/newmat/newmatio.h
newmat-devel.x86_64: W: spurious-executable-perm /usr/include/newmat/tmt.h
newmat-devel.x86_64: W: spurious-executable-perm /usr/include/newmat/newmatrc.h
newmat-devel.x86_64: W: spurious-executable-perm /usr/include/newmat/precisio.h
newmat-devel.x86_64: W: spurious-executable-perm /usr/include/newmat/myexcept.h
newmat-devel.x86_64: W: spurious-executable-perm /usr/include/newmat/controlw.h
newmat-devel.x86_64: W: spurious-executable-perm /usr/include/newmat/solution.h
newmat-devel.x86_64: W: spurious-executable-perm /usr/include/newmat/newmatap.h
newmat-devel.x86_64: W: spurious-executable-perm /usr/include/newmat/newmatnl.h
newmat-devel.x86_64: W: spurious-executable-perm /usr/include/newmat/include.h
These should not be executable.
newmat.x86_64: W: shared-lib-calls-exit
/usr/lib64/libnewmat.so.0.0.0 exit@GLIBC_2.2.5
This is generally a bad thing that should be reported as a bug to upstream, but isn't something you have to fix on your own.
newmat-devel.x86_64: W: no-documentation
This is not a problem.
Otherwise this package seems fine, and if you are still interested and willing to do some other review work I think this could probably go in without too much difficulty.

This is still marked StalledSubmitter even though you did respond. However, you don't appear to provide a src.rpm anywhere, so it's not possible for anyone to review this. Please just provide a bare link to a package that can be downloaded and built.