The current stable kicad-6.0.9-r1 dropped support for python3_10 which is the current stable PYTHON_SINGLE_TARGET. The previous kicad-6.0.9 supported python3_10 and worked well using it in my case. The change happened in commit efdb96fba96c4cc3da3a877ed8676346e93ff28e. The bug linked in that commit makes no mention of python version incompatibilities. Neither the commit message nor the linked bug contains any reasoning for the change to PYTHON_COMPAT. Reproducible: Always Steps to Reproduce: 1. Use a stable profile with the currently recommended PYTHON_SINGLE_TARGET=python3_10 2. Attempt to emerge kicad Actual Results: The following REQUIRED_USE flag constraints are unsatisfied: python_single_target_python3_9 Expected Results: Successful install
I'm just going to put it back until we have a reason to not have it, given it causes a lot of disruption..
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fae9c9142e17af938bc46115b831f4f7c291cc94 commit fae9c9142e17af938bc46115b831f4f7c291cc94 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-04-22 11:36:44 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-04-22 11:36:44 +0000 sci-electronics/kicad: enable py3.10 for 6.0.x It's unclear why this was dropped, so let's put it back given it causes a lot of disruption. Really needs to be tested w/ 3.11 ASAP too. Closes: https://bugs.gentoo.org/904760 Signed-off-by: Sam James <sam@gentoo.org> sci-electronics/kicad/kicad-6.0.11.ebuild | 2 +- sci-electronics/kicad/kicad-6.0.9-r1.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
(In reply to Sam James from comment #1) > I'm just going to put it back until we have a reason to not have it, given > it causes a lot of disruption.. The reasoning is apparently buried in the PR notes for Bug 873124 which then created Bug 902205. If everything is true, the ultimate solution is either to fast track kicad 7 and wxPython 4.2 or else just figure out bug 902205. I don't have any true knowledge or time investment other than looking at bugs and the PR notes.
(In reply to Brian Evans from comment #3) > (In reply to Sam James from comment #1) > > I'm just going to put it back until we have a reason to not have it, given > > it causes a lot of disruption.. > > The reasoning is apparently buried in the PR notes for Bug 873124 which then > created Bug 902205. > > If everything is true, the ultimate solution is either to fast track kicad 7 > and wxPython 4.2 or else just figure out bug 902205. > > I don't have any true knowledge or time investment other than looking at > bugs and the PR notes. Thank you for digging that up! I think in light of that, the change still makes sense - ultimately wxpython has py3.10 in its compat, and the alternative is to drop it entirely. Plus it's worked mostly well enough until now. But agreed, should likely just fast track 7 now as a non-stopgap.
Sorry, I was out for the weekend. I dropped Py3.10 support for KiCad 6 series, because with Python 3.10 scripting is broken (i.e. try pulling up the scripting window, it will just print error messages). While not everyone uses scripting, this is a mayor bug that can only be fixed in wxpython-4.0.7 itself by backporting Py3.10 support (see bug 902205). wxpython-4.0.7 being marked as compatible with Py3.10 actually incorrect as the incompatibility has been there for quite some time (see bug 863494) and has never been resolved. On the other hand Kicad 6 series is incompatible with wxGTK 3.2 and wxpython-4.2.0, and resolving it would require significant backporting from KiCad 7 series, which in the light of availability of kicad-7.0.0, kicad-7.0.1 made no sense. There was also a stable request opened for 7.0.1 already (see bug 904671). I admit I could have done better commit messages though. Nonetheless this commit breaks KiCad 6 series again :(
