Re: setup RFC: Ditch homegrown http/ftp code and use a library?
Robert Collins wrote: Huh? Doing what I suggest has nothing to do with the # of connections, the protocol supports it completely. It might, if you are spawning rsync locally each time, with the file list option, you could (easily) add a new file destination list, and that would provide the single connection, custom basis approach. Huh? Do yo mean using the new batch mode, with --read-batch and --write-batch? I don't think I understand in which way you mean to accomplish it... Probably I have overlooked the full usefulness of some command line option... -- Lapo Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796)
[UPDATE] base-files
Changes:
3.1-3
* Change cd ${HOME} functionality for CHERE - Dave Kilroy
3.1-2
* Fix for zsh/ksh - Tero Niemela
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.1-3.tar.bz2
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint
Please upload at your earliest convenience.
J.
Re: [UPDATE] base-files
On Sun, Nov 14, 2004 at 07:37:07PM -, John Morrison wrote:
Changes:
3.1-3
* Change cd ${HOME} functionality for CHERE - Dave Kilroy
3.1-2
* Fix for zsh/ksh - Tero Niemela
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.1-3.tar.bz2
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint
Please upload at your earliest convenience.
Done.
Deleted base-files-2.6-1.tar.bz2 and base-files-3.0-2.tar.bz2.
cgf
Re: [UPDATE] base-files
On Sun, Nov 14, 2004 at 07:37:07PM -, John Morrison wrote:
Changes:
3.1-3
* Change cd ${HOME} functionality for CHERE - Dave Kilroy
3.1-2
* Fix for zsh/ksh - Tero Niemela
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-3.1-3.tar.bz2
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum
http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint
Please upload at your earliest convenience.
Done.
Deleted base-files-2.6-1.tar.bz2 and base-files-3.0-2.tar.bz2.
Wow! Thanks Chris that was fast :)
J.
Please upload: startup-notification-0.8-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please upload this at your earliest convienence. http://cygwin-ports.sourceforge.net/install/temp/startup-notification/startup-notification-0.8-1-src.tar.bz2 http://cygwin-ports.sourceforge.net/install/temp/startup-notification/startup-notification-0.8-1.tar.bz2 Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBmC3TpiWmPGlmQSMRAnRMAJ0dr0bjbI2B4ByYKGvOs7AAjlhIHgCgy0SJ 0Ds/2T/GjJQ2HWX94FIK6BE= =HKND -END PGP SIGNATURE-
Re: Please upload: startup-notification-0.8-1
Yaakov Selkowitz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please upload this at your earliest convienence. http://cygwin-ports.sourceforge.net/install/temp/startup-notification/startup-notification-0.8-1-src.tar.bz2 http://cygwin-ports.sourceforge.net/install/temp/startup-notification/startup-notification-0.8-1.tar.bz2 Done and I changed the category to Gnome. Gerrit -- =^..^=
Re: Mozilla patch
Ok, I think I will be able to compile tonight. Will give you news at max monday. After that, what do you want me to examine ? Bruno
Re: Mozilla patch
bruno patin wrote: Ok, I think I will be able to compile tonight. Will give you news at max monday. After that, what do you want me to examine ? I the build of the debugging version succeeds, it would be nice if I could get my hands on it, I still have no success building a debugging version. BTW, please change --enable-strip to --disable-strip in the file '.mozconfig' in the top-level soucre directory, because a stripped debugging version is pretty useless. Gerrit -- =^..^=
Re: Mozilla patch
Gerrit P. Haase wrote: bruno patin wrote: Ok, I think I will be able to compile tonight. Will give you news at max monday. After that, what do you want me to examine ? I the build of the debugging version succeeds, it would be nice if I If your build ... could get my hands on it, I still have no success building a debugging version. BTW, please change --enable-strip to --disable-strip in the file '.mozconfig' in the top-level soucre directory, because a stripped debugging version is pretty useless. Currently I'm trying to build from the tarball which was released as mozilla-1.8a5 since the daily snapshot from yesterday doesn't produce a running executable at all. Gerrit -- =^..^=
Re: Mozilla patch
Gerrit P. Haase wrote: bruno patin wrote: Ok, I think I will be able to compile tonight. Will give you news at max monday. After that, what do you want me to examine ? I the build of the debugging version succeeds, it would be nice if I could get my hands on it, I still have no success building a debugging version. BTW, please change --enable-strip to --disable-strip in the file '.mozconfig' in the top-level soucre directory, because a stripped debugging version is pretty useless. Gerrit If you want a debugging version we also have to use the --enable-debug option no ? So here my complete mozilla command. #!/bin/sh export CC=ccache gcc export CXX=ccache g++ export MOZ_INTERNAL_LIBART_LGPL=1 export MOZILLA_OFFICIAL=1 mkdir -p mozilla/.build cd mozilla/.build ../configure --prefix=/usr --enable-debug --enable-debug --disable-strip 21 | tee ../log.conf make 21 | tee ../log.make
Re: Mozilla patch
bruno patin wrote: Gerrit P. Haase wrote: bruno patin wrote: Ok, I think I will be able to compile tonight. Will give you news at max monday. After that, what do you want me to examine ? I the build of the debugging version succeeds, it would be nice if I could get my hands on it, I still have no success building a debugging version. BTW, please change --enable-strip to --disable-strip in the file '.mozconfig' in the top-level soucre directory, because a stripped debugging version is pretty useless. Gerrit If you want a debugging version we also have to use the --enable-debug option no ? So here my complete mozilla command. This looks wrong: .../configure --prefix=/usr --enable-debug --enable-debug --disable-strip Just two dots to refer to the upper next dirctory! But don't specify options with the configure command! Add or remove or change settings in the .mozconfig file in the toplevel source directory so it will be included ion the patch files and it is safe. I only specify --prefix with the configure command since these are user options, eg. you can specify --prefix/opt/mozilla here. Gerrit -- =^..^=
Re: xorg installation fails, 99% complete only
Christopher Faylor cgf-no-personal-reply-please at cygwin.com writes: On Tue, Nov 09, 2004 at 04:31:53PM +, Roboco Sanchez wrote: The setup.exe should do the installation job properly. [snip] As for what our two develpers said, I do respect them for what they do for us but I wouldn't tell my users to shut up like that. Being a volunteer doing things for people for free doesn't give you the right to do that. Did you *read* what Bobby said about Alexander? Why didn't you jump to Alexander's defense if you respect him so much? Or does being a user of free software does give someone the right to insult a developer? That seems pretty one-sided to me. Yes, I did read what Bobby said. His post wasn't meant for Alexander. He was responding to Daniel who previously just wanted to add something to the discussion. From my view it was meant for the users and for the Cygwin team or the management not a particular developer. Like I said I think what Bobby said was perfectly all right and reasonable. I was also adding something the the discussion just like Daniel did. I saw what he added as useful to both users and developers. To users it indicated that there was some problem with the installation so everyone should be aware of. To developers this problem should be investigated and fixed. Also to developers he referred to a previous developer who he thought did a better job. Now I can understand most people would be upset if anyone tell you they think someone did or can do a better job but if I was a developer here I would just listen to what Bobby said, be open-minded, and think, because he might be right. I have been installing/using Cygwin for years and this is the first time I have a problem. I thought Bobby might be thinking the same thing before suggested that. You need the users and the users need you. You somehow think that there is a flow of obligation going from me to you? You're very wrong. You are benefitting from my efforts and Alexander's efforts. I am not benefitting from your efforts in any way. That is not true of some users here who are capable of sending bug reports or providing constructive feedback without pontificating. Since I care about cygwin, I do appreciate when people can provide feedback without whining and without insulting the people who have donated their time to help them. You have no rights here. Sorry. I was talking about users and developers in general. I didn't say that you needed me. I said that you needed the users. But since you have shown your typical developer attitude I should make this point clearer. Every user of your free software has contributed somehow to your project. They don't have to be here to show that they are contributing. Just if they download and install and use your software is enough. Why? These people although they don't come here to praise you or give their supports to you when they don't find bugs/problems in your software they are still helping you testing the software for you. Their absence here tells that the software works for them althouth some just don't bother to come here no matter they found a problem or they have fixed it themselves or maybe they are in some other places like IRC channels, forums, usenet, etc. As for those who come posting questions, they may not be capable of sending bug reports or providing constructive feedback without pontificating in your eyes but they are making contribution to your project. Not all of them really need help. Some are just reporting bugs/problems so that they can be fixed and everyone can be happy both users and developers. I was in this type of users when I was confirming this problem. You said that I'm benefitting from your efforts and Alexander's efforts, that is ture. But when you said you are not benefitting from my efforts in any way, that is not true. I spent time and efforts to download files and test the installation and I spent time to report that here. Should I have to go through all this had the setup.exe worked properly? No. I didn't really need those X components from Cygwin I only needed the C compiler and I usually do install everything when I install any software. I found the problem so I came here and found other users with the same problem then I did more tests in order to confirm the problem here. I don't mind you are not appreciating what I did but I want you not to forget that this type of users does exist and you will appreciate their efforts or not is up to you but you should never underestimate their efforts. They may well call that an insult to them. It is simple, you either do it your best or you don't do it at all. Sorry, but that is simple-minded pap. How can you judge what someone's best is? So, if I can't give cygwin 100% of my effort, I should just abandon it? Ridiculous. Everyone knows what their best is. No one is judging. Best doesn't mean 100% effort. No, you
Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.
At 12:11 AM 11/14/2004 -0500, Christopher Faylor wrote: When you first mentioned this, I had an idea that maybe we could be waiting on something else besides a process handle which would be inherited by any subprocesses. I thought that maybe we could somehow use a mutex but there would always be a period when you'd have to do some tricky synchronization to make sure that the child gets to lock the mutex but the parent doesn't. I don't know how many times I have wished for a non-process handle that would become signalled when a process exits. So, today, it occurred to me that pipes could come to the rescue again. If we opened a pipe and put the write end in every child process, the parent could wait on the read end of the pipe. When the last child process dies, the parent would wake up and do what it does now. At first, I was hoping that pipes would work correctly when called with WaitFor* and we could just drop pipe handles in there. Of course, it can't be that simple and I really should have known that wouldn't work. I think I have tried this technique about twice a year since 1998. Instead, you have to use ReadFile in a thread. So, the children would gain an extra open handle, the parent would get some new threads. But the parent would be able to track A LOT more subprocesses than the current 63. That would be the key advantage of this approach. Do you have a way (async I/O?) to avoid having one thread per child? BTW, have you ever tried using select, having a connection from the parent to the child? I just implemented most of this and it seems to work ok. One side effect of this technique is that any subprocess created with CreateProcess will also inherit the pipe and so, a parent cygwin process will wait for all of the processes created with CreateProcess. I'm not sure if I really care about that, though. The other negative side effect is the overhead of creating a pipe and a thread. I don't think this is noticeable and this technique eliminates some overhead in cygwin, too. It's not exactly a wash, but I'm hoping it won't be too bad, regardless. When I get the code to a point that it can run configure, I'll do a benchmark and see how bad this technique is. If there is not a noticeable degradation, I think I'll probably duplicate the scenario of last year and checkin this revamp which, I believe will eliminate the security problem that you were talking about. There is also the case where a setuid child needs to signal its parent. That's another use of my ppid_waitsig, avoiding the PROCESS_DUP_HANDLE issue. Could your end of pid pipe be used to transmit signals, with the reader thread forwarding the sigpacket to the local sigthread? Pierre
Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.
At 01:03 PM 11/14/2004 -0500, Christopher Faylor wrote: On Sun, Nov 14, 2004 at 12:34:30PM -0500, Pierre A. Humblet wrote: At 12:11 AM 11/14/2004 -0500, Christopher Faylor wrote: BTW, have you ever tried using select, having a connection from the parent to the child? select involves polling or setting up other events to track end-of-pipe conditions. I don't think that's a win. I meant the Windows select, on sockets. When I get the code to a point that it can run configure, I'll do a benchmark and see how bad this technique is. If there is not a noticeable degradation, I think I'll probably duplicate the scenario of last year and checkin this revamp which, I believe will eliminate the security problem that you were talking about. There is also the case where a setuid child needs to signal its parent. That's another use of my ppid_waitsig, avoiding the PROCESS_DUP_HANDLE issue. Could your end of pid pipe be used to transmit signals, with the reader thread forwarding the sigpacket to the local sigthread? It could but that's not its intent. It's used now to transmit stop/continue state but if you need to send a signal from parent to child, I don't think it makes sense to relay it through this mechanism. Then something else is needed. An advantage of the relay is that it could allow only stop/continue to pass through. The ppid_waitsig lets all signals go through. Pierre
Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.
On Sun, Nov 14, 2004 at 01:23:59PM -0500, Pierre A. Humblet wrote: At 01:03 PM 11/14/2004 -0500, Christopher Faylor wrote: On Sun, Nov 14, 2004 at 12:34:30PM -0500, Pierre A. Humblet wrote: At 12:11 AM 11/14/2004 -0500, Christopher Faylor wrote: BTW, have you ever tried using select, having a connection from the parent to the child? select involves polling or setting up other events to track end-of-pipe conditions. I don't think that's a win. I meant the Windows select, on sockets. Use sockets rather than pipes? Given all of the problems that we have with sockets, I don't think we want to go down that path. cgf
Cygwin has two ROOT tree strcutures and the old one is not the default anymore.
I have two root directory structures (both with usr, bin, etc, ...). One under the standard C:\cygwin ( i.e. /cygdrive/c/cygwin) and the other under C:\cygwin\download (i.e. /cygdrive/c/cygwin/download). When I enquire about the default bin location here is the reply: $ which ls /usr/bin/ls Here is what leads to it. The last couple of days I had a problem with several DLLs (linintl-1.dll, cygwin DLL, ) when I was trying to install new components. At the same time, ls and most command stopped working on a bash shell, except few like cd and pwd. Although it seemed slightly better when I redefined the default path to the bin directory with PATH=/usr/local/bin:/usr/bin:/bin:$PATH, ls on /usr/bin directory prompted more complaints on missing dlls. It felt as if a lot of the env parameter where not defined and cygwin totally incapacitated. I re-installed the libraries which were reported missing, even though there were present in their respective directory. Out of frustration I re-installed the entire base Cygwin and most of the libraries and dev components. Now, everything seems working except that I have two directory structures, and the libraries and source code I compiled are in the depreciated structure. Did I break my cygwin? Can I salvage my old structure in order to save all that I had organized and compiled in it (lots of hours)? Many thanks in advance for your help and suggestions, Donat-Pierre P.s.: I attached a cygcheck.out file for further details (i.e. generated with cygcheck -s -v r ). Cygwin Configuration Diagnostics Current System Time: Sat Nov 13 22:37:06 2004 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Path: C:\cygwin\download\usr\local\bin C:\cygwin\download\bin C:\cygwin\download\bin C:\cygwin\download\usr\X11R6\bin c:\WINNT\system32 c:\WINNT c:\WINNT\System32\Wbem c:\Program Files\Common Files\Adaptec Shared\System c:\Program Files\IVI\bin c:\VXIPNP\WinNT\Bin c:\Program Files\Microsoft SQL Server\80\Tools\Binn\ Output from C:\cygwin\download\bin\id.exe (nontsec) UID: 11796(luigi) GID: 10545(mkgroup-l-d) 10545(mkgroup-l-d) Output from C:\cygwin\download\bin\id.exe (ntsec) UID: 11796(luigi) GID: 10545(mkgroup-l-d) 0(root) 544(Administrators) 545(Users) 10545(mkgroup-l-d) SysDir: C:\WINNT\system32 WinDir: C:\WINNT HOME = `c:\Documents and Settings\luigi' MAKE_MODE = `unix' PWD = `/cygdrive/c/cygwin/download' USER = `luigi' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\luigi\Application Data' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `ICTPRODS1' COMSPEC = `C:\WINNT\system32\cmd.exe' CVS_RSH = `/bin/ssh' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\luigi' HOSTNAME = `ictprods1' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' LOGONSERVER = `\\ICTPRODS1' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man:/usr/X11R6/man' NIDAQMXSWITCHDIR = `C:\Program Files\National Instruments\NI-DAQ\Switch\' NUMBER_OF_PROCESSORS = `1' OLDPWD = `/cygdrive/c/cygwin' OS2LIBPATH = `C:\WINNT\system32\os2\dll;' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig' PRINTER = `\\http://xwing.ict.usc.edu:631\Canon iR5000-6000-L1 PS Ver 1.0' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 7, GenuineIntel' PROCESSOR_LEVEL = `15' PROCESSOR_REVISION = `0207' PROGRAMFILES = `C:\Program Files' PROMPT = `$P$G' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINNT' TEMP = `C:\DOCUME~1\luigi\LOCALS~1\Temp' TERM = `cygwin' TMP = `C:\DOCUME~1\luigi\LOCALS~1\Temp' USERDNSDOMAIN = `ict.usc.edu' USERDOMAIN = `ICT2000' USERNAME = `luigi' USERPROFILE = `C:\Documents and Settings\luigi' VXIPNPPATH = `C:\VXIPNP\' WINDIR = `C:\WINNT' _ = `/usr/bin/cygcheck' POSIXLY_CORRECT = `1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin\download' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin\download/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin\download/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
sometimes resource alters but version numbers don't
Hi, Recently 23 files *.tar.bz2 under release/X11/ altered and so did the matching md5sums in setup.ini. (So these were real changes, not just a case of a buggy setup.ini catching up with release/.) However the version numbers did not alter, and so users with the earlier download i.j.old are not updated to i.j.new. In some sense this must matter, otherwise the substitution would not have been made or the version numbers would have been incremented. There are precedents for this, not under X11/, and anyway it seems to me to be a setup issue not specifically cygwin-x. A while ago there were objections posted to this list along the lines oh God, another day, another version of xemacs and I can see that there is a class of improvements (spelling, minor packaging, ...) that do not really make a new download worthwhile, let alone essential. Obviously maintainers can behave as they want, and maybe uploading to the mirrors is the best way of making sure such improvements are not forgotten, but it does lead to some disconcerting mismatches for those sad nutcases (e.g. me) who spend far too much time on housekeeping. Have I described correctly what has happened here (minor improvements) or has something actually gone wrong with setup.ini - release/X11/? Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sometimes resource alters but version numbers don't
fergus schrieb: Recently 23 files *.tar.bz2 under release/X11/ altered and so did the matching md5sums in setup.ini. (So these were real changes, not just a case of a buggy setup.ini catching up with release/.) However the version numbers did not alter, and so users with the earlier download i.j.old are not updated to i.j.new. In some sense this must matter, otherwise the substitution would not have been made or the version numbers would have been incremented. There are precedents for this, not under X11/, and anyway it seems to me to be a setup issue not specifically cygwin-x. A while ago there were objections posted to this list along the lines oh God, another day, another version of xemacs and I can see that there is a class of improvements (spelling, minor packaging, ...) that do not really make a new download worthwhile, let alone essential. Obviously maintainers can behave as they want, and maybe uploading to the mirrors is the best way of making sure such improvements are not forgotten, but it does lead to some disconcerting mismatches for those sad nutcases (e.g. me) who spend far too much time on housekeeping. Have I described correctly what has happened here (minor improvements) or has something actually gone wrong with setup.ini - release/X11/? that explains something. that could have been caught by an improved upset. unfortunately the maintainer doesn't accept patches. http://cygwin.com/ml/cygwin-apps/2004-10/msg00560.html -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: slightly different cygwin installation problem
Daniel Newhouse wrote: I installed all the cygwin packages except for the X11 packages (I set the X11 packages to uninstall) and although I installed successfully there were a couple of errors in the installation procedure. I got an error message (in a Windows error message box) at one point telling me that it couldn't run something because the x11 dll was not found. There are some packages requireing X11, ie. gtk2-x11. Running the gtk2 postinstallscript requires X11 too. After okaying that it progressed to /etc/postinstall/post-texinf.sh where it hung for a few minutes until I got another error message where it said This application could not run because #.dll was not found. I didn't write down what dll it was, but it wasn't the x11 dll. You can easy check this, run the postinstall script again from the command line before installing X11: $ sh /etc/postinstall/post-texinf.sh.done Also, and someone else mentioned this, if I download the packages first and then try to run the installation from a local directory - it doesn't work. Should make no difference, yes. Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: new cygwin has memory problems?
In regards to adding code to support coLinux, I don't see why that would be neccessary. coLinux doesn't need to talk to cygwin. Except for older versions, coLinux is not built on cygwin. If someone is really interested, as part of the coLinux tools I wrote set of functions for querying cygwin paths from a non-cygwin executable. It does so by calling a cygwin executable to convert paths. If the executable fails, it assumes the cygwin.dll has not been installed. I would not recommend adding it to cygwin, because it would be pointless. If you know someone has installed cygwin to install the tool, then there is no reason not to link to the cygwin.dll directly. However, the tool is open source, so people are free to use it for their non-cygwin, but cygwin compatible open source projects. Bill On Sat, 13 Nov 2004 12:38:32 -0500, Christopher Faylor [EMAIL PROTECTED] wrote: On Sat, Nov 13, 2004 at 01:07:03PM +0100, Reini Urban wrote: Christopher Faylor schrieb: On Fri, Nov 12, 2004 at 05:58:00PM +0100, Gerrit P. Haase wrote: Christopher Faylor wrote: Hey cool, you have top? $ top bash: top: command not found Where can I get it? http://cygwin.com/cgi-bin2/package-cat.cgi?file=procps%2Fprocps-010801-2grep=top%5C.exe I really need to install this package, thanks. Just to fruitlessly stifle the next question from anyone else who has just found out about this package: No, there is no way to make top or procps display non-cygwin processes. For everything there's a way. The question is if it's worth the effort. For example I'm now seriously considering exporting a procfs to native windows, just to play with installable filesystems. I didn't say it was impossible. It's not even hard. It just doesn't work now. To improve mount and to get cygwin better talk to colinux. I don't think we want to add any colinux features to cygwin. Maybe Corinna will disagree but I don't see any reason to add one byte of extra code to cygwin to handle colinux. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
icecast
Hello,
i want to compile icecast under cygwin.
./configure works fine, but it produces this warning:
checking winsock2.h usability... no
checking winsock2.h presence... yes
configure: WARNING: winsock2.h: present but cannot be compiled
configure: WARNING: winsock2.h: check for missing prerequisite headers?
configure: WARNING: winsock2.h: proceeding with the preprocessor's
result
configure: WARNING: ## ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ## ##
checking for winsock2.h... yes
Make exit with this error:
In file included from sock.h:28,
from sock.c:58:
/usr/include/w32api/winsock2.h:95:2: warning: #warning fd_set and
associated ma
cros have been defined in sys/types. This may cause runtime
problems with W
32 sockets
In file included from sock.h:28,
from sock.c:58:
/usr/include/w32api/winsock2.h:101: error: redefinition of `struct
timeval'
/usr/include/w32api/winsock2.h:112: error: redefinition of `struct
hostent'
/usr/include/w32api/winsock2.h:120: error: redefinition of `struct
linger'
/usr/include/w32api/winsock2.h:147: error: redefinition of `struct
netent'
/usr/include/w32api/winsock2.h:153: error: redefinition of `struct
servent'
/usr/include/w32api/winsock2.h:159: error: redefinition of `struct
protoent'
/usr/include/w32api/winsock2.h:215: error: redefinition of `struct
in_addr'
/usr/include/w32api/winsock2.h:246: error: redefinition of `struct
sockaddr_in'
/usr/include/w32api/winsock2.h:327: error: redefinition of `struct
sockaddr'
/usr/include/w32api/winsock2.h:515: error: conflicting types for
`accept'
/usr/include/sys/socket.h:29: error: previous declaration of `accept'
/usr/include/w32api/winsock2.h:516: error: conflicting types for `bind'
/usr/include/sys/socket.h:30: error: previous declaration of `bind'
/usr/include/w32api/winsock2.h:518: error: conflicting types for
`connect'
/usr/include/sys/socket.h:31: error: previous declaration of `connect'
/usr/include/w32api/winsock2.h:520: error: conflicting types for
`getpeername'
/usr/include/sys/socket.h:32: error: previous declaration of
`getpeername'
/usr/include/w32api/winsock2.h:521: error: conflicting types for
`getsockname'
/usr/include/sys/socket.h:33: error: previous declaration of
`getsockname'
/usr/include/w32api/winsock2.h:522: error: conflicting types for
`getsockopt'
/usr/include/sys/socket.h:44: error: previous declaration of
`getsockopt'
/usr/include/w32api/winsock2.h:523: error: conflicting types for
`inet_addr'
/usr/include/arpa/inet.h:22: error: previous declaration of `inet_addr'
/usr/include/w32api/winsock2.h:524: error: conflicting types for
`inet_ntoa'
/usr/include/arpa/inet.h:28: error: previous declaration of `inet_ntoa'
/usr/include/w32api/winsock2.h:525: error: conflicting types for
`listen'
/usr/include/sys/socket.h:34: error: previous declaration of `listen'
/usr/include/w32api/winsock2.h:526: error: conflicting types for `recv'
/usr/include/sys/socket.h:35: error: previous declaration of `recv'
/usr/include/w32api/winsock2.h:527: error: conflicting types for
`recvfrom'
/usr/include/sys/socket.h:37: error: previous declaration of `recvfrom'
/usr/include/w32api/winsock2.h:528: error: conflicting types for `send'
/usr/include/sys/socket.h:39: error: previous declaration of `send'
/usr/include/w32api/winsock2.h:529: error: conflicting types for
`sendto'
/usr/include/sys/socket.h:42: error: previous declaration of `sendto'
/usr/include/w32api/winsock2.h:530: error: conflicting types for
`setsockopt'
/usr/include/sys/socket.h:43: error: previous declaration of
`setsockopt'
/usr/include/w32api/winsock2.h:531: error: conflicting types for
`shutdown'
/usr/include/sys/socket.h:45: error: previous declaration of `shutdown'
/usr/include/w32api/winsock2.h:532: error: conflicting types for
`socket'
/usr/include/sys/socket.h:46: error: previous declaration of `socket'
/usr/include/w32api/winsock2.h:533: error: conflicting types for
`gethostbyaddr'
/usr/include/netdb.h:139: error: previous declaration of `gethostbyaddr'
/usr/include/w32api/winsock2.h:534: error: conflicting types for
`gethostbyname'
/usr/include/netdb.h:140: error: previous declaration of `gethostbyname'
/usr/include/w32api/winsock2.h:535: error: conflicting types for
`getservbyport'
/usr/include/netdb.h:149: error: previous declaration of `getservbyport'
/usr/include/w32api/winsock2.h:536: error: conflicting types for
`getservbyname'
/usr/include/netdb.h:148: error: previous declaration of `getservbyname'
/usr/include/w32api/winsock2.h:537: error: conflicting types for
`getprotobynumb
er'
/usr/include/netdb.h:146: error: previous declaration of
`getprotobynumber'
/usr/include/w32api/winsock2.h:538: error: conflicting types for
`getprotobyname
'
/usr/include/netdb.h:145: error: previous declaration of
`getprotobyname'
/usr/include/w32api/winsock2.h:607: error: parse error before '(' token
Re: [ANNOUNCEMENT] Updated: libxml2-2.6.13-1
Gerrit P. Haase schrieb: Libxml2 has been updated to version 2.6.16 NEWS There was a bug in the 'xmlcatalog' program in version 2.6.13 of Libxml2, it is strongly recommended to upgrade as soon as possible to libxml2-2.6.16. The Cygwin Libxml2 distribution consists now of four separate packages, the main package 'libxml2' contains the runtime library and the executables 'xmlcatalog' and 'xmllint', the import library and the headers are in the package 'libxml2-devel', the Python bindings and according docs and examples are in the package 'libxml2-python' and the Libxml2 documentation has its own package now: 'libxml2-doc'. Hi Gerrit Marcel, lovely. This works (almost) as expected ;) The group elements don't get lost anymore. Unfortunately, the xml:base parameter in the group element is ignored when updating the catalog, and I end up with my relative path being substituted with an absolute one. But that's Marcel's plate again :) Can the postinstall script test whether an element is already available and replace only the relevant part, ie. make the replace parameter of the xmlcatalog --add command variable? Hm, I can see, that making this work in all cases can easily become nasty. Alternatively, you could add a note to future announcements... Anyway, thanks for your quick response and good work. Patrick -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: icecast
At 07:06 AM 11/14/2004, Bernhard Janetzki wrote: Hello, i want to compile icecast under cygwin. ./configure works fine, but it produces this warning: checking winsock2.h usability... no checking winsock2.h presence... yes configure: WARNING: winsock2.h: present but cannot be compiled configure: WARNING: winsock2.h: check for missing prerequisite headers? configure: WARNING: winsock2.h: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## checking for winsock2.h... yes Make exit with this error: In file included from sock.h:28, from sock.c:58: /usr/include/w32api/winsock2.h:95:2: warning: #warning fd_set and associated ma cros have been defined in sys/types. This may cause runtime problems with W 32 sockets In file included from sock.h:28, from sock.c:58: Do you have autoconf installed? I don't see the usual echo in the log where it should test for presence of autoconf and report whether it is working. If autoconf is present, this configure script may be tripping up over the presence of unistd.h along with w32api. It says they conflict. I don't see how you could say it is working fine. Tim Prince -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: icecast
Hi Bernie, Bernhard Janetzki wrote: Hello, i want to compile icecast under cygwin. ./configure works fine, but it produces this warning: checking winsock2.h usability... no checking winsock2.h presence... yes configure: WARNING: winsock2.h: present but cannot be compiled configure: WARNING: winsock2.h: check for missing prerequisite headers? configure: WARNING: winsock2.h: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## checking for winsock2.h... yes This is not an autoconf problem: In file included from configure:19744: /usr/include/w32api/winsock2.h:614: error: conflicting types for `gethostname' /usr/include/sys/unistd.h:205: error: previous declaration of `gethostname' Don't use winsock2.h when you compile a Cygwin application, comment the relevant parts in the source where winsock2.h is included and try to compile again. Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sometimes resource alters but version numbers don't
On Sun, Nov 14, 2004 at 12:30:57PM +0100, Reini Urban wrote: fergus schrieb: Recently 23 files *.tar.bz2 under release/X11/ altered and so did the matching md5sums in setup.ini. (So these were real changes, not just a case of a buggy setup.ini catching up with release/.) However the version numbers did not alter, and so users with the earlier download i.j.old are not updated to i.j.new. In some sense this must matter, otherwise the substitution would not have been made or the version numbers would have been incremented. There are precedents for this, not under X11/, and anyway it seems to me to be a setup issue not specifically cygwin-x. A while ago there were objections posted to this list along the lines oh God, another day, another version of xemacs and I can see that there is a class of improvements (spelling, minor packaging, ...) that do not really make a new download worthwhile, let alone essential. Obviously maintainers can behave as they want, and maybe uploading to the mirrors is the best way of making sure such improvements are not forgotten, but it does lead to some disconcerting mismatches for those sad nutcases (e.g. me) who spend far too much time on housekeeping. Have I described correctly what has happened here (minor improvements) or has something actually gone wrong with setup.ini - release/X11/? that explains something. that could have been caught by an improved upset. unfortunately the maintainer doesn't accept patches. http://cygwin.com/ml/cygwin-apps/2004-10/msg00560.html As hard as this is to believe, the changes to X11 packages were discussed (drum roll please) ON THE cygwin-xfree list! Can you believe it? What are the odds? The reason that the version numbers did not change is that the contents of the packages did not change. The .tar.bz2 files were repacked in a different order to see if this solved an installation problem. There is no need for anyone to download these new packages. There was nothing untoward to detect here, no need for an improved upset, and no need to panic. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin has two ROOT tree strcutures and the old one is not the default anymore.
At 05:42 AM 11/14/2004, you wrote: I have two root directory structures (both with usr, bin, etc, ...). One under the standard C:\cygwin ( i.e. /cygdrive/c/cygwin) and the other under C:\cygwin\download (i.e. /cygdrive/c/cygwin/download). When I enquire about the default bin location here is the reply: $ which ls /usr/bin/ls Here is what leads to it. The last couple of days I had a problem with several DLLs (linintl-1.dll, cygwin DLL, ) when I was trying to install new components. At the same time, ls and most command stopped working on a bash shell, except few like cd and pwd. Although it seemed slightly better when I redefined the default path to the bin directory with PATH=/usr/local/bin:/usr/bin:/bin:$PATH, ls on /usr/bin directory prompted more complaints on missing dlls. It felt as if a lot of the env parameter where not defined and cygwin totally incapacitated. I re-installed the libraries which were reported missing, even though there were present in their respective directory. Out of frustration I re-installed the entire base Cygwin and most of the libraries and dev components. Now, everything seems working except that I have two directory structures, and the libraries and source code I compiled are in the depreciated structure. Did I break my cygwin? Can I salvage my old structure in order to save all that I had organized and compiled in it (lots of hours)? Many thanks in advance for your help and suggestions, Donat-Pierre P.s.: I attached a cygcheck.out file for further details (i.e. generated with cygcheck -s -v r ). Looks like everything now points to your 'C:\cygwin\download' directory, so that's apparently where you reinstalled. If this is really the directory that you specified in 'setup.exe' as the place to put your downloaded packages (during the install), then I'd really recommend that you choose a different directory. The download directory is where 'setup.exe' puts the packages it downloads and it assumes it can do anything it wants/needs with this directory. Installing to this same directory is not recommended. As for things you've built locally that are not part of your currently installed Cygwin tree, you can move or copy them wherever you like or is convenient. There's nothing magical about the root directory (or the directory structure in general really). If you copy/move things you've built, untar'd, etc, from your deprecated tree to the current install tree, I don't foresee any obvious problems. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: libxml2-2.6.13-1
Hi. On Sun, Nov 14, 2004 at 04:20:07PM +0100, Patrick Eisenacher wrote: Unfortunately, the xml:base parameter in the group element is ignored when updating the catalog, and I end up with my relative path being substituted with an absolute one. But that's Marcel's plate again :) Can the postinstall script test whether an element is already available and replace only the relevant part, ie. make the replace parameter of the Why do you need to modify entry in /etc/xml/catalog for docbook-xml2 and/or docbook-xsl packages? If you want/need these packages then you should leave the package to do his job. The package itself know where it is installed and /etc/xml/catalog is set up properly. If you need to modify /etc/xml/catalog entry for docbook-xml42/xsl then you can't use precompiled packages from Cygwin distribution and you should instal DTDs and/or XSLT stylesheets from source. Or, am I missed something? xmlcatalog --add command variable? Hm, I can see, that making this work in all cases can easily become nasty. Alternatively, you could add a note to future announcements... Regards. -- +---+ | Marcel Telka e-mail: [EMAIL PROTECTED] | |homepage: http://telka.sk/ | |jabber: [EMAIL PROTECTED] | +---+ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] [ANNOUNCEMENT] Update: base-files
Changes:
3.1-3
* Change cd ${HOME} functionality for CHERE - Dave Kilroy
3.1-2
* Fix for zsh/ksh - Tero Niemela
Please direct all comments and questions to the cygwin list.
J.
** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe: tag in the email header of this message.
Send email to the address specified there. It will be in the format:
[EMAIL PROTECTED]
If you need more information on unsubscribing, start reading here:
http://sources.redhat.com/lists.html#unsubscribe-simple
Please read *all* of the information on unsubscribing that is available
starting at this URL.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Cygwin has two ROOT tree strcutures and the old one is not the default anymore.
Larry, Thanks for your reply. C:\cygwin\download has always been the one used for Setup on my system, and it only created havoc when I re-installed base and library packages. It was supposed to be on the place to store the installation files that Setup downloads. Do suggest I should re-install everything else-wheer and cygwin should re-instate the cygwin tree where it was intended originally? Right now, cd / points to C:\cygwin\download instead of C:\cygwin\, which means that most of the local packages which were not re-installed since are still in the old strucure (i.e. C:\cygwin\) and do not seem visible anymore. I don't take the ROOT as magical but I thought that moving/copying (soft) linked object breaks the link. Besides, it would be hard for me to track down all the places the source code I build put their files at the install (e.g. using make install). The most tricky ones were the Math optimized libraries lapack, ATLAS, blas, FFTW, octave, which were all tricky for me to install. That is why I'd like to know how to reset the reference to ROOt to that of the intended path/tree structure. How shall I proceed if at possible? What did I do to make Setup.exe install the base package in the downloads directory, so that I avoid the same mistake. Many thanks again for you reply. I look forward to receiving any suggestions. Donat From: Larry Hall [EMAIL PROTECTED] Reply-To: Cygwin List [EMAIL PROTECTED] To: Donat-Pierre Luigi [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Cygwin has two ROOT tree strcutures and the old one is not the default anymore. Date: Sun, 14 Nov 2004 13:26:13 -0500 At 05:42 AM 11/14/2004, you wrote: I have two root directory structures (both with usr, bin, etc, ...). One under the standard C:\cygwin ( i.e. /cygdrive/c/cygwin) and the other under C:\cygwin\download (i.e. /cygdrive/c/cygwin/download). When I enquire about the default bin location here is the reply: $ which ls /usr/bin/ls Here is what leads to it. The last couple of days I had a problem with several DLLs (linintl-1.dll, cygwin DLL, ) when I was trying to install new components. At the same time, ls and most command stopped working on a bash shell, except few like cd and pwd. Although it seemed slightly better when I redefined the default path to the bin directory with PATH=/usr/local/bin:/usr/bin:/bin:$PATH, ls on /usr/bin directory prompted more complaints on missing dlls. It felt as if a lot of the env parameter where not defined and cygwin totally incapacitated. I re-installed the libraries which were reported missing, even though there were present in their respective directory. Out of frustration I re-installed the entire base Cygwin and most of the libraries and dev components. Now, everything seems working except that I have two directory structures, and the libraries and source code I compiled are in the depreciated structure. Did I break my cygwin? Can I salvage my old structure in order to save all that I had organized and compiled in it (lots of hours)? Many thanks in advance for your help and suggestions, Donat-Pierre P.s.: I attached a cygcheck.out file for further details (i.e. generated with cygcheck -s -v r ). Looks like everything now points to your 'C:\cygwin\download' directory, so that's apparently where you reinstalled. If this is really the directory that you specified in 'setup.exe' as the place to put your downloaded packages (during the install), then I'd really recommend that you choose a different directory. The download directory is where 'setup.exe' puts the packages it downloads and it assumes it can do anything it wants/needs with this directory. Installing to this same directory is not recommended. As for things you've built locally that are not part of your currently installed Cygwin tree, you can move or copy them wherever you like or is convenient. There's nothing magical about the root directory (or the directory structure in general really). If you copy/move things you've built, untar'd, etc, from your deprecated tree to the current install tree, I don't foresee any obvious problems. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin has two ROOT tree strcutures and the old one is not the default anymore.
At 03:50 PM 11/14/2004, you wrote: Larry, Thanks for your reply. C:\cygwin\download has always been the one used for Setup on my system, and it only created havoc when I re-installed base and library packages. It was supposed to be on the place to store the installation files that Setup downloads. Do suggest I should re-install everything else-wheer and cygwin should re-instate the cygwin tree where it was intended originally? Right now, cd / points to C:\cygwin\download instead of C:\cygwin\, which means that most of the local packages which were not re-installed since are still in the old strucure (i.e. C:\cygwin\) and do not seem visible anymore. I don't take the ROOT as magical but I thought that moving/copying (soft) linked object breaks the link. Besides, it would be hard for me to track down all the places the source code I build put their files at the install (e.g. using make install). The most tricky ones were the Math optimized libraries lapack, ATLAS, blas, FFTW, octave, which were all tricky for me to install. That is why I'd like to know how to reset the reference to ROOt to that of the intended path/tree structure. How shall I proceed if at possible? What did I do to make Setup.exe install the base package in the downloads directory, so that I avoid the same mistake. Many thanks again for you reply. I look forward to receiving any suggestions. If you just want to have '/' point to 'c:\cygwin' instead of 'c:\cygwin\download', just remount your mounts to point there. '/', '/usr/bin', and '/usr/lib' are the ones you're concerned with. So do: mount -b -s -f C:/cygwin / mount -b -s -f C:/cygwin/bin /usr/bin mount -b -s -f C:/cygwin/lib /usr/lib If you have any Cygwin services running, I recommend stopping them, doing the above, and restarting them. As for what you did to setup to make it use your download directory as your root install directory, you must have specified it as such in the 3rd page of the install process. You should type this directory into the 4th page where it asks for the local package directory only. Actually, if you find the above 'mount' commands above too difficult to follow/do, you can rerun setup and simply reset your root directory to be 'c:\cygwin'. It w ill make the above mount changes for you as a result. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin has two ROOT tree strcutures and the old one is not the default anymore.
Thanks Larry, This seems easy enough. I was about to run setup to follow your hunch of the 1st email you sent me. Also, I was reading about rebase in same post. You are right, I was distracted, I am so used to see the select the loacl package directory selction on the 4th page, I must have added download to the rood path in the 3rd page. I am glad there is way to repair this without re-installing everything. We learn every day. I'll try this later this afternoon, here in Los Angeles, CA. Good evening to you in MA Donat If you just want to have '/' point to 'c:\cygwin' instead of 'c:\cygwin\download', just remount your mounts to point there. '/', '/usr/bin', and '/usr/lib' are the ones you're concerned with. So do: mount -b -s -f C:/cygwin / mount -b -s -f C:/cygwin/bin /usr/bin mount -b -s -f C:/cygwin/lib /usr/lib If you have any Cygwin services running, I recommend stopping them, doing the above, and restarting them. As for what you did to setup to make it use your download directory as your root install directory, you must have specified it as such in the 3rd page of the install process. You should type this directory into the 4th page where it asks for the local package directory only. Actually, if you find the above 'mount' commands above too difficult to follow/do, you can rerun setup and simply reset your root directory to be 'c:\cygwin'. It w ill make the above mount changes for you as a result. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin has two ROOT tree strcutures and the old one is not the default anymore.
At 04:23 PM 11/14/2004, you wrote: Thanks Larry, This seems easy enough. I was about to run setup to follow your hunch of the 1st email you sent me. Also, I was reading about rebase in same post. You are right, I was distracted, I am so used to see the select the loacl package directory selction on the 4th page, I must have added download to the rood path in the 3rd page. I am glad there is way to repair this without re-installing everything. We learn every day. I'll try this later this afternoon, here in Los Angeles, CA. Good evening to you in MA Donat Yup, should be easy. If not, make sure you get a full refund. ;-) After you're done, you should be able to remove the unwanted install tree in 'c:\cygwin\download' if you'd like to regain your disk space. Good luck, -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin has two ROOT tree strcutures and the old one is not the default anymore.
I could not resist to try it before going out. It worked. I am late but tha's ok. The only little problem is with the profile in /etc: bash: /etc/profile: line 196: syntax error: unexpected end of file. And I look in it with vi: E325: ATTENTION Found a swap file by the name /etc/.profile.swp owned by: luigi dated: Mon Oct 25 13:24:27 2004 file name: /etc/profile modified: no user name: luigi host name: ictprods1 process ID: 1840 While opening file /etc/profile dated: Sun Nov 14 13:27:00 2004 NEWER than swap file! I might have edited something last time, such as adding PATH=/usr/local/bin:/usr/bin:/bin:$PATH but I am not sure. So far I am tempted to recover it, since teh old version is from the time I did the fresh new install back in late October. Donat From: Larry Hall [EMAIL PROTECTED] Reply-To: Cygwin List [EMAIL PROTECTED] To: Donat-Pierre Luigi [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Cygwin has two ROOT tree strcutures and the old one is not the default anymore. Date: Sun, 14 Nov 2004 16:25:34 -0500 At 04:23 PM 11/14/2004, you wrote: Thanks Larry, This seems easy enough. I was about to run setup to follow your hunch of the 1st email you sent me. Also, I was reading about rebase in same post. You are right, I was distracted, I am so used to see the select the loacl package directory selction on the 4th page, I must have added download to the rood path in the 3rd page. I am glad there is way to repair this without re-installing everything. We learn every day. I'll try this later this afternoon, here in Los Angeles, CA. Good evening to you in MA Donat Yup, should be easy. If not, make sure you get a full refund. ;-) After you're done, you should be able to remove the unwanted install tree in 'c:\cygwin\download' if you'd like to regain your disk space. Good luck, -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
postinstall scripts don't run when installing onto samba share.
G'day, I've googled around, searched the list archives, and not found anything quite like what I'm experiencing. Whenever I install onto a samba share (ie P:/cygwin instead of C:/cygwin), the postinstall scripts don't run. There is no indication of any errors. The most obvious symptom is the cygwin-X start menu entries are not created. When I install to a local disk, they do run, and everything installs OK. As near as I can tell, when installing onto a samba share, the execute permissions are not set on any install scripts. I noticed this when I attempted to run the cygwin-X menu postinstall script. I was able to manually do a chmod a+x on it then run it OK. I don't understand why the execute bits would not be set. I thought cygwin checked shell scripts for a #! and set execute based on that. Is there something in my samba config that might be doing this? -- Donovan Baarda [EMAIL PROTECTED] Obsidian Consulting Group -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FYI: Reboot is needed after a failed setup.
On Fri, 12 Nov 2004 16:58:00 -0800, Brian Dessent [EMAIL PROTECTED] wrote: Solution: add setup.exe logic to remove and install new cygwin DLL first before all other operations, if selected. I am willing to try an add this logic. Where is the source for setup.exe ? I am looking through CVS and I am not finding the setup code: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/?cvsroot=src -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FYI: Reboot is needed after a failed setup.
Stephen More wrote: I am willing to try an add this logic. Where is the source for setup.exe ? I am looking through CVS and I am not finding the setup code: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/?cvsroot=src You can find details of building setup.exe at http://sources.redhat.com/cygwin-apps/setup.html. If you proceed, you should join the cygwin-apps list where setup.exe development is on-topic and coordinate with the other setup.exe maintainers. I believe that means Max Bowsher currently (previously Robert Collins) with patches also coming from Reini U., Igor P., Gary V.S., et al. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: postinstall scripts don't run when installing onto samba share.
On Mon, Nov 15, 2004 at 10:47:16AM +1100, Donovan Baarda wrote: I don't understand why the execute bits would not be set. Remote shares are assumed to be non-executable by default for speed considerations. You can fix this by mounting the share with the -x option: mount -x -f //foo/bar /bar Mounting the share in that manner will cause cygwin (and setup postinstall scripts) to consider everything in /bar to be consdired executable. It might be better to mount any specific directories that you know will contain executable content with -x: mount -x -f //foo/c/cygwin/bin /bin mount -x -f //foo/c/cygwin/sbin /sbin mount -x -f //foo/c/cygwin/usr/sbin /usr/sbin etc. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: libgnomeprint22-2.8.0.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following package has been updated in the Cygwin distribution: *** libgnomeprint22-2.8.0.1-1 This contains upstream bugfixes as part of the GNOME 2.8.1 desktop release. Yaakov - -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBmDEKpiWmPGlmQSMRAkGBAJ9lJTqNeTr7Ei/gyT58xYnWVBySvQCfSOZf /DtKLoxTMrMBHshZrqEawVc= =7jzC -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: desktop-file-utils-0.10-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following package has been updated in the Cygwin distribution: *** desktop-file-utils-0.10-1 This upstream release includes a major rewrite to the code and build system, as much of the previous code (namely the internal libmenu) is now in the GNOME libraries themselves. The gnome-vfs module -- which I never got a chance to include in the Cygwin builds -- was also removed from the sources as part of this upgrade. Bottom line: source package is much smaller, but the end user won't see much difference. Yaakov - -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBmDJ+piWmPGlmQSMRAgBmAKDnzEiaiAbaya2gcZHqbYQ8P1vZmQCePZ0R EBlNxV5vHVosluk4NaCuNLk= =k4J5 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: postinstall scripts don't run when installing onto samba share.
On Mon, 2004-11-15 at 15:36, Christopher Faylor wrote: On Mon, Nov 15, 2004 at 10:47:16AM +1100, Donovan Baarda wrote: I don't understand why the execute bits would not be set. Remote shares are assumed to be non-executable by default for speed considerations. You can fix this by mounting the share with the -x option: mount -x -f //foo/bar /bar Mounting the share in that manner will cause cygwin (and setup postinstall scripts) to consider everything in /bar to be consdired executable. It might be better to mount any specific directories that you know will contain executable content with -x: mount -x -f //foo/c/cygwin/bin /bin mount -x -f //foo/c/cygwin/sbin /sbin mount -x -f //foo/c/cygwin/usr/sbin /usr/sbin How do you tell this to setup.exe on a fresh install? -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: postinstall scripts don't run when installing onto samba share.
On Mon, Nov 15, 2004 at 03:56:01PM +1100, Donovan Baarda wrote: On Mon, 2004-11-15 at 15:36, Christopher Faylor wrote: On Mon, Nov 15, 2004 at 10:47:16AM +1100, Donovan Baarda wrote: I don't understand why the execute bits would not be set. Remote shares are assumed to be non-executable by default for speed considerations. You can fix this by mounting the share with the -x option: mount -x -f //foo/bar /bar Mounting the share in that manner will cause cygwin (and setup postinstall scripts) to consider everything in /bar to be consdired executable. It might be better to mount any specific directories that you know will contain executable content with -x: mount -x -f //foo/c/cygwin/bin /bin mount -x -f //foo/c/cygwin/sbin /sbin mount -x -f //foo/c/cygwin/usr/sbin /usr/sbin How do you tell this to setup.exe on a fresh install? AFAIK, you can't. Sorry. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Update: base-files
Changes:
3.1-3
* Change cd ${HOME} functionality for CHERE - Dave Kilroy
3.1-2
* Fix for zsh/ksh - Tero Niemela
Please direct all comments and questions to the cygwin list.
J.
** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe: tag in the email header of this message.
Send email to the address specified there. It will be in the format:
[EMAIL PROTECTED]
If you need more information on unsubscribing, start reading here:
http://sources.redhat.com/lists.html#unsubscribe-simple
Please read *all* of the information on unsubscribing that is available
starting at this URL.
Updated: libgnomeprint22-2.8.0.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following package has been updated in the Cygwin distribution: *** libgnomeprint22-2.8.0.1-1 This contains upstream bugfixes as part of the GNOME 2.8.1 desktop release. Yaakov - -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBmDEKpiWmPGlmQSMRAkGBAJ9lJTqNeTr7Ei/gyT58xYnWVBySvQCfSOZf /DtKLoxTMrMBHshZrqEawVc= =7jzC -END PGP SIGNATURE-
Updated: desktop-file-utils-0.10-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following package has been updated in the Cygwin distribution: *** desktop-file-utils-0.10-1 This upstream release includes a major rewrite to the code and build system, as much of the previous code (namely the internal libmenu) is now in the GNOME libraries themselves. The gnome-vfs module -- which I never got a chance to include in the Cygwin builds -- was also removed from the sources as part of this upgrade. Bottom line: source package is much smaller, but the end user won't see much difference. Yaakov - -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBmDJ+piWmPGlmQSMRAgBmAKDnzEiaiAbaya2gcZHqbYQ8P1vZmQCePZ0R EBlNxV5vHVosluk4NaCuNLk= =k4J5 -END PGP SIGNATURE-
