Re: cygport upload command?
On Oct 14 01:12, Andrew Schulman wrote: On 2014-07-07 20:14, Andrew Schulman wrote: Yaakov, would you consider adding an 'upload' command to cygport, that would handle the uploading details? That would take away the last bit of manual work in a routine package update. I'm a bit busy at the moment, but it sounds like a good idea to me. I have an implementation of this ready at https://github.com/andrex-e-schulman/cygport. What's new compared to upstream git: * New upload command (cygport up). Minor nit: This should be `cygport upload' to be in line with the other cygport commands. Alternatively, cygport could introduce a two-letter abbreviation scheme, for instance: cygport download - cygport dl or (rcs-like) co cygport prep - cygport pr cygport build - cygport mk or cc cygport install - cygport in cygport package - cygport pk cygport upload- cygport up or (rcs-like) ci Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgphhE_wYKs9K.pgp Description: PGP signature
Re: cygport upload command?
Minor nit: This should be `cygport upload' to be in line with the other cygport commands. Alternatively, cygport could introduce a two-letter abbreviation scheme, for instance: cygport download- cygport dl or (rcs-like) co cygport prep- cygport pr cygport build - cygport mk or cc cygport install - cygport in cygport package - cygport pk cygport upload - cygport up or (rcs-like) ci I didn't say so, but yes, the command is named and described everywhere as 'cygport upload'. 'cygport up' also works. I didn't think of 'cygport ci', but that's a good idea.
Re: cygwin emacs failing siletnly
On Mon, Oct 13, 2014 at 7:16 PM, Gulliver Smith wrote: Thanks for the pointer to fc-cache. On which machine should this be run? a) the machine hosting the X-Server b) the machine on which emacs is running I don't have a client/server configuration, so I don't know how to answer that, sorry. -- Jim Reisert AD1C, jjreis...@alum.mit.edu, http://www.ad1c.us -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
problems with cygwin/x
On 04/10/2014 18:16, t s wrote: first of all, regarding the Cygwin setup program; the options are install / re-install / un-install / default is it correct that to install only the latest updates, I would choose the option 'default' ? I'm not sure what text you are looking at. The options for an individual package which is already installed are 'reinstall', 'uninstall', 'keep' and specific versions other than the currently installed one (if any). I can't see default anywhere. If you mean the default version, then yes, when curr is selected at the top, all packages which have updates, will be updated. The current version of the setup program, 2.850 (64 bit), on the select packages screen, features a default option. Please see; http://cpm86.com/default.jpg The four options are; Install; Reinstall; Uninstall; Default I just want to be sure; to install only the latest updates, I would choose 'Default' ? next question : if I delete the start menu option Cygwin/x and run the setup program for option default, it doesn't re-create the start menu option Cygwin/x is this 'feature' acknowledged, and is it being addressed? The start menu link for for the X server is owned by the package xinit. If you reinstall that package, it should be recreated. That's the answer I was looking for. Thank you. I have a further question. Choosing menu item Cygwin-X / X Win Server boots X windows. If you right click on the 'X' icon in the lower right side of the screen, it features applications xterm / emacs / notepad / xload. Is it possible to tailor the list of applications referenced above? to include say xclock, xeyes And yet another question; I note the presence of a number of files in \usr\bin which start with 'gnome'. Does Cygwin/x feature gnome or kde as user interfaces? or does it only allow compilation of apps which use features of those interfaces? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: FW: Cygwin start menu / mirrors
On 08/10/2014 23:40, t s wrote: On 04/10/2014 18:16, t s wrote: first of all, regarding the Cygwin setup program; the options are install / re-install / un-install / default is it correct that to install only the latest updates, I would choose the option 'default' ? I'm not sure what text you are looking at. The options for an individual package which is already installed are 'reinstall', 'uninstall', 'keep' and specific versions other than the currently installed one (if any). I can't see default anywhere. If you mean the default version, then yes, when curr is selected at the top, all packages which have updates, will be updated. The current version of the setup program, 2.850 (64 bit), on the select packages screen, features a default option. Please see; http://cpm86.com/default.jpg The four options are; Install; Reinstall; Uninstall; Default I just want to be sure; to install only the latest updates, I would choose 'Default' ? Oh yes, on the category view, you have that option next to each category, which does what you expect. I have a further question. Choosing menu item Cygwin-X / X Win Server boots X windows. If you right click on the 'X' icon in the lower right side of the screen, it features applications xterm / emacs / notepad / xload. Is it possible to tailor the list of applications referenced above? to include say xclock, xeyes Yes. See http://x.cygwin.com/docs/ug/configure-cygwin-xwinrc.html And yet another question; I note the presence of a number of files in \usr\bin which start with 'gnome'. Does Cygwin/x feature gnome or kde as user interfaces? or does it only allow compilation of apps which use features of those interfaces? I don't think KDE or GNOME desktop environments are available. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: problems with cygwin/x
On 14/10/2014 17:19, t s wrote: [duplicate email] Please don't spam the list with the same mail. If you get no answer, it is because no-one has an answer for you (yet). -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: glwDrawingAreaWidgetClass
On 13/10/2014 02:48, Chris Carlson wrote: I have a fairly large program that I developed on Fedora Linux. It uses glwDrawingAreaClassRec to create a GL window. I attempted to compile and run it on Cygwin, and I got the failure. I added a print statement just before calling XtCreateManagedWidget() and discovered the value was 0 on Cygwin and an address on Linux. I presumed that meant there was an issue. To get around the problem, I downloaded the source from Mesa and compiled it myself. The .a that was generated identifies the following (using nm): 0640 D glwDrawingAreaClassRec 0728 D glwDrawingAreaWidgetClass I then compared it to /lib/libGLw.dll.a and got this: nm /lib/libGLw.dll.a | grep DrawingAreaClass I __imp_glwMDrawingAreaClassRec I __nm_glwMDrawingAreaClassRec I __imp_glwDrawingAreaClassRec I __nm_glwDrawingAreaClassRec Unfortunately, this isn't telling you anything useful as the __imp import symbols are fixed up at run-time. Now I tried compiling your test program and found that it did work as you showed, but I then added the include of GLwDrawA.h, and it fails. This doesn't make a whole lot of sense to me, and it doesn't seem right. The issue is that without the extern, the declaration of glwDrawingAreaWidgetClass is also a 'tentative definition' If there are no other references to symbols in libGLw, then that tentative definition (with a value of 0) will be used by ld as the definition. (Linking with a shared library on linux is more relaxed) What do you think? If I want to use the GLwDrawingAreaWidgetClass, I would presume that I should include the corresponding header file and the class would be defined. On 07/10/2014 14:50, Jon TURNEY wrote: but this isn't testing correctly as glwDrawingAreaWidgetClass isn't marked as extern in GLwDrawA.h Sorry, I should have said something like 'it's a bug that glwDrawingAreaWidgetClass isn't marked as extern in GLwDrawA.h' So, something like the following attached patch to GLwDrawA.h is needed. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer --- GLwDrawA.h.bak 2014-10-13 13:00:18.140625400 +0100 +++ GLwDrawA.h 2014-10-13 13:01:06.581762300 +0100 @@ -136,7 +136,7 @@ typedef struct _GLwMDrawingAreaClassRec*GLwMDrawingAreaWidgetClass; typedef struct _GLwMDrawingAreaRec *GLwMDrawingAreaWidget; -GLAPI WidgetClass glwMDrawingAreaWidgetClass; +extern GLAPI WidgetClass glwMDrawingAreaWidgetClass; #else @@ -144,7 +144,7 @@ typedef struct _GLwDrawingAreaClassRec *GLwDrawingAreaWidgetClass; typedef struct _GLwDrawingAreaRec *GLwDrawingAreaWidget; -GLAPI WidgetClass glwDrawingAreaWidgetClass; +extern GLAPI WidgetClass glwDrawingAreaWidgetClass; #endif -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: xorg-server-1.16.1-2
On 10/10/2014 19:32, Nem W Schlecht wrote: Just to confirm - I haven't had any crashes with 1.16.1-2 so far. Woot! :) On Wed, Oct 8, 2014 at 11:08 PM, Chris Carlson wrote: No sooner did I respond than I see the update. Nevermind. On 10/8/2014 8:31 PM, Nem W Schlecht wrote: I just remembered that my version of xv has been modified to place the current image filename in the X11 clipboard. That might have been the cause of the issue. Regardless, my crashes seem to have gone away with this update. Thanks for all the hard work on Cygwin X11! Thanks for letting me know there was a problem, and apologies for the inconvenience. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: FW: Cygwin start menu / mirrors
On 14/10/14 20:35, Jon TURNEY wrote: On 08/10/2014 23:40, t s wrote: And yet another question; I note the presence of a number of files in \usr\bin which start with 'gnome'. Does Cygwin/x feature gnome or kde as user interfaces? or does it only allow compilation of apps which use features of those interfaces? I don't think KDE or GNOME desktop environments are available. I think both are available in CygwinPorts. http://cygwinports.org/ Dave. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog fhandler_socket.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-10-14 19:08:27 Modified files: winsup/cygwin : ChangeLog fhandler_socket.cc Log message: * fhandler_socket.cc (fhandler_socket::connect): Init connect_state to connect_pending only on unconnected socket. Set connect_state to connected on WSAEISCONN error. Set connect_state to connect_failed on any other error except WSAEWOULDBLOCK if connect is still pending. Add lots of comment to explain why all of the above. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6536r2=1.6537 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_socket.cc.diff?cvsroot=srcr1=1.314r2=1.315
src/winsup/cygwin ChangeLog cygheap.cc cygheap ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-10-14 19:14:33 Modified files: winsup/cygwin : ChangeLog cygheap.cc cygheap.h dlfcn.cc Log message: * cygheap.cc (init_cygheap::init_installation_root): Install Cygwin's installation dir as DLL search path, instead of .. * cygheap.h (class cwdstuff): Add parameter names in function declarations for readability. (cwdstuff::get): Ad inline implementation fetching the CWD as wide char string. * dlfcn.cc (dlopen): Add searching for dependent DLLs in DLL installation dir or CWD, if all else failed. Add comment to explain scenarios this is accommodating. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6537r2=1.6538 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygheap.cc.diff?cvsroot=srcr1=1.179r2=1.180 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygheap.h.diff?cvsroot=srcr1=1.172r2=1.173 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dlfcn.cc.diff?cvsroot=srcr1=1.58r2=1.59
src/winsup/cygwin ChangeLog fhandler_socket.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-10-14 19:43:09 Modified files: winsup/cygwin : ChangeLog fhandler_socket.cc Log message: * fhandler_socket.cc (fhandler_socket::connect): Don't change state on WSAEALREADY error. Change comment accordingly. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6538r2=1.6539 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_socket.cc.diff?cvsroot=srcr1=1.315r2=1.316
autorebase.bat failure - /etc/rebase.db.i386 is not a valid rebase database
This is a newly built win7.1 x64 system with Cygwin 32-bit installed. I recently ran the Cygwin installer to get updates and at the end of installation in the log I see: 2014/10/13 23:29:18 running: cmd.exe /c C:\cygwin\etc\postinstall\autorebase.bat gzip: /etc/setup/font-adobe-dpi75.lst.gz: not in gzip format gzip: /etc/setup/font-alias.lst.gz: not in gzip format gzip: /etc/setup/font-encodings.lst.gz: not in gzip format gzip: /etc/setup/font-misc-misc.lst.gz: not in gzip format gzip: /etc/setup/fontconfig.lst.gz: not in gzip format rebase: /etc/rebase.db.i386 is not a valid rebase database. 2014/10/13 23:29:19 abnormal exit: exit code=2 Is this a bug? Do I need to do something to correct the problem? cygcheck output attached Also, the file /etc/rebase.db.i386 consists of about 26kb of binary zeroes: jim@home ~ $ hexdump /etc/rebase.db.i386 000 * 00064d0 00064df -- Jim Garrison (j...@acm.org) PGP Keys at http://www.jhmg.net RSA 0x04B73B7F DH 0x70738D88 Cygwin Configuration Diagnostics Current System Time: Tue Oct 14 07:44:16 2014 Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1 Running under WOW64 on AMD64 Path: C:\cygwin\usr\sbin C:\cygwin\usr\local\bin C:\cygwin\bin C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common C:\Program Files (x86)\Intel\iCLS Client C:\Program Files\Intel\iCLS Client C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Program Files\Intel\Intel(R) Management Engine Components\DAL C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL C:\Program Files\Intel\Intel(R) Management Engine Components\IPT C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT C:\Program Files (x86)\GNU\GnuPG\pub C:\Program Files (x86)\QuickTime\QTSystem C:\Program Files (x86)\Common Files\Roxio Shared\10.0\DLLShared C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared C:\Program Files (x86)\Common Files\Roxio Shared\10.0\DLLShared C:\Program Files\Microsoft Windows Performance Toolkit Output from C:\cygwin\bin\id.exe UID: 1000(jim) GID: 513(None) 513(None) 545(Users) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'jim' PWD = '/home/jim' HOME = '/home/jim' HOMEPATH = '\Users\jim' APPDATA = 'C:\Users\jim\AppData\Roaming' SSH_AGENT_PID = '40092' ProgramW6432 = 'C:\Program Files' HOSTNAME = 'home' SHELL = '/bin/bash' TERM = 'xterm' RoxioCentral = 'C:\Program Files (x86)\Common Files\Roxio Shared\10.0\Roxio Central36\' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 60 Stepping 3, GenuineIntel' PROFILEREAD = 'true' WINDIR = 'C:\Windows' EMC_AUTOPLAY = 'C:\Program Files (x86)\Common Files\Roxio Shared\' PUBLIC = 'C:\Users\Public' OLDPWD = '/usr/bin' ORIGINAL_PATH = '/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/c/Program Files (x86)/Intel/iCLS Client:/c/Program Files/Intel/iCLS Client:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0:/c/Program Files/Intel/Intel(R) Management Engine Components/DAL:/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/DAL:/c/Program Files/Intel/Intel(R) Management Engine Components/IPT:/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/IPT:/c/Program Files (x86)/GNU/GnuPG/pub:/c/Program Files (x86)/QuickTime/QTSystem:/c/Program Files (x86)/Common Files/Roxio Shared/10.0/DLLShared:/c/Program Files (x86)/Common Files/Roxio Shared/DLLShared:/c/Program Files (x86)/Common Files/Roxio Shared/DLLShared:/c/Program Files (x86)/Common Files/Roxio Shared/10.0/DLLShared:/c/Program Files/Microsoft Windows Performance Toolkit' USERDOMAIN = 'home' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' windows_tracing_flags = '3' windows_tracing_logfile = 'C:\BVTBin\Tests\installpackage\csilogfile.log' !:: = '::\' TEMP = '/tmp' COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files' SSH_AUTH_SOCK = '/tmp/ssh-JakLBt0FhHH3/agent.42672' USERNAME = 'jim' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' LIBGL_ALWAYS_INDIRECT = '1' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' PROCESSOR_ARCHITEW6432 = 'AMD64' LANG = 'en_US' USERPROFILE = 'C:\Users\jim' TZ = 'America/Los_Angeles' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\HOME' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\jim\AppData\Local' ProgramData = 'C:\ProgramData' EXECIGNORE = '*.dll' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE
Re: autorebase.bat failure - /etc/rebase.db.i386 is not a valid rebase database
Jim Garrison jhg at jhmg.net writes: This is a newly built win7.1 x64 system with Cygwin 32-bit installed. I recently ran the Cygwin installer to get updates and at the end of installation in the log I see: 2014/10/13 23:29:18 running: cmd.exe /c C:\cygwin\etc\postinstall\autorebase.bat gzip: /etc/setup/font-adobe-dpi75.lst.gz: not in gzip format gzip: /etc/setup/font-alias.lst.gz: not in gzip format gzip: /etc/setup/font-encodings.lst.gz: not in gzip format gzip: /etc/setup/font-misc-misc.lst.gz: not in gzip format gzip: /etc/setup/fontconfig.lst.gz: not in gzip format These files seem to be corrupt for whatever reason. Remove them and re-install those packages manually. rebase: /etc/rebase.db.i386 is not a valid rebase database. Remove it. Regards, Achim. -- 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: [ANNOUNCEMENT] Updated (experimental): coreutils-8.23-3
Eric Blake eblake at redhat.com writes: D'oh - now I see it. In my .exe code additions, I had added a '!= 0' test that should have really been a ' 0' test; because directories cause an expected -1 return that should not have triggered an attempt at .exe magic. -4 coming soon. Fix confirmed. Regards, Achim.requires -- 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: Crash in g_file_monitor on 32-bit Cygwin
On 6/28/2014 7:08 AM, Ken Brown wrote:
On 6/27/2014 1:52 PM, Yaakov Selkowitz wrote:
On 2014-06-27 12:11, Ken Brown wrote:
On 6/25/2014 10:17 PM, Ken Brown wrote:
This is a followup to
https://cygwin.com/ml/cygwin/2014-06/msg00324.html, from which I
extracted the following test case:
$ cat gfile-test.c
#include stdio.h
#include gio/gio.h
void
gfile_add_watch (const char *file)
{
GFile *gfile = g_file_new_for_path (file);
GFileMonitor *monitor;
GFileMonitorFlags gflags = G_FILE_MONITOR_NONE;
monitor = g_file_monitor (gfile, gflags, NULL, NULL);
if (! monitor)
printf (Can't watch file %s\n, file);
else
printf (Watching file %s\n, file);
}
int
main ()
{
const char *file = gfile-test.c;
gfile_add_watch (file);
}
$ gcc -g -O0 -o gfile-test $(pkg-config --cflags gio-2.0) gfile-test.c
$(pkg-config --libs gio-2.0)
In the 64-bit case, this behaves as expected:
$ ./gfile-test.exe
Watching file gfile-test.c
In the 32-bit case, however, it crashes. Running it under gdb shows
that the call to g_file_monitor leads to a SEGV, but I can't tell
exactly where; when I try to single step through the Glib code, I
eventually hit an assertion violation in gdb. strace shows lots of
exceptions, but I can't make much sense out of it otherwise.
I rebuilt glib and gamin without optimization so that I could step
through the code in gdb. But stepping through the code turned out to be
unnecessary, because the bug was gone after the rebuilds. I don't know
if optimization was really the issue or whether just rebuilding with the
latest tools is what fixed it.
My builds can be obtained from
http://sanibeltranquility.com/cygwin/
if anyone else wants to try to reproduce this without rebuilding the
packages themselves.
Yaakov, could you take a look?
Sure. Are you narrow this down to only one of glib or gamin?
The culprit is gamin, and optimization *is* relevant. What's strange, though,
is that when I rebuild it with optimization, my test case hangs instead of
crashing. Summary:
- With gamin-0.1.10-14 (and its subpackages), my test case crashes. The outward
symptom is that there's no output, but running the test case under gdb shows the
SEGV.
- If I rebuild gamin without optimization, I don't see any bug. More precisely,
I build it using your gamin.cygport with the following line added:
CFLAGS+= -O0 -g3
- If I rebuild gamin with optimization (i.e., just using your gamin.cygport with
no changes), my test case hangs.
I made another attempt to debug this, and I found the problem, but I don't know
how to fix it. First, I have to correct the last assertion I made above about
my test case hanging; I just didn't wait long enough for it to finish. What
happens is that there is a retry loop in
libgamin/gam_api.c:gamin_connect_unix_socket that gives up after 25 seconds.
And the reason it fails is that /usr/libexec/gam_server.exe has crashed. In
fact, the latter always crashes on 32-bit Cygwin if it's built with optimization
and if the directory /tmp/fam-username exists before it is run. [And this
directory will always exist after one run of gam_server.exe.]
The crash occurs in a call to g_free at server/gam_channel.c:525 because the
pointer 'dir' that is being freed has been clobbered by a call to
gam_check_not_fat on line 497. Here are some details, based on a build using
Yaakov's gamin.cygport file with the added line
CFLAGS+= -O1 -g3
I've appended at the end of this message a transcript of a gdb session that
illustrates some of the assertions I'll be making.
At line 447 of server/gam_channel.c, g_strconcat is called to get a pointer to
the directory name /tmp/fam-username. The value of this pointer is assigned
to the variable 'dir' at line 473, and in my run it is 0x8005c068. Although
'dir' is optimized out, I can see from a disassembly that the pointer is stored
on the stack at -0x510(%ebp):
0x004058fc +266: call 0x408bf8 g_strconcat
0x00405901 +271: mov%eax,-0x510(%ebp)
And I verified in my gdb session that this stack location does indeed contain
0x8005c068. After the call to gam_check_not_fat a little later, that stack
location contains the value 0x0104. Then when g_free attempts to free the
bogus pointer 0x0104, we get a crash.
I can't tell from the disassembly why the call to gam_check_not_fat clobbers the
stack. My best guess is that it happens as a result of calls to some Windows
functions. I hope someone more knowledgeable can take this further and fix it.
By the way, the problem doesn't occur in the 64-bit case because the pointer
'dir' is saved in a register rather than on the stack, and apparently (by luck?)
this register is not clobbered by gam_check_not_fat.
Ken
P.S. I think I found a typo in gam_check_not_fat, unrelated to the present
problem. Based on the context and the indentation, I think a couple of lines
need to be enclosed in braces:
--- gam_channel.c.orig 2014-10-14
lwp-request stopped working with snapshots
I've ran into some strange problem with the snapshots. This seems to be getting complicated, so I'm throwing it out here in the hope someone has an idea. I've boiled it down to a minimal Cygwin (32bit, but it's happening in 64bit too) installation, plus perl and perl_vendor. As installed $ lwp-request http://server.local/ spits out the index page as it should. Installing a snapshot, both the earliest I still had locally available, which was 2014-08-19 and the latest from 2014-10-11 produces the error: Transport endpoint not connected From the actual application that led me onto this hunt I know that the request gets sent and the response is at least sometimes partially read before the connection is destroyed. The server seems to think the client has closed the connection and the client thinks the same of the server apparently. This only happens when there is data sent from the server, if I make the client wait for data it will dutifully sit there until I send some and then things break down. Now, I've been running exclusively on snapshots for quite some time and this was working until about two weeks ago. Looking at the updates during that time I don't see anything obvious that would interfere with LWP; I thought coreutils might and will still try to test this. But I don't really see how I'd need the combination of the snapshot installation and one of the recently updated packages to cause this kind of breakage, so if anyone has any ideas, please tell. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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: Crash in g_file_monitor on 32-bit Cygwin
On 10/14/2014 12:26 PM, Ken Brown wrote:
On 6/28/2014 7:08 AM, Ken Brown wrote:
On 6/27/2014 1:52 PM, Yaakov Selkowitz wrote:
On 2014-06-27 12:11, Ken Brown wrote:
On 6/25/2014 10:17 PM, Ken Brown wrote:
This is a followup to
https://cygwin.com/ml/cygwin/2014-06/msg00324.html, from which I
extracted the following test case:
$ cat gfile-test.c
#include stdio.h
#include gio/gio.h
void
gfile_add_watch (const char *file)
{
GFile *gfile = g_file_new_for_path (file);
GFileMonitor *monitor;
GFileMonitorFlags gflags = G_FILE_MONITOR_NONE;
monitor = g_file_monitor (gfile, gflags, NULL, NULL);
if (! monitor)
printf (Can't watch file %s\n, file);
else
printf (Watching file %s\n, file);
}
int
main ()
{
const char *file = gfile-test.c;
gfile_add_watch (file);
}
$ gcc -g -O0 -o gfile-test $(pkg-config --cflags gio-2.0) gfile-test.c
$(pkg-config --libs gio-2.0)
In the 64-bit case, this behaves as expected:
$ ./gfile-test.exe
Watching file gfile-test.c
In the 32-bit case, however, it crashes. Running it under gdb shows
that the call to g_file_monitor leads to a SEGV, but I can't tell
exactly where; when I try to single step through the Glib code, I
eventually hit an assertion violation in gdb. strace shows lots of
exceptions, but I can't make much sense out of it otherwise.
I rebuilt glib and gamin without optimization so that I could step
through the code in gdb. But stepping through the code turned out to be
unnecessary, because the bug was gone after the rebuilds. I don't know
if optimization was really the issue or whether just rebuilding with the
latest tools is what fixed it.
My builds can be obtained from
http://sanibeltranquility.com/cygwin/
if anyone else wants to try to reproduce this without rebuilding the
packages themselves.
Yaakov, could you take a look?
Sure. Are you narrow this down to only one of glib or gamin?
The culprit is gamin, and optimization *is* relevant. What's strange, though,
is that when I rebuild it with optimization, my test case hangs instead of
crashing. Summary:
- With gamin-0.1.10-14 (and its subpackages), my test case crashes. The outward
symptom is that there's no output, but running the test case under gdb shows the
SEGV.
- If I rebuild gamin without optimization, I don't see any bug. More precisely,
I build it using your gamin.cygport with the following line added:
CFLAGS+= -O0 -g3
- If I rebuild gamin with optimization (i.e., just using your gamin.cygport with
no changes), my test case hangs.
I made another attempt to debug this, and I found the problem, but I don't know
how to fix it. First, I have to correct the last assertion I made above about
my test case hanging; I just didn't wait long enough for it to finish. What
happens is that there is a retry loop in
libgamin/gam_api.c:gamin_connect_unix_socket that gives up after 25 seconds. And
the reason it fails is that /usr/libexec/gam_server.exe has crashed. In fact,
the latter always crashes on 32-bit Cygwin if it's built with optimization and
if the directory /tmp/fam-username exists before it is run. [And this
directory will always exist after one run of gam_server.exe.]
The crash occurs in a call to g_free at server/gam_channel.c:525 because the
pointer 'dir' that is being freed has been clobbered by a call to
gam_check_not_fat on line 497. Here are some details, based on a build using
Yaakov's gamin.cygport file with the added line
CFLAGS+= -O1 -g3
I've appended at the end of this message a transcript of a gdb session that
illustrates some of the assertions I'll be making.
At line 447 of server/gam_channel.c, g_strconcat is called to get a pointer to
the directory name /tmp/fam-username. The value of this pointer is assigned
to the variable 'dir' at line 473, and in my run it is 0x8005c068. Although
'dir' is optimized out, I can see from a disassembly that the pointer is stored
on the stack at -0x510(%ebp):
0x004058fc +266:call 0x408bf8 g_strconcat
0x00405901 +271:mov%eax,-0x510(%ebp)
And I verified in my gdb session that this stack location does indeed contain
0x8005c068. After the call to gam_check_not_fat a little later, that stack
location contains the value 0x0104. Then when g_free attempts to free the
bogus pointer 0x0104, we get a crash.
I can't tell from the disassembly why the call to gam_check_not_fat clobbers the
stack. My best guess is that it happens as a result of calls to some Windows
functions. I hope someone more knowledgeable can take this further and fix it.
I stepped into gam_check_not_fat (which I should have done to begin with) and
narrowed this down further. The stack location in question gets clobbered by
the call to GetVolumeInformation:
(gdb) s
gam_check_not_fat (path=0x8005c068 /tmp/fam-kbrown)
at /usr/src/debug/gamin-0.1.10-16/server/gam_channel.c:35
35cygwin_conv_path(CCP_POSIX_TO_WIN_A, path, winpath, MAX_PATH);
(gdb) x/x $ebp-0x510
0x28a6a8:
Re: Crash in g_file_monitor on 32-bit Cygwin
Hi Ken, I know the code is not yours, but I have to vent while I see this code :) On Oct 14 14:30, Ken Brown wrote: I stepped into gam_check_not_fat (which I should have done to begin with) and narrowed this down further. The stack location in question gets clobbered by the call to GetVolumeInformation: (gdb) s gam_check_not_fat (path=0x8005c068 /tmp/fam-kbrown) at /usr/src/debug/gamin-0.1.10-16/server/gam_channel.c:35 35cygwin_conv_path(CCP_POSIX_TO_WIN_A, path, winpath, MAX_PATH); Ouch. What about paths longer than MAX_PATH? (gdb) x/x $ebp-0x510 0x28a6a8: 0x8005c068 (gdb) n 37pGVPN = GetProcAddress(LoadLibrary(kernel32), GetVolumePathNameA); There's no reason to load GetVolumePathName from kernel32 since all supported platforms provide this entry point. (gdb) x/x $ebp-0x510 0x28a6a8: 0x8005c068 (gdb) n 38if (!pGVPN || !(pGVPN)(winpath, root, MAX_PATH)) (gdb) x/x $ebp-0x510 0x28a6a8: 0x8005c068 (gdb) n 52if (!GetVolumeInformation (root, volname, MAX_PATH, NULL, (gdb) x/x $ebp-0x510 0x28a6a8: 0x8005c068 (gdb) n 58if (!strncmp(fsname, FAT, 3)) /* FAT, FAT32 */ How old is this code? What *exactly* is this function trying to check? I assume it's checking for certain filesystem capabilities, but then, there's no good reason to check for a filesystem being FAT or FAT32. Any other filesystem might have the same or similar capabilities and be called FOOBAR. Whatever the code is doing, it should probably simply call statvfs() and check the f_flag member of the returned struct statvfs for a certain flag. The flags returned in f_flag are the same as the fs flags returned by GetVolumeInformation. So, what is it the code is trying to test by checking the FS name? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgprTWYMqH9pn.pgp Description: PGP signature
Re: Cannot exec() program outside of /bin if PATH is unset
On Oct 10 17:39, Corinna Vinschen wrote: On Oct 10 14:13, Arjen Markus wrote: 2014-10-10 13:22 GMT+02:00 tednolan: 2014-10-10 13:24 GMT+02:00 Jan Nijtmans ...: 2014-10-10 12:34 GMT+02:00 Corinna Vinschen ...: On Oct 9 11:46, tednolan.net wrote: I'm pretty sure I've got some programs loading Tcl extensions that cd into the directory with the extension dlls, load the extension and then change back to where ever they were. Hmm. If so, it's quite a weird way to handle this, rather than loading the modules with full path. Is that a Tcl feature, or is it how certain Tcl apps are implemented? I can't really believe the former... This is certainly not a Tcl feature! The standard Tcl extension mechanism always uses the full path simply because Tcl cannot depend on platform-specific ways to search for such libraries elsewhere. I'm willing to test this;I don't believe such a change will break anything in my Tcl environment. Regards, Jan Nijtmans Hmm, It's been a while, but I think it is something like the extension is a DLL, but it depends on another DLL. Consider for instance, mysqltcl. If you want to deploy that, you need the mysqltcl.dll and the mysql dll, so you either have to be in the same dir when you load the extension, or put that dir in PATH. Unfortunately, I can't run a test release on my work machine, or take my work progs home. Right, that makes sense. There is indeed no way for the package manager to handle that scenario without external help, such as a PATH variable that includes the various directories these extra DLLs reside in. There might be a potential workaround. Given that Cygwin Tcl calls dlopen to load DLLs, we have this somewhat under control. The default DLL search algorithm searches the application dir for dependent DLLs. But there's a LoadLibraryEx flag called LOAD_WITH_ALTERED_SEARCH_PATH. When using this flag, and the DLL is given with full path, the application dir in the DLL search path is replaced by the directory of the DLL. Thus, dependent DLLs will be searched in the same dir the original DLL has been loaded from. This could be utilized in dlopen. If the DLL is given with no path, and if LoadLibrary failes, create the full path to the DLL and call LoadLibraryEx (full_path, LOAD_WITH_ALTERED_SEARCH_PATH). DLLs in /bin are taken care of by the SetDllDirectory call we're talking about here. I implemented this in the latest snapshot. It calls SetDllDirectory on Cygwin's /bin, and dlopen addiotnally tries to load the DLL with LoadLibraryEx(LOAD_WITH_ALTERED_SEARCH_PATH) if all else failed. Please give the latest snapshot from https://cygwin.com/snapshots/ a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp2M5GRUkdW0.pgp Description: PGP signature
Re: lwp-request stopped working with snapshots
On Oct 14 20:21, Achim Gratz wrote: I've ran into some strange problem with the snapshots. [...] $ lwp-request http://server.local/ spits out the index page as it should. Installing a snapshot, both the earliest I still had locally available, which was 2014-08-19 and the latest from 2014-10-11 produces the error: Transport endpoint not connected lwp-request is one of the tools using connect to try if a former non-blocking connect worked. This is ugly but, sigh, valid behaviour, The latest changes to the socket code didn't take this scenario into account. I applied a fix and uploaded a new snashot to https://cygwin.com/snapshots/ Please give it a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpF8yS4DZ16x.pgp Description: PGP signature
Re: lwp-request stopped working with snapshots
Corinna Vinschen writes: lwp-request is one of the tools using connect to try if a former non-blocking connect worked. This is ugly but, sigh, valid behaviour, What should it be doing instead? LWP upstream has switched to a new maintainer recently IIRC, so it might be a good time to suggest a few cleanups. The latest changes to the socket code didn't take this scenario into account. I applied a fix and uploaded a new snashot to https://cygwin.com/snapshots/ Please give it a try. I sure will do this first thing tomorrow, thanks! Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: [ANNOUNCEMENT] Updated: run-1.3.2 (test version: run-1.3.3)
Jon TURNEY writes: Any chance this can be promoted to current? It seems that --quote is necessary for commands of the form 'run /usr/bin/bash -l -c command args' to work, which are used quite a lot in X start menu items (e.g. see [1]). I would appreciate if you could let me know if that release solves your problem. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: lwp-request stopped working with snapshots
On Oct 14 21:41, Achim Gratz wrote: Corinna Vinschen writes: lwp-request is one of the tools using connect to try if a former non-blocking connect worked. This is ugly but, sigh, valid behaviour, What should it be doing instead? LWP upstream has switched to a new maintainer recently IIRC, so it might be a good time to suggest a few cleanups. Calling select or poll instead. But, anyway, uglyness is in the eye of the beholder and ultimately it *is* a valid approach and it worked before. So it was clearly a newly introduced bug in Cygwin. The latest changes to the socket code didn't take this scenario into account. I applied a fix and uploaded a new snashot to https://cygwin.com/snapshots/ Please give it a try. I sure will do this first thing tomorrow, thanks! Oh, good! I just realized that I missed to handle EALREADY, so I applied YA patch and just replaced the snapshot with a new one. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpi_gTQcCPq6.pgp Description: PGP signature
Re: cygwin bash script suddenly can't find ls, grep
Achim Gratz wrote:
LMH writes:
Good Lord, I guess I wasn't thinking very clearly trying to use PATH as
a variable for something else. I changed to,
FILE_DIR=$(ls -d './'$SET'/'$FOLD'/'$FOLD'_anneal/'$PARAM_SET'/'$AN_SET)
echo $FILE_DIR
FILE_LIST=($(ls $FILE_DIR'/'*'out.txt' ))
echo ${FILE_LIST[@]}
and everything is fine. I guess it was a bash issue after all. Thanks
for checking that out.
Are you trying to re-write some Windows BAT/CMD script perhaps? It
seems that you'd actually want to use find instead of ls and protect
yourself a bit against the possibility of one of these path or file
names containing whitespace. The ls constructing FILE_LIST is probably
not needed because the shell already globs the file names before ls ever
gets to it.
Regards,
Achim.
Thanks for the advice. I went to using something like,
FILE_LIST=($(ls
'./'$SET'/'$FOLD'/'$FOLD'_anneal/'$PARAM_SET'/'$AN_SET'/'*'out.txt' ))
instead of,
FILE_LIST='./'$SET'/'$FOLD'/'$FOLD'_anneal/'$PARAM_SET'/'$AN_SET'/'*'out.txt'
when I was creating a script because ls will throw an exception if there
is nothing found matching the glob. This is especially true when I am
using a long path with allot of variables. I often remove the ls once I
know the script is working. The the first syntax above also creates an
array.
FILE_DIR was assigned separately because it it used in some other places
in the script and convenient to have in scope.
I have also had problems evaluating strings that were created by
assigning with a glob.
If I had a file,
myfile_1.txt
and did,
file_name='myfile_'*'.txt'
and then,
if [ $file_name = myfile_1.txt ];
I have had issues getting the above conditional to evaluate as true.
If instead I do,
file_name=$(ls 'myfile_'*'.txt')
the conditional will evaluate properly.
Am I mistaken about this? I have not taken the time to run down all of
these issues when they occur, which I really should.
LMH
--
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: cygwin bash script suddenly can't find ls, grep
Thorsten Kampe wrote:
* LMH (Sat, 11 Oct 2014 20:30:07 -0400)
Good Lord, I guess I wasn't thinking very clearly trying to use
PATH as
a variable for something else. I changed to,
FILE_DIR=$(ls -d './'$SET'/'$FOLD'/'$FOLD'_anneal/'$PARAM_SET'/'$AN_SET)
echo $FILE_DIR
FILE_LIST=($(ls $FILE_DIR'/'*'out.txt' ))
echo ${FILE_LIST[@]}
That looks pretty ugly. You probably can replace all that with
FILE_LIST=(./$SET/$FOLD/$FOLD_anneal/$PARAM_SET/$AN_SET/*out.txt)
Thorsten
--
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
Thank you for the suggestion. I have mad an additional post in response
to the previous message that addresses your suggestion as well.
LMH
--
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: Crash in g_file_monitor on 32-bit Cygwin
On 2014-10-14 14:28, Corinna Vinschen wrote: I know the code is not yours, but I have to vent while I see this code :) Actually, this isn't the first time you're seeing this code, it's just been a while. :-) There's no reason to load GetVolumePathName from kernel32 since all supported platforms provide this entry point. They didn't when this code was written. How old is this code? 2006. What *exactly* is this function trying to check? gamin enforces permissions on its sockets, which will fail on FAT partitions for obvious reasons, so we need to bypass those checks in that case. Obviously this code is overdue for an update, which I'll try to do later today. Yaakov -- 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] Updated: gzip-1.6-1
A new release of gzip, 1.6-1, has been uploaded and will soon reach a mirror near you; leaving the previous version at 1.4-1. NEWS: = This represents a new upstream release, and the first build of gzip by a new maintainer. This release also drops the 'uncompress' symlink now that the 'ncompress' package is available without patent restrictions. If you have already installed 'ncompress', you will need to reinstall it after upgrading 'gzip' in order to avoid a missing file. This build also adds a debuginfo package. For more details on the upstream changes, see the documentation in /usr/share/doc/gzip/. DESCRIPTION: GNU Gzip is a popular data compression program originally written by Jean-loup Gailly for the GNU project. Mark Adler wrote the decompression part. It was developed as a replacement for compress because of Unisys and IBM patents covering the LZW algorithm at the time. The superior compression ratio of gzip is just a bonus. UPDATE: === To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'gzip' in the 'Base' category (it should already be selected). DOWNLOAD: = Note that downloads from cygwin.com aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Eric Blake volunteer cygwin gzip package maintainer For more details on this list (including unsubscription), see: http://sourceware.org/lists.html signature.asc Description: OpenPGP digital signature
perl -d causes completion to fail
I'm a big fan of Perl and using Perl's debugger (i.e. perl -d script), however I noticed that Bash completion works if I say perl scr... then tab but fails if I say perl -d scr... The script doesn't complete! (and no I don't mean the actual characters script rather the script filename). Now I did some Bash completion stuff before so I'm familiar but where would I find which completion thing causes this to work but only if -d was not specified? Specify some other Perl option (i.e. -v) and it WORKS! To recap: perl -d mysctab does NOT complete to perl -d myscript.pl but perl -v mysctab does! That's just odd! -- Andrew DeFaria http://defaria.com -- 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: Very slow to launch cygwin applications
Greetings, David Arnstein! Most applications, including bash.exe and ssh.exe are slow to launch. Problem started approximately two weeks ago. I update cygwin frequently, but I am not confident that a cygwin change caused this behavior. I have attached the output from cygcheck -s -v -r cygcheck.out. Any suggestions for debugging this further? This could be caused by extra stupid AV software. Also, can you try snapshot DLL and see, if that change anything? -- WBR, Andrey Repin (anrdae...@yandex.ru) 15.10.2014, 5:37 Sorry for my terrible english... -- 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: Very slow to launch cygwin applications
On 10/14/2014 07:16 PM, David Arnstein wrote: Most applications, including bash.exe and ssh.exe are slow to launch. Problem started approximately two weeks ago. I update cygwin frequently, but I am not confident that a cygwin change caused this behavior. I have attached the output from cygcheck -s -v -r cygcheck.out. Any suggestions for debugging this further? I notice that you have UNC paths in PATH. That can really slow things down if they are accessed regularly. Try pulling those paths out and see if it makes a difference. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: FW: [BUG] SCons 2.3.0 sometimes cannot find files
Hello! I saw the email, but haven't had time to look into it. Your reduced test case didn't make it, either. How ? The idea is to save it under 'test.py' name and run as 'python test.py'. You should get FAIL with the original version and PASS if you apply the fix. So, if you think you know the solution and can provide a patch, I can roll a fixed package pretty quickly. Ok. The patch is attached. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia always-use-normcase.patch Description: Binary data -- 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: lwp-request stopped working with snapshots
Corinna Vinschen corinna-cygwin at cygwin.com writes: Oh, good! I just realized that I missed to handle EALREADY, so I applied YA patch and just replaced the snapshot with a new one. The snapshot fixes things in the minial test installation. I'll update my other systems later today. Regards, Achim. -- 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
Updated: gzip-1.6-1
A new release of gzip, 1.6-1, has been uploaded and will soon reach a mirror near you; leaving the previous version at 1.4-1. NEWS: = This represents a new upstream release, and the first build of gzip by a new maintainer. This release also drops the 'uncompress' symlink now that the 'ncompress' package is available without patent restrictions. If you have already installed 'ncompress', you will need to reinstall it after upgrading 'gzip' in order to avoid a missing file. This build also adds a debuginfo package. For more details on the upstream changes, see the documentation in /usr/share/doc/gzip/. DESCRIPTION: GNU Gzip is a popular data compression program originally written by Jean-loup Gailly for the GNU project. Mark Adler wrote the decompression part. It was developed as a replacement for compress because of Unisys and IBM patents covering the LZW algorithm at the time. The superior compression ratio of gzip is just a bonus. UPDATE: === To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'gzip' in the 'Base' category (it should already be selected). DOWNLOAD: = Note that downloads from cygwin.com aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Eric Blake volunteer cygwin gzip package maintainer For more details on this list (including unsubscription), see: http://sourceware.org/lists.html signature.asc Description: OpenPGP digital signature
