request to join python team - packaging foxdot live coding tool
Hello Python Team, 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. My salsa login is: joenio I've read and agree with the Debian Python Team - Policy [1]. FoxDot ITP bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015898 [1] https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst Thanks, -- Joenio Marques da Costa Invited Researcher at Université Gustave Eiffel Research Software Engineer at LISIS Developer at CorTexT platform & RISIS Core Facility http://umr-lisis.fr/membre/joenio
German Debian Forum : How to do packaging ("HowTo: Wie paketiert man eine Python Bibliothek?")
Hello, I would like to inform about that in the German Debian Forum is a thread explaining how to package a python library for official Debian. https://debianforum.de/forum/viewtopic.php?t=187764 Kind Christian
Re: DebConf 23: Python BoF
On Sunday, September 10, 2023 1:23:12 AM EDT Stefano Rivera wrote: > 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. As of today (assuming my count approach worked correctly), there are 5,118 source packages in Debian that B-D/B-D-I dh-python. Of those, only 813 B-D/B- D-I pybuild-plugin-pyproject. I think it's very premature to be considering something at 20% usage for any kind of default. I don't think it's a good idea in any case. The only advantage I can see is that people would not have to add pybuild-plugin-pyproject to B-D/B-D-I anymore. If the build backend is anything other than setuptools, people will still have to add that, so I don't see much of an advantage here. In cases where both setup.py and pyproject.toml are provided, these packages might start to FTBFS. On the disadvantage side, any package that does use setuptools has a pyproject.toml that has not been migrated by the maintainer (packages with both setup.py and pyproject.toml are not rare) will be automatically switched with unpredictable results. The best case scenario is nothing changes. I don't really see a lot of upside here. Let's not. We have lintian checks to let maintainers know they can update to the newer system. I think that's sufficient. Scott K signature.asc Description: This is a digitally signed message part.
Publishing multiple packages with aptly in Salsa CI
Hello, A few weeks ago, I asked about techniques for making new packages available to other new packages so that the autopkgtest job could be run successfully in a pipeline in the Salsa CI environment. Eventually, this was made to work by taking advantage of the aptly job defined in the standard Debian CI pipeline. To recap, the aptly job publishes the package built during the execution of a pipeline by creating a dedicated apt-compatible package repository just for that package. Such repositories can then be made available to various jobs in the pipeline of another package, allowing the successful installation of that package and its dependencies, including new packages, and the successful execution of jobs like autopkgtest. However, one other thing I wanted to achieve was to take the complete set of new packages and to publish them in a single package repository. This would allow people to install and test the built packages in a more convenient fashion than asking them to hunt down each built package from job artefacts or to build the packages themselves. Obviously, the aptly job in the standard Debian CI pipeline publishes a single package (or maybe a collection of packages built from a single source package), but I wanted to aggregate all packages published by a collection of aptly repositories. Fortunately, it seems that this is possible by augmenting the existing aptly job definition as shown in the following file: https://salsa.debian.org/moin-team/moin/-/blob/debian/master/debian/salsa-ci.yml Ignoring the "ls" command which was there to troubleshoot this rather opaque environment, one script adds repository definitions to the apt configuration, whereas the other performs the appropriate "apt source" and "apt download" commands, making the source and binary package files available for aptly to process. Consequently, aptly will include all the dependency packages in the final package repository. (Since the scripts reside in my package's debian directory, I also had to request the availability of the Git repository for the job. Generally, I have found it challenging to have these job definitions make effective use of scripts due to environmental inconsistencies.) I imagine that publishing packages like this is not particularly desirable, at least if done widely, but I hope it shows that it can be done relatively easily, at least if all the right incantations have been discovered. Paul
Request to join the Debian Python Team
Hello, To start, apologies if this has sent multiple times, but I don't see my previous email on the mailing list archive. I would like to join the Debian Python team. Why I want to join: The main reason is to contribute the hyfetch package to Debian and maintain it (related ITP bugreport linked below), but I am also happy to help in other places that it is needed. Though I do not have other specific packages in mind. My Salsa login: Catumin (https://salsa.debian.org/Catumin) I have read the policy.rst file and agree to it. ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051250 Thank you, Bailey Kasin
