Re: [ITA] xerces-c
On Apr 23 00:02, Charles Wilson wrote: Updated to 2.8.0, switched to cygport build framework, and renamed xerces-c-devel package to libxerces-c-devel. Also, added xerces-c-test package containing test and utility programs, installed into /usr/lib/xerces-c-test/. http://cygwin.cwilson.fastmail.fm/ITP/xerces-c-2.8.0-1-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/xerces-c-2.8.0-1.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/libxerces-c28-2.8.0-1.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/libxerces-c-devel-2.8.0-1.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/xerces-c-doc-2.8.0-1.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/xerces-c-test-2.8.0-1.tar.bz2 Packaging and hint files are looking good to me. Thanks for taking over maintainership. Feel free to upload. I marked the xerces-c-devel package as obsolete now in the maintainer list. What about the old libxerces-c21 - libxerces-c25 packages? Is any of them obsolete, too? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
P?teris K?avi? wrote: So why can't the registry entry be path-to-dll instead of the fixed 'setup\rootdir' in order that the setup application could populate a drop-down list of all currently installed Cygwins? It could. But I think Chuck made a good point that the ability to have multiple installed copies extends to what you might call expert users, i.e. they must know the ins and outs of not actually ever using these two installs at once. And so we need to be careful not to give the impression that this is supposed to work in the general case. Maybe all cyg*.exe native Windows applications could use this same algorithm to compute their root. cygcheck and strace are the only things that use the code in question, and strace only uses it for the purpose of resolving the win32 filename of the output file specified with -o. Would this problem go away if cygrunsrv.exe used the same algorithm to compute its root? No, the problem is that the operating system's service configuration in the registry needs the path to cygrunsrv.exe -- it needs to know the path to the image to execute, and we of course have no control over that. The only workaround I can think of to providing an absolute path would be to use the REG_EXPAND_SZ key type's capability to expand variables from the environment, e.g. %CygwinRoot%\bin\cygrunsrv.exe. However, this doesn't really solve anything, it just shifts the problem to making sure this variable is set. And even if you figured out a way to do that, the change in environment would not take effect in the services.exe process until the next time it was started, i.e. a reboot. It would still be easier just to edit the service config after moving the files. I have (finally) started using an environment where I share all my personal files on a separate disk drive accessible from all my bootable operating systems, whether it's Vista, WS2008, or Debian. The drive names (and mount points) vary. It's the same as moving install trees, and it would be nice if Cygwin didn't really care that when I started the services this time they were started from a different location than last time. In this case the problem has nothing to do with any code in Cygwin. But no I don't see your situation as the same, since as long as the location is consistent on any given system, you can install the service once and it will continue to be correct from there on. Brian
Re: [ITA] xerces-c
Corinna Vinschen wrote: Packaging and hint files are looking good to me. Thanks for taking over maintainership. Feel free to upload. OK. I marked the xerces-c-devel package as obsolete now in the maintainer list. What about the old libxerces-c21 - libxerces-c25 packages? Is any of them obsolete, too? Yes. Apparently nothing in the official distro uses any of them. -- Chuck
Re: [ITA] xerces-c
Charles Wilson wrote: I marked the xerces-c-devel package as obsolete now in the maintainer list. What about the old libxerces-c21 - libxerces-c25 packages? Is any of them obsolete, too? Yes. Apparently nothing in the official distro uses any of them. Actually, I think libxerces-c21, -c22, and -c23 should be *removed* entirely. They do not have source. (Alternatively, I could rummage around in the cygwin time machine and retrieve the appropriate source tarball). Why hasn't upset caught this? Each respective setup.hint specifies 'external-source: xerces-c' but there is no xerces-c-src package for, e.g. verison 2.4.0-4. -- Chuck
Re: [ITA] xerces-c
On Apr 23 10:50, Charles Wilson wrote: Charles Wilson wrote: I marked the xerces-c-devel package as obsolete now in the maintainer list. What about the old libxerces-c21 - libxerces-c25 packages? Is any of them obsolete, too? Yes. Apparently nothing in the official distro uses any of them. Actually, I think libxerces-c21, -c22, and -c23 should be *removed* entirely. They do not have source. Go ahead. Thanks for catching this. I'll remove them from my package list, too. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Brian Dessent wrote: So why can't the registry entry be path-to-dll instead of the fixed 'setup\rootdir' in order that the setup application could populate a drop-down list of all currently installed Cygwins? It could. Excellent. I second your suggestion. :-) But I think Chuck made a good point that the ability to have multiple installed copies extends to what you might call expert users, i.e. they must know the ins and outs of not actually ever using these two installs at once. And so we need to be careful not to give the impression that this is supposed to work in the general case. Sigh. Yes I read Chuck's clear denouncement that there is any whisper of there being a goal to support multiple Cygwin DLL's running simultaneously. However, that doesn't stop me from lobbying for setting up such a goal, and having a path-to-dll registry entry for the Cygwin DLL would be a step towards it, even if in the short term there was only one such path allowed in the registry, i.e., subsequent Cygwin setups would remove the previous path and replace it with the current user's choice, if it was different. Peter Klavins
[RFU] monotone-0.40-1
http://lapo.it/~lapo/cygwin/monotone-0.40-1.tar.bz2 http://lapo.it/~lapo/cygwin/monotone-0.40-1-src.tar.bz2 http://lapo.it/~lapo/cygwin/setup.hint Dependencies have changed (since 0.38, actually, but I forgot to point it out): libboost is no more required at runtime, only at build time. sdesc: free distributed version control system ldesc: monotone is a free distributed version control system. it provides a simple, single-file transactional version store, with fully disconnected operation and an efficient peer-to-peer synchronization protocol. it understands history-sensitive merging, lightweight branches, integrated code review and 3rd party testing. it uses cryptographic version naming and client-side RSA certificates. it has good internationalization support, has no external dependencies, runs on linux, solaris, OSX, windows, and other unixes, and is licensed under the GNU GPL. category: Devel requires: libiconv2 libintl8 zlib PS: this package is the result of 10 hours of compilation under QEMU ;-) -- Lapo Luchini [EMAIL PROTECTED] (OpenPGP X.509) www.lapo.it (Jabber, ICQ, MSN)
src/winsup/cygwin ChangeLog cygwin.din path.cc ...
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2008-04-23 11:13:52 Modified files: winsup/cygwin : ChangeLog cygwin.din path.cc syscalls.cc winsup/cygwin/include/cygwin: version.h Log message: * cygwin.din: Sort. (faccessat): Export. (fchmodat): Export. (fchownat): Export. (fstatat): Export. (futimesat): Export. (linkat): Export. (mkdirat): Export. (mkfifoat): Export. (mknodat): Export. (openat): Export. (readlinkat): Export. (renameat): Export. (symlinkat): Export. (unlinkat): Export. * path.cc (readlink): Align definition to POSIX. * syscalls.cc (gen_full_path_at): New static function. (faccessat): Implement. (fchmodat): Implement. (fchownat): Implement. (fstatat): Implement. (futimesat): Implement. (linkat): Implement. (mkdirat): Implement. (mkfifoat): Implement. (mknodat): Implement. (openat): Implement. (readlinkat): Implement. (renameat): Implement. (symlinkat): Implement. (unlinkat): Implement. * include/cygwin/version.h: Bump API minor number. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4114r2=1.4115 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygwin.din.diff?cvsroot=srcr1=1.187r2=1.188 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.492r2=1.493 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srcr1=1.487r2=1.488 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/version.h.diff?cvsroot=srcr1=1.263r2=1.264
wait.h
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 glibc ships a wait.h which contains only one line: #include sys/wait.h I know of at least three packages that #include wait.h instead of sys/wait.h. Could such a header please be added to Cygwin (preferably to both branches)? Patch attached; I presume this is trivial enough to not require a copyright assignment. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgPi30ACgkQpiWmPGlmQSOIMgCg3ZFsz6Zc+nld3dEG+OnNuud9 5oMAn1T1hG2bJJ5JFhziC0w9ffN9aWW2 =ObqW -END PGP SIGNATURE- Index: ChangeLog === RCS file: /cvs/src/src/winsup/cygwin/ChangeLog,v retrieving revision 1.4116 diff -u -r1.4116 ChangeLog --- ChangeLog 23 Apr 2008 11:19:57 - 1.4116 +++ ChangeLog 23 Apr 2008 17:48:09 - @@ -1,3 +1,7 @@ +2008-04-23 Yaakov (Cygwin Ports) [EMAIL PROTECTED] + + * include/wait.h: New file. + 2008-04-23 Corinna Vinschen [EMAIL PROTECTED] * posix.sgml: Add openat, faccessat, fchmodat, fchownat, fstatat, Index: include/wait.h === RCS file: include/wait.h diff -N include/wait.h --- /dev/null 1 Jan 1970 00:00:00 - +++ include/wait.h 23 Apr 2008 17:48:09 - @@ -0,0 +1,16 @@ +/* wait.h + + Copyright 2008 Red Hat, Inc. + +This file is part of Cygwin. + +This software is a copyrighted work licensed under the terms of the +Cygwin license. Please consult the file CYGWIN_LICENSE for +details. */ + +#ifndef _WAIT_H +#define _WAIT_H + +#include sys/wait.h + +#endif /* _WAIT_H */
Re: wait.h
Yaakov (Cygwin Ports) wrote, On 23.4.2008 21:18: glibc ships a wait.h which contains only one line: #include sys/wait.h I know of at least three packages that #include wait.h instead of sys/wait.h. Could such a header please be added to Cygwin (preferably to both branches)? Patch attached; I presume this is trivial enough to not require a copyright assignment. Yaakov I strongly think you should fix the packages and send the patches upstream instead. -- VH signature.asc Description: OpenPGP digital signature
Re: wait.h
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Václav Haisman wrote: | I strongly think you should fix the packages and send the patches | upstream instead. I don't disagree that using wait.h isn't very portable, but glibc has it. The point is that we should be trying to be compatible with glibc when possible. This patch is a small price to pay to make building software on Cygwin that much closer to Linux. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgQG5sACgkQpiWmPGlmQSM97QCeMYcn39K5qbwwyC2KZ6e16Kwb AWYAn3mktGXW4wCyyvNrLZMSTduL+GlK =UWnF -END PGP SIGNATURE-
Re: Looking for basic documentation on Cygwin and Serial Ports
Nefastor wrote: I want to write simple programs which use the serial port (for example, a program that will trap and log activity on a serial port, nothing fancy). I know how to do that under Linux, and under DOS as well. The problem is I don't know which of Cygwin's /dev/tty device corresponds to which serial port on my PC (that is, I only know the COM port number). I can sort of guess /dev/tty0 is COM1, but that's a guess, and I'd prefer some certainty. Cygwin works the same as Linux, /dev/ttyS0 is the first serial device, /dev/ttyS1 is the second, etc. Please consult the users guide: http://cygwin.com/cygwin-ug-net/using-specialnames.html. It gets complicated : I'd like my programs to work with any kind of RS-232 port, especially USB adapters (FTDI chips) and USB Bluetooth dongles. While Google-ing around I found mention of exotic devices such as /dev/ttyUSB0 or even /dev/usb/tty, and what I COULDN'T find was a clear explanation of which exist and which work in Cygwin. It will still be /dev/ttySnumber for USB devices, just with a number like 9 or whatever, corresponding to whatever emulated serial device it is configured as (e.g. COM10 in this case.) Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
fork: child -1 - CreateProcessA failed, errno 11
Hi, I am using cygwin for comiling Mono on Windows but recently I kepp getting error messages: 18858 [main] sh 93120 fork: child -1 - CreateProcessA failed, errno 11 1168010 [main] sh 93120 fork: child -1 - CreateProcessA failed, errno 11 3176500 [main] sh 93120 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: line 2513: /usr/bin/sed: Resource temporarily unavailable ... After that all further process creation fails and while make is trying to create new processes, process initialization of other non-cygwin processes (like iexplore.exe) fails as well with a MessageBox from ntdll.dll. This problem occurs after some time of using cygwin but at random points. It's very weird that after terminating all processes that use cygwin (I checked this with Process Explorer) the problem still remains. Logging out (killing the window session) doesn't help either. The only solution is to restart Windows. Please let me know what should I do to resolve the problem. Thank you very much. Please reply to my address as well, I'm not on the list. Kornél -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin-1.7.0-3 problem (wet paint version)
Corinna Vinschen wrote: On Apr 20 14:52, Trevor Forbes wrote: I access my windows XP PC either via rdesktop or ssh on a Linux Gentoo PC. (Note I use using XPUnlimited to get multiple rdesktops) Using Cygwin-1.7.0-3 I found I can run Cygwin application via ssh or rdesktop but not both at the same time. Strange. But I'm still heavily working on this stuff. With my current local code I can't reproduce this, neither on XP, nor on 2K8. I guess I'll check in my changes and create a 1.7.0-4 today, so you have something new for testing. Thanks for the report, Corinna That fixed the problem although I not sure why looking at the changes... Thanks for all the great work... Trevor -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: fork: child -1 - CreateProcessA failed, errno 11
Kornél Pál wrote on 23 April 2008 12:31: I am using cygwin for comiling Mono on Windows but recently I kepp getting error messages: 18858 [main] sh 93120 fork: child -1 - CreateProcessA failed, errno 11 1168010 [main] sh 93120 fork: child -1 - CreateProcessA failed, errno 11 3176500 [main] sh 93120 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: line 2513: /usr/bin/sed: Resource temporarily unavailable ... After that all further process creation fails and while make is trying to create new processes, process initialization of other non-cygwin processes (like iexplore.exe) fails as well with a MessageBox from ntdll.dll. This problem occurs after some time of using cygwin but at random points. It's very weird that after terminating all processes that use cygwin (I checked this with Process Explorer) the problem still remains. Which rather suggests it is not a problem with Cygwin (which is a user-mode application and should not be able to break or otherwise affect separate processes or the O/S kernel). Please let me know what should I do to resolve the problem. Identify the BLODA application that has borked your computer: http://cygwin.com/acronyms#BLODA http://cygwin.com/faq/faq-nochunks.html#faq.using.bloda and uninstall it. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: fork: child -1 - CreateProcessA failed, errno 11
Hi, Thank you very much for the information, and please forgive me for this reply if I have the problem described in the FAQ. I only have Windows Defender installed from the list but I am using it with cygwin for more than a year without any problems. Note that according to the error message CreateProcessA is failing rather than cygwin's fork implementation and other processes not related to cygwin start fail to initialize (CreateProcess fails) after cygwin starts failing. Have anybody else experienced this problem? Kornél - Original Message - From: Dave Korn To: 'Kornél Pál' Sent: Wednesday, April 23, 2008 2:27 PM Subject: RE: fork: child -1 - CreateProcessA failed, errno 11 Kornél Pál wrote on 23 April 2008 12:31: I am using cygwin for comiling Mono on Windows but recently I kepp getting error messages: 18858 [main] sh 93120 fork: child -1 - CreateProcessA failed, errno 11 1168010 [main] sh 93120 fork: child -1 - CreateProcessA failed, errno 11 3176500 [main] sh 93120 fork: child -1 - CreateProcessA failed, errno 11 ../../libtool: line 2513: /usr/bin/sed: Resource temporarily unavailable ... After that all further process creation fails and while make is trying to create new processes, process initialization of other non-cygwin processes (like iexplore.exe) fails as well with a MessageBox from ntdll.dll. This problem occurs after some time of using cygwin but at random points. It's very weird that after terminating all processes that use cygwin (I checked this with Process Explorer) the problem still remains. Which rather suggests it is not a problem with Cygwin (which is a user-mode application and should not be able to break or otherwise affect separate processes or the O/S kernel). Please let me know what should I do to resolve the problem. Identify the BLODA application that has borked your computer: http://cygwin.com/acronyms#BLODA http://cygwin.com/faq/faq-nochunks.html#faq.using.bloda and uninstall it. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: fork: child -1 - CreateProcessA failed, errno 11
Kornél Pál wrote on 23 April 2008 14:00: Hi, Thank you very much for the information, and please forgive me for this reply if I have the problem described in the FAQ. I only have Windows Defender installed from the list but I am using it with cygwin for more than a year without any problems. It could be that you have discovered a new entry for the list :-( Note that according to the error message CreateProcessA is failing rather than cygwin's fork implementation and other processes not related to cygwin start fail to initialize (CreateProcess fails) after cygwin starts failing. Yes, this almost certainly means some buggy software (antivirus? desktop firewall? other security software?) which includes a kernel-mode component (device driver or filter) is leaking O/S resources such as pool memory or handles. You might be able to track it down by use of the windows Driver verifier: http://support.microsoft.com/kb/244617 http://www.microsoft.com/whdc/DevTools/tools/DrvVerifier.mspx although it's a fairly advanced debugging tool, but for your purposes you'd just want to enable it for all devices, run your system up to the point the errors start to arise, and if it spots any misbehaviour it'll give you a BSOD that clearly identifies the faulty driver. (Then disable verification again after the reboot!) Have anybody else experienced this problem? Many people, many times, and IIRC it has /always/ turned out to be some other application interfering. Like I say, your first suspicion should be security-related software or anything that installed a device driver. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Fwd: gcc does not honor -fno-leading-underscore flag?
Brian Dessent wrote: [EMAIL PROTECTED] wrote: I do not know how to get rid of the leading underscores in Cygwin. I have other sources compiled in Linux, and they do not have a leading underscore added. As I understand it, the -fleading-underscore flag is only useful to add a leading underscore for targets that do not have a leading underscore, like linux. It won't accomplish anything on one that already has it, like PE. You may be right. But then this is strange for me. I would guess that either -fleading-underscore or -fno-leading-underscore do something, but not both doing nothing. So if a target does have a leading underscore and then -fleading-underscore does nothing on it (according to what you say), then I would expect -fno-leading-underscore removing the underscore. Now my problem is that I have a library with symbol names without a leading underscore. Although the library is for Linux (I do not have a version specific for Cygwin, which would be the ideal solution, and I do not think that I could get it; I don't have the sources), I expect it to work under Cygwin (or at least give it a try), if only I could get my objects to link with its symbols. Even if I am trying to mix objects for different platforms, I guess that there should be a chance to do it by appropriate configuration. The flag -fno-leading-underscore seemed to be the answer, but it did not work for me. There is absolutely no way that you can use an object compiled for Linux with Cygwin. The fact that symbols don't have a leading underscore is trivial compared to the massive differences between ELF and PE formats. There is just no chance of this working even if you solved the underscore issue. I suspected this, but I was not sure. I do not know what is ELF and PE... I though about trying since I have Windows apps that work on Cygwin, but possibly they are much more similar. Thanks a lot. Santiago Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Fwd: gcc does not honor -fno-leading-underscore flag?
[EMAIL PROTECTED] wrote: You may be right. But then this is strange for me. I would guess that either -fleading-underscore or -fno-leading-underscore do something, but not both doing nothing. So if a target does have a leading underscore and then -fleading-underscore does nothing on it (according to what you say), then I would expect -fno-leading-underscore removing the underscore. Adding an extra underscore on a platform that doesn't have one isn't doing anything that you couldn't equivalently accomplish at the source level, so it's not really violating any ABIs. However, removing the underscore when the platform spec says that all symbols must have a leading underscore prepended would violate the ABI, and there is no way[1] to achieve the equivalent thing at the source level so this is a much more dangerous proposition. That is the intent of the switch; it is not designed for what you're trying to make it do. I suspected this, but I was not sure. I do not know what is ELF and PE... I though about trying since I have Windows apps that work on Cygwin, but possibly they are much more similar. I think you are confused about what Cygwin is. It is not a binary emulator of any kind, it is a Win32 library just like any other DLL. All Cygwin apps are standard Win32 executables/libraries, there is no difference as far as the operating system is concerned. The reason you cannot use an object compiled with a Linux compiler is because Linux uses an entirely different binary format and ABI. Even though they may run on the same identical hardware, the details of how things work at the assembler and linker level are significantly different. The fact that it's gcc on both sides doesn't change anything, because gcc's behavior is determined entirely by the target it was configured for; two gccs of different targets are essentially two totally different compilers. Brian [1] well technically it's possible using __asm__() but that's an extension and not standard C. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Download Incomplete. Try again? failures
A little more information... It appears as though the package, _update-info-dir-00605-1.tar.bz2, does not exist on any of the mirrors that I am using. What does exist is _update-info-dir-00726-1.tar.bz2. I am using the latest version of cygwin setup. I leave the package list at Default and select either Prev or Curr versions with the same result. Any idea why it's trying to download a package that does not exist? Any idea why this package is not in the list of packages I'm selecting, it's not in the list of dependencies that pop up, and yet, cygwin setup tries to download it anyway? -Original Message- From: LATHAM, JUSTIN HS Sent: Tuesday, April 22, 2008 2:33 PM To: 'cygwin@cygwin.com' Subject: Download Incomplete. Try again? failures I am trying to install Cygwin on a Windows XP PC that has not previously had it installed. Since I want to install the exact same distribution on multiple PCs, I am selecting the Download Without Installing option to just get the packages I want first. I have attempted the operation on 4 different mirrors with the same result. From each, I get the Download Incomplete. Try again? error box when it is trying to download _update-info-dir-00605-1.tar.bz2. I am attaching my setup.log and setup.log.full to assist in debugging the problem. Please let me know if you have any thoughts what I might be doing incorrectly. Thanks in advance, Justin -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
On Mon, Apr 21, 2008 at 11:35:51AM +0100, Dave Korn wrote:
* On Sat, Apr 19, 2008 at 06:59:56PM +0200 I wrote:
Ok, here is the description: Sometimes (!) when I do a svn co or svn
up, I get the following error:
svn: Can't move 'src/arch/riscos/.svn/tmp/all-wcprops' to
'src/arch/riscos/.svn/all-wcprops': Permission denied
It is a problem of my Anti-Virus solution. So, I have already contacted
the company which develops it.
Ah, this problem happens sometimes: the anti-virus on-access scanner keeps a
handle open to the file a bit too long, interfering with normal operations
that require unshared access.
I gather that this issue has been brought up several times over the
last few years already but nothing has been done about it other than
to say disable your virus checker/indexing service.
Why doesn't the Cygwin SVN build simply just #define WIN32 (or
whatever it takes) so the code which is _already in SVN_ to work
around this problem is actually used to fix the issue? I have not
seen anyone give a reason as to why this shouldn't be done. (If
there is, please feel free to flame me :)
I work with a repository of about 2GB and nearly a hundred thousand
files. I have never been able to check this out with Cygwin SVN
without it failing - company policy does not allow disabling of
virus checkers (as does the lack of admin rights). The only reliable
workaround I have found is to:
(a) check it out with WinSVN (the Win32 build of SVN) - this
always works flawlessly, but creates non-Cygwin symlinks;
(b) go through and remove the symlinks in Cygwin:
svn status | awk '/^~/ {print $2}' | xargs rm -f
(c) svn update in Cygwin to restore the small handful of symlinks
in Cygwin-style symlinks
taking about twice as long. It would be much easier if the SVN
binary in Cygwin would DTRT in the first place.
Is there a showstopping reason why this can't be done? I would be
more than happy to test it out :)
Cheers,
Bernard.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Bernard Blackham wrote: Why doesn't the Cygwin SVN build simply just #define WIN32 (or whatever it takes) so the code which is _already in SVN_ to work around this problem is actually used to fix the issue? I have not seen anyone give a reason as to why this shouldn't be done. (If there is, please feel free to flame me :) Because defining WIN32 would enable all of the native Windows codepaths and disable all the POSIX codepaths... that would not work very well considering that all Cygwin functions expect POSIX paths not Win32 paths. You'd essentially be building a native Win32 svn client that has no POSIX capability but still uses the Cygwin library, the worst of all possible worlds. But I'm quite sure you wouldn't even get that far since all those MSVCRT-specific things would stop it from even building, such as 1-arg vs 2-arg mkdir(), %lld vs %I64d, : vs ;, _foo vs foo, etc. What really needs to happen is to find just those places where a virus scanner workaround exists and change #ifdef _WIN32 to #if defined(_WIN32) || defined(__CYGWIN__). Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Bernard Blackham wrote on 23 April 2008 18:08: Why doesn't the Cygwin SVN build simply just #define WIN32 (or whatever it takes) so the code which is _already in SVN_ to work around this problem is actually used to fix the issue? I have not seen anyone give a reason as to why this shouldn't be done. (If there is, please feel free to flame me :) I don't know in this specific case, but in the general case: nobody else is reporting having this problem apart from you. There are millions of other programs out there that aren't cygwin, and it seems Just Plain Wrong to twist and contort cygwin until it's bent completely out of shape trying to fix other people's bug in other people's software. (Historically, that's one of the prime reasons why the windows OS itself is such a godawful mess) Simply defining WIN32, btw, will not work. It will bring in all sorts of code that assumes MSVCRT functions are available, and just break the .. (oh, hang on, I see Brian has just addressed this point, so I'll leave off there). I work with a repository of about 2GB and nearly a hundred thousand files. I have never been able to check this out with Cygwin SVN without it failing - company policy does not allow disabling of virus checkers (as does the lack of admin rights). Again; if it is your company policy to force you to use buggy AV software that breaks the vital tools you need to perform your work, then your company's policy is bad and wrong, and nobody is particuarly inclined to try and work around it in cygwin, potentially impairing the operation of cygwin for the everybody-else-in-the-world who does /not/ work for your company. It would be much easier if the SVN binary in Cygwin would DTRT in the first place. It DOES do absolutely the right thing, and is prevented from success by external force majeure. All cygwin does is open, read, write, and close files. Any system on which those fundamental operations can fail owing to the interference of another application is fundamentally broken, and it is not cygwin's fault for in any way not doing the right thing. Is there a showstopping reason why this can't be done? I would be more than happy to test it out :) Of course there is no reason why it is impossible in theory, but there may be engineering reasons such as performance impact why it is not desirable in practice. SVN is an open source project like any other, so if you want this changed, your best bet is to send a patch upstream to the responsible maintainers. It would greatly strengthen the argument for inclusion of the patch if you accompanied it with timings of testruns that show it does not cause any significant performance degradation - not, of course, when compared with the version that can't fully run under your buggy antivirus, but when compared with the unpatched version running under no antivirus, or when comparing the two as run under a different antivirus; you can't justify causing a slowdown for everybody by pointing to your one broken machine and saying it's not slower on that, for example. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | That was fixed in libtool CVS after 2.2.2 was released: | http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00019.html | but this release is 'stock' libtool-2.2.2 with only your patches. I'm not sure what's triggering this, but *sometimes* I'm getting more than that: ./.libs/lt-foo.c:263: warning: string length `4368' is greater than the length `4095' ISO C99 compilers are required to support ./.libs/lt-foo.c: In function `main': ./.libs/lt-foo.c:288: warning: implicit declaration of function `_setmode' ./.libs/lt-foo.c: In function `chase_symlinks': ./.libs/lt-foo.c:577: warning: implicit declaration of function `realpath' ./.libs/lt-foo.c:577: warning: assignment makes pointer from integer without a cast strip: './foo.exe': No such file When this does happen, the libtool launchers 'foo' and 'foo.exe' are NOT created in the build directory, but the real executable .libs/foo.exe is built. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgPsroACgkQpiWmPGlmQSOrRACdGr3iBUSF+KVg813/0M78viI2 2GYAoKVkVJnkhy641kx6uVQxYGvaO7VM =OnNU -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Alone tonight? | 00
By far you're bored with that.. go to http://lovecomes.2ya.com and find your next Date / Love / penpal.. in your area! - Have a nice night! :) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Fwd: gcc does not honor -fno-leading-underscore flag?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to [EMAIL PROTECTED] on 4/23/2008 8:27 AM: | As I understand it, the -fleading-underscore flag is only useful to add | a leading underscore for targets that do not have a leading underscore, | like linux. It won't accomplish anything on one that already has it, | like PE. | | You may be right. But then this is strange for me. I would guess that | either -fleading-underscore or -fno-leading-underscore do something, but | not both doing nothing. I look at it this way: -fleading-underscore adds an underscore on platforms where it is not necessary (and is a no-op on platforms where leading underscore is already required); -fno-leading-underscore undoes the effect of an earlier -fleading-underscore (removes the underscore where possible, and is a no-op on platforms like cygwin where it is not possible). - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgP/nsACgkQ84KuGfSFAYCnXgCePRD9+U8AZusRmgRqWeBjhtmK sEEAn3hHttMrUCi21Ch13oC7aL5fZJL5 =pizv -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: {xerces-c/libxerces-c-devel/xerces-c-doc}-2.8.0-1 New: {libxerces-c28/xerces-c-test}-2.8.0-1
I've adopted the xerces-c package and updated the version to 2.8.0-1. xerces-c is a validating XML parser written in a portable subset of C++ (it is also known as Xerces-C++). xerces-c makes it easy to give your application the ability to read and write XML data. A shared library is provided for parsing, generating, manipulating, and validating XML documents. Changes since 2.5.0-1 == * new maintainer * switched to cygport build framework * renamed xerces-c-devel -- libxerces-c-devel * new xerces-c-test package provides test and utility programs * updated to latest upstream release The changes in the various official release since the last cygwin release are summarized below. xerces-c 2.8.0 (August 31, 2007) * Exponential growth of memory block (from 16KB to 128KB) that are allocated by the DOM heap. * The NODE_CLONED notification is now sent to each node's user data handler when cloning the entire DOMDocument. * On Windows extract the registry code page from MIME\Database\Charset\encoding[EMAIL PROTECTED] instead of MIME\Database\Charset\encoding[EMAIL PROTECTED] * Allow whitespace-only nodes to be added as children of a DOMDocument. * When a node is cloned or imported the type information (PSVI) is also copied. * When using SAX2, including XMLReaderFactory to use createXMLReader doesn't include xercesc/parsers/SAX2XMLReaderImpl.hpp anymore. If you need to cast the SAX2XMLReader to SAX2XMLReaderImpl, you need to include this header yourself. xerces-c 2.7.0 (September 01, 2005) === * Feature to not generate XML Schema annotations. That is, not to add them to the grammar. If you don't need annotations you may want to turn on this feature to avoid memory bloat for XML Schemas that use annotations heavily. * Option to skip regenerating the XML Schema annotations when deserializing a grammar. If you don't need annotations you may want to turn on this option to avoid memory bloat for XML Schemas that use annotations heavily. * Feature to not perform default entity resolution. When the entityResolver returns NULL, the parser does not try to resolve the entity externally. * Feature to do schema-only validation even if there is a DTD. xerces-c 2.6.0 (October 02, 2004) = * Reduce footprint of DLL by building the deprecated DOM as a separate library * Various enhancements to the schema component model API * Improve support for schema annotations, including an option to laxly validate their contents * Bring parser up to the XML 1.0 3rd Edition * Update to the XML 1.1 recommendation * Update Schema Errata * Feature for disabling schema identity constraints * Upgrade to ICU3.0 * Enable the parser to handle elements with a very large number of attributes -- Chuck To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
Yaakov (Cygwin Ports) wrote: I'm not sure what's triggering this, but *sometimes* I'm getting more than that: ./.libs/lt-foo.c:263: warning: string length `4368' is greater than the length `4095' ISO C99 compilers are required to support ./.libs/lt-foo.c: In function `main': ./.libs/lt-foo.c:288: warning: implicit declaration of function `_setmode' ./.libs/lt-foo.c: In function `chase_symlinks': ./.libs/lt-foo.c:577: warning: implicit declaration of function `realpath' ./.libs/lt-foo.c:577: warning: assignment makes pointer from integer without a cast What's puzzling is there is no *error* message from the compiler -- just warnings. strip: './foo.exe': No such file But obviously something went wrong. I wonder of the string length warning is from the pre-processor, and then the compiler itself dies (dumps core?) without issuing an error message. Does the problem -- missing wrappers -- *always* occur paired with the string length warning? I can easily see the following; (1) the size of the wrapper script is very close to 4K (2) there are several embedded paths (3) sometimes, those paths are long enough to push the total script length over 4K -- and gcc-3.4.x is rude enough to fail silently. If so, I could easily split the the script generation into two separate strings... -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
I am not in office
Ich werde ab 24.04.2008 nicht im Büro sein. Ich kehre zurück am 25.04.2008. I am not in office on April, 24th. I will be back on April, 25th. As for ATIC92-94, OVP3 and SPS4 please contact Mr. Hans Falter. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: git-1.5.5.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A new release of git, 1.5.5.1-1, has been uploaded, replacing 1.5.5-1 as current, and leaving 1.5.4-1 as the previous version. NEWS: = This is a new upstream release. See also the package documentation in /usr/share/doc/git-1.5.5.1/, along with the attached upstream release notes. When compiled out of the box, the upstream git maintainers cater to older cygwin releases, and intentionally disable certain features that have been reported on their mailing list, even though they work with the latest cygwin. Therefore, this build turns those features back on. However, it means that this version does assume that you are not using FAT or FAT32 to hold your repositories, since they do not store file permissions very accurately. DESCRIPTION: Git is popular version control system designed to handle very large projects with speed and efficiency; it is used mainly for various open source projects, most notably the Linux kernel. Git falls in the category of distributed source code management tools, similar to e.g. GNU Arch or Monotone (or BitKeeper in the proprietary world). Every Git working directory is a full-fledged repository with full revision tracking capabilities, not dependent on network access or a central server. UPDATE: === To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'git' from the 'Devel' category. DOWNLOAD: = Note that downloads from sources.redhat.com (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. - -- Eric Blake volunteer cygwin git maintainer 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: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgQAb8ACgkQ84KuGfSFAYCjhQCgrUgcK5BLG6MYFgL+lcaK5/t5 3AAAniDsIQ2C8qJV0pDJdppBdtmV+sy8 =LW17 -END PGP SIGNATURE- GIT v1.5.5.1 Release Notes == Fixes since v1.5.5 -- * git archive --prefix=$path/ mishandled gitattributes. * git fetch -v that fetches into FETCH_HEAD did not report the summary the same way as done for updating the tracking refs. * git svn misbehaved when the configuration file customized the git log output format using format.pretty. * git submodule status leaked an unnecessary error message. * git log --date-order --topo-order did not override the earlier date-order with topo-order as expected. * git bisect good $this did not check the validity of the revision given properly. * url.there.insteadOf did not work correctly. * git clean ran inside subdirectory behaved as if the directory was explicitly specified for removal by the end user from the top level. * git bisect from a detached head leaked an unnecessary error message. * git bisect good $a $b when $a is Ok but $b is bogus should have atomically failed before marking $a as good. * git fmt-merge-msg did not clean up leading empty lines from commit log messages like git log family does. * git am recorded a commit with empty Subject: line without complaining. * when given a commit log message whose first paragraph consists of multiple lines, git rebase squashed it into a single line. * git remote add $bogus_name $url did not complain properly. Also comes with various documentation updates. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | What's puzzling is there is no *error* message from the compiler -- just | warnings. | | strip: './foo.exe': No such file | | But obviously something went wrong. | | I wonder of the string length warning is from the pre-processor, and | then the compiler itself dies (dumps core?) without issuing an error | message. | | Does the problem -- missing wrappers -- *always* occur paired with the | string length warning? I can easily see the following; | (1) the size of the wrapper script is very close to 4K | (2) there are several embedded paths | (3) sometimes, those paths are long enough to push the total script | length over 4K -- and gcc-3.4.x is rude enough to fail silently. | If so, I could easily split the the script generation into two separate | strings... OK, I figured it out: libtool-2.2 adds CFLAGS to LTCFLAGS, which it uses to compile the lt-foo.c files. Many configure scripts add to CFLAGS, but usually after all the standard initializations. With 1.5, or with 2.2 and LT_OUTPUT, libtool would be generated before CFLAGS is altered beyond the default (-O2 -pipe with cygport). But with 2.2 without LT_OUTPUT, the package CFLAGS are added to LTCFLAGS, sometimes with disastrous consequences. The broken case was being compiled with the following CFLAGS: CFLAGS = ... -Wall -Werror -pedantic -std=c99 -D_POSIX_C_SOURCE=200112L * -Wall produces the _setmode warning; * -std=c99 produces the realpath and ptr2int warnings; * -pedantic produces the string length warning; * -Werror makes sure that the build fails, but libtool doesn't catch it. This is definitely a regression from 1.5, the problems being: * libtool should generate lt-foo.c files without warnings, or at least compile it with sane CFLAGS that work no matter what. * libtool should catch if the lt-foo.c compile fails; I think I have also found a separate case of breakage when the CXX tag is enabled, in which case LTCC is mysteriously undefined. The results: ./libtool: line 7737: -O2: command not found strip: './foo.exe': No such file ./libtool: line 7748: $func_ltwrapper_scriptname_result: ambiguous redirect Hopefully this gives you enough to figure out where these bugs really are. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgQEz4ACgkQpiWmPGlmQSMlCACcCUE3QzUDDTl1cgpeRQOIPhMf N4gAoNCWgSfvzFeCu7YqtqqYJROcy46L =cdxV -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Updated: {xerces-c/libxerces-c-devel/xerces-c-doc}-2.8.0-1 New: {libxerces-c28/xerces-c-test}-2.8.0-1
I've adopted the xerces-c package and updated the version to 2.8.0-1. xerces-c is a validating XML parser written in a portable subset of C++ (it is also known as Xerces-C++). xerces-c makes it easy to give your application the ability to read and write XML data. A shared library is provided for parsing, generating, manipulating, and validating XML documents. Changes since 2.5.0-1 == * new maintainer * switched to cygport build framework * renamed xerces-c-devel -- libxerces-c-devel * new xerces-c-test package provides test and utility programs * updated to latest upstream release The changes in the various official release since the last cygwin release are summarized below. xerces-c 2.8.0 (August 31, 2007) * Exponential growth of memory block (from 16KB to 128KB) that are allocated by the DOM heap. * The NODE_CLONED notification is now sent to each node's user data handler when cloning the entire DOMDocument. * On Windows extract the registry code page from MIME\Database\Charset\encoding[EMAIL PROTECTED] instead of MIME\Database\Charset\encoding[EMAIL PROTECTED] * Allow whitespace-only nodes to be added as children of a DOMDocument. * When a node is cloned or imported the type information (PSVI) is also copied. * When using SAX2, including XMLReaderFactory to use createXMLReader doesn't include xercesc/parsers/SAX2XMLReaderImpl.hpp anymore. If you need to cast the SAX2XMLReader to SAX2XMLReaderImpl, you need to include this header yourself. xerces-c 2.7.0 (September 01, 2005) === * Feature to not generate XML Schema annotations. That is, not to add them to the grammar. If you don't need annotations you may want to turn on this feature to avoid memory bloat for XML Schemas that use annotations heavily. * Option to skip regenerating the XML Schema annotations when deserializing a grammar. If you don't need annotations you may want to turn on this option to avoid memory bloat for XML Schemas that use annotations heavily. * Feature to not perform default entity resolution. When the entityResolver returns NULL, the parser does not try to resolve the entity externally. * Feature to do schema-only validation even if there is a DTD. xerces-c 2.6.0 (October 02, 2004) = * Reduce footprint of DLL by building the deprecated DOM as a separate library * Various enhancements to the schema component model API * Improve support for schema annotations, including an option to laxly validate their contents * Bring parser up to the XML 1.0 3rd Edition * Update to the XML 1.1 recommendation * Update Schema Errata * Feature for disabling schema identity constraints * Upgrade to ICU3.0 * Enable the parser to handle elements with a very large number of attributes -- Chuck To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Updated: git-1.5.5.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A new release of git, 1.5.5.1-1, has been uploaded, replacing 1.5.5-1 as current, and leaving 1.5.4-1 as the previous version. NEWS: = This is a new upstream release. See also the package documentation in /usr/share/doc/git-1.5.5.1/, along with the attached upstream release notes. When compiled out of the box, the upstream git maintainers cater to older cygwin releases, and intentionally disable certain features that have been reported on their mailing list, even though they work with the latest cygwin. Therefore, this build turns those features back on. However, it means that this version does assume that you are not using FAT or FAT32 to hold your repositories, since they do not store file permissions very accurately. DESCRIPTION: Git is popular version control system designed to handle very large projects with speed and efficiency; it is used mainly for various open source projects, most notably the Linux kernel. Git falls in the category of distributed source code management tools, similar to e.g. GNU Arch or Monotone (or BitKeeper in the proprietary world). Every Git working directory is a full-fledged repository with full revision tracking capabilities, not dependent on network access or a central server. UPDATE: === To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'git' from the 'Devel' category. DOWNLOAD: = Note that downloads from sources.redhat.com (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. - -- Eric Blake volunteer cygwin git maintainer 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: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgQAb8ACgkQ84KuGfSFAYCjhQCgrUgcK5BLG6MYFgL+lcaK5/t5 3AAAniDsIQ2C8qJV0pDJdppBdtmV+sy8 =LW17 -END PGP SIGNATURE- GIT v1.5.5.1 Release Notes == Fixes since v1.5.5 -- * git archive --prefix=$path/ mishandled gitattributes. * git fetch -v that fetches into FETCH_HEAD did not report the summary the same way as done for updating the tracking refs. * git svn misbehaved when the configuration file customized the git log output format using format.pretty. * git submodule status leaked an unnecessary error message. * git log --date-order --topo-order did not override the earlier date-order with topo-order as expected. * git bisect good $this did not check the validity of the revision given properly. * url.there.insteadOf did not work correctly. * git clean ran inside subdirectory behaved as if the directory was explicitly specified for removal by the end user from the top level. * git bisect from a detached head leaked an unnecessary error message. * git bisect good $a $b when $a is Ok but $b is bogus should have atomically failed before marking $a as good. * git fmt-merge-msg did not clean up leading empty lines from commit log messages like git log family does. * git am recorded a commit with empty Subject: line without complaining. * when given a commit log message whose first paragraph consists of multiple lines, git rebase squashed it into a single line. * git remote add $bogus_name $url did not complain properly. Also comes with various documentation updates.
