Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 13 15:35, Christopher Faylor wrote: On Sun, Apr 13, 2008 at 11:42:46AM +0200, Corinna Vinschen wrote: We would need to transfer them to the new place or we stick to the Cygnus Solutions for backward compatibility. I'm not sure we still need the Program Options thingy. I never heard about anybody actually using heap_slop_in_mb and only fortran programmers seem to need heap_chunk_in_mb :) I use Program Options (since I invented it) but I'm probably the only person in the known universe to do so. Are you suggesting to remove the Program Options? I admit I never quite understood what to do with them which I couldn't put into a script. I'm all for changing the name from Cygnus Solutions to Red Hat, but OTOH I think keeping the name of the key is more hassle free. Can't it just be Cygwin rather than Cygnus Solutions or Red Hat? By definition the key under the Software key is supposed to be the company name, the next key is the product key, os it should contain the Red Hat *iff* we change it. I'm not sure, though, we should change it at all. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] xmds-1.6.5
On Apr 13 11:49, Dr. Volker Zell wrote: Corinna Vinschen writes: Gentoo is not valid since it packs everything, including the kitchen sink. For Debian we require that it's in stable. But if it's in Ubuntu, it's ok. Now *somebody* has to review it... hint, hint Is that me ? I didn't mean you personally. I just hoped that somebody would review the package. Not many reviewers except you are left for some reason :( The more I'm glad that you still review often and thorough. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] transfig: Tools for creating TeX documents with graphics
On Apr 13 21:49, Dr. Volker Zell wrote: wget http://volkerzell.de/cygwin/ITP/transfig/setup.hint wget http://volkerzell.de/cygwin/ITP/transfig/transfig-3.2.5-1-src.tar.bz2 wget http://volkerzell.de/cygwin/ITP/transfig/transfig-3.2.5-1.tar.bz2 Looks good, uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[HEADSUP] Start of Cygwin 1.7 release cycle
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 The idea is this: - You set up a local Cygwin 1.7 installation. - You build the packages you maintain under that Cygwin 1.7 release. - You prepare the packages for uploading into the 1.7 release area. - You report bugs to the cygwin list (maybe we should set up a temporary cygwin-test mailing list for a couple of months?). Over the time the Cygwin 1.7 release area will be populated with corresponding packages. The more packages we have, the easier will get further testing, especially for the two most intrusive changes, IPv6 support and long path names. However, right now we have still a problem. The new Cygwin DLL uses /etc/fstab and /etc/fstab.d/$USER files instead of the registry for the mount table. While this decouples the new release from an old one in terms of mount points, setup.exe still accesses and creates registry mount points and stumbles over that. As a result, for now I'd suggest to install Cygwin 1.7 only if you have a spare machine or in a distinct virtual machine. Once setup can deal with a parallel 1.5 release, this gets much easier. Below you'll find a list of the major changes from 1.5 to 1.7. Please read it carefully. The most important changes on the user level are the long path name support including UTF-8 character support, as well as IPv6. Other changes are also important, but these two will likely have the most impact. I'd like to ask you to keep an eye especially on them when building and testing. The most important changes on the application level are the new Cygwin functions for path name conversion between DOS and POSIX filenames which, in contrast to the previous functions, allow long path names. The old functions are marked as obsolete in the header file, so you will get approrpiate warnings if your application is using them. The new functions are already documented (including example code), though, for the time being, only in the Cygwin sources (see winsup/cygwin/path.sgml). Please note that, besides other stuff, two really crucial changes are still missing: - Native Language Support and the character set handling according to $LANG and $LC_CTYPE is still lacking. I'm glad to report that Kazuhiro Fujieda volunteered to work on that. For now, you have to set CYGWIN=codepage:utf8 as well as LC_CTYPE=C-UTF-8 to get UTF-8 support working. This should get much simpler and better after Kazuhiro's patches. - Documentation (Help!) Ok, if something is unclear, feel free to ask. Other than that, enjoy the below list of changes and the new functionality. Corinna Wind^WList of Changes: == OS releated changes: - Windows 95, 98 and Me are not supported anymore. The new DLL will not run on any of these systems. File Access related changes: - Mount points are no longer stored in the registry. Use /etc/fstab and /etc/fstab.d/$USER instead. Mount points created with mount(1) are only local to the current session and disappear when the last Cygwin process in the session exits. - PATH_MAX is now 4096. Internally, path names can be as long as the underlying OS can handle (32K). - UTF-8 filenames are supported now. So far, this requires to set the environment variable CYGWIN to contain codepage:utf8, but this will likely disappear in a few weeks time. The setting of $LANG or $LC_CTYPE will be used instead. - Creating filenames with special DOS characters '', '*', ':', '', '', '|' is supported. - Creating files with special DOS device filename components (aux, nul, prn) is supported. - Managed mounts are now identical to normal mounts, except they allow to create files only differing by case (abc, Abc, ABC). - unlink(2) and rmdir(2) try very hard to remove files/directories even if they are currently accessed or locked. This is done by utilizing the hidden recycle bin directories and marking the files for deletion. - rename(2) rewritten to be more POSIX conformant. - Add st_birthtim member to struct stat. - File locking is now advisory, not mandatory anymore. The fcntl(2) and the new lockf(2) APIs create and maintain locks with POSIX semantics, the flock(2) API
Re: [ITA] transfig: Tools for creating TeX documents with graphics
Corinna Vinschen writes: On Apr 13 21:49, Dr. Volker Zell wrote: wget http://volkerzell.de/cygwin/ITP/transfig/setup.hint wget http://volkerzell.de/cygwin/ITP/transfig/transfig-3.2.5-1-src.tar.bz2 wget http://volkerzell.de/cygwin/ITP/transfig/transfig-3.2.5-1.tar.bz2 Looks good, uploaded. Thanks. xfig should be uploaded too. The URL's are still the old ones. My tests so far are working. For downloading cut here #!/bin/bash mkdir -p xfig/xfig-lib cd xfig wget http://volkerzell.de/cygwin/ITP/xfig/setup.hint wget http://volkerzell.de/cygwin/ITP/xfig/xfig-3.2.4-7-src.tar.bz2 wget http://volkerzell.de/cygwin/ITP/xfig/xfig-3.2.4-7.tar.bz2 cd xfig-lib wget http://volkerzell.de/cygwin/ITP/xfig/xfig-lib/setup.hint wget http://volkerzell.de/cygwin/ITP/xfig/xfig-lib/xfig-lib-3.2.4-7.tar.bz2 cut here Ciao Volker
Re: [ITA] transfig: Tools for creating TeX documents with graphics
On Apr 14 15:26, Dr. Volker Zell wrote: wget http://volkerzell.de/cygwin/ITP/xfig/setup.hint wget http://volkerzell.de/cygwin/ITP/xfig/xfig-3.2.4-7-src.tar.bz2 wget http://volkerzell.de/cygwin/ITP/xfig/xfig-3.2.4-7.tar.bz2 cd xfig-lib wget http://volkerzell.de/cygwin/ITP/xfig/xfig-lib/setup.hint wget http://volkerzell.de/cygwin/ITP/xfig/xfig-lib/xfig-lib-3.2.4-7.tar.bz2 Thanks, uploaded. 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 Mon, Apr 14, 2008 at 03:11:56PM +0200, Corinna Vinschen 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. I was hoping to get a little more feedback on using the union fs before we announce this. I'd like to use the mechanism that I mentioned since it would be the most transparent for package maintainers. In keeping with the full-steam approach I guess I'll put it into place today. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Mon, Apr 14, 2008 at 11:56:28AM +0200, Corinna Vinschen wrote: On Apr 13 15:35, Christopher Faylor wrote: On Sun, Apr 13, 2008 at 11:42:46AM +0200, Corinna Vinschen wrote: We would need to transfer them to the new place or we stick to the Cygnus Solutions for backward compatibility. I'm not sure we still need the Program Options thingy. I never heard about anybody actually using heap_slop_in_mb and only fortran programmers seem to need heap_chunk_in_mb :) I use Program Options (since I invented it) but I'm probably the only person in the known universe to do so. Are you suggesting to remove the Program Options? I admit I never quite understood what to do with them which I couldn't put into a script. ? Program Options are not intended to be put in a script. They are intended to be set once to cygwin environment variable settings and then forgotten. It's somewhat equivalent to setting a global cygwin environment variable and could be used to set a per-system or per-user policy. I'm all for changing the name from Cygnus Solutions to Red Hat, but OTOH I think keeping the name of the key is more hassle free. Can't it just be Cygwin rather than Cygnus Solutions or Red Hat? By definition the key under the Software key is supposed to be the company name, the next key is the product key, os it should contain the Red Hat *iff* we change it. I'm not sure, though, we should change it at all. Yes, I know. I just don't think it clarifies anything to put a Red Hat in the registry. cgf
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
On Apr 14 10:39, Christopher Faylor wrote: On Mon, Apr 14, 2008 at 03:11:56PM +0200, Corinna Vinschen 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. I was hoping to get a little more feedback on using the union fs before we announce this. I'd like to use the mechanism that I mentioned since it would be the most transparent for package maintainers. In keeping with the full-steam approach I guess I'll put it into place today. Oh, hmm, I assumed you would do that anyway at one point. I'm just a bit surprised that the resulting purged directory is still that big. I thought that more than half the size would be obsolete and prev packages. 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 Mon, Apr 14, 2008 at 05:27:58PM +0200, Corinna Vinschen wrote: On Apr 14 10:39, Christopher Faylor wrote: On Mon, Apr 14, 2008 at 03:11:56PM +0200, Corinna Vinschen 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. I was hoping to get a little more feedback on using the union fs before we announce this. I'd like to use the mechanism that I mentioned since it would be the most transparent for package maintainers. In keeping with the full-steam approach I guess I'll put it into place today. Oh, hmm, I assumed you would do that anyway at one point. It will be a pain in the neck to do it if people start updating the current cygwin-2 directory while I'm trying to perfect the unionfs version. I'm just a bit surprised that the resulting purged directory is still that big. Yes, well, er, there was a pretty serious bug in my purge script on the order of How could that have possibly done anything right? variety. Looks like I have to start from scratch and do the purge again. Sigh. cgf
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
On Apr 14 11:42, Christopher Faylor wrote: On Mon, Apr 14, 2008 at 05:27:58PM +0200, Corinna Vinschen wrote: Oh, hmm, I assumed you would do that anyway at one point. It will be a pain in the neck to do it if people start updating the current cygwin-2 directory while I'm trying to perfect the unionfs version. Ok, so let's not create new packages for the next couple of days. I will just update the Cygwin package itself if serious bugs crop up, that should be ok, right? Just for clarity, do you mean release-2 parallel to release, or cygwin-2 parallel to the parent cygwin dir? I'd expect the latter might actually break a lot of mirrors which explicitely mirror the cygwin directory only. release-2 seems less error prone on the mirror side. 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
The most important changes on the user level are the long path name support including UTF-8 character support, as well as IPv6. Other changes are also important, but these two will likely have the most impact. I'd like to ask you to keep an eye especially on them when building and testing. OK, a few questions and comments: (1) Do all packages that include compiled code need to be rebuilt for Cygwin 1.7? IOW, is ABI compatibility broken from 1.5? Also, I presume that there would be no need to rebuild any packages that don't include compiled code, e.g. packages that depend only on Perl or Python. (2) If I understand right, the implication here seems to be that although Cygwin 1.7 will support the above features, it's going to be up to us package maintainers to ensure, or at least just test, that our packages support them too. But, there seems to be no requirement about that. That is, we could just dump our packages as they are into Cygwin 1.7, and not test them for any of the new supported features, assuming our consciences allow this. Correct? (3) For packages that have been tested, are we going to have a standard and/or common location or format in which to put our tested against Cygwin 1.7/tested for long file name/UTF-8/IPv6/etc. support results? Or just note the results or not in our README.Cygwin files? The latter seems fine to me, I'm just wondering. (4) It seems that it might be useful to develop standard unit tests for some of these features. Long file name support is simple enough-- we just have to create some path names longer than 260 characters, and try feeding them to our applications. But for UTF-8 and IPv6 support, it could take each of us a lot of time to work out tests on our own. Or at least, it would take me a while since I'm mostly ignorant of them... A standard, documented approach would sure help me, and maybe other packagers too. I freely admit though that I am not volunteering to do this. Thanks, Andrew.
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Sat, 12 Apr 2008, Brian Dessent wrote: Unresolved issues with this plan: - What are we going to do about text/binary mode? To maintain the setting, setup would have to be taught to parse/write fstab. Ugh. Plan B would be to say that if you want textmode you have to edit fstab yourself. That has the advantage of making it harder to use textmode, which leads to fewer bugreports. On the other hand, the small army of insane people that do actually use textmode will probably be mad that they have to manually edit config files (the horror!) because the setup tool no longer has a choice. 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. It might make it easier if mount understood absolute POSIX paths as well (i.e., mount -t /etc/text /etc/text should work). 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). - Do we really want to pick a new key for $newkey, or wedge it into the same existing location somehow? I admit that I do find it a bit silly that Cygwin still installs under Cygnus Solutions, and since a 1.7 DLL will not even look at the registry I guess it is proper to move to a totally new key for this setting. And of course for the 1.7 testing period we'd want it to be separate. But I mean long term, are we making 3rd parties lives easier or harder by having two totally different places/formats to check for an existing install of Cygwin? I agree that naming the new key Cygnus Solutions is silly, beyond certain nostalgic value. But one thing to consider is that by adding a registry key, we're setting things up for one dominant installation of Cygwin. So people juggling multiple installations really *will* have to go edit the registry to switch -- no more nice mount -m approach, since the mounts will no longer apply anyway. Also, things like heap_chunk_in_mb currently live in the registry. Will they stay there? Will we instead have /etc/cygwinopts (or move it to $CYGWIN)? 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
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
Company ID in the resource strings for cygwin1.dll, listing Red Hat
always seemed a bit off to me, but I recognise that if we have to list a
real company that Red Hat is the obvious choice.
Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Igor Peshansky wrote: But one thing to consider is that by adding a registry key, we're setting things up for one dominant installation of Cygwin. So people juggling multiple installations really *will* have to go edit the registry to switch -- no more nice mount -m approach, since the mounts will no longer apply anyway. Can you clarify what you mean here? I don't understand. You're talking about maintaining separate installs, but part of the plan for setup.exe that I outlined supports this directly by the fact that if you change the value of the root install dir at step 2, setup then forgets anything it knew about the previous value, enabling you to keep around as many parallel installs as you want. Or do you mean keeping around an old-style 1.5 tree and a new-style 1.7 tree simultaneously? In that case you'd be using the old setup.exe (which doesn't know a thing about $newkey) for the 1.5 tree so I still don't see any conflict. Where does the need to edit the registry manually arise? Brian
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
Andrew Schulman wrote: (1) Do all packages that include compiled code need to be rebuilt for Cygwin 1.7? IOW, is ABI compatibility broken from 1.5? Also, I presume that there would be no need to rebuild any packages that don't include compiled code, e.g. packages that depend only on Perl or Python. No, it should be fully ABI backwards compatible, it's just that recompilation will be required to enable the new features. For example if the app allocated its path buffers based on PATH_MAX (260 in 1.5, 4096 in 1.7), it will not be able to take advantage of long pathnames even if the DLL would support it. And likewise for ipv6 support, fopencookie, etc. Those features would not have been detected by the package's configure script and thus disabled in 1.5, but they would be detected and enabled when rebuilt against 1.7. And it's that fact (new codepaths exposed in the app) that needs testing. (2) If I understand right, the implication here seems to be that although Cygwin 1.7 will support the above features, it's going to be up to us package maintainers to ensure, or at least just test, that our packages support them too. But, there seems to be no requirement about that. That is, we could just dump our packages as they are into Cygwin 1.7, and not test them for any of the new supported features, assuming our consciences allow this. Correct? Well, part of the implication of the above is that some packages might not build against 1.7 without tweaks. 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. funopen/fopencookie didn't exist in 1.5 and are new in 1.7, so these issues would have never been exposed when building the package against 1.5, but the new feature exposed the codepath in autogen that tried to use funopen, which needed some tweaks to work with Cygwin. In my completely unofficial opinion I'd say that it's always at the maintainer's judgement how to deal with these things. In most cases if a feature does not work you can simply disable it by configuring with --disable-foo, or e.g. in the case of autogen by configuring with ac_cv_func_fopencookie=no ac_cv_func_funopen=no ./configure ... forced those features to be disabled since the configure tests were broken. But ideally it would be best if whatever compatibility problems arise can be dealt with so that the package builds as close to OOTB as possible, and so that the new functionality is enabled in the app. (3) For packages that have been tested, are we going to have a standard and/or common location or format in which to put our tested against Cygwin 1.7/tested for long file name/UTF-8/IPv6/etc. support results? Or just note the results or not in our README.Cygwin files? The latter seems fine to me, I'm just wondering. I can't speak for anyone else but the way I invisioned this working is: - maintainer uploads 1.7-built package to the 1.7 release area - other 1.7 testers install it in their 1.7 tree - problems are reported to this list - maintainers fix the issues, upload updated packages to the 1.7 release area - after sufficient iterations of this, the 1.7 area is declared ready for prime time, and is switched over to the default distro instead of being a sandboxed area Of course if you want to note in the README.Cygwin the changes/tweaks that were necessary for each package bump, that would probably help everyone. But the fact that the package exists in the 1.7 area at the time that it goes live would be the main indicator that it's passed somebody's definition of (at least minimal) working. In other words, if there's some really hairy unsolvable problem with a 1.7-built package, it should be removed from the 1.7 area and the old 1.5-built version used until the problem is fully resolved. (4) It seems that it might be useful to develop standard unit tests for some of these features. Long file name support is simple enough-- we just have to create some path names longer than 260 characters, and try feeding them to our applications. But for UTF-8 and IPv6 support, it could take each of us a lot of time to work out tests on our own. Or at least, it would take me a while since I'm mostly ignorant of them... A standard, documented approach would sure help me, and maybe other packagers too. I freely admit though that I am not volunteering to do this. Yes, I'm sure all of those things would be helpful. We don't have to be perfect either. We should be realistic in that the number of people that are clued enough to monitor this list and download a separate setup.exe and follow the steps to install an experimental distro is going to be much smaller than the general userbase of Cygwin, so we won't be able to suss out every problem before the 1.7 area goes live. I think that's fine, we just need to get things into a good enough state. Brian
