On Mon, Jul 25, 2022 at 12:41:16AM +0500, Andrey Rahmatullin wrote:
> On Sun, Jul 24, 2022 at 08:30:42PM +0100, Julian Gilbey wrote:
> [...]
> > > > are they all effectively Multi-Arch: no? Is this worth thinking about
> > > > in the longer term?
> > > What do you propose?
> >
> > I think the fix
On Sun, Jul 24, 2022 at 08:30:42PM +0100, Julian Gilbey wrote:
> On Sun, Jul 24, 2022 at 11:41:56PM +0500, Andrey Rahmatullin wrote:
> > [...]
> > >
> > > I got all of the triplets working, but was then stymied when I tried
> > > to specify Multi-Arch: same in the control file. I got a lintian
>
On Sun, Jul 24, 2022 at 11:41:56PM +0500, Andrey Rahmatullin wrote:
> [...]
> >
> > I got all of the triplets working, but was then stymied when I tried
> > to specify Multi-Arch: same in the control file. I got a lintian
> > warning: multi-arch-same-package-calls-pycompile
> > It seems that sinc
On Sun, Jul 24, 2022 at 11:46:14PM +0500, Andrey Rahmatullin wrote:
> On Sun, Jul 24, 2022 at 06:36:57PM +0100, Julian Gilbey wrote:
> > I got all of the triplets working, but was then stymied when I tried
> > to specify Multi-Arch: same in the control file. I got a lintian
> > warning: multi-arch
On Sun, Jul 24, 2022 at 06:36:57PM +0100, Julian Gilbey wrote:
> I got all of the triplets working, but was then stymied when I tried
> to specify Multi-Arch: same in the control file. I got a lintian
> warning: multi-arch-same-package-calls-pycompile
> It seems that since the pybuild system (via
On Sun, Jul 24, 2022 at 06:36:57PM +0100, Julian Gilbey wrote:
> > > > > I'd like to ask for some help. I'm working on packaging pydevd, which
> > > > > builds a private .so library. Ordinary extensions built using cython
> > > > > or similar end up being called "foo.cpython-310-x86_64-linux-gnu.
Well, here's an update on this old thread...
On Thu, Jun 09, 2022 at 01:03:25PM +0500, Andrey Rahmatullin wrote:
> On Thu, Jun 09, 2022 at 08:42:28AM +0100, Julian Gilbey wrote:
> > > > I'd like to ask for some help. I'm working on packaging pydevd, which
> > > > builds a private .so library. Or
On Thu, Jun 09, 2022 at 03:00:24PM +0500, Andrey Rahmatullin wrote:
> > The build system here is the standard Python setup.py, except for this
> > library. That is built by the following script:
> >
> > ---
> > g++ -m64 -shared -o attach_linux_amd64.so -fPIC -nostartfiles attach.cpp
> > mv attach
On Thu, Jun 09, 2022 at 11:00:28AM +0100, Simon McVittie wrote:
> On Thu, 09 Jun 2022 at 09:56:42 +0100, Julian Gilbey wrote:
> > OK (and yes, it does require the full path at runtime). What triplet
> > do I use in d/rules? dpkg-architecture offers 6 different ones:
> > DEB_{BUILD,HOST,TARGET}_{G
On Thu, 09 Jun 2022 at 09:56:42 +0100, Julian Gilbey wrote:
> OK (and yes, it does require the full path at runtime). What triplet
> do I use in d/rules? dpkg-architecture offers 6 different ones:
> DEB_{BUILD,HOST,TARGET}_{GNU_TYPE,MULTIARCH}? I'm guessing
> DEB_TARGET_MULTIARCH, but I'm really
On Thu, Jun 09, 2022 at 10:43:01AM +0100, Julian Gilbey wrote:
> > > The normal way for this is putting it into
> > > /usr/lib//pkgname/foo.so, and according to the code below you'll
> > > need the full path at the run time so you indeed need the triplet at both
> > > build and run time.
> >
> > Y
On Thu, Jun 09, 2022 at 09:56:42AM +0100, Julian Gilbey wrote:
> > [...]
> > > Well, the upstream wanted to compile two versions of the library, one
> > > for 64 bit architectures and one for 32 bit architectures. I don't
> > > really want to build two different arch libraries in a single build,
>
On Thu, Jun 09, 2022 at 10:26:13AM +0100, Simon McVittie wrote:
> On Thu, 09 Jun 2022 at 13:03:25 +0500, Andrey Rahmatullin wrote:
> > The normal way for this is putting it into
> > /usr/lib//pkgname/foo.so, and according to the code below you'll
> > need the full path at the run time so you indeed
On Thu, 09 Jun 2022 at 13:03:25 +0500, Andrey Rahmatullin wrote:
> The normal way for this is putting it into
> /usr/lib//pkgname/foo.so, and according to the code below you'll
> need the full path at the run time so you indeed need the triplet at both
> build and run time.
You can do something li
On Thu, Jun 09, 2022 at 01:03:25PM +0500, Andrey Rahmatullin wrote:
> [...]
> > Well, the upstream wanted to compile two versions of the library, one
> > for 64 bit architectures and one for 32 bit architectures. I don't
> > really want to build two different arch libraries in a single build,
> >
On Thu, Jun 09, 2022 at 08:42:28AM +0100, Julian Gilbey wrote:
> > > I'd like to ask for some help. I'm working on packaging pydevd, which
> > > builds a private .so library. Ordinary extensions built using cython
> > > or similar end up being called "foo.cpython-310-x86_64-linux-gnu.so",
> > > b
On Thu, Jun 09, 2022 at 11:23:26AM +0500, Andrey Rahmatullin wrote:
> On Wed, Jun 08, 2022 at 10:43:57PM +0100, Julian Gilbey wrote:
> > I'd like to ask for some help. I'm working on packaging pydevd, which
> > builds a private .so library. Ordinary extensions built using cython
> > or similar en
On Wed, Jun 08, 2022 at 10:43:57PM +0100, Julian Gilbey wrote:
> I'd like to ask for some help. I'm working on packaging pydevd, which
> builds a private .so library. Ordinary extensions built using cython
> or similar end up being called "foo.cpython-310-x86_64-linux-gnu.so",
> but this library,
I'd like to ask for some help. I'm working on packaging pydevd, which
builds a private .so library. Ordinary extensions built using cython
or similar end up being called "foo.cpython-310-x86_64-linux-gnu.so",
but this library, which is not dependent on the Python version, should
presumably be cal
19 matches
Mail list logo
