Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #16645 > unrolled thread

Bug#1091506: ITP: python-unshare -- extension for C unshare() call

Back to article view | Back to linux.debian.maint.python

Contents

  Bug#1091506: ITP: python-unshare -- extension for C unshare() call Simon Josefsson <simon@josefsson.org> - 2024-12-27 20:30 +0100
    Bug#1091506: ITP: python-unshare -- extension for C unshare() call Simon Josefsson <simon@josefsson.org> - 2024-12-28 11:10 +0100
      Re: Bug#1091506: ITP: python-unshare -- extension for C unshare() call Simon Josefsson <simon@josefsson.org> - 2024-12-28 11:30 +0100
        Re: Bug#1091506: ITP: python-unshare -- extension for C unshare()  call Andrey Rakhmatullin <wrar@debian.org> - 2024-12-28 11:40 +0100
        Re: Bug#1091506: ITP: python-unshare -- extension for C unshare()  call Andrey Rakhmatullin <wrar@debian.org> - 2024-12-28 11:40 +0100
          Re: Bug#1091506: ITP: python-unshare -- extension for C unshare() call Simon Josefsson <simon@josefsson.org> - 2024-12-28 11:50 +0100
            Re: Bug#1091506: ITP: python-unshare -- extension for C unshare()  call Andrey Rakhmatullin <wrar@debian.org> - 2024-12-28 12:00 +0100
    Stop recommending PyPi as upstream for Debian Python packages? Simon Josefsson <simon@josefsson.org> - 2025-01-02 10:00 +0100
      Re: Stop recommending PyPi as upstream for Debian Python packages? Andrey Rakhmatullin <wrar@debian.org> - 2025-01-02 10:20 +0100
      Re: Stop recommending PyPi as upstream for Debian Python packages? Dominik George <natureshadow@debian.org> - 2025-01-02 10:20 +0100
      Re: Stop recommending PyPi as upstream for Debian Python packages? Andrey Rakhmatullin <wrar@debian.org> - 2025-01-02 10:20 +0100

#16645 — Bug#1091506: ITP: python-unshare -- extension for C unshare() call

[Multipart message — attachments visible in raw view] — view raw

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson <simon@josefsson.org>
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-python@lists.debian.org

* Package name    : python-unshare
  Version         : 0.22
  Upstream Author : Shubham Sharma <shubhamsharma1172@gmail.com>
* URL             : https://github.com/shubham1172/unshare
* License         : GPL-3
  Programming Lang: Python
  Description     : extension for C unshare() call

 Python extension for C's unshare call, see unshare(2).

https://salsa.debian.org/python-team/packages/python-unshare/

/Simon

[toc] | [next] | [standalone]

#16647

[Multipart message — attachments visible in raw view] — view raw

I have patched out use of python-unshare from python-netfilterqueue, it
was only used during self-tests but those did not work anyway.

https://salsa.debian.org/python-team/packages/python-netfilterqueue/-/commit/22a94f3ba90112ea8aa474ba2523f6c81ca1d333
https://salsa.debian.org/python-team/packages/python-netfilterqueue/-/pipelines/787900

I opened an upstream bug report to ask them to consider another
approach:

https://github.com/oremanj/python-netfilterqueue/issues/15#issuecomment-2564282968

It seems their code is here:

https://github.com/oremanj/python-netfilterqueue/blob/master/tests/test_basic.py
https://github.com/oremanj/python-netfilterqueue/blob/master/tests/conftest.py

If you (or anyone on debian-python that I'm cc'ing now) can propose a
patch for upstream, maybe that will convince them to avoid the
python-unshare dependency and we'll have better self-tests as a result.

Note that there appears to be two python-unshare: one on PyPI and
another one here: https://github.com/NightTsarina/python-unshare/

/Simon

Simon Josefsson <simon@josefsson.org> writes:

> Thank you - I agree and hope to convince upstream PQconnect to pick
> build dependencies in a better way. This was a bit further down the
> dependency stack, but hopefully they can help anyway. They brought up
> a valid concern: prefer not to depend on things not on PyPI and I
> agree (of course, within reason).  It seems unshare is there:
> https://pypi.org/project/unshare/
>
> /Simon
>
>> 28 dec. 2024 kl. 08:08 skrev Helmut Grohne <helmut@subdivi.de>:
>> 
>> Control: tags -1 + moreinfo
>> 
>> Hi Simon,
>> 
>>> On Fri, Dec 27, 2024 at 08:24:28PM +0100, Simon Josefsson wrote:
>>> Package: wnpp
>>> Severity: wishlist
>>> Owner: Simon Josefsson <simon@josefsson.org>
>>> X-Debbugs-Cc: debian-devel@lists.debian.org, debian-python@lists.debian.org
>>> 
>>> * Package name    : python-unshare
>>>  Version         : 0.22
>>>  Upstream Author : Shubham Sharma <shubhamsharma1172@gmail.com>
>>> * URL             : https://github.com/shubham1172/unshare
>>> * License         : GPL-3
>>>  Programming Lang: Python
>>>  Description     : extension for C unshare() call
>>> 
>>> Python extension for C's unshare call, see unshare(2).
>>> 
>>> https://salsa.debian.org/python-team/packages/python-unshare/
>> 
>> I recommend not adding this to Debian. This Python extension wraps a
>> single syscall. You can achieve a similar effect using ctypes.
>> 
>>    import ctypes
>>    unshare = ctypes.CDLL(None, use_errno=True)["unshare"]
>>    unshare(flags)
>> 
>> The functionality being added here is useful, but in my opinion it does
>> not reach the bar of being sufficiently useful to warrant the cost of
>> carrying it in Debian yet. Bear in mind that every package being added
>> bears a permanent cost to Debian.
>> 
>> Please allow me to suggest an alternative.
>> https://git.subdivi.de/~helmut/python-linuxnamespaces.git/
>> Disclaimer: I am the author of the alternative.
>> 
>> I did not dare to propose adding this to Debian yet, because I consider
>> it work in progress, but even at this time, it does so much more than
>> the module you propose that it probably is worth looking into. It is not
>> API compatible, because it uses the enum module instead of numeric
>> constants. It also includes a pile of examples for more elaborate
>> container construction.
>> 
>> Helmut
>> 

[toc] | [prev] | [next] | [standalone]

#16648

[Multipart message — attachments visible in raw view] — view raw

Hi.  Asking for some advice here, in python-netfilterqueue there is now:

export PYBUILD_TEST_ARGS=--ignore tests/conftest.py

but dh_auto-test still seems to use that file, see output below.

How do I make pytest (for both build and autopkgtest) really ignore that
file and not try to use it?

My reading of https://wiki.debian.org/Python/Pybuild suggests it should
work.

/Simon

dh_auto_test 
I: pybuild base:311: cd /builds/python-team/packages/python-netfilterqueue/debian/output/source_dir/.pybuild/cpython3_3.13/build; python3.13 -m pytest --ignore tests/conftest.py
ImportError while loading conftest '/builds/python-team/packages/python-netfilterqueue/debian/output/source_dir/.pybuild/cpython3_3.13/build/tests/conftest.py'.
tests/conftest.py:8: in <module>
    import unshare  # type: ignore
E   ModuleNotFoundError: No module named 'unshare'
E: pybuild pybuild:389: test: plugin pyproject failed with: exit code=4:
cd /builds/python-team/packages/python-netfilterqueue/debian/output/source_dir/.pybuild/cpython3_3.13/build;
python3.13 -m pytest --ignore tests/conftest.py

[toc] | [prev] | [next] | [standalone]

#16649 — Re: Bug#1091506: ITP: python-unshare -- extension for C unshare() call

[Multipart message — attachments visible in raw view] — view raw

On Sat, Dec 28, 2024 at 03:34:07PM +0500, Andrey Rakhmatullin wrote:
> On Sat, Dec 28, 2024 at 11:21:11AM +0100, Simon Josefsson wrote:
> > Hi.  Asking for some advice here, in python-netfilterqueue there is now:
> > 
> > export PYBUILD_TEST_ARGS=--ignore tests/conftest.py
> 
> conftest.py is not a file with test cases, it's a "config" file for all
> tests, ignoring it doesn't make sense and not running code from it (if
> that's what you want) is likely impossible. I don't understand what do you
> want to achieve by ignoring it so I cannot suggest anything useful though.

If you want to replace the unshare module with the ctypes code as proposed
by Helmut or with something else, you need to *patch* the code.


-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#16650 — Re: Bug#1091506: ITP: python-unshare -- extension for C unshare() call

[Multipart message — attachments visible in raw view] — view raw

On Sat, Dec 28, 2024 at 11:21:11AM +0100, Simon Josefsson wrote:
> Hi.  Asking for some advice here, in python-netfilterqueue there is now:
> 
> export PYBUILD_TEST_ARGS=--ignore tests/conftest.py

conftest.py is not a file with test cases, it's a "config" file for all
tests, ignoring it doesn't make sense and not running code from it (if
that's what you want) is likely impossible. I don't understand what do you
want to achieve by ignoring it so I cannot suggest anything useful though.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#16651

[Multipart message — attachments visible in raw view] — view raw

Andrey Rakhmatullin <wrar@debian.org> writes:

> On Sat, Dec 28, 2024 at 11:21:11AM +0100, Simon Josefsson wrote:
>> Hi.  Asking for some advice here, in python-netfilterqueue there is now:
>> 
>> export PYBUILD_TEST_ARGS=--ignore tests/conftest.py
>
> conftest.py is not a file with test cases, it's a "config" file for all
> tests, ignoring it doesn't make sense and not running code from it (if
> that's what you want) is likely impossible. I don't understand what do you
> want to achieve by ignoring it so I cannot suggest anything useful though.

Thank you -- what I want to achieve is a build that succeeds after I
remove this heavy hammer that ignores all self-tests errors:

override_dh_auto_test:
	-dh_auto_test $(DH_BUILD_OPTS)

Maybe all of upstreams self-tests really do depend on the unshare
module, and if we don't want to include that in Debian [1] there is no
hope to get netfilterqeueue self-tests to work.  And then we just as
well disable all self-tests like that.

/Simon

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091506#10

[toc] | [prev] | [next] | [standalone]

#16652 — Re: Bug#1091506: ITP: python-unshare -- extension for C unshare() call

[Multipart message — attachments visible in raw view] — view raw

On Sat, Dec 28, 2024 at 11:41:19AM +0100, Simon Josefsson wrote:
> >> Hi.  Asking for some advice here, in python-netfilterqueue there is now:
> >> 
> >> export PYBUILD_TEST_ARGS=--ignore tests/conftest.py
> >
> > conftest.py is not a file with test cases, it's a "config" file for all
> > tests, ignoring it doesn't make sense and not running code from it (if
> > that's what you want) is likely impossible. I don't understand what do you
> > want to achieve by ignoring it so I cannot suggest anything useful though.
> 
> Thank you -- what I want to achieve is a build that succeeds after I
> remove this heavy hammer that ignores all self-tests errors:
> 
> override_dh_auto_test:
> 	-dh_auto_test $(DH_BUILD_OPTS)
> 
> Maybe all of upstreams self-tests really do depend on the unshare
> module,

They likely do, considering that they all use it via pytest_runtestloop().

> and if we don't want to include that in Debian [1] there is no
> hope to get netfilterqeueue self-tests to work.  And then we just as
> well disable all self-tests like that.
> 
> /Simon
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091506#10

That says "you can use this instead of that".

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#16658 — Stop recommending PyPi as upstream for Debian Python packages?

[Multipart message — attachments visible in raw view] — view raw

Context: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091506#27

Helmut Grohne <helmut@subdivi.de> writes:

> Hi Simon,
>
> On Sat, Dec 28, 2024 at 10:33:28AM +0100, Simon Josefsson wrote:
>> Thank you - I agree and hope to convince upstream PQconnect to pick
>> build dependencies in a better way. This was a bit further down the
>> dependency stack, but hopefully they can help anyway. They brought
>> up a valid concern: prefer not to depend on things not on PyPI and I
>> agree (of course, within reason).  It seems unshare is there:
>> https://pypi.org/project/unshare/
>
> Everyone has their own kink. I ignore Python modules that are not in
> Debian and others ignore Python modules not on PyPI.
>
> My reasons for ignoring PyPI:
>  * It has a history of hosting malware.
>  * It has a history of hosting low-quality modules (such as the one you
>    are packaging).
>  * It tends to have multiple competing modules for a usecase. Each of
>    them has their own downsides and the good solution ends up not being
>    uploaded to PyPI.
>  * Modules come and go often only ever receiving a single upload and
>    your dependency ends up becoming technical debt.
>  * It has made uploading stuff harder and harder while simultaneously
>    degrading security by stopping support for pgp signatures.
>  * Accessing PyPI has become harder since it became "protected" by
>    fastly.
>  * Salvo Tomaselli gave a talk in Toulouse with more reasons.
>
> I no longer consider PyPI worth my time.

I am beginning the feel the same.

Is there anyone in the Debian Python team who feels PyPi is preferrable?

I don't recall seeing arguments in favor of PyPi, but maybe they exist.

Otherwise is there any objections to me updating

https://wiki.debian.org/Python/LibraryStyleGuide?action=show&redirect=Python%2FPackaging#debian.2Fwatch

which led me in the wrong way, and made me use PyPi as the upstream
source for packages I look at?

/Simon

[toc] | [prev] | [next] | [standalone]

#16659 — Re: Stop recommending PyPi as upstream for Debian Python packages?

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jan 02, 2025 at 10:03:59AM +0100, Dominik George wrote:
> >> Everyone has their own kink. I ignore Python modules that are not in
> >> Debian and others ignore Python modules not on PyPI.
> >>
> >> My reasons for ignoring PyPI:
> >> [long list of arguments]
> 
> I somehow don't get the point here.
> 
> Usually, I don't get to choose my build dependencies, so if an
> application I want to package depends on some module, I will have to
> package it. What point is there in discussing whether PyPI has a lot of
> crap around it, or whether it is a bad dependency? If an application I
> am packaging depends on a module and that module is low-quality or
> malware, what point is there in pulling it from GitHub instead?

Exactly.
The reasons listed are for an app upstream, not for a module packager.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#16660 — Re: Stop recommending PyPi as upstream for Debian Python packages?

Hi,

>> Everyone has their own kink. I ignore Python modules that are not in
>> Debian and others ignore Python modules not on PyPI.
>>
>> My reasons for ignoring PyPI:
>> [long list of arguments]

I somehow don't get the point here.

Usually, I don't get to choose my build dependencies, so if an application I want to package depends on some module, I will have to package it. What point is there in discussing whether PyPI has a lot of crap around it, or whether it is a bad dependency? If an application I am packaging depends on a module and that module is low-quality or malware, what point is there in pulling it from GitHub instead?

-nik

[toc] | [prev] | [next] | [standalone]

#16661 — Re: Stop recommending PyPi as upstream for Debian Python packages?

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jan 02, 2025 at 09:51:45AM +0100, Simon Josefsson wrote:
> Context: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091506#27
> 
> Helmut Grohne <helmut@subdivi.de> writes:
> 
> > Hi Simon,
> >
> > On Sat, Dec 28, 2024 at 10:33:28AM +0100, Simon Josefsson wrote:
> >> Thank you - I agree and hope to convince upstream PQconnect to pick
> >> build dependencies in a better way. This was a bit further down the
> >> dependency stack, but hopefully they can help anyway. They brought
> >> up a valid concern: prefer not to depend on things not on PyPI and I
> >> agree (of course, within reason).  It seems unshare is there:
> >> https://pypi.org/project/unshare/
> >
> > Everyone has their own kink. I ignore Python modules that are not in
> > Debian and others ignore Python modules not on PyPI.
> >
> > My reasons for ignoring PyPI:
> >  * It has a history of hosting malware.
> >  * It has a history of hosting low-quality modules (such as the one you
> >    are packaging).
> >  * It tends to have multiple competing modules for a usecase. Each of
> >    them has their own downsides and the good solution ends up not being
> >    uploaded to PyPI.
> >  * Modules come and go often only ever receiving a single upload and
> >    your dependency ends up becoming technical debt.
> >  * It has made uploading stuff harder and harder while simultaneously
> >    degrading security by stopping support for pgp signatures.
> >  * Accessing PyPI has become harder since it became "protected" by
> >    fastly.
> >  * Salvo Tomaselli gave a talk in Toulouse with more reasons.
> >
> > I no longer consider PyPI worth my time.
> 
> I am beginning the feel the same.
> 
> Is there anyone in the Debian Python team who feels PyPi is preferrable?

I think this conflates two mostly unrelated things and at least some of
the listed reasons are not applicable to your question.
And "I ignore Python modules that are not in Debian" solves everything
already.

-- 
WBR, wRAR

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web