开云体育

Hi, I'm using XEphem 4.2.0 on a debian 12.9 computer and when the Skyview is close to the celestial pole (N or S) I'm getting the following alert : "UCAC : Error reading UCAC data near x:yz a:bc" with various values of x,y,z ,a,b,c ie RA/DEC. After this the UCAC stars disappear and the catalog is unselected in the Field Stars Setup window. I have to move away from the pole to be able to select the catalog again. This happens at less than 1 or 2 degrees from the pole. Same behavior with UCAC3, UCAC4 or UCAC5... Any ideas ? Thierry

Maybe slackware-current is too bleeding edge because when I use make to compile xephem it stops with the following error: sunmenu.c: In function ‘readSOHOImage’: sunmenu.c:922:17: error: implicit declaration of function ‘strptime’; did you mean ‘strftime’? [-Wimplicit-function-declaration] 922 | strptime(buf+20, "%d %b %Y %H:%M:%S %Z", &tm); | ^~~~~~~~ | strftime make: *** [<builtin>: sunmenu.o] Error 1 Cheers Frits

Dear friends of XEphem, I would like to have my Bachelor students estimate the orbital period of Mars using only data from XEphem-simulated ground-based observations. I mean, from Sky view, from the Data table... and of course not from the Solar system view. I feel there should be a way to do this by estimating the interval between two dates at which the Sun, Earth and Mars are aligned but I am not sure how to define this configuration from XEphem data. Could I simply select one "fixed star" of the ecliptic plane and wait for Mars to come again to this position as seen from Earth? A rough estimate would be sufficient but a precise method is welcome if simple enough for me and my non-specialist students! If it's easier with any other planet, let me know... Any help would be highly appreciated! Yours, Maxime

Hello, I have few questions about the settings to compare ephemeris generated by XEphem and almanac data. Times are calculated for upper limb or sun center crossing the horizon? Atmosphere pressure: 0 or 1013 hPa? Does it change refraction? Menu Preferencies > Equatorial > Topocentric or Geocentric? Other settings to consider? Best regards Stefano

Hello, I write to ask some "directions for use". To reckon the next new or full moon date I use the solver tool. I set "Moon.Sep" or "Moon.Elong" as the function and check "Find Minimum" or "Find Maximum" goal. Here my questions: - is this the correct way to do it? - why the separation values are not 0 or 180 degrees at every new or full moon? Can you explain or point me to sources/models where to visualize the dynamics of involved bodies (in plain style if possible ...). If I am not wrong "Topocentric" or "Geocentric" setting does not change this too much. Thanks in advance, best regards stefano

Dear friends of XEphem, I am seeking your opinion about how I could overhaul the astronomy practical work that I've had with my Bachelor students for quite a few years. They are in a curriculum for would-be school teachers (for pupils aged 3-11) thus this has to be scientifically robust though basic and very applied. I am not dreaming that some day they might use XEphem with the children (though, who knows?) but at least that this course gives them a minimal background. I would like to modify it in-depth to better correspond to the historical buildup of knowledge over the centuries... I mean, starting as far as possible from sky observations, and I would also like to introduce some basic calculations (whereas in the current version, they use the Solar system view right at the beginning and that is not really an observation that one could make in real...). I am for example thinking of the calculation of the Earth's radius... What do you think about it? Any suggestion or constructive criticism is welcome! N.B. it is a Google translation of my document in French, that I quickly reviewed but not thouroughly polished... Yours, Maxime

This does not pertain immediately to Maxime's question, but I can report an effortless new installation on a new computer using Linux Mint 21.1 (Kernel: Linux 5.15.0-56-generic). Bernie On 1/1/23 23:52, Jakob via groups.io wrote: > Hello Maxime, > > I think you need to recompile xephem, to get the libraries right. > > This is what I did (on Ubuntu 22.10): > > xephem: apt install build-essential groff-base libmotif-dev libssl-dev libxext-dev libxmu-dev libxt-dev > Then: follow xephem/INSTALL > cd xephem/GUI/xephem > make clean > make > ./xephem -> works! > > Replacing your old binary by the newly compiled one might be enough (not sure). > > Hope this helps - Jakob. > > Cheers - Jakob. > > > > >

Dear friends of XEphem, I have the impression that the upgrade from Ubuntu 20.04 to 22.04 has messed up my XEphem install. I am no longer able to launch it from a terminal as I used to (xephem &), instead I get an error message: "xephem: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory". Is there any simple way to fix this? Or should I reinstall XEphem from start (and if so, what shall I do to first remove it properly)? Thank you for your help and clear skies for 2023! Yours, Maxime

FYI regarding future support for libXp ---------- Forwarded message --------- From: Alan Coopersmith <alan.coopersmith@...> Date: Mon, Sep 12, 2022 at 1:52 PM Subject: [ANNOUNCE] libXp 1.0.4 To: <[email protected]> Cc: <[email protected]> This library provides support for X11 clients to print via the X Print Extension, as previously implemented in the Xprt server. X.Org removed support for the Xprt server from the xorg-server releases in the 1.6.0 release in 2009, and the standalone git repo it was moved to has been unmaintained since 2009, making it difficult to actually use this library. While X.Org has continued to maintain this library for binary compatibility, we do not plan to do so for the long term and encourage anyone still building or shipping it to investigate how to stop doing so going forward as we now consider it to be deprecated. Adam Jackson (1): Fix a memory leak on the error path in XpGetLocaleNetString Alan Coopersmith (9): Update README for gitlab migration Update configure.ac bug URL for gitlab migration Build xz tarballs instead of bzip2 Fix spelling/wording issues gitlab CI: add a basic build test XpNotifyPdm.c: fix -Wmisleading-indentation warning XpExtVer.c: fix -Wredundant-decls warning Add deprecation notice to README libXp 1.0.4 Emil Velikov (1): autogen.sh: use quoted string variables Mihail Konev (1): autogen: add default patch prefix Peter Hutterer (1): autogen.sh: use exec instead of waiting for configure to finish git tag: libXp-1.0.4 https://xorg.freedesktop.org/archive/individual/lib/libXp-1.0.4.tar.gz SHA256: 05e46af1ccb68f1752cca5879774a4fb9bf3b19fe088eb745034956e0c6fadba libXp-1.0.4.tar.gz SHA512: a04018707bd8933c93c04f88361855d9f8129550fd5730befb5a0d5c4747ffe4b82630b80670f3cc718f0abd601e0e0927d6000b2fc32c9985db320b75cc59bb libXp-1.0.4.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/lib/libXp-1.0.4.tar.gz.sig https://xorg.freedesktop.org/archive/individual/lib/libXp-1.0.4.tar.xz SHA256: 1f19e3b8e82a34a8fd9889a7d9af0abe8588cb03fb57c37c569634cf3b9df1a4 libXp-1.0.4.tar.xz SHA512: 50e82e7ee7222db13a04f6223ae8653eb783593c3b28825d7fc233af188960bec53d2b11ced281e01140d283d840d0e3822d71f95f5045d594fb704485fd0f89 libXp-1.0.4.tar.xz PGP: https://xorg.freedesktop.org/archive/individual/lib/libXp-1.0.4.tar.xz.sig -- -Alan Coopersmith- alan.coopersmith@... Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Hi, gang. This morning XQuartz reminded me that there's a new version (2.8.2) to which to upgrade. Alas, because versions later than 2.7.11 remove libXp, XEphem won't compile on macOS with a modern XQuartz. libXp dependence in XEphem should be removed and replaced with a modern lib for any missing functionality; otherwise, we're at risk of being left behind. Unfortunately, it's way beyond my skill set to even analyze the code and figure out where such functionality is used. Cheers! trane -- // // Trane Francks trane@... Tokyo, Japan // Practice random kindness and senseless acts of beauty.

I see that xephem 4.1.0 now needs some version of OpenSSL. I have my own build of OpenSSL 1.1.1q, but it won't link against that -- it has undefined symbols. It will link with creaky old unsupported OpenSSL 1.0.2u. What version should I be using? (Yes, I know that I might be the only person building this on SPARC Solaris.) -- Jeff Wieland jjwieland@...

Good morning, XEphem folks! It came to my attention that the free “GitHub Actions” build service, which can be configured to run each time there’s a new commit, now supports macOS. I’ve just done a long series of experiments to see if it could compile XEphem. The result: I was able to get it compiled! But I don’t know if the resulting binary would really run, because I’ve not worked out whether GitHub Actions can somehow be induced to run a “headless” X server. First I edited the Makefile so that the Linux/Mac section looks like: UNAME_S = $(shell uname -s) ifeq ($(UNAME_S),Darwin) PLATI = -I/usr/local/opt/openssl@3/include PLATL = -L/usr/local/opt/openssl@3/lib endif CC = gcc CLDFLAGS = -g CFLAGS = $(LIBINC) $(CLDFLAGS) -O2 -Wall -I$(MOTIFI) $(PLATI) LDFLAGS = $(LIBLNK) $(CLDFLAGS) -L$(MOTIFL) $(PLATL) XLIBS = -lXm -lXt -lXext -lXmu -lX11 LIBS = $(XLIBS) $(LIBLIB) -lm -lssl It then compiles with: brew install openmotif brew install openssl brew install xquartz --cask make -C GUI/xephem (Note that make is NOT provided with a MOTIF= argument in this case.) Some questions for the folks on this email thread: Is anyone interested in trying this locally? I wonder if the resulting binary would run. If we discover this does produce a working executable, are these realistic instructions for the INSTALL file? Can we just show users the three brew install ... commands and have them happily compile? Or is brew not an option for most macOS users, and they will continue to be stuck with MOTIF=../../libXm/osx and the Xprint extension errors that it gives on modern macOS? (I tried installing brew on my old MacBook here at home but it said my MacBook is too old, so I have no way to verify locally what kind of binary the above instructions might produce on a real laptop.) It’s just occurred to me that maybe I could ask GitHub Actions to give me back the compiled binary when it’s finished? If we built one that’s statically linked, maybe this could produce a binary for macOS folks with each XEphem release that they could use without having to compile it themselves. Do any of you know how to produce binaries that work across different macOS versions? In any case, I’m happy at least that these build steps seem to provide a way to automatically verify, on each commit, that XEphem still at least successfully compiles under macOS, without users having to find out for themselves later that something broke. What I don’t know, since I’m not a macOS user, is whether these successful compile steps might be the basis for real users getting it compiled themselves. Let me know! I'm open to ideas.

I am by no means an expert in building xephem though I have had quite a bit of experience. I have compiled it on multiple flavors of Linux as well as Rapberry Pi (Raspian) and on the PC in Cygwin. The latest 4.xx builds do stymie me with OSX. I have a poorly funded lab which I use for education purposes. In that lab I have a plethora of devices and veritable smorgasbord of old macs. The most recent machines are 1st generation Mac Pros running El-Capitan and quite a fe running Lion as well as a few really crusty devils running Tiger or Leopard. I usually work from the most "recent" and work backwards. I will limit my questions to building on El-Capitan. The current build error I get is ld symbols not found for architecture x86_64. The system is a 64-bit 1st gen mac pro that lacks the uefi of the newer 2nd gen machines. The OS is 64 bit. The make version is Gnu Make 3.81 I am compiling with GCC and the version appears to be 4.2.1. I installed initially trying the old incantation of make MOTIF=../../libXm/osx. This method has worked with versions up to 3..7.7 and to check I untarred and recompiled a fresh copy of 3.7.7 on the box to test that something in my development environment hadn't changed. It worked flawlessly. Every version since breaks however even the pre ssl 4.x.x versions. I installed SSL via macports and commented out the generic section and uncommented the section specific to macports libraries in the makefile. Still no luck. I believe the ssl devel code I downloaded does work in previous iterations on other systems lacking the ssl libs the compile would break far sooner. The actual break occurs in the verbose fashion of: d ../../libz; make make[1]: `libz.a' is up to date. gcc -L../../libastro -L../../libip -L../../liblilxml -L../../libjpegd -L../../libpng -L../../libz -g -L../../libXm/osx -L/usr/X11R6/lib -o xephem aavso.o annotmenu.o broadcast.o calmenu.o closemenu.o compiler.o coordsmenu.o datamenu.o db.o dbmenu.o earthmap.o earthmenu.o fallbacks.o favmenu.o formats.o fsmenu.o ../../libXm/osx/libXm.a -lXp -lXt -lXext -lXmu -lX11 -lastro -lip -llilxml -ljpegd -lpng -lz -lm Undefined symbols for architecture x86_64: "_GSCFetch", referenced from: _fs_fetch in fsmenu.o "_GSCSetup", referenced from: _fs_save in fsmenu.o "_PATCHLEVEL", referenced from: _fetchAndShow in aavso.o _e_setupwxpm in earthmenu.o "_UCACFetch", referenced from: _fs_fetch in fsmenu.o "_UCACSetup", referenced from: _fs_save in fsmenu.o "_USNOFetch", referenced from: _fs_fetch in fsmenu.o "_USNOSetup", referenced from: _fs_save in fsmenu.o "_XPSAsk", referenced from: _av_print_cb in aavso.o _e_print_cb in earthmenu.o "_XPSCleanStr", referenced from: _e_print in earthmenu.o "_XPSClose", referenced from: _av_print in aavso.o _e_print in earthmenu.o "_XPSDirect", referenced from: _e_print in earthmenu.o _e_ps_ll in earthmenu.o "_XPSDrawLine", referenced from: _ano_draw in annotmenu.o "_XPSDrawLines", referenced from: _e_map in earthmenu.o _add_to_polyline in earthmenu.o "_XPSDrawPoints", referenced from: _e_drawsites in earthmenu.o "_XPSDrawSegments", referenced from: _e_drawcross in earthmenu.o "_XPSDrawString", referenced from: _ano_draw in annotmenu.o _e_map in earthmenu.o "_XPSFillArc", referenced from: _e_map in earthmenu.o "_XPSFillPolygon", referenced from: _e_map in earthmenu.o "_XPSPixmap", referenced from: _av_print in aavso.o _e_map in earthmenu.o "_XPSXBegin", referenced from: _av_print in aavso.o _e_print in earthmenu.o "_XPSXEnd", referenced from: _av_print in aavso.o _e_print in earthmenu.o "_XPS_cursor", referenced from: _watch_cursor in broadcast.o "_buttonAsButton", referenced from: _dm_manage in datamenu.o _dm_newfavs in datamenu.o _dm_selection_mode in datamenu.o _e_manage in earthmenu.o _e_buildfavs in earthmenu.o _e_set_buttons in earthmenu.o "_confirm", referenced from: _ano_save_cb in annotmenu.o _c_flistok_cb in closemenu.o _dm_flistok_cb in datamenu.o _db_delall_cb in dbmenu.o _db_relall_cb in dbmenu.o _fav_add_cb in favmenu.o _fav_save_cb in favmenu.o ... "_createFSM", referenced from: _ano_manage in annotmenu.o _db_c