Spec URL: http://dl.atrpms.net/all/arpack.spec SRPM URL: http://dl.atrpms.net/all/arpack-2.1-5.at.src.rpm Description: ARPACK is a collection of Fortran77 subroutines designed to solve large scale eigenvalue problems. The package is designed to compute a few eigenvalues and corresponding eigenvectors of a general n by n matrix A. It is most appropriate for large sparse or structured matrices A where structured means that a matrix-vector product w <- Av requires order n rather than the usual order n**2 floating point operations. This software is based upon an algorithmic variant of the Arnoldi process called the Implicitly Restarted Arnoldi Method (IRAM). ============================================================================ rpmlint gives W: arpack invalid-license Freely distributable W: arpack no-documentation W: arpack-devel invalid-license Freely distributable documentation is in the devel package, and the license is a BSD derived one (so maybe BSD-like would be more appropriate).
I fear this is not possible to include in fedora due to the licensing. As a first remark it is not BSD-like, since there is this clause (which is acceptable): * If you modify the source for these routines we ask that you change the name of the routine and comment the changes made to the original. And then there is those clauses which seem to be unacceptable to me: * Written notification is provided to the developers of intent to use this software. This is a restriction on use which seems to strong to me for that software to be OSI-compliant. * Also, we ask that use of ARPACK is properly cited in any resulting publications or software documentation. Depending on what exactly 'ask' means (is it an option, or is it an obligation?) it may also be a restriction on use which is too strong to reach OSI-compliance.
Patrice's concerns appear valid, though imo the only problematic licensing statement is the bit about "Written notification is provided to the developers...". That's one of the more poorly worded and silly license requirements I've seen in awhile.
For what it's worth, arpack is in Debian, and binaries are distributed by the MathWorks in MATLAB, so either everyone else has "notified the authors" or they are just ignoring this. Technically, this does not place any burden on Fedora or any repackager of Fedora, but on the end user. Realistically, it will be ignored by users of Fedora as I'm sure it has been by virtually every other user. I was going to try contacting the authors, but I thought I would make sure nobody else here has or intends to so that they don't get multiple identical requests about the same thing.
(In reply to comment #3) > For what it's worth, arpack is in Debian, and binaries are distributed by the > MathWorks in MATLAB, so either everyone else has "notified the authors" or they > are just ignoring this. You should also contact the debian people, their copyright at http://packages.debian.org/changelogs/pool/main/a/arpack/arpack_2.1-8/copyright state that it is public domain... > Technically, this does not place any burden on Fedora or any repackager of > Fedora, but on the end user. Realistically, it will be ignored by users of > Fedora as I'm sure it has been by virtually every other user. It doesn't matter, it is not OSI-compliant. Users ignoring the clause don't have the right to use it. I think it is the same for * Also, we ask that use of ARPACK is properly cited in any resulting publications or software documentation. except if 'ask' isn't a requirement. But is it sure that it isn't a requirement?
(In reply to comment #3) > I was going to try contacting the authors, but I thought I would make sure > nobody else here has or intends to so that they don't get multiple identical > requests about the same thing. That was my next idea, too, after reading Patrice's (valid) remarks. Can you put me into the Cc:? Thanks!
Changing blocker to FE-REVIEW since it seems to be under review.
I seem to remember building arpack privately for some other software. I'm interested in seeing this in Extras, too. If Quentin doesn't have the time to review this, I can do it in a few days.
The main thing stopping the review at this point is clarification about the odd licensing terms. I sent an e-mail to the "official" arpack address last week asking for clarification and have received no response. I found an e-mail for one of the authors and tried to contact him directly today. I think I'll try to track down the others as well.
I forgot about this and submitted this package for review in #bug 216916 myself, sorry. Axel, would you consider letting me maintain this or at least co-maintain? Here's a patch to fix undefined-non-weak-symbols rpmlint warning.
Created attachment 141957 [details] Fix undefined-non-weak-symbols rpmlint warning and add license text to the package.
*** Bug 216916 has been marked as a duplicate of this bug. ***
Thanks for the lapack patch and of course for the troublesome license inclusion, I'll bump the release tag and add a changelog entry like %changelog * Thu Nov 23 2006 Dominik 'Rathann' Mierzejewski <hidden-for-bugzilla-scrapers> - 2.1-5 - Fix missing lapack dependencies. - Add RiceBSD license text. No problem with comaintaining. Let's hope that packages makes it through the license barrier, e.g. the authors grant a different license than the current one (thanks to Quentin for picking this up).
Let's hope so! :) Another thing worth mentioning: I actually built arpack against atlas-devel, which provides an alternative lapack implementation, but since it doesn't provide lapack-devel, I decided to stick to lapack-devel. The user can replace lapack with atlas at install time. In fact, I wonder what yum will pick to satisfy lapack.so.3 dependency...
Created attachment 148107 [details] Clarification of ARPACK license by author
Comment on attachment 148107 [details] Clarification of ARPACK license by author I phoned Danny Sorensen to try and get clarification for this. He stated that it was the lawyers at RICE that required him to have the license, and so he hesitated to change the license due to the need to involve the RICE lawyers in the loop. He was however willing to clarify the statement <quote> Written notification is provided to the developers of intent to use this software. Also, we ask that use of ARPACK is properly cited in any resulting publications or software documentation. </quote> and how it applies to Fedora. The clarification is in the attached e-mail above from Danny. Essentially, he is not asking that Fedora or their users inform him of the use of ARPACK. However, he is requesting that the "eigs" function that uses ARPACK cites it. This is in fact the case, however, I take this statement a bit further in meaning that code that links to ARPACK muct mention ARPACK in its documentation Is this an acceptable clarification? If not what is needed to further clarify this point? Regards David
Thanks David for contacting the author over phone! In my understanding this is still an advertizing style clause. I'm escalating this to FE-Legal and asked spot about this, who is the license wizzard around here.
Is there any progress on FE-Legal's side on the above statement from Sorensen? He seemed quite willing to help out and it was just the amount of time it would take him to negotiate with his universities lawyers that worried him. If I can have a clarification of exactly what clarifying statement you'd need from him to resolve this issue, I'm willing to recontact him. D.
Include the clarification attachment in the package as %doc, and we're good. This is really unenforceable anyways, as it amounts to a "please do this" as opposed to a "you must do this". Lifting FE-Legal
Hi Tom, This is great news. I hope Axel or Quentin are now able to package ARPACK for Extras.. Cheers David
(In reply to comment #18) > Include the clarification attachment in the package as %doc, and we're good. > > This is really unenforceable anyways, as it amounts to a "please do this" as > opposed to a "you must do this". > > Lifting FE-Legal Because it was unclear whether this license could be regarded as GPL compatible, the primary author of octave has not included some code that links to arpack. In separate discussions with him, he has asked whether there is any other discussion or reasoning behind the decision to accept this license now after it was originally considered problematic.
(In reply to comment #20) > Because it was unclear whether this license could be regarded as GPL compatible, > the primary author of octave has not included some code that links to arpack. In > separate discussions with him, he has asked whether there is any other > discussion or reasoning behind the decision to accept this license now after it > was originally considered problematic. I didn't say that it was GPL compatible. We can ask the FSF if we want that ruling. The delay on the decision was entirely due to the fact that I hadn't yet looked at it (until yesterday). If I had to guess, I would say it's not GPL compatible, due to the advertising clauses.
(In reply to comment #21) > I didn't say that it was GPL compatible. We can ask the FSF if we want that > ruling. The delay on the decision was entirely due to the fact that I hadn't yet > looked at it (until yesterday). > > If I had to guess, I would say it's not GPL compatible, due to the advertising > clauses. Well, I guess that's what I (and octave's author) don't understand. While the advertising clause is apparently non-binding and likely unenforceable, it does appear to make it technically incompatible with the GPL. That makes it impossible for octave, a GPL program, to link to it. So, we can include this in Fedora, but other Fedora programs can't link to it? My interest in getting arpack into Fedora was for the benefit of octave. Maybe this should be taken up with the FSF.
Opened a license request with the FSF. Putting this back on FE-Legal.
Since the GPL compatibility is not a blocker for reviewing this package I created a new bug for the discussion on whether octave can be linked against arpack: bug #234191 Thanks, spot, for clearing the FE-Legal issues for the principal import!
Now that the licensing issues are clarified we can continue reviewing: Spec URL: http://dl.atrpms.net/all/arpack.spec SRPM URL: http://dl.atrpms.net/all/arpack-2.1-6.at.src.rpm This includes the license (+ a text transcript of the doc file ...) & author clarification. It also includes the patch by rathann of comment #10.
(In reply to comment #22) > Well, I guess that's what I (and octave's author) don't understand. While the > advertising clause is apparently non-binding and likely unenforceable, it does > appear to make it technically incompatible with the GPL. That makes it > impossible for octave, a GPL program, to link to it. So, we can include this > in Fedora, but other Fedora programs can't link to it? My interest in getting > arpack into Fedora was for the benefit of octave. Maybe this should be taken up > with the FSF. I'm interested in arpack for the benefit of freefem++, which is LGPL, so don't say that "other Fedora programs can't link to it".
Spec file quote: > # The correct dependency would be the following, but it doesn't exist on RHEL4/3 > #BuildRequires: lapack-devel > BuildRequires: %{_libdir}/liblapack.so Unfortunately, the new dependency breaks mock (fc6/x86_64) for me.
To be precise, this happens because instead of lapack-devel, mock installs atlas-devel.
How does it break? Maybe it is an atlas <-> lapack generic issue?
(In reply to comment #29) > How does it break? Maybe it is an atlas <-> lapack generic issue? > Yes, it is.
Is there a bugzilla for this? If yes, we should add this as a blocker to this bug, or at least reference it. If not, could you please open one and block/reference this to this bug? Thanks!
The problem seems interesting but I've got a question. You've written that lapack-devel doesn't exist on RHEL. So which package provides %{_libdir}/ liblapack.so in RHEL?
Axel, why don't you keep BuildRequires: lapack-devel and just change it in RHEL branch of the specfile?
> The problem seems interesting but I've got a question. You've written that > lapack-devel doesn't exist on RHEL. So which package provides %{_libdir}/ > liblapack.so in RHEL? lapack itself, e.g. what I meant is that RHEL does have lapack, but hasn't split out the development files to lapack-devel, but the file dependency covers both. It's a packaging difference just in naming and subpackaging - at the end it's lapack bits that are being used in both cases.
Any progress? I have a new package depending on this.
rathann, could you fix the liblapack.so conflict between lapack and atlas?
There's no conflict. atlas' lapack is in a different directory (%{_libdir}/atlas/ IIRC).
It looks like the comments from Michał Bentkowski indicate that lapack/atlas are sharing (virtual?) Provides, but are not compatible. See also comment #13. If atlas-devel/lapack-devel are interchangable forget my comment :) Quentin, any chance you'd find some time for reviewing? Or are you waiting to see whether this package is GPL compatible (bug #234191), as otherwise it is of no use to octave? If you don't want to review with the current license or until bug #234191 is resolved otherwise, then perhaps someone else would like to? Rathann, maybe?
I was going to take a look at it, but the most recent SRPM link is broken: http://dl.atrpms.net/all/arpack-2.1-6.at.src.rpm The spec is still there, but since there are patches are other local source files, I thought it would be easier to review the SRPM. Having said that, I don't have a lot of time to do this, so if someone else wants to take it, they can. If not, I'll try to get it done soon.
There is no '.at' anymore in the package name, e.g. it's plain http://dl.atrpms.net/all/arpack-2.1-6.src.rpm
Anyone up to a a review?
I'm a bit busy these days, but I'll try to find some time during the weekend to do this.
I'll review this now.
I suggest the following patch to adress two issues: 1. we shouldn't ship static libraries 2. there's a bug in eigenvalue calculation routine, see http://www.ann.jussieu.fr/pipermail/freefempp/2006/000213.html for more details.
Created attachment 158233 [details] patch to remove static libs and fix function name clash You can to get the arpack-patch-lapack.tar.gz from any freefem++ tarball.
Doesn't build in mock/devel/x86_64: + gcc -shared -llapack -Wl,-soname,libarpack.so.2 -o libarpack.so.2.1 cgetv0.o cmout.o cnaitr.o cnapps.o cnaup2.o cnaupd.o cneigh.o cneupd.o cngets.o csortc.o cstatn.o cvout.o dgetv0.o dlaqrb.o dmout.o dnaitr.o dnapps.o dnaup2.o dnaupd.o dnconv.o dneigh.o dneupd.o dngets.o dsaitr.o dsapps.o dsaup2.o dsaupd.o dsconv.o dseigt.o dsesrt.o dseupd.o dsgets.o dsortc.o dsortr.o dstatn.o dstats.o dstqrb.o dvout.o icnteq.o icopy.o iset.o iswap.o ivout.o second.o sgetv0.o slaqrb.o smout.o snaitr.o snapps.o snaup2.o snaupd.o snconv.o sneigh.o sneupd.o sngets.o ssaitr.o ssapps.o ssaup2.o ssaupd.o ssconv.o sseigt.o ssesrt.o sseupd.o ssgets.o ssortc.o ssortr.o sstatn.o sstats.o sstqrb.o svout.o zgetv0.o zmout.o znaitr.o znapps.o znaup2.o znaupd.o zneigh.o zneupd.o zngets.o zsortc.o zstatn.o zvout.o /usr/bin/ld: cannot find -llapack collect2: ld returned 1 exit status error: Bad exit status from /var/tmp/rpm-tmp.94753 (%build) I suggest you keep BuildRequires: lapack-devel for now and change it to BR: lapack for older RHEL.
Is that perhaps comment #38? > It looks like the comments from Michał Bentkowski indicate that lapack/atlas are > sharing (virtual?) Provides, but are not compatible. See also comment #13. > > If atlas-devel/lapack-devel are interchangable forget my comment :) E.g. did your build fail because atlas was pulled in instead of lapack? In that case it's an issue within lapack <-> atlas that should be fixed irrespective of arpack. But even then I wonder why the build doesn't find %{_libdir}/liblapack.so when it's an explicit build requirement, even if pulled in from atlas.
(In reply to comment #44) > I suggest the following patch to adress two issues: > 1. we shouldn't ship static libraries Why not? Many people using arpack do so in static builds. But what needs to be done is to split of the static lib in arpack-static (when the package was submitted the guideline did not exist yet). > 2. there's a bug in eigenvalue calculation routine, see > http://www.ann.jussieu.fr/pipermail/freefempp/2006/000213.html for more details. Thanks! It does look a bit awkward that freefem++ ships a patch to two files as those two files in a tarball within its tarball, and for simplicity's sake I'll better make a real patch out of it. Do you perhaps know whether freefem++ reported this bug upstream to arpack? I saw that you asked, but there was no reply on the archive (maybe unlinked due to mailman's archive boundaries).
(In reply to comment #47) > Is that perhaps comment #38? [...] > E.g. did your build fail because atlas was pulled in instead of lapack? In > that case it's an issue within lapack <-> atlas that should be fixed > irrespective of arpack. Yes. atlas-devel got installed. > But even then I wonder why the build doesn't find %{_libdir}/liblapack.so > when it's an explicit build requirement, even if pulled in from atlas. Hm. We'll have to investigate that.
(In reply to comment #48) > (In reply to comment #44) > > I suggest the following patch to adress two issues: > > 1. we shouldn't ship static libraries > > Why not? Many people using arpack do so in static builds. But what needs to be > done is to split of the static lib in arpack-static (when the package was > submitted the guideline did not exist yet). Why too? The guidelines say there must be a compelling reason to ship static libs. Is there one? If yes, please provide it. And yes, of course static libs must be in a separate subpackage. > > 2. there's a bug in eigenvalue calculation routine, see > > http://www.ann.jussieu.fr/pipermail/freefempp/2006/000213.html for more details. > > Thanks! It does look a bit awkward that freefem++ ships a patch to two files > as those two files in a tarball within its tarball, and for simplicity's sake > I'll better make a real patch out of it. Do you perhaps know whether freefem++ > reported this bug upstream to arpack? I saw that you asked, but there was no > reply on the archive (maybe unlinked due to mailman's archive boundaries). I don't think they did. At least there were no further replies. I would've made a patch myself, but I don't know Fortran and I didn't have time to look into it.
In continuation to comment #47 The atlas vs lapack issue is quite mysterious: # repoquery -q --whatprovides /usr/lib64/liblapack.so Importing additional filelist information atlas-devel-0:3.6.0-11.fc6.x86_64 lapack-devel-0:3.1.1-1.fc6.x86_64 # rpm -q atlas-devel atlas-devel-3.6.0-11.fc6 # rpm -ql atlas-devel | grep liblapack.so$ /usr/lib64/atlas/liblapack.so # rpm -q atlas-devel --provides atlas-devel = 3.6.0-11.fc6 So repoquery (and therefore also yum/mock) think atlas-devel contains %{_libdir}/liblapack.so while in reality it does not? I haven't looked at the atlas specfile, but the situation above should not be possible to happen. Why is repoquery fooled that atlas-devel contains %{_libdir}/liblapack.so? It isn't a %file and not a virtual Provides: either. (this comment probably belongs as a bug report against atlas or yum-metadata-parser)
(In reply to comment #50) > > Many people using arpack do so in static builds. > Why too? The guidelines say there must be a compelling reason to ship static > libs. Is there one? If yes, please provide it. The reason is that people use it that way. :) Seriously though, it has been often discussed on fedora-packaging that numerical libraries are more often than not statically linked especially on large sites with heterogeneous setups (e.g. every numerical physics institute ... ;). People have been ranting about scientists and their assumed lack of IT skills, bad IT planning leading to non-homogeneous setups, not keeping all Linux systems on the same distro and release etc., but irrespective of whether one approves of their work mode and IT setups the fact remains that static libs are very much in use there. Which makes every numerical libs a candidate for a static subpackage.
(In reply to comment #50) > Why too? The guidelines say there must be a compelling reason to ship static > libs. Is there one? If yes, please provide it. And yes, of course static libs > must be in a separate subpackage. I have tried to summarize the reasons for shipping static libs for numerical and data processing on my wiki page https://fedoraproject.org/wiki/PatriceDumas
(In reply to comment #48) > Why not? Many people using arpack do so in static builds. But what needs > to be done is to split of the static lib in arpack-static (when the package > was submitted the guideline did not exist yet). OK, I have no objections to shipping static libs as long as they're in a separate subpackage. > Thanks! It does look a bit awkward that freefem++ ships a patch to two files > as those two files in a tarball within its tarball, and for simplicity's sake > I'll better make a real patch out of it. Ping?
Axel, it's been 2 months with no changes. I've asked you to apply a simple workaround for the lapack issue, which you ignored. You offered to clean up the patch from freefem, but nothing has happened since. If nothing changes within a few days, I'm going to close this review and submit my own request. This has been holding up my freefem++ package for too long now.
(In reply to comment #51) > In continuation to comment #47 > > The atlas vs lapack issue is quite mysterious: > > # repoquery -q --whatprovides /usr/lib64/liblapack.so > Importing additional filelist information > atlas-devel-0:3.6.0-11.fc6.x86_64 > lapack-devel-0:3.1.1-1.fc6.x86_64 > # rpm -q atlas-devel > atlas-devel-3.6.0-11.fc6 > # rpm -ql atlas-devel | grep liblapack.so$ > /usr/lib64/atlas/liblapack.so > # rpm -q atlas-devel --provides > atlas-devel = 3.6.0-11.fc6 > > So repoquery (and therefore also yum/mock) think atlas-devel contains > %{_libdir}/liblapack.so while in reality it does not? I haven't looked at the > atlas specfile, but the situation above should not be possible to happen. > > Why is repoquery fooled that atlas-devel contains %{_libdir}/liblapack.so? It > isn't a %file and not a virtual Provides: either. > > (this comment probably belongs as a bug report against atlas or yum-metadata-parser) > FWIW, F-7's repoquery doesn't have this problem: $ repoquery -q --whatprovides /usr/lib64/liblapack.so Loading "fastestmirror" plugin Loading mirror speeds from cached hostfile Importing additional filelist information lapack-devel-0:3.1.0-4.fc7.x86_64 lapack-devel-0:3.1.1-1.fc7.x86_64
(In reply to comment #55) > Axel, it's been 2 months with no changes. I've asked you to apply a simple > workaround for the lapack issue, which you ignored. I didn't ignore it, we were talking about this issue on bugzilla and list. The workaround you suggest is looking more like papering over an issue that will revenge itself later. You suggest to force the choice on BR, but we have no sane way to do so for the run-time dependencies, too. Starting to work around that, too, is the wrong angle to attack this. The issue is a generic problem between lapack and atlas and needs to be resolved and not looked away from. I opened bug #258041 for this issue and made it a blocker. > You offered to clean up the patch from freefem, but nothing has happened > since. If nothing changes within a few days, I'm going to close this review > and submit my own request. This has been holding up my freefem++ package > for too long now. OK, I suggest if you have the time that you clean up the patch and submit it to this bugzilla.
Created attachment 235721 [details] specfile patch to fix function name clash
Created attachment 235731 [details] source patch to fix function name clash
(In reply to comment #57) > OK, I suggest if you have the time that you clean up the patch and submit it to > this bugzilla. Done.
Filed bug 349801 against mock.
Thanks a lot, taken as is. Will still post new URLs for spec/src.rpm to be formally correct.
http://dl.atrpms.net/all/arpack-2.1-7.src.rpm http://dl.atrpms.net/all/arpack.spec * Wed Oct 24 2007 Dominik 'Rathann' Mierzejewski <rpm> 2.1-7 - apply Frederic Hecht's patch for eigenvalue bug - move static libs to separate package
I think this possibly only needs your approved check mark (all your changes were taken verbatim :)
I've checked everything once again and this package is APPROVED. However, please add %{?_smp_mflags} to both make calls in %build. I've tested the build locally on a dual-core CPU and it completed successfully so I see no reason no to use -jN. It still won't build in koji as-is (see bug 349801), but that's not our fault.
*ping* Could you add a workaround (BR: lapack-devel instead of %{_libdir}/liblapack.so) in the meantime and build this?
New Package CVS Request ======================= Package Name: arpack Short Description: Fortran77 subroutines for solving large scale eigenvalue problems Owners: athimm Branches: F-8 InitialCC: Cvsextras Commits: no
Please include the F-7 branch, if it's not too much trouble. I've already created the F-7 branch of freefem++ (which depends on arpack).
Axel: do you want a F-7 branch as well?
(In reply to comment #69) > Axel: do you want a F-7 branch as well? Yes, no problem. I thought there might not be demand for F7, but since there is, let's build it :)
cvs done. Any particular reason for the cvsextras commits: no?
Thanks! > Any particular reason for the cvsextras commits: no? No particular reason as in "arpack specific". I just believe that if someone is interested in comaintaining a package he should first become a comaintainer. Important mass edits and time-critical security fixes happen independent of that setting anyway.
Oh, well, I now hit bug #349801 ... :(
In reply to Comment #72: Sure, but allowing cvsextras would let other people help out on the package in the event you were unavailable or busy. In any event, up to you, just wanted to know the reasoning...
arpack-2.1-7.fc8 has been submitted as an update for Fedora 8
arpack-2.1-7.fc7 has been submitted as an update for Fedora 7
arpack-2.1-7.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
arpack-2.1-7.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
Can you build this for EPEL 5? I'd need it to update Octave to the 3.2 series.
cc athimm Axel: can you build arpack for EPEL 5?
No reply for more than a week, including an email sent to arpack-owner on Jan 9. I can take ownership of the EPEL branch; if you want to maintain it yourself then just give me a ping. Package Change Request ====================== Package Name: arpack New Branches: EL-5 Owners: jussilehtola
CVS done. By the way, you do not have to wait for Axel to respond, since he's already indicated that he doesn't wish to participate in EPEL: http://fedoraproject.org/wiki/EPEL/ContributorStatusNo
Thanks. Oh, I hadn't thought of looking there.