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 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 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 Thu, Dec 15, 2022 at 04:08:29PM +0100, Thomas Goirand wrote: > 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. I forgot to reply here, but I uploaded fixed nose on Tuesday: https://tracker.debian.org/news/1398350/accepted-nose-137-9-source-into-unstable/ -- Dmitry Shachnev signature.asc Description: PGP signature
Updating khal to fix RC bug #1023341
Hello, I tried to update khal to block the autoremoval from testing (due #1023341) but it's not clear to me how to import metadata used to parse the package version with uscan¹ during repack of the tarball. PKG-INFO and the egg.info directory are on salsa¹ upstream branch but I'm not able to see them in the upstream tarballs (I looked also the commit on salsa with hash ba53a6bfb845ab4df3d5298f91f323b070084f4b): also PKG-INFO in the root of the repository is a news to me. How can I put them in the repacked tarball? In d/watch is indicated that for update the classic uscan invocation (through gbp) is used. The only way I can think of is to manually repack (AFAIK uscan doesn't support adding files before the invocation of mk-origtargz)... but it not seems that this was the procedure used according documentation on d/watch. AFAIU this mechanism was introduced to fix #1002406.³ Jonas do you have the time to explain? Many thanks, ¹ I know that it's easy to generate them with python3 setup.py egg_info ² https://salsa.debian.org/python-team/packages/khal ³ I don't know if it's worth to extend python3-setuptools-scm to support version schema we use in Debian, it seems not to hard, we could abuse of https://github.com/pypa/setuptools_scm#adding-a-new-scm P.S. Jonas I don't know if you are subscribed to this list, so I'm adding you to CC. -- Daniele Tricoli https://mornie.org OpenPGP_0x8BAF522C0D6CCEDD.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
