Re: [PATCH] Setup postinstall logging - take 3?
Igor Pechtchanski wrote: Will let you know what I find when I get a chance to try your test with the script. bk Oops, I was going to mention that the output now goes into setup.log.full, but for some reason thought better of it. Looks like I should have. :-) Sorry. Ah hah. There it is - they are still updating - both machines (w2k and win95). I don't think progress bars will show any useful information with only one script. If you create a few of those (testpostinstall1.sh, testpostinstall2.sh, etc), you should see the progress bar jumping in 5-second increments. On Win2k Testpostinstall1.sh through testpostinstall4.sh executed as planned - each waited 5 seconds and each displayed their portion of the status bar. Log still being updated. Same test performed on Win95 - all is still good - testpostinstall1.sh through testpostinstall4.sg ran as planned and log still being updated. Bk
Re: [PATCH] Allow logging of {pre,post}remove scripts
Igor Pechtchanski wrote: This patch extends logging support to preremove/postremove scripts. Igor = Igor, gave the patch a shot on my Win2k and Win95 laptops and reinstalling gcc-mingw an inetutils and the Command window seems to be gone but other than the reference to install of the gcc-mingw preremove script I could find nothing in setup.log.full (this is the right place for this one right) about its having been executed. The postinstall gcc-mingw script does have a reference for its install and its execution - is that what I should see as well for the preremove. I also noticed when I reinstalled gcc-mingw that a gcc-mingw.sh was created in preremove and postinstall and as we have already tested in postinstall it gets renamed to gcc-mingw.sh.done but in preremove it appears to be copied (not moved or renamed) to gcc-mingw.sh.done - so then there are two in preremove - a done and a not done. Hope this helps bk
Re: [PATCH] Setup postinstall logging - take 3?
On Mon, 24 Mar 2003, Brian Keener wrote: Igor Pechtchanski wrote: Will let you know what I find when I get a chance to try your test with the script. bk Oops, I was going to mention that the output now goes into setup.log.full, but for some reason thought better of it. Looks like I should have. :-) Sorry. Ah hah. There it is - they are still updating - both machines (w2k and win95). I don't think progress bars will show any useful information with only one script. If you create a few of those (testpostinstall1.sh, testpostinstall2.sh, etc), you should see the progress bar jumping in 5-second increments. On Win2k Testpostinstall1.sh through testpostinstall4.sh executed as planned - each waited 5 seconds and each displayed their portion of the status bar. Log still being updated. Same test performed on Win95 - all is still good - testpostinstall1.sh through testpostinstall4.sg ran as planned and log still being updated. Bk This is good news. Thanks. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
Re: [PATCH] Allow logging of {pre,post}remove scripts
Brian, Replies inline below. On Mon, 24 Mar 2003, Brian Keener wrote: Igor Pechtchanski wrote: This patch extends logging support to preremove/postremove scripts. Igor = Igor, gave the patch a shot on my Win2k and Win95 laptops and reinstalling gcc-mingw an inetutils and the Command window seems to be gone but other than the reference to install of the gcc-mingw preremove script I could find nothing in setup.log.full (this is the right place for this one right) about its having been executed. The postinstall gcc-mingw script does have a reference for its install and its execution - is that what I should see as well for the preremove. Yes, the preremove scripts should also be logged to setup.log.full. I'm not sure I understand the above, though - was the preremove script logged or wasn't it? The gcc-mingw preremove script's output should be the following one line: *** Removing gcc-mingw files. Please wait. *** and should be preceded by running: C:\cygwin\bin\sh.exe -c /etc/preremove/gcc-mingw.sh. You're welcome to send me the resulting setup.log.full off-list if you're unsure whether the logging worked. I also noticed when I reinstalled gcc-mingw that a gcc-mingw.sh was created in preremove and postinstall and as we have already tested in postinstall it gets renamed to gcc-mingw.sh.done but in preremove it appears to be copied (not moved or renamed) to gcc-mingw.sh.done - so then there are two in preremove - a done and a not done. This is fine. It is renamed. But remember, you're *reinstalling* the package. The newly installed copy of the package will again contain a /etc/preremove/gcc-mingw.sh. :-) Hope this helps bk Yes, thanks for testing. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
Re: ATTN: Apache, Perl, Python, and Exim maintainers
Chuck, On Sat, Mar 22, 2003 at 06:47:37PM -0500, Charles Wilson wrote: python/setup.hint to change the requires: dependency on 'gdbm' to 'libgdbm'. Thus, you don't need to do anything NOW, but you probably need to note this change so that your next release reflects the correct dependency. Thanks for the heads up. I have updated my source controlled copy. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
Re: ATTN: Apache, Perl, Python, and Exim maintainers
Stipe, On Sun, Mar 23, 2003 at 08:40:23AM -0500, Nicholas Wourms wrote: While your at it, will you *please* remove rebase from mod_php4. As you know, rebase is now an official cygwin package. The one you have is deprecated and broken, it causes trouble when the new rebase tries to rebase the dll's that your ancient rebase touched. I concur with the above and I ask you again: Please release updated package(s) without the broken rebase ASAP. Your packages corrupt DLLs for Me users and are becoming to be a (rebase) support burden. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
Re: ATTN: Apache, Perl, Python, and Exim maintainers
Jason, I concur with the above and I ask you again: Please release updated package(s) without the broken rebase ASAP. Your packages corrupt DLLs for Me users and are becoming to be a (rebase) support burden. ok, I'll even update the packages, even while we still have a serious connection problem in apache. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [PATCH] Allow logging of {pre,post}remove scripts
Igor, My apologies - all is well - see below. Igor Pechtchanski wrote: I'm not sure I understand the above, though - was the preremove script logged or wasn't it? The gcc-mingw preremove script's output should be the following one line: *** Removing gcc-mingw files. Please wait. *** and should be preceded by running: C:\cygwin\bin\sh.exe -c /etc/preremove/gcc-mingw.sh. You're welcome to send me the resulting setup.log.full off-list if you're unsure whether the logging worked. Sorry - I goofed - the line you mention is in fact in the setup.log.full file. My explanation is that I am more used to using pg in unix than less and therefore I have a link for pg that points to less. For whatever reason - I have noticed that I don't always see the first line of a page or document when I use the pg link as opposed to just using less. I had apparently used pg and searched for gcc-mingw.sh and only saw the part about installing and then running the postinstall - I never saw the running preremove and I really did search several times - but obviously always using pg. I even searched for preremove but still never saw it. When I went back on both Win95 and W2k and used less to look at setup.log.full - there they were. I guess I really should figure out why the pg link causes that to happen as opposed to just using less, or quit using my pg link. Anyways - sorry for the false alarm - all appears to be well. I also noticed when I reinstalled gcc-mingw that a gcc-mingw.sh was created in preremove and postinstall and as we have already tested in postinstall it gets renamed to gcc-mingw.sh.done but in preremove it appears to be copied (not moved or renamed) to gcc-mingw.sh.done - so then there are two in preremove - a done and a not done. This is fine. It is renamed. But remember, you're *reinstalling* the package. The newly installed copy of the package will again contain a /etc/preremove/gcc-mingw.sh. :-) You are correct - I forgot the obvious. bk
Re: ATTN: Apache, Perl, Python, and Exim maintainers
Sorry for chiming in unannounced but the connection problem only seems to happen when libphp4 is loaded into the server. I have had a running Apache install (before I re-installed my production box) that worked for over two weeks. Add php to the equation and what happened...it died. Before 1.3.21 I was not even able to keep the daemon running longer than five minutes with or without php. Now it works perfectly by itself (without php). nop, I see this happen even for a bare nacked apache without any extra modules. can you please issue the following to your httpd processes: $ /usr/sbin/ab -i -r 1000 http://localhost/ this will hit your apache with 1000 HTTP HEAD requests. After this has done wait some seconds and re-do. This should cause the httpd childs to 'hang'. And even a 'telnet localhost 80' will either give you no TCP connect or if, you can enter a HTTP request but will never get a response. Ok, just to be sure: which cygwin version and OS are you running? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [PATCH] Run postinstall scripts in a thread with progress bars - take 3
On 21 Mar 2003, Robert Collins wrote: On Fri, 2003-03-21 at 08:49, Igor Pechtchanski wrote: On 21 Mar 2003, Robert Collins wrote: On Fri, 2003-03-21 at 04:49, Igor Pechtchanski wrote: Same as above, but regenerated against HEAD. ChangeLog is the same. The only thing about this patch that really makes me uncomfortable is having to run through iterators/FindVisitors twice. Any suggestions for improvement are welcome. Sight unseen - instead of counting in the visitor and iterators, push all the script details (and package references if appropriate) onto a list or vector first time through. Then, simply walk the list. Rob I've give a fuller review later. However: This code can be simplified: 1) iterate over the dependency ordered packages and push all their scripts into the 'to be run' collection. Save the current count of scripts. 2) iterate over the files in the directory. 3) subtract the count in 1) from the now total to get the total scripts to be run. 3a) optional: iterate forward through the scripts vector and remove any duplicates. There may even be an stl order preserving call to do this (removing the duplicates from pos-end()). 4) iterate through the scripts and run them. 3a) is optional because we don't error on missing scripts IIRC. Rob, I wanted (and still want) to keep the two bar progress on this. The second bar would show progress through packages, and the first - progress through the scripts *in the current package*. Alteratively/also you could extract the script running and screen updating code to a new method. Rob Done. I've also done some restructuring of the Script class and enabled the #if 0'd code from the previous patch, now that the progress bars exist. I've attached the next iteration. Should apply cleanly to HEAD. Igor == ChangeLog: 2003-03-24 Igor Pechtchanski [EMAIL PROTECTED] * threebar.h (WM_APP_START_POSTINSTALL): New message. (WM_APP_POSTINSTALL_THREAD_COMPLETE): New message. * threebar.cc (ThreeBarProgressPage::OnMessageApp): Add handling for WM_APP_START_POSTINSTALL and WM_APP_POSTINSTALL_THREAD_COMPLETE. * install.cc (do_install_thread): Set next_dialog to IDD_S_POSTINSTALL. * desktop.cc (DesktopSetupPage::OnFinish): Move the do_postinstall call to ThreeBarProgressPage::OnMessageApp. * script.h (Script::fullName): New member function. (Script::run): New member function. * script.cc (Script::fullName): Implement. (Script::run): Implement. (run): Enable #if 0'd code. * postinstall.cc (Progress): New extern variable. (RunFindVisitor::visitFile): Add script to vector instead of running. (RunFindVisitor::_scripts): New member variable. (run_package_scripts): New static function. (do_postinstall_thread): Rename do_postinstall to. Add Progress bar and text setting. Add package count. (do_postinstall_reflector): New static function. (do_postinstall): Rename to do_postinstall_thread. Create a thread instead. -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune Index: desktop.cc === RCS file: /cvs/cygwin-apps/setup/desktop.cc,v retrieving revision 2.34 diff -u -p -r2.34 desktop.cc --- desktop.cc 25 Nov 2002 22:12:08 - 2.34 +++ desktop.cc 24 Mar 2003 22:04:08 - @@ -397,8 +397,6 @@ DesktopSetupPage::OnFinish () HWND h = GetHWND (); save_dialog (h); do_desktop_setup (); - NEXT (IDD_S_POSTINSTALL); - do_postinstall (GetInstance (), h); return true; } Index: install.cc === RCS file: /cvs/cygwin-apps/setup/install.cc,v retrieving revision 2.60 diff -u -p -r2.60 install.cc --- install.cc 17 Mar 2003 22:23:33 - 2.60 +++ install.cc 24 Mar 2003 22:04:08 - @@ -455,7 +455,7 @@ do_install_thread (HINSTANCE h, HWND own num_installs = 0, num_uninstalls = 0, num_replacements = 0; rebootneeded = false; - next_dialog = IDD_DESKTOP; + next_dialog = IDD_S_POSTINSTALL; io_stream::mkpath_p (PATH_TO_DIR, String (file://) + get_root_dir ()); Index: postinstall.cc === RCS file: /cvs/cygwin-apps/setup/postinstall.cc,v retrieving revision 2.12 diff -u -p -r2.12 postinstall.cc --- postinstall.cc 20 Mar 2003 10:02:51 - 2.12 +++ postinstall.cc
Re: [PATCH] Run postinstall scripts in a thread with progress bars- take 3
On Tue, 2003-03-25 at 09:48, Igor Pechtchanski wrote: On 21 Mar 2003, Robert Collins wrote: Rob, I wanted (and still want) to keep the two bar progress on this. The second bar would show progress through packages, and the first - progress through the scripts *in the current package*. Ok. I don't really see the end-user benefit, but don't object either. Alteratively/also you could extract the script running and screen updating code to a new method. Rob Done. I've also done some restructuring of the Script class and enabled the #if 0'd code from the previous patch, now that the progress bars exist. I've attached the next iteration. Should apply cleanly to HEAD. Igor == ChangeLog: 2003-03-24 Igor Pechtchanski [EMAIL PROTECTED] * threebar.h (WM_APP_START_POSTINSTALL): New message. (WM_APP_POSTINSTALL_THREAD_COMPLETE): New message. * threebar.cc (ThreeBarProgressPage::OnMessageApp): Add handling for WM_APP_START_POSTINSTALL and WM_APP_POSTINSTALL_THREAD_COMPLETE. * install.cc (do_install_thread): Set next_dialog to IDD_S_POSTINSTALL. * desktop.cc (DesktopSetupPage::OnFinish): Move the do_postinstall call to ThreeBarProgressPage::OnMessageApp. * script.h (Script::fullName): New member function. (Script::run): New member function. * script.cc (Script::fullName): Implement. (Script::run): Implement. (run): Enable #if 0'd code. * postinstall.cc (Progress): New extern variable. (RunFindVisitor::visitFile): Add script to vector instead of running. (RunFindVisitor::_scripts): New member variable. (run_package_scripts): New static function. (do_postinstall_thread): Rename do_postinstall to. Add Progress bar and text setting. Add package count. (do_postinstall_reflector): New static function. (do_postinstall): Rename to do_postinstall_thread. Create a thread instead. etc_postinstall should be: 1) a static public const member of Script. 2) called ETCPostinstall. (Leading capital for statics). 3) reused in RunFindVisitor. run_package_scripts cries our for a helper class IMO. i.e. ScriptRunner with a) constructor b) destructor c) run(std::vectorScript const ) method. d) operator () (Script const aScript) method. this: for (std::vectorScript::iterator script = scripts.begin(); + script != scripts.end(); + ++script) then becomes *this = for_each (scripts.begin(), scripts.end(), *this); This is looking very good, and nearly ready to apply. Cheers, Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [PATCH] Run postinstall scripts in a thread with progress bars - take 3
On 25 Mar 2003, Robert Collins wrote: On Tue, [EMAIL PROTECTED]:48, Igor Pechtchanski wrote: On 21 Mar 2003, Robert Collins wrote: Rob, I wanted (and still want) to keep the two bar progress on this. The second bar would show progress through packages, and the first - progress through the scripts *in the current package*. Ok. I don't really see the end-user benefit, but don't object either. Alteratively/also you could extract the script running and screen updating code to a new method. Rob Done. I've also done some restructuring of the Script class and enabled the #if 0'd code from the previous patch, now that the progress bars exist. I've attached the next iteration. Should apply cleanly to HEAD. Igor == ChangeLog: 2003-03-24 Igor Pechtchanski [EMAIL PROTECTED] * threebar.h (WM_APP_START_POSTINSTALL): New message. (WM_APP_POSTINSTALL_THREAD_COMPLETE): New message. * threebar.cc (ThreeBarProgressPage::OnMessageApp): Add handling for WM_APP_START_POSTINSTALL and WM_APP_POSTINSTALL_THREAD_COMPLETE. * install.cc (do_install_thread): Set next_dialog to IDD_S_POSTINSTALL. * desktop.cc (DesktopSetupPage::OnFinish): Move the do_postinstall call to ThreeBarProgressPage::OnMessageApp. * script.h (Script::fullName): New member function. (Script::run): New member function. * script.cc (Script::fullName): Implement. (Script::run): Implement. (run): Enable #if 0'd code. * postinstall.cc (Progress): New extern variable. (RunFindVisitor::visitFile): Add script to vector instead of running. (RunFindVisitor::_scripts): New member variable. (run_package_scripts): New static function. (do_postinstall_thread): Rename do_postinstall to. Add Progress bar and text setting. Add package count. (do_postinstall_reflector): New static function. (do_postinstall): Rename to do_postinstall_thread. Create a thread instead. etc_postinstall should be: 1) a static public const member of Script. 2) called ETCPostinstall. (Leading capital for statics). Agreed. Will do. 3) reused in RunFindVisitor. No. In fact, the code currently in RunFindVisitor is broken and will not work if there are subdirectories under /etc/postinstall. What I would like to do (in a separate patch) is change FindVisitor so that basePath is the POSIX path, rather than the Windows one. We can then simply concatenate the filename to it and use that. run_package_scripts cries our for a helper class IMO. i.e. ScriptRunner with a) constructor b) destructor c) run(std::vectorScript const ) method. d) operator () (Script const aScript) method. I don't see the benefit of run(); it'll be subsumed by operator(), IMO. Otherwise, I'll give it a shot. this: for (std::vectorScript::iterator script = scripts.begin(); + script != scripts.end(); + ++script) then becomes *this = for_each (scripts.begin(), scripts.end(), *this); We could probably just lose the return value... This is looking very good, and nearly ready to apply. Cheers, Rob Thanks, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
Re: [PATCH] Run postinstall scripts in a thread with progress bars - take 3
On 25 Mar 2003, Robert Collins wrote: On Tue, 2003-03-25 at 11:00, Igor Pechtchanski wrote: 3) reused in RunFindVisitor. No. In fact, the code currently in RunFindVisitor is broken and will not work if there are subdirectories under /etc/postinstall. What I would like to do (in a separate patch) is change FindVisitor so that basePath is the POSIX path, rather than the Windows one. We can then simply concatenate the filename to it and use that. Ok. There aren't allowed to directories under /etc/postinstall BTW. IMO it's much neater to just be able to use the basePath. I don't think basePath is even used now. This would make the Find/FindVisitor more generic. run_package_scripts cries our for a helper class IMO. i.e. ScriptRunner with a) constructor b) destructor c) run(std::vectorScript const ) method. d) operator () (Script const aScript) method. I don't see the benefit of run(); it'll be subsumed by operator(), IMO. Otherwise, I'll give it a shot. well, you'll have one instance of ScriptRunner for both the dependency order package scripts, and the found-by-filename scripts. If you have pre-running-a-vector or post-running-a-vector code, then that belongs in run(). If that code goes into the constructor, then sure, eliminate run(). Yep, I think the pre-post vector code could go into the constructor/destructor. this: for (std::vectorScript::iterator script = scripts.begin(); + script != scripts.end(); + ++script) then becomes *this = for_each (scripts.begin(), scripts.end(), *this); We could probably just lose the return value... Check the template, IIRC it takes a copy of the object, calls the copy's operator (), then returns a copy of the copy. i.e. if we want failure stats, script run counts etc, we need the return value. Rob Yes, but we don't keep failure stats. If we ever decide to, we can easily capture the return value later. I'm pretty sure we can ignore it for now. Thanks for the feedback. I'll send the next iteration soon. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
Re: [PATCH] Run postinstall scripts in a thread with progress bars - take 3
On Mon, 24 Mar 2003, Igor Pechtchanski wrote: On 25 Mar 2003, Robert Collins wrote: On Tue, 2003-03-25 at 11:00, Igor Pechtchanski wrote: run_package_scripts cries our for a helper class IMO. i.e. ScriptRunner with a) constructor b) destructor c) run(std::vectorScript const ) method. d) operator () (Script const aScript) method. I don't see the benefit of run(); it'll be subsumed by operator(), IMO. Otherwise, I'll give it a shot. well, you'll have one instance of ScriptRunner for both the dependency order package scripts, and the found-by-filename scripts. If you have pre-running-a-vector or post-running-a-vector code, then that belongs in run(). If that code goes into the constructor, then sure, eliminate run(). Yep, I think the pre-post vector code could go into the constructor/destructor. this: for (std::vectorScript::iterator script = scripts.begin(); + script != scripts.end(); + ++script) then becomes *this = for_each (scripts.begin(), scripts.end(), *this); We could probably just lose the return value... Check the template, IIRC it takes a copy of the object, calls the copy's operator (), then returns a copy of the copy. i.e. if we want failure stats, script run counts etc, we need the return value. Rob Yes, but we don't keep failure stats. If we ever decide to, we can easily capture the return value later. I'm pretty sure we can ignore it for now. Thanks for the feedback. I'll send the next iteration soon. Igor ...and here it is. Attached. Igor == ChangeLog: 2003-03-24 Igor Pechtchanski [EMAIL PROTECTED] * threebar.h (WM_APP_START_POSTINSTALL): New message. (WM_APP_POSTINSTALL_THREAD_COMPLETE): New message. * threebar.cc (ThreeBarProgressPage::OnMessageApp): Add handling for WM_APP_START_POSTINSTALL and WM_APP_POSTINSTALL_THREAD_COMPLETE. * install.cc (do_install_thread): Set next_dialog to IDD_S_POSTINSTALL. * desktop.cc (DesktopSetupPage::OnFinish): Move the do_postinstall call to ThreeBarProgressPage::OnMessageApp. * script.h (Script::fullName): New member function. (Script::run): New member function. (Script::ETCPostinstall): New static member constant. * script.cc (Script::fullName): Implement. (Script::run): Implement. (Script::ETCPostinstall): Define. (Script::isAScript): Use ETCPostinstall instead of a hardcoded string constant. (run): Enable #if 0'd code. * postinstall.cc (Progress): New extern variable. (RunFindVisitor::visitFile): Add script to vector instead of running. (RunFindVisitor::_scripts): New member variable. (RunScript): New helper class for use in for_each. (do_postinstall_thread): Rename do_postinstall to. Add Progress bar and text setting. Add package count. (do_postinstall_reflector): New static function. (do_postinstall): Rename to do_postinstall_thread. Create a thread instead. -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune Index: desktop.cc === RCS file: /cvs/cygwin-apps/setup/desktop.cc,v retrieving revision 2.34 diff -u -p -r2.34 desktop.cc --- desktop.cc 25 Nov 2002 22:12:08 - 2.34 +++ desktop.cc 25 Mar 2003 01:24:28 - @@ -397,8 +397,6 @@ DesktopSetupPage::OnFinish () HWND h = GetHWND (); save_dialog (h); do_desktop_setup (); - NEXT (IDD_S_POSTINSTALL); - do_postinstall (GetInstance (), h); return true; } Index: install.cc === RCS file: /cvs/cygwin-apps/setup/install.cc,v retrieving revision 2.60 diff -u -p -r2.60 install.cc --- install.cc 17 Mar 2003 22:23:33 - 2.60 +++ install.cc 25 Mar 2003 01:24:28 - @@ -455,7 +455,7 @@ do_install_thread (HINSTANCE h, HWND own num_installs = 0, num_uninstalls = 0, num_replacements = 0; rebootneeded = false; - next_dialog = IDD_DESKTOP; + next_dialog = IDD_S_POSTINSTALL; io_stream::mkpath_p (PATH_TO_DIR, String (file://) + get_root_dir ()); Index: postinstall.cc === RCS file: /cvs/cygwin-apps/setup/postinstall.cc,v retrieving revision 2.12 diff -u -p -r2.12 postinstall.cc --- postinstall.cc 20 Mar 2003 10:02:51 - 2.12 +++ postinstall.cc 25 Mar 2003 01:24:28 - @@
Re: vnc-3.3.7 with cygwin
On Mon, 24 Mar 2003, roland wrote: c++ -O2 -Wall -L/usr/X11R6/lib -o vncviewer argsresources.o colour.o desktop.o dialogs.o fullscreen.o listen.o misc.o popup.o rfbproto.o selection.o shm.o vncv iewer.o sockets.o zrle.o buildtime.o ../rfb/librfb.a ../rdr/librdr.a ../zlib/li bz.a -lXmu -lXaw -lXt -lX11 -lXext /usr/X11R6/lib/libXaw.a(Form.o)(.text+0x45f):Form.c: undefined reference to `_Xm uNewCvtStringToWidget' /usr/X11R6/lib/libXaw.a(Form.o)(.text+0x481):Form.c: undefined reference to `_Xm uCvtWidgetToString' /usr/X11R6/lib/libXaw.a(Toggle.o)(.text+0xc7):Toggle.c: undefined reference to This seems to be a problem with the order of libraries. Try -lXaw -lXmu -lXt bye ago
RE: two new -multiwindow bugs
Jack,
Which of your monitors is the primary? I'm guessing it is the right hand one
(note that monitor 1 is not necessarily the primary, you have the choice).
If you set the primary monitor to be the left hand one then the xterm will
appear on the same monitor for both cases below.
If it really matters to you then I could have a look at the code.
Regards,
Nick
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jack Tanner
Sent: 17 March 2003 23:11
To: [EMAIL PROTECTED]
Subject: two new -multiwindow bugs
(By new, I mean not discussed here before, not new as in only present in
the most recent release.)
Thank you for your time and effort, Kensuke, Harold, et. al.
I have two monitors, monitor 2 is physically left of monitor 1.
XFree86-xserv 4.2.0-28.
0) the repeated keystrokes bug is still present in this release
http://www.cygwin.com/ml/cygwin-xfree/2003-03/msg00059.html
1) window positioning bug
# Xwin -rootless -multiplemonitors -clipboard
# xterm -geometry +34+5
The xterm is positioned in the upper left-hand corner of monitor 2.
# Xwin -multiwindow -multiplemonitors -clipboard
# xterm -geometry +34+5
The xterm is positioned in the upper left-hand corner of monitor 1.
Presumably, the xterm should get positioned on the same monitor regardless
whether I use -rootless or -multiwindow.
2) window title bug
# Xwin -rootless -multiplemonitors -clipboard
# xterm -geometry +34+5
# TERM=xterm; export TERM
# xterm -e bash -i -c ssh -X [EMAIL PROTECTED]
The xterm window gets a title like [EMAIL PROTECTED]:~. This is very pretty and
very useful when you open a gazillion xterms, like I do. (The remote machine
has an /etc/bashrc that sets up $PROMPT_COMMAND appropriately. For my stock
RedHat 8 install, it's PROMPT_COMMAND='echo -ne
\033]0;[EMAIL PROTECTED]:${PWD/#$HOME/~}\007'.)
# Xwin -multiwindow -multiplemonitors -clipboard
[snip. same xterm, TERM and ssh setup as above, but note -multiwindow, not
-rootless Xwin invocation]
The xterm window gets the title bash. Awful, boring title.
Best,
JT
_
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
_
This e-mail has been scanned for viruses by the WorldCom Internet Managed
Scanning Service - powered by MessageLabs. For further information visit
http://www.worldcom.com
Re: remote X to SUN box
Hi, I tried both commands, still no luck. This time nothing happen. What am I missing here? Last time I tried at least I got to hourglass. Anybody care to help me, please? Thank you. regards, feroz --- Rasjid Wilcox [EMAIL PROTECTED] wrote: On Sun, 23 Mar 2003 08:48 pm, Feroz F. Basir wrote: Hi all, I'm new to cygwin. I downloaded to do remote X to my SUN box. I already read the FAQ section about SUN box issue with xfree. I ran these 2 commands but still got hourglass, no login prompt. Command as follow: xwin -query sun_ip from client_ip Is that just a typo? You need the bash before the from. ie, -from. xwin -query sun_ip -fp tcp/sun_ip:7100 I've never connected to a Sun box, but have you tried all three parameters? xwin -query sun_ip -fp tcp/sun_ip:7100 -from client_ip It would seem likely that all three are required. Rasjid. __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
using cygpath for setting $HOME in multiuser and multicomputer environment
Hi, since I plan to distribute LyX in my universitiy's department I have to consider a very inhomogenous computer environment, ranging from PCs with network, without, from Win9x to XP, with homedirs on servers, to what-ever-you-want. I want to set $HOME to the value stored in \HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\AppData my /etc/profile looks this way: snipp PATH=/usr/local/bin:/usr/bin:/bin:$PATH USER=`id -un` # Set up USER's home directory # if [ -z $HOME ]; then # HOME=/home/$USER # fi APPDATA=`regtool get \HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\AppData` FOO=`cygpath -ws $APPDATA` HOME=`cygpath -u $FOO` if [ ! -d $HOME ]; then mkdir -p $HOME fi export HOME USER for i in /etc/profile.d/*.sh ; do if [ -f $i ]; then . $i fi done export MAKE_MODE=unix export PS1='\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' cd $HOME snapp starting bash (cygwin.bat) with user Admin on SCHIEBELER1 cygwin sets $HOME correctly to /cygdrive/f/DOKUME~1/ADMIN~1.SCH/ANWEND~1 To tart LyX I used the provided startlyx.bat snipp @echo off SET DISPLAY=127.0.0.1:0.0 SET CYGWIN_ROOT=E:\Programme\office\cygwin SET PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH% if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix if %OS% == Windows_NT goto USE-B-SWITCH echo startxwin.bat - Starting on Windows 95/98/Me start XWin run xterm -sl 1000 -sb -rightbar -ms red -fg yellow -bg black -e /usr/bin/bash run twm goto END :USE-B-SWITCH echo startlyx.bat - Starting LyX on Windows NT/2000 start XWin -screen 0 1250 940 run twm run lyxwin32.exe -geometry 1250x900+0+0 %1 %2 %3 %4 %5 :END run xsetroot -solid aquamarine4 snapp if I do so unfortunately nothing appears except an empty anquamarine-colored Cygwin/Xfree86 rl window. if I click and start an xterm, HOME is set to /home/Admin (which doesn't exist) and ps shows a cygpath process. After killing that process there is one bash process more than before and another cygpath process running - killing that LyX starts but without a proper set $HOME. Can enyone point me to my mistake? regards Stefan -- +++ GMX - Mail, Messaging more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
Is there an XFree86-bin source package?
Is there an XFree86-bin source package, like for the other packages of the Cygwin's disribution? or are sources only available through CVS? I ask 'cause I tried with setup to download the sources of that package through half a dozen mirrors, and each time the sources where marked as n/a. André Bleau, Cygwin's OpenGL package maintainer. email: bleau at igb dot umontreal dot ca (Fight SPAM: encode your email-address) Please address all questions and problem reports about Cygwin's OpenGL package to [EMAIL PROTECTED] .
Re: Is there an XFree86-bin source package?
Nope, no such package. Harold Andre Bleau wrote: Is there an XFree86-bin source package, like for the other packages of the Cygwin's disribution? or are sources only available through CVS? I ask 'cause I tried with setup to download the sources of that package through half a dozen mirrors, and each time the sources where marked as n/a. André Bleau, Cygwin's OpenGL package maintainer. email: bleau at igb dot umontreal dot ca (Fight SPAM: encode your email-address) Please address all questions and problem reports about Cygwin's OpenGL package to [EMAIL PROTECTED] .
Re: using cygpath for setting $HOME in multiuser and multicomputer environment
On Mon, 24 Mar 2003, Stefan Schiebeler wrote: Hi, since I plan to distribute LyX in my universitiy's department I have to consider a very inhomogenous computer environment, ranging from PCs with network, without, from Win9x to XP, with homedirs on servers, to what-ever-you-want. I want to set $HOME to the value stored in \HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\AppData my /etc/profile looks this way: snipp PATH=/usr/local/bin:/usr/bin:/bin:$PATH USER=`id -un` # Set up USER's home directory # if [ -z $HOME ]; then # HOME=/home/$USER # fi APPDATA=`regtool get \HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\AppData` FOO=`cygpath -ws $APPDATA` HOME=`cygpath -u $FOO` if [ ! -d $HOME ]; then mkdir -p $HOME fi export HOME USER for i in /etc/profile.d/*.sh ; do if [ -f $i ]; then . $i fi done export MAKE_MODE=unix export PS1='\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' cd $HOME snapp starting bash (cygwin.bat) with user Admin on SCHIEBELER1 cygwin sets $HOME correctly to /cygdrive/f/DOKUME~1/ADMIN~1.SCH/ANWEND~1 To tart LyX I used the provided startlyx.bat snipp @echo off SET DISPLAY=127.0.0.1:0.0 SET CYGWIN_ROOT=E:\Programme\office\cygwin SET PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH% if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix if %OS% == Windows_NT goto USE-B-SWITCH echo startxwin.bat - Starting on Windows 95/98/Me start XWin run xterm -sl 1000 -sb -rightbar -ms red -fg yellow -bg black -e /usr/bin/bash run twm goto END :USE-B-SWITCH echo startlyx.bat - Starting LyX on Windows NT/2000 start XWin -screen 0 1250 940 run twm run lyxwin32.exe -geometry 1250x900+0+0 %1 %2 %3 %4 %5 :END run xsetroot -solid aquamarine4 snapp if I do so unfortunately nothing appears except an empty anquamarine-colored Cygwin/Xfree86 rl window. if I click and start an xterm, HOME is set to /home/Admin (which doesn't exist) and ps shows a cygpath process. After killing that process there is one bash process more than before and another cygpath process running - killing that LyX starts but without a proper set $HOME. Can enyone point me to my mistake? regards Stefan Stefan, Any particular reason you use the -s option to cygpath? The following should work (quoting adjusted as well): APPDATA=`regtool get '\HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\AppData'` HOME=`cygpath -u $APPDATA` Also be aware that bash doesn't read /etc/profile unless it's a login shell (i.e., has the --login option). You can also pass the -ls option to the xterm for that effect. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune
winsup/utils ChangeLog cygcheck.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2003-03-25 01:20:04 Modified files: utils : ChangeLog cygcheck.cc Log message: * cygcheck.cc (dump_sysinfo): Ensure that CYGWIN environment variable is correctly set. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/utils/ChangeLog.diff?cvsroot=uberbaumr1=1.203r2=1.204 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/utils/cygcheck.cc.diff?cvsroot=uberbaumr1=1.32r2=1.33
help!!
Hello, I would like to make you a question:
I'm trying to call to java code from C++ code, so I
have just do it for linux with gcc using gcj and gcjh.
Now, I have been trying the same for Windows 2000,
following these steps:
1.- Write the java file -- prueba_java.java
2.- Compile it with javac -- javac prueba_java.java
3.- Create the header file -- gcjh prueba_java
4.- Create the .o file --
gcj gcj -c -g -O prueba_java.java
5.- Write the C++ file, from which I call the java
code -- main.cc
6.- Compile it -- gcc -c -I /MinGW/include main.cc
7.- Linking with java code --
gcc -static main.o prueba_java.o -o ejecutable -L
-L/MinGW/lib -lgcj -lmingw32 -lwsock32
And when I try to execute the executable file (
ejecutable ), but it dies with an abnormal program
termination, because of the following error:
Program received signal SIGSEGV, Segmentation fault.
0x78002320 in _libwsock32_a_iname ()
(gdb) where
#0 0x78002320 in _libwsock32_a_iname ()
#1 0x0043f966 in
java::lang::System::init_properties() ()
#2 0x00413335 in
java::lang::System::getProperty(java::lang::String*)
()
#3 0x00458caa in
java::util::TimeZone::__U3c_clinit__U3e_() ()
#4 0x0040530f in java::lang::Class::initializeClass()
()
#5 0x004d671c in _Jv_InitClass () at {standard
input}:205
#6 0x004543f6 in
java::util::TimeZone::getTimeZone(java::lang::String*)
()
#7 0x00412f79 in
java::lang::System::getDefaultTimeZoneId() ()
#8 0x0043f7ed in
java::lang::System::init_properties() ()
#9 0x00413335 in
java::lang::System::getProperty(java::lang::String*)
()
#10 0x004602b1 in
java::io::PrintStream::__U3c_clinit__U3e_() ()
#11 0x0040530f in java::lang::Class::initializeClass()
()
#12 0x00402c31 in _Jv_AllocObjectNoFinalizer ()
#13 0x004136e7 in
java::lang::System::__U3c_clinit__U3e_() ()
#14 0x0040530f in java::lang::Class::initializeClass()
()
#15 0x004d671c in _Jv_InitClass () at {standard
input}:205
#16 0x004133e0 in
java::lang::System::getSecurityManager() ()
#17 0x0040c81a in java::lang::Thread::checkAccess() ()
#18 0x0040ca24 in java::lang::Thread::setDaemon(bool)
()
#19 0x004127a2 in
gnu::gcj::runtime::FinalizerThread::FinalizerThread()
()
#20 0x0040396f in _Jv_CreateJavaVM(void*) ()
#21 0x004d674d in JvCreateJavaVM(void*) () at
{standard input}:205
#22 0x004012b7 in main ()
I would like you to tell me how to solve this problem,
if it's possible..
Thank you very much for your attention..
___
Yahoo! Messenger - Nueva versión GRATIS
Super Webcam, voz, caritas animadas, y más...
http://messenger.yahoo.es
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Starting .exe: DOS prompt OK, double-click not
On Sat, 22 Mar 2003, Kodaj Bence wrote: [sbip] (The actual Tcl/Tk installation on my machine is ActiveTcl 8.4., but that's not really important.) Windows doesn't understand POSIX paths.. Now, when I double-click on OurApp.exe in Windows Explorer, I get the following error message from wish: Error in startup script couldn't read file /cygdrive/c/OurAppFolder/OurScript.tcl: no such file or directory ^^ This is a POSIX path. You can translate it to a Windows path using the Cygwin API call cygwin_conv_to_win32_path See http://cygwin.com/cygwin-api/func-cygwin-conv-to-win32-path.html for details HTH rlc -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Possible GPL violation.
Hi Robert, On Mon, Mar 24, 2003 at 11:40:25AM +0800, Robert Biuk-Aghai wrote: Is my reading of the GPL, term 3, correct in that I need to download the sources of all packages included in the binary archive file I prepared, and place them on the same web server as the binary archive file itself? Or would it suffice if I provided a link to the nearest ftp site from where the sources can be downloaded? your reading was perfectly fine. It's not sufficient to provide a link, you have to provide the sources on the same server. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Linking VC++ DLL
Hi,
I have already compiled and linked the following function
extern C __declspec(dllexport) int hello()
{
printf(Hello World!\n);
return 345;
}
in a VC++ DLL.
I have also successfully linked and created the import library in Cygwin,
libhallo.a
However,
when I compile and run the following code
using
gcc hello.c -lhallo
extern int hello();
int main()
{
printf(What is this? %d\n, hello());
}
All I get in return is (under Cygwin):
What is this? 345
345 demonstrates that the function was called and correctly returned but
why is it that the printf statement in the function hello() went missing?
I have tried to run other VC compiled program but had no problem in
getting printf statements to work under the Cygwin environment. Would
appreciate if anyone can suggest what could be the possible
problem. Thanks!
regards
Edward
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Possible GPL violation.
Hi Corinna, Ok, I'll make the sources available on our web server before I put the binary archive online again. By that time I'll send you a message so that you can visit my download page and confirm that things are done in the proper way. This will probably only be in September when I next teach my C programming course and when I will prepare a new binary archive of the relevant part of Cygwin. Robert. On Mon, 24 Mar 2003, Corinna Vinschen wrote: Hi Robert, On Mon, Mar 24, 2003 at 11:40:25AM +0800, Robert Biuk-Aghai wrote: Is my reading of the GPL, term 3, correct in that I need to download the sources of all packages included in the binary archive file I prepared, and place them on the same web server as the binary archive file itself? Or would it suffice if I provided a link to the nearest ftp site from where the sources can be downloaded? your reading was perfectly fine. It's not sufficient to provide a link, you have to provide the sources on the same server. Corinna -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Emacs, adding PHP as major mode
What about adding PHP as major mode in emacs in the autoinstall and download of files? Here is a link to the php-mode site: http://php-mode.sourceforge.net http://php-mode.sourceforge.net /Klaus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Emacs, adding PHP as major mode
On Mon, 2003-03-24 at 22:40, Klaus Friis Østergaard wrote: What about adding PHP as major mode in emacs in the autoinstall and download of files? You could always package up the php mode and have that depend on emacs. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1
Hi Jeff, I'm waiting already for more than a month for this to happen. Needless to say, I'm pretty frustrated. But despite Robert claiming to take care of this in his initial response you cited below, no update was ever published. All further inquiries were silently ignored. The interpretation of this behaviour and consequences are up to you. Right now, Cygwin is not usable for XML editing. I recommend switching over to some other *nix and a VM. Alternatively you can use the Windows ports of the xml libaries provided by Igor Zlatkovic. His ports are always up to date: http://www.zlatkovic.com/projects/libxml/index.html Disappointed, Patrick Robert Collins said on 19 Feb 2003 07:57:58 +1100: Yes, and this takes the current version from 'old' to 'old + buggy'. I've upped my priority to get a new release out. Uhmm, end of the week should do it. Please, could we/you somehow get xsltproc associated libs in the cygwin installation repository brought up-to-date? I'm trying to use xsltproc with some docbook stuff (we're using docbook to write the next phase of ProjectLiberty specs, and I use cygwin as my *nix environment), and said docbook stuff uses xinclude. The old xsltproc et al included (still) in the cygwin install (I updated this morning) barfs on the xinclude stuff, plus it doesn't properly handle (eg skip over) included mediaobjects (eg EPS). The latest version of xsltproc et al (the various *xml* libs) handles both of these just fine. thanks, JeffH -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1
On Mon, 2003-03-24 at 23:15, Patrick Eisenacher wrote: Hi Jeff, I'm waiting already for more than a month for this to happen. Needless to say, I'm pretty frustrated. But despite Robert claiming to take care of this in his initial response you cited below, no update was ever published. All further inquiries were silently ignored. The interpretation of this behaviour and consequences are up to you. Right now, Cygwin is not usable for XML editing. I recommend switching over to some other *nix and a VM. Alternatively you can use the Windows ports of the xml libaries provided by Igor Zlatkovic. His ports are always up to date: http://www.zlatkovic.com/projects/libxml/index.html Disappointed, Patrick Hi Patrick, you're absolutely right. I hereby put the libxslt and libxml packages up as orphans. I won't be updating them - period. According to cygwin policy, if no new maintainer steps up in the near future, these packages will get pulled... Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
Re: apropos, man -k, and makewhatis
[EMAIL PROTECTED] wrote: Sounds like a combination of your path pointing to Windows directories first (i.e. you have the Windows FIND.EXE) and FAQ entry: Why doesn't man (or apropos) work? http://cygwin.com/faq/faq_4.html#SEC43 Does that clear up the problem? Yes, thank you! It was indeed the path. -- Mike Maxwell Linguistic Data Consortium [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
System load question
Hello, everybody, I have seen that since a couple of months the /proc directory is present, an with it some stats, esp. loadavg. Does the loadavg work however ? If I cat /proc/loadavg then the numbers are always 0.00 0.00 0.00, even though I have a fair number of jobs running every five minutes or every quarter of an hour. Jurgen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
tar file size limitation
Hi, I'm trying to put on a tape a 16 GB file with Cygwin tar on W2K. A tar -cvf gives the hand after 2 seconds, and when I try to read the tape, tar -tvf produces the following error: tar: Archive value -55607296 is out of off_t range 0..2147483647 Is there a file size limitation with tar usage ? The problem is the same from disk to tape and from disk to disk. I've seen few questions about tar limitations in the Cygwin mailing list, but no answer. Can you help me? Regards, Pierre GREGORESKI Ingénieur Avant Vente Hi-Stor Technologies Tel: 05.62.12.14.59 Fax: 05.62.12.14.49 Email: [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Starting .exe: DOS prompt OK, double-click not
/cygdrive/c/OurAppFolder/OurScript.tcl: no such file or directory ^^ This is a POSIX path. You can translate it to a Windows path using the Cygwin API call cygwin_conv_to_win32_path Thanks for the tip, but I'm not sure this is the solution. There's a point that I might not have made clear enough in my previous posting: = Everything's fine when I start OurApp.exe from a DOS prompt. = Now, OurApp.exe invokes wish like this: execlp( wish, wish, ./OurScript.tcl , ...); My question is: why does this call work in the DOS-prompt mode, and why doesn't it work in double-click mode? Let me emphasize again that wish is invoked _in the same way_ in both cases. Bence Kodaj -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Added setup.exe to User's Guide
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Joshua Daniel Franklin On Sun, Mar 23, 2003 at 08:54:11PM +0100, Hannu E K Nevalainen (garbage mail) wrote: Suggestions for wording changes/expansion of the text. I believe most of your suggestions assume that the user has little or no knowledge of Unix. I'm operating under the assumption that most new users have knowledge of Unix and will already have run into things like \r\n line endings, man, info, etc. IMHO my suggestions adds just that *tiny bit* of extra info that makes a new user get the grip - without some of the FAQs. -- 8 -- Local Package Directory Append something like the following to the paragraph: There are circumstances when it is useful to use the cache as local package directory for installation on another system than the primary one. This is currently NOT directly supported by setup.exe, but can be achieved in a number of ways. Information regarding this has yet to be gathered here. Currently it is spread out amongst the postings on the mailing lists, especially the cygwin list. Huh? Hmm...? Why so perplexed? I've gotten the impression that this isn't easily accomplished. Install Cygwin on one machine. Copy the cache to a separate machine. Install again. This will work fine, as long as you choose the same mirror. First of all; those two lines belong on the web-page. Second; setup.exe does not cover all situations. Third; It involves loads of manual work, on more than a few machines. Fourth; using a LAN - high load when all machines has to be updated. This has been discussed throughly here on the ML. With a slant towards the second; IMHO this needs to be mentioned, toghether with some kind of pointers to the postings - unless it can be summarised directly. I'm asking myself: Why do people insist on not telling about the possible ways to achieve this? IMHO this is like somebody telling you that there is no such thing as free speech unless you pay the license fee (Here: the bill for having high speed Internet). Simply put: _irritating_ ;-} . Arguments follow, feel free to skip to next comment. My experience of - downloading MOST of the packages, - creating a CDR of the cache - and running setup.exe on it at home has learnt me that it really isn't that easy in every situation. The basis of it - is here: - It isn't that fun to download all of cygwin over 128k/ISDN (or slower), you really need something faster than that. - Not everybody has ADSL++/flat rate/eons of time for plain downloads. - Please, also note: We have to pay in proportion to time, for beeing online, over here. This escalates into unbearable bills very soon. Example of the last: With minimal Internet online-time I have to pay more than $100/month currently. I have no intention to increase the amount on those bills e.g. by downloading the entire cygwin. To what sort of information are you referring? All the postings on the cygwin ML about installing without setup.exe, creating CDR-copies of the cache _to be used as install-source_ and so on. Am I that unclear in style of writing? I find it alarming. s /Hannu E K Nevalainen, Mariefred, Sweden --END OF MESSAGE-- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Linking VC++ DLL
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
--8--
extern C __declspec(dllexport) int hello()
{
printf(Hello World!\n);
return 345;
}
--8--
int main()
{
printf(What is this? %d\n, hello());
}
All I get in return is (under Cygwin):
What is this? 345
345 demonstrates that the function was called and correctly returned but
why is it that the printf statement in the function hello() went missing?
I have tried to run other VC compiled program but had no problem in
getting printf statements to work under the Cygwin environment. Would
appreciate if anyone can suggest what could be the possible
problem. Thanks!
regards
Edward
I believe this is close to off topic on the cygwin list. ;-)
My guess is that stdin/stdout from main() isn't defined/visible for the
functions inside your library.
To illustrate the problem; Try this:
--8--
extern C __declspec(dllexport) int hello(FILE *of)
{
fprintf(of,Hello World!\n);
return 345;
}
--8--
int main()
{
printf(What is this? %d\n, hello(stdout));
}
--8--
... which MIGHT work.
Expect something like:
Hello World!
What is this? 345
as output.
You may have a problem here:
I believe you have to think about which version of printf() you wish to
have available in your library and/or program.
Your library might contain *a copy of printf()*, I'm not sure it will be
sufficient for all situations. Especially as it seems as you're using two
different compilers/environments to compile your library and program.
If so; IMHO there is great potential for serious malfunction.
/Hannu E K Nevalainen, Mariefred, Sweden
--END OF MESSAGE--
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1
If you're frustrated, imagine how frustrated Rob is receiving all these complaints for his efforts to make this package available to you (at any version level). Makes one wonder why anyone would spend their time to support a package. Anyway, it's a point to ponder the next time you are frustrated with a particular package and feel like you'd like to lash out at someone. Larry Original Message: - From: Patrick Eisenacher [EMAIL PROTECTED] Date: Mon, 24 Mar 2003 13:15:28 +0100 To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1 Hi Jeff, I'm waiting already for more than a month for this to happen. Needless to say, I'm pretty frustrated. But despite Robert claiming to take care of this in his initial response you cited below, no update was ever published. All further inquiries were silently ignored. The interpretation of this behaviour and consequences are up to you. Right now, Cygwin is not usable for XML editing. I recommend switching over to some other *nix and a VM. Alternatively you can use the Windows ports of the xml libaries provided by Igor Zlatkovic. His ports are always up to date: http://www.zlatkovic.com/projects/libxml/index.html Disappointed, Patrick Robert Collins said on 19 Feb 2003 07:57:58 +1100: Yes, and this takes the current version from 'old' to 'old + buggy'. I've upped my priority to get a new release out. Uhmm, end of the week should do it. Please, could we/you somehow get xsltproc associated libs in the cygwin installation repository brought up-to-date? I'm trying to use xsltproc with some docbook stuff (we're using docbook to write the next phase of ProjectLiberty specs, and I use cygwin as my *nix environment), and said docbook stuff uses xinclude. The old xsltproc et al included (still) in the cygwin install (I updated this morning) barfs on the xinclude stuff, plus it doesn't properly handle (eg skip over) included mediaobjects (eg EPS). The latest version of xsltproc et al (the various *xml* libs) handles both of these just fine. thanks, JeffH -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ mail2web - Check your email from the web at http://mail2web.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: System load question
On Mon, Mar 24, 2003 at 03:30:17PM +0100, [EMAIL PROTECTED] wrote: Does the loadavg work however ? No. cgf -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: help!!
My suggestion to you is to pull out your favorite debugger and
start looking at where the problem occurs. That usually provides
some clues or at least a basis on which you can start asking
questions that lead to a solution. If you have a follow-up question
as a result of this analysis, you should visit http://cygwin.com/bugs.html
for information on how to report bugs or ask for assistance with problem
analysis.
Larry
Original Message:
-
From: Sacri Acuyo [EMAIL PROTECTED]
Date: Mon, 24 Mar 2003 10:31:59 +0100 (CET)
To: [EMAIL PROTECTED]
Subject: help!!
Hello, I would like to make you a question:
I'm trying to call to java code from C++ code, so I
have just do it for linux with gcc using gcj and gcjh.
Now, I have been trying the same for Windows 2000,
following these steps:
1.- Write the java file -- prueba_java.java
2.- Compile it with javac -- javac prueba_java.java
3.- Create the header file -- gcjh prueba_java
4.- Create the .o file --
gcj gcj -c -g -O prueba_java.java
5.- Write the C++ file, from which I call the java
code -- main.cc
6.- Compile it -- gcc -c -I /MinGW/include main.cc
7.- Linking with java code --
gcc -static main.o prueba_java.o -o ejecutable -L
-L/MinGW/lib -lgcj -lmingw32 -lwsock32
And when I try to execute the executable file (
ejecutable ), but it dies with an abnormal program
termination, because of the following error:
Program received signal SIGSEGV, Segmentation fault.
0x78002320 in _libwsock32_a_iname ()
(gdb) where
#0 0x78002320 in _libwsock32_a_iname ()
#1 0x0043f966 in
java::lang::System::init_properties() ()
#2 0x00413335 in
java::lang::System::getProperty(java::lang::String*)
()
#3 0x00458caa in
java::util::TimeZone::__U3c_clinit__U3e_() ()
#4 0x0040530f in java::lang::Class::initializeClass()
()
#5 0x004d671c in _Jv_InitClass () at {standard
input}:205
#6 0x004543f6 in
java::util::TimeZone::getTimeZone(java::lang::String*)
()
#7 0x00412f79 in
java::lang::System::getDefaultTimeZoneId() ()
#8 0x0043f7ed in
java::lang::System::init_properties() ()
#9 0x00413335 in
java::lang::System::getProperty(java::lang::String*)
()
#10 0x004602b1 in
java::io::PrintStream::__U3c_clinit__U3e_() ()
#11 0x0040530f in java::lang::Class::initializeClass()
()
#12 0x00402c31 in _Jv_AllocObjectNoFinalizer ()
#13 0x004136e7 in
java::lang::System::__U3c_clinit__U3e_() ()
#14 0x0040530f in java::lang::Class::initializeClass()
()
#15 0x004d671c in _Jv_InitClass () at {standard
input}:205
#16 0x004133e0 in
java::lang::System::getSecurityManager() ()
#17 0x0040c81a in java::lang::Thread::checkAccess() ()
#18 0x0040ca24 in java::lang::Thread::setDaemon(bool)
()
#19 0x004127a2 in
gnu::gcj::runtime::FinalizerThread::FinalizerThread()
()
#20 0x0040396f in _Jv_CreateJavaVM(void*) ()
#21 0x004d674d in JvCreateJavaVM(void*) () at
{standard input}:205
#22 0x004012b7 in main ()
I would like you to tell me how to solve this problem,
if it's possible..
Thank you very much for your attention..
___
Yahoo! Messenger - Nueva versión GRATIS
Super Webcam, voz, caritas animadas, y más...
http://messenger.yahoo.es
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
mail2web - Check your email from the web at
http://mail2web.com/ .
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Sementation fault in OpenGL application
Unless someone here has the same video card, driver (+version), and can reproduce your problem, I'm not sure you'll get much response here beyond the advice already given. Certainly it is possible that there is a video driver issue and that would certainly be specific to the card in question. But it's also possible that your program is causing a problem for the video driver. It's also possible that there's a bug elsewhere (i.e. gcc) which is contributing to this failure. But the answer to where the problem actually lies will come from some analysis. Then again, there might be someone here on the list that has seen exactly this problem and will pipe up with a solution. It's my impression that if that was the case, you would've heard from that person already. So I'm recommending you don't hold your breath waiting for that nice, simple solution to come your way. ;-) Larry Original Message: - From: Tron Thomas [EMAIL PROTECTED] Date: Sun, 23 Mar 2003 16:31:07 -0800 To: [EMAIL PROTECTED] Subject: Sementation fault in OpenGL application Earlier I had posted a message concerning I segmentation fault I get when I build an OpenGL application using the GCC compiler on Cygwin. I have since discovered that the debugger spits out some information when the segmentation fault occurs. The is what it says: Program received signal SIGSEGV, Segmentation fault. 0x6966190c in nvoglnt!DrvSetPixelFormat () I have a 64 Megabyte nVidia GeForce 3 video card on my system. The debug message implies the error is occuring in the video driver. I do not know what would be causing this, especially when the program runs fine when built with other compilers. Can anyone offer any help on this matter? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ mail2web - Check your email from the web at http://mail2web.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bleadperl on Cygwin with threads, 1 Test fails
Gerrit P. Haase wrote: Thomas schrieb: Gerrit P. Haase wrote: Thomas schrieb: Gerrit P. Haase wrote: Hallo perl5-porters, successfully builded bleadperl with threads the first time, many thanks to the Wizard of Perl! I was able to build perl 5.8.0-1 with threads that has passed all tests by disabling perls internal malloc. With the perl malloc the embed test has failed. You could build perl-5.8.0 with threads? I thought the 5.8. pumpking fixed it just some days ago? Have you patched the sources? Fails for me (w/ Cygwin, latest release): lib/Thread/Queue.FAILED at test 1 This test uses pthread_conds too. Maybe you should wait until the next cygwin release or until Chris creates a new snapshot. Thomas -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1
Nobody was lashing at anybody. So let's stay with this, Larry. Patrick [EMAIL PROTECTED] schrieb: If you're frustrated, imagine how frustrated Rob is receiving all these complaints for his efforts to make this package available to you (at any version level). Makes one wonder why anyone would spend their time to support a package. Anyway, it's a point to ponder the next time you are frustrated with a particular package and feel like you'd like to lash out at someone. Larry Original Message: - From: Patrick Eisenacher [EMAIL PROTECTED] Date: Mon, 24 Mar 2003 13:15:28 +0100 To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1 Hi Jeff, I'm waiting already for more than a month for this to happen. Needless to say, I'm pretty frustrated. But despite Robert claiming to take care of this in his initial response you cited below, no update was ever published. All further inquiries were silently ignored. The interpretation of this behaviour and consequences are up to you. Right now, Cygwin is not usable for XML editing. I recommend switching over to some other *nix and a VM. Alternatively you can use the Windows ports of the xml libaries provided by Igor Zlatkovic. His ports are always up to date: http://www.zlatkovic.com/projects/libxml/index.html Disappointed, Patrick Robert Collins said on 19 Feb 2003 07:57:58 +1100: Yes, and this takes the current version from 'old' to 'old + buggy'. I've upped my priority to get a new release out. Uhmm, end of the week should do it. Please, could we/you somehow get xsltproc associated libs in the cygwin installation repository brought up-to-date? I'm trying to use xsltproc with some docbook stuff (we're using docbook to write the next phase of ProjectLiberty specs, and I use cygwin as my *nix environment), and said docbook stuff uses xinclude. The old xsltproc et al included (still) in the cygwin install (I updated this morning) barfs on the xinclude stuff, plus it doesn't properly handle (eg skip over) included mediaobjects (eg EPS). The latest version of xsltproc et al (the various *xml* libs) handles both of these just fine. thanks, JeffH -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: xsltproc segfaults after upgrading to docbook xsl stylesheets v1.60.1
That's the beauty of open software, Patrick. The source is available. If it's not good enough for you, you can just 'make it happen'. As you found out, there are other packages too that you could use to replace those not to your liking. Most of the people working on those packages do it voluntarily and do not appreciate - being bitched at - are suggested -between the lines- to being fired Long time ago, very long time ago, I played in the open software field too, for the simple reason that I wanted to do something that I really cared for; like -as I assume- many do nowadays. I ceased working in this area because of people like you. If you have the qualification, fix it. If you don't, than we can safely assume that you don't know about the problems and side effects that need to be solved and also that you have no idea of how long it will take to work perfect. Those individuals you are griping about are not your slaves but do valuable work for all of us on their free will and their own time and deserve your appreciation instead of being publicly attacked. Very frustrated günter strubinsky [EMAIL PROTECTED] Tel: 402.212.0196 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Eisenacher Sent: Monday, March 24, 2003 6:15 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: xsltproc segfaults after upgrading to docbook xsl stylesheets v1.60.1 Hi Jeff, I'm waiting already for more than a month for this to happen. Needless to say, I'm pretty frustrated. But despite Robert claiming to take care of this in his initial response you cited below, no update was ever published. All further inquiries were silently ignored. The interpretation of this behaviour and consequences are up to you. Right now, Cygwin is not usable for XML editing. I recommend switching over to some other *nix and a VM. Alternatively you can use the Windows ports of the xml libaries provided by Igor Zlatkovic. His ports are always up to date: http://www.zlatkovic.com/projects/libxml/index.html Disappointed, Patrick Robert Collins said on 19 Feb 2003 07:57:58 +1100: Yes, and this takes the current version from 'old' to 'old + buggy'. I've upped my priority to get a new release out. Uhmm, end of the week should do it. Please, could we/you somehow get xsltproc associated libs in the cygwin installation repository brought up-to-date? I'm trying to use xsltproc with some docbook stuff (we're using docbook to write the next phase of ProjectLiberty specs, and I use cygwin as my *nix environment), and said docbook stuff uses xinclude. The old xsltproc et al included (still) in the cygwin install (I updated this morning) barfs on the xinclude stuff, plus it doesn't properly handle (eg skip over) included mediaobjects (eg EPS). The latest version of xsltproc et al (the various *xml* libs) handles both of these just fine. thanks, JeffH -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1
If this is not lashing at somebody, I don't want to be in the same solar system with you when you really are! günter strubinsky [EMAIL PROTECTED] Tel: 402.212.0196 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Eisenacher Sent: Monday, March 24, 2003 9:45 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1 Nobody was lashing at anybody. So let's stay with this, Larry. Patrick [EMAIL PROTECTED] schrieb: If you're frustrated, imagine how frustrated Rob is receiving all these complaints for his efforts to make this package available to you (at any version level). Makes one wonder why anyone would spend their time to support a package. Anyway, it's a point to ponder the next time you are frustrated with a particular package and feel like you'd like to lash out at someone. Larry Original Message: - From: Patrick Eisenacher [EMAIL PROTECTED] Date: Mon, 24 Mar 2003 13:15:28 +0100 To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1 Hi Jeff, I'm waiting already for more than a month for this to happen. Needless to say, I'm pretty frustrated. But despite Robert claiming to take care of this in his initial response you cited below, no update was ever published. All further inquiries were silently ignored. The interpretation of this behaviour and consequences are up to you. Right now, Cygwin is not usable for XML editing. I recommend switching over to some other *nix and a VM. Alternatively you can use the Windows ports of the xml libaries provided by Igor Zlatkovic. His ports are always up to date: http://www.zlatkovic.com/projects/libxml/index.html Disappointed, Patrick Robert Collins said on 19 Feb 2003 07:57:58 +1100: Yes, and this takes the current version from 'old' to 'old + buggy'. I've upped my priority to get a new release out. Uhmm, end of the week should do it. Please, could we/you somehow get xsltproc associated libs in the cygwin installation repository brought up-to-date? I'm trying to use xsltproc with some docbook stuff (we're using docbook to write the next phase of ProjectLiberty specs, and I use cygwin as my *nix environment), and said docbook stuff uses xinclude. The old xsltproc et al included (still) in the cygwin install (I updated this morning) barfs on the xinclude stuff, plus it doesn't properly handle (eg skip over) included mediaobjects (eg EPS). The latest version of xsltproc et al (the various *xml* libs) handles both of these just fine. thanks, JeffH -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1
OK, perhaps your message just suffers from poor timing and too much innuendo. Or perhaps I saw more in it than there was. ;-) Anyway, it looks like this is working out in your favor. Despite Rob's announcement that he's dropping maintainership for these packages, Elfyn has offered to pick it up. This is good news for anyone who wants to use these packages with Cygwin. I'd like to thank Rob for his efforts on this package and Elfyn for stepping in to take over. Larry Original Message: - From: Patrick Eisenacher [EMAIL PROTECTED] Date: Mon, 24 Mar 2003 16:44:52 +0100 To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1 Nobody was lashing at anybody. So let's stay with this, Larry. Patrick [EMAIL PROTECTED] schrieb: If you're frustrated, imagine how frustrated Rob is receiving all these complaints for his efforts to make this package available to you (at any version level). Makes one wonder why anyone would spend their time to support a package. Anyway, it's a point to ponder the next time you are frustrated with a particular package and feel like you'd like to lash out at someone. Larry Original Message: - From: Patrick Eisenacher [EMAIL PROTECTED] Date: Mon, 24 Mar 2003 13:15:28 +0100 To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1 Hi Jeff, I'm waiting already for more than a month for this to happen. Needless to say, I'm pretty frustrated. But despite Robert claiming to take care of this in his initial response you cited below, no update was ever published. All further inquiries were silently ignored. The interpretation of this behaviour and consequences are up to you. Right now, Cygwin is not usable for XML editing. I recommend switching over to some other *nix and a VM. Alternatively you can use the Windows ports of the xml libaries provided by Igor Zlatkovic. His ports are always up to date: http://www.zlatkovic.com/projects/libxml/index.html Disappointed, Patrick Robert Collins said on 19 Feb 2003 07:57:58 +1100: Yes, and this takes the current version from 'old' to 'old + buggy'. I've upped my priority to get a new release out. Uhmm, end of the week should do it. Please, could we/you somehow get xsltproc associated libs in the cygwin installation repository brought up-to-date? I'm trying to use xsltproc with some docbook stuff (we're using docbook to write the next phase of ProjectLiberty specs, and I use cygwin as my *nix environment), and said docbook stuff uses xinclude. The old xsltproc et al included (still) in the cygwin install (I updated this morning) barfs on the xinclude stuff, plus it doesn't properly handle (eg skip over) included mediaobjects (eg EPS). The latest version of xsltproc et al (the various *xml* libs) handles both of these just fine. thanks, JeffH -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ mail2web - Check your email from the web at http://mail2web.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cygwin running problem with mysql
I have installed Cygwin 1.3.20 and compiled mysql-4.0.12. It worked well as a mysql client, but when I ran some applications using mysql client, I got some error: Mon Mar 24 16:05:32 2003 : Info: Starting - reading configuration files ... rlm_sql_mysql: Starting connect to MySQL server for #0rlm_sql_mysql: Starting co nnect to MySQL server for #1rlm_sql_mysql: Starting connect to MySQL server for #2rlm_sql_mysql: Starting connect to MySQL server for #3rlm_sql_mysql: Starting connect to MySQL server for #4d:\freerd\src\main\radiusd.exe: *** unable to rema p D:\cygwin\usr\local\lib\rlm_sql_mysql.dll to same address as parent(0xDD) != 0xE3 16 [main] radiusd 496 sync_with_child: child 992(0x1B8) died before initial ization with status code 0x1 13132 [main] radiusd 496 sync_with_child: *** child state child loading dlls Did anybody have met the problem? Can you use rebase to solve it? Thanks Roger Lu __ Post your free ad now! http://personals.yahoo.ca -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1
I started working on this one last night. Thanks! Now I know what you mean by these packages being a bugger to build OOTB. That's what I was afraid of and why I'm not at liberty to volunteer, fwiw. In the coming week I'm going to be testing this and release a test package for people to try, if you don't mind of course. :-) I'll do some limited testing by running our docbook-based specs thru the libs/xsltproc et al. another thing that'd be great to get in the cygwin distro is eps2pdf if anyone has the cycles to take that on. our toolchain uses it too so I can try it out. fwiw, the toolchain includes TeX, and I've folded passivetex into my installation and it appeared to work. passivetex is a tex macro package, and is available here. would be nice to have it automagically folded in, too... http://www.tei-c.org.uk/Software/passivetex/ As for maintainership I volunteer, as this is a package I don't want to see pulled from the distribution. thanks again, and as I said I can do some testing. JeffH -- Jeff Hodges[EMAIL PROTECTED] Sun Microsystems, Inc. voice: +1 408.276.5467 4220 Network Circle, Bldg 22 fax: +1 408.276.7209 Santa Clara, CA 95054 USA -- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin running problem with mysql
Original Message: - From: Zhen LU [EMAIL PROTECTED] Date: Mon, 24 Mar 2003 11:17:54 -0500 (EST) To: [EMAIL PROTECTED] Subject: cygwin running problem with mysql [snip] #4d:\freerd\src\main\radiusd.exe: *** unable to rema p D:\cygwin\usr\local\lib\rlm_sql_mysql.dll to same address as parent(0xDD) != 0xE3 16 [main] radiusd 496 sync_with_child: child 992(0x1B8) died before initial ization with status code 0x1 13132 [main] radiusd 496 sync_with_child: *** child state child loading dlls Did anybody have met the problem? Can you use rebase to solve it? Yes indeed. Sounds like a perfect fit. If you have apache installed, make sure you remove the rebase.exe in that package and that you install the rebase utilities package. rebaseall from the utilities package should do the trick. Larry mail2web - Check your email from the web at http://mail2web.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1
That's great news :o) Elfyn, please let me know when you need support on this task. Peace, Patrick [EMAIL PROTECTED] schrieb: OK, perhaps your message just suffers from poor timing and too much innuendo. Or perhaps I saw more in it than there was. ;-) Anyway, it looks like this is working out in your favor. Despite Rob's announcement that he's dropping maintainership for these packages, Elfyn has offered to pick it up. This is good news for anyone who wants to use these packages with Cygwin. I'd like to thank Rob for his efforts on this package and Elfyn for stepping in to take over. Larry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: xsltproc segfaults after upgrading to docbook xsl stylesheetsv1.60.1
Napsan da 2003.03.24 17:42, (autor: [EMAIL PROTECTED]): another thing that'd be great to get in the cygwin distro is eps2pdf if anyone has the cycles to take that on. tetex-bin package contains epstopdf script... -- +---+ | Marcel Telka e-mail: [EMAIL PROTECTED] | |homepage: http://telka.sk/ | |jabber: [EMAIL PROTECTED] | +---+ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Sementation fault in OpenGL application
Actually I'm thinking that the problem is not with the video driver. I renamed the driver dll so that the system would use the software renderer instead of the video card driver. The same problem occurred in a call to wglChoosePixelFormat provided by the software render. I checked the documentation for DrvSetPixelFormat on the Microsoft website. It mentioned that this call should only be made once and calling it multiple times can cause problems with the window manager and the multithreaded applications. I would think that this function has already been called earlier in the program when I actually specify my pixel format while initializing OpenGL with calls to the ChoosePixelFormat and SetPixelFormat API's. After this initialization, I then try to create a texture, and that is where the problem is occuring. I'm not sure why this DrvSetPixelFormat is being called while making the texture. It seems that this method might be called when it shouldn't be, and that could be related to the problem. [EMAIL PROTECTED] wrote: Unless someone here has the same video card, driver (+version), and can reproduce your problem, I'm not sure you'll get much response here beyond the advice already given. Certainly it is possible that there is a video driver issue and that would certainly be specific to the card in question. But it's also possible that your program is causing a problem for the video driver. It's also possible that there's a bug elsewhere (i.e. gcc) which is contributing to this failure. But the answer to where the problem actually lies will come from some analysis. Then again, there might be someone here on the list that has seen exactly this problem and will pipe up with a solution. It's my impression that if that was the case, you would've heard from that person already. So I'm recommending you don't hold your breath waiting for that nice, simple solution to come your way. ;-) Larry Original Message: - From: Tron Thomas [EMAIL PROTECTED] Date: Sun, 23 Mar 2003 16:31:07 -0800 To: [EMAIL PROTECTED] Subject: Sementation fault in OpenGL application Earlier I had posted a message concerning I segmentation fault I get when I build an OpenGL application using the GCC compiler on Cygwin. I have since discovered that the debugger spits out some information when the segmentation fault occurs. The is what it says: Program received signal SIGSEGV, Segmentation fault. 0x6966190c in nvoglnt!DrvSetPixelFormat () I have a 64 Megabyte nVidia GeForce 3 video card on my system. The debug message implies the error is occuring in the video driver. I do not know what would be causing this, especially when the program runs fine when built with other compilers. Can anyone offer any help on this matter? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ mail2web - Check your email from the web at http://mail2web.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Starting .exe: DOS prompt OK, double-click not
On Mon, 24 Mar 2003, Kodaj Bence wrote: /cygdrive/c/OurAppFolder/OurScript.tcl: no such file or directory ^^ This is a POSIX path. You can translate it to a Windows path using the Cygwin API call cygwin_conv_to_win32_path Thanks for the tip, but I'm not sure this is the solution. There's a point that I might not have made clear enough in my previous posting: = Everything's fine when I start OurApp.exe from a DOS prompt. = Now, OurApp.exe invokes wish like this: execlp( wish, wish, ./OurScript.tcl , ...); My question is: why does this call work in the DOS-prompt mode, and why doesn't it work in double-click mode? Let me emphasize again that wish is invoked _in the same way_ in both cases. Bence Kodaj Because from the DOS prompt your program is invoked as .\OurApp.exe, and from Explorer it's invoked with a full path (i.e., C:\OurAppFolder\OurApp.exe). Cygwin translates the current directory into a POSIX path. In the first case, the current directory is .\, which in POSIX is ./. Now, since Windows understands mixed paths, it interprets this correctly, so your program works. In the second case, the path becomes what you see in the error message above, which is not understood by Windows. I'm not sure how to avoid path translation. You could try invoking wish as execlp( wish, wish, OurScript.tcl , ...); instead... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Added setup.exe to User's Guide
On Mon, 24 Mar 2003, Hannu E K Nevalainen (garbage mail) wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Joshua Daniel Franklin On Sun, Mar 23, 2003 at 08:54:11PM +0100, Hannu E K Nevalainen (garbage mail) wrote: Suggestions for wording changes/expansion of the text. I believe most of your suggestions assume that the user has little or no knowledge of Unix. I'm operating under the assumption that most new users have knowledge of Unix and will already have run into things like \r\n line endings, man, info, etc. IMHO my suggestions adds just that *tiny bit* of extra info that makes a new user get the grip - without some of the FAQs. -- 8 -- Local Package Directory Append something like the following to the paragraph: There are circumstances when it is useful to use the cache as local package directory for installation on another system than the primary one. This is currently NOT directly supported by setup.exe, but can be achieved in a number of ways. Information regarding this has yet to be gathered here. Currently it is spread out amongst the postings on the mailing lists, especially the cygwin list. Huh? Hmm...? Why so perplexed? I've gotten the impression that this isn't easily accomplished. Install Cygwin on one machine. Copy the cache to a separate machine. Install again. This will work fine, as long as you choose the same mirror. First of all; those two lines belong on the web-page. Second; setup.exe does not cover all situations. Third; It involves loads of manual work, on more than a few machines. Fourth; using a LAN - high load when all machines has to be updated. This has been discussed throughly here on the ML. With a slant towards the second; IMHO this needs to be mentioned, toghether with some kind of pointers to the postings - unless it can be summarised directly. I'm asking myself: Why do people insist on not telling about the possible ways to achieve this? IMHO this is like somebody telling you that there is no such thing as free speech unless you pay the license fee (Here: the bill for having high speed Internet). Simply put: _irritating_ ;-} . Arguments follow, feel free to skip to next comment. My experience of - downloading MOST of the packages, - creating a CDR of the cache - and running setup.exe on it at home has learnt me that it really isn't that easy in every situation. The basis of it - is here: - It isn't that fun to download all of cygwin over 128k/ISDN (or slower), you really need something faster than that. - Not everybody has ADSL++/flat rate/eons of time for plain downloads. - Please, also note: We have to pay in proportion to time, for beeing online, over here. This escalates into unbearable bills very soon. Example of the last: With minimal Internet online-time I have to pay more than $100/month currently. I have no intention to increase the amount on those bills e.g. by downloading the entire cygwin. To what sort of information are you referring? All the postings on the cygwin ML about installing without setup.exe, creating CDR-copies of the cache _to be used as install-source_ and so on. Am I that unclear in style of writing? I find it alarming. s /Hannu E K Nevalainen, Mariefred, Sweden Hannu, IIRC, the only gotcha about using setup's cache on a CD-R was to not put it in the root of the CD-R (because of the way Windows omits the \ from the root path, and that confuses setup). Placing the cache in a subdirectory, say, G:\cygwin works perfectly fine. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin running problem with mysql
Hello All: I am attempting to install mysql but the install script dies on groupadd and useradd commands how do I do groupadd with cygwin? how do I do useradd with cygwin? Thanks, Martin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 24, 2003 9:46 AM Subject: RE: cygwin running problem with mysql Original Message: - From: Zhen LU [EMAIL PROTECTED] Date: Mon, 24 Mar 2003 11:17:54 -0500 (EST) To: [EMAIL PROTECTED] Subject: cygwin running problem with mysql [snip] #4d:\freerd\src\main\radiusd.exe: *** unable to rema p D:\cygwin\usr\local\lib\rlm_sql_mysql.dll to same address as parent(0xDD) != 0xE3 16 [main] radiusd 496 sync_with_child: child 992(0x1B8) died before initial ization with status code 0x1 13132 [main] radiusd 496 sync_with_child: *** child state child loading dlls Did anybody have met the problem? Can you use rebase to solve it? Yes indeed. Sounds like a perfect fit. If you have apache installed, make sure you remove the rebase.exe in that package and that you install the rebase utilities package. rebaseall from the utilities package should do the trick. Larry mail2web - Check your email from the web at http://mail2web.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Starting .exe: DOS prompt OK, double-click not
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Kodaj Bence --8-- = Everything's fine when I start OurApp.exe from a DOS prompt. = Now, OurApp.exe invokes wish like this: execlp( wish, wish, ./OurScript.tcl , ...); My question is: why does this call work in the DOS-prompt mode, and why doesn't it work in double-click mode? Let me emphasize again that wish is invoked _in the same way_ in both cases. Bence Kodaj DOS accepts / as path item separator *to some extent* C:\ dir c:/windows/command works (Win98-DOS); NOTE that the quotes are necessary. /Hannu E K Nevalainen, Mariefred, Sweden --END OF MESSAGE-- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin running problem with mysql
See net user help and net group help. Windows handles user/group maintenance functions. Larry Original Message: - From: Martin [EMAIL PROTECTED] Date: Mon, 24 Mar 2003 10:49:55 -0700 To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: cygwin running problem with mysql Hello All: I am attempting to install mysql but the install script dies on groupadd and useradd commands how do I do groupadd with cygwin? how do I do useradd with cygwin? Thanks, Martin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 24, 2003 9:46 AM Subject: RE: cygwin running problem with mysql Original Message: - From: Zhen LU [EMAIL PROTECTED] Date: Mon, 24 Mar 2003 11:17:54 -0500 (EST) To: [EMAIL PROTECTED] Subject: cygwin running problem with mysql [snip] #4d:\freerd\src\main\radiusd.exe: *** unable to rema p D:\cygwin\usr\local\lib\rlm_sql_mysql.dll to same address as parent(0xDD) != 0xE3 16 [main] radiusd 496 sync_with_child: child 992(0x1B8) died before initial ization with status code 0x1 13132 [main] radiusd 496 sync_with_child: *** child state child loading dlls Did anybody have met the problem? Can you use rebase to solve it? Yes indeed. Sounds like a perfect fit. If you have apache installed, make sure you remove the rebase.exe in that package and that you install the rebase utilities package. rebaseall from the utilities package should do the trick. Larry mail2web - Check your email from the web at http://mail2web.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ mail2web - Check your email from the web at http://mail2web.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Starting .exe: DOS prompt OK, double-click not
On Mon, 2003-03-24 at 06:35, Kodaj Bence wrote: /cygdrive/c/OurAppFolder/OurScript.tcl: no such file or directory ^^ This is a POSIX path. You can translate it to a Windows path using the Cygwin API call cygwin_conv_to_win32_path Thanks for the tip, but I'm not sure this is the solution. There's a point that I might not have made clear enough in my previous posting: = Everything's fine when I start OurApp.exe from a DOS prompt. = Now, OurApp.exe invokes wish like this: execlp( wish, wish, ./OurScript.tcl , ...); My question is: why does this call work in the DOS-prompt mode, and why doesn't it work in double-click mode? Let me emphasize again that wish is invoked _in the same way_ in both cases. Bence Kodaj have you tried creating a shortcut for the application, *and* specifying the path in the start in location? -- Michael [EMAIL PROTECTED] http://www.strange1.net GPG ID:1D630EF7 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin running problem with mysql
I am attempting to install mysql but the install script dies on groupadd
and
useradd commands
how do I do groupadd with cygwin?
how do I do useradd with cygwin?
Cygwin does not have {user,group}add in it's net distribution. If you are on
Windows NT/2000/XP you can use the `net' command, which is shipped with
windows, which can add users/groups. On word though: In Windows you cannot
have a user and group with the same name so you will have you play with
/etc/passwd so you can have a user/group as mysql/mysql.
Regards,
Elfyn McBratney
[EMAIL PROTECTED]
www.exposure.org.uk
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: cygwin running problem with mysql
On Mon, 24 Mar 2003, Elfyn McBratney wrote:
I am attempting to install mysql but the install script dies on groupadd
and useradd commands
how do I do groupadd with cygwin?
how do I do useradd with cygwin?
Cygwin does not have {user,group}add in it's net distribution. If you are on
Windows NT/2000/XP you can use the `net' command, which is shipped with
windows, which can add users/groups. On word though: In Windows you cannot
have a user and group with the same name so you will have you play with
/etc/passwd so you can have a user/group as mysql/mysql.
Regards,
Elfyn McBratney
However, on Windows, the owner of the file can be a Windows group. So,
you could create a *group* named mysql and make entries for it in both
/etc/passwd and /etc/group.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
-- /usr/games/fortune
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
python script recently started getting unable to remap error on cygssl from popen2
Hi. Since 1.3.19, I've been seeing this error sporadically from a script that had been working fine till then. It only appears with ssl so far -- various other DLLs seem to work fine. (removing the call to import socket removes the problem). This is under Windows 2000, SP3. Any ideas -- the archives have references to rebasing libraries, any pointers to how I can do that (and whether this needs to be done to python's _socket.dll or to cygssl?) Thanks, Mark. : ashoka ; python test-remap-cygssl-problem.py C:\opt\gnu\cygwin\bin\python2.2.exe: *** unable to remap C:\opt\gnu\cygwin\bin\cygssl-0.9.7.dll to same address as parent(0x72) != 0x73 8 [main] python 1440 sync_with_child: child 1612(0x238) died before initialization with status code 0x1 4275 [main] python 1440 sync_with_child: *** child state child loading dlls Traceback (most recent call last): File test-remap-cygssl-problem.py, line 8, in ? fw, fr = os.popen2(wc -l) File /usr/lib/python2.2/os.py, line 569, in popen2 stdout, stdin = popen2.popen2(cmd, bufsize) File /usr/lib/python2.2/popen2.py, line 144, in popen2 inst = Popen3(cmd, 0, bufsize) File /usr/lib/python2.2/popen2.py, line 40, in __init__ self.pid = os.fork() OSError: [Errno 11] Resource temporarily unavailable Exit 1 : ashoka ; ls -lt /usr/bin/*ssl* -rwxrwxrwx1 Administ Users 168960 Mar 19 12:35 /usr/bin/cygssl.dll -rwxrwxrwx1 Administ Users 180736 Mar 19 12:25 /usr/bin/cygssl-0.9.7.dll -rwxrwxrwx1 Administ Users 318464 Mar 19 12:25 /usr/bin/openssl.exe : ashoka ; sum /usr/bin/*ssl* 17190 177 /usr/bin/cygssl-0.9.7.dll 63625 165 /usr/bin/cygssl.dll 34128 311 /usr/bin/openssl.exe #! /usr/bin/env python import socket import os if __name__ == '__main__': fw, fr = os.popen2(wc -l) fw.write(hello\nworld\n) fw.flush() fw.close() s = fr.read() print `s` -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Fresh Install Question (Cygwin 1.3.22-1)
I have a fresh install of Cygwin 1.3.22-1 on a PC with Win2K in c:\cygwin. After the install, when I run the cygwin.bat file using the shortcut that appears on the desktop it does not seem to execute the /etc/profile file and hence does not create the /home/[username] directory. Any suggestions as to what might be happening? I have tried to maually creating the /home/[username] directory, but I have to execute the .bashrc everytime I open a cygwin window. I have been using Cygwin 1.3.10 and hence tried doing a fresh install of 1.3.10 on the same machine and it seems to execute the /etc/profile and hence create a /home/[username] directory when the cygwin.bat file is run the very first time. Thanks in advance for any suggestions. Raju Damle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin running problem with mysql
On Mon, 24 Mar 2003, Elfyn McBratney wrote:
I am attempting to install mysql but the install script dies on
groupadd
and useradd commands
how do I do groupadd with cygwin?
how do I do useradd with cygwin?
Cygwin does not have {user,group}add in it's net distribution. If you
are on
Windows NT/2000/XP you can use the `net' command, which is shipped with
windows, which can add users/groups. On word though: In Windows you
cannot
have a user and group with the same name so you will have you play with
/etc/passwd so you can have a user/group as mysql/mysql.
Regards,
Elfyn McBratney
However, on Windows, the owner of the file can be a Windows group. So,
you could create a *group* named mysql and make entries for it in both
/etc/passwd and /etc/group.
That cat is always giving me a run for my mahooney ;-)
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ [EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_ [EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Regards,
Elfyn McBratney
[EMAIL PROTECTED]
www.exposure.org.uk
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: python script recently started getting unable to remap error oncygssl from popen2
Mark, On Mon, Mar 24, 2003 at 12:26:54PM -0800, Mark Moraes wrote: Any ideas -- the archives have references to rebasing libraries, any pointers to how I can do that (and whether this needs to be done to python's _socket.dll or to cygssl?) See the following: /usr/doc/Cygwin/python-2.2.2.README or http://www.tishler.net/jason/software/python/python-2.2.2.README Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
texi2dvi problem, uname bug
Hello, I'm using Cygwin 1.3.22-1. On line 105 of the texi2dvi script there is `uname -S ...` the capital S here is wrong, it should be a lower-case s. (there is no -S uname option). Here is the patch: *** texi2dvi.orig Mon Mar 24 21:38:25 2003 --- texi2dviMon Mar 24 21:38:16 2003 *** *** 102,108 elif echo $PATH | grep ':.*:' 2/dev/null; then path_sep=':' else ! case `uname -S 2/dev/null` in [Cc][Yy][Gg][Ww][Ii][Nn]*) path_sep=':' ;; *) path_sep = ';' ;; esac --- 102,108 elif echo $PATH | grep ':.*:' 2/dev/null; then path_sep=':' else ! case `uname -s 2/dev/null` in [Cc][Yy][Gg][Ww][Ii][Nn]*) path_sep=':' ;; *) path_sep = ';' ;; esac Pascal. -- --|-- --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|-- --| http://perso.wanadoo.fr/pascal.obry --| The best way to travel is by means of imagination --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: python script recently started getting unable to remap error on cygssl from popen2
Since 1.3.19, I've been seeing this error sporadically from a script that had been working fine till then. It only appears with ssl so far -- various other DLLs seem to work fine. (removing the call to import socket removes the problem). This is under Windows 2000, SP3. Any ideas -- the archives have references to rebasing libraries, any pointers to how I can do that (and whether this needs to be done to python's _socket.dll or to cygssl?) : ashoka ; python test-remap-cygssl-problem.py C:\opt\gnu\cygwin\bin\python2.2.exe: *** unable to remap C:\opt\gnu\cygwin\bin\cygssl-0.9.7.dll to same address as parent(0x72) != 0x73 8 [main] python 1440 sync_with_child: child 1612(0x238) died before initialization with status code 0x1 4275 [main] python 1440 sync_with_child: *** child state child loading dlls Traceback (most recent call last): File test-remap-cygssl-problem.py, line 8, in ? fw, fr = os.popen2(wc -l) File /usr/lib/python2.2/os.py, line 569, in popen2 stdout, stdin = popen2.popen2(cmd, bufsize) File /usr/lib/python2.2/popen2.py, line 144, in popen2 inst = Popen3(cmd, 0, bufsize) File /usr/lib/python2.2/popen2.py, line 40, in __init__ self.pid = os.fork() OSError: [Errno 11] Resource temporarily unavailable Exit 1 Mark, Rebasing all of your Cygwin DLL's *should* fix this. If you don't have the rebase package installed install it via setup.exe and follow this (taken from the rebase README): Use the following procedure to rebase your entire system: 1. shutdown all Cygwin processes 2. start bash (do not use rxvt) 3. execute rebaseall (in the bash window) Once you've follwed these steps things should work. Regards, Elfyn McBratney [EMAIL PROTECTED] www.exposure.org.uk -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tar file size limitation
[EMAIL PROTECTED] wrote: I know work is progressing to change this but seems to me this is worthwhile fodder for the FAQ at this point. You are right - however, I'm not the FAQ maintainer. Forwarding to the list. Max. Original Message: - From: Max Bowsher [EMAIL PROTECTED] Date: Mon, 24 Mar 2003 14:59:36 - To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: tar file size limitation Pierre Gregoreski wrote: Hi, I'm trying to put on a tape a 16 GB file with Cygwin tar on W2K. Cygwin does not support large files (2GB+). Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin running problem with mysql
Thanks Elfyn
Apparently passwd file requires the SID
how do I obtain the SID which corresponds with mysql username or groupname
Sorry for the bother!
-Martin
- Original Message -
From: Elfyn McBratney [EMAIL PROTECTED]
To: cygwin [EMAIL PROTECTED]; Martin [EMAIL PROTECTED]
Sent: Monday, March 24, 2003 12:53 PM
Subject: Re: cygwin running problem with mysql
I am attempting to install mysql but the install script dies on groupadd
and
useradd commands
how do I do groupadd with cygwin?
how do I do useradd with cygwin?
Cygwin does not have {user,group}add in it's net distribution. If you are
on
Windows NT/2000/XP you can use the `net' command, which is shipped with
windows, which can add users/groups. On word though: In Windows you cannot
have a user and group with the same name so you will have you play with
/etc/passwd so you can have a user/group as mysql/mysql.
Regards,
Elfyn McBratney
[EMAIL PROTECTED]
www.exposure.org.uk
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: texi2dvi problem, uname bug
On Mon, 24 Mar 2003, Pascal Obry wrote: Hello, I'm using Cygwin 1.3.22-1. On line 105 of the texi2dvi script there is `uname -S ...` the capital S here is wrong, it should be a lower-case s. (there is no -S uname option). Here is the patch: *** texi2dvi.orig Mon Mar 24 21:38:25 2003 --- texi2dviMon Mar 24 21:38:16 2003 *** *** 102,108 elif echo $PATH | grep ':.*:' 2/dev/null; then path_sep=':' else ! case `uname -S 2/dev/null` in [Cc][Yy][Gg][Ww][Ii][Nn]*) path_sep=':' ;; *) path_sep = ';' ;; esac --- 102,108 elif echo $PATH | grep ':.*:' 2/dev/null; then path_sep=':' else ! case `uname -s 2/dev/null` in [Cc][Yy][Gg][Ww][Ii][Nn]*) path_sep=':' ;; *) path_sep = ';' ;; esac Pascal. While you're correct in principle, wouldn't the above be a no-op under Cygwin anyway (unless your PATH has less than 3 entries in it)? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
vim quits and cygwin window contents not restored
Refer to: http://sources.redhat.com/ml/cygwin/2001-03/msg01816.html I still see that this is not working. Terminal contents are not restored. Can I set anything to resolve this? Will the fix be in soon? Thanks, Stephen Ehmann -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
changing text file type from DOS to unix?
I am trying to install a package that needs the text file type to be unix, but have previously installed Cygwin with the file type of DOS. Is it possible to change the text file type from DOS to unix without doing a reinstall of Cygwin? When I go through setup, if I select the file type as unix but don't select any new packages, it doesn't do anything. Thanks, -Anoop -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: vim quits and cygwin window contents not restored
Works for me (tm). Larry Original Message: - From: Stephen Ehmann [EMAIL PROTECTED] Date: Mon, 24 Mar 2003 13:57:02 -0800 To: [EMAIL PROTECTED] Subject: vim quits and cygwin window contents not restored Refer to: http://sources.redhat.com/ml/cygwin/2001-03/msg01816.html I still see that this is not working. Terminal contents are not restored. Can I set anything to resolve this? Will the fix be in soon? Thanks, Stephen Ehmann -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ mail2web - Check your email from the web at http://mail2web.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: vim quits and cygwin window contents not restored
It used to work fine for me to but I am setting up a new machine with a recent install of cygwin. Did you install recently? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 5:06 PM To: Stephen Ehmann; [EMAIL PROTECTED] Subject: RE: vim quits and cygwin window contents not restored Works for me (tm). Larry Original Message: - From: Stephen Ehmann [EMAIL PROTECTED] Date: Mon, 24 Mar 2003 13:57:02 -0800 To: [EMAIL PROTECTED] Subject: vim quits and cygwin window contents not restored Refer to: http://sources.redhat.com/ml/cygwin/2001-03/msg01816.html I still see that this is not working. Terminal contents are not restored. Can I set anything to resolve this? Will the fix be in soon? Thanks, Stephen Ehmann -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ mail2web - Check your email from the web at http://mail2web.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: changing text file type from DOS to unix?
On Mon, 24 Mar 2003, Anoop Ghanwani wrote: I am trying to install a package that needs the text file type to be unix, but have previously installed Cygwin with the file type of DOS. Is it possible to change the text file type from DOS to unix without doing a reinstall of Cygwin? When I go through setup, if I select the file type as unix but don't select any new packages, it doesn't do anything. Thanks, -Anoop eval `mount -m | grep -i cygwin | sed 's/-t/-b/'` Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: xsltproc segfaults after upgrading to docbook xslstylesheetsv1.60.1
I don't mind one iota. I do suggest you leverage the -src package for the currently-on-cygwin.com packages. Strip out the autoconf generated file patches, and you'll see what has to be forward ported. Some of the stuff may be eligible (now) for pushing upstream, but the bulk won't be, unless I've missed a transition to automake 1.5+ (which I *don't think) I have. Specific things to watch for: * python bindings (new in the cygwin package, more stable in upstream now). * new exports from dynamic libraries (I check for new exports via the win32 .dll specs, and ensure they are libtool auto-import compatible). * libtool API interface changes. If the interface has changed in a backwards compatible way, when you link xsltproc, xmllint etc, you'll link against your installed version which may not have enough symbols to link successfully. Secondly if the interface has brokne backwards compatability, but the libtool library identifier hasn't been bumped, well, welcome to h**l. * per object flags are needed to prevent duplicate or missing symbols against libxml and the test programs in libxml. Ask me if you get other surprises, I may have forgotten something. Will do. Thanks for the tips.. :-) As for maintainership I volunteer, as this is a package I don't want to see pulled from the distribution. Typo. I meant to say these are packages... Thank you. I stepped down because I realised I wasn't fulfilling my obligations and simply didn't want to get whipped to devote time I don't have, on someone elses schedule, not because I wanted to see the package removed (I don't). Sorry, Didn't mean to make it sound like you abbandoned it. What I find ironic is the immediate offer to help that you recieved, rather than abuse. Funny you said that. I was actually going to reply to Patrick and comment on his harshness, and if it wasn't for the fact that I was late for work I would have done...I see Larry beat me to it. If it wasn't for you maintaining the originals I/someone else would have to cover a lot of new ground, so offering to help seemed a h**l of a lot better than bitching and not doing anything to rectify the situation Rob Regards, Elfyn McBratney [EMAIL PROTECTED] www.exposure.org.uk -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: changing text file type from DOS to unix?
Much thanks! -Anoop -Original Message- From: Igor Pechtchanski [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 2:25 PM To: Anoop Ghanwani Cc: [EMAIL PROTECTED] Subject: Re: changing text file type from DOS to unix? On Mon, 24 Mar 2003, Anoop Ghanwani wrote: I am trying to install a package that needs the text file type to be unix, but have previously installed Cygwin with the file type of DOS. Is it possible to change the text file type from DOS to unix without doing a reinstall of Cygwin? When I go through setup, if I select the file type as unix but don't select any new packages, it doesn't do anything. Thanks, -Anoop eval `mount -m | grep -i cygwin | sed 's/-t/-b/'` Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_ [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Added setup.exe to User's Guide
From: Igor Pechtchanski [mailto:[EMAIL PROTECTED] --8-- IIRC, the only gotcha about using setup's cache on a CD-R was to not put it in the root of the CD-R (because of the way Windows omits the \ from the root path, and that confuses setup). Placing the cache in a subdirectory, say, G:\cygwin works perfectly fine. Ok. I didn't catch that one, obviously. My general point in this thread has been: Documentation should include simple pointers and just enough information on use. Just so that an intelligent beginner can read the text and find the information he needs. Background: A few years back, when I was a beginner, I found it REAL HARD to catch the hook - simply because the documentation was so beginner-unfriendly (BUF ;-). I occassionally still have a hard time finding the correct place in the docs. IMHO the docs doesn't need much of a change, just a few words here and a reference or a pointer there. And this is all it is about... Without those *tiny* details, you're out in the cold as beginner. If you're stubborn enough (I have been told I'm VERY stubborn) you'll get a hang on it... If you're not... Well... Getting more users to the free software world is A Good Thing i.e. a benefit for us all. IMHO creating *too* terse docs is counterproductive in this sense. /Hannu E K Nevalainen, Mariefred, Sweden --END OF MESSAGE-- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Added setup.exe to User's Guide
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Hannu, Your comments about installing Cygwin via setup using a local cache and/or burning a CD to install from do have merit. Can you suggest some wording that would describe a simple process that will work well? I think this would be the most hopeful and useful for inclusion. Larry As I understood from a posting of Igor Pechtchanski this isn't as hard as I thought(1). Well, now to the collection of words; something like this, maybe: -- If you have a CD-burner, ZIP, Jazz, removable HD or some such at home _and_ in a machine elsewhere, which also has fast internet access; you can do this: 1. Use the fast internet access machine, create a temporary Local Package Directory (the package cache) where there is enough space. 2. Download and use setup.exe to fill the above cache with whatever contents you wish (Download from Internet in setup.exe). 3. *Move* the ENTIRE cache directory onto a CDR (or whatever) - do NOT change anything within the cache. 4. Carry the CDR (or whatever) home, where you will be able to use it directly as Local Package Directory for setup's Install from local directory mode. NOTE1: The prerequisite here is that you do put THE DIRECTORY CONTAINING THE CACHE onto your CDR. Do something else and you will have trouble using it at home. NOTE2: If there is more packages than can be fitted on your CDR (e.g. you're using ZIP-disks) then you need to select NO MORE packages AT A TIME than can fit on your disk. -- Comments or Corrections anyone? (Don't say I got it right on the first try, I wouldn't believe you! ;-) /Hannu E K Nevalainen, Mariefred, Sweden -- (1) I had the impression that setup.exe saved paths within it's *ini-file or some such; thus forcing one to have *exactly* the same path at cache-disk creation AND use time. (This can be accomplished by intelligent use of the subst DOS-command. I don't know if subst is available for more than just Win98) This path saving is one of the worst nightmares you can be caught of as computer user. Windows has it, all over the place - I know people who have been hit by Windows changing D:\WINDOWS - C:\WINDOWS and thus destroying everything! i.e. D: contains the Windows installation, all paths get reset into C:. Xilinx Modelsim has it. Borland's old C++ V5.02 has it. OrCad PSpice has it. These are the ones I remember right now... I KNOW there is more. Example: Create a BC5.02 project on one machine - make it work. Copy the *.ide file and the sources to another machine. If the compiler on the new machine was NOT installed under the same path - you will end up with gery hairs pretty quick. UNLESS you know to look into Options-Project-Source Directories:Include Library If THESE do not point at the right place - trouble. THIS is a SIMPLE ONE to change. Have a go at doing the same for PSpice projects or Modelsim... THE WHIP: AN APPLICATION-GLOBAL PATH THAT DEPENDS ON INSTALLATION POSITION (i.e. PATH) DOES NOT BELONG IN A _*PROJECT FILE*_ THAT GETS CREATED BY THAT APPLICATION. PERIOD. Project files MUST be relocatable. --END OF MESSAGE-- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Added setup.exe to User's Guide
On Tue, 2003-03-25 at 09:35, Hannu E K Nevalainen (garbage mail) wrote: (1) I had the impression that setup.exe saved paths within it's *ini-file or some such; thus forcing one to have *exactly* the same path at cache-disk creation AND use time. setup doesn't. :]. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
RE: vim quits and cygwin window contents not restored
Larry, It used to work for me, but a recent update has caused it to cease working for me, too. Unfortunately, I'm not sure which--wasn't there an ncurses update recently? Perhaps when it's convenient, I'll try to back up to see if that makes screen restore start working again. One other thing I've noticed is that less restores the screen but Vim doesn't. For the hell of it, cygcheck -s -v output is attached. Randall Schulz At 14:06 2003-03-24, [EMAIL PROTECTED] wrote: Works for me (tm). Larry Original Message: - From: Stephen Ehmann [EMAIL PROTECTED] Date: Mon, 24 Mar 2003 13:57:02 -0800 To: [EMAIL PROTECTED] Subject: vim quits and cygwin window contents not restored Refer to: http://sources.redhat.com/ml/cygwin/2001-03/msg01816.html I still see that this is not working. Terminal contents are not restored. Can I set anything to resolve this? Will the fix be in soon? Thanks, Stephen Ehmann cygcheck-Clemens-s-v-2003-03-24 Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
autoexpect appears to be missing
Hello, I appear to be missing the autoexpect command, yet I have latest full versions of: expect tcltk dejagnu (plus source) I searched for this problem in the Documentation page, list archives, FAQ, and manpage. Do I need to install something else? thanks, (please include me on any reply as I'm currently off the list) Scott -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: vim quits and cygwin window contents not restored
It used to work for me, but a recent update has caused it to cease working for me, too. Unfortunately, I'm not sure which--wasn't there an ncurses update recently? Perhaps when it's convenient, I'll try to back up to see if that makes screen restore start working again. One other thing I've noticed is that less restores the screen but Vim doesn't. FWICS (acronym alert: From What I Can See :-) there is no difference. I've been switching libncurses and ncurses and I don't think anything has changed. Perhaps a change in the termcap? Regards, Elfyn McBratney [EMAIL PROTECTED] www.exposure.org.uk -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: xsltproc segfaults after upgrading to docbookxslstylesheetsv1.60.1
On Tue, 2003-03-25 at 09:32, Elfyn McBratney wrote: Thank you. I stepped down because I realised I wasn't fulfilling my obligations and simply didn't want to get whipped to devote time I don't have, on someone elses schedule, not because I wanted to see the package removed (I don't). Sorry, Didn't mean to make it sound like you abbandoned it. You didn't make it sound that way. I was enlarging on my fairly abrupt statement :}. Cheers, Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. signature.asc Description: This is a digitally signed message part
How to decide the file type in Cygwin?
I need to list all files in a folder (including sub-folder,
recursively), and I tried some sample codes in GNU C manual, as
follows:
/***/
#include stddef.h
#include stdio.h
#include sys/types.h
#include dirent.h
int
main (void)
{
DIR *dp;
struct dirent *ep;
dp = opendir (./);
if (dp != NULL)
{
while (ep = readdir (dp))
puts (ep-d_name);
(void) closedir (dp);
}
else
puts (Couldn't open the directory.);
return 0;
}
/***/
The sample was working. Then I added some codes to check the
ep-d_type (the type of the file). If it was a directory, the
program would check the sub-folder recursively. However, I
encountered a compiler error. The property d_type was not defined
in the Cygwin header file dirent.h. It seems that we cannot
distinguish the files from the directories. Is that true? Doesn't
anybody have a good idea to do this?
Thank you very much in adavance!
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: How to decide the file type in Cygwin?
Yang, Unix file systems don't store the the type of a file system entity in the directory entry used to access that entity, they stored in the so-called inode. Once you have a name, use the stat(2) system call to get its inode information. From there you'll be able to determine what kind of an entity it is. If you have a file descriptor, then fstat(2) will do the same. Randall Schulz At 15:27 2003-03-24, Yang, Huaichen wrote: I need to list all files in a folder (including sub-folder, recursively), and I tried some sample codes in GNU C manual, as follows: ... The sample was working. Then I added some codes to check the ep-d_type (the type of the file). If it was a directory, the program would check the sub-folder recursively. However, I encountered a compiler error. The property d_type was not defined in the Cygwin header file dirent.h. It seems that we cannot distinguish the files from the directories. Is that true? Doesn't anybody have a good idea to do this? Thank you very much in adavance! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: vim quits and cygwin window contents not restored
On Mon, 24 Mar 2003, Elfyn McBratney wrote: It used to work for me, but a recent update has caused it to cease working for me, too. Unfortunately, I'm not sure which--wasn't there an ncurses update recently? Perhaps when it's convenient, I'll try to back up to see if that makes screen restore start working again. One other thing I've noticed is that less restores the screen but Vim doesn't. FWICS (acronym alert: From What I Can See :-) Yes, but you don't get the credit. It's been used before... :-p there is no difference. I've been switching libncurses and ncurses and I don't think anything has changed. Perhaps a change in the termcap? Regards, Elfyn McBratney Well, I've been reading some vim help. A few interesting things surfaced. For details, help restorescreen, help term, help terminfo, and help xterm-screens in vim. FWIW, it works for me in an xterm, but doesn't in the bash window (we *really* ought to come up with a better name for that). Looks like vim doesn't recognize TERM=cygwin and doesn't set t_ti and t_te appropriately. These two variables control the alternate screen feature. As they aren't even defined for TERM=cygwin, I don't know how it ever worked (unless termcap/terminfo were changed recently). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygcheck calling id.exe with nontsec
On Mon, Mar 24, 2003 at 08:22:20PM -0500, Christopher Faylor wrote: On Mon, Mar 24, 2003 at 07:37:05PM -0500, Pierre A. Humblet wrote: cygcheck calling id.exe with CYGWIN=nontsec has a problem... At the risk of sounding ungrateful, can I point you at http://cygwin.com/bugs.html? The fact that you are reporting a problem in cygcheck doesn't mean that the hints there are not still useful. It would hvae saved me some time trying to puzzle out what you'd discovered if you'd 1) described it and 2) included cygcheck output. I suspect that you may even have figured out why the problem was happening. Chris, If I had figured it out I would have told you. Normally I would even have tried to patch it but I have never been able to make cygcheck on WinME, due to include file problems that I never felt the need to try to solve. Thanks for the fix. Pierre -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Problems interpreting errno
I have a client/server application that runs the client on a Linux workstation (RHAS) and runs the server on Win2k (under Cygwin). The client sends a filesystem command to the server and returns the errno. Here is the problem The file system call on Win2k (under cygwin) generates the errno, but the text string for the errno is interpreted on the client-side (under Linux), using the strerror() function. As a result, the error message is mis-interpreted. For example, Win2k ENOEMPTY = 90 Linux EMSGSIZE = 90 In other words, the error that occurred was Directory not empty, but the text displayed by the client was Message too long. Any ideas how to resolve the discrepency? Thanks, Matt Berney -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problems interpreting errno
On Mon, 24 Mar 2003, Matt Berney wrote: I have a client/server application that runs the client on a Linux workstation (RHAS) and runs the server on Win2k (under Cygwin). The client sends a filesystem command to the server and returns the errno. Here is the problem The file system call on Win2k (under cygwin) generates the errno, but the text string for the errno is interpreted on the client-side (under Linux), using the strerror() function. As a result, the error message is mis-interpreted. For example, Win2k ENOEMPTY = 90 Linux EMSGSIZE = 90 In other words, the error that occurred was Directory not empty, but the text displayed by the client was Message too long. Any ideas how to resolve the discrepency? Thanks, Matt Berney You mean, aside from the obvious interpret the error on the server and send a string to the client? ;-) Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Another GPL violation: Re: MinimalisticBuild-Environmentforwin32 (~7.5MB)
Bringing this back on list, with Rolands ok. On Tue, 2003-03-25 at 11:03, roland wrote: :( err - how to solve that ? since installation came from cygwin setup routines months ago - how do i know, what packages have been used (and which versions?) Your /etc/installed.db will list your current versions, and if you haven't updated since, will be accurate. To dig into this, this will cost me HOURS ! Any tips for an easy solution ? Sorry, not really. Use setup.exe is what comes to mind. We've spent much more than hours making it robust and easy to use. Completely new cygwin setup ,corresponding striptease and packaging ? Come on - I have no time for just doing some satisfaction for a sheet of paper. If I REALLY have to do this, I will take my website down and make rockbox people unhappy. This package was meant to make cygwin environment easier for the rockbox people - nobody depends on that - it`s just for comfort. It doesn`t work ? It doesn`t run ? It corrupts your code ? You miss a feature and NEED it ? Throw this package away - download cygwin and install yourself ! What would be the consequence, if i wouldn`t take care of your advice ? Will I get a reminder? I respect the GPL - but I also think, there could be a little freedom for interpretation. It`s hard enough, that we have to fiddle around with ordinary and absurd laws and licensing terms the rest of our life the GPL is what got you cygwin in the first place. Any interpretation which conflicts with the GPL is not valid. If you don't like the licence, return the product! regards roland ps: There must be HOUNDREDTHOUSANDS of people violating the gpl! On Mon, 2003-03-24 at 10:53, roland wrote: Hello Robert, I take GPL serious and didn`t see, that this is a problem. I have added the following lines on the download page: Download rockbox-sdk_win32.tar.bz2. (store in dir c:\cygwin) This package contains a minimalistic cygwin environment in binary form. See www.cygwin.com for sourcecode and further information Does this give satisfaction ? Unfortunately no, you must host the matching sources yourself. http://www.cygwin.com/ml/cygwin/2003-03/msg01623.html is a link to another recent GPL discussion where this is pointed out. Rob -- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. ---BeginMessage--- don`t see a problem with that - but perhaps you should initiate it. regards Roland PS: If I hear from you cygwin folks: take care of the gpl! If you don`t, we would like you to remove your package - I really would accept this decision because you made a great job with this software and you should decide - But I really think, there are also many people, which don`t take it that serious, as you do... The GPL is meant to PROTECT OpenSource software - but I don`t see anything that i`m doing bad things to OpenSource or to the Opensource Community - Far from it ! - Original Message - From: Robert Collins [EMAIL PROTECTED] To: roland [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 1:06 AM Subject: Re: Another GPL violation: Re: MinimalisticBuild-Environmentforwin32 (~7.5MB) ---End Message--- signature.asc Description: This is a digitally signed message part
Re: [avail for test] ncurses-5.3-1
Any comments on this, or should I just go-for-broke (literally) and mark it current? It's been over two weeks, and ncurses is in 'Base' ya know... --Chuck Charles Wilson wrote: I've placed updated versions of the ncurses packages on sourceware, but have marked them 'test'. In order to install them, you must use setup and pick the 'Exp'erimental radio button on the chooser. The new packages: ncurses-5.3-1 ncurses-demo-5.3-1 libncurses-devel-5.3-1 libncurses7-5.3-1 ncurses-5.3-1-src -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
I can jam cygwin in 2 minutes - can you?- Cannot fork: Permission denied jam
This relates to a bug in Win NT 2000 sp3 or cygwin- hard to say which. I can only exercise the bug in cygwin, but I would like to exercise it from command.exe- see below. Another user jammed cygwin in 183 iterations of the loop, after two days without a reboot. I am not alone. This script, crashme, will jam cygwin even faster than before- jam times are now down to about 2 minutes on my hardware! (less interaction with terminal- ha ha!) Wow. Otherwise, I can run all day unless I try to build some open source software. #! /bin/sh i=1 # 1 Infinite Loop /usr/bin/ps -al |grep PID while test $i != 0 do /usr/bin/ps -al | grep ps #PID value done (I have grep for Win NT and pslist (like ps, search for pstools in google), and I would like to run the above type script in command.exe. Can anyone translate the above into something that will run within command.exe? have pity...) Run the script in cygwin like this: ./crashme r7.txt 21 and after you reboot ;-} or ^C you will have a nice record of the PIDs used preceding the jam or ^C. I am trolling for similar problems on other peoples hardware, so here is some google bait: (email me if you want the whole 151K file) PIDPPIDPGID WINPID TTY UID STIME COMMAND 292828442844 2948 con 400 21:57:15 /usr/bin/ps 292028442844 2972 con 400 21:57:15 /usr/bin/ps 291228442844 2992 con 400 21:57:16 /usr/bin/ps 296428442844 3012 con 400 21:57:16 /usr/bin/ps 296828442844 3032 con 400 21:57:16 /usr/bin/ps 298828442844 3052 con 400 21:57:16 /usr/bin/ps ... 1090028442844 10964 con 400 21:57:45 /usr/bin/ps 1098028442844 10984 con 400 21:57:45 /usr/bin/ps 970028442844 11004 con 400 21:57:45 /usr/bin/ps 1096028442844 11024 con 400 21:57:45 /usr/bin/ps 1092028442844 11044 con 400 21:57:45 /usr/bin/ps 1100028442844 11064 con 400 21:57:45 /usr/bin/ps ... 1998028442844 20044 con 400 21:58:19 /usr/bin/ps 228442844 20064 con 400 21:58:19 /usr/bin/ps 2007228442844 20084 con 400 21:58:19 /usr/bin/ps 1974028442844 20104 con 400 21:58:19 /usr/bin/ps 2002028442844 20124 con 400 21:58:19 /usr/bin/ps ... 2468028442844 24744 con 400 21:58:36 /usr/bin/ps 2470028442844 24764 con 400 21:58:36 /usr/bin/ps 72428442844 24780 con 400 21:58:36 /usr/bin/ps 2478428442844 2272 con 400 21:58:37 /usr/bin/ps 2479228442844 24812 con 400 21:58:37 /usr/bin/ps 2481628442844 24832 con 400 21:58:37 /usr/bin/ps ... 3679228442844 36856 con 400 21:59:26 /usr/bin/ps 3681228442844 36876 con 400 21:59:26 /usr/bin/ps 6344 [main] ps 36832 winpids::enumNT: error 0xC005 reading system process information 6884 [main] ps 36744 winpids::enumNT: error 0xC005 reading system process information 6281 [main] ps 36852 winpids::enumNT: error 0xC005 reading system process information 2977 [main] ps 36892 winpids::enumNT: error 0xC005 reading system process information 6574 [main] ps 36972 winpids::enumNT: error 0xC005 reading system process information 6306 [main] ps 36932 winpids::enumNT: error 0xC005 reading system process information 2857 [main] ps 36952 winpids::enumNT: error 0xC005 reading system process information 2014 [main] ps 37024 winpids::enumNT: error 0xC005 reading system process information ./crashme: /usr/bin/ps: permission denied ./crashme: /usr/bin/ps: permission denied ./crashme: /usr/bin/ps: permission denied ./crashme: Cannot fork: Permission denied Notice that the PID and WINPID do not always increase monotonically- but damn close. Any debugging suggestions? This behaviour does not change if the heap_chunk_in_mb is increased to 256. $ regtool -i set /HKEY_LOCAL_MACHINE/SOFTWARE/Cygnus\ Solutions/Cygwin/heap_chunk_in_mb 256 $ regtool -v list /HKEY_LOCAL_MACHINE/SOFTWARE/Cygnus\ Solutions/Cygwin mounts v2\ (Cygwin) Program Options\ (cygnus) heap_chunk_in_mb = 0x0100 (256) If you encounter this problem on your hardware, please post to the list and send me your cygcheck output and crashme output. If people have had out of resource , failure to fork, or other such problems, this might be related and you can test it in 10 minutes. Then please post to the list. Anyone care to comment if these are related: http://sources.redhat.com/ml/cygwin/2002-02/msg01188.html http://sources.redhat.com/ml/cygwin/2002-07/msg01894.html http://sources.redhat.com/ml/cygwin/2002-05/msg01333.html http://sources.redhat.com/ml/cygwin/2002-02/msg01361.html http://sources.redhat.com/ml/cygwin/2002-02/msg00304.html
Re: Another GPL violation: Re: Minimalistic Build-Environmentforwin32(~7.5MB)
To dig into this, this will cost me HOURS ! And how many hours do you think went into setup, cygwin, and all of the ports? Any tips for an easy solution ? Uploading a few source tarballs to your website is a hell of lot easier than recoding everything from scratch. Remember, the GPL says that if you do not obey the license, ALL of your rights to use the software are REVOKED. Completely new cygwin setup ,corresponding striptease and packaging ? Come on - I have no time for just doing some satisfaction for a sheet of paper. That sheet of paper (and the tons of case law, the US Code, and international treaties [Berne Convention]) are all that keeps Microsoft from pulling an embrace-and-extend. It's all that prevents SCO from taking our work, and republishing it as their own (closed source) product -- (and maybe taking out a patent application and suing US for infringement 20 years later!) Did you follow the Xvid vs. Sigma Designs controversy? Sigma Designs stole the Xvid GPL'ed code and distributed it without sources (and even changed authorship strings in the code itself, it was later discovered). These things DO happen, and vigilant action -- even gentle reminders to the good guys -- are part of the process of keeping our weapons sharp for when we really need them. If I REALLY have to do this, I will take my website down and make rockbox people unhappy. This package was meant to make cygwin environment easier for the rockbox people - nobody depends on that - it`s just for comfort. Yes. You Really Do Have To Do This. If obeying the law is too much effort, then by all means take your package off the web. I imagine that will be much easier than dealing with the legal hassles continued infractions will bring (you ain't seen nuthin' 'til you've seen RMS go after a GPL violation; not that he'd do so in this case -- you'd be at the mercy of the Red Hat legal beagles.) What would be the consequence, if i wouldn`t take care of your advice ? Will I get a reminder? Yes, probably via certified mail or from the friendly man in the County Sherriff's uniform (that's how legal summons are delivered). I respect the GPL - but I also think, there could be a little freedom for interpretation. Huh? You mean like, Honestly, officer, 70mph doesn't really mean 7-0, does it? 85mph is close enough, right? There's room for 'interpretation'... Geez. If there WERE room for interpretation -- YOU don't get to choose the interpretation. The GPL has already been fully explained and interpreted by the people who wrote it -- see http://www.gnu.org/licenses/gpl-faq.html#TOCSourceAndBinaryOnDifferentSites It`s hard enough, that we have to fiddle around with ordinary and absurd laws and licensing terms the rest of our life Red herring. This is not hard at all; I do it all the time. When you do scp my-binary.tar.gz my.web.site you follow that immediately with scp my-source.tar.gz my.web.site Geez. And if, while developing, you find it difficult to keep track of sources so that the above two steps are hard -- you really need a better way to keep track of your development... the GPL is what got you cygwin in the first place. Any interpretation which conflicts with the GPL is not valid. If you don't like the licence, return the product! Actually, if you do not obey the GPL, you lose all rights to the product and are required to destroy your copy. Technically, the loss-of-right is permanent and irrevocable, unless reinstatement is authorized by the copyright holder. But most copyright holders are not sticklers for that -- they tend to automatically grant reinstatement as a matter of course, as long as the offenders correct the problem. But this is always and solely at the discretion of the copyright holder (in cygwin's case, Red Hat). ps: There must be HOUNDREDTHOUSANDS of people violating the gpl! That doesn't make it right. There are thousands of murders every year, millions of thefts, ... Hello Robert, I take GPL serious and didn`t see, that this is a problem. There are none so blind as those who WILL not see. If I hear from you cygwin folks: take care of the gpl! If you don`t, we would like you to remove your package - I really would accept this decision because you made a great job with this software and you should decide - But I really think, there are also many people, which don`t take it that serious, as you do... The GPL is meant to PROTECT OpenSource software - but I don`t see anything that i`m doing bad things to OpenSource or to the Opensource Community - Far from it ! I'm not sure about the context here...but taking care of the GPL is precisely what we're trying to do here. See, if Red Hat simply lets this one slide -- then when Microsoft comes along and steals the code, and buries it inside MSunixwin1.dll without releasing the source, Red Hat has no legal leg to stand on. MS can simply point out discriminatory enforcement and skate. You don't
Re: libtool 20030216: problem recognizing import libraries
Charles Wilson wrote: Okay, the patch I posted to libtool-patches works on my system (of course, the UNpatched libtool works on my system) -- but the patch ought to fix this problem. It hunts specifically for head.exe and uses that, if found, falling back to 'head' only if 'head.exe' is not found in the path. After a few iterations, somebody hit me on the head with a clue-by-4; a patch has been accepted into libtool CVS that fixes this problem. The patch? Don't use head. Instead, call sed -e '10q'. It's just as fast, and a far less intrusive change. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: texi2dvi problem, uname bug
Igor Pechtchanski writes: While you're correct in principle, wouldn't the above be a no-op under Cygwin anyway (unless your PATH has less than 3 entries in it)? Exactly and I had only 2 entries in PATH when I used it, hence the problem. Pascal. -- --|-- --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|-- --| http://perso.wanadoo.fr/pascal.obry --| The best way to travel is by means of imagination --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: System load question
Thanks for cleaning up the doubts. Jurgen Christopher Faylor [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 03/24/2003 04:19 PM Please respond to cygwin To: [EMAIL PROTECTED] cc: (bcc: Jurgen Defurne/BRG/CE/PHILIPS) Subject:Re: System load question Classification: On Mon, Mar 24, 2003 at 03:30:17PM +0100, [EMAIL PROTECTED] wrote: Does the loadavg work however ? No. cgf -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
procps and top output
Dear all, Thanks for the nice procps package. However, are all values always shown as megabytes ? When top or procps are used, the size on top, vsz on procps report extremely large, like this : 08:43:41 up 6 days, 19:52, 1 user, load average: 0.00, 0.00, 0.00 29 processes: 28 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 2.3% user, 5.0% system, 0.0% nice, 92.6% idle Mem:522476K total, 324552K used, 197924K free,0K buffers Swap: 1277020K total, 300224K used, 976796K free,0K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 2512 beq00871 8 0 412M 415644 R12.6 0.7 0:00 top 1552 beq00871 8 0 412M 417248 S 8.1 0.7 0:01 top 2456 beq00871 8 0 418M 751664 S 2.9 1.4 10:54 wmaker 712 beq00871 13 0 406M 441640 S 1.4 0.8 9:22 perl 1792 beq00871 8 0 418M 516484 S 1.4 0.9 0:01 rxvt 1764 beq00871 8 0 423M 21M52 S 1.4 4.2 9:58 XWin 1688 beq00871 8 0 418M 442456 S 1.4 0.8 0:00 xinit 2124 beq00871 8 0 398M 200048 S 1.4 0.3 0:00 pdksh 1852 beq00871 8 0 418M 517284 S 1.4 0.9 0:02 rxvt 1444 beq00871 8 0 398M 159644 S 0.7 0.3 0:00 sh 1364 beq00871 8 0 404M 281628 S 0.7 0.5 0:00 sshd 2460 beq00871 8 0 420M 592048 S 0.7 1.1 0:53 perl 1304 beq00871 8 0 398M 159248 S 0.7 0.3 0:00 sh 1584 beq00871 8 0 416M 524060 S 0.7 1.0 0:01 xclock 1696 beq00871 8 0 418M 515684 S 0.7 0.9 0:02 rxvt 1136 beq00871 13 0 407M 275636 S 0.7 0.5 0:01 boa 2028 beq00871 8 0 398M 164448 S 0.7 0.3 0:00 sh 1984 beq00871 8 0 398M 339648 S 0.7 0.6 0:00 grotty It seems that the RSS values are OK, they are from the same order as on Linux, however the SIZE value is extremely large. Has anybody an explanation ? Jurgen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
