Re: DebConf24 Sprint & BoF!
Hi Louis-Philippe (2024.04.25_13:58:42_+) > I've taken the liberty of submitting the annual Python BoF for DebConf24. If > you have ideas of what we should talk about, please add them to this > (temporary? the dc24.pad instance isn't up yet) pad: It's alive! https://pad.dc24.debconf.org/p/python-team-bof https://pad.dc24.debconf.org/p/python-team-sprint Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: salsa join request
Hi Lee (2024.04.17_16:35:33_+) > I've been part of the DPMT team in the past [0]. I'd like to put ansible and > ansible-core under the Debian Python Team umbrella. My salsa login is > "lgarrett". I have read > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > and I accept it. Welcome back. Added you. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Requests to join DPT haven't been processed for months
Hi Christian (2024.04.01_15:45:20_+) > one of the GSoC candidates I'm mentoring hasn't had his request to join > the team processed for a month. I then checked and unless I'm mistaken, > *no*( requests filed in 2024 have been processed. At least, all threads > I could find are as of yet unanswered. We've added a new owner to help out. Thanks peb! Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: OK to create a new package in "python-team/packages/"
Hi c.buhtz (2024.03.15_07:31:22_+) > On the long run it is my goal to make the package [1] ready for official > upload. But I suspect this is a long way. So on short view that repo will be > for practicing only. Am I allowed to create such a repo in my position? I don't have a problem with staging an ITP in progress in the git repos. If you do create a repo and then never upload the package, please delete/archive the repo when you're done. Personally, I usually get the package ready to upload before creating a git repo in the team. I want to be sure that it's something maintainable that I want to take on, before I commit to it. The advice for doing it in your own salsa profile seems sensible. For a complex package that you aren't sure about adding to the team, that could make sense. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to Join Debian Python Team as a Package Maintainer
Hi Pulak (2024.02.20_19:12:33_+) > I am interested in joining the Python Team to actively contribute to the > maintenance of Python-related packages within Debian. I am currently > maintaining a set of packages (python-pylatex, python-duet, > python-sphinx-contributors, and python-sphinx-autodoc2) and would like to > collaborate with the team to bring in more packages to Debian. Added, welcome. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join Debian Python Team
Hi Francesco (2024.01.30_12:05:04_+) > With this email, I am asking you to let me join your team with my > salsa username francesco.ballarin, associated with this email address. Added to the team, welcome! Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Joining the Debian Python Team
Hi Daniel (2024.01.30_10:12:14_+) > I wanna join the debian-python packaging team. Added, welcome to the team. Sorry for the delay, haven't processed these in a while. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Maintenance of python-resolvelib and python-commentjson
Hi Scott (2024.03.15_13:31:40_+) > I originally packaged python-resolvelib for pip and python-commentjson so we > could run python-resolvelib's tests. Pip is no longer using the packaged > version. It's currently used by pdm and ansible-core. However pip does still use resolvelib (albeit vendored). I make an effort to keep all pip's vendored dependencies in Debian so that we are familiar with them and track their security issues. So, I'll add myself as an uploader of resolvelib. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Please delete two empty salsa repositories
Hi Julian (2024.03.02_20:52:04_+) > Please could someone with the required permissions delete the > following two empty salsa repositories Deleted. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Suggesting change in DPT policy
Hi Christian (2024.03.02_22:09:29_+) > Some packages are complex, some packages have lots of reverse > dependencies. Where these two circles overlap, a careless "drive-by" > maintainer can do a lot of harm. Maybe we should look at ways we can improve this situation, without having to have packages under the team umbrella that aren't really team maintained. Now that we have Salsa with Merge Requests, it's hard for me to see much benefit from having packages in the team with the weak team membership (uploader). As a team member all I can do to contribute to such packages is commit to git. If I'm not sure my changes will be approved, I'd rather file a merge request. At that point, it may as well not be a team package. I filed merge requests to improve a weak team package, a couple of months ago. They never got reviewed. Is this still a team package? Yes I was able to do emergency uploads of it too, but I could also do that via NMU. > Things like "oh, documentation doesn't build anymore, I'll just disable > it", rather than fixing it. Or "oh, these tests don't pass anymore, I'll > just disable them", rather than looking into the regression. "Oh, my > upload triggered a transition, I'm no longer interested in this". > > (This are all things that have happened to me.) > > All that stuff is then left for others to clean up. And if one is > unlucky enough, this doesn't just cause work for the package, but for > all reverse dependencies. I don't think any of the things you describe there are acceptable for team maintenance. Disabling tests or docs may be necessary in the short term. Or if they will never be able to work again. But I don't think those are OK to do, upload and walk away. If the tests are broken and you can't figure it out, you talk to the people who know the package better. We could spell these things out more clearly in the team rules. We can also push back on team members who behave like this. Repeatedly doing the things you describe, when asked not to, should lead to being kicked out of the team. Picking up a bug and realising you are in over year head is something that will happen to new contributors to Debian. Having a team there to help out when someone does make a mess like that is useful. A few lines in a README.source about what makes a package complex is probably also useful to your collaborators (although, yes, of course writing this is work). > I see Uploaders as a signal of "these are the regular maintainers, I > should check with these people before doing any *major* changes". And I > argue that this is reasonable. I'd say it's best practice to do that whenever a package has people who seem to be caring about it. That's not the case for many packages in the team. Even ones listed with the team in Uploaders and a human as Maintainer. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Suggesting change in DPT policy
Hi Andreas (2024.02.27_08:05:44_+) > I did what I usually do in those teams: I dedicated quite some time in > team wide bug hunting. That way I squashed about 50 bugs on packages > where I was not in Uploaders. Thank you for doing this work. I've come across a number of DPT bugs where you've been leading the charge on Python 3.12 support (and related things, like Cython 3). I'd like the Python Team to be a team that fosters this kind of collaboration. Being supported, rather than demotivated by the response you get from the team is important. We've been talking about changing the maintainership rules for years, for all the reasons you raise. They are unexpected and hurt new (and old) contributors. What other people are hinting at is that there are one or two package maintainers in the team who feel strongly about needing this level of control for their packages. The team only gets to have their packages in the git repo, in exchange for allowing them this control. We'd probably lose their packages if we change the rule. How bad would that be? Now that everyone uses git, probably not so bad. Back in the day, if the package wasn't in our svn it probably wasn't in VCS at all. So, +1 from me. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: dh_python3: file in /usr/lib/python3.12/dist-packages ?
Hi Carles (2024.02.26_00:00:48_+) > The first one includes, in top_level.txt: > debian > ping3 > > And the second one: > build > debian > ping3 > > Where "ping3" is the expected module. "debian" is there because of the > debian/ directory (I'm super sure, and AFAIK should not be there!) and > "build" is there on the second time since, I guess, it exists at that > time. > > So, even in the package in testing, it contains "debian" which is wrong: Yeah, that's wrong. We tried to stop this from happening a while ago, but it doesn't appear to be working, here. https://github.com/pypa/setuptools/pull/4001 I think you've hit the NOTE in https://setuptools.pypa.io/en/latest/userguide/package_discovery.html#finding-simple-packages If you (or ideally upstream) set "namespaces = false" I think it'll behave correctly. BTW, I see this package has patches-applied in git, so gbp can't work with them. The team policy is to store patches-unapplied. You can work on the patches with git via gbp-pq. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: [Help] Re: python-pkginfo: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Hi Andreas (2024.01.11_17:48:43_+) > I've fixed the two other bugs in python-pkginfo and upgraded to latest > upstream. Unfortunately I have no clue about this issue. The test is expecting the module to be installed in the test environment. Either we could try harder to emulate that, or skip the tests. I committed a patch to run the test inside tox, which will install it in a virtualenv before running the test. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team
Hi Alexandre (2023.12.10_02:39:08_+) > I'm interested: > - fixing the bug I submitted > - checking if old python2 compatibility layers are actually still used: >- unittest2 >- future >- six >- dose1 >- >( I also check upstreams & send PR if upstream is still active) > > - add typing annotations to native packages > (alike python3-debian, python3-debconf, apt-listchanges ...) > > - helping with Py3.12 support & random RC bugs Added, welcome to the team. We always need more people do this kind of work. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team
Hi Fabio (2023.12.12_21:08:57_+) > Hi, I would like to join the Debian Python team for help to maintain > bleachbit, that I already helped, and possible occasional help to other > packages with low or zero activity. Added, welcome to the team! Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to Join the Debian Python Team
Hi Dale (2023.12.21_22:23:20_+) > My Salsa ID is: doge-tech [1] Added, welcome to the team! Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team
Hi Matthias (2023.12.09_20:50:29_+) > My username on Salsa is mak as well, and I have read the policy > document at > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > and I accept it. Added, welcome to the team! Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team
Hi Eduardo (2023.11.19_12:52:22_+) > I'd like to join the Python team. I intend to package the browser_cookie3 > module (https://github.com/borisbabic/browser_cookie3), ITP #1056159. What's the use-case for this package in Debian? It's a bit of a weird library (digging around in the user's browser profile isn't something expected). Please prepare some packaging on salsa and get some review of it. I don't really like to add members to the team when the only work I can see of theirs is an email requesting membership... I just want to see something that shows that you're likely to follow through with this package maintenance. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Debian Python Team join application
Hi Alexandre (2023.11.17_21:52:39_+) > My name is Alexandre and I am beginning into debian packaging. > > I started to package Gaphor which is a modeling GUI in Python. Also, Gaphas > is a python library that is used by Gaphor (and other projects). > > I started to initiate the work here, on my salsa account (Salsa login = > ahresse): > - https://salsa.debian.org/ahresse/gaphas > - https://salsa.debian.org/ahresse/gaphor > > I initiated two ITP for these two potential packages. (Still waiting for > the IDs). FWIW, these were both previously in Debian. Yeah, we could carry them in the team. I'm not going to review those packages right now. But request sponsorship for them in the usual channels (IRC / the list) and hopefully someone can help you. > However, I think these packages would better be hosted in the Python team. > Thus, I would like to join the Debian Python Team since I read > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > and accepted it. I'm always a little bit hesitant to add brand new Debian contributors to the team. In the past, I've sometimes done probationary membership or just access to a single repo. But the risk is fairly minimal. The main worry is that we get stuck with a package that nobody is maintaining. Added you. Welcome to the team! Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: pybuild and optional dependencies
Hi PICCA (2023.12.18_09:41:52_+) > When I compile the package, I got the dh_python3 computed runtime > dependencies from the install_requires. > > Now I would like to build this package but with the larix optional > dependencies. > > so I added all the dependencies in the Build-Depends, but dh_python3 still > produce the previous dependencies. > > How can I teach pybuild that I really want xraylarch[larix] ? This is really a dh_python3 question, it generates the dependencies. Pass --depends-section=larix (or recommends/suggests as appropriate). Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: bug in DebHelper or pybuild when deteting the plugin system.
Hi PICCA (2023.12.21_14:10:16_+) > "pyproject" That's a bug, the tab got included. I'll fix it now. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request for getting added to the team
Hi Gregor (2023.08.17_09:45:22_+) > herewith I request getting added to the Debian Python Team. > > The reason for this is that I'd like to package Darker [0] and possibly more > libraries and applications in the future. > > My Salsa login is "gdstr" [1]. Added, sorry I missed this before. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Preparing for Python 3.12
Hi Matthias (2023.12.03_14:03:44_+) > We probably will see some Python related build failures while binNMUing > around 600 packages to add 3.12 as a supported version. If you see builds > failing because of a missing 3.12 extension, please just wait a few days > until all the binNMUs are done. > > For the progress, see (ignoring the 'unknown' status) > https://release.debian.org/transitions/html/python3.12-add.html This is a great time for new Python Team contributors to get involved in helping to support Python 3.12. This is a time when upstream Python knowledge can be more helpful than Debian packaging experience. Look go down the list of packages and investigate the ones with a red line. Either they have failed to build (top of the list) or they haven't been built against 3.12 yet (bottom of the list). As we investigate these, we'll file FTBFS bugs against them (which usually show up on buildd.debian.org, below the builds). Usually the process is: 1. Read the bug to see the investigation so far. 2. Check the upstream bugtracker for related bugs. 3. See if there is a new upstream release or commit that promises to support Python 3.12 (or whatever the issue is). 4. Report back on the bug 5. Prepare an upload. We're mostly coordinating in #debian-python on IRC. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: cython 3.x (for Python 3.12)
Hi debian-python (2023.11.25_16:23:46_+) > As part of preparing for Python 3.12 in Debian, I've uploaded cython 3 > to experimental. > > I did some test-building of reverse dependencies, and quite a lot of > them fail. I should have said, all the build logs are here: https://people.debian.org/~stefanor/cython3/cython-3.0.5/ > Stefano Rivera >pystemmer (U) Fixed in 2.2.0.1-2 Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
cython 3.x (for Python 3.12)
As part of preparing for Python 3.12 in Debian, I've uploaded cython 3 to experimental. I did some test-building of reverse dependencies, and quite a lot of them fail. Out of 291 packages that build-depend on cython3: 104 attempted <- FTBFS 6 given-back<- build-deps aren't installable 1 skipped <- not for arm64 180 successful https://people.debian.org/~stefanor/cython3/cython-3.0.5/summary.txt https://people.debian.org/~stefanor/cython3/cython-3.0.5/stats.txt I re-tried those "attempted" failures, with cython 0.29.36 to find the regressions and: 32 attempted 1 given-back 71 successful https://people.debian.org/~stefanor/cython3/cython-0.29.36/summary.txt https://people.debian.org/~stefanor/cython3/cython-0.29.36/stats.txt So, that's 71 regressions with cython3. dd-list below. Please help us port to cython 3. If this isn't possible, Graham is preparing a cython-legacy package, to help the stragglers. But we're expecting that this won't have great Python 3.12 support... https://ftp-master.debian.org/new/cython-legacy_0.29.36-1~exp1.html Stefano Regression dd-list: Adrian Vondendriesch peewee (U) Alastair McKinstry adios Andreas Tille atropos (U) macs (U) python-cykhash (U) python-cytoolz (U) python-skbio (U) python-srsly (U) python-thinc (U) tombo (U) Anton Gladky sfepy (U) Antonio Valentino cyarray (U) pysph (U) python-ltfatpy (U) pyzoltan (U) B. Clausius pybik (U) Bastian Venthur kivy (U) Benjamin Drung rdma-core Boyuan Yang py-libzfs (U) ChangZhuo Chen (陳昌倬) python-feather-format (U) Dean Serenevy kivy (U) Debian Astro Team healpy montage pyregion Debian Fonts Task Force compreffor pyclipper Debian Games Team pygame-sdl2 python-sfml Debian Med Packaging Team atropos cyvcf2 macs nipy python-cykhash python-skbio tombo Debian Multimedia Maintainers pyliblo Debian PaN Maintainers opentsne Debian Python Modules Team fpylll Debian Python Team azure-uamqp-python indexed-gzip kivy mayavi2 numpy (U) peewee py-libzfs pybik pymssql pyreadstat (U) pystemmer python-cassandra-driver python-cytoolz python-feather-format python-hidapi python-line-profiler python-llfuse (U) python-openstep-plist python-pcl python-pomegranate python-srsly python-stack-data python-thriftpy uvloop (U) Debian QA Group xmms2 Debian Science Maintainers cyarray gensim h5py libgpuarray mpi4py-fft opentsne (U) petsc4py pyfftw pysph python-ltfatpy python-thinc pyzoltan sfepy statsmodels Debian Science Team cypari2 pandas pplpy Debian ZFS on Linux maintainers py-libzfs (U) Debichem Team mdtraj Diane Trout statsmodels (U) Drew Parsons mdtraj (U) mpi4py-fft (U) petsc4py (U) Emmanuel Arias python-cassandra-driver (U) Free Ekanayaka pyliblo (U) Gard Spreemann gudhi python-pyspike Geoffrey Thomas pymssql (U) Ghislain Antony Vaillant h5py (U) libgpuarray (U) pyfftw (U) python-line-profiler (U) Gianfranco Costamagna python-esmre Gijs Molenaar montage (U) Gordon Ball python-stack-data (U) gtkpod Maintainers libimobiledevice Hilko Bengen python-acora James Cowgill python-sfml (U) Jaromír Mikeš pyliblo (U) Jeremy Bicha compreffor (U) pyclipper (U) Jerome Benoit fpylll (U) Jochen Sprickerhof python-pcl (U) Jonas Smedegaard python-av Joost van Baal-Ilić pyreadstat Josue Ortega python-rtmidi Julien Puydt fpylll (U) pplpy (U) Kevin Murray python-skbio (U) Kunal Mehta python-libzim Leo Singer healpy (U) Liubov Chuprikova cyvcf2 (U) Luca Boccassi azure-uamqp-python (U) Markus Koschany pygame-sdl2 (U) Matthias Klose pygccjit Michael Hanke pandas (U) statsmodels (U) Michael Hanke indexed-gzip (U) Michael R. Crusoe macs (U) python-pomegranate (U) Mo Zhou h5py (U) Nikolaus Rath python-llfuse Nilesh Patra python-cytoolz (U) Ole Streicher montage (U) Olivier Sallou python-thriftpy (U) Paul Wise gensim (U) Picca Frédéric-Emmanuel opentsne (U) Piotr Ożarowski uvloop Rebecca N. Palmer libgpuarray (U) pandas (U) statsmodels (U) Richard Ulrich python-hidapi (U) Roland Mas python-orderedset Sandro Tosi numpy Sebastien Delafond opentsne (U) Stefano Rivera pystemmer (U) Steffen Moeller cyvcf2 (U) python-pomegranate (U) Tobias Hansen cypari2 (U) pplpy (U) Varun Hiremath mayavi2 (U) Vincent Cheng kivy (U) Vincent Prat pyregion (U) Ximin Luo cypari2 (U) fpylll (U) Yao Wei (魏銘廷) python-openstep-plist (U) Yaroslav Halchenko indexed-gzip (U) pandas (U) statsmodels (U) Yves-Alexis Perez libimobile
Re: Request for DPT salsa access
Hi weepingclown (2023.11.12_11:44:44_+) > I would like to request for DPT salsa access so that I can work on packages > with the Python Team. I have a few packages that I would like to work on and > am currently packaging yte and its dependency dpath-python. Added. Welcome to the team! Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join Python Team -Packaging disptrans and gradientmodel
Hi Yogeswaran (2023.11.08_16:51:47_+) > I'm packaging two Python packages that comprise analysis software and > models, making them accessible to the scientific community. I would like > to be part of the Python Team and maintain those two packages within the > team. Added, welcome to the team. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join Python Team, maintaining B2 packages
Hi Jiri (2023.11.06_10:03:03_+) > I'd like to join Python team to maintain B2 packages, specifically: Added, welcome. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join python team
Hi Santiago (2023.10.25_14:43:34_+) > I'd like to work on QA issues. Mainly FTBFS bugs, and mainly ensuring that > they are backported to stable if needed (with similar aim I joined debian-med > and go team). > > I've read Python Policy and accept it. Added, welcome! We could always use more people willing to work across the team, and not just trying to add their own packages with the minimum effort :) Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request access to salsa for python package for gitlab-emulator
Hi Ian (2023.10.23_12:09:59_+) > Hi, I'm the owner/maintainer of the gitlab-emulator project > https://gitlab.com/cunity/gitlab-emulator I'd like to request access > to Salsa to introduce a debian package for gitlab-emulator. Sorry, I'm afraid the Python Team doesn't gate salsa access. You need to get an account before joining the team. If your account hasn't been approved, go and chase the salsa team on #salsa on IRC. This does sound like a useful package that would be nice to have in Debian. I suggest filing an ITP bug and starting to work on it. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the Python Team
Hi Guilherme (2023.10.21_23:28:42_+) > I would like to join the Python Team on Salsa. I'm currently working on > packaging pytest-flake8-path and flake8-spellcheck. Added, welcome to the team. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join Python Team
Hi Alexander (2023.10.19_14:36:35_+) > I would like to join the Python Team on Salsa Added, welcome to the team Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join Python Team - Packaging Thumbor smart imaging service
Hi Raphael (2023.10.18_20:11:57_+) > I'm packaging a Python tool named Thumbor and I would like to enter the team > to upload the package under the Gitlab Salsa team umbrella. > My salsa login is: raphael.rossi https://salsa.debian.org/raphael.rossi > > I've read and agree with the Debian Python Team - Policy [1]. Added, too. Welcome! Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join Python Team - Packaging Thumbor smart imaging service
Hi Pedro (2023.10.18_19:55:38_+) > I'm packaging a Python tool named Thumbor and I would like to enter the > team to upload the package under the Gitlab Salsa team umbrella. > My salsa login is: devppjr <https://salsa.debian.org/devppjr> > > I've read and agree with the Debian Python Team - Policy [1]. Added, welcome. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Debian Python Team membership
Hi Carles (2023.09.27_22:58:42_+) > I'd like to join the team. Added, welcome! Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request: Debian Python Team membership
Hi Kurva (2023.09.25_18:09:27_+) > I'd like to join the team. During DebCamp(DebConf23) I started packaging > software's[1,2,3] which I'm using day-to-day in my robotics research > work. At the moment I'm packaging python dependencies of those > software's and I would like to maintain it under the team's umbrella. Added, welcome to the team! > I am also looking for a sponsor for the packages[4]. The best way to get sponsorship is through the RFS list in the topic of the #debian-python IRC channel. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join python team
Hi Thais (2023.09.15_08:44:02_+) > I would like to join the team to help maintain the packages Robber [1], > Delta [2] and Pytest-executable [3]. > My salsa login is: Thais-ra Added, welcome! Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the Debian Python Team
Hi Bailey (2023.09.11_03:02:52_+) > I would like to join the Debian Python team. Added, welcome! Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: request to join python team - packaging foxdot live coding tool
Hi Joenio (2023.09.10_07:30:34_+) > I'm packaging a Python tool named FoxDot and I would like to enter the team > to upload the package under the Gitlab Salsa team umbrella. Added you to the team, welcome! Sorry about the delay. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Mitchell's Debian Python Team join request
Hi Mitchell (2023.08.18_22:24:39_+) > My name is Mitchell and I would like to join the Debian Python Team. Sorry about the delay, added you. Welcome! > I would like to be a maintainer of https://tracker.debian.org/pkg/pyparted. If you do, that, please move it into the team git (you may need to ask a salsa admin to do that). Good luck! Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: DebConf 23: Python BoF
Hi debian-python (2023.09.10_05:23:12_+) > We have scheduled a Python BoF at DebConf23: > https://debconf23.debconf.org/talks/27-python-bof/ > It will be on Sep 16 (Sat): at 10:30 local time (05:00 - 05:45 UTC) We had the BoF, notes: https://salsa.debian.org/debconf-team/public/data/dc23/-/blob/main/etherpad/txt/27-python-bof.txt Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
DebConf 23: Python BoF
We have scheduled a Python BoF at DebConf23: https://debconf23.debconf.org/talks/27-python-bof/ It will be on Sep 16 (Sat): at 10:30 local time (05:00 - 05:45 UTC) I started getting together an agenda in: https://pad.dc23.debconf.org/p/27-python-bof Please help me to build it out. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Naming of python binary packages
Hi debian-python (2023.08.11_14:49:00_+) > I don't think the solution here is for your packages to use > distribution-derived names while everyone else's use the policy-defined > names. Can we rather come to a consensus on what we should be using? I should say, of course, that we have a history of groups of packages that diverge from this policy. e.g. the Django app packages, and some sphinx things (I think). Sometimes it makes sense to not name things python3-foo, but rather something more descriptive to the sub-community that the package is a part of. But this example was a run of the mill Python module, as far as I can tell. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Naming of python binary packages
Bringing bug 1023512 [0] to the Debian Python list: [0] https://bugs.debian.org/1023512 > > According to the Debian Python Policy Section 4.3, binary package > > names should be named after the *import* name of the module, not the > > PyPI distribution name. > Unfortunately, I do not agree at all with this policy. The import name has > no importance, and IMO, we should change that policy so that the package > name matches the egg-name rather than the import name. I wouldn't quite say it has no importance. It describes which part of the filesystem the package owns. I don't know the history of this policy offhand, but I presume it's also because not all Python modules come from PyPI, and we needed a standard way to address them. Also, we sometimes break PyPI distributions up into separate binary packages. They are closer to a source package than a Debian binary package. FIWIW: I am not convinced that Python made the right decision in allowing distribution names to diverge from import names, it tends to just create confusion. But that's neither here nor there. > In many places, that would make our life of package maintainer better. A > good example is all the oslo libraries in OpenStack, that all have a dot in > their egg-name, but an underscore in the import path (so that it works > better under python3). In this specific case, using the dash instead of the > dot would be really stupid and break many things, like automation for > dependencies. Presumably that can be solved with a few automated adjustments, (like the . -> _ transformation you describe). Having a straightforward distribution name -> package name mapping would make automating dependencies simpler, I agree. But we have tooling that handles that already: dh-python and its' pydist data. > In fact, this extend to all of the Debian Python module archive. > > If you want to discuss this further, please open a thread in the list. I don't think the solution here is for your packages to use distribution-derived names while everyone else's use the policy-defined names. Can we rather come to a consensus on what we should be using? My vote would be strongly towards maintaining the status quo of the policy-defined names. I don't see any strong argument for changing this. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: pybuild now supports meson
Hi Simon (2023.08.02_18:23:31_+) > On Wed, 02 Aug 2023 at 17:44:24 +0000, Stefano Rivera wrote: > > The latest upload of dh-python to unstable (6.20230802) includes a > > meson plugin, so pybuild can easily build a package multiple times for > > all supported Python modules. > > I don't think this is necessarily appropriate for a lot of the packages > in the dd-list: many of them don't install any public Python modules, > only private Python modules for internal use (often only for their > tests). It seems better for those to keep using Meson directly, to match > upstream expectations and give their maintainers full control over their > build options. Make sense. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
pybuild now supports meson
FYI: The latest upload of dh-python to unstable (6.20230802) includes a meson plugin, so pybuild can easily build a package multiple times for all supported Python modules. It should detect meson from the presence of a meson.build file. And it'll re-execute dh's meson driver for the build step for each Python version. Hopefully that helps... (and doesn't cause unexpected FTBFSs) Stefano CCed teams of maintainers of packages matching: grep-dctrl -F Build-Depends,Build-Depends-Arch,Build-Depends-Indep \ -s Package,Build-Depends,Build-Depends-Arch,Build-Depends-Indep \ -e '(\s|^)meson(\s|$)' | \ grep-dctrl -F Build-Depends,Build-Depends-Arch,Build-Depends-Indep \ -s Package \ -e '(\s|^)python3(-all)?(-dev)?(\s|$)' Debian GNOME Maintainers gedit gi-docgen gnome-music gtk-doc libgom libpeas rhythmbox totem Debian Input Method Team keyman Debian Python Team gtg meson-python Eberhard Beilharz keyman (U) Emilio Pozuelo Monfort gtk-doc (U) libpeas (U) rhythmbox (U) FingerForce Team libfprint Francois Mazen gtg (U) Iain Lane gnome-music (U) gtk-doc (U) libpeas (U) Jeremy Bicha gtk-doc (U) libgom (U) Jeremy Bicha gedit (U) gnome-music (U) rhythmbox (U) totem (U) Jeremy Bícha libpeas (U) Jordi Mallach rhythmbox (U) Keyman team keyman (U) Laurent Bigonville gedit (U) gnome-music (U) libgom (U) libpeas (U) rhythmbox (U) totem (U) Maintainers of GStreamer packages gst-python1.0 Marco Trevisan libfprint (U) Michael Biebl gtk-doc (U) libgom (U) libpeas (U) rhythmbox (U) totem (U) Sebastian Dröge gst-python1.0 (U) pitivi Simon McVittie gi-docgen (U) meson-python (U) xdg-desktop-portal (U) Sjoerd Simons libpeas (U) Tim Lunn gnome-music (U) gtk-doc (U) Ulises Vitulli libfprint (U) Utopia Maintenance Team xdg-desktop-portal -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team
Hi Robin (2023.04.20_19:29:43_+) Excuse a long delay, I missed this request at the time. Welcome to the team! Stefano > Hi, > > I would like to join the team. > > I want to help maintain Python packages due to my general interest in > Python. > > Here's a first contribution: > * > https://salsa.debian.org/python-team/packages/python-werkzeug/-/merge_requests/3 > > I've read the team's policy document and I accept it. > > Regards, > Robin -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the Debian Python team
Hi Daniel (2023.07.19_22:44:33_+) > I'd like to join the team. I've packaged and uploaded python-keycloak > recently, and I would like to maintain it under the team's umbrealla. > I've read the policy and my salsa handle is "dleidert". Added, welcome to the team! Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Access request
Hi matthias.geiger1024 (2023.03.13_23:27:38_+) > Sorry, > forgot this: > I have read and acknowledged the Debian Python Teams' policy. > My salsa login is werdahias. Added, welcome! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: #!/usr/bin/python3 vs virtualenv
Hi Julian (2023.03.05_10:47:08_+) > the NEWS file for python3.11. The > /usr/lib/python3.11/EXTERNALLY-MANAGED file is not mentioned there It was mentioned, but I've expanded on that in 3.11.2-5, and even more in the next upload: https://salsa.debian.org/cpython-team/python3/-/blob/master/debian/README.venv SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Generating stricter dependencies on python3-protobuf rdeps
Hi Adrian (2023.03.07_10:09:35_+) > Creating an own debhelper addon similar to dh_numpy3 would work for > automatically creating such dependencies, but is there any way for > python3-protobuf to inject such versioned runtime dependencies into > python3:Depends that does not require every rdep to manually add > addon usage? Yes, via pydist files, see /usr/share/doc/dh-python/README.PyDist They are consulted when translating Python .dist-info/.egg-info requires into Debian dependencies. You can see a (more complex) example in cffi: https://salsa.debian.org/python-team/packages/python-cffi/-/blob/master/debian/gen-backend-versions.py SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Join Python Team
Hi Vasyl (2023.03.01_15:21:18_+) > I'd like to join Python Team on Debian Salsa to continue my ongoing > contribution to NeuroDebian Project. Excellent, please read the team policy, it has instructions for joining the team. https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#id1 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: can pip be made using local Debian packages for any dependencies
Hi Philippe (2023.02.17_02:17:49_+) > Well in my case the main motivation was security (i.e. only using > code) that has security support by Debian. There is probably some value there. You're safer from a variety of attacks that *could* theoretically happen on PyPI. But, let me deflate Debian's reputation a bit here. Debian security support doesn't mean you're completely protected. There is probably a human behind a Debian upload that has vetted the upload and thinks it is safe. They thought this thing was useful to package for Debian (so probably not malware), and did some review to see that it installed itself correctly. They may have reviewed the upstream code, they may not have. They may review new upstream version diffs, they may not. (Generally, small things are easy to review, big complex things are impossible to.) For the security support, it's largely reliant on security issues being reported as CVEs, which security researchers usually do, but upstreams often fail to do. And then it needs a volunteer to find/figure out the fix and apply it to the version in Debian. So, again, there is definitely value here. If you're just using software from Debian stable releases, you know that some people have reviewed some of it. And you can be reasonably confident that you're using the same stack as some other people. But, on balance, for many problems the gains here aren't worth the pain of restricting yourself to Python modules published in Debian stable releases. > But shouldn't that use case also be interesting for Debian > Maintainers? Whenever their pip would need to download something from > PyPI, it would mean that some dependency is likely not fulfilled in > Debian (unless of course that Debian package is simply not installed). Generally speaking when I'm working on code, I install libraries in virtualenvs. This is what the upstream tooling expects and so it makes everything more convenient. All the work may be done in a container, but I'm not restricting myself to Debian packages. If I am using Debian packages for something, I'll install them with apt. I don't need pip involved. This is where I don't find the pip plugin idea that useful. Some people try to write software specifically to run on Debian stable, without any third party packages. For simple projects, this can work well. But, there are downsides. You often find you have to couple code changes to Debian's release cycle, which can get problematic. And nobody will understand what you're trying to do :) SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: can pip be made using local Debian packages for any dependencies
Hi Ian (2023.02.15_18:07:39_+) > My suggestion to the pip folks was a plugin system and extension point for > "install x" package that distros could provide implementations for Yeah, something like that could work. I don't know how useful it would be, though. Obviously, only root could use it (or root inside a container). And our selection of Python modules is far from complete. It's not Debian's intent to provide a mirror of PyPI within Debian. Generally speaking, we package the modules that we find useful for supporting building and shipping other python modules and applications. We'll only have a single version of each package. And they're usually not the versions developers want, because in any stable release they're probably out of date. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: can one change the path of generated entry point console_scripts
Hi Philippe (2023.02.14_00:13:08_+) > When I use dh-python to build a package that contains a pyproject.toml > and uses python3-setuptools for building like e.g. described here > https://setuptools.pypa.io/en/latest/userguide/entry_point.html > > and I use that entry point feature to have a script auto-generated > that calls my main():[project.scripts] > somescript = "package:main" > > is it possible to change the path were that script is finally put it > the package (i.e. not ./usr/bin/)? Just move it somewhere else later in the build? e.g. after dh_install. /usr/bin is where user-executable scripts should go, unless they belong in /usr/sbin or /usr/games. Internal scripts (that will be executed by the full path name) can live in /usr/share/ or similar. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: can pip be made using local Debian packages for any dependencies
Hi Philippe (2023.02.13_01:11:28_+) > On Sun, Feb 12, 2023 at 7:31 PM Donald Stufft wrote: > > > > I'm pretty sure that most if not all debian packages already ship > > the required information for pip to see them as installed, and if > > they are installed and they satisfy the dependency constraints that > > pip has for those projects, then they'll be used. Yeah, most packages should ship .egg-info/.dist-info. > Also: > $ dpkg -l python3-setuptools > ... > ii python3-setuptools 66.1.1-1 all Python3 Distutils > Enhancements > > Yet when I do e.g.: > $ pip install --editable . > Defaulting to user installation because normal site-packages is not writeable > Obtaining file:///home/test/example > Installing build dependencies ... error > error: subprocess-exited-with-error You sure it isn't doing an isolated build? Try --no-build-isolation. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Python 3.10 in bookworm
Hi Joost (2023.02.07_11:31:23_+) > Op Tue, Feb 07, 2023 at 05:52:21AM + schreef Danial Behzadi دانیال بهزادی: > > Does it worth trying to package pyenv for Debian? Ain't it against any > > rules? > > See "ITP pyenv" @ http://bugs.debian.org/978149 . I think the Python development community would be very happy to see this. Debian's selected Python releases don't meet all the needs of Python developers, who typically want access to all supported Python 3 versions (and possibly the next alpha), at all times. I'd be happy to review and sponsor uploads. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Bug#791635 python-policy: Please require namespacing source python module packages
Hi Scott (2023.01.29_01:34:54_+) > It'd be much simpler just to drop DPT or myself from uploaders and ignore > this, so that's probably the path I would take. The Debian Python Policy is independent of DPT. So, if adopted, that wouldn't help much... :) > Regardless, I don't think this is an appropriate use of FTP Team time/energy. +1. I could live with this being a recommendation for new source packages, but it don't really see the value in renaming existing source packages. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join team
Hi Robie (2023.02.05_20:47:01_+) > I'd like to join the team. Right now I'd like to just fix > python-service-identity in order to fix an FTBFS in one of my packages > (python-trustme, bug 1030487). It just needs a cherry-pick of > https://github.com/pyca/service-identity/commit/705f4af829adf4d1b6e44250d8039635a73199d5, > but it's about time I joined the team and did it. Added, welcome! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request for joining the team
Hi Danial (2023.01.15_09:54:38_+) > I am Danial Behzadi and I want to join Debian Python Team to maintain > package [python-fire](1) through this team as that's an orphaned > dependency of my current package [tractor](2) as [requested](3) by DDs. Added, sorry about the delay, welcome. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Python 3.10 in bookworm
Hi Julian (2023.02.05_10:38:23_+) > Why is the current intention not to ship the python3.10 package in > bookworm? Because we aim to have a single Python release supported in every stable release. > I was trying to run some experiments in a virtual environment a few > days ago, and it turns out that several of the Python packages I > needed do not yet run on Python 3.11. I was saved by being able to > run in a Python 3.10 venv and download all the required packages from > PyPI. If bookworm shipped without python3.10, I would not have been > able to do my work. Removing python3.10 from bookworm will seriously > affect many of our users in a similar situation to me. By the time bookworm releases, that probably won't be the case any more. But anything that gets removed from Debian, because it isn't ready yet obviously gets hurt in the process... SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Policy Proposal python3-supported-(min|max) virtual packages
Hi Scott (2023.01.14_19:34:59_+) > >dh_python3 would have been able to generate > >python3-tomli | python3-min-version (>= 3.11) > > > >instead of > >python3-tomli | python3 (>> 3.11) > > > >Then, once python3.10 was dropped from supported, python3 would > >Provides: python3-min-version (= 3.11), python3-max-version (= 3.11) > > And python3-min-version is a virtual package, so dpgk doesn't need any > special knowledge to do the right thing, right? I think that's reasonable. Yeah. > Typically though doesn't the python interpreter package provide modules that > are now incorporated? If python3.11 provides python3-tomli, won't that mess > this up? I can't recall how this was done historically, but the git history of python3 and python3-defaults doesn't show any provides like that. The only one I can see is python3-profiler, which is provided by python3, not python3.X. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Policy Proposal python3-supported-(min|max) virtual packages
Hi Scott (2023.01.14_17:22:42_+) > Take the example in #1027947. If this proposal had been in place > already, what would he have been the generated dependency and how > would it have worked? dh_python3 would have been able to generate python3-tomli | python3-min-version (>= 3.11) instead of python3-tomli | python3 (>> 3.11) Then, once python3.10 was dropped from supported, python3 would Provides: python3-min-version (= 3.11), python3-max-version (= 3.11) The >= vs >> isn't particularly relevant here. At the moment python3 (>> 3.11) effectively means >= 3.11, because it's always 3.11.something-something. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Policy Proposal python3-supported-(min|max) virtual packages
I have proposed a policy change that would permit dh_python3 to generate dependencies that apply to all currently-supported Python 3 versions: https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/13 Please review it and give me feedback. Matthias: I'm CCing you, because you had concerns when I mentioned this on IRC. But I hadn't provided a clear description of what I was proposing. Does this sound like something that works? SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Please add me to the salsa project
Hi Michael (2023.01.07_15:25:31_+) > please add me to the python-team/packages salsa project. > > I would like to maintain my python-related packages there. Added. Welcome! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Joining the team
Hi Sebastiaan (2022.12.23_13:16:38_+) > Please add sebastic to the team on Salsa, I'd like to help by pushing > commits for packages maintained in the team that are part of the dependency > chain of the packages I help maintain. Added, welcome! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Joining the team to maintain pydrive
Hi Sebastien (2022.12.09_12:18:38_+) > I would like to add pydrive [1] to Debian (I'm currently maintaining it for > Ubuntu as a opt-depends of deja-dup to be able to back-up on gdrive). I > think it makes sense for it to be under the python team umbrella. > I might occasionally contribute to updates or fixes on desktop components > maintained by the team. Added. Welcome to the team! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Requset to join team
Hi اوبونتو (2022.12.07_13:29:03_+) > I want to join Debian Python team to maintain python-fire package. Hi, thanks for your interest in joining the Python team. Please read the team policy: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#joining-the-team SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Help to package xdoctest
Hi Bo (2022.12.26_07:01:29_+) > W: python3-xdoctest: no-manual-page [usr/bin/xdoctest] Yeah, applications *should* have manual pages, but it's not required. If you need more tooling to build the manpage, it can wait until those tools are available in Debian. > P: xdoctest source: very-long-line-length-in-source-file 563 > 512 > [dev/outline.md:11] > X: xdoctest source: debian-watch-does-not-check-openpgp-signature > [debian/watch] I'd ignore those. > X: python3-xdoctest: application-in-library-section python [usr/bin/xdoctest] > X: python3-xdoctest: library-package-name-for-application [usr/bin/xdoctest] So, technically, xdoctest could be split into an xdoctest binary package (the command) and python3-xdoctest (the library). Personally, I don't bother to do that for niche tools like this. If it was a more user-oriented package, then it could make more sense to split it. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Python 3.11 for bookworm?
Hi Timo (2022.12.22_12:56:20_+) > > There have been rebuilds in Ubuntu that give us some idea of how much > > work remains. I think it's tractable, but also will have some package > > casualties. > I have some spare time right now, and I am happy to help > work on problematic cases, so hopefully nobody will feel left out in > the cold with their favorite packages. Offhand, the one I most expect trouble with is numba. We were reliant on upstream for the 3.10 transition, and probably will be for 3.11. Thanks for your help with pony ORM, Timo. I didn't think we'd be able to port that without upstream, but it did end up being tractable. I'm expecting to have more time in the upcoming weeks, too. So, release team, I still think we should go ahead! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Python 3.11 for bookworm?
Hi Sandro (2022.12.22_00:13:36_+) > It appears there has been little work in preparing the work to > introduce python3.11 from its maintainer, instead that works has been > pushed downstream to maintainers. That is, I'm afraid, the only realistic approach for handling new Python versions. It is too much work for one or two people to do. It needs the help of the team and upstreams to make it happen. Yes, a maintainer could take all this work on their shoulders, but if we require them to, I don't think we'll ship even vaguely current Python versions. > if we continue with the plan as described above, several python > libraries/applications maintainers will be left with the short end of > the stick and deal with an unknown amount of issues (upstream fixes > not available, not ready and or/ not released, rushed, etc) with less > than a month from the beginning of the transition freeze[2] That will almost certainly be the case, yes. So we have a trade-off to make between shipping a new Python upstream release, that many of our users would definitely appreciate, and having some libraries / apps miss the release, that many of our users would probably be affected by. > [2] also highlights at the very beginning "Plan your changes for > bullseye", this change appears as if it was not planned and we should > be skeptical to proceed without further (and in advance) understanding > of the impact it may have on Bullseye. We discussed this transition at DebConf 22, and decided to approach it the way that it has been approached. Where we currently are in the release, I would lean towards going through with the transition. So far, it seems to have been roughly as difficult as previous Python transitions. There have been rebuilds in Ubuntu that give us some idea of how much work remains. I think it's tractable, but also will have some package casualties. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team
Hi Malik (2022.12.04_17:03:05_+) > I would like to join the team to help maintaining packages and adopt > easyprocess [1] Welcome to the team, added you. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team or Request for sponsor
Hi Dean (2022.12.04_00:49:45_+) > Hello, would like to join the Debian python team. My immediate > interest is in updating the python3-kivy package and generally keeping > packages I use up to date. Added, welcome to the team. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team
Hi Domenico (2022.11.26_14:30:05_+) > I'd like to join the Python team, mainly to maintain the > python3-setuptools-golang package I've just ITPed. Added, welcome. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team
Hi Lance (2022.11.08_12:30:17_+) > I would like to formally request to join the Debian Python Team. Added, welcome. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team
Hi Legner, (2022.09.20_09:25:16_+) > I'm working with Claudius Heine (cmhe) and would like to join the DPT > to help maintain packages; currently I'm interested in packages related > to the TPM (tpm2-pytss) and cryptography (python-cryptography) but I > may get involved with other topics in the future. Added, welcome. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team
Hi Stanislas (2022.09.19_19:09:40_+) > I hereby request to join the Python Team. Added, welcome. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join Python team on Salsa
Hi John (2022.11.25_20:27:32_+) > I would like to join the team primarily to maintain pygopherd in Debian. Welcome! Added to the team. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join team
Hi Miah (2022.11.11_13:12:46_+) > Looking to update and maintain the nagstamon package, since I use it > daily and the packaged version crashes with icingaweb2. Added. Welcome! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Join python team
Hi Christopher (2022.11.02_09:21:26_+) > I'd like to join the python team and package some libraries > (e.g. https://github.com/esphome/aioesphomeapi) and their dependencies > for Debian. Added, welcome. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Joining the Debian Python Team
Hi Alper (2022.11.01_23:44:48_+) > I'm packaging "depthcharge-tools", a Python project of mine that manages > the ChromeOS bootloader to make Debian natively bootable on Chromebooks. > My sponsor already cloned it to the python-team/packages Salsa namespace > and uploaded it to NEW with the Python Team as Maintainer. I want to > join the team to keep maintaining it as part of the team. Added! Welcome to the team. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to Join
Hi Peter(2022.10.23_22:01:15_+) > Hello, > I'd like to join the maintenance team for Python. Added, welcome. And sorry about the delay. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Joining the team
Hi Marcin (2022.10.20_06:56:35_+) > I want to join the team to maintain a new package, ledgerhelpers [1] > within the team. > My Salsa login is porridge Added, welcome! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Joining the team
Hi Andrea (2022.09.24_10:09:26_+) > I'm [currently packaging][1] a C++ library which depends on [Poxy], a > documentation generator currently not packaged by Debian. I don't know much > about Python (I especially don't know anything about its ecosystem), so I > believe that joining the team is a good way to learn a bit how to package > Python programs. Added, welcome. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join python-team
Hi Mohd (2022.12.03_05:37:30_+) > Just came to know about the sprint happening and I thought to use it as an > opportunity to join and contribute to the team :) Added, welcome. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: join the team
Hi Nilson (2022.09.27_03:28:59_+) > I hereby request my membership as a team member! > > I already keep some packages with the team, and I'm willing to help in any > way I can! Added you, welcome. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join Debian Python Team
Hi kkremitzki (2022.10.05_17:29:50_+) > Hello, I would like to join the Debian Python Team to help with general Python > package maintenance. There is a lot of overlap with what I already work on in > the domain-specific Debian Science Team. Added, welcome! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the Python Team
Hi Sebastien (2022.03.30_20:43:25_+) > I would like to join the Debian Python Team in order to migrate > python-ncclient and python-xmltodict¹ inside the team. > And also click-option-group (new dependency of synadm²) Apologies for the very long delay. Added you to the team. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team - salsa: tai271828
Hi Taihsiang (2022.12.02_22:51:03_+) > I would like to join the Debian Python team for the sprint today and > this weekend, and help with more packaging work in the future. Added. Thanks for the help. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Bug#1022526: python-ssdeep: FTBFS: distutils.errors.DistutilsClassError: command class must subclass Command
Hi Helmut (2022.11.04_11:36:41_+0200) > And no, updating it to 3.4 does not fix the ftbfs. Updating it to 3.4.1 might. It includes this commit: https://github.com/DinoTools/python-ssdeep/commit/fce02106c07ff56a84097dec0df02fb00ef69dc7 which moves the setuptools import above the first distutils import, which should resolve this issue. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Python 3.11 is now a supported release in unstable
We've started the Python 3.11 addition transition. https://release.debian.org/transitions/html/python3.11-add.html The release team will do binNMUs to rebuild C extensions to add 3.11 support. To help the transition, please: 1. Avoid starting any Python-related transitions until we get this migrated into testing. 2. Fix arch-any python packages that FTBFS 3. Fix any python3.11 compatibility bugs that come up. I'm aware of a number of FTBFS caused by setuptools >= 60, at the moment. If there is a distutils-related exception, they're usually fixed by importing distutils after setuptools. I've been looking for them and NMUing. Feel free to help :) SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: zope.testrunner: FTBFS: AttributeError: 're.Pattern' object has no attribute 'replace'
Hi Nilesh (2022.10.01_09:48:50_+)
> > > File "/usr/share/dh-python/dhpython/depends.py", line 228, in parse
> > > args += " -X '%s'" % pattern.replace("'", r"'\''")
> > > AttributeError: 're.Pattern' object has no attribute 'replace'
> > > make[1]: *** [debian/rules:20: override_dh_python3] Error 1
>
> This looks like a bug with dh-python itself. Maybe this needs to be "sub"
> instead of "replace", similar
> string regex replaces at a couple more places.
That looks like fallout from my migration of dh_python* to argparse. I
changed the objects used to represent regexes, but clearly didn't test
-X.
I'll upload a fix, now.
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Re: Enabling salsa-ci on all Debian Python Team repos
Hi Carsten (2022.09.23_05:01:05_+) > sure, that's a killer argument that I can't really argue against. But that > is not the point for me. > > For all these checks we already have existing infrastructure, running the > same also by a pipeline job isn't helping at all if it's not clear how to > handle the fallout (we already mostly have seen in other places too!). Yeah, it's similar for me. I test build locally, my sbuild setup does most (but not all) of the same checks as gitlab CI. Then when I'm happy I push and upload. If there is any gitlab CI, it runs too late. And if it fails, I usually don't even bother to investigate, because I trust my local setup implicitly. Anything that's failing in gitlab CI is almost certain to be a failure specific to gitlab CI. I do see a value in having it enabled globally, for the team, though. 1. It can make the team packages friendlier to new contributor team members who don't have a setup like that. I would like to see our team act more like a team and have people contribute to packages that they don't regularly maintain. 2. Getting a test failure on a merge-request catches contributor mistakes early. I love having CI on incoming patches like that. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team
Hi Chiara (2022.09.06_07:33:59_+) > I would like to join the Debian Python team. > I am currently maintaining the python package sphinxext-opengraph [1] and I > am contributing to the updates of numpydoc [2]. Added, welcome! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team
Hi Blair (2022.09.01_13:18:50_+) > I would like to join the Python team, to help update and maintain > the Python packages in Debian as a daily Debian and Python user, > to learn how Debian works, and to contribute to the community. > > I have read and accept the team's policy. Added, welcome to the team. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: PYTHONPATH with cmake build
Hi PICCA (2022.08.30_16:02:01_+)
> cd build
> cmake ../modules/dxtbx
> cmake --build . --target install
> pip install ../modules/dxtbx
This package essentially has 2 build systems, camke for the C++ stuff
and setuptools for the pure-python. I don't see any integration between
the two (which is quite annoying, the upstream really should fix that).
pybuild knows how to drive distutils, and knows how to drive cmake, but
not both together. Ideally, you do want to use pybuild when building
Python extensions, so you can do them for all supported Python versions.
So, can I suggest something like this?
#! /usr/bin/make -f
export PYBUILD_NAME=dxtbx
export PYBUILD_SYSTEM=distutils
export PYBUILD_AFTER_CONFIGURE=cmake -DPython_EXECUTABLE=/usr/bin/{interpreter}
-S . -B {build_dir}/lib
export PYBUILD_AFTER_BUILD=make -C {build_dir}/lib
export PYBUILD_BEFORE_TEST=cp {build_dir}/lib/lib/*.so {build_dir}
%:
dh $@ --with python3 --buildsystem=pybuild
You'll need something for the install too, but I didn't get that far, as
the tests fail (due to missing dependencies in Debian).
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Re: Join the team
Hi Claudius (2022.08.30_09:56:12_+) > I would like to join the python team to help maintain packages, currently > related to tpm2-pytss but will potentially extend to other python packages > like python-cryptography and others. Added, welcome! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Joining the team
Hi Emanuele (2022.08.29_19:39:17_+) > I'd like to join the debian-python team to help with general QA work on > all packages. > > My salsa login is ema. Added, welcome! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: is sysconfig.get_path('purelib') local ?
Hi Jerome (2022.08.28_12:41:18_+) > > > You want to propagate the change to /usr/share/aclocal/ax_python_devel.m4 > > > distributed in autoconf-archive . > > > (I localized the error there.) > > Can you point at a package that FTBFS because of this? Or something > > easily reproducible. It's really useful to have test cases, when > > changing code you've never seen before. > My brand new package graph-tool [1] that experienced a FTBFS during > what should be a quiet 'Upload to unstable'. Thanks, that's a beast of a package that wanted *all* my memory when building with parallel=16 :) But it gave me a good starting point to drive the autoconf macro. Filed: https://bugs.debian.org/1018298 (and forwarded it upstream) SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: is sysconfig.get_path('purelib') local ?
Hi Jerome (2022.08.27_21:24:48_+) > You want to propagate the change to /usr/share/aclocal/ax_python_devel.m4 > distributed in autoconf-archive . > (I localized the error there.) Can you point at a package that FTBFS because of this? Or something easily reproducible. It's really useful to have test cases, when changing code you've never seen before. > Otherwise, is there any keyword to get /usr/lib/python/dist-packages > via sysconfig.get_path ? May we pass 'distlib' ? > I guess it would be useful. I quote from that email: > The solution in build tools is to explicitly select the posix_prefix > scheme, and specify the appropriate prefix (/usr or /usr/local). For > build tools that default to /usr/local, this should be all you need to > do. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
