Re: New Cygwin 1.7.0-18 in release-2
On Jul 23 21:44, John Morrison wrote: On Wed, July 23, 2008 7:00 pm, Corinna Vinschen wrote: I'd be happy if even the most important packages have been rebuilt for 1.7. So far the reactions from the package maintainers were somewhat reticent. I think that'll probably alter once there's a setup for 1.7. Speaking personally I *need* my installation of cygwin and couldn't stand to be without it. (I will get 'round to patching the base packages, but I was/did hand these over to Igor; is he still around?) Igor is still around, yes. I didn't know (or forgot again) you handed over maintainership of the base packages. Igor? X under 1.7 is a requirement for me. Just wish I had the skills to get the latest version working. OTOH I'm not sure what the user reaction would be. I suppose one compromise would be to require users to rm -fr /etc/setup before upgrading to 1.7. Once X works, that works for me :) Why is X so important for testing and building packages? I mean, the console window and rxvt exist, right? Personally I'm doing a lot in my Linux X console, connecting to my Windows machines via rdesktop and ssh in an xterm. Btw., since 1.5 and 1.7 can co-exist running in different directories, there should be no problem running 1.7 based rxvt/xterm in a 1.5 X server. We *really* need a new setup for 1.7 which doesn't access the Cygnus Solutions registry key anymore. Agreed :( J. (attempting to find some time!) Please with sugar? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
On Thu, July 24, 2008 10:08 am, Corinna Vinschen wrote: On Jul 23 21:44, John Morrison wrote: On Wed, July 23, 2008 7:00 pm, Corinna Vinschen wrote: I'd be happy if even the most important packages have been rebuilt for 1.7. So far the reactions from the package maintainers were somewhat reticent. I think that'll probably alter once there's a setup for 1.7. Speaking personally I *need* my installation of cygwin and couldn't stand to be without it. (I will get 'round to patching the base packages, but I was/did hand these over to Igor; is he still around?) Igor is still around, yes. I didn't know (or forgot again) you handed over maintainership of the base packages. Igor? X under 1.7 is a requirement for me. Just wish I had the skills to get the latest version working. OTOH I'm not sure what the user reaction would be. I suppose one compromise would be to require users to rm -fr /etc/setup before upgrading to 1.7. Once X works, that works for me :) Why is X so important for testing and building packages? testing and building no, but I suspect that for most maintainers (at least those with only one or two packages) the package is a 'thank you' back to cygwin for the environment so the stability of the environment is very important. I know that's why I started with the base- packages, 'cause I wanted to improve the 'out of the box' experience. I mean, the console window and rxvt exist, right? Personally I'm doing a lot in my Linux X console, connecting to my Windows machines via rdesktop and ssh in an xterm. Btw., since 1.5 and 1.7 can co-exist running in different directories, there should be no problem running 1.7 based rxvt/xterm in a 1.5 X server. I didn't know that. (attempting to find some time!) Please with sugar? I only have windows at work now and all my time is 'allocated' to projects... trying! If I don't get it done before the weekend I'll get a virtual machine running. Promise. J.
Re: New Cygwin 1.7.0-18 in release-2
On Jul 23 22:44, Yaakov (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: | I'd be happy if even the most important packages have been rebuilt for | 1.7. So far the reactions from the package maintainers were somewhat | reticent. I know I've been holding back because of the apparent difficulties in transitioning between versions (even one way, not to mention back-and-forth), and until recently the uncertainty as to the timeframe for 1.7. I am at the point that I am ready to consider switching, however. I'm building OpenSSH as 1.5 and 1.7 version in different build dirs. I had no transitioning problems. Maybe that's because the build system is rather simple or something. Admittedly, except for openssh, openssl and syslog-ng and a local BETA vim7.2a I didn't bother to create more 1.7 packages so far. I was mainly interested in IPv6. | I'm still rather trying to smooth out the upgrade path so that there | are as little as possible manual changes left to the user. It will | be bumpy nevertheless... IOW you want to leave upgrading in the same root a possibility. Is it really worth it? Honestly, I don't know. Maybe it isn't. But so far I'm still thinking that a parallel 1.7 install should only be a temporary solution for developers and maintainers. It's not something I would like to drag on for years. That's why an upgrade path has some merits for me. | The problem so far is the Cygnus Solutions registry key and the | default name of the cygwin dir, C:\cygwin. When you try to install | 1.7, both shouldn't exist. So what I did is this: I understand the registry key is due to setup. But what's the problem with C:\cygwin? So far setup looks if c:\cygwin exists and if so, uses the install database in c:\cygwin\etc\setup accidentelly, even if you choose to install another installation to, say, D:\cygwin-2. | We *really* need a new setup for 1.7 which doesn't access the Cygnus | Solutions registry key anymore. Agreed, **ASAP**. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New Cygwin 1.7.0-18 in release-2
On Jul 24 10:17, John Morrison wrote: On Thu, July 24, 2008 10:08 am, Corinna Vinschen wrote: Please with sugar? I only have windows at work now and all my time is 'allocated' to projects... trying! If I don't get it done before the weekend I'll get a virtual machine running. Promise. Thanks! Btw., all my Windows machines are virtual machines. Even my domain controller is running in a VM :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFC] 1.7 Packaging: Obsolete packages
On Jul 23 23:43, Yaakov (Cygwin Ports) wrote: What I *do* know about by now is porting and packaging for Cygwin, having done it for almost five years now. And with the transition to 1.7 coming up, there are a few general packaging issues that I think it would be timely to address. Can't contribute much to your points but... The first thing is that I think a mass rebuild is in order. There are too many packages that are outdated, dependent on old libraries, or that would greatly benefit from the new features in 1.7 (or 1.5 for that matter). To reiterate, the most important features of Cygwin 1.7 to consider when rebuilding packages, because of how they influence building applications are: - IPv6 support, new functions getaddrinfo, getnameinfo. - minires and libresolv.a are now part of Cygwin. - PATH_MAX has changed from 260 to 4096. getcwd() can potentially return paths of up to 32K. - Potentially case sensitivity file operations (on OSes and FSes supporting it). - New file conversion API for conversion from Win32 to POSIX path and vice versa (cygwin_conv_path, cygwin_create_path, cygwin_conv_path_list). 1) try to make 1.5-1.7 like 1.5.x-1.5.y. *If* it's possible, then this would theoretically make it easier for users to upgrade. When the necessary packages are rebuilt, then the old libraries could be removed from the distro, but the empty compatibility packages may need to remain. 2) start over with a new install. This may be more difficult for users, depending on how they use Cygwin, and depending on what will ultimately be necessary for handling a straight upgrade. As for the packaging, it would give us the chance to dump a lot of old baggage and make some additional changes without worrying about now-ancient history. I'm not sure if there's really a big difference between these two points. Since we're using two different installation directories, we can get rid of old cruft, if we just look carefully what's still used and what not. The release-2 directory has already no obsolete packages anymore. Stuff like minires, which is now a part of Cygwin, can entirely go away as soon as all packages relying on resolver functions have been rebuilt. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFC] 1.7 Packaging: Toolchain
On Jul 24 00:25, Yaakov (Cygwin Ports) wrote: a) _GLIBCXX_USE_WCHAR_T Will std::wstring and friends be possible with cygwin-1.7? If not, is there anything that can be done to make it possible? I don't know if that's a problem for std::wstring, but newlib is still missing the wprintf family of functions. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFC] 1.7 Packaging: Toolchain
Corinna Vinschen wrote: I don't know if that's a problem for std::wstring, but newlib is still missing the wprintf family of functions. Based on the defintion of GLIBCXX_ENABLE_WCHAR_T in http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/acinclude.m4?view=markup the list of missing functions before wchar_t can be enabled is: fgetwc fgetws fputwc fputws fwide fwprintf fwscanf getwc getwchar putwc putwchar swprintf swscanf ungetwc vfwprintf vswprintf vwprintf wcsftime wcstod wcstok wprintf wscanf Brian
Re: New Cygwin 1.7.0-18 in release-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: | Honestly, I don't know. Maybe it isn't. But so far I'm still thinking | that a parallel 1.7 install should only be a temporary solution for | developers and maintainers. It's not something I would like to drag | on for years. That's why an upgrade path has some merits for me. I definitely agree that we don't want to support 1.5 anymore after 1.7 is stable. | So far setup looks if c:\cygwin exists and if so, uses the install | database in c:\cygwin\etc\setup accidentelly, even if you choose to | install another installation to, say, D:\cygwin-2. Would it suffice to rename /etc/setup/installed.db? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkiIqxoACgkQpiWmPGlmQSPs+wCfbBHf8/82nFnMi0495IxmgZYH 9yYAoOIsocD8gruP4uyKhWWgCiDIPj7X =DRzP -END PGP SIGNATURE-
Re: New Cygwin 1.7.0-18 in release-2
On Jul 24 11:17, Yaakov (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: | Honestly, I don't know. Maybe it isn't. But so far I'm still thinking | that a parallel 1.7 install should only be a temporary solution for | developers and maintainers. It's not something I would like to drag | on for years. That's why an upgrade path has some merits for me. I definitely agree that we don't want to support 1.5 anymore after 1.7 is stable. | So far setup looks if c:\cygwin exists and if so, uses the install | database in c:\cygwin\etc\setup accidentelly, even if you choose to | install another installation to, say, D:\cygwin-2. Would it suffice to rename /etc/setup/installed.db? I don't know, sorry. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFC] 1.7 Packaging: Toolchain
On Thu, Jul 24, 2008 at 03:53:16AM -0700, Brian Dessent wrote: Corinna Vinschen wrote: I don't know if that's a problem for std::wstring, but newlib is still missing the wprintf family of functions. Based on the defintion of GLIBCXX_ENABLE_WCHAR_T in http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/acinclude.m4?view=markup the list of missing functions before wchar_t can be enabled is: fgetwc fgetws fputwc fputws fwide fwprintf fwscanf getwc getwchar putwc putwchar swprintf swscanf ungetwc vfwprintf vswprintf vwprintf wcsftime wcstod wcstok wprintf wscanf Huh. That list is actually smaller than I would have expected. Can't we get all of these from freebsd? How about scrapping newlib in favor of freebsd libraries? I have been suggesting this for years. Maybe the timing is wrong since we want to release Cygwin ASAP but it sure would be nice to be in control of 100% of Cygwin and not have to wander over to newlib whenever we need to make changes. cgf
Re: [RFC] 1.7 Packaging: Toolchain
On Jul 24 15:24, Christopher Faylor wrote: On Thu, Jul 24, 2008 at 03:53:16AM -0700, Brian Dessent wrote: Corinna Vinschen wrote: I don't know if that's a problem for std::wstring, but newlib is still missing the wprintf family of functions. Based on the defintion of GLIBCXX_ENABLE_WCHAR_T in http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/acinclude.m4?view=markup the list of missing functions before wchar_t can be enabled is: fgetwc fgetws fputwc fputws fwide fwprintf fwscanf getwc getwchar putwc putwchar swprintf swscanf ungetwc vfwprintf vswprintf vwprintf wcsftime wcstod wcstok wprintf wscanf Huh. That list is actually smaller than I would have expected. Can't we get all of these from freebsd? Basically, yes, but not quite. At least the put/get functions and the fwide function requires integration into the newlib stdio structures and REENT support. It's not just a simple drop-in job. How about scrapping newlib in favor of freebsd libraries? I have been suggesting this for years. Maybe the timing is wrong since we want to release Cygwin ASAP but it sure would be nice to be in control of 100% of Cygwin and not have to wander over to newlib whenever we need to make changes. If we had more man power, maybe. As it is, I see no chance. We also talked about getting the above functions into newlib a few months ago on cygwin-developers. Exactly nada happened so far. As far as I'm concerned I'm glad that there's at least the libc part we only have to marginally care about. Maybe that's something for 1.9. 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 Wednesday 02 April 2008 5:35:51 am Corinna Vinschen wrote: Having said that, I would like to ask especially you package maintainers to set up a separate machine or a separate cygwin directory for the 1.7 release. Well, I'm a little slow on following and I'm not an official maintainer (yet) but I am the maintainer of the Coda distribution for Windows that uses cygwin heavily. (In fact, I do have a set of sources that build cygwin packages that we currently distribute via a private mirror. I've just not done the work to do a GTG e-mail. Part of the reason is that one of the packages, the kernel module for Coda, requires a Windows build environment to be installed even though the kernel module is compiled from a UNIX makefile ... so once the extra build environments are installed, one can do make; make install in the cygwin directory tree but I digress...) I decided to try 1.7 with Coda and rather quickly got stopped by a user/group issue in 1.7. I have my primary sources copies on a NetBSD box with Samba running on it. Works great from 1.5. Map the drive in windows, use cygwin to compile via the net.In 1.7 the user and group returned is 2^32-1 () which doesn't allow me to do anything other than read on the file server. I'm not sure if this is the right list for 1.7 bugs or if they should go to another list. If I'm wrong, I'm sure someone will tell me e.g. to the same file server and ls the same 1.5: cd /cygdrive/n ls -ldn JUNK drwxr-xr-x 1 500 513 0 May 27 10:54 JUNK 1.7: cd /cygdrive/n ls -ldn JUNK drwxr-x--- 1 4294967295 4294967295 0 Jan 14 2008 JUNK So it looks like user, group, permissions and dates are all wrong under 1.7. --Phil -- Phil Nelson (phil at cs.wwu.edu) http://www.cs.wwu.edu/nelson NetBSD: http://www.NetBSD.org Coda: http://www.coda.cs.cmu.edu signature.asc Description: This is a digitally signed message part.
Re: [RFC] 1.7 Packaging: Obsolete packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: | I'm not sure if there's really a big difference between these two points. | Since we're using two different installation directories, we can get rid | of old cruft, if we just look carefully what's still used and what not. | | The release-2 directory has already no obsolete packages anymore. Stuff | like minires, which is now a part of Cygwin, can entirely go away as | soon as all packages relying on resolver functions have been rebuilt. The difference is if I want to reorganize a package when I rebuild it for 1.7, e.g. right now I have: pcre = pcre, libpcre0, pcre-devel, pcre-doc If I want to rename pcre-devel to libpcre-devel, then normally I would need an empty _obsolete pcre-devel package which deps libpcre-devel to make the upgrade smooth. That wouldn't be necessary if we don't support upgrading to 1.7 in the same installation. That may seem like a trivial example, but a transition like X11R6 to X11R7 would be a lot bigger. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkiJE9kACgkQpiWmPGlmQSN2xQCeOih7EzNLgL4HsDjAPFeyfPMW RxgAoJEjoxN10tfbginETYl9BJRDjgoh =m1Bm -END PGP SIGNATURE-
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, Jul 24, 2008 at 03:40:51PM -0700, Phil Nelson wrote: On Wednesday 02 April 2008 5:35:51 am Corinna Vinschen wrote: Having said that, I would like to ask especially you package maintainers to set up a separate machine or a separate cygwin directory for the 1.7 release. Well, I'm a little slow on following and I'm not an official maintainer (yet) but I am the maintainer of the Coda distribution for Windows that uses cygwin heavily. (In fact, I do have a set of sources that build cygwin packages that we currently distribute via a private mirror. I've just not done the work to do a GTG e-mail. Part of the reason is that one of the packages, the kernel module for Coda, requires a Windows build environment to be installed even though the kernel module is compiled from a UNIX makefile ... so once the extra build environments are installed, one can do make; make install in the cygwin directory tree but I digress...) I decided to try 1.7 with Coda and rather quickly got stopped by a user/group issue in 1.7. I have my primary sources copies on a NetBSD box with Samba running on it. Works great from 1.5. Map the drive in windows, use cygwin to compile via the net.In 1.7 the user and group returned is 2^32-1 () which doesn't allow me to do anything other than read on the file server. I'm not sure if this is the right list for 1.7 bugs or if they should go to another list. If I'm wrong, I'm sure someone will tell me e.g. to the same file server and ls the same 1.5: cd /cygdrive/n ls -ldn JUNK drwxr-xr-x 1 500 513 0 May 27 10:54 JUNK 1.7: cd /cygdrive/n ls -ldn JUNK drwxr-x--- 1 4294967295 4294967295 0 Jan 14 2008 JUNK So it looks like user, group, permissions and dates are all wrong under 1.7. It could look like that when you look at it from 100 yards away. To get closer we'd need to see things like what your /etc/passwd and /etc/group files look like. Even cygcheck output would help. cgf
