2.3.1 not working on my OSX 10.11.6 (15G1611) #1075
Comments
|
@Cpuroast we have reports of this in the forum too. Did you notice anything in your systems? |
|
@grillp Could you do this? https://sabnzbd.org/wiki/faq#freshstart And then start SABnzbd via the terminal, like this: What is the whole output? Is |
|
Tried without th reset and got this:
Will try with reset later. The illegal hardware instruction looks weird.. |
|
The Thats the IP address of my VPN TUN interface. so strange, but the same thing shows up in 2.2.0 which works fine. Here is the same startup log using 2.2.0:
And that also has |
|
Tried the reset as mentioned above. Ran
So no go. |
|
I have also tried re-downloading the the I just DLed |
|
2.3.1 launches perfectly in my 10.11.6 VM, obviously with a fresh ini file. Did you try just running 2.3.1 with a fresh ini file without any special command? Shutdown Sab |
|
I just retested with a fresh copy of 2.3.1 on my 10.11 VM running: System Version: OS X 10.11.6 (15G17023) This is the same as grillp's version and it launches perfectly. |
|
I am reading online that it is something python specific. Found some stuff about retina and non retina machines, weird things. |
|
We have some retina boxes at work, I can give it a whirl and see. 2.3.1 is when Python 2.7.14 landed. 2.3.0 and 2.2.0 used Python 2.7.13. |
|
@Cpuroast, I did try '2.3.1' with a clean ini and just dbl clicked the icon. Same deal. Didn't work. My spec is an old 2007 24' iMac which is still alive. (Amazingly!!) But upgraded with SSD and max mem, and perfect for background stuff like Sab. So non Retina machine. Also the reason I can't upgradefrom El Captain to High Sierra. And again, '2.3.0' works fine. Maybe I'll stick with '2.3.0' and see when a new version comes out as it seems like "it's me, not you"? |
|
@grillp, it's not you :/ Could you possible try these 2 different builds? They are just experiments to see where to start from: |
|
If I run the )OSX10.12 version I get:
So does not start at all. I am waiting for the second build to complete. |
|
Now testing on a Late 2013 non-retina iMac running 10.11.6 with the same build number as grillp. The "OSX10.12" build obviously doesn't run on 10.11 as the "xcode9.1" image doesn't contain the SDK for 10.11. The latest stable 2.3.1 version runs just fine as it did in my 10,11 VM. As far as travis goes: xcode6.4 is for 10.9 and up |
|
I also just tried with the the real Got this:
Waiting for the https://github.com/sabnzbd/sabbuild/releases/tag/OSX10.11-2 build now to try that out. |
|
It all boils down to the fact that your mac is too old. |
|
Nooo! Say it ain't so! ;-) Shame cause it works well as that work horse. Seems strange that it happened between 2.3.0 and 2.3.1. I assume that the XCode version between the build/packaging updated the python version from 2.7.13 to 2.7.14? Is there a way to tie it back to the previous version? i.e. downgrade XCode/Python? Or is this something I would have to try and do myself? Otherwise it looks like I will be stuck at 2.3.0 for a while to come then! Thanks for looking into it! |
|
The build environment which built 2.3.0, 2.3.1 and 2.3.2RC1 didn't actually change, which is why it still runs on my 10.9 VM. 2.3.0 has Python 2.7.13 while 2.3.1 and up have Python 2.7.14, so it could be something in Python 2.7.14. Starting with 2.3.0, I have been personally testing Sab on 10.9, 10.10, 10.11, 10.13 in VMs and on 10.12 on the host running those VMs which is a mid-2012 MacBook Pro running 10.12, to make sure builds run on all OSes and so far they have been working flawlessly at least on this 2012 CPU. Maybe there's a way to make the build environment even more restrictive in terms of CPU features when building. |
|
IC. So where does the python version change come into it? from 2.7.13 to 2.7.14? It's not like I change my python between installs of SAB?
So it seems anything running/built with 2.7.14 fails on my machine. I assume the python version is build into the App package? Is that part of the XCode build chain? or what ever version the build server has installed at the time? Just trying to understand a bit better ;-) |
|
As far as I know Python is built at the same time as everything else and bundled with the app. Sab stopped using the system python as that is stuck on a old version which is linked to an ancient version of OpenSSL. |
|
While Safihre may find a work around to restrain the build environment in terms of CPU instructions, the simple fact is that all macs which did not make the Sierra cut and which are stuck on 10.11 are in their last year or so of useful life, once Apple stops supporting 10.11 in Fall 2018, many apps will start to follow and since the hardware cannot be upgraded to 10.12 and up, it's game over. Web browsers like Chrome and Firefox have been very generous and currently support 10.9 and up. That's current+4 previous versions, which is 2 more than Apple supports. Other popular apps are more strict for example: Office 2016 supports 10.10 and up, which is current+3 previous |
|
Sounds fair. Now i have to convince the Minister Of Finance that my iMac really really needs updating. ;-) So give me a few months please ;-) G./ |
|
Oops, I made a typo in the 10.11 build. Restarting now! |
|
Just tried The python version in this build is Thanks for all your efforts guys! |
|
Hmmm @Cpuroast now what do we do? 😆 I could also try to force the 10.10 build to use 2.7.13 and see if that maybe works? |
|
@grillp Could you maybe test this version? |
|
In a surprising turn of events, OSX10.11-2 actually runs on 10.9 and 10.10. |
|
maybe there's something weird with the xcode6.4 travis image Xcode 7.3.1 is available by adding osx_image: xcode7.3 to your .travis.yml. You could try that one. |
|
as I said, there might be something funky with the old xcode6.4 image. |
|
Python 2.7.14 is fine, I think the travis images simply have their quirks. So we know that builds done with xcode6.4 image has issues with older CPUs |
|
Still need to test OSX10.11-2 on 10.11,10.12 and 10.13 |
|
OSX10.11-2 runs on 10.9, 10.10, 10.11, 10.12 and 10.13 At least on this 2012 CPU Looks like we might have a new winner. I didn't bother testing OSX10.10-3 across all OSes as that rolls back Python, which isn't ideal and it would mean maintaining multiple builds for multiple OSes again. 1 build for all 5 versions of macOS is much nicer. |
|
Also, Safihre you should really join the sab IRC channel on SynIRC, would be faster for testing and collaboration than github comments. |
|
@Safihre , tried the version in https://github.com/sabnzbd/sabbuild/releases/tag/OSX10.10-3 It failed:
No logging other than that. |
|
Great, then |
|
@Safihre I assume you meant "OSX10.11-2" instead of "OSX10.10-2" |
|
Yes indeed! |
|
@Safihre I'm actually surprised it runs on 10.9 and 10.10, that completely caught me by surprise, according to travis the xcode8 image doesn't even even contain the 10.9 and 10.10 sdks. For the hell of it though, we should try a build using xcode7.3.1, but heh, if xcode8 works, across the board it should result in a more optimized build for newer OSes. |
|
Here it is :) |
|
Ok, no real differences with xcode7.3 vs xcode8, it runs fine on my VMs. I think things may start breaking for 10.9 and possibly 10.10, starting with the xcode8.1 image which is built on 10.12. Why not make a build using xcode8.1, xcode8.2 and xcode8.3, xcode9 and xcode9.1 and I'll see if they still run on 10.9/10.10/10.11. At least we'll know exactly when things start breaking for older OSes. |
|
I'm away from home for a few weeks, but will vpn in when I can to test out the new version. Will let you know when I have tried. Thanks again folks! |
|
Waiting between flights I managed to give it a try. https://github.com/sabnzbd/sabbuild/releases/tag/osx73 works fine on my machine. |
|
That's what I thought, ok, we stick with xcode8 since it seems to work fine on everything and I suspect xcode8.1 on 10.12 would break 10.9, 10.10 and potentially 10.11. |
|
@grillp @Cpuroast Travis removed the |
|
@Safihre That's odd, since xcode8 is still in their docs: https://docs.travis-ci.com/user/reference/osx/#OS-X-Version They did remove some of the build environments, but xcode8 is still there. And your travis config file is still specifying xcode8: |
|
That announcement says that their new default is changing from 7.3 to 8.3. They also mention at the bottom of it that some images are being retired: "The following images will be deprecated: But their docs clearly state that the xcode8 image is still there, but that message does indicate that it is not, their docs need to be updated then to reflect this. I e-mailed their support to have their docs updated to reflect these changes. I'll run the new build on the 5 supported macOS versions and see how it goes. |
|
Mid 2012 MBP 2.3.2RC2-2 So far so good. If @grillp reports back that it's good on his older hardware, no point in going back in time to xcode7.3 If all is good with this build, It would be worth updating .travis.yml to use xcode8.3 to avoid the redirect message and to clarify exactly which build image is used during the build. Would be fun to try the xcode9, xcode9,1 and xcode9,2 images to see how far we can go before it breaks compatibility with the older macOS versions. |
|
Heya, https://github.com/sabnzbd/sabbuild/releases/tag/2.3.2RC2-2 Works fine on my clunker..ehmm.. workhorse! Mid 2007 iMac |
|
Good, looks like xcode8.3 is our new default as I'm pretty sure the more recent images would at least break 10.9. |
|
Thanks for testing guys! 🥇 |
I updated SABNzb+ to v 2.3.1 (from 2.2.0). Start SABNzb+ and nothing happens. If I start Activity Monitor and Filter for SAB, I see the process starting and then stopping again after a few seconds away.
If I revert to 2.2.0 that works fine.
In ~/Library/Application Support/sabnzb/logs/sabnzb.logs, all I see is:
Changed the loglevel (in sabnzb.ini) to 9 and see:
Anything else I can check?
The text was updated successfully, but these errors were encountered: