Bug 478539 - Kstars does not supply INDI; drivers.xml wrong syntax
Summary: Kstars does not supply INDI; drivers.xml wrong syntax
Alias: None
Product: Fedora
Classification: Fedora
Component: kdeedu
Version: 10
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Ngo Than
QA Contact: Fedora Extras Quality Assurance
Depends On: libfli libindi
Blocks: kde42
TreeView+ depends on / blocked
Reported: 2008-12-31 17:12 UTC by Joe Dell'Orfano
Modified: 2009-02-10 17:58 UTC (History)
7 users (show)

Fixed In Version: 4.2.0-7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-02-10 17:58:54 UTC

Attachments (Terms of Use)
corrected drivers file Save to /usr/share/kde4/apps/kstars (4.87 KB, text/plain)
2008-12-31 17:14 UTC, Joe Dell'Orfano
no flags Details

Description Joe Dell'Orfano 2008-12-31 17:12:39 UTC
Description of problem:

Kstars has been packaged separately from kdeedu in current versions of Fedora. However, the Kstars package does not supply indiserver and the indi drivers, causing a crash when device control is attempted. The solution is to install the entire kdeedu package in addition to the kstars package, although this seems to defeat the purpose of separating kstars from the kdeedu package.

In addition, the devices.xml file supplied by kstars has a syntax error. The file is found in /usr/share/kde4/apps/kstars. I have uploaded a corrected file. 

Finally, there are several missing device files from indi as supplied in package kdeedu. Current version is 0.6.  

Version-Release number of selected component (if applicable): 

kdeedu-kstars-4.1.3-1.fc10 (i386), kdeedu-kstars-4.1.2-2.fc10 (i386), kdeedu-4.1.3-1.fc10 (i386), kdeedu-4.1.3-1.fc10 (i386)

How reproducible: Reproducible

Steps to Reproduce:
Install kstars package and attempt to start indiserver.
Actual results:
kstars crashes

Expected results:
indiserver should start and kstars should connect to it as a client

Additional info:

I believe that adding indiserver and the related files to package kstars should fix the problem. It appears that indi source code is independently available on sourceforge, so perhaps providing a separate indi package and making it a dependency of kstars would be more appropriate.


Comment 1 Joe Dell'Orfano 2008-12-31 17:14:55 UTC
Created attachment 328018 [details]
corrected drivers file

Save to /usr/share/kde4/apps/kstars

Comment 2 Joe Dell'Orfano 2008-12-31 17:15:50 UTC
Comment on attachment 328018 [details]
corrected drivers file

Save to /usr/share/kde4/apps/kstars

><parsererror xmlns="http://www.mozilla.org/newlayout/xml/parsererror.xml">XML Parsing Error: junk after document element
>Location: https://bugzilla.redhat.com/attachment.cgi?id=328018
>Line Number 13, Column 1:<sourcetext>&lt;devGroup group="Telescopes"&gt;

Comment 3 Rex Dieter 2009-01-02 20:22:38 UTC
Adding indiserver would be a welcome package request... I'll add it to our wishlist.  Hopefully some enterprising soul who's interested in it could step forward to help out... hint hint... :)

In the meantime, the parser error is troublesome.  Mind either providing a diff/patch and/or reporting the issue upstream to bugs.kde.org?

I'm testing kde-4.2-beta2 myself, and it would appear that devices.xml no longer exists in that version, so the point may be moot.

Comment 4 Rex Dieter 2009-01-12 17:58:23 UTC
Doh, looks like kdeedu-4.2 no longer bundles libindi, but needs it installed separately.  Marking this to block kde42 update until done so.

Comment 5 Rex Dieter 2009-01-12 19:46:57 UTC
pointer/reference: http://indi.sourceforge.net/

Comment 6 Kevin Kofler 2009-01-24 09:10:53 UTC
Ping? Any review request for libindi yet? Missing INDI support is a 4.2 regression, it should be fixed before 4.2.0 goes out to stable.

Comment 7 Kevin Kofler 2009-01-24 15:46:12 UTC
Actually, the stuff which used to be in kstars/indi in KDE 4.1 is now in several tarballs, which we all need for full functionality (libindi alone is just the basics):

These are what used to be included:

This is already in Fedora as a separate package:

This one too, but an old version. The old version is sufficient, but we should still try to get it updated at least in Rawhide:

These ones cannot be shipped in Fedora because the driver is binary only (that's the infamous sbigudrv which was always reported as missing):
They'd have to go to RPM Fusion nonfree if somebody wants them (and presumably permission to redistribute would have to be obtained, the sbig tarball contains no license at all). sbig is the proprietary tarball, but indi-sbig (which is LGPL) does not build without it. What the copy built into KStars used to do is to build a dummy sbigudrv which only returns an error, that way you'd only have to replace the dummy library with the blob. But I don't think it makes sense to package such an indi-sbig in Fedora (we'd have to patch it or to ship an sbig-dummy package and it wouldn't be working anyway). The whole thing should go to a third-party repository if anybody cares about it at all.

So, to sum up, there should be 4 Fedora review requests (libfli, libindi (or indi or indilib, they're using all 3 variants), libapogee and indi-apogee, preferably in that order), libnova should get updated to the latest version (but we can use the one which is there for now, it's sufficient) and the sbig mess should get figured out for a third-party repository (but IMHO that one's not a blocker).

Comment 8 Kevin Kofler 2009-01-24 16:15:25 UTC
I just checked the licenses:

libfli is BSD (without the advertising clause).

libindi is mostly LGPLv2+ (v 2.1 + to be more precise), but some of the drivers are GPLv2+:
* There are some files for v4l2 conversion under libs/webcam which are GPLv2+. They should really use libv4l instead, which supports a lot more formats (and is LGPL). These are linked into the indi_lpi, indi_philips and indi_v4l drivers.
* drivers/video/stvdriver (indi_stv driver) also appears to contain GPL code (the header says so, it gives a GPLv2+ copyright notice for some copied code, the .c file doesn't, this should be clarified).
So this would be "LGPLv2+ and GPLv2+".

libapogee is GPLv2 (at least that's the version shipped with it, most of the source files contain no license headers (I've found a few files saying just "GPL", all the others say nothing), so it's unclear whether they really mean GPLv2, GPLv2+ or GPL+, clarification from upstream could be useful).

indi-apogee is LGPLv2+ (again 2.1+, but our License tags don't distinguish).

Comment 9 Sergio Pascual 2009-01-28 10:29:42 UTC
Review request for libfli


Libindi it's on the way, stay tuned :)

Comment 10 Kevin Kofler 2009-01-29 23:54:26 UTC
Ping? Any review request for libindi?

And are you also interested in the libapogee/indi-apogee stack? That adds support for INDI on some telescope hardware, it used to be included in KStars' copy of the INDI code.

Comment 11 Sergio Pascual 2009-01-31 17:03:55 UTC

(In reply to comment #10)
> Ping? Any review request for libindi?

I have a libindi package but I havn't submitted yet. 

> And are you also interested in the libapogee/indi-apogee stack? That adds
> support for INDI on some telescope hardware, it used to be included in KStars'
> copy of the INDI code.

If nobody else is interested I will probably package it also.

Comment 12 Sergio Pascual 2009-02-01 11:11:12 UTC
Libindi review request:


Comment 13 Sergio Pascual 2009-02-09 16:28:43 UTC
Here is the review request for libapogee #484704

Comment 14 Kevin Kofler 2009-02-09 16:34:51 UTC
FYI, we can build KStars against libindi as soon as libindi is in, libapogee and indi-apogee can go in afterwards (it's a plugin for libindi, so it should get picked up without KStars being explicitly built against indi-apogee).

Comment 15 Kevin Kofler 2009-02-10 17:50:18 UTC
libindi support will be back in the next push.

@Sergio: I removed the libapogee review from the blockers because it's not needed to build kdeedu. But we'll want libapogee and indi-apogee reviewed and pushed out ASAP.

Also please note that we added libfli and libindi to the KDE 4.2 update, so please do NOT file separate updates for those.

Note You need to log in before you can comment on or make changes to this bug.