Looks like ufsparse has been replaced by suitesparse and ufsparse needs to get pulled from the devel repository.
On Thursday, 16 August 2007 at 20:21, Orion Poplawski wrote:
Looks like ufsparse has been replaced by suitesparse and ufsparse needs to get pulled from the devel repository.
Does the soname change? Does the new package provide ufsparse(-devel)?
Regards, R.
On Thursday, 16 August 2007 at 20:21, Orion Poplawski wrote:
Looks like ufsparse has been replaced by suitesparse and ufsparse needs to get pulled from the devel repository.
Does the soname change? Does the new package provide ufsparse(-devel)?
Not sure about the soname - but I don't think it does. suitespare provides and obsoletes ufsparse. I noticed it because ufsparse gets installed on new installs, but is then replaced with suitesparse on first yum update.
On Thursday, 16 August 2007 at 22:22, orion@cora.nwra.com wrote:
On Thursday, 16 August 2007 at 20:21, Orion Poplawski wrote:
Looks like ufsparse has been replaced by suitesparse and ufsparse needs to get pulled from the devel repository.
Does the soname change? Does the new package provide ufsparse(-devel)?
Not sure about the soname - but I don't think it does. suitespare provides and obsoletes ufsparse. I noticed it because ufsparse gets installed on new installs, but is then replaced with suitesparse on first yum update.
So starting with devel/f8 I should use BuildRequires: suiteparse-devel, right? Or will there be an update for f7 as well?
Regards, R.
Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 16 August 2007 at 22:22, orion@cora.nwra.com wrote:
On Thursday, 16 August 2007 at 20:21, Orion Poplawski wrote:
Looks like ufsparse has been replaced by suitesparse and ufsparse needs to get pulled from the devel repository.
Does the soname change? Does the new package provide ufsparse(-devel)?
Not sure about the soname - but I don't think it does. suitespare provides and obsoletes ufsparse. I noticed it because ufsparse gets installed on new installs, but is then replaced with suitesparse on first yum update.
So starting with devel/f8 I should use BuildRequires: suiteparse-devel, right? Or will there be an update for f7 as well?
Yes, that's right. I assumed that octave was the only thing depending on suitesparse (sorry, I should have checked), so I never said anything. There is a soname change. I had thought about updating f7, but I have other priorities (drastic changes to octave-forge to work out), so I probably won't.
Quentin
On Friday, 17 August 2007 at 02:58, Quentin Spencer wrote:
Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 16 August 2007 at 22:22, orion@cora.nwra.com wrote:
On Thursday, 16 August 2007 at 20:21, Orion Poplawski wrote:
Looks like ufsparse has been replaced by suitesparse and ufsparse needs to get pulled from the devel repository.
Does the soname change? Does the new package provide ufsparse(-devel)?
Not sure about the soname - but I don't think it does. suitespare provides and obsoletes ufsparse. I noticed it because ufsparse gets installed on new installs, but is then replaced with suitesparse on first yum update.
So starting with devel/f8 I should use BuildRequires: suiteparse-devel, right? Or will there be an update for f7 as well?
Yes, that's right. I assumed that octave was the only thing depending on suitesparse (sorry, I should have checked), so I never said anything. There is a soname change. I had thought about updating f7, but I have other priorities (drastic changes to octave-forge to work out), so I probably won't.
freefem++ is one other thing depending on ufsparse, but it's not in CVS yet, awaiting arpack to pass review (Axel, are you alive there?).
Thanks for the heads-up.
Regards, R.
On Fri, Aug 17, 2007 at 10:31:36AM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Friday, 17 August 2007 at 02:58, Quentin Spencer wrote:
Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 16 August 2007 at 22:22, orion@cora.nwra.com wrote:
On Thursday, 16 August 2007 at 20:21, Orion Poplawski wrote:
Looks like ufsparse has been replaced by suitesparse and ufsparse needs to get pulled from the devel repository.
Does the soname change? Does the new package provide ufsparse(-devel)?
Not sure about the soname - but I don't think it does. suitespare provides and obsoletes ufsparse. I noticed it because ufsparse gets installed on new installs, but is then replaced with suitesparse on first yum update.
So starting with devel/f8 I should use BuildRequires: suiteparse-devel, right? Or will there be an update for f7 as well?
Yes, that's right. I assumed that octave was the only thing depending on suitesparse (sorry, I should have checked), so I never said anything. There is a soname change. I had thought about updating f7, but I have other priorities (drastic changes to octave-forge to work out), so I probably won't.
freefem++ is one other thing depending on ufsparse, but it's not in CVS yet, awaiting arpack to pass review (Axel, are you alive there?).
Sure, I'm waiting for the lapack <-> atlas issue to be resolved.
On Friday, 17 August 2007 at 12:13, Axel Thimm wrote:
On Fri, Aug 17, 2007 at 10:31:36AM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Friday, 17 August 2007 at 02:58, Quentin Spencer wrote:
Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 16 August 2007 at 22:22, orion@cora.nwra.com wrote:
On Thursday, 16 August 2007 at 20:21, Orion Poplawski wrote:
>Looks like ufsparse has been replaced by suitesparse and ufsparse needs >to get pulled from the devel repository. > Does the soname change? Does the new package provide ufsparse(-devel)?
Not sure about the soname - but I don't think it does. suitespare provides and obsoletes ufsparse. I noticed it because ufsparse gets installed on new installs, but is then replaced with suitesparse on first yum update.
So starting with devel/f8 I should use BuildRequires: suiteparse-devel, right? Or will there be an update for f7 as well?
Yes, that's right. I assumed that octave was the only thing depending on suitesparse (sorry, I should have checked), so I never said anything. There is a soname change. I had thought about updating f7, but I have other priorities (drastic changes to octave-forge to work out), so I probably won't.
freefem++ is one other thing depending on ufsparse, but it's not in CVS yet, awaiting arpack to pass review (Axel, are you alive there?).
Sure, I'm waiting for the lapack <-> atlas issue to be resolved.
Why haven't you filed a bug? You can't expect the problem to resolve by itself.
IMHO that problem is NOT a blocker. A workaround is easy enough. Please do it like I suggested in the review comment (i.e. BR: lapack for EPEL and BR: lapack-devel for the rest) for now.
Regards, R.
On Fri, Aug 17, 2007 at 05:48:57PM +0200, Dominik 'Rathann' Mierzejewski wrote:
freefem++ is one other thing depending on ufsparse, but it's not in CVS yet, awaiting arpack to pass review (Axel, are you alive there?).
Sure, I'm waiting for the lapack <-> atlas issue to be resolved.
Why haven't you filed a bug? You can't expect the problem to resolve by itself.
Well, I think I saw that this was your package and since we were discussing this in the review I thought you were aware of it. I'm also not sure whether this is really an issue, it was reported as such by a reviewer (yum picking the smallest name for fulfilling a dependency or something along the lines which makes atlas win over lapack).
At any rate the claim was that atlas(-devel?) provides equivalent files like lapack but is still not working as a replacement. I haven't checked whether this claim is true, this is something for lapack/atlas experts to digest :)
On Friday, 17 August 2007 at 18:35, Axel Thimm wrote:
On Fri, Aug 17, 2007 at 05:48:57PM +0200, Dominik 'Rathann' Mierzejewski wrote:
freefem++ is one other thing depending on ufsparse, but it's not in CVS yet, awaiting arpack to pass review (Axel, are you alive there?).
Sure, I'm waiting for the lapack <-> atlas issue to be resolved.
Why haven't you filed a bug? You can't expect the problem to resolve by itself.
Well, I think I saw that this was your package and since we were discussing this in the review I thought you were aware of it. I'm also not sure whether this is really an issue, it was reported as such by a reviewer (yum picking the smallest name for fulfilling a dependency or something along the lines which makes atlas win over lapack).
To make things clear, because you seem a bit confused: arpack is your package and I am the reviewer.
At any rate the claim was that atlas(-devel?) provides equivalent files like lapack but is still not working as a replacement. I haven't checked whether this claim is true, this is something for lapack/atlas experts to digest :)
It was. I only tested it as much as to confirm that yum install atlas ; rpm -e lapack blas doesn't prevent apps linked against these from running.
Regards, R.
On Fri, Aug 17, 2007 at 06:41:39PM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Friday, 17 August 2007 at 18:35, Axel Thimm wrote:
On Fri, Aug 17, 2007 at 05:48:57PM +0200, Dominik 'Rathann' Mierzejewski wrote:
freefem++ is one other thing depending on ufsparse, but it's not in CVS yet, awaiting arpack to pass review (Axel, are you alive there?).
Sure, I'm waiting for the lapack <-> atlas issue to be resolved.
Why haven't you filed a bug? You can't expect the problem to resolve by itself.
Well, I think I saw that this was your package and since we were discussing this in the review I thought you were aware of it. I'm also not sure whether this is really an issue, it was reported as such by a reviewer (yum picking the smallest name for fulfilling a dependency or something along the lines which makes atlas win over lapack).
To make things clear, because you seem a bit confused: arpack is your package and I am the reviewer.
well, I'm referring to reviewer before you picked it up, Michał Bentkowski, who claimed that atlas broke arpack. But looking at the bugzilla again he never wrote how and why, so maybe it's a Red Herring?
At any rate the claim was that atlas(-devel?) provides equivalent files like lapack but is still not working as a replacement. I haven't checked whether this claim is true, this is something for lapack/atlas experts to digest :)
It was. I only tested it as much as to confirm that yum install atlas ; rpm -e lapack blas doesn't prevent apps linked against these from running.
I digged out that bugzilla and found the following mysterious issue with atlas-devel (not?) containing liblapack.so
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214967#c51 | 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)