[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: