FWIW … KiCAD users have been unable to use Fedora 43 because of an incompatibility with Python 3.14 (which Fedora 43 packages).
Good news … Python 3.14.1 was just released and it fixes the problem. Presumably the .rpm for Fedora 43 will be available in a few days.
Since F43 dropped Xorg, there remains the problems of running KiCAD with Wayland 
Thank you for posting this. Is there any way to know when the rpm for 3.14.1 will be available? Is there any standard timeline for release of stuff like this?
As a user of F43 and KiCad who has been greatly impacted by this I’ve been following the whole “python decided to play stack police” discussion that broke KiCad (I say that in jest even though that was the root cause of the problem, lest anyone take that the wrong way) and when I saw that the fix was released yesterday I’ve been trying to figure out when I would see it in F43 (or when I could pull it myself through official channels).
I tried patching the source RPM to use the 3.14.1 .xz source but got a bunch of errors when trying to build the RPM.
Missing expected provides:
- Provides: bundled(python3dist(certifi)) = 2025.10.5
- Provides: bundled(python3dist(msgpack)) = 1.1.2
- Provides: bundled(python3dist(platformdirs)) = 4.5
- Provides: bundled(python3dist(requests)) = 2.32.5
- Provides: bundled(python3dist(resolvelib)) = 1.2.1
- Provides: bundled(python3dist(rich)) = 14.2
- Provides: bundled(python3dist(tomli)) = 2.3
- Provides: bundled(python3dist(truststore)) = 0.10.4
I was able to just build the 3.14.1 source tree using the autotools build and it installed (by default) into /usr/local/bin.
When the RPM is released I will uninstall it.
Michael
Looks like it’s on the way ….
ksurma created the branch 3.14.1 on forks/ksurma/rpms/python3.14 10 hours ago |
Wow .. even Linus filed a bug! 2416523 – Python 3.14 Stack overflow check very very broken
He got a new computer … now he is searching the limits of it 
Yes and I agree with him 100% that it is a big deal when an OS upgrade breaks things without any warning and addressing the breakage isn’t treated as an urgent matter. And as I’m sure you are aware, the issue impacted several other tools besides KiCad.
And I still have philosophical issues with python doing stack checking it shouldn’t need to do (but that’s a whole different discussion ).
Regardless, my productivity will get a heck of a lot better when the rpm is available and (hopefully) I can use KiCad in F43…
To me it looks like he is using that software to design little electronic gadgets like the guitar effect splitter that he is showing in the video (https://youtu.be/mfv0V1SxbNA?t=678&si=Pz9fpVoQC-jaZom-, at minute 11:18)
Yes, or just the case for 3d printing.
by the way, if the bug reporter was using that kind of language in this here forum, he would be in trouble with the CoC police immediately.
This is really annoying. The flatpak kind of works if you run it with:
flatpak run --env=GDK_BACKEND=x11 org.kicad.KiCad
However, at least on my PC, this might work for a while, but suddenly some of the dialog fields become invisible or you don’t see the text you enter (the old text still visible), e.g. the PCB DRC tool results window. Could be a wxwidgets issue with Xwayland. The 3D view also freezes. And the mouse consistently, when it falls into a “fault” mode, jumps a certain offset when dragging or moving tracks or components. If I reboot the computer it often fixes the issues and it works again for a while.
I wonder what the big change from Fedora 42 is, because I also tried to run KiCad there under XWayland and I can’t remember seeing the same issues.
I had the exact same issues with the flatpak. It’s one of the major reasons I’m waiting for the 3.14.1 rpm. Haven’t seen anything since the branching Michael pointed out earlier in the thread. I’m trying very hard to resist the urge to deviate from official packages but this whole thing is extremely frustrating. It would be really nice to have at least a clue as to when we might see the rpm given that ALL KiCad users on F43 are hosed by this and are likely just as frustrated as we are.
Of course the 3.14.1 update may still result in F43 Wayland issues but with KiCad not even running it’s kinda hard to do anything about it at the moment. Like you, I didn’t have any issues with F42.
I tried with distrobox/podman, but I’m having the same issues with dialogs stuck and not updating. I tried running it with distrobox-enter -n f42 – bash -c ‘export GDK_BACKEND=x11 && kicad’, but it didn’t help.
Edit. After doing sudo dnf install xorg-x11-server-Xwayland @base-x inside the container it works. I don’t even have to add the environment variable. I’m a bit confused… Edit 2. No, it works better with the environment variable.
You can edit the desktop shortcuts in ~/.local/share/applications/f42-org.kicad.* and edit the “Exec” line:
Exec=/usr/bin/distrobox-enter --additional-flags “–env GDK_BACKEND=x11” -n f42 – kicad %f
The distrobox suggestion worked for me as well. Thanks for the info. Wish I had known about it a few weeks ago instead of just seeing “use the flatpak” everywhere.
Still want to see everything actually fixed in F43 but at least I’m able to work effectively again.
3.14.2 has been released to fix some regressions caused by 3.14.1 … .
Sounds like Python needed people in charge like Torvalds. I chuckled a bit when I read his criticism of the broken 3.14 release: 2416523 – Python 3.14 Stack overflow check very very broken At least his motto of “never break user space” could be more seriously taken in various other projects than just the kernel.
3.14.2 is in the testing repo now.
Update with: $ sudo dnf update --enablerepo=updates-testing python3
For anyone still following this thread, 3.14.2 is officially released now and can be had via normal dnf update (no need to point to testing repos). KiCad is much happier now and so far does not appear to have the occasional random issues the distrobox had.
I have a dual screen setup that, oddly, has a problem with kicad on one monitor (LHS)(https://youtu.be/NaAwqmRFg8w) but not the other (RHS)(https://youtu.be/Wmlkr1T_atQ).
The problem is correlated with a gnome extensions (any of them) updating the screen (like the analog clock with a sweeping second hand) while kicad makes a graphics update..
I presume this is a gnome shell issue. (no point in flagging this to kicad given their distain of Wayland users )
I had raised an issue with gnome shell and it seems that there is a fix to ‘mutter’ in the works that will address this.
I back ported this fix to mutter-49.2 RPM and it seems to have fixed the issue.