Re: FW: RE: Cut and Paste between X and WindowsXP sometimes fails
On 13/02/2012 23:05, Bennett, Tony wrote: On 03/02/2012 22:55, Bennett, Tony wrote: Often when cutting from Xwin and attempting to Paste to a WindowsXP application, the most recent cut is not pasted... but instead a previous Xwin cut. In other words, this scenario: LOCATIONACTComment XwinCut abc WinXP Pastecorrectly pastes abc XwinCut def WinXP PasteIncorrectly pastes abc When the above problem occurs, no matter how many times a cut from Xwin, Whenever I paste on WinXP it pastes abc. I can correct the problem by cutting from WinXP and pasting into Xwin... ...after doing this the next Xwin cut will correctly paste on WinXP. Yes, this is a rather long-standing problem (see the bug report at [1] for some of the technical details), which is unfortunately not easy to fix in a way that works well for all cases. Fortunately, there is a simple workaround for the moment: If you install and run xclipboard, that will cause XWin to notice every change of the clipboard contents. Thanks for the reply, Jon. Exactly how do I use xclipboard...??? Here's how I'm starting Xwin right now in a Windows Script called startx.bat: @echo off C: chdir C:\cygwin\bin bash -c PATH=$PATH:/bin:/usr/bin;XWin -clipboard -logverbose 3 -ac -query cdcxvd0559.con-way.com -fp \tcp/cdcxvd0559.con-way.com:8000,/usr/share/fonts/100dpi/,/usr/share/fonts/75dpi/,/usr/share/fonts/Type1/\ You'll notice I use XDMCP to establish a CDE session on cdcxvd0559... I've tried starting xclipboard in the same script, after starting Xwin (and sometimes even specifying -noclipboard)... and I always get an IO error and X-win dies. Ah. Applying this workaround is perhaps not so simple when using XDMCP :-( You can't just add a 'xclipboard' line after 'XWin ', because the X server may still be starting up when xclipboard tries to start, which will fail. However, this shouldn't lead to the X server itself dying. It's possible to put a wait here, but there are a couple of other reasons why this approach won't work well. You might find it easier to start xclipboard on the host you are XDMCPing to, possibly as part of your login script there -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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/
RE: FW: RE: Cut and Paste between X and WindowsXP sometimes fails
On 13/02/2012 23:05, Bennett, Tony wrote: On 03/02/2012 22:55, Bennett, Tony wrote: Often when cutting from Xwin and attempting to Paste to a WindowsXP application, the most recent cut is not pasted... but instead a previous Xwin cut. In other words, this scenario: LOCATIONACTComment XwinCut abc WinXP Paste correctly pastes abc Xwin Cut def WinXP Paste Incorrectly pastes abc When the above problem occurs, no matter how many times a cut from Xwin, Whenever I paste on WinXP it pastes abc. I can correct the problem by cutting from WinXP and pasting into Xwin... ...after doing this the next Xwin cut will correctly paste on WinXP. Yes, this is a rather long-standing problem (see the bug report at [1] for some of the technical details), which is unfortunately not easy to fix in a way that works well for all cases. Fortunately, there is a simple workaround for the moment: If you install and run xclipboard, that will cause XWin to notice every change of the clipboard contents. Thanks for the reply, Jon. Exactly how do I use xclipboard...??? Here's how I'm starting Xwin right now in a Windows Script called startx.bat: @echo off C: chdir C:\cygwin\bin bash -c PATH=$PATH:/bin:/usr/bin;XWin -clipboard -logverbose 3 -ac -query cdcxvd0559.con-way.com -fp \tcp/cdcxvd0559.con-way.com:8000,/usr/share/fonts/100dpi/,/usr/share/fonts/75dpi/,/usr/share/fonts/Type1/\ You'll notice I use XDMCP to establish a CDE session on cdcxvd0559... I've tried starting xclipboard in the same script, after starting Xwin (and sometimes even specifying -noclipboard)... and I always get an IO error and X-win dies. Ah. Applying this workaround is perhaps not so simple when using XDMCP :-( You can't just add a 'xclipboard' line after 'XWin ', because the X server may still be starting up when xclipboard tries to start, which will fail. However, this shouldn't lead to the X server itself dying. It's possible to put a wait here, but there are a couple of other reasons why this approach won't work well. You might find it easier to start xclipboard on the host you are XDMCPing to, possibly as part of your login script there Jon, Given that I'd have to build xclipboard for the host that I'm XDMCPing to, and that host is running AIX... Sadly, I may just have to live with the problem. Is there any hope that the issue will be corrected in the foreseeable future...??? -tony -- 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 flock.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2012-02-15 14:43:08 Modified files: winsup/cygwin : ChangeLog flock.cc Log message: * flock.cc (lf_setlock): Add timeout variable and set before calling WFMO. Drop debug output if process is not available. Set timeout to 0 instead. Document timeout 0 in WFMO comment. (lf_getblock): Drop invalid F_POSIX lock type shortcut. Only return overlap if event is not signalled. Fix comment. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5707r2=1.5708 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/flock.cc.diff?cvsroot=srcr1=1.41r2=1.42
src/winsup/cygwin ChangeLog dtable.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2012-02-15 16:11:37 Modified files: winsup/cygwin : ChangeLog dtable.cc Log message: * dtable.cc (dtable::init_std_file_from_handle): Use tmp_pathbuf for name. (handle_to_fn): Ditto for device. Fix size in QueryDosDeviceW call. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5709r2=1.5710 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dtable.cc.diff?cvsroot=srcr1=1.249r2=1.250
src/winsup/cygwin ChangeLog miscfuncs.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2012-02-15 21:34:06 Modified files: winsup/cygwin : ChangeLog miscfuncs.cc Log message: * miscfuncs.cc: Revert change from 2012-02-13 which used the Windows-provided stack rather than an own stack created in CygwinCreateThread. (struct thread_wrapper_arg): Rename commitsize to stacklimit. (CygwinCreateThread): Rename commitsize to real_stacklimit. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5710r2=1.5711 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/miscfuncs.cc.diff?cvsroot=srcr1=1.80r2=1.81
Re: sed strips CRs
On Feb 15 01:13, Andrey Repin wrote: Greetings, Earnie Boyd! The standard response to issues dealing with CRLF files is to point the user to dos2unix and text mode mounts. This should be adequate without the hidden behavior of sed/grep/awk and probably others. While your reasoning is sound, I prefer them to behave the way they are for my own goals. I can't possible alter between text and binary mounts, or use d2u on and off in an attempt to produce consistent and predictable end results. Consistent behavior is what I see as the issue. IMO, sed, grep and awk should behave the same as on UNIX for consistent and predictable behavior. Treating CR as white space not only helps the Windows user it also helps the Unix user when Windows files are transferred to it. I know that for sed at least treating CR as white space works very well. Most apparent: it breaking EOL matches. This is about the script, not the input file. From my POV both works fine here, either just ignoring the CR, or using rt mode. 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: File operations really slow in emacs
On Feb 14 14:50, Ryan Johnson wrote: On 14/02/2012 12:57 PM, Corinna Vinschen wrote: On Feb 14 12:46, Ryan Johnson wrote: On 14/02/2012 11:26 AM, Corinna Vinschen wrote: On Feb 14 10:47, Ryan Johnson wrote: On 14/02/2012 10:17 AM, Corinna Vinschen wrote: Does anybody know a system call which allows to fetch the network drive state (connected/not connected) without a billion microsecond timeout? [...] What if we parsed the mount table instead of calling readdir? I don't know how that's computed, but it's never been a performance problem, it only shows drives that are actually connected [...] What mount table? Cygwin's? It calls GetFileAttributes on the drive's root dir as well... This is bizarre... what would cause calls to the same Windows API function behave so differently when called by stat vs ls vs bash-autocomplete? I'm happy to accept that there's some weirdness on my box, but I would have expected that weirdness to be consistent at any given instant in time (either all go slow or all behave normally). SMB just is not consistent. More often than not the timing behaviour is just plain puzzeling. And, btw., in *my* testing I got hangs in mount as well if I disabled the remote share. But only once. Subsequent calls were fast. And after enabling the remote share, mount happily ignored that fact for about a minute or so. Caching, anybody? Heisenburg? Impossible to know both what SMB share a mount points to and whether it's currently connected? It's really unfortunate Windows doesn't have a GetLocalDrives() or GetAccessibleDriveLetters() function. Actually, isn't there a function to convert DOS paths to those funky //?/ paths? Maybe that \\?\ is nothing but a Win32 path prefix which tells the kernel32 routines to omit the step to convert to native NT paths. The problem is that the conversion buffers have a fixed size of MAX_PATH characters, so Win32 paths without the prefix are restricted to 259 chars. So in fact, there's no difference between the paths other than to omit a conversion step. Apart from that the paths are equivalent: standard Win32C:\dir\file\\server\share\file long-path Win32 \\?\C:\dir\file\\?\UNC\server\share\file native NT \??\C:\dir\file\??\UNC\server\share\file would be both fast and give enough information to keep stat() happy; Not at all. It's all the same file and the underlying NT functions will do the same in all cases. But I already changed cygdrive::fstat yesterday to set st_nlinks to 1 without calling GetFileAttributes in a loop. 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: File operations really slow in emacs
On Feb 15 04:35, Mark Geisert wrote: Corinna Vinschen writes: Does anybody know a system call which allows to fetch the network drive state (connected/not connected) without a billion microsecond timeout? I just looked into this and I really don't see a way. While there's a NetUseGetInfo call, which is pretty fast even for unavailable drives, it's not reliable. Even if the drive is available again, it can take minutes in which it still returns a status of Session lost. I'm not sure this is what we want. ...and the call doesn't work for NFS drives. Too bad. Does WNetGetConnection() do any better? It's referenced on the NetUseGetInfo() page in MSDN. Claims to support other providers besides SMB. Yes, that's right. Alas, BTDT. The function returns success even if the share becomes unavailable. Apart from that, is net use the mount table Ryan was referring to? Can we tell what it's doing to identify connected and disconnected drives? Given it's import table it uses all functions available. I see at least these: NetUseEnum NetUseGetInfo WNetCloseEnum WNetEnumResourceW WNetOpenEnumW WNetGetConnectionW WNetGetLastErrorW WNetCancelConnection2W WNetAddConnection2W But net use is not quite accurate either. If you switch off a remote share it recognizes the disconmnection pretty fast, but if the share becomes available again, it stays in the disconnected state for quite some time, just like the NetUseGetInfo function. But, on second thought, maybe that's ok for us. It would at least help for SMB drives. I'll look into that again at one point. 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: PROGRAMFILES variable is not set during openssh session
On Feb 15 01:20, Andrey Repin wrote: Greetings, Corinna Vinschen! PROGRAMFILES variable is not set during openssh session. This is very important for remote administrative tasks. OpenSSH 6.0p1 is due soon. I asked to apply a patch upstream so that PROGRAMFILES is added back to the environment variables passed over to the child process. Both of them? (on x86_64 systems, there's two relevant variables) Argh. Can of worms. No, only the 32 bit variant for now. Oh, btw., 32 bit processes only see the 32 bit PROGRAMFILES variable by default. Which makes sense since PROGRAMFILES for 32 bit processes is the same as PROGRAMFILES for 64 bit processes... I can't say that I understood your reply, I'll just go into hiding thinking that you know what you doing . A dangerous assumption... ;) I think my reply was a bit on the strange side. Let's use the source instead. If you start a 32 bit CMD on an English system you get this: ProgramFiles=C:\Program Files (x86) ProgramFiles(x86)=C:\Program Files (x86) In the 64 bit CMD you get this: ProgramFiles=C:\Program Files ProgramFiles(x86)=C:\Program Files (x86) So for a 32 bit process, the values of ProgramFiles and ProgramFiles(x86) are identical. 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: OpenSSH *** fatal error - unable to load C:\WINDOWS\system32\user32.dll, Win32 error 1114
On Feb 14 20:49, Stepp, Charles wrote: On Feb 14 17:54, Charles Stepp wrote: Does the FAQ help? http://cygwin.com/faq-nochunks.html#faq.using.sshd-in-domain Yes it did! Essentially, it needs to be a domain user. I had to use my own domain ID. I added permissions through some hairy Windoze as recommended in the following link. http://ist.uwaterloo.ca/~kscully/CygwinSSHD_W2K3.html I just hope you didn't follow the WRONG advice to set CYGWIN=binmode ntsec tty or ntsec tty. None of that makes any sense in Cygwin 1.7. Thanks SO much! It must be a real PIA trying to emulate setuid stuff/ID switching stuff for these Server class Windoze versions. Indeed. 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: need help with perl script and rsync
Greetings, i...@kalani.com! We use ActiveState perl in a backup processes at my work. A programmer created a perl script to create an incremental backup using rsync. The script does not do the incremental backup, just a full backup. It worked in winxp, but now that we are using it on win7 its not incrementing. I cannot get in contact with the programmer. Is there someone here that can look at the script and find out what the issue is? ActiveState Perl is not relevant to Cygwin in any way, but... I recall a discussion along the same lines of issue, that could be helpful for you. Try searching the list archive. -- WBR, Andrey Repin (anrdae...@freemail.ru) 15.02.2012, 14:37 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
Recent Cygwin/Tk move to Cygwin/X (was Re: Problems with tkinter after python upgrade on cygwin)
I wonder if you could share with us the reason for making this move, which seems pretty disruptive. It significantly increases the overhead in using Cygwin to deliver Tk-based applications, and will require many users to come to grips with Cygwin/X installation and maintenance. I've been very happy with the performance of GDI-based Tk for over 10 years, but now I'm stuck with having to choose between using a non-updating version of Tcl/Tk, or installing Cygwin/X, neither of which is a very attractive proposition. . . ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -- 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: Problems with tkinter after python upgrade on cygwin
On 15 February 2012 at 02:25, Jason Tishler wrote: On Mon, Feb 13, 2012 at 05:23:37PM +0100, Hans Peter Jepsen wrote: I googled for an answer, but did not find any. What about the following Google search on TclError: no display name and no $DISPLAY environment variable? http://www.google.com/search?q=TclError%3A+no+display+name+and+no+%24DI SPLAY+environment+variable The first item from the above search yields: http://www.linuxquestions.org/questions/programming-9/tcl-error-no- display-name-and-no-display-environment-variable-340184/ Having had the same trouble myself with gitk, I don't think the help on those links is particularly useful. The two pieces of advice there (and on most similar posts Google threw at me) are to set $DISPLAY to ':0' or similar (which doesn't help at all without an X server), or saying that one needs to use X. Having never required X previously, and having assumed the Cygwin installer would have told me if packages I was using required X11, I assumed that was a different problem; one specific to full Linux systems. I knew gitk on Cygwin could just work and create windows without needing X11, because that's how it had always worked since I started using it. Eventually I found http://cygwin.com/ml/cygwin/2012-02/msg00115.html, and realized I did now need to use X11. However, I suspect most people aren't going to subscribe to the Cygwin mailing lists, and are going to hit exactly the same problems. Where they, as I did, will spend quite a bit of time trying to work out why things that always used to work are suddenly pumping out errors about this X11 thing they've never used previously and have no desire to use. -- Adam Dinwoodie Software Engineer, Carrier Systems Division Metaswitch Networks -- 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: Problems with tkinter after python upgrade on cygwin
On 2/15/2012 1:27 PM, Adam Dinwoodie wrote: On 15 February 2012 at 02:25, Jason Tishler wrote: On Mon, Feb 13, 2012 at 05:23:37PM +0100, Hans Peter Jepsen wrote: I googled for an answer, but did not find any. google is usually fine, but a look at cygwin mailing list archive is likely more effective and focused. At least a look at http://cygwin.com/ml/cygwin-announce/ archive should be given. Having never required X previously, and having assumed the Cygwin installer would have told me if packages I was using required X11, I assumed that was a different problem; one specific to full Linux systems. I knew gitk on Cygwin could just work and create windows without needing X11, because that's how it had always worked since I started using it. Eventually I found http://cygwin.com/ml/cygwin/2012-02/msg00115.html, and realized I did now need to use X11. However, I suspect most people aren't going to subscribe to the Cygwin mailing lists, and are going to hit exactly the same problems. Where they, as I did, will spend quite a bit of time trying to work out why things that always used to work are suddenly pumping out errors about this X11 thing they've never used previously and have no desire to use. In reality installation of new tcl-tk requires a certain bunch of X, and setup takes care of that, see extract of setup.ini - @ tcl-tk sdesc: Tcl X11 toolkit ldesc: An X11 toolkit implemented with the Tcl scripting language. category: Interpreters Tcl X11 requires: libfontconfig1 libX11_6 libXft2 libXss1 tcl cygwin version: 8.5.11-1 -- It is clear to all that this change broke with the past usage, but due to the lack of support for the old tk gdi interface only 2 options were available: - do nothing and staying with tcl-8.4 forever without any evolution - move to X11 as any other Unix and follow the tcl-8.5 and following evolution The first solution was in place for long time and we already saw serious problem in upgrading any package requiring a recent tcl-tk. So it was a common decision of the package maintainer community to drink the bitter cup of breaking with the past and taking the second road. Regards 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
base-files 4.0-9: LANG is set to the system default, why not the user selection?
Hi!
My Windows is Swedish, but I generally like it to show as little as
possible in Swedish so my display language is English. I want
English, to not suffer from strange translations that don't make
sense, to be able to search for error messages, etc.
A recent change seems to have LANG set to the output of the system
default language, but I think that's just wrong, it should be the
language of the current user.
Please change lang.{c}sh to do locale -uU instead of locale -sU.
Where is the recommended position to override LANG until such a
change is made, or if it is not an agreeable change?
Cheers,
Peter
--
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: base-files 4.0-9: LANG is set to the system default, why not the user selection?
On 15 February 2012 13:59, Peter Rosin wrote:
My Windows is Swedish, but I generally like it to show as little as
possible in Swedish so my display language is English. I want
English, to not suffer from strange translations that don't make
sense, to be able to search for error messages, etc.
A recent change seems to have LANG set to the output of the system
default language, but I think that's just wrong, it should be the
language of the current user.
Please change lang.{c}sh to do locale -uU instead of locale -sU.
I agree.
Where is the recommended position to override LANG until such a
change is made, or if it is not an agreeable change?
If you're using the default terminal, i.e. mintty, you can set it on
the Text page of its options.
Andy
--
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: {db4.5/libdb4.5/libdb4.5-devel/tcl-db4.5}-4.5.20.2-3: Oracle Berkeley DB - db4.5
Hi New versions of 'db4.5/libdb4.5/libdb4.5-devel/tcl-db4.5' have been uploaded to a server near you. o Build for cygwin 1.7.9 with gcc-4.5.3 o tcl-db4.5 linked against the Unix version of tcl CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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. -- 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: WordNet-3.0-2: A lexical database for the English language
Hi A new version of 'WordNet' has been uploaded to a server near you. o Build for cygwin 1.7.9 with gcc-4.5.3 o Uses now the X11 version of Tcl/Tk o Security fixes for CVE-2008-2149 and CVE-2008-3908 o Applied a couple of patches from Debian CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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. -- 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: rxvt broken in recent snapshots (since cygwin 1.7.10(0.259/5/3))
On 2/14/2012 10:41 PM, Hans Horn wrote: On 2/14/2012 5:39 PM, Christopher Faylor wrote: On Tue, Feb 14, 2012 at 06:02:51PM -0500, Charles Wilson wrote: On 2/14/2012 6:00 PM, Charles Wilson wrote: On 2/14/2012 1:05 PM, Hans Horn wrote: something in the recent post-1.7.10(0.259/5/3) cygwin snapshots (20120207..20120214) broke rxvt. I'll need a few more details than it broke rxvt. vis. cgf's reply, never mind... If the breakage wasn't so obvious, I would have had the same response. But, really, there is no reason to assume that something is so obvious as to not provide details. *Please* when reporting a problem explain what the problem actually is. cgf I typically do. In this case: rxvt starts (I see window opening) and then disappears quickly, in other words, it is broken. H. snapshot 20120215 has put rxvt back on the map. thx Chris. H. -- 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: STC for libapr1 failure
On Feb 14 13:43, David Rothenberger wrote: On 2/14/2012 10:24 AM, Corinna Vinschen wrote: On Feb 14 09:58, David Rothenberger wrote: On 2/14/2012 6:45 AM, Corinna Vinschen wrote: On Feb 14 15:02, Corinna Vinschen wrote: On Feb 14 00:00, David Rothenberger wrote: The libapr1 test cases are failing again for flock locks. This same test case failed with 1.7.9 with a fatal error[1], but that was corrected. The test is no longer encountering the fatal error, but it is producing the wrong result. Thanks for the testcase. I think I found the issue. An event handle was closed in the wrong place, outside of the important mutex lock for the lock object. I applied the patch to CVS. Your testcase now appears to run fine for me. Can you try your entire testsuite again and see if there's another failure lurking? I uploaded a snapshot for testing. Thanks. The snapshot fixes the flock test case, but now the fcntl test case is failing. *Sob*. How so? Does it hang or does it allow multiple concurrent exclusive locks as the flock case? Sorry, I should have said. It hangs. I'll try to send an STC for that case, but I suspect the one from last year will have the problem. Please send it anyway. It's attached. If you run it with an argument (any argument), each child will print its loop count and you can see what happens. If it doesn't hang for you, try increasing MAX_ITER or CHILDREN at the top. Did I mention that I hate synchronization problems? Anyway, I think I found the problem. I applied a patch which fixes the problem for me and, surprise!, the flock test still runs fine, too. I've just uploaded a new snapshot. Please give it a try. Thanks, 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: Problems with tkinter after python upgrade on cygwin
On Wed, Feb 15, 2012 at 02:19:12PM +0100, marco atzeri wrote: On 2/15/2012 1:27 PM, Adam Dinwoodie wrote: On 15 February 2012 at 02:25, Jason Tishler wrote: On Mon, Feb 13, 2012 at 05:23:37PM +0100, Hans Peter Jepsen wrote: I googled for an answer, but did not find any. google is usually fine, but a look at cygwin mailing list archive is likely more effective and focused. At least a look at http://cygwin.com/ml/cygwin-announce/ archive should be given. Having never required X previously, and having assumed the Cygwin installer would have told me if packages I was using required X11, I assumed that was a different problem; one specific to full Linux systems. I knew gitk on Cygwin could just work and create windows without needing X11, because that's how it had always worked since I started using it. Eventually I found http://cygwin.com/ml/cygwin/2012-02/msg00115.html, and realized I did now need to use X11. However, I suspect most people aren't going to subscribe to the Cygwin mailing lists, and are going to hit exactly the same problems. Where they, as I did, will spend quite a bit of time trying to work out why things that always used to work are suddenly pumping out errors about this X11 thing they've never used previously and have no desire to use. In reality installation of new tcl-tk requires a certain bunch of X, and setup takes care of that, see extract of setup.ini - @ tcl-tk sdesc: Tcl X11 toolkit ldesc: An X11 toolkit implemented with the Tcl scripting language. category: Interpreters Tcl X11 requires: libfontconfig1 libX11_6 libXft2 libXss1 tcl cygwin version: 8.5.11-1 -- It is clear to all that this change broke with the past usage, but due to the lack of support for the old tk gdi interface only 2 options were available: - do nothing and staying with tcl-8.4 forever without any evolution And, also, the tcl/tk which was previously released were basically Windows versions of those packages which had problems with Cygwin path names, signal handling, and other stuff. This represented a bunch of bugs that are now magically fixed by the release of a modern tcl/tk built for Cygwin without any Windows hacks. (And they were hacks) cgf -- 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: OpenSSH *** fatal error - unable to load C:\WINDOWS\system32\user32.dll, Win32 error 1114
On Wed, Feb 15, 2012 at 10:44:48AM +0100, Corinna Vinschen wrote: On Feb 14 20:49, Stepp, Charles wrote: On Feb 14 17:54, Charles Stepp wrote: Does the FAQ help? http://cygwin.com/faq-nochunks.html#faq.using.sshd-in-domain Yes it did! Essentially, it needs to be a domain user. I had to use my own domain ID. I added permissions through some hairy Windoze as recommended in the following link. http://ist.uwaterloo.ca/~kscully/CygwinSSHD_W2K3.html I just hope you didn't follow the WRONG advice to set CYGWIN=binmode ntsec tty or ntsec tty. None of that makes any sense in Cygwin 1.7. ...and setting CYGWIN to tty for a service was really nonsensical for any release. I'm very glad that setting is gone. cgf -- 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
File permissions problems with cp in Windows 7
I'm hoping you can help me understand a problem that's been plaguing me for some time. I'm on a recent version of Cygwin (cygcheck -V reports 1.7.9) and I'm on Windows 7. I believe I have set up my /etc/passwd and /etc/group using mkpasswd and mkgroup in the appropriate way. If it makes a difference I am logged on to my machine as a domain user. So I have a file created externally to Cygwin, just normal notepad for example. Let's say this is called hello.txt. Within Cygwin I can cat this file: tomq@spot /cygdrive/c/work/cygtest $ cat hello.txt tom tomq@spot /cygdrive/c/work/cygtest I create a subdirectory sub1: $ mkdir sub1 Then copy hello.txt into that directory: $ cp hello.txt sub1/ I can view the contents of sub1/hello.txt: $ cat sub1/hello.txt tom However, if I then create another subdirectory $ mkdir sub1/sub2 And copy into that: $ cp hello.txt sub1/sub2 I then can't cat that file: $ cat sub1/sub2/hello.txt cat: sub1/sub2/hello.txt: Permission denied Using getfacl gives me some insight, the key is in the different acls on sub1 and sub2: $ getfacl . # file: . # owner: tomq # group: Domain Users user::--- group::--- group:SYSTEM:rwx group:Administrators:rwx group:Users:r-x mask:rwx other:--- default:user::--- default:group::--- default:group:SYSTEM:rwx default:group:Administrators:rwx default:group:Users:r-x default:mask:rwx default:other:--- $ getfacl sub1/ # file: sub1/ # owner: tomq # group: Domain Users user::rwx group::r-x group:SYSTEM:rwx group:Administrators:rwx group:Users:r-x mask:rwx other:r-x default:user::rwx default:group::r-x default:group:SYSTEM:rwx default:group:Administrators:rwx default:group:Users:r-x default:mask:rwx default:other:r-x $ getfacl sub1/sub2 # file: sub1/sub2 # owner: tomq # group: Domain Users user::rwx group::r-x group:SYSTEM:rwx group:Administrators:rwx group:Users:r-x mask:rwx other:r-x default:user::rwx default:group::r-x default:other:r-x $ getfacl hello.txt # file: hello.txt # owner: tomq # group: Domain Users user::--- group::--- group:SYSTEM:rwx group:Administrators:rwx group:Users:r-x mask:rwx other:--- $ getfacl sub1/sub2/hello.txt # file: sub1/sub2/hello.txt # owner: tomq # group: Domain Users user::--- group::--- mask:rwx other:--- So on one level I understand what's going on, but my question is what do I do about this. I haven't done anything strange in my windows setup, and all my files started out with just having Windows permissions that inherited from C:\, and the fundamental issue seems to be that the basic permissions on c:\ are -: $ getfacl /cygdrive/c # file: /cygdrive/c # owner: # group: user::--- group::--- group:SYSTEM:rwx group:Administrators:rwx group:Users:r-x mask:rwx other:--- default:user::--- default:group::--- default:group:SYSTEM:rwx default:group:Administrators:rwx default:group:Users:r-x default:mask:rwx default:other:--- icacls on the directory give me: c:\work\cygtest BUILTIN\Administrators:(I)(F) BUILTIN\Administrators:(I)(OI)(CI)(IO)(F) NT AUTHORITY\SYSTEM:(I)(F) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F) BUILTIN\Users:(I)(OI)(CI)(RX) NT AUTHORITY\Authenticated Users:(I)(M) NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M) Now I can fix this by just doing a chmod -R 755 or some such, but this seems so be papering over the real issue. Do I expect the permissions on the root of my C drive to just be -? Have I set up Cygwin wrong, or rather missed a set up step? Any help would be appreciated on this. -- 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
psmisc-22.14-1: fuser command does not longer work
fuser reports missing /proc/net/unix and does not list any used files: $ cygcheck -f /bin/cygwin1.dll cygwin-1.7.10-1 $ cygcheck -f /bin/fuser psmisc-22.14-1 $ sleep 100 /tmp/foo [1] 4132 $ fuser /tmp/foo Cannot open /proc/net/unix: No such file or directory $ fuser -a /tmp/foo Cannot open /proc/net/unix: No such file or directory /tmp/foo: $ ls -l /proc/4132/fd total 0 lrwxrwxrwx 1 franke none 0 Feb 15 18:35 0 - /dev/pty1 lrwxrwxrwx 1 franke none 0 Feb 15 18:35 1 - /tmp/foo lrwxrwxrwx 1 franke none 0 Feb 15 18:35 2 - /dev/pty1 Christian -- 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
Mintty Log Off problem
With Cygwin 1.7.10(0.259/5/3) upon logging off Windows XP SP3 I get a pop-up window End Program - C:\cygwin\bin\mintty.exe with a End Now and Cancel button every time I log off Windows and I have somewhere in that Windows session run the Mintty shortcut which has C:\cygwin\bin\mintty -u - in it and my default shell is tcsh. This never happened with previous Cygwin releases. What's even more interesting is that in all cases I exit all my programs before logging off, including the mintty window. I've even tried hitting the Cancel button and then looking for a process named mintty or Terminal (since that's what mintty's description is and that is used by some process tools) with both Process Explorer and Task Manager, but I can find no such process -- and then when I try to log off again not having found such a process the pop-up comes back and I can't log off until I hit End Now. Since I haven't seen any reports of this on this list, I must be about the only one this is happening to. Any clues as to what I can do to find out what Windows is actually failing to stop when I try to log off having run mintty beforehand? -- Harry G. McGavran, Jr. E-mail: w5...@w5pny.com -- 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
porting problem triggered by gcc include search order
Hi, I'm now porting Nick Gasson's nvc[1] to cygwin 1.7. and i'm stuck a porting problem triggered by gcc include search order[2]. Should I rename local signal.h? Or, anyone can tell me better way to solve this problem? Peace, - [1] https://github.com/nickg/nvc [2] https://github.com/hiyuh/nvc/blob/port-cygwin/TODO -- 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
tirpc broken in cygwin 1.7.10
STC which worked in 1.7.9, breaks in 1.7.10: $ cat foo.c #include rpc/rpc.h $ gcc -c -I/usr/include/tirpc foo.c In file included from /usr/include/tirpc/rpc/rpc.h:38:0, from foo.c:1: /usr/include/tirpc/rpc/types.h:44:28: fatal error: rpc/types.h: No such file or directory compilation terminated. $ cygcheck -p rpc/types.h Found 5 matches for rpc/types.h cygwin/cygwin-1.7.10-1-src The UNIX emulation engine cygwin/cygwin-1.7.9-1 The UNIX emulation engine cygwin/cygwin-1.7.9-1-src The UNIX emulation engine libtirpc-devel/libtirpc-devel-0.2.1-1 A port of Sun's Transport-Independent RPC library (devel) sunrpc/sunrpc-4.0-3 Sun RPC (ONC/RPC) utilities Notice that cygwin's /usr/include/rpc/types.h disappeared between 1.7.9 and 1.7.10, meaning that the #include_next in tirpc's /usr/include/tirpc/rpc/types.h fails. I don't know whether this needs to be fixed in cygwin, in tirpc, or both. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: File permissions problems with cp in Windows 7
On 2/15/2012 12:09 PM, Tom Quarendon wrote: I'm hoping you can help me understand a problem that's been plaguing me for some time. I'm on a recent version of Cygwin (cygcheck -V reports 1.7.9) and I'm on Windows 7. I believe I have set up my /etc/passwd and /etc/group using mkpasswd and mkgroup in the appropriate way. If it makes a difference I am logged on to my machine as a domain user. So I have a file created externally to Cygwin, just normal notepad for example. Let's say this is called hello.txt. snip Now I can fix this by just doing a chmod -R 755 or some such, but this seems so be papering over the real issue. Do I expect the permissions on the root of my C drive to just be -? Have I set up Cygwin wrong, or rather missed a set up step? I can't reproduce this on 1.7.9 using a domain user following the steps you outlined above. Perhaps there's something hidden in your cygcheck output and passwd and group files that would help? The only thing that occurred to me is that my user is part of the local administrators group. I'm not sure yours is. You might investigate that. Or try with a local user (with and without admin privs). Alternatively, if you only care about Windows permissions and not POSIX ones that Cygwin prefers, you can use the noacl to tell Cygwin to not use POSIX permissions on any part of the file-system. See http://cygwin.com/cygwin-ug-net/using.html#mount-table for more details. I recommend this option only as a last resort of course. -- Larry _ 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: tirpc broken in cygwin 1.7.10
On Wed, Feb 15, 2012 at 11:19:16AM -0700, Eric Blake wrote: STC which worked in 1.7.9, breaks in 1.7.10: $ cat foo.c #include rpc/rpc.h $ gcc -c -I/usr/include/tirpc foo.c In file included from /usr/include/tirpc/rpc/rpc.h:38:0, from foo.c:1: /usr/include/tirpc/rpc/types.h:44:28: fatal error: rpc/types.h: No such file or directory compilation terminated. $ cygcheck -p rpc/types.h Found 5 matches for rpc/types.h cygwin/cygwin-1.7.10-1-src The UNIX emulation engine cygwin/cygwin-1.7.9-1 The UNIX emulation engine cygwin/cygwin-1.7.9-1-src The UNIX emulation engine libtirpc-devel/libtirpc-devel-0.2.1-1 A port of Sun's Transport-Independent RPC library (devel) sunrpc/sunrpc-4.0-3Sun RPC (ONC/RPC) utilities Notice that cygwin's /usr/include/rpc/types.h disappeared between 1.7.9 and 1.7.10, meaning that the #include_next in tirpc's /usr/include/tirpc/rpc/types.h fails. I don't know whether this needs to be fixed in cygwin, in tirpc, or both. That was caused by a newlib typo which caused the contents of /usr/include/rpc to be deleted. I've checked in a fix and generated a snapshot which now includes the missing files from that directory. Maybe we should consider a 1.7.10-2 release to fix these header file issues. cgf -- 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] New packages: {db4.8/db4.8-doc/libdb4.8/libdb4.8-devel/tcl-db4.8}-4.8.30-1: Berkeley DB version 4.8
Hi The packages db4.8/db4.8-doc/libdb4.8/libdb4.8-devel/tcl-db4.8 are now available with the Cygwin distribution: o Initial release o Build for cygwin 1.7.9 with gcc-4.5.3 o tcl-db4.8 linked against the Unix version of tcl DESCRIPTION: Oracle Berkeley DB is the industry-leading open source, embeddable database engine that provides developers with fast, reliable, local persistence with zero administration. Oracle Berkeley DB is a library that links directly into your application. Your application makes simple function calls, rather than sending messages to a remote server, eliminating the performance penalty of client-server architectures. Oracle Berkeley DB eliminates the overhead of SQL query processing, enabling applications with predictable access patterns to run faster. Enjoy Volker CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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. -- 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: psmisc-22.14-1: fuser command does not longer work
On Feb 15 18:40, Christian Franke wrote: fuser reports missing /proc/net/unix and does not list any used files: $ cygcheck -f /bin/cygwin1.dll cygwin-1.7.10-1 $ cygcheck -f /bin/fuser psmisc-22.14-1 $ sleep 100 /tmp/foo [1] 4132 $ fuser /tmp/foo Cannot open /proc/net/unix: No such file or directory $ fuser -a /tmp/foo Cannot open /proc/net/unix: No such file or directory /tmp/foo: $ ls -l /proc/4132/fd total 0 lrwxrwxrwx 1 franke none 0 Feb 15 18:35 0 - /dev/pty1 lrwxrwxrwx 1 franke none 0 Feb 15 18:35 1 - /tmp/foo lrwxrwxrwx 1 franke none 0 Feb 15 18:35 2 - /dev/pty1 Works with fuser from psmisc-21.5 so it seems to be a bug in fuser itself. I'll look into it the next couple of days (if nobody beats me to it). 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: STC for libapr1 failure
On 2/15/2012 7:38 AM, Corinna Vinschen wrote: Did I mention that I hate synchronization problems? Anyway, I think I found the problem. I applied a patch which fixes the problem for me and, surprise!, the flock test still runs fine, too. I've just uploaded a new snapshot. Please give it a try. All the procmutex tests pass now! Awesome! But... now one of the flock tests is failing. It takes a while to extract a STC from the APR test suite because everything is written in APR-ese and I have to convert every APR call into the base C library calls. I'll work on that over the next day or three. The gist of the test that's failing is this: * Create a file. * Get an exclusive flock on it. * Spawn a child process that attempts to get an exclusive, non-blocking lock on the file. The test is expecting that the child will not be able to get the lock, but the child is able to. -- David Rothenberger daver...@acm.org Hubbard's Law: Don't take life too seriously; you won't get out of it alive. -- 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
Snapshot 20120214: fork: can't reserve memory for stack
\cygwin\bin\cygsvn_client-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_client-1-0.dll v0.0 ts=2012/2/13 19:25 39k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_delta-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_delta-1-0.dll v0.0 ts=2012/2/13 19:24 57k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_diff-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_diff-1-0.dll v0.0 ts=2012/2/13 19:24 20k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_fs-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_fs-1-0.dll v0.0 ts=2012/2/13 19:24 143k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_fs_base-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_fs_base-1-0.dll v0.0 ts=2012/2/13 19:24 133k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_fs_fs-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_fs_fs-1-0.dll v0.0 ts=2012/2/13 19:24 7k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_fs_util-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_fs_util-1-0.dll v0.0 ts=2012/2/13 19:24 34k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_ra-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_ra-1-0.dll v0.0 ts=2012/2/13 19:25 23k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_ra_local-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_ra_local-1-0.dll v0.0 ts=2012/2/13 19:24 119k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_ra_neon-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_ra_neon-1-0.dll v0.0 ts=2012/2/13 19:24 131k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_ra_serf-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_ra_serf-1-0.dll v0.0 ts=2012/2/13 19:24 70k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_ra_svn-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_ra_svn-1-0.dll v0.0 ts=2012/2/13 19:24 146k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_repos-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_repos-1-0.dll v0.0 ts=2012/2/13 19:24 289k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_subr-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_subr-1-0.dll v0.0 ts=2012/2/13 19:24 470k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_wc-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_wc-1-0.dll v0.0 ts=2012/2/13 19:24 58k 2011/11/14 D:\dev_apps\cygwin\bin\cygtasn1-3.dll - os=4.0 img=1.0 sys=4.0 cygtasn1-3.dll v0.0 ts=2011/11/14 19:35 48k 2010/01/02 D:\dev_apps\cygwin\bin\cygtic-10.dll - os=4.0 img=1.0 sys=4.0 cygtic-10.dll v0.0 ts=2010/1/2 14:45 48k 2009/11/20 D:\dev_apps\cygwin\bin\cygtic-9.dll - os=4.0 img=1.0 sys=4.0 cygtic-9.dll v0.0 ts=2009/11/20 19:10 48k 2010/01/02 D:\dev_apps\cygwin\bin\cygticw-10.dll - os=4.0 img=1.0 sys=4.0 cygticw-10.dll v0.0 ts=2010/1/2 17:28 41k 2011/08/16 D:\dev_apps\cygwin\bin\cygusb0.dll - os=4.0 img=1.0 sys=4.0 cygusb0.dll v0.0 ts=2011/8/16 19:28 16k 2010/06/24 D:\dev_apps\cygwin\bin\cyguuid-1.dll - os=4.0 img=1.0 sys=4.0 cyguuid-1.dll v0.0 ts=2010/6/24 20:19 2758k 2012/02/05 D:\dev_apps\cygwin\bin\cygwin1-1.7.10.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2012/2/5 11:36 2758k 2012/02/15 D:\dev_apps\cygwin\bin\cygwin1-20120207.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2012/2/7 17:00 2757k 2012/02/15 D:\dev_apps\cygwin\bin\cygwin1-20120209.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2012/2/9 16:22 2757k 2012/02/15 D:\dev_apps\cygwin\bin\cygwin1-20120210.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2012/2/10 16:48 2747k 2012/02/15 D:\dev_apps\cygwin\bin\cygwin1-20120214.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2012/2/14 21:21 2746k 2012/02/15 D:\dev_apps\cygwin\bin\cygwin1-20120215.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2012/2/15 18:45 28k 2010/03/28 D:\dev_apps\cygwin\bin\cygwrap-0.dll - os=4.0 img=1.0 sys=4.0 cygwrap-0.dll v0.0 ts=2010/3/28 10:02 1045k 2011/08/22 D:\dev_apps\cygwin\bin\cygX11-6.dll - os=4.0 img=1.0 sys=4.0 cygX11-6.dll v0.0 ts=2011/8/22 9:25 11k 2010/08/03 D:\dev_apps\cygwin\bin\cygXau-6.dll - os=4.0 img=1.0 sys=4.0 cygXau-6.dll v0.0 ts=2010/8/3 1:32 337k 2011/02/04 D:\dev_apps\cygwin\bin\cygXaw-7.dll - os=4.0 img=1.0 sys=4.0 cygXaw-7.dll v0.0 ts=2011/2/4 7:02 75k 2010/12/21 D:\dev_apps\cygwin\bin\cygxcb-1.dll - os=4.0 img=1.0 sys=4.0 cygxcb-1.dll v0.0 ts=2010/12/21 1:36 17k 2010/10/31 D:\dev_apps\cygwin\bin\cygXdmcp-6.dll - os=4.0 img=1.0 sys=4.0 cygXdmcp-6.dll v0.0 ts=2010/10/31 20:29 52k 2011/05/23 D:\dev_apps\cygwin\bin\cygXext-6.dll - os=4.0 img=1.0 sys=4.0 cygXext-6.dll v0.0 ts=2011/5/23 9:32 66k 2010/11/01 D:\dev_apps\cygwin\bin\cygXft-2.dll - os=4.0 img=1.0 sys=4.0 cygXft-2.dll v0.0 ts=2010/11/1 2:10 119k 2010/11/01 D
Re: STC for libapr1 failure
On Feb 15 11:39, David Rothenberger wrote: On 2/15/2012 7:38 AM, Corinna Vinschen wrote: Did I mention that I hate synchronization problems? Anyway, I think I found the problem. I applied a patch which fixes the problem for me and, surprise!, the flock test still runs fine, too. I've just uploaded a new snapshot. Please give it a try. All the procmutex tests pass now! Awesome! But... now one of the flock tests is failing. It takes a while to extract a STC from the APR test suite because everything is written in APR-ese and I have to convert every APR call into the base C library calls. I'll work on that over the next day or three. The gist of the test that's failing is this: * Create a file. * Get an exclusive flock on it. * Spawn a child process that attempts to get an exclusive, non-blocking lock on the file. The test is expecting that the child will not be able to get the lock, but the child is able to. Did I really mention that I hate synchronization problems? Does it fork/exec or does it only exec? If the latter, and if the child uses the file descriptor inherited from the parent, then it's ok that it gets the lock, afaics. From the Linux man page: Locks created by flock() are associated with an open file table entry. This means that duplicate file descriptors (created by, for example, fork(2) or dup(2)) refer to the same lock, and this lock may be modi‐ fied or released using any of these descriptors. Furthermore, the lock is released either by an explicit LOCK_UN operation on any of these duplicate descriptors, or when all such descriptors have been closed. [...] Locks created by flock() are preserved across an execve(2) But maybe I misunderstood something when implementig this? I guess I really need the testcase. 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: Snapshot 20120214: fork: can't reserve memory for stack
=2012/2/13 19:25 39k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_delta-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_delta-1-0.dll v0.0 ts=2012/2/13 19:24 57k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_diff-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_diff-1-0.dll v0.0 ts=2012/2/13 19:24 20k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_fs-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_fs-1-0.dll v0.0 ts=2012/2/13 19:24 143k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_fs_base-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_fs_base-1-0.dll v0.0 ts=2012/2/13 19:24 133k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_fs_fs-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_fs_fs-1-0.dll v0.0 ts=2012/2/13 19:24 7k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_fs_util-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_fs_util-1-0.dll v0.0 ts=2012/2/13 19:24 34k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_ra-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_ra-1-0.dll v0.0 ts=2012/2/13 19:25 23k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_ra_local-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_ra_local-1-0.dll v0.0 ts=2012/2/13 19:24 119k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_ra_neon-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_ra_neon-1-0.dll v0.0 ts=2012/2/13 19:24 131k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_ra_serf-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_ra_serf-1-0.dll v0.0 ts=2012/2/13 19:24 70k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_ra_svn-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_ra_svn-1-0.dll v0.0 ts=2012/2/13 19:24 146k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_repos-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_repos-1-0.dll v0.0 ts=2012/2/13 19:24 289k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_subr-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_subr-1-0.dll v0.0 ts=2012/2/13 19:24 470k 2012/02/13 D:\dev_apps\cygwin\bin\cygsvn_wc-1-0.dll - os=4.0 img=1.0 sys=4.0 cygsvn_wc-1-0.dll v0.0 ts=2012/2/13 19:24 58k 2011/11/14 D:\dev_apps\cygwin\bin\cygtasn1-3.dll - os=4.0 img=1.0 sys=4.0 cygtasn1-3.dll v0.0 ts=2011/11/14 19:35 48k 2010/01/02 D:\dev_apps\cygwin\bin\cygtic-10.dll - os=4.0 img=1.0 sys=4.0 cygtic-10.dll v0.0 ts=2010/1/2 14:45 48k 2009/11/20 D:\dev_apps\cygwin\bin\cygtic-9.dll - os=4.0 img=1.0 sys=4.0 cygtic-9.dll v0.0 ts=2009/11/20 19:10 48k 2010/01/02 D:\dev_apps\cygwin\bin\cygticw-10.dll - os=4.0 img=1.0 sys=4.0 cygticw-10.dll v0.0 ts=2010/1/2 17:28 41k 2011/08/16 D:\dev_apps\cygwin\bin\cygusb0.dll - os=4.0 img=1.0 sys=4.0 cygusb0.dll v0.0 ts=2011/8/16 19:28 16k 2010/06/24 D:\dev_apps\cygwin\bin\cyguuid-1.dll - os=4.0 img=1.0 sys=4.0 cyguuid-1.dll v0.0 ts=2010/6/24 20:19 2758k 2012/02/05 D:\dev_apps\cygwin\bin\cygwin1-1.7.10.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2012/2/5 11:36 2758k 2012/02/15 D:\dev_apps\cygwin\bin\cygwin1-20120207.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2012/2/7 17:00 2757k 2012/02/15 D:\dev_apps\cygwin\bin\cygwin1-20120209.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2012/2/9 16:22 2757k 2012/02/15 D:\dev_apps\cygwin\bin\cygwin1-20120210.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2012/2/10 16:48 2747k 2012/02/15 D:\dev_apps\cygwin\bin\cygwin1-20120214.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2012/2/14 21:21 2746k 2012/02/15 D:\dev_apps\cygwin\bin\cygwin1-20120215.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2012/2/15 18:45 28k 2010/03/28 D:\dev_apps\cygwin\bin\cygwrap-0.dll - os=4.0 img=1.0 sys=4.0 cygwrap-0.dll v0.0 ts=2010/3/28 10:02 1045k 2011/08/22 D:\dev_apps\cygwin\bin\cygX11-6.dll - os=4.0 img=1.0 sys=4.0 cygX11-6.dll v0.0 ts=2011/8/22 9:25 11k 2010/08/03 D:\dev_apps\cygwin\bin\cygXau-6.dll - os=4.0 img=1.0 sys=4.0 cygXau-6.dll v0.0 ts=2010/8/3 1:32 337k 2011/02/04 D:\dev_apps\cygwin\bin\cygXaw-7.dll - os=4.0 img=1.0 sys=4.0 cygXaw-7.dll v0.0 ts=2011/2/4 7:02 75k 2010/12/21 D:\dev_apps\cygwin\bin\cygxcb-1.dll - os=4.0 img=1.0 sys=4.0 cygxcb-1.dll v0.0 ts=2010/12/21 1:36 17k 2010/10/31 D:\dev_apps\cygwin\bin\cygXdmcp-6.dll - os=4.0 img=1.0 sys=4.0 cygXdmcp-6.dll v0.0 ts=2010/10/31 20:29 52k 2011/05/23 D:\dev_apps\cygwin\bin\cygXext-6.dll - os=4.0 img=1.0 sys=4.0 cygXext-6.dll v0.0 ts=2011/5/23 9:32 66k 2010/11/01 D:\dev_apps\cygwin\bin\cygXft-2.dll - os=4.0 img=1.0 sys=4.0 cygXft-2.dll v0.0 ts=2010/11/1 2:10 119k 2010/11/01 D:\dev_apps
Re: Snapshot 20120214: fork: can't reserve memory for stack
On 02/15/2012 01:47 PM, Corinna Vinschen wrote: On Feb 15 11:45, Jehan Bing wrote: I'm getting the following error starting with cygwin snapshot 20120214 when running a git command: $ git add bigfile-test.dll 0 [main] git 7440 D:\dev_apps\cygwin\bin\git.exe: *** fatal error in forked process - fork: can't reserve memory for stack 0xAD - 0xBD, Win32 error 487 I can't reproduce that (also on W7). How big is bigfile-test.dll? Eric, does git use pthreads and fork from a thread, by any chance? /me rummages around in git.git Well, it certainly has both pthread_create and fork calls in the same files (at least run-command.c), although I'm not quire sure if it tries to actually fork from a pthread rather than from the main thread. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Snapshot 20120214: fork: can't reserve memory for stack
On Feb 15 14:01, Eric Blake wrote: On 02/15/2012 01:47 PM, Corinna Vinschen wrote: On Feb 15 11:45, Jehan Bing wrote: I'm getting the following error starting with cygwin snapshot 20120214 when running a git command: $ git add bigfile-test.dll 0 [main] git 7440 D:\dev_apps\cygwin\bin\git.exe: *** fatal error in forked process - fork: can't reserve memory for stack 0xAD - 0xBD, Win32 error 487 I can't reproduce that (also on W7). How big is bigfile-test.dll? Eric, does git use pthreads and fork from a thread, by any chance? /me rummages around in git.git Well, it certainly has both pthread_create and fork calls in the same files (at least run-command.c), although I'm not quire sure if it tries to actually fork from a pthread rather than from the main thread. Ok, thanks anyway. I think I know what happens. Two days ago I thought it is a good idea to use the Windows-provided stack from CreateThread by default (== if the application didn't provide its own). Too bad that Windows creates the stacks typically in the lower regions of the processes VM. I guess I have to revert that, so that pthread_create always uses a self-created stack again. Oh well. So much for good ideas... 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: STC for libapr1 failure
On 2/15/2012 12:45 PM, Corinna Vinschen wrote: On Feb 15 11:39, David Rothenberger wrote: On 2/15/2012 7:38 AM, Corinna Vinschen wrote: Did I mention that I hate synchronization problems? Anyway, I think I found the problem. I applied a patch which fixes the problem for me and, surprise!, the flock test still runs fine, too. I've just uploaded a new snapshot. Please give it a try. All the procmutex tests pass now! Awesome! But... now one of the flock tests is failing. It takes a while to extract a STC from the APR test suite because everything is written in APR-ese and I have to convert every APR call into the base C library calls. I'll work on that over the next day or three. The gist of the test that's failing is this: * Create a file. * Get an exclusive flock on it. * Spawn a child process that attempts to get an exclusive, non-blocking lock on the file. The test is expecting that the child will not be able to get the lock, but the child is able to. Did I really mention that I hate synchronization problems? Yeah, you mentioned it. :-) Does it fork/exec or does it only exec? Looks like fork/exec. execv to be precise. I guess I really need the testcase. I'll try to work on that tonight. -- 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
Re: STC for libapr1 failure
On Feb 15 13:15, David Rothenberger wrote: On 2/15/2012 12:45 PM, Corinna Vinschen wrote: On Feb 15 11:39, David Rothenberger wrote: On 2/15/2012 7:38 AM, Corinna Vinschen wrote: Did I mention that I hate synchronization problems? Anyway, I think I found the problem. I applied a patch which fixes the problem for me and, surprise!, the flock test still runs fine, too. I've just uploaded a new snapshot. Please give it a try. All the procmutex tests pass now! Awesome! But... now one of the flock tests is failing. It takes a while to extract a STC from the APR test suite because everything is written in APR-ese and I have to convert every APR call into the base C library calls. I'll work on that over the next day or three. The gist of the test that's failing is this: * Create a file. * Get an exclusive flock on it. * Spawn a child process that attempts to get an exclusive, non-blocking lock on the file. The test is expecting that the child will not be able to get the lock, but the child is able to. Did I really mention that I hate synchronization problems? Yeah, you mentioned it. :-) Does it fork/exec or does it only exec? Looks like fork/exec. execv to be precise. I guess I really need the testcase. I'll try to work on that tonight. Thanks. Btw., does that testcase fail in 1.7.9 as well? 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: Snapshot 20120214: fork: can't reserve memory for stack
On 2012-02-15 12:47, Corinna Vinschen wrote: On Feb 15 11:45, Jehan Bing wrote: I'm getting the following error starting with cygwin snapshot 20120214 when running a git command: $ git add bigfile-test.dll 0 [main] git 7440 D:\dev_apps\cygwin\bin\git.exe: *** fatal error in forked process - fork: can't reserve memory for stack 0xAD - 0xBD, Win32 error 487 I can't reproduce that (also on W7). How big is bigfile-test.dll? That one is 20MB. So it would never fit in the a stack (not a default-sized one anyway). But it also (mostly) fails on a smaller file (1.5MB). Given the size difference, if file size mattered, one would always succeed or the other always fail. Jehan -- 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: Snapshot 20120214: fork: can't reserve memory for stack
On Feb 15 22:13, Corinna Vinschen wrote: On Feb 15 14:01, Eric Blake wrote: On 02/15/2012 01:47 PM, Corinna Vinschen wrote: On Feb 15 11:45, Jehan Bing wrote: I'm getting the following error starting with cygwin snapshot 20120214 when running a git command: $ git add bigfile-test.dll 0 [main] git 7440 D:\dev_apps\cygwin\bin\git.exe: *** fatal error in forked process - fork: can't reserve memory for stack 0xAD - 0xBD, Win32 error 487 I can't reproduce that (also on W7). How big is bigfile-test.dll? Eric, does git use pthreads and fork from a thread, by any chance? /me rummages around in git.git Well, it certainly has both pthread_create and fork calls in the same files (at least run-command.c), although I'm not quire sure if it tries to actually fork from a pthread rather than from the main thread. Ok, thanks anyway. I think I know what happens. Two days ago I thought it is a good idea to use the Windows-provided stack from CreateThread by default (== if the application didn't provide its own). Too bad that Windows creates the stacks typically in the lower regions of the processes VM. I guess I have to revert that, so that pthread_create always uses a self-created stack again. Oh well. So much for good ideas... Just reverted in CVS. Will show up in the next snapshot. 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: porting problem triggered by gcc include search order
On 2/15/2012 6:44 PM, KIMURA Masaru wrote: Hi, I'm now porting Nick Gasson's nvc[1] to cygwin 1.7. and i'm stuck a porting problem triggered by gcc include search order[2]. Should I rename local signal.h? Or, anyone can tell me better way to solve this problem? Peace, - [1] https://github.com/nickg/nvc [2] https://github.com/hiyuh/nvc/blob/port-cygwin/TODO -- rename local signal.h is effective. I guess that -I. is influencing the inclusion order with unexpected results. -- 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: STC for libapr1 failure
On 2/15/2012 1:20 PM, Corinna Vinschen wrote: On Feb 15 13:15, David Rothenberger wrote: On 2/15/2012 12:45 PM, Corinna Vinschen wrote: On Feb 15 11:39, David Rothenberger wrote: On 2/15/2012 7:38 AM, Corinna Vinschen wrote: Did I mention that I hate synchronization problems? Anyway, I think I found the problem. I applied a patch which fixes the problem for me and, surprise!, the flock test still runs fine, too. I've just uploaded a new snapshot. Please give it a try. All the procmutex tests pass now! Awesome! But... now one of the flock tests is failing. It takes a while to extract a STC from the APR test suite because everything is written in APR-ese and I have to convert every APR call into the base C library calls. I'll work on that over the next day or three. The gist of the test that's failing is this: * Create a file. * Get an exclusive flock on it. * Spawn a child process that attempts to get an exclusive, non-blocking lock on the file. The test is expecting that the child will not be able to get the lock, but the child is able to. Did I really mention that I hate synchronization problems? Yeah, you mentioned it. :-) Does it fork/exec or does it only exec? Looks like fork/exec. execv to be precise. I guess I really need the testcase. I'll try to work on that tonight. Thanks. Btw., does that testcase fail in 1.7.9 as well? I'm pretty sure it did. I think all the tests passed the last time I released this package (2011-09-10), but I might have been testing against a snapshot. It's hard for me to tell now. If I just install 1.7.9 on my system, things like /bin/ls stop working. The compiled tests don't run, either. FYI, the test was passing with 1.7.10 and the 20120214 snapshot. It didn't start failing until your last snapshot (20120215). -- David Rothenberger daver...@acm.org Don't panic. -- 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: base-files 4.0-9: LANG is set to the system default, why not the user selection?
On Wed, Feb 15, 2012 at 02:11:14PM +, Andy Koppe wrote:
On 15 February 2012 13:59, Peter Rosin wrote:
My Windows is Swedish, but I generally like it to show as little as
possible in Swedish so my display language is English. I want
English, to not suffer from strange translations that don't make
sense, to be able to search for error messages, etc.
A recent change seems to have LANG set to the output of the system
default language, but I think that's just wrong, it should be the
language of the current user.
Please change lang.{c}sh to do locale -uU instead of locale -sU.
Where is the recommended position to override LANG until such a
change is made, or if it is not an agreeable change?
The files under /etc/profile.d are sourced by /etc/profile, which sets
system wide settings.
For user-defined values, the place to override a system-wide setting
depends on the shell you're using. E.g., for bash, it would be
~/.bash_profile. Check /etc/skel/.bash_profile. It should include
these lines:
# Set user-defined locale
export LANG=$(locale -uU)
Probably you have a customized ~/.bash_profile, so updating to
base-files-4.0-9 didn't replace it.
--
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56
signature.asc
Description: Digital signature
Re: base-files 4.0-9: LANG is set to the system default, why not the user selection?
David Sastre Medina skrev 2012-02-15 23:14:
The files under /etc/profile.d are sourced by /etc/profile, which sets
system wide settings.
For user-defined values, the place to override a system-wide setting
depends on the shell you're using. E.g., for bash, it would be
~/.bash_profile. Check /etc/skel/.bash_profile. It should include
these lines:
# Set user-defined locale
export LANG=$(locale -uU)
Probably you have a customized ~/.bash_profile, so updating to
base-files-4.0-9 didn't replace it.
Hmmm, ok, that doesn't completely match what I'm seeing in my $HOME, my
.bash_profile *looks* (who am I to tell, it's attached) unmodified from
4.0-6, so just a quick question, what postinstall script is responsible
for moving the updated skel files into $HOME? I couldn't find any, but
admittedly didn't spend much time looking...
Cheers,
Peter
# base-files version 4.0-6
# ~/.bash_profile: executed by bash(1) for login shells.
# The latest version as installed by the Cygwin Setup program can
# always be found at /etc/defaults/etc/skel/.bash_profile
# Modifying /etc/skel/.bash_profile directly will prevent
# setup from updating it.
# The copy in your home directory (~/.bash_profile) is yours, please
# feel free to customise it to create a shell
# environment to your liking. If you feel a change
# would be benifitial to all, please feel free to send
# a patch to the cygwin mailing list.
# User dependent .bash_profile file
# source the users bashrc if it exists
if [ -f ${HOME}/.bashrc ] ; then
source ${HOME}/.bashrc
fi
# Set PATH so it includes user's private bin if it exists
# if [ -d ${HOME}/bin ] ; then
# PATH=${HOME}/bin:${PATH}
# fi
# Set MANPATH so it includes users' private man if it exists
# if [ -d ${HOME}/man ]; then
# MANPATH=${HOME}/man:${MANPATH}
# fi
# Set INFOPATH so it includes users' private info if it exists
# if [ -d ${HOME}/info ]; then
# INFOPATH=${HOME}/info:${INFOPATH}
# fi
--
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
TAB cannot auto complete
Hi, I found that sometimes TAB key wouldn't do auto completion. My case is: there is 3 files in the directory: a.sh g.txt g1.txt And I type: sh a.sh g and then I would like to use bash completion to speed up typing. But nothing happened when I type TAB. It seemed that bash could not complete `g' to `g.txt' at all. The cygiwn version is: CYGWIN_NT-6.1-WOW64 3CNL12311 1.7.10(0.259/5/3) 2012-02-05 12:36 i686 Cygwin I never came across this error before. I don't know it is a new bug or not. And I attached the directory package. Hope it locate the cause of the problem. -- Best Regards, Pan Ruochen tmp.7z Description: application/7z-compressed -- 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: TAB cannot auto complete
On 2/16/2012 1:04 AM, Pan ruochen wrote: Hi, I found that sometimesTAB key wouldn't do auto completion. My case is: there is 3 files in the directory: a.sh g.txt g1.txt And I type: sh a.sh g and then I would like to use bash completion to speed up typing. But nothing happened when I typeTAB. It seemed that bash could not complete `g' to `g.txt' at all. The cygiwn version is: CYGWIN_NT-6.1-WOW64 3CNL12311 1.7.10(0.259/5/3) 2012-02-05 12:36 i686 Cygwin I never came across this error before. I don't know it is a new bug or not. And I attached the directory package. Hope it locate the cause of the problem. There's nothing new here. bash will complete any unambiguous file name. In your case, you don't have an unambiguous file name that starts with 'g'. You need to type either 'g.' or 'g1' to get bash to complete the rest. If you're ever not sure why bash hasn't done what you expect, you can always hit TAB again to see what possible completions exist. bash will list them. -- Larry _ 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
Updated: WordNet-3.0-2: A lexical database for the English language
Hi A new version of 'WordNet' has been uploaded to a server near you. o Build for cygwin 1.7.9 with gcc-4.5.3 o Uses now the X11 version of Tcl/Tk o Security fixes for CVE-2008-2149 and CVE-2008-3908 o Applied a couple of patches from Debian CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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.
Updated: {db4.5/libdb4.5/libdb4.5-devel/tcl-db4.5}-4.5.20.2-3: Oracle Berkeley DB - db4.5
Hi New versions of 'db4.5/libdb4.5/libdb4.5-devel/tcl-db4.5' have been uploaded to a server near you. o Build for cygwin 1.7.9 with gcc-4.5.3 o tcl-db4.5 linked against the Unix version of tcl CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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.
New packages: {db4.8/db4.8-doc/libdb4.8/libdb4.8-devel/tcl-db4.8}-4.8.30-1: Berkeley DB version 4.8
Hi The packages db4.8/db4.8-doc/libdb4.8/libdb4.8-devel/tcl-db4.8 are now available with the Cygwin distribution: o Initial release o Build for cygwin 1.7.9 with gcc-4.5.3 o tcl-db4.8 linked against the Unix version of tcl DESCRIPTION: Oracle Berkeley DB is the industry-leading open source, embeddable database engine that provides developers with fast, reliable, local persistence with zero administration. Oracle Berkeley DB is a library that links directly into your application. Your application makes simple function calls, rather than sending messages to a remote server, eliminating the performance penalty of client-server architectures. Oracle Berkeley DB eliminates the overhead of SQL query processing, enabling applications with predictable access patterns to run faster. Enjoy Volker CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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.
