Re: [RFU] orpie-1.5.1-1
On Nov 21 13:45, [EMAIL PROTECTED] wrote: Please upload. Thanks, Andrew. wget \ http://home.comcast.net/~aschulman2/orpie/orpie-1.5.1-1.tar.bz2 \ http://home.comcast.net/~aschulman2/orpie/orpie-1.5.1-1-src.tar.bz2 Doesn't work: $ wget http://home.comcast.net/~aschulman2/orpie/orpie-1.5.1-1.tar.bz2 --09:15:08-- http://home.comcast.net/~aschulman2/orpie/orpie-1.5.1-1.tar.bz2 = `orpie-1.5.1-1.tar.bz2' Resolving home.comcast.net... 216.87.188.20 Connecting to home.comcast.net|216.87.188.20|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://home.comcast.net/site/error/error_404.html [following] --09:15:08-- http://home.comcast.net/site/error/error_404.html = `error_404.html' Connecting to home.comcast.net|216.87.188.20|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,579 (1.5K) [text/html] 100%[] 1,579 --.--K/s 09:15:08 (71.71 MB/s) - `error_404.html' saved [1579/1579] Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[UPLOAD] lighttpd-1.4.18-1
http://cyberx.lapo.it/cygwin/lighttpd/setup.hint (unchanged) http://cyberx.lapo.it/cygwin/lighttpd/lighttpd-1.4.18-1-src.tar.bz2 http://cyberx.lapo.it/cygwin/lighttpd/lighttpd-1.4.18-1.tar.bz2 (now based on cygport instead of g-b-s) -- Lapo Luchini [EMAIL PROTECTED] (OpenPGP X.509) www.lapo.it (Jabber, ICQ, MSN)
src/winsup/cygwin ChangeLog fhandler_registry.cc
CVSROOT:/cvs/src Module name:src Branch: cr-0x5f1 Changes by: [EMAIL PROTECTED] 2007-11-22 11:10:48 Modified files: winsup/cygwin : ChangeLog fhandler_registry.cc Log message: * fhandler_registry.cc (must_encode): New function. (encode_regname): Ditto. (decode_regname): Ditto. (fhandler_registry::exists): Encode name before path compare. (fhandler_registry::fstat): Pass decoded name to win32 registry call. (fhandler_registry::readdir): Return encoded name to user. (fhandler_registry::open): Store decoded name into value_name. (open_key): Pass decoded name to win32 registry call. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cr-0x5f1r1=1.3582.2.33r2=1.3582.2.34 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_registry.cc.diff?cvsroot=srconly_with_tag=cr-0x5f1r1=1.35r2=1.35.4.1
Re: [Patch] Encode invalid chars in /proc/registry entries
On Nov 16 20:25, Christian Franke wrote: Corinna Vinschen wrote: Thanks for this patch. Apart from the missing ChangeLog I'm inclined to apply it to the upcoming 1.5.25 release, but I don't like to have it in HEAD as is. Thanks, I would appreciate to have this issue fixed in the bugfix release. Here is a new version of the patch and a ChangeLog. The names . and .. are now also encoded. Theses are also valid as Key/Value Names and .. may result in infinite recursion. Thanks, I've tested it on my machine and I've applied the patch to the cr-0x5f1 branch. So, for HEAD I'd like to ask you to allow arbitrary path lengths in your code. Personally I could live with restricting registry paths to PATH_MAX as well. Agree. Probably Cygwin should never descend paths that exceed PATH_MAX, as an application using PATH_MAX may have no buffer overflow check. I agree. While you're digging in registry code anyway... would you be interested to convert the entire registry code to wide char and long path names? I'd be glad for any help. I will have a look at it, but be patient. Is current HEAD a reasonable starting point or is there a better (more stable) snapshot? Usually HEAD is the *only* valid starting point. Thanks again for the patch, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Resource Temporarily Unavailable workaround
On Thu, Nov 22, 2007 at 04:41:54PM +, Andrew STUBBS wrote: The attached patch adds a 'retry' to the fork system call. Basically it waits 10 seconds to allow the 'resource temporarily unavailable' to become (temporarily) available once more, and tries again, up to a maximum of three attempts. There is already a retry in the fork and spawn system calls. This technique has proved to be problematic since it can mask problems and you can end up with situations where a process starts successfully but cygwin thinks it fails and restarts the process again. For the exec case, there is also a problem with non-cygwin .exes. If you look for retry in the fork call you should see where this is supposed to be happening. cgf
Re: Resource Temporarily Unavailable workaround
On Thu, Nov 22, 2007 at 12:00:51PM -0500, Christopher Faylor wrote: On Thu, Nov 22, 2007 at 04:41:54PM +, Andrew STUBBS wrote: The attached patch adds a 'retry' to the fork system call. Basically it waits 10 seconds to allow the 'resource temporarily unavailable' to become (temporarily) available once more, and tries again, up to a maximum of three attempts. There is already a retry in the fork and spawn system calls. This technique has proved to be problematic since it can mask problems and you can end up with situations where a process starts successfully but cygwin thinks it fails and restarts the process again. For the exec case, there is also a problem with non-cygwin .exes. If you look for retry in the fork call you should see where this is supposed to be happening. Btw, it is likely that if you are seeing this problem that there is something happening after the retry code in fork which is causing an EAGAIN. The existing retry code could be expanded to take that into account if that is the case. cgf
Re: Resource Temporarily Unavailable workaround
Christopher Faylor wrote: On Thu, Nov 22, 2007 at 12:00:51PM -0500, Christopher Faylor wrote: On Thu, Nov 22, 2007 at 04:41:54PM +, Andrew STUBBS wrote: The attached patch adds a 'retry' to the fork system call. Basically it waits 10 seconds to allow the 'resource temporarily unavailable' to become (temporarily) available once more, and tries again, up to a maximum of three attempts. There is already a retry in the fork and spawn system calls. This technique has proved to be problematic since it can mask problems and you can end up with situations where a process starts successfully but cygwin thinks it fails and restarts the process again. For the exec case, there is also a problem with non-cygwin .exes. If you look for retry in the fork call you should see where this is supposed to be happening. Btw, it is likely that if you are seeing this problem that there is something happening after the retry code in fork which is causing an EAGAIN. The existing retry code could be expanded to take that into account if that is the case. Thanks, now I see the retry, but the code is impossible to follow without knowing both Cygwin and Windows backwards, and I don't have that much time to spend on this. :( Clearly its retries aren't (always) sufficient. Perhaps it isn't retrying enough, or retrying the right stuff, or maybe not waiting long enough between retries. There is quite a lot of stuff outside the while (1) that I assume is the retried code. EAGAIN is mentioned a few times, and that's without taking into account the contents of the various function calls. In particular there's one comment that says Hopefully, this will succeed. - which is reassuring. Unfortunately the problem isn't easily reproducible. I can't use strace as it runs way too slowly and I would just never get to the problem. I could instrument the whole file up so that I can trace just that, and then sit back and wait. Any suggestions? Andrew
Re: Resource Temporarily Unavailable workaround
On Thu, Nov 22, 2007 at 05:55:05PM +, Andrew STUBBS wrote: Christopher Faylor wrote: On Thu, Nov 22, 2007 at 12:00:51PM -0500, Christopher Faylor wrote: On Thu, Nov 22, 2007 at 04:41:54PM +, Andrew STUBBS wrote: The attached patch adds a 'retry' to the fork system call. Basically it waits 10 seconds to allow the 'resource temporarily unavailable' to become (temporarily) available once more, and tries again, up to a maximum of three attempts. There is already a retry in the fork and spawn system calls. This technique has proved to be problematic since it can mask problems and you can end up with situations where a process starts successfully but cygwin thinks it fails and restarts the process again. For the exec case, there is also a problem with non-cygwin .exes. If you look for retry in the fork call you should see where this is supposed to be happening. Btw, it is likely that if you are seeing this problem that there is something happening after the retry code in fork which is causing an EAGAIN. The existing retry code could be expanded to take that into account if that is the case. Thanks, now I see the retry, but the code is impossible to follow without knowing both Cygwin and Windows backwards, and I don't have that much time to spend on this. :( Clearly its retries aren't (always) sufficient. Perhaps it isn't retrying enough, or retrying the right stuff, or maybe not waiting long enough between retries. Yes, that's why I typed the above Btw, paragraph. Unfortunately the problem isn't easily reproducible. I can't use strace as it runs way too slowly and I would just never get to the problem. I could instrument the whole file up so that I can trace just that, and then sit back and wait. Any suggestions? You could use printf's to find where it is failing. But, really, that's a pretty obvious suggestion. I'm not sure what suggestions you're looking for if you can't find the time to learn anything more about Cygwin or Windows. cgf
starting squid getgrnam failed , getpwnam failed , , `nobody` , `nogroup`. Windows xp
I have had these errors when trying to run squid. in win xp. $ squid FATAL: getpwnam failed to find userid for effective user 'nobody' I read this [1] which seems to say to me I can solve this by creating a nobody account. So I saw this [2] about how to do that in cygwin. and I did created the nobody user net user nobody /add and probably added him to users. net localgroup users nobody /add or I created the user in windows and it automatically went into the users group. and seeing that $less /etc/passwd and $less /etc/group seem less up to date, than mkgroup -l -u and mkpasswd -l , I did mkgroup -l /etc/group mkpasswd -l /etc/passwd I saw these commands mentioned once. And then when trying to run squid, I got the similar error FATAL: getgrnam failed to find groupid for effective group 'nogroup' That is more-or-less what happened. I am not sure what to do next to get it working. I don`t really know what I am doing! [1] http://www.squid-cache.org/mail-archive/squid-users/200112/0585.html [2] http://www.cygwin.com/ml/cygwin/2005-07/msg00931.html -- 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: Announce: FlexDLL, flexible DLLs under Windows
Christopher Faylor wrote: Not an unreasonable idea, but very hard to make work when we really want cygwin apps to basically be windows apps; I can't see how cygwin could support e.g. an ELF loader and yet still be able to launch cygwin apps from cmd.exe rather than having to fire up bash or whatever. It could theoretically do that if it had it's own loader for ELF binaries. Yes, probably. But then you run into the situation where you're doing things behind the back of Windows, so to speak. The first thing that comes to mind is the prefetching that is present in XP and later, which reduces process startup time by recording the disk extents of all images involved in startup so that they can be loaded all at once sequentially the next time the process starts. The next thing is the memory manager, which I think treats DLLs differently than generic file mappings for the purpose of maintaining and trimming the working set. And I wonder if there are further things that would not be possible without specific kernel support -- unless maybe you had a real win32 stub image for each exe/dll. Anyway, I don't mean to discourage anyone from trying this crazy idea, but just pointing out why staying with PE-compliant DLLs and EXEs under the hood has its advantages. ISTM it would be easier to add event notifiers to the shell or the app, although the implementation of that would almost certainly require a code fork. And the memory management and the practice of loading Windows apps with Unix is much better documented. AND although Cygwin is limited by its use of static libraries in that regard, the task would not be impossible. Just my 0.02. -- Ctalk Home Page: http://ctalk-lang.sourceforge.net -- 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: [experimental] cygwin-1.5.25-1
CYGWIN THANKSGIVING EDITION
I've made the new version of the Cygwin DLL, 1.5.25-1, and associated
utilities available for testing. Version 1.5.24-2 remains the current
version for now.
This is a bug fix release. Important changes since 1.5.24-2:
- Always add LOCAL and INTERACTIVE groups to user tokens to fix some
permission problems on Windows 2003 Server and later.
- Set preferred IO blocksize to 64K for performance reasons.
- Add missing baudrates for serial IO up to 3.000.000 baud.
- Fix various race conditions in process exit, in dll initialization,
when starting native Win32 processes, and in signal handling.
- Fix a couple of buffer-related problems when accessing raw disk devices.
- Fix bug in dlclose.
- Don't set TZ environment variable in calls to tzset.
- Don't follow symlinks in calls to open if O_EXCL is given.
- Fix deadlock and reentrancy problems in stdio functions. Fix
append mode handling in stdio functions.
- Fix append mode bug when accessing files 4 Gigs.
- Various fixes to stat/fstat/lstat functions (wrong permission bits,
timestamps, etc).
- Fix a deadlock problem in fork, as well as a crash on fork after
calling shmctl(IPC_RMID).
- Add thread-safety to mmap and to XSI IPC calls.
- Drop a non-sensical check in pthread_key_create.
- Encode special characters in /proc/registry key and value names to
avoid invalid character problems.
- Assorted fixes to cygpath.exe, cygcheck.exe, dumper.exe and mkgroup.exe.
- Various bugfixes to printf/scanf function families. Add support for
j, t, and z modifiers to scanf functions.
- Close security hole in tmpfile.
- Fix potential crashes in argz functions.
- Fix long-standing regression in rewind error handling.
- Support NULL output buffer in wcstombs.
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, then look for
'cygwin' in the 'Base' category (it should already be selected). You
will need to use the 'Exp' radio button to get the test version.
If you have questions or comments, please send them to the Cygwin
mailing list. See http://cygwin.com/lists.html for details.
*** 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://sourceware.org/lists.html#unsubscribe-simple
Please read *all* of the information on unsubscribing that is available
starting at this URL.
Corinna Vinschen
Red Hat
--
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: Announce: FlexDLL, flexible DLLs under Windows
On Thu, Nov 22, 2007 at 04:15:50AM -0500, Robert Kiesling wrote: ISTM it would be easier to add event notifiers to the shell or the app, although the implementation of that would almost certainly require a code fork. And the memory management and the practice of loading Windows apps with Unix is much better documented. AND although Cygwin is limited by its use of static libraries in that regard, the task would not be impossible. Just my 0.02. My $.02: I can't grok most of the above. Cygwin doesn't rely on a shell, adding event notifiers doesn't make a lot of sense in this context, and the mention of static libraries doesn't really seem pertinent to a disscussion of shared library loading. cgf -- 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: Reliable old script loses data on new Cygwin installation
On Tue, 13 Nov 2007, Thomas Baker wrote: The /bin/pdksh script sequence that is causing problems is: [snip] The obvious question is: do you still get the error if you replace pdksh with bash, or is the problem pdksh-specific? When you reduce this to a minimal testcase, are there bits of that testcase that require pdksh to be used? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- 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] Updated: [experimental] cygwin-1.5.25-1
* Corinna Vinschen (Thu, 22 Nov 2007 16:42:10 +0100) CYGWIN THANKSGIVING EDITION I've made the new version of the Cygwin DLL, 1.5.25-1, and associated utilities available for testing. Version 1.5.24-2 remains the current version for now. This is a bug fix release. Important changes since 1.5.24-2: Unfortunately the changes that made rsync run about 2 - 6 times faster [1] (on a backup of about 100,000 files residing on a FAT32 volume) didn't make it into the prelease. The first snapshot that exhibited the stunning increase was the snapshot from 2007-08-02 and the last one was the snapshot from 2007- 08-13. Thorsten [1] http://thread.gmane.org/gmane.os.cygwin/91350/focus=91509 -- 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: Reliable old script loses data on new Cygwin installation
On Thu, Nov 22, 2007 at 12:56:33PM -0500, Igor Peshansky wrote: The /bin/pdksh script sequence that is causing problems is: [snip] The obvious question is: do you still get the error if you replace pdksh with bash, or is the problem pdksh-specific? When you reduce this to a minimal testcase, are there bits of that testcase that require pdksh to be used? It appears that pdksh (or Cygwin) per se had nothing to do with the problem. As I reported in [1], the problem was resolved when I discovered that the anti-virus software (Anti-Vir) was checking each time a file is written to disk. When I switched off this extra check (so that Anti-Vir now checks only when files are read), the script ran perceptibly faster and data is no longer lost. I originally wrote the script using the MKS Toolkit Korn shell with DOS 3.3, and it uses some features which may be Korn shell-specific (e.g., redirecting to numbered file descriptors with constructs such as 3|) -- I have not really tried to port it to bash. Tom [1] http://cygwin.com/ml/cygwin/2007-11/msg00313.html -- Tom Baker - [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 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: Running Cygwin bash from Ant script
On Wed, 14 Nov 2007, Nicolai Kamenzky wrote: Hi folks! In my Ant script I have a target which should 1. Start the Cygwin bash, 2. Change the current directory, and 3. Execute a command. I have done this previously using the windows console, but now I want to do the same with the Cygwin bash. My Ant target looked like this: project name=xyz basedir=. target name=build exec dir=. executable=cmd.exe arg line=/c make/ /exec /target /project I tried this, but it didn't work: project name=xyz basedir=. target name=build exec dir=. executable=C:\Program Files\cygwin\bin\bash arg line= --login -i -c cd /cygdrive/c/someFolderToBeTheCurrentDir/; make/ /exec /target /project Any ideas? This isn't really Cygwin-specific -- you'd have the same problem with ant and bash on Linux. Don't use arg line, use something like exec dir=. executable=C:\Program Files\cygwin\bin\bash arg value=--login/ arg value=-i/ arg value=-c/ arg value=cd /cygdrive/c/someFolderToBeTheCurrentDir/; make/ /exec HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- 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] Updated: unison2.13, unison2.17, unison2.27
On Wed, 14 Nov 2007, Andrew Schulman wrote: Also is bash style shell arithmetic used for the priority allowed in a /bin/sh script ? I'm not sure, since bash is the default shell now. But since ash is still out there, I've removed the offending arithmetic (which I now take care of in my makefile instead). Or you could make the postinstall script a bash script, and make bash a prerequisite of unison (no big deal, as bash is already in Base). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- 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: Announce: FlexDLL, flexible DLLs under Windows
On Thu, Nov 22, 2007 at 04:15:50AM -0500, Robert Kiesling wrote: ISTM it would be easier to add event notifiers to the shell or the app, although the implementation of that would almost certainly require a code fork. And the memory management and the practice of loading Windows apps with Unix is much better documented. AND although Cygwin is limited by its use of static libraries in that regard, the task would not be impossible. Just my 0.02. I can't grok most of the above. Cygwin doesn't rely on a shell, adding event notifiers doesn't make a lot of sense in this context, and the mention of static libraries doesn't really seem pertinent to a disscussion of shared library loading. The scenario is normal and expected - program that uses data for another program and its libraries to finish before another program can read the data written to disk, loaded and swapped in its memory and then make use of the data. The mechanisms of this scenario vary between operating system and version. Unfortunately, Cygwin apps do rely on shells, or in the case of services, the exec () and similar system calls that load the apps and libraries. ISTM the previous description obfuscates and in fact complicates the process. The APIs to accomplish those tasks already exist. Anybody that wants to accomplish the tasks has only to look them up for themselves. -- Ctalk Home Page: http://ctalk-lang.sourceforge.net -- 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/
Library Problem
Hi!
I've got a problem using the libflv library
(http://klaus.geekserver.net/libflv/). The build worked without any problems.
make produced a libflv.so file, so i copied it as libflv.dll to /usr/lib.
I wrote a test app and tried building it with:
gcc -lflv test.c -o test.exe
That worked well (no warnings,errors).
But if I try running ./test.exe there's no responce at all and I get the bash
prompt again.
[EMAIL PROTECTED] ~
$ ./test.exe
[EMAIL PROTECTED] ~
$
When I remove the libflv functions I get the printf output...
The same code works well on unix systems...
Probably a linking error? How can I fix that?
Thanks in advance!
test.c:
#include libflv.h
#include stdio.h
int main( void ){
printf(foo\n);
Stream *vstream;
FlvStream *flv;
int width = 400;
int height = 300;
srand ( time(NULL) );
vstream = ScreenVideo_newStream(width, height, 16, 9);
flv = FlvStream_newStream(./out.flv, NULL, vstream , FLV_VERSION_1);
...
}
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
--
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: starting squid getgrnam failed , getpwnam failed , , `nobody` , `nogroup`. Windows xp
[EMAIL PROTECTED] wrote: I have had these errors when trying to run squid. in win xp. $ squid FATAL: getpwnam failed to find userid for effective user 'nobody' I read this [1] which seems to say to me I can solve this by creating a nobody account. So I saw this [2] about how to do that in cygwin. and I did created the nobody user net user nobody /add and probably added him to users. net localgroup users nobody /add or I created the user in windows and it automatically went into the users group. and seeing that $less /etc/passwd and $less /etc/group seem less up to date, than mkgroup -l -u and mkpasswd -l , I did mkgroup -l /etc/group mkpasswd -l /etc/passwd I saw these commands mentioned once. And then when trying to run squid, I got the similar error FATAL: getgrnam failed to find groupid for effective group 'nogroup' That is more-or-less what happened. I am not sure what to do next to get it working. I don`t really know what I am doing! I think you're doing alright. Why not try creating the 'nogroup' group and see if that moves the peg forward a bit? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: xargs: cannot fork: Resource temporarily unavailable
Jose Correia wrote: Hi all Sometime ago I posted saying it could have been the Logitech services running, as I had read somewhere on the mailing list, but unfortunately that is not the case, the problem below still persists... Can someone shed some urgent light on this matter please? Got BLODA? ;-) http://cygwin.com/acronyms/#BLODA This is a typical cause of stuff like this. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: xargs: cannot fork: Resource temporarily unavailable
Hi all
Sometime ago I posted saying it could have been the Logitech services
running, as I had read somewhere on the mailing list, but unfortunately
that is not the case, the problem below still persists... Can someone
shed some urgent light on this matter please?
Appreciated
Jose Correia
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Jose Correia
Sent: 12 November 2007 03:55 PM
To: cygwin@cygwin.com
Subject: xargs: cannot fork: Resource temporarily unavailable
Hi all
Im using cygin install when the cygwin install version 2.457.2.2 on
Windows XP professional SP2, on an IBM ThinkPad Dual Processor T60.
I run a unix script from a bigger ant script, which used to work fine on
a single processor laptop. Now it works intermittently
The Unix script is this:
#START
export SRC=$1
find $SRC -type d -name 'CVS' | xargs -i rm -rf {}
mv $SRC/tres/src/java/com/traderoot/core/
$SRC/tres/src/java/com/traderoot/cfgcore
#for jaxb generated source
mv $SRC/com/traderoot/core/ $SRC/com/traderoot/cfgcore
grep -Rl 'com.traderoot.core' $SRC | xargs -i ./replace.sh
's/com\.traderoot\.core/com.traderoot.cfgcore/g' {} grep -Rl
'com/traderoot/core' $SRC | xargs -i ./replace.sh
's#com/traderoot/core#com/traderoot/cfgcore#g' {} grep -Rl
'com.traderoot.tools' $SRC | xargs -i ./replace.sh
's/com\.traderoot\.tools/com.traderoot.cfgtools/g' {}
#END
On the times when it does not work it spews out:
[exec] + xargs -i ./replace.sh
's/com\.traderoot\.tools/com.traderoot.cfgtools/g' '{}'
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/Additionaldata.jav
a
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/Address.java
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/Arg.java
[exec] replacing in
bootloadergensrc/com/traderoot/cfgtools/artifact/jaxb/impl/JAXBVersion.j
ava
[exec] 4 [main] xargs 112660 fork_copy: linked dll data/bss
pass 0 failed, 0x54D000..0x54D020, done 0, windows pid 114584, Win32
error 487
[exec] xargs: cannot fork: Resource temporarily unavailable
Could this be because of the dual processor where somehow the one
process is left hanging waiting for the other? Anyone experienced this
issue before...? can't find anything on the archives...
Regards
Jose Correia
--
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/
--
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: Library Problem
On Fri, Nov 23, 2007 at 12:21:17AM +0100, [EMAIL PROTECTED] wrote: Hi! I've got a problem using the libflv library (http://klaus.geekserver.net/libflv/). The build worked without any problems. make produced a libflv.so file, so i copied it as libflv.dll to /usr/lib. I wrote a test app and tried building it with: gcc -lflv test.c -o test.exe You need to put the -lflv after the test.c: gcc test.c -lflv -o test.exe cgf -- 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: Library Problem
On 22 November 2007 23:21, [EMAIL PROTECTED] wrote: Hi! I've got a problem using the libflv library (http://klaus.geekserver.net/libflv/). The build worked without any problems. make produced a libflv.so file, so i copied it as libflv.dll to /usr/lib. DLLs need to be on your path, and go in /usr/bin. /usr/lib is only for static link libs (.a) really. But if I try running ./test.exe there's no responce at all and I get the bash prompt again. [EMAIL PROTECTED] ~ $ ./test.exe [EMAIL PROTECTED] ~ $ Using echo $? at this point would probably show error code 53, which means 'Missing DLL'. 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/
Updated: [experimental] cygwin-1.5.25-1
CYGWIN THANKSGIVING EDITION
I've made the new version of the Cygwin DLL, 1.5.25-1, and associated
utilities available for testing. Version 1.5.24-2 remains the current
version for now.
This is a bug fix release. Important changes since 1.5.24-2:
- Always add LOCAL and INTERACTIVE groups to user tokens to fix some
permission problems on Windows 2003 Server and later.
- Set preferred IO blocksize to 64K for performance reasons.
- Add missing baudrates for serial IO up to 3.000.000 baud.
- Fix various race conditions in process exit, in dll initialization,
when starting native Win32 processes, and in signal handling.
- Fix a couple of buffer-related problems when accessing raw disk devices.
- Fix bug in dlclose.
- Don't set TZ environment variable in calls to tzset.
- Don't follow symlinks in calls to open if O_EXCL is given.
- Fix deadlock and reentrancy problems in stdio functions. Fix
append mode handling in stdio functions.
- Fix append mode bug when accessing files 4 Gigs.
- Various fixes to stat/fstat/lstat functions (wrong permission bits,
timestamps, etc).
- Fix a deadlock problem in fork, as well as a crash on fork after
calling shmctl(IPC_RMID).
- Add thread-safety to mmap and to XSI IPC calls.
- Drop a non-sensical check in pthread_key_create.
- Encode special characters in /proc/registry key and value names to
avoid invalid character problems.
- Assorted fixes to cygpath.exe, cygcheck.exe, dumper.exe and mkgroup.exe.
- Various bugfixes to printf/scanf function families. Add support for
j, t, and z modifiers to scanf functions.
- Close security hole in tmpfile.
- Fix potential crashes in argz functions.
- Fix long-standing regression in rewind error handling.
- Support NULL output buffer in wcstombs.
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, then look for
'cygwin' in the 'Base' category (it should already be selected). You
will need to use the 'Exp' radio button to get the test version.
If you have questions or comments, please send them to the Cygwin
mailing list. See http://cygwin.com/lists.html for details.
*** 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://sourceware.org/lists.html#unsubscribe-simple
Please read *all* of the information on unsubscribing that is available
starting at this URL.
Corinna Vinschen
Red Hat
