Am 2018-11-18 11:18, schrieb Carsten Schoenert:
Hello Seth,
Am 17.11.18 um 05:34 schrieb Seth Hillbrand:
Hi Julien-
Am 2018-11-16 22:37, schrieb Julien Goodwin:
It looks to me like the python-wxgtk and wxwidgets versioning is
orthogonal, it's just chance they happen to be similar.
I did try doing a rebuild of the python-wxgtk source package (on my
affected machine) to see if that would help, and it's the same
behaviour.
One thing I forgot to mention, this also affected the last build of
5.0,
before 5.0.1.
My apologies for the hasty response the first time. I gave a poor
response.
python-wxgtk3.0=3.0.2.0+dfsg-7 and higher are compiled against gtk3.0.
This conflicts with the GTK2.0 versions of wxgtk3.0 that KiCad 5 is
compiled against. The latest version that can be used is
python-wxgtk3.0=3.0.2.0+dfsg-6. You will need to downgrade this
package.
now I'm really confused.
I added a versioned dependency on python-wxgtk3.0 >= 3.0.2.0+dfsg-7~ to
the kicad package on Apr 8 2018 in preparation for
5.0.0_rc1+dfsg1+20180318-3.
That will be required for KiCad 5.1 as soon as the package works
reliably with GTK3. As long as we are using the wxgtk3.0 built against
GTK2, we need to maintain the python-wxgtk that is also built against
GTK2. On Buster, this does not exist, so we will need to disable
scripting for Buster until KiCad 5.1 is released.
The maintainers of the wxWidget related packages don't build a GTK2+
version of python-wxgtk3.0 package in Debian testing anymore. And this
will not change for the Buster release. So we need to deal with this.
This whole wx stuff and the relations between the various packages is
getting more and more worse in my eyes.
I agree. The decision to change python-wxgtk3.0 from GTK2 to GTK3 but
keep the same package name was a poor one. At a minimum, I wish that
they would have changed the name as the functionality is definitely not
equivalent.
-Seth
