Packaging for Debian (Astro)

[olebole]

Dear Radek,

I write you on behalf of the Debian Astro team. As you may know, our goal is to package the important software relevant for astronomy and astrophysics for the Debian GNU/Linux distribution. I just found your astroberry system for the Raspberry, and I think it would be great if this could make its way into the Debian distribution directly. From there, it would automatically migrate to Raspbian, and to other distributions based on Debian (Ubuntu, Mint, ...). This would have a few advantages. Especially, the packages are automatically built and tested as Debian evolves, and you would get code reviews from other Debian developers.

To maintain your packages within Debian, you don't need to be an official Developer; this works also through "sponsoring" by one. I would volunteer to do that. I would also review your packages and help if there are problems with it (sometimes, there are formal requirements, like for copyright etc.).

What do you think ybout this?

Best regards

Ole (olebole@debian.org)

[rkaczorek]

Hi Ole, Sounds like a good idea. I think that it would make easier for users of various distros to get into open source astronomy. There are a few things to be discussed before getting there. Drop me an email so we can exchange some pros and cons and possible copyright issues.

Kind regards

Radek (rkaczorek AT gmail DOT com)

[jscheidtmann]

Would love to see this and help with it. I once was grimaldi@debian.org in the 90s.

[olebole]

@jscheidtmann I think that would be great! I think, Astroberry could be one "task" of the Debian Astro Pure Blend.

[rkaczorek]

@olebole I was thinking about adding it to Debian Astro Pure Blend. Things that need to be discussed are related to the fact that many INDI drivers use binary components, which are not open source. It could be a show stopper, right?

[olebole]

In some sense, yes, as they cannot be in Debian main, and therefore the task can only "suggest" it, which means that they are not installed by default when selecting the task. Some workaround could be to have a specific "astroberry-nonfree" task, which by itself lives in Debian contrib and has the INDI drivers as strong(er) dependencies. Then, all non-free packages could be added by selecting one additional package.

[rkaczorek]

Thanks for the input. I believe that whole INDI core and INDI 3rd party drivers should be reviewed for licensing issues. KStars/Ekos is probably not a problem, except non-bleeding version of KStars is already there AFAIK. @jscheidtmann would you find time for such a review so we can set a starting point.

[jscheidtmann]

Can do, will take a handful of days.

[jscheidtmann]

Ok, I setup an instance of FOSSology and imported indi3rdparty and let the license scanners in there do their job: A handful of days will probably not be enough.

Scanner Count	Concluded License Count	License Name
208	0	LGPL-2.1+
134	0	MPL-2.0
90	0	GPL-2.0+
86	0	LGPL-2.0
58	0	LGPL-2.0+
50	0	BSD-3-Clause
48	0	WebM
45	0	BSD
37	0	GPL-3.0+
36	0	LGPL
23	0	LGPL-3.0+
13	0	MIT
13	0	FSFULLR
12	0	GPL
9	0	MIT-style
8	0	CCPL
8	0	BSD-2-Clause
7	0	CC-BY-3.0
7	0	Autoconf-exception
6	0	Unlicense
5	0	UnclassifiedLicense
5	0	Libtool-exception
5	0	GPL-3.0
5	0	GPL-2.0
5	0	FSFUL
4	0	Public-domain
3	0	See-file
3	0	See-URL
3	0	LGPL-2.1
3	0	BSD-possibility
2	0	WTFPL
2	0	Unicode
2	0	LGPL-3.0
2	0	BSD-2-Clause-Views
2	0	Apache-2.0
1	0	X11
1	0	See-doc.OTHER
1	0	Public-domain-ref
1	0	Non-commercial
1	0	IJG
1	0	GFDL-1.1+
1	0	Dual-license
1	0	COMMERCIAL

[jscheidtmann]

This is the result for indi-core:

Scanner Count	Concluded License Count	License Name
281	0	LGPL-2.1+
155	0	LGPL-2.0
94	0	GPL-2.0+
77	0	LGPL
12	0	BSD
10	0	GPL-3.0+
7	0	LGPL-2.0+
5	0	BSD-3-Clause
4	0	MIT
2	0	LicenseRef-NASA-FV-License-Agreement
2	0	LGPL-2.1
2	0	GPL-3.0
2	0	GPL
1	0	See-doc.OTHER
1	0	IJG-possibility
1	0	GPL-2.0
1	0	BSD-2-Clause
1	0	Apache-2.0

[jochym]

That is what I would expect. On the other hand, I think many of these packages are derived works of indi and people do not care too much about the details of the license. I am more surprised about the core. Maybe this should be cleared up first. I, for one, am fully willing to sync the licensing of the code I have contributed (however insignificant it may be). I am quite sure most other authors will have similar attitude (but not all probably).

[jochym]

@rkaczorek : BTW would you be willing to add deb-src repo to your binary repo? At least for indi packages. It will greatly ease the recompiling and testing...

[rkaczorek]

Thanks a lot @jscheidtmann @olebole this is what I meant in my first reply to your proposal. Major thing to be discussed and possibly put in order. Probably not that difficult but time consuming for sure. Any idea how we can proceed from here?

[rkaczorek]

@jochym As the matter of fact I'm packaging for debian/raspbian and majority of binary packages are coming from upstream with no changes whatsoever (INDI core, 3rdparty, KStars). The rest, including astroberry specific, are kept on github and linked in debian/copyright files. Let me think about it

[olebole]

As far as I see, indi (-core?) is already in Debian; is this the one you are using as well? If not, it may be worth to contact the current maintainers and get it collaboratively maintained. They already did the job of fiddling all the whistled of debian/copyright there.

There also seems to be "some" drivers being packaged by @alteholz (like this one), so I would guess there is some parallel activity to bring the drivers into Debian. It would probably also good to contact him to coordinate efforts; also he is definitely a good source when it comes to licensing/policy questions. This would bring hopefully many of the drivers into Debian.

There are also other programs, like oacapture that would be worth to bring to Debian, and for things like kstars the packages should somehow be synchronized (if I understand your statement that you package kstars yourself) and co-maintained.

So, I would mainly recommend to bring first the individual AstropBerry packages into Debian, piece by piece, and then create a "metapackage" that installs an AstroBerry system on any platform. This makes the whole process evolutionary, which is less likely to fail.

[alteholz]

Yes, the core part of indi is already in Debian, as well as kstars. Both versions in Debian seem to be rather up to date.

At the moment I am trying to package all drivers from indi-3rdparty. Indeed, the binary blobs are the biggest problem. Sometimes even the manufacturers have no idea under what license they distribute their SDK and the support people don't know how to answer questions about this topic.

[jochym]

@rkaczorek my issue was lack of the deb-src repo for the deb repo of astroberry. This prevents quick and easy rebuild of the packages for different architecture or for the test build. e.g. my CAUX driver included in astroberry seems to have some instability (crashes from time to time). I would like to rebuild it exactly as it is build for the repo and debug it. Having the exact config for the build removes one variable from the debugging process, which always helps ;) But this is of course a minor issue. Getting indi-3rd-party into debian would be a big deal, really. People need these drivers. The astroberry solves this nicely on the Pi, but sometimes you want something like this on the PC as well.

[rkaczorek]

@jochym could you please take it to separate issue? This is "Packaging for Debian", not "Missing deb-src repo" Answering your question - astroberry repository is not for any architecture, it is only for armhf and raspbian specifically. You can easily build any upstream component exactly as it is built in astroberry by using upstream build configuration e.g. indi-3rdparty/indi-celestronaux is built with indi-3rdparty/debian/indi-celestronaux and no changes whatsoever is introduced at packaging. Clone, checkout version you are interested in, compile and debug. What variable is missing in this equation?

[jochym]

No problem @rkaczorek I just got my answer. Thanks.