On Tue, 9 Aug 2022, Steven A. Falco wrote:
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. :-)
OK, I pushed wxPython 4.2.0 to Rawhide (now F38) and am building in side
tag f38-build-side-56468. It's still building at the moment.
Also, I sent you a pull request to rebuild kicad with wxWidgets 3.2.0 and
wxPython 4.2.0. I was able to rebuild it in a copr successfully with
these changes.
Thanks,
Scott
_______________________________________________
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
