FWIW, in my experience I can compile Indi and KStars on my 4Gb RPi4 no problem. It's certainly not as quick as compiling them on my mac laptop, but it works for me and is usable for me. I've done it as well on a 2Gb RPi4, and the difference is noticeable, but still works OK. I would not recommend compiling these programs on a 1Gb machine (last year I tried and gave up on my Rpi3b+, I guess you can get lucky, but...).
You certainly want to run parallel make (e.g. 'make -j 6 kstars') on the 4Gb RPi.

I'm not on top of swap space for linux, but I checked my Raspbian RPi4 4Gb just now, and I had the 100Mb setting you mentioned active in /etc/ dphys-swapfile. However, running 'free -h' or 'top' shows that I currently have 4Gb swap, not 100Mb. I guess this is due to running zram en.wikipedia.org/wiki/Zram (something I didn't actively setup, but I guess I'm using, as I checked and it is in my /etc/rc.local file, and visible with '/etc/swapon -s'.

(I don't use Astroberry, just raw Raspbian with Rob's script).
Hy

Hello,

The script is rated for multiple versions of hardware. I never worried about Ubuntu Mate’s swap file. I was shag grinned to find Raspbian gasping for breath and dying under the load. I set up a zram under Ubuntu Mate for buffering images not compiling code.

I use INDI and KSTARS to run an AstroEQ driven OTA. I have several CCD cameras to try alignment, guiding, and capture. This is all under RPI3B+.

I just ran the updated script and PHD2 did not build with the full supported camera list.

Hello,

After increasing the swap file area of Raspbian, I restarted the Raspbian script @ 8:35 am. At 10:45 pm, the script was still running. It was nearing the end of KSTARS. The number of scales from 0 to 100% never gives the scale of the script.

Under Ubuntu Mate, I have compiled INDI and KSTARS before automation. Not one compile took 16+ hours (not done yet) to complete. That was on a lowly RPI3.

I think I need to see if Raspbian requires optimizations and additional options to speed things up. Raspbian is very spartan like to me.

I would like the script to log to a file and screen. Many applications during compiling had GCC7 does things this way now. This was usually around variable initiation routines. This could be a dead code area also. KSTARS and INDI had several call outs of GCC7 “violation”.

Also, the script had several “no access rights” and “application not found” messages. With no logging and limited command window buffering (all memory is committed to the script), I am not interested in running another multi-day script without something optimized. Raspbian doesn’t given many option in the GUI.

Thanks AradoSKYindi for investigating this,

I have run the Raspbian version of my script many times in Raspbian on Raspberry Pi 4, and I have run the original ubuntu mate version many times on my raspberry pi 3b and 3b+, but I haven't tried running the raspbian version on raspberry pi 3. I developed the original for the raspberry pi 3 to be running ubuntu mate, so it just installs everything from the PPA, rather than building it. When the Raspberry pi 4 came out and ubuntu mate didn't work on it, thats when I wrote the raspbian version of the script. So it is very helpful that you are trying this. If you have any suggestions for improving the build for the PI3, I would appreciate it and try to implement any suggestions you might have. I have never tried it, for the very reason you found, it would take a VERY long time, since it is a big build. So I have basically believed that anybody using the Pi3 would be running ubuntu mate and anybody running the pi4 would be running raspbian. That doesn't mean it should not work though. So if you do find any way to make it better, I'm all ears.

Thanks,

Rob

I haven't gotten a chance to test it yet since I have been out of town due to thanksgiving. I just removed the build option for PHD2 as you stated. I can try it when I get home.

I have been building PHD2 myself because of the missing drivers, via the most rudimentary 'cmake ..' command and it worked. And the documentation stated
I am speculating that It may be that the PHD2 source folder must simply be cleared of the old git clone since if the script had been run before it only does a git pull. But I have not tried that yet.

do you think it is the source folder or the build folder that needs to be cleared? I could experiment with having it clear the build folder before building.

Hello,

After two days, the script completed. I now have desktop icons of KSTARS and INDI. Under AB 2.0, I had these icons on the tool bar as applets. I am redundant.

I also have a system tool bar. This shows the number of cores with the RPI3B+, 4. Opening 6 to 7 threads during compilation of full INDI and KSTARS is the problem. Proper thread management would speed things up. Giving every thread a high priority is like trying to drain an Olympic swimming pool through 4 soda straws. Now to investigate thread management under RPI3B+.

Also, PHD2 installed successfully. I have not tested it. I have not checked the ASTAP installation. When installed AB2.0, ASTAP was installed. KSTARS did not recognize the ASTAP. I had to reinstall ASTAP to get KSTARS to recognize the ASTAP installation and DB.

I would say the build folder would be more likely since the source should not be missing anything.

Hi,
A question for the script developer...
I have tried the backup / restore script you have created, and it seems to work well, except it does not backup and restore my FOV settings or the telescopes and start I have saved for them...it seems to do other stuff, like the profiles..but not that, and as I have four telescopes saved with focal reducers that 8 different set ups I have saved, and none of them or the FOV I have saved are transferring...

Now I am backing up from an Kubuntu PC and trying to restore o to an rpi4 with raspbian buster, could that be the issue, even though some parts seem to be working, the script runs through and reports all good with no errors, but I then open Kstars, and info not there...
Any ideas...
Thanks

So the setup and restore script simply copies and pastes the files where critical KStars user information is stored into a backup location and when you restore, it copies them back. It is possible that if something is not getting saved/restored that there was another file that I missed. It is also very possible since I made the script awhile ago, that new data base files have been added since then, which of course would not be getting backed up. We can revisit the script to see if some other files need to be added.