Re: [Review - not yet] Re: [ITP] tree

2003-12-19 Thread Stipe Tolj 
Corinna Vinschen wrote:
> 
> Do I understand that right?  There's a patch which changes the default
> prefix?  Is it really necessary to patch the package to install into /usr
> by default?  That sounds rather superfluous and irritating.  Usually,
> when a user calls `configure', the default prefix is /usr/local and
> if that's not what the user wants, she calls `configure --prefix=/usr'.
> Better add a Cygwin README which tells the user which configure options
> to use to create the Cygwin net release package.

there is no configure at all. Only a Makefile that compiles, links and
installs *one* .c file. So consider this maybe as the most tiny
package we have in Cygwin ;)

Stipe

mailto:[EMAIL PROTECTED]
---
Wapme Systems AG

Münsterstr. 248
40470 Düsseldorf, NRW, Germany

phone: +49.211.74845.0
fax: +49.211.74845.299

mailto:[EMAIL PROTECTED]
http://www.wapme-systems.de/
---

-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.2.2 (Cygwin)

mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS
OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2
nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT
dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv
bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID
AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl
OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ
K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H
g2HyLAEKQIp30Q==
=aYCI
-END PGP PUBLIC KEY BLOCK-

Re: [Review - not yet] Re: [ITP] tree

2003-12-19 Thread Corinna Vinschen 
On Dec 18 18:33, Igor Pechtchanski wrote:
> On Thu, 18 Dec 2003, Stipe Tolj wrote:
> > now, I'd like to take method 2, but the package does not provide and
> > sophisticated autoconf suite, only the raw Makefile. And actually for
> > one .c file this is ok ;)

Uh, scratch my previous posting.  No configure, that explains it.

What about adding one? ;-)

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

Re: [Review - not yet] Re: [ITP] tree

2003-12-19 Thread Corinna Vinschen 
On Dec 18 17:16, Igor Pechtchanski wrote:
> On Thu, 18 Dec 2003, Stipe Tolj wrote:
> > [snip]
> > > 5) There are no port notes in the Cygwin-specific README, even though
> > >there are some user-visible changes in the patch, such as changing the
> > >prefix to /usr and removing the "-s" linker flag (any particular reason
> > >why you did that?)
> >
> > -s linker flag put in place again (was a simple typo). So we get
> > stripping again. I don't see any needs for port notes to be honest.
> 
> Well, I think changing the prefix from /usr/local to /usr is a pretty
> serious change, in a sense that someone familiar with the package and
> wanting to install it on their system will download it, run "make; make
> install", and get the packages in /usr/bin instead of /usr/local/bin where
> they would expect them.  IMO, it deserves a mention in the port notes, but
> I'm not going to hold up the release of a package because of this.

Do I understand that right?  There's a patch which changes the default
prefix?  Is it really necessary to patch the package to install into /usr
by default?  That sounds rather superfluous and irritating.  Usually,
when a user calls `configure', the default prefix is /usr/local and
if that's not what the user wants, she calls `configure --prefix=/usr'.
Better add a Cygwin README which tells the user which configure options
to use to create the Cygwin net release package.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

Re: [Review - not yet] Re: [ITP] tree

2003-12-19 Thread Dr. Volker Zell 
> "Stipe" == Stipe Tolj writes:

Stipe> BTW, @Volker: you should have voted to the -apps list too ;)

Sorry, I just hit the reply button...

I vote pro

Stipe> Stipe

Ciao
  Volker

Re: [Review - not yet] Re: [ITP] tree

2003-12-18 Thread Charles Wilson 
Stipe Tolj wrote:

I did reverse patching for thre previous packages apache, php, etc
too. Non was objected until know. AFAIK, either you have the orginal
source tree and your patch provides the cygwin specific changes or
oposite. Actually this may you apply the patch to produce the orginal
source tree.
Probably nobody complained because nobody dared look at the monstrous 
pile-o-code that those two large packages entail.  I know I didn't.

3) Any particular reason you have the make and install logs in
  CYGWIN-PATCHES?  Also, the make log contains a warning that looks
  suspicious, and the install log shows that "make install" will install
  files directly into /usr/bin, rather than to a subdirectory.  Also,
  "make install" will not put the Cygwin-specific README in the right
  directory.


historical. AFAIK some people have been doing this for "documentation
purpose" while building packages. The log files may be helpful in
identifing possible problems that someone may observe on his local
installation.
Meh.  IMO this is a developer prerogative.  Do as you like.

Is it really required to patch Makefiles in order to "install" the
cygwin specific README to the ..doc/Cygwin place?! I consider this an
unneading hacking in sources. 
Not at all.  The method 2 package script does this manually.  (e.g part 
of "./script install" -- which calls 'make install' and then does the 
"extra stuff".

IMO, sources should be changed as minimally as required.
Yep.

-s linker flag put in place again (was a simple typo). So we get
stripping again. I don't see any needs for port notes to be honest.
Agree (with Stipe).  There's no need to repeat, in every package for 
cygwin, "yep, used --prefix=/usr on THIS package, too!"

8) There is a bug that the file size is declared as u_long, and will be
  truncated for large files.  Why not simply change it to off_t?


any scenario you can give that reproduces this?!
Sure: files larger than 2GiB.  off_t == off64_t == long long with 
cygwin-1.5.x, while "u_long" is just 32 bits IIRC.

--
Chuck

Re: [Review - not yet] Re: [ITP] tree

2003-12-18 Thread Igor Pechtchanski 
On Thu, 18 Dec 2003, Stipe Tolj wrote:

> Igor Pechtchanski wrote:
> >
> > Hmm, I guess it's not that important.  I was just going by what's on
> > , which clearly states that applying the
> > patch *in reverse* should get you the original sources...
>
> hmm, isn't it the case?!

Nope:
$ patch -p1 -R < CYGWIN-PATCHES/tree-1.4-1.patch
patching file Makefile
Unreversed patch detected!  Ignore -R? [n] n
Apply anyway? [n] n
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file Makefile.rej

> > > > 3) Any particular reason you have the make and install logs in
> > > >CYGWIN-PATCHES?  Also, the make log contains a warning that looks
> > > >suspicious, and the install log shows that "make install" will install
> > > >files directly into /usr/bin, rather than to a subdirectory.  Also,
> > > >"make install" will not put the Cygwin-specific README in the right
> > > >directory.
> > >
> > > historical. AFAIK some people have been doing this for "documentation
> > > purpose" while building packages. The log files may be helpful in
> > > identifing possible problems that someone may observe on his local
> > > installation.
> >
> > True.  It's usually a good idea, though, to be able to install somewhere
> > outside of the main tree (e.g., to recreate the package without polluting
> > your system)...  I'm not sure how important it is that a package is able
> > to do this.
>
> personally I'm not "required" to put the build logs into the tree.
> That's right.
>
> What do the others mean. I haven't followed the list for "some while"
> (no comments on this please ;). So I'm for sure out-of-sync regarding
> the "commen behaviour"?!

Umm, I was actually referring to the fact that the installation cannot be
redirected to a subdirectory...  I'm ok with the logs being included,
FWIW.

> > I agree, that's why method 2 became popular, since you don't have to
> > change the Makefiles for some of the Cygwin-specific stuff.  But if you
> > stick with method 1, the users should be able to fully install the package
> > using "make install"...
>
> now, I'd like to take method 2, but the package does not provide and
> sophisticated autoconf suite, only the raw Makefile. And actually for
> one .c file this is ok ;)

:-)  Take a look at the wtf package...  It's not autotooled either.  And
it uses method 2.

> > Well, I think changing the prefix from /usr/local to /usr is a pretty
> > serious change, in a sense that someone familiar with the package and
> > wanting to install it on their system will download it, run "make; make
> > install", and get the packages in /usr/bin instead of /usr/local/bin where
> > they would expect them.  IMO, it deserves a mention in the port notes, but
> > I'm not going to hold up the release of a package because of this.
>
> agreed. But don't we consider *all* packages that are installed from
> setup.exe to be "system packages" and hence reside underneath the
> system /usr mount point. In contrast to those who are compiled and
> build by users on their own, which usually go to /usr/local?!?!
>
> I changed the same semantics for Apache. Apache usualy has its
> instllation layout into /usr/local/apache and we addopted the
> "cygwin-way" to Apache's layout config file to reflect that it is then
> "a system package".

Ok.  It's a minor point, anyway.

> > Well, I don't have any 4G+ files on my system, but it's easy to see that
> > anything with size over 4G will be displayed incorrectly.
> >
> > In fact, most of the LINUX_BIGFILE code should be turned on, except that
> > the types are wrong in some places ("long long" instead of off_t), and
> > Cygwin has no such thing as "struct stat64" - its "struct stat" is 64-bit
> > already.
>
> ok, I'll give it a try... let's see how far I get.

Well, turns out I was wrong.  The only LINUX_BIGFILE code that should have
been enabled was the printf in line 521...  You could probably just make
it conditional on LINUX_BIGFILE *or* __CYGWIN__...

> > I'll point out that some of the types in "struct _info" are all wrong for
> > Cygwin (mode should be mode_t, uid should be uid_t, gid should be gid_t,
> > and size should be off_t).
>
> ok, I'll consider this too.

Actually, consider also changing the '#define _LARGEFILE64_SOURCE' in the
LINUX_BIGFILE block to '#define _FILE_OFFSET_BITS 64', removing the
'#ifdef LINUX_BIGFILE...#else' block from "struct _info" (off_t will
already mean the right thing in that case), and submitting this patch
upstream.

> > Cool.  Let me know when I can download a new version.
>
> I'll give it a try ASAP.
>
> Stipe
> mailto:[EMAIL PROTECTED]

Thanks,
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since com

Re: [Review - not yet] Re: [ITP] tree

2003-12-18 Thread Stipe Tolj 
Igor Pechtchanski wrote:
> 
> Hmm, I guess it's not that important.  I was just going by what's on
> , which clearly states that applying the
> patch *in reverse* should get you the original sources...

hmm, isn't it the case?!

> > > 3) Any particular reason you have the make and install logs in
> > >CYGWIN-PATCHES?  Also, the make log contains a warning that looks
> > >suspicious, and the install log shows that "make install" will install
> > >files directly into /usr/bin, rather than to a subdirectory.  Also,
> > >"make install" will not put the Cygwin-specific README in the right
> > >directory.
> >
> > historical. AFAIK some people have been doing this for "documentation
> > purpose" while building packages. The log files may be helpful in
> > identifing possible problems that someone may observe on his local
> > installation.
> 
> True.  It's usually a good idea, though, to be able to install somewhere
> outside of the main tree (e.g., to recreate the package without polluting
> your system)...  I'm not sure how important it is that a package is able
> to do this.

personally I'm not "required" to put the build logs into the tree.
That's right. 

What do the others mean. I haven't followed the list for "some while"
(no comments on this please ;). So I'm for sure out-of-sync regarding
the "commen behaviour"?!

> I agree, that's why method 2 became popular, since you don't have to
> change the Makefiles for some of the Cygwin-specific stuff.  But if you
> stick with method 1, the users should be able to fully install the package
> using "make install"...

now, I'd like to take method 2, but the package does not provide and
sophisticated autoconf suite, only the raw Makefile. And actually for
one .c file this is ok ;)

> Well, I think changing the prefix from /usr/local to /usr is a pretty
> serious change, in a sense that someone familiar with the package and
> wanting to install it on their system will download it, run "make; make
> install", and get the packages in /usr/bin instead of /usr/local/bin where
> they would expect them.  IMO, it deserves a mention in the port notes, but
> I'm not going to hold up the release of a package because of this.

agreed. But don't we consider *all* packages that are installed from
setup.exe to be "system packages" and hence reside underneath the
system /usr mount point. In contrast to those who are compiled and
build by users on their own, which usually go to /usr/local?!?!

I changed the same semantics for Apache. Apache usualy has its
instllation layout into /usr/local/apache and we addopted the
"cygwin-way" to Apache's layout config file to reflect that it is then
"a system package".

> Well, I don't have any 4G+ files on my system, but it's easy to see that
> anything with size over 4G will be displayed incorrectly.
> 
> In fact, most of the LINUX_BIGFILE code should be turned on, except that
> the types are wrong in some places ("long long" instead of off_t), and
> Cygwin has no such thing as "struct stat64" - its "struct stat" is 64-bit
> already.

ok, I'll give it a try... let's see how far I get.

> I'll point out that some of the types in "struct _info" are all wrong for
> Cygwin (mode should be mode_t, uid should be uid_t, gid should be gid_t,
> and size should be off_t).

ok, I'll consider this too.

> Cool.  Let me know when I can download a new version.

I'll give it a try ASAP.

Stipe

mailto:[EMAIL PROTECTED]
---
Wapme Systems AG

Münsterstr. 248
40470 Düsseldorf, NRW, Germany

phone: +49.211.74845.0
fax: +49.211.74845.299

mailto:[EMAIL PROTECTED]
http://www.wapme-systems.de/
---

-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.2.2 (Cygwin)

mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS
OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2
nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT
dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv
bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID
AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl
OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ
K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H
g2HyLAEKQIp30Q==
=aYCI
-END PGP PUBLIC KEY BLOCK-

Re: [Review - not yet] Re: [ITP] tree

2003-12-18 Thread Igor Pechtchanski 
On Thu, 18 Dec 2003, Stipe Tolj wrote:

> Igor Pechtchanski wrote:
> >
> > Sounds interesting.  I'll vote for this.
>
> I'll update this after we resolve this issues here.
>
> > Now for the review:
> > [snip]
> > 2) This uses method 1 packaging.  AFAIU, the patch in CYGWIN-PATCHES
> >should still be a forward patch.  Yours is reverse.
>
> I did reverse patching for thre previous packages apache, php, etc
> too. Non was objected until know. AFAIK, either you have the orginal
> source tree and your patch provides the cygwin specific changes or
> oposite. Actually this may you apply the patch to produce the orginal
> source tree.

Hmm, I guess it's not that important.  I was just going by what's on
, which clearly states that applying the
patch *in reverse* should get you the original sources...

> > 3) Any particular reason you have the make and install logs in
> >CYGWIN-PATCHES?  Also, the make log contains a warning that looks
> >suspicious, and the install log shows that "make install" will install
> >files directly into /usr/bin, rather than to a subdirectory.  Also,
> >"make install" will not put the Cygwin-specific README in the right
> >directory.
>
> historical. AFAIK some people have been doing this for "documentation
> purpose" while building packages. The log files may be helpful in
> identifing possible problems that someone may observe on his local
> installation.

True.  It's usually a good idea, though, to be able to install somewhere
outside of the main tree (e.g., to recreate the package without polluting
your system)...  I'm not sure how important it is that a package is able
to do this.

> Is it really required to patch Makefiles in order to "install" the
> cygwin specific README to the ..doc/Cygwin place?! I consider this an
> unneading hacking in sources.
>
> IMO, sources should be changed as minimally as required.

I agree, that's why method 2 became popular, since you don't have to
change the Makefiles for some of the Cygwin-specific stuff.  But if you
stick with method 1, the users should be able to fully install the package
using "make install"...

> [snip]
> > 5) There are no port notes in the Cygwin-specific README, even though
> >there are some user-visible changes in the patch, such as changing the
> >prefix to /usr and removing the "-s" linker flag (any particular reason
> >why you did that?)
>
> -s linker flag put in place again (was a simple typo). So we get
> stripping again. I don't see any needs for port notes to be honest.

Well, I think changing the prefix from /usr/local to /usr is a pretty
serious change, in a sense that someone familiar with the package and
wanting to install it on their system will download it, run "make; make
install", and get the packages in /usr/bin instead of /usr/local/bin where
they would expect them.  IMO, it deserves a mention in the port notes, but
I'm not going to hold up the release of a package because of this.

> > 8) There is a bug that the file size is declared as u_long, and will be
> >truncated for large files.  Why not simply change it to off_t?
>
> any scenario you can give that reproduces this?!

Well, I don't have any 4G+ files on my system, but it's easy to see that
anything with size over 4G will be displayed incorrectly.

In fact, most of the LINUX_BIGFILE code should be turned on, except that
the types are wrong in some places ("long long" instead of off_t), and
Cygwin has no such thing as "struct stat64" - its "struct stat" is 64-bit
already.

I'll point out that some of the types in "struct _info" are all wrong for
Cygwin (mode should be mode_t, uid should be uid_t, gid should be gid_t,
and size should be off_t).

> > I think this is it.  A lot of the above is very easy to fix, so we'll wait
> > for a new installment soon, eh? ;-)
>
> let's get this going.

Cool.  Let me know when I can download a new version.

> BTW, @Volker: you should have voted to the -apps list too ;)
> Stipe

-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

Re: [Review - not yet] Re: [ITP] tree

2003-12-18 Thread Stipe Tolj 
Igor Pechtchanski wrote:
> 
> Sounds interesting.  I'll vote for this.

I'll update this after we resolve this issues here.

> Now for the review:
> 
> 1) The documentation is still in /usr/doc and /usr/man...  Any plans on
>moving it to /usr/share/{doc,man}?

ok, changed.

> 2) This uses method 1 packaging.  AFAIU, the patch in CYGWIN-PATCHES
>should still be a forward patch.  Yours is reverse.

I did reverse patching for thre previous packages apache, php, etc
too. Non was objected until know. AFAIK, either you have the orginal
source tree and your patch provides the cygwin specific changes or
oposite. Actually this may you apply the patch to produce the orginal
source tree.

> 3) Any particular reason you have the make and install logs in
>CYGWIN-PATCHES?  Also, the make log contains a warning that looks
>suspicious, and the install log shows that "make install" will install
>files directly into /usr/bin, rather than to a subdirectory.  Also,
>"make install" will not put the Cygwin-specific README in the right
>directory.

historical. AFAIK some people have been doing this for "documentation
purpose" while building packages. The log files may be helpful in
identifing possible problems that someone may observe on his local
installation.

Is it really required to patch Makefiles in order to "install" the
cygwin specific README to the ..doc/Cygwin place?! I consider this an
unneading hacking in sources. 

IMO, sources should be changed as minimally as required.

> 4) The file list in the Cygwin-specific README mentions /usr/bin/tree, and
>not /usr/bin/tree.exe, which, IMO, is misleading.

ok, changed.

> 5) There are no port notes in the Cygwin-specific README, even though
>there are some user-visible changes in the patch, such as changing the
>prefix to /usr and removing the "-s" linker flag (any particular reason
>why you did that?)

-s linker flag put in place again (was a simple typo). So we get
stripping again. I don't see any needs for port notes to be honest.

> 6) I don't see a "strip" step anywhere in the installation process
>(although the executable in the binary tarball is stripped).  That's
>actually what the -s linker flag does...

(see above)

> 7) There is a bug in the printing of inode numbers, since ino_t is 64-bit
>in Cygwin now, and it's printed using "%ld" (tree.c:515).

yep, patched.

> 8) There is a bug that the file size is declared as u_long, and will be
>truncated for large files.  Why not simply change it to off_t?

any scenario you can give that reproduces this?!

> I think this is it.  A lot of the above is very easy to fix, so we'll wait
> for a new installment soon, eh? ;-)

let's get this going.

BTW, @Volker: you should have voted to the -apps list too ;)

Stipe

mailto:[EMAIL PROTECTED]
---
Wapme Systems AG

Münsterstr. 248
40470 Düsseldorf, NRW, Germany

phone: +49.211.74845.0
fax: +49.211.74845.299

mailto:[EMAIL PROTECTED]
http://www.wapme-systems.de/
---

-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.2.2 (Cygwin)

mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS
OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2
nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT
dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv
bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID
AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl
OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ
K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H
g2HyLAEKQIp30Q==
=aYCI
-END PGP PUBLIC KEY BLOCK-

[Review - not yet] Re: [ITP] tree

2003-12-18 Thread Igor Pechtchanski 
On Thu, 18 Dec 2003, Stipe Tolj wrote:
Re: [ITP] tree: Recursive directory listing program that produces a depth indented 
listing of files

> Hi list,
>
> this is a quick one. Canonical homepage is:
>
>   http://mama.indstate.edu/users/ice/tree/
>
> --setup.hint--
> sdesc: "Recursive directory listing program that produces a depth
> indented listing of files"
> category: Utils
> requires: cygwin
> ldesc: "Tree is a recursive directory listing program that produces
> a depth indented listing of files, which is colorized ala dircolors
> if the LS_COLORS environment variable is set and output is to tty."
> --setup.hint--
>
> --cut--
> #!/bin/bash
>
> mkdir -p tree
> cd tree
>
> wget 
> http://cygwin.dev.wapme.net/packages/tolj/cygwin/release/tree/tree-1.4-1-src.tar.bz2
> wget http://cygwin.dev.wapme.net/packages/tolj/cygwin/release/tree/tree-1.4-1.md5sum
> wget http://cygwin.dev.wapme.net/packages/tolj/cygwin/release/tree/tree-1.4-1.tar.bz2
> wget http://cygwin.dev.wapme.net/packages/tolj/cygwin/release/tree/setup.hint
> --cut--
>
> Please review and vote for upload.
>
> Stipe

Sounds interesting.  I'll vote for this.

Now for the review:

1) The documentation is still in /usr/doc and /usr/man...  Any plans on
   moving it to /usr/share/{doc,man}?

2) This uses method 1 packaging.  AFAIU, the patch in CYGWIN-PATCHES
   should still be a forward patch.  Yours is reverse.

3) Any particular reason you have the make and install logs in
   CYGWIN-PATCHES?  Also, the make log contains a warning that looks
   suspicious, and the install log shows that "make install" will install
   files directly into /usr/bin, rather than to a subdirectory.  Also,
   "make install" will not put the Cygwin-specific README in the right
   directory.

4) The file list in the Cygwin-specific README mentions /usr/bin/tree, and
   not /usr/bin/tree.exe, which, IMO, is misleading.

5) There are no port notes in the Cygwin-specific README, even though
   there are some user-visible changes in the patch, such as changing the
   prefix to /usr and removing the "-s" linker flag (any particular reason
   why you did that?)

6) I don't see a "strip" step anywhere in the installation process
   (although the executable in the binary tarball is stripped).  That's
   actually what the -s linker flag does...

7) There is a bug in the printing of inode numbers, since ino_t is 64-bit
   in Cygwin now, and it's printed using "%ld" (tree.c:515).

8) There is a bug that the file size is declared as u_long, and will be
   truncated for large files.  Why not simply change it to off_t?

I think this is it.  A lot of the above is very easy to fix, so we'll wait
for a new installment soon, eh? ;-)
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton