I successfully built (locally using git clone) and ran kstars on both my laptop and desktop. Perhaps the kstars-bleeding package needs to be rebuilt for AMD64 21.04...
Sorry -- replied to wrong topic.
I missed the e-mail (not showing up on any account, including spam folders). I successfully built kstars locally on both the laptop and the desktop and both instances are working well.
Maybe a rebuild of the AMD64 version for Ubuntu 21.04 will be sufficient...
I have a similar issue. If I'm reading the backtrace correctly, this appears to be an issue with libQt5Core.so.5.15.2.
I'm trying to run kstars-bleeding 3.5.4+202107081131~ubuntu21.04.1 on two machines recently upgraded to 21.04 with same result.
I have attached a backtrace for reference and have also raised a bug on bugs.kde.org.
You can check the status of the driver packages you use on
. Look for a date in May (e.g., 202105....). If the latest is still in April, it hasn't completed the rebuild.
It is, indeed, a PITA that launchpad is working so slowly.
I have successfully run ~23 hours using Weather Watcher and my script. See image
I'm in the process of doing a longer term test.
I get data from my WeatherLink Live via a python script and write data to multiple web pages and an InfluxDB database. I modified the script to create a specific file accessible on my LAN for Weather Watcher to get its readings.
I'll post if I see any instabilities with this approach.
I have a permanent pier which only holds the mount between astrophotography sessions. That is, the scope, computer and all but the mount electronics come in after every session. Among the electronics is a Unihedron SQM which is monitored and MPSAS values saved in the FITS header of each image.
I also have a Davis weather station which I monitor with my personal RPi based solution. I see how I can add the data to allow weather monitoring in EKOS/INDI with the Weather Watcher driver.
Since I don't have any automation needs tied into the Weather Watcher, what value will I get out of this operation other than to be able to go to the appropriate INDI tab to see the current conditions? Is anything, e.g., the ambient temperature added to the FITS header?
Please take the following as progress feedback.
I trust that all the 20.10 and 20.04 indi packages (and 21.04?) will be regenerated. Today, I found that indi-bin, libindi-data and libindi1 had been updated. That was insufficient to resolve the issue on the laptop which has only been updated with the binaries.
As pawel-soja indicated on github, if I recompile indi and all its libraries, including 3rd party, everything seems to be working OK.
Yes, I did a "sudo make install". I also built and installed libasi and re-built and re-installed indi-asi. No change.
Can you confirm your EFW is a human interface device (hid)? Do you have any udev rules for asi devices?
I needed to create a make directory within build. After that, I was able to compile indi-asi, but the EFW still wasn't being recognized.
For what it's worth, here is the setup I'm testing:
I have a flat screen set up with the cameras, filter wheel, etc. connected. That's where I saw the EFW tab wasn't present. I have also connected only the EFW for testing.
I have tried to compile the drivers, but it has been a long time since I compiled them. I first tried a pull to update, and when that didn't work, I deleted the directory entirely and cloned the stable repository. I'm still getting this message:This was after following the following instructions from github:
I don't recall how I got this sorted before. Any help in getting this sorted will be welcome.