[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: gcx - astronomical image processing and photometry

On 12/14/05, Justin Pryzby <justinpryzby@users.sourceforge.net> wrote:
> Hi Radu!!
> I want to see this happen; unfortunately I'm still in the early NM
> queue, so cannot (yet!) sponsor your uploads.  I've read the .diff,
> and I'm going to critique your packaging, hoping to make it trivial
> for someone to sponsor.
> Some will critique your inclusion of the ./debian/ directory in the
> upstream source.  Personally, I'm okay with it; and it probably helps
> reduce the overhead of the project.

Well, i definitely want to keep the debian dir in the cvs source tree.
i have it in the upstream source because my procedure is to do a make
dist in the upstream, then copy the tar to .orig, detar it and just
run dpkg-buildpackage and pbuilder.

I can of course remove it from there if it's objectionable.

> But, why is there a .diff then?  Just to avoid making another gcx
> release, from which nonDebian users won't benefit?  (This is one of
> the primary objections of people to including ./debian/ in an upstream
> tarball).

There shouldnt be one - i must have forgot to update the .orig on the
last package build after changing the docs makefile.in ;-).

> ./docs/Makefile.in:
> Since you are the upstream author, you should not have to patch this
> file.  Instead, it should be made sufficiently general to work for
> Debian users and nonDebian users.

That's how it's supposed to be - see above.

> Indeed, the only other changes in your .diff are from autotools.
> Personally, I find that a readable .diff is more important than the
> goal of including the new config.{sub,guess} from autotools-dev in the
> .diff.  So, (if you like), you could *remove* those 2 files in the
> ./debian/rules:clean target, and cp or ln them before building.
> Removing is okay, because dpkg-source ignores removals, assuming you
> know what you are doing; this makes the .diff much smaller.

i'll try to see what i can do about this.

> (The following files are included in the 'upstream' tarball):
> ./debian/compat:
> You might consider bumping this to '5', and build-dep on debhelper
> (>=5.0.0); the only problem is that it complicates backporting to
> sarge.

well, as it stands now, the source package builds on woody and sarge.
besides, the woody build is the only one that has installed cleanly on
all eight or so machines i tried it on, so backporting is important
for me.

> gcx.doc-base:
> Its probably best not to include the phrase "This is the" as the
> opening abstract phrase.  I'm probably being overly picky, though..

i was copying from the debtools example - don't particularly like it
either, but though that how most entries should sound. it's gone ;-).

> You can (and should) remove the template maintscripts (prerm preinst
> postrm postinst), since the debhelper tools will add the relevent
> snippets in the correct way, even without templates.  If you needed
> specialized maintscripts, then you would keep them, and the
> #DEBHELPER# token.


> ./debian/copyright:
> Pertti Paakkonen <firstname.lastname_at_joensuu_dot_fi>
> Is that actually somebody's address?  :)


> ./debian/control:
> Priority: extra might be appropriate, since this is IMHO a specialized
> application, and it is unlikely that another nonextra package will
> Depend on gcx.  Reference: policy 2.5.


> ./debian/rules:
> You could remove some comments here, and dh_installman doesn't
> presently do anything.


> Please consider adding a copyright statement to ./debian/copyright and
> ./debian/rules to the effect of "Debian packaging is copyright (C)
> 2005 by Radu Corlan, and is released under the GNPL, which may be
> found in ...".


> Please also consider adding a "watch" file, using
> qa.debian.org/watch/sf.php.
> (See http://lists.debian.org/debian-mentors/2005/12/msg00035.html for
> more info about this hack).
> Please note that I'm being critical here; this package looks fine.  I
> really, really hope that someone will sponsor it!  Though I don't
> presently use gcx, I have tested it, and would recommend it to anyone
> doing observational astronomy under Linux.  Documentation, in
> particular, is excellent.

Thanks for the comments - we all want to make perfect packages here ;-).


> Cheers from Reynolds Observatory, where I'm presently taking data on
> "Bernhard 02".
> Clear skies,
> Justin
> On Tue, Dec 13, 2005 at 11:42:06PM +0200, Radu Corlan wrote:
> > Hi,
> >
> > I'm looking for a sponsor for gcx, an astronomical gtk app. I'm also
> > the upstream author for this package, which has had about two dozen
> > public source releases in the last 2.5 years (see freshmeat page:
> > http://freshmeat.net/gcx for statistics).
> >
> > The package files can be found at http://gcx.sf.net/debian
> >
> > The package is lintian and linda-clean and builds with pbuilder for
> > woody, sarge and sid.
> >
> > Package details follow:
> >
> >  Package: gcx
> >  Version: 0.9.7-1
> >  Section: science
> >  Priority: optional
> >  Architecture: i386
> >  Depends: libc6 (>= 2.3.5-1), libglib1.2 (>= 1.2.0), libgtk1.2 (>= 1.2.10-4), li
> > bx11-6 | xlibs (>> 4.1.0), libxext6 | xlibs (>> 4.1.0), libxi6 | xlibs (>> 4.1.0
> > )
> >  Recommends: gnuplot
> >  Installed-Size: 2828
> >  Maintainer: Radu Corlan <radu@corlan.net>
> >  Description: astronomical image processing and photometry gtk+ application
> >   Gcx is an astronomical image processing and data reduction tool,
> >   with an easy to use graphical user interface. It provides a
> >   complete set of data reduction functions for CCD photometry,
> >   with frame WCS fitting, automatic star identification, aperture
> >   photometry of target and standard stars, single-frame ensemble
> >   photometry solution finding, multi-frame color coefficient
> >   fitting, extinction coefficient fitting, and all-sky photometry;
> >   as well as general-purpose astronomical image processing functions
> >   (bias, dark, flat, frame alignment and stacking); It can function
> >   as a FITS viewer.
> >   .
> >   For automating data reduction of large numbers of frames, gcx
> >   implements recipe files. These files contain specific information
> >   about the objects measured in each field. Once a recipe file is
> >   created for a given field, any number of frames of that field
> >   can be reduced without user intervention.
> >   .
> >   The program can control CCD cameras and telescopes, and implement
> >   automatic observation scripting. Cameras are controlled through a
> >   hardware-specific server, to which gcx connects through a TCP socket.
> >   It generates FITS files with comprehensive header information.
> >   .
> >   Telescopes and mounts using the LX200 protocol are
> >   supported. Gcx uses it's automatic field identification
> >   functions to refine telecope pointing accuracy.
> >   .
> >   When invoked without arguments, the program runs in GUI
> >   mode. Most functions are also accessible through command line
> >   options, allowing integration in a custom reduction pipeline.
> --
> To UNSUBSCRIBE, email to debian-science-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: