Astronomy (Sub)sprint 2015 Minutes, according to Markus


First, Ole Streicher introduced Debian Astro: Up to now, the Debian Astronomy Working Group (Debian Astro) is a subproject of the Debian Science project / blend. This results in actually two metapackages of Debian science, namely "Astronomy" and "Astronomy-dev". Technically, the group is organised as the "Debian Astronomy & Astrophysics" project. Everybody may apply for memebership using an account on (possibly a newly-registered one). A mid-term goal is promoting all of this to a distinct Debian blend, in order to increase the visibility of the astronomy packages. In this way, the project should also attract more package developers.

Overview of the Packaging Process

With a view to a new package author intending to offer an additional package that would complement the offerings of Debian Astro, Ole Streicher gave an overview about the process a package undergoes for inclusion into Debian. The usual way to start packaging for the official Debian repositories is "sponsoring" by a Debian developer (such as Ole Streicher of Debian Astro, but in fact anybody of the around 1000 Debian developers will do). This means that the Debian developer will digitally sign the packages from the package author before uploading them to the Debian archive.

There must be a source package, containing an original upstream source archive, together with patches and build instructions; and there must be also a binary package for at least one binary architecture officially supported by Debian. Architecture-independent packages, such as documentation, count as binary packages. Packages uploaded for the first time are put into the "new queue", where a small team, the so-called "FTP masters", will manually inspect them -- especially for questions of licence compliance. Leaving the "new queue", packages become part of the Debian "unstable" distribution, where more people take a look at the packages. Packages in "unstable" will be automatically rebuilt for all binary architectures, and the status reports of these build attempts will appear on a web site (which one???). A "maybe-successful" status should be reagarded as "successful", and likewise "maybe-failed" as "failed". All of this is a quite effective quality assurance process, where it is not uncommon to receive problem reports together with patches that fix the issue in question.

After packages are built, the are subjected to further tests by "piuparts", this tests for orderly package installation, deinstallation and related things. One important point is that file names must be effectively globally unique when considering all existing Debian packages. Thus, especially executable names residing in /usr/bin will have to be sometimes renamed relative to the upstream. For name clashes, one can search in . It is possible to allow file name clashes by changing the default "priority-opt" attibute to "priority-extra", but this is strongly discouraged.

If a package resides in the "unstable" distribution for ten days without problems, it enters the Debian "testing" distribution. Six months before a Debian release, there is a "freeze": the automatic migration from the "unstable" to the "testing" distribution is halted. Since the typical time interval between Debian distributions is about two years, packages in official Debian releases tend to lag somewhat with respect to upstream versions. One potential remedy for this is the "backports" Debian repository, from where a user of a stable distribution can install more recent software, after enabling "backports" in /etc/apt/sources.list*. However, presently Debian Astro lacks the manpower to feed the "backports" archive in addition to "unstable"/"testing". As the Ubuntu distribution generally includes all Debian packages from "unstable", freezing only two months before an Ubuntu release, the regular Ubuntu releases will often provide more recent versions of Debian packages.

Packages for Debian Astro should be created from git repositories on Finally, a package developer may become a Debian "maintainer", which allows to upload revised version of a set of specific packages to the Debian archives.

Hands-on Session

Next to the packaging introduction, there was a in-depth hands-on session where a program for gamma astronomy was prepared and built as a Debian package, using the pbuilder utility program, at git repository on and the lintian tool. This session included the steps lined out in the "Debian Astro Astropy packaging tutorial". It was mentioned that for manual package testing, virtual environments set up with the "schroot" secure change root utility are often sufficient, as compared to full virtual machine configurations.


There was a thread of discussion about software and other licenses in Debian packages, taken up at various points in time throughout the sprint session. The licenses of all parts of a Debian package must conform to the Debian Free Software Guidelines (DFSG). This includes data such as images and reference databases. Data that is not free with respect to the DFSG might be dowloaded from external servers during package installation (???).

Licenses will be checked by other Debian developers when a package is in the process of being integrated into Debian. Some license problems may be found automatically with the "lintian" packaging helper tool. The usability of "exotic" licenses for Debian should be discussed on the "Debian legal" mailing list.

The most common problem with otherwise free astronomy code for Debian packing is actually the rampant careless inclusion of code from the "Numerical Recipies" books, all of which is proprietary. Sometimes the origin of the proprietary parts is undocumented, and the packager will have to search for typical code fragments such as function names.

Upstream authors are generally receptive to requests for replacement of non-free code from Debian packagers. In some cases, splitting off non-free parts of a software may be a means of last resort to in order to attain the goal of an official Debian package.

Virtual Observatory Packages

Last not least there was a lively discussion about how to best integrate virtual observatory (VO) tools into Debian Astro, as they are still largely missing. One promiment idea was a vision to include application defaults yielding a default usability potentially as simple as Google Earth.


The sprint has been possible thanks to: