Re: Request to join the Debian Python Team
On 2024-09-12 19:51, Soren Stoutner wrote: I would like to join the Debian Python Team to help maintain the python-trezor package. I am the maintainer of the electrum package, which depends on python-trezor, but the version in Debian is so out-of-date that it is currently non-functional. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062442 I have communicated with Richard Ulrich, the current uploader, who indicated he would appreciate help maintaining the package. My Salsa login is soren. I have read have read https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst and accept it. Welcome to the team! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Bug#1024971: pybuild: should fail when the result of running tests is "Ran 0 tests in 0.000s"
On 2024-09-08 13:21, Scott Kitterman wrote: Thanks. I think some variation of #4 is the right answer. Causing a thousand packages to FTBFS isn't great. I would find it easier to have an environment variable (similar to what you suggested for #3) instead of adding an override, but that's more of an implementation detail. Scott K Having an opt-in environment variable means all the packages using unittest will eventually need to add it. What is the end goal? Once we have enough buy-in we flip it around? I agree breaking tons of packages isn't great, but I don't want us to haul crud forever either :( -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Debian Python Team Join Request: Jason Blackwell
On 2024-09-09 16:16, Jason Blackwell wrote: Hi all, I would like to join the Debian Python Team to help maintain the pmbootstrap package to start. I have interest in working on other packages as well once I get the process down. I would like to tackle this bug first: https://bugs.debian.org/cgi-bin/ bugreport.cgi?bug=1079785 Followed by: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069772 If approved, I will work to consolidate these merge requests and make changes directly to the branches for the 2.3.1 pmbootstrap update as recommended on #debian-python. https://salsa.debian.org/python-team/packages/pmbootstrap/-/ merge_requests/1 https://salsa.debian.org/python-team/packages/pmbootstrap/-/ merge_requests/2 https://salsa.debian.org/python-team/packages/pmbootstrap/-/ merge_requests/3 Salsa login: @blackwell https://salsa.debian.org/blackwell I have read https://salsa.debian.org/python-team/tools/python-modules/ blob/master/policy.rst and I accept the terms. Please let me know if there is any other information I can provide, or if you have ideas on other packages/things that I can assist with. Regards, Jason Blackwell Background: https://www.linkedin.com/in/blackwelljason/ https://github.com/blackwellops/ Commits for Fedora pmbootstrap 2.3.1 update: https:// src.fedoraproject.org/rpms/pmbootstrap/ c/613271ac8c52aa5d3ba03ba472b53e26ebe2451b?branch=rawhide Current Maintainer for pmbootstrap on Gentoo GURU: https://github.com/ gentoo/guru/blob/master/dev-util/pmbootstrap/metadata.xml Welcome to the team :) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Python3.12 and a half
On 2024-08-23 4 h 19 a.m., Julian Gilbey wrote: On Fri, Aug 23, 2024 at 09:55:17AM +0200, Matthias Klose wrote: On 22.08.24 21:37, Alexandre Detiste wrote: Hi, Would it be possible to remove 2to3 from Python3.12 without waiting for 3.13 ? I see in the meantime a new usage was brought back. I'll check if this "slimit" package can be easily switched to python3-fissix; which is a 2to3 fork that is already used to keep python3-nose artificially alive. I'd like to avoid addressing a single module. 3.13 has a whole bunch of modules that are removed in the standard library. What's the status of filing bug reports for all these removed modules? Matthias Lintian does do a check for them: uses-deprecated-python-stdlib but beware of false positives, in particular for uu and crypt; see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077324 (which is now pending an upload). (There used to be a website lintian.debian.org where you could search reports by tag, but that doesn't seem to exist any more, and I haven't had any luck searching with UDD.) Hi, This is probably what you were looking for: https://udd.debian.org/lintian-tag.cgi More specifically: https://udd.debian.org/lintian-tag.cgi?tag=uses-deprecated-python-stdlib As for #1077324, in theory I just pushed the fix to the buildds. In practice, this is my first Lintian release, so we'll see how that goes :P When/if 2.118.1 gets in the archive, I'll ping Luca to update UDD's lintian version. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Policy Change Proposal: Running the upstream test suite
On 2024-08-16 6 h 44 p.m., Pierre-Elliott Bécue wrote: Hi, Louis-Philippe Véronneau wrote on 15/08/2024 at 00:09:15+0200: On 2024-07-29 4 h 53 a.m., Louis-Philippe Véronneau wrote: Hello, As discussed during the DebConf24 Python BoF, I'm submitting this change to the policy to require the use of the upstream test suite, both during the build process and as an autopkgtest. You can find the MR here: https://salsa.debian.org/python-team/tools/python-modules/-/ merge_requests/24 People present at the BoF seemed to think this was a good idea. If you don't please reply to this message and make yourself heard :) Cheers, Hi, It's been about 2 weeks since the policy change has been proposed. I believe I have taken in account the feedback and the discussion seems to have died down. As the response from the team member was largely positive, I propose the change be merged. Cheers, I'm still against this, and I'm not sure yet whether or not it'll drive me to leave the team. The first sentence is ok, but the second is not ok with me. Can you be more explicit on the reasons why you dislike the second sentence? It only says you should document why tests aren't ran in a package and encourages you to open a bug report. You certainly don't have to write ten paragraphs, a single sentence summarizing the issue (and thus letting other people in the team help) is enough IMO. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: QA Experiment: removing "stale uploaders"
On 2024-08-16 9 h 09 a.m., weepingclown wrote: Hi, This is a very reasonable thing to do considering the policy change. I also have two packages where I mistakenly ended up as the maintaner and DPT as uploader (see python-graphene-directives and python-graphene-federation) because of tooling defaults and me missing to see it in the end. I have been contemplating since I realized this about how urgently I should take care of this. What I mean is that, does this call for an immediate revision of the debian package, or is it sufficient to have a git commit to reverse it and then later upload it with the next possible upstream release. Thoughts? Feel free to commit and not make a new release. I don't think anything is urgent. PS: And depending on how strictly we want to enforce this, there can perhaps also be a lintian warning/error? Lintian can't be used to generate this kind of information, as it only has access to the source and binary packages, not the git history. I feel relying on d/changelog for this doesn't provide enough information. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: QA Experiment: removing "stale uploaders"
On 2024-08-15 5 h 55 p.m., Scott Kitterman wrote: As a first cut, I would exclude archived repositories for removed packages (e.g. ptable). Thanks, I did see this after the fact (although there's very few repositories that are archived). If the team as a whole is keeping a package up to date, I think we should be happy that the package is maintained and not expend effort to make it harder for people to do that. I think that makes sense for a subset of packages, but in general I feel that puts a lot of burden on a few people, especially during transitions. If people do find they tend to team upload the same packages again and again and want to take care of them, they should adopt them and add their names to the Uploaders list. If we can get a list of packages that should be orphaned, it might also motivate people to adopt them and take better care of them. I'm really not sure how you are going to sort through this. Another example is appdirs. Yes, I didn't upload it the last few times someone touched it, but it's not in need of an upload now. What it really needs is to be removed, but there's a key package that depends on it. I don't think it's stale at all in any meaningful sense, but I don't know how you would know that without spending more time on the package than it's worth. I think it would be more useful to work on finding team packages that aren't maintained at all and have issues. Those should either be fixed or removed. Crossing different "smells" like no human uploaders outside of "stale uploaders", no recent releases, new upstream versions not packaged, etc. would probably yield a more tame list of packages one could have a look at. I agree going through the current list as-is by hand is not worth it :P In the end, I'm not 100% sure what I'll do with all of this yet, but suggestions are welcomed. I do have some code to run a bunch of tests on all of our repositories though and that was also a goal of mine. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
QA Experiment: removing "stale uploaders"
Hello! I had a chance to have a chat with doko at DC24 and one of the things that came out was this question: "Are there packages in the DPT that aren't maintained by their uploaders and are kept in the team because other people fix bugs and do team uploads on them?" Let's call these "stale uploaders". To get some data, I had a little fun and wrote a Python script [1] to match a package git history with the Uploaders field in d/control. If in the last 3 years, someone listed in the Uploaders field hasn't made a single commit, the package gets flagged. Turns out about half of the packages in our namespace get flagged one way or another :P = Some caveats: 1. To save time and disk space, I did shallow clones of the DPT's git repositories, using 2021-08-14 as a cutoff date. This certainly creates false-positives, but it seemed like a reasonable tradeoff. 2. There might be some discrepancies between packages' git repositories on Salsa and what's been uploaded to the archive. Some of these repos might not have gone through NEW at all. 3. A cursory look revealed a bunch of empty repositories [2] and packages that had been moved to other namespaces, but never removed from the DPT's namespace. 4. Packages flagged as "None" don't have an "Uploaders" field. Either: * the DPT is the "Maintainer" and we should make sure the package has been orphaned or * there's a human "Maintainer" and the DPT isn't listed in Uploaders and we should fix the package. 5. Some of the packages flagged as "Debian Python Team" have the team as Uploaders. Considering the recent policy change, we should probably try to make things more uniform by having the DPT as maintainer everywhere. = All in all, a fair amount of manual work is probably needed to make this list useful and remove false-positive, thus the 'QA Experiment' part in the title of this mail. Before putting more efforts into this, I wanted to hear from other team members. Do you think this is valuable work? If I get a good enough list (again, the current one needs work), would you support removing "stale uploaders" from our team-maintained packages?? Cheers, [1]: https://salsa.debian.org/pollo/qa-scripts/-/blob/master/dpt-stale-uploaders.py [2]: See empty.txt. I took the liberty of removing them, as they were all older than 6 months. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ asn1crypto-tests blea cefpython cornice datalad-metalad django-uwsgi-ng fedora-messaging flake8-mypy flask-rest-jsonapi karabo-master lets-enc manim-ce metaextract mpremote napalm-nxos oq-engine orange3 pcre2.py pyarranger pyls-mypy python-django-dynamic-scraper python-ezcolor python-gdsii python-hiyapyco python-js2py python-plone.testing python-protobuf3 python-robotframework-selenium2library python-robotsuite python-setuptools-golang python-sounddevice stashy thumbor-plugins-jpegrecompress thumbor-plugins-mozjpeg thumbor-plugins-optipng thumbor-plugins-pngcrush thumbor-plugins-pngquant tvb-framework unrpa upstream-ontologist aafigure: Debian Python Team adapt-parser: Ethan Ward afew: Free Ekanayaka aioftp: Adam Cecile aiohttp-cors: Debian Python Team aiohttp-debugtoolbar: Piotr Ożarowski aiohttp-jinja2: Debian Python Team aiohttp-jwt: Adam Cecile aiohttp-mako: Debian Python Team aiohttp-retry: Adam Cecile aiohttp-wsgi: William Grzybowski aiomysql: Adam Cecile aionotify: Adam Cecile aiopg: Debian Python Team aioredis: Debian Python Team aiorwlock: William Grzybowski aiowsgi: Jelmer Vernooij aioxmlrpc: Debian Python Team aiozmq: Debian Python Team airr: Steffen Moeller ajsonrpc: Peter Záhradník alienfeed: Debian Python Team alot: Simon Chopin, Johannes 'josch' Schauer annexremote: Michael Hanke anorack: Georg Faerber anosql: Florian Grignon ansi: Muri Nicanor ansible-lint: Gregory Colpart ansicolors: nicoo antlr4-python3-runtime: Debian Python Team apachedex: Debian Python Team api-hour: Debian Python Team app-model: Debian PaN Maintainers appdirs: Scott Kitterman archivemail: Debian Python Team archmage: Debian Python Team arcp: Michael R. Crusoe argparse: Debian Python Team argvalidate: Stephan Peijnik asn1crypto: None astroid: Debian Python Team astroid2: Debian Python Team asyncpg: Debian Python Team atheist: Cleto Martín, Francisco Moya, David Villa Alises authprogs: None authres: Debian Python Team autokey: Luke Faraone, Anthony Fok automat: Free Ekanayaka automx2: None autopep8: Debian Python Team autosuspend: Johannes Wienke awx: None axisregistry: Debian Python Team azure-cosmos-python: Luca Boccassi azure-cosmos-table-python: Luca Boccassi azure-functions-devops-build: Luca Boccassi babelfish: Etienne Millon, Oxan van Leeuwen babiloo: Marco Rodrigues backblaze-b2: Ondřej Kobližek backports.func
Re: Policy Change Proposal: Running the upstream test suite
On 2024-07-29 4 h 53 a.m., Louis-Philippe Véronneau wrote: Hello, As discussed during the DebConf24 Python BoF, I'm submitting this change to the policy to require the use of the upstream test suite, both during the build process and as an autopkgtest. You can find the MR here: https://salsa.debian.org/python-team/tools/python-modules/-/ merge_requests/24 People present at the BoF seemed to think this was a good idea. If you don't please reply to this message and make yourself heard :) Cheers, Hi, It's been about 2 weeks since the policy change has been proposed. I believe I have taken in account the feedback and the discussion seems to have died down. As the response from the team member was largely positive, I propose the change be merged. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Alternative libraries for PEP-594
On 2024-08-03 4 h 02 a.m., Matthias Klose wrote: On 03.08.24 07:25, Louis-Philippe Véronneau wrote: On 2024-08-02 20:40, Blair Noctis wrote: to scale it out in an external source package which is effectively going against Python upstream, allowing the thing to live on, and people to say "it's still alive in Debian!" Also, even python3.11 is still there. Sure someone needing something expunged from 3.13 would be fine staying with 3.12? The idea of having these libraries around for Trixie (and to remove them after the release) is to ease the 3.13 transition. From my preliminary analysis, there are more than 600 packages that use one of the stdlib that'll be removed in 3.13. There's also the option to remove packages from testing and/or unstable. I assume, we'll see a lot of packages still using old modules getting removed from testing, once 3.13 becomes the default. It's also an option to remove those completely, if they are not maintained. That is a lot of work and I doubt we'll have a successful transition without this temporary measure. can we agree on a naming for the packaging, e.g. python3-zombie- , so that we make it clear, that people are using obsolete code? we do that for python3-zombie-imp already. I like this a lot and I support this naming scheme. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Requesting membership in Debian Python team for Taavi Väänänen
On 2024-08-10 2 h 34 a.m., Taavi Väänänen wrote: Hi, I'm requesting membership in the Debian Python team in order to adopt[0] the mwclient package[1] which seems like a good fit for the team. I have read and accept the Python team policy. My Salsa username is 'taavi'. [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068659 [1]: https://tracker.debian.org/pkg/mwclient thanks in advance, Taavi Access granted. Welcome to the team! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Alternative libraries for PEP-594
On 2024-08-02 20:40, Blair Noctis wrote: to scale it out in an external source package which is effectively going against Python upstream, allowing the thing to live on, and people to say "it's still alive in Debian!" Also, even python3.11 is still there. Sure someone needing something expunged from 3.13 would be fine staying with 3.12? The idea of having these libraries around for Trixie (and to remove them after the release) is to ease the 3.13 transition. From my preliminary analysis, there are more than 600 packages that use one of the stdlib that'll be removed in 3.13. That is a lot of work and I doubt we'll have a successful transition without this temporary measure. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Alternative libraries for PEP-594
On 2024-08-02 20:40, Blair Noctis wrote: https://codesearch.debian.net/search?q=telnetlib&literal=1&perpkg=1&page=5 Searching in regex mode with `import.*telnetlib path:*.py` should give more accurate results. But nevertheless: I did this work already in Lintian: https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Languages/Python/StdlibDeprecation.pm?ref_type=heads The current code for "uses-deprecated-python-stdlib" in Sid is flawed (see #1077324) but that will be fixed in the next Lintian release. When that happens, I'm planning on making a MBF. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Alternative libraries for PEP-594
On 2024-08-02 23:06, Salvo Tomaselli wrote: Which is a popular opinion. Still, asyncore was deprecated in 2016. Eh, software is 8 years old so it needs a full rewrite now? Please try to keep comments that are not productive to the current efforts to some other channels? That kind of email certainly doesn't motivate me to make things in Debian better :( -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Alternative libraries for PEP-594
On 2024-08-02 17:21, Alexandre Detiste wrote: Hi, I will need some "zombie-telnetlib" (so exactly the same API as existing telnetlib) because I maintain proprietary .deb (not "Debian packages") that need to be installable without rebuild on Buster, Bookworm & Trixie. I understand that "telnetlib3" / "exscript" are 'better/newer' API but that does not fit the need. Debian could also benefit from this zombie-telnetlib. Should it be a native package or one with real upstream on PyPi ? That was another item we discussed during the 2nd BoF. There are already some projects like these [1][2] and we were considering packaging them to ease the 3.13 transition. eamanu said he would make a list of upstream projects we could package, but if you have some time, getting a list of projects would be great. If we end up packaging these libraries, I think it should be clear that they won't be available for Forky (Debian 14). The last thing we want is to maintain some deprecated zombie-libraries forever in Debian :( Cheers, [1]: https://github.com/simonrob/pyasyncore [2]: https://github.com/tiran/legacycrypt -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Alternative libraries for PEP-594
Hello, In the 2nd Python BoF today, it was pointed out we should probably make sure the alternatives listed in PEP-594 for libraries removed in 3.13 are packaged in Debian. I had a look, and these are the ones that should be packaged (all the other ones are already in the archive). There are no RFP open for them either: crypt: * legacycrypt: standalone version of crypt [1] telnetlib: * telnetlib3: a Telnet Client and Server library for python [2] * exscript: automating network connections over protocols such as Telnet or SSH [3] Is anyone in the DPT interested in packaging and maintaining these libraries? They will likely be very useful for the 3.13 transition. From the stats I have, I currently count: * 37 packages using telnetlib * 300 packages using crypt [1]: https://pypi.org/project/legacycrypt/ [2]: https://github.com/jquast/telnetlib3/ [3]: https://github.com/knipknap/exscript/ -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Policy Change Proposal: Running the upstream test suite
On 2024-07-30 12:58, Scott Kitterman wrote: On July 30, 2024 2:47:08 AM UTC, "Louis-Philippe Véronneau" wrote: On 2024-07-30 11:09, Scott Kitterman wrote: On July 30, 2024 12:49:50 AM UTC, "Louis-Philippe Véronneau" wrote: On 2024-07-29 21:07, Scott Kitterman wrote: On July 29, 2024 8:53:11 AM UTC, "Louis-Philippe Véronneau" wrote: Hello, As discussed during the DebConf24 Python BoF, I'm submitting this change to the policy to require the use of the upstream test suite, both during the build process and as an autopkgtest. You can find the MR here: https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/24 People present at the BoF seemed to think this was a good idea. If you don't please reply to this message and make yourself heard :) I understand the theory and why it's a good idea to run the test suite. I don't think it ought to be a hard requirement. I have several packages where there's a test suite, but I don't run it: 1. The largest set is packages that need test only dependencies which are not packaged. When I am packaging something new which has a test suite, then I generally package any needed test depends. If those test depends also need test depends packaged, I generally stop and don't enable tests for things that are only in the archives to support tests. Noseofyeti is an example of this. That sounds like a valid technical reason not to run the tests to me :) 2. There's at least one case where Debian has customizations that cause the test suite to fail, but the failures don't seem to cause any real problems. If anyone wants to make it so the weasyprint test suite works on Debian, please knock yourself out. Again, as long as you document that, I don't think it would go against the proposed policy change. 3. I also maintain multiple packages which require network access to run their test suite, so they can't run tests during build, only autopkgtests. Same. Except for #3, I don't get that from the wording in the MR. I don't think not worth the trouble is a technical reason. I think the real rule that's being proposed is that packages must run the test suit or document why not. I don't have a problem with that, but I don't think that's what it actually says now. I think if you were to change must to should and strike the word technical before reason, it would accomplish the same thing and be clearer. I could support that. Language is hard and I'm not a native English speaker :) What I want to prevent is people not running tests because they don't feel like it, even though it would not take them a large amount of efforts to do so. I'll strike "technical", as it seems others also interpreted this word they way you have. As for "MUST" vs "SHOULD", I believe the exception clause provides enough leeway to justify a reasonable way out in case of $VALID_REASON. "SHOULD" is not particularly strong and again, I fear it would let people get away with not running tests although it wouldn't be much work to do so... I guess it depends on how you look at the word. In the context of technical specifications, I tend to think of terms as defined in RFC 2119 [1]. I think that's pretty close to what you are suggesting: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. The way RFC 2119 defines MUST doesn't leave much room for exceptions. If you want to be clear, I suggest SHOULD with a reference to RFC 2119. While not universal, it is a widely used reference for definitions of these terms in technical specifications. Scott K [1] https://datatracker.ietf.org/doc/html/rfc2119#section-3 Fair enough. I also made that change. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Policy Change Proposal: Running the upstream test suite
On 2024-07-30 11:09, Scott Kitterman wrote: On July 30, 2024 12:49:50 AM UTC, "Louis-Philippe Véronneau" wrote: On 2024-07-29 21:07, Scott Kitterman wrote: On July 29, 2024 8:53:11 AM UTC, "Louis-Philippe Véronneau" wrote: Hello, As discussed during the DebConf24 Python BoF, I'm submitting this change to the policy to require the use of the upstream test suite, both during the build process and as an autopkgtest. You can find the MR here: https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/24 People present at the BoF seemed to think this was a good idea. If you don't please reply to this message and make yourself heard :) I understand the theory and why it's a good idea to run the test suite. I don't think it ought to be a hard requirement. I have several packages where there's a test suite, but I don't run it: 1. The largest set is packages that need test only dependencies which are not packaged. When I am packaging something new which has a test suite, then I generally package any needed test depends. If those test depends also need test depends packaged, I generally stop and don't enable tests for things that are only in the archives to support tests. Noseofyeti is an example of this. That sounds like a valid technical reason not to run the tests to me :) 2. There's at least one case where Debian has customizations that cause the test suite to fail, but the failures don't seem to cause any real problems. If anyone wants to make it so the weasyprint test suite works on Debian, please knock yourself out. Again, as long as you document that, I don't think it would go against the proposed policy change. 3. I also maintain multiple packages which require network access to run their test suite, so they can't run tests during build, only autopkgtests. Same. Except for #3, I don't get that from the wording in the MR. I don't think not worth the trouble is a technical reason. I think the real rule that's being proposed is that packages must run the test suit or document why not. I don't have a problem with that, but I don't think that's what it actually says now. I think if you were to change must to should and strike the word technical before reason, it would accomplish the same thing and be clearer. I could support that. Language is hard and I'm not a native English speaker :) What I want to prevent is people not running tests because they don't feel like it, even though it would not take them a large amount of efforts to do so. I'll strike "technical", as it seems others also interpreted this word they way you have. As for "MUST" vs "SHOULD", I believe the exception clause provides enough leeway to justify a reasonable way out in case of $VALID_REASON. "SHOULD" is not particularly strong and again, I fear it would let people get away with not running tests although it wouldn't be much work to do so... -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Policy Change Proposal: Running the upstream test suite
On 2024-07-29 23:08, Pierre-Elliott Bécue wrote: Hey, Louis-Philippe Véronneau wrote on 29/07/2024 at 10:53:11+0200: Hello, As discussed during the DebConf24 Python BoF, I'm submitting this change to the policy to require the use of the upstream test suite, both during the build process and as an autopkgtest. You can find the MR here: https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/24 People present at the BoF seemed to think this was a good idea. If you don't please reply to this message and make yourself heard :) Cheers, I spend a lot of time trying to make the upstream tests working in package building, but I'm against enforcing this. There are a lot of packages with good code but crappy tests, and we don't want to force ourselves maintaining these, and dropping the packages seem a bit too much. I'd file that under "a technical issue [that] prevents you from running the test suite and you believe the reason to be valid". :) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Policy Change Proposal: Running the upstream test suite
On 2024-07-29 21:07, Scott Kitterman wrote: On July 29, 2024 8:53:11 AM UTC, "Louis-Philippe Véronneau" wrote: Hello, As discussed during the DebConf24 Python BoF, I'm submitting this change to the policy to require the use of the upstream test suite, both during the build process and as an autopkgtest. You can find the MR here: https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/24 People present at the BoF seemed to think this was a good idea. If you don't please reply to this message and make yourself heard :) I understand the theory and why it's a good idea to run the test suite. I don't think it ought to be a hard requirement. I have several packages where there's a test suite, but I don't run it: 1. The largest set is packages that need test only dependencies which are not packaged. When I am packaging something new which has a test suite, then I generally package any needed test depends. If those test depends also need test depends packaged, I generally stop and don't enable tests for things that are only in the archives to support tests. Noseofyeti is an example of this. That sounds like a valid technical reason not to run the tests to me :) 2. There's at least one case where Debian has customizations that cause the test suite to fail, but the failures don't seem to cause any real problems. If anyone wants to make it so the weasyprint test suite works on Debian, please knock yourself out. Again, as long as you document that, I don't think it would go against the proposed policy change. 3. I also maintain multiple packages which require network access to run their test suite, so they can't run tests during build, only autopkgtests. Same. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Policy Change Proposal: Running the upstream test suite
Hello, As discussed during the DebConf24 Python BoF, I'm submitting this change to the policy to require the use of the upstream test suite, both during the build process and as an autopkgtest. You can find the MR here: https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/24 People present at the BoF seemed to think this was a good idea. If you don't please reply to this message and make yourself heard :) Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Review of package dep-logic
Hello! Here's my review of the work you did for dep-logic. I'll try to be thorough. If something isn't clear, feel free to hit me up on IRC. === 1. d/changelog: The version number for your package isn't right. You currently only have the upstream version (0.2.0) and you forgot to add the Debian revision part. It should thus be "0.2.0-1", as it's the first Debian revision of this upstream version. You can find more info on this field here [1]. You also named the package "dep-log" instead of "dep-logic" 2. d/control: * You have a "Maintainer" field (which is OK), but you also need an "Uploaders" field, listing humans. * Your "Build-Depends" field is very incomplete. I would suggest you look at other packages in the Team to get some inspiration, but in addition to python3-packaging, I would expect it to depend on: - debhelper-compat (the main "Debian building framework" in use) - dh-python (the debhelper tool we use to build Python packages) - python3-all (all the python version available in the archive) - python3-pdm-backend (the build tool used for this package) * Your "Description" field only has a short description. It also needs a long one. 3. d/copyright: Your copyright file is not complete. This file is very important, as if it's not 100% right, your package will be rejected by the FTP masters when submitting it to the archive for the first time (the NEW queue). I would recommend using some automated tools (I like 'decopy') to start the work, but it's always a good idea to manually double-check and fix errors. 4. d/format: There is currently no such thing as a "3.0 (git)" format. The choices you have are listed here [2], but the right one is most probably "3.0 (quilt)". Not only this, but this file should be in a directory named "debian/source". 5. d/rules: The only thing you're currently specifying in this file, is that you're using the debhelper framework. At a minimum, you'll need to tell it to use pybuild, the main Python build tool in Debian. === More generally, I doubt you tried to build this package, as fails to pretty quickly :) I encourage you to take a few minutes to set up a clean build environment. In my opinion, sbuild is a good tool for this and the documentation on the Debian wiki is pretty good [3]. I suggest you follow the "Option 2: Automatic setup using sbuild-debian-developer-setup" setup process, as this tools pretty much does everything for you. Once setup, the "magical" sbuild command I like to use is: "sbuild -A -s -d unstable --source-only-changes PACKAGE". If you need inspiration from another package, I think this one is fairly straightforward and simple: https://salsa.debian.org/python-team/packages/python-mpv Cheers, and thanks for your contribution to Debian :) --- [1]: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version [2]: https://www.debian.org/doc/manuals/maint-guide/dother.en.html#sourcef [3]: https://wiki.debian.org/sbuild -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Proposal IRC meeting DPT
On 2024-06-29 2 h 29 p.m., Scott Kitterman wrote: According to codesearch.d.n over 600 packages reference disutils in their code. That doesn't mean that they all use it, but it's a lot of packages. FWIW, I wrote a lintian tag to flag these packages: https://udd.debian.org/lintian-tag.cgi?tag=uses-python-distutils -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: request for removal of my packages from the DPT namespace
On 2024-06-20 1 h 03 p.m., Jeroen Ploemen wrote: *ping* *ping* *ping* On Thu, 23 May 2024 08:27:42 +0200 Jeroen Ploemen wrote: *ping* *ping* On Tue, 16 Apr 2024 11:21:51 +0200 Jeroen Ploemen wrote: *ping* On Tue, 19 Mar 2024 13:41:04 +0100 Jeroen Ploemen wrote: Seeing you haven't got an answer back (the DPT's admin are known to be busy...), I'd highly suggest you open a ticket on the Salsa Team's issue tracker [1]. In the past, asking them to remove repositories by opening such a ticket worked for me. Cheers, [1]: https://salsa.debian.org/salsa/support -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: DPT ideas to organize
On 2024-06-14 9 h 25 a.m., Emmanuel Arias wrote: Hi team, Sorry for the subject, this mail is more like questions than given ideas :-). After reading the DPL's contact and its responses, it got me thinking - and this is also a personal feeling - that the DPT is a place where I can seek help. This is beneficial because we understand that if we encounter a Debian packaging issue specific to Python, we can expect a prompt response from experienced people within the team. However, it's true that each one maintains their own packages, while some others fix RC bugs. But IMHO we lack like clear direction to follow as a team. While ultimately, we just need to ensure that the packages under the DPT umbrella are up-to-date with upstream and free of RC bugs as much as possible. I don't know if that 'direction' is needed. I understand that our team's priority is to address 3.12 bugs [0], as mentioned in the irc topic. I know that some people are already working on this, and they don't necessarily need to seek permission before tackling an RC bug. However, perhaps we could attempt to organize our efforts better. Maybe we could identify packages that are candidates for removal like [1] and try to reduce the list of RC bugs. Another question is: what should we do with packages that are not under the team's umbrella but are affecting Python 3.12? On the other hand, we could assess if there are any improvements needed in our tools, such as pybuild, or determine which packages require, for instance, autopkgtests, lintian, etc. Or maybe we can start making short IRC meetings once a week or every two weeks? Experienced members of the team, do you think this is feasible given the DPT workflow? I would like to hear the opinion from the team :-) [0] https://deb.li/3T4QN [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025181 I agree with the points you raise. It's true the DPT isn't a very organised entity (although there's much worse teams in Debian :9). I think more would be possible if we were more organised. Having regular meetings would surely help. On my side though, I sadly don't have time for that. I'm already part of plenty of Teams in Debian (some of which do have regular meetings, like the DebConf Videoteam) and I only have so many spoons... If others want to push this way, I'll root for you! That said, if I had more time, I would probably prioritise reviewing and sponsoring more DPT packages, something I haven't done in a while. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Contacting DPT
On 2024-06-06 11 h 40 a.m., Andreas Tille wrote: - Do you feel good when doing your work in Debian Python team? Yes. - Do you consider the workload of your team equally shared amongst its members? No, and that's perfectly OK? Some people have more time to give than others. - Do you have some strategy to gather new contributors for your team? Not really, but I feel that's generally true for Debian at large :) I think joining an active team is an easier way to start packaging though. - I guess you will have your regular DPT meeting at DebConf (which I intend to join). What do you think about the general team meeting I registered. I think it's a great idea and I'll be more than happy to join. I've heard great things about what other teams have been doing in terms of workflow and practices and I'd like to learn more. I feel it would be really positive if we could try to work towards a more standardised set of "team practices" in Debian, to make the general packaging experience less chaotic. - In the beginning of this year there was a change in the policy of DPT. I'd like to hear your opinion about: * The process how it went (possibly with suggestions to do better) * The final result after a couple of months I'm sad that some people left, but then again, I don't think a solution that suited everyone was possible. I feel the status quo created a lot of tensions (especially for some newcomers who made honest mistakes) and as such, I don't think we could've reached a consensus and believe a vote was necessary. - Since a long time we try to migrate from Python3.11 to Python3.12. * What are your thoughts about the transition process? * Can you identify some blockers? * Do you have some suggestions for enhancements of this process? I've said it many times but I really dislike transitions that are near the release freeze. It forces us into a crunch and I don't think that's healthy. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: install entry points in a dedicated binary package
On 2024-06-05 2 h 57 a.m., PICCA Frederic-Emmanuel wrote: > with the something fonctionnaly equivalent which install the entry points only in the binoculars package. > ... > # install scripts into binoculars > python3 setup.py install_scripts -d debian/binoculars/usr/bin I'm not 100% sure I understand your question, but is something preventing you from installing the script with a debian/binoculars.install file? -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
DebConf24 Sprint & BoF!
Hello Team! 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: https://pad.online.debconf.org/p/python-team-bof I've also submitted a Python Sprint for DebCamp. I think this time could be used to do some QA work on the team's packages? If you have ideas of what people should work on, there's another (temporary?) pad: https://pad.online.debconf.org/p/python-team-sprint Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
python3-poetry-dynamic-versioning is now in the Debian archive
Hello! python3-poetry-dynamic-versioning recently landed in the archive and I wanted to make it known! This package does something similar to python3-setuptools-scm and can be used in Debian in a similar way. You can use it manually with the following snippet, but pybuild's next release will automate this [1]. - export POETRY_DYNAMIC_VERSIONING_BYPASS = $(DEB_VERSION_UPSTREAM) include /usr/share/dpkg/pkg-info.mk - With the rise of poetry as a packaging tool, I think it'll become more and more common. There is already a bunch of packages in the archive that could use it :) https://codesearch.debian.net/search?q=poetry-dynamic-versioning+path%3Apyproject.toml&literal=0 Cheers! [1]: https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/54 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Suggesting change in DPT policy
ation" option from policy. I've attached an according patch to the team policy[5]. I'm fine with creating a MR to be discussed rather in Salsa than this mailing list - whatever seems worthwhile to you. I too, support this change. As Scott said, I want to reiterate that I think it's important that anyone who thinks this is a bad idea to make themselves heard. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Breaking changes in pytest 8
On 2024-01-09 12:45, Julian Gilbey wrote: Hi Timo, Please can we hold back on uploading pytest 8 to unstable until the current Python 3.12 transition is complete? It is entirely possible that several of the packages that currently break with pytest 8 already have newer upstream versions that address these issues, but it's probably not wise to mix that in with the current transition. Agreed! There currently a lot of instability caused by 3.12 transition and waiting a little bit would certainly make things easier to deal with :) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Review of package dunamai
Hello!
It seems you're a DD! Sorry, it took me a bit to realise this... No need
for me to sponsor anything then!!
As promised, here's the review for the dunamai package.
> I guess it's time to move/re-create/import the repo to
> python-team/packages alongside other python packages, right?
Yes, the first step if you want the package to be part of the Debian
Python Team is to upload it to Salsa in
https://salsa.debian.org/groups/python-team/packages, following the
proper branch structure described in the team's policy.
As for the current branches, I see you've built the package on a git
import instead of a tarball (meaning you have upstream commits in the
upstream and debian/foo branches). This is not typically what is done in
the Team.
As such, the Team's policy says:
"DPT requires a pristine-tar branch, and only upstream tarballs can be
used to advance the upstream branch. Complete upstream Git history
should be avoided in the upstream branch."
> What is the preferred repo name? I went with dunamai, but some
> packages use python-dunamai
Typically, if it's a library, it's a good idea to have the source
package start by "python-". If you are packaging something that is
primarily an application (say, supysonic), you can omit it.
In your case, dunamai is both a CLI tool and a library. In this case,
I'd strongly recommend going with "python-dunamai" for the source
package and "python3-dunamai" for the binary package.
> I currently maintain the package in debian/experimental branch. Would
> you recommend going through experimental with dunamai /
> poetry-dynamic-versioning or aim straight for sid in debian/master?
Hmm, whatever? It's really a matter of personal preferences. I tend to
be lazy and not want to build on experimental because the sbuild script
is more tedious... :)
That said, here's the actual review:
1. d/changelog: as per the Team's policy, packages that haven't been
uploaded to the archive should be marked as UNRELEASED instead of
experimental or unstable. This helps us keep track of what's actually
been uploaded when working collaboratively on packages.
2. d/control: you don't need to restrict the python version (">= 3.5")
even if that's something upstream does somewhere.
In fact, you don't even need to specify "python3" at all. See #5.
3. d/control: you can skip the "Python 3" mentions in the description.
python2 is 100% deprecated since Bookworm.
4. d/control: I would strongly encourage you to add "Testsuite:
autopkgtest-pkg-pybuild" to your d/control source statement. This will
run the upstream testsuite as an autopkgtest for you and makes you
package much more robust. (man pybuild-autopkgtest)
5. d/control: In the eternal words of dpkg-gencontrol:
dpkg-gencontrol: warning: package python3-dunamai: substitution variable
${python3:Depends} unused, but is defined
You should add it to your binary dependencies.
6. d/copyright: The "MIT" license tends to be called "Expat" in Debian.
It's a nitpick, but IMO it's enough for some ftp-masters to reject your
upload to NEW. "decopy" identifies the LICENSE file as Expat correctly :)
7. d/metadata: This file tends to be in "debian/upstream/metadata"?
8. d/tests/dunamai: You don't really need to the python import function.
This is trivial, doesn't really do much and if you still want to do
this, I'd recommend using "Testsuite: autopkgtest-pkg-python" in
d/control, as it does this exact thing in a more automated and
streamlined fashion.
9. d/rules: as pointed out by lintian, you're parsing dpkg-changelog
directly.
You can make your life easier by using "source
/usr/share/dpkg/pkg-info.mk" at the top and using variables like
DEB_{SOURCE,VERSION}.
"cat /usr/share/dpkg/pkg-info.mk" will give you the list of variables
you can use and what they are.
In fact, I'm not sure I get why you need this VERSION variable? The
package seems to build fine without it.
10. Your package doesn't actually run tests during build: "Ran 0 tests
in 0.000s". You're missing "python3-pytest" as a build-dependency.
With this dependency, all tests (and not only the unit tests) will be
ran and they'll fail. I don't think you want to run the integration
tests, or at least, this should probably be done in an autopkgtest instead.
You can fix this by adding a "d/pybuild.testsuites" file containing
"tests/unit" to specify what testfiles to add/keep.
(man pybuild for more info)
Cheers, and thanks for contributing to Debian! When you're ready for a
review of poetry-dynamic-versioning, don't hesitate to
Re: Updating python-build/getting rid of pep517
On 2023-08-02 09 h 23, Éric Araujo wrote: Le 02/08/2023 à 00:09, Scott Kitterman a écrit : * pdm (update to new version, needs pyproject-hooks) [pdm-pep517 can probably go away too] pdm-pep517 was renamed to pdm-backend, which will still be needed by Python packages who want to use it as a build backend. (It does not depend on pyproject-hooks.) Cheers I see pdm-pep517 is still a complete package (as opposed to being a virtual package redirecting to pdm-backend). What's the plan for this? I'm asking, since at the moment in Lintian, when we find a `build-backend = "pdm.pep517.api"` line in pyproject.toml, we are recommending people build-depend on python3-pdm-pep517. Should I change something? -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1040066: python-marshmallow-enum: Intent to remove from the archive
Source: python-marshmallow-enum Severity: serious Owner: po...@debian.org X-Debbugs-CC: debian-python@lists.debian.org I maintain the python-marshmallow-enum package. Since it has been deprecated upstream [1] (marshmallow 3.18.0 added Enum support), I'm planning on removing it from the archive as soon as possible. This bug should be enough to have python3-marshmallow-enum be removed from testing in the meantime and will help me link the bugs blocking the RM. Once those are closed, I'll turn this bug into a formal RM request. Cheers, [1]: https://github.com/justanr/marshmallow_enum/issues/51 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: installation of script in a dedicated package
On 2023-06-16 06 h 09, PICCA Frederic-Emmanuel wrote:
Hello,
I try to update the silx package and I want to replace this call
python3 setup.py install_scripts -d debian/silx/usr/bin
with the right call without setup.py.
thanks for your help
Frederic
Hi,
A good way to know what needs to be done is to remove the line and then diff
the result:
==
foo@bar:/tmp$ debdiff silx_1.1.2+dfsg-1_amd64.changes
silx_1.1.2+dfsg-2_amd64.changes
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in first .changes but not in second
-
-rwxr-xr-x root/root /usr/bin/silx
Control files of package python-silx-doc: lines which differ (wdiff format)
---
Version: [-1.1.2+dfsg-1-] {+1.1.2+dfsg-2+}
Control files of package python3-silx: lines which differ (wdiff format)
Version: [-1.1.2+dfsg-1-] {+1.1.2+dfsg-2+}
Control files of package python3-silx-dbgsym: lines which differ (wdiff format)
---
Depends: python3-silx (= [-1.1.2+dfsg-1)-] {+1.1.2+dfsg-2)+}
Version: [-1.1.2+dfsg-1-] {+1.1.2+dfsg-2+}
Control files of package silx: lines which differ (wdiff format)
Depends: python3-silx (>= [-1.1.2+dfsg-1), python3-numpy, python3:any-]
{+1.1.2+dfsg-2), python3-numpy+}
Installed-Size: [-65-] {+63+}
Version: [-1.1.2+dfsg-1-] {+1.1.2+dfsg-2+}
==
It seems the only thing this line does is to install /usr/bin/silx. This can be
done 'manually' via
dh_install (see man dh_install).
I personally tend to prefer having a file like 'debian/python3-silx.install'
instead of having a
'dh_install' line in 'debian/rules', as it yields a 'cleaner' d/rules file.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org
⠈⠳⣄
OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: Migration from setuptools to pyproject
On 2023-05-03 04 h 06, Jerome Kieffer wrote:
Dear Debian Packager
I am the upstream developer of a few debian packages (fabio, pyfai...) and
those packages used to rely on numpy.distutils. Since setuptools 60,
this is not more possible so I changed the build system to use mesonpy
(pep517 compliant).
I found it easy to tell the debian packaging helper pybuild to use the
`pyproject.toml` file to build the software instead of the `setup.py`:
`export PYBUILD_SYSTEM=pyproject` in the debian/rules file.
But later on, the meson configuration finds cython as cython3 but complains the
compiler was not found:
```
dh build --with python3,sphinxdoc --buildsystem=pybuild
dh_update_autotools_config -O--buildsystem=pybuild
dh_autoreconf -O--buildsystem=pybuild
dh_auto_configure -O--buildsystem=pybuild
pybuild --configure -i python{version} -p 3.11
dh_auto_build -O--buildsystem=pybuild
pybuild --build -i python{version} -p 3.11
I: pybuild plugin_pyproject:107: Building wheel for python3.11 with "build"
module
I: pybuild base:240: python3.11 -m build --skip-dependency-check --no-isolation
--wheel --outdir
/home/kieffer/workspace/pyFAI/build/debian12/pyFAI-2023.5.1a0/.pybuild/cpython3_3.11_pyfai
* Building wheel...
+ meson setup --prefix=/usr
/home/kieffer/workspace/pyFAI/build/debian12/pyFAI-2023.5.1a0
/home/kieffer/workspace/pyFAI/build/debian12/pyFAI-2023.5.1a0/.mesonpy-0rgp966m/build
--native-file=/home/kieffer/workspace/pyFAI/build/debian12/pyFAI-2023.5.1a0/.mesonpy-native-file.ini
-Ddebug=false -Doptimization=2
The Meson build system
Version: 1.0.1
Source dir: /home/kieffer/workspace/pyFAI/build/debian12/pyFAI-2023.5.1a0
Build dir:
/home/kieffer/workspace/pyFAI/build/debian12/pyFAI-2023.5.1a0/.mesonpy-0rgp966m/build
Build type: native build
Project name: pyFAI
Project version: 2023.5.1a0
C compiler for the host machine: ccache cc (gcc 12.2.0 "cc (Debian 12.2.0-14)
12.2.0")
C linker for the host machine: cc ld.bfd 2.40
Cython compiler for the host machine: cython3 (cython 0.29.32)
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program cython found: NO
../../meson.build:17:0: ERROR: Program 'cython' not found or not executable
```
I had a similar problem for python3 and it was solved by installing
`python-is-python3`. But there is no such trick for cython ...
Nota: `sudo ln -s /usr/bin/cython3 /usr/bin/cython` addresses the bug but I am
looking for a solution which is compliant with debian packaging !
Thanks for your help.
Jerome
Hi,
It's hard to help you without seeing what the /debian dir looks like.
In theory, you don't need to specify `PYBUILD_SYSTEM=pyproject` for
pybuild to use the pyproject.toml file.
As per the pybuild manpage, you need to have the
`pybuild-plugin-pyproject` package as a build-dependency and the package
you use as the build system, in your case, `python3-mesonpy`.
As for your cython problem, it doesn't seem like you are building in a
clean environment. I would highly recommend you use something like
sbuild to do so:
https://wiki.debian.org/sbuild
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org
⠈⠳⣄
OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: python-param: FTBFS: TypeError: The only supported seed types are: None,
On 2023-02-03 11 h 58, FC Stegerman wrote: Presumably there is a way to get the version from e.g. "dpkg-parsechangelog -S Version" (minus the -1 revision) instead. I'm not sure how other packages handle this. You can get those values via the variables provided by /usr/share/dpkg/pkg-info.mk You can "source" those in your d/rules makefile by using: include /usr/share/dpkg/pkg-info.mk -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Python 3.11 for bookworm?
On 2022-12-12 18 h 51, Graham Inggs wrote: Dear Python Team Looking at the current state of the 'adding Python 3.11 as a supported version' transition [1], the tracker [2] shows only 12 red packages (excluding unknowns and packages not in testing) remaining, copied below for reference. We believe all FTBFS and autopkgtest regression bugs have already been filed and tagged. The current state of bugs tagged 'python3.11' [3] is 116 resolved and 49 still open. Many thanks to everyone who has contributed to fixing these, and especially to the organizers of the recent Python sprint [4]. As this transition is non-blocking (i.e. uploaded packages are able to migrate ahead of python3-defaults), we could wait for the remaining bugs to be fixed, or for auto-removal to take its course. However, with the bookworm transition freeze only one month away [5], we'd like to hear from the Python Team within the next week whether they wish to proceed with Python 3.11 being the only supported version for bookworm (in which case we will allow python3-defaults to migrate right now) or, revert the changes in python3-defaults and have Python 3.10 as the only supported version for bookworm. Should it be the former, we'd like an undertaking from the Python Team that they will help resolve the remaining bugs against key packages [6], as these cannot easily be avoided by manual or auto-removals. On behalf of the Release Team Graham I still feel the move to 3.11 so late in the release cycle was cavalier and we should have used our energies to fix issues we had in the archive instead of trying to fix 3.11 bugs. I've said it already here, but it's very frustrating to work on packaging python libraries and apps for a whole release cycle, just to see all that work put in the bin at the last minute because upstream doesn't support 3.11. I hate to be put in a position where I have to tell upstreams (some with whom I've been collaborating for years) "ahem, by the way, you have 2 months to fix this or it won't be in the next Debian stable release". That said, 3.11 proponents certainly walked the walk and fixed a lot of stuff already. Kudos to them. I don't feel like I can take position on this. I'm certainly biased by one of the packages I really care about not being 3.11 compatible (and probably won't be before the release). All I know is this late transition leaves a bitter taste in my mouth. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: on the lack of a `python-` prefix for source packages
On 2022-12-11 20 h 53, Scott Kitterman wrote: On December 12, 2022 1:24:35 AM UTC, Sandro Tosi wrote: Proposal: the DPT will start adding a `python-` prefix to NEW source packages names, unless the upstream project already contains it AFAICT all other major languages ecosystems packaging teams use a (semi?)mandatory tag to identify their source packages (results below from a very quick look at Sources, top results only): prefix: golang, rust, r, node, ruby, haskell, php, ocaml, python (on a voluntary basis), and others prefix+suffix: perl At the beginning, I remember being in favor of the current status quo in DPT, where each maintainer can choose to add `python-` if they feel like it, or just use the upstream name. Thru the years, i've grown more uncomfortable with this situation and i think the fact we dont mandate a `python` prefix in the team source packages names (and thus guiding the rest of the python packagers within Debian towards a common style) is detrimental to Debian as a whole, and we should change it. My proposal as stated at the top is to start from now on to prepend `python` to all NEW source packages in DPT, with the option to rename existing packages at a later date. What are other team members' opinions on this? For packages that on contain a python module/extension, I think it's not horrible, but I don't see why it's better to diverge from upstream naming. I tend to agree with Sandro on for this use case. For packages that contain or are primarily applications, I don't think it's a good idea. Ditto on that one, I don't feel having "python-supysonic" would be a good naming scheme... -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [MBF] pybuild: Stop calling setup.py test?
On 2022-12-10 17 h 09, Colin Watson wrote: On Mon, Aug 15, 2022 at 06:27:22PM +, Stefano Rivera wrote: Calling "setup.py test" has been deprecated since setuptools 28.5. That's 6 years ago. pybuild calls currently setup.py test, when it can see that the package supports it, and another test runner hasn't been selected. I looked at dropping support for this (https://bugs.debian.org/982298) last year. I did some test builds and decided that breaking 50 odd packages to stop calling setup.py test wasn't worth it. I spent a bit of time this weekend converting some packages that I'm interested in to use the pytest runner, focusing first on ones that were using nose but also a few from this list (lazr.uri, python-wadllib, zope.interface). I needed a couple of workarounds, some due to packages using importlib.metadata to get their own version at import time (typified by the rather messy https://salsa.debian.org/python-team/packages/lazr.uri/-/commit/786825acc6) and some due to pre-PEP-420 namespace packages (typified by https://salsa.debian.org/python-team/packages/zope.interface/-/commit/a8c7881b1a). Fortunately pytest provides IMO rather convenient ways to hook in and gently tweak the import system just before it tries to import the modules under test, which I think is better in this context than bringing up a virtualenv or whatever. I'd be happy to do a bit more of this sort of thing. https://veronneau.org/debian-python-team-2022-sprint-report.html said that around 29 of 67 team-maintained packages were fixed during the sprint, which means I'm going to have a slightly annoying hit rate if I have to just go through this email to find targets. Is there somewhere else where the current list of target packages is being maintained, or would it be possible to do this mass bug-filing at sub-RC level so that there's a convenient list in the BTS? This is the list we used during the sprint to coordinate: https://pad.riseup.net/p/FixSetupTest-keep It's probably outdated though and I feel a real MBF would be helpful to keep track at this point... -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Debian Python Team Sprint: December 2-3-4 2022
On 2022-12-01 13 h 56, Louis-Philippe Véronneau wrote: On 2022-10-14 13 h 55, Louis-Philippe Véronneau wrote: On 2022-10-05 14 h 50, Louis-Philippe Véronneau wrote: On 2022-09-12 17 h 08, Louis-Philippe Véronneau wrote: Hello! Our next team sprint will be on December 2-3-4 2022 and will be remote. Please register on this wiki page if you are interested: https://wiki.debian.org/Sprints/2022/PythonTeam There are plenty of items in the 'Agenda' section for people who want to help out but have no idea on what to work on :) Please note you need to register **before October 15th** to get food sponsorship. Cheers, Hello hello, Reminder: the deadline to sign up and get food sponsorship is *October 15th*. That's next week! Cheers, > Today is the last day to sign up and get food sponsoring! https://deb.li/2S8U Hi! The sprint starts tomorrow, so I thought I'd send a reminder here. All the relevant information can be found on the sprint's wiki page: https://wiki.debian.org/Sprints/2022/PythonTeam As always, the best place to reach out is our IRC channel. If people feel the need to have a meeting to discuss particular issues, I've also listed a Jitsi room on the wiki. At the end of the sprint, I'll have to write a report. Please help me with this task by keeping track of what you did during the sprint on this etherpad: https://pad.riseup.net/p/DPT2022Sprint If you were granted a budget for food sponsorship, don't forget to keep your receipts and open a reimbursement request as soon as possible at the end of the sprint! Cheers, Here's the sprint report: https://veronneau.org/debian-python-team-2022-sprint-report.html If I missed something, or didn't get something right, ping me and I'll fix it! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1025164: lintian: missing-prerequisite-for-pyproject-backend tag needs to check Build-Depends-Indep too
On 2022-12-01 01 h 52, Stuart Prescott wrote: Hi Scott On 01/12/2022 15:16, Scott Kitterman wrote: On Wednesday, November 30, 2022 10:38:30 PM EST Stuart Prescott wrote: Hi Scott, On 01/12/2022 02:16, Scott Kitterman wrote: Package: lintian Version: 2.115.3 Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org The missing-prerequisite-for-pyproject-backend check appears to only look for the prerequisite packages in Build-Depends, but since they aren't needed for clean, they could be in Build-Depends-Indep, leading to false positives. Scott K I contemplated filing a similar the other day but in writing it up, I realised that lintian was correct. Policy requires that the 'clean' target be functional with only the Build-Depends (and Build-Conflicts) satisfied, and pybuild + the build-backend dependencies are involved in the cleaning step. Not always. At least with the package I ran into this on, clean works fine without them. Yes indeed... - the most obvious case where that works is where 'clean' is explicit in d/rules - it would also be possible for it to work in situations where dh-python is (redundantly?) listed in B-D (not B-D-I), since the pyproject plugin's 'clean' operation has no dependency on `build`, `installer`, and the backend. However, this for this second case: - it might result in pybuild picking a different plugin through lack of dependencies like `tomli`. That might just work... but also feels slightly terrifying. - there's not _currently_ any backend-specific cleaning code, but perhaps there should be, which would then need the deps to be in B-D? (Is that in the spec somewhere?) I guess the main thing to be careful of in any rewording of this explanation is that for the most common case of using "%:\n\tdh --buildsystem pybuild", dh-python (or pybuild-plugin-pyproject) is needed in B-D not B-D-I to be policy-compliant. cheers Stuart I've proposed a fix here: https://salsa.debian.org/lintian/lintian/-/merge_requests/426 It's not precise enough to flag packages that would declare everything as a Build-Depends-Indep though. This would be much more complex and I feel this situation is overall pretty rare. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Debian Python Team Sprint: December 2-3-4 2022
On 2022-10-14 13 h 55, Louis-Philippe Véronneau wrote: On 2022-10-05 14 h 50, Louis-Philippe Véronneau wrote: On 2022-09-12 17 h 08, Louis-Philippe Véronneau wrote: Hello! Our next team sprint will be on December 2-3-4 2022 and will be remote. Please register on this wiki page if you are interested: https://wiki.debian.org/Sprints/2022/PythonTeam There are plenty of items in the 'Agenda' section for people who want to help out but have no idea on what to work on :) Please note you need to register **before October 15th** to get food sponsorship. Cheers, Hello hello, Reminder: the deadline to sign up and get food sponsorship is *October 15th*. That's next week! Cheers, > Today is the last day to sign up and get food sponsoring! https://deb.li/2S8U Hi! The sprint starts tomorrow, so I thought I'd send a reminder here. All the relevant information can be found on the sprint's wiki page: https://wiki.debian.org/Sprints/2022/PythonTeam As always, the best place to reach out is our IRC channel. If people feel the need to have a meeting to discuss particular issues, I've also listed a Jitsi room on the wiki. At the end of the sprint, I'll have to write a report. Please help me with this task by keeping track of what you did during the sprint on this etherpad: https://pad.riseup.net/p/DPT2022Sprint If you were granted a budget for food sponsorship, don't forget to keep your receipts and open a reimbursement request as soon as possible at the end of the sprint! Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Python 3.11, bytecode and new internals
On 2022-11-21 02 h 08, Julian Gilbey wrote: I'm just flagging this up here, with a question about how we should proceed. Certainly we are not ready to make Python 3.11 the default Python version!! This is a concern I share and I think I've been pretty vocal about it. I feel the state of python packages for Bookworm with 3.10 was pretty good and it seemed reasonable to prioritize stability for our next stable release :) It's very frustrating to work on packaging python libraries and apps for a whole release cycle, just to see all that work put in the bin at the last minute because upstream doesn't support 3.11... I've been told the current 3.11 transition was a test, and if it was clear too many important things were broken and couldn't be fixed, we would roll back and release using 3.10. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Review of Debian package pystray
On 2022-10-21 23 h 28, Louis-Philippe Véronneau wrote: Hello, This is my review of the pystray package you asked the Debian Python Team to sponsor in the Debian archive. 1. I doubt d/README.source is needed, as this is a team-maintained package and most of that info is in the Policy :) 2. in d/rules, you are using "override_dh_sphinxdoc" and then calling dh_sphinxdoc. You should instead use "execute_before_dh_sphinxdoc". 3. You are not running any upstream tests, neither at build not as autopkgtests. Tests are very important. How do you know your package isn't broken, or has not been broken by a change in the archive? Only tests can tell you that. I see you've noted that some tests require user confirmations and it indeed seems to be the case for most of the ones in icon_tests.py. * is there a way to bypass this or are those tests simply not relevant in a automated environment? * what about menu_descriptor_tests.py? I gave it a very cursory look, but it doesn't seem to use the confirm() function. Trying to run it gives me an "Xlib.error.DisplayNameError: Bad display name" error though, so chances are you'd need to run tests with xvfb to mock an X session. Note that it is my personal policy not to sponsor packages that do not run upstream tests. I make some exceptions for unusual cases (this might be one?), but rarely. Some other people might not be as rigid as I am on this, but I thought you should know. --- That's it! I've removed your package from the sponsor queue for now, but feel free to re-add it when you feel like you've dealt with my review. Apart from the test problem, this is a pretty good package! Thanks for you contribution to Debian. Hello, I've taken another look at pystray. First of all, next time, please don't force push, it made it harder to know what had changed since my last review and I had to start from scratch :( The autopkgtests are currently failing. I suspect you are not running those locally when you are building the package? It's fairly easy to do on sbuild [1] and I would highly recommend you add this to your standard build process. In any case, I get the following error: E Xlib.error.DisplayNameError: Bad display name "" I see you patched the upstream code to be able to run the tests at build (kudos). I suspect either dependencies are missing in the autopkgtest, or you aren't passing your TEST_SKIP_INTERACTIVE var there. In either case, those tests need to pass, otherwise the package won't migrate to testing. Note that: 1. You have duplicate build-dep entries in d/control 2. Your d/salsa-ci.yml file is currently skipping autopkgtests I would've have fixed those before uploading, but with the failing autopkgtests it seems we'll need another back-and-forth round anyway. Cheers, [1]: Look for "run_autopkgtest = 1" in /etc/sbuild/sbuild.conf -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Review of Debian package lazy-loader
Hello, This is my review of the lazy-loader package you asked the Debian Python Team to sponsor in the Debian archive. 1. In d/control, I'm not sure to understand why the binary package is marked as "Multi-Arch: foreign", as this package isn't arch dependent? 2. In d/control, your list of build-dependencies for the source package should be reviewed. * Why do you need 'python3-setuptools' when this package uses flit? * Why the dependency on 'python3-toml'? * You should build-depend on 'pybuild-plugin-pyproject', as this is a PEP517 compatible package. The 'old' flit plugin for pybuild is being deprecated in favor of this one. * since 'python3-pytest' is only used for tests, it should be marked as so using 3. In d/control, although Stefan van der Walt is the author, the copyright should only be "Scientific Python project", as that's the only licensing information in this package. 4. There are many commented lines in d/rules that should just be removed. Note that you do not need 'export DH_VERBOSE = 1' nor 'export PYBUILD_SYSTEM=flit' (since you'll now build with 'pybuild-plugin-pyproject') 5. The autopkgtests you are running in d/tests are redundant. autodep8 already does this for python. You should instead run the upstream test suite as autopkgtests: they are much more meaningful. Have a look at this example: https://salsa.debian.org/python-team/packages/metalfinder/-/tree/debian/master/debian/tests 6. In d/changelog, you marked your entry as "unstable", whereas it should be UNRELEASED. Please re-read the DPT's policy with regards to this. 7. Although I have not listed them here, pretty much all of the lintian tags raised are relevant errors that you should fix. -- You're 90% there! I've removed your package from the sponsor queue for now, but feel free to re-add it when you feel like you've dealt with my review. I'll be happy to sponsor it then. Thanks for your contribution to Debian. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Review of Debian package pystray
Hello, This is my review of the pystray package you asked the Debian Python Team to sponsor in the Debian archive. 1. I doubt d/README.source is needed, as this is a team-maintained package and most of that info is in the Policy :) 2. in d/rules, you are using "override_dh_sphinxdoc" and then calling dh_sphinxdoc. You should instead use "execute_before_dh_sphinxdoc". 3. You are not running any upstream tests, neither at build not as autopkgtests. Tests are very important. How do you know your package isn't broken, or has not been broken by a change in the archive? Only tests can tell you that. I see you've noted that some tests require user confirmations and it indeed seems to be the case for most of the ones in icon_tests.py. * is there a way to bypass this or are those tests simply not relevant in a automated environment? * what about menu_descriptor_tests.py? I gave it a very cursory look, but it doesn't seem to use the confirm() function. Trying to run it gives me an "Xlib.error.DisplayNameError: Bad display name" error though, so chances are you'd need to run tests with xvfb to mock an X session. Note that it is my personal policy not to sponsor packages that do not run upstream tests. I make some exceptions for unusual cases (this might be one?), but rarely. Some other people might not be as rigid as I am on this, but I thought you should know. --- That's it! I've removed your package from the sponsor queue for now, but feel free to re-add it when you feel like you've dealt with my review. Apart from the test problem, this is a pretty good package! Thanks for you contribution to Debian. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
docarray Debian package review
Hello, This is my review of the docarray package you asked the Debian Python Team to sponsor in the Debian archive. 1. In d/control, you've specified version restrictions for build-dependencies, I guess based on setup.py. Most of those are not needed, as those versions aren't even in Debian anymore. For example, you specified python3-setuptools (>= 18.0). The current version in Sid is 65.5.0 and even Stretch has 33.1.1. Version restrictions can be useful for backporting packages, but it's always a good idea to check if they actually make sense. 2. As explained in d/rules, you are not currently running any testsuite, since it requires packages not currently in the archive. It is my personal policy not to sponsor packages that do not run upstream tests. Tests are very important, otherwise, how do you know if your package hasn't been broken by some change in the archive? Some other people might not be as rigid as I am on this, but I thought you should know. 3. To me, d/source/local-options, d/source/options and d/source/patch-header look like superfluous files you could remove. 4. docarray/resources/embedding-projector/index.html.gz seems to be an embedded copy of https://projector.tensorflow.org/. This is not something that can be done in Debian. Sadly, it looks like this file is needed to run docarray? I haven't dug very deep, but that raises a lot of questions with regards to the possibility of actually packaging this in Debian. I might be wrong, as I'm not familiar with docarray, but I would be interested in your reflections on this. 5. d/copyright is incomplete. A lot of files in docarray/docs/datatypes are not documented in d/copyright properly. I see some non-free images (docs/datatypes/image/complicated-image.jpeg) and some free ones, (docs/datatypes/video/chunk-1.png), but this again raises a red flag for me. I'd recommend running decopy as a tool to inspect copyright in files. It's not perfect, but it helps. - That's it for now! I have not tried building this package, as there were too many large flaws I think you should try to address first. Thanks for your contribution to Debian. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Debian Python Team Sprint: December 2-3-4 2022
On 2022-10-05 14 h 50, Louis-Philippe Véronneau wrote: On 2022-09-12 17 h 08, Louis-Philippe Véronneau wrote: Hello! Our next team sprint will be on December 2-3-4 2022 and will be remote. Please register on this wiki page if you are interested: https://wiki.debian.org/Sprints/2022/PythonTeam There are plenty of items in the 'Agenda' section for people who want to help out but have no idea on what to work on :) Please note you need to register **before October 15th** to get food sponsorship. Cheers, Hello hello, Reminder: the deadline to sign up and get food sponsorship is *October 15th*. That's next week! Cheers, > Today is the last day to sign up and get food sponsoring! https://deb.li/2S8U -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: pyyaml 6
On 2022-10-06 21 h 43, Paul Wise wrote: On Fri, 2022-10-07 at 00:10 +0200, Gordon Ball wrote: * Upload to unstable and see what breaks? The experimental pseudo-excuses already say several packages break: https://qa.debian.org/excuses.php?experimental=1&package=pyyaml autopkgtest for ganeti/3.0.2-1: amd64: Regression, arm64: Regression autopkgtest for llvm-toolchain-13/1:13.0.1-7: amd64: Pass, arm64: Regression autopkgtest for satpy/0.37.1-1: amd64: Regression, arm64: Regression autopkgtest for spades/3.15.5+dfsg-1: amd64: Regression So at least these issues need to be investigated and maybe bugs filed. * Request an archive rebuild with this version and see what breaks? Definitely. * File bugs against all likely affected packages with a fixed date for an upload? Definitely. Shameless plug here, but if you do it in time for the DPT sprint (December 2-3-4), fixing packages that broke can even be an agenda item people can work on! https://deb.li/2S8U -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Debian Python Team Sprint: December 2-3-4 2022
On 2022-09-12 17 h 08, Louis-Philippe Véronneau wrote: Hello! Our next team sprint will be on December 2-3-4 2022 and will be remote. Please register on this wiki page if you are interested: https://wiki.debian.org/Sprints/2022/PythonTeam There are plenty of items in the 'Agenda' section for people who want to help out but have no idea on what to work on :) Please note you need to register **before October 15th** to get food sponsorship. Cheers, Hello hello, Reminder: the deadline to sign up and get food sponsorship is *October 15th*. That's next week! Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Enabling salsa-ci on all Debian Python Team repos
On 2022-09-19 06 h 51, Emanuele Rocca wrote: Hello debian-salsa-ci and debian-python! I was wondering if it would make sense to enable CI/CD on Salsa for all projects owned by the Debian Python Team, or if there's any concern about scaling issues in terms of pipeline workers (or anything else really). For the past few days I've been enabling CI/CD on Salsa for various packages owned by the DPT. I've been doing this on a case-by-case basis: if the package I wanted to work on (for reasons unrelated to CI) did not have CI/CD yet, I'd add [1] as the pipeline configuration file and carry on with my work. Perhaps there's an opportunity to automate and getting wider CI usage. Thanks, Emanuele [1] recipes/debian.yml@salsa-ci-team/pipeline Hi, I was told "please don't" 3 years ago and although I've pushed a number of times (in private and in public), I have had no replies: https://salsa.debian.org/salsa/support/-/issues/170 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Debian Python Team Sprint: December 2-3-4 2022
Hello! Our next team sprint will be on December 2-3-4 2022 and will be remote. Please register on this wiki page if you are interested: https://wiki.debian.org/Sprints/2022/PythonTeam There are plenty of items in the 'Agenda' section for people who want to help out but have no idea on what to work on :) Please note you need to register **before October 15th** to get food sponsorship. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Python Team Sprint: poll to find best dates (deadline, September 10th)
On 2022-08-29 17 h 34, Louis-Philippe Véronneau wrote: Thanks to everyone who replied [1]. I think there is enough interest for this to be worth organising. Here's a poll to find the best dates for the sprint: https://deb.li/38VrF There are only 2 options, Oct 28-29-30 & December 2-3-4. We could have a pretty long debate on dates, but I'm making it simple by restricting it to those 2 options :) Please answer the poll before September 10th if you are interested in participating. Once we have a date, I'll create a proper wiki page. Cheers, [1]: https://lists.debian.org/debian-python/2022/08/threads.html#00052 Kindly reminder: if you want your opinion on the sprint dates to be taken in account, please answer the poll *before September 10th* (this Saturday). https://deb.li/38VrF -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Python Team Sprint: poll to find best dates (deadline, September 10th)
Thanks to everyone who replied [1]. I think there is enough interest for this to be worth organising. Here's a poll to find the best dates for the sprint: https://deb.li/38VrF There are only 2 options, Oct 28-29-30 & December 2-3-4. We could have a pretty long debate on dates, but I'm making it simple by restricting it to those 2 options :) Please answer the poll before September 10th if you are interested in participating. Once we have a date, I'll create a proper wiki page. Cheers, [1]: https://lists.debian.org/debian-python/2022/08/threads.html#00052 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Are YOU interested in a potential remote sprint sometime in October/November? (yes YOU!)
On 2022-08-19 14 h 04, Michel Alexandre Salim wrote: Hello, On Wed, Aug 17, 2022 at 08:22:28PM -0400, Louis-Philippe Véronneau wrote: Hello folks, At DC22, a few people seemed interested in a potential Python Team remote sprint, sometime between October and early December. I'm thus writing to the list to see if there is indeed interest for this. If only 2 people reply, I won't push this further :) Here are a few potential ideas of things people could work on, in no particular order: ... - fixing the ~50 packages that are still using 'python3 setup.py' [2] ... I'm not part of the team (yet), but am part of the Python SIG in Fedora and working on getting my DM status here. If I can participate by submitting MRs for salsa.debian.org/python-team, I would love to take part. You don't need to be a DM/DD to join the Python Team! https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#joining-the-team I'd encourage you to join if you want to do work inside the team, as MRs often aren't the best tool in our workdlow. Updating a package means updating multiple git branches and MRs aren't well suited for that :( I've done a remote sprint for the Clojure Team back in May and it went great. Huh neat, I packaged Clojure in Fedora for a while! Each people registered and we asked for a food budget, based on the "Meals and Incidentals Rate" the US government publishes for most cities in the world [12] [13]. I encourage you to look up your city, but I know I ended up eating pretty well :) As I'm not part of the team, I perfectly understand if I don't get a food allowance. If you help during the sprint fixing things, I don't see why you couldn't ask for food sponsorship :) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Are YOU interested in a potential remote sprint sometime in October/November? (yes YOU!)
Hello folks, At DC22, a few people seemed interested in a potential Python Team remote sprint, sometime between October and early December. I'm thus writing to the list to see if there is indeed interest for this. If only 2 people reply, I won't push this further :) Here are a few potential ideas of things people could work on, in no particular order: - working on testing and merging the pybuild-autodep8 feature [1] - fixing the ~50 packages that are still using 'python3 setup.py' [2] - reviewing and merging unnoticed salsa MRs on the Team's packages [3] - fixing policy violations [4] - upstreaming CPython patches [5] - trying to remove all remaining Python 2 packages [6] - working on PEP 668 [7] [8] - working on lintian tags for the team [9] - patching tracker.debian.org (Django) to show pending MRs [10] [11] People are of course welcome to work on whatever other things they see fit for the betterment of the Team :) I've done a remote sprint for the Clojure Team back in May and it went great. Each people registered and we asked for a food budget, based on the "Meals and Incidentals Rate" the US government publishes for most cities in the world [12] [13]. I encourage you to look up your city, but I know I ended up eating pretty well :) I would envision a 3 day sprint (Friday, Saturday, Sunday) being long enough yet not too long for most of us to make progress on key issues without being over-tiring. Happy to hear back from y'all (please do if you're interested). If I see people are interested, I'll send a poll to find the most suitable dates. Cheers, [1]: https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27 [2]: https://lists.debian.org/debian-python/2022/08/msg00046.html [3]: https://salsa.debian.org/groups/python-team/packages/-/merge_requests [4]: https://github.com/sandrotosi/dpt-repos-check/blob/main/violations.txt [5]: see https://pad.riseup.net/p/dc22pythonsprint-keep [6]: see https://lists.debian.org/debian-python/2022/07/msg00065.html [7]: https://discuss.python.org/t/pep-668-marking-python-base-environments-as-externally-managed/ [8]: https://peps.python.org/pep-0668/ [9]: see https://lists.debian.org/debian-python/2022/07/msg00065.html [10]: https://tracker.debian.org/teams/python/ [11]: https://salsa.debian.org/qa/distro-tracker [12]: https://www.gsa.gov/travel/plan-book/per-diem-rates/per-diem-rates-lookup [13]: https://aoprals.state.gov/web920/per_diem.asp -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: pybuild-autopkgtest (was: Notes from the DC22 Python Team BoF)
On 2022-07-27 16 h 32, Julian Gilbey wrote: On Wed, Jul 27, 2022 at 07:45:12PM +0100, Julian Gilbey wrote: On Wed, Jul 27, 2022 at 10:26:33AM -0400, Louis-Philippe Véronneau wrote: The way I see it: 1. We should have a Lintian tag for packages not using the new pybuild-autodep8 autopkgtest. It would be even better if this tag would be a pointed hint that identified 'manually' written unit test autopkgtests that could be replaced. This way, you get something like: python-foo source: not-using-pybuil-autodep8 [debian/tests/unittests] for python packages that have old 'manually' written unit test autopkgtests and: python-foo source: not-using-pybuild-autodep8 [no-autopkgtest] for python packages without any autopkgtest. 2. lintian-brush (or something else, but I think lintian-brush is the right tool) would go over these packages to: 2.1 Add the new autodep8 autopkgtests and build the package to see if they pass 2.2 Remove the "manual" unit test autopkgtests if 2.1 succeeds 2.3 Open a bug report if 2.1 fails I'd be wary about 2.2 and 2.3. I have several packages where I know that an automated test will fail; there are all sorts of weird cases where I've had to write tests manually. I would also be quite cross if manually crafted tests were automatically removed, especially in cases such as Simon mentioned where they do things that that automatically generated test does not do. Another thing I could imagine happening is that the automated test succeeds in a trivial way - it succeeds but doesn't actually test much because of the nature of the package. On the other hand, a bug report saying something like the following seems much more reasonable: "We've tested this package using the automated autopkgtest system and it seems to work by adding the line 'Testsuite: autopkgtest-pkg-pybuild'; please check that the automated tests cover all of the tests of your manually written debian/tests/* and if so, then please remove them. The autopkgtest-pkg-pybuild logs are attached." This would give the maintainer the chance to decide how best to proceed. Here's another alternative to steps 2.1-2.3 based on this: For packages which currently have manually-written autopkgtests: 2.A Try removing debian/tests and adding Testsuite: autopkgtest-pkg-pybuild to debian/control, then building the package and running autopkgtest. 2.B If this works, then submit a bug report to the BTS as I suggested above. 2.C If this does not work, don't do anything more; trust that the maintainer knew what they were doing when they wrote the manual autopkgtests. For packages which don't currently have manually-written autopkgtests: 2.A' Try adding Testsuite: autopkgtest-pkg-pybuild to debian/control, then building the package and running autopkgtest. 2.B' If this works, then either Janitor adds this line to debian/control or submit a bug report to the BTS to recommend this. (But we would not expect Janitor to do step 2.1', so this might have to be a different setup, or maybe the script doing 2.A' could leave a list of packages for Janitor, or something like that.) 2.C' If this does not work, submit a wishlist bug to the BTS to recommend that the maintainer adds some autopkgtest tests, either by making the autodep8 system work or by writing some manual tests. I'd be wary about adding lintian tags for this, though: with so many packages not being able to use the autodep8 system (I vaguely recall someone suggesting that a third of Python packages would not be able to use the system), that's a lot of packages getting false positives. In particular, for the suggested first version of not-using-pybuild-autodep8 tag (which would probably be better named manual-autopkgtest-could-be-pybuild-autodep8), how would lintian go about identifying which packages fall into category 2.B and which into 2.C? The second version of the tag (better named something like no-autopkgtest-could-use-pybuild-autodep8, but that's still not very good) is less problematic. This all makes a lot of sense to me and I think this is the way forward, once the MR is merged. Thanks for the discussion. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [MBF] pybuild: Stop calling setup.py test?
On 2022-08-15 14 h 27, Stefano Rivera wrote: Calling "setup.py test" has been deprecated since setuptools 28.5. That's 6 years ago. pybuild calls currently setup.py test, when it can see that the package supports it, and another test runner hasn't been selected. I looked at dropping support for this (https://bugs.debian.org/982298) last year. I did some test builds and decided that breaking 50 odd packages to stop calling setup.py test wasn't worth it. I just ran the tests again, and the numbers are 41 new FTBFS, and 54 packages start emitting "Ran 0 tests", so they lost test coverage. dd-lists attached. That's an improvement over last year, but still enough to give me pause on just changing pybuild and breaking packages. We also now know that calling setup.py at all is deprecated. "setup.py test" support hasn't been removed yet, and I don't know if it will be, at this point... Options: 1. Change pybuild, cause 41 new FTBFS, and 54 packages to lose testing. File FTBFS bugs. 2. File "Severity: important" bugs on the packages that would FTBFS or lose testing. Change pybuild when most of these are closed. 3. File "Severity: minor" bugs on the packages that would FTBFS or lose testing. Leave pybuild as is, for now. Change pybuild when upstream setuptools drops support for "setup.py test". I think we're currently in a good place wrt the Bookworm release. This gives us some leeway in what we want to do with the time we have until the freeze :) I think option 2 is reasonable _IF_ (big 'if' here) we plan to stick with python 3.10. I don't think we need 50 extra RC bugs in addition to all the potential 3.11 failures. Otherwise, I'd go with 3. 1 seems unnecessary disruptive. I guess fixing those bugs could be a valuable sprint goal for the potential remote sprint we discussed at DC22. I'll try to prod people on the ML in the next few days to see who'd be interested. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: pybuild-autopkgtest (was: Notes from the DC22 Python Team BoF)
On 2022-07-27 04 h 18, Julian Gilbey wrote: There seems to be little point running both pybuild-autopkgtest and a manually written debian/tests/* test suite. So would the script only add pybuild-autopkgtest to packages which don't have a manually written debian/tests/* suite? The way I see it: 1. We should have a Lintian tag for packages not using the new pybuild-autodep8 autopkgtest. It would be even better if this tag would be a pointed hint that identified 'manually' written unit test autopkgtests that could be replaced. This way, you get something like: python-foo source: not-using-pybuil-autodep8 [debian/tests/unittests] for python packages that have old 'manually' written unit test autopkgtests and: python-foo source: not-using-pybuild-autodep8 [no-autopkgtest] for python packages without any autopkgtest. 2. lintian-brush (or something else, but I think lintian-brush is the right tool) would go over these packages to: 2.1 Add the new autodep8 autopkgtests and build the package to see if they pass 2.2 Remove the "manual" unit test autopkgtests if 2.1 succeeds 2.3 Open a bug report if 2.1 fails This way, we can imagine a transition that would be mostly automated. We'd probably have to fix the ones that failed to migrate manually, but it would be much less work :) Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: Notes from the DC22 Python Team BoF
On 2022-07-27 03 h 52, Thomas Goirand wrote: On 7/25/22 09:37, Julian Gilbey wrote: On Sat, Jul 23, 2022 at 07:52:19PM +0200, Louis-Philippe Véronneau wrote: Hey folks, We had a Python Team BoF at DC22 earlier today and I thought relaying the notes we took in gobby here would be a good idea. Thanks for the notes, Louis-Philippe, and sorry I couldn't join you! A few comments -- == python3.11 == python3.11 release has been delayed, from october 2022 to december 2022. [...] My 2 cents' worth is as the 3.9->3.10 transition took several months, and was quite complicated, it is not wise to attempt the 3.10->3.11 before the freeze. We could then potentially go straight to 3.12 a few months after the bookworm freeze rather than going to 3.11 first. And that will probably be quite painful. I agree, also because 3.10 wont be EOL before Bookworm becomes LTS. As I said during the BoF, I'm also in favor of sticking with 3.10 for bookworm. I think we should aim for a stable Python ecosystem. Using the time we have left to iron out bugs and failures in our packages for 3.10 sounds like a much better decision than trying to fix a ton of RC bugs for 3.11 in time for the final freeze. However, it's quite tempting to upgrade to 3.11 because: - our users will prefer having the latest stable release of Python in our latest release, rather than an old version. - 3.11 has many optimization (it's said to be 25% faster) So if we can at least TRY, it's not a so bad idea... Hopefully, we can take the decision to reverse if needed. AFAIU, doko said it was pretty hard to go back, since that meant recompiling pretty much all the python extensions. I'd much rather we don't waste tons of energy trying to get 3.11 and then deciding it's not working. We know we only have a 2-3 months window of opportunity to make the transition, IMO that's too short. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: pybuild-autopkgtest (was: Notes from the DC22 Python Team BoF)
On 2022-07-26 20 h 13, Paul Wise wrote: > On Tue, 2022-07-26 at 17:53 -0300, Antonio Terceiro wrote: > >> Well the idea is to only actually commit the change and upload the >> package with the new Testsuite value after ensuring that actually works, >> i.e. that the autopkgtest passes. > > This sounds like something for lintian and the Janitor. I suggest > lintian because not all Python packages are in the team and I suggest > the Janitor because it makes changes automatically, although I am not > entirely sure if it runs autopkgtests yet? I agree Lintian+Janitor is probably the best tool combo for this, yes. If Jelmer agrees to do the Janitor part, I'll be happy to do the Lintian part once the pybuild-autopkgtest MR has been merged and we've confirmed this feature is ready for large-scale deployment. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Notes from the DC22 Python Team BoF
Hey folks, We had a Python Team BoF at DC22 earlier today and I thought relaying the notes we took in gobby here would be a good idea. -- == python3.11 == python3.11 release has been delayed, from october 2022 to december 2022. python3.12 is planned for october 2023. Debian testing freeze for transitions is in January 2023, which is very tight. Do we want to try python3.11 in bookworm, or do we delay it for after the freeze? One problem we'll likely have, is upstream python libraries might not have started playing with 3.11 already. It might be hard to try to use beta versions right now to try and prepare the transition. Once the default version in the archive has changed, it's hard to revert to an older one. Some packages like pandas and numba (and dart?) might need an exception from the Release Team to allow us to upload versions more compatible with 3.11 after the bookworm release. For sure, this is a lot of work for me (zigo) on the OpenStack packages. On each Python 3 release, this makes me fix lots of stuff. At the moment, upstream OpenStack isn't even on Python 1.10 on its CI... As a datapoint, Ruby always releases on Christmas, and the Ruby team has never even attempted to push that as a default in the next Debian stable release. 3.11 beta 4 is already in unstable, people can start trying to build against it. 3.10 EOL is october 2026. upstream is working on lots of speed optimizations. 3.11 has a bunch of these that our users would appreciate. 3.11 as an extra supported version might work out, but it will create subtle breakage for packages that happen not to be compatible with that version, so we should avoid that in a stable release. 3.11 cannot be easily tested via an archive rebuild since there are about 25 stages to a transition which build on top of one another. Doko asked if it would be possible to have the Python releases 1 month earlier, to which people replied: "Why doesn't Debian change their release dates?". :( == PEP 668 == https://discuss.python.org/t/pep-668-marking-python-base-environments-as-externally-managed/ https://peps.python.org/pep-0668/ We would like to have an directory reserved for distro-managed packages, where pip should not be installing anything. upstream pip seems to be keen on that, although there are currently no issues in their bug report about it. it would also be nice to have a python option to only use distro-managed packages on the load path. == pybuild improvements == getting the autopkgtest MR in would be great https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27 We need people to test this MR some more, although it seems fairly mature. It might be a good idea to have a line in d/control to let us migrate from the existing autopkgtests running unit tests to the new automated MR. == lintian tags requests for the team == pollo will write you Python-related lintian tags. Ask him to. * find packages that are building extensions only for the current Python default version, instead of all the available python versions. * warn packages still using distutils.version (removal in python 3.12) It would be nice if lintian brush could help us migrate to pybuild-pyproject - pollo can ping Jelmer. == upstream cpython patches == Some work has been done, but some Debian patches still need to be forwarded to python upstream == where are we with python2rm? == pypy is still a blocker. A solution would be to bundle the python2 source code in it. Other blockers (https://release.debian.org/transitions/html/python2-rm.html): python-defaults python2.7 pam-python python-stdlib-extensions redland-bindings #938345 orphaned, key package mozilla-devscripts (used for firefox extension building) #937085 key package python-setuptools python2-pip six == possible remote sprint? == a good time to have a remote sprint would be after adding python3.11 as the new default (and thus creating new RC bugs). Therefore, this would be between end of October up to early December. == tracker.d.o dashboard == https://tracker.debian.org/teams/python-modules/ Would be great to have Salsa MRs on it -- Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
QA uploads and tags
Hi! I saw that you've done QA uploads on some packages in the Debian Python Team after changes made by the Janitor. Thanks a lot! Looking at python-mpv [1], it seems the tag you made is "1.0.1-2". I would've have expected it to be "debian/1.0.1-2". This is based on the DPT policy, that says we try to adhere to DEP-14, which specifies tag format in the "Tagging package releases" section [2]. All in all this is pretty minor, but do you think you could modify your scripts accordingly? Cheers, [1]: https://salsa.debian.org/python-team/packages/python-mpv [2]: https://dep-team.pages.debian.net/deps/dep14/ -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Packaging of pdm (Was: pdm-pep517: Shall we package it now?)
On 2022-07-03 00 h 49, Boyuan Yang wrote: > Hi all, > > 在 2022-06-28星期二的 09:24 -0400，Boyuan Yang写道： >> Hi all, >> >> I have encountered more and more packages that uses pdm-pep517 as build >> backend. Looking at [1], existing packages in Debian added patches to >> manually switch to other backends, such as Poetry. >> >> I am wondering if it's time to package pdm-pep517 itself [2], or is there >> any blocking for it. I am aware that some sort of bootstrapping might be >> needed since pdm-pep517 seems to build-depends on itself. Besides that, >> what >> about packaging of pdm? Please correct me if needed: my mind and my >> packaging work is still stuck in the old times of setup.py, and I just >> started to look into the new ecosystem of pep517. Thanks! > > As an update, I also pushed pdm package [3] as well as several of its build- > dependencies into the NEW queue. > > [3] http://salsa.debian.org/python-team/packages/pdm Nice! As I'm sure people will confuse "python3-pdm" (the cli tool) and "python3-pdm-pep517" (the tool used to build packages), I've created a Lintian tag: https://salsa.debian.org/lintian/lintian/-/merge_requests/401 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: pdm-pep517: Shall we package it now?
On 2022-07-07 15 h 36, Boyuan Yang wrote: > Hi, > > 在 2022-06-28星期二的 11:19 -0400，Louis-Philippe Véronneau写道： >> On 2022-06-28 09 h 24, Boyuan Yang wrote: >>> Hi all, >>> >>> I have encountered more and more packages that uses pdm-pep517 as build >>> backend. Looking at [1], existing packages in Debian added patches to >>> manually switch to other backends, such as Poetry. >>> >>> I am wondering if it's time to package pdm-pep517 itself [2], or is >>> there >>> any blocking for it. I am aware that some sort of bootstrapping might be >>> needed since pdm-pep517 seems to build-depends on itself. Besides that, >>> what >>> about packaging of pdm? Please correct me if needed: my mind and my >>> packaging work is still stuck in the old times of setup.py, and I just >>> started to look into the new ecosystem of pep517. Thanks! >>> >>> Regards, >>> Boyuan Yang >>> >>> >>> [1] https://codesearch.debian.net/search?q=pdm.pep517 >>> [2] https://github.com/pdm-project/pdm-pep517 >> >> Once packaged, please ping me so I can update the >> "missing-prerequisite-for-pyproject-backend" Lintian tag accordingly and >> let people know they can migrate to it. > > This is now accepted at https://tracker.debian.org/pkg/pdm-pep517 . Thanks for the work on this. Here's the lintian MR for reference: https://salsa.debian.org/lintian/lintian/-/merge_requests/400 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: DebConf22 -- Python Team BoF + Sprint?
On 2022-03-28 12 h 17, Louis-Philippe Véronneau wrote: > On 2022-03-26 18 h 02, Stefano Rivera wrote: >> Hi Louis-Philippe (2022.03.20_21:51:45_+) >>> I think it would also be neat to have a team sprint during DebCamp. Here >>> are a few ideas of things we could work on: >>> >>> * pybuild improvements (getting the autopkgtest MR in would be great) >>> * general team QA (maybe based on [2]?) >>> * lintian tags used for the team >> >> +1 to a sprint, as usual. >> >> I think upstream cpython would also appreciate it if we did a pass >> through all of our cpython patches and ensured they were forwarded. Ping >> bugs, etc. Same goes for any core libraries / big packages. >> I've attempted to document them all, this year, which is a start. But >> only a start. In many cases forwarding the patch would require clearly >> defining the bug, writing reproducer scripts, etc. >> >> I'd happily mentor people in working on this. > > I've just submitted the sprint too, the description links to: > > https://wiki.debian.org/DebConf/22/Sprints > > Which links to: > > https://pad.riseup.net/p/dc22pythonsprint-keep > > Please add relevant goals there :) Hello folks! The Python Team BoF has been scheduled on Saturday July 23rd at 14:00. https://debconf22.debconf.org/talks/8-python-team-bof/ As for the sprint, let's meet during DebCamp, on Friday 15th! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: pdm-pep517: Shall we package it now?
On 2022-06-28 09 h 24, Boyuan Yang wrote: > Hi all, > > I have encountered more and more packages that uses pdm-pep517 as build > backend. Looking at [1], existing packages in Debian added patches to > manually switch to other backends, such as Poetry. > > I am wondering if it's time to package pdm-pep517 itself [2], or is there > any blocking for it. I am aware that some sort of bootstrapping might be > needed since pdm-pep517 seems to build-depends on itself. Besides that, what > about packaging of pdm? Please correct me if needed: my mind and my > packaging work is still stuck in the old times of setup.py, and I just > started to look into the new ecosystem of pep517. Thanks! > > Regards, > Boyuan Yang > > > [1] https://codesearch.debian.net/search?q=pdm.pep517 > [2] https://github.com/pdm-project/pdm-pep517 Once packaged, please ping me so I can update the "missing-prerequisite-for-pyproject-backend" Lintian tag accordingly and let people know they can migrate to it. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: archive rebuild for pytest from experimental
Thank you for your guidance. I have filled all of the regressions you reported in the BTS: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pytest7;users=debian-python@lists.debian.org Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ On 2022-06-15 15 h 32, Lucas Nussbaum wrote: > Hi, > > On 15/06/22 at 15:22 -0400, Louis-Philippe Véronneau wrote: >> Thanks a lot for this rebuild, very useful. >> >> I was told you needed a list of pytest regressions for you to fill bug >> reports. >> It's my first time doing this, so if I missed something you needed, please >> say >> so. > > I was only asked for the rebuild itself, but can also file bugs > (however, given the small number of bugs to file, there's no big > advantage with me automating) > > I would need a template similar to > https://salsa.debian.org/lucas/collab-qa-data/-/blob/master/ftbfs.txt.liquid > >> # Valid pytest regression, deprecated feature: >> >> * asyncpg 0.25.0-1 (deprecated pytest feature: -k-) >> * junitparser 2.5.0-2 (deprecated pytest feature: -k-) >> * openlp 2.9.4-2 (deprecated pytest feature: -k-) >> * python-astor 0.8.1-2 (deprecated pytest feature: -k-) >> * python-aws-xray-sdk 0.95-2 (deprecated pytest feature: -k-) >> * python-b2sdk 1.3.0-2 (deprecated pytest feature: -k-) >> * python-easydev 0.12.0+dfsg-2 (deprecated pytest feature: -k-) >> * python-h11 0.13.0-1 (deprecated pytest feature: -k-) >> * python-jose 3.3.0+dfsg-2 (deprecated pytest feature: -k-) >> * python-matrix-nio 0.19.0-2 (deprecated pytest feature: -k-) >> * python-twitter 3.3-3 (deprecated pytest feature: -k-) >> * sphinx-gallery 0.10.1-1 (deprecated pytest feature: -k-) >> * spyne 2.14.0-1 (deprecated pytest feature: -k-) >> * flask 2.0.1-2 (deprecated pytest feature: pytest.warns(None)) >> * photutils 1.4.0-3 (deprecated pytest feature: pytest.warns(None)) >> * python-ase 3.22.1-1 (deprecated pytest feature: pytest.warns(None)) >> >> # Probably a valid pytest regression, but I'm less sure: >> >> * python-biom-format 2.1.10-4 (not sure what the problem is, seems like >> pytest) >> * python-httplib2 0.20.2-3 (not sure what the problem is, seems like pytest) >> * python-pytest-subtests 0.6.0-1 (not sure what the problem is, seems like >> pytest) >> * python-can 3.3.2.final~github-3 (AttributeError: pytest.approx() is not >> supported in a boolean context) >> * python-protobix 1.0.2-11 (plugin distutils failed with: exit code=5) >> * python-pykka 2.0.3-2 (AttributeError: module pytest has no attribute >> collect) >> * python-ratelimiter 1.2.0.post0-1 (AttributeError: module pytest has no >> attribute collect) >> * python-pytest-xprocess 0.18.1-3 (pytest.PytestUnraisableExceptionWarning: >> Exception ignored) >> >> # Doesn't seem like a pytest regression, but I could be wrong?: > > They are probably worth investigating further: I actually did two > rebuilds (one with vanilla unstable, the other with unstable+pytest from > experimental) => it's unlikely that they are NOT pytest regressions. > >> * humanfriendly 10.0-1 (upstream doesn't actually use pytest?) >> * pyglet 1.5.14-2 (py3.9 OK, py3.10 fails) >> * pyranges 0.0.111+ds-1 (py3.9 OK, py3.10 fails with Fatal Python error: Bus >> error) > > I had to kill that one, it went in some sort of infinite loop. Probably > worth investigating manually. > >> * pytest-pylint 0.18.0-3 (AssertionError) >> * python-qtpy 2.1.0-2 (TypeError: the 'package' argument is required to >> perform a relative import) >> * sentry-python 1.4.3-1 (AssertionError: previous item was not torn down >> properly) >> >> # Already fixed in the archive: >> >> * monitoring-plugins-systemd 2.3.1-2 > > Lucas
Re: archive rebuild for pytest from experimental
Thanks a lot for this rebuild, very useful. I was told you needed a list of pytest regressions for you to fill bug reports. It's my first time doing this, so if I missed something you needed, please say so. # Valid pytest regression, deprecated feature: * asyncpg 0.25.0-1 (deprecated pytest feature: -k-) * junitparser 2.5.0-2 (deprecated pytest feature: -k-) * openlp 2.9.4-2 (deprecated pytest feature: -k-) * python-astor 0.8.1-2 (deprecated pytest feature: -k-) * python-aws-xray-sdk 0.95-2 (deprecated pytest feature: -k-) * python-b2sdk 1.3.0-2 (deprecated pytest feature: -k-) * python-easydev 0.12.0+dfsg-2 (deprecated pytest feature: -k-) * python-h11 0.13.0-1 (deprecated pytest feature: -k-) * python-jose 3.3.0+dfsg-2 (deprecated pytest feature: -k-) * python-matrix-nio 0.19.0-2 (deprecated pytest feature: -k-) * python-twitter 3.3-3 (deprecated pytest feature: -k-) * sphinx-gallery 0.10.1-1 (deprecated pytest feature: -k-) * spyne 2.14.0-1 (deprecated pytest feature: -k-) * flask 2.0.1-2 (deprecated pytest feature: pytest.warns(None)) * photutils 1.4.0-3 (deprecated pytest feature: pytest.warns(None)) * python-ase 3.22.1-1 (deprecated pytest feature: pytest.warns(None)) # Probably a valid pytest regression, but I'm less sure: * python-biom-format 2.1.10-4 (not sure what the problem is, seems like pytest) * python-httplib2 0.20.2-3 (not sure what the problem is, seems like pytest) * python-pytest-subtests 0.6.0-1 (not sure what the problem is, seems like pytest) * python-can 3.3.2.final~github-3 (AttributeError: pytest.approx() is not supported in a boolean context) * python-protobix 1.0.2-11 (plugin distutils failed with: exit code=5) * python-pykka 2.0.3-2 (AttributeError: module pytest has no attribute collect) * python-ratelimiter 1.2.0.post0-1 (AttributeError: module pytest has no attribute collect) * python-pytest-xprocess 0.18.1-3 (pytest.PytestUnraisableExceptionWarning: Exception ignored) # Doesn't seem like a pytest regression, but I could be wrong?: * humanfriendly 10.0-1 (upstream doesn't actually use pytest?) * pyglet 1.5.14-2 (py3.9 OK, py3.10 fails) * pyranges 0.0.111+ds-1 (py3.9 OK, py3.10 fails with Fatal Python error: Bus error) * pytest-pylint 0.18.0-3 (AssertionError) * python-qtpy 2.1.0-2 (TypeError: the 'package' argument is required to perform a relative import) * sentry-python 1.4.3-1 (AssertionError: previous item was not torn down properly) # Already fixed in the archive: * monitoring-plugins-systemd 2.3.1-2 Cheers! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: DebConf22 -- Python Team BoF + Sprint?
On 2022-03-26 18 h 02, Stefano Rivera wrote: > Hi Louis-Philippe (2022.03.20_21:51:45_+) >> I think it would also be neat to have a team sprint during DebCamp. Here >> are a few ideas of things we could work on: >> >> * pybuild improvements (getting the autopkgtest MR in would be great) >> * general team QA (maybe based on [2]?) >> * lintian tags used for the team > > +1 to a sprint, as usual. > > I think upstream cpython would also appreciate it if we did a pass > through all of our cpython patches and ensured they were forwarded. Ping > bugs, etc. Same goes for any core libraries / big packages. > I've attempted to document them all, this year, which is a start. But > only a start. In many cases forwarding the patch would require clearly > defining the bug, writing reproducer scripts, etc. > > I'd happily mentor people in working on this. I've just submitted the sprint too, the description links to: https://wiki.debian.org/DebConf/22/Sprints Which links to: https://pad.riseup.net/p/dc22pythonsprint-keep Please add relevant goals there :) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
DebConf22 -- Python Team BoF + Sprint?
Hello team! The DebConf22 content team has issued a call for papers [1]. As I'm planning to be there this year, I'd be happy to send a proposal for our annual BoF :) I think it would also be neat to have a team sprint during DebCamp. Here are a few ideas of things we could work on: * pybuild improvements (getting the autopkgtest MR in would be great) * general team QA (maybe based on [2]?) * lintian tags used for the team I don't think any of this is controversial, but I'll give y'all a few days to reply before submitting the talks :) [1]: https://debconf22.debconf.org/cfp/ [2]: https://github.com/sandrotosi/dpt-repos-check/blob/main/violations.txt -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Should we allow Janitor to commit directly to all DPT packages?
On 2022-02-17 12 h 39, Sandro Tosi wrote: > Hello all, > the question is essentially all in the subject line, and my answer is yes. > > I receive notifications for all MRs opened against DPT packages, and > Janitor's are always pretty much ready to merge as is, and so i think > we should let Janitor commit directly to the team packages. > > Jelmer is in CC (not sure if he's subscribed), in case he wants to > chime in on the implication of this discussion. > > Regards, You sent a mail on the list on 2020-07-27 about this and the general consensus (3-4 replies) was that it was a good idea. Anyway, I also vote yes! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Moving deepdiff to the Python Team? (and maybe taking over)
CleverCSV and ordered-set went through NEW 2 days ago, so I tweaked what Andreas had done and uploaded the latest upstream version of deepdiff to unstable. I had a look at the upstream docs, but it seems nothing builds a clean man page. Clearly something that could be improved :) Note that I also moved the default branch from `master` to `debian/master` on Salsa, per the team's policy. Cheers, PS: I'm not planning on maintaining this package btw, this really was a one-off. New versions should be easy to update, since all the deps are now in Sid :) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: Cleaning up the Salsa DPT landing page
On 2022-01-17 12 h 31, Scott Kitterman wrote: > On Monday, January 17, 2022 12:20:59 PM EST Louis-Philippe Véronneau wrote: >> Hey folks, >> >> The merger between the DPMT and the PAPT into a single entity has been >> pretty successful IMO and I think it's time to cleanup the Salsa DPT >> landing page. >> >> Looking at https://salsa.debian.org/python-team, I would propose the >> following: >> >> 1. Delete the empty DPMT sub-group at >> https://salsa.debian.org/python-team/modules >> >> 2. Delete the empty PAPT sub-group at >> https://salsa.debian.org/python-team/applications > > I don't have an opinion on #3 and #4. I mostly care about #3 in #4 :P > Might it be better to leave these with a description that explains where they > went? There's lots of things that refer to DPMT/PAPT and I don't think all > the packages have been uploaded with the correct Vcs-* data yet. It doesn't > hurt to leave them there and if they explain where to look instead, I think > the chances of someone being confused later are reduced. The following lintian tags flag packages using the old Vcs-* data: https://lintian.debian.org/tags/old-papt-vcs (11 packages) https://lintian.debian.org/tags/old-dpmt-vcs (431 packages) Those packages have been fixed in git though, as Ondřej ran a script to fix all of them a while ago already. Someone correct me if I'm wrong, but I don't think keeping empty dirs does anything to the Salsa redirects though. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Reaching team consensus on usage of py3versions -r and X-Python3-Version in Lintian
Hey folks, I'm following up on bug #1001677 [1] on the DPT's list to try to reach consensus, as I think the Lintian tags that were created to fix this bug are not recommending the proper thing. As a TL;DR for those of you who don't want to read the whole BTS thread, jdg saw that a bunch of packages were using `py3versions -r` in autopkgtests, and this fails when there's no X-Python3-Version variable in d/control. The fix that Lintian now proposes for packages that use `py3versions -r` in autopkgtests is to set X-Python3-Version. I think the proper fix would be to ask people to move away from `py3versions -r` if there is no X-Python3-Version, and use`py3versions -s` instead. As such, I think we should ask the Lintian maintainers to: 1. Change the desc for tag declare-requested-python-versions-for-test to The specified test attempts to query the Python versions requested by your sources with the command py3versions --requested but your sources do not actually declare those versions with the field X-Python3-Version. . Please query all supported Python versions with the command py3versions --supported in your test instead. 2. Change the desc for tag query-requested-python-versions-in-test to The specified test queries all supported Python versions with the command py3versions --supported but your sources request a specific set of versions via the field X-Python3-Version. . Please delete the field X-Python3-Version, as it is not needed. These changes would push maintainers to use `py3versions -s`, but wouldn't ask people using `py3versions -r` and X-Python3-Version to make any changes. AFAIU, the only valid use of X-Python3-Version would be a package that fails to build on an older but currently supported version of Python (let's say 3.9) but builds on the newer version (say 3.10). I think such use cases are pretty rare though. Cheers, [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001677 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Cleaning up the Salsa DPT landing page
Hey folks, The merger between the DPMT and the PAPT into a single entity has been pretty successful IMO and I think it's time to cleanup the Salsa DPT landing page. Looking at https://salsa.debian.org/python-team, I would propose the following: 1. Delete the empty DPMT sub-group at https://salsa.debian.org/python-team/modules 2. Delete the empty PAPT sub-group at https://salsa.debian.org/python-team/applications 3. In the 'tools' sub-group, rename the 'python-modules' sub-sub-group to 'policy' and delete everything that is not the 'policy.rst' file, as people now use the 'packages' sub-sub-group for tracking purposes https://salsa.debian.org/python-team/tools/python-modules 4. Delete the legacy 'python-apps' sub-sub-group https://salsa.debian.org/python-team/tools/python-apps Happy to hear what others think of this. I don't have the permissions to enact this anyway, so if we reach consensus, and admin will have to make the actual changes :) Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
ponyorm v0.7.15rc1, python3.10 and github releases
Hello! Upstream ponyorm released v0.7.15rc1, which adds python3.10 support and thus fixes #1000716. I ran a quick sbuild and the testsuite passes and everything seems good. Since it is team maintained, I'd have updated the package in unstable, but the latest pypi tarball changes the default carriage return, and creates a huge diff on the upstream branch. This causes some patches to fail to apply, etc. Would you mind if I migrated ponyorm to the github releases, using uscan's git mode? I've made a quick test and it does solves this issue :) Asking, since I'd be pretty upset if someone were to do the opposite on a package I team maintain :P Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: DPT repositories checks/"violations" report
On 2022-01-03 01 h 30, Scott Kitterman wrote: > Since this is all about team Git repositories, someone should just fix them > (modulo the one about using pypi, which I think we mostly agree isn't > something someone unfamiliar with the package can 'fix'). But that doesn't prevent future errors from popping up and doesn't make maintainers aware of their errors (so they can learn from it). I think the "perfect" solution would be to have an automated tool (aka janitor) fixing these automatically, but this would require more work. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: DPT repositories checks/"violations" report
On 2021-12-12 01 h 23, Sandro Tosi wrote: >> I think there's still one point we need to figure out: how to make >> these remarks known to the packages maintainers, instead of all of >> them just being in a text file. > > This is still an open point, and i welcome ideas Is there a reason why we shouldn't just file bugs in the BTS? I get it's not the perfect tool for that, but it would certainly help reach the maintainers. Using a common usertag would also make it easier to find and fix these issues en masse ;) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: Moving deepdiff to the Python Team? (and maybe taking over)
On 2021-12-25 08 h 01, Andreas Tille wrote: > Am Fri, Dec 24, 2021 at 11:49:49PM +0100 schrieb Michael Banck: >> AFAICT, the newer deepdiff requires the following unpackaged modules: >> >> https://github.com/rspeer/ordered-set I've just uploaded this one to NEW, it's packaged at: https://salsa.debian.org/python-team/packages/python-ordered-set >> https://github.com/alan-turing-institute/CleverCSV Were you planning to work on this one? I _could_ package it myself, but it depends on pandas and so far I've successfully avoided maintaining packages that touch it :) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: Moving deepdiff to the Python Team? (and maybe taking over)
On 2021-12-23 06 h 16, Michael Banck wrote: > I'm not in > https://salsa.debian.org/groups/python-team/packages/-/group_members > AFAICT so either you will have to remove me as maintainer or add me to > that group I guess. Here's how you can join the team: https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst#joining-the-team If you do not wish to join the team, I can also remove you as uploader and add myself instead. Cheers, and thanks a lot Andreas! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Moving deepdiff to the Python Team? (and maybe taking over)
Hi! One of the packages I maintain is currently broken by BTS 1001292 [1] and it seems deepdiff is in need of some love. Would you be open to moving it to the Python Team? I'd be more than happy to update it to the latest upstream version (seems like it would fix the bug in question). It doesn't seem like there's a VCS though, so that might require some work on your side. If you want, I'd also be happy to take over and maintain it in the Python Team myself. Happy holidays! [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001292 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Review of python-bonsai
Hi!
Here's my review of python-bonsai:
1. d/control:
* You don't need the "(>= 3.6)" restriction for python3-all-dev, as that
version isn't even in oldstable.
* sphinx-common isn't needed for the source package, as python3-sphinx
depends on it
* "python3 (>= 3.6)" is not required for python3-bonsai,
${python3:Depends} should take care of that for you.
* IMO, python3-bonsai should recommend or suggest python3-bonsai-doc,
but that's up to you.
-
2. d/copyright:
* you forgot to add a debian/* section. AFAIU, noirello isn't the one
who wrote d/rules :)
* .appveyor/run_with_env.cmd is licensed CC0. You probably don't need
those files, so you can exclude them from the source package using
Files-Excluded in d/copyright
* the MIT license in Debian is named "Expat", for historical reasons.
-
4. d/rules:
* You left "export DH_VERBOSE = 1" uncommented.
* I'm curious to why you need to set "export LC_ALL = C.UTF-8".
-
5. d/tests:
I don't have an autopkgtests setup that has machine-level isolation. You
ran that code and it works?
-
6. d/watch:
You left "" in there instead of replacing it by the actual
project's name (have a look at Lintian) :) Note you can use the "git
tag" mode to simplify this file (not that it's required, your file works
as-is): [1]
-
7. Upstream code
Have you read the upstream code? It's something you should do (and you
should read all the changes for each new update). Not that you have to
do a proper security audit, but you should go through the code to be
sure there's no obvious or dangerous things in there.
Otherwise, good job! Fix those, ping me and if it's OK, I'll read the
upstream code myself and sponsor it.
Cheers,
[1]:
https://salsa.debian.org/python-team/packages/python-mediafile/-/blob/debian/master/debian/watch
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org
⠈⠳⣄
Re: grammalecte sponsorship (was: Re: Fwd: grammalecte_2.1.2+ds-1_amd64.changes REJECTED)
On 2021-12-01 15 h 19, Romain Porte wrote: > Hi, > > 27/11/2021 19:32, Louis-Philippe Véronneau : >> Sorry for being so slow to sponsor. >> >> While trying to build, I get this error: >> >> mv: will not overwrite just-created >> 'debian/tmp/usr/share/doc/python3-grammalecte/README.txt' with >> 'debian/tmp/usr/lib/python3.9/dist-packages/grammalecte/README.txt' >> >> This happens because you are trying to move multiple files to the same >> path: >> >> debian/tmp/usr/lib/python3.10/dist-packages/grammalecte/README.txt >> debian/tmp/usr/lib/python3.9/dist-packages/grammalecte/README.txt >> >> -> debian/tmp/usr/lib/python3.9/dist-packages/grammalecte/README.txt >> >> I'd suggest singling out one python interpreter with `py3versions -d`? > > Fixed by this commit: > https://salsa.debian.org/python-team/packages/grammalecte/-/commit/20e2d458b360c81d929d3d8cab7db64ca21e0d0a > > > New version available on salsa or on sponsors at your convenience: > > https://mentors.debian.net/debian/pool/main/g/grammalecte/grammalecte_2.1.2+ds-1.dsc > > > Bests > Uploaded to NEW! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: Installing data files with pybuild
On 2021-12-01 12 h 28, Andrey Rahmatullin wrote: > >> Only the .py files are currently included in the build; what is the >> best way to include all of the data files after the build step and >> before the test step, and then to ensure they are included in the >> final package? > Apart from fixing setup.py? execute_after_dh_auto_install I guess. Or you can use debian/foobar.install to install the missing files in the right location, and keep your d/rules file cleaner :) ex. (man dh_install): https://sources.debian.org/src/sublime-music/0.11.16-1/debian/sublime-music.install/ -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: Fwd: grammalecte_2.1.2+ds-1_amd64.changes REJECTED
On 2021-11-08 14 h 00, Romain Porte wrote: > Hello, > > 06/11/2021 18:18, Louis-Philippe Véronneau : >> Hello! >> >> Grammalecte was rejected. It would be nice if you could fix the issue >> mentioned below :) > > Please have a look at https://mentors.debian.net/package/grammalecte/ > > DSC file: > https://mentors.debian.net/debian/pool/main/g/grammalecte/grammalecte_2.1.2+ds-1.dsc > > > Commits since last upload: > > * 534d918 (HEAD -> debian/latest, origin/debian/latest) d/changelog: update > * a9a6817 fix missing autopkgtest dep > * 3f684d0 fix d/copyright REJECT > * 1f38706 fix d/watch > * e6d7849 introduce d/salsa-ci.yml > > Salsa repo: https://salsa.debian.org/python-team/packages/grammalecte > > Thanks. > Sorry for being so slow to sponsor. While trying to build, I get this error: mv: will not overwrite just-created 'debian/tmp/usr/share/doc/python3-grammalecte/README.txt' with 'debian/tmp/usr/lib/python3.9/dist-packages/grammalecte/README.txt' This happens because you are trying to move multiple files to the same path: debian/tmp/usr/lib/python3.10/dist-packages/grammalecte/README.txt debian/tmp/usr/lib/python3.9/dist-packages/grammalecte/README.txt -> debian/tmp/usr/lib/python3.9/dist-packages/grammalecte/README.txt I'd suggest singling out one python interpreter with `py3versions -d`? -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: DPT repositories checks/"violations" report
On 2021-11-27 08 h 54, Stefano Rivera wrote: > Hi Sandro (2021.11.27_06:01:08_+) > >> Hello, >> while working on something else[1], i noticed how many of the >> repositories in the DPT salsa group are in poor shape: >> >> * missing branches >> * changes not pushed to salsa >> * general misalignment in configuration/setup/organization >> * many other small nuances >> >> [1] https://github.com/sandrotosi/debian-python-team-tracker > > +1 this is great! \0/ I've been wanting something for QA like that for a while, but never had the time / energy to look into it further. All in all, it's too easy to forget to push something to Salsa and never realise it. >> please take the content with caution, as it's still an early, raw >> draft (i spot-checked some of the reported issues, but there could be >> bugs/issues) and it contains data that can be outdated (see below re >> caching); the fact that the report indicates only 43 repos are without >> violations is a bit disarming, but i think the tool tries to err on >> the side of verbosity and pedantry, with 2 level of violations (ERROR >> and WARNING) to mark which ones are the most important that require >> immediate attention vs the nice-to-have ones. > > When we did the migration to git, there weren't good tools for managing > the setup of the salsa repos (hooks, etc.) yet. I'd assume those exist > now, we should check in with what other teams are doing. That stuff can > all be fixed in one run of a tool, I'd assume. Could this become part of the Debian Janitor at some point? I could see teams adding a per-team config file to check things like what branch names should be expected, etc. and the Janitor fixing all this if it has commit access. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Fwd: grammalecte_2.1.2+ds-1_amd64.changes REJECTED
Hello! Grammalecte was rejected. It would be nice if you could fix the issue mentioned below :) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ Forwarded Message Subject: grammalecte_2.1.2+ds-1_amd64.changes REJECTED Date: Sat, 06 Nov 2021 12:00:09 + From: Thorsten Alteholz To: Debian Python Team , Louis-Philippe Véronneau Hi, different README.md state that the license of parts of this package is GPL-3 only. Please remove the term "or (at your option) any later version" from your GPL-3+ license block and rename it to GPL-3. Thanks! Thorsten === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. OpenPGP_signature Description: OpenPGP digital signature
Re: PEP-517/PEP-518 Support In Debian: current state
On 2021-10-25 14 h 04, Mathias Behrle wrote: > * Mathias Behrle: " PEP-517/PEP-518 Support In Debian: current state" (Mon, 25 > Oct 2021 19:45:39 +0200): > >> Hi all, >> >> before doing something nasty I would like to hear if >> https://lists.debian.org/debian-python/2020/06/msg2.html >> is still valid? > > JFTR I forgot to mention the background of my question: > > Package simpleeval has moved to a setup.py-less build using pypa/build. > Stuart Prescott has done some work to get this in dh-python: * https://salsa.debian.org/python-team/packages/python-installer * https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/20 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: Python BoF at DebConf2021
On 2021-06-15 14 h 32, Louis-Philippe Véronneau wrote: > On 2021-06-12 16 h 20, Louis-Philippe Véronneau wrote: >> Hey folks, >> >> The deadline to submit talks for DebConf21 is June 20th and I was >> thinking it would be a good idea to have a Python BoF, as we always do. >> >> Anyone opposed to the idea? >> > > I've submitted the BoF. Chances are it will be approved :P > The Python BoF will be on Aug 27, from 21:00 to 21:45 UTC [1]. Sadly, I have prior engagements and I won't be able to make it. Could someone else take on the task of coming up with an agenda and chairing the BoF? [1]: https://debconf21.debconf.org/talks/20-python-team-bof/ -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: Plan to upload all packages still using Alioth in Maintainer/Uploaders
On 2021-08-14 09 h 30, Stefano Rivera wrote: > Hi Sandro (2021.08.14_02:25:21_+) >> [1] https://lintian.debian.org/tags/python-teams-merged > > There are more than those, some other variants made it into use too: > > udd=> SELECT COUNT(*), maintainer_email FROM sources WHERE release='sid' AND > maintainer_email LIKE '%python%' GROUP BY maintainer_email; > count |maintainer_email > ---+- > 1 | gst-python...@packages.debian.org > 1 | pkg-python-debian-ma...@lists.alioth.debian.org > 1 | python-apps-t...@alioth-lists.debian.net > 1 | python-apps-t...@lists.alioth.debian.net > 62 | python-apps-t...@lists.alioth.debian.org > 15 | python-modules-t...@alioth-lists.debian.net >713 | python-modules-t...@lists.alioth.debian.org > 9 | team+python-modu...@tracker.debian.org >670 | team+pyt...@tracker.debian.org > (9 rows) Good catch. FWIW, I've opened a feature request on Lintian to try to catch those kind of errors [1]. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991955 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: mathlibtools_1.0.0-1_amd64.changes is NEW
On 2021-08-06 03 h 18, Debian FTP Masters wrote: > binary:mathlibtools is NEW. > binary:mathlibtools is NEW. > source:mathlibtools is NEW. > > Your package has been put into the NEW queue, which requires manual action > from the ftpteam to process. The upload was otherwise valid (it had a good > OpenPGP signature and file hashes are valid), so please be patient. > > Packages are routinely processed through to the archive, and do feel > free to browse the NEW queue[1]. > > If there is an issue with the upload, you will receive an email from a > member of the ftpteam. > > If you have any questions, you may reply to this email. > > [1]: https://ftp-master.debian.org/new.html > or https://ftp-master.debian.org/backports-new.html for *-backports > Dear Christopher, It looks like you made a mistake in the d/control file of this package. The "Maintainer" field currently reads Maintainer: Debian Python Team It should be Maintainer: Debian Python Team I thought there was a lintian tag for that, but there is none. I'll put that on my TODO. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: Request for review for Poetry(Was: Re: Asking for help Poetry)
On 2021-07-02 18 h 25, Louis-Philippe Véronneau wrote: > 2. d/control: > > If you require specific dependencies, you should make it clear in > d/control. It's the kind of thing that helps a lot if people decide to > backport it. Specific _versions_ of dependencies. Sorry, Friday afternoon :) -- Louis-Philippe Véronneau OpenPGP_signature Description: OpenPGP digital signature
Re: Request for review for Poetry(Was: Re: Asking for help Poetry)
On 2021-06-19 18 h 21, Emmanuel Arias wrote: > Hello everybody, > > I want to tell you that I push to salsa an advances of poetry packaging. > > Now, we have a complete package of poetry, so I'm requesting some more > experienced reviewers. Sorry, I said I would do this but it took me some time to actually do it :) Thanks for working on poetry, it's 100% going to make our lives easier. I have not read the upstream code, so I might be missing things... That's the kind of thing I only do when a package is ready to be sponsored. Here are my comments: 1. d/control: You haven't set the Python Team either in Maintainer or Uploaders. - 2. d/control: If you require specific dependencies, you should make it clear in d/control. It's the kind of thing that helps a lot if people decide to backport it. - 3. tests/repositories/fixtures This directory contains a bunch of tarballs from other projects. I'm not sure what should be done with this, as I guess they are used in the testsuite My first reflex would be to exclude them from the imported tarball and disable the tests that require them, but I don't know how much of the testsuite depends on those tarballs. Maybe someone else from the team can chime-in? - 4. d/tests There are no autopkgtests. This being a large project that's kinda hard to package, I don't really mind for now. I think it's fair to wait to have at least 1 version in unstable before working on that. - 5. d/rules Isn't the step in execute_after_dh_auto_install better suited in execute_after_dh_clean instead? At least, it seems to me you're cleaning the ./foo dir you patched in. - 6. Lintian: W: python3-poetry: no-manual-page usr/bin/poetry Again, not something that needs to be fixed, but each subcommand of poetry should probably get a man page: https://python-poetry.org/docs/cli/ I looked at the code and I have no idea how this website is built (they don't use sphinx). It seems like they do something manual? https://github.com/python-poetry/poetry/issues/3382 Anyway, here's an example of how I added man pages to a program with multiple commands: https://github.com/spl0k/supysonic/tree/master/docs/man - Overall it's very good! The trickiest part to fix will likely be #3 :S > I need to skip some tests because use a non versioned python, so that > give me some troubles like "python don't exist". > > Also, there're some package (or package version) that aren't in Debian > yet. So, to save your time looking which are them I tell you that I run > the buildpackage in this way: > > ``` > > gbp buildpackage --git-ignore-new > --extra-package=/home/eamanu/Debian/DEPENDENCIES/python3-cleo_0.8.1-1_all.deb > --extra-package=/home/eamanu/Debian/DEPENDENCIES/python3-httpretty_1.0.5-0.1_all.deb > --extra-package=/home/eamanu/Debian/DEPENDENCIES/python3-pkginfo_1.7.0-1_all.deb This package has not been updated on Salsa, or at least, I couldn't find version 1.7.0-1 anywhere. Maybe you forgot to push? I'm getting test failures on tests/inspection/test_info.py, but I'm taking for granted it's because I don't have the right version. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs
On 2021-06-25 16 h 42, Nicholas D Steeves wrote: > Hi Team! > > I feel like there is probably consensus against the use of PyPi-provided > upstream source tarballs in preference for what will usually be a GitHub > release tarball, so I made an MR to this effect (moderate recommendation > rather than a "must" directive): > > > https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/16 I don't often use PyPi releases because of the issues mentioned in the MR, but I think Jeremy's point is valid. IMO, rewording the text so that it clearly says "should" and not "must" would fix the issues at hand, as long as people justify their usage of PyPi when it's "The Right Thing" in a file somewhere. To me, the most important thing is that all packages must at least run the upstream testsuite when it exists (I'm planning on writing a policy proposal saying this after the freeze). If PyPi releases include them, I think it's fine (but they often don't). -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: Python BoF at DebConf2021
On 2021-06-12 16 h 20, Louis-Philippe Véronneau wrote: > Hey folks, > > The deadline to submit talks for DebConf21 is June 20th and I was > thinking it would be a good idea to have a Python BoF, as we always do. > > Anyone opposed to the idea? > I've submitted the BoF. Chances are it will be approved :P -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Python BoF at DebConf2021
Hey folks, The deadline to submit talks for DebConf21 is June 20th and I was thinking it would be a good idea to have a Python BoF, as we always do. Anyone opposed to the idea? -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: Code review for grammalecte
Hello! This is quite a large package, so instead of continuing to spam the IRC channel, here are my comments. 1. These files are licensed under the MPL2 * darg.py * gc_core/py/oxt/Grammalecte.py * gc_core/py/oxt/Options.py * gc_lang/fr/build_data.py * gc_lang/fr/dictionnaire/genfrdic.py * gc_lang/fr/dictionnaire/_templates/ooo/DictionarySwitcher.py * gc_lang/fr/oxt/AppLauncher.py * gc_lang/fr/oxt/Graphspell.py * gc_lang/fr/oxt/About/About.py * gc_lang/fr/oxt/ChangeAuthor/Author.py * gc_lang/fr/oxt/ContextMenu/ContextMenu.py * gc_lang/fr/oxt/DictOptions/DictOptions.py * gc_lang/fr/oxt/DictOptions/LexiconEditor.py * gc_lang/fr/oxt/DictOptions/SearchWords.py * gc_lang/fr/oxt/DictOptions/TagsInfo.py * gc_lang/fr/oxt/GraphicOptions/GraphicOptions.py * gc_lang/fr/oxt/Lexicographer/Enumerator.py * gc_lang/fr/oxt/TextFormatter/TextFormatterEditor.py * gc_lang/fr/oxt/TextFormatter/TextFormatter.py * graphspell/dawg.py * graphspell/progressbar.py * graphspell-js/dawg.js To me, this is a sign you haven't read the code Although it can be long and tiresome (and trust me, I know, I've just read the entire codebase :P), it's an important step in packaging something in Debian. When updating a package, you should also go through the diff. 2. There should be an entry in d/copyright for gc_lang/fr/dictionnaire/metaphone2.py 3. gc_lang/fr/nodejs/cli/lib/minimist.js seems to be a vendored copy of a version of node-minimist. If you need it, you should use the debian package. If not, it should be excluded. That's pretty much it! Fix those issues and I'll be happy to upload to experimental. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Re: Salsa access
On 2021-03-03 07 h 44, Stephan Lachnit wrote: > Dear team members, > > boolean.py is a python package that just landed in Unstable. > I would like to transfer the repo from my namespace to the team namespace, > since the team is also named as maintainer. > > Can someone give me maintainer access so I can move it? Hi! If you intend to maintain the package in the Team, you need to follow this procedure: https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst#joining-the-team Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
