Closed evils closed 3 years ago
Hi @evils, I don't have/use mac but happy to answer any wxPython questions as I can
I'm experiencing the same issue with Linux, using nix-build '<nixpkgs>' -A python3Packages.wxPython_4_0
.
@matthuszagh likely a different issue. Stacktrace? What nixpkgs version / commit?
The latest master branch commit as of this writing. Here's the output I'm seeing.
It looks like pkg-config is giving an old version of GTK+?
@matthuszagh please use
<details>
<summary> save the scroll wheels </summary>
dump code block here
</details>
your failure seems the same as #86609
which i closed because it's fixed in the staging
branch by #86318
and i can confirm nix-build -A python3Packages.wxPython_4_0
at least starts building there (it's still going...)
i'm not sure when this fix will get to master
...
@evils nice! didn't know about the details tag. Ok yeah that looks like my issue, thanks for pointing me in that direction.
I can reproduce this on 10.14.6. My best take so far was to use wxmac
and adapt other Darwin requirements.
Unfortunately it does not build with the same errors as for the homebrew maintainers.
Bumped wxmac
to 3.0.5.1, added WebKit
to its buildInputs
, and it builds! --enable-webkit
was set, but no dependency specified. That's what caused the missing symbols.
I'm not even sure why this works at all. wxPython
claims they build wxWidgets
from a git
submodule, but obviously in this setup we take whatever is supplied through nix
.
To be pedantic, wxPython
4.0.7 is supposed use some specific commit instead of a release, as you can see here. That commit is after* 3.0.4 and shortly before 3.0.5. I only skimmed the diff, but it sounds and looks like backwards-compatible bug fixes. Opinions on how to proceed? If we follow upstream and choose the intermediate revision, what to specify as the package version?
i've kinda given up on wxWidgets
stuff, at least until the next wxPython
release which i hope will either be built based on a wxWidgets
release or be compatible with the latest release (i have no reason to believe this would be the case though)
Opinions on how to proceed?
if you have a diff that fixes a package, i recommend you make a PR
wxPython
4.0.7 seems to work with the wxWidgets
3.0.4, it seems reasonable to assume the same would be true for wxmac
3.0.4
Describe the bug wxPython_4_0, while accounting for darwin somewhat, does not build there likely because it uses wxGTK rather than wxmac this prevents kicad from being built on darwin
To Reproduce Steps to reproduce the behavior:
nix-build '<nixpkgs>' -A wxPython_4_0
Expected behavior wxPython_4_0 to build on darwin and be usable by kicad there
Additional context i maintain the kicad package and already tried pinging the principle contributor
Notify maintainers while there are no listed maintainers for this package it was initially contributed by @tbenst (if you already investigated after the kicad PR ping, nothing relevant changed since) and has a fair amount of contributions by @FRidh
Maintainer information: