Re: scipy packaging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ondrej Certik ha scritto: > On Mon, Jul 7, 2008 at 6:34 PM, Pietro Battiston <[EMAIL PROTECTED]> > wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> Hello, a package I maintain, gvb, has just entered sid, and I >> noticed that unfortunately I erroneously set "Priority: optional" >> (it is wrong because it depends on python-scipy which has >> "Priority: extra"). >> >> I was already fixing this, but first I was curious on why scipy >> had "extra". I noticed it Conflicts: with the following packages: >> >> >> python-scipy-core, python2.3-scipy, python2.3-scipy-core, >> python2.4-scipy, python2.4-scipy-core >> >> actually, those seem to me all obsolete or only used in kfreebsd >> architecture... in other words, it seems to me better to set >> "Priority: extra" in those and "Priority: optional" in main >> python-scipy package. >> >> Please forgive me if I'm missing something, those are my first >> steps as Debian maintainer... > > Thanks for asking these questions. Even though I try to keep > python-scipy in shape, I don't know the answers. To me personally > it doesn't really matter, if it's extra, or optional. But if you > need something fixed in python-scipy and you get a consensus on > that, I'll fix it, or help you fix it. > > Ondrej Actually, a further look showed that all the packages in "Conflict:" (do not exists in unstable/testing, and...) also have "Priority: extra", so those conflicts are not themselves the reason of the "extra" priority... they are maybe a hint (python-scipy has probably "inherited" this), but I still don't get the original reason. Anyway, if it's not so important, I will wait a couple of days for some more info and then switch my package to "extra" and stop bothering. thanks Pietro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIcoOJcZVtR82bmAYRAvqGAJ9VwCEHxBpXIbFTv90ltGubtgdE8QCdEKLN VsrhrEp9GeZI9dZrBj77Nyw= =hepX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: scipy packaging
On Mon, Jul 7, 2008 at 6:34 PM, Pietro Battiston <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > a package I maintain, gvb, has just entered sid, and I noticed that > unfortunately I erroneously set "Priority: optional" (it is wrong > because it depends on python-scipy which has "Priority: extra"). > > I was already fixing this, but first I was curious on why scipy had > "extra". I noticed it Conflicts: with the following packages: > > python-scipy-core, python2.3-scipy, python2.3-scipy-core, > python2.4-scipy, python2.4-scipy-core > > actually, those seem to me all obsolete or only used in kfreebsd > architecture... in other words, it seems to me better to set > "Priority: extra" in those and "Priority: optional" in main > python-scipy package. > > Please forgive me if I'm missing something, those are my first steps > as Debian maintainer... Thanks for asking these questions. Even though I try to keep python-scipy in shape, I don't know the answers. To me personally it doesn't really matter, if it's extra, or optional. But if you need something fixed in python-scipy and you get a consensus on that, I'll fix it, or help you fix it. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
scipy packaging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, a package I maintain, gvb, has just entered sid, and I noticed that unfortunately I erroneously set "Priority: optional" (it is wrong because it depends on python-scipy which has "Priority: extra"). I was already fixing this, but first I was curious on why scipy had "extra". I noticed it Conflicts: with the following packages: python-scipy-core, python2.3-scipy, python2.3-scipy-core, python2.4-scipy, python2.4-scipy-core actually, those seem to me all obsolete or only used in kfreebsd architecture... in other words, it seems to me better to set "Priority: extra" in those and "Priority: optional" in main python-scipy package. Please forgive me if I'm missing something, those are my first steps as Debian maintainer... Pietro Battiston -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIckWccZVtR82bmAYRAu2JAJ4rhr0OwrO/bY5PI0g4cBtlKdpVPACfdCfl xpIYdKLd0Yovd1+ElG6llDo= =U3SJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian: numpy not building _dotblas.so
Hi, we have this problem in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489726 The problem is that numpy should not depend on atlas unconditionally, yet it should allow it for users that have it. I am not an expert in blas/lapack/atlas and it's Debian packaging much (I know some people say that atlas packaging in Debian is not very good, actually pretty bad), so I am just forwarding the question here. The problem is with this patch: http://projects.scipy.org/scipy/numpy/changeset/3854 and the question that we have is: I'd like to know, if the code was changed to only work with atlas, or if was never working. if it's the latter, then we should use atlas Matthias, Tiziano, feel free to clarify this more. See the above Debian bug for more information and background. Thanks, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: should numpy be built with atlas?
On Mon, Jul 7, 2008 at 2:12 PM, Matthias Klose <[EMAIL PROTECTED]> wrote: > Package: python-numpy > Version: 1:1.1.0-2 > Severity: serious > > python-numpy now has an unconditional dependency on libatlas3gf-base, > needing the "specialized" atlas libraries as a runtime > dependency. Users still should have the option to use the standard > blas and lapack libs instead of the untested/unmaintained atlas > libraries in debian. The problem is that the new (>1.0) numpy building system needs ATLAS at compile time to enable fast matrix-multiplication. If ATLAS is not found at compile time, numpy.core._dotblas.so is not built and slow matrix multiplication is used even if the end user has ATLAS installed. In the old numpy _dotblas.so was always compiled using refblas and the end user would still have had the option of using ATLAS. I'm not sure I understand why ATLAS is now needed at compile time, but look here: http://scipy.org/scipy/numpy/ticket/667 and here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464784 I think python-numpy should stay as it is now and a bug-wishlist should be reported to the atlas package to encourage packaging of the new stable version (3.8.2). Filing a ticket on numpy trac may help, but the fate of ticket 667 seems to indicate that there's no will of fixing this bug upstream... thank you, tiziano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: should numpy be built with atlas?
Ondrej Certik writes: > On Mon, Jul 7, 2008 at 2:12 PM, Matthias Klose <[EMAIL PROTECTED]> wrote: > > Package: python-numpy > > Version: 1:1.1.0-2 > > Severity: serious > > > > python-numpy now has an unconditional dependency on libatlas3gf-base, > > needing the "specialized" atlas libraries as a runtime > > dependency. Users still should have the option to use the standard > > blas and lapack libs instead of the untested/unmaintained atlas > > libraries in debian. > > Hi Matthias, > > I changed that on a request from a user: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489253 > > so should we revert this change? I.e. should numpy not be built with > atlas support? This will make it quite slow in Debian. > > CCing to debian python as well to get more opinions on this. afaiu this has nothing to do if blas/lapack or atlas are used; apparently _dotblas.so is not built when just using blas/lapack. this seems to be the real bug which we should fix. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
should numpy be built with atlas?
On Mon, Jul 7, 2008 at 2:12 PM, Matthias Klose <[EMAIL PROTECTED]> wrote: > Package: python-numpy > Version: 1:1.1.0-2 > Severity: serious > > python-numpy now has an unconditional dependency on libatlas3gf-base, > needing the "specialized" atlas libraries as a runtime > dependency. Users still should have the option to use the standard > blas and lapack libs instead of the untested/unmaintained atlas > libraries in debian. Hi Matthias, I changed that on a request from a user: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489253 so should we revert this change? I.e. should numpy not be built with atlas support? This will make it quite slow in Debian. CCing to debian python as well to get more opinions on this. Thanks, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
