So the Astroberry, StellarMate, and the software built with my script is all pretty much the same from an astronomy point of view. They all have INDI installed including various drivers, as well as KStars and sometimes other software. You can use INDI/KStars on Raspbian, Ubuntu MATE, or other Linux systems. Astroberry uses Raspbian and StellarMate uses Ubuntu. My script can try to set up either system, but it does require some knowledge in order to decide which parts of the script you would like to use and which parts you can comment out. Also, since not all systems are the same, some issues could be encountered.
As for whether they are up to date, Astroberry, since it is an image with everything installed, could easily be out of date after some time goes by. But I assume that there is some system in Astroberry to update INDI or other software periodically. It is Raspbian, so I don't think it can use the PPA, so I don't know how that software gets updated. StellarMate is based on Ubuntu, so it almost certainly has the PPA installed, so updating indi or kstars to the latest version is pretty simple with just two commands. As for my scripts, if you use an Ubuntu-Mate installation and the script I have for setting that one up, then it uses the PPA as well. I include scripts for updating, or you can just use the update commands I mentioned earlier. If you use Raspbian with my script, then to update it, you could run my update script, but that does involve rebuilding the latest versions.
It sounds to me like you encountered some sort of issue in the build if the kstars-build folder is small. It is not that small. My recommendation to you probably would be to either use StellarMate OS on your PI, or maybe try Ubuntu Mate and run my other script? I would be glad to help you try to find out what went wrong with your Raspbian run, but it sounds like you don't have any info about what happened during the build.
If it helps, my usual preference for my own system is to use Ubuntu Mate on the Pi, not Raspbian. With Ubuntu MATE, you can use the PPA and install everything in much simpler ways. I have another script on the Repo you used that handles ubuntu, and it is much simpler and takes much less time. On Raspbian, you have to build everything, and if you are not comfortable with diagnosing problems with building software or used to doing it, I would probably recommend the ubuntu route.
In terms of the Terminal Scrollback, if you didn't save it, then it is probably gone. I usually try to keep it open until I check that the installation worked before closing it. While it is still open, you can save it as a text file if needed.
If you want to check if the software installation worked, you could go to terminal and type kstars and see if it runs. If not, maybe go into the astroroot folder, look in the kstars-build folder and see if kstars was built there. if so, you could go there in terminal and try ./kstars to see if it runs.
On Raspbian, all the astrophotography software needs to be built from scratch since there isn't anything like the PPA for Raspbian and the software in the package managers for Debian which Raspbian is built on is way out of date. From what you posted here, it sounds like you built a good deal of the software most likely. Did you have any information about any errors that might have printed to the console? It is possible that it all built perfectly and you just didn't get any icons for running it on the desktop. Maybe something about the Desktop on Raspbian has changed?
Hey MacOS users,
I built a KStars DMG yesterday so that we can test the MacOS DMG before release next week. Please let me know if there are any packaging issues or other MacOS only bugs that we can take care of before release. I already tested it with simulators at my end and everything seemed fine. Please try with other equipment and let me know if there are any problems.
Yes I worked on this about a week ago after someone brought it to my attention. I made some changes that should fix a lot of the problems I think.
To give some back story, when I was first working to port KStars to work on MacOS back in 2016/2017, I immediately ran into a huge issue. Unlike on Linux, where child windows appear above their parent windows and don't go behind them when you click the parent window, I found that on MacOS in QT, anything could end up behind the main planetarium window, from Ekos to the FitsViewer to any given Dialog or Alert window. This was a huge show stopper, because in a planetarium program, you often have to click on the Skymap to move to different parts of the sky, click on an object, get object details, or to do various tasks. In fact, often I found that you had to click something in Ekos, then slew the skymap and then do something in Ekos again. The problem was, every time I clicked the skymap, everything else and I do mean everything went behind it. This is a really big problem because in a Planetarium program, the Skymap is meant to be large if not full screen. You don't have to use it this way and not everyone does, but really if a planetarium program can't keep its skymap behind all the other windows, it really can't be used like a Planetarium program. That is a problem.
I thought this would be fairly easy to fix, but I was wrong. There were multiple solutions that I tried and finally the one that mostly worked was to use "Tool Windows" and "Window flags" to keep everything in front of the skymap. There were some side effects of this and it was not the best solution in the world, but it was better than the previous issue. Unfortunately the side effect was that sometimes some windows ended up behind others and that was really annoying. So some of the issues you have observed are actually the original issue of things that go behind everything else. They include the "About KStars" window and the "Port Selector" window that were mentioned a few posts ago. And some issues were a side effect of the solution such as the dialog that was mentioned. I am sorry about these side effects of my solution but you should note that it was much worse before I did that work back in 2017. Most of you never saw how it worked before my changes back then, so you don't know how annoying it was. But believe me I know that I need to eliminate the side effects for usability. So I came back to this problem last week and I will try to fix it to make it work better.
When I revisited the problem last week, I think I finally managed to fix the side effects that were really annoying so that the dialog should not go behind now. I (and Hy) also fixed a couple of windows to which the solution was never applied such as the port selector window. But note that the "About KStars" window is not one that I can apply my solution to since KStars does not include the function that actually makes that dialog appear so we can't edit the window properties at all. Another one like that is the "Configure Notifications" window. We just don't have access to it. But I can certainly make sure my fix is applied to all the others that we can control and I think I can fix it so that side effect with the dialogs doesn't happen anymore.
Thanks for the feedback,
Thanks for the post, I took a look, it seems that a line was deleted from the 3rd Party Drivers Cmakelist by accident. I found it and told Jasem what was missing and he fixed it. It successfully built yesterday. I didn't realize the build was broken.
Ok Jasem added the line back and it successfully built on my machine, craft should build a new version tomorrow that will hopefully work fine.
Yep, we can fix that, sorry about that. A important line from the cmakelists for 3rd party drivers appears to have been removed. We can put that back.
Peter, does this mean that after you created the new profile it doesn't crash anymore after you start up after closing it? So it was related to an issue with optical trains somehow? Maybe it was an issue with how the optical train had been saved or not saved in your kstars or profile database ?
I still don't understand why it would do that though. . .
I would say we should try to fix whatever it is, but if the only way it would happen is somebody who created a profile around the same time optical trains came out then that is not a common issue and probably won't happen too much going forward.
To my knowledge there has been a bug for a long time where when you stop indiserver sometimes kstars crashes. This is a cross platform bug and I think it was being investigated by a couple of different people. I am not sure of the current status of this, it may have been resolved or maybe not. I don’t think that is related to Peter’s bug, but I could be wrong. The reason I don’t think it is related is because Peter confirmed that indi and kstars were fully shutdown before he tried to start it up again, whereas with the bug I am referencing, it’s just when shutting down that it sometimes crashes kstars.
It didn't do it with simulators.
Can you try a couple of different profiles to see if it is caused by a specific driver? If so, we can narrow It down. I don't have the same equipment you do, So your testing is very valuable.