Re: Investigating the reverse dependencies of python-monotonic.
Once python3-m2crypto is in Debian, I will port oz to python3. /Simon > 13 aug. 2019 kl. 21:46 skrev Thomas Goirand : > >> On 8/13/19 12:38 PM, peter green wrote: >> Hi >> >> I've been looking at various python 2 cruft packages (packages no longer >> built by the corresponding source packages) and why they can't be >> cleaned up, I have been looking in a derivative but many of my results >> are also relevant to debian proper. Where relevant I have been filing >> bugs against the reverse-dependencies of these cruft packages, so they >> can be fixed or ultimately removed. >> >> Most such packages have been part of upstream projects that have dropped >> python 2 support, notablly django and openstack. In such cases it is >> pretty clear that the only reasonable way forward is for the reverse >> dependencies to be either removed or migrated to python 3. >> >> One package that stood out from the rest was python-monotonic. >> python-monotonic is maintained by the Debian openstack team, but it >> doesn't seem to be in any way openstack specific, nor does upstream seem >> to have dropped python2 support. It seemed to have a fair few reverse >> dependencies. >> >> python-humanfriendly (has rdeps) >> oz (rc bug filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933509 ) >> python-fasteners (has rdeps) >> python-futurist (has rdeps, cruft) >> python-octaviaclient (assumed to be openstack related) >> python-oslo.log (assumed to be openstack related) >> python-oslo.messaging (assumed to be openstack related) >> python-oslo.service (assumed to be openstack related) >> python-oslo.utils (assumed to be openstack related) >> python-tenacity (has rdeps, cruft) >> >> There are also indirect reverse dependencies, (i'm not investigating >> reverse dependencies of packages that are clearly openstack specific here) >> >> python-coloredlogs (via python-humanfriendly, no reverse dependencies) >> python-datalad (via python-fasteners, no reverse dependencies) >> duplicity (via python-fasteners) >> python-oauth2client (via python-fasteners) >> python-oslo.concurrency (via python-fastners, openstack related) >> python-taskflow (via python-fasteners, cruft) >> python-tooz (via python-fasteners, openstack related, cruft) >> python-googleapi (via python-oauth2client) >> python-pypowervm (via python-taskflow, openstack related, cruft) >> python-googleapi-samples (via python-googleapi) >> python-etcd3gw (no rdeps) >> python-gnocchiclient (openstack related, cruft) >> >> If we ignore openstack stuff, python modules and an examples package the >> two main packages left seem to be oz and duplicity, oz seems to have >> very low popcon, but duplicity seems to have a popcon of around 3000 and >> growing. >> >> So the main question seems to be can duplicity be reasonably migrated to >> python 3 and if not is it worth reinstating the python-monotonic binary >> package to save duplicity? > > What happened is that I simply uploaded the latest version of OpenStack > from Experimental to Sid. This includes monotonic. It's been a long time > I maintain monotonic because it's used in OpenStack, then other packages > started using it. You may have noticed that it was in Experimental with > Python 2 removed for at least 6 months, just like for Django, giving the > sign that Py2 would soon go away. However, maybe bugs should have been > filled, sorry that I didn't do it in time. > > Let's take a look at the situation. > > As per Andrey's reply, we can fix duplicity. > > From your report above, if I remove all the OpenStack stuff (which at > this time, should all be only Python 3), the only affected packages > would be: > >> python-humanfriendly (has rdeps) >> oz (rc bug filed #933509) >> python-coloredlogs (via python-humanfriendly, no reverse dependencies) >> python-datalad (via python-fasteners, no reverse dependencies) >> duplicity (via python-fasteners) >> python-oauth2client (via python-fasteners) >> python-googleapi-samples (via python-googleapi) > > According to the setup.py of python-googleapi in the Github repo, latest > upstream version supports Python 3, so it should be doable to upload a > new version to fix this. > > I will remove Python 2 suport from python-oauth2client and > python-fasteners tomorrow. > > So, this leaves us only: humanfriendly, oz, python-coloredlogs, > python-datalad. I've uploaded humanfriendly and coloredlogs Py2 removal. > BTW, I believe python-coloredlogs was there as a build-depends of > cyvcf2, which has been fixed on the 1st of august by Andreas Tille. > > By all means, let's not play the dance of re-introducting Python 2 when > we can move forward on the right direction. > > Thanks for taking the time to investigate this, this is very useful, and > I have to admit that, even though I know how to do the work, I am a bit > lost into knowing from were to begin. The release tracker is not very > helpful in this regard. > > Cheers, > > Thomas Goirand (zigo)
Re: Investigating the reverse dependencies of python-monotonic.
Thank you! I just uploaded oz with python 3 dependencies. If any python Debian packager want to take a look and suggest improvements that would be great, as I’m mostly guessing how to package python apps in Debian. /Simon > 14 aug. 2019 kl. 09:20 skrev Thomas Goirand : > >> On 8/13/19 9:58 PM, Simon Josefsson wrote: >> Once python3-m2crypto is in Debian, I will port oz to python3. >> >> /Simon > > Well, it's in unstable already... > > Thomas Goirand (zigo)
Re: Alternative signature mechanisms for upstream source verification
Stefano Rivera writes: > Should we expand this to include some of these new mechanisms? > Things brought up in the debian-python thread include: > 1. sigstore https://docs.sigstore.dev/ > 2. ssh signatures > 3. signify https://man.openbsd.org/signify.1 +1 I believe all signatures we trust should be encoded in a non-mutable transparency log like Sigstore/Sigsum etc. But the first step towards that is to add support for verifying that property. > There is a general trend towards getting upstream sources from Git > rather than tarballs in Debian, but we're a long way from moving across > completely, or even finding consensus to do so. > These signature mechanisms can generally be applied to git commits as > well as tarballs. Signatures of git commits is the same as a signature on a SHA1 object which is broken for authentication purposes. But it is possible to discuss these issues separately, paving the way for git commit signing to be trustworthy when GitHub/GitLab moves to SHA256. /Simon signature.asc Description: PGP signature
Re: Bug#1091506: ITP: python-unshare -- extension for C unshare() call
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 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 : >> >> 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 >>> X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org >>> >>> * Package name: python-unshare >>> Version : 0.22 >>> Upstream Author : Shubham Sharma >>> * 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 >> signature.asc Description: PGP signature
Re: Bug#1091506: ITP: python-unshare -- extension for C unshare() call
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 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 signature.asc Description: PGP signature
Re: Bug#1091506: ITP: python-unshare -- extension for C unshare() call
Andrey Rakhmatullin 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 signature.asc Description: PGP signature
Stop recommending PyPi as upstream for Debian Python packages?
Context: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091506#27 Helmut Grohne 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 signature.asc Description: PGP signature
Bug#1092260: ITP: python-certstream -- Client library for talking to certstream servers
Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-certstream Version : 1.12 Upstream Author : Cali Dog Security, Ryan Sears * URL : https://github.com/CaliDog/certstream-python * License : Expat Programming Lang: Python Description : Client library for talking to certstream servers Certstream-python is a library for interacting with the certstream network -- https://certstream.calidog.io/ -- to monitor an aggregated feed from a collection of Certificate Transparency Lists: https://www.certificate-transparency.org/known-logs https://salsa.debian.org/python-team/packages/python-certstream/ /Simon signature.asc Description: PGP signature
Certstream Go & Python packages
All, I have uploaded a pair of CertStream-related projects: one self-hosted server written in Go and a Python library and client tool. What do they do? It allows you to watch the stream of newly minted certificates published into various certificate transparency logs. Please let me know if you find anything strange with the packaging. Here is a small recipe for testing for future reference: Build your own packages from git: https://salsa.debian.org/python-team/packages/python-certstream/ https://salsa.debian.org/go-team/packages/certstream-server-go/ Or pick the latest Salsa-built amd64 binaries: https://salsa.debian.org/jas/certstream-server-go/-/jobs/6872068 https://salsa.debian.org/python-team/packages/python-certstream/-/jobs/6872129 Either 'dpkg -i' or 'apt-get install' the 'certstream-server-go' package and start it locally like this: /usr/bin/certstream-server-go -config /usr/share/doc/certstream-server-go/examples/config.sample.yaml you should see it start talking to networks and print lines like: 2025/01/06 17:10:19 ct-watcher.go:143: Currently monitored ct logs: 48 2025/01/06 17:10:26 ct-watcher.go:292: Processed 1000 entries | Queue length: 0 2025/01/06 17:10:31 ct-watcher.go:292: Processed 2000 entries | Queue length: 0 ... Then either 'dpkg -i' or 'apt-get install' the 'python3-certstream' package and start the client talking to your own server like this: /usr/bin/certstream --url ws://127.0.0.1:8080/ You should see output like this: ... [2025-01-06T17:11:31.623000] https://wyvern.ct.digicert.com/2025h1 - cc.xiaoxidaka.cn [cc.xiaoxidaka.cn] [2025-01-06T17:11:31.624000] https://wyvern.ct.digicert.com/2025h1 - *.swvasb.com [*.swvasb.com, www.swvabook.swvasb.com, www.swvasb.swvasb.com] [2025-01-06T17:11:31.653000] https://ct.googleapis.com/logs/eu1/xenon2025h1 - www.silverresorts.com [www.silverresorts.com] [2025-01-06T17:11:31.654000] https://ct.googleapis.com/logs/eu1/xenon2025h1 - www.phoenixcpa.cpa [www.phoenixcpa.cpa] [2025-01-06T17:11:31.655000] https://ct.googleapis.com/logs/eu1/xenon2025h1 - intranet.wov.ch [intranet.wov.ch] ... /Simon signature.asc Description: PGP signature
packaging rfc3161-client
Hi Rust & Python teams, I would like to package: https://github.com/trailofbits/rfc3161-client It is a Python library that ships with and needs a Rust crate to work, the separation is best explained by upstream: It is composed of three subprojects: 🦀 tsp-asn1: A Rust crate using rust-asn1 to create the types used by the Time-Stamp protocol. This crate depends on rust-asn1 and cryptography to minimize the amount of duplicated code. While it is usable as a standalone crate, this is not officially supported. Drop us a message if you are interested in using it. 🦀 rfc3161-client: Another Rust crate that provides Python bindings to the tsp-asn1 crate using PyO3. 🐍 rfc3161-client A Python library using the crate above to provide a usable API to create Timestamp Request and read Timestamp Response. Are there similar projects that are packaged in Debian that I look at for inspiration? Any thoughts on if this be split up into two separate Debian source packages, one maintained by the rust team following their policies and ship the crates - and one source package maintained by the python team following their policies that ship the library and depend on the rust packages -- or just one source package with a more complicated maintainership and build process? I have started python-like packaging here: https://salsa.debian.org/python-team/packages/python-rfc3161-client/ However it lacks the Rust part. Would someone who knows Rust want to join me working on this package? I'm still learning Python packaging so I hope to help on that, but I haven't done any Rust packaging at all... forks, merge requests, commits etc appreciated. /Simon signature.asc Description: PGP signature
Bug#1091490: ITP: pqconnect -- easy-to-install Post-Quantum Internet security layer
Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: pqconnect Version : 1.2.1 Upstream Author : Jonathan Levin, et al * URL : https://www.pqconnect.net/ * License : public domain Programming Lang: Python Description : easy-to-install Post-Quantum Internet security layer https://salsa.debian.org/python-team/packages/pqconnect /Simon signature.asc Description: PGP signature
Re: Bug#1091490: ITP: pqconnect -- easy-to-install Post-Quantum Internet security layer
Hi If anyone wants to play with Debian packaging of PQConnect I have a draft set of packages that at least produce /usr/bin/pqconnect. https://salsa.debian.org/python-team/packages/pqconnect/-/pipelines/ https://salsa.debian.org/python-team/packages/python-netfilterqueue/-/pipelines/ https://salsa.debian.org/python-team/packages/python-unshare/-/pipelines/ https://salsa.debian.org/python-team/packages/python-py25519/-/pipelines/ https://salsa.debian.org/python-team/packages/python-pymceliece/-/pipelines/ I have brought up with upstream the duplication of py25519 vs https://tracker.debian.org/pkg/python-lib25519 and pymceliece vs https://tracker.debian.org/pkg/python-mceliece and hopefully we won't need to package both, but I started preparing py25519 + pymceliece packages anyway just to get pqconnect to build. I'm running out of cycles on this, so I'm going to leave this for now. Feel free to push to these projects as you may see fit. This was my first Python packages that do C library interaction I'm fairly sure there is a lot unfinished stuff in there. Especially the self-tests are problematic because unshare() seem to require root privileges. /Simon Simon Josefsson writes: > Package: wnpp > Severity: wishlist > Owner: Simon Josefsson > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org > > * Package name: pqconnect > Version : 1.2.1 > Upstream Author : Jonathan Levin, et al > * URL : https://www.pqconnect.net/ > * License : public domain > Programming Lang: Python > Description : easy-to-install Post-Quantum Internet security layer > > https://salsa.debian.org/python-team/packages/pqconnect > > /Simon > signature.asc Description: PGP signature
Bug#1091494: ITP: python-netfilterqueue -- bindings for libnetfilter_queue
Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-netfilterqueue Version : 1.1.0 Upstream Author : Kerkhoff Technologies Inc, Matthew Fox, Joshua Oreman * URL : https://github.com/oremanj/python-netfilterqueue/ * License : Expat Programming Lang: Python Description : bindings for libnetfilter_queue NetfilterQueue provides access to packets matched by an iptables rule in Linux. Packets so matched can be accepted, dropped, altered, reordered, or given a mark. https://salsa.debian.org/python-team/packages/python-netfilterqueue/ /Simon signature.asc Description: PGP signature
Bug#1091506: ITP: python-unshare -- extension for C unshare() call
Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-unshare Version : 0.22 Upstream Author : Shubham Sharma * 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 signature.asc Description: PGP signature
Re: Bug#1091197: ITP: python-genson -- user-friendly JSON Schema generator
Many thanks for a helping hand!
Carsten Schoenert writes:
> Hello Simon,
>
> Am 26.12.24 um 02:23 schrieb Simon Josefsson:
>> Hi. I'm struggling with packaging for this package:
>> https://salsa.debian.org/python-team/packages/python-genson
>
> ...
>> Why doesn't pybuild do the right thing by default?
>
> on which base pybuild could make the right decision? pybuild is doing
> what it need and should do.
>
> The missing installation of the subfolder looks to me like an upstream
> issue.
> If the folder is needed for later usage it needs to get installed by
> setuptools.
Yes I suspected this may be an upstream issue, but I'm not familiar
enough with python build systems to understand how to debug or have
confidence in a upstream bug report. I tried to channel this forward:
https://github.com/wolverdude/GenSON/issues/80
>> +execute_before_dh_auto_test:
>> + cp -rv genson/schema .pybuild/cpython3_3.12/build/genson/
>> + cp -rv genson/schema .pybuild/cpython3_3.13/build/genson/
>
> You can simplify this all by using the variable PYBUILD_BEFORE_TEST
Which is not documented in pybuild(1) but now I found time to read
https://wiki.debian.org/Python/Pybuild
>> +export PYBUILD_BEFORE_TEST = cp -rv {dir}/genson/schema
>> {build_dir}/$(PYBUILD_NAME)
Yay thank you! This works and is cleaner than my hack.
All is not perfect, now autopkgtest fail with a different error. The
strange thing is that this didn't happen in my 'hack' branch which ought
to be fairly similar, except for maybe PYTHON_BUILD_NAME and the
packaging merge. The autopkgtest was successful there. Ideas?
https://salsa.debian.org/python-team/packages/python-genson/-/jobs/6820031
___ ERROR collecting test/test_add_multi.py
ImportError while importing test module
'/tmp/autopkgtest-lxc.394h6eqm/downtmp/autopkgtest_tmp/build/test/test_add_multi.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.13/importlib/__init__.py:88: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
test/test_add_multi.py:1: in
from . import base
test/base.py:4: in
from genson import SchemaNode, SchemaBuilder
E ImportError: cannot import name 'SchemaNode' from 'genson'
(/tmp/autopkgtest-lxc.394h6eqm/downtmp/autopkgtest_tmp/build/genson/__init__.py)
> And I personally would introduce another small package with just the
> binary genson. To mee it's totally fine it's serverd by the package
> python3-genson.
> It's done very often within other Python binary packages.
Done!
In the Go team the preference is the reverse, I believe, but I suppose
the key difference for Python is that /usr/bin binaries end up being
Architecture:any for Go programs but for Python they are still
Architecture:all so there is no duplication of /usr/lib Python code for
all the architectures which there would be for /usr/lib Go code if
library+program are put in the same Debian binary package. I hadn't
realized this difference can influence the packaging style so much.
This decision makes lintian unhappy:
X: python3-genson: application-in-library-section python [usr/bin/genson]
N:
N: This package contains a binary in $PATH but is in a section just thought
N: for libraries. It likely should be in another section like e.g. utils,
N: text, devel, misc, etc., but not in e.g. perl, ruby or python.
N:
N: People tend to skip these package sections when looking for applications
N: in the package list and hence wouldn't notice this package.
N:
N: In case the program in $PATH is only a helper tool and the package is
N: primarily a library, please add a Lintian override for this tag.
N:
N: Visibility: info
N: Show-Always: no
N: Check: application-not-library
N: This tag is experimental.
It also makes deciding the section harder for the resulting combined
tool+library package:
X: python3-genson: library-package-name-for-application [usr/bin/genson]
N:
N: This package contains a program in $PATH but is named like a library. E.g.
N: instead of libfoo-bar-perl it should be named just foo-bar.
N:
N: People tend to skip library-like named packages when looking for
N: applications in the package list and hence wouldn't notice this package.
N: See the reference for some (not perl-specific) reasoning.
N:
N: In case the program in $PATH is only a helper tool and the package is
N: primarily a library, please add a Lintian override for this tag.
N:
N: Please refer to
N: https://perl-team.pages.debian.net/policy.html#Package_Naming_Policy for
N: details.
N:
N: Visibility: info
N: Show-Always: no
N: Check: application-not-library
N: This tag is experimental.
I don't think 'genson' is a helper tool s
Re: Bug#1091197: ITP: python-genson -- user-friendly JSON Schema generator
Andrey Rakhmatullin writes: > On Thu, Dec 26, 2024 at 12:03:51PM +0100, Simon Josefsson wrote: >> Andrey Rakhmatullin writes: >> >> > Wasn't the proposed fix "export PYBUILD_NAME as the docs say"? I see you >> > are not doing this. >> >> Thanks for reply! I added that but commented out since adding it did >> not change the pybuild behaviour. The extra genson/schema/ files are >> not built and installed, only the top-level genson/ directory which is >> the case even without PYBUILD_NAME. > > I've rechecked and the proposed fix also included "also, note the big fat > warnings about upstream not configuring setuptools correctly". > As I've just checked, running `python3 -m build` in the upstream repo also > produces a wheel without the schema subpackage. Thanks for testing. Yes so maybe the best is if upstream make genson/schema/ installed by default, and maybe that will solve the autopkgtest failure too. Or we can look into reverting back something based on my 'hack' approach, which is pretty much the same as the PYBUILD_BEFORE_TEST command, that made autopkgtest happy. I didn't understand which big fat warning this was? I looked in the build logs. /Simon signature.asc Description: PGP signature
Re: Bug#1091197: ITP: python-genson -- user-friendly JSON Schema generator
Andrey Rakhmatullin writes: > Wasn't the proposed fix "export PYBUILD_NAME as the docs say"? I see you > are not doing this. Thanks for reply! I added that but commented out since adding it did not change the pybuild behaviour. The extra genson/schema/ files are not built and installed, only the top-level genson/ directory which is the case even without PYBUILD_NAME. /Simon signature.asc Description: PGP signature
Re: packaging rfc3161-client
Jelmer Vernooij writes: > I've packaged a few Python packages that are fully or partially built in > rust. The simplest examples are probably: > > * dulwich > * python-upstream-ontologist > > More advanced are e.g.: > > * ruff Thanks! Alexander Kjäll writes: > As long as the Rust crates are published on crates.io then I think it would > be easiest to package them in the rust team :) They aren't on creates.io. Since the need arose from a python library, I'll see if I can complete this within the python team, but if the Rust part of this package turns out to be heavy I think that is a bad idea and it should be split up or moved to Rust team. Maybe upstream could publish the Rust crate on crates.io and separate the project into two parts eventually. weepingclown writes: > Hi, > > Top of my head, there is src:pendulum and src:python-orjson. *Probably* > anything with a python3-maturin build-dep can be of help. Thank you! I will try to learn from python-upstream-ontologist and python-orjson which looks closest to this package. /Simon signature.asc Description: PGP signature
Re: renewed python-sigstore packaging work
Louis-Philippe Véronneau writes: > On 2024-12-06 10 h 57 a.m., Simon Josefsson wrote: >> stefa...@debian.org writes: >> >>> Hi Simon (2024.12.05_22:48:05_+) >>>> I'd appreciate help and collaborators on this! >>> >>> Feel free to add me as an uploader. >> Thank you! Added. >> >>> I think the Python Team would make sense for it. If you're not a member, >>> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#joining-the-team >> I have read that file now and accept it. My salsa username is >> 'jas'. >> I'm happy to move python-sigstore and python-tuf to the >> python-modules >> namespace, to make it easier for all team members to help. >> /Simon > > Welcome to the team! Thank you! There is now: https://salsa.debian.org/python-team/packages/python-tuf https://salsa.debian.org/python-team/packages/sigstore-python The first is stuck waiting for a new version of python-securesystemslib: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089125 The second is pending other unpackaged dependencies, I'll try to work on them one by one... Feel free to help and join by adding yourself to Uploaders and make commits to these repositories. So far I've force-pushed updates to the first commit contains everything, but that's a bad idea going forward so I'll stop. /Simon signature.asc Description: PGP signature
Re: renewed python-tuf packaging work
Philippe Coval writes: > hi > Hello why didnt you resume work on the previous attempt to package it at: > https://salsa.debian.org/python-team/packages/tuf > > It would be nice to merge those 2 repos merged and have it team maintained. I noticed that repository, but it was for a really old release and never finished/uploaded as far as I could tell. Compare debian/rules, they are wildly different due to how upstream evolved. I found it easier to start from scratch than trying to fix the old package and then update it to the latest upstream version. I am happy to team maintain things. I wasn't part of the Python team when I wrote the e-mail below, but I am now. My repository below has been moved to: https://salsa.debian.org/python-team/packages/python-tuf/ I uploaded it to NEW yesterday. Don't let that stop you (or anyone else) from adding themselves to Uploaders and start improve the packaging, I am looking for help here! We should be prepared to roll a minimal-changes upload to NEW in case ftp-master's find a problem with the package though. So I would suggest pushing changes to a new debian/experimental branch for simplicity. Regardless of workflow, it will be possible to sort things out later. /Simon > Regards > > > > > -- > > https://purl.org/rzr > mailto:r...@users.sf.net > > > > > > De : "Simon Josefsson" > A : 934...@bugs.debian.org,931...@bugs.debian.org,"Lukas Puehringer" > ,"Philippe Coval" > Envoyé: jeudi 5 Décembre 2024 23:45 > Objet : > > Hi! > > I am working on getting python-tuf into Debian: > > https://lists.debian.org/debian-python/2024/12/msg00040.html > > Packaging currently lives here: > > https://salsa.debian.org/jas/python-tuf/ > > I'd appreciate help and collaborators on this! > > /Simon > > > signature.asc Description: PGP signature
Re: Bug#1085852: python-securesystemslib 1.1.0 is released
Holger Levsen writes: > On Wed, Dec 11, 2024 at 06:58:28PM +0100, Simon Josefsson wrote: >> > fine with me, but maybe >> > https://qa.debian.org/developer.php?login=in-toto-dev%40googlegroups.com >> > would be better? I'm fine with either, please do what you think is >> > more appropriate. >> Happy to, but it also looks like a small team with no written down >> process for how to apply for group membership or packaging workflow. > > right. > >> There is also no Salsa group in use for it. Okay if I move >> python-securesystemslib to Salsa /debian/ namespace, change Maintainer >> to in-toto and add myself as Uploaders? Then I can cleanup remaining >> issues and fix Vcs-* URLs. Or just the 'Debian QA Group'. > > I definitly prefer either the Debian group or the Debian Python team > and would let you choose. I dislike moving the package to the Debian QA > Group however. I have moved my repository to the Python team (cc'ed). I'm monitoring testing migration, and hope to eventually do another upload from this repository to clean up some metadata (see recent commits). https://salsa.debian.org/python-team/packages/securesystemslib This package is a dependency for python-tuf which is a dependency for python-sigstore and https://www.python.org/downloads/metadata/sigstore/ is likely to trigger interest from the Debian python community. I don't feel strongly about any of this, and I'm hoping I'm not stepping on anyones toes with this upload -- let me know if you want to revert anything, or prefer something else. I barely know python, TUF, Sigstore or Debian packaging either, so these packages need help. I realized one problem with using the in-toto-dev package group: it seems to be a closed mailing list, and I recall trying to send e-mail to that list before without any response, so maybe the Googlegroups is configured with limited public posting rights. /Simon signature.asc Description: PGP signature
Re: Bug#1085852: python-securesystemslib 1.1.0 is released
I noticed that 1.2.0-1 migrated to testing, so I did an upload to finalize the packaging move and it now live here: https://salsa.debian.org/python-team/packages/securesystemslib/ Python team, please review packaging if you have cycles! I am not up to speed up all python group best practices. /Simon signature.asc Description: PGP signature
Re: Bug#1085852: python-securesystemslib 1.1.0 is released
Colin Watson writes: > On Tue, Dec 17, 2024 at 08:44:39AM +0100, Simon Josefsson wrote: >> I noticed that 1.2.0-1 migrated to testing, so I did an upload to >> finalize the packaging move and it now live here: >> >> https://salsa.debian.org/python-team/packages/securesystemslib/ >> >> Python team, please review packaging if you have cycles! I am not up to >> speed up all python group best practices. > > The random Dockerfile is anomalous (though not forbidden) and wouldn't > be used by most of the members of the DPT, so I haven't reviewed it. I removed that file -- I didn't notice that file myself. Upstream seems to have stopped using that process over a year ago and have made several upstream releases after that. The file is still present upstream and in git history if anyone is curious. I prefer if packaging follows Debian practices in general and Debian Python packaging team in particular, let's make it easy for people to help. > The rest looks OK from a quick visual inspection. Thank you! It really helps to have review of new things. > * It's a shame that the basename of the git repository URL doesn't >match the source package name. If it's practical to rename the >repository without too much trouble, that would be good. Done. > * You could depend on dh-sequence-python3 instead of dh-python, and >drop "--with python3" from debian/rules. Done. > Oh, also, DPT practice is to use pristine-tar, so please do that. See > https://wiki.debian.org/Python/GitPackaging. Done. There is a reproducability FTBFS on armhf that I'm trying to debug, but hopefully I'll do another upload shortly. /Simon signature.asc Description: PGP signature
Bug#1090897: ITP: python-sigstore-protobuf-specs -- Python bindings for Sigstore's protocol buffer (protobuf) specs
Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-sigstore-protobuf-specs Version : 0.3.3 Upstream Author : The Sigstore Authors * URL : https://github.com/sigstore/protobuf-specs * License : Apache-2 Programming Lang: Python Description : Python bindings for Sigstore's protocol buffer (protobuf) specs These are the Python language bindings for Sigstore's protobuf specs. I plan to maintain this package as part of the Python team: https://salsa.debian.org/python-team/packages/python-sigstore-protobuf-specs Work in progress will hopefully be found here: https://salsa.debian.org/jas/sigstore-protobuf-specs https://salsa.debian.org/jas/protobuf-specs /Simon signature.asc Description: PGP signature
Bug#1090902: ITP: python-betterproto -- better Protobuf / gRPC generator & library
Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-betterproto Version : 2.0.0b7 Upstream Author : Daniel G. Taylor * URL : https://github.com/danielgtaylor/python-betterproto * License : MIT Programming Lang: Python Description : better Protobuf / gRPC generator & library This project aims to provide an improved experience when using Protobuf / gRPC in a modern Python environment by making use of modern language features and generating readable, understandable, idiomatic Python code. It will not support legacy features or environments (e.g. Protobuf 2). The following are supported: - Protobuf 3 & gRPC code generation - Both binary & JSON serialization is built-in - Python 3.6+ making use of: - Enums - Dataclasses - async/await - Timezone-aware datetime and timedelta objects - Relative imports - Mypy type checking I plan to maintain this package as part of the Python team: https://salsa.debian.org/python-team/packages/python-betterproto Work in progress will hopefully be found here: https://salsa.debian.org/jas/python-betterproto /Simon signature.asc Description: PGP signature
Re: renewed python-sigstore packaging work
Simon Josefsson writes:
> https://salsa.debian.org/python-team/packages/python-tuf
I have uploaded 5.1.0-2 to unstable, however I would appreciate review
of python-tuf since I'm new to python packaging. My main concern is
about debian/tests/ and if there are better approaches?
> https://salsa.debian.org/python-team/packages/sigstore-python
I'm happy to report that this now builds! Please review packaging.
However it does not yet run, there is a failure that shows up during
build too:
https://salsa.debian.org/python-team/packages/sigstore-python/-/jobs/6793076#L1421
For the ones who want to try out bleeding edge and perhaps debug things
further, please try something like this (keep in mind that this
downloads untrusted stuff...):
podman run -it --rm debian:unstable
echo "deb [trusted=yes]
https://salsa.debian.org/python-team/packages/python-grpclib/-/jobs/6792419/artifacts/raw/aptly
unstable main" | tee --append /etc/apt/sources.list.d/add.list
echo "deb [trusted=yes]
https://salsa.debian.org/python-team/packages/python-betterproto/-/jobs/6792726/artifacts/raw/aptly
unstable main" | tee --append /etc/apt/sources.list.d/add.list
echo "deb [trusted=yes]
https://salsa.debian.org/python-team/packages/python-sigstore-rekor-types/-/jobs/6792765/artifacts/raw/aptly
unstable main" | tee --append /etc/apt/sources.list.d/add.list
echo "deb [trusted=yes]
https://salsa.debian.org/python-team/packages/python-sigstore-protobuf-specs/-/jobs/6792898/artifacts/raw/aptly
unstable main" | tee --append /etc/apt/sources.list.d/add.list
echo "deb [trusted=yes]
https://salsa.debian.org/python-team/packages/rfc8785/-/jobs/6792999/artifacts/raw/aptly
unstable main" | tee --append /etc/apt/sources.list.d/add.list
echo "deb [trusted=yes]
https://salsa.debian.org/python-team/packages/sigstore-python/-/jobs/6793079/artifacts/raw/aptly
unstable main" | tee --append /etc/apt/sources.list.d/add.list
echo >>/etc/apt/apt.conf.d/99verify-peer.conf "Acquire { https::Verify-Peer
false }"
apt update
apt install -y sigstore
The error message is below, does anyone have ideas? I wonder if
pydantic in Debian is too old, or something.
/Simon
root@ab7dd93df2f1:/# sigstore
Traceback (most recent call last):
File "/usr/bin/sigstore", line 5, in
from sigstore._cli import main
File "/usr/lib/python3/dist-packages/sigstore/_cli.py", line 38, in
from sigstore import __version__, dsse
File "/usr/lib/python3/dist-packages/sigstore/dsse/__init__.py", line 33, in
from sigstore.hashes import Hashed
File "/usr/lib/python3/dist-packages/sigstore/hashes.py", line 28, in
class Hashed(BaseModel, frozen=True):
File
"/usr/lib/python3/dist-packages/pydantic/_internal/_model_construction.py",
line 226, in __new__
complete_model_class(
File
"/usr/lib/python3/dist-packages/pydantic/_internal/_model_construction.py",
line 658, in complete_model_class
schema = cls.__get_pydantic_core_schema__(cls, handler)
^^
File "/usr/lib/python3/dist-packages/pydantic/main.py", line 702, in
__get_pydantic_core_schema__
return handler(source)
^^^
File
"/usr/lib/python3/dist-packages/pydantic/_internal/_schema_generation_shared.py",
line 84, in __call__
schema = self._handler(source_type)
^^
File "/usr/lib/python3/dist-packages/pydantic/_internal/_generate_schema.py",
line 610, in generate_schema
schema = self._generate_schema_inner(obj)
File "/usr/lib/python3/dist-packages/pydantic/_internal/_generate_schema.py",
line 879, in _generate_schema_inner
return self._model_schema(obj)
^^^
File "/usr/lib/python3/dist-packages/pydantic/_internal/_generate_schema.py",
line 691, in _model_schema
{k: self._generate_md_field_schema(k, v, decorators) for k, v in
fields.items()},
File "/usr/lib/python3/dist-packages/pydantic/_internal/_generate_schema.py",
line 1071, in _generate_md_field_schema
common_field = self._common_field_schema(name, field_info, decorators)
^^^
File "/usr/lib/python3/dist-packages/pydantic/_internal/_generate_schema.py",
line 1263, in _common_field_schema
schema = self._apply_annotations(
File "/usr/lib/python3/dist-packages/pydantic/_internal/_generate_schema.py",
line 2056, in _apply_annotations
schema = get_inner_schema(source_type)
^
File
"/usr/lib/python3/dist-packages/pydantic/_internal/_schema_generation_sha
Re: Bug#1090897: ITP: python-sigstore-protobuf-specs -- Python bindings for Sigstore's protocol buffer (protobuf) specs
Hi, I would appreciate packaging review of: https://salsa.debian.org/python-team/packages/python-sigstore-protobuf-specs Some questions/concerns: - Same concern about using PyPI tarballs as for the other packages, some files are missing compared to upstream's GitHub repository. Maybe this is actually common for Python packages, and understanding this is part of my learning curve. But it still feels surprising to me, and a bit sub-optimal from a supply-chain safety point of view: which hosting site to rely on? PyPI that publish tarballs, or GitHub who (should) hold the source code used to generate the tarballs? How to detect when these differ? What to do about it? /Simon Simon Josefsson writes: > Package: wnpp > Severity: wishlist > Owner: Simon Josefsson > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org > > * Package name: python-sigstore-protobuf-specs > Version : 0.3.3 > Upstream Author : The Sigstore Authors > * URL : https://github.com/sigstore/protobuf-specs > * License : Apache-2 > Programming Lang: Python > Description : Python bindings for Sigstore's protocol buffer (protobuf) > specs > > These are the Python language bindings for Sigstore's protobuf specs. > > I plan to maintain this package as part of the Python team: > > https://salsa.debian.org/python-team/packages/python-sigstore-protobuf-specs > > Work in progress will hopefully be found here: > > https://salsa.debian.org/jas/sigstore-protobuf-specs > https://salsa.debian.org/jas/protobuf-specs > > /Simon > signature.asc Description: PGP signature
Re: Bug#1090952: ITP: python-rfc8785 -- Pure-Python JSON Canonicalization Scheme (Python library)
Hi, I'd appreciate review of this package too: https://salsa.debian.org/python-team/packages/python-rfc8785 Pardon the incorrect Subject line of the ITP bug report! Cut'n'paste error... /Simon Simon Josefsson writes: > Package: wnpp > Severity: wishlist > Owner: Simon Josefsson > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org > > * Package name: python-rfc8785 > Version : 0.1.4 > Upstream Author : William Woodruff, Anders Rundgren, et al > * URL : https://github.com/trailofbits/rfc8785.py > * License : Apache-2.0 > Programming Lang: Python > Description : Pure-Python JSON Canonicalization Scheme (Python library) > > A pure-Python, no-dependency implementation of [RFC 8785], > a.k.a. JSON Canonicalization Scheme or JCS. > > https://salsa.debian.org/python-team/packages/python-rfc8785 > > /Simon > signature.asc Description: PGP signature
Bug#1090952: ITP: python-sigstore-rekor-types -- Python models for Rekor's API types
Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-rfc8785 Version : 0.1.4 Upstream Author : William Woodruff, Anders Rundgren, et al * URL : https://github.com/trailofbits/rfc8785.py * License : Apache-2.0 Programming Lang: Python Description : Pure-Python JSON Canonicalization Scheme (Python library) A pure-Python, no-dependency implementation of [RFC 8785], a.k.a. JSON Canonicalization Scheme or JCS. https://salsa.debian.org/python-team/packages/python-rfc8785 /Simon signature.asc Description: PGP signature
Bug#1090918: ITP: python-sigstore-rekor-types -- Python models for Rekor's API types
Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-sigstore-rekor-types Version : 0.0.18 Upstream Author : William Woodruff, et al * URL : https://github.com/trailofbits/sigstore-rekor-types * License : Apache-2.0 Programming Lang: Python Description : Python models for Rekor's API types https://salsa.debian.org/python-team/packages/python-sigstore-rekor-types /Simon signature.asc Description: PGP signature
Re: Bug#1090902: ITP: python-betterproto -- better Protobuf / gRPC generator & library
Hi again, I would appreciate packaging review of 'betterproto': https://salsa.debian.org/python-team/packages/python-betterproto Some questions/concerns: - The dh_auto_test call fail, but debian/rules mask this error so the build completes. Does anyone understand the error message? Is 'pydantic' too old in Debian? Help appreciated on this one. https://salsa.debian.org/python-team/packages/python-betterproto/-/jobs/6792723#L1283 dh_auto_test I: pybuild base:311: cd /build/python-betterproto-2.0.0b7/.pybuild/cpython3_3.13/build; python3.13 -m unittest discover -v betterproto.lib.pydantic.google.protobuf.compiler (unittest.loader._FailedTest.betterproto.lib.pydantic.google.protobuf.compiler) ... ERROR == ERROR: betterproto.lib.pydantic.google.protobuf.compiler (unittest.loader._FailedTest.betterproto.lib.pydantic.google.protobuf.compiler) -- ImportError: Failed to import test module: betterproto.lib.pydantic.google.protobuf.compiler Traceback (most recent call last): File "/usr/lib/python3.13/unittest/loader.py", line 429, in _find_test_path package = self._get_module_from_name(name) File "/usr/lib/python3.13/unittest/loader.py", line 339, in _get_module_from_name __import__(name) ~~^^ File "/build/python-betterproto-2.0.0b7/.pybuild/cpython3_3.13/build/betterproto/lib/pydantic/google/protobuf/compiler/__init__.py", line 208, in CodeGeneratorRequest.__pydantic_model__.update_forward_refs() # type: ignore ^^^ AttributeError: type object 'CodeGeneratorRequest' has no attribute '__pydantic_model__'. Did you mean: '__pydantic_config__'? -- Ran 1 test in 0.000s FAILED (errors=1) - Do the /usr/bin binary have to go in a separate package, or can it be in the python3-betterproto binary package? I believe they are developer-only tools of limited applicability. - Naming - right now it uses this style: Source: python-betterproto Package: python3-betterproto Package: protoc-betterproto Does that make sense? Similar to 'grpc', maybe this should be 'python-betterproto-protoc' instead? Or 'protoc-python-betterproto? Or 'protoc-betterproto-python'? - This uses tarballs from pypi.debian.net, which isn't identical to upstream's GitHub git archive. Just like for 'grpc' it seems tests/ is missing. Maybe this is a common issue with PyPI tarballs? Is an upstream request appropriate here? - autopkgtest/piuparts fails because of the python-grpclib dependency. I added a custom apt repository to debian/salsa-ci.yml however I don't know how to make autopkgtest/piuparts pick that up. This will go away once python-grpclib is in Debian. - There is an X lintian complaint - is this common? Isn't a simpler fix to chmod -x the file? X: python3-betterproto: executable-in-usr-lib [usr/lib/python3/dist-packages/betterproto/plugin/main.py] N: N: The package ships an executable file in /usr/lib. N: N: Please move the file to /usr/libexec. N: N: With policy revision 4.1.5, Debian adopted the Filesystem Hierarchy N: Specification (FHS) version 3.0. N: N: The FHS 3.0 describes /usr/libexec. Please use that location for N: executables. N: N: Please refer to File System Structure (Section 9.1.1) in the Debian Policy N: Manual, filesystem-hierarchy, N: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html, and N: Bug#954149 for details. N: N: Visibility: pedantic N: Show-Always: no N: Check: files/permissions/usr-lib N: This tag is experimental. N: N: Screen: emacs/elpa/scripts N: Advocates: "David Bremner" N: Reason: The emacsen-common package places installation and removal N: scripts, which for ELPA packages are executable, in the folder N: /usr/lib/emacsen-common/packages. N: N: About four hundred installation packages are affected. All of N: them declare emacsen-common as an installation prerequisite. N: N: Read more in Bug#974175 and Bug#954149. N: N: Screen: web/cgi/scripts N: Advocates: "Andrius Merkys" N: Reason: The folder /usr/lib/cgi-bin/ is designated for scripts in the N: Common Gateway Interface (CGI). They require the executable bit N: so the server can run them. N: N: Read more in N: https://en.wikipedia.org/wiki/Common_Gateway_Interface, N: https://datatracker.ietf.org/doc/html/rfc3875.html, and N: Bug#1003941. - Others? /Simon Simon Josefsson writes: > Package: wnpp > Severi
Bug#1090912: ITP: python-grpclib -- Pure-Python gRPC implementation for asyncio
Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-grpclib Version : 2.0.0b7 Upstream Author : Vladimir Magamedov, et al * URL : https://github.com/vmagamedov/grpclib * License : BSD-3-Clause Programming Lang: Python Description : Pure-Python gRPC implementation for asyncio This is a Pure-Python gRPC implementation for asyncio. https://salsa.debian.org/python-team/packages/python-grpclib /Simon signature.asc Description: PGP signature
Re: Bug#1090912: ITP: python-grpclib -- Pure-Python gRPC implementation for asyncio
Hi Python Team, I have prepared packaging of 'grpclib' and I'm new to Python packaging, so I would appreciate open minded review of how this is packaged: https://salsa.debian.org/python-team/packages/python-grpclib Please bring up stylistic concerns, for me to learn. I plan to upload this to NEW shortly. Some of the questions/concerns I have are: - Do the /usr/bin binaries have to go in a separate package, or could they be in the python3-grpclib binary package? I believe they are developer-only tools of limited applicability. - Naming - right now it uses this style: Source: python-grpclib Package: python3-grpclib Package: protoc-grpclib Does that make sense? Upstream calls itself 'grpclib' but using 'python-grpclib' in Debian seems nicer. I see there is a 'rustc-protoc' in the archive, maybe this should be 'python-grpclib-protoc' instead? Or 'protoc-python-grpclib'? Or 'protoc-grpclib-python'? - This uses tarballs from pypi.debian.net, which isn't identical to upstream's GitHub git archive. It seems tests/ are missing. I've approached upstream about including them in the PyPI upload -- https://github.com/vmagamedov/grpclib/issues/200 -- but I'm not sure what the best practices are here. Is using the pypi.debian.net tarball recommended? Or do people package the github.com tarball instead? Or directly from git? What do we do when some stuff is missing from the PyPI archive? - Man pages are missing - the tools doesn't respond to -h or --help, I suppose this is an upstream request, or are there any other ideas on that? - Others? /Simon Simon Josefsson writes: > Package: wnpp > Severity: wishlist > Owner: Simon Josefsson > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org > > * Package name: python-grpclib > Version : 2.0.0b7 > Upstream Author : Vladimir Magamedov, et al > * URL : https://github.com/vmagamedov/grpclib > * License : BSD-3-Clause > Programming Lang: Python > Description : Pure-Python gRPC implementation for asyncio > > This is a Pure-Python gRPC implementation for asyncio. > > https://salsa.debian.org/python-team/packages/python-grpclib > > /Simon > signature.asc Description: PGP signature
Re: Bug#1090918: ITP: python-sigstore-rekor-types -- Python models for Rekor's API types
Hi again, I would appreciate packaging review of: https://salsa.debian.org/python-team/packages/python-sigstore-rekor-types Some questions/concerns: - Autopkgtest fail, it appears to be looking for a module called 'sigstore_rekor_types' but the installed name is 'rekor_types'. I don't understand where the autopkgtest is picking up the 'sigstore_rekor_types' namespace from, is there a way to make it use 'rekor_types'? https://salsa.debian.org/python-team/packages/python-sigstore-rekor-types/-/jobs/6792771 - Naming... it seems upstream calls itself 'sigstore-rekor-types' so I think 'python-sigstore-rekor-types' is a good name, but it does install itself under ./usr/lib/python3/dist-packages/rekor_types/ which would argue for 'python-rekor-types'. Maybe the autopkgtest gets the name wrong for this reason. /Simon Simon Josefsson writes: > Package: wnpp > Severity: wishlist > Owner: Simon Josefsson > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org > > * Package name: python-sigstore-rekor-types > Version : 0.0.18 > Upstream Author : William Woodruff, et al > * URL : https://github.com/trailofbits/sigstore-rekor-types > * License : Apache-2.0 > Programming Lang: Python > Description : Python models for Rekor's API types > > https://salsa.debian.org/python-team/packages/python-sigstore-rekor-types > > /Simon > signature.asc Description: PGP signature
Re: python-sigstore / python-tuf: request for packaging help
Andrey Rakhmatullin writes: > On Thu, Dec 05, 2024 at 11:39:24PM +0100, Simon Josefsson wrote: >> The self-tests tries seems to open some files which fails and I suspect >> it is because srcdir != builddir reasons, or something similar, see >> errors here: >> >> https://salsa.debian.org/jas/python-tuf/-/jobs/6707693 >> >> ERRORS >> >> __ ERROR collecting tests/test_metadata_generation.py >> __ >> tests/test_metadata_generation.py:10: in >> from tests.generated_data.generate_md import generate_all_files >> tests/generated_data/generate_md.py:60: in >> os.mkdir(OUT_DIR) >> E FileNotFoundError: [Errno 2] No such file or directory: >> 'generated_data/ed25519_metadata' >> >> How is this (seamingly common) problem solved normally? Do we copy test >> data files into the build directory somehow? Do we include them in the >> package? Do we patch hard-coded paths like this to make it work? > > It's not common and test data files are already copied because they are > under tests/. It's because of relative paths and I can reproduce this > problem by running pytest in the upstream's git checkout. You are right, I reported it upstream: https://github.com/theupdateframework/python-tuf/issues/2745 I disabled that self-check meanwhile, and got a bit further: collected 184 items tests/test_api.py [ 19%] tests/test_examples.py FFF [ 21%] tests/test_fetcher_ng.py ....[ 27%] tests/test_metadata_eq_.py [ 29%] tests/test_metadata_serialization.py . [ 43%] tests/test_repository.py [ 47%] tests/test_trusted_metadata_set.py ..[ 61%] tests/test_updater_consistent_snapshot.py ...[ 63%] tests/test_updater_delegation_graphs.py .. [ 66%] tests/test_updater_fetch_target.py . [ 69%] tests/test_updater_key_rotations.py .. [ 70%] tests/test_updater_ng.py .FF.FF.F. [ 77%] tests/test_updater_top_level_update.py . [ 95%] ... [ 97%] tests/test_updater_validation.py .. [ 98%] tests/test_utils.py F.. [100%] ... == 21 failed, 163 passed, 5 warnings in 5.39s == See full log: https://salsa.debian.org/jas/python-tuf/-/jobs/6710680/viewer Several failures seems related to not being able to find some test file, any ideas how to fix this further? I'll see if I can figure out how to disable only the failing tests, pending some better fix. It seems a large portion of the self-tests now work so I think this is in good enough shape for an upload to NEW. /Simon signature.asc Description: PGP signature
python-sigstore / python-tuf: request for packaging help
Hi I am new to python debian packaging, and I'm looking for guidance and review my packaging. I'm happy to team-maintain these packages if someone can add me to the salsa group. Right now I am working on python-sigstore and my packaging is here: https://salsa.debian.org/jas/sigstore-python/ as you can see in the pipeline, it currently fails due to lacking tuf: https://salsa.debian.org/jas/sigstore-python/-/jobs/6706412 It seems python-tuf has an old ITP/RFS report here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934151 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931178 I started from scratch on python-tuf with the latest upstream version, instead of trying to understand the old packaging work that I couldn't get to work. Upstream evolved a lot. My packaging is here: https://salsa.debian.org/jas/python-tuf/ The self-tests tries seems to open some files which fails and I suspect it is because srcdir != builddir reasons, or something similar, see errors here: https://salsa.debian.org/jas/python-tuf/-/jobs/6707693 ERRORS __ ERROR collecting tests/test_metadata_generation.py __ tests/test_metadata_generation.py:10: in from tests.generated_data.generate_md import generate_all_files tests/generated_data/generate_md.py:60: in os.mkdir(OUT_DIR) E FileNotFoundError: [Errno 2] No such file or directory: 'generated_data/ed25519_metadata' How is this (seamingly common) problem solved normally? Do we copy test data files into the build directory somehow? Do we include them in the package? Do we patch hard-coded paths like this to make it work? If anyone can review my python-tuf and python-sigstore packages, that would be appreciated -- all nit-picks and style advice is most recommended, as I have not worked on python packaging before. Don't assume I understand any of the debian/* content so feel free to question some decision. If you want to build python-tuf locally, it depends on a more recent version of python3-securesystemslib and you can find it here: https://salsa.debian.org/jas/securesystemslib/ https://salsa.debian.org/jas/securesystemslib/-/pipelines/774721 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089125 Thanks, /Simon signature.asc Description: PGP signature
Re: renewed python-sigstore packaging work
stefa...@debian.org writes: > Hi Simon (2024.12.05_22:48:05_+) >> I'd appreciate help and collaborators on this! > > Feel free to add me as an uploader. Thank you! Added. > I think the Python Team would make sense for it. If you're not a member, > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#joining-the-team I have read that file now and accept it. My salsa username is 'jas'. I'm happy to move python-sigstore and python-tuf to the python-modules namespace, to make it easier for all team members to help. /Simon signature.asc Description: PGP signature
Re: Bug#1090912: ITP: python-grpclib -- Pure-Python gRPC implementation for asyncio
I have uploaded python-grpclib to NEW. I settled for including the command-line tools even though they may be rarely used developer tools, under the 'protoc-grpclib' name (I tried 'python-grpclib-protoc and 'python-protoc-grpclib' but then lintian complained about using python-* namespace). It still uses the PyPI tarball, it seems to work fine and I've opened upstream reports about including self-tests and man pages. I added Testsuite:autopkgtest-pkg-pybuild to be prepared for when upstream adds self-tests. /Simon signature.asc Description: PGP signature
Re: Bug#1090918: ITP: python-sigstore-rekor-types -- Python models for Rekor's API types
I have uploaded this to NEW. Using Testsuite: autopkgtest-pkg-pybuild solve the autopkgtest failure, so Salsa CI is now green. /Simon signature.asc Description: PGP signature
Re: renewed python-sigstore packaging work
Colin Watson writes: > On Sat, Dec 21, 2024 at 02:01:27AM +0100, Simon Josefsson wrote: >> Simon Josefsson writes: >> > https://salsa.debian.org/python-team/packages/python-tuf >> >> I have uploaded 5.1.0-2 to unstable, however I would appreciate review >> of python-tuf since I'm new to python packaging. My main concern is >> about debian/tests/ and if there are better approaches? > > I haven't done a full review, but a quick note on the point you brought > up: it looks to me as though you could replace the whole of > debian/tests/ with the field "Testsuite: autopkgtest-pkg-pybuild" in the > source stanza of debian/control. See pybuild-autopkgtest(1). Thanks -- I had some trouble with autopkgtest-pkg-pybuild when I started packaging, and removed it to simplify things, but later forgot to add it back in. It work fine for python-tuf: https://salsa.debian.org/python-team/packages/python-tuf/-/jobs/6802287 I'll try to adapt this for all the new packages too. >> The error message is below, does anyone have ideas? I wonder if >> pydantic in Debian is too old, or something. > > pydantic in Debian is current (assuming this is unstable, anyway - I did > a small upstream version bump quite recently). Does upstream test with > the latest version? Ah -- I will debug more and will consider that Debian's pydantic may actually be too new instead. /Simon signature.asc Description: PGP signature
Bug#1091194: ITP: python-datamodel-code-generator -- pydantic code generator from OpenAPI and more
Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-datamodel-code-generator Version : 0.26.4 Upstream Author : Koudai Aono * URL : https://github.com/koxudaxi/datamodel-code-generator * License : Expat Programming Lang: Python Description : pydantic code generator from OpenAPI and more https://salsa.debian.org/python-team/packages/python-sigstore-rekor-types /Simon signature.asc Description: PGP signature
Re: Bug#1090912: ITP: python-grpclib -- Pure-Python gRPC implementation for asyncio
Soren Stoutner writes: >> - This uses tarballs from pypi.debian.net, which isn't identical to >> upstream's GitHub git archive. It seems tests/ are missing. I've >> approached upstream about including them in the PyPI upload -- >> https://github.com/vmagamedov/grpclib/issues/200 -- but I'm not sure >> what the best practices are here. Is using the pypi.debian.net >> tarball recommended? Or do people package the github.com tarball >> instead? Or directly from git? What do we do when some stuff is >> missing from the PyPI archive? > > I am not experienced enough with Python packaging to respond to your other > questions, but I do know that many Python packages pull from github or gitlab > when thinks like tests are missing from PyPI, so you should feel free to do > so > when needed. Thanks for insight! This is good to know. I prefer to ask upstreams to include the relevant stuff into the PyPI tarball instead. However if it turns out upstreams don't want to do that (or that doing so is against PyPI best practices somehow) AND there is significant advantage in using upstream's github as the tarball source, then at least I know this isn't considered a big no-no for Debian packages. So far I've only noticed that some self-tests and auxilliary files are missing from the PyPI tarballs, and I don't consider that to be important enough to deviate from using the pypi.debian.net sources yet. /Simon signature.asc Description: PGP signature
Re: Bug#1091197: ITP: python-genson -- user-friendly JSON Schema generator
Hi
Could someone help me and upstream how to get python setuptools to get
all files installed for this package?
Please see this thread and upstream bug report:
https://github.com/wolverdude/GenSON/issues/80
I work around the problem in the debian packaging like this:
export PYBUILD_BEFORE_TEST = \
cp -rv {dir}/genson/schema {build_dir}/$(PYBUILD_NAME)
However installing these files should be done by upstream setuptools
magic somehow. Some hint or ideally an upstream merge request to fix
this would be appreciated...
/Simon
Andrey Rakhmatullin writes:
>> Thanks for reply! I added that but commented out since adding it did
>> not change the pybuild behaviour. The extra genson/schema/ files are
>> not built and installed, only the top-level genson/ directory which is
>> the case even without PYBUILD_NAME.
>
> I've rechecked and the proposed fix also included "also, note the big fat
> warnings about upstream not configuring setuptools correctly".
> As I've just checked, running `python3 -m build` in the upstream repo also
> produces a wheel without the schema subpackage.
Carsten Schoenert writes:
>> Why doesn't pybuild do the right thing by default?
>
> on which base pybuild could make the right decision? pybuild is doing
> what it need and should do.
>
> The missing installation of the subfolder looks to me like an upstream
> issue.
> If the folder is needed for later usage it needs to get installed by
> setuptools.
/Simon
signature.asc
Description: PGP signature
Re: Bug#1091194: ITP: python-datamodel-code-generator -- pydantic code generator from OpenAPI and more
Hi. I'd appreciate review of this package: https://salsa.debian.org/python-team/packages/python-datamodel-code-generator/ The debian/* files are minimal, and Salsa CI is happy, so I plan to upload this shortly but I appreciate review and co-maintainers whenever appropriate. /Simon signature.asc Description: PGP signature
Bug#1091197: ITP: python-genson -- user-friendly JSON Schema generator
Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-genson Version : 1.3.0 Upstream Author : Jon Wolverton * URL : https://github.com/wolverdude/genson/ * License : Expat Programming Lang: Python Description : user-friendly JSON Schema generator https://salsa.debian.org/python-team/packages/python-genson /Simon signature.asc Description: PGP signature
Re: Bug#1090912: ITP: python-grpclib -- Pure-Python gRPC implementation for asyncio
Julian Gilbey writes: > On Sun, Dec 22, 2024 at 06:23:24PM +0100, Simon Josefsson wrote: >> So far I've only noticed that some self-tests and auxilliary files are >> missing from the PyPI tarballs, and I don't consider that to be >> important enough to deviate from using the pypi.debian.net sources yet. > > Hi Simon, > > There is no Debian Python policy to use PyPI versus GitHub versions as > far as I am aware. However, the PyPI versions of packages frequently > do not include the test suites, as many developers regard those as > part of the development environment, not the release environment (and > having test suites included in all packages could cause significant > bloat). You are, of course, welcome to ask them to reconsider for > this package, but you may not have any success, and I wouldn't rely on > them agreeing to your request. > > Whatever the outcome of your negotiations, the Debian Python team is > very keen on having autopkgtests for as many packages as possible: > doing so catches all sorts of bugs and can prevent your package from > mysteriously breaking. So given that upstream have written a test > suite that you have easy access to (via GitHub), unless you have a > very strong reason *not* to include it in the Debian sources, you > really ought to do so. "It isn't included in the PyPI source tarball" > is not a strong reason. So it seems that you have a few choices: > > (1) Use the GitHub sources in place of the PyPI sources. > > (2) Use the GitHub sources, patched in those few places where the PyPI > version differs to match the PyPI version. (This can be done via > debian/patches.) > > (3) Use the PyPI sources and include the test suite from GitHub; this > could be done via the dpkg-source components mechanism, for example. > It would complicate the packaging a bit, and make upgrading harder > work, but it would certainly be feasible. > > (4) Decide on principle that you're going to stick with the PyPI > version come what may, and as upstream haven't included a test suite > in that version, the Debian package won't either. > > > I am sure I'm not alone on the Debian Python Team in strongly > discouraging you from following option (4). My personal preference > would be (1) or (2), depending on how significantly different the > GitHub and PyPI versions are. (And this does also assume that the > developers have tagged their Git repository with appropriate tags.) Thank you! I'm happy to adopt 1) but I didn't want to do that without some +1 on doing so since https://wiki.debian.org/Python/LibraryStyleGuide?action=show&redirect=Python%2FPackaging#debian.2Fwatch says 'Thus, it is highly recommended that you update your existing packages to the new debian/watch format described here' and 'Since probably for most of our packages, the original tarball comes from the Python Package Index (a.k.a. PyPI or the Cheeseshop)' which give me the impression that using PyPI tarballs is generally preferred, so it is hard for me as newbie to understand the preferences. I do agree that self-tests are important, and I was surprised maintainers don't include them in the PyPI tarballs. Maybe it is not worth our time to open bug reports about changing the PyPI tarballs, and switching to the GitHub tarballs is fine. Another question is about which version to package -- latest GitHub tag or PyPI version? Have a look at this project: https://pypi.org/project/sigstore-protobuf-specs/#history I suppose I may run into whatever bug that prompted this yanking too... /Simon signature.asc Description: PGP signature
Re: Bug#1091197: ITP: python-genson -- user-friendly JSON Schema generator
Hi. I'm struggling with packaging for this package: https://salsa.debian.org/python-team/packages/python-genson On the 'debian/latest' branch there is a "normal" packaging (except that it ignore self-check errors), and there are two related problems: https://salsa.debian.org/python-team/packages/python-genson/-/jobs/6818093 1) Self-checks cannot find the 'genson.schema' module. E ModuleNotFoundError: No module named 'genson.schema' 2) The resulting package doesn't have the genson/schema sub-directory: jas@kaka:~/dpkg/python-genson$ curl --silent 'https://salsa.debian.org/python-team/packages/python-genson/-/jobs/6818096/artifacts/raw/aptly/pool/main/p/python-genson/python3-genson_1.3.0-1+salsaci+20241226+4_all.deb'|dpkg -c -|grep dist-packages/genson/ drwxr-xr-x root/root 0 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/ -rw-r--r-- root/root 347 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/__init__.py -rw-r--r-- root/root 5877 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/__main__.py jas@kaka:~/dpkg/python-genson$ On the 'hack' branch I made a crude attempt at resolving this, and indeed self-checks are happy, even autopkgtest, and the package contains the sub-directory: https://salsa.debian.org/python-team/packages/python-genson/-/pipelines/786628 jas@kaka:~/dpkg/python-genson$ curl --silent 'https://salsa.debian.org/python-team/packages/python-genson/-/jobs/6818159/artifacts/raw/aptly/pool/main/p/python-genson/python3-genson_1.3.0-1+salsaci+20241226+6_all.deb'|dpkg -c -|grep dist-packages/genson/ drwxr-xr-x root/root 0 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/ -rw-r--r-- root/root 347 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/__init__.py -rw-r--r-- root/root 5877 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/__main__.py drwxr-xr-x root/root 0 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/schema/ -rw-r--r-- root/root 0 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/schema/__init__.py -rw-r--r-- root/root 5423 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/schema/builder.py -rw-r--r-- root/root 4741 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/schema/node.py drwxr-xr-x root/root 0 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/schema/strategies/ -rw-r--r-- root/root 522 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/schema/strategies/__init__.py -rw-r--r-- root/root 2109 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/schema/strategies/array.py -rw-r--r-- root/root 2196 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/schema/strategies/base.py -rw-r--r-- root/root 3276 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/schema/strategies/object.py -rw-r--r-- root/root 1891 2024-12-23 12:52 ./usr/lib/python3/dist-packages/genson/schema/strategies/scalar.py jas@kaka:~/dpkg/python-genson$ But the patch is really ugly! See below. It copies files from the source direcory into the pybuild internal path, including hard coded version numbers. Pybuild should have copied these files by itself. Why doesn't pybuild do the right thing by default? Any ideas how to resolve? Feel free to clone the project and/or push to it to experiment. I'll take a little break from this package now... jas@kaka:~/dpkg/python-genson$ git diff debian/latest..hack diff --git a/debian/rules b/debian/rules index a1954a9..1658f7b 100755 --- a/debian/rules +++ b/debian/rules @@ -3,6 +3,7 @@ include /usr/share/dpkg/pkg-info.mk # DEB_VERSION #export PYBUILD_NAME = genson +export PYBUILD_TEST_ARGS= -k 'not test_no_input' %: dh $@ --buildsystem=pybuild @@ -10,8 +11,9 @@ include /usr/share/dpkg/pkg-info.mk # DEB_VERSION B = $(CURDIR)/debian/tmp/usr/bin M = $(CURDIR)/debian/tmp/usr/share/man/man1 -override_dh_auto_test: - -dh_auto_test $(DH_BUILD_OPTS) +execute_before_dh_auto_test: + cp -rv genson/schema .pybuild/cpython3_3.12/build/genson/ + cp -rv genson/schema .pybuild/cpython3_3.13/build/genson/ execute_after_dh_auto_install: ifeq (,$(filter nodoc,$(DEB_BUILD_PROFILES))) jas@kaka:~/dpkg/python-genson$ /Simon signature.asc Description: PGP signature
Bug#1101009: ITP: python-freezegun -- allow Python tests to travel through time via datetime
Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-freezegun Version : 1.5.1 Upstream Author : Steve Pulec * URL : https://github.com/spulec/freezegun/ * License : Apache-2.0 Programming Lang: Python Description : allow Python tests to travel through time via datetime FreezeGun is a library that allows your Python tests to travel through time by mocking the datetime module. This dependency is needed by python-tuf 6.0. https://salsa.debian.org/python-team/packages/python-freezegun/ /Simon signature.asc Description: PGP signature
