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@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, report it:
https://pagure.io/fedora-infrastructure/new_issue
