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.5 The package has been successfully built in mock. It's my first package and I am seeking for a sponsor. Cheers, Pascal
Sorry guys, I broke my webserver, files are no longer available at the moment.
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/).
> -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?
You are right, it's a mistake.
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
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.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.
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?
Thanks for the review. I'll contact upstream.
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.
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.
(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.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
ping, what's the status?
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 :)
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
(In reply to comment #16) > version soname is removed Very bad idea. Could it be you haven't understood the purpose of SONAMEs?
(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.
I sent an email upstream about the soname. Before looking for a workaround which seems not to be trivial.
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.
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
Any progress on this package? I am going to close this review request, shouldn't we hear from the OP within 1 week.
Yes, I applied the patch. http://fedora.debroglie.net/SRPMS/11/newmat-11-2.fc11.debroglie.src.rpm http://svn.debroglie.net/specs/trunk/newmat.spec
ping ?
At least spec file is unavailable.
Here is the last rpm/srpm http://fedora.debroglie.net/RPMS/12/i386/newmat-11-2.fc12.i686.rpm http://fedora.debroglie.net/SRPMS/12/newmat-11-2.fc12.src.rpm And the spec file: http://svn.debroglie.net/debroglie/specs/trunk/newmat.spec
http://fedora.debroglie.net/RPMS/14/i386/newmat-11-2.fc14.i686.rpm http://fedora.debroglie.net/SRPMS/14/newmat-11-2.fc14.src.rpm
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.
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.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.
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.
Ping Pascal?
Permissions on *.h have been fixed: http://depot.debroglie.net/fedora/RPMS/15/repoview/newmat.html https://svn.parois.net/debroglie/specs/trunk/newmat.spec
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.
Another week; marking this as not ready for review. As before, please clear the whiteboard if providing a package to review.