Re: HEADSUP: Python 2.7 upgrade
On Wed, 23 Jan 2013 18:56:56 -0600, Yaakov (Cygwin/X) wrote: Jason Tishler announced last month[1] that he intends to upgrade Python to 2.7 on 01 February, which is quickly approaching. Jason, Everything but python-brlapi is in place now, so I think we're ready to do this. Shall I mark 2.7.3-1 stable and move everything in? Yaakov
Re: attn mantainer: libfltk-devel , libfltk-doc
fltk 1.3 works fine, I have been using it myself for a long time now, I do not object to moving it to stable. I will prepare an update as well. Teun Op 2013-02-06 16:31, marco atzeri schreef: On 1/27/2013 9:18 AM, marco atzeri wrote: Teun, can we move 1.3.1.9285-1 to stable, and eventually move to 1.3.2 ? They are in test for long time and I do not remember any objection to finally move from 1.1 to 1.3 [cut] Regards Marco have we lost Teun ? Marco
Re: [PATCH] setup: implement perpetual postinstall scripts
Christopher Faylor writes: I don't really see how making setup.exe always run rebaseall makes unattended installs work better. It requires less invocations of setup and yields a simpler install script which consequently has less chance of being repaired to death by someone ten timezones away when it finally gets rolled out. ??? If we need to rebase dlls then we should just run rebaseall. There isn't any reason to tell people to run setup.exe to do that. Right now you are telling users to run rebaseall after setup.exe in the FAQ, actually. Even with _autorebase, users really have to do that when they have downgraded or re-installed packages and didn't remember to also reinstall _autorebase, which they most likely didn't know about. How to run rebaseall is described in another document that they then have to find, comprehend and do. Having setup.exe take care of that and additionally providing an easier way to do the equivalent of rebase or rebaseall (the user is already familiar with setup.exe at that point) does seem like an improvement to me — if only because it requires less explanation and involves fewer opportunities for operator error. If the problem is that people are installing third-party dlls then they should get in the habit of running rebaseall. We don't want people superstitiously running setup.exe expecting it to solve their problems even when there are no new packages to install. We are apparently talking about completely disjoint sets of users and I can't hope for this discussion to lead any further. If we can't expect the unwashed to run autorebase then we could have an autorebase daemon running which just attempts to rebase dlls that it hasn't seen before every N minutes. That idea could grow on me, but just like the proposal to somehow get rid of setup.exe altogether it doesn't solve any problems in a shorter timeframe. Sorry but I don't think this is a good idea. Very well, apologies for bothering you then. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: attn mantainer: libfltk-devel , libfltk-doc
On Thu, 07 Feb 2013 19:42:24 +0100, a.rburgers wrote: fltk 1.3 works fine, I have been using it myself for a long time now, I do not object to moving it to stable. Done. Yaakov
Re: HEADSUP: Python 2.7 upgrade
Yaakov, On Thu, Feb 07, 2013 at 03:30:19AM -0600, Yaakov wrote: On Wed, 23 Jan 2013 18:56:56 -0600, Yaakov (Cygwin/X) wrote: Jason Tishler announced last month[1] that he intends to upgrade Python to 2.7 on 01 February, which is quickly approaching. Jason, Everything but python-brlapi is in place now, so I think we're ready to do this. Shall I mark 2.7.3-1 stable and move everything in? Sounds good. How should we handle the announcement(s)? Should each maintainer send their own announcement(s)? Or, should one coordinated announcement be sent? I really appreciate your help with this upgrade. Thanks, Jason
What has happened to release-legacy?
Looking at mirrors recently (last 3 or 4 days) the directory release-legacy is missing (Utah, Michigan, Illinois) and in one case where it is currently still present (Palo Alto) the file setup-legacy.ini is missing. So, unless one has it already, the Legacy version is unavailable to users. Is this a glitch or something else? Fergus -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: What has happened to release-legacy?
On 2/7/2013 8:23 AM, Fergus wrote: Looking at mirrors recently (last 3 or 4 days) the directory release-legacy is missing (Utah, Michigan, Illinois) and in one case where it is currently still present (Palo Alto) the file setup-legacy.ini is missing. So, unless one has it already, the Legacy version is unavailable to users. Is this a glitch or something else? Fergus retiring for old age... http://cygwin.com/ml/cygwin-apps/2013-02/msg00049.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: stat() and tilde prefix (was bad bash tab completion)
On 02/07/2013 12:00 AM, Shaddy Baddah wrote:
Please find the patch discussed attached. It probably needs to be a bit
more generic, maybe with some precompiler directives to limit it to
cygwin? Although if it is just for cygwin, perhaps it can just go in the
cygports patch?
The build of bash has nothing to do with cygports; if I decide to take
this, I will include something like it the next time I build bash for
cygwin.
Do I need to put an attn bash maintainer on the subject line?
Nah, I read the list.
*r++ = '\\';
/* XXX -- check for standalone tildes here and backslash-quote them */
- if (s == text *s == '~' file_exists (text))
+ if (s == text *s == '~' tilde_file_exists (text)) {
No need to add the {} here.
*r++ = '\\';
+ }
*r++ = *s;
}
*r = '\0';
diff --git a/general.c b/general.c
index fdadf1d..b279cbe 100644
--- a/general.c
+++ b/general.c
@@ -544,6 +544,28 @@ file_exists (fn)
}
int
+tilde_file_exists (fn)
This function is misnamed for what it does, which is attempt work around
the fact that cygwin's handling of .. is not POSIX-compliant. I think a
better fix would be to change file_exists() itself instead of adding a
misnamed wrapper function; then bashline.c wouldn't even need patching.
The string 'tilde' need not even be in the patch; what you are really
after is a function that says that if '..' is found within a string
being probed for existence, then add an additional check to see if the
prefix of that string exists as a directory.
But I don't mind experimenting with the idea - it remains to be seen
whether people will complain that bash is noticeably slower because it
takes time to double-check instead of rely on cygwin's non-POSIX
shortcut. And the slowdown would only be on paths containing a '..'; I
would NOT be checking for symlinks (even though symlinks containing ..
are also being interpreted in a non-POSIX manner, it is much more
expensive to second-guess if you have to check every name for being a
symlink than it is to just check for literal ..).
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: stat() and tilde prefix (was bad bash tab completion)
Am 07.02.2013 16:30, schrieb Eric Blake: ... ... the fact that cygwin's handling of .. is not POSIX-compliant. I think a better fix would be to change file_exists() itself instead of adding a misnamed wrapper function; then bashline.c wouldn't even need patching. The string 'tilde' need not even be in the patch; what you are really after is a function that says that if '..' is found within a string being probed for existence, then add an additional check to see if the prefix of that string exists as a directory. But I don't mind experimenting with the idea - it remains to be seen whether people will complain that bash is noticeably slower because it takes time to double-check instead of rely on cygwin's non-POSIX shortcut. And the slowdown would only be on paths containing a '..'; I would NOT be checking for symlinks (even though symlinks containing .. are also being interpreted in a non-POSIX manner, it is much more expensive to second-guess if you have to check every name for being a symlink than it is to just check for literal ..). Do I interpret correctly that you talk about bash filename completion here? Referring to http://cygwin.com/ml/cygwin/2013-01/msg00201.html, I'd like to point out that while this .. thing is a cygwin bug, or known downside as Corinna says, the same issue occurs on Linux precisely with filename completion which isn't consistent there either. So it would be over-fixing to handle that specifically in bash. On the other hand, considering again this downside: If the core cygwin filesystem function would follow this approach, simply checking for an occurrence of .. first before resolving the filename, wouldn't that be an acceptable fix without inappropriate penalty? -- Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Cygwin 1.5.x removed from site
Given the age, bugginess, lack of security, and minimal interest in the old Cygwin 1.5.x release, I've removed this legacy release from the Cygwin site. If you still have 1.5 files sitting around that you need to install, grab a copy of setup.exe now because, in the future, new versions of setup.exe will no longer work on older systems or with release-legacy. If someone wants to volunteer to host these files elsewhere, please send email to the Cygwin mailing list with information on where to download. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: stat() and tilde prefix (was bad bash tab completion)
On Feb 7 17:10, Thomas Wolff wrote: Am 07.02.2013 16:30, schrieb Eric Blake: ... ... the fact that cygwin's handling of .. is not POSIX-compliant. I think a better fix would be to change file_exists() itself instead of adding a misnamed wrapper function; then bashline.c wouldn't even need patching. The string 'tilde' need not even be in the patch; what you are really after is a function that says that if '..' is found within a string being probed for existence, then add an additional check to see if the prefix of that string exists as a directory. But I don't mind experimenting with the idea - it remains to be seen whether people will complain that bash is noticeably slower because it takes time to double-check instead of rely on cygwin's non-POSIX shortcut. And the slowdown would only be on paths containing a '..'; I would NOT be checking for symlinks (even though symlinks containing .. are also being interpreted in a non-POSIX manner, it is much more expensive to second-guess if you have to check every name for being a symlink than it is to just check for literal ..). Do I interpret correctly that you talk about bash filename completion here? Referring to http://cygwin.com/ml/cygwin/2013-01/msg00201.html, I'd like to point out that while this .. thing is a cygwin bug, or known downside as Corinna says, the same issue occurs on Linux precisely with filename completion which isn't consistent there either. So it would be over-fixing to handle that specifically in bash. On the other hand, considering again this downside: If the core cygwin filesystem function would follow this approach, simply checking for an occurrence of .. first before resolving the filename, wouldn't that be an acceptable fix without inappropriate penalty? You don't know what you're asking for (can of worms, etc.) This is some kind of chicken egg problem. - The path must be normalized, otherwise we can't reliably convert the POSIX path prefix to a Windows pathname. - Only after converting to a Windows path, we can perform file checks. - Rinse and repeat. Also, the path normalization is performed in an entirely distinct function from the mount point conversion, and this in turn is another function than the path function handling symlinks and devices. Changing that requires to implement the path conversion functionality almost from scratch. Given the age of some of these functions, I'd like to have done that for a long time, but I'm constantly shying away since I don't want to break what is working today. There's, of course, still the aforementioned chicken-egg problem. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: stat() and tilde prefix (was bad bash tab completion)
On Thu, Feb 07, 2013 at 05:23:22PM +0100, Corinna Vinschen wrote: On Feb 7 17:10, Thomas Wolff wrote: Am 07.02.2013 16:30, schrieb Eric Blake: ... ... the fact that cygwin's handling of .. is not POSIX-compliant. I think a better fix would be to change file_exists() itself instead of adding a misnamed wrapper function; then bashline.c wouldn't even need patching. The string 'tilde' need not even be in the patch; what you are really after is a function that says that if '..' is found within a string being probed for existence, then add an additional check to see if the prefix of that string exists as a directory. But I don't mind experimenting with the idea - it remains to be seen whether people will complain that bash is noticeably slower because it takes time to double-check instead of rely on cygwin's non-POSIX shortcut. And the slowdown would only be on paths containing a '..'; I would NOT be checking for symlinks (even though symlinks containing .. are also being interpreted in a non-POSIX manner, it is much more expensive to second-guess if you have to check every name for being a symlink than it is to just check for literal ..). Do I interpret correctly that you talk about bash filename completion here? Referring to http://cygwin.com/ml/cygwin/2013-01/msg00201.html, I'd like to point out that while this .. thing is a cygwin bug, or known downside as Corinna says, the same issue occurs on Linux precisely with filename completion which isn't consistent there either. So it would be over-fixing to handle that specifically in bash. On the other hand, considering again this downside: If the core cygwin filesystem function would follow this approach, simply checking for an occurrence of .. first before resolving the filename, wouldn't that be an acceptable fix without inappropriate penalty? You don't know what you're asking for (can of worms, etc.) This is some kind of chicken egg problem. - The path must be normalized, otherwise we can't reliably convert the POSIX path prefix to a Windows pathname. - Only after converting to a Windows path, we can perform file checks. - Rinse and repeat. Also, the path normalization is performed in an entirely distinct function from the mount point conversion, and this in turn is another function than the path function handling symlinks and devices. Changing that requires to implement the path conversion functionality almost from scratch. Given the age of some of these functions, I'd like to have done that for a long time, but I'm constantly shying away since I don't want to break what is working today. There's, of course, still the aforementioned chicken-egg problem. What she said. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
One unreadable sentence at http://cygwin.com/setup.html
I have uploaded an image demonstrating the problem. It is at http://img825.imageshack.us/img825/3599/setupqa.png . The image is taken from http://cygwin.com/setup.html . The marked line should read: Note: Not all of the above setup.hint lines are required. Please read the description below for further details on how to construct a setup.hint file. I have split the line to make it readable in this post. If you will ask the browser to search for the first line of the text, it will probably find the line for you. Am I the only one that see it? As an aside, I also think the Notes at http://cygwin.com/lists.html , should have their fonts somewhat larger. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: non-blocking accept() can hang.
2013/2/6 Achim Gratz strom...@nexgo.de: It was clear from your post that you were running the release version, thank you. I've compiled your program and it does seem to work correctly, I'm running the latest snapshot. Thank you. I'm grad to hear that. I can wait next release. -- Tanaka Akira -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: non-blocking accept() can hang.
On 2/8/2013 7:37 AM, Tanaka Akira wrote: 2013/2/6 Achim Gratz strom...@nexgo.de: It was clear from your post that you were running the release version, thank you. I've compiled your program and it does seem to work correctly, I'm running the latest snapshot. Thank you. I'm grad to hear that. I can wait next release. you can also test by yourself http://cygwin.com/snapshots/ Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin 1.5.x removed from site
Given the age, bugginess, lack of security, and minimal interest in the old Cygwin 1.5.x release, I've removed this legacy release from the Cygwin site. If you still have 1.5 files sitting around that you need to install, grab a copy of setup.exe now because, in the future, new versions of setup.exe will no longer work on older systems or with release-legacy. If someone wants to volunteer to host these files elsewhere, please send email to the Cygwin mailing list with information on where to download.
