Re: Python 3.11 for bookworm?
Am Tue, Jan 17, 2023 at 01:04:50AM +0100 schrieb Thomas Goirand: > > > #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. Fixed in the sense that there was an upload closing the bug. If you look at https://tracker.debian.org/pkg/pandas https://tracker.debian.org/pkg/numba you see multiple blockers for a testing migration. So the problem for the release persists. I have confirmations of upstream of several rdepends of these packages that they do not support 3.11 since these two packages do not officially support Python 3.11 yet (the Debian packages are coming with several patches - just one example of an answer from upstream for python-cogent[1]) > > 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? No, I have not dealt with torch. I just know that this package is in the very competent hands of Mo Zhou who will know what to do. > 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. As I said above the packages above are far from testing. If someone could lend helping hands to let these packages migrate this would be really helpful. > > 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. I understand the advantages of Python 3.11 and I'm not against releasing Bookworm with it. I'm against overlong freezing periods which I see as the consequence of pushing Python 3.11 while sticking to the current freeze shedule. If we would decide that Python 3.11 is really important I would consider shifting the testing period by one or two months. We have just seen that every full rebuild of the archive as Lucas recently did creates quite some new RC bugs that are related to the Python version bump and I expect more of these at the next rebuild. > > > 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. Since you said above that we want to release with 3.11 only this becomes clear. Luckily the teams where I'm working in have also quite good autopkgtest coverage so I'm positive about sensible warnings. > > 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...). We are just a couple of people who are fighting hard through scientific packages with a complex depency tree. Some of them (like numba) take ages to build even on amd64 (salsa CI is set to 6h here) and thus take quite some time to fix. As I said above I'm not against Python 3.11 per see. I'm simply afraid that this decision will delay the release process and IMHO it makes sense to shift the schedule if we decide that Python 3.11 is something we want. Kind regards Andreas. [1] https://github.com/cogent3/cogent3/issues/1263 -- http://fam-tille.de
Re: How to create multi-source tarball with different submodules for scipy
On Mon, 2023-01-16 at 17:05 +0100, Andreas Tille wrote: > I intended to merge all these submodules in a single > scipy_1.10.0.orig-submodules.tar.gz. Any reason not to use one tarball per submodule? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
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: RFS: mercurial-evolve
Hi, I just made a new version of the mercurial-evolve package, following the new upstream 10.5.3. It's still at https://salsa.debian.org/python-team/packages/mercurial-evolve. Andrej, would you be so kind to take a look at it, I hope the package can make it before the freeze. On the technical side, this new upsteam version provides compatibility with Mercurial 6.3 (which I see has come up since last attempt) and Python 3.11, according to the changelog, I didn't follow details myself. I believe I had formerly addressed the ftpmaster reservations about the copyright statements, but feel free to tell me if there is something else to be done. Best, On 9/7/22 09:12, Andrej Shadura wrote: Hi, On Tue, 6 Sep 2022, at 14:53, Andrej Shadura wrote: On Tue, 6 Sep 2022, at 14:45, Georges Racinet wrote: I'm looking for a sponsor for my package "mercurial-evolve". (Cc-ing DDs I've spoken about it in the past) Cool. I'm a little bit busy right now packing for the trip, but I will have a look at it a bit later this afternoon. I’ve made some changes and uploaded evolve to NEW. In one commit I made a "typo" and wrote a wrong word: "Drop unnecessary variable names". What I meant was, of course, "variables" :) Anyway, DH_VERBOSE=1 is better set by the maintainer rather than directly in debian/rules, as it’s a bit too verbose, and this package is not too tricky to require it at all times. I can’t remember right now how exactly PYBUILD_NAME works, but I don’t think you were using it correctly here, and it didn’t make any visible difference anyway (likely because there’s only one binary package), so I dropped it. Other than that, the rest of the commits are minor nitpicks and are, hopefully, self-descriptive. Thanks, you did a good job on your first Debian package :) -- Georges Racinet https://octobus.net, https://about.heptapod.host, https://heptapod.net GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics OpenPGP_signature Description: OpenPGP digital signature
Re: How to create multi-source tarball with different submodules for scipy
On Mon, Jan 16, 2023 at 05:05:39PM +0100, Andreas Tille wrote: > Hi, > > I tried to create a multi-source tarball for scipy in its experimental > branch[1]. Upstream includes a set of git submodules in its build > process. I intended to merge all these submodules in a single > scipy_1.10.0.orig-submodules.tar.gz. This tarball is created with a > script[2] which makes sure that the exact directory structure as it is > used by upstream is conserved. This directory layout is needed in the > build process. Unfortunately `dpkg-source -x` extracts the content of > the submodules tarball into a subdirectory submodules/. > > Is there any trick to unpack this tarball right into the root? > Otherwise I need to do some symlinks workaround in d/rules to provide > all files where these are needed. Not that I know of; this is the design of the multi-source tarball setup: each component tarball is extracted into a directory with the name of the component. Best wishes, Julian
Re: Python 3.11 for bookworm?
Am Sat, Jan 07, 2023 at 09:05:21AM +0100 schrieb Andreas Tille: > Hi Thomas, > > Am Thu, Jan 05, 2023 at 01:57:43PM +0100 schrieb Thomas Goirand: > > > > This has since already been discussed here: the final decision was to "at > > least try 3.11", which is exactly what we're doing. > > I admit I was not at site and may be I missunderstood what was finally > decided. From my perspective this "at least try" is that we are > actually trying by having 3.11 as additional supported version which has > triggered quite some work. We are approaching the Transition and > Toolchain Freeze in 5 days[1]. Given that switching default Python is a > transition I wonder how you can assume that this is the right time to > suggest this. I would not have been that astonished if you would have > done so say at first December last year. But now its absolutely clear > that a migration (with the "option" to revert which will cause extra > work) will pour sand into the gears of the release process. How will we decide whether the "at least try 3.11" is success or fail? Did we defined anything I might have missed in terms of number of packages that need to pass or number of packages we shoule not loose? > > 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): > > That's a nice situation for the field you are working in. > > > > 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'd like to add #1027851 [src:pytorch] FTBFS with Python 3.11 as default version also with lots of rdepends. > These packages have a sufficient amount of rdepends and usually trigger > lots of other autopkgtest failures in other packages which will keep > them out of testing for quite some time. We could need all helping > hands to fix these ... all noise that will happen afterwards will keep > the relevant teams busy enough. I did not received any response to my "small" list. What does this mean for the transition to 3.11 process? > > > 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? > > > 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. > > I can understand that we can never satisfy the needs of everybody. My > main problem is the extremely unfortunate timing that is happening now. > > > 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. > > I do not remember that the scchedule was discussed. > >* Add 3.11 as a supported Python3 version > > was done in python3-defaults (3.10.6-2) at Fri, 11 Nov 2022 11:10:31 > +0200. At 12. December Graham suggested on the behalf of the release > team[2] to switch to 3.11. If we would have acted upon this at that > very time I would have considered this quite dense but the last chance > to consider this in line with the "lets try" attempt discussed at > DebConf. > > 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. Kind regards Andreas. > > [1] https://release.debian.org/testing/freeze_policy.html > [2] https://lists.debian.org/debian-python/2022/12/msg00074.html > [3] https://release.debian.org/transitions/html/python3.11-default.html > > -- > http://fam-tille.de > > -- http://fam-tille.de
How to create multi-source tarball with different submodules for scipy
Hi, I tried to create a multi-source tarball for scipy in its experimental branch[1]. Upstream includes a set of git submodules in its build process. I intended to merge all these submodules in a single scipy_1.10.0.orig-submodules.tar.gz. This tarball is created with a script[2] which makes sure that the exact directory structure as it is used by upstream is conserved. This directory layout is needed in the build process. Unfortunately `dpkg-source -x` extracts the content of the submodules tarball into a subdirectory submodules/. Is there any trick to unpack this tarball right into the root? Otherwise I need to do some symlinks workaround in d/rules to provide all files where these are needed. Kind regards Andreas. [1] https://salsa.debian.org/python-team/packages/scipy/-/tree/experimental [2] https://salsa.debian.org/python-team/packages/scipy/-/blob/experimental/debian/get-submodules -- http://fam-tille.de
Bug#1029009: RFP: accessible-pygments -- accessible themes for pygments
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org, Piotr Ożarowski * Package name: accessible-pygments Version : 0.0.2 Upstream Contact: Tania Allard * URL : https://github.com/Quansight-Labs/accessible-pygments * License : BSD Programming Lang: Python Description : accessible themes for pygments This package includes a collection of accessible themes for pygments based on different sources. This package augments python3-pygments by providing themes supporting accessibility. It is required by the latest version of pydata-sphinx-theme, for which it provides high contrast light-dark themes. Could be maintained by the Debian Python Team, or Piotr Ożarowski (python3-pygments maintainer) would be welcome to package it alongside pygments.
