Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 14 19:24, Igor Peshansky wrote: Hmm. Even now, one does not have to edit the registry to switch from binary mode to text mode -- you just need to re-mount with the appropriate option. I assume the same will hold for the /etc/fstab approach. No, how should it? Of course you have to edit the fstab file to create a text mount from a binary mount, *iff* you want a persistent solution. mount(1) only creates temporary mount points who's life time is determined by the life time of the Cygwin processes in the current session. If we taught mount to do this now and removed the Text option from setup altogether, complainers could be directed to the mount manpage. Then switching to the new setup won't be that much of a pain (at least in the text/binary department). They will be directed to the user's guide. 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 14 20:02, Brian Dessent wrote:
Christopher Faylor wrote:
Yes, I know. I just don't think it clarifies anything to put a Red
Hat in the registry.
I was thinking Cygwin would be better as well, but since it is
supposed to be a two-level heirarchy how about
HK{LM,CU}\Software\Cygwin Project\Cygwin. It has always seemed to me
that we actively try to de-emphasize any association that Red Hat has in
the actual day-to-day operation of the project, other than owning the
copyrights and having their own commercial fork. Likewise with the
Well, not exactly. I have done a lot of my 1.7 development lately on
blessed Red Hat time. The IPv6 changes and the long path name support
wouldn't be as progressed as they are if I hadn't got enough paid time
to do them. I don't think that deserves to be ignored.
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 15 02:29, Brian Dessent wrote: Corinna Vinschen wrote: Having said that, should we really rename the registry keys, what do we do with the Program Options and the two heap_foo values? Should they be moved to the new registry key? If yes, should the postinstall script I created a couple of days ago also move them? For the heap_chunk settings, couldn't they simply be moved into $CYGWIN? Unfortunately, no. The environment initialization requires that the memory initialization has already be done. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
On Apr 15 02:48, Brian Dessent wrote: Corinna Vinschen wrote: They do? How and Why? Is that something which should be rather fixed in newlib instead of in the autogen configuration? The BSD implementation of funopen() doesn't explicitly define any types for the cookie functions, but simply says they should match the signatures of read(2), write(2), lseek(2), and close(2). Autogen tried to define the following if it detected that funopen() exists: typedef int (cookie_read_function_t )(void *, char *, int); typedef int (cookie_write_function_t)(void *, const char *, int); typedef fpos_t (cookie_seek_function_t )(void *, fpos_t, int); typedef int (cookie_close_function_t)(void *); However the newlib implementation explicitly defines these types as: typedef ssize_t cookie_read_function_t(void *__cookie, char *__buf, size_t __n); typedef ssize_t cookie_write_function_t(void *__cookie, const char *__buf, size_t __n); # ifdef __LARGE64_FILES typedef int cookie_seek_function_t(void *__cookie, _off64_t *__off, int __whence); # else typedef int cookie_seek_function_t(void *__cookie, off_t *__off, int __whence); # endif /* !__LARGE64_FILES */ typedef int cookie_close_function_t(void *__cookie); So you got an error because the types differ. I don't see anything wrong with the newlib definitions here, as they match the prototypes of read/write/etc. I'm not sure why autogen was trying to define them using int instead of size_t or ssize_t, but that's what it was doing and it was apparently succeeding because the BSD headers didn't have any typedefs. I see. So what we have in newlib is how it's defined on Linux. Howver, shouldn't autogen have the same problem on Linux then? If not, any idea why? 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
Corinna Vinschen wrote: Having said that, should we really rename the registry keys, what do we do with the Program Options and the two heap_foo values? Should they be moved to the new registry key? If yes, should the postinstall script I created a couple of days ago also move them? For the heap_chunk settings, couldn't they simply be moved into $CYGWIN? Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 15 11:31, Corinna Vinschen wrote: On Apr 15 02:29, Brian Dessent wrote: Corinna Vinschen wrote: Having said that, should we really rename the registry keys, what do we do with the Program Options and the two heap_foo values? Should they be moved to the new registry key? If yes, should the postinstall script I created a couple of days ago also move them? For the heap_chunk settings, couldn't they simply be moved into $CYGWIN? Unfortunately, no. The environment initialization requires that the memory initialization has already be done. Of course, what we could do is to create a ../etc/cygwin.conf file which is read when the first cygwin process starts... Corinna
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
First of all, I couldn't have said anything better than Brian did. On Apr 14 20:37, Brian Dessent wrote: For example I recently tracked down a configure issue in autogen where it assumed the BSD signatures of the types used with funopen(), which differ from the implementation in newlib. They do? How and Why? Is that something which should be rather fixed in newlib instead of in the autogen configuration? 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 15 10:55, Corinna Vinschen wrote:
On Apr 14 20:02, Brian Dessent wrote:
Christopher Faylor wrote:
Yes, I know. I just don't think it clarifies anything to put a Red
Hat in the registry.
I was thinking Cygwin would be better as well, but since it is
supposed to be a two-level heirarchy how about
HK{LM,CU}\Software\Cygwin Project\Cygwin. It has always seemed to me
that we actively try to de-emphasize any association that Red Hat has in
the actual day-to-day operation of the project, other than owning the
copyrights and having their own commercial fork. Likewise with the
Well, not exactly. I have done a lot of my 1.7 development lately on
blessed Red Hat time. The IPv6 changes and the long path name support
wouldn't be as progressed as they are if I hadn't got enough paid time
to do them. I don't think that deserves to be ignored.
Having said that, should we really rename the registry keys, what do we
do with the Program Options and the two heap_foo values? Should
they be moved to the new registry key? If yes, should the postinstall
script I created a couple of days ago also move them?
Btw., I think the postinstall script as part of the Cygwin package was a
bad idea. I will create another package called base-cygwin which will
contain this script as well as a few scripts in /bin which allow users
to resurrect their HKCU keys and values.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
Corinna Vinschen wrote: I see. So what we have in newlib is how it's defined on Linux. Howver, shouldn't autogen have the same problem on Linux then? If not, any idea why? I suppose it's because on linux, HAVE_FOPENCOOKIE would be set and this code would be skipped. It was only when HAVE_FOPENCOOKIE was not defined but HAVE_FUNOPEN was that it tried to include the typedefs. The HAVE_FOPENCOOKIE codepath was unusable on Cygwin because it assumed presence of libio.h when fopencookie() is present, and while newlib has fopencookie() it has no such libio.h. I haven't looked at CVS autogen but Bruce said he was going to fix both of these issues so hopefully this is all resolved now. Brian
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 4/15/2008 3:50 AM: | | I see. So what we have in newlib is how it's defined on Linux. fopencookie matches Linux. Linux does not have funopen. I guess the reason funopen disagrees with BSD is that BSD took a different path to 64-bit I/O than newlib years ago; I'm not sure that I broke things any worse than they already were when I worked on making funopen reliable (it was already declared before my patches). | Howver, shouldn't autogen have the same problem on Linux then? I guess the problem here is that autogen assumed a header that newlib doesn't provide - it would be relatively easy to add a stub libio.h to cygwin (or even newlib). Speaking of newlib stdio functions, shouldn't we go ahead and export fopen_memstream and fmemopen, as those will be required by POSIX 200x (and have a more standardized interface than either funopen or fopencookie)? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgEmjwACgkQ84KuGfSFAYAAGACgqVftklHTBGx9OkOlhaax9WwH GrMAoMjwdL67vt8ekVKNQI5XfC0g3ws3 =iijv -END PGP SIGNATURE-
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
On Apr 15 06:06, Eric Blake wrote: Speaking of newlib stdio functions, shouldn't we go ahead and export fopen_memstream and fmemopen, as those will be required by POSIX 200x (and have a more standardized interface than either funopen or fopencookie)? IIRC, you implemented it. Did I miss a patch from you to cygwin-patches to enable them in Cygwin? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 4/15/2008 6:15 AM: | On Apr 15 06:06, Eric Blake wrote: | Speaking of newlib stdio functions, shouldn't we go ahead and export | fopen_memstream and fmemopen, as those will be required by POSIX 200x (and | have a more standardized interface than either funopen or fopencookie)? | | IIRC, you implemented it. Did I miss a patch from you to cygwin-patches | to enable them in Cygwin? I thought I had, but looking in the archives, I don't see it. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgEnuQACgkQ84KuGfSFAYA87gCfXztHIDKbczA5FKkbbDbUdpgs NUYAnirRCVlUcgGr0yX1z5SuftJtmszE =jj44 -END PGP SIGNATURE-
setup-1.7 defaults to Just me
Brian, I just found that, regardless of my privileges, setup-1.7 defaults to install for just me instead of all users while the standard setup defaults to all users. Why does that happen? 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 Tue, Apr 15, 2008 at 11:08:49AM +0200, Corinna Vinschen wrote:
On Apr 15 10:55, Corinna Vinschen wrote:
On Apr 14 20:02, Brian Dessent wrote:
Christopher Faylor wrote:
Yes, I know. I just don't think it clarifies anything to put a Red
Hat in the registry.
I was thinking Cygwin would be better as well, but since it is
supposed to be a two-level heirarchy how about
HK{LM,CU}\Software\Cygwin Project\Cygwin. It has always seemed to me
that we actively try to de-emphasize any association that Red Hat has
in the actual day-to-day operation of the project, other than owning
the copyrights and having their own commercial fork. Likewise with the
Well, not exactly. I have done a lot of my 1.7 development lately on
blessed Red Hat time. The IPv6 changes and the long path name support
wouldn't be as progressed as they are if I hadn't got enough paid time
to do them. I don't think that deserves to be ignored.
Having said that, should we really rename the registry keys, what do we
do with the Program Options and the two heap_foo values?
I'd like to keep the Program Options and nuke the heap_foo options.
I also object to using Red Hat as the owner regardless of how much
paid work you've been able to do. I think it sends an extremely mixed
message for the public Cygwin project to be viewed as owned by Red Hat
while we solicit donations to help with development on the Cygwin web
site. I've been paid by a few companies to work on Cygwin and have been
spent long hours tracking down bugs for them. Additionally, most of the
work I have done for Cygwin in the past was done in my spare time even
when I was a paid employee
While I realize that you've spent quite a bit more time being paid by
Red Hat to make ipv6 and long path names work, I don't think that
necessarily translates into using Red Hat as the owner key in the
registry.
Also, given that this is a Windows project I have to wonder just how
much Red Hat would desire to have their names in the Windows Registry.
cgf
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
On Mon, Apr 14, 2008 at 8:11 AM, Corinna Vinschen [EMAIL PROTECTED] wrote: Hi all, we're now finally starting the release cycle for Cygwin 1.7. Not everything is in it's place, some changes are still in flux and the installation is still somewhat bumpy but we should get to all of that while testing goes on. We have set up a new release area which is dedicated to the 1.7 release. This allows us to test the new Cygwin DLL in a complete distro environment without breaking the standard release. This standard release will get frozen at one point, when we think it's safe enough to switch the community to the new distro. The old one stays available for Windows 95/98/Me users. So far the new release area is a copy of the existing one. To access it, you have to use a special setup.exe version you get from http://cygwin.com/setup-1.7.exe I was / am very happy to see this available. I frequently run in to the path / filename too long error. I downloaded this version of setup and when I run it (I have tested it against 5 or 6 different mirrors), it fails on 99% complete. The setup dialog shows that it is Downloading _update-info-dir-00743-1.tar.bz2. Is there anything I can do to get past this point? Thanks Troy
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 15 10:17, Christopher Faylor wrote: On Tue, Apr 15, 2008 at 11:08:49AM +0200, Corinna Vinschen wrote: Having said that, should we really rename the registry keys, what do we do with the Program Options and the two heap_foo values? I'd like to keep the Program Options and nuke the heap_foo options. Maybe you can get rid of heap_chunk_in_mb but it's still not clear that we can get rid of heap_slop_in_mb. The strange allocation in 2003 and later is a problem and just because we had nobody complaining for a while doesn't mean the current slop value is always sufficient. I'm for keeping this option. I also object to using Red Hat as the owner [...] Red Hat *is* the owner of the code, regardless of the registry key you want to use. I know that you have mixed feelings about Red Hat, however, assuming the code is owned by the FSF, would you object against a parent key name of FSF as well? 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
2008/4/15, Corinna Vinschen: On Apr 15 10:17, Christopher Faylor wrote: I also object to using Red Hat as the owner [...] Red Hat *is* the owner of the code, regardless of the registry key you want to use. I know that you have mixed feelings about Red Hat, however, assuming the code is owned by the FSF, would you object against a parent key name of FSF as well? Cannot we just use just Cygwin as the most obvious choice. We really don't have to use some artificial company name. -- Reini
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Tue, Apr 15, 2008 at 05:44:00PM +0200, Corinna Vinschen wrote: On Apr 15 10:17, Christopher Faylor wrote: On Tue, Apr 15, 2008 at 11:08:49AM +0200, Corinna Vinschen wrote: Having said that, should we really rename the registry keys, what do we do with the Program Options and the two heap_foo values? I'd like to keep the Program Options and nuke the heap_foo options. Maybe you can get rid of heap_chunk_in_mb but it's still not clear that we can get rid of heap_slop_in_mb. The strange allocation in 2003 and later is a problem and just because we had nobody complaining for a while doesn't mean the current slop value is always sufficient. I'm for keeping this option. I also object to using Red Hat as the owner [...] Red Hat *is* the owner of the code, regardless of the registry key you want to use. I know that you have mixed feelings about Red Hat, however, assuming the code is owned by the FSF, would you object against a parent key name of FSF as well? Ok, since my motives for having an opinion are in question, I will withdraw from the discussion, rather than spending time on pointless self-justification. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 15 13:59, Christopher Faylor wrote: On Tue, Apr 15, 2008 at 05:44:00PM +0200, Corinna Vinschen wrote: Red Hat *is* the owner of the code, regardless of the registry key you want to use. I know that you have mixed feelings about Red Hat, however, assuming the code is owned by the FSF, would you object against a parent key name of FSF as well? Ok, since my motives for having an opinion are in question, I will withdraw from the discussion, rather than spending time on pointless self-justification. I apologize for making this argument. It was needless, pointless and rude. Since everybody else seems to dislike the company name in the registry key, I will not further argue against using Cygwin Project\Cygwin or just Cygwin. 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
Corinna Vinschen wrote: I will not further argue against using Cygwin Project\Cygwin or just Cygwin. I guess the one name no one can strongly argue against is the one we're using right now: perfect or outdated as it may be, it has at least one reason to be (retro-compatibility). PS: my only WinXP box is still waiting for his motherboard back from RMA... I'll try qemu to test cygwin-1.7 and, if it's not too slow, produce updated packages for both 1.5 and 1.7 (or is 1.7 near enough that is better to update that first?). -- Lapo Luchini [EMAIL PROTECTED] (OpenPGP X.509) www.lapo.it (Jabber, ICQ, MSN)
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 4/15/2008 12:38 PM: | | Since everybody else seems to dislike the company name in the registry | key, I will not further argue against using Cygwin Project\Cygwin or | just Cygwin. I hate unnecessary spaces. Can we go with Cygwin rather than Cygwin Project, so that scripts using /proc/registry don't have to worry about the space? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgE+y0ACgkQ84KuGfSFAYByzgCcDyXFFF9/0lgFJjUD6kNt0UJK /gEAniAU01A0w3WdNHYy5eKPraNzoL2Q =kfbj -END PGP SIGNATURE-
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Eric Blake wrote:
I hate unnecessary spaces. Can we go with Cygwin rather than Cygwin
Project, so that scripts using /proc/registry don't have to worry about
the space?
The only reason I suggested Cygwin Project\Cygwin is that it's
supposed to be a two level hierarchy, company\product, matching the
current Cygnus Solutions\Cygwin arrangement.
However, after a quick jaunt through HKLM\Software on this machine I see
that there are a good number of programs that forego the two level
custom and just put keys under HKLM\Software\Foo. So, with that in
mind, are there any objections to simply HK{LM,CU}\Software\Cygwin?
Brian
Re: setup-1.7 defaults to Just me
Corinna Vinschen wrote: I just found that, regardless of my privileges, setup-1.7 defaults to install for just me instead of all users while the standard setup defaults to all users. Why does that happen? This is very odd. Setup's is_admin() was returning 0 despite the user belonging to the administrators group, and debugging revealed that the cause was the following: // Get the group token information UCHAR token_info[1024]; PTOKEN_GROUPS groups = (PTOKEN_GROUPS) token_info; DWORD token_info_len = sizeof (token_info); status = GetTokenInformation (token, TokenGroups, token_info, token_info_len, token_info_len); CloseHandle (token); if (!status) return 0; For whatever reason, GetTokenInformation was failing and returning ERROR_NOACCESS when passed a 1024 byte buffer. I changed the code to first call it with NULL to get the desired size, and that seems to have satisfied it. I cannot explain why it would object to a 1024 byte buffer, maybe you have some idea. I'll install an updated setup-1.7.exe in a moment. Brian
