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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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 on the list, report it:
https://pagure.io/fedora-infrastructure
