I suspect you mean my first thought, since what we really would want is nightly builds of KStars with rebuilt indi drivers inside, not nightly builds of indi outside of kstars.

or do you mean we would add a separate entry for INDI packages similar to the one shown above for kstars?

would that mean editing the KStars entry to something like this?

Maybe you could try something like https://invent.kde.org/sysadmin/binary-factory-tooling/-/blob/master/craft/enabled-projects.yaml#L289 to force rebuilds of your unreleased software.

Thanks! I will check on it later to see if it works out.

I've initiated a Craft Builder Clean run which will eliminate any legacy artifacts laying around on the Windows and Mac builders.

Hi Hannah, thank you for your help! So then will cfitsio now build on the binary server again as a dylib so that linking will work with stellarsolver, or do we need to do something to make that happen? I think it ran on the binary factory a couple of hours ago and it is still linking to a static cfitsio according to the log.

cfitsio now builds, my craft was outdated.

Hi Hannah,

If a static lib is used all its dependent libs must be linked too. Ideally the libcfitsio.pc would provide the required libs.
Now why do you build libcfitsio static? I tried to build it locally, it tires to build shared and fails due to the curl issue you had before.

I guess another question I have is if cfitsio is a static library, would it have the zlib functions baked into it, or would there need to be a separate link to zlib if you link to cfitsio? On my system, cfitsio is a dynamic library and it is linked to zlib, so I don't have to link stellarsolver to zlib since cfitsio took care of that. But on the server, it doesn't seem to know the zlib functions.

Yes that was my initial conclusion since on my own computer cfitsio is a dynamic library and it works. But then my question is if the binary server and my computer are using the exact same craft recipe with the same options for cfitsio, why it would install as static on the binary server, but as dynamic on my computer? Unless the server is doing something different or somehow has different settings from craft that is downloaded to a computer?

Sorry i'm not much of an expert here but I suspect it could have something to do with it linking against a static version of libcfitsio:

/Users/packaging/Craft/BinaryFactory/macos-64-clang/lib/libcfitsio.a

That might be how CFITSIO is distributed of course.

Sorry to say but I think currently I don't have adequate knowledge to complete this task. So it is open for contribution :)

Thanks! Please check https://invent.kde.org/education/kstars.git and its readme.

I would like to work on this @mutlaqja . Can you point me to the source?

Thanks for this, I hadn't returned to it yet.

Thanks, great job on your first PR to KStars!

The offset thing wouldn't have worked. I looked through some corrections in chapter 10 of the book and this makes it the closest to the online calculators. If we reduce the time by huge numbers(say 800 years), even the online versions produce different results.

Great job! I doubled checked with other sources and we are very close. However, it appears all the times we have are almost exactly 1 minute later. Not sure what is causing this. Perhaps as a "hack" solution, we subtract 60 seconds from the final results?

Added comment block and removed choice variable with a single function call to compute all Solstices and Equinoxes.

Nice bug fix! I haven't tested the changes yet, just please check the commit and update accordignly.

This is great!! I hope it makes DSLR focusing much more accessible now in Ekos. Hopefully we get reports back from Canon users as well.

Thank you for keeping this up to date Christian! It's greatly appreciated.

My opinion on this is that observatory setups are too diverse to use a set predefined durations. Those durations need to be at least customizable via options. We thus get a whole new set of options, incidentally one or two per Ekos module.
Based on this observation, it means the estimation of procedure duration needs to rely on each module instead of being computed by scheduler. By extension, each module has to be responsible for the calculation of those duration, based on the actual work it has to do.
Therefore, I suggest we review that estimation activity when each Ekos module is assigned a blob of settings, as I presented on the forum.
"Hi Ekos module, here's what you need to do!" "- Yeah, that will probably take me <insert double> hours!"
Makes sense?

In D23735#526271, @wreissenberger wrote:

Aaaah, sorry, I misinterpreted one thing. You're absolutely right, 60sec for aligning makes sense, since it is more than one single astrometry run.

Aaaah, sorry, I misinterpreted one thing. You're absolutely right, 60sec for aligning makes sense, since it is more than one single astrometry run.

Good idea, Alex. And welcome to the Scheduler-Optimizing-Club :-)

Thanks Alex for improving the scheduler!

fixed the typo to use the right setting - resetGuideCalibration (not alwaysResetSequenceWhenStarting)

Hmm, no feedback...
Looks like nobody from kstars is interested in my project. No problem, let´s forget about it.

I already now the basic use of Valgrim and I think it could be enough for this task, I ll try to find some memory leaks and fix them, I will let you know if I need some help but I think it is going to be ok. You can assign this task to me.

Hi Oliver, welcome!

I am a brand new KDE contributor and I would like to get involved in the developpement of KStars. I would like to do this task but I never used tools like Valgrind or Heaptrack.
Could you please tell me for exemple the type of scenarios you want me to do in order to asses KStars memory use ? Thank you in advance

They are new lines. I paint the constellations in another way than common. Look here for an example: https://sternenkarten.com/zwischenspiele/sternbilder-malen/
The first picture show ursa major, painted in western style
The second picture show ursa major, how I paint the lines.

Hello, thank you for contribution, so I'm not sure if I follow.. are these missing lines or new ones or both?

This change is not anymore required since D18235 solves my issue in a much better way.
Thanks to anybody working on this topic

It is alright with D18235, I tested it yesterday night and so far
dicovered no issue, it solves my issue in a much better way.

Do I have to close D18627? or do you do it.

I am new to this platform so a bit unsure how to behave.

Le 01/02/2019 à 08:01, Jasem Mutlaq a écrit :

View Revision https://phabricator.kde.org/D18627
mutlaqja added a comment.

Thanks, but we cannot add any more options to the capture module UI.
It has to be added to opsekos.ui under the "Capture" tab. How does
this work with D18235 https://phabricator.kde.org/D18235? Maybe it
should be merged in there as well?

*REPOSITORY*
R321 KStars

*REVISION DETAIL*
https://phabricator.kde.org/D18627

*To: *alainz, KStars
*Cc: *mutlaqja, kde-edu, KStars, smoe, narvaez, apol

Thanks, but we cannot add any more options to the capture module UI. It has to be added to opsekos.ui under the "Capture" tab. How does this work with D18235? Maybe it should be merged in there as well?

See attached UI screen shot

An example lineup:

• to-do
• junior jobs
• doing/WIP
• needs review
• (to be discussed)
• (done)