-
-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
w3m 0.5.3-38 #65291
w3m 0.5.3-38 #65291
Conversation
To my knowledge, it’s a MIT license. |
Formula/w3m.rb
Outdated
url :stable | ||
regex(%r{url=.*?/w3m[._-]v?(\d+(?:\.\d+)+)\.t}i) | ||
regex(%r{url=.*?/w3m[._-]v?(\d+(?:\.\d+)+)\.orig.t}i) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not too familiar with the suggestions thing, but this should be:
url "https://deb.debian.org/debian/pool/main/w/w3m/"
regex(/href=.*?w3m[._-]v?(\d+(?:\.\d+)+)\.orig\.t/i)
This ensures 0.5.3
is still reported as the version found by livecheck.
@fxcoudert -- you might want to try rebottling |
If the linkage test and the tests worked fine, why would we rebottle nmh? |
Just so we can get a big_sur native bottle for nmh so we can get it off of the #65000 list. It didn't happen duing the mass-rebottling, but that was possibly due to the w3m dependency, since it builds from source fine for me. |
I can dispatch a Big Sur bottle build without revision bumping, just ping me when you see a formula that should build. |
Is there a particular place that is best to ping you at? My rebottling wishlist is getting long. |
Any issue, here is fine :) |
Here are some entries from your #65000 list that either have had dependencies resolved OR I couldn't find out what had failed when I ran them manually. Some of them I've pinged people on other PRs as noted by the links:
I don't know if all of them will bottle for Big Sur now but I bet some of them will. |
@mitchblank I've queued bottles for all of those listed above, the failures should be linked here below |
❌ @fxcoudert bottle request for launchdns failed. |
❌ @fxcoudert bottle request for lemon failed. |
❌ @fxcoudert bottle request for amap failed. |
❌ @fxcoudert bottle request for get-flash-videos failed. |
❌ @fxcoudert bottle request for oq failed. |
❌ @fxcoudert bottle request for mingw-w64 failed. |
Well it looks like we got 12 successes and 6 failures.
@fxcoudert -- since |
Sure enough, when this was updated from 1.0.3 -> 1.0.4 the However I don't know how to resolve the problem now. If I remove the |
Opened #67584 to fix download url (although the formula may have other long-term issues, as described) |
This failed to bottle because of a /usr/local/Cellar path ending up in a binary which I guess is a no-no somehow?
I don't fully understand what it is complaining about though. |
❌ @dtrodrigues bottle request for neko failed. |
❌ @dtrodrigues bottle request for odin failed. |
❌ @dtrodrigues bottle request for pg_top failed. |
❌ @dtrodrigues bottle request for po4a failed. |
boost-python compiled OK on ARM, but
|
❌ @dtrodrigues bottle request for speech-tools failed. |
❌ @dtrodrigues bottle request for spidermonkey failed. |
❌ @dtrodrigues bottle request for rethinkdb failed. |
❌ @dtrodrigues bottle request for tarantool failed. |
❌ @dtrodrigues bottle request for zpaq failed. |
Failed due to autoconf being too old I guess:
Normally this is easy to fix just by rerunning autotools. A bit more complicated in this case since we have existing patches that mess with EDIT: opened #71712 to try that |
❌ @dtrodrigues bottle request for jack failed. |
Not clear if it's just an autoconf-too-old issue there or if the package itself doesn't support ARM currently. |
❌ @dtrodrigues bottle request for ponyc failed. |
Looks like we have a sha256 mismatch to track down there...
|
EDIT: sorry, other way around. neko is forcing Looking near the top of https://github.com/HaxeFoundation/neko/blob/master/CMakeLists.txt :
... so that's not really a great sign. EDIT2: filed HaxeFoundation/neko#221 upstream |
Looks like this one is fixed upstream: odin-lang/Odin@776c3f4#diff-1f0034637c3196a3296a2a9673068256f899131064f94daad4623dd1506d5b90 But not clear if it's fully done yet since there is still an open PR for arm support: odin-lang/Odin#738 |
Looks like we need to add a re-run of autoconf here:
|
Something failed to build in some perl module on ARM, unfortunately not clear what from the CI output:
|
Looks like upstream doesn't support arm64 yet?
That file doesn't exist in the upstream git yet, either. |
Looks like some assumptions about compiler flags are baked into its configure script:
Note that we build against a pretty old version of spidermonkey for dependency purposes so patching will probably be required to make this ARM buildable, if that is practical at all. |
Looks like their patched version of v8 is too old to build on OS/X-plus-ARM:
Seems to be something under active development so hopefully there will be an upstream release addressing it sooner or later. |
Seems to possibly be a known issue with some bundled 3rd party code that is conditionally enabled? tarantool/tarantool#5684 |
This one is weird, on ARM it built OK but the unit test failed with
One guess is possibly we need to compile with
EDIT: opened #71704 |
Looks like it's more CPU specific than I would have guessed:
We are a version behind on that formula and @fxcoudert has already looked into it (but the PR went stale) #69123 |
Looks like just lack of upstream support. |
@fxcoudert -- could you try another 11-Intel rebottle on EDIT: thanks, it worked. Now we have both |
Debian has become upstream, really.