Bug 479978 (libnewmat)

Summary: Review Request: newmat - C++ matrix library
Product: [Fedora] Fedora Reporter: Pascal Parois <pascal22p>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: denis.arnaud_fedora, fedora-package-review, notting, pascal22p, rc040203, susi.lehtola, tcallawa
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-01 11:11:34 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 201449    
Attachments:
Description Flags
Patch against newmat.spec none

Description Pascal Parois 2009-01-14 06:59:42 EST
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
Comment 1 Pascal Parois 2009-01-23 06:26:25 EST
Sorry guys, I broke my webserver, files are no longer available at the moment.
Comment 2 Pascal Parois 2009-01-23 12:35:25 EST
Fixed, file are available again.

This library is going to be used by the next package I am going to submit. I am waiting for a new release upstream to submit it (http://vincefn.net/Fox/).
Comment 3 Michael Schwendt 2009-01-27 09:04:13 EST
> -shared -Wl,-soname,libnewmat.so.10.4 

> ln -s libnewmat.so.10.4 libnewmat.so.10

Are you sure you didn't want the soname to be libnewmat.so.10?
Comment 4 Pascal Parois 2009-01-27 09:35:05 EST
You are right, it's a mistake.
Comment 5 Pascal Parois 2009-02-06 16:09:26 EST
I corrected the soname name

New srpm: http://fedora.debroglie.net/SRPMS/10/libnewmat-10D-2.fc10.debroglie.src.rpm
New spec: http://svn.debroglie.net/specs/trunk/libnewmat.spec
Comment 6 Denis Arnaud 2009-06-13 11:39:01 EDT
Note that I am not a sponsor. However, I have quickly reviewed your package (https://fedoraproject.org/wiki/Packaging/ReviewGuidelines) and fixed the warnings of rpmlint. The corresponding new specification file and source RPM are to be found here:
-------------------------------------------------------------------------
Spec URL: http://denisarnaud.fedorapeople.org/newmat/11/1/newmat.spec
SRPM URL: http://denisarnaud.fedorapeople.org/newmat/11/1/newmat-11-1.fc10.src.rpm
-------------------------------------------------------------------------

and it builds nicely on all architectures: http://koji.fedoraproject.org/koji/taskinfo?taskID=1409984

So, following are a few points, in no particular order, that I have fixed in my version of the specification file (and with the patch):
 0. I have renamed the package from 'libnewmat' into 'newmat', as it matches upstream naming (http://www.robertnz.net/ftp/newmat11.tar.gz). See https://fedoraproject.org/wiki/Packaging/NamingGuidelines#General_Naming for further details.

 1. License. Please have a look at https://fedoraproject.org/wiki/Packaging/LicensingGuidelines and http://fedoraproject.org/wiki/Licensing#SoftwareLicenses . For instance, "Public Use" does not exist. In my version of the spec file, I have used "Public Domain", which is acceptable for Fedora. However, it would be better to contact upstream (robert at statsresearch.co.nz), in order to clarify the license issue and potentially explicitly add a license file, if so intended.

 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).

 3. Dynamic library. Usually, the library is set to be executable when installed:
 install -p -D -m 0755 lib/lib%{name}.so %{buildroot}%{_libdir}/lib%{name}.so.%{version}
where %{version} is the full version (e.g., '11.1')

------------------

If you agree with the above, and you contact upstream for the corresponding issues (license, exit() function), and if upstream is fine with the license ("Public Domain"), I shall approve that package.
Comment 7 Denis Arnaud 2009-06-13 11:51:03 EDT
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?
Comment 8 Pascal Parois 2009-06-13 14:56:07 EDT
Thanks for the review. I'll contact upstream.
Comment 9 Pascal Parois 2009-06-26 14:27:07 EDT
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 ?
Comment 10 Denis Arnaud 2009-06-26 16:04:54 EDT
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.
Comment 11 Tom "spot" Callaway 2009-07-06 09:28:42 EDT
This is an extremely permissive license, and it is clearly Free and GPL Compatible. I've added it to the Licenses list, please use:

License: Newmat

Lifting FE-Legal.
Comment 12 Susi Lehtola 2009-07-08 13:03:32 EDT
(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.
Comment 13 Pascal Parois 2009-07-11 17:30:54 EDT
> - 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
Comment 14 Susi Lehtola 2009-08-05 05:06:08 EDT
ping, what's the status?
Comment 15 Pascal Parois 2009-08-05 06:29:46 EDT
I didn't do anything yet.

I am struggling submitting my phd thesis by the end of the month. I'll catch up when I'll be a doctor :)
Comment 16 Pascal Parois 2009-08-30 05:09:54 EDT
Finally, I made the corrections.

the license is fixed
version soname is removed
version bumped to 11

http://pascal.parois.net/fedoraproject/
http://svn.debroglie.net/specs/trunk/newmat.spec
Comment 17 Ralf Corsepius 2009-08-30 06:52:58 EDT
(In reply to comment #16)
> version soname is removed
Very bad idea. Could it be you haven't understood the purpose of SONAMEs?
Comment 18 Susi Lehtola 2009-08-30 14:08:05 EDT
(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?
Comment 19 Ralf Corsepius 2009-08-30 22:38:38 EDT
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.
Comment 20 Susi Lehtola 2009-08-31 03:48:23 EDT
(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.
Comment 21 Michael Schwendt 2009-08-31 04:22:42 EDT
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.
Comment 22 Pascal Parois 2009-08-31 05:00:17 EDT
I sent an email upstream about the soname. Before looking for a workaround which seems not to be trivial.
Comment 23 Pascal Parois 2009-09-01 14:40:25 EDT
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 :)
Comment 24 Ralf Corsepius 2009-09-02 11:23:43 EDT
(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.
Comment 25 Ralf Corsepius 2009-09-02 11:25:39 EDT
Created attachment 359548 [details]
Patch against newmat.spec

This patch is one approach to implement what I wrote in previous comment.

SONAME libnewmat.so.0, file name libnewmat.so.0.0.0
Comment 26 Ralf Corsepius 2009-09-14 10:36:36 EDT
Any progress on this package? I am going to close this review request, shouldn't we hear from the OP within 1 week.
Comment 28 Pascal Parois 2009-10-27 09:31:38 EDT
ping ?
Comment 29 Susi Lehtola 2010-05-08 04:40:45 EDT
At least spec file is unavailable.
Comment 32 Michael Schwendt 2011-03-01 13:03:30 EST
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Get_Sponsored

| Review and approval for the first package for new packagers must be done
| by registered sponsors. Subsequent reviews can be done by any package
| maintainer. Informal reviews can always be done by anyone interested.
Comment 33 Jason Tibbitts 2011-03-12 21:40:02 EST
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.
Comment 34 Pascal Parois 2011-04-10 04:22:18 EDT
I'll address these when I'll get some time and no I haven't review anything. There is not much chemistry in Fedora and I am not interesting in the rest.
Comment 35 Susi Lehtola 2011-12-16 04:57:11 EST
Ping Pascal?
Comment 37 Jason Tibbitts 2012-06-29 19:05:04 EDT
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.
Comment 38 Jason Tibbitts 2012-07-05 15:25:47 EDT
Another week; marking this as not ready for review.  As before, please clear the whiteboard if providing a package to review.