Description: LINPACK is a collection of FORTRAN subroutines that analyze and solve linear equations and linear least-squares probles. The package solves linear systems whose matrices are general, banded, symmetric indefinite, symmetric positive definite, triangular, and tridiagonal square. In addition, the package computes the QR and singular value decompositions of rectangular matrices and applies them to least-squares problems. LINPACK uses column-oriented algorithms to increase efficiency by preserving locality of reference. LINPACK was designed for supercomputers in use in the 1970s and early 1980s. LINPACK has been largely superseded by LAPACK which has been designed to run efficiently on shared-memory, vector supercomputers. Koji Builds: el5: https://koji.fedoraproject.org/koji/taskinfo?taskID=5851811 el6: https://koji.fedoraproject.org/koji/taskinfo?taskID=5851815 F18: https://koji.fedoraproject.org/koji/taskinfo?taskID=5851819 F19: https://koji.fedoraproject.org/koji/taskinfo?taskID=5851822 F20: https://koji.fedoraproject.org/koji/taskinfo?taskID=5851825 Frh: https://koji.fedoraproject.org/koji/taskinfo?taskID=5851829 Issues: fedora-review shows no issues, rpmlint reports some false positives. Fedora Account System Username: besser82 Urls: Spec URL: http://besser82.fedorapeople.org/review/linpack.spec SRPM URL: http://besser82.fedorapeople.org/review/linpack-19880411-1.fc19.src.rpm ##### Thanks for review in advance!
Some questions: 1. I can see ifarch here, why not use ifarch to install files, but just add more subpackages? 2. devel/static packages description are not good: Example: This package contains shared libraries for developing applications that use %{name}. This package contains static libraries for developing applications that use %{name}.
(In reply to Christopher Meng from comment #1) > Some questions: > > 1. I can see ifarch here, why not use ifarch to install files, but just add > more subpackages? %ifarch is used here for building linpack64-subpkgs with support for 64Bit INT. Every subpkg, but the doc, carries just one or two files. I don't know why to add even more subpackages? > 2. devel/static packages description are not good: > > Example: > > This package contains shared libraries for developing applications that use > %{name}. > > This package contains static libraries for developing applications that use > %{name}. current %discription are ripped-off from LAPACK or BLAS. I did this intentionally to keep this in consistancy with them, because they more or less come from the same family.
OK. cp -a ---> cp -pa APPROVED.
(In reply to Christopher Meng from comment #3) > cp -a ---> cp -pa cp -a == cp -cdpR Thanks for the review, Christopher! ##### New Package SCM Request ======================= Package Name: linpack Short Description: FORTRAN subroutines to analyze and solve linear equations Owners: besser82 Branches: el5 el6 f18 f19 f20 InitialCC:
Some remarks: I personally hate reviews, which are rushed through in such a haste, they don't give anybody a chance to look into a packages. In this case, it was LESS THAN AN HOUR, which, to me, excludes any possibility of a careful review. Simply running rpmlint or fedora-review also is not a careful review! Back to this package: * This section from the spec is bogus and should be needs to be removed: # compress man-pages pushd man3 gzip -9 * popd * Any proof for this package being BSD-licensed? The license file contained in this package is added by Björn, but I can't find any upstream evidence linpack is actually licensed BSD. Googling also did not provide further information. * I prefer packages to install their docs into /usr/share/doc/<package>. Installing docs into <package>-doc seems quite nonsensical to me.
I've told him about the manpage generation script issue in gtalk. For license problem, I think he should add some comments in the spec. docdir waiting for Björn to answer.
(In reply to Ralf Corsepius from comment #5) > * This section from the spec is bogus and should be needs to be removed: > # compress man-pages > pushd man3 > gzip -9 * > popd I nuked this inside the updated spec. > * Any proof for this package being BSD-licensed? The license file contained > in this package is added by Björn, but I can't find any upstream evidence > linpack is actually licensed BSD. Googling also did not provide further > information. http://www.netlib.org/linpack/archives/readme says: Questions/comments should be directed to lapack.edu. Looking on their archives [1] I see some question about this from a few years ago, which was answered: "Basically it is BSD." The additional documentation from Universität Bayreuth was auto-generated from the source-files, so I consider them covered by the same license as the code-sources are. Same goes for the DQRDC2 routine which is a modified version from LINPACK's original DQRDC routine. I added some clarifing comments about that inside the spec. > * I prefer packages to install their docs into /usr/share/doc/<package>. > Installing docs into <package>-doc seems quite nonsensical to me. Is there any guideline telling me where the contents of a doc-subpkg has to be located? There are a lot of packages providing the documentation from the doc-subpkg inside <package>-doc: * boost-doc * gtk2-devel-docs * kernel-doc * xorg-x11-docs Just to name a prominent few. So I would consider doing so is somehow common pratice. [1] http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg00301.html ##### Updated package: %changelog * Mon Aug 26 2013 Björn Esser <bjoern.esser> - 19990929-1 - added some detailed comments about licensing - added DQRDC2 routine - removed compression of man-pages during %%build - added some pdf-documentation from CERN's public library * Sun Aug 25 2013 Björn Esser <bjoern.esser> - 19880411-1 - Initial rpm release Koji Builds: el5: https://koji.fedoraproject.org/koji/taskinfo?taskID=5853614 el6: https://koji.fedoraproject.org/koji/taskinfo?taskID=5853620 F18: https://koji.fedoraproject.org/koji/taskinfo?taskID=5853624 F19: https://koji.fedoraproject.org/koji/taskinfo?taskID=5853627 F20: https://koji.fedoraproject.org/koji/taskinfo?taskID=5853635 Frh: https://koji.fedoraproject.org/koji/taskinfo?taskID=5853639 Urls: Spec URL: http://besser82.fedorapeople.org/review/linpack.spec SRPM URL: http://besser82.fedorapeople.org/review/linpack-19990929-1.fc19.src.rpm
> I prefer packages to install their docs into /usr/share/doc/<package>. > Installing docs into <package>-doc seems quite nonsensical to me. While this would be nice, it won't work anymore in Fedora 20 due to the UnversionedDocdirs feature. And it has been troublesome for older releases, too, when packagers installed their -doc subpackage files into /usr/share/doc/%{name}-%{version} manually (temporarily %doc has even deleted manually installed files in the default docdir). Using %doc in the base package conflicts with installing subpackage files into /usr/share/doc/%{name}. How? The %doc macro in the base package will include any files in /usr/share/doc/%{name} leading to duplicate documentation and conflicts. Examples? At the bottom of the UnversionedDocdirs tracker bug 993551 I've added a few.
(In reply to Björn "besser82" Esser from comment #7) > (In reply to Ralf Corsepius from comment #5) > > * This section from the spec is bogus and should be needs to be removed: > > # compress man-pages > > pushd man3 > > gzip -9 * > > popd > > I nuked this inside the updated spec. > > > * Any proof for this package being BSD-licensed? The license file contained > > in this package is added by Björn, but I can't find any upstream evidence > > linpack is actually licensed BSD. Googling also did not provide further > > information. > > http://www.netlib.org/linpack/archives/readme says: > > Questions/comments should be directed to lapack.edu. > > Looking on their archives [1] I see some question about this from a few > years ago, which was answered: > > "Basically it is BSD." That's what I also saw, but ... ... that's insufficient. For being able to ship something one needs a license from the copyright holder of the source code, otherwise you are at risk of committing license violations. (Note: lack of licensing means "unlicense" and "non-redistributatble"). What you currently are doing in your tarball is you - Björn - adding a license and thus granting others a license to code you do not own. > > * I prefer packages to install their docs into /usr/share/doc/<package>. > > Installing docs into <package>-doc seems quite nonsensical to me. > > Is there any guideline telling me where the contents of a doc-subpkg has to > be located? There are a lot of packages providing the documentation from the > doc-subpkg inside <package>-doc: There is a guideline telling you documentation should accompany the package it is documenting. This originally was referring to "move devel-docs" (e.g. man 3 man-pages) into the *devel packages and run-time docs (e.g. man 1 man-pages) into "run-time" docs. > > * boost-doc > * gtk2-devel-docs > * kernel-doc > * xorg-x11-docs Yes, there are several packages, which IMO package their docs in this non-helpful way. In many cases, this likely had happened accidentally, when rpmlint started to rant on "big doc" packages, which caused packagers to start splitting them out of the main package. There are also cases, in which doc-packages are "arched", despite this hardly rare makes sense.
(In reply to Michael Schwendt from comment #8) > > I prefer packages to install their docs into /usr/share/doc/<package>. > > Installing docs into <package>-doc seems quite nonsensical to me. > > While this would be nice, it won't work anymore in Fedora 20 due to the > UnversionedDocdirs feature. Not true. It does work in Fedora 18 .. 20. And yes, it requires work. > And it has been troublesome for older releases, > too, when packagers installed their -doc subpackage files into > /usr/share/doc/%{name}-%{version} manually (temporarily %doc has even > deleted manually installed files in the default docdir). Right, rpm's behavior wrt. %doc has changed, but the %_pkgdocdir combined with direct installation to _pkgdocdir works at least on Fedora and likely also on EPEL6.
> Not true. Huh? Why would you say that? It does not work anymore in Fedora 20. See bug 998149 (jsoncpp) for an example: %files %doc AUTHORS LICENSE NEWS.txt README.txt %files doc %doc AUTHORS LICENSE NEWS.txt README.txt %{_docdir}/%{name} and the base package includes the whole docdir contents. This causes a conflict, if the noarch -doc pkg has been built on a different arch. The only work-around would be to install all the %doc files manually. > And yes, it requires work. A lot of work, since you cannot use %doc anymore, such as with the more complicated bug 998168 (mathgl). [...] A general repo check is still missing to find out where this leads to duplicated documentation. It's easy to find these cases if they conflict already, but where they don't conflict yet (out of coincidence), it's a time-bomb.
(In reply to Michael Schwendt from comment #11) > > Not true. > > Huh? Why would you say that? Because I just did that for a package. see. libkni3 in git).
(In reply to Ralf Corsepius from comment #9) > (In reply to Björn "besser82" Esser from comment #7) > > (In reply to Ralf Corsepius from comment #5) > > "Basically it is BSD." > That's what I also saw, but ... > > ... that's insufficient. > > For being able to ship something one needs a license from the copyright > holder of the source code, otherwise you are at risk of committing license > violations. > > (Note: lack of licensing means "unlicense" and "non-redistributatble"). > > What you currently are doing in your tarball is you - Björn - adding a > license and thus granting others a license to code you do not own. The LICENSE I put into the tarball actually meets the license from the authors. Just got an answer from Jack Dongarra: LINPACK is licensed under the Modified 3 clause BSD license. Hope this helps, Jack Dongarra ********************************************************** Prof. Jack Dongarra; Innovative Computing Laboratory; EECS Department; 1122 Volunteer Blvd; University of Tennessee; Knoxville TN 37996-3450; +1-865-974-8295; dongarra.edu; http://www.cs.utk.edu/~dongarra/ Additionaly I send off an email about license-clarification to Ross Ihaka and Brian Ripley (BDR) about DQRDC2. Will post this, when I get an answer from them.
> libkni3 in git > %exclude %{_pkgdocdir}/html > %exclude %{_pkgdocdir}/*.pdf That's cheating. How many packages duplicate the docs because they don't %exclude anything? And here's it *only* two files to exclude -> not (or hardly) practicable if there are many more files/dirs to exclude. Anyway, I've mailed Ville privately about the %doc %_pkgdocdir conflicts.
(In reply to Michael Schwendt from comment #14) > > libkni3 in git > > > %exclude %{_pkgdocdir}/html > > %exclude %{_pkgdocdir}/*.pdf > > That's cheating. What's cheating about this? It's the normal way to split subdirs into different packages. > How many packages duplicate the docs because they don't > %exclude anything? And here's it *only* two files to exclude html is a directory filled with the usual doxygen stuff, and *pdf also is more than 1 package. > -> not (or > hardly) practicable if there are many more files/dirs to exclude. Now you are cheating.
(In reply to Björn "besser82" Esser from comment #13) > (In reply to Ralf Corsepius from comment #9) > > (In reply to Björn "besser82" Esser from comment #7) > > > (In reply to Ralf Corsepius from comment #5) > > > "Basically it is BSD." > > That's what I also saw, but ... > > > > ... that's insufficient. > > > > For being able to ship something one needs a license from the copyright > > holder of the source code, otherwise you are at risk of committing license > > violations. > > > > (Note: lack of licensing means "unlicense" and "non-redistributatble"). > > > > What you currently are doing in your tarball is you - Björn - adding a > > license and thus granting others a license to code you do not own. > > The LICENSE I put into the tarball actually meets the license from the > authors. Just got an answer from Jack Dongarra: > > LINPACK is licensed under the Modified 3 clause BSD license. > Hope this helps, > Jack Dongarra > > ********************************************************** > Prof. Jack Dongarra; Innovative Computing Laboratory; EECS Department; > 1122 Volunteer Blvd; University of Tennessee; Knoxville TN 37996-3450; > +1-865-974-8295; dongarra.edu; http://www.cs.utk.edu/~dongarra/ OK, I'd recommed to include this mail into the package's docs and remove your extra license file.
Git done (by process-git-requests).
> It's the normal way to split subdirs into different packages. Normal? Very unusual it is. In the following fragment, %doc LICENSE.txt readme.txt AUTHORS.txt %exclude %{_pkgdocdir}/html %exclude %{_pkgdocdir}/*.pdf there is no path that includes %{_pkgdocdir}/html %{_pkgdocdir}/*.pdf to begin with. Therefore it's nothing than a hack to %exclude those paths based on the knowledge that the %doc line not only copies local files into the docdir but includes the dir *and* everything (!) in it, regardless of which files are specified on that line, and that the whole thing will conflict in Fedora 20. The mathgl packager in the ticket I've linked also called that a hack some days ago, btw. ;) Only when not using %doc to install any of those files I would agree with you calling it an ordinary subpackage split, because then dir/file ownership would not be automatic, and in many cases it would be possible to do it without %exclude statements even. %exclude is a last resort, not the norm. Further, there's not even a "file listed twice" warning, if the excludes are missing. As I've mentioned, for a long time it has not even been possible to install into the versioned (!) default docdir and use %doc at the same time.
(In reply to Michael Schwendt from comment #18) > > It's the normal way to split subdirs into different packages. > > Normal? Yes. > Very unusual it is. Definitely no. It is one standard way how packages, which are "mixing subdirs" can be split into sub-packages. The fact we are talking about %doc is mostly irrelevant here. > In the following fragment, > > %doc LICENSE.txt readme.txt AUTHORS.txt > %exclude %{_pkgdocdir}/html > %exclude %{_pkgdocdir}/*.pdf > > there is no path that includes > > %{_pkgdocdir}/html > %{_pkgdocdir}/*.pdf These are packaged into another package a couple of lines elsewhere in the package. == sharing %{_pkgdocdir} between packages.
> These are packaged into another package a couple of lines > elsewhere in the package. You misunderstand it. :-/ One uses %exclude in a %files section, only if the same %files section includes the files, but if you want the files to be included in a subpackage instead. It's only a side-effect that "%doc LICENSE.txt readme.txt AUTHORS.txt" includes not only those three files, but everything in %{_pkgdocdir}. I'll open a ticket in the FPC trac instance.
(In reply to Ralf Corsepius from comment #16) > (In reply to Björn "besser82" Esser from comment #13) > > (In reply to Ralf Corsepius from comment #9) > > > (In reply to Björn "besser82" Esser from comment #7) > > > > (In reply to Ralf Corsepius from comment #5) > > > > "Basically it is BSD." > > > That's what I also saw, but ... > > > > > > ... that's insufficient. > > > > > > For being able to ship something one needs a license from the copyright > > > holder of the source code, otherwise you are at risk of committing license > > > violations. > > > > > > (Note: lack of licensing means "unlicense" and "non-redistributatble"). > > > > > > What you currently are doing in your tarball is you - Björn - adding a > > > license and thus granting others a license to code you do not own. > > > > The LICENSE I put into the tarball actually meets the license from the > > authors. Just got an answer from Jack Dongarra: > > > > LINPACK is licensed under the Modified 3 clause BSD license. > > Hope this helps, > > Jack Dongarra > > > > ********************************************************** > > Prof. Jack Dongarra; Innovative Computing Laboratory; EECS Department; > > 1122 Volunteer Blvd; University of Tennessee; Knoxville TN 37996-3450; > > +1-865-974-8295; dongarra.edu; http://www.cs.utk.edu/~dongarra/ > > OK, I'd recommed to include this mail into the package's docs and remove > your extra license file. Seems like I'll get DQRDC2 as BSD-3, too :) The code in R is GPL2+. I'd be happy to make this subroutine available as BSD or even public domain if Brian agrees. But I think I'll need a bundling exception for this, since it seems to be compiled into libR as well. On the other hand libR bundles some LINPACK code... What's your thoughts, Ralf and Michael?
(In reply to Ralf Corsepius from comment #16) > OK, I'd recommed to include this mail into the package's docs and remove > your extra license file. That won't work. If the package really is under BSD then full license text must be included to comply with licensing terms, see point 1 of the license: "Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer."
(In reply to Mikolaj Izdebski from comment #22) > (In reply to Ralf Corsepius from comment #16) > > OK, I'd recommed to include this mail into the package's docs and remove > > your extra license file. > > That won't work. If the package really is under BSD then full license text > must be included to comply with licensing terms, see point 1 of the license: > "Redistributions of source code must retain the above copyright notice, this > list of conditions and the following disclaimer." So I need to include the LICENSE-file generated during creation of tarball, too, I think? Right?
If no such LICENSE file is included already, don't add it to the source tarball of the Fedora package. Without confirmation by upstream, it may or may not be the actual license terms they refer to. Follow https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text and add the file to the src.rpm as a separate file, which to include as %doc. Same for an email response you receive. However, if the response is only a promise to clarify the licensing, that's not enough. [...] About the bundled code, this is still too vague to comment on, IMO. Is it just a subroutine, a copylib, or a copied (and possibly modified) library that exists as a separate upstream project?
(In reply to Michael Schwendt from comment #24) > If no such LICENSE file is included already, don't add it to the source > tarball of the Fedora package. Without confirmation by upstream, it may or > may not be the actual license terms they refer to. Follow > https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text > and add the file to the src.rpm as a separate file, which to include as %doc. So I sent the whole License-text to upstream ad he replied in meaning of "Yes, BSD-3-clause is the right license...". So I think using the the reply of upstream can be used as %doc LICENSE here. It actually has the full BSD-3-clause license in it. > Same for an email response you receive. However, if the response is only a > promise to clarify the licensing, that's not enough. This is currently about the DQRDC2 routine. Here I'm actually waiting for some definitive response from upstream. I could include this as GPLv2+ licensed code, since libR-upstreams confirmed license is such. > [...] > > About the bundled code, this is still too vague to comment on, IMO. Is it > just a subroutine, a copylib, or a copied (and possibly modified) library > that exists as a separate upstream project? It's a modified version of LINPACK's DQRDC routine, which is included inside libR-sources. Inside these source partialy modified subsets of LINPACK and BLAS are bundled, too. The _real_ problem here is, that there is a bunch of software (e.g. scikit-learn or biolab's Orange) which needs LINPACK && DQRDC2, but you can't link against liblinpack AND libR into the same binary. Linking both into the same binary will either result in ld-errors (double-defined functions) or segfaults on runtime, because LINPACK and libR expose some identical symbols. The other problem is, the subset of LINPACK, which get's bundled by libR has been modified and it's routines will not return the same results the pristine LINPACK will do. So you just can't link these executables against against libR, only.
Package Change Request ====================== Package Name: linpack Owners: ml-sig besser82 Branches: el5 el6 f18 f19 f20
Complete.
This was meant to be a copy lib from upstream, so I opened: https://fedorahosted.org/fpc/ticket/349 I retired the package on all branches. There has been no import nor a build for it. Closing this as "CANTFIX".