I am trying to rebuild it on my system via the craft script, let's see how it goes.

Yes there are 3 commands.

The first 2, it looks like nothing happens because nothing prints. But something very important happened. It tells the system which python and netpbm to use and where they are. Those two commands will be exactly the same for you unless kstars is somewhere else on your system.

For the 3rd command you cannot copy and paste my command you need to get your own from the kstars log right after you try to platesolve and it fails to work . I showed you where it appears in the log. You are trying to test the command it used that you tell me didn’t work. My command will not work for you because you don’t have my image. Also the command you copy and paste will change every time you take an image with kstars to platesolve since it is a temp file.

The goal is to test the exact command that kstars sent to astrometry using the exact image that it used and using the exact solver and settings it used

OK, got it.

I´ll test this tonight. Thanks for your patience.

Niki

Hi Rob looks like the target platform for 10.12 is being ignored on some libs and dependencies.
I am getting alot of this messages :
"/usr/bin/make: b'error: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.12" but "10.13" during configure'"
This only happens on external binaries, the KStars itself seems to be compiling ok, but, it's also using 10.14 SDK of the Command Line Tools.

So maybe that's the reason why the compiled astrometry binaries give the error, they are being compiled for the detected platform instead of the forced platform.
Are you compiling using a 10.14 system?

Yes, I am using 10.14. It would not be good if it is ignoring the flag for the system. But I can always check afterwards to make sure it did it correctly. Which thing says that it was wrong? The 10.14 SDK should be fine as long as it has the command that says to build for 10.12.

Niki,

Did you say it printed this?

Then something happens: Reading input file 1 of 1: "/private/var/folders/l3/yznjwk917w9_f9qglkhkndpr0000gn/T/fitstVCXWV.fits"...
sh: /usr/local/bin/python2.7: No such file or directory

You may have told it to use the wrong file, but this still tells me something very useful. It is apparently trying to use the wrong python! That is not good. Let me look into that.

Thanks,

Rob

Yes the SDK is bulding fine for the target, the problem is only on some libs and dependencies. I will try to find wich ones, anyway I have just rebuilt the DMG on my system and it's working fine!!! No more errors, and it solves fine.
I just had to copy my old astrometry.cfg as it's not incluided in the DMG. I will do some more testing on this build to see if it's all ok but If anyone is interested here is the 3.1.1 DMG built on 10.13: we.tl/t-w5YTkEqDdQ

Ok I looked into it Niki. There is a very good reason that it didn't work! Your error stated "sh: /usr/local/bin/python2.7: No such file or directory". Of course we don't want it to use that one because you don't have that on your system.

So I was wondering why it didn't want to use the one we told it to use, which the python in the folder: "/Applications/kstars.app/Contents/MacOS/python/bin". So I checked just now, python is there and there is no problem with it running on a 10.12 system. BUT it is called "python". Astrometry apparently now looks for "python2.7" which is NOT what it is called. Renaming it make it work.

So yes, I think the solution is simply to rename the python executable. Can you try this command in the terminal and see if it fixes the problem?

mv /Applications/kstars.app/Contents/MacOS/python/bin/python /Applications/kstars.app/Contents/MacOS/python/bin/python2.7

Ok a couple of people verified that yes, changing this file to be called python2.7 fixed the problem. So I just updated the build script. It should be good now. We had a couple of other fixes as well that we did in the past week. We can build a new DMG soon.

Hi again!

The command worked for me!

Thanx a lot Rob.

Cheers,
Niki


Gesendet von iPhone mit Tapatalk

Hello Rob,
while I can confirm, that the file is now called python2.7, the content of the directory kstars.app/Contents/Resources/DriverSupport ist missing a few directories compared to 3.0, namely why, apogee and others.
Is this caused by the new build process?


Regards

Dirk

It probably is . I will check to see about any missing files. It would be good to sort out any issues like this before we release a new dmg. If you see anything else, please let me know