Handling sponsorship requests by new contributors (was: Request for Python Team assistance in Debian Mentors)
Hi, On 2024-06-13 13:13:33, Pierre-Elliott Bécue wrote: Andrey Rakhmatullin wrote on 13/06/2024 at 12:48:36+0200: I'm always hesitant to look at Python module RFSes because on one hand I would like all of them to be in the team but on the other hand I'm not sure if it makes sense to write "please move this to DPT" or "please consider moving this to DPT", especially for people who are first time packages without a team membership. Perhaps we should discuss this and find a single recommended practice for such packages. I really think we should encourage newcomers to apply joining the team and put their packages there. What we could do if the idea of giving broad commit rights to newcomers poses issues is to create a specific namespace in python-team for newcomers. (then we'd need to have some migration plan and then oh dear) I agree with both of you that it would be good to encourage new contributors to put their Python packages in the Python team namespace. If one does not want to grant push rights to all team repositories to newcomers, an alternative to a separate namespace would be that a sponsor (who is a member of the Python group on salsa) creates a repository in the Python team namespace (after approval by the sponsored person), moves the repository contents to the created repository and grants the right to push to this repository to the sponsored person. During that phase, new contributors can only submit changes to other repositories in the team namespace by other means, e. g. by submitting merge requests (although MRs are not ideal for all cases, e. g. updating packages to new upstream versions). After a couple of good contributions access to all team repositories could be granted if there is interest in broader team contributions (rather than focusing on one's own packages). This sketched procedure is e. g. followed by the security tools packaging team (see e. g. Samuel Henrique's explanation on [0]). It does not involve an additional migration step but adopting this by the Python team probably requires rethinking the team policy acceptance workflow. Best regards, Peter [0] https://lists.debian.org/debian-security-tools/2021/10/msg3.html
Re: Bug#1022526: python-ssdeep: FTBFS: distutils.errors.DistutilsClassError: command class must subclass Command
Dear Helmut, On 04.11.22 10:36, Helmut Grohne wrote: Would someone handle dnstwist, which is the only remaining dependency? I opened a corresponding upstream request: https://github.com/elceef/dnstwist/issues/170 Peter
Re: How to run unit tests?
Hi Andrey, thanks for sharing your thoughts. On 08.12.20 21:43, Andrey Rahmatullin wrote: You didn't explain what actual problems do you have, but https://github.com/lark-parser/lark/issues/792 suggests that some way you used was skipping some of the tests? I am not familiar enough with Python unit testing for a solid judgement but I find it disturbing that the outcome of the test suite depends on the way you run it. I wonder whether this is a) due to a problem in the test suite, b) due to a problem somewhere in the tested code, c) by construction because the three different ways to run the test suite are not equivalent? Upstream uses option 3 in its CI testing [2] and did not see any issues with lark release 0.11.1. dh_auto_test seems to use option 2 by default (for the pybuild build system). For autopkgtest I have chosen to use option 1. The latter two options both fail for version 0.11.1. Which is good? After applying a patch provided by upstream [3], also option 2 works but option 1 still fails. Which is good or bad? I'm not sure. I am asking myself the same questions. That is why I am asking for advice here. :-) Upstream suggested to change the way the (autopkgtest) tests are run [4]. So are you asking only about autopkgtests, not build-time tests? Rereading it I think one should not constrain the question to autopkgtests but also consider build-time tests. Is there something like a general recommendation on what is the best way to run Python unit tests? No (except "whatever the upstream CI runs"). This would vote for option 3: pythonX -m tests Best regards Peter
How to run unit tests?
Dear Python experts, in trying to update the python-lark package [0] to the most recent upstream version, an interesting issue regarding unit tests showed up [1]. Depending on how one runs unit tests they either fail or not. Tried options are: 1. PYTHONWARNINGS=d pythonX -m unittest discover -v tests 2. pythonX setup.py test 3. pythonX -m tests Upstream uses option 3 in its CI testing [2] and did not see any issues with lark release 0.11.1. dh_auto_test seems to use option 2 by default (for the pybuild build system). For autopkgtest I have chosen to use option 1. The latter two options both fail for version 0.11.1. After applying a patch provided by upstream [3], also option 2 works but option 1 still fails. Upstream suggested to change the way the (autopkgtest) tests are run [4]. I am reluctant to do this without a better understanding of the differences between the above three options. Can anybody shed some light on the differences between them? Is there something like a general recommendation on what is the best way to run Python unit tests? Peter [0] https://salsa.debian.org/python-team/packages/python-lark [1] https://github.com/lark-parser/lark/issues/792 [2] https://github.com/lark-parser/lark/blob/0.11.1/.github/workflows/tests.yml#L28 [3] https://github.com/lark-parser/lark/pull/782 [4] https://github.com/lark-parser/lark/issues/792#issuecomment-739504664
Re: embedded-javascript-library usr/share/doc/python3-lmfit/html/_static/language_data.js please use sphinx
Hi Frederic, On 03.08.20 17:04, PICCA Frederic-Emmanuel wrote: > I use sphinx, so my question is: do you know how to fix this issue have a look at https://bugs.debian.org/964013#35 and the following comment. Best regards, Peter
RFS: python-lark
Dear DDs, I prepared packaging for the parsing library python-lark (ITP bug #941657). It is needed to bump the versions of prewikka [0] and charliecloud [1]. The git repository is available on https://salsa.debian.org/python-team/modules/python-lark It would be great if someone could review the code, provide feedback and - once everything looks fine - upload it. Thanks, Peter [0] https://tracker.debian.org/pkg/prewikka [1] https://tracker.debian.org/pkg/charliecloud
Re: name change: python-lark-parser -> python-lark
Hi Simon, thanks for your helpful input. On 30.12.19 18:04, Simon McVittie wrote: > There are two options: > > * If "lark" on PyPI is a dead project, or otherwise something that is never > going to be useful to package in Debian for some reason, then perhaps it's > safe for the lark parser to claim the python3-lark name. The last commit happened six years ago. It might be dead but I am not sure. > * Otherwise, if its PyPI name is lark-parser, then I would personally > recommend asking the upstream developer to rename the module you import > to lark_parser (or maybe larkparser if that's preferred), and packaging > it as python3-lark-parser (or python3-larkparser), optionally with > compatibility glue to make "import lark" continue to work (which might not > get packaged in Debian). I opened a corresponding issue: https://github.com/lark-parser/lark/issues/505 Peter
Re: name change: python-lark-parser -> python-lark
Hi Thomas, I am including the Python team to tap their expertise. For those not familiar with the topic: We are referring to https://github.com/lark-parser/lark which is not in the Debian archive yet (packaging work is still ongoing). On 29.12.19 23:10, Thomas Andrejak wrote: > Why changing the name ? it's named lark-parser in pypi. >From the beginning I felt uncertain how to call the source package: python-lark-parser or python-lark. > Moreover, in pypi, there already is a "lark" module which is not lark-parser When filing the ITP bug I decided to choose python-lark-parser for exactly this reason although upstream seems to call its software simply "Lark" in most places. Later I became aware of https://bugs.debian.org/945823 which says: "use the name you import in preference to the name from the PKG-INFO". That is why I decided to change the name to python-lark. But given the PyPI name clash this is certainly not optimal either. So this seems to be a particular unfortunate case. Any advice is welcome! Peter > Le sam. 28 déc. 2019 à 05:03, Peter Wienemann <mailto:foss...@posteo.de>> a écrit : > > Following the suggestions in > > https://bugs.debian.org/945823 > > I have changed the name from python-lark-parser to python-lark. > > The new repository URL is > > https://salsa.debian.org/python-team/modules/python-lark > > Peter
Re: Bug#943785: RFS: python-pyjsparser (ITP bug #943785)
Hi Nick, have you already found time to look into the revised packaging described in [0] and [1]? Cheers, Peter [0] https://lists.debian.org/debian-python/2019/11/msg00048.html [1] https://lists.debian.org/debian-python/2019/11/msg00106.html
Re: Bug#943785: RFS: python-pyjsparser (ITP bug #943785)
Hi Nick, On 11.11.19 20:01, Peter Wienemann wrote: * d/copyright - the only copyright dates I can see in the source are 2014-2015 Judging from the source files, you are right. Judging from the git commit history I see commits between 2015 and 2019. What is a better guideline for copyright years: copyright notices in the source or the git history? Maybe it would be best to combine both information which would yield 2014-2019. Once I know what should be used, I will update the copyright file accordingly. I asked on IRC how to handle this situation. The answer was: Use the copyright years from the copyright notices in the source. I have just pushed a commit with the corresponding change to salsa. Peter
Re: Bug#943785: RFS: python-pyjsparser (ITP bug #943785)
Hi Nick, thank you very much for taking the time to review the packaging and providing such detailed and helpful feedback. On 10.11.19 00:02, Nick Morrott wrote: > Thank you for your work in packaging python-pyjsparser. Out of > curiosity, what are you using to be build your package? My primary motivation for packaging python-pyjsparser is to be able to bump the version of Charliecloud: https://tracker.debian.org/pkg/charliecloud Version 0.10 of Charliecloud adds new dependencies, including lark-parser which in turn depends on python-js2py which in turn depends on python-pyjsparser. > I checked out the package and built it - your work looks good, and the > build was successful. I then ran it through lintian, Debian's package > linting tool which you should get into the habit of using before > uploading to salsa (and once you're a DM/DD, also before uploading to > the archive). I have configured my sbuild setup in such a way that it always runs lintian after builds. But thanks to your feedback I noticed that I was running lintian with a too high display threshold such that the only lintian feedback I received was "I: Lintian run was successful." and "Lintian: pass" despite of the issues you discovered. I have tweaked the lintian options in my ~/.sbuildrc now. Hopefully I will not miss similar issues in the future. > * d/control > - no Rules-Requires-Root field [lintian] Fixed. > - the extended package description should probably include details > about the library's key features/support [lintian] Done. > * d/copyright > - the only copyright dates I can see in the source are 2014-2015 Judging from the source files, you are right. Judging from the git commit history I see commits between 2015 and 2019. What is a better guideline for copyright years: copyright notices in the source or the git history? Maybe it would be best to combine both information which would yield 2014-2019. Once I know what should be used, I will update the copyright file accordingly. > - you can add the Upstream-Contact field to the header Done. > * d/rules > - pybuild can provide verbose output with "export PYBUILD_VERBOSE=1" Added. > * d/upstream/metadata > - please add and complete this file - there are plenty of examples > in the team's salsa project [lintian] Done. > * d/watch > - +1 for asking upstream to version their releases on github Thanks! Let's see what happens. > - the additional (commented) scaffolding inserted into the file by > dh-make can be removed to leave only the version line and the URL to > check [lintian] The idea behind leaving the Github lines as comment was that I could easily switch to following Github tags/releases provided that upstream decides to publish them for future releases. But since the "" string triggers the lintian complaint and replacing this placeholder would be just guessing until upstream actually provides releases on Github, I removed all comments related to this. This also makes lintian happier. :-) > - as this is a version 4 watch file, we can take advantage of new > variable substitutions for the version and extension fields, so that > the URL to check would look like: > > https://pypi.debian.net/pyjsparser/pyjsparser@ANY_VERSION@@ARCHIVE_EXT@ Very convenient variables. Changed accordingly. > * upstream changelog > - there is no upstream changelog To my knowledge upstream does not provide such a file. > * documentation/examples > - There is no documentation at all, aside from the simple example in > the README. Perhaps this snippet could be installed as an example when > installing the package? Done (although I am not sure whether the way I implemented it is the recommended way to do it). Suggestions how to improve the code are welcome. > * tests > - there are no tests to run at build time (and therefore no > autopkgtests to run for continuous integration whenever the package's > dependencies are updated). Looking at the github repo there seems to > be a significant testsuite that should really be available in the > Debian source package to take advantage of autopkgtest. [lintian] The testsuite available on Github requires js2py which is not in the Debian archive yet (thus the testsuite introduces a circular dependence: pyjsparser <-> js2py). js2py is the next package on my to-package list (see above). I see two options to move forward: 1. Wait for js2py being packaged and provide autopkgtests for pyjsparser once js2py is available. 2. Install js2py using pip for the test. None is really nice in my opinion. Which option do you prefer? > I hope you find this useful - if you have any questions don't hesitate > to ask the team (the Python list is visible and archived, IRC may get > a quicker answer...). I'm a new DD and there are likely some things > that the more experienced members of the team will notice. Yes, your feedback was definitely very helpful and allowed me to learn new things. Thanks, Peter
RFS: python-pyjsparser (ITP bug #943785)
Dear Python team, I prepared packaging for python-pyjsparser (ITP bug #943785) on https://salsa.debian.org/python-team/modules/python-pyjsparser It provides a fast JavaScript parser written in Python. It would be great if a DD could review the code, provide feedback and (if everything looks OK) upload it. Thanks, Peter
Joining the DPMT
Hi, I am one of the maintainers of the Charliecloud package [0]. The most recent version of Charliecloud (0.10) has added new python dependencies (lark [1] and its dependencies). Some of them are not yet available in Debian. My salsa login is wiene-guest. I read the DPMT policy [2] and I accept it. Peter [0] https://tracker.debian.org/pkg/charliecloud [1] https://github.com/lark-parser/lark [2] https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
