wmMoonClock doesn't build in OBS

please_try_again · July 10, 2011, 8:48pm

I don’t get why I haven’t been able to build this tiny applet for openSUSE in OBS. It takes two seconds to compile locally with or without the patch I added - which has absolutely no effect - i.e didn’t affect the building where it did already work (Fedora & Mandriva) and didn’t help for openSUSE.

https://build.opensuse.org/package/show?package=wmMoonClock&project=home%3Aplease_try_again

I couldn’t find any missing header so far.

malcolmlewis · July 10, 2011, 11:48pm

Hi
Adding export SUSE_ASNEEDED=0 gets it to build, how ever building locally, the first hint of other issues would be this in the build log;


I: Program is using implicit definitions of special functions.
   these functions need to use their correct prototypes to allow
   the lightweight buffer overflow checking to work.
     - Implicit memory/string functions need #include <string.h>.
     - Implicit *printf functions need #include <stdio.h>.
     - Implicit *printf functions need #include <stdio.h>.
     - Implicit *read* functions need #include <unistd.h>.
     - Implicit *recv* functions need #include <sys/socket.h>.
W: wmMoonClock implicit-fortify-decl CalcEphem.c:249

I: File is compiled without RPM_OPT_FLAGS
W: wmMoonClock no-rpm-opt-flags <cmdline>:wmMoonClock.c, CalcEphem.c, Moon.c, MoonRise.c, xutils.c

This will fix the first one…
SUSE Paste

Now adding the following to add the opt flags;


make CFLAGS='%{optflags}'

Creates a slew of the following;


I: Program returns random data in a function
E: wmMoonClock no-return-in-nonvoid-function CalcEphem.c:394, 198
E: wmMoonClock no-return-in-nonvoid-function Moon.c:327, 316, 306, 288
E: wmMoonClock no-return-in-nonvoid-function MoonRise.c:98, 76

I: Program returns random data in a function
E: wmMoonClock no-return-in-nonvoid-function CalcEphem.c:394, 198
E: wmMoonClock no-return-in-nonvoid-function Moon.c:327, 316, 306, 288
E: wmMoonClock no-return-in-nonvoid-function MoonRise.c:98, 76

You would need to patch out the errors along with fixing the code…

please_try_again · July 11, 2011, 12:55am

Hi Malcolm,

Many thanks! (I knew you would know). Do you mean that it would be better generally speaking to apply the patch, even it just built fine with export SUSE_ASNEEDED=0? Is the latter a hack?

malcolmlewis · July 11, 2011, 1:11am

Hi
It seems that the build checks for openSUSE are much more, not stringent as such, but aggressive in identifying a potential issue. If it’s not compiled with optflags AFAIK it wouldn’t get far up the foodchain to appear in openSUSE.

That being said, the first is not a hack, it fixes a problem, for the second one adding returns for the offending lines to me is hackish and it would appear the code needs to be fixed… I’m no C expert, so don’t really know where to start for the additional warnings created…

I would add the patch and let it build and publish, then add the optflags, then add this patch to see the additional warnings;
SUSE Paste

please_try_again · July 11, 2011, 3:52am

Done. And both steps built as expected. Actually I added another step in between, consisting in adding the optflags whithout the second patch you provided. Then it didn’t build under openSUSE. After I added the patch, it built successfully and one can see the warnings in the log.
Thanks a lot!

I renamed the spec file because RPMLINT kept complaining that it didn’t match the package name.

malcolmlewis · July 11, 2011, 4:00am

Hi
It builds, hopefully it works as well

Have a look here about patches and how they should appear in the spec file;
openSUSE:Packaging Patches guidelines - openSUSE

please_try_again · July 11, 2011, 5:26am

It does. I just checked.

vodoo · July 11, 2011, 3:39pm

@please_try_again: thank you for this package.

May I add some fairly off topic thoughts to this thread? I hope yes.

wmMoonClock uses Browns Lunar Theory to calculate the position of the moon. Ernest William Brown’s theory dates back to papers published between 1897 and 1908. The tables derived from his theory were published in 1919. All formulae are based on gravitational theory and are designed for very high accuracy. However, as it turned out, there remained an unexplained discrepancy between the theory and the observed positions in longitude, which had to be corrected with a ‘great empirical term’.

Later it was found that Brown’s theory was correct, but did not take into account that the earth’s rotation is slowing down in some unpredictable way due to friction generated by the tides.

Looking at the source it appears that many of the minor perturbation terms have been omitted, but I could not verify this, because I no longer have the code I wrote back in the 1980’s incorporating the complete theory. However, for any practical use, this should not degrade the precision in an unacceptable way, but it means, that the positions can not be directly compared with Brown’s results.

With the invention of computers the gravitational theory has been replaced by numerical integrations of the moon’s position. The latest is DE421. For those interested in this, here is the paper:

http://ipnpr.jpl.nasa.gov/progress_report/42-178/178C.pdf

Other packages use different algorithms. The ‘stellarium’ package uses the lunar solution ELP2000-82B by Chapront-Touze M., Chapront J.

ftp://ftp.imcce.fr/pub/ephem/moon/elp82b

It has a better precision and is a starting point for all who want to know how a precise ephemeris of the moon can be calculated with today’s modern equipment.

please_try_again · July 11, 2011, 10:54pm

Absolutely. And I would say that you did brilliantly!