Re: please test the numpy package
Hi Piotr, Kumar and Matthias,
thanks for all the replies, I'll reply one by one:
On Sun, Jan 25, 2009 at 1:39 AM, Piotr Ożarowski <piotr@debian.org> wrote:
> [Ondrej Certik, 2009-01-25]
>> There is a problem with documentation, that it depends on sphinx-0.5,
>> which is currently only in experimental. And also upstream doesn't
>> have it in the tarball. I originally fixed that by
>> adding a new target into debian/rules, that downloaded the upstream
>> tgz, unpacked, eported the doc/ directory from upstream svn and then
>> packaged it again. But since it still doesn't build in pure sid, I
>> rather fixed the build with the current upstream tarball.
>
> python-numpy has many reverse dependencies[1] - how about uploading it
> to experimental for now? This way you'll have Sphinx 0.5.x available.
I really want it in unstable. It's because the new scipy won't build
without this upload etc. and many people are just waiting for it. It's
a legitimate question though, but so far I understood that this is
what unstable is for. Otherwise people will have to move from unstable
to experimental to get the latest packages. Is this what we want? I
prefer it in unstable, but I am open to other opinions.
>
> If you really want to upload it to unstable, build the docs using Sphinx
> from experimental and include them in the upstream source tarball for
> now (add ".ds" to upstream version, get-orig-source rule and a
> README.Debian-source file in the new tarball explaining that you've
> added the docs and how to regenerate it[2])
I can do that, but imho it's quite an ugly solution. I talked with
upstream about that, and the have never shipped the sphinx doc with
the upstream tarball (yet). They will do so from the next release, but
so far I think the best solution is to just keep what they have and
package it. The current python-numpy-doc is not very good either. So
in my current packaging I just copied what was in numpy/doc/* in
there.
On Sun, Jan 25, 2009 at 7:03 AM, Kumar Appaiah
<a.kumar@alumni.iitm.ac.in> wrote:
> On Sun, Jan 25, 2009 at 12:53:05AM -0800, Ondrej Certik wrote:
> Thanks Ondrej, and sorry for not helping out with this earlier.
>
> I built the package and tested it, and it seems fine; I ran some of my
> matplotlib+SciPy examples, and they seemed to run all
> right. numpy.test() also seemed OK.
Thanks.
>
> I guess this can be uploaded to experimental with the new Sphinx
> documentation, as Piotr says.
I would prefer to upload it to unstable. Matthias, Piotr --- do you
think it is a bad idea with regards to the release of Lenny?
On Sun, Jan 25, 2009 at 7:42 AM, Matthias Klose <doko@debian.org> wrote:
> Ondrej Certik schrieb:
>> Hi,
>>
>> I finally packaged the newest uptream and committed all fixes into our
>> svn repo for numpy. Kumar (or others), do you think you could please
>> test the package?
>
> numpy becomes big. see https://launchpad.net/bugs/309215. In the past the parts
> depending on external numeric libraries were splitted out into a separate
> package, but the package structure now makes it difficult to keep this split.
Yes.
> Please consider splitting out a python-multiarray (seems to be straightforward,
> maybe keep it in its own name space) or a python-numpy-core/-base package
> (unsure where to make the split).
Could you please elaborate how to split it? Looking at the only
multiarray.so files in the binary package:
ondra@august:~$ ll -h /usr/lib/python2.5/site-packages/numpy/core/multiarray.so
-rw-r--r-- 1 root root 516K 2009-01-25 09:43
/usr/lib/python2.5/site-packages/numpy/core/multiarray.so
ondra@august:~$ ll -h /usr/lib/python2.4/site-packages/numpy/core/multiarray.so
-rw-r--r-- 1 root root 508K 2009-01-25 09:43
/usr/lib/python2.4/site-packages/numpy/core/multiarray.so
It only adds 1MB to the total size. Do we really have to care about
1MB? Or is there something I don't see.
Also if we need to split it, I would very much prefer not to mess up
with the namespace, because otherwise people will have to fix their
codes to work on Debian, as opposed to when they build numpy
themselves. Also I'd like to consult this with upstream first, once I
understand what you suggest to split.
>> There is a problem with documentation, that it depends on sphinx-0.5,
>> which is currently only in experimental. And also upstream doesn't
>> have it in the tarball. I originally fixed that by
>> adding a new target into debian/rules, that downloaded the upstream
>> tgz, unpacked, eported the doc/ directory from upstream svn and then
>> packaged it again. But since it still doesn't build in pure sid, I
>> rather fixed the build with the current upstream tarball.
>
> As long as you can fulfill the dependencies with build dependencies all should
> be ok. However python itself now uses sphinx from the sphinx trunk. very nice :-/
Yeah, see above. I suggest to use sphinx when upstream ships it with
the tarball.
Ondrej
Reply to: