On 8/9/22 06:00 PM, Scott Talbert wrote:
On Tue, 9 Aug 2022, Steven A. Falco wrote:
On 8/9/22 05:06 PM, Scott Talbert wrote:
On Tue, 9 Aug 2022, Steven A. Falco wrote:
On 8/9/22 02:25 PM, Steven A. Falco wrote:
On 8/9/22 01:09 PM, Scott Talbert wrote:
Hi,
Upstream wxPython has finally made a new release and this involves migrating to wxWidgets 3.2.0 at the same time. I'm planning to build the new wxPython in Rawhide after F37 branch (although could put it in F37 later).
For those packages that use both wxPython and wxWidgets (I *think* this is just kicad?), do you want me to do this in a side-tag so we can switch the packages at the same time? Or just build in rawhide and let you fix things up?
That is very good news, Scott. The upstream KiCad devs are working on 3.2.0 right now, as part of their efforts to support the new M1 Apple machines.
If KiCad is the only customer, I'd say there is no need to do a side-tag, unless that is easier for you. I'm fine either way.
I should add that I would like to see this in F37 at some point, because that will help with retiring the old wxWidgets code from KiCad sooner.
Yeah, we can get the changes into F37.
So KiCad isn't quite ready to move yet? I can hold off until you're ready.
I've spoken with the upstream KiCad developers, and based on that conversation I think you should go ahead and put the new wxWidgets / wxPython into Rawhide when it is convenient for you, without waiting for KiCad.
There is a KiCad Copr [1], where we make nightly pre-release builds of what will become the KiCad 7.x series, with 7.0.0 probably releasing towards the end of the year. The KiCad 7 series is where the upstream devs prefer to integrate with the new wxWidgets / wxPython both because of the risk of new bugs and also so they don't have to backport fixes to the older KiCad 6.x series.
So, once you have the new wxWidgets / wxPython in Rawhide, I'll try it out locally and in our Copr. Based on how that goes, we can consider switching over the downstream Rawhide builds. But based on the way the timing has worked out, and because we don't want to do a major version upgrade of KiCad in a stable Fedora release, we may not be able to switch KiCad to the new wxWidgets / wxPython in F37.
The problem though, is that while wxWidgets versions are parallel installable, wxPython versions are not. So, once I update to wxPython 4.2.0 (which links with wxWidgets 3.2.0), wxPython 4.0.7 will be gone. I'm presuming that's going to break KiCad?
It is a bit awkward to be mediating between the Fedora devel list and the KiCad one, but I think we are nearly there. According to one of the KiCad leads:
"The Flatpak has been running the wx 3.1 branch since v6 was released, and so far there have been no issues. We already have Windows and macOS running the 3.1 versions, so I don't see why we need to hold the Linux builds back."
So, I think we are good to go forward and retire wxPython 4.0.7 at your convenience. If it is not too much trouble to use a side-tag, I'll make the KiCad build there and it can all go in together. My schedule is quite open, so I shouldn't hold you up.
Please let me know whenever you are ready. No rush. And thanks for your patience. :-)
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, report it: https://pagure.io/fedora-infrastructure/new_issue
