Re: [ITA] libXft/libXft2/libXft-devel: X.org libXft component
Yaakov writes: Dr. Volker Zell wrote: | I would like to adopt and maintain the 'libXft/libXft2/libXft-devel' packages from Harold Hunt. Unfortunately this needs to be done together with the rest of modular X11R7, because xft.pc requires xproto.pc and xrender.pc. Opps, you're right of course. So scratch that ITA. By the way Yaakov, did you read o http://cygwin.com/ml/cygwin/2008-02/msg00645.html o http://cygwin.com/ml/cygwin/2008-03/msg00567.html Ciao Volker
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
For a start, please note that this patch is just preliminary. The actual problem is still one of the problems I noted in my mail http://cygwin.com/ml/cygwin-developers/2008-03/msg0.html, to which I didn't get a reply, except from Brian. - The POSIX path of mount points is restricted to 256 characters. That's because it's used as the value name of a registry value and value names are restricted to (surprise!) 256 chars. A decision and, perhaps, coding has to be done: - Do we stick to this restriction? - Do we introduce a new mount point storage in the registry? - Do we drop registry mount points and store mount points in future in fstab-like files as, say, /etc/fstab (system mount points) and ~/.fstab (user mount points)? Having said that... On Apr 2 17:56, Charles Wilson wrote: Corinna Vinschen wrote: I have applied a preliminary patch to Cygwin which allows to load the mount entries from /etc/fstab and /etc/fstab.usersid. If none of these files is available, the DLL falls back to reading the mount points from the registry. I like this. A lot. AOL ;) Cygwin finds the fstab files by fetching it's own Win32 path and then replacing the last two path components with etc/fstab or etc/fstab.usersid, like this: Get own path == C:\\cygwin\\bin\\cygwin1.dll Where's fstab? == C:\\cygwin\\etc\\fstab So, it implicitly computes where / is? No, it doesn't. It just snips away the last two path components and tacks the etc/fstab string on. Plus the .$SID to get the user mounts. After the mount points have been read, root can potentially be somewhere else entirely. The layout of the fstab file follows the Linux layout. As example, these are my fstab files: $ cat /etc/fstab C:\cygwin / ntfs binary 0 0 Which means that the line above really ought to match the computed '/', or bad things might happen, right? If so, then it is redundant to specify it here. Perhaps this should just be autocomputed...since the fstype and last two elements are ignored. Yes, I thought about this, too. It doesn't really seem to make much sense to redefine /. As for /usr/bin and /usr/lib, these paths are not inherently defined by the DLL. They exist because a decision has been made how to create a Cygwin installation in the net distro. This could be changed in future, or our internal Red Hat release could need another layout. There's no reason to couple this distro decision to the DLL, IMHO. [...] Maybe there should be special rules for the three special autocomputed mount points: # NOTE: the three magic auto-computed paths are present # in this file strictly so that mount options may be specified. C:\This\Path\Is\AutoComputed /ntfs binary 0 0 C:\This\Path\Is\AutoComputed /usr/bin ntfs binary 0 0 C:\This\Path\Is\AutoComputed /usr/lib ntfs binary 0 0 Or simply root / ntfs binary 0 0 and stick to /usr/bin and /usr/lib as they are today. Oh, and I'm guessing that setup-1.7 should create /etc/fstab if install for all users, and /etc/fstab.SID if just me? Otherwise, you'll clobber the old cygwin's registry entries every time you try to update your new cygwin installation... That's right. I think this could be done by a simple postinstall script which gets called from setup-1.7. Consider a package which comes with a default /etc/fstab which consists only of the above entry for the root dir. The script would simply add the /usr/bin and /usr/lib entries. I have the vague feeling it would be sufficient to install only a /etc/fstab, even in just me mode, though. The fstab.$SID file is only necessary in multi-user installations, IMHO. Another problem is that the 1.7 mount(1) still creates the mount entries in the registry. This should be removed, if we stick to the file based approach. mount would only create temporary mount points which are only valid in this single session, until the last Cygwin process in this session exits. A bit like a reboot on Linux :) One little wrinkle that makes switching between two cygwin installations difficult: services. Do you (1) stop/uninstall -- switch-to-other-cygwin -- reinstall/start as part of each switch, or (2) somehow change each service's target path (and PATH environment variable, if the service.exe is not in /bin. For the proposed 1.7.0 you have to ensure that the correct cygwin1.dll is used), and then restart? (3) install services under different names for the two installations, and just remember to stop all the old ones, before trying to use any tools from the new installation, and restart the new services under their alternate installation names? The installation part of this proposal could be automated in the foo-config scripts: if cygwin_17 then service_name=sshd_17 else service_name=sshd fi etc. Consider that a parallel installation is not really for the normal user. My answer to this question is, whatever is
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, Apr 03, 2008 at 11:42:20AM +0200, Corinna Vinschen wrote: For a start, please note that this patch is just preliminary. The actual problem is still one of the problems I noted in my mail http://cygwin.com/ml/cygwin-developers/2008-03/msg0.html, to which I didn't get a reply, except from Brian. - The POSIX path of mount points is restricted to 256 characters. That's because it's used as the value name of a registry value and value names are restricted to (surprise!) 256 chars. A decision and, perhaps, coding has to be done: - Do we stick to this restriction? - Do we introduce a new mount point storage in the registry? - Do we drop registry mount points and store mount points in future in fstab-like files as, say, /etc/fstab (system mount points) and ~/.fstab (user mount points)? Having said that... FWIW: ~/.fstab - No /etc/fstab - Yes and get rid of the registry entirely On Apr 2 17:56, Charles Wilson wrote: Corinna Vinschen wrote: I have applied a preliminary patch to Cygwin which allows to load the mount entries from /etc/fstab and /etc/fstab.usersid. If none of these files is available, the DLL falls back to reading the mount points from the registry. I like this. A lot. AOL ;) Cygwin finds the fstab files by fetching it's own Win32 path and then replacing the last two path components with etc/fstab or etc/fstab.usersid, like this: Get own path == C:\\cygwin\\bin\\cygwin1.dll Where's fstab? == C:\\cygwin\\etc\\fstab So, it implicitly computes where / is? No, it doesn't. It just snips away the last two path components and tacks the etc/fstab string on. Plus the .$SID to get the user mounts. After the mount points have been read, root can potentially be somewhere else entirely. I think that's the right way to handle this. The layout of the fstab file follows the Linux layout. As example, these are my fstab files: $ cat /etc/fstab C:\cygwin / ntfs binary 0 0 Which means that the line above really ought to match the computed '/', or bad things might happen, right? If so, then it is redundant to specify it here. Perhaps this should just be autocomputed...since the fstype and last two elements are ignored. Yes, I thought about this, too. It doesn't really seem to make much sense to redefine /. As for /usr/bin and /usr/lib, these paths are not inherently defined by the DLL. They exist because a decision has been made how to create a Cygwin installation in the net distro. This could be changed in future, or our internal Red Hat release could need another layout. There's no reason to couple this distro decision to the DLL, IMHO. For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. [...] Maybe there should be special rules for the three special autocomputed mount points: # NOTE: the three magic auto-computed paths are present # in this file strictly so that mount options may be specified. C:\This\Path\Is\AutoComputed /ntfs binary 0 0 C:\This\Path\Is\AutoComputed /usr/bin ntfs binary 0 0 C:\This\Path\Is\AutoComputed /usr/lib ntfs binary 0 0 Or simply root / ntfs binary 0 0 and stick to /usr/bin and /usr/lib as they are today. I think something like an automount is needed since it would be nice to eventually generalize the cygdrive stuff and we don't want to explicitly mount a: - z: So, maybe we could consider a linux-like solution to accomplish this although I really don't like automount. Oh, and I'm guessing that setup-1.7 should create /etc/fstab if install for all users, and /etc/fstab.SID if just me? Otherwise, you'll clobber the old cygwin's registry entries every time you try to update your new cygwin installation... That's right. I think this could be done by a simple postinstall script which gets called from setup-1.7. Consider a package which comes with a default /etc/fstab which consists only of the above entry for the root dir. The script would simply add the /usr/bin and /usr/lib entries. I have the vague feeling it would be sufficient to install only a /etc/fstab, even in just me mode, though. The fstab.$SID file is only necessary in multi-user installations, IMHO. Why do we need a fstab.$SID and linux doesn't need this? Another problem is that the 1.7 mount(1) still creates the mount entries in the registry. This should be removed, if we stick to the file based approach. mount would only create temporary mount points which are only valid in this single session, until the last Cygwin process in this session exits. A bit like a reboot on Linux :) On XP it should be possible to make it so that the mounts last until reboot. If we can do that I think it would be ideal. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 3 09:56, Christopher Faylor wrote: On Thu, Apr 03, 2008 at 11:42:20AM +0200, Corinna Vinschen wrote: - Do we drop registry mount points and store mount points in future in fstab-like files as, say, /etc/fstab (system mount points) and ~/.fstab (user mount points)? Having said that... FWIW: ~/.fstab - No I don't think that's as easily implementable as having such a file in /etc anyway, but you're making an important note below, so, see there. /etc/fstab - Yes and get rid of the registry entirely ACK. The reason I implemented this with using the registry as a fallback is for easier testing. The idea is that we (developers and maintainers) can start to use the fstab approach, while normal users on the Cygwin list, who are just curious, still can run a snapshot in their otherwise unchanged environment. On Apr 2 17:56, Charles Wilson wrote: Corinna Vinschen wrote: Get own path == C:\\cygwin\\bin\\cygwin1.dll Where's fstab? == C:\\cygwin\\etc\\fstab So, it implicitly computes where / is? No, it doesn't. It just snips away the last two path components and tacks the etc/fstab string on. Plus the .$SID to get the user mounts. After the mount points have been read, root can potentially be somewhere else entirely. I think that's the right way to handle this. That puzzles me a bit, because of what you write below. these are my fstab files: $ cat /etc/fstab C:\cygwin / ntfs binary 0 0 Which means that the line above really ought to match the computed '/', or bad things might happen, right? If so, then it is redundant to specify it here. Perhaps this should just be autocomputed...since the fstype and last two elements are ignored. Yes, I thought about this, too. It doesn't really seem to make much sense to redefine /. As for /usr/bin and /usr/lib, these paths are not inherently defined by the DLL. They exist because a decision has been made how to create a Cygwin installation in the net distro. This could be changed in future, or our internal Red Hat release could need another layout. There's no reason to couple this distro decision to the DLL, IMHO. For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. Full ACK! However, this needs a bit of careful revisiting of some of the packages. For instance, assuming the Cygwin DLL will go to /bin, cygrunsrv should also reside in /bin when we do this, not in /usr/bin, obviously. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. Or simply root / ntfs binary 0 0 and stick to /usr/bin and /usr/lib as they are today. I think something like an automount is needed since it would be nice to eventually generalize the cygdrive stuff and we don't want to explicitly mount a: - z: So, maybe we could consider a linux-like solution to accomplish this although I really don't like automount. I'm not sure I understand this, that's why I was puzzled above. Do you think that / should be free as today: C:\arbitrary\useless\new\path / ntfs binary 0 0 or do you think an automatic approach as the above root / ntfs binary 0 0 is the way to go? As for cygdrives, isn't the cygdrive /mnt auto binary 0 0 already along the lines of an automount?!? I have the vague feeling it would be sufficient to install only a /etc/fstab, even in just me mode, though. The fstab.$SID file is only necessary in multi-user installations, IMHO. Why do we need a fstab.$SID and linux doesn't need this? Let me think... I don't know. I assume I just took this as it is. I guess the only reason to create user mounts to begin with was, so that any non-privileged user can create mount points, too, for a pure just me installation in a restricted environment. However, that's not really necessary anymore with /etc/fstab. So I agree, we can simply get rid of fstab.$SID. Another problem is that the 1.7 mount(1) still creates the mount entries in the registry. This should be removed, if we stick to the file based approach. mount would only create temporary mount points which are only valid in this single session, until the last Cygwin process in this session exits. A bit like a reboot on Linux :) On XP it should be possible to make it so that the mounts last until reboot. If we can do that I think it would be ideal. How? The mount points are bound to the existance of the shared memory they reside in. This shared mem disappears when the last Cygwin process in a session exits. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, 3 Apr 2008, Corinna Vinschen wrote: [snip] Get own path == C:\\cygwin\\bin\\cygwin1.dll Where's fstab? == C:\\cygwin\\etc\\fstab So, it implicitly computes where / is? No, it doesn't. It just snips away the last two path components and tacks the etc/fstab string on. Plus the .$SID to get the user mounts. After the mount points have been read, root can potentially be somewhere else entirely. So would it make sense to put the root mount info in the same directory as cygwin1.dll? I know it doesn't belong in /bin, but playing with relative paths is even more error-prone. [snip] For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. Full ACK! However, this needs a bit of careful revisiting of some of the packages. For instance, assuming the Cygwin DLL will go to /bin, cygrunsrv should also reside in /bin when we do this, not in /usr/bin, obviously. Umm, i don't see how that follows. cygrunsrv can easily reside in /usr/bin, as long as (a) /bin is in the PATH when cygrunsrv is invoked from the shell, and (b) when cygrunsrv installs the services, it adds /bin to the PATH in the service environment. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. /bin should contain programs that should work even if the PATH and mounts are screwed up. So, kill, shutdown, etc. Or simply root / ntfs binary 0 0 and stick to /usr/bin and /usr/lib as they are today. I think something like an automount is needed since it would be nice to eventually generalize the cygdrive stuff and we don't want to explicitly mount a: - z: So, maybe we could consider a linux-like solution to accomplish this although I really don't like automount. I'm not sure I understand this, that's why I was puzzled above. Do you think that / should be free as today: C:\arbitrary\useless\new\path / ntfs binary 0 0 or do you think an automatic approach as the above root / ntfs binary 0 0 is the way to go? As for cygdrives, isn't the cygdrive /mnt auto binary 0 0 already along the lines of an automount?!? It is, IMHO. I have the vague feeling it would be sufficient to install only a /etc/fstab, even in just me mode, though. The fstab.$SID file is only necessary in multi-user installations, IMHO. Why do we need a fstab.$SID and linux doesn't need this? Let me think... I don't know. I assume I just took this as it is. I guess the only reason to create user mounts to begin with was, so that any non-privileged user can create mount points, too, for a pure just me installation in a restricted environment. That, and also to allow completely disjoint Cygwin installations for different users (where the mount table would otherwise be shared). But this effect can also be accomplished with /etc/fstab (one per installation). However, that's not really necessary anymore with /etc/fstab. So I agree, we can simply get rid of fstab.$SID. Yes, that reasoning is mostly correct. However, some packages (like Cygwin/X) apparently assume a single-user installation, and create sockets/temp files in shared locations (i.e., /tmp). That, unfortunately, makes the default startup scripts insufficient to allow multiple users to run Cygwin/X sessions simultaneously, unless that shared location is overridden in a per-user manner (e.g., through user mounts). So, until we figure out how to solve that issue, user mounts are actually userful. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! That which is hateful to you, do not do to your neighbor. That is the whole Torah; the rest is commentary. Go and study it. -- Rabbi Hillel
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 3 11:16, Igor Peshansky wrote: On Thu, 3 Apr 2008, Corinna Vinschen wrote: [snip] Get own path == C:\\cygwin\\bin\\cygwin1.dll Where's fstab? == C:\\cygwin\\etc\\fstab So, it implicitly computes where / is? No, it doesn't. It just snips away the last two path components and tacks the etc/fstab string on. Plus the .$SID to get the user mounts. After the mount points have been read, root can potentially be somewhere else entirely. So would it make sense to put the root mount info in the same directory as cygwin1.dll? I know it doesn't belong in /bin, but playing with relative paths is even more error-prone. I don't understand this. As discussed somewhat later, if the root dir follows automatically from where the DLL itself resides. Which, btw., the current code doesn't do right. I called GetModuleFileName(NULL) which returns the path of the current application, not the path of the Cygwin DLL. I'll fix that. [snip] For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. Full ACK! However, this needs a bit of careful revisiting of some of the packages. For instance, assuming the Cygwin DLL will go to /bin, cygrunsrv should also reside in /bin when we do this, not in /usr/bin, obviously. Umm, i don't see how that follows. cygrunsrv can easily reside in /usr/bin, as long as (a) /bin is in the PATH when cygrunsrv is invoked from the shell, and (b) when cygrunsrv installs the services, it adds /bin to the PATH in the service environment. Which is too late for cygrunsrv itself, right? The idea is to avoid having to add the Cygwin bin dir to the system variable %PATH%. If you want to accomplish that, cygrunsrv itself must be independent of it. That's only the case if it shares the bin dir with the Cygwin DLL. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. /bin should contain programs that should work even if the PATH and mounts are screwed up. So, kill, shutdown, etc. And cygrunsrv. However, that's not really necessary anymore with /etc/fstab. So I agree, we can simply get rid of fstab.$SID. Yes, that reasoning is mostly correct. However, some packages (like Cygwin/X) apparently assume a single-user installation, and create sockets/temp files in shared locations (i.e., /tmp). That, unfortunately, That's a bug in Cygwin/X or in using it. If you have different DISPLAY numbers for different displays, they shouldn't share the /tmp stuff, just like on Linux et al. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
[#$%^! I had a reply-to set in my original reply. I removed it. Please reply to *this* mail. Thanks.] On Apr 3 11:16, Igor Peshansky wrote: On Thu, 3 Apr 2008, Corinna Vinschen wrote: [snip] Get own path == C:\\cygwin\\bin\\cygwin1.dll Where's fstab? == C:\\cygwin\\etc\\fstab So, it implicitly computes where / is? No, it doesn't. It just snips away the last two path components and tacks the etc/fstab string on. Plus the .$SID to get the user mounts. After the mount points have been read, root can potentially be somewhere else entirely. So would it make sense to put the root mount info in the same directory as cygwin1.dll? I know it doesn't belong in /bin, but playing with relative paths is even more error-prone. I don't understand this. As discussed somewhat later, if the root dir follows automatically from where the DLL itself resides. Which, btw., the current code doesn't do right. I called GetModuleFileName(NULL) which returns the path of the current application, not the path of the Cygwin DLL. I'll fix that. [snip] For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. Full ACK! However, this needs a bit of careful revisiting of some of the packages. For instance, assuming the Cygwin DLL will go to /bin, cygrunsrv should also reside in /bin when we do this, not in /usr/bin, obviously. Umm, i don't see how that follows. cygrunsrv can easily reside in /usr/bin, as long as (a) /bin is in the PATH when cygrunsrv is invoked from the shell, and (b) when cygrunsrv installs the services, it adds /bin to the PATH in the service environment. Which is too late for cygrunsrv itself, right? The idea is to avoid having to add the Cygwin bin dir to the system variable %PATH%. If you want to accomplish that, cygrunsrv itself must be independent of it. That's only the case if it shares the bin dir with the Cygwin DLL. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. /bin should contain programs that should work even if the PATH and mounts are screwed up. So, kill, shutdown, etc. And cygrunsrv. However, that's not really necessary anymore with /etc/fstab. So I agree, we can simply get rid of fstab.$SID. Yes, that reasoning is mostly correct. However, some packages (like Cygwin/X) apparently assume a single-user installation, and create sockets/temp files in shared locations (i.e., /tmp). That, unfortunately, That's a bug in Cygwin/X or in using it. If you have different DISPLAY numbers for different displays, they shouldn't share the /tmp stuff, just like on Linux et al. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 3 17:38, Corinna Vinschen wrote: On Apr 3 11:16, Igor Peshansky wrote: On Thu, 3 Apr 2008, Corinna Vinschen wrote: [snip] Get own path == C:\\cygwin\\bin\\cygwin1.dll Where's fstab? == C:\\cygwin\\etc\\fstab So, it implicitly computes where / is? No, it doesn't. It just snips away the last two path components and tacks the etc/fstab string on. Plus the .$SID to get the user mounts. After the mount points have been read, root can potentially be somewhere else entirely. So would it make sense to put the root mount info in the same directory as cygwin1.dll? I know it doesn't belong in /bin, but playing with relative paths is even more error-prone. I don't understand this. As discussed somewhat later, if the root dir follows automatically from where the DLL itself resides. Which, btw., [...] Looks like I distracted myself while replying. What I was trying to say is, if the root dir is taken automatically from the path of the DLL, there is no reason to have the path to the root dir stored anywhere, isn't it? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, Apr 03, 2008 at 04:19:58PM +0200, Corinna Vinschen wrote: On Apr 3 09:56, Christopher Faylor wrote: On Thu, Apr 03, 2008 at 11:42:20AM +0200, Corinna Vinschen wrote: - Do we drop registry mount points and store mount points in future in fstab-like files as, say, /etc/fstab (system mount points) and ~/.fstab (user mount points)? Having said that... FWIW: ~/.fstab - No I don't think that's as easily implementable as having such a file in /etc anyway, but you're making an important note below, so, see there. /etc/fstab - Yes and get rid of the registry entirely ACK. The reason I implemented this with using the registry as a fallback is for easier testing. The idea is that we (developers and maintainers) can start to use the fstab approach, while normal users on the Cygwin list, who are just curious, still can run a snapshot in their otherwise unchanged environment. On Apr 2 17:56, Charles Wilson wrote: Corinna Vinschen wrote: Get own path == C:\\cygwin\\bin\\cygwin1.dll Where's fstab? == C:\\cygwin\\etc\\fstab So, it implicitly computes where / is? No, it doesn't. It just snips away the last two path components and tacks the etc/fstab string on. Plus the .$SID to get the user mounts. After the mount points have been read, root can potentially be somewhere else entirely. I think that's the right way to handle this. That puzzles me a bit, because of what you write below. these are my fstab files: $ cat /etc/fstab C:\cygwin / ntfs binary 0 0 Which means that the line above really ought to match the computed '/', or bad things might happen, right? If so, then it is redundant to specify it here. Perhaps this should just be autocomputed...since the fstype and last two elements are ignored. Yes, I thought about this, too. It doesn't really seem to make much sense to redefine /. As for /usr/bin and /usr/lib, these paths are not inherently defined by the DLL. They exist because a decision has been made how to create a Cygwin installation in the net distro. This could be changed in future, or our internal Red Hat release could need another layout. There's no reason to couple this distro decision to the DLL, IMHO. For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. Full ACK! However, this needs a bit of careful revisiting of some of the packages. For instance, assuming the Cygwin DLL will go to /bin, cygrunsrv should also reside in /bin when we do this, not in /usr/bin, obviously. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. Or simply root / ntfs binary 0 0 and stick to /usr/bin and /usr/lib as they are today. I think something like an automount is needed since it would be nice to eventually generalize the cygdrive stuff and we don't want to explicitly mount a: - z: So, maybe we could consider a linux-like solution to accomplish this although I really don't like automount. I'm not sure I understand this, that's why I was puzzled above. Do you think that / should be free as today: C:\arbitrary\useless\new\path / ntfs binary 0 0 or do you think an automatic approach as the above root / ntfs binary 0 0 is the way to go? As for cygdrives, isn't the cygdrive /mnt auto binary 0 0 already along the lines of an automount?!? auto in /etc/fstab doesn't mean automount. It means that it is meant to be automatically mounted at boot time. That's fine for /, /bin, /usr/bin. It isn't fine for z: where z: is a usb device. Another problem is that the 1.7 mount(1) still creates the mount entries in the registry. This should be removed, if we stick to the file based approach. mount would only create temporary mount points which are only valid in this single session, until the last Cygwin process in this session exits. A bit like a reboot on Linux :) On XP it should be possible to make it so that the mounts last until reboot. If we can do that I think it would be ideal. How? The mount points are bound to the existance of the shared memory they reside in. This shared mem disappears when the last Cygwin process in a session exits. I have to research what I'm thinking of but I think it's possible. I don't know if it is possible for a non-privileged user though. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 3 12:11, Christopher Faylor wrote: On Thu, Apr 03, 2008 at 04:19:58PM +0200, Corinna Vinschen wrote: Do you think that / should be free as today: C:\arbitrary\useless\new\path / ntfs binary 0 0 or do you think an automatic approach as the above root / ntfs binary 0 0 is the way to go? As for cygdrives, isn't the cygdrive /mnt auto binary 0 0 already along the lines of an automount?!? auto in /etc/fstab doesn't mean automount. It means that it is meant to be automatically mounted at boot time. That's fine for /, /bin, /usr/bin. It isn't fine for z: where z: is a usb device. Uh, that's something I didn't look for. I just used the word auto because it sounded nice at this point. Actually the third field is ignored. The important part is the cygdrive in the first field, which is along the lines of, say, proc or sysfs in Linux. We don't have a reason (so far) to care for the FS type field in fstab. Another problem is that the 1.7 mount(1) still creates the mount entries in the registry. This should be removed, if we stick to the file based approach. mount would only create temporary mount points which are only valid in this single session, until the last Cygwin process in this session exits. A bit like a reboot on Linux :) On XP it should be possible to make it so that the mounts last until reboot. If we can do that I think it would be ideal. How? The mount points are bound to the existance of the shared memory they reside in. This shared mem disappears when the last Cygwin process in a session exits. I have to research what I'm thinking of but I think it's possible. I don't know if it is possible for a non-privileged user though. If you mean to create permanent shared objects, that's not possible for an admin user either without tweaking the security policy. This policy is by default only active for kernel mode code. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, Apr 03, 2008 at 06:26:46PM +0200, Corinna Vinschen wrote: On Apr 3 12:11, Christopher Faylor wrote: On Thu, Apr 03, 2008 at 04:19:58PM +0200, Corinna Vinschen wrote: Do you think that / should be free as today: C:\arbitrary\useless\new\path / ntfs binary 0 0 or do you think an automatic approach as the above root / ntfs binary 0 0 is the way to go? As for cygdrives, isn't the cygdrive /mnt auto binary 0 0 already along the lines of an automount?!? auto in /etc/fstab doesn't mean automount. It means that it is meant to be automatically mounted at boot time. That's fine for /, /bin, /usr/bin. It isn't fine for z: where z: is a usb device. Uh, that's something I didn't look for. I just used the word auto because it sounded nice at this point. Actually the third field is ignored. The important part is the cygdrive in the first field, which is along the lines of, say, proc or sysfs in Linux. We don't have a reason (so far) to care for the FS type field in fstab. But if we were doing this the right way then I think we probably should have a procfs and something else which allowed the automatic mounting of devices like floppies or usb disks. cgf
[RFU] gnupg-1.4.9-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since nobody has answered my mail (see below), I have decided to treat this possible security issue seriously and not to use /dev/random anymore in the future gnupg releases. Port Notes: - - version 1.4.9-2 - * gnupg does not use /dev/random anymore but the builtin entropy gatherer for W32 (rndw32.c). Possible security issue, see: http://en.wikipedia.org/w/index.php?title=CryptGenRandomoldid=190115987 Package location: = wget \ http://home.arcor.de/thuffir/cygwin/gnupg/gnupg-1.4.9-2-src.tar.bz2 \ http://home.arcor.de/thuffir/cygwin/gnupg/gnupg-1.4.9-2.tar.bz2 Signatures: === wget \ http://home.arcor.de/thuffir/cygwin/gnupg/gnupg-1.4.9-2-src.tar.bz2.sig \ http://home.arcor.de/thuffir/cygwin/gnupg/gnupg-1.4.9-2.tar.bz2.sig; \ gpg --keyserver subkeys.pgp.net --recv-keys FD65117B 1CE0C630; \ gpg --verify gnupg-1.4.9-2-src.tar.bz2.sig; \ gpg --verify gnupg-1.4.9-2.tar.bz2.sig Build: == mkdir gnupg-1.4.9-2-build; \ cd gnupg-1.4.9-2-build; \ tar xjvf ../gnupg-1.4.9-2-src.tar.bz2; \ cygport gnupg-1.4.9-2 all Cheers Gergely Budai -Original Message- From: cygwin-apps On Behalf Of Gergely Budai Sent: Freitag, 28. März 2008 17:51 To: cygwin-apps Subject: gnupg and /dev/random Dear Community! It appears to me that gnupg has always been using /dev/random on cygwin since it's first release (1.0.7-1). AFAIK cygwin is using CryptGenRandom() for this device. According to Wikipedia, several significant weaknesses had been found recently in the Windows 2000 and XP implementation of that function. According to that same Wikipedia article, Microsoft is planning to fix that bug with the release of SP3 for XP, but not planning (at least did not tell to do so) to fix it for Windows 2000. Since the presence of a strong cryptographical random function is the prerequisite of cryptography and some of us are sill going to use Cygwin on Windows 2000 in the future, my question is the following: Would not it be better to configure the future gnupg cygwin releases not to use /dev/random, but the builtin and specially for windows developped randomness entropy gatherer (rndw32.c)? Looking forward to your kind oppinions, Gergely Budai Sources: http://en.wikipedia.org/wiki/CryptGenRandom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) iEYEARECAAYFAkf1DPwACgkQ15iwsP1lEXveWwCfdP6tjFvXDm58C+yQWpmmgcAf KK4An1Zy+UrnbigkIUeusKkYa1ktUdxk =G9Zb -END PGP SIGNATURE-
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 3 12:59, Christopher Faylor wrote: On Thu, Apr 03, 2008 at 06:26:46PM +0200, Corinna Vinschen wrote: On Apr 3 12:11, Christopher Faylor wrote: On Thu, Apr 03, 2008 at 04:19:58PM +0200, Corinna Vinschen wrote: Do you think that / should be free as today: C:\arbitrary\useless\new\path / ntfs binary 0 0 or do you think an automatic approach as the above root / ntfs binary 0 0 is the way to go? As for cygdrives, isn't the cygdrive /mnt auto binary 0 0 already along the lines of an automount?!? auto in /etc/fstab doesn't mean automount. It means that it is meant to be automatically mounted at boot time. That's fine for /, /bin, /usr/bin. It isn't fine for z: where z: is a usb device. Uh, that's something I didn't look for. I just used the word auto because it sounded nice at this point. Actually the third field is ignored. The important part is the cygdrive in the first field, which is along the lines of, say, proc or sysfs in Linux. We don't have a reason (so far) to care for the FS type field in fstab. But if we were doing this the right way then I think we probably should have a procfs and something else which allowed the automatic mounting of devices like floppies or usb disks. I see. I did the evaluation of a mount point being something automatic by using a string in the first field, but actually we should use specific strings in the FS type field and either ignore the content of the first field - for FS types like cygdrive, proc (later) root, sysfs (much later) - or the first field is the device which gets mounted in the second dir if the mount point is auto. Sort of a better cygdrive. I'll change the fstab stuff to do the FS type recognition for cygdrive and root. We can then add the auto and proc stuff easily at some later point. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: libtool packaging errors
Christopher Faylor wrote:
*** upset: release/libtool/libtool1.5/setup.hint:11: unknown key 'conflicts:
libtool2.2'
I've commented out the offending line.
Sorry. I remembered (from the last time I looked at the setup source
code) that its lexer understands conflicts:, so I included it.
As it happens, that's about the ONLY thing that understands the
conflicts: keyword. Setup will properly parse and store the information
within the object representation of the ini file, so that
myPkgVerNode-conflicts() will return the correct information.
But setup's installer does not use the information. And as we
discovered, upset chokes on it as well.
So, any suggestions? These two packages -- libtool1.5 and libtool2.2 --
DO conflict. Ordinarily, we'd just have:
libtool-{1.5.x|2.2.x}
libltdl3-1.5.x
libltdl7-2.2.y
and it would just work(tm) like other packages do. However, this
'numbered' approach to the libtool packages (as opposed to the libltdl
ones) was chosen for three reasons:
1) there is hope that in the future, we can have simultaneous parallel
installations, just like ac-2.13/ac-2.61 and am-x.y. We're not there
yet, tho.
2) legacy from the old libtool-stable/libtool-devel split
3) Three years ago (when libtool-2.0 was gonna be released Real Soon
Now, We Promise), I had intended to continue maintaining parallel
releases of 1.5.x and 2.0.x, and wanted separate prev/test/curr choices
for each development stream. You can't do that if both 1.5-derived and
2.2-derived are all named libtool
Here are the choices as I see them (given that items #1 and #2 above are
no longer operative)
A) give up on item #3, and consolidate all libtoolx.y into a new
libtool package. Eventually, 1.5.x releases will not be easily
accessible from setup, because the prev/curr/test 'slots' will all be
2.2-related.
B) Leave stuff alone, and just rely on savvy users reading the
Announcements, which encourage them to uninstall libtool1.5 before
installing libtool2.2. If they don't do this, the fix is simple:
i) uninstall both libtool1.5 and libtool2.2
ii) reinstall the desired version
C) Fix setup to understand conflicts:, and update upset to allow such
things.
i) I don't know how to do this
ii) Folks who do have more important things on their minds right now,
with Corinna's 1.7 proposal
Comments?
--
Chuck
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Christopher Faylor wrote: Why do we need a fstab.$SID and linux doesn't need this? Well, I like to create user mounts for each user (Guest, Administrator, me) like this: mount -f -u -b C:/Documents and Settings/user/My Documents /mydocs mount -f -u -b C:/Documents and Settings/user/Desktop /desktop mainly for convenience, but also because spaces and the command line don't mix well. Linux doesn't have to deal with asinine decisions made in Redmond, WA...from a hidden microphone in 1995: LOOK! We can support spaces in filenames as well as filenames longer than 8.3, so let's use them EVERYWHERE! Spaces for EVERYBODY! Really long and hard to type system paths, like 'Documents and Settings'! Whoo-pee!! Steve Jobs has got nuthin' on us! I realize that on (clean-install, non-upgrade) Vista, this is less of an issue, because the new paths are mount -f -u -b C:/Users/user/Documents /mydocs mount -f -u -b C:/Users/user/Desktop /desktop but XP and 2k aren't going anywhere for a long long time, if even one of the horror stories I've read about Vista are true... -- Chuck
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen wrote: On Apr 3 09:56, Christopher Faylor wrote: For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. Full ACK! However, this needs a bit of careful revisiting of some of the packages. For instance, assuming the Cygwin DLL will go to /bin, cygrunsrv should also reside in /bin when we do this, not in /usr/bin, obviously. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. Yep. A few things off the top of my head: 1) the shells need to install both in /bin and /usr/bin. This is up to the individual maintainers when they build their -1.7 versions, but to take on super-duper important shell: C:\cygwin/bin\bash.exe C:\cygwin/bin\cygwin1.dll C:\cygwin/bin\cygintl-8.dll C:\cygwin/bin\cygiconv-2.dll C:\cygwin/bin\cygreadline6.dll C:\cygwin/bin\cygncurses-8.dll Should /bin/bash be built statically (at least with regards libintl/libiconv/libreadline/libncurses)? Should /usr/bin/bash be identical to /bin/bash and also built statically? Or should bash-3.x.y-z.tar.bz2 for cygwin-1.7 have two separate (and different) bash executables in it? What if that tarball (with different /usr/bin/bash and /bin/bash) is unpacked on a system where legacy /usr/bin-/bin mounts are present? Or should some important set of DLL libraries be installed into both /usr/bin/ and /bin, and then /usr/bin/bash.exe and /bin/bash.exe (and /bin/sh.exe) can all be exactly the same, built using dynamic links, just as /usr/bin/bash.exe is today? Or tough. you want to run /bin/bash, ensure /usr/bin is in your PATH 2) build tools (netrel, gbs, cygport) might need a few additions/tweaks to support any of the above. I don't know. I assume I just took this as it is. I guess the only reason to create user mounts to begin with was, so that any non-privileged user can create mount points, too, for a pure just me installation in a restricted environment. However, that's not really necessary anymore with /etc/fstab. So I agree, we can simply get rid of fstab.$SID. No, please don't...I like my /desktop mount... -- Chuck
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Igor Peshansky wrote: So would it make sense to put the root mount info in the same directory as cygwin1.dll? I know it doesn't belong in /bin, but playing with relative paths is even more error-prone. MSYS has been doing the find msys dll, then locate ../../etc/fstab thing for years. Of all the (many) problems MSYS has, AFAIK this error-prone issue has NEVER been one of them. /bin should contain programs that should work even if the PATH and mounts are screwed up. So, kill, shutdown, etc. But if THAT is the requirement (work if mounts are messed up and -- for instance -- /usr/bin/ can't be found), then they all need to be statically linked (with the exception of /bin/cygwin1.dll, of course) -- or some carefully selected set of DLLs need to be installed in /bin. -- Chuck
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen wrote: /etc/fstab - Yes and get rid of the registry entirely ACK. Upgrading pain could be eased if setup.exe (or a postinstall script, perhaps) detected that /etc/fstab doesn't exist, and created it from the registry entries.
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, Apr 03, 2008 at 06:01:37PM -0500, Charles Wilson wrote: Corinna Vinschen wrote: On Apr 3 09:56, Christopher Faylor wrote: For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. Full ACK! However, this needs a bit of careful revisiting of some of the packages. For instance, assuming the Cygwin DLL will go to /bin, cygrunsrv should also reside in /bin when we do this, not in /usr/bin, obviously. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. Yep. A few things off the top of my head: 1) the shells need to install both in /bin and /usr/bin. This is up to the individual maintainers when they build their -1.7 versions, but to take on super-duper important shell: Or tough. you want to run /bin/bash, ensure /usr/bin is in your PATH Yes. Making duplicate copies is asking for trouble. 2) build tools (netrel, gbs, cygport) might need a few additions/tweaks to support any of the above. I don't know. I assume I just took this as it is. I guess the only reason to create user mounts to begin with was, so that any non-privileged user can create mount points, too, for a pure just me installation in a restricted environment. However, that's not really necessary anymore with /etc/fstab. So I agree, we can simply get rid of fstab.$SID. No, please don't...I like my /desktop mount... You don't need fstab to do mounts. It's always possible to add a mount to your .bashrc or something. That's what you'd do on linux if you wanted similar functionality. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, Apr 03, 2008 at 05:22:51PM -0600, Warren Young wrote: Corinna Vinschen wrote: /etc/fstab - Yes and get rid of the registry entirely ACK. Upgrading pain could be eased if setup.exe (or a postinstall script, perhaps) detected that /etc/fstab doesn't exist, and created it from the registry entries. Yes. I think that is the intent. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
[responding to the thread which started it all] On Wed, Apr 02, 2008 at 02:35:51PM +0200, Corinna Vinschen wrote: - We create a ftp://cygwin.com/pub/cygwin-1.7 dir. - Under that dir, we create the full release directory structure as it exists in the parallel cygwin dir, except for the cygwin itself. So far so good. - All files in the original release dir are hardlinked into their matching spot in the cygwin-1.7 dir. I don't like hardlinking. It's too easy to have unintended side effects. I think I'd rather just symlink the directories in the new release area then rm the symlink and create a new directory when it's time to populate the directory with a 1.7 version. - The cygwin subdir gets created and filled with only the first Cygwin DLL 1.7.0 tar files. - Chris starts a second upset which creates the setup.ini file in the cygwin-1.7 dir. I can do this but on top of this, I'd actually like to implement my plan for allowing people to control their own directories. I hadn't thought about adding a 1.7 directory but it should still be doable. If we don't do this, I think we'll be awash in a sea of RFU's and me pulling what little hair I have left out over upset errors. I'd also like to finally have a package lint program which could be invoked automatically. Anyone want to write one of those? I don't want to necessarily gate 1.7 on these things but a package lint is really long overdue, IMO. You could even write one that took a setup.ini as input to make sure that the setup.hint was correct to help stem the tide of upset errors. cgf
