[GTG] Re: [ITA] tcp_wrappers
Charles Wilson writes: I definitely need some feedback on this, preferably from someone who is currently using tcpd from inetd.conf or xinetd. I'm concerned about the DLL path issues, because /usr/sbin/tcpd.exe is linked against /usr/bin/cygwrap-0.dll. This means that the cygwin bin directory has to be in the PATH for the inetd or xinetd process. I don't THINK this is a problem -- after all, the daemons have to be able to find cygwin1.dll -- but some confirmation that this version can be airdropped in to an existing, in-use configuration without causing problems would be good. http://cygwin.cwilson.fastmail.fm/ITP/tcp_wrappers-7.6-4-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/tcp_wrappers-7.6-4.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/libwrap-devel-7.6-4.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/libwrap0-7.6-4.tar.bz2 Builds fine from source, packaging and setup.hint look good. Charles did you forget about this ? o http://cygwin.com/ml/cygwin/2008-02/msg00042.html This release obsoletes the mktemp package; you should upgrade both packages at the same time or do coreutils second, to ensure that you still have a mktemp program. GTG Volker
[GTG] Re: [ITP] wiggle 0.6 -- A program for applying patches with conflicting changes
Jari Aalto writes: Included in Debian stable http://packages.debian.org/unstable/wiggle Builds fine from source, packaging and setup.hint look good. GTG Volker
[GTG] Re: [ITP] codeville 0.8.0 -- A distributed version control system implemented in Python
Jari Aalto writes: Included in Debian stable http://packages.debian.org/codeville Builds fine from source, packaging and setup.hint look good. GTG Volker
Re: [ITA] tcp_wrappers
On Feb 23 02:35, Charles Wilson wrote: I definitely need some feedback on this, preferably from someone who is currently using tcpd from inetd.conf or xinetd. I'm concerned about the DLL path issues, because /usr/sbin/tcpd.exe is linked against /usr/bin/cygwrap-0.dll. This means that the cygwin bin directory has to be in the PATH for the inetd or xinetd process. I don't THINK this is a problem -- after all, the daemons have to be able to find cygwin1.dll -- but some confirmation that this version can be airdropped in to an existing, in-use configuration without causing problems would be good. Should really not be a problem. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
mktemp obsolete [was: Re: [GTG] Re: [ITA] tcp_wrappers]
Dr. Volker Zell wrote: Charles did you forget about this ? o http://cygwin.com/ml/cygwin/2008-02/msg00042.html This release obsoletes the mktemp package; you should upgrade both packages at the same time or do coreutils second, to ensure that you still have a mktemp program. Um, no? The mktemp package's setup.hint now specifies the _obsolete category. The package directory has been moved from release/mktemp/ to release/_obsolete/mktemp. What's to do? I thought about creating a new, empty package with an updated version number -- but it's too late now. Once somebody has updated to the new coreutils, if they update using my new empty mktemp, then coreutils' mktemp.exe will be deleted. That's no good. -- Chuck
Re: mktemp obsolete
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Charles Wilson on 2/23/2008 9:08 AM: | The mktemp package's setup.hint now specifies the _obsolete category. | The package directory has been moved from release/mktemp/ to | release/_obsolete/mktemp. | | What's to do? | | I thought about creating a new, empty package with an updated version | number -- but it's too late now. Once somebody has updated to the new | coreutils, if they update using my new empty mktemp, then coreutils' | mktemp.exe will be deleted. That's no good. I can bump the version number of coreutils if you want to bump the version number of mktemp. But I think we're okay leaving things as they are for now - no one has complained. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHwEn684KuGfSFAYARAhpZAJkBazBNk6dfy5/QZ6VnQIcOUFZ/XwCeK7hh n3vEYb1+lIq/NI1qxQShEy0= =n1ZJ -END PGP SIGNATURE-
Re: RFD: Adding ability for maintainers to upload their own packages
Christopher Faylor schrieb: Please send comments here. Is this a positive thing? Are there other things that could be done in this scenario? What I like to have is the STDERR output of the genini/upset script in my environment, as logfile somewhere and maybe also as mail. It's a lot of work, and I hope it will not hinder progress in 1.7. -- Reini
Setup.exe vs corrupt lst.gz files.
Afternoon all, After a little more testing, and unless anyone yells, I intend to apply this patch later tonight to catch the infamous corrupt lst.gz file crash in current setup.exe. 2008-02-23 Dave Korn [EMAIL PROTECTED] * cygpackage.cc (cygpackage::getfirstfile): Guard against trying to construct std::string from NULL returned by io_stream::gets when the stream decompressor fails on a corrupt *.lst.gz file. cheers, DaveK -- Can't think of a witty .sigline today bad-gz-file-patch.diff Description: Binary data
Re: Setup.exe vs corrupt lst.gz files.
Dave Korn wrote: After a little more testing, and unless anyone yells, I intend to apply this patch later tonight to catch the infamous corrupt lst.gz file crash in current setup.exe. Thanks for looking at this, but that's really only solving half of the problem. The other half is that we generate one of these bogus .lst.gz files while installing a package if the user is prompted to retry an in-use file and clicks the close-X in the dialog instead of chosing retry or replace. But go ahead and commit this. Brian
RE: Setup.exe vs corrupt lst.gz files.
On 23 February 2008 18:50, Brian Dessent wrote: Thanks for looking at this, but that's really only solving half of the problem. The other half is that we generate one of these bogus .lst.gz files while installing a package if the user is prompted to retry an in-use file and clicks the close-X in the dialog instead of chosing retry or replace. I'll get to that next :) This is just to be nice to any users who have already got one of these files (or corrupted it by any other means). cheers, DaveK -- Can't think of a witty .sigline today
Re: Setup.exe vs corrupt lst.gz files.
On Sat, Feb 23, 2008 at 06:54:19PM -, Dave Korn wrote: On 23 February 2008 18:50, Brian Dessent wrote: Thanks for looking at this, but that's really only solving half of the problem. The other half is that we generate one of these bogus .lst.gz files while installing a package if the user is prompted to retry an in-use file and clicks the close-X in the dialog instead of chosing retry or replace. I'll get to that next :) This is just to be nice to any users who have already got one of these files (or corrupted it by any other means). Thanks for doing this. I think this bug may be near the top of the list for why everyone thinks cygwin's setup.exe sucks. cgf
RE: Setup.exe vs corrupt lst.gz files.
On 23 February 2008 18:50, Brian Dessent wrote: problem. The other half is that we generate one of these bogus .lst.gz files while installing a package if the user is prompted to retry an in-use file and clicks the close-X in the dialog instead of chosing retry or replace. Need a bit of clarification here: I could only get this to happen by clicking the X on the main setup.exe dialog behind, not the popup warning itself; I take it that's what you meant. cheers, DaveK -- Can't think of a witty .sigline today
Re: mktemp obsolete
On Sat, 23 Feb 2008, Eric Blake wrote: According to Charles Wilson on 2/23/2008 9:08 AM: | The mktemp package's setup.hint now specifies the _obsolete category. | The package directory has been moved from release/mktemp/ to | release/_obsolete/mktemp. | | What's to do? | | I thought about creating a new, empty package with an updated version | number -- but it's too late now. Once somebody has updated to the new | coreutils, if they update using my new empty mktemp, then coreutils' | mktemp.exe will be deleted. That's no good. I can bump the version number of coreutils if you want to bump the version number of mktemp. But I think we're okay leaving things as they are for now - no one has complained. They won't complain until they try to uninstall mktemp and find their coreutils incomplete... That wouldn't be a very common situation (so no rush), but it would be nice to do what you propose at some point. 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: Setup.exe vs corrupt lst.gz files.
On Sat, 23 Feb 2008, Dave Korn wrote: On 23 February 2008 18:50, Brian Dessent wrote: problem. The other half is that we generate one of these bogus .lst.gz files while installing a package if the user is prompted to retry an in-use file and clicks the close-X in the dialog instead of chosing retry or replace. Need a bit of clarification here: I could only get this to happen by clicking the X on the main setup.exe dialog behind, not the popup warning itself; I take it that's what you meant. You'd also get that if you press Cancel in the main dialog while the package is being installed. 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: Setup.exe vs corrupt lst.gz files.
On 23 February 2008 21:23, Igor Peshansky wrote: On Sat, 23 Feb 2008, Dave Korn wrote: On 23 February 2008 18:50, Brian Dessent wrote: problem. The other half is that we generate one of these bogus .lst.gz files while installing a package if the user is prompted to retry an in-use file and clicks the close-X in the dialog instead of chosing retry or replace. Need a bit of clarification here: I could only get this to happen by clicking the X on the main setup.exe dialog behind, not the popup warning itself; I take it that's what you meant. You'd also get that if you press Cancel in the main dialog while the package is being installed. Yes, I see, the dialog isn't modal and so it allows the 'X' which is effectively the same as cancelling. The solution has two parts then: 1) make the pop-up modal so the user can't mess with the app's main window while answering the question, and 2) make sure clicking 'cancel' or 'X' while in the middle of installing anyway close down gracefully. Part 1 I've already figured out. cheers, DaveK -- Can't think of a witty .sigline today
Re: mktemp obsolete
Igor Peshansky wrote: They won't complain until they try to uninstall mktemp and find their coreutils incomplete... That wouldn't be a very common situation (so no rush), but it would be nice to do what you propose at some point. Well, the best time to do that is whenever coreutils is next updated. So, Eric, if you would please upload the two attached files into the proper place simultaneous with your next, regularly scheduled coreutils update, I'd be grateful. -- Chuck
Re: mktemp obsolete
Charles Wilson wrote: Igor Peshansky wrote: They won't complain until they try to uninstall mktemp and find their coreutils incomplete... That wouldn't be a very common situation (so no rush), but it would be nice to do what you propose at some point. Well, the best time to do that is whenever coreutils is next updated. So, Eric, if you would please upload the two attached files into the proper place simultaneous with your next, regularly scheduled coreutils update, I'd be grateful. Attached. blush -- Chuck mktemp-1.5-5-src.tar.bz2 Description: Binary data mktemp-1.5-5.tar.bz2 Description: Binary data
