On April 13, 2020 3:44:31 AM UTC, Paul Wise wrote:
>On Sun, Apr 12, 2020 at 10:32 PM Scott Kitterman wrote:
>
>> I took a look at the presence of pyproject.toml files in the Debian
>archive.
>> There are currently 99 packages. Of those, only 28 specify a
>'build-backend',
>> which is required
On Sun, Apr 12, 2020 at 10:32 PM Scott Kitterman wrote:
> I took a look at the presence of pyproject.toml files in the Debian archive.
> There are currently 99 packages. Of those, only 28 specify a 'build-backend',
> which is required by 517/518 to be useful for building a package.
Is there a to
On Sunday, April 12, 2020 9:56:01 PM EDT Sandro Tosi wrote:
> Hello,
> python-pytest is blocking 18 packages from removal, most of them would
> be leaves once python-pytest is gone.
>
> so i was playing with the idea of tackling python-pytest removal by
> updating all its rdeps and not run unittes
Hello,
python-pytest is blocking 18 packages from removal, most of them would
be leaves once python-pytest is gone.
so i was playing with the idea of tackling python-pytest removal by
updating all its rdeps and not run unittests for the python2 binary
(so dropping pytest and the other b-d* only us
This being roughly the mid-point in the development cycle, I thought it might
be good to see where we are in terms of future Python packaging developments.
As I understand it, PEP-517 and PEP-518 are 'the future'.
I took a look at the presence of pyproject.toml files in the Debian archive.
The
>> You should consider /usr/lib// if you want to make your
>> package multiarch-safe.
>
> And what about ?
>
> /usr/lib//
>
> whcih one is better ?
Have a look at the Debian policy at
https://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs
It explicitly mentions:
> Applications may also
> You should consider /usr/lib// if you want to make your
> package multiarch-safe.
And what about ?
/usr/lib//
whcih one is better ?
> so my question is how can I solve this error.
> I thought about adding rpath to these libraries in order to move then
> under a private location /usr/lib/. But for this I need to add
> an rpath to all the extensions which use these libraries.
You should consider /usr/lib// if you want to make y
> > The issue is that the current build system do not provide rpath for
> > these libraries so I can not add one via chrpath.
> Well, ideally you need to fix the build system so that it sets the correct
> rpath directly.
I found patchelf whcih allows to add a rpath :))
So I just need to set the
On Sun, Apr 12, 2020 at 03:18:39PM +0200, picca wrote:
> I thought about adding rpath to these libraries in order to move then
> under a private location /usr/lib/.
This looks like the correct way to solve this.
> The issue is that the current build system do not provide rpath for
> these librar
Hello, I am working on the dials[1] package. This scientific software
produce a bunch of python extension via boost python, but also a bunch
of libraries, which are the common part of the python extension.
when I package it, I moved the common library under the /usr/lib//
directory. This way the
11 matches
Mail list logo
