Discusses packaging issues regarding applications that are distributed with the Cygwin DLL

Jussi Kantola | 6 Oct 2011 15:05

Picon

Re: [ITP] astrometry.net-0.38-1

I've updated the package as per instructions from this thread (fixed
the paths, dropped the unnecessary libs).
Hopefully I got it right this time -- I've found a new respect for
package maintainers of all my favorite distros,
this stuff requires more concentration and care than actually
programming the contents! ;)

As a side note, I occasionally have to run the program
(solve-field.exe) twice, as on the first attempt
it dies complaining of a slowly loading DLL (_functools).  Is this
normal?  I'm doing this in a Win7 virtual machine...

wget \
http://rubor.org/astrometrytortilla/astrometry.net/astrometry.net-0.38-1.tar.bz2
\
http://rubor.org/astrometrytortilla/astrometry.net/astrometry.net-0.38-1-src.tar.bz2
\
http://rubor.org/astrometrytortilla/astrometry.net/setup.hint

--

-- 
jussi

Marco Atzeri | 7 Oct 2011 16:20

Picon

Re: [ITP] astrometry.net-0.38-1

On 10/6/2011 3:05 PM, Jussi Kantola wrote:
> I've updated the package as per instructions from this thread (fixed
> the paths, dropped the unnecessary libs).
> Hopefully I got it right this time -- I've found a new respect for
> package maintainers of all my favorite distros,
> this stuff requires more concentration and care than actually
> programming the contents! ;)
>
> As a side note, I occasionally have to run the program
> (solve-field.exe) twice, as on the first attempt
> it dies complaining of a slowly loading DLL (_functools).  Is this
> normal?  I'm doing this in a Win7 virtual machine...
>
> wget \
> http://rubor.org/astrometrytortilla/astrometry.net/astrometry.net-0.38-1.tar.bz2
> \
> http://rubor.org/astrometrytortilla/astrometry.net/astrometry.net-0.38-1-src.tar.bz2
> \
> http://rubor.org/astrometrytortilla/astrometry.net/setup.hint
>

Hi Jussi,
could you clarify the usage/scope of
usr/lib/astrometry/libbackend.so ?

for what I see, none of the 77 exe you have in
    usr/bin
is using it.

Regards

(Continue reading)

Jussi Kantola | 7 Oct 2011 18:18

Picon

Re: [ITP] astrometry.net-0.38-1

On Fri, Oct 7, 2011 at 5:20 PM, Marco Atzeri wrote:
> Hi Jussi,
> could you clarify the usage/scope of
> usr/lib/astrometry/libbackend.so ?

I'm not a programmer of astrometry.net, and don't know how it works
internally (except that it's looking for
"stars" in the image to be solved, then constructs quads from the
stars and matches the quads to an index).
However I had to modify backend-main.c so that the config file (which
defines the location of index files)
could be read from cygwin's preferred location,
/usr/share/astrometry/etc/backend.cfg.

From backend-main.c:

/**
 * Accepts an augmented xylist that describes a field or set of fields to solve.
 * Reads a config file to find local indices, and merges information about the
 * indices with the job description to create an input file for
'blind'.  Runs blind
 * and merges the results.
 */

Not supposing everyone's an amateur astronomer, please allow me to decipher:

field = field of view, starfield, the area of the sky that's contained
in the image that is to be solved;
solving = figuring out the sky coordinates of the field
indices = files containing the known coordinates of celestial objects

(Continue reading)

Jussi Kantola | 7 Oct 2011 18:20

Picon

Re: [ITP] astrometry.net-0.38-1

Sorry for my linebreaking, gmail has been messing it up lately :/

--

-- 
jussi

Jussi Kantola | 10 Oct 2011 20:54

Picon

Re: [ITP] astrometry.net-0.38-1

Bumping up (is this cool, or am I being too spammy?)

--

-- 
jussi

Christopher Faylor | 11 Oct 2011 01:14

Re: [ITP] astrometry.net-0.38-1

On Mon, Oct 10, 2011 at 09:54:18PM +0300, Jussi Kantola wrote:
>Bumping up (is this cool, or am I being too spammy?)

You are being spammy.

cgf

Charles Wilson | 4 Nov 2011 07:29

Re: [ITP] astrometry.net-0.38-1

On 10/7/2011 12:18 PM, Jussi Kantola wrote:
> However I had to modify backend-main.c so that the config file (which
> defines the location of index files)
> could be read from cygwin's preferred location,
> /usr/share/astrometry/etc/backend.cfg.

That's a little odd, and I don't think that's exactly what was meant by 
the documentation http://cygwin.com/setup.html#package_contents.

I don't think this is a showstopper for this release, but ordinarily 
configuration files belong in the top-level /etc directory.  However, 
once installed there, a name like "backend.cfg" is poorly chosen, since 
it doesn't really indicate what package it belongs to, and thus might 
conflict with some other package.

/usr/share/≤pkg>/ is usually used for other, more extensive data files 
and support -- e.g. that's probably where your star catalog files 
(indexes?) ought to go.

Furthermore, if backend.cfg is user-editable, then you would probably 
want to install it into

	/etc/defaults/etc/backend.cfg

and include a postinstall/preremove scripts here:

	(a) /etc/postinstall/astrometry.net.sh
	(b) /etc/preremove/astrometry.net.sh

whose job is to (a) copy the "default" version into /etc on install, IF

(Continue reading)

Jussi Kantola | 4 Nov 2011 10:02

Picon

Re: [ITP] astrometry.net-0.38-1

On Fri, Nov 4, 2011 at 8:29 AM, Charles Wilson wrote:
> I don't think this is a showstopper for this release, but ordinarily
> configuration files belong in the top-level /etc directory.  However, once
> installed there, a name like "backend.cfg" is poorly chosen, since it
> doesn't really indicate what package it belongs to, and thus might conflict
> with some other package.

Which is precisely the reason I've tried to keep everything under
paths that have "astrometry" in them; as has already been pointed out
(and as you point out below), a.n isn't really (at this point)
designed for portability and/or 3rd party vendor distribution.  I
actually shuddered when I realized there would be a "cygbackend.dll",
as it sounds ALL wrong 

> /usr/share/≤pkg>/ is usually used for other, more extensive data files and
> support -- e.g. that's probably where your star catalog files (indexes?)
> ought to go.

Yes; indexes = star catalogs.

> Also, when I did 'make install ...' my lib/astrometry/bin directory was
> empty.

That's odd, I was building and installing it all night last night and
the folder was being updated duly.  Looking at the source package, the
Makefile seems fine (at least on that regard).

> ....so, not GTG.  Also, you missed Corinna's statement: "If the binaries are
> using it (the libbackend library), they should also be linked against [the
> DLL], rather than being linked statically."

(Continue reading)

Yaakov (Cygwin/X | 4 Nov 2011 16:11

Picon

Re: [ITP] astrometry.net-0.38-1

On Fri, 2011-11-04 at 02:29 -0400, Charles Wilson wrote:
> On 10/7/2011 12:18 PM, Jussi Kantola wrote:
> > However I had to modify backend-main.c so that the config file (which
> > defines the location of index files)
> > could be read from cygwin's preferred location,
> > /usr/share/astrometry/etc/backend.cfg.
> 
> That's a little odd, and I don't think that's exactly what was meant by 
> the documentation http://cygwin.com/setup.html#package_contents.
> 
> I don't think this is a showstopper for this release, but ordinarily 
> configuration files belong in the top-level /etc directory.  However, 
> once installed there, a name like "backend.cfg" is poorly chosen, since 
> it doesn't really indicate what package it belongs to, and thus might 
> conflict with some other package.

Then this should be /etc/astrometry/backend.cfg instead.

> IOW, cygwin python's distutils is _doing the right thing_ -- creating 
> the plugin with the name spherematch_c.dll -- but the Makefile in 
> astrometry.net thinks the plugin will always be named spherematch_c.so 
> and reports an error when it tries to install the latter file.

So patch the Makefile.in.

> Now, this bit is interesting:
> -       mkdir -p $(INSTALL_DIR)/python/astrometry/libkd
> +       mkdir -p $(INSTALL_DIR)/share/astrometry/python/astrometry/libkd
> 
> Normally, python extensions go under the "real" python dir:

(Continue reading)

Charles Wilson | 4 Nov 2011 17:07

Re: [ITP] astrometry.net-0.38-1

On 11/4/2011 11:11 AM, Yaakov (Cygwin/X) wrote:
> software is quite unpolished.

 From reading the web page, it appears to be a research project by a 
couple of grad students -- with goals of supporting amateur and even 
professional astronomers by automating what is currently a 
labor-intensive task.

So...like all research projects, it appears to suffer from 
"get-it-done-itis" focused on Linux and/or BSD, with little attention 
paid to portability.  That's...problematic when going to any flavor of 
win32, including cygwin.

I mean really: hand-editing makefiles? no configure scripts (some 
subdirs have them, but they are invoked as part of the top-level make, 
which doesn't).

IMO the whole thing needs to be autotoolized, but I'm not going there.

OTOH, I just spent a couple hours adding $(EXE) to about a thousand 
makefile rules, only to watch it blow up because of some built-in rule I 
can't turn off (where is it COMING from!!!??) that adds "foo.exe.o" to 
the dependencies and then looks for "foo.exe.c" to build it...Aaarrrggh....

--
Chuck

Charles Wilson | 4 Nov 2011 22:13

Re: [ITP] astrometry.net-0.38-1

On 11/4/2011 2:29 AM, Charles Wilson wrote:
> Your build still links against libbackend.a, rather than cygbackend.dll.
>
> I'm trying to massage your -src package to DTRT. Stay tuned.

I've posted a revised version of your package here:

http://cygwin.cwilson.fastmail.fm/astrometry.net-0.38-2-src.tar.bz2
http://cygwin.cwilson.fastmail.fm/astrometry.net-0.38-2.tar.bz2

Inside the -src tarball is the *original* upstream sources 
(astrometry.net-0.38.tar.bz2), a few patches, and a .cygport script. to 
rebuild, unpack the -src and do:

	$ cygport astrometry.net-0.38-2.cygport all

You should probably do that, to ensure that the build procedure works on 
your machine. Also, to test the resuts; I have no idea how to use this 
stuff.

Finally: the backend.exe program is linked to cygbackend.dll, which are 
both in /usr/lib/astrometry/bin/.  All the python stuff, including three 
extension DLLs, are in /usr/lib/astrometry/python/*/

I modified the build procedure for cygbackend.dll -- it now generates an 
import lib, and it also (re)exports all of the symbols from the other 
(sub)libraries.  That means when linking backend.exe, you don't need to 
list those other dependencies, because cygbackend.dll will satisfy them 
all. (*)

(Continue reading)

Jussi Kantola | 7 Nov 2011 14:18

Picon

Re: [ITP] astrometry.net-0.38-1

On Fri, Nov 4, 2011 at 11:13 PM, Charles Wilson wrote:
> You should probably do that, to ensure that the build procedure works on
> your machine. Also, to test the resuts; I have no idea how to use this
> stuff.

It builds fine, and the resulting installation works fine when I put
some sky catalogs in /usr/share/astrometry/data/.  The question
becomes, would it be better to create a separate package
(astrometry.net-data-tycho or such) for the (example/test) catalogs,
than to have them in the binary/source packages?  Theoretically, and I
suppose in eventual actuality as well, there could be many different
sets of catalogs, so separate packaging sounds like the way to go ...

> Provided you can rebuild this package on your machine, AND that it actually
> works, consider it GTG.

With the notice/question above, it worked like a charm -- and I thank
you dearly!

--

-- 
jussi

Charles Wilson | 7 Nov 2011 15:46

Re: [ITP] astrometry.net-0.38-1

On 11/7/2011 8:18 AM, Jussi Kantola wrote:
> On Fri, Nov 4, 2011 at 11:13 PM, Charles Wilson wrote:
>> You should probably do that, to ensure that the build procedure works on
>> your machine. Also, to test the resuts; I have no idea how to use this
>> stuff.
> 
> It builds fine, and the resulting installation works fine when I put
> some sky catalogs in /usr/share/astrometry/data/. 

Good news.  Please post *your* rebuilt packages somewhere, so they can
be uploaded.

> The question
> becomes, would it be better to create a separate package
> (astrometry.net-data-tycho or such) for the (example/test) catalogs,
> than to have them in the binary/source packages?  Theoretically, and I
> suppose in eventual actuality as well, there could be many different
> sets of catalogs, so separate packaging sounds like the way to go ...

Definitely separate. However, it may be best not to create any catalog
packages at all, and instead provide helper scripts (in
/usr/lib/astrometry/scripts/ ?) to d/l and install the individual
catalogs.  The reason for this suggestion is twofold.

First, if you create a cygwin package containing the data from catalog
"foo", then cygwin will be *redistributing* that data.  However, many
scientific databases of this sort, while free (gratis) to use, prohibit
redistribution -- everybody is required to get them directly from the
source.  So, for this sort of catalog, a helper script to enable the
end-user to do THAT is the only solution.

(Continue reading)

Jussi Kantola | 7 Nov 2011 17:12

Picon

Re: [ITP] astrometry.net-0.38-1

On Mon, Nov 7, 2011 at 4:46 PM, Charles Wilson wrote:
> Good news.  Please post *your* rebuilt packages somewhere, so they can
> be uploaded.

wget \
http://rubor.org/astrometrytortilla/astrometry.net/astrometry.net-0.38-2.tar.bz2
\
http://rubor.org/astrometrytortilla/astrometry.net/astrometry.net-0.38-2-src.tar.bz2
\
http://rubor.org/astrometrytortilla/astrometry.net/setup.hint

> Definitely separate. However, it may be best not to create any catalog
> packages at all, and instead provide helper scripts (in
> /usr/lib/astrometry/scripts/ ?) to d/l and install the individual
> catalogs.  The reason for this suggestion is twofold.

I like this even more.  Yeah, we'll go the dl-script way; for the
initial release, there will be no catalogs included, however, I
modified the cygwin-specific README with instructions for downloading
the previously included tycho*.fits from my own server.  With future
updates, we can have a fuller index from Tycho at f.e. AstroTortillas
site, or then people will just request the indices from
astrometry.net, which is the default procedure anyway.

> I have to admit, it was pretty painful.  The upstream astrometry guys
> really should work on making their project more cross-platform- and
> distro-packaging- friendly.

Yes, while I'm far too happy to have a free astrometrical solver to
actually complain, the codebase sure isn't in the best of shapes for

(Continue reading)

Christopher Faylor | 7 Nov 2011 17:17

Re: [ITP] astrometry.net-0.38-1

On Mon, Nov 07, 2011 at 09:46:21AM -0500, Charles Wilson wrote:
>On 11/7/2011 8:18 AM, Jussi Kantola wrote:
>> On Fri, Nov 4, 2011 at 11:13 PM, Charles Wilson wrote:
>>> You should probably do that, to ensure that the build procedure works on
>>> your machine. Also, to test the resuts; I have no idea how to use this
>>> stuff.
>> 
>> It builds fine, and the resulting installation works fine when I put
>> some sky catalogs in /usr/share/astrometry/data/. 
>
>Good news.  Please post *your* rebuilt packages somewhere, so they can
>be uploaded.
>
>> The question
>> becomes, would it be better to create a separate package
>> (astrometry.net-data-tycho or such) for the (example/test) catalogs,
>> than to have them in the binary/source packages?  Theoretically, and I
>> suppose in eventual actuality as well, there could be many different
>> sets of catalogs, so separate packaging sounds like the way to go ...
>
>Definitely separate. However, it may be best not to create any catalog
>packages at all, and instead provide helper scripts (in
>/usr/lib/astrometry/scripts/ ?) to d/l and install the individual
>catalogs.  The reason for this suggestion is twofold.
>
>First, if you create a cygwin package containing the data from catalog
>"foo", then cygwin will be *redistributing* that data.  However, many
>scientific databases of this sort, while free (gratis) to use, prohibit
>redistribution -- everybody is required to get them directly from the
>source.  So, for this sort of catalog, a helper script to enable the

(Continue reading)

Charles Wilson | 8 Nov 2011 05:49

Re: [ITP] astrometry.net-0.38-1

On 11/7/2011 11:17 AM, Christopher Faylor wrote:
> I've been trying not to offer an opinion here but it isn't clear to me
> why so many people voted +1 for this package.  It seems like we're
> adding a huge package

Meh, if you exclude the star catalogs (and I think we should; and the OP 
has agreed to avoid), then bin+src weighs in at 25MB (65MB 
uncompressed), which is pretty large but not unheard of.

Most of that is because it has a ton of exe's, and all but one are 
linked statically to various support libraries.  (Oddly all of those 
libs get dumped together into the DLL, and that dll is used by only one 
client. But, conceivably, the other exes could also link to that dll, 
for a big win: from 45MB uncompressed to approx 2.5MB, based on my 
seat-of-pants calculation).

> to the distribution just to help out a very
> miniscule user base.

Meh, without casting aspersions, I doubt the user base of our various 
specialized math tools -- like singular, octave, fftw3, qhull, etc -- 
are very large in absolute terms.  But...we have maintainers, they 
volunteered and contributed, so here we are.  If they go AWOL, then the 
package gets slapped with _obsolete.

Same deal here.

> Do we really need this package in the Cygwin
> distribution?

(Continue reading)

Christopher Faylor | 8 Nov 2011 08:19

Re: [ITP] astrometry.net-0.38-1

On Mon, Nov 07, 2011 at 11:49:45PM -0500, Charles Wilson wrote:
>On 11/7/2011 11:17 AM, Christopher Faylor wrote:
>> I've been trying not to offer an opinion here but it isn't clear to me
>> why so many people voted +1 for this package.  It seems like we're
>> adding a huge package
>
>Meh, if you exclude the star catalogs (and I think we should; and the OP 
>has agreed to avoid), then bin+src weighs in at 25MB (65MB 
>uncompressed), which is pretty large but not unheard of.
>
>Most of that is because it has a ton of exe's, and all but one are 
>linked statically to various support libraries.  (Oddly all of those 
>libs get dumped together into the DLL, and that dll is used by only one 
>client. But, conceivably, the other exes could also link to that dll, 
>for a big win: from 45MB uncompressed to approx 2.5MB, based on my 
>seat-of-pants calculation).
>
>> to the distribution just to help out a very
>> miniscule user base.
>
>Meh, without casting aspersions, I doubt the user base of our various 
>specialized math tools -- like singular, octave, fftw3, qhull, etc -- 
>are very large in absolute terms.  But...we have maintainers, they 
>volunteered and contributed, so here we are.  If they go AWOL, then the 
>package gets slapped with _obsolete.
>
>Same deal here.

No.  It's not, and please avoid the obnoxious "Meh"s.  There is no need
for that affectation unless you are purposely trying to offend.

(Continue reading)

Ken Brown | 8 Nov 2011 13:44

Picon

Re: [ITP] astrometry.net-0.38-1

On 11/8/2011 2:19 AM, Christopher Faylor wrote:
> Cygwin is supposed to be like a Linux distro.  Including packages which
> come with Linux distros is a no-brainer.  Including a large, specialized
> package which is not commonly found on Linux and which has a small user
> base is not a no-brainer.
[...]
> Given the fact that the votes needed to trickle in over the course of
> more than a month, it seems that most people don't feel very strongly
> about including this package.  I understand that the OP wants to have a
> convenient way of distributing it to the small number of people who need
> it but I don't think that is necessarily a good enough reason for the
> package to occupy disk space and bandwidth on sourceware.org and
> mirrors, for potential package support to show up in the cygwin mailing
> list, and for someone to take time to upload updates to sourceware.org.
>
> I was wondering if anyone else felt like I did about this package.  If
> it hadn't required many weeks to get approval + more weeks to get
> packaging worked out, it would have gone in without comment from me.
> Since it did drag on and required multiple pleading messages to keep
> things moving, it certainly seems like there isn't a lot of enthusiasm
> for getting this in.
>
> The bottom line is that I was trying to ask why people voted +1.  If it
> was just to "help the guy out" then that's not a really good reason for
> the package to be in the distro.  If it was because people thought this
> was "kinda cool..." then that would imply that there was more thought
> involved.

I was the last person to vote +1, and I have to admit that it was mostly 
to help the guy out.  I regret that I didn't give it more thought.  Now

(Continue reading)

Chris Sutcliffe | 9 Nov 2011 03:42

Picon

Re: [ITP] astrometry.net-0.38-1

On 8 November 2011 07:44, Ken Brown wrote:
> I was the last person to vote +1, and I have to admit that it was mostly to
> help the guy out.  I regret that I didn't give it more thought.  Now that
> I've seen this discussion, I am no longer in favor of including the package
> in the distro.  I think it would make more sense for the OP to set up his
> own repository.

Much like Ken I wasn't as thorough as I should have been when voting
for the package.  I like the concept of the package, but in all
likelihood I will likely not use it very often.  Following the thread
it looks like the package may not quite be ready for the distro.

Chris

--

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

Jussi Kantola | 9 Nov 2011 11:00

Picon

Re: [ITP] astrometry.net-0.38-1

Well, well.

I'm grateful for esp. the hours Chuck put into this, and for having at
least seen the process and all, but I suppose it's time to end this --
I just can't bear to watch losing all the votes so bravely fought for


AstroTortilla is fine with a custom repo.  All we ever wanted was to
be able to install astrometry.net with Cygwin's setup.exe.  There were
two reasons for doing the ITP: 1) Astrometry.net is immensely useful,
albeit for a relatively minor userbase (*), and it *will* be part of
both Cygwin and all the other major/applicable distros, eventually 2)
the thought never occured to me that custom repos are possible ...

(*) So-called computerized GOTO telescopes have been sold by the
unknown tens if not hundreds of thousands over the past 10-20yrs.  ALL
of them are essentially fixed by AstroTortilla, which critically
relies on Astrometry.net.  So it may well be that once the word gets
out that there's a GOTO correction program just like the one Hubble
Space Telescope uses, available for amateur astronomers and compatible
with their trusty old mounts, we'll see some downloads.  How many
would we need for it to be considered significant enough?

Is this document still valid?
http://sourceware.org/cygwin-apps/package-server.html
Anything else I need to know?

Thanks once again for your time and effort!  I'm sorry the lessons you
gave me will go down the drain if I won't become a package manager ...

(Continue reading)

Charles Wilson | 10 Nov 2011 00:24

Re: [ITP] astrometry.net-0.38-1

On 11/9/2011 5:00 AM, Jussi Kantola wrote:
> AstroTortilla is fine with a custom repo.  All we ever wanted was to
> be able to install astrometry.net with Cygwin's setup.exe

OK.

> How many
> would we need for it to be considered significant enough?

No idea.

> Is this document still valid?
> http://sourceware.org/cygwin-apps/package-server.html

Seems accurate -- but it's missing information about gpg security.  I 
think you want "Creating a custom Cygwin package server" -- you probably 
don't want to create or host a full mirror.

> Anything else I need to know?

Here's what I do, locally:

<top>/setup.exe
<top>/genini
<top>/release/foo/foo-1.2.3-1.tar.bz2
<top>/release/foo/foo-1.2.3-1-src.tar.bz2
<top>/release/foo/setup.hint

$ cd cygwin
$ ./genini --recursive release > setup.ini

(Continue reading)

Jussi Kantola | 11 Nov 2011 11:46

Picon

Re: [ITP] astrometry.net-0.38-1

Hello, and pardon me for still pestering you.

I've got a custom repo now working with setup.exe -X  <at> 
http://rubor.org/astrometrytortilla (won't be the final location).
Signatures are more troublesome.  I suspect my .sig files are in a
wrong format, but can't find detailed info on what the correct format
is.  Currently, I've just done

gpg --output setup.ini.sig --sign setup.ini
gpg --output setup.bz2.sig --sign setup.bz2

I also did my own key,

gpg --gen-keys  (to generate a 1024bit DSA key, no passphrase)
gpg --export "Jussi Kantola" > tortilla.gpg

intending to run

setup.exe -K http://rubor.org/astrometrytortilla/tortilla.gpg

However, setup.exe can't verify the signatures.  Error is "Internal
Error: gcrypt library error 163 illegal old tag"

I looked at setup.exe source, for hints on what the signatures should
be like, but got the impression that the full libgcrypt set should be
useable.  Apparently this impression is wrong -- or something.  Help?


--

-- 
jussi

(Continue reading)

Marco Atzeri | 8 Nov 2011 19:01

Picon

Re: [ITP] astrometry.net-0.38-1

On 11/8/2011 8:19 AM, Christopher Faylor wrote:

>
>> I think it's kinda cool for cygwin be one of the first (not THE first;
>> it's already in BSD ports IIUC) to provide these tools, so that's why I
>> voted +1.
>
> ^That is actually the type of answer I was looking for.  I wanted to
> know why people thought the package was needed in the distro.
>
>
> cgf

Of course there is no "need" for such package, but I noticed that all
distro have some astronomical package and at first glance they are
not more used that Astrometry.
The time taken to approve is likely linked to such particular usage.

I looked at the website and they have a community, a mailing list,
a bug tracker and some planning. It has some usage and I can image
that porting to windows with cygwin is much simpler than trying
another route. For that reason I voted +1.

I built it using one of the first trial and I noticed that
the build system is crude and every utility is static linked,
so personally my preference will be a smaller package using dynamic
linking; but it is a personal estetic opinion.
If the package size is a problem we can put it as a condition

Regards

(Continue reading)

Christopher Faylor | 8 Nov 2011 20:54

Re: [ITP] astrometry.net-0.38-1

On Tue, Nov 08, 2011 at 07:01:52PM +0100, Marco Atzeri wrote:
>On 11/8/2011 8:19 AM, Christopher Faylor wrote:
>>>I think it's kinda cool for cygwin be one of the first (not THE first;
>>>it's already in BSD ports IIUC) to provide these tools, so that's why I
>>>voted +1.
>>
>>^That is actually the type of answer I was looking for.  I wanted to
>>know why people thought the package was needed in the distro.
>
>Of course there is no "need" for such package, but I noticed that all
>distro have some astronomical package and at first glance they are not
>more used that Astrometry.

Sigh.  Ok.  Let me rephrase: "I wanted to know why people thought the
package was useful enough in the distro that they decided to vote for it
knowing that standard Linux distros do not contain the package".

If all distros have an astronomical package why aren't we looking to
get one of those rather than using one that isn't used in other Linux
distros?

>The time taken to approve is likely linked to such particular usage.

I can't precisely parse what you're trying to say but you seem to be
asserting that everyone else who voted +1 has done the same research as
you.  We already know that wasn't true.

>I looked at the website and they have a community, a mailing list,
>a bug tracker and some planning. It has some usage and I can image
>that porting to windows with cygwin is much simpler than trying

(Continue reading)

Return

Return to gmane.os.cygwin.applications.

Project Web Page

Discusses packaging issues regarding applications that are distributed with the Cygwin DLL

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane