Re: Status of sqlalchemy
On 4/15/24 12:04, Martin wrote: If nobody objects (or is faster than me), I'll upload SQLAlchemy 2.x to unstable in a couple of days or weeks. No hurry from my side. Cheers Please don't do this alone. Ask Piotr, as he's been the usual maintainer of the package. Cheers, Thomas Goirand (zigo)
Re: Status of sqlalchemy
On 4/14/24 23:23, Martin wrote: Hi, are there any news regarding the status of sqlalchemy? I'm curious, because the next version of gajim will depend on sqlalchemy >= 2, which is only in experimental right now. Cheers Hi, As much as I know, Piotr has been nicely putting this on old until the OpenStack packages could be fixed. Thanks for the patience. OpenStack 2024.1 (aka: Caracal) was released 2 weeks ago, and I uploaded all of it in Unstable. It's nice much better. Let me give you a quick comment on the situation. I'm still waiting on Manila support which is the most annoying one. I've been told that upstream Manila will backport all the SQLA 2.x fixes when they land in Master. As per this: https://qa.debian.org/excuses.php?experimental=1=sqlalchemy SQLA 2.x will also break Trove and Zaqar, but we can probably live with them broken until the next release of OpenStack. I care more about Trove (OpenStack DB as a service) than Zaqar (Messaging as a Service). I hope Trove upstream contributors will fix the situation, but at this point I don't know the status. I don't really use gertty, and I'm unsure why it's doing unit tests against SQLA. These could probably be ignored. The rest of: - pymodbus - sqlalchemy-utc - wtforms-alchemy I don't even know what they do. All that to say: I'm ok at this point if SQLA 2.x is uploaded to Sid and we move on... Cheers, Thomas Goirand (zigo)
Re: New upstream version for python-pint
On 4/5/24 10:14, Antonio Valentino wrote: The change is already in salsa. Please Thomas, let me know if this is acceptable for you. Yeah, that's ok. Unfortunately the package is not currently buildable because of an update in python3-lxml that determined #1068349 [1] Please ping me when I can build the package. Thomas Goirand (zigo)
Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
On 3/25/24 19:17, Julian Gilbey wrote: Hi all, [NB: sent to d-science, d-python, d-devel and the RFP bug; reply-to set to d-science and the RFP bug only] An update on Apache Arrow, and in particular the Python library PyArrow. For those who don't know: Apache Arrow is a development platform for in-memory analytics. It contains a set of technologies that enable big data systems to process and move data fast. It specifies a standardized language-independent columnar memory format for flat and hierarchical data, organized for efficient analytic operations on modern hardware. The project is developing a multi-language collection of libraries for solving systems problems related to in-memory analytical data processing. This includes such topics as: * Zero-copy shared memory and RPC-based data movement * Reading and writing file formats (like CSV, Apache ORC, and Apache Parquet) * In-memory analytics and query processing (from: https://arrow.apache.org/docs/index.html) Pandas has announced that Pandas 3.x will depend on PyArrow in a critical way (it will back the "string" datatype), and it is due to be released imminently. So this is a plea for anyone looking for something really helpful to do: it would be great to have a group of developers finally package this! There was some initial work done (see the RFP bug report for details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), but that is fairly old now. As Apache Arrow supports numerous languages, it may well benefit from having a group of developers with different areas of expertise to build it. (Or perhaps it would make more sense to split the upstream source into a collection of different Debian source packages for the different supported languages. I don't know.) Unfortunately I don't have the capacity to devote any time to it myself. Thanks in advance for anyone who can step forward for this! Best wishes, Julian Hi, I may not have much available time to help, though I'd love to have Arrow in Debian, as Ceph uses it, and currently use an embedded version. Cheers, Thomas Goirand (zigo)
Re: New upstream version for python-pint
On 3/31/24 21:05, Antonio Valentino wrote: Dear Thomas, Il 30/03/24 22:25, Thomas Goirand ha scritto: On 3/29/24 15:13, Antonio Valentino wrote: Dear Thomas and Ondřej, a couple of packages that I maintain are impacted by an RC bug in python-pint (#1067318). I think that an update to the to the latest pint version 0.23 should be sufficient to fix the issue. If you agree, I would like prepare the package for the new upstream version in the salsa. Of course I will let to you the review and upload. Please let me know, kind regards Please go ahead and feel free to add yourself as uploader. Thomas Thanks Thomas The packages is now updated in salsa. Unfortunately the reprotest job fails in CI, but I'm not able to reproduce on my laptop and it seems not to be a regression. I will try to fix it in future uploads but for the moment I would prefer to have an upload to fix a couple of RC bugs. Could you please review and upload? I have also put myself as uploader. I'm a DM so I kindly ask you to grant me upload permissions as described in [3]. kind regards Hi! Thanks for the work Antonio. 1/ In the clean target, please also clean: - Pint.egg-info - docs/savefig 2/ There's a typo in d/changelog, you wrote: "d/copuright". 3/ I'm really not sure about the python-pint-doc.lintian-overrides overriding "font-in-non-font-package". Can't you use the fonts from system instead? Cheers, Thomas Goirand (zigo)
Re: New upstream version for python-pint
On 3/29/24 15:13, Antonio Valentino wrote: Dear Thomas and Ondřej, a couple of packages that I maintain are impacted by an RC bug in python-pint (#1067318). I think that an update to the to the latest pint version 0.23 should be sufficient to fix the issue. If you agree, I would like prepare the package for the new upstream version in the salsa. Of course I will let to you the review and upload. Please let me know, kind regards Please go ahead and feel free to add yourself as uploader. Thomas
Re: morph's abandoned packages (list)
On 3/30/24 02:08, Bo YU wrote: hi! On Sat, Mar 30, 2024 at 8:20 AM Thomas Goirand wrote: On 3/29/24 21:18, Timo Röhling wrote: Hi Thomas, * Thomas Goirand [2024-03-17 23:09]: Anyone is welcome to join, it's just that I'm using git tag workflow, so it doesn't fit in the DPT, but that's the only thing. I am not familiar with that workflow and could not find any documentation. Can you give me a quick overview what I should do differently from the "regular" DPT workflow? Cheers Timo I'm not using pristine-tar, or gbp import-orig, and don't use upstream tarballs, but git only. Everything is done in a single (debian) branch. Just share the workflow of DPT I always follow[0]: ``` $ uscan # Download your package's upstream original tarball $ tar -xvf srcpkgname_1.0.orig.tar.gz $ cd srcpkgname_1.0 $ git init $ git checkout -b upstream $ git add . $ git commit -m "import srcpkgname_1.0.orig.tar.gz" $ git tag -s upstream/1.0 $ pristine-tar commit ../srcpkgname_1.0.orig.tar.gz upstream $ git checkout -b debian/master ``` And upgrade upstream release[1]. These should be enough. If given team maintenance, I would like to suggest to follow this. [0]: https://wiki.debian.org/Python/GitPackaging#Creating_a_new_package [1]: https://wiki.debian.org/Python/GitPackaging#New_upstream_release I would not do this way, but use gbp import-orig instead. I'm not sure why the wiki recommends, IMO wrongly, to do things by hand. Indeed, all of this: $ git checkout -b upstream $ git add . $ git commit -m "import srcpkgname_1.0.orig.tar.gz" $ git tag -s upstream/1.0 can be replaced by by this simple command: $ gbp import-orig ../srcpkgname_1.0.orig.tar.gz Cheers, Thomas Goirand (zigo)
Re: morph's abandoned packages (list)
On 3/29/24 21:18, Timo Röhling wrote: Hi Thomas, * Thomas Goirand [2024-03-17 23:09]: Anyone is welcome to join, it's just that I'm using git tag workflow, so it doesn't fit in the DPT, but that's the only thing. I am not familiar with that workflow and could not find any documentation. Can you give me a quick overview what I should do differently from the "regular" DPT workflow? Cheers Timo I'm not using pristine-tar, or gbp import-orig, and don't use upstream tarballs, but git only. Everything is done in a single (debian) branch. The only thing that needs to be done, is to push upstream tags to the Debian repository. The git history contains all upstream commits then, because the workflow is to merge upstream tag. To upgrade to a newer upstream tag, simply do: ./debian/rules fetch-upstream-remote git merge -X theirs dch --newversion -m "New upstream release." Then simply generate the upstream tarball from the git tag: ./debian/rules gen-orig-xz The fetch-upstream-remote and gen-orig-xz are from the openstack-pkg-tools package, though I heard others in Debian have standardized on something else. But who cares what wrapper one is using, really. The point is to fetch upstream tags, merge them, and use "git archive" to generate an orig tarball before building and uploading to Debian. If the upstream release was already uploaded to Debian, best is to download it instead of generating it, as (like with pristine-tar) regenerating it may (in some cases) lead to a different checksum. Cheers, Thomas Goirand (zigo)
Re: request for removal of my packages from the DPT namespace
On 3/27/24 14:31, Jeroen Ploemen wrote: On Wed, 27 Mar 2024 00:33:15 +0100 Thomas Goirand wrote: On 3/19/24 13:41, Jeroen Ploemen wrote: Dear team admins, please delete the following packages from the DPT namespace on salsa: cheetah jaraco.classes jaraco.collections jaraco.context jaraco.text nfoview ply puremagic python-autocommand python-jaraco.functools python-portend python-rarfile python-tempora python-yenc sabctools sabnzbdplus All of these have already been mirrored into my personal namespace to keep a public VCS available, while gaining at least some protection against ongoing policy violations. Hi, Usually, you'd ask for one of the Salsa admins to actually *move* the packages from one namespace to another, so that there's redirections, rather than copying somewhere else and deleting. This can be done by a simple ticket at: https://salsa.debian.org/salsa/support Or is it too late, and you already cloned, and don't want to bother? Thomas, thanks for getting back to me on this. I would have preferred to have redirects in place, but simply overlooked the possibility of the salsa overlords doing the moves after figuring out gitlab wouldn't let me move things out and the team admins in turn wouldn't be able to move anything into my namespace. I'll try to keep that in mind for next time; for now, please proceed with the deletion from the team namespace as I outright lack the time for another round of reorganising git repos for weeks to come. Sure, no worries. Unless they authorize me to do it, I'll let the DPT admins do it then (as I don't want to step on their feet with my "overlord" power as you said... :P). Thanks for clarifying the situation with your packages (which is what the change of policy is about...), and sorry for the added administrative work that was pushed on you because of it. Cheers, Thomas Goirand (zigo)
Further development in the asn1 & asn1-modules
Hi, It looks like pyasn1-lextudio and pyasn1-modules-lextudio are given up, then pyasn1 and pyasn1-modules are back into active maintenance. So I will ask for the 2 lextudio modules to be removed from Debian, and make sure no dependency are left. Note: this is *not* to be mistaken with the pysnmp situation. I'm still not sure what road it's going to take, but we'll have to act. So at the end: I'm happy I left things untouched and did something else. ;) Cheers, Thomas Goirand (zigo)
Re: request for removal of my packages from the DPT namespace
On 3/19/24 13:41, Jeroen Ploemen wrote: Dear team admins, please delete the following packages from the DPT namespace on salsa: cheetah jaraco.classes jaraco.collections jaraco.context jaraco.text nfoview ply puremagic python-autocommand python-jaraco.functools python-portend python-rarfile python-tempora python-yenc sabctools sabnzbdplus All of these have already been mirrored into my personal namespace to keep a public VCS available, while gaining at least some protection against ongoing policy violations. Hi, Usually, you'd ask for one of the Salsa admins to actually *move* the packages from one namespace to another, so that there's redirections, rather than copying somewhere else and deleting. This can be done by a simple ticket at: https://salsa.debian.org/salsa/support Or is it too late, and you already cloned, and don't want to bother? Cheers, Thomas Goirand (zigo)
Re: morph's abandoned packages (list)
On 3/15/24 12:40, Thomas Goirand wrote: On 3/15/24 10:59, Andreas Tille wrote: Hi Timo, Am Fri, Mar 15, 2024 at 09:50:39AM +0100 schrieb Timo Röhling: * Julian Gilbey [2024-03-14 06:20]: #1065198 O: networkx -- tool to create, manipulate and study complex networks language I use this somewhat regularly, so I'd be happy to share the workload with zigo. Zigo will be probably happy. :-) Yeah, I am. Networkx is a big piece. FYI, I started working on it already, to upgrade it to 3.2.1. Just to build the doc, I had to package mercantile and contextily that were needed during the sphinx build of examples. I'll let you know my progress (currently, my contextily package is empty... :/ not sure what I'm doing wrong with pybuid again...). Cheers, Thomas Goirand (zigo) FYI, the 3 new needed build-dependencies where uploaded and are waiting in the NEW queue (needed to build networkx doc): - python-contextily - python-mercantile - python-momepy and I uploaded networkx 3.2.1 in Experimental (since build dependencies aren't available yet). All of these 4 packages (included networkx itself) are under: https://salsa.debian.org/openstack/third-party Anyone is welcome to join, it's just that I'm using git tag workflow, so it doesn't fit in the DPT, but that's the only thing. Cheers, Thomas Goirand (zigo)
Re: python-debian | remove some Python2 dead code (!131)
On 3/17/24 14:56, Alexandre Detiste wrote: Hi, Does anyone know some automated tool to convert Python2-style annotations into Python3-style ? python-debian $ grep '# type' -r | wc -l 1499 Greetings You may try to run "sixer" which was written by a Python core developer, and used to convert all of OpenStack to python2 + 3 using six. Once it has found all the things that may use six, you can manually convert to *not* use six anymore. I did this multiple times, and it worked well for me at least. I hope this helps, Cheers, Thomas Goirand (zigo)
Re: Maintenance of python-cryptography
On 3/15/24 13:52, Scott Kitterman wrote: On March 15, 2024 7:19:16 AM UTC, Thomas Goirand wrote: On 3/14/24 08:52, Andreas Tille wrote: I would have prefered to read constructive arguments instead of silent leaving the team (in the sense of not informing the team mailing list about the leave). Me too. But I'm not surprised. I didn't have a list, I'm glad someone went through and made one. Yes, he might have handled his departure from the team differently, but I found the entire discussion about changing the team policy on setting the maintainer very off putting. I haven't talked to him about it beyond making sure he was aware of the discussion, so I don't know why he handled it the way he did, but I can easily imagine he was quite frustrated. Frankly, I think statements like the above aren't particularly consistent with the project CoC and have me thinking again about if this is the kind of team I care to be involved with. Which part? The one where I am saying that I'm not surprised? That in no way should be taken badly, or as an attack on him. Let me explain then. I too, would prefer if Sandro didn't leave, even if I had difficult moments when communicating with him. I stated it already, I did appreciate his contribution to the team, and to the project at large. Though it's a fact that I was not surprised, because you mentioned it. We knew in advance it could happen. Looking backward, it seems it was inevitable, unfortunately. I'd be very sad to see you go as well, please stay. While the way he left the team is on him, the fact that it even came up is 100% on the people pushing this change. I do not agree. It came up because what it was generating (frustration, flames about "rogue uploads", you name it...) had to be addressed. Cheers, Thomas Goirand (zigo)
Re: morph's abandoned packages (list)
On 3/15/24 11:42, Michael Fladischer wrote: Hi, Am 14.03.2024 um 07:20 schrieb Julian Gilbey: #1065142 O: html5lib -- HTML parser/tokenizer based on the WHATWG HTML5 specification as I use html5lib in quite a few projects at work, I'd take over this one. Is there already a consensus to just ITA it and change Maintainer to DPT in the next upload? I think that's fine. You can as well close the bug, and declare it as invalid, saying the package never had to be orphaned at all, since it was in the team. IMO, whatever you like as long as the package is kept alive and you're doing it in a timely manner. :) Cheers, Thomas Goirand (zigo)
Re: morph's abandoned packages (list)
On 3/15/24 10:59, Andreas Tille wrote: Hi Timo, Am Fri, Mar 15, 2024 at 09:50:39AM +0100 schrieb Timo Röhling: * Julian Gilbey [2024-03-14 06:20]: #1065198 O: networkx -- tool to create, manipulate and study complex networks language I use this somewhat regularly, so I'd be happy to share the workload with zigo. Zigo will be probably happy. :-) Yeah, I am. Networkx is a big piece. FYI, I started working on it already, to upgrade it to 3.2.1. Just to build the doc, I had to package mercantile and contextily that were needed during the sphinx build of examples. I'll let you know my progress (currently, my contextily package is empty... :/ not sure what I'm doing wrong with pybuid again...). Cheers, Thomas Goirand (zigo)
Re: morph's abandoned packages (list)
On 3/14/24 07:20, Julian Gilbey wrote: Recently-orphaned packages (removing those in wnpp which have been retitled "ITA") sorted alphabetically; these could, of course, be brought into team maintenance. #1065235 O: basemap -- matplotlib toolkit to plot on map projections #1065243 O: colorspacious -- library for doing colorspace conversions #1065151 O: commonmark -- Python parser for the CommonMark Markdown spec #1065246 O: contourpy -- Python library for calculating contours of 2D quadrilateral grids #1065248 O: cppy -- C++ headers for (Python) C extension development #1065139 O: dot2tex -- Graphviz to LaTeX converter #1065140 O: fastkml -- fast KML processing #1065142 O: html5lib -- HTML parser/tokenizer based on the WHATWG HTML5 specification #1065244 O: kiwisolver -- fast implementation of the Cassowary constraint solver #1065238 O: lazy-object-proxy -- Python 3 fast and thorough lazy object proxy #1065037 O: m2crypto -- Python wrapper for the OpenSSL library #1065325 O: matplotlib -- Python based plotting system #1065143 O: mkautodoc -- AutoDoc for MarkDown #1065042 O: mpl-sphinx-theme -- documentation for the mpl-sphinx-theme Python library #1065220 O: mpmath -- library for arbitrary-precision floating-point arithmetic #1065224 O: mysql-connector-python -- pure Python implementation of MySQL Client/Server protocol #1065198 O: networkx -- tool to create, manipulate and study complex networks #1065329 O: numpy -- Fast array facility to the Python 3 language #1065221 O: py7zr -- pure Python 7-zip library #1065222 O: pychm -- Python binding for CHMLIB #1065231 O: pydot -- Python interface to Graphviz's dot #1065152 O: pygeoif -- basic implementation of the __geo_interface__ #1065036 O: pyopenssl -- Python wrapper around the OpenSSL library #1065149 O: pyproject-metadata -- Dataclass for PEP 621 metadata with support for [core metadata] generation #1065223 O: pysimplesoap -- simple and lightweight SOAP Library #1064977 O: python-cryptography-vectors -- Test vectors for python-cryptography #1065327 O: python-levenshtein -- extension for computing string similarities and edit distances #1065025 O: sphinx-book-theme -- clean book theme for scientific explanations and documentation with Sphinx #1065026 O: sphinx-bootstrap-theme -- bootstrap theme for Sphinx #1065030 O: sphinxcontrib-log-cabinet -- Organize changelog directives in Sphinx docs #1065027 O: sphinx-copybutton -- sphinx extension to add a "copy" button to code blocks #1065028 O: sphinx-gallery -- extension that builds an HTML gallery of examples from Python scripts #1065029 O: sphinx-panels -- documentation for the sphinx-panels Python library #1065043 O: sphinxtesters -- utilities for testing Sphinx extensions #1064948 O: texext -- sphinx extensions for working with LaTeX math There's also an old ITP that was closed: #1015231 ITP: sphinx-theme-builder -- tool for authoring Sphinx themes with a simple (opinionated) workflow Best wishes, Julian I can take care of networkx, which is used in OpenStack. If nobody else care, I prefer to use a git tag based workflow, meaning it cannot stay in the team (but everyone is more than welcome in the OpenStack team). If anyone doesn't agree, and feel strong about keeping networkx to use pristine-tar and stay in the team, please voice your concern (and of course, volunteer to do the work). I probably also need to keep pydot in shape. Cheers, Thomas Goirand (zigo)
Re: Maintenance of python-cryptography
On 3/13/24 18:34, Scott Kitterman wrote: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064979 Would some of you who are pushing so hard to change the policy for Uploaders/ Maintainer in the team please step up and take over this package. It really needs updated to the new upstream release (blocking both aioquic and dnspythong for me, I don't know about others). I haven't done a comprehensive check, but I think morph asked for all the leaf packages he was maintaining in the team to be removed from the archive and is removing himself from uploaders/maintainer on others. You all made this mess. Please clean it up. Absolutely not. Sandro did. There's btw absolutely no reason to declare a package as "orphan" if it is supposed to be team maintained. It's also a very bad behavior to do this silently, without telling the team about it, or taking part of the thread. I very much regret things are happening this way, but I don't think the rest of the team should be held responsible. If you have the list of the packages matching what you are saying, please do share. On 3/14/24 08:52, Andreas Tille wrote: > I would have prefered to > read constructive arguments instead of silent leaving the team (in the > sense of not informing the team mailing list about the leave). Me too. But I'm not surprised. Cheers, Thomas Goirand (zigo)
Re: Help with the Cython 3.0 failures in Ceph
On 3/3/24 21:08, Thomas Goirand wrote: Hi, I'm long overdue for an upload of Ceph 18.2.x in Unstable. I'm currently stuck with the below build failure: Error compiling Cython file: ... """ name = cstr(name, 'name') cdef: rados_ioctx_t _ioctx = convert_ioctx(ioctx) char *_name = name librbd_progress_fn_t _prog_cb = _op_progress_callback ^ rbd.pyx:760:44: Cannot assign type 'int (*)(uint64_t, uint64_t, void *) except? -1' to 'librbd_progress_fn_t'. Exception values are incompatible. Suggest adding 'noexcept' to type 'int (uint64_t, uint64_t, void *) except? -1'. THere's like a dozen of these in the build log, always with the same thing, with the same kind of assignation of a reference the op progress callback address. I tried a few dumb things, but can't find out what to do to fix. Does anyone know what's going on, and how I can patch Ceph to have rbd.pyx to build? Cheers, Thomas Goirand (zigo) Sorry for the noise, looks like I found a commit upstream (in the master branch) that fixes the issue. Cheers, Thomas Goirand (zigo)
Help with the Cython 3.0 failures in Ceph
Hi, I'm long overdue for an upload of Ceph 18.2.x in Unstable. I'm currently stuck with the below build failure: Error compiling Cython file: ... """ name = cstr(name, 'name') cdef: rados_ioctx_t _ioctx = convert_ioctx(ioctx) char *_name = name librbd_progress_fn_t _prog_cb = _op_progress_callback ^ rbd.pyx:760:44: Cannot assign type 'int (*)(uint64_t, uint64_t, void *) except? -1' to 'librbd_progress_fn_t'. Exception values are incompatible. Suggest adding 'noexcept' to type 'int (uint64_t, uint64_t, void *) except? -1'. THere's like a dozen of these in the build log, always with the same thing, with the same kind of assignation of a reference the op progress callback address. I tried a few dumb things, but can't find out what to do to fix. Does anyone know what's going on, and how I can patch Ceph to have rbd.pyx to build? Cheers, Thomas Goirand (zigo)
Re: Suggesting change in DPT policy
On 3/3/24 00:37, Christian Kastner wrote: For example, I also often skip tests -- it's just that I do it under conditions that I'm happy to defend (cause isolated, reported upstream, etc.), but others may not be aware of that. There are many cases where skipping tests is ok. As you wrote, when reported upstream, and when the thing that's broken is the test itself (but the functionality is not broken). The best practice is to document somewhere in the package (in d/rules?) why it's been disabled. I have to admit I often don't do that extra documentation work myself though (though mostly on packages I maintain alone, for OpenStack for example). Unfortunately, when dealing with a large amount of packages, at some point, one may be tired and skip some of the documentation/reporting upstream work, because there's so much to do... I have to admit that sometimes, I just do the quick fix by myself in debian/ptaches, and don't have enough energy to report or fix upstream, thinking that upstream will hit the (python 3.x for example) bug themselves, and fix anyways. :/ Cheers, Thomas Goirand (zigo)
Re: Suggesting change in DPT policy
On 3/2/24 23:09, Christian Kastner wrote: Not going to name names, but I've seen this with packages I've worked on: I put a lot of effort into cleaning things up, making things robust, getting docs to build, tests to pass, collaborating with upstream, fixing reverse dependencies, and then someone spends a few minutes to upload a new version with total disregard for what the other maintainer(s) were doing. Things like "oh, documentation doesn't build anymore, I'll just disable it", rather than fixing it. Or "oh, these tests don't pass anymore, I'll just disable them", rather than looking into the regression. "Oh, my upload triggered a transition, I'm no longer interested in this". (This are all things that have happened to me.) All that stuff is then left for others to clean up. And if one is unlucky enough, this doesn't just cause work for the package, but for all reverse dependencies. I've seen careless uploads and mistakes too (and done my part of bad uploads a few times as well). There's one thing that can save us all from this: a lot of autopkgtest in every package, and uploading packages with a lot of reverse dependencies to Experimental first, then fixing the excuse page before an upload to unstable. I did this for flask 2.2 and werkzeug, and saw Carsten Schoenert doing the same with flask 3. It's a proven safe workflow. For this, you don't really need to know the said transitioning package. I very much hope we all move into this direction, even if that means more work and follow-up with reverse dependency maintainers. Cheers, Thomas Goirand (zigo)
Re: Suggesting change in DPT policy
On 3/2/24 21:29, Andreas Tille wrote: sphinxtesters (0.2.3-4) unstable; urgency=medium * Revert attempt by a rogue developer to hijack this package -- Sandro Tosi Sun, 14 Jan 2024 01:25:23 -0500 I wonder how the attribute 'rogue' is supported by the discussion above, nor where the intention to hijack the package is inferred from. On 3/2/24 21:29, Andreas Tille wrote: > In my view, this crosses the line It does cross the line. On 3/2/24 21:29, Andreas Tille wrote: > and I am grateful to have been part of teams where such > incidents were not tolerated. IMO, this shouldn't be tolerated in this team either. Even if Sandro is doing awesome work in the team. I'm btw hereby sending warm thanks to Sandro for his huge work that I very much respect, despite all of this thread and other events. I remember the huge amount of uploads when we removed Python 2 from Debian, tirelessly doing things on the correct order, in a technically near perfect way, when I didn't dare to touch this puzzle ... But it's not an excuse to create a toxic atmosphere. This has been hashed multiple times in many areas in Debian: doing a lot of (good) packaging work doesn't grant anyone the right to disrespect others. On 3/2/24 22:11, Scott Kitterman wrote: > I understand your argument to be: > > I did not follow the team policy and didn't care about the other > people involved to rectify the error. They were upset about this, so > clearly this mess is all their fault. We should change the rules so > that I won't have been wrong. > > I absolutely do not know how to respond to that level of entitlement. > Hopefully I have misunderstood what you are trying to communicate? I strongly do not agree with the above. You wrote it as if what triggered Sandro was Andreas not willing to "rectify the error". That's not what's happened: Sandro was harsh with Andreas to begin with, and that is the reason Andreas wasn't motivated to "fix" what he saw as cosmetic metadata in d/control for a weird policy of packages "half belonging to the team", rather than an important bugfix. The way you wrote it, it feels like you're only blaming Andreas for what he did: I wouldn't do that, but that is ok, it's your opinion. But it feels you're saying his bad behavior is an excuse for changing the policy, and that, I do not agree, this isn't what's happening. We should change the policy, but that's not so that Andreas "won't have been wrong". It is because at least 3 persons (including myself and Andreas) in this thread missed the point we're willing to remove. It is because having a package "half in the team" doesn't make sense. And it is because of many other points we already discussed in this thread. I don't understand why are you making such a shortcut, when you already agreed to these other points. I'm sure you also notice part of this thread is also about Sandro's communication style. My view (which I believe is shared by others) is that Andreas is a nice person that deserves respect. It's unfortunate that the sphinxtesters uploads were the tiger of this policy change, though we need to take a step back, and understand the policy was bad anyways. So indeed, we have read the same things, but have very different perspectives. None of them are completely wrong, we simply have very different feelings. And despite all of this, it's a good thing you also agree to get rid of this part of this policy. Cheers, Thomas Goirand (zigo)
Re: Suggesting change in DPT policy
On 2/28/24 12:44, Scott Kitterman wrote: Everyone in Debian is already bound by the code of conduct already, so it seems redundant to add it here again. I agree. Thomas
Re: Suggesting change in DPT policy
On 2/28/24 09:21, Andreas Tille wrote: Hi, Louis-Philippe (just quoting below in case you might have missed it) is repeating the importance that anyone who thinks my suggestion (MR[1]) is a bad idea make themselves heard. I'm hereby adding those maintainers who have more than 5 packages that are affected and did not yet raised their opinion in To: field. udd=> SELECT * FROM (select maintainer, count(*) from sources where uploaders like '%team+pyt...@tracker.debian.org%' and release = 'sid' group by maintainer order by maintainer) tmp WHERE count > 5; maintainer| count -+--- Debian PaN Maintainers | 7 Jeroen Ploemen | 16 Piotr Ożarowski |23 Sandro Tosi | 82 Scott Kitterman| 7 Vincent Bernat | 15 (6 rows) Note that it's been the case at least for Vincent, in at least a few instances, that the tooling (py2dsp you wrote?) made him wrongly put the team as uploader. There's porbably other cases as well. Cheers, Thomas Goirand (zigo)
Re: Suggesting change in DPT policy
On 2/28/24 00:54, Scott Kitterman wrote: It's self-induced. I mean if it's demotivating to have people point out that you didn't follow the policy, then you can solve that all by yourself by following the policy. If I take your argument to its logical conclusion, all of Debian's rules can be demotivating when people ignore them, so we should get rid of them all so your feelings are safe. The way you're wording it, it feels like we on purpose didn't follow what was written in the policy. That's not the case. The point you're missing here, is that this policy is not obvious at all, and it's easy to either not understand it, or not know about it. Cheers, Thomas Goirand (zigo)
Re: Suggesting change in DPT policy
On 2/27/24 19:32, Scott Kitterman wrote: I suspect that packages will be removed from team maintenance as a result though and I think that's a bad idea. If a package isn't in the team, any DD can ask for permission from the maintainer before an upload. So, what's the difference, with a package that is "is in the Python team", but nobody from the team can upload without prior approval from the current maintainer? It simply doesn't make sense. So at the end, if packages get "removed from the team", it's a good thing: it clarifies the situation. Andreas has been the biggest uploader of packages for many years (by the number of upload per year), and working a lot on Python stuff. It feels wrong we both fell in the "upload not granted: you should have read the team's policy better" mistake, and I do not wish others also receive this kind of demotivating message anymore. Cheers, Thomas Goirand (zigo)
Re: Suggesting change in DPT policy
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. Kind regards Andreas. Hi Andreas, I had similar experience, and the same kind of demotivating response from the same person. So I'm not surprised. It's been a long long time that I would have like this DPT policy to go away, but didn't dare to raise the topic. Though indeed, I don't think it's reasonable to have a package in the team, but with strong ownership. I believe that we should either have a package in the team, or not. Period. If someone isn't happy about this policy change, it's ok to move the package way from the team, if having team-mate working on "your" package isn't ok (of course, we would all prefer this doesn't happen, and that we work collaboratively). This would make things a way clearer. So I'm 100% with you for the removal of this policy. To everyone else in the team: please also state your opinion, so we can make a collective decision. Cheers, Thomas Goirand (zigo)
Re: QA python3-unittest2
On 1/17/24 14:25, Alexandre Detiste wrote: Le jeu. 11 janv. 2024 à 10:47, Thomas Goirand a écrit : I'm busy with the (tentative-) removal of python3-unittest2. unitest2 is an old version of what has become "unittest" in the standard library 90% of dependencies are stale and only need a quick edit of debian/control for the other I submit patches upstream Will you also send patches to upstream OpenStack? If so, please note that OpenStack uses Gerrit, and you need to follow the instructions detailed here for a new account: https://docs.openstack.org/contributors/en_GB/common/accounts.html I will learn Gerrit because I'm curious... ...but 90% of these remaining dep on unittest2 are really only about removing 1 line from debian/control ... only committing this change + setting the bug as pending would already help with triaging I can send Salsa MR if that's easier for everyone too. If you just send me the list of packages affected, with no change to be sent upstream, I can take care of it in a few minutes myself. Or have you already filled the bugs? Cheers, Thomas Goirand (zigo)
Re: QA python3-unittest2
Hi, On 1/10/24 12:27, Alexandre Detiste wrote: Hi, I'm busy with the (tentative-) removal of python3-unittest2. unitest2 is an old version of what has become "unittest.mock" in the standard library 90% of dependencies are stale and only need a quick edit of debian/control for the other I submit patches upstream Will you also send patches to upstream OpenStack? If so, please note that OpenStack uses Gerrit, and you need to follow the instructions detailed here for a new account: https://docs.openstack.org/contributors/en_GB/common/accounts.html I'd strongly recommend sending patches upstream rather than in downstream Debian packages only. The next OpenStack release (codename: Caracal) is due for April, so if you send patches upstream now, it's going to be in Debian soonish. One of the reason is that upstream runs a full functional CI on every commit, while the Debian packages are only running unit tests. I do run the functional tests kind of manually myself, but that's de-corelated from individual package testing. Can I get (minimal) Salsa team membership for this one task ? maybe also checking for python3-mock & python3-six at the same time. Note that upstream OpenStack has been actively removing the Six dependency, and they'll be very happy to have some kind of help finishing the work. As for Mock, probably also. I do not plan to do any upload of these packages and more generally I do not even fully grasp what OpenStack is about. I don't think it's technically needed to so. I can maybe handle just this urgent one #1059108 [i|P|♔] [src:gnocchi] gnocchi: please remove extraneous dependency on python3-future This has been dealt with already (by myself...) in Debian, and even merged upstream (3 weeks ago): https://github.com/gnocchixyz/gnocchi/pull/1366 It looks like I only forgot to upload, which I just did today. python3-unittest2: """"""""""""""""""""""" designate-dashboard keystone mistral murano-agent neutron python-django-compressor python-funcsigs python-jenkins python-kafka python-linecache2 python-novaclient python-oauth2client python-pecan python-pymysql sahara-dashboard senlin-dashboard testresources trove-dashboard Best for these, IMO, would be to push the change upstream. I'd very much prefer if you could do this, and just open bugs in the Debian BTS (linking to your patch upstream), and I'll work on fixing the packages myself. Is that ok if we do like this? python3-six: #1053966 [n| | ] [python3-ironic-ui] python3-ironic-ui: please remove extraneous, obsolete, dependency on python3-six #1054151 [n| | ] [python3-neutron-vpnaas] python3-neutron-vpnaas: please remove obsolete python3-six dependency #1060114 [n| |↝] [src:python-txaio] python-txaio: please remove extraneous dependency on python3-six I have just pushed these on Debian, so these are closed. Thanks for pushing me to do the actual work! :) (so not these ones, unless requested) #1052512 [n| | ] [src:python-pysaml2] python-pysaml2: please package v7.4.2 and remove python3-six dependency #1053378 [n| | ] [src:python-gabbi] python-gabbi: please package v2.10.0 and remove dependency on python3-six For these, I'm planning to do them when Caracal is released (ie: this spring), if you don't mind. Cheers, Thomas Goirand (zigo)
Re: [Help] Re: python-future: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
On 1/4/24 00:30, Alexandre Detiste wrote: Le lun. 11 déc. 2023 à 16:43, Andreas Tille a écrit : Control: tags -1 help [Bug #1056419 in CC since the issue seems to be caused by python-future] Hi Vincent, I tried to upgrade python-future to the latest upstream version in the hope that this would solve the issue reported in bug #1042244. Unfortunately this is not the case and now with Python3.12 we also have to deal with the removal of imp (which affects bug #1056419). I'd like to ask for help on debian-python list since I'm pretty overworked with other stuff. Please also review my rude patch[1] to hack around a shinx issue. It would be great to have some better solution here. The better solution is to remove python3-future altogether. I very much agree with this. Most of the time, it's simply patching out stuff like: from __future__ import in every .py of the package, and you're done. So it's quite easy to do. As we removed Python 2.7 2 releases ago, it's probably a good time to finish the transition... :) Cheers, Thomas Goirand (zigo)
Re: Bug#1043240: transition: pandas 1.5 -> 2.1
On 12/11/23 08:12, Matthias Klose wrote: On 10.12.23 14:06, Rebecca N. Palmer wrote: I'd like to move forward with the pandas 1.5 -> 2.1 transition reasonably soon. Given that pandas 2.x is *not* required for Python 3.12 (but is required for Cython 3.0), should we wait for the Python 3.12 transition to be done first? These are broken by pandas 2.x and have a possible (but untested) fix in their bug - please test and apply it: dask(?) dials influxdb-python* python-altair python-feather-format python-upsetplot seaborn tqdm* (* = this package is currently also broken for a non-pandas reason, probably Python 3.12, that I don't have a fix for) These are broken by pandas 2.x and have no known-to-me fix: augur cnvkit dyda emperor esda mirtop pymatgen pyranges python-anndata python-biom-format python-cooler python-nanoget python-skbio python-ulmo q2-quality-control q2-demux q2-taxa q2-types q2templates sklearn-pandas Some generic things to try are pandas.util.testing -> pandas.testing, .iteritems() -> .items(), and if one exists, a more recent upstream version. Is this an acceptable amount of breakage or should we continue to wait? Bear in mind that if we wait too long, we may be forced into it by some transition further up the stack (e.g. a future Python or numpy) that breaks pandas 1.x. up to the maintainers. But please wait at least until the current pandas and numpy migrated to testing, e.g. that the autopkg tests of pandas and numpy triggered by python3-defaults pass. Is there a way to see the binNMUs which are still stuck in unstable, and don't migrate? Matthias As a reminder: it's best practice to first upload the new release to Experimental, so we can see what happens with autopkgtest before destroying everything at once... Cheers, Thomas Goirand (zigo)
Re: Preparing for Python 3.12
On 11/7/23 11:27, Matthias Klose wrote: Python 3.12 was released a month ago, and it's time to prepare for the update in unstable, first adding 3.12 as a supported version. There s a tracker for adding 3.12 as a supported version [1], also there are the first bug reports filed for issues related to 3.12 [2]. As usual, it's difficult to find about issues in higher stages before building packages in lower/earlier stages of the transition. Therefore we started again adding 3.12 in Ubuntu, and then filing and fixing issues in unstable before adding 3.12 in Debian unstable. This Ubuntu tracker can be seen at [3]. Note that i386 is only a partial architecture, and that Ubuntu doesn't run the tests on riscv64 during the build (so packages succeeding to build on riscv64 but not on the other architectures most likely show test failures instead of build failures). Ubuntu's update_excuses for python3-defaults also shows autopkg tests failing with 3.12 supported, although this information is a bit out of date, due to infrastructure issues for the autopkg testers. The plan is to make 3.12 supported in unstable at the end of November, or earlier if possible, so that other transitions aren't blocked by the addition of 3.12. Then planning for the defaults change in January. While this timeline is not that much needed for 3.12, it will be a good exercise for 3.13, so that we get 3.13 as the default into the trixie release. Matthias Hi Matthias, Thanks a lot for all the work you're doing on the Python interpreter. When 3.12 because an available version, it would help a lot to have someone like Lucas Nusbaumm to rebuild all reverse dependencies of Python. Is that something planned? Cheers, Thomas Goirand (zigo)
Re: Packages wrongly marked as FTBFS with Sphinx 7.1, docutils 0.20
On 10/31/23 15:41, Dmitry Shachnev wrote:
dh_sphinxdoc looks for either the new way of loading searchindex.js:
or the old way:
jQuery(function() { Search.loadIndex("searchindex.js"); });
Looking at openstackdocstheme's search.html, it does have one of these
lines (the second one):
https://opendev.org/openstack/openstackdocstheme/src/tag/3.2.0/openstackdocstheme/theme/openstackdocs/search.html#L38
If it's there but dh_sphinxdoc still shows this error, then it's probably a
dh_sphinxdoc bug. Otherwise, please figure out why that line is not there.
Thanks for the hint. I found it out myself: I mistakenly removed these
lines trying to remove the search thingy and all the external references
(ie: JS files hosted in some CDNs and the like).
I mentioned all that because I thought I wouldn't have time to figure
out before next week (as I'm taking days off starting tomorrow morning),
but it looks like everything is fine now... :)
Cheers,
Thomas Goirand (zigo)
Re: Packages wrongly marked as FTBFS with Sphinx 7.1, docutils 0.20
On 10/31/23 13:52, Dmitry Shachnev wrote: On one of the closed bugs, I replied to you (#1043075). FYI, before reading it, I finished my work on version 3.2.0 of openstackdocstheme, that I uploaded today. So everything should be fine, hopefully. What other bugs did you close? Will you mind if I reopen them, or you will do that yourself? The others are all OpenStack packages, which I fixed with the above upload. The other one was python-amqp, but I re-opened the bug. Also, they built successfully in sid, i.e. with old Sphinx, right? Right. Though as per above, it should be fine now. The only thing is that the packages will produce a different doc package if rebuilt (ie: new theme), but there's going to be another OpenStack release in 5 months, so it should be fine. Cheers, Thomas Goirand (zigo)
Re: Packages wrongly marked as FTBFS with Sphinx 7.1, docutils 0.20
On 10/31/23 13:27, Lucas Nussbaum wrote: Hi Thomas, On 31/10/23 at 13:08 +0100, Thomas Goirand wrote: Hi, I'm not really sure what's going on, but I saw many packages marked as RC buggy with Sphinx 7.1, docutils 0.20, however, both are still in Experimental, not in Unstable. I tried rebuilding those, and in built fine. I therefore closed the bugs. I'm not sure if I was right doing so, and what's the intention behind bumping severity to serious. Is this for preparing before the upload of sphinx+docutils to unstable? If so, I would strongly suggest explaining this in bug entries, stating the intention is to upload sphinx and docutils very soon. Otherwise, like me, someone may wrongly close the bugs after a successful rebuild. See this message: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042585;msg=7 and this comment from Dmitry Shachnev: # Dear Maintainers, I am going to upload Sphinx 7.2.6 to unstable next weekend. # That will make these packages FTBFS in sid, which is a release-critical bug. # The new docutils will be uploaded after Sphinx migrates to testing. Lucas Hi Lucas, First of all, thanks for your care doing this BTS dance. I'm just trying to improve things, but this is not at all a strong critic, I appreciate the work being done. However, I missed it, because it didn't appear in the bug report itself. I certainly will not be the only one not seeing it, which is why I wrote this message. If it isn't too much work, I would suggest adding a few words in each BTS entry. BTW, I closed the OpenStack related bugs, but I believe upgrading python3-openstackdocs will fix it. The new theme builds, but when using it, I get: dh_sphinxdoc -O--buildsystem=python_distutils dh_sphinxdoc: error: debian/python-openstacksdk-doc/usr/share/doc/python-openstacksdk-doc/html/search.html does not load searchindex.js I'm not sure how to fix it, but I'll find out. So please don't re-open bugs, I'll take care of that next week, and just fixing the docs theme should fix it. Cheers, Thomas Goirand (zigo)
Packages wrongly marked as FTBFS with Sphinx 7.1, docutils 0.20
Hi, I'm not really sure what's going on, but I saw many packages marked as RC buggy with Sphinx 7.1, docutils 0.20, however, both are still in Experimental, not in Unstable. I tried rebuilding those, and in built fine. I therefore closed the bugs. I'm not sure if I was right doing so, and what's the intention behind bumping severity to serious. Is this for preparing before the upload of sphinx+docutils to unstable? If so, I would strongly suggest explaining this in bug entries, stating the intention is to upload sphinx and docutils very soon. Otherwise, like me, someone may wrongly close the bugs after a successful rebuild. Cheers, Thomas Goirand (zigo)
Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
On 10/2/23 09:11, Carles Pina i Estany wrote: Hi, I've uploaded my first package (python-cloudscraper). I've filled a RFS (#1053332). I have some questions (some specific to debian-python organisation) * Question 1: Git repo I pushed the code to https://salsa.debian.org/carlespina/python-cloudscraper/ . Should I, instead, push it already to https://salsa.debian.org/python-team/packages/python-cloudscraper/ ? Yes please. That might be related to Question 2. * Question 2: debian/control, Maintainers and Uploaders I've read https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst#maintainership and I think that my favourite, "long term" (does not need to be now), would be: Maintainer: Debian Python Team Uploader: Carles Pina i Estany Yes. Note that not everyone in the team agree with the Python team policy of having the team as Uploader, some, including myself, think that if you don't want other people from the team to upload, you shouldn't push the package to the team at all. YMMV... So far I've done: Maintainer: Carles Pina i Estany And no Uploader (will be the sponsor on the first time). Is that correct? It's probably preferable to directly put the team as Maintainer. * Question 3: allow failing tests from upstream in dh_auto_test Upstream has 4 failing unit tests. Besides working with upstream to fix them what I've done is, in debian/rules: - override_dh_auto_test: # Disable tests failing from upstream pytest -k "not (test_bad_interpreter_js_challenge1_16_05_2020 or test_bad_solve_js_challenge1_16_05_2020 or test_Captcha_challenge_12_12_2019 or test_reCaptcha_providers)" - The reason is that I don't want to disable or even ignore failing unit tests in the salsa-ci pipeline. If there is a new one failing I'd like to know. The override_dh_auto_test is my way of having "allowed to fail" for a specific list. Is there any other, better / recommended / standard way? That's very good, and that's exactly what you should do, indeed: have as many tests running as possible, so that you avoid regression. I would also strongly suggest to use autopkgtest, to avoid that someone breaks your package when uploading some of your dependencies. * Question 4 Any casual comments on the package would be welcomed (even in a non-sponsor level). For sponsoring: the main reason of packaging this is that it's an indirect dependency of "simplemonitor". Related bugs: RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053134 ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053134 ITP of simplemonitor: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016113 Sorry, I wont have time for this right now, but if nobody does it, feel free to ping me in a week or 2. Cheers, Thomas Goirand (zigo)
Re: Transitionning to the lextudio pysnmp / pyasn1 ecosystem
Scott & everyone, On 9/16/23 19:04, Scott Kitterman wrote: It's pretty relevant to your question. If you had instead updated the existing packages from the new upstream, no transition would be needed. I'm not entirely sure that no transition is needed, no. The major version was bumped to version 5, and I have no clue if this represent some incompatibility. This needs to be tested at least (see below). Did you check with the existing maintainers to see what they thought? Hum ... why do you think I've opened this thread? As is usually the case in Debian, I think the answer is you work with the maintainers to figure out the best solution. Ignoring them and hijacking the packages is not the right answer. Ditto. Plus I really dislike that you write the word "hijacking". That's not at all my intention, and /me opening this thread proves it. Anyways, let's try to be more productive... I thought it was kind of obvious why I did things the way I did, but let me try to be more explicit. It is my understanding that "pysnmp4" doesn't match "pysnmp-lextudio" released as version 5.0.20. We could rename the binary as "python3-pysnmp" (ommiting the "4"), and have a transition package, yes. But I have no confidence that they are drop-in replacements (I just don't know yet...). The packages that I maintain do need the lextudio modules *now* (OpenStack moves fast, I cannot afford to wait 6 months), so I thought it was faster to address the current situation first with my uploads, so I can offer a continuity of what I already packaged (ie: Ironic and other OpenStack stuff). Though believe me, I want to do the things properly, and I have no intention of hijacking anyone's work. If someone wants to work on this with me, we can move the 4 new lextudio packages back in the team, of course. I have already too many packages under my responsibility, I'd love to have others working on them. Then I can act on the OpenStack part of things quickly once we agree on the way to go. So let me ask once more the persons involved and/ore volunteering on this: what's your suggestion? There's actually 2 paths (and yes, I had the 2 paths in mind before Scott suggested replacing the older packages): 1/ We get the lextudio packages replace the older packages like Scott suggested. This would be a transition anyways, since we're moving to version 5 and there's a year of commits. If we're to do like this, then we need to make sure that: - the lextudio replacing packages are staged in experimental first, and look at the pseudo-excuse - the reverse dependencies have meaningful autopkgtest, otherwise uploading to experimental first is pointless, and then 2/ below becomes the best solution 2/ The other possibility, is what I suggested and envisioned first, by uploading the lextudio packages: open 9 bugs, and let maintainers switch to the new packages. This is IMO the safest path, as it wont create any breakage, though we'd have conflicting packages for a while, which can be annoying. We got to make sure the transition finishes quickly enough then (meaning, probably make the bugs RC after some time, so we make sure we can remove the older pysnmp/asn1 packages before Trixie freeze). I don't think 2/ is an inferior way of doing things. I am still convinced that I did the right way, that uploading the *-lextudio packages was correct, so that current maintainers of reverse dependencies can at least test and see if everything goes well with the new packages, without destroying them. I also continue to have OpenStack packages working this way, and I'm not destroying reverse dependencies carelessly. Please share your thoughts on how to do it, Cheers, Thomas Goirand (zigo)
Re: Transitionning to the lextudio pysnmp / pyasn1 ecosystem
On 9/15/23 14:03, Scott Kitterman wrote: Why did you hijack this from the Python team instead of just working with the existing maintainers to update the existing packages from the new upstream location? Scott K Thanks for replying to the original question ... :) If the current maintainer was interested, they had plenty of time to work on this (it's been nearly a year that lextudio took over). It doesn't seem to be the case unfortunately. If someone wants to take over my work, please do (and write in this thread saying you're working on it...), it's not too late. I take care of too many packages already, I'd love if someone stepped in. Cheers, Thomas Goirand (zigo)
Transitionning to the lextudio pysnmp / pyasn1 ecosystem
Hi, As you may know, the upstream author for pysnmp passed away last year. As a result, the whole suite was forked by "lextudio". I packaged it, and the result is this list of source packages: python-pyasn1-lextudio python-pyasn1-modules-lextudio python-pysmi-lextudio python-pysnmp-lextudio Appart from the OpenStack packages, here's the list of reverse dependencies for the old python3-pysnmp4 binary package: * patator * pdudaemon * pysmi * snimpy * changeme * python3-snimpy * python3-pysnmp4-apps * python3-pysnmp4-mibs * snmpsim My plan is to file bugs against these packages, asking to transition to the newer packages. We're just below the threshold for asking debian-devel about mass bug-filling, so I figured out I would only send a mail to the Python list. Do you guys approve my plan? Should we make transition dummy packages? Also to Adam Cécile: can you make your pull request against the new Salsa repository? Cheers, Thomas Goirand (zigo)
Re: Maintenance of netmiko in the Python team
On 9/13/23 14:29, Vincent Bernat wrote: On 2023-09-13 09:29, Thomas Goirand wrote: OpenStack networking-generic-switch needs 4.1.2, from last August, so I'm about to upload that version to Experimental right away. Since you, Vincent, is listed in the Maintainer: field, and the team is only listed as Uploaders:, I was wondering if it's ok for me to switch these, and go back to normal team maintenance. FYI, I'm doing this on my current upload to Experimental, though it's not unstable, and can be reverted very fast (PLEASE everyone, do NOT start another flame war for uploads to Experimental, especially when I'm kindly taking the time to write such a courteous message...). Yes, you can. I am often listed as Maintainer while the team should be because in a distant past, this was the default for whatever tool we used to generate debian/control. So, if you can, switch me to uploader (or remove me, I lack time to do anything useful). Thanks! Thanks for your prompt reply Vincent. FYI, the new version of Netmiko needs a lot of new dependencies that I've been able to work on already. At least: - python-ntc-templates - python-scrapli - python-scrapli-replay (useful to test the package just above) I'll be uploading these first, and see how this leads me. They are almost ready (I need to carefully review d/copyright before upload). Cheers, Thomas Goirand (zigo)
Re: PySNMP asyncio backend unusable in Debian 12 (needs stable update?)
On 9/13/23 13:43, Adam Cecile wrote: On 9/13/23 12:55, Thomas Goirand wrote: On 9/12/23 18:16, Adam Cecile wrote: Hello, No hurry, I think we might want to wait for upstream to respond to my PR regarding double awaitable fix. It is indeed lextudio upstream that took over the PySNMP package and all patches are coming from us (except mine ofc). Regards, Adam. Because it messes up the order in which people normally read text. Why is top-posting such a bad thing? Top-posting. What is the most annoying thing in e-mail? Hello, you started first ! LOL ! :) Well, I was on my phone, sorry for that ... :P Thanks! :) I tried applying your patch at https://salsa.debian.org/acecile-guest/python-pysnmp4/-/commit/88d40f1225de8f7b42413b56206b41a6155fcf09 Unfortunately, it doesn't apply on top of 4.4.12-2, which is the current version of the package (in Bookworm, Unstable and Testing). Would you be able to rebase your patch on top of 4.4.12-2? Then I'll do the work to get this into Bookworm (and Unstable/Testing). Cheers, Thomas Goirand (zigo) Yes that's expected. Well, how can I then apply it to the version in Bookworm? This commit is only to fix double awaitable "new" upstream bug. It depends on a large amount of backported commits to fix asyncio / Python 3.11 support. Could you backport it to 4.4.12-2 as in Bookworm and Unstable? As I wrote already, I already packaged python-pysnmp-lextudio, which is currently in the NEW queue. I will be happy to apply your patch in there, but IMO, we should treat pysnmp-lextudio as a different source and binary package (my binary conflicts with python3-pysnmp4), because the dependency chain is very different. You can see here a branch created from upstream 4.4.12 tag with asyncio patches cherry-pick from new upstream master: https://salsa.debian.org/acecile-guest/python-pysnmp4/-/commits/4.4.12+cherry-pick-asyncio-lextudio-fixes/ It has then been squashed into a single debian/patch: https://salsa.debian.org/acecile-guest/python-pysnmp4/-/commit/a5f17d27c7813dbdb64cdf674d1855a77c3eb0f0 Ah, super cool! It's too late for today (have to go back home), so I'll work on this tomorrow. Thanks a lot for your contrib. BTW, we've been using your MegaCli repo (we mirror it), and I also would like to thank you for this. :) I made my own forked repository because I'm unsure how we should proceed, but I can easily push the debian/4.4.12-3 tag to the regular Python module repository on Salsa. 4.4.12-3 will be for Unstable. For Stable, it's going to be something like 4.4.12-2+deb12u1, as per the normal process, and it will have to be (pre-)approved by the Debian Stable release team by filling a bug against release.debian.org. No worries, I do understand that Debian procedures are not easy to understand, though I'm happy to explain if you need. Cheers, Thomas Goirand (zigo)
Re: PySNMP asyncio backend unusable in Debian 12 (needs stable update?)
On 9/12/23 18:16, Adam Cecile wrote: Hello, No hurry, I think we might want to wait for upstream to respond to my PR regarding double awaitable fix. It is indeed lextudio upstream that took over the PySNMP package and all patches are coming from us (except mine ofc). Regards, Adam. Because it messes up the order in which people normally read text. Why is top-posting such a bad thing? Top-posting. What is the most annoying thing in e-mail? Thanks! :) I tried applying your patch at https://salsa.debian.org/acecile-guest/python-pysnmp4/-/commit/88d40f1225de8f7b42413b56206b41a6155fcf09 Unfortunately, it doesn't apply on top of 4.4.12-2, which is the current version of the package (in Bookworm, Unstable and Testing). Would you be able to rebase your patch on top of 4.4.12-2? Then I'll do the work to get this into Bookworm (and Unstable/Testing). Cheers, Thomas Goirand (zigo)
Maintenance of netmiko in the Python team
Hi, It appears to me that netmiko hasn't received as much love as it should. The package in Debian is still on upstream release 2.4.2, while upstream has continuously upgraded it (there's a new upstream release roughly every 3 months on average), and is now on 4.2.0 from May the 5th. OpenStack networking-generic-switch needs 4.1.2, from last August, so I'm about to upload that version to Experimental right away. Since you, Vincent, is listed in the Maintainer: field, and the team is only listed as Uploaders:, I was wondering if it's ok for me to switch these, and go back to normal team maintenance. FYI, I'm doing this on my current upload to Experimental, though it's not unstable, and can be reverted very fast (PLEASE everyone, do NOT start another flame war for uploads to Experimental, especially when I'm kindly taking the time to write such a courteous message...). Note that I am also planing a few changes, like the package is currently using the pypi tarball, I'd like to switch to using tags from github and probably other stuff. Please let me know, Cheers, Thomas Goirand (zigo)
Re: Uncleaned egg-info directory giving lots of bugs about failing to build after successful build
On 8/18/23 14:42, Julian Gilbey wrote: I'm sure I'm not the only one who received a whole bunch of bugs entitled "Fails to build source after successful build" last weekend. There was one theme common to most of them: the presence of a *.egg-info directory which was not cleaned by debian/rules clean. I know the bug report said that this policy is currently under discussion As much as I know, there's no controversy: this really is a bug in packages. However, the discussion in d-devel has shown it's a minor issue, as everyone has switch to use Git for packaging. , but I did get thinking about it. I imagine that this particular directory should be the responsibility of dh-python to clean up, but it may not be sensible to always delete *.egg-info directories, as they may be present in the orig.tar.gz file. They should not. If you're packaging from pypi, you should switch to using upstream VCS (most Python modules are in github). Otherwise, one possibility is to manually (well, through debian/watch) remove the egg-info from the orig.tar.gz. One could handle it by manually adding this directory to debian/clean in each package I used to add this to all of my packages: $ cat debian/source/options extend-diff-ignore = "^[^/]*[.]egg-info/" This works, and actually fixes the above mentioned bugs. However, as I didn't want to have a single remaining instance of this bad clean-up, I have setup my sbuild to check on it. The config is over here: https://wiki.debian.org/zigo/mysbuild#A.2BAH4-.2F.sbuildrc See the $external_commands thingy. This does a diff between the source package, and the result after build + clean. It does report files from the egg-info. Therefore, I did add rm -rf *.egg-info in all affected packages, so I can continue to use the $external_commands checks. I would strongly recommend every DD to do the same thing. Yes, we can have dh-python to do the work, but IMO, the only thing it should be doing, is rm -rf *.egg-info, and error out if the egg-info is within the orig tarball, as this should not happen, IMO. Now, I still think this is a minor issue... :) Cheers, Thomas Goirand (zigo)
Re: Python 3.10 in bookworm
On 2/5/23 14:50, Julian Gilbey wrote: Our social contract #4 says "Our priorities are our users and free software". In a Debian thread, invoking the social contract #4, is like owning a goodwin point. It suggests that the opponent is trying to do something against the Debian users, which is a very bad way to interact with others. Well done, you've earned a Debian goodwin point! Why would we tell a whole bunch of our users: "Don't upgrade to Debian 12 until all of the critical packages you use from PyPI are upgraded to support Python 3.11, or fix those packages yourself"? Because: - we don't want to maintain 2 interpreter in the next stable (that's too much work, and as much as I know, nobody volunteered for it, did you?). - the freeze will take months anyways, so these packages can be fixed in the mean time. - these modules aren't in Debian, and we can't cover all of what's in PyPi, only the subset we package. - that's a very valid answer. Bullseye will be around for at least 1 more year after Bookworm. There will be 2 more years of LTS after that. If you care yourself, probably you should attempt to open merge requests against the affected modules, to fix the situation. Cheers, Thomas Goirand (zigo)
Re: Python 3.10 in bookworm
How about fixing the 3.11 issues if you hit them ? How about using Buster and 3.9 if 3.11 doesn't work (yet) for you ? Thomas Goirand (zigo) On Feb 5, 2023 11:38, Julian Gilbey wrote: > > Why is the current intention not to ship the python3.10 package in > bookworm? > > I was trying to run some experiments in a virtual environment a few > days ago, and it turns out that several of the Python packages I > needed do not yet run on Python 3.11. I was saved by being able to > run in a Python 3.10 venv and download all the required packages from > PyPI. If bookworm shipped without python3.10, I would not have been > able to do my work. Removing python3.10 from bookworm will seriously > affect many of our users in a similar situation to me. > > Best wishes, > > Julian > > P.S. We should also fix #1036268 if we do keep python3.10 in bookworm; > I'm happy to do an NMU if needed. >
Re: Python 3.11 for bookworm?
On 1/16/23 17:23, Andreas Tille wrote: Am Sat, Jan 07, 2023 at 09:05:21AM +0100 schrieb Andreas Tille: If I would create a list mine whould be way longer. Please share it in this list! #1023965 [src:pandas] pandas FTBFS with Python 3.11 as supported version #1024031 [src:numba] numba FTBFS with Python 3.11 as supported version I saw the above 2 were fixed. I'd like to add #1027851 [src:pytorch] FTBFS with Python 3.11 as default version also with lots of rdepends. So we're back with one single bug. I remember seeing something similar in another package ... (scratching my head...). The latest version of the upstream code has some modifications to this broken Stream.cpp, have you tried to apply them? Do you have more to share? It's harder to help if you don't ask for it. IMO, feel free to give a full list of problematic packages in this list, so others may help. I did not received any response to my "small" list. What does this mean for the transition to 3.11 process? As much as I know, we're moving toward having Python 3.11 only in Bookworm. I'm not the person driving it though, and I am not in the best position to make such choice, but I support it (as I would prefer having the nice enhancements of Python 3.11 rather than lagging behind). Hopefully, I wont regret it and wont find more failures in "my" packages. We are constantly beaten by removal from testing warnings even with Python3.11 as an option and sometimes we simply need to remove that option as a temporary means for bookworm. Same over here. It's finally looking good for me after 2 months of heavy efforts. You mean you are fixing Python 3.10 manually in some packages diverging what will be default Python? Any answer to this question? All of my packages hopefully always test with all available versions, and most run autopkgtest. So I was warned early of Py 3.11 failures. They are all fixed, as much as I know (no opened RC bug remaining...). And no, forcing Python 3.10 is *NOT* an option, one must fix failures in Python 3.11. Bug #1026825: python3.11 as default filed right before (21.12.) a series of holidays in the region of the world where lots of developers will typically reduce their activity which is closely followed by the first freeze step is IMHO something else. Since I realised that the transition was started[3] our discussion is a bit useless. I just want to explain the motivation why I sounded "astonished" since you said that you do not understood astonishment since we are following the suggested plan. I keep on thinking that the timing is unfortunate and that it will spoil the whole release process. I'm sad to read this. Hopefully, this is truth only for some of the packages you care, and the vast majority of the packages are fine? I'm unfortunately not in a good position to tell (I didn't run any survey of broken packages...). Cheers, Thomas Goirand (zigo)
Re: Python 3.11 for bookworm?
Hi Andreas, On 12/30/22 10:22, Andreas Tille wrote: True, I remember the DebConf Python BoF. My memory tells me that the plan was to keep 3.10 as default. Thus Python 3.11 would be really a surprise. From a maintainers team with lots of Python packages that will need heavy work I can't say I'd be happy about a "migrate and see what might happen afterwards" strategy as it was proposed here. We have lots to do even without such an experiment. This has since already been discussed here: the final decision was to "at least try 3.11", which is exactly what we're doing. Well, that's not the first time we are trying to push the latest interpreter close to a release. The fact that we did so before does not make the idea better. I also very much would appreciate help on these (which all look like probably related to py3.11): #1026524 ironic-inspector: FTBFS: AttributeError: '_thread.RLock' object has no attribute 'is_locked' #1026547 python-pypowervm: FTBFS: AssertionError: Expected 'warn' to be called once. Called 2 times. #1026549 python-pytest-xprocess: FTBFS: tests failed #1026591 cinder: FTBFS: make[1]: pyversions: No such file or directory #1026595 python-murano-pkg-check: FTBFS: TypeError: load_all() missing 1 required positional argument: 'Loader' #1026610 horizon: FTBFS: tests failed #1026691 bandit: FTBFS: TypeError: load() missing 1 required positional argument: 'Loader' #1026693 cloudkitty: FTBFS: touch: cannot touch '/<>/debian/cloudkitty-doc/usr/share/doc/cloudkitty-doc/html/_static/toggle.js': No such file or directory #1026702 python-cursive: FTBFS: AttributeError: '_RSAPrivateKey' object has no attribute 'signer' #1026705 python-pecan: FTBFS: E AttributeError: 'code' object has no attribute 'co_endlinetable' #1026707 jenkins-job-builder: FTBFS: E: pybuild pybuild:386: test: plugin custom failed with: exit code=1: PYTHON=python3.10 stestr run FYI, I'm down with only 2 major bugs (I don't mind much if the other 3 RC bugs push the 3 affected packages away from the release, it's just a "would be nice" thing ATM): #1026524 ironic-inspector: FTBFS: AttributeError: '_thread.RLock' object has no attribute 'is_locked' #1026591 cinder: FTBFS: make[1]: pyversions: No such file or directory The first one also appears in Python 3.10.9, but seems not present in Python 3.10.6, as per a discussion with upstream on IRC. It looks like the default threading thingy has changed a little bit, leading to this... I know already how to fix the actual executed code, but this leaves some wrong tests (assert called), so I'm waiting to see if upstream can do better than me. For the Cinder bug, it looks like a test-only issue, which upstream is already working on. Worst case: blacklist these 250 failing tests, which is better than what it sounds (ie: just like Ironic, the actual production code is ok...). If I would create a list mine whould be way longer. Please share it in this list! We are constantly beaten by removal from testing warnings even with Python3.11 as an option and sometimes we simply need to remove that option as a temporary means for bookworm. Same over here. It's finally looking good for me after 2 months of heavy efforts. No better solution but better timing which means after bookworm release. I've read *many* people saying it would be disappointing for them to see their package removed because of Python 3.11. Well, please consider that it would also be very disappointing to *not* have Python 3.11 for those who managed constantly fix issues for it. The timing was exactly what was discussed during Debconf: it's very annoying that this year, upstream Python release was one month late... we're only trying to deal with it. Cheers, Thomas Goirand (zigo)
Re: Python 3.11 for bookworm?
On 12/22/22 02:21, Nicholas D Steeves wrote: 100% +1 I'm especially concerned about how a clear plan was not communicated to other teams--whose work will be broken by the proposed transition, were an exception to be granted. Debian is not a paragon of community if it makes late, unannounced changes that result in a yet-undetermined number of projects being dropped from bookworm's release. If Python 3.11 as the only supported version is a release goal, then the freeze schedule would need to be modified. Regards, Nicholas Hi Nicholas, While I can agree that it may be harsh, and that some packages wont be fixed in time, I can't let you say that there was only 1 month given, and that all of this comes as a surprise. We've been talking about this since last summer. On 12/22/22 05:48, M. Zhou wrote: > A significant Python performance improvement in 3.11 is good. > But note, when python performance has really become an issue, > people already have mature solutions, e.g. offloading the > performance critical part onto a compiled language. I don't agree with this either. I'm running large-ish OpenStack swift clusters, where we run up to 18 physical nodes as proxies (eating 100s of requests per seconds). Even a 10% gain would be greatly appreciated for us. There's no "C" improvement here, it's fully in Python... I tried running all Swift services over uwsgi, but it didn't work well (we reverted this type of setup because many things broke). The fact that a new python process can spawn faster is also really a good thing (so that's not only the interpreter pure speed that I would like to have). On 12/22/22 05:48, M. Zhou wrote: > Apart from that, package maintainers have their own plans as well. > I believe that at the current stage, many people have assumed that > the next stable will ship python3.10, and have their packages > finalized for freeze already. Making that transition at the current > stage will push a number of maintainers into a rush of updating > their packages again -- in the worst case, the package upstreams > might be not even ready for python 3.11. Well, that's not the first time we are trying to push the latest interpreter close to a release. In fact, this happens on nearly each freeze. Yes, sometimes, there's no upstream fixes yet and you have to write your own. But that's what we do: we maintain packages... and fix bugs when we can. Since last summer, I fixed maybe about 20 to 30 Python 3.11 issues, sometimes with, and sometimes without help from upstream. And I have about a dozen more to fix in my TODO (see below). I invite everyone to try to do the same, so we can reach that goal. I also very much would appreciate help on these (which all look like probably related to py3.11): #1026524 ironic-inspector: FTBFS: AttributeError: '_thread.RLock' object has no attribute 'is_locked' #1026547 python-pypowervm: FTBFS: AssertionError: Expected 'warn' to be called once. Called 2 times. #1026549 python-pytest-xprocess: FTBFS: tests failed #1026591 cinder: FTBFS: make[1]: pyversions: No such file or directory #1026595 python-murano-pkg-check: FTBFS: TypeError: load_all() missing 1 required positional argument: 'Loader' #1026610 horizon: FTBFS: tests failed #1026691 bandit: FTBFS: TypeError: load() missing 1 required positional argument: 'Loader' #1026693 cloudkitty: FTBFS: touch: cannot touch '/<>/debian/cloudkitty-doc/usr/share/doc/cloudkitty-doc/html/_static/toggle.js': No such file or directory #1026702 python-cursive: FTBFS: AttributeError: '_RSAPrivateKey' object has no attribute 'signer' #1026705 python-pecan: FTBFS: E AttributeError: 'code' object has no attribute 'co_endlinetable' #1026707 jenkins-job-builder: FTBFS: E: pybuild pybuild:386: test: plugin custom failed with: exit code=1: PYTHON=python3.10 stestr run BTW, thanks a lot to Lucas Nussbaum for doing the archive rebuilt and finding these out early! To sum-up: while I'm not 100% on the side of breaking things that close to a release, and would also feel it very painful if one of the above bugs isn't fixed in time, I don't feel like you guys are giving good point of argumentation, or a solution to improve the process. Doko already explained that switching the interpreter (the hard way) is the only viable way to find out the remaining bugs. Do you have a better solution in mind? Cheers, Thomas Goirand (zigo) OpenPGP_signature Description: OpenPGP digital signature
Re: Python 3.11 for bookworm?
On 12/15/22 16:18, Thomas Goirand wrote: On 12/13/22 00: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 Hi Graham, For OpenStack, I believe I was able to fix all Python 3.11 bugs (often with the help of upstream, a few times, on my own but very trivial fixes like the easy getargspec -> getfullargspec). The remaining filled RC bugs because of Python 3.11, I don't really mind (even if these 5 packages are AUTORM, I'm fine with that, they aren't key packages from the OpenStack perspective). However, there's still one very annoying bug in flask-restful that makes it not rebuild under Python 3.11. Keystone needs flask-restful, so I *must* fix it. Note here that #1024913 is because of another issue (ie: the autopkgtest functional test doesn't support more than one available Python interpreter, though it's easy to fix: simply kill the server between runs...). Though it hides the real FTBFS issue (failure in unit tests), which I believe is probably due to my upgrade of werkzeug 2.2.2 rather than Python 3.11. Help would be greatly appreciated fixing this bug. Hopefully, I can get this done during my holidays (and avoid any other work...). Cheers, Thomas Goirand (zigo) FYI, I have just uploaded a new Debian release of this package that fixes all the issues, thanks to a colleague of mine that had time to help (which I didn't really have...). So, I believe I'm all good regarding OpenStack packages right now (even if that last one was werkzeug 2.2.2 related, not python 3.11). Cheers, Thomas Goirand (zigo)
Re: Python 3.11 for bookworm?
On 12/13/22 00: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 Hi Graham, For OpenStack, I believe I was able to fix all Python 3.11 bugs (often with the help of upstream, a few times, on my own but very trivial fixes like the easy getargspec -> getfullargspec). The remaining filled RC bugs because of Python 3.11, I don't really mind (even if these 5 packages are AUTORM, I'm fine with that, they aren't key packages from the OpenStack perspective). However, there's still one very annoying bug in flask-restful that makes it not rebuild under Python 3.11. Keystone needs flask-restful, so I *must* fix it. Note here that #1024913 is because of another issue (ie: the autopkgtest functional test doesn't support more than one available Python interpreter, though it's easy to fix: simply kill the server between runs...). Though it hides the real FTBFS issue (failure in unit tests), which I believe is probably due to my upgrade of werkzeug 2.2.2 rather than Python 3.11. Help would be greatly appreciated fixing this bug. Hopefully, I can get this done during my holidays (and avoid any other work...). Cheers, Thomas Goirand (zigo)
Re: Python 3.11 for bookworm?
On 12/13/22 13:34, Julian Gilbey wrote: Hi Graham, On Mon, Dec 12, 2022 at 11:51:11PM +, 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. [...] If Python 3.11 is the default, then it is highly likely that Spyder will not be included: debugpy, which is a dependency of Spyder and python3-ipykernel (and lots of things that depend on that) seems to require major work upstream to make it fully compatible with Python 3.11. This is work in progress, but I don't know whether it will be ready in time for the freeze. At the moment, I have worked around this problem by just skipping the failing tests, but that is far from an ideal solution. Best wishes, Julian Hi Julian, It's probably ok if it's a *TEMPORARY* solution until upstream fixes everything in time for the release (which is months after the freeze). The question is: do you believe this may happen for let's say next March? Cheers, Thomas Goirand (zigo)
Re: Python 3.11 for bookworm?
On 12/13/22 10:57, c.bu...@posteo.jp wrote: Am 13.12.2022 10:15 schrieb Timo Röhling: One remaining problem is the unmaintained nose package [...] done some work patching up nose This question is just for my learning: Why is nose patched? Upstream nose is unmaintained for years. I understand that you cannot drop nose from Debian in the current situation of a freeze in one months and so many dependencies. But isn't there a Debian process/workflow to "warn" package maintainers about an upcoming package drop of one of there dependend packages to put some pressure into it? Looking into the list of over 200 packages I see this also as a chance to clean out some other unmaintained (and maybe not so important) packages from the Debian repo. It's unfortunately sometimes a bit harder than what one may think. Removing Nose from (build-)depends in some cases is hard, and IMO we started this process a way too late. Hopefully, Trixie will be nose-free! In the mean time, it is unfortunately my opinion that it's too late for Bookworm and that we must keep Nose for one more release. Cheers, Thomas Goirand (zigo)
Re: Python 3.11, bytecode and new internals
On 11/22/22 17:59, Julian Gilbey wrote: Or should we mark them as X-Python3-Version: << 3.11 so they can stay in testing as long as Python 3.10 is the default? I don't think this is the way. I'm sorry, I don't understand - which is not the way? I don't think you should "mark them as X-Python3-Version: << 3.11", because either we use 3.10 or 3.11 in Bookworm, I don't think that there's a plan for having both interpreters available. But I still don't know what to do in the meantime with the spyder ecosystem besides either wait for upstream to sort bytecode and pydevd and Piotr (and possibly upstream) to sort parso, or to mark them as Python 3.10 only. Well, hopefully for you, you'll get it fixed before next January, or we go back to 3.10 only (or both?). Cheers, Thomas Goirand (zigo)
Re: Python 3.11, bytecode and new internals
On 11/22/22 10:59, Julian Gilbey wrote: On Tue, Nov 22, 2022 at 09:22:05AM +0100, Thomas Goirand wrote: this, 100 times I very much don't agree. I think it's going pretty well, and the number of breakage isn't high. We just need a little bit of effort to make it in good enough shape. [...] Now, out of *many* of my packages, only a very few broke. Complicated packages like Eventlet for example, just worked. Others had upstream patches I applied. And I am in the opinion that we should go ahead and make 3.11 the default. If there are people with the expertise to help upstream update bytecode and parso (and probably several other low-level packages) for 3.11 so that the software that depends on them works with 3.11, then fine. (And it is a non-trivial update, AFAICT.) But until then, I'd be very reluctant to make 3.11 the default. Have you tried this PR? https://github.com/MatthieuDartiailh/bytecode/pull/107 I haven't decided what to do with packages which now FTBFS under 3.11 because of this. Should we just let them fall out of testing (that certainly includes spyder, and quite possibly ipython as well)? Or should we mark them as X-Python3-Version: << 3.11 so they can stay in testing as long as Python 3.10 is the default? I don't think this is the way. If we make 3.11 the default, these packages will likely not be in bookworm, which might upset our users even more. We're not there yet. We have until January to fix, and we haven't decided yet if 3.11 will be the default. Cheers, Thomas Goirand (zigo)
Re: Python 3.11, bytecode and new internals
On 11/21/22 18:30, Sandro Tosi wrote: On Mon, Nov 21, 2022 at 12:03 PM Louis-Philippe Véronneau wrote: 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... this, 100 times I very much don't agree. I think it's going pretty well, and the number of breakage isn't high. We just need a little bit of effort to make it in good enough shape. 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. Though we're not there yet, as a point were we can say it's a lost battle. why are we running a "test" this close to the release? Let me fix the above sentence for you: s/release/freeze/ Because Python 3.11 brings many nice feature, one of them being that it's 15 to 50% faster, very often 20% faster. Also, releasing the last Debian with an already obsolete interpreter version doesn't feel good. *who* are we running this test for? who made this decision (i figure RT gave the go ahead, but still)? is there any searchable source for this claim? This was discussed during Debconf in Prizren. You are always free to: - join us during debconf - join on IRC if you can't go to Debconf - read the video and voice your concerns on the list So the decision was made collectively. We also discussed this on IRC, and in this very list, if I'm not mistaking (sorry, I will not search for it). Currently, Python 3.11 is only an "available interpreter version", not the default. So it's kind of easy to revert (we would "only" need to remove the 3.11 interpreter, and rebuild the packages that produce 3.11 so files). It would be a lot harder to revert having 3.11 as default, Mathias said/wrote. So we're good... I very much thank Stefano for the many fixes he already uploaded. Now, out of *many* of my packages, only a very few broke. Complicated packages like Eventlet for example, just worked. Others had upstream patches I applied. And I am in the opinion that we should go ahead and make 3.11 the default. I'd be happy to have the opinion of the rest of the team, especially Doko and Stefano. Cheers, Thomas Goirand (zigo)
python-werkzeug 2.2.2 and flask 2.2.2 transition
Hi, I'd like Bookworm to be released with python-werkzeug 2.2.2 and flask 2.2.2 (needed by Sahara). So I've uploaded both to Experimental, and here's the result: https://qa.debian.org/excuses.php?experimental=1=python-werkzeug https://qa.debian.org/excuses.php?experimental=1=flask So I filled bugs against the relevant packages: pytest-httpbin: #1020728, #1020796 quart: #1020729 sentry-python: #1020730 flask-appbuilder: #1020739 flask-bcrypt: #1020824 flask-login: #1020794 pydevd: #1020795 python-flask-marshmallow: #1020822 searx-admin: #1020823 Please help fixing these. Cheers, Thomas Goirand (zigo)
Re: Notes from the DC22 Python Team BoF
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. 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. Cheers, Thomas Goirand (zigo)
Re: List of packages of Python team that have no autopkgtest
On 7/19/22 07:59, Andreas Tille wrote: Hi Zigo, you asked me for a list of packages without autopkgtest sorted by popcon value as we create it for Debian Med team also for Python team. I've simply added it to the Debian Med dir for simplicity - feel free to take over the code (or suggest some better place). Here ist the list https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/python-team-tests.txt which is created by the script I'm using for Debian Med and Debian Science[1]. It will be refreshed by a daily cron job. Hope this helps Andreas. [1] https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/missing-autopkgtest Hi Andreas, It does help a lot. Thanks a lot for this. We're really missing you in Prizren, btw. Cheers, Thomas Goirand (zigo)
Re: Reaching team consensus on usage of py3versions -r and X-Python3-Version in Lintian
On 1/17/22 18:47, Louis-Philippe Véronneau wrote: 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 +1 (very much)
Re: Update packages to recent version
On 1/13/22 21:25, Mechtilde Stehmann wrote: Hallo, I intend to package paperless-ng. Many of its dependencies are packaged in Debian but in an older version. You can see the list at https://salsa.debian.org/mechtilde/paperless-ng/-/wikis/home Are there any hints to upload newer versions? Kind regards Hi, If you're looking at the requirements.txt file from upstream to tell what version you need in Debian, this is a *very* wrong approach. What's happening is that your upstream is using the requirements.txt to tell pip what version to fetch for paperless-ng testing. This is, in no way, some indication of what should be in your package. For example, the requirements.txt contains: pytz==2021.1 however, I'd be really surprised if paperless-ng wouldn't work with some other version of python3-tz (even an older one). What's harder then, is to know what is the minimum version of each component for your application. However, running internal tests at build time may help you to know. I hope this helps, Cheers, Thomas Goirand (zigo)
Re: python-cryptography, Rust, and OpenSSL 3.0
On 12/1/21 4:05 PM, Andrius Merkys wrote: > Hi Simon, > > On 2021-12-01 14:31, Simon Chopin wrote: >> TL;DR: Does it make sense to upload the intermediary upstream version >> 3.4.8 or rather wait for someone to work on the Rust-based later versions? > > I would say yes. python-cryptography >= v3.4.6 is needed to update > python-autobahn [1]. Thomas Goirand (in CC) said [2] he is already > working on python-cryptography, thus it would be best to coordinate > uploads with him. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995431 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994914#19 > > Best, > Andrius > Did ?!? I believe I wrote I was working on python-autobahn, but I have to admit I completely failed my duty (busy on other stuff, like Ceph and many other RC bug fixing). At this point, I believe I must accept NMUs, or at least patches, otherwise it will take forever... Cheers, Thomas Goirand (zigo)
Removal of python-flask-script and flask-assets from unstable/bookworm
Hi, flask-assets build-depends on python3-flask-script. python-flask-script depends on Flask, but isn't compatible with Flask 2.x which is now in unstable. python-flask-script has no commit or release since 2017. So both packages are kind of doomed... Neither python-flask-script or flask-assets have reverse dependencies. I am therefore hereby proposing the removal of python-flask-script and flask-assets from unstable/testing, which by the way will allow Flask to migrate to Bookworm. Your thoughts? Cheers, Thomas Goirand (zigo)
Re: mass bug filling for nose removal (was: Bug#997758: nose: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 220))
On 11/11/21 1:33 PM, Dmitry Shachnev wrote: > Hi Thomas! > > On Thu, Nov 11, 2021 at 11:04:10AM +0100, Thomas Goirand wrote: >> On 10/24/21 3:24 PM, Dmitry Shachnev wrote: >>> If anyone is still using nose (1.x), please port your packages to nose2, >>> pure unittest or pytest. I am attaching a dd-list and I intend to do a MBF >>> in a few weeks when I have more time. >>> >>> -- >>> Dmitry Shachnev >> >> Hi, >> >> I wonder if we could do a mass bug filling for this. Your thoughts? > > Yes, this idea was present in my original mail you quoted here :) > > I intend to do it at some point, but I can't yet say when it will happen. Yes, but your original idea was to kick nose out of Debian before we get the chance to fix. I believe it'd be nicer to do the MBF even if we keep nose for a while, which is why I wrote about it again, as I didn't know what your intention was. Very good if you still have it in mind then! It'd be very useful to me at least (as many of the package I contribute may be affected and it's hard to have a vision of it without the MBF). Cheers, Thomas Goirand (zigo)
Re: mass bug filling for nose removal (was: Bug#997758: nose: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 220))
On 10/24/21 3:24 PM, Dmitry Shachnev wrote: > If anyone is still using nose (1.x), please port your packages to nose2, > pure unittest or pytest. I am attaching a dd-list and I intend to do a MBF > in a few weeks when I have more time. > > -- > Dmitry Shachnev Hi, I wonder if we could do a mass bug filling for this. Your thoughts? Cheers, Thomas Goirand (zigo) P.S: I'm not volunteering for doing it, just giving the idea...
Re: platform.machine() on salsa i386 build?
On 10/30/21 8:43 PM, Andrey Rahmatullin wrote:
> On Sat, Oct 30, 2021 at 02:20:40PM +0200, Ole Streicher wrote:
>> I have a package (pyraf) where I need to switch off some tests for i386
>> (but not for other 32-bit platforms). I do this by
>>
>> import platform
>> is_i386 = platform.machine() in ('i386', 'i486', 'i586', 'i686')
> Yup, this is incorrect. This is the same as `uname -m` and so returns the
> kernel architecture.
> If you want to do this purely at the upstream side without checking
> DEB_HOST_ARCH, AFAIK there is no 100% reliable way to do this.
I would also advise to use DEB_HOST_ARCH... Maybe with some fallbacks if
you wish to upstream it?
Cheers,
Thomas Goirand (zigo)
Re: Bug#997758: nose: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 220)
On 10/25/21 8:18 PM, Dmitry Shachnev wrote: > However, it would be still nice to remove nose at some future point, maybe > before Bookworm release. Will do, probably for the next version of OpenStack (last one made me update 220 packages: that's a good way to review everything). > I'm impressed by the number of packages you have depending on nose, but if > they all come from the same upstream, maybe you can convince this upstream > to not rely on dead software. I believe most dependencies on Nose could be removed (for example, all of the OpenStack dashboard stuff...), but just right after a release isn't the best time to start the work... Cheers, Thomas Goirand (zigo)
Re: Bug#997758: nose: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 220)
On 10/24/21 3:24 PM, Dmitry Shachnev wrote: > Hi all! > > On Sun, Oct 24, 2021 at 01:49:30PM +0200, Lucas Nussbaum wrote: >> Source: nose >> Version: 1.3.7-7 >> Severity: serious >> Justification: FTBFS >> Tags: bookworm sid ftbfs >> User: lu...@debian.org >> Usertags: ftbfs-20211023 ftbfs-bookworm >> >> Hi, >> >> During a rebuild of all packages in sid, your package failed to build >> on amd64. >> >> [...] > > It happens because setuptools v58.0.0 removed support for 2to3 during builds, > which nose relied on (because it has a Python 2 codebase). > > Instead of spending time on a proper Python 3 port, I would prefer to simply > let nose die (it is abandoned since 2016). > > If anyone is still using nose (1.x), please port your packages to nose2, > pure unittest or pytest. I am attaching a dd-list and I intend to do a MBF > in a few weeks when I have more time. > > -- > Dmitry Shachnev Hi, I'm referenced for 55 packages. Please don't force me to do this right away, that's too much work. I very much would prefer if we could have a smoother transition. Note that it's possible that for many packages mentioned, only removing the dependency should be enough. Still, that's some work to do... :/ Other alternative would be: help with NMU fixes (or I can add any of you in the OpenStack team if you need...). Cheers, Thomas Goirand (zigo)
Re: python-anyio not building?
On 10/23/21 1:09 PM, Julien Puydt wrote: > Hi, > > I don't get why python-anyio is stuck ; I certainly didn't upload it > without trying to build it, and I just tried again and there was no > issue : > https://buildd.debian.org/status/package.php?p=python-anyio > > Does someone have a clue what is happening? > > Cheers, > > J.Puydt > It looks fine to me, is there any issue? Cheers, Thomas Goirand (zigo)
Re: .egg-info for entry points during dh_auto_test
On 10/21/21 8:55 PM, Michael Fladischer wrote:
> Hi,
>
> I'm working on src:pytest-lazy-fixtures and was trying to get the
> unittests to run but it seems that I have run into a problem that I'm
> not sure on how to fix it in a clean way.
>
> pytest-lazy-fixtures is a pytest plugin and registers itself through the
> Python entrypoints mechanism. In its unitests, it assumes that this
> registration has already happened but during dh_auto_test there is no
> .egg-info directory available. I could use "python3 setup.py develop -x"
> to generate it, but this registers the package in /usr inside the build
> chroot which I think is not the best solution.
>
> Is there an other, less intrusive way to register the entrypoint before
> running the tests?
>
> Thanks,
> Michael
>
Hi Michael,
I do this in many of my packages (or a variation of this) to solve that
problem:
override_dh_install:
python3 setup.py install --install-layout=deb \
--root=$(CURDIR)/debian/tmp
ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
PYTHONPATH=$(CURDIR)/debian/tmp/usr/lib/python3/dist-packages \
dh_auto_test
endif
dh_install
override_dh_auto_test:
echo "Do nothing..."
I hope this helps,
Cheers,
Thomas Goirand (zigo)
Re: Why is isal limited to just three archs?
On 10/16/21 9:09 AM, Nilesh Patra wrote: > Hi Ondřej, > > I see that isal package is limited to amd64, arm64 and kfreebsd-amd64. > Is there a particular reason for this? -- Is it possible to extend > support to other archs? > > Actually, a -med team package fastp has started to depend on > libisal-dev, and this > now is limited to the few archs isal supports. So it would be really > nice if isal > can build on more archs. > > Please do let me know. > > Nilesh Hi, Did you look into the source package? isal is written in assembly language... Cheers, Thomas Goirand (zigo)
Re: writing debian/gbp.conf considered harmful [was: python-django-js-asset_1.2.2-3_source.changes REJECTED]
On 9/21/21 11:00 PM, Antonio Terceiro wrote:
> However, having it duplicated in every package means we as a team work
> consistently regardless of people's global configuration, and that's one
> less detail people need to get just right to be able to contribute
> effectively.
No. It *ALREADY* works by default, no need to tweak anything on
debian/gbp.conf. Also, as I wrote already, using gbp buildpackage is
*NOT* the only one way of doing things. One can use sbuild without gbp.
What you're proposing is in fact the same as if you were proposing to
add defaults for some text editors in the packaging: that's irrelevant,
and hard to maintain consistently (like Sandro wrote).
> Also, one's global configuration might not apply to all the packages
> they contribute to
It is the case for me: I contribute to both the OpenStack team and the
Python team. Both teams have *very* different workflow (the Python team
is using pristine-tar, I don't like it and that's the main reason why
OpenStack is maintained outside of this team...).
In the OpenStack team, we used to maintain per-package debian/gbp.conf.
I am *very* happy we decided back in Debconf Montreal in 2017 to stop
doing that.
> it's easier for everyone if gbp just does the
> right thing based on per-package configuration than expecting people to
> remember to switch their defaults, or to pass options explicitly.
There's nothing to switch. One just needs to remember to explicitly
generate the tarball with "gbp export-orig", OR (preferred) directly
fetch the orig.tar.{gz,xz} from the Debian archive. If you forget, gbp
complains about it and stops building (that is, as long as you have the
option "no-create-orig = True" in your ~/.gbp.conf).
Cheers,
Thomas Goirand (zigo)
Re: python-django-js-asset_1.2.2-3_source.changes REJECTED
On 9/20/21 5:14 PM, Sandro Tosi wrote: >> That's because gbp does not use pristine-tar by default, and >> debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to >> fix that. > > I dont think this is the right approach: the default options to work > on DPT packages should be in gbp default config file (or in another, > global, config file), and not live in each and every package > debian/gbp.conf file; it is already inconsistently maintained with > several packages having uncommon settings that will take precedence > over the default ones. +1 Plus gbp is just *one* out of *many* tools available. Some people just prefer to use sbuild only, for example, and that's perfectly fine. IMO it's up to the person that's using gbp to know what they are doing. FYI, I've rebuilt regularly packages from the team, I even have "pristine-tar = False" in my ~/.gbp.conf, and it's all fine... Cheers, Thomas Goirand (zigo)
Re: Moving forward with more Python 2 removal, plus upgrading to markupsafe 2.0, jinja2 3.0, werkzeug 2.0 and flask 2.0
On 9/18/21 3:02 PM, Thomas Goirand wrote: > Dear Python Team, Dear Piotr, > > As I was packaging Cloudkitty (that is: OpenStack rating of resources, > typically used in a public cloud) for the next Xena release, I went into > this chain of dependency: > > cloudkitty: needs flask 2.0 > Flask 2.0: needs werkeug 2.0, jinja2 3.0 > jinja2: needs markupsafe 2.0 > > The thing is, markupsafe 2.0 looks like incompatible with Python 2 (when > I removed Python 2 support in the package, it built fine). > > I currently have updated markupsafe and jinja2 packages in my laptop, > (which IS removing Python 2 support). I'll soon have updates for the > other 2 (if I don't hit any blockers). > > During the python BoF of the last Debconf, we decided to go ahead with > full removal of Python 2, so doing this looks like a move to the right > direction. > > Is it fine for everyone (including Piotr, who's the only marked uploader > for these) if I upload these to Experimental right now (which is where I > am uploading OpenStack Xena), and in Unstable after the 8th of October > (when OpenStack Xena will be finally released)? > > I'm also aware that the packages I mentioned above are high profile (ie: > used a lot in Debian), which is why I thought announcing my plan was a > good idea (also so that Piotr can tell his opinion). > > Also Piotr, can I add myself as uploader for all of these? > > Your thoughts? > Cheers, > > Thomas Goirand (zigo) > > P.S: I do believe that uploading to Experimental is harmless (when we're > not in freeze), so I may go ahead before getting a reply, and we can > decide what to do together. > FYI, I went ahead with the above, and uploaded to Experimental (and also uploaded Falcon 3.0.1 too...). All went fine, however, I had to disable a dozen unit tests in werkzeug. Help to fix this would be very much appreciated. Cheers, Thomas Goirand (zigo)
Moving forward with more Python 2 removal, plus upgrading to markupsafe 2.0, jinja2 3.0, werkzeug 2.0 and flask 2.0
Dear Python Team, Dear Piotr, As I was packaging Cloudkitty (that is: OpenStack rating of resources, typically used in a public cloud) for the next Xena release, I went into this chain of dependency: cloudkitty: needs flask 2.0 Flask 2.0: needs werkeug 2.0, jinja2 3.0 jinja2: needs markupsafe 2.0 The thing is, markupsafe 2.0 looks like incompatible with Python 2 (when I removed Python 2 support in the package, it built fine). I currently have updated markupsafe and jinja2 packages in my laptop, (which IS removing Python 2 support). I'll soon have updates for the other 2 (if I don't hit any blockers). During the python BoF of the last Debconf, we decided to go ahead with full removal of Python 2, so doing this looks like a move to the right direction. Is it fine for everyone (including Piotr, who's the only marked uploader for these) if I upload these to Experimental right now (which is where I am uploading OpenStack Xena), and in Unstable after the 8th of October (when OpenStack Xena will be finally released)? I'm also aware that the packages I mentioned above are high profile (ie: used a lot in Debian), which is why I thought announcing my plan was a good idea (also so that Piotr can tell his opinion). Also Piotr, can I add myself as uploader for all of these? Your thoughts? Cheers, Thomas Goirand (zigo) P.S: I do believe that uploading to Experimental is harmless (when we're not in freeze), so I may go ahead before getting a reply, and we can decide what to do together.
Re: RFS: colorzero/2.0-1 [ITP] -- Construct, convert, and manipulate colors in a Pythonic manner.
On 6/19/21 2:03 PM, Peter Green wrote: > Just done some reviewing/tweaking. I've pushed the following changes to > the git repo, please > tell me if you have any objections. > > I added a gpb.conf to make git-buildpackage actually use pristine tar > and hence result in an orig > tarball that was consistent with what is already in Ubuntu. > > I found the clean target was not cleaning up the "egg-info" so I added a > command to do that. I used to do that, but a few years ago, I switched to (and generalize in all of my packages) using this: $ cat debian/source/options extend-diff-ignore = "^[^/]*[.]egg-info/" That's a way more simple, as sometimes, upstream ships an egg-info and building *modifies* it (and then, nightmare starts...). Just my 2 cents of experience... :) Thomas Goirand (zigo)
Re: Python BoF at DebConf2021
On 6/12/21 10:20 PM, 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? Thanks, go ahead! :) Did you also register a BoF for the puppet team? Thomas
Re: Jupyter team?
On 5/18/21 10:06 AM, Gordon Ball wrote: > On Mon, May 17, 2021 at 06:20:19PM +0200, Roland Mas wrote: >> Hi everyone, >> >> I've been contracted by Synchrotron Soleil to work on the packaging of >> Jupyterhub and its dependencies. This turns out to about 20 Python packages, >> most of which should probably go under the Debian Python Team umbrella >> (although some may go into Debian Science). So I hereby request to be added >> to the python-team group on salsa. My salsa login is "lolando", and I have >> read and accept the >> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst >> policy. > > Hello > > Good to have more people working on jupyter and related tools. Can you > say what the extent of your goal here is? Does it just relate to the > jupyterhub server, spawners, proxy, etc or does your target also include > some work on the jupyter interfaces/core side? > > I wonder if it is time to have a distinct jupyter packaging team given > the (perhaps concerningly?) growing size of this software stack [1]. We're talking about 2 dozen of Python packages. Do you really think that's a lot? Cheers, Thomas Goirand (zigo)
Re: Challenges packaging Python for a Linux distro - at Python Language Summit
umpy and sci-py. The problem isn't the build system, which is doing things the correct way. Any "arch: any" package linked against Python *must* be upgraded together with the interpreter itself when it transition from Unstable to Testing. That's a fact, and how Debian is designed. By *policy* Debian doesn't support multiple versions of a library on a single system. The only thing that is allowed, is to have 2 versions *during a transition*. What we hope is to have such thing happen (ie: 2 versions of a single library) only in Unstable, though sometimes, this also migrates to testing, but that's not what we desire. If you wish Debian to support multiple versions of a library, you should first attempt to discuss this feature at large with the Debian community because *by design* (and therefore, written in the stones of the Debian Policy Manual) that isn't how we want Debian to work, and how the Debian community wants it to work. If you wish to have such a feature, then yeah, probably you should go and use another distribution, because I don't see Debian changing on the direction you describe anytime soon. > i can only surmise that they probably don't want to say anything > because the message being sent to them on summary closure > of bugreports is that, well, "nobody cares". I don't think that's right. They just think you are wrong, because you believe Debian should support multiple versions of a library (here: Python), when it's not the case *by design*, because we (ie: everyone contributing to Debian) want Debian to be this way. This isn't specific to the Python world, this is how Debian *at large* is designed. > once this is accepted as actually being a problem that needs solving, > rather than being avoided because "it's not supported, you're on your > own, not our problem", i am happy to help advise and discuss > solutions. > > given that this has been ongoing for 10 years now i have been giving > it some thought for a long, long time. > > however before getting to a discussion of solutions i would prefer > to see acknowledgement that it is recognised as a problem that > people actively wish to see fixed. As I wrote earlier, before discussing if this is a problem or not, you will need to convince a majority of Debian Developers that having 2 versions of a shared library at the same time on a given Debian system is something we desire. Good luck doing that, as this is a very strong feature of Debian. I don't know any Debian Developer that believes this is something desirable. > otherwise i will have to wait patiently > for the next disaster situation to occur, or, sadly, after 20 years of > using debian, and remaining loyal to it despite maltreatment, i will > have to find an alternative distro. There's no maltreatment. Just a misunderstanding from your side of what Debian does, IMO. Finding another distro may be one solution indeed. Doing what Jeremy suggests (ie: running your builds in a chroot, or with venv, etc.) may work for some times, though I would strongly recommend the best practices in terms of dependency management, which means: always try to stay current with all of your dependencies. > what is stopping me from doing that is the severe financial consequences > involved and risk to myself and my family due to my income being > far below average. the downtime that would result is a huge risk, > plus learning a new distro also compromises my effectiveness which > also results in further lost income. Then learn how to reproducibly build chroot and venvs. > what i am saying is: this is serious - i am effectlvely financially > trapped and critically dependent on the decisions that you make, > even though i am not paying you money for the work that you do. IMO, you've trapped yourself here... but there's exist strategies. :) I sincerely hope you will find a solution that matches your need, hopefully by continuing to use Debian. Cheers, Thomas Goirand (zigo)
Re: Challenges packaging Python for a Linux distro - at Python Language Summit
On 5/16/21 1:52 PM, Luke Kenneth Casson Leighton wrote: >> * One 3.x version at a time. Doesn't line up with cpython's support terms. > > folks, deep breath here: this is much more important than the one line > summary suggests. > > for some background: i have been using debian since 1996 and python for > 20+ years, dating back to python 2.0. > > due to the massive amount of accumulated software (several million > development source code files) i run a rolling debian/testing system, > *never* do an "apt-get dist-upgrade", *always* simply perform an on-demand > install of a given package and let apt sort itself out even to the > point often of > having some innocuous package end up pulling in a new libc6-dev and > binutils. All the horrors that you are painting after this paragraph, are due to the fact that you aren't doing "apt-get dist-upgrade". I'm having a hard time understanding why you're both: - not doing "apt-get dist-upgrade" - complaining that it's breaking your system Could you care to explain? This makes absolutely no sense. By the way, since you're never doing "apt-get dist-upgrade", it means your system is full of security issues that aren't getting fixed. Hopefully, the computer system(s) you're talking about isn't connected to internet, right? Cheers, Thomas Goirand (zigo)
Re: Challenges packaging Python for a Linux distro - at Python Language Summit
On 5/13/21 1:26 AM, Stefano Rivera wrote: > Hi Thomas (2021.05.12_23:06:45_+) >> On 5/12/21 11:21 PM, Stefano Rivera wrote: >>> Matthias Klose gave a presentation at the Python Language Summit on the >>> Challenges packaging Python for a Linux distro. >>> [..] >> This looks great. Is there a video of it somewhere? > > No, there won't be videos published, only blog posts written. > > SR Matthias, if you read this: you *MUST* make such a presentation at the next debconf, *PLEASE* !!! Cheers, Thomas Goirand (zigo)
Re: Challenges packaging Python for a Linux distro - at Python Language Summit
On 5/12/21 11:21 PM, Stefano Rivera wrote: > Matthias Klose gave a presentation at the Python Language Summit on the > Challenges packaging Python for a Linux distro. > [..] This looks great. Is there a video of it somewhere? Cheers, Thomas Goirand (zigo)
Re: upstream python concerns, python3-full package for bullseye
On 2/16/21 5:25 AM, Stefano Rivera wrote: > Hi debian-python (2021.02.11_18:24:57_+) >> I have prepared a policy MR for this: >> https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/8 >> It catches up on the current split situation, too. > > We had a discussion on the principle of the change, but nobody has > responded to the policy wording yet. > > Anyone seconds / objections? > > SR > It's fine, thanks for working on this. Cheers, Thomas Goirand (zigo)
Re: upstream python concerns, python3-full package for bullseye
Hi,
FYI, my concerned are addressed by what Stefano wrote about the full
desc, though I still feel like I need to reply to you.
On 2/12/21 2:08 PM, Julien Palard wrote:
> Hi,
>
> As far as I understand, the divergence between "Python upstream" and
> Debian is:
>
> - It looks like Debian target users consuming software, users just
> install a package and it works, no venv needed obviously, it always just
> work, it's fantastic. Users may not even care if the program is written
> in Python or not at this point.
>
> - Upstream Python is obviously composed by people writing in Python and
> know many people who write some Python too: all in need of venv to work.
>
>> Also, it's a disservice to push our users into the direction of using
>> venv which is very ugly way to use Python in a Debian system
> I do agree, we could even replace Python with software in this sentence.
>
> And I don't think we're pushing our users to always install things in
> venvs. Providing venv is not a big signal for Debian users to ask them
> to use it to install packages (if a signal at all).
>
> With my "I do write things in Python that may run on non-Debian systems"
> hat, and "I teach Python" (most of them not using Debian) hat, a venv is
> helping me in many many ways, it's literally part of my daily routine:
>
> - It allows me to pin a set of dependencies and sub-dependencies to an
> exact version (I do use pip-compile, from pip-tools), per project, that
> I can use in automatic tests (ensuring if tests passes today, they'll
> pass tomorrow), I can share this set with coworkers and future me ("if
> it works for me, it works for you"), note my coworkers may not use
> Debian at all.
>
> - It allows me to easily replace a dependency with a modified one to
> test it, or make anyone else test it (for example [1]).
>
> - It allows me to work on my Debian testing laptop on code aimed to work
> on Debian stable, or a completly different OS.
>
> - It allows me to work on various projects with a different set of
> incompatible dependencies.
Wouldn't it be nicer if all of the dependencies you're talking about
were all playing well together? You're happy with venv and pip because
they address the huge problem that your dependencies are constantly
breaking the world. This needs to stop. Promoting venv and pip isn't
helping toward this goal, and that's what I was trying to say to begin with.
> I still think venv is a very usefull tool
It is. Because it addresses (badly) the brokenness of your dependencies,
as I wrote above.
> P.S.: If you still feel I'm completly wrong to use venv and pip in my
> workflow, I'll be very happy to learn better ways.
You are not. Though in an ideal world, you'd be only describing the list
of dependency you need, and the tooling would either fetch the Debian
package (if available) or through PyPi, and it would always work,
without ever needing to care about versions (here, from your side, with
pinning and version bounds), and without ever needing to isolate things
in a venv/chroot.
Cheers,
Thomas Goirand (zigo)
Re: upstream python concerns, python3-full package for bullseye
Hi, Looks like once more I've been not able to express myself clearly enough in the first message. Hopefully, what's bellow contain *all* of my thoughts, and that it brings value to this thread. On 2/12/21 9:30 AM, Raphael Hertzog wrote: > On Fri, 12 Feb 2021, Thomas Goirand wrote: >> What I read from Elana, is that *upstream* think we have a problem. But >> do we really have one? Or are we just being influenced by upstream who >> is trying to impose a view we don't necessary share? > > Or is it you that is trying to impose your view on those users? > > Let's be clear, I understand what you are saying and I mostly agree > with your view but Debian is about inclusiveness and about meeting > the needs of as many people as possible and I believe that implementing > this python3-full meta-package can only help towards this. I mostly agree to add a metapackage. I just don't agree with the choice of package name. It makes our user believe that Python isn't "full" without it, and they then may install it when they don't need it to consume whatever is packaged in Debian. Reality is different. Also, it's a disservice to push our users into the direction of using venv which is very ugly way to use Python in a Debian system, outside of just testing something. You then end up with a variety of versions of things pulled by pip, which are quickly unmanageable. That's why we do package Python modules, and make sure they work well together (sometimes, patching them to achieve this goal). So, by all means, let's create a metapackage, and call it "python3-addons-that-upstream-thinks-make-python-full" or anything you like, but not just "python3-without-this-package-python-is-not-full", misguiding our users to install venv and distutils which they don't need if they are consuming only Python for things that we package already. I'm also concerned that this is useful at all. If someone wants to use venv, 2to3 or setuptools, I believe they will know how to fetch them... Cheers, Thomas Goirand (zigo)
Re: upstream python concerns, python3-full package for bullseye
On 2/12/21 1:42 AM, stefa...@debian.org wrote: > Hi Thomas (2021.02.12_00:11:07_+) >> So indeed, it's a good thing to *not* include distutils and venv by >> default when someone installs python. > > ... > >>> I propose that we add a python3-full* metapackage for >>> bullseye. (*We can use a different name, but it must be a name not >>> currently in use.) >> >> Please do not add distutils, venv and lib2to3 in this python3-full >> metapackage. IMO that's falling into a design that isn't Debian. This >> would probably be best in a "python3-dev-full" or something similar, as >> from the distribution perspective, we see them as developer use only. >> Don't confuse our users so that they install something they don't need. > > From your arguments above, it doesn't sound like the python3-full solves > a problem you experience. So, I'm not sure why you'd be using it. I don't think I would. And to me, Python is already "full"(y supported) without these. Though at least, adding "dev" in its name shows it's not for our users. > If it doesn't include distutils, venv, lib2to3, etc. then it doesn't > solve any problem we currently have, and we don't need it. The purpose > is to provide a package that gives you the entire stdlib. > > SR What I read from Elana, is that *upstream* think we have a problem. But do we really have one? Or are we just being influenced by upstream who is trying to impose a view we don't necessary share? Cheers, Thomas Goirand (zigo)
Re: upstream python concerns, python3-full package for bullseye
Hi Elana, Thanks for bringing this topic in the channel, and speaking with the Python Steering Council, plus Mathias and Stefano. That's very much appreciated. On 2/11/21 7:12 PM, Elana Hashman wrote: > - When users install Python, it should be easy to install all required > modules for what upstream considers core, including venv, distutils, > and lib2to3. I understand that upstream python guys probably think the way to consume python stuff is through venv, pip, and setuptools. I have a very different view on this, and probably I'm not alone. We (Debian people) indeed prefer if our user can enjoy a packaged versions of things if they are available (and that's not specific to Python). In such a packaged environment, venv and distutils are useless, as the distribution is taking care of all what these tools would do without apt or dpkg. I do prefer my system to *not* have venv support, for example. So indeed, it's a good thing to *not* include distutils and venv by default when someone installs python. As for lib2to3, is this a joke? Lib2to3 is a complete failure to begin with. Upstream python developer naively thought everyone would just switch at once to Python3, but it never happened, which is why things like six exist (ie: to bring a layer of compatibility between python 2 and 3 during the transition). Also, since we got rid of Python 2, is this a (naive) call to bring a library that could convert old code which nobody cared to port in time? This also will be a failure, IMO. Lib2to3 is just an utility, which has nothing to do on a standard user computer, unless they really know what it does and explicitly want to use it (and in that case, it's easy for them to fetch it). > I propose that we add a python3-full* metapackage for > bullseye. (*We can use a different name, but it must be a name not > currently in use.) Please do not add distutils, venv and lib2to3 in this python3-full metapackage. IMO that's falling into a design that isn't Debian. This would probably be best in a "python3-dev-full" or something similar, as from the distribution perspective, we see them as developer use only. Don't confuse our users so that they install something they don't need. Hoping that what I wrote is making sense, Cheers, Thomas Goirand (zigo)
Re: Downgrading dnspython back to 1.16.0 to fix Eventlet
On 2/2/21 7:46 PM, Thomas Goirand wrote: > Both Eventlet and DNSPython are monkey patching the standard SSL library > in potentially conflicting ways After checking, that's *NOT* the case. Though Eventlet is doing monkey-patching of dnspython, in a possible not-compatible with 2.x. Anyways, looks like this small patch fixes Eventlet with dnspython 2: https://github.com/tipabu/eventlet/commit/2f9b7969f9a66a75e72908454246b88bf57fe58a I've uploaded Debian release 0.26.1-5, and when it reaches the mirrors, I'll try again to make OpenStack work, and see how it goes. If it fixes everything, then we're good to go. Otherwise, my questioning about downgrading dnspython to 1.16.0 still stand. I'll let you know. Cheers, Thomas Goirand (zigo) P.S: Thanks to Tim Burke for this patch
Downgrading dnspython back to 1.16.0 to fix Eventlet
Hi Scott, Robert, As you may know, Eventlet is at the hart of OpenStack. Unfortunately, version 0.26.1 currently in Sid/Testing fails when connecting over SSL, with a traceback that looks like this: File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 392, in connect self.ssl_context = create_urllib3_context( File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line 303, in create_urllib3_context context.options |= options File "/usr/lib/python3.9/ssl.py", line 602, in options super(SSLContext, SSLContext).options.__set__(self, value) File "/usr/lib/python3.9/ssl.py", line 602, in options super(SSLContext, SSLContext).options.__set__(self, value) File "/usr/lib/python3.9/ssl.py", line 602, in options super(SSLContext, SSLContext).options.__set__(self, value) [Previous line repeated 458 more times] RecursionError: maximum recursion depth exceeded (txn: txad38d097c88545ecbd274-0060127626) In OpenStack, this happens whenever a service attempts to validate a Keystone token, meaning whenever any component connects to the OpenStack API (in most deployments: this is done over SSL). In other words: all of OpenStack is currently completely broken because of this. Both Eventlet and DNSPython are monkey patching the standard SSL library in potentially conflicting ways (for those who don't know: this means they override the standard Python SSL objects/functions to re-write / overload them). This incompatibility is well known upstream. Some has been addressed in Eventlet, but not all. Currently, Eventlet has: 'dnspython >= 1.15.0, < 2.0.0' as dependency in upstream setup.py. So I am currently wondering if we could revert DNSPython in Sid/Testing to 1.16.0 until this is fixed upstream. That is, unless someone here in this list knows how to fix Eventlet, but this looks like non-trivial... Note that Ubuntu has version 2.0.0+really1.16.0-2ubuntu2, as they understood the above. Scott, Robert, your thoughts? Do you think it's ok to downgrade dnspython? Or will it break some other reverse-dependencies? Is there another way to fix the current situation? Cheers, Thomas Goirand (zigo) P.S: The current reverse-dependency tree is: Reverse-Recommends == * 2ping * calibre * dnstwist Reverse-Depends === * ansible * b4 * dehydrated-hook-ddns-tsig * designate-tempest-plugin * dhcpy6d * dkimpy-milter * dnsdiag * dnsrecon * dnsviz * fierce * knockpy * linkchecker [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x] * mailman3 * patator * python3-aioxmpp * python3-authheaders * python3-certbot-dns-rfc2136 * python3-designate * python3-dkim * python3-dnsq * python3-electrum * python3-email-validator * python3-etcd * python3-eventlet * python3-exchangelib * python3-formencode * python3-kdcproxy * python3-ldapdomaindump * python3-sleekxmpp * python3-spf * recon-ng * samba [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x]
Re: gotchas when running tests via pybuild?
On 1/22/21 6:06 PM, Antonio Terceiro wrote: > Hi, > > I'm working on python-eventlet, to fix a FTBFS bug and an > incompatibility with python3.9. I got both fixes ready, but I'm not > fighting with the fact that the test suite fails randomly. In my > experiments, the test suite fails ~40% of the time, but *only when run > during the build* (!!). > > - I added a testsuite run to autopkgtest, and it consistently passes, > 100% of the time. > - If I run the same command as pybuild runs manually (python3 -m nose) > on a fully patched tree, it passes 100% of the time. > - Only during the build -- when executed automatically by pybuild -- the > test fails ~40% of the time. > > The failures are the typical failures you get when testing concurrency > code: timeouts, race conditions, etc, and it happens on different tests > every time. What I don't quite understand yet is why this _only_ happens > during the Debian package build. > > I already checked that the tests don't use anything else from the source > tree beyond the tests themselves and the python modules. For example the > autopkgtest copies tests/, and only it, to a temp directory and runs the > tests from there; and works every time. So in principle I wouldn't need > to have an explicit testfiles file. > > Does anybody have an insight on cases like this? Are there any details > that I'm missing? > > If anyone wants to try it, the git repository is up to date. Hi, Eventlet looks broken beyond just the unit tests. I did a deployment of OpenStack on unstable, and there's lots of issues on absolutely all daemons. Hopefully, I can fine time to investigate this next week. Cheers, Thomas Goirand (zigo)
Re: sponsor uploading python-discogs-client_2.3.5-1
On 12/14/20 11:43 PM, jojo wrote: > On 11.12.20 10:03, jojo wrote: >> Hi, >> I updated a team-maintained package and am looking for an upload >> sponsor. This one: >> https://salsa.debian.org/python-team/packages/python3-discogs-client/-/tree/debian/2.3.5-1. >> I already uploaded the package to my webserver: >> https://jojo.peek-a-boo.at/E950513F/python-discogs-client_2.3.5-1.dsc >> >> I tried to find a sponsor on the irc channel #debian-python already. I >> posted it in the channel and have been told to better just add it to >> the topic of that channel. I didn't do that because I am an irc noob >> and use the irc bridge on matrix.org to access irc rooms and didn't >> find a way to do it yet. Just so you know. > > I finally found out how to properly edit the topic via my matrix client > and just have added python-discogs-client to the RFS list :-) Uploaded. Thanks for your contribution to Debian. Cheers, Thomas Goirand (zigo)
Re: Should Binaries provided by python-babel have a "python3-" prefix?
On 11/27/20 1:13 PM, Simon McVittie wrote: > A good way to decide this is to think about what we would do if we had a > Python 4 that is incompatible with Python 3 (which I assume will happen > eventually, although hopefully not for a few years). It is very likely that you're wrongly guessing. Numerous times, the Python upstream people wrote that the py2 to py3 transition was a bad idea, and they will not do the same kind of mistake again, and that there probably wont be a Python 4 anytime. Which is why I thought merging the content of python3-babel and python3-babel-localedata would be a good idea. Cheers, Thomas Goirand (zigo)
Re: Should Binaries provided by python-babel have a "python3-" prefix?
On 11/26/20 1:16 PM, Nilesh Patra wrote: > Hi, > > Currently src:python-babel provides 3 binaries: > > * python3-babel > * python-babel-doc > * python-babel-localedata > > of which python3-babel is the main binary, -babel-doc is for the > documentation and -babel-localedata is for storing locale data files > used by python3-babel. > > Should this be renamed to a "python3-" prefix for both binaries? They do > not contain any actual code though > > BTW this also has a RC bug, and I pushed the fix to salsa. If it needs a > renaming, it'd be great if someone could upload it to NEW. > > If not, I'll do a source-only-upload. > Please let me know what you think of this. > > Kind regards > Nilesh Hi, It used to be that we had a python-babel that also needed the data in python-babel-localedata, which was shared by both the Python 2 and 3 packages. Now, we don't have it anymore. So probably, what could be done, is move all the files in python3-babel, and get rid of python-babel-localedata completely. python-babel-doc is still the correct package name for the doc (unless the amount of doc is small and could be integrated in python3-babel as well). If that's the way to go, then python3-babel needs a Breaks+Replaces: python-babel-localedata. Cheers, Thomas Goirand (zigo)
Re: Joining the team
On 11/23/20 10:10 PM, Sandro Tosi wrote: >>> First, an apology: it seems I misremembered being in the team, and uploaded >>> to >>> NEW a bunch of packages with the team in `Uploaders`. >> >> Please put the team as Maintainer, and yourself as Uploaders. > > why? that's not a requirement: > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#maintainership Because joining a team, putting packages in them, and enforcing strong ownership, is not logic at all. I know you like to do this way, but this shouldn't be what we advise for new comers. Cheers, Thomas Goirand (zigo)
Re: Joining the team
On 11/23/20 2:15 PM, nicoo wrote: > Hi everyone! > > First, an apology: it seems I misremembered being in the team, and uploaded to > NEW a bunch of packages with the team in `Uploaders`. Please put the team as Maintainer, and yourself as Uploaders. Cheers, Thomas Goirand (zigo)
Re: [Python-modules-team] Bug#954381: marked as done (python3-kubernetes: New upstream version available)
On 11/21/20 3:36 AM, Sandro Tosi wrote: >>* Use git to generate upstream tarball, as the PyPi module doesn't include >> the test folder. Using the gen-orig-xz in debian/rules, as using the >> repack function of debian/watch doesn't make sense (why downloading a >> tarball that would be later on discarded? I'm open to a better solution >> which would be uscan compatible though...). Switch d/watch to the github >> tag therefore. > > you can track the github project instead of pypi (man uscan has the > details); this is was i'm doing recently, as most of the time PyPI > releases dont have all the files we need (tests, or test data, or > documentation, or a combination of that) Hi. Thanks, I know that. However, that's not my problem. The issue is that uscan --download will download the tarball from github, and I'd like to replace that by what I'm doing in debian/rules, which is using git and git submodule, to fetch things using git, and create a tarball. Sure, I could use a repack script in debian/watch, but then uscan will continue to first download the archive from github, and *then* only, I can discard what's been downloaded, and fetch stuff from github with git. Is there a solution here, so that uscan uses a repack script directly without attempting to download first? Cheers, Thomas Goirand (zigo)
Re: Python 3.9 for bullseye
On 11/9/20 10:19 AM, Matthias Klose wrote: > https://bugs.debian.org/973239 src:python-fixtures Does anyone else than me think it's probably OK to just disable to 2 broken tests? Cheers, Thomas Goirand (zigo)
Re: "pytest" command is missing
On 11/4/20 9:27 PM, Novy, Ondrej wrote: > Hi, > > Antonio Terceiro píše v St 04. 11. 2020 v 14:01 -0300: >> Could you ellaborate? Maybe we should have a discussion in the Python >> team so that we implement consistent practices. For example, `gunicorn` >> and `pip` now point to their python3 versions, but you are saying that >> pytest will not do that, what maybe creates more confusion given Debian >> bullseye will not support any other Python. > > "pytest" in buster now points to python2 version of pytest and > "pytest-3" points to python3 version. To prevent confusion after upgrade > I want to keep one stable release with pytest cmd "unoccupied" and keep > pytest-3. > > Bullseye will support Python2 interpreter so user can keep python-pytest > package installed from buster. Moreover, simply invoking "pytest-3" is not enough, one should be using: for pyvers in $$(py3versions -vr 2>/dev/null) ; do \ python$$pyvers -m pytest ; \ done otherwise, only the default version of Python3 is tested, and we really want to test with all available versions (so we get results whenever we're transitioning to a new Python 3 version). Cheers, Thomas Goirand (zigo)
