Bug 214967 - Review Request: arpack - Fortran77 subroutines for solving large scale eigenvalue problems
Review Request: arpack - Fortran77 subroutines for solving large scale eigenv...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dominik 'Rathann' Mierzejewski
Fedora Package Reviews List
:
: 216916 (view as bug list)
Depends On: 258041 349801
Blocks: 233975
  Show dependency treegraph
 
Reported: 2006-11-10 06:15 EST by Axel Thimm
Modified: 2010-01-19 14:50 EST (History)
9 users (show)

See Also:
Fixed In Version: 2.1-7.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-18 22:14:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
dominik: fedora‑review+
tibbs: fedora‑cvs+


Attachments (Terms of Use)
Fix undefined-non-weak-symbols rpmlint warning and add license text to the package. (1.34 KB, patch)
2006-11-22 17:26 EST, Dominik 'Rathann' Mierzejewski
no flags Details | Diff
Clarification of ARPACK license by author (4.01 KB, message/rfc822)
2007-02-15 07:54 EST, David Bateman
no flags Details
patch to remove static libs and fix function name clash (2.55 KB, patch)
2007-06-29 14:10 EDT, Dominik 'Rathann' Mierzejewski
no flags Details | Diff
specfile patch to fix function name clash (2.33 KB, patch)
2007-10-23 20:57 EDT, Dominik 'Rathann' Mierzejewski
no flags Details | Diff
source patch to fix function name clash (53.56 KB, patch)
2007-10-23 20:58 EDT, Dominik 'Rathann' Mierzejewski
no flags Details | Diff

  None (edit)
Description Axel Thimm 2006-11-10 06:15:22 EST
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).
Comment 1 Patrice Dumas 2006-11-10 06:30:47 EST
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.
Comment 2 Rex Dieter 2006-11-10 09:20:34 EST
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.
Comment 3 Quentin Spencer 2006-11-10 09:55:11 EST
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.
Comment 4 Patrice Dumas 2006-11-10 10:04:06 EST
(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?
Comment 5 Axel Thimm 2006-11-10 10:41:51 EST
(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!
Comment 6 Orion Poplawski 2006-11-16 15:21:33 EST
Changing blocker to FE-REVIEW since it seems to be under review.
Comment 7 Dominik 'Rathann' Mierzejewski 2006-11-16 21:22:50 EST
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.
Comment 8 Quentin Spencer 2006-11-16 21:51:20 EST
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.
Comment 9 Dominik 'Rathann' Mierzejewski 2006-11-22 17:24:42 EST
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.
Comment 10 Dominik 'Rathann' Mierzejewski 2006-11-22 17:26:24 EST
Created attachment 141957 [details]
Fix undefined-non-weak-symbols rpmlint warning and add license text to the package.
Comment 11 Dominik 'Rathann' Mierzejewski 2006-11-22 17:27:54 EST
*** Bug 216916 has been marked as a duplicate of this bug. ***
Comment 12 Axel Thimm 2006-11-22 18:59:38 EST
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).
Comment 13 Dominik 'Rathann' Mierzejewski 2006-11-22 19:14:09 EST
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...
Comment 14 David Bateman 2007-02-15 07:54:56 EST
Created attachment 148107 [details]
Clarification of ARPACK license by author
Comment 15 David Bateman 2007-02-15 07:57:37 EST
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
Comment 16 Axel Thimm 2007-02-15 09:47:55 EST
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.
Comment 17 David Bateman 2007-03-04 16:58:57 EST
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.
Comment 18 Tom "spot" Callaway 2007-03-26 11:07:31 EDT
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
Comment 19 David Bateman 2007-03-27 06:07:34 EDT
Hi Tom,

This is great news. I hope Axel or Quentin are now able to package ARPACK for
Extras..

Cheers
David
Comment 20 Quentin Spencer 2007-03-27 09:46:58 EDT
(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.
Comment 21 Tom "spot" Callaway 2007-03-27 10:05:09 EDT
(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.
Comment 22 Quentin Spencer 2007-03-27 11:44:36 EDT
(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.
Comment 23 Tom "spot" Callaway 2007-03-27 11:47:52 EDT
Opened a license request with the FSF. Putting this back on FE-Legal.
Comment 24 Axel Thimm 2007-03-27 13:07:39 EDT
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!

Comment 25 Axel Thimm 2007-03-27 13:15:26 EDT
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.
Comment 26 Dominik 'Rathann' Mierzejewski 2007-03-27 13:48:49 EDT
(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".
Comment 27 Michał Bentkowski 2007-04-27 11:39:25 EDT
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.
Comment 28 Michał Bentkowski 2007-04-27 11:51:15 EDT
To be precise, this happens because instead of lapack-devel, mock installs 
atlas-devel.
Comment 29 Axel Thimm 2007-04-27 12:43:02 EDT
How does it break? Maybe it is an atlas <-> lapack generic issue?
Comment 30 Michał Bentkowski 2007-04-28 06:38:27 EDT
(In reply to comment #29)
> How does it break? Maybe it is an atlas <-> lapack generic issue?
> 
Yes, it is.

Comment 31 Axel Thimm 2007-04-28 07:33:11 EDT
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!
Comment 32 Michał Bentkowski 2007-04-28 16:12:14 EDT
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?
Comment 33 Dominik 'Rathann' Mierzejewski 2007-04-28 16:13:57 EDT
Axel, why don't you keep BuildRequires: lapack-devel and just change it in RHEL
branch of the specfile?
Comment 34 Axel Thimm 2007-04-28 21:58:08 EDT
> 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.
Comment 35 Dominik 'Rathann' Mierzejewski 2007-05-18 13:06:13 EDT
Any progress? I have a new package depending on this.
Comment 36 Axel Thimm 2007-05-18 13:22:22 EDT
rathann, could you fix the liblapack.so conflict between lapack and atlas?
Comment 37 Dominik 'Rathann' Mierzejewski 2007-05-18 13:48:11 EDT
There's no conflict. atlas' lapack is in a different directory
(%{_libdir}/atlas/ IIRC).
Comment 38 Axel Thimm 2007-05-23 07:41:35 EDT
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?
Comment 39 Quentin Spencer 2007-05-23 21:46:32 EDT
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.
Comment 40 Axel Thimm 2007-05-24 04:08:32 EDT
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
Comment 41 Axel Thimm 2007-06-10 17:12:32 EDT
Anyone up to a a review?
Comment 42 Dominik 'Rathann' Mierzejewski 2007-06-12 17:36:07 EDT
I'm a bit busy these days, but I'll try to find some time during the weekend to
do this.
Comment 43 Dominik 'Rathann' Mierzejewski 2007-06-29 13:40:32 EDT
I'll review this now.
Comment 44 Dominik 'Rathann' Mierzejewski 2007-06-29 14:07:51 EDT
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.
Comment 45 Dominik 'Rathann' Mierzejewski 2007-06-29 14:10:58 EDT
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.
Comment 46 Dominik 'Rathann' Mierzejewski 2007-06-29 14:40:18 EDT
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.
Comment 47 Axel Thimm 2007-06-29 15:43:25 EDT
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.
Comment 48 Axel Thimm 2007-06-29 15:54:23 EDT
(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).
Comment 49 Dominik 'Rathann' Mierzejewski 2007-06-29 16:07:40 EDT
(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.
Comment 50 Dominik 'Rathann' Mierzejewski 2007-06-29 16:13:46 EDT
(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.
Comment 51 Axel Thimm 2007-06-29 16:29:58 EDT
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)
Comment 52 Axel Thimm 2007-06-29 16:53:10 EDT
(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.
Comment 53 Patrice Dumas 2007-06-29 17:31:57 EDT
(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
Comment 54 Dominik 'Rathann' Mierzejewski 2007-07-06 08:41:53 EDT
(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?
Comment 55 Dominik 'Rathann' Mierzejewski 2007-08-27 13:03:58 EDT
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.
Comment 56 Dominik 'Rathann' Mierzejewski 2007-08-27 13:38:01 EDT
(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
Comment 57 Axel Thimm 2007-08-27 17:09:24 EDT
(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.
Comment 58 Dominik 'Rathann' Mierzejewski 2007-10-23 20:57:47 EDT
Created attachment 235721 [details]
specfile patch to fix function name clash
Comment 59 Dominik 'Rathann' Mierzejewski 2007-10-23 20:58:22 EDT
Created attachment 235731 [details]
source patch to fix function name clash
Comment 60 Dominik 'Rathann' Mierzejewski 2007-10-23 20:59:12 EDT
(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.
Comment 61 Dominik 'Rathann' Mierzejewski 2007-10-23 21:24:56 EDT
Filed bug 349801 against mock.
Comment 62 Axel Thimm 2007-10-24 07:57:34 EDT
Thanks a lot, taken as is. Will still post new URLs for spec/src.rpm to be
formally correct.
Comment 63 Axel Thimm 2007-10-26 02:16:45 EDT
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@greysector.net> 2.1-7
- apply Frederic Hecht's patch for eigenvalue bug
- move static libs to separate package
Comment 64 Axel Thimm 2007-12-30 05:07:56 EST
I think this possibly only needs your approved check mark (all your changes were
taken verbatim :)
Comment 65 Dominik 'Rathann' Mierzejewski 2007-12-30 08:32:06 EST
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.
Comment 66 Dominik 'Rathann' Mierzejewski 2008-01-17 06:27:23 EST
*ping*

Could you add a workaround (BR: lapack-devel instead of %{_libdir}/liblapack.so)
in the meantime and build this?

Comment 67 Axel Thimm 2008-01-20 03:09:47 EST
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
Comment 68 Dominik 'Rathann' Mierzejewski 2008-01-20 05:42:08 EST
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).
Comment 69 Kevin Fenzi 2008-01-21 11:53:11 EST
Axel: do you want a F-7 branch as well? 
Comment 70 Axel Thimm 2008-01-25 15:34:46 EST
(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 :)
Comment 71 Kevin Fenzi 2008-01-25 15:48:20 EST
cvs done. 

Any particular reason for the cvsextras commits: no? 
Comment 72 Axel Thimm 2008-01-26 02:08:28 EST
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.
Comment 73 Axel Thimm 2008-01-26 03:05:44 EST
Oh, well, I now hit bug #349801 ... :(
Comment 74 Kevin Fenzi 2008-01-26 13:31:53 EST
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... 
Comment 75 Fedora Update System 2008-02-16 16:48:54 EST
arpack-2.1-7.fc8 has been submitted as an update for Fedora 8
Comment 76 Fedora Update System 2008-02-16 16:48:58 EST
arpack-2.1-7.fc7 has been submitted as an update for Fedora 7
Comment 77 Fedora Update System 2008-02-18 22:14:24 EST
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.
Comment 78 Fedora Update System 2008-02-18 22:17:00 EST
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.
Comment 79 Susi Lehtola 2010-01-06 05:44:43 EST
Can you build this for EPEL 5? I'd need it to update Octave to the 3.2 series.
Comment 80 Susi Lehtola 2010-01-09 06:43:07 EST
cc athimm

Axel: can you build arpack for EPEL 5?
Comment 81 Susi Lehtola 2010-01-17 06:31:52 EST
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
Comment 82 Jason Tibbitts 2010-01-19 14:32:58 EST
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
Comment 83 Susi Lehtola 2010-01-19 14:50:06 EST
Thanks. Oh, I hadn't thought of looking there.

Note You need to log in before you can comment on or make changes to this bug.