Bug 195414

Summary: No stars appear - toggle stars has no effect
Product: [Applications] kstars Reporter: Mike Hore <mike_hore>
Component: generalAssignee: Akarsh Simha <akarsh.simha>
Status: RESOLVED FIXED    
Severity: normal CC: alexey.skladnoy, mike_hore
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Mike Hore 2009-06-06 07:54:08 UTC
Version:           1.5.0 (using 4.2.2 (KDE 4.2.2), Debian packages)
Compiler:          cc
OS:                Linux (ppc64) release 2.6.26-2-powerpc64

Since upgrading to KDE 4, no stars appear in KStars.  All other objects appear OK, But there are no stars, and toggling "toggle stars" has no effect at all.  The search window shows no star objects - e.g. "Rigel" isn't there.  It seems that all the stars have simply disappeared!
I tried removing KStars, clearing my local aptitude cache, and reinstalling, but still get the same problem.
Comment 1 Mike Hore 2009-06-07 04:44:38 UTC
The platform is G5 iMac (64-bit PowerPC).  
The previous KStars version (under KDE 3) worked fine.
Comment 2 Akarsh Simha 2009-06-07 10:27:21 UTC
Thanks for your valuable bug report. KDE 4.2 onwards, we moved to a binary file format for star data that has been tested only on 32-bit x86 with GNU/Linux. I strongly suspect that's the problem. 

I need a lot more debugging information to solve this. It would be a great help is somebody with a PowerPC (and other architectures / platforms) could build KStars from sources and help us fix this problem by applying patches for debugging.

Any testimonials of KStars working correctly on other platforms will also help.
Comment 3 Mike Hore 2009-06-07 13:51:11 UTC
Hi Akarsh, I think you've got it.

> KDE 4.2 onwards, we moved to a binary file
> format for star data that has been tested only on 32-bit x86 with GNU/Linux. I
> strongly suspect that's the problem. 

I agree that's the likely culprit.  Maybe an endianness issue.

I'm a semi-retired software developer, and though my experience is on the Macintosh rather than Linux,  I might have a go at compiling from sources and trying possible patches.  I don't have a lot of time but I'll see how I go.

Cheers,  Mike.
Comment 4 Alexey Khudiakov 2009-06-07 14:44:43 UTC
Another possibility is that StarData and DeepStarData are differently arraged in memory. Data fields could be aligned differently. Compilers have some liberties in this respect.
Comment 5 Mike Hore 2009-06-08 05:42:23 UTC
I've had a look at compiling from source, but it looks like a rather major undertaking for somebody who hasn't done any Linux development before (and the instructions don't seem to have been updated since 2006).  If somebody's willing to give me a bit of hand-holding to get a development setup going, I'll have a go, but haven't really got the time to work it all out myself.  I have used svn before, though.

Cheers,  Mike.
Comment 6 Akarsh Simha 2009-06-08 10:44:14 UTC
Mike,

Even if you could build KStars from Debian source packages for KDE 4.2.2 (which is a lot easier than building trunk), that should be enough. You should build it with the debug flags.

KDE Developers are usually around on #kde-devel and #kde-edu on FreeNode (IRC), and they could help you build KStars.

Thanks for offering to help!
Comment 7 Akarsh Simha 2009-06-08 11:50:35 UTC
SVN commit 978818 by asimha:

Swapping bytes for cross-architecture compatibility.

Although we did have byte-swap calls in most places, they were not
present at some crucial places. [While reading the header of the data
files]

This should hopefully ease the situation, if not fix bug
195414. However, this is still untested and testing on big endian
machines is still required.

CCMAIL: kstars-devel@kde.org
CCBUG: 195414



 M  +10 -0     deepstarcomponent.cpp  
 M  +7 -0      starcomponent.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=978818
Comment 8 Mike Hore 2009-06-09 04:54:56 UTC
>Even if you could build KStars from Debian source packages for KDE 4.2.2 (which
>is a lot easier than building trunk), that should be enough. You should build
>it with the debug flags.

OK, but I'm not sure what package(s) I should be installing - I'm trying kdevelop, but I'm not really sure what to do next.

>KDE Developers are usually around on #kde-devel and #kde-edu on FreeNode (IRC),
>and they could help you build KStars.

I don't know how to do IRC, and in any case I'm in a timezone that's pretty unfriendly to most of the rest of the world (GMT +9.30).  As I said, this is ALL very new to me!!

>Thanks for offering to help!

I'll try, but there's a bit of a learning curve...

Cheers,  Mike.
Comment 9 Mike Hore 2009-06-09 09:38:50 UTC
Hi again all,

I've now joined the KDE forums and posted a question in the developer section -- hopefully somebody there can give me some guidance.  kdevelop needs me to locate the package to work on and I'm stuck at that point until I can get some help.

Cheers,  Mike.
Comment 10 Mike Hore 2009-06-10 04:35:12 UTC
As I've now emailed Akarsh, I've now successfully compiled and run kstars on my PPC G5.  So now we can do some testing!

Cheers,  Mike.
Comment 11 Akarsh Simha 2009-06-11 09:06:17 UTC
SVN commit 980107 by asimha:

+ Use the correct syntax of the byteswap macros defined in the
  standard include, byteswap.h

Many thanks to Mike Hore, who helped me find this mistake! This should
fix bug 195414 at least partially, although it still needs testing.

CCMAIL: kstars-devel@kde.org
CCBUG: 195414



 M  +6 -6      binfilehelper.cpp  
 M  +17 -17    data/tools/binfiletester.c  
 M  +16 -16    data/tools/nomadbinfiletester.c  
 M  +6 -6      data/tools/readnomadbindump.c  
 M  +18 -18    skycomponents/deepstarcomponent.cpp  
 M  +10 -10    skycomponents/starcomponent.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=980107
Comment 12 Akarsh Simha 2009-06-16 10:22:58 UTC
After SVN commit 982519, Mike says that KStars is displaying stars. This issue should be resolved in trunk (although we tested it by applying patches on 4.2.x source packages). Please reopen if necessary.