Hi Helmut,
* Helmut Grohne [2024-09-15 20:17]:
On my system, _core.file becomes
"/usr/lib/python3/dist-packages/numpy/_core/__init__.py" Do you
mean numpy.core rather than numpy._core? (Not sure what the
difference is.)
Yeah, that has changed with NumPy 2. Quoting the release notes:
Rename
Hi Timo,
On Sun, Sep 15, 2024 at 04:30:44PM +0200, Timo Röhling wrote:
> * Helmut Grohne [2024-09-09 18:38]:
> > > And it will not solve cross-building for packages which interrogate
> > > numpy.get_include() directly, as SciPy does in its Meson build.
> >
> > But this is not a matter of numpy-c
Hi Helmut,
* Helmut Grohne [2024-09-09 18:38]:
And it will not solve cross-building for packages which
interrogate numpy.get_include() directly, as SciPy does in its
Meson build.
But this is not a matter of numpy-config then. Would you mind
detailing how numpy.get_include() works? Generally
Hi Timo,
On Mon, Sep 09, 2024 at 05:46:41PM +0200, Timo Röhling wrote:
> numpy-config is actually in python3-numpy, not in python3-numpy-dev, so it
> is not MA: same. Without $PKG_CONFIG, it will simply return the
> configuration for python3-numpy's own architecture, which is arguably not
> surpri
Hi Helmut,
* Helmut Grohne [2024-09-09 07:36]:
I vaguely take issue with this approach. It was tried elsewhere and
it is an annoying failure mode. Generally speaking. foo-config
tools should not reside in M-A:same packages. We expect that a
foo-config tool behaves for the architecture of the
Hi Timo et al,
On Sun, Sep 08, 2024 at 11:17:02PM +0200, Timo Röhling wrote:
> The cross build support relies on pkg-config to select the correct host
> architecture via "/usr/lib/ARCH/pkgconfig/numpy.pc", so I patched all
> relevant API entrypoints (numpy-config, numpy.get_include()) to query
> $
Hi,
I'm cc'ing debian-cross for the Multi-Arch related parts below.
* Dima Kogan [2024-09-07 12:59]:
I see the python3-numpy-dev package separates ALL the headers into
/usr/lib/ARCH/. 99% of them are identical across arches though, so
that's overkill, but it just costs our users a bit of extr
I just looked at the python3-numpy = 1:2.1.1+ds-1 currently in
experimental.
Overall it works! Thanks for doing that.
I built these packages for amd64 and arm64 (natively; want to think
about one thing at a time). Then I installed python3-numpy-dev:amd64 and
python3-numpy-dev:arm64 on my amd64 ma
Hi Dima,
* Dima Kogan [2024-08-01 16:47]:
Thinking about this some more, I'm fairly certain that splitting
the package is the correct way to do this because the -dev package
shouldn't require python3 to be installed, which is currently
required by numpy. Installing a foreign-architecture pyth
Hi Dima,
* Dima Kogan [2024-08-06 10:54]:
So numpy 2.0 is coming very soon, right? If so, I'm considering
this done for right now, and I'll propose a new patch when that
comes. If you see anything in the current proposal that you're very
much against, I'd like to know about it.
I just uploade
On Tue, 06 Aug 2024 at 10:54:09 +0700, Dima Kogan wrote:
> The last missing piece that makes Multi-Arch:same not work is the
> Depends:python3. This is due to dh_python3 doing something I don't
> understand:
>
> https://lists.debian.org/debian-python/2024/08/msg00036.html
Please see my reply to
Hi Timo.
I have a mostly-working prototype of a python3-numpy package that is
Multi-Arch:same. Looks like you can ALMOST avoid splitting the package,
so let's see if we can follow that path. The branch (with a single
commit at this time) is here:
https://salsa.debian.org/python-team/packages/n
Hi Timo.
> I'm not opposed to splitting the package per se, but I want to point
> out that long before I became NumPy maintainer, there used to be a
> separate python-numpy-dev package already, and I'd like to find out
> why it was discontinued and if the reason is still relevant before I
> go ah
Hi Dima,
* Dima Kogan [2024-08-01 16:47]:
I THINK this is currently impossible, or at least I can't figure out a
set of Build-Depends that would achive this result. It maybe would be
enough to add a Multi-Arch tag, but it would be clearer to split the dev
stuff (*.h and *.pc) into a separate pa
> I THINK this is currently impossible, or at least I can't figure out a
> set of Build-Depends that would achive this result. It maybe would be
> enough to add a Multi-Arch tag, but it would be clearer to split the dev
> stuff (*.h and *.pc) into a separate package, and that package should be
> Mu
Package: python3-numpy
Version: 1:1.26.4+ds-6
Severity: normal
Hello. Currently the python3-numpy package serves at least two
independent purposes:
- To make it possible to run numpy Python code
- To support building extension modules using the C numpy API
It should be possible to install the f
16 matches
Mail list logo
