Hello,
To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated rebuild in a side tag.
https://fedoraproject.org/wiki/Changes/Python3.13
Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024. We hope to start the mass rebuild shortly after it's available.
TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.13.
Details: If you see a "Rebuilt for Python 3.13" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate.
If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via:
on branch rawhide: $ fedpkg build --target=f41-python $ koji wait-repo f41-python --build <nvr>
It takes time to build all the essential packages, so don't expect all your dependencies to be available right away. Any attempts to build your packages in the side tag before we do will likely fail due to missing dependencies.
When in trouble, ask here or on Fedora's Matrix - Fedora Python room (https://matrix.to/#/#python:fedoraproject.org) Ping me (ksurma) or Miro (mhroncok) if you need to talk to us.
Builds will appear here: https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f41-python&...
Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over.
Thanks! Karolina
Hi there,
Karolina Surma venit, vidit, dixit 2024-05-31 10:55:16:
Hello,
To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated rebuild in a side tag.
https://fedoraproject.org/wiki/Changes/Python3.13
Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024. We hope to start the mass rebuild shortly after it's available.
I'm somewhat confused by the two different coprs
@python/python3.13-b1 @python/python3.13
What is the role of which?
I have a package (notmuch) which succeeds locally in mock (against python 3.13) and in @python/python3.13 but fails in @python/python3.13-b1. The failure is probably related to gdb (the python module) usage in a test.
@python/python3.13-b1 was used as a basis for bugzilla, it appears. (The bz entry points to instructions which are not filled in, btw.)
Cheers Michael
Hi,
On 6/6/24 12:41, Michael J Gruber wrote:
Hi there, I'm somewhat confused by the two different coprs
@python/python3.13-b1 @python/python3.13
What is the role of which?
@python/python3.13 is the main copr used for the continuous Python rebuild since alpha1 and a testing bed for the package maintainers. As its environment rapidly changes, sometimes the obsolete package versions are pulled into the buildroot.
In order to simulate the current Fedora environment as close as possible, last week we created a python3.13-b1 copr - a testing repository to bootstrap Python (again) from scratch and make sure we haven't omitted something by accident.
I have a package (notmuch) which succeeds locally in mock (against python 3.13) and in @python/python3.13 but fails in @python/python3.13-b1. The failure is probably related to gdb (the python module) usage in a test.
My guess is the "main" copr was still using some older package builds, while the python3.13-b1 only contains the newest versions and that exposed the issue in notmuch. We're currently rebuilding everything with Python 3.13.0~beta2 in the main copr and will know in a few hours whether notmuch is still affected.
@python/python3.13-b1 was used as a basis for bugzilla, it appears. (The bz entry points to instructions which are not filled in, btw.)
Apologies for the inconsistent instructions, that's an oversight.
Cheers, Karolina
Karolina Surma venit, vidit, dixit 2024-06-06 14:17:10:
Hi,
On 6/6/24 12:41, Michael J Gruber wrote:
Hi there, I'm somewhat confused by the two different coprs
@python/python3.13-b1 @python/python3.13
What is the role of which?
@python/python3.13 is the main copr used for the continuous Python rebuild since alpha1 and a testing bed for the package maintainers. As its environment rapidly changes, sometimes the obsolete package versions are pulled into the buildroot.
In order to simulate the current Fedora environment as close as possible, last week we created a python3.13-b1 copr - a testing repository to bootstrap Python (again) from scratch and make sure we haven't omitted something by accident.
I have a package (notmuch) which succeeds locally in mock (against python 3.13) and in @python/python3.13 but fails in @python/python3.13-b1. The failure is probably related to gdb (the python module) usage in a test.
My guess is the "main" copr was still using some older package builds, while the python3.13-b1 only contains the newest versions and that exposed the issue in notmuch. We're currently rebuilding everything with Python 3.13.0~beta2 in the main copr and will know in a few hours whether notmuch is still affected.
@python/python3.13-b1 was used as a basis for bugzilla, it appears. (The bz entry points to instructions which are not filled in, btw.)
Apologies for the inconsistent instructions, that's an oversight.
Thanks for the clarification, and no need to apologize :)
BTW: With current @python/python3.13-b1, the problem seems to be scripting gdb:
``` /etc/gdbinit:9: Error in sourced command file: Scripting in the "Python" language is not supported in this copy of GDB. /builddir/build/BUILD/notmuch-0.38.3-build/notmuch-0.38.3/test/atomicity.py:11: Error in sourced command file: Undefined command: "import". Try "help". ```
This is from mock --shell. (notmuch's test suite makes it hard to spot these things the easy way.)
So, let's hope gdb with py 3.13.0~beta2 will fix scripting.
Michael
On 06. 06. 24 16:03, Michael J Gruber wrote:
Karolina Surma venit, vidit, dixit 2024-06-06 14:17:10:
Hi,
On 6/6/24 12:41, Michael J Gruber wrote:
Hi there, I'm somewhat confused by the two different coprs
@python/python3.13-b1 @python/python3.13
What is the role of which?
@python/python3.13 is the main copr used for the continuous Python rebuild since alpha1 and a testing bed for the package maintainers. As its environment rapidly changes, sometimes the obsolete package versions are pulled into the buildroot.
In order to simulate the current Fedora environment as close as possible, last week we created a python3.13-b1 copr - a testing repository to bootstrap Python (again) from scratch and make sure we haven't omitted something by accident.
I have a package (notmuch) which succeeds locally in mock (against python 3.13) and in @python/python3.13 but fails in @python/python3.13-b1. The failure is probably related to gdb (the python module) usage in a test.
My guess is the "main" copr was still using some older package builds, while the python3.13-b1 only contains the newest versions and that exposed the issue in notmuch. We're currently rebuilding everything with Python 3.13.0~beta2 in the main copr and will know in a few hours whether notmuch is still affected.
@python/python3.13-b1 was used as a basis for bugzilla, it appears. (The bz entry points to instructions which are not filled in, btw.)
Apologies for the inconsistent instructions, that's an oversight.
Thanks for the clarification, and no need to apologize :)
BTW: With current @python/python3.13-b1, the problem seems to be scripting gdb:
/etc/gdbinit:9: Error in sourced command file: Scripting in the "Python" language is not supported in this copy of GDB. /builddir/build/BUILD/notmuch-0.38.3-build/notmuch-0.38.3/test/atomicity.py:11: Error in sourced command file: Undefined command: "import". Try "help".This is from mock --shell. (notmuch's test suite makes it hard to spot these things the easy way.)
So, let's hope gdb with py 3.13.0~beta2 will fix scripting.
gdb is built twice in the rebuild. The first build is without_python. notmuch probably needs the second build, but there is no way to express that via RPM BuildRequires (unless gdb starts providing something like gdb(python)).
On 6/6/24 9:21 AM, Miro Hrončok wrote:
So, let's hope gdb with py 3.13.0~beta2 will fix scripting.
gdb is built twice in the rebuild. The first build is without_python. notmuch probably needs the second build, but there is no way to express that via RPM BuildRequires (unless gdb starts providing something like gdb(python)).
If you don't need python scripting, there is the gdb-minimal package.
Keith
Hello,
We have just started the Python 3.13 mass rebuild in the side tag for Fedora 41 with Python 3.13.0b2.
Please, follow the original instructions when planning to build your Python packages. We'll let you know when we'll plan to merge the side tag.
And... keep your fingers crossed :) Karolina
On 5/31/24 10:55, Karolina Surma wrote:
Hello,
To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated rebuild in a side tag.
https://fedoraproject.org/wiki/Changes/Python3.13
Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024. We hope to start the mass rebuild shortly after it's available.
TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.13.
Details: If you see a "Rebuilt for Python 3.13" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate.
If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via:
on branch rawhide: $ fedpkg build --target=f41-python $ koji wait-repo f41-python --build <nvr>
It takes time to build all the essential packages, so don't expect all your dependencies to be available right away. Any attempts to build your packages in the side tag before we do will likely fail due to missing dependencies.
When in trouble, ask here or on Fedora's Matrix - Fedora Python room (https://matrix.to/#/#python:fedoraproject.org) Ping me (ksurma) or Miro (mhroncok) if you need to talk to us.
Builds will appear here: https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f41-python&...
Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over.
Thanks! Karolina
On Fri, Jun 07, 2024 at 08:48:03AM +0200, Karolina Surma wrote:
Hello,
We have just started the Python 3.13 mass rebuild in the side tag for Fedora 41 with Python 3.13.0b2.
Please, follow the original instructions when planning to build your Python packages. We'll let you know when we'll plan to merge the side tag.
If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via:
on branch rawhide: $ fedpkg build --target=f41-python
I built rust-add-determinism-0.2.0-11.fc41 in the side tag. It drops the dependency on python3-libs and marshalparser and provides an internal reimplementation of marshalparser. Subsequent builds of python packages should have the pyc handler active.
I sincerely hope this doesn't interrupt the rebuild in any way!
Zbyszek
On 5/31/24 01:55, Karolina Surma wrote:
Hello,
To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated rebuild in a side tag.
https://fedoraproject.org/wiki/Changes/Python3.13
Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024. We hope to start the mass rebuild shortly after it's available.
TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.13.
Details: If you see a "Rebuilt for Python 3.13" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate.
If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via:
on branch rawhide: $ fedpkg build --target=f41-python $ koji wait-repo f41-python --build <nvr>
I'm in the middle of updating the LLVM packages in my own side tag, would it work if I tag python3.13.0b2 into my LLVM side-tag and rebuild the LLVM packages there?
-Tom
It takes time to build all the essential packages, so don't expect all your dependencies to be available right away. Any attempts to build your packages in the side tag before we do will likely fail due to missing dependencies.
When in trouble, ask here or on Fedora's Matrix - Fedora Python room (https://matrix.to/#/#python:fedoraproject.org) Ping me (ksurma) or Miro (mhroncok) if you need to talk to us.
Builds will appear here: https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f41-python&...
Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over.
Thanks! Karolina -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 10. 06. 24 15:07, Tom Stellard wrote:
On 5/31/24 01:55, Karolina Surma wrote:
Hello,
To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated rebuild in a side tag.
https://fedoraproject.org/wiki/Changes/Python3.13
Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024. We hope to start the mass rebuild shortly after it's available.
TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.13.
Details: If you see a "Rebuilt for Python 3.13" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate.
If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via:
on branch rawhide: $ fedpkg build --target=f41-python $ koji wait-repo f41-python --build <nvr>
I'm in the middle of updating the LLVM packages in my own side tag, would it work if I tag python3.13.0b2 into my LLVM side-tag and rebuild the LLVM packages there?
It works if you merge your side tag later than ours. If you merge it sooner, it breaks the world unless you untag python first (which would presumably break the Python packages built in your side tag).
On 6/10/24 06:12, Miro Hrončok wrote:
On 10. 06. 24 15:07, Tom Stellard wrote:
On 5/31/24 01:55, Karolina Surma wrote:
Hello,
To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated rebuild in a side tag.
https://fedoraproject.org/wiki/Changes/Python3.13
Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024. We hope to start the mass rebuild shortly after it's available.
TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.13.
Details: If you see a "Rebuilt for Python 3.13" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate.
If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via:
on branch rawhide: $ fedpkg build --target=f41-python $ koji wait-repo f41-python --build <nvr>
I'm in the middle of updating the LLVM packages in my own side tag, would it work if I tag python3.13.0b2 into my LLVM side-tag and rebuild the LLVM packages there?
It works if you merge your side tag later than ours. If you merge it sooner, it breaks the world unless you untag python first (which would presumably break the Python packages built in your side tag).
OK, I will tag python3.13.0b2 into the LLVM side-tag, build the rest of the LLVM packages there, then I will untag python3.13.0b2 to be extra safe and also wait to merge the LLVM side-tag until after the python side-tag is merged.
-Tom
On 6/10/24 06:27, Tom Stellard wrote:
On 6/10/24 06:12, Miro Hrončok wrote:
On 10. 06. 24 15:07, Tom Stellard wrote:
On 5/31/24 01:55, Karolina Surma wrote:
Hello,
To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated rebuild in a side tag.
https://fedoraproject.org/wiki/Changes/Python3.13
Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024. We hope to start the mass rebuild shortly after it's available.
TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.13.
Details: If you see a "Rebuilt for Python 3.13" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate.
If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via:
on branch rawhide: $ fedpkg build --target=f41-python $ koji wait-repo f41-python --build <nvr>
I'm in the middle of updating the LLVM packages in my own side tag, would it work if I tag python3.13.0b2 into my LLVM side-tag and rebuild the LLVM packages there?
It works if you merge your side tag later than ours. If you merge it sooner, it breaks the world unless you untag python first (which would presumably break the Python packages built in your side tag).
OK, I will tag python3.13.0b2 into the LLVM side-tag, build the rest of the LLVM packages there, then I will untag python3.13.0b2 to be extra safe and also wait to merge the LLVM side-tag until after the python side-tag is merged.
I just tried this and it didn't work, because the rest of the python packages in the buildroot required the 3.12 abi, so 3.13 wasn't able to be installed. I think the only way to fix this would be using tag-inheritance of the python3 tag from the LLVM tag. It sounds like the python3 rebuild is almost done, so I 'might just wait.
-Tom
-Tom
-
Karolina Surma -
Keith Seitz -
Michael J Gruber -
Miro Hrončok -
Tom Stellard -
Zbigniew Jędrzejewski-Szmek