On 12/12/21 06:21 PM, Scott Talbert wrote:
On Sun, 12 Dec 2021, Steven A. Falco wrote:
I also noticed that python3-wxpython4 appears to require the 3.0 branch, so that might be what is causing both 3.0 and 3.1 of wxGTK to be dragged in:
$ rpm -q --requires python3-wxpython4
...
libwx_baseu-3.0.so.0()(64bit)
...
Is there a version of python3-wxpython4 that uses 3.1? I really don't want both wxGTK versions in the build.
Yes, there is. However, the latest version bundles its own non-release copy of wxWidgets, and I don't believe it can be (easily) built unbundled with the current release of wxWidgets 3.1. So that's why I have been holding off packaging it. That, plus the 3.1.x variant of wxWidgets is a development release and not API/ABI stable. Perhaps it's worth reconsidering if there's a new release of wxPython that can use the latest released wxWidgets 3.1.x.
Thanks very much for the reply, Scott.
I'm not sure how critical it is to KiCad to make the switch, but I'll ask. I believe that the KiCad Mac, Windows, and Flatpack builds have already made the switch, but I don't know if the KiCad team make their own builds of wxWidgets / wxpython.
Do you have a feel for when the 3.1 branch might stabilize enough to create a Fedora package?
Steve
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
