Re: [ITP] mingw-w64
Hi, Here are the GCC links. I hope I got them all. mingw64-tc64-gcc4: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-gcc4-4.6.20100619-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-gcc4-4.6.20100619-1.tar.bz2/download category: Devel requires: libgcc1 libgmp3 libgmpxx4 libppl libmpc1 libstdc++6 libcloog0 libintl8 mingw64-tc64-crt mingw64-tc64-m64-libgomp1-devel mingw64-m64-libgcc1 mingw64-tc64-m64-libssp0-devel sdesc: GCC C frontend for Windows target. ldesc: Mingw-w64 GCC for Windows target development.(C frontend, Mulilib, 64bit default) mingw64-m64-libssp0: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-m64-libssp0/mingw64-m64-libssp0-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m64-libgcc1 external-source: mingw64-tc64-gcc4 sdesc: 64bit libssp DLL. (Runtime) ldesc: 64bit GCC Stack Smash protection DLL. (Runtime) mingw64-tc64-m64-libssp0-devel: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-m64-libssp0-devel/mingw64-tc64-m64-libssp0-devel-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-tc64-gcc4 mingw64-m64-libssp0 external-source: mingw64-tc64-gcc4 sdesc: 64bit libssp DLL import library. (Devel) ldesc: 64bit GCC Stack Smash protection DLL import library for use with x86_64-w64-mingw32. (Devel) mingw64-m64-libssp0: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-m64-libssp0/mingw64-m64-libssp0-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m64-libgcc1 external-source: mingw64-tc64-gcc4 sdesc: 64bit libssp DLL. (Runtime) ldesc: 64bit GCC Stack Smash protection DLL. (Runtime) mingw64-m32-libssp0: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-m32-libssp0/mingw64-m32-libssp0-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m32-libgcc1 external-source: mingw64-tc64-gcc4 sdesc: 32bit libssp DLL. (Runtime) ldesc: 32bit GCC Stack Smash protection DLL. (Runtime) mingw64-tc64-m32-libssp0-devel: https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-m32-libssp0-devel/mingw64-tc64-m32-libssp0-devel-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-tc64-gcc4 mingw64-m32-libssp0 external-source: mingw64-tc64-gcc4 sdesc: 32bit libssp DLL import library. (Devel) ldesc: 32bit GCC Stack Smash protection DLL import library for use with x86_64-w64-mingw32. (Devel) mingw64-m64-libgomp1 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-m64-libgomp1/mingw64-m64-libgomp1-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m64-libpthread2 external-source: mingw64-tc64-gcc4 sdesc: 64bit libgomp DLL. (Runtime) ldesc: 64bit libgomp DLL for use with OpenMP. (Runtime) mingw64-m32-libgomp1 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-m32-libgomp1/mingw64-m32-libgomp1-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m32-libpthread2 mingw64-m32-libgcc1 external-source: mingw64-tc64-gcc4 sdesc: 32bit libgomp DLL. (Runtime) ldesc: 32bit libgomp DLL for use with OpenMP. (Runtime) mingw64-tc64-m64-libgomp1-devel https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-m64-libgomp1-devel/mingw64-tc64-m64-libgomp1-devel-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m64-libgomp1 mingw64-tc64-m64-libpthread2-devel mingw64-tc64-gcc4 external-source: mingw64-tc64-gcc4 sdesc: 64bit libgomp DLL import library. (Devel) ldesc: 64bit libgomp DLL import library for use with x86_64-w64-mingw32 mingw64-tc64-m32-libgomp1-devel https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-m32-libgomp1-devel/mingw64-tc64-m32-libgomp1-devel-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-m32-libgomp1 mingw64-tc64-m32-libpthread2-devel mingw64-tc64-gcc4 external-source: mingw64-tc64-gcc4 sdesc: 32bit libgomp DLL import library. (Devel) ldesc: 32bit libgomp DLL import library for use with x86_64-w64-mingw32 mingw64-tc64-gcc4-g++ https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-tc64-gcc4/mingw64-tc64-gcc4-g%2B%2B/mingw64-tc64-gcc4-g%2B%2B-4.6.20100619-1.tar.bz2/download category: Devel requires: mingw64-tc64-gcc4 mingw64-tc64-m64-libstdc++6-devel external-source: mingw64-tc64-gcc4 sdesc: GCC C++ frontend for Windows target. ldesc: Mingw-w64 GCC for Windows target development.(C++ frontend, Mulilib, 64bit default) mingw64-tc64-gcc4-gfortran
Re: [ITP] mingw-w64
I forgot to mention, don't upload GCC first, I need to confirm the nature of the gcc bug with Kai. Some GCC headers are needlessly shadowing the system headers.
Re: [ITP] mingw-w64
On 7/2/2010 14:38, JonY wrote: I forgot to mention, don't upload GCC first, I need to confirm the nature of the gcc bug with Kai. Some GCC headers are needlessly shadowing the system headers. OK to upload if packaging is fine, no changes needed.
Re: [RFU] libaprutil1-1.3.9-3
On Jul 1 13:39, David Rothenberger wrote: This release updates from libdb4.2 to libdb4.5. Please leave 1.3.9-2 as previous and remove any older versions. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/aprutil1/aprutil1-1.3.9-3.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/aprutil1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-1.3.9-3-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-1.3.9-3.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-devel/libaprutil1-devel-1.3.9-3.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/setup.hint Uploaded and 1.3.7-2 removed. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] subversion-1.6.12-2
On Jul 1 13:44, David Rothenberger wrote: This release is linked against libdb4.5 instead of libdb4.2. Please delete 1.6.11-1 and leave 1.6.12-1 as the previous version. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-1.6.12-2-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-1.6.12-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-apache2/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-apache2/subversion-apache2-1.6.12-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-devel/subversion-devel-1.6.12-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-perl/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-perl/subversion-perl-1.6.12-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-python/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-python/subversion-python-1.6.12-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-ruby/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-ruby/subversion-ruby-1.6.12-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-tools/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-tools/subversion-tools-1.6.12-2.tar.bz2 Uploaded and 1.6.11-1 removed. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] cyrus-sasl
On Jun 30 08:14, David Rothenberger wrote: I would like to adopt cyrus-sasl. It is listed as orphaned and Gareth Pearce recently indicated he was not planning to repackage it.[1] Thanks for taking over. Packaging looks good to me, just the setup.hint files... libsasl2.hint -- sdesc: The Cyrus SASL API implementation. (Runtime library and Daemon) ldesc: The Cyrus SASL library allows for client/server authentication in conformance with RFC . category: Libs requires: crypt libdb4.5 libgcc libopenssl098 That should be libgcc1, I guess. external-source: cyrus-sasl libsasl2-ldap.hint -- sdesc: The Cyrus SASL API implementation. (LDAP Plugin) ldesc: The Cyrus SASL library allows for client/server authentication in conformance with RFC . category: Libs requires: libsasl2 libopenldap2 Is that the right version of libopenldap? The last update to openldap only came with the libopenldap2_3_0 package. So your libsasl2-ldap package should be linked against that version, right? Btw., Volker, is there a chance that we can get an updated version of libopenldap2_3_0 which does not rely on minires? Minires is part of Cygwin since 1.7.0, so it would be nice if we could get rid of the runtime dependencies to this package. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] cyrus-sasl
On 7/2/2010 1:34 AM, Corinna Vinschen wrote: On Jun 30 08:14, David Rothenberger wrote: I would like to adopt cyrus-sasl. It is listed as orphaned and Gareth Pearce recently indicated he was not planning to repackage it.[1] Thanks for taking over. Packaging looks good to me, just the setup.hint files... Thanks for catching those errors. You were right, of course. Here's the updated setup.hints and packages. cyrus-sasl.hint -- sdesc: The Cyrus SASL API implementation. (Documentation and Utilities) ldesc: The Cyrus SASL library allows for client/server authentication in conformance with RFC . category: Utils requires: libsasl2 libsasl2.hint -- sdesc: The Cyrus SASL API implementation. (Runtime library and Daemon) ldesc: The Cyrus SASL library allows for client/server authentication in conformance with RFC . category: Libs requires: crypt libdb4.5 libgcc1 libopenssl098 external-source: cyrus-sasl libsasl2-devel.hint -- sdesc: The Cyrus SASL API implementation. (Development files) ldesc: The Cyrus SASL library allows for client/server authentication in conformance with RFC . category: Libs requires: libsasl2 libdb4.5-devel openssl-devel openldap-devel libpq-devel external-source: cyrus-sasl libsasl2-ldap.hint -- sdesc: The Cyrus SASL API implementation. (LDAP Plugin) ldesc: The Cyrus SASL library allows for client/server authentication in conformance with RFC . category: Libs requires: libsasl2 libopenldap2_3_0 external-source: cyrus-sasl libsasl2-sql.hint -- sdesc: The Cyrus SASL API implementation. (SQL Plugin) ldesc: The Cyrus SASL library allows for client/server authentication in conformance with RFC . category: Libs requires: libsasl2 libpq5 external-source: cyrus-sasl download: wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/cyrus-sasl-2.1.23-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/cyrus-sasl-2.1.23-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2/libsasl2-2.1.23-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-devel/libsasl2-devel-2.1.23-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-ldap/libsasl2-ldap-2.1.23-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-ldap/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-sql/libsasl2-sql-2.1.23-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-sql/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/setup.hint -- David Rothenberger daver...@acm.org Steinbach's Guideline for Systems Programming: Never test for an error condition you don't know how to handle.
Re: [ITP] mingw-w64
On 2 July 2010 08:17, JonY wrote: OK to upload if packaging is fine, no changes needed. Great to see mingw64 coming to Cygwin, but I think the upload should wait until Cygwin gcc maintainer Dave Korn has had a chance to comment on this. Is mingw64 already part of a major Linux distribution? Otherwise it needs five votes from Cygwin maintainers. Also, are you sure that gcc-4.6 is sufficiently stable for release, i.e. that there won't be any more compatibility breaking changes before official release? Finally, I'm not sure what the conclusion was about which toolchain(s) will be included. Looks like a single multilib toolchain defaulting to 64 bits to me. If that's the case, is the tc64 bit in the name actually needed? Andy
Re: [ITP] mingw-w64
On Fri, Jul 2, 2010 at 1:41 PM, Andy Koppe andy.ko...@gmail.com wrote: Is mingw64 already part of a major Linux distribution? Otherwise it needs five votes from Cygwin maintainers. Ubuntu, Debian, and Fedora. Also, are you sure that gcc-4.6 is sufficiently stable for release, i.e. that there won't be any more compatibility breaking changes before official release? It is unlikely given the roadmap of 4.6. Finally, I'm not sure what the conclusion was about which toolchain(s) will be included. Looks like a single multilib toolchain defaulting to 64 bits to me. If that's the case, is the tc64 bit in the name actually needed? I thought it was both.
Re: [ITP] mingw-w64
On 7/2/2010 1:41 PM, Andy Koppe wrote: On 2 July 2010 08:17, JonY wrote: OK to upload if packaging is fine, no changes needed. Great to see mingw64 coming to Cygwin, but I think the upload should wait until Cygwin gcc maintainer Dave Korn has had a chance to comment on this. I agree. Apparently DK has been AFK for a few weeks, but I think he's back now. Is mingw64 already part of a major Linux distribution? Otherwise it needs five votes from Cygwin maintainers. AFAICT, mingw64 is the mingw cross compiler provided by fedora. Also, are you sure that gcc-4.6 is sufficiently stable for release, i.e. that there won't be any more compatibility breaking changes before official release? That...is beyond my ken. Finally, I'm not sure what the conclusion was about which toolchain(s) will be included. Looks like a single multilib toolchain defaulting to 64 bits to me. If that's the case, is the tc64 bit in the name actually needed? IMO, even if JonY has no *immediate* plans for a default-to-32bit toolchain (whether multilib or single target), I think it makes sense to allow for the possibility in the package naming scheme. And...JonY already said he was saving the /i686-w64-mingw32/* tree for use by the default-to-32bit toolchain, so... -- Chuck
Re: [ITP] mingw-w64
I am a little surprised that you got this to work simply by passing
--prefix=/opt/mingw64/... and a few other flags. Last time I looked
closely, cygport assumed /usr in quite a few places. Maybe that's
changed; if so, cool!
On 7/2/2010 1:29 AM, JonY wrote:
mingw64-tc64-headers:
...
category: Devel
requires: mingw64-tc64-gcc4
sdesc: Headers for Windows target.
ldesc: Mingw-w64 headers for Windows target development.
Rebuilds cleanly from source. Packaging looks ok (assuming current
status of naming discussion represents the ultimate consensus view).
I think you should included your branding in the sdesc:
Mingw-w64 headers for Windows target development.
or something. Also, I think you should specify in the ldesc that this
package is for both -m32 and -m64, AND that it's for the
default-to-64bit toolchain.
Mingw-w64 headers for Windows target development, for use with
the Mingw-w64 toolchain that defaults to 64bit output. However, this
package supports that toolchain in both 64bit (-m64) and 32bit (-m32)
mode.
Finally, I don't think this package actually *requires* the compiler,
does it? It may not be of any USE without the compiler, but I could
install it just to look at the files, right?
mingw64-tc64-binutils:
category: Devel
requires: libgcc1 zlib0 libintl8
sdesc: Binutils for Windows target.
ldesc: Cross binutils for Win64 and Win32 target.(Mulilib, 64bit default)
Packaging looks ok (assuming current status of naming discussion
represents the ultimate consensus view).
Rebuilds (almost) fine from source. There is a warning during packaging:
Checking packages for missing or duplicate files
*** Warning: Packages are missing files:
-opt/mingw64/lib/libiberty.a
Now, I know you don't WANT to include libiberty.a in the package, so to
suppress the warning just override src_install():
src_install() {
cd ${B}
cyginstall
rm -f ${D}/opt/mingw64/lib/libiberty.a
}
Again, I'd include the mingw64 branding in sdesc (actually, your
original ldesc is a better sdesc...):
Mingw-w64 cross binutils for windows target (multilib, 64bit default)
And with ldesc:
Mingw-w64 cross binutils for Win64 and Win32 target. This is part
of a multilib toolchain that defaults to 64bit output, but supports both
64bit (-m64) and 32bit (-m32) mode.
Oddly, my build doesn't appear to depend on zlib0; libgcc1 and libintl8
(and cygwin, of course, but that is never included in requires:).
mingw64-tc64-m32-crt:
mingw64-tc64-crt:
mingw64-tc64-m64-crt:
I assume I need the mingw64-tc64-gcc to (re)build these, so I'll have to
verify that later (and comment on the setup.hints)
Packaging looks ok (assuming current status of naming discussion
represents the ultimate consensus view).
One oddity: the -m64 package contains 2112 files, but the -m32 package
contains only 227 files. Is that expected? I would have thought that
the same libraries would be available in both lib/* and lib32/*
mingw64-tc64-libpthread2
mingw64-tc64-libpthread2-headers
mingw64-m64-libpthread2
mingw64-m32-libpthread2
Again, I assume I need the mingw64-tc64-gcc to (re)build these, so I'll
have to verify that later (and comment on the setup.hints)
The packaging needs a few more tweaks. Usually, we only include the
'dll version' in the package name of the packages that actually contain
the DLLs themselves:
mingw64-m64-libpthread2
mingw64-m32-libpthread2
The docs and headers are not really versioned -- it's not as if you
could have two distinct versions installed (for the same bitdepth and
toolchain) at the same time. (it's pthread.h not pthread2.h)
So, I'd name these packages like so:
mingw64-m32-libpthread2-20100619-1.tar.bz2
mingw64-m64-libpthread2-20100619-1.tar.bz2
mingw64-tc64-libpthread-20100619-1.tar.bz2
mingw64-tc64-libpthread-20100619-1-src.tar.bz2
mingw64-tc64-libpthread-headers-20100619-1.tar.bz2
--
Chuck
RE: Using the Canadian Multilingual Standard keyboard with WindowsXP
Hello Jon, With WIN XP keyboard set to Canadian Multilingual Standard: Run xev, press Right Alt KeyPress event, serial 24, synthetic NO, window 0xa1, root 0x101, subw 0x0, time 175760620, (207,-35), root:(383,197), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 27, synthetic NO, window 0xa1, root 0x101, subw 0x0, time 175760620, (207,-35), root:(383,197), state 0x4, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0xa1, root 0x101, subw 0x0, time 175760720, (207,-35), root:(383,197), state 0x84, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False press Right Ctrl KeyRelease event, serial 27, synthetic NO, window 0xa1, root 0x101, subw 0x0, time 175766418, (207,-35), root:(383,197), state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False press Right Ctrl again KeyPress event, serial 27, synthetic NO, window 0xa1, root 0x101, subw 0x0, time 175776102, (207,-35), root:(383,197), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0xa1, root 0x101, subw 0x0, time 175776182, (207,-35), root:(383,197), state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False With WIN XP keyboard set to US: Run xev, press Right Alt KeyPress event, serial 24, synthetic NO, window 0xa1, root 0x101, subw 0x0, time 175606538, (643,593), root:(775,767), state 0x0, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0xa1, root 0x101, subw 0x0, time 175606608, (643,593), root:(775,767), state 0x80, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False press Right Ctrl KeyPress event, serial 27, synthetic NO, window 0xa1, root 0x101, subw 0x0, time 175613939, (643,593), root:(775,767), state 0x0, keycode 109 (keysym 0xfe11, ISO_Level5_Shift), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0xa1, root 0x101, subw 0x0, time 175614009, (643,593), root:(775,767), state 0x20, keycode 109 (keysym 0xfe11, ISO_Level5_Shift), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False The latter seems correct. Regards, George Young -Original Message- From: Jon TURNEY [mailto:jon.tur...@dronecode.org.uk] Sent: July 1, 2010 10:50 AM To: cygwin-xfree@cygwin.com Cc: Young, George Subject: Re: Using the Canadian Multilingual Standard keyboard with WindowsXP On 03/06/2010 21:17, Young, George wrote: Using Windows XP and cygwin started with the command %RUN% XWin -multiwindow -clipboard -silent-dup-error -xkblayout ca -xkbvariant multix -xkbmodel pc104 If the Windows keyboard is set to US, cygwin works fine. If the Windows keyboard is set to Canadian Multilingual Standard, cygwin doesn't get the RightAlt and RightControl inputs. I couldn't reproduce this. Checking with xev, the right alt and right control keys generate key events when the Windows keyboard layout is Canadian Multilingual Standard, although it seems that right control generates the same X keysym as left control with that layout for some reason. Can you clarify how you are checking for the keypresses? Please attach your /var/log/XWin.0.log as well. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer XWin.0.log Description: XWin.0.log -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Coupe du monde
Sur Yahoo Sport http://fr.sports.yahoo.com/football/coupe-du-monde/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog net.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-07-02 14:36:43 Modified files: winsup/cygwin : ChangeLog net.cc Log message: * net.cc (cygwin_getsockopt): Make sure SO_PEERCRED is only handled in level SOL_SOCKET. Workaround a return value regression in Vista and later. Add comment to explain. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4971r2=1.4972 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/net.cc.diff?cvsroot=srcr1=1.272r2=1.273
Re: Re: Windows GUI programs (e.g. notepad) start but are invisible after ssh login
User Thorsten Kampe wrote: From: Thorsten Kampe Subject: Re: Re: Windows GUI programs (e.g. notepad) start but are invisible after ssh login To: cygwin@cygwin.com (...) Same on Windows XP SP3... Is it possible to run sshd as a regular process rather than a service? I'm OK not seeing the GUI most of the time (I'm launching my application after logging over ssh, the application does some processing and then quits). However, if something goes wrong I would be happy to stop sshd service, launch sshd as a regular process, rerun the application and _see_ what goes wrong. K. -- Doladuj telefon przez Internet. Sprawdz http://linkint.pl/f2778 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Issue with Cygwin perl *** fatal error - fork: can't reserve memory for stack
The cause was that the argument list was long. That is, a program invoked with a long argument list could not fork. Perhaps this behaviour could be improved. On the other hand, I tried creating a junction point with linkd.exe so that I could use short names for the openoffice source tree. But this didn't work becase the configure script translated junction points, because cygpath translates them. Why? This is surprising. For example if c:\ooo is a junction to c:\Documents and settings\myuser\openoffice, why should cygpath -w /cygdrive/c/ooo return c:\Documents...\openoffice rather than c:\ooo? At least that translation should be optional. Aviso legal – Comisión Nacional del Mercado de Valores Este mensaje y, en su caso, los ficheros que lleve incorporados, está dirigido exclusivamente a su destinatario y es de carácter confidencial. Si fuere recibido por error o se tuviere conocimiento del mismo sin ser su destinatario, rogamos nos lo comunique por la misma vía o telefónicamente (91 585 15 00) y proceda a su destrucción, debiendo abstenerse de utilizar, transmitir, divulgar o reproducir la información contenida en el mismo. La CNMV se reserva las acciones legales que procedan contra todo tercero que acceda de forma ilegítima al contenido de cualquier mensaje externo procedente de la entidad Para información y consultas visite nuestra web: http://www.cnmv.es Disclaimer - Comisión Nacional del Mercado de Valores This message, its content and any file attached thereto is for the intended recipient only and is confidential. If you have received this e-mail in error or had access to it, you should note that the information in it is private and any use thereof is unauthorised. In such an event please notify us by e-mail or by telephone (+ 34 91 585 15 00). Any reproduction of this e-mail by whatsoever means and any transmission or dissemination thereof to other persons is prohibited. The Comisión Nacional del Mercado de Valores reserves the right to take legal action against any persons unlawfully gaining access to the content of any external message it has emitted For additional information, please visit our website: http://www.cnmv.es
Re: Fwd: unstable behavior with 1.7.5
On Fri, Jul 2, 2010 at 12:30 AM, Leigh Orf wrote: On Thu, Jul 1, 2010 at 4:29 PM, Larry Hall wrote: Please: http://cygwin.com/acronyms/#PCYMTNQREAIYR http://cygwin.com/acronyms/#TOFU If you can convince google/gmail to make options for these things (and change rfc1855), great, just spent half an hour trying to get a likely outdated greasemonkey script working to no avail. Gmail sucks in this regard. I always do both of these by hand. It's not that hard. -- Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Re: Windows GUI programs (e.g. notepad) start but are invisible after ssh login
* Koszalek Opalek (02 Jul 2010 08:50:47 +0200) User Thorsten Kampe wrote: Same on Windows XP SP3... Is it possible to run sshd as a regular process rather than a service? Sure. Thorsten -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
R: getsockopt(SO_KEEPALIVE) returns incorrect option length
--- Ven 2/7/10, Pavel Holejsovsky ha scritto:
Hi,
I think that following problem shows problematic behavior
in cygwin 1.7.5, at least incompatible with linux:
#include stdio.h
#include sys/socket.h
int main() {
int sock, option, optlen =
sizeof(int);
sock = socket(AF_INET,
SOCK_STREAM, 0);
getsockopt(sock, SOL_SOCKET,
SO_KEEPALIVE, option, optlen);
printf(option=%d,
optlen=%d\n, option, optlen);
return 0;
}
Prints optlen=1, while it is expected to be sizeof(int),
i.e. 4.
This is most probably because uinderlying winsock call has
this (mis)behavior, but I think that in cygwin layer this
could be worked around to be more unix compatible.
This issue is relevant:
SO_KEEPALIVE value is actually a char on Windows, not BOOL
https://bugzilla.gnome.org/show_bug.cgi?id=611756
And causes glib gio 2.24 to fail certain socket operations
on cygwin.
thanks,
Pavel
option=0, optlen=4
on XP-sp2, cygwin 1.7.5s(0.227/5/3) 20100628
MArco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Mail program
Greetings, Refr Bruhl! I found a resolution to my email problem. I had to reinstall ssmtp I discovered where I work was blocking port 25. This was removed for me Try the alternate mail submission port (587/tcp) or less standard 2525/tcp which is often configured to work. -- WBR, Andrey Repin (anrdae...@freemail.ru) 02.07.2010, 14:12 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issue with Cygwin perl *** fatal error - fork: can't reserve memory for stack
2010/7/2 Ramón García Fernández ram...@cnmv.es: The cause was that the argument list was long. That is, a program invoked with a long argument list could not fork. Perhaps this behaviour could be improved. I'll try if it's within perl. Before I see no problem with perl's fork, but maybe it's elsewhere. What is your openoffice ticket url for this problem? With http://www.openoffice.org/servlets/ReadMsg?listName=allsvnmsgNo=9427 I see a possible problem in: my $command = rebase . $options_string; where $options_string can get too large and the error message should be improved. I don't think perl has a test for argument length limits yet. I'll investigate. If within the cygwin1.dll you have to be more specific were exactly. A part of the strace of the failing rebase.pl call would help. On the other hand, I tried creating a junction point with linkd.exe so that I could use short names for the openoffice source tree. But this didn't work becase the configure script translated junction points, because cygpath translates them. Why? This is surprising. For example if c:\ooo is a junction to c:\Documents and settings\myuser\openoffice, why should cygpath -w /cygdrive/c/ooo return c:\Documents...\openoffice rather than c:\ooo? At least that translation should be optional. This is a behaviour within the cygwin dll. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: R: getsockopt(SO_KEEPALIVE) returns incorrect option length
On 7/2/2010 12:01 PM, Marco Atzeri wrote:
--- Ven 2/7/10, Pavel Holejsovsky ha scritto:
Hi,
I think that following problem shows problematic behavior
in cygwin 1.7.5, at least incompatible with linux:
#includestdio.h
#includesys/socket.h
int main() {
int sock, option, optlen =
sizeof(int);
sock = socket(AF_INET,
SOCK_STREAM, 0);
getsockopt(sock, SOL_SOCKET,
SO_KEEPALIVE,option,optlen);
printf(option=%d,
optlen=%d\n, option, optlen);
return 0;
}
Prints optlen=1, while it is expected to be sizeof(int),
i.e. 4.
This is most probably because uinderlying winsock call has
this (mis)behavior, but I think that in cygwin layer this
could be worked around to be more unix compatible.
This issue is relevant:
SO_KEEPALIVE value is actually a char on Windows, not BOOL
https://bugzilla.gnome.org/show_bug.cgi?id=611756
And causes glib gio 2.24 to fail certain socket operations
on cygwin.
thanks,
Pavel
option=0, optlen=4
on XP-sp2, cygwin 1.7.5s(0.227/5/3) 20100628
Thanks for testing, Marco.
So it is even system-dependent misbehaviour of winsock. On w7-x64
cygwin 1.7.5 it prints
option=2674688, optlen=1
Pavel
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Issue with Cygwin perl *** fatal error - fork: can't reserve memory for stack
We did put a ticket for this issue. It is not really necessary to strace rebase.pl. When rebase was invoked with a long command, any attempt to fork, including a call to perl system() before anything else, causes this issue. I suggest not to translate junctions to targets, even if the functionality is in cygwin1.dll. It is surprising. -Mensaje original- De: reini.ur...@gmail.com [mailto:reini.ur...@gmail.com] En nombre de Reini Urban Enviado el: viernes, 02 de julio de 2010 12:36 Para: cygwin@cygwin.com CC: Ramón García Fernández Asunto: Re: Issue with Cygwin perl *** fatal error - fork: can't reserve memory for stack 2010/7/2 Ramón García Fernández ram...@cnmv.es: The cause was that the argument list was long. That is, a program invoked with a long argument list could not fork. Perhaps this behaviour could be improved. I'll try if it's within perl. Before I see no problem with perl's fork, but maybe it's elsewhere. What is your openoffice ticket url for this problem? With http://www.openoffice.org/servlets/ReadMsg?listName=allsvnmsgNo=9427 I see a possible problem in: my $command = rebase . $options_string; where $options_string can get too large and the error message should be improved. I don't think perl has a test for argument length limits yet. I'll investigate. If within the cygwin1.dll you have to be more specific were exactly. A part of the strace of the failing rebase.pl call would help. On the other hand, I tried creating a junction point with linkd.exe so that I could use short names for the openoffice source tree. But this didn't work becase the configure script translated junction points, because cygpath translates them. Why? This is surprising. For example if c:\ooo is a junction to c:\Documents and settings\myuser\openoffice, why should cygpath -w /cygdrive/c/ooo return c:\Documents...\openoffice rather than c:\ooo? At least that translation should be optional. This is a behaviour within the cygwin dll. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ Aviso legal – Comisión Nacional del Mercado de Valores Este mensaje y, en su caso, los ficheros que lleve incorporados, está dirigido exclusivamente a su destinatario y es de carácter confidencial. Si fuere recibido por error o se tuviere conocimiento del mismo sin ser su destinatario, rogamos nos lo comunique por la misma vía o telefónicamente (91 585 15 00) y proceda a su destrucción, debiendo abstenerse de utilizar, transmitir, divulgar o reproducir la información contenida en el mismo. La CNMV se reserva las acciones legales que procedan contra todo tercero que acceda de forma ilegítima al contenido de cualquier mensaje externo procedente de la entidad Para información y consultas visite nuestra web: http://www.cnmv.es Disclaimer - Comisión Nacional del Mercado de Valores This message, its content and any file attached thereto is for the intended recipient only and is confidential. If you have received this e-mail in error or had access to it, you should note that the information in it is private and any use thereof is unauthorised. In such an event please notify us by e-mail or by telephone (+ 34 91 585 15 00). Any reproduction of this e-mail by whatsoever means and any transmission or dissemination thereof to other persons is prohibited. The Comisión Nacional del Mercado de Valores reserves the right to take legal action against any persons unlawfully gaining access to the content of any external message it has emitted For additional information, please visit our website: http://www.cnmv.es
[ANNOUNCEMENT] Updated: googlecl-0.9.8-1
Version 0.9.8-1 of googlecl has been uploaded. GoogleCL brings Google services to the command line. For examples see: http://code.google.com/p/googlecl/wiki/ExampleScripts Change include: * Proper login procedure for Apps users * setuptools support * Uploading directory trees to Docs * Multiple-calendar tasks *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mutt and perl-ming
On Jul 1 17:14, Lee Rothstein wrote: I got bitten by the misconfig of gnome-canvas on kernel.org. That plus, bandwidth shenanigans by Comcast, and probably some errors in my recovery process left me with a bunch of missing pieces from sundry packages. I've fixed all the problems except for 'mutt' and 'perl-ming' (jeff? ;-)). No amount of reinstalling, uninstalling and installing seems to fix these residual problems. Clues greatly appreciated! Attached is my 'cygcheck' output. As long as I'm asking questions, why does 'cygcheck' no longer properly list?: Last downloaded files to: ”' Last downloaded files from: ”' Oh, hmm. The latest versions of setup have changed the way the information is stored, but cygcheck doesn't yet know that. It still looks in the old places. This needs fixing... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Weird directories on Windows share when using rm to delete a directory
On Jul 1 15:28, Eric Blake wrote: On 07/01/2010 03:24 PM, Slide wrote: I am seeing a VERY odd problem. If I run /usr/bin/rm -rf //computer/share/path/to/dir to remove a directory on a network share. I get some directories created with names like .XXXf8a0015e3b00c65f07a9f20c7a31 at the ROOT of the share (where XXX is unprintable character with the value 0x3f). I ran the command with strace, but didn't see anything in there that would point to why the directory is created. If I run the corresponding Windows command rmdir /s /q \\computer\share\path\to\dir I do NOT see the same thing occur, so something in Cygwin is causing this issue. I am running Cygwin 1.7 updated today. This is due to cygwin emulating the ability to delete a file that is still open. Since windows doesn't directly allow it, cygwin instead renames it out of the way, and relies on windows delete-on-close semantics to get rid of that temporary name after everything finally lets go of the file. But if the delete-on-close stuff isn't working for your particular network share, [...] Sorry Eric, but that's not the problem. Cygwin does what you say *only* for local drives. It utilizes the recycle bin directory of local drives for this mechanism. Remote shares usually don't have a recycle bin and for the unlink() mechanism I decided at one point that I don't want to create Cygwin directories in the root of the share without being asked. So, removing in-use files on shares is not directly supported from within Cygwin. However, there are shares which support that on their own, either in the server or in the client. The above folder using that weird hex number is definitely one of them. Cygwin has no control over that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Weird directories on Windows share when using rm to delete a directory
On Jul 2 15:28, Corinna Vinschen wrote: On Jul 1 15:28, Eric Blake wrote: On 07/01/2010 03:24 PM, Slide wrote: I am seeing a VERY odd problem. If I run /usr/bin/rm -rf //computer/share/path/to/dir to remove a directory on a network share. I get some directories created with names like .XXXf8a0015e3b00c65f07a9f20c7a31 at the ROOT of the share (where XXX is unprintable character with the value 0x3f). I ran the command with strace, but didn't see anything in there that would point to why the directory is created. If I run the corresponding Windows command rmdir /s /q \\computer\share\path\to\dir I do NOT see the same thing occur, so something in Cygwin is causing this issue. I am running Cygwin 1.7 updated today. This is due to cygwin emulating the ability to delete a file that is still open. Since windows doesn't directly allow it, cygwin instead renames it out of the way, and relies on windows delete-on-close semantics to get rid of that temporary name after everything finally lets go of the file. But if the delete-on-close stuff isn't working for your particular network share, [...] Sorry Eric, but that's not the problem. Cygwin does what you say *only* for local drives. [...] Oh boy, scratch this. I didn't remember that I implemented it exactly as described for remote drives. *blush* I just read my longish comment in the source code which describes what happens: /* Create hopefully unique filename. Since we have to stick to the current directory on remote shares, make the new filename at least very unlikely to match by accident. It starts with .cyg, with cyg transposed into the Unicode low surrogate area starting at U+dc00. Use plain ASCII chars on filesystems not supporting Unicode. The rest of the filename is the inode number in hex encoding and a hash of the full NT path in hex. The combination allows to remove multiple hardlinks to the same file. */ Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: R: getsockopt(SO_KEEPALIVE) returns incorrect option length
On Jul 2 13:31, Pavel Holejsovsky wrote:
On 7/2/2010 12:01 PM, Marco Atzeri wrote:
--- Ven 2/7/10, Pavel Holejsovsky ha scritto:
Hi,
I think that following problem shows problematic behavior
in cygwin 1.7.5, at least incompatible with linux:
#includestdio.h
#includesys/socket.h
int main() {
int sock, option, optlen =
sizeof(int);
sock = socket(AF_INET,
SOCK_STREAM, 0);
getsockopt(sock, SOL_SOCKET,
SO_KEEPALIVE,option,optlen);
printf(option=%d,
optlen=%d\n, option, optlen);
return 0;
}
Prints optlen=1, while it is expected to be sizeof(int),
i.e. 4.
This is most probably because uinderlying winsock call has
this (mis)behavior, but I think that in cygwin layer this
could be worked around to be more unix compatible.
This issue is relevant:
SO_KEEPALIVE value is actually a char on Windows, not BOOL
https://bugzilla.gnome.org/show_bug.cgi?id=611756
And causes glib gio 2.24 to fail certain socket operations
on cygwin.
thanks,
Pavel
option=0, optlen=4
on XP-sp2, cygwin 1.7.5s(0.227/5/3) 20100628
Thanks for testing, Marco.
So it is even system-dependent misbehaviour of winsock. On w7-x64
cygwin 1.7.5 it prints
option=2674688, optlen=1
Looks like a Windows regression. I can reproduce optlen=1 on Vista
and W7, while I also get optlen=4 on XP.
I tested this a bit further and checked the other BSD-compatible
SOL_SOCKET options which use int as return type in BSD and BOOL in
Winsock. It turns out that starting with Vista the SO_DONTROUTE option
is also wrongly returning just a one byte value with optlen set to 1.
I assume somebody changed something accidentally from BOOL to BOOLEAN in
the Winsock sources.
I'll added a workaround to Cygwin.
Thanks for the report,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Weird directories on Windows share when using rm to delete a directory
On Jul 1 20:03, Slide wrote: On Thu, Jul 1, 2010 at 3:26 PM, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote: On 7/1/2010 5:52 PM, Slide wrote: snip What sort of information would you need for the share? I believe it is actually a Linux box running Samba for the share. I would have to double check with my IT department on that. I should be able to get any information needed about the share to help workaround the issue. Knowing the source system O/S, version, sharing protocol and version, and file system type would be helpful. Also, please provide the output of /usr/lib/csih/getVolInfo for the mounted path. The system is a NetApp. This is the information that my IT guy gave me. 1)System O/S and Version - ONTAP 7.2.6.1P8 2)Sharing protocol and version - CIFS 3)File system type - WAFL (not really a file system according to wikipedia) And here is the info from getVolInfo Device Type: 7 Characteristics: 10 Volume Name: PCA Serial Number : 50512157 Max Filenamelength : 255 Filesystemname : NTFS Flags : 4000f FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : FALSE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : TRUE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE So, IIUC, youre'saying that the directories get renamed to this temporary name, but they never disappear after rm -rf? Are you sure that no other process is accessing them? Does Cygwin recognize the drive as netapp if you add a mount point for it? How to check: If the drive has been mounted with a drive letter, say X:, what does `mount' print as drive type of /cygdrive/x? Or, if the drive is used via UNC path, just mount it temporarily like this: $ mount -f //server/share /mnt And see what a `mount' command prints for the .mnt mount point: $ mount Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Error with libtool when compiling MySQL
make fails when building MySQL 5.1.48, using libtool: make[3]: Entering directory `/home/Eric Thompson/My Documents/Downloads/mysql-5.1.48/unittest/mytap/t' /bin/sh ../../../libtool --preserve-dup-deps --tag=CC --mode=link gcc -O2 -L../../../unittest/mytap -o basic-t.exe basic-t.o -lmytap -lcrypt -lm libtool: link: cannot find the library `' or unhandled argument `Thompson/My'\ Path is truncated. What could cause this? Thanks, Jet -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Weird directories on Windows share when using rm to delete a directory
snip So, IIUC, youre'saying that the directories get renamed to this temporary name, but they never disappear after rm -rf? Are you sure that no other process is accessing them? Does Cygwin recognize the drive as netapp if you add a mount point for it? How to check: If the drive has been mounted with a drive letter, say X:, what does `mount' print as drive type of /cygdrive/x? Or, if the drive is used via UNC path, just mount it temporarily like this: $ mount -f //server/share /mnt And see what a `mount' command prints for the .mnt mount point: $ mount Corinna I'm pretty sure there are no other processes accessing the files. $ mount ... Y: on /cygdrive/y type netapp (binary,posix=0,user,noumount,auto) So, yes, it does see it as a netapp. Now, from my horrible memory, it _seems_ like this started happening when we upgraded to Cygwin 1.7 from Cygwin 1.5. I don't know that for sure though, it just _seems_ that that is what happened. Thanks, slide -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
R: Error with libtool when compiling MySQL
--- Gio 1/7/10, Jet Thompson ha scritto: make fails when building MySQL 5.1.48, using libtool: make[3]: Entering directory `/home/Eric Thompson/My ^^ a space in the path Documents/Downloads/mysql-5.1.48/unittest/mytap/t' /bin/sh ../../../libtool --preserve-dup-deps --tag=CC --mode=link gcc -O2 -L../../../unittest/mytap -o basic-t.exe basic-t.o -lmytap -lcrypt -lm libtool: link: cannot find the library `' or unhandled argument `Thompson/My'\ Path is truncated. What could cause this? try to build in a path with no space at all Thanks, Jet Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Windows GUI programs (e.g. notepad) start but are invisible after ssh login
On 7/2/2010 2:50 AM, Koszalek Opalek wrote: User Thorsten Kampe wrote: Same on Windows XP SP3... Is it possible to run sshd as a regular process rather than a service? I'm OK not seeing the GUI most of the time (I'm launching my application after logging over ssh, the application does some processing and then quits). However, if something goes wrong I would be happy to stop sshd service, launch sshd as a regular process, rerun the application and _see_ what goes wrong. You can run it as yourself in a terminal if you prefer. You cannot switch back and forth between running it as a service and running it in a terminal unless you run it as yourself in both circumstances. 'sshd' will not be able to switch user context unless you add privileges for your account, which adds to security concerns. FWIW, I have not tried doing this so there may be other bumps along the way. And this is not a method of operation supported by this list. But if you're game, give it a shot. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Weird directories on Windows share when using rm to delete a directory
On Jul 2 08:11, Slide wrote: snip So, IIUC, youre'saying that the directories get renamed to this temporary name, but they never disappear after rm -rf? Are you sure that no other process is accessing them? Does Cygwin recognize the drive as netapp if you add a mount point for it? How to check: If the drive has been mounted with a drive letter, say X:, what does `mount' print as drive type of /cygdrive/x? Or, if the drive is used via UNC path, just mount it temporarily like this: $ mount -f //server/share /mnt And see what a `mount' command prints for the .mnt mount point: $ mount Corinna I'm pretty sure there are no other processes accessing the files. $ mount ... Y: on /cygdrive/y type netapp (binary,posix=0,user,noumount,auto) So, yes, it does see it as a netapp. Now, from my horrible memory, it _seems_ like this started happening when we upgraded to Cygwin 1.7 from Cygwin 1.5. I don't know that for sure though, it just _seems_ that that is what happened. This funtionality wasn't available in 1.5, so, yes, this would only have started with 1.7. So it seems that these netapp drives somehow don't understand the entirely normal FileDispositionInformation method, or they ignore it for some unknown reason. Unfortunately the strace from your OP isn't helpful since it only contains the deletion of a single file. What would help is an strace of a rmdir or rm -rf(*) of a directory which then creates one of those temporary directories. There are lots of potential debug messages wqhich might sched a light here. Corinna (*) If possible with not more than a single file in the dir, so that the strace doesn't become too big. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: {aprutil1,libaprutil1,libaprutil1-devel}-1.3.9-3
A new version the Apache Portable Runtime utilities library is now available for download. CYGWIN NEWS: === This release is linked against libdb4.5 instead of libdb4.2. DESCRIPTION: The mission of the Apache Portable Runtime (APR) project is to create and maintain software libraries that provide a predictable and consistent interface to underlying platform-specific implementations. The primary goal is to provide an API to which software developers may code and be assured of predictable if not identical behaviour regardless of the platform on which their software is built, relieving them of the need to code special-case conditions to work around or take advantage of platform-specific deficiencies or features. DOWNLOAD: = Note that downloads from sourceware.org (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenberger daver...@acm.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: subversion-1.6.12-2
A new version of subversion is available. This version is linked against libdb4.5. CYGWIN NEWS: One test fails while using the serf HTTP library. Please switch to neon if you encounter problems with serf. The maintainer uses serf for most activities but does occasionally encounter segfaults and has to switch to neon. NEWS: = See CHANGES (URL below) for more information about the differences between 1.6.12 and previous Subversion releases. IMPORTANT: This release will silently upgrade your Subversion working copies to the 1.6 format, rendering them unusable with previous major versions of Subversion. Please see the release notes http://subversion.apache.org/docs/release-notes/1.6.html for more details about the changes in Subversion. See http://svn.apache.org/repos/asf/subversion/tags/1.6.12/CHANGES for more details about the changes in 1.6.12. DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/en/1.5/index.html for the latest official release of the Subversion Book, covering 1.5 or http://svnbook.red-bean.com/en/nightly/index.html for the WIP version of the book covering 1.6. DOWNLOAD: = Note that downloads from sourceware.org (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenberger daver...@acm.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Answer: How to fix error strace: error creating process vim, (error 2)
Since no one bothered to reply to my previous message (help the cygwin newbies, yall!), I'll post the answer. If you get: ~$ strace vim strace: error creating process vim, (error 2) ~$ strace It's because vim is a symlink, and strace can't follow symlinks, as it's not a cygwin.dll program. Instead, figure out where 'vim' (or whatever) goes. ~$ realpath `which vim` /usr/bin/gvim.exe ~$ strace /usr/bin/gvim.exe The strace manpage does say this now (in a roundabout way), but I didn't have the requisite optional manpage package installed at the time. DEVS: PLEASE file the missing error message text in strace (a cygwin-specific program!) as a bug, as the error message isn't missing (and replaced with cryptic error 2) on other platforms. Thomas Shanks -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
vimdiff sharing violation race condition when diffing .bashrc [Was: Re: Trouble with vimdiff and strace on most recent cygwin]
On Tue, Jun 22, 2010 at 9:13 PM, Thomas Shanks thomas.sha...@gmail.com wrote: ... $ vimdiff /etc/skel/.bashrc ~/.bashrc 2 files to edit 7 [?47h [27m [24m [0m [H [J [25;1H/etc/skel/.bashrc 130L, 3754C ~/.bashrc [25;13H [K [25;13H135L, 3884C 1 [main] gvim 1752 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1164 [main] gvim 1752 open_stackdumpfile: Dumping stack trace to gvim.exe.stackdump 1 [main] gvim 3760 exception::handle: Exception: STATUS_ACCESS_VIOLATION ... Cygwin.dll and/or Vim devs: It appears the file was somehow being locked by one of the vim processes (why does starting vim take a read-lock on .bashrc?) at the moment the other one was trying to read it. It is, it seems, a race condition. It was failing due to sharing violation 95% of the time, with both (!) vim processes failing to load their required file the majority of the time. This indicates that somehow the problem goes both ways: both the vim reading .bashrc and the other one trying to use .bashrc can experience a sharing violation in the same vimdiff call. The question I have is: why does starting vimdiff use .bashrc, and why would they both manage to experience a sharing violation when only one is editing .bashrc? Could this apply equally to diffing anything that vim loads during startup, including a syntax highlighting filetype config file or other config file? Thomas Shanks -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
problem updating to dash 0.5.6.1-2
Running `setup.exe`, to update dash from 0.5.6.1-1 to 0.5.6.1-2, produces: Unable to extract /usr/share/doc/dash/ChangeLog -- the file is in use. Please stop all Cygwin processes and select Retry, or select Continue to go on anyway (you will need to reboot). No Cygwin window is open, and no process reported by Task Manager appears relevant, except setup itself. So I see no Cygwin process to stop. Pressing Continue leads to hanging while displaying: Installing dash-0.5.6.1-2 /usr/share/doc/dash/ChangeLog -- rmd Cygwin Configuration Diagnostics Current System Time: Fri Jul 02 15:59:03 2010 Windows 7 Enterprise Ver 6.1 Build 7600 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\opus\nti C:\GP C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0\ C:\Program Files\Common Files\Roxio Shared\DLLShared\ C:\Program Files\Common Files\Roxio Shared\10.0\DLLShared\ C:\Program Files\QuickTime\QTSystem\ C:\Program Files\SAS\Shared Files\Formats C:\PROGRA~1\CA\SHARED~1\SCANEN~1 C:\LF9571\Bin C:\cygwin\lib\lapack Output from C:\cygwin\bin\id.exe UID: 50597(mcdougar) GID: 10513(Domain Users) 10513(Domain Users) 545(Users) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'mcdougar' PWD = '/cygdrive/c/home/d' HOME = '/cygdrive/c/home' HOMEPATH = '\' MANPATH = '/usr/local/man:/usr/share/man:/usr/man:' APPDATA = 'C:\Users\mcdougar\AppData\Roaming' HOSTNAME = '1145-AE00533' GPFLIB = 'C:\lf9571\lib' TERM = 'cygwin' RoxioCentral = 'C:\Program Files\Common Files\Roxio Shared\10.0\Roxio Central36\' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 4 Stepping 3, GenuineIntel' WINDIR = 'C:\Windows' PERL5LIB = '/usr/local/lib/perl5' TEXDOCVIEW_txt = 'cygstart %s' CVSROOT = '/cygdrive/c/home/cvsroot' TEXDOCVIEW_dvi = 'cygstart %s' PUBLIC = 'C:\Users\Public' OLDPWD = '/cygdrive/c/home' USERDOMAIN = 'ONEPURDUE' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' FLIB_DVT_BUFFER = '0' TEMP = '/cygdrive/c/Users/mcdougar/AppData/Local/Temp' DEFLOGDIR = 'C:\ProgramData\McAfee\DesktopProtection' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' Lib = 'C:\LF9571\Lib' QTJAVA = 'C:\Program Files\Java\jre6\lib\ext\QTJava.zip' USERNAME = 'mcdougar' GPDIR = 'C:\GP' TEXDOCVIEW_pdf = 'cygstart %s' PROCESSOR_LEVEL = '15' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' TEXDOCVIEW_html = 'cygstart %s' LANG = 'C.UTF-8' USERPROFILE = 'C:\Users\mcdougar' FCEDIT = '/usr/bash/vim' PS1 = '\[\033[0;32m\]\!$\[\033[0m\] ' LOGONSERVER = '\\WPPCENDC05' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\mcdougar\AppData\Local' !C: = 'C:\cygwin\bin' ProgramData = 'C:\ProgramData' SHLVL = '1' OSTYPE = 'cygwin' USERDNSDOMAIN = 'CENTRAL.PURDUE.LCL' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'H:' BASH_ENV = '/cygdrive/c/home/.bash_env' PROMPT = '$P$G' COMSPEC = 'C:\Windows\system32\cmd.exe' TMP = '/tmp' SYSTEMROOT = 'C:\Windows' VISUAL = '/usr/bin/vim' PRINTER = '\\1145prt\HP571B_PCL' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0403' CLASSPATH = '.;C:\Program Files\Java\jre6\lib\ext\QTJava.zip' TEXDOCVIEW_ps = 'cygstart %s' CVSEDITOR = '/usr/bin/vim' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' HOMESHARE = '\\stone.ics.purdue.edu\mcdougar' NUMBER_OF_PROCESSORS = '2' AVENGINE = 'C:\PROGRA~1\CA\SHARED~1\SCANEN~1' VIM = '/usr/share/vim' VSEDEFLOGDIR = 'C:\ProgramData\McAfee\DesktopProtection' Include = 'C:\LF9571\Include' asl.log = 'Destination=file;OnFirstLog=command,environment' SESSIONNAME = 'Console' HISTFILE = '/cygdrive/c/home/.bash_history' COMPUTERNAME = '1145-AE00533' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Console\Cygwin (default) = 0x0007 PopupColors = 0x00f5 ColorTable00 = 0x ColorTable01 = 0x0080 ColorTable02 = 0x8000 ColorTable03 = 0x00808000 ColorTable04 = 0x0080 ColorTable05 = 0x00800080 ColorTable06 = 0x8080 ColorTable07 = 0x00c0c0c0 ColorTable08 = 0x00808080 ColorTable09 = 0x00ff ColorTable10 = 0xff00 ColorTable11 = 0x0000 ColorTable12 = 0x00ff ColorTable13 = 0x00ff00ff ColorTable14 = 0x ColorTable15 = 0x00ff InsertMode = 0x0001 QuickEdit = 0x FullScreen = 0x ScreenBufferSize = 0x012c0050 WindowSize = 0x00320050 FontSize = 0x FontFamily = 0x FontWeight = 0x FaceName = '' CursorSize = 0x0019 HistoryBufferSize = 0x0032 NumberOfHistoryBuffers = 0x0004 HistoryNoDup = 0x HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Installations (default) = '\??\C:\cygwin' HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup (default) = 'C:\cygwin'
Re: problem updating to dash 0.5.6.1-2
On 7/2/2010 4:57 PM, Robert McDougall wrote: Running `setup.exe`, to update dash from 0.5.6.1-1 to 0.5.6.1-2, produces: Unable to extract /usr/share/doc/dash/ChangeLog -- the file is in use. Please stop all Cygwin processes and select Retry, or select Continue to go on anyway (you will need to reboot). No Cygwin window is open, and no process reported by Task Manager appears relevant, except setup itself. So I see no Cygwin process to stop. Pressing Continue leads to hanging while displaying: Installing dash-0.5.6.1-2 /usr/share/doc/dash/ChangeLog My guess is the Logitech Process Monitor service listed in the Potential app conflicts section of your cygcheck output. Uninstall this and try again. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mutt and perl-ming
On 7/2/2010 9:22 AM, Corinna Vinschen wrote: On Jul 1 17:14, Lee Rothstein wrote: I got bitten by the misconfig of gnome-canvas on kernel.org. That plus, bandwidth shenanigans by Comcast, and probably some errors in my recovery process left me with a bunch of missing pieces from sundry packages. I've fixed all the problems except for 'mutt' and 'perl-ming' (jeff? ;-)). No amount of reinstalling, uninstalling and installing seems to fix these residual problems. Clues greatly appreciated! Attached is my 'cygcheck' output. As long as I'm asking questions, why does 'cygcheck' no longer properly list?: Last downloaded files to: ”' Last downloaded files from: ”' Oh, hmm. The latest versions of setup have changed the way the information is stored, but cygcheck doesn't yet know that. It still looks in the old places. This needs fixing... I presume you're saying that the cygcheck problem is caused by the information being stored in a new locations, but not the mutt and perl-ming install issues?! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: googlecl-0.9.8-1
Version 0.9.8-1 of googlecl has been uploaded. GoogleCL brings Google services to the command line. For examples see: http://code.google.com/p/googlecl/wiki/ExampleScripts Change include: * Proper login procedure for Apps users * setuptools support * Uploading directory trees to Docs * Multiple-calendar tasks *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
Updated: {aprutil1,libaprutil1,libaprutil1-devel}-1.3.9-3
A new version the Apache Portable Runtime utilities library is now available for download. CYGWIN NEWS: === This release is linked against libdb4.5 instead of libdb4.2. DESCRIPTION: The mission of the Apache Portable Runtime (APR) project is to create and maintain software libraries that provide a predictable and consistent interface to underlying platform-specific implementations. The primary goal is to provide an API to which software developers may code and be assured of predictable if not identical behaviour regardless of the platform on which their software is built, relieving them of the need to code special-case conditions to work around or take advantage of platform-specific deficiencies or features. DOWNLOAD: = Note that downloads from sourceware.org (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenberger daver...@acm.org
Updated: subversion-1.6.12-2
A new version of subversion is available. This version is linked against libdb4.5. CYGWIN NEWS: One test fails while using the serf HTTP library. Please switch to neon if you encounter problems with serf. The maintainer uses serf for most activities but does occasionally encounter segfaults and has to switch to neon. NEWS: = See CHANGES (URL below) for more information about the differences between 1.6.12 and previous Subversion releases. IMPORTANT: This release will silently upgrade your Subversion working copies to the 1.6 format, rendering them unusable with previous major versions of Subversion. Please see the release notes http://subversion.apache.org/docs/release-notes/1.6.html for more details about the changes in Subversion. See http://svn.apache.org/repos/asf/subversion/tags/1.6.12/CHANGES for more details about the changes in 1.6.12. DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/en/1.5/index.html for the latest official release of the Subversion Book, covering 1.5 or http://svnbook.red-bean.com/en/nightly/index.html for the WIP version of the book covering 1.6. DOWNLOAD: = Note that downloads from sourceware.org (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenberger daver...@acm.org
