Re: [RFU] ddrescue-1.8-1

2008-02-26 Thread Corinna Vinschen
On Feb 25 21:07, Christian Franke wrote:
 Please upload:

 wget \
  http://franke.dvrdns.org/cygwin/release/ddrescue/ddrescue-1.8-1.tar.bz2 \
  
 http://franke.dvrdns.org/cygwin/release/ddrescue/ddrescue-1.8-1-src.tar.bz2

 and remove 1.4-1.

Done.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat


Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]

2008-02-26 Thread Dave Korn
On 24 February 2008 14:13, Dave Korn wrote:

 On 23 February 2008 21:51, Dave Korn wrote:
 
   The solution has two parts then: 

   And here is part 1.


  No comments then?  I'll apply it sometime tonight or tomorrow if nobody
objects.

  Meanwhile (here's the RFC part), my suggestion for part 2 is attached
(merged into part 1).  It's pretty crude: it disables and reenables the cancel
button around each call to Installer::installOne().  This probably doesn't
stop the user from pressing the cancel key or clicking the X close box,
although I haven't tested that yet.  I would be interested in hearing from
anyone who reckons they do know the proper way to do this.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


setup-modal-dialogs-patch-2.diff
Description: Binary data


Re: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]

2008-02-26 Thread Brian Dessent
Dave Korn wrote:

And here is part 1.
 
   No comments then?  I'll apply it sometime tonight or tomorrow if nobody
 objects.

Well, you labeled it as part 1 and so I mentally said, okay, I'll
take a look at this whenever it's complete.

   Meanwhile (here's the RFC part), my suggestion for part 2 is attached
 (merged into part 1).  It's pretty crude: it disables and reenables the cancel
 button around each call to Installer::installOne().  This probably doesn't
 stop the user from pressing the cancel key or clicking the X close box,
 although I haven't tested that yet.  I would be interested in hearing from
 anyone who reckons they do know the proper way to do this.

Ick.  I don't really like that.  It seems to me that we simply don't
support canceling in any sane way once the installation step has begun. 
Even if we are able to cancel cleanly at a point in between unpacking
two packages, that still could leave the system in a horrid state --
missing dependencies, postinstalls not run, etc.  We should disable the
button for the entirety.

Brian


RE: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]

2008-02-26 Thread Dave Korn
On 26 February 2008 13:59, Brian Dessent wrote:

 Dave Korn wrote:
 
   And here is part 1.
 
   No comments then?  I'll apply it sometime tonight or tomorrow if nobody
 objects.
 
 Well, you labeled it as part 1 and so I mentally said, okay, I'll
 take a look at this whenever it's complete.

  Ah, no, I intended to break out and submit the separate parts of the patch
incrementally, sorry for any confusion.

   Meanwhile (here's the RFC part), my suggestion for part 2 is attached
 (merged into part 1).  It's pretty crude: it disables and reenables the
 cancel button around each call to Installer::installOne().  This probably
 doesn't stop the user from pressing the cancel key or clicking the X
 close box, although I haven't tested that yet.  I would be interested in
 hearing from anyone who reckons they do know the proper way to do this.
 
 Ick.  I don't really like that.  

  Just the reason why I wanted to keep the uncontroversial bits separate from
the more obviously-correct bits!

 It seems to me that we simply don't
 support canceling in any sane way once the installation step has begun.
 Even if we are able to cancel cleanly at a point in between unpacking
 two packages, that still could leave the system in a horrid state --
 missing dependencies, postinstalls not run, etc.  We should disable the
 button for the entirety.

  Right, I'll rework part 2 on that approach.

  Meanwhile, part 1 OK for trunk? 


cheers,
  DaveK
-- 
Can't think of a witty .sigline today



Re: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]

2008-02-26 Thread Igor Peshansky
On Tue, 26 Feb 2008, Brian Dessent wrote:

 Dave Korn wrote:

 And here is part 1.
 
No comments then?  I'll apply it sometime tonight or tomorrow if
  nobody objects.

 Well, you labeled it as part 1 and so I mentally said, okay, I'll
 take a look at this whenever it's complete.

Meanwhile (here's the RFC part), my suggestion for part 2 is
  attached (merged into part 1).  It's pretty crude: it disables and
  reenables the cancel button around each call to
  Installer::installOne().  This probably doesn't stop the user from
  pressing the cancel key or clicking the X close box, although I
  haven't tested that yet.  I would be interested in hearing from anyone
  who reckons they do know the proper way to do this.

 Ick.  I don't really like that.  It seems to me that we simply don't
 support canceling in any sane way once the installation step has begun.
 Even if we are able to cancel cleanly at a point in between unpacking
 two packages, that still could leave the system in a horrid state --
 missing dependencies, postinstalls not run, etc.  We should disable the
 button for the entirety.

I don't like Dave's proposal either.  However, simply disabling the
Cancel button altogether is not the solution -- if the user is unable to
interrupt the installation, she will just kill the process, with
disastrous results.

The question is: what kind of behavior do we really want in case of
cancellation?  If we want setup to stop whatever it's doing (dependences,
etc, aside), but be able to resume at a later point to fix the state of
the system, then Dave's part 1 is the right approach.  If we want setup
to always leave the system in a sane state, even when it's interrupted,
then we should capture the exit message and figure out how to clean up the
missing dependences.

Keep in mind that processes can be killed in a way that isn't capturable,
so setup *will* leave corrupt listing files and missing dependences in
some cases.  Making sure setup does not crash when restarted after such
cases is probably the best we can do.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

That which is hateful to you, do not do to your neighbor.  That is the whole
Torah; the rest is commentary.  Go and study it. -- Rabbi Hillel


Re: [ITP] suck 4.3.2 -- Small newsfeed from an NNTP server with standard NNTP commands

2008-02-26 Thread Dr. Volker Zell
 Jari Aalto writes:

 Included in Debian stable

 http://packages.debian.org/unstable/suck

Builds fine from source and packaging looks good.

setup.hint needs libgdbm4 in it's require line. suck depends on it.

Ciao
  Volker


[RFU] speex-1.2beta3-1

2008-02-26 Thread David Rothenberger
Here are new speex packages updating to upstream 1.2beta3.

wget -x -nH --cut-dirs=2 \
  http://mysite.verizon.net/res00a7j/cygwin/speex/speex-1.2beta3-1-src.tar.bz2 \
  http://mysite.verizon.net/res00a7j/cygwin/speex/speex-1.2beta3-1.tar.bz2 \
  http://mysite.verizon.net/res00a7j/cygwin/speex/setup.hint \
  
http://mysite.verizon.net/res00a7j/cygwin/speex/libspeex1/libspeex1-1.2beta3-1.tar.bz2
 \
  http://mysite.verizon.net/res00a7j/cygwin/speex/libspeex1/setup.hint \
  http://mysite.verizon.net/res00a7j/cygwin/speex/speex-devel/setup.hint \
  
http://mysite.verizon.net/res00a7j/cygwin/speex/speex-devel/speex-devel-1.2beta3-1.tar.bz2

-- 
David Rothenberger    [EMAIL PROTECTED]

White's Statement:
Don't lose heart!

Owen's Commentary on White's Statement:
...they might want to cut it out...

Byrd's Addition to Owen's Commentary:
...and they want to avoid a lengthy search.



Re: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]

2008-02-26 Thread Brian Dessent
Dave Korn wrote:

   Meanwhile, part 1 OK for trunk?

Yes, I think making that dialog modal is good.

Igor Peshansky wrote:

 I don't like Dave's proposal either.  However, simply disabling the
 Cancel button altogether is not the solution -- if the user is unable to
 interrupt the installation, she will just kill the process, with
 disastrous results.

Yes, but there will always be a way for the user to shoot themselves in
the foot.  The best we can do is try to make it harder to find the
bullets.  Right now it's quite easy to get into trouble since we allow
arbitrarily stopping the install at any point.  I think disabling the
Cancel button (and the close 'X' button) for the entire install phase
does put us at a better place than we're at now.  Even if they look up
the PID of setup and kill it that way, it's still no worse than what we
have now.  The sad fact is that we don't truly support canceling in any
sane form, so we shouldn't advertise that ability in the UI.  The fact
that you can usually repair things by just rerunning setup (and
especially so now that a corrupt .lst doesn't kill the party) is good,
but it doesn't mean we should rely on this.  To really do this right
(e.g. how MSI can rollback to the starting state midway through a
aborted install) is a tremendous amount of work that I don't think
anyone here is prepared to take on.

Brian


RE: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]

2008-02-26 Thread Dave Korn
On 26 February 2008 14:55, Igor Peshansky wrote:

 The question is: what kind of behavior do we really want in case of
 cancellation?  If we want setup to stop whatever it's doing (dependences,
 etc, aside), but be able to resume at a later point to fix the state of
 the system, then Dave's part 1 is the right approach.  If we want setup
 to always leave the system in a sane state, even when it's interrupted,
 then we should capture the exit message and figure out how to clean up the
 missing dependences.

  You've somewhat missed the point.  The justification for part 1 is that,
entirely orthogonal to and regardless of whatever else we do, those dialog
boxes should be modal and they aren't.  It Is Just Plain Wrong.

  It is a fortuitous side-effect of making them correctly modal that it
becomes slightly trickier to accidentally cancel an installation when you
thought you were just cancelling an individual pop-up request.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today



[GTG] Re: [ITP] VOTE: ctorrent 1.3.4 -- BitTorrent client written in C++

2008-02-26 Thread Dr. Volker Zell
 Jari Aalto writes:

 Included in Debian testing. Need votes.

+1

 http://packages.debian.org/ctorrent

Builds fine from source, packaging and setup.hint look good.

Ciao
  Volker


[GTG] Re: [ITP] planet 2.0 -- Flexible RDF, RSS and Atom feed aggregator

2008-02-26 Thread Dr. Volker Zell
 Jari Aalto writes:

 Icluded in Debian stable

 http://packages.debian.org/planet

Builds fine from source, packaging and setup.hint look good.

GTG
  Volker


RE: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]

2008-02-26 Thread Dave Korn
On 26 February 2008 15:24, Brian Dessent wrote:

 Dave Korn wrote:
 
   Meanwhile, part 1 OK for trunk?
 
 Yes, I think making that dialog modal is good.

  Thanks, will commit at a convenient moment.

 Igor Peshansky wrote:
 
 I don't like Dave's proposal either.  However, simply disabling the
 Cancel button altogether is not the solution -- if the user is unable to
 interrupt the installation, she will just kill the process, with
 disastrous results.
 
 Yes, but there will always be a way for the user to shoot themselves in
 the foot.  The best we can do is try to make it harder to find the
 bullets.  

  Hear hear.  I'm just focussed on helping the end-users avoid trouble to make
the package friendlier.

  Right now it's quite easy to get into trouble since we allow
 arbitrarily stopping the install at any point.  I think disabling the
 Cancel button (and the close 'X' button) for the entire install phase
 does put us at a better place than we're at now.  Even if they look up
 the PID of setup and kill it that way, it's still no worse than what we
 have now.

  Anyone who's clever enough to attach a debugger to it, I don't need to help.

   The sad fact is that we don't truly support canceling in any
 sane form, so we shouldn't advertise that ability in the UI.  

  Ditto.  I just want to help people avoid unexpected consequences of what
might seem like reasonable actions.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today



[GTG] Re: [ITP] urlgrabber 3.1.0 -- Python based URL grabber

2008-02-26 Thread Dr. Volker Zell
 Jari Aalto writes:

 Included in Debian stable

 http://packages.debian.org/python-urlgrabber

Builds fine from source, packaging and setup.hint look good.

GTG
  Volker


Re: [ITP] ipcalc 0.41 -- Parameter calculator for IPv4 addresses

2008-02-26 Thread Dr. Volker Zell
 Jari Aalto writes:

 Included in Debian stable

 http://packages.debian.org/unstable/ipcalc

04:37 PM [510] ./ipcalc-0.41-1.sh --color all
## cygbuild 2008.0225.2252 http://freshmeat.net/projects/cygbuild
-- [NOTE] command [all] is used for checking build procedure only. See -h for 
source development options.
== Verifying signatures in /misc/src
-- [prep] Skipping Cygwin patch; source already unpacked
-- [NOTE] applying included patches to sources (if any)
-- Patching with CYGWIN-PATCHES/0001-Makefile-new-file.patch
The next patch would create the file Makefile,
which already exists!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file Makefile.rej
-- [FATAL] Exiting.


RE: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]

2008-02-26 Thread Igor Peshansky
On Tue, 26 Feb 2008, Dave Korn wrote:

 On 26 February 2008 14:55, Igor Peshansky wrote:

  The question is: what kind of behavior do we really want in case of
  cancellation?  If we want setup to stop whatever it's doing
  (dependences, etc, aside), but be able to resume at a later point to
  fix the state of the system, then Dave's part 1 is the right
  approach.  If we want setup to always leave the system in a sane
  state, even when it's interrupted, then we should capture the exit
  message and figure out how to clean up the missing dependences.

   You've somewhat missed the point.  The justification for part 1 is
 that, entirely orthogonal to and regardless of whatever else we do,
 those dialog boxes should be modal and they aren't.  It Is Just Plain
 Wrong.

Sorry, I misspoke (mis-wrote?).  I meant to say that your part 1 takes
us towards that goal.  Also, in my morning confusion, I referred to the
fix for the corrupt lst.gz files as your part 1.  There is no question
that both were the right thing to do.

   It is a fortuitous side-effect of making them correctly modal that it
 becomes slightly trickier to accidentally cancel an installation when
 you thought you were just cancelling an individual pop-up request.

An alternative would be to pop up a warning box on Cancel that says that
this action may leave the system in an unstable state, and are you sure
you want to cancel?.  I'd still like to have the ability to cancel a long
install (preferably with the ability to fix things later by rerunning
setup).

Incidentally, we already get an incremental install from the way setup is
structured -- it will not re-download packages, and will rerun any
postinstall scripts remaining from the previous run.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

That which is hateful to you, do not do to your neighbor.  That is the whole
Torah; the rest is commentary.  Go and study it. -- Rabbi Hillel


Re: [ITP] VOTE: ctorrent 1.3.4 -- BitTorrent client written in C++

2008-02-26 Thread Corinna Vinschen
On Feb 25 18:01, Jari Aalto wrote:
 http://cygwin.cante.net/ctorrent/ctorrent-1.3.4-dnh3.2-1-src.tar.bz2 \
 http://cygwin.cante.net/ctorrent/ctorrent-1.3.4-dnh3.2-1.tar.bz2 \
 http://cygwin.cante.net/ctorrent/setup.hint

Uploaded.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat


Re: [ITP] planet 2.0 -- Flexible RDF, RSS and Atom feed aggregator

2008-02-26 Thread Corinna Vinschen
On Feb 25 19:20, Jari Aalto wrote:
 http://cygwin.cante.net/planet/planet-2.0-1-src.tar.bz2 \
 http://cygwin.cante.net/planet/planet-2.0-1.tar.bz2 \
 http://cygwin.cante.net/planet/setup.hint

Uploaded.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat


Re: [ITP] urlgrabber 3.1.0 -- Python based URL grabber

2008-02-26 Thread Corinna Vinschen
On Feb 25 23:32, Jari Aalto wrote:
 http://cygwin.cante.net/urlgrabber/urlgrabber-3.1.0-1-src.tar.bz2 \
 http://cygwin.cante.net/urlgrabber/urlgrabber-3.1.0-1.tar.bz2 \
 http://cygwin.cante.net/urlgrabber/setup.hint

Uploaded.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat


Re: [ITP] ipcalc 0.41 -- Parameter calculator for IPv4 addresses

2008-02-26 Thread Jari Aalto
* Tue 2008-02-26 Dr Dr [EMAIL PROTECTED]
* Message-Id: [EMAIL PROTECTED]
 Jari Aalto writes:

 04:37 PM [510] ./ipcalc-0.41-1.sh --color all
 ## cygbuild 2008.0225.2252 http://freshmeat.net/projects/cygbuild
 -- Patching with CYGWIN-PATCHES/0001-Makefile-new-file.patch
 The next patch would create the file Makefile,
 which already exists!  Skipping patch.
 1 out of 1 hunk ignored -- saving rejects to file Makefile.rej
 -- [FATAL] Exiting.

Fixed in latest build.

Jari

a) manual

  wget\
http://cygwin.cante.net/ipcalc/ipcalc-0.41-1-src.tar.bz2 \
http://cygwin.cante.net/ipcalc/ipcalc-0.41-1.tar.bz2 \
http://cygwin.cante.net/ipcalc/setup.hint

b) automated

  gpg --keyserver wwwkeys.pgp.net --recv-keys 955A92D8

  mkdir ipcalc ; cd ipcalc
  rm -f get.sh get.sh.sig
  wgethttp://cygwin.cante.net/ipcalc/get.sh \
  http://cygwin.cante.net/ipcalc/get.sh.sig 
  gpg --verify get.sh.sig get.sh 
  sh get.sh



-- 
Welcome to FOSS revolution: we fix and modify until it shines


Re: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]

2008-02-26 Thread Robert Collins
On Tue, 2008-02-26 at 07:24 -0800, Brian Dessent wrote:
 To really do this right
 (e.g. how MSI can rollback to the starting state midway through a
 aborted install) is a tremendous amount of work that I don't think
 anyone here is prepared to take on.

FWIW this is why I started porting dpkg to cygwin, way back when - it
was with the intent of getting a transaction packaging system without
writing one from scratch.

-Rob
-- 
GPG key available at: http://www.robertcollins.net/keys.txt.



signature.asc
Description: This is a digitally signed message part


Re: [ITP] suck 4.3.2 -- Small newsfeed from an NNTP server with standard NNTP commands

2008-02-26 Thread Jari Aalto
* Tue 2008-02-26 Dr Dr [EMAIL PROTECTED]
* Message-Id: [EMAIL PROTECTED]
 Jari Aalto writes:

  Included in Debian stable

  http://packages.debian.org/unstable/suck

 Builds fine from source and packaging looks good.

 setup.hint needs libgdbm4 in it's require line. suck depends on it.

Fixed.

  wget \
http://cygwin.cante.net/suck/suck-4.3.2-1-src.tar.bz2 \
http://cygwin.cante.net/suck/suck-4.3.2-1.tar.bz2 \
http://cygwin.cante.net/suck/setup.hint

-- 
Welcome to FOSS revolution: we fix and modify until it shines


[ITP] colorgcc 1.3.2 -- Colorizer for GCC warning/error messages

2008-02-26 Thread Jari Aalto

Included in Debian stable

http://packages.debian.org/colorgcc

Example:

make CC=colorgcc

Jari

sdesc: Colorizer for GCC warning/error messages
ldesc: A Perl wrapper to colorize the output of compilers with warning and
error messages matching the gcc output format.
category: Devel Perl
requires: cygwin perl

a) manual

  wget \
http://cygwin.cante.net/colorgcc/colorgcc-1.3.2-1-src.tar.bz2 \
http://cygwin.cante.net/colorgcc/colorgcc-1.3.2-1.tar.bz2 \
http://cygwin.cante.net/colorgcc/setup.hint

b) automated

  gpg --keyserver wwwkeys.pgp.net --recv-keys 955A92D8

  mkdir colorgcc ; cd colorgcc
  rm -f get.sh get.sh.sig
  wgethttp://cygwin.cante.net/colorgcc/get.sh \
  http://cygwin.cante.net/colorgcc/get.sh.sig 
  gpg --verify get.sh.sig get.sh 
  sh get.sh

-- 
Welcome to FOSS revolution: we fix and modify until it shines


[ITP] deroff 1.1 -- Remove roff and preprocessor constructs

2008-02-26 Thread Cygwin-bug#20080226T2350

Included in Debian stable:

http://packages.debian.org/deroff

Jari

sdesc: Remove roff and preprocessor constructs
ldesc: Program strips out roff constructs and macros. The preprocessor (eqn,
tbl, pic, grap, and vgrind) sections are removed entirely. The
resulting output is suitable for spelling with e.g. spell(1).
category: Utils
requires: cygwin

a) manual

 wget\
http://cygwin.cante.net/deroff/deroff-1.1-1-src.tar.bz2 \
http://cygwin.cante.net/deroff/deroff-1.1-1.tar.bz2 \
http://cygwin.cante.net/deroff/setup.hint

b) automated

  gpg --keyserver wwwkeys.pgp.net --recv-keys 955A92D8

  mkdir deroff ; cd deroff
  rm -f get.sh get.sh.sig
  wgethttp://cygwin.cante.net/deroff/get.sh \
  http://cygwin.cante.net/deroff/get.sh.sig 
  gpg --verify get.sh.sig get.sh 
  sh get.sh

-- 
Welcome to FOSS revolution: we fix and modify until it shines


[ITP] dog 1.7 -- Enhanced replacement for cat

2008-02-26 Thread Cygwin-bug#20080227T0044

Included in Debian stable:

http://packages.debian.org/unstable/dog

Jari

sdesc: Enhanced replacement for cat
ldesc: Program writes the contents of each given file, URL or standard input
to standard output. It currently supports file, http and raw URLs. It
is designed as a compatible, but enhanced replacement for cat.
category: Net
requires: cygwin

a) manual

  wget \
http://cygwin.cante.net/dog/dog-1.7-1-src.tar.bz2 \
http://cygwin.cante.net/dog/dog-1.7-1.tar.bz2 \
http://cygwin.cante.net/dog/setup.hint

b) automated

  gpg --keyserver wwwkeys.pgp.net --recv-keys 955A92D8

  mkdir dog ; cd dog
  rm -f get.sh get.sh.sig
  wgethttp://cygwin.cante.net/dog/get.sh \
  http://cygwin.cante.net/dog/get.sh.sig 
  gpg --verify get.sh.sig get.sh 
  sh get.sh

Not quite wget(1) clone. Options:

 -A, --show-all equivalent to -vET
 -b, --number-nonblank  precede each non-blank line with its line number
 -B, --no-blanksonly print lines with non-whitespace characters
 --bind=portdump each connection to port, print connection output
 --dos  convert line endings to DOS-style
 -e equivalent to -vE
 -E, --show-endsdisplay $ at the end of each line
 --hang-up  do not wait for socket input during --bind
 --hide-nonprinting hide non-printing characters
 --help display this help message and exit
 --hex  display the data as a hex dump
 --images   list unique, absolute image links from input data
 --krad convert lines to k-rad
 -l lines   list of lines to print, comma delimited, ranges allowed
 --linkslist unique, absolute URL links from input data
 --lowerconvert all upper-case characters to lower
 --mac  convert line endings to Macintosh-style
 -n, --number   precede each line with its line number
 --no-headerdo not dump out the header on each connection in --bind,
and don't dump header in URL data
 --oog  OOG A STRING!!!
 --rot=num  rotate character values (can be negative)
 -s, --squeeze-blanknever more than one single blank link
 --strfry   stir-fry each line (Linux only)
 --sock=domain:port connect, dump input to socket, print socket output
 --sock-testwith --sock, print if connection can be made
 -t equivalent to -vT
 -T, --show-tabsdisplay TAB characters as ^I
 --skip-tagsdo not process HTML tags from input, and simply output 
them as-is
 --translatetranslate end-of-line characters
 -u ignored
 --udp  use UDP rather than TCP on socket activity
 --unix convert line endings to UNIX-style
 --upperconvert all lower-case characters to upper
 -v, --show-nonprinting use ^ and M- notation, except for TAB
 -w[cols]   print first 'cols' characters of each line (default=80)
 --version  output version information and exit

-- 
Welcome to FOSS revolution: we fix and modify until it shines


cygwin-services-helper [was: Re: [ITA] inetutils-1.5-1]

2008-02-26 Thread Charles Wilson

Corinna Vinschen wrote:

On Feb 25 20:46, Charles Wilson wrote:
How about a new package, cygwin-services-helper or somesuch, that 
contains


(1) a script [*] derived from the appropriate portion of sshd-host-config, 
whose job is to create the appropriate priveleged user (I like 
'cygwin_svc') -- unless it already exists under either name ('cygwin_svc' 
or 'sshd_server').


(2) maybe another script [*] whose job is to ascertain whether such a user 
already exists, and return its name (or  if not).


It would be up to the calling foo-config to use these two scripts 
appropriately.  And, of course, the user might have to enter the password 
for the priveleged user account twice: once when it is created, and then 
again (by foo-config) to install the service 'foo'.


Then, openssh (and inetutils, and syslog-ng, and sysvinit, ...) could all 
depend on the cygwin-services-helper package.


[*] or maybe a script function library somewhere like 
/usr/lib/cygwin-services/ that foo-config could 'source', and then call the 
functions directly.  This would help the enter the password twice 
problem...


Sounds good!  The function library would be cool.


Here's my first draft.  Totally untested, almost nuthin' in the way of 
documentation...but I figured I'd post it now, because I won't have time 
for any more cygwin stuff until the weekend...


TODO: (1) test, documentation, bughunt this function library
  (2) rewrite ssh-host-config to use it
  (3) rewrite iu-config to use it
  (4) rewrite syslog-config to use it
  (5) chase setup.exe bug with regards to inetutils' setup.hint
  (6) incorporate bugfix for rshd (and rexecd /does/ have a similar 
bug)

  (7) remove --install-as-service from inetd

  (7a) add code to read existing \\Parameters\ConfigFilePath 
REG_SZ,, instead of ignoring it completely in favor of 
\\Parameters\ConfigFilePaths REG_MULTI_SZ -- probably migrating it over 
to the new REG_MULTI_SZ, since new 1.5 code *expects* at least two 
entries in the char** config_files array.


  (8) batten down the hatches on default inetd.conf
  (9) update inetutils.README to reflect #7  #8

Yeesh.  This is gonna take a while...

--
Chuck

#--  #!/bin/bash  --
# cygwin_services_helper.sh
#
# This is a script library used to assist installing cygwin
# services, such as sshd.  It is derived in part from
#
#   ssh-host-config (2008-02-25) Copyright 2000, 2001, 2002, 2003 Red Hat Inc.
# part of the Cygwin port of OpenSSH
#
#   cygport (2008-02-25) Copyright (C) 2006, 2007 Yaakov Selkowitz
# GPL v3
#
# Do not attempt to run this file. Instead, it should be sourced by
# configuration scripts (such as a newer version of ssh-host-config,
# syslog-config, or iu-config) -- and that script should then use
# the shell functions defined here.
#
# REQUIREMENTS:
#   SHELL must be bash
#
# PROVIDES:
#csh_error
#csh_error_multi
#csh_warning
#csh_inform
#csh_verbose
#csh_request
#csh_is_nt
#csh_is_nt2003
#csh_check_prog
#csh_check_prog_req
#csh_install_config
#csh_make_dir
#csh_privileged_user_name
#csh_privileged_user_exists
#csh_service_should_run_as
#csh_check_mounts
#csh_create_privileged_user
#csh_create_unprivileged_user
#
# MUTABLE VARIABLES:
#   csh_FORCE_PRIVILEGED_USER
#   if yes, then create a privileged user even on NT/2k/XP
#   where it is not required (on those versions, LocalSystem
#   will do fine).
#   SYSCONFDIR
#   default value = /etc
#   LOCALSTATEDIR
#   default value = /var
#   csh_auto_answer
#   default value =  (no automatic answers)


csh_progname=$0
csh_progname_base=$(basename $csh_progname)
csh_auto_answer=
csh_FORCE_PRIVILEGED_USER=no

if [ -z ${SYSCONFDIR} ]
then 
  SYSCONFDIR=/etc
fi

if [ -z ${LOCALSTATEDIR} ]
then
  LOCALSTATEDIR=/var
fi

# messaging functions borrowed from cygport
csh_error() {
  case $? in
0) local errorcode=1 ;;
*) local errorcode=$? ;;
  esac

  echo -e \e[1;31m*** ERROR:\e[0;0m ${1:-no error message provided};
  exit ${errorcode};
}
csh_error_multi() {
  # used for multi-line error messages.
  case $? in
0) local errorcode=1 ;;
*) local errorcode=$? ;;
  esac

  while test $# -gt 1
  do
echo -e \e[1;31m*** ERROR:\e[0;0m ${1};
shift
  done
  echo -e \e[1;31m*** ERROR:\e[0;0m ${1:-no error message provided};
  exit ${errorcode};
}

csh_warning() {
  echo -e \e[1;33m*** Warning:\e[0;0m ${1};
}

csh_inform() {
  echo -e \e[1;32m*** Info:\e[0;0m ${1};
}

csh_verbose() {
  echo [EMAIL PROTECTED]
  [EMAIL PROTECTED]
  return $?
}

csh_request()
{
  local answer=

  if [ ${csh_auto_answer} = yes ]
  then
echo $1 (yes/no) yes
return 0
  elif [ ${csh_auto_answer} = no ]
  then
echo $1 (yes/no) no
return 1
  fi

  while [ X${answer} != Xyes -a X${answer} != Xno ]
  do
echo -n $1 (yes/no) 
read -e answer
  done
  if [ X${answer} = Xyes ]
  then
return 0
  else
return 1
  fi
}