Re: [ITP] openldap-devel: Lightweight Directory Access Protocol clients and libraries

[Dr. Volker Zell]

> "Daniel" == Daniel Reed writes:

Daniel> There does not seem to be much precedent for having a "package" that only
Daniel> has a -devel; the closest appears to be "db", which looks to be more of a
Daniel> grouping of similar packages (but feel free to look for yourself in case I
Daniel> missed another example).

Daniel> Typically -devel packages are subordinate to [and built from] some other
Daniel> package. There are .exe files in this -devel, so it might make sense to 
move
Daniel> at least those (and usr/share/*) into an actual "openldap" package, and
Daniel> leave the manual pages, headers, and static libraries in -devel.

If I find time today I'll repackage ...

Daniel> Daniel Reed

Ciao
  Volkre

Re: [ITP] openldap-devel: Lightweight Directory Access Protocol clients and libraries

[Dr. Volker Zell]

> "Stipe" == Stipe Tolj <[EMAIL PROTECTED]> writes:

Stipe> Volker,
Stipe> trying to reproduce your issue I run into:

Stipe> ...
Stipe> checking to see if -lrpcrt4 is needed for win32 UUID support... no
Stipe> checking for res_query... no
Stipe> checking for __res_query... no
Stipe> checking for res_query in -lbind... no
Stipe> checking for __res_query in -lbind... no
Stipe> checking for res_query in -lresolv... no
Stipe> checking for __res_query in -lresolv... no
Stipe> configure: error: DNSSRV requires res_query()

Do you have minires and minires-devel installed. The postinstall script
of minires-devel sets up a symbolic link libresolv.a:

#! /bin/sh
set -e
if [ ! -e /usr/lib/libresolv.a ]
  then
  if [ -L /usr/lib/libresolv.a ]
then
/bin/rm -f /usr/lib/libresolv.a
  fi
  ln -s /usr/lib/libminires.dll.a /usr/lib/libresolv.a
fi

Stipe> while configure runs. So I'm wondering which resolver lib you have
Stipe> been using?!

Stipe> Stipe

Ciao
  Volker

PS: By the way . apache .

Re: [ITP] openldap-devel: Lightweight Directory Access Protocol clients and libraries

[Stipe Tolj]

"Dr. Volker Zell" schrieb:
> 
> Do you have minires and minires-devel installed. The postinstall script
> of minires-devel sets up a symbolic link libresolv.a:
> 
> #! /bin/sh
> set -e
> if [ ! -e /usr/lib/libresolv.a ]
>   then
>   if [ -L /usr/lib/libresolv.a ]
> then
> /bin/rm -f /usr/lib/libresolv.a
>   fi
>   ln -s /usr/lib/libminires.dll.a /usr/lib/libresolv.a
> fi

have to check... thanks for the hint.

> PS: By the way . apache .

working on it... Apache is finished, but I'd like to test the whole
bunch including the new php package, that's why the delay takes place.
But we'll kick it as Xmas present I guess ;)

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: [ITP - with packages] xemacs: A powerful, highly customizable open source text editor and application development system

[Dr. Volker Zell]

Hi

Please redownload xemacs when you want to test as there was a packaging error
and I forgot to include widget support.

 cut here 
#!/bin/bash

mkdir -p xemacs
cd xemacs

wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/xemacs/setup.hint
wget 
http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/xemacs/xemacs-21.4.14-1-src.tar.bz2
wget 
http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/xemacs/xemacs-21.4.14-1.tar.bz2
 cut here 


Ciao
  Volker

Re: [ITP] ccrypt: A utility for encrypting and decrypting files and streams

[Stipe Tolj]

Andreas Seidl wrote:
> 
> I would like to contribute and maintain ccrypt:
> 
> * http://quasar.mathstat.uottawa.ca/~selinger/ccrypt/  (Homepage)
> * http://quasar.mathstat.uottawa.ca/~selinger/ccrypt/download/ccrypt-1.6.tar.gz
>(Download)
> 
> Obtaining this package for review:
> 
> wget 
> http://alice.fmi.uni-passau.de/~seidl/cygwin/release/ccrypt/ccrypt-1.6-1-src.tar.bz2
> wget http://alice.fmi.uni-passau.de/~seidl/cygwin/release/ccrypt/ccrypt-1.6-1.tar.bz2
> wget http://alice.fmi.uni-passau.de/~seidl/cygwin/release/ccrypt/setup.hint
> 
> Alternatively, this package can be downloaded and installed through
> setup.exe by adding http://alice.fmi.uni-passau.de/~seidl/cygwin to your
> server list.
> 
> - setup.hint -
> sdesc: "A utility for encrypting and decrypting files and streams"
> category: Utils
> requires: cygwin
> ldesc: "ccrypt is a utility for encrypting and decrypting files and
> streams. It was designed as a replacement for the standard unix crypt
> utility, which is notorious for using a very weak encryption
> algorithm. ccrypt is based on the Rijndael cipher, which is the
> U.S. government's chosen candidate for the Advanced Encryption
> Standard (AES, see http://www.nist.gov/aes/). This cipher is believed
> to provide very strong security.
> 
> Unlike unix crypt, the algorithm provided by ccrypt is not symmetric,
> i.e., one must specify whether to encrypt or decrypt. The most common
> way to invoke ccrypt is via the commands ccencrypt and
> ccdecrypt. There is also a ccat command for decrypting a file directly
> to the terminal, thus reducing the likelihood of leaving temporary
> plaintext files around. In addition, there is a compatibility mode for
> decrypting legacy unix crypt files. An emacs mode is also supplied for
> editing encrypted text files."
> - end -

the packages has my +1 vote to go.

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-

[ITP] tree: Recursive directory listing program that produces a depth indented listing of files

[Stipe Tolj]

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

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

[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

Heads-up: cygrunsrv-0.97-1 never announced

[Igor Pechtchanski]

On Sun, 7 Dec 2003, Corinna Vinschen wrote:

> On Dec  5 18:00, Brian Ford wrote:
> > 2003-12-05  Brian Ford  <[EMAIL PROTECTED]>
> >
> >   * cygrunsrv.cc (terminate_child): Send the signal to the whole
> >   processes group.
> >
> > --- cygrunsrv.cc  2003-12-05 17:48:26.25000 -0600
> > +++ cygrunsrv.cc.orig 2003-12-05 17:48:13.52000 -0600
> > @@ -978,7 +978,7 @@ terminate_child ()
> >sleep (1);
> >  else
> >{
> > - kill (-server_pid, termsig);
> > + kill (server_pid, termsig);
> >   report_service_status ();
> >   return 0;
> >}
>
> Thanks, I've just uploaded a new version of cygrunsrv which contains
> this patch.
>
> Corinna

BTW, this was never announced.
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

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

[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-

Re: Heads-up: cygrunsrv-0.97-1 never announced

[Corinna Vinschen]

On Dec 18 11:38, Igor Pechtchanski wrote:
> BTW, this was never announced.
>   Igor

Uh, yes.  Thanks for the heads up.

Corinna

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

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

[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

[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

[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

[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