* [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
@ 2011-12-06 10:00 Corinna Vinschen
2011-12-06 12:07 ` Ken Brown
` (9 more replies)
0 siblings, 10 replies; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-06 10:00 UTC (permalink / raw)
To: cygwin
A lot of changes and fixes have been made in Cygwin since 1.7.9 has
been released, so we're looking forward to release Cygwin 1.7.10 soon.
Please test the latest developer snapshots at http://cygwin.com/snapshots/
which should have "Release Candidate" quality.
A very noticable change is that for this release we dropped support for
Windows NT4 entirely. Cygwin 1.7.10 won't start on NT4 machines anymore.
Nor will Cygwin and the Cygwin utilities know about NT4 domains. Domain
support requires at least a Windows 2000 Active Directory domain now.
In 1.7.10 a few internals have changed, which influence the way some of
the Cygwin tools work. For instance, the Cygwin ps tool from 1.7.9 will
show weird tty numbers for processes running in a console window, while
the new ps knows how to handle the new values.
So, ideally for testing you don't just exchange the Cygwin DLL, but also
the tools and, if you want to test some of the new API, the include
files and link libs.
Please report bugs to the cygwin at cygwin dot com mailing list.
Please follow the guidelines at http://cygwin.com/problems.html
Be aware that we're mainly focusing on regressions from 1.7.9.
What's new:
-----------
- New getconf tool for querying confstr(3), pathconf(3), sysconf(3), and
limits.h configuration.
- The passwd tool now allows an administrator to use the -R command for
other user accounts: passwd -R username.
- Experimental: Change the way sockets are created so that Cygwin always
circumvents so-called "layered service providers" (LSPs) starting with
Windows Vista.
- signal handler functions are now dispatched in threads other than the
main thread.
- Support NcFsd filesystem.
- clock_gettime(3) and clock_getres(3) accept per-process and per-thread
CPU-time clocks, including CLOCK_PROCESS_CPUTIME_ID and
CLOCK_THREAD_CPUTIME_ID.
- New pthread functions:
- Spin Locks: pthread_spin_destroy, pthread_spin_init, pthread_spin_lock,
pthread_spin_trylock, pthread_spin_unlock.
- Stack management: pthread_attr_getstack, pthread_attr_getstackaddr,
pthread_attr_getguardsize, pthread_attr_setstack, pthread_attr_setstackaddr,
pthread_attr_setguardsize, pthread_getattr_np.
- Clock Selection: pthread_getcpuclockid, pthread_condattr_getclock,
pthread_condattr_setclock.
- Scheduling: pthread_setschedprio.
- Add /proc/devices, /proc/misc, /proc/sysvipc, /proc/swaps.
- Make various system functions thread cancelation points per POSIX.
- Add ioctl FIONREAD handling for non-sockets.
- dlopen now supports the Glibc-specific RTLD_NODELETE and RTLD_NOOPEN flags.
- Execed processes now inherit the children of their predecessor.
- Fifos have been rewritten and should now be more reliable.
- GNU/glibc error.h error reporting functions: error, error_at_line,
error_message_count, error_one_per_line, error_print_progname.
- Other new API: clock_getcpuclockid, clock_nanosleep, clock_settime, __fpurge,
getgrouplist, ppoll, psiginfo, psignal, ptsname_r, sys_siglist, sysinfo.
- cygwin_conv_path_list finally supports CCP_WIN_W_TO_POSIX and
CCP_POSIX_TO_WIN_W conversions.
What changed:
-------------
- Drop support for Windows NT4.
- The CYGWIN environment variable options "envcache", "strip_title", "title",
"tty", and "upcaseenv" have been removed.
- Revamp console and pseudo tty handling. Rename /dev/ttyX to /dev/consX,
/dev/ttyX to /dev/ptyX.
- The CYGWIN=tty mode using pipes to communicate with the console in a pseudo
tty-like mode has been removed. Either just use the normal Windows console
as is, or use a terminal application like mintty.
- Improve fork/exec performance on 64 bit systems.
- Improve Ctrl-C handling in console.
- Try harder to let fork not fail if DLLs are moved in memory which should,
in some cases, minimize the need for rebaseall.
- New heap management. Drop registry setting "heap_chunk_in_mb" in favor of
a new per-executable setting in the executable file header which can be set
using the peflags tool. Drop registry setting "heap_slop_in_mb" entirely.
- dlopen can now find "cygFOO.dll", even if the caller specified "libFOO.so".
This is supposed to support applications which are no aware of Windows DLLs.
- Make accept(2), poll(2) and shutdown(2) behave more like on Linux.
- Raise max number of mount points from 30 to 64.
- Output of /proc/maps is closer to what Linux prints and much more useful to
examine process VM layout.
- /proc/loadavg now shows the number of currently running processes and the
total number of processes.
- /proc/version now shows the username of whomever compiled the Cygwin DLL
as well as the version of GCC used when compiling.
- cygwin_conv_path and cygwin_conv_path_list: In CCP_WIN_A_TO_POSIX and
CCP_POSIX_TO_WIN_A conversions, use the current Windows ANSI or OEM
charset, depending on the return value of AreFileApisANSI. Up to Cygwin
1.7.9, both conversions used the current Cygwin charset for the conversion.
- Various assorted bugfixes and improvements.
- Preliminary, no guarantee, may be broken in subtil ways, Windows 8 support.
Corinna
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:
cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com
If you need more information on unsubscribing, start reading here:
http://sourceware.org/lists.html#unsubscribe-simple
Please read *all* of the information on unsubscribing that is available
starting at this URL.
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 10:00 [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10 Corinna Vinschen
@ 2011-12-06 12:07 ` Ken Brown
2011-12-06 12:14 ` Corinna Vinschen
2011-12-06 13:57 ` Thorsten Kampe
` (8 subsequent siblings)
9 siblings, 1 reply; 93+ messages in thread
From: Ken Brown @ 2011-12-06 12:07 UTC (permalink / raw)
To: cygwin
On 12/6/2011 4:37 AM, Corinna Vinschen wrote:
> In 1.7.10 a few internals have changed, which influence the way some of
> the Cygwin tools work. For instance, the Cygwin ps tool from 1.7.9 will
> show weird tty numbers for processes running in a console window, while
> the new ps knows how to handle the new values.
[...]
> - Revamp console and pseudo tty handling. Rename /dev/ttyX to /dev/consX,
> /dev/ttyX to /dev/ptyX.
The new ps shows `?' for the tty of mintty when the latter is started
from the Cygwin Terminal shortcut, whereas it shows an ordinary pxyX for
mintty started from a bash shell. Is that to be expected?
Ken
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 12:07 ` Ken Brown
@ 2011-12-06 12:14 ` Corinna Vinschen
0 siblings, 0 replies; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-06 12:14 UTC (permalink / raw)
To: cygwin
On Dec 6 07:07, Ken Brown wrote:
> On 12/6/2011 4:37 AM, Corinna Vinschen wrote:
> >In 1.7.10 a few internals have changed, which influence the way some of
> >the Cygwin tools work. For instance, the Cygwin ps tool from 1.7.9 will
> >show weird tty numbers for processes running in a console window, while
> >the new ps knows how to handle the new values.
>
> [...]
>
> >- Revamp console and pseudo tty handling. Rename /dev/ttyX to /dev/consX,
> > /dev/ttyX to /dev/ptyX.
>
> The new ps shows `?' for the tty of mintty when the latter is
> started from the Cygwin Terminal shortcut, whereas it shows an
> ordinary pxyX for mintty started from a bash shell. Is that to be
> expected?
Yes. When you start mintty from the GUI, there's no tty. Mintty will
open the master side of a pseudo tty, but it will by itself not have a
controlling tty. Thus the ?. When started from bash, bash has already
a controlling tty which is inherited by mintty.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 10:00 [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10 Corinna Vinschen
2011-12-06 12:07 ` Ken Brown
@ 2011-12-06 13:57 ` Thorsten Kampe
2011-12-06 19:38 ` David Rothenberger
2011-12-06 14:40 ` marco atzeri
` (7 subsequent siblings)
9 siblings, 1 reply; 93+ messages in thread
From: Thorsten Kampe @ 2011-12-06 13:57 UTC (permalink / raw)
To: cygwin
* Corinna Vinschen (Tue, 6 Dec 2011 10:37:46 +0100)
> - Fifos have been rewritten and should now be more reliable.
Trying to run GNU Screen:
"open fifo /tmp/uscreens/S-thorsten/2756.cons1.hombre: Bad file
descriptor"
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 10:00 [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10 Corinna Vinschen
2011-12-06 12:07 ` Ken Brown
2011-12-06 13:57 ` Thorsten Kampe
@ 2011-12-06 14:40 ` marco atzeri
2011-12-06 17:46 ` Corinna Vinschen
2011-12-06 15:21 ` Lars Bjørndal
` (6 subsequent siblings)
9 siblings, 1 reply; 93+ messages in thread
From: marco atzeri @ 2011-12-06 14:40 UTC (permalink / raw)
To: cygwin
On 12/6/2011 10:37 AM, Corinna Vinschen wrote:
> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
> been released, so we're looking forward to release Cygwin 1.7.10 soon.
>
> Please test the latest developer snapshots at http://cygwin.com/snapshots/
> which should have "Release Candidate" quality.
>
> A very noticable change is that for this release we dropped support for
> Windows NT4 entirely. Cygwin 1.7.10 won't start on NT4 machines anymore.
> Nor will Cygwin and the Cygwin utilities know about NT4 domains. Domain
> support requires at least a Windows 2000 Active Directory domain now.
>
> In 1.7.10 a few internals have changed, which influence the way some of
> the Cygwin tools work. For instance, the Cygwin ps tool from 1.7.9 will
> show weird tty numbers for processes running in a console window, while
> the new ps knows how to handle the new values.
>
> So, ideally for testing you don't just exchange the Cygwin DLL, but also
> the tools and, if you want to test some of the new API, the include
> files and link libs.
>
> Please report bugs to the cygwin at cygwin dot com mailing list.
> Please follow the guidelines at http://cygwin.com/problems.html
> Be aware that we're mainly focusing on regressions from 1.7.9.
>
> What's new:
> -----------
>
> - New getconf tool for querying confstr(3), pathconf(3), sysconf(3), and
> limits.h configuration.
>
> - The passwd tool now allows an administrator to use the -R command for
> other user accounts: passwd -R username.
>
> - Experimental: Change the way sockets are created so that Cygwin always
> circumvents so-called "layered service providers" (LSPs) starting with
> Windows Vista.
>
> - signal handler functions are now dispatched in threads other than the
> main thread.
>
> - Support NcFsd filesystem.
>
> - clock_gettime(3) and clock_getres(3) accept per-process and per-thread
> CPU-time clocks, including CLOCK_PROCESS_CPUTIME_ID and
> CLOCK_THREAD_CPUTIME_ID.
>
> - New pthread functions:
>
> - Spin Locks: pthread_spin_destroy, pthread_spin_init, pthread_spin_lock,
> pthread_spin_trylock, pthread_spin_unlock.
>
> - Stack management: pthread_attr_getstack, pthread_attr_getstackaddr,
> pthread_attr_getguardsize, pthread_attr_setstack, pthread_attr_setstackaddr,
> pthread_attr_setguardsize, pthread_getattr_np.
>
> - Clock Selection: pthread_getcpuclockid, pthread_condattr_getclock,
> pthread_condattr_setclock.
>
> - Scheduling: pthread_setschedprio.
>
> - Add /proc/devices, /proc/misc, /proc/sysvipc, /proc/swaps.
>
> - Make various system functions thread cancelation points per POSIX.
>
> - Add ioctl FIONREAD handling for non-sockets.
>
> - dlopen now supports the Glibc-specific RTLD_NODELETE and RTLD_NOOPEN flags.
>
> - Execed processes now inherit the children of their predecessor.
>
> - Fifos have been rewritten and should now be more reliable.
>
> - GNU/glibc error.h error reporting functions: error, error_at_line,
> error_message_count, error_one_per_line, error_print_progname.
>
> - Other new API: clock_getcpuclockid, clock_nanosleep, clock_settime, __fpurge,
> getgrouplist, ppoll, psiginfo, psignal, ptsname_r, sys_siglist, sysinfo.
>
> - cygwin_conv_path_list finally supports CCP_WIN_W_TO_POSIX and
> CCP_POSIX_TO_WIN_W conversions.
>
>
> What changed:
> -------------
>
> - Drop support for Windows NT4.
>
> - The CYGWIN environment variable options "envcache", "strip_title", "title",
> "tty", and "upcaseenv" have been removed.
>
> - Revamp console and pseudo tty handling. Rename /dev/ttyX to /dev/consX,
> /dev/ttyX to /dev/ptyX.
>
> - The CYGWIN=tty mode using pipes to communicate with the console in a pseudo
> tty-like mode has been removed. Either just use the normal Windows console
> as is, or use a terminal application like mintty.
>
> - Improve fork/exec performance on 64 bit systems.
>
> - Improve Ctrl-C handling in console.
>
> - Try harder to let fork not fail if DLLs are moved in memory which should,
> in some cases, minimize the need for rebaseall.
>
> - New heap management. Drop registry setting "heap_chunk_in_mb" in favor of
> a new per-executable setting in the executable file header which can be set
> using the peflags tool. Drop registry setting "heap_slop_in_mb" entirely.
>
> - dlopen can now find "cygFOO.dll", even if the caller specified "libFOO.so".
> This is supposed to support applications which are no aware of Windows DLLs.
>
> - Make accept(2), poll(2) and shutdown(2) behave more like on Linux.
>
> - Raise max number of mount points from 30 to 64.
>
> - Output of /proc/maps is closer to what Linux prints and much more useful to
> examine process VM layout.
>
> - /proc/loadavg now shows the number of currently running processes and the
> total number of processes.
>
> - /proc/version now shows the username of whomever compiled the Cygwin DLL
> as well as the version of GCC used when compiling.
>
> - cygwin_conv_path and cygwin_conv_path_list: In CCP_WIN_A_TO_POSIX and
> CCP_POSIX_TO_WIN_A conversions, use the current Windows ANSI or OEM
> charset, depending on the return value of AreFileApisANSI. Up to Cygwin
> 1.7.9, both conversions used the current Cygwin charset for the conversion.
>
> - Various assorted bugfixes and improvements.
>
> - Preliminary, no guarantee, may be broken in subtil ways, Windows 8 support.
>
>
> Corinna
>
Hi Corinna,
I have the impression that 20111124 is working better than 20111129,
and that 20111204 and 05 have some additional problems.
On 20111129, building atlas on W7/x64 I see the custom config spinning
and never ending, while on 20111124 is goes smooth.
On 20111204 and 05, I see forking problems on octave with
some puzzling message about fifo issues. Rebaseall is ineffective.
I will look to build some simple test case for both problems.
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 10:00 [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10 Corinna Vinschen
` (2 preceding siblings ...)
2011-12-06 14:40 ` marco atzeri
@ 2011-12-06 15:21 ` Lars Bjørndal
2011-12-06 15:27 ` Corinna Vinschen
2011-12-06 17:38 ` Ken Brown
` (5 subsequent siblings)
9 siblings, 1 reply; 93+ messages in thread
From: Lars Bjørndal @ 2011-12-06 15:21 UTC (permalink / raw)
To: cygwin
Hi
Sorry, but now, with this new snapshot, BRLTTY doesn't work. I'm not
sure how to figure out which snapshot I'm currently using, where the
program does work.
Regards,
Lars
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 15:21 ` Lars Bjørndal
@ 2011-12-06 15:27 ` Corinna Vinschen
2011-12-06 15:31 ` Corinna Vinschen
0 siblings, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-06 15:27 UTC (permalink / raw)
To: cygwin
On Dec 6 16:21, Lars Bjørndal wrote:
> Hi
>
> Sorry, but now, with this new snapshot, BRLTTY doesn't work. I'm not
> sure how to figure out which snapshot I'm currently using, where the
> program does work.
Uname -a. The build date will show.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 15:27 ` Corinna Vinschen
@ 2011-12-06 15:31 ` Corinna Vinschen
2011-12-06 20:18 ` Lars Bjørndal
2011-12-07 9:23 ` Lars Bjørndal
0 siblings, 2 replies; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-06 15:31 UTC (permalink / raw)
To: cygwin
On Dec 6 16:27, Corinna Vinschen wrote:
> On Dec 6 16:21, Lars Bjørndal wrote:
> > Hi
> >
> > Sorry, but now, with this new snapshot, BRLTTY doesn't work. I'm not
> > sure how to figure out which snapshot I'm currently using, where the
> > program does work.
>
> Uname -a. The build date will show.
Btw., "brltty doesn't work" is a bit low on detail. It would also be
helpful if you could find out with which snapshot brltty starts to
misbehave.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 10:00 [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10 Corinna Vinschen
` (3 preceding siblings ...)
2011-12-06 15:21 ` Lars Bjørndal
@ 2011-12-06 17:38 ` Ken Brown
2011-12-06 17:58 ` Corinna Vinschen
2011-12-07 17:00 ` Bengt Larsson
` (4 subsequent siblings)
9 siblings, 1 reply; 93+ messages in thread
From: Ken Brown @ 2011-12-06 17:38 UTC (permalink / raw)
To: cygwin
On 12/6/2011 4:37 AM, Corinna Vinschen wrote:
> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
> been released, so we're looking forward to release Cygwin 1.7.10 soon.
>
> Please test the latest developer snapshots at http://cygwin.com/snapshots/
> which should have "Release Candidate" quality.
Here's an easily reproducible problem with the 2011-12-05 cygwin1.dll
snapshot:
1. Download cygwin-inst-20111205.tar.bz2 .
2. Start mintty from the Cygwin Terminal shortcut.
3. tar -C/ -xf /path/to/cygwin-inst-20111205.tar.bz2
--exclude=usr/bin/cygwin1.dll
An hourglass appears and tar doesn't run. I'm on W7-64 if that makes a
difference.
Ken
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 14:40 ` marco atzeri
@ 2011-12-06 17:46 ` Corinna Vinschen
2011-12-07 3:08 ` Christopher Faylor
0 siblings, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-06 17:46 UTC (permalink / raw)
To: cygwin
On Dec 6 15:39, marco atzeri wrote:
> On 12/6/2011 10:37 AM, Corinna Vinschen wrote:
> >A lot of changes and fixes have been made in Cygwin since 1.7.9 has
> >been released, so we're looking forward to release Cygwin 1.7.10 soon.
> >[...]
>
> Hi Corinna,
> I have the impression that 20111124 is working better than 20111129,
> and that 20111204 and 05 have some additional problems.
>
> On 20111129, building atlas on W7/x64 I see the custom config
> spinning and never ending, while on 20111124 is goes smooth.
I can't say a lot about the FIFO stuff, but as far as these weird hangs,
busy or not busy, are concerned, they were one of the problems we
tackled in the last couple of days. Personally I ran a lot of tests now
and I can't reproduce these hangs anymore with 1.7.10. I had a spurious
hang when starting tcsh from mintty two days ago but I couldn't
reproduce this one either since then.
> On 20111204 and 05, I see forking problems on octave with
> some puzzling message about fifo issues. Rebaseall is ineffective.
>
> I will look to build some simple test case for both problems.
Yes, that would be helpful.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 17:38 ` Ken Brown
@ 2011-12-06 17:58 ` Corinna Vinschen
2011-12-06 18:29 ` Ken Brown
0 siblings, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-06 17:58 UTC (permalink / raw)
To: cygwin
On Dec 6 12:37, Ken Brown wrote:
> On 12/6/2011 4:37 AM, Corinna Vinschen wrote:
> >A lot of changes and fixes have been made in Cygwin since 1.7.9 has
> >been released, so we're looking forward to release Cygwin 1.7.10 soon.
> >
> >Please test the latest developer snapshots at http://cygwin.com/snapshots/
> >which should have "Release Candidate" quality.
>
> Here's an easily reproducible problem with the 2011-12-05
> cygwin1.dll snapshot:
>
> 1. Download cygwin-inst-20111205.tar.bz2 .
>
> 2. Start mintty from the Cygwin Terminal shortcut.
>
> 3. tar -C/ -xf /path/to/cygwin-inst-20111205.tar.bz2
> --exclude=usr/bin/cygwin1.dll
>
> An hourglass appears and tar doesn't run. I'm on W7-64 if that
> makes a difference.
Works for me. I just tried from mintty with bash as login shell as
well as with tcsh as login shell. I even left out the --exclude and
it worked ;)
Does that really occur reproducible on your machine, every try?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 17:58 ` Corinna Vinschen
@ 2011-12-06 18:29 ` Ken Brown
2011-12-06 20:03 ` Corinna Vinschen
0 siblings, 1 reply; 93+ messages in thread
From: Ken Brown @ 2011-12-06 18:29 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 2076 bytes --]
On 12/6/2011 12:57 PM, Corinna Vinschen wrote:
> On Dec 6 12:37, Ken Brown wrote:
>> On 12/6/2011 4:37 AM, Corinna Vinschen wrote:
>>> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
>>> been released, so we're looking forward to release Cygwin 1.7.10 soon.
>>>
>>> Please test the latest developer snapshots at http://cygwin.com/snapshots/
>>> which should have "Release Candidate" quality.
>>
>> Here's an easily reproducible problem with the 2011-12-05
>> cygwin1.dll snapshot:
>>
>> 1. Download cygwin-inst-20111205.tar.bz2 .
>>
>> 2. Start mintty from the Cygwin Terminal shortcut.
>>
>> 3. tar -C/ -xf /path/to/cygwin-inst-20111205.tar.bz2
>> --exclude=usr/bin/cygwin1.dll
>>
>> An hourglass appears and tar doesn't run. I'm on W7-64 if that
>> makes a difference.
>
> Works for me. I just tried from mintty with bash as login shell as
> well as with tcsh as login shell. I even left out the --exclude and
> it worked ;)
>
> Does that really occur reproducible on your machine, every try?
Yes. And I just tried twice more with the same behavior. Earlier today
I had a similar thing occur on a different machine, on which the
2011-12-04 dll was installed instead of the 2011-12-05 dll. On that
machine (again W7-64), the mintty window simply disappeared when I gave
the tar command.
The only other detail I can think of is that I started mintty by
right-clicking on the shortcut and choosing "Run as administrator".
I'm attaching cygcheck.out in case it helps you spot some difference
between my environment and yours. I do see something strange in it:
Cygwin installations found in the registry:
System: Key: c5e39b7a9d22bafb Path: C:\cygwin
System: Key: 2707db8e4ba5ae4f Path: C:\cygwin-a
User: Key: c5e39b7a9d22bafb Path: C:\cygwin
User: Key: 2707db8e4ba5ae4f Path: C:\cygwin-a
I do have two Cygwin installations, but I don't know why they're each
showing up twice, once as "System:" and once as "User:". I just looked
at an old cygcheck output from last March, and only the "System:"
entries are there.
Ken
[-- Attachment #2: cygcheck.out --]
[-- Type: text/plain, Size: 59553 bytes --]
Cygwin Configuration Diagnostics
Current System Time: Tue Dec 06 13:13:02 2011
Windows 7 Professional N Ver 6.1 Build 7601 Service Pack 1
Running under WOW64 on AMD64
Path: C:\cygwin\usr\local\texlive\2011\bin\i386-cygwin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\windows\system32
C:\windows
C:\windows\System32\Wbem
C:\windows\System32\WindowsPowerShell\v1.0
C:\Program Files\Intel\WiFi\bin
C:\Program Files\Common Files\Intel\WirelessCommon
C:\Program Files (x86)\Toshiba\Bluetooth Toshiba Stack\sys
C:\Program Files (x86)\Toshiba\Bluetooth Toshiba Stack\sys\x64
Output from C:\cygwin\bin\id.exe
UID: 1002(kbrown-admin) GID: 513(None)
513(None) 0(root) 544(Administrators)
545(Users)
SysDir: C:\windows\system32
WinDir: C:\windows
USER = 'kbrown-admin'
PWD = '/home/kbrown-admin'
HOME = '/home/kbrown-admin'
MANPATH = '/usr/local/texlive/2011/texmf/doc/man:/usr/local/man:/usr/share/man:/usr/man:'
APPDATA = 'C:\Users\kbrown-admin\AppData\Roaming'
ProgramW6432 = 'C:\Program Files'
HOSTNAME = 'moufang'
TERM = 'xterm'
PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 37 Stepping 5, GenuineIntel'
WINDIR = 'C:\windows'
PUBLIC = 'C:\Users\Public'
OLDPWD = '/c/Users/kbrown/Desktop'
TIME_STYLE = 'long-iso'
USERDOMAIN = 'moufang'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\ProgramData'
VBOX_INSTALL_PATH = 'C:\Program Files\Oracle\VirtualBox\'
TEMP = '/tmp'
COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files'
USERNAME = 'kbrown-admin'
PROCESSOR_LEVEL = '6'
ProgramFiles(x86) = 'C:\Program Files (x86)'
PSModulePath = 'C:\windows\system32\WindowsPowerShell\v1.0\Modules\'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
PROCESSOR_ARCHITEW6432 = 'AMD64'
LANG = 'en_US.UTF-8'
USERPROFILE = 'C:\Users\kbrown-admin'
GSETTINGS_BACKEND = 'memory'
PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
CommonProgramW6432 = 'C:\Program Files\Common Files'
PROCESSOR_ARCHITECTURE = 'x86'
LOCALAPPDATA = 'C:\Users\kbrown-admin\AppData\Local'
HISTCONTROL = 'ignoredups'
ProgramData = 'C:\ProgramData'
SHLVL = '1'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
COMSPEC = 'C:\windows\system32\cmd.exe'
TMP = '/tmp'
SYSTEMROOT = 'C:\windows'
PRINTER = 'Quicken PDF Printer'
PROCESSOR_REVISION = '2505'
INFOPATH = '/usr/local/texlive/2011/texmf/doc/info:/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files (x86)'
NUMBER_OF_PROCESSORS = '4'
COMPUTERNAME = 'MOUFANG'
_ = '/usr/bin/cygcheck'
HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Installations
(default) = '\??\C:\cygwin'
2707db8e4ba5ae4f = '\??\C:\cygwin-a'
HKEY_CURRENT_USER\Software\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin\setup
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations
(default) = '\??\C:\cygwin'
2707db8e4ba5ae4f = '\??\C:\cygwin-a'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup
(default) = 'C:\cygwin'
obcaseinsensitive set to 0
Cygwin installations found in the registry:
System: Key: c5e39b7a9d22bafb Path: C:\cygwin
System: Key: 2707db8e4ba5ae4f Path: C:\cygwin-a
User: Key: c5e39b7a9d22bafb Path: C:\cygwin
User: Key: 2707db8e4ba5ae4f Path: C:\cygwin-a
c: hd NTFS 109256Mb 73% CP CS UN PA FC TI106026W0C
d: cd N/A N/A
C:\cygwin / system binary,auto
C: /c system binary,posix=0
C:\cygwin\bin /usr/bin system binary,auto
C:\cygwin\lib /usr/lib system binary,auto
cygdrive prefix /cygdrive user binary,auto
Found: C:\cygwin\bin\awk
-> C:\cygwin\bin\gawk.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cp.exe
Found: C:\cygwin\bin\cpp.exe
-> C:\cygwin\etc\alternatives\cpp
-> C:\cygwin\bin\cpp-4.exe
Not Found: crontab
Found: C:\cygwin\bin\find.exe
Found: C:\windows\system32\find.exe
Warning: C:\cygwin\bin\find.exe hides C:\windows\system32\find.exe
Found: C:\cygwin\bin\gcc.exe
-> C:\cygwin\etc\alternatives\gcc
-> C:\cygwin\bin\gcc-4.exe
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\grep.exe
Found: C:\cygwin\bin\kill.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Found: C:\cygwin\bin\make.exe
Found: C:\cygwin\bin\mv.exe
Found: C:\cygwin\bin\patch.exe
Found: C:\cygwin\bin\perl.exe
Found: C:\cygwin\bin\rm.exe
Found: C:\cygwin\bin\sed.exe
Found: C:\cygwin\bin\ssh.exe
Found: C:\cygwin\bin\sh.exe
Found: C:\cygwin\bin\tar.exe
Found: C:\cygwin\bin\test.exe
Not Found: vi
Not Found: vim
118k 2011/09/10 C:\cygwin\bin\cygapr-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygapr-1-0.dll" v0.0 ts=2011/9/10 17:56
87k 2011/09/10 C:\cygwin\bin\cygaprutil-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygaprutil-1-0.dll" v0.0 ts=2011/9/10 17:46
567k 2011/11/13 C:\cygwin\bin\cygaspell-15.dll - os=4.0 img=1.0 sys=4.0
"cygaspell-15.dll" v0.0 ts=2011/11/10 19:41
94k 2011/11/16 C:\cygwin\bin\cygatk-1.0-0.dll - os=4.0 img=1.0 sys=4.0
"cygatk-1.0-0.dll" v0.0 ts=2011/11/15 22:22
15k 2009/12/27 C:\cygwin\bin\cygattr-1.dll - os=4.0 img=1.0 sys=4.0
"cygattr-1.dll" v0.0 ts=2009/11/18 7:52
95k 2010/06/24 C:\cygwin\bin\cygblkid-1.dll - os=4.0 img=1.0 sys=4.0
"cygblkid-1.dll" v0.0 ts=2010/6/24 15:20
62k 2011/05/21 C:\cygwin\bin\cygbz2-1.dll - os=4.0 img=1.0 sys=4.0
"cygbz2-1.dll" v0.0 ts=2011/5/21 15:16
678k 2010/12/29 C:\cygwin\bin\cygcairo-2.dll - os=4.0 img=1.0 sys=4.0
"cygcairo-2.dll" v0.0 ts=2010/12/29 1:16
20k 2010/12/29 C:\cygwin\bin\cygcairo-gobject-2.dll - os=4.0 img=1.0 sys=4.0
"cygcairo-gobject-2.dll" v0.0 ts=2010/12/29 1:17
98k 2010/12/29 C:\cygwin\bin\cygcairo-script-interpreter-2.dll - os=4.0 img=1.0 sys=4.0
"cygcairo-script-interpreter-2.dll" v0.0 ts=2010/12/29 1:17
8k 2011/10/16 C:\cygwin\bin\cygcharset-1.dll - os=4.0 img=1.0 sys=4.0
"cygcharset-1.dll" v0.0 ts=2011/10/16 13:00
108k 2010/01/05 C:\cygwin\bin\cygcloog-0.dll - os=4.0 img=1.0 sys=4.0
"cygcloog-0.dll" v0.0 ts=2010/1/4 19:45
188k 2011/11/16 C:\cygwin\bin\cygcroco-0.6-3.dll - os=4.0 img=1.0 sys=4.0
"cygcroco-0.6-3.dll" v0.0 ts=2011/11/16 2:53
7k 2003/10/19 C:\cygwin\bin\cygcrypt-0.dll - os=4.0 img=1.0 sys=4.0
"cygcrypt-0.dll" v0.0 ts=2003/10/19 3:57
1147k 2011/03/16 C:\cygwin\bin\cygcrypto-0.9.8.dll - os=4.0 img=1.0 sys=4.0
"cygcrypto-0.9.8.dll" v0.0 ts=2011/3/16 16:54
314k 2011/11/02 C:\cygwin\bin\cygcurl-4.dll - os=4.0 img=1.0 sys=4.0
"cygcurl-4.dll" v0.0 ts=2011/11/1 19:38
17k 2011/10/02 C:\cygwin\bin\cygdatrie-1.dll - os=4.0 img=1.0 sys=4.0
"cygdatrie-1.dll" v0.0 ts=2011/10/2 19:13
943k 2007/12/17 C:\cygwin\bin\cygdb-4.5.dll - os=4.0 img=1.0 sys=4.0
"cygdb-4.5.dll" v0.0 ts=2007/12/17 8:12
219k 2011/10/03 C:\cygwin\bin\cygdbus-1-3.dll - os=4.0 img=1.0 sys=4.0
"cygdbus-1-3.dll" v0.0 ts=2011/10/3 1:10
1296k 2007/12/17 C:\cygwin\bin\cygdb_cxx-4.5.dll - os=4.0 img=1.0 sys=4.0
"cygdb_cxx-4.5.dll" v0.0 ts=2007/12/17 8:12
511k 2010/06/17 C:\cygwin\bin\cygedit-0.dll - os=4.0 img=1.0 sys=4.0
"cygedit-0.dll" v0.0 ts=2010/6/17 7:42
57k 2010/12/06 C:\cygwin\bin\cygevtlog-0.dll - os=4.0 img=1.0 sys=4.0
"cygevtlog-0.dll" v0.0 ts=2010/12/6 10:59
118k 2008/05/09 C:\cygwin\bin\cygexpat-1.dll - os=4.0 img=1.0 sys=4.0
"cygexpat-1.dll" v0.0 ts=2008/5/9 0:03
71k 2010/05/12 C:\cygwin\bin\cygexslt-0.dll - os=4.0 img=1.0 sys=4.0
"cygexslt-0.dll" v0.0 ts=2010/5/12 5:59
29k 2010/05/12 C:\cygwin\bin\cygfam-0.dll - os=4.0 img=1.0 sys=4.0
"cygfam-0.dll" v0.0 ts=2010/5/12 6:26
21k 2011/10/26 C:\cygwin\bin\cygffi-4.dll - os=4.0 img=1.0 sys=4.0
"cygffi-4.dll" v0.0 ts=2011/10/23 9:33
176k 2010/01/29 C:\cygwin\bin\cygfontconfig-1.dll - os=4.0 img=1.0 sys=4.0
"cygfontconfig-1.dll" v0.0 ts=2010/1/28 17:12
20k 2010/10/31 C:\cygwin\bin\cygfontenc-1.dll - os=4.0 img=1.0 sys=4.0
"cygfontenc-1.dll" v0.0 ts=2010/10/31 15:19
43k 2010/01/02 C:\cygwin\bin\cygform-10.dll - os=4.0 img=1.0 sys=4.0
"cygform-10.dll" v0.0 ts=2010/1/2 9:49
40k 2009/03/01 C:\cygwin\bin\cygform-8.dll - os=4.0 img=1.0 sys=4.0
"cygform-8.dll" v0.0 ts=2009/3/1 1:32
43k 2009/11/20 C:\cygwin\bin\cygform-9.dll - os=4.0 img=1.0 sys=4.0
"cygform-9.dll" v0.0 ts=2009/11/20 14:14
47k 2010/01/02 C:\cygwin\bin\cygformw-10.dll - os=4.0 img=1.0 sys=4.0
"cygformw-10.dll" v0.0 ts=2010/1/2 12:31
548k 2011/11/09 C:\cygwin\bin\cygfpx-1.dll - os=4.0 img=1.0 sys=4.0
"cygfpx-1.dll" v0.0 ts=2011/11/9 17:30
500k 2011/10/19 C:\cygwin\bin\cygfreetype-6.dll - os=4.0 img=1.0 sys=4.0
"cygfreetype-6.dll" v0.0 ts=2011/10/19 0:40
79k 2011/10/26 C:\cygwin\bin\cyggcc_s-1.dll - os=4.0 img=1.0 sys=4.0
"cyggcc_s-1.dll" v0.0 ts=2011/10/23 9:15
449k 2011/05/20 C:\cygwin\bin\cyggcrypt-11.dll - os=4.0 img=1.0 sys=4.0
"cyggcrypt-11.dll" v0.0 ts=2011/5/19 22:29
19k 2009/02/26 C:\cygwin\bin\cyggdbm-4.dll - os=4.0 img=1.0 sys=4.0
"cyggdbm-4.dll" v0.0 ts=2009/2/26 2:58
8k 2009/02/26 C:\cygwin\bin\cyggdbm_compat-4.dll - os=4.0 img=1.0 sys=4.0
"cyggdbm_compat-4.dll" v0.0 ts=2009/2/26 2:58
517k 2011/11/16 C:\cygwin\bin\cyggdk-3-0.dll - os=4.0 img=1.0 sys=4.0
"cyggdk-3-0.dll" v0.0 ts=2011/11/15 23:31
554k 2011/11/16 C:\cygwin\bin\cyggdk-x11-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggdk-x11-2.0-0.dll" v0.0 ts=2011/11/15 23:26
103k 2011/09/26 C:\cygwin\bin\cyggdk_pixbuf-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggdk_pixbuf-2.0-0.dll" v0.0 ts=2011/9/25 21:19
1006k 2011/10/16 C:\cygwin\bin\cyggettextlib-0-18-1.dll - os=4.0 img=1.0 sys=4.0
"cyggettextlib-0-18-1.dll" v0.0 ts=2011/10/16 1:51
245k 2011/10/16 C:\cygwin\bin\cyggettextpo-0.dll - os=4.0 img=1.0 sys=4.0
"cyggettextpo-0.dll" v0.0 ts=2011/10/16 2:12
213k 2011/10/16 C:\cygwin\bin\cyggettextsrc-0-18-1.dll - os=4.0 img=1.0 sys=4.0
"cyggettextsrc-0-18-1.dll" v0.0 ts=2011/10/16 1:57
29k 2009/03/23 C:\cygwin\bin\cyggif-4.dll - os=4.0 img=1.0 sys=4.0
"cyggif-4.dll" v0.0 ts=2009/3/23 14:55
1024k 2011/11/16 C:\cygwin\bin\cyggio-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggio-2.0-0.dll" v0.0 ts=2011/11/15 19:23
377k 2011/07/20 C:\cygwin\bin\cygGL-1.dll - os=4.0 img=1.0 sys=4.0
"cygGL-1.dll" v0.0 ts=2011/7/19 21:19
846k 2011/11/16 C:\cygwin\bin\cygglib-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cygglib-2.0-0.dll" v0.0 ts=2011/11/15 19:16
141k 2009/03/30 C:\cygwin\bin\cygglitz-1.dll - os=4.0 img=1.0 sys=4.0
"cygglitz-1.dll" v0.0 ts=2009/3/30 12:22
21k 2009/03/30 C:\cygwin\bin\cygglitz-glx-1.dll - os=4.0 img=1.0 sys=4.0
"cygglitz-glx-1.dll" v0.0 ts=2009/3/30 12:23
434k 2011/07/20 C:\cygwin\bin\cygGLU-1.dll - os=4.0 img=1.0 sys=4.0
"cygGLU-1.dll" v0.0 ts=2011/7/19 21:20
12k 2011/11/16 C:\cygwin\bin\cyggmodule-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggmodule-2.0-0.dll" v0.0 ts=2011/11/15 19:19
317k 2011/07/31 C:\cygwin\bin\cyggmp-3.dll - os=4.0 img=1.0 sys=4.0
"cyggmp-3.dll" v0.0 ts=2011/7/31 1:14
14k 2011/07/31 C:\cygwin\bin\cyggmpxx-4.dll - os=4.0 img=1.0 sys=4.0
"cyggmpxx-4.dll" v0.0 ts=2011/7/31 6:31
614k 2011/11/15 C:\cygwin\bin\cyggnutls-26.dll - os=4.0 img=1.0 sys=4.0
"cyggnutls-26.dll" v0.0 ts=2011/11/15 2:02
21k 2011/11/15 C:\cygwin\bin\cyggnutls-extra-26.dll - os=4.0 img=1.0 sys=4.0
"cyggnutls-extra-26.dll" v0.0 ts=2011/11/15 2:02
24k 2011/11/15 C:\cygwin\bin\cyggnutls-openssl-27.dll - os=4.0 img=1.0 sys=4.0
"cyggnutls-openssl-27.dll" v0.0 ts=2011/11/15 2:03
52k 2011/11/15 C:\cygwin\bin\cyggnutlsxx-27.dll - os=4.0 img=1.0 sys=4.0
"cyggnutlsxx-27.dll" v0.0 ts=2011/11/15 2:02
267k 2011/11/16 C:\cygwin\bin\cyggobject-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggobject-2.0-0.dll" v0.0 ts=2011/11/15 19:20
42k 2011/10/26 C:\cygwin\bin\cyggomp-1.dll - os=4.0 img=1.0 sys=4.0
"cyggomp-1.dll" v0.0 ts=2011/10/23 9:21
14k 2011/05/20 C:\cygwin\bin\cyggpg-error-0.dll - os=4.0 img=1.0 sys=4.0
"cyggpg-error-0.dll" v0.0 ts=2011/5/19 22:04
5491k 2008/11/27 C:\cygwin\bin\cyggs-8.dll - os=4.0 img=1.0 sys=4.0
"cyggs-8.dll" v0.0 ts=2008/11/27 8:24
6546k 2011/11/10 C:\cygwin\bin\cyggs-9.dll - os=4.0 img=1.0 sys=4.0
"cyggs-9.dll" v0.0 ts=2011/11/10 17:56
190k 2011/05/24 C:\cygwin\bin\cyggsf-1-114.dll - os=4.0 img=1.0 sys=4.0
"cyggsf-1-114.dll" v0.0 ts=2011/5/24 17:33
14k 2011/11/16 C:\cygwin\bin\cyggthread-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggthread-2.0-0.dll" v0.0 ts=2011/11/15 19:19
3783k 2011/11/16 C:\cygwin\bin\cyggtk-3-0.dll - os=4.0 img=1.0 sys=4.0
"cyggtk-3-0.dll" v0.0 ts=2011/11/16 0:12
3679k 2011/11/16 C:\cygwin\bin\cyggtk-x11-2.0-0.dll - os=4.0 img=1.0 sys=4.0
"cyggtk-x11-2.0-0.dll" v0.0 ts=2011/11/15 23:33
24k 2009/06/23 C:\cygwin\bin\cyghistory6.dll - os=4.0 img=1.0 sys=4.0
"cyghistory6.dll" v0.0 ts=2009/6/23 8:20
25k 2011/01/26 C:\cygwin\bin\cyghistory7.dll - os=4.0 img=1.0 sys=4.0
"cyghistory7.dll" v0.0 ts=2011/1/25 22:25
74k 2010/10/31 C:\cygwin\bin\cygICE-6.dll - os=4.0 img=1.0 sys=4.0
"cygICE-6.dll" v0.0 ts=2010/10/31 15:18
358k 2011/04/29 C:\cygwin\bin\cygicons-0.dll - os=4.0 img=1.4 sys=4.0
"cygicons-0.dll" v0.0 ts=2011/4/29 0:37
985k 2011/10/16 C:\cygwin\bin\cygiconv-2.dll - os=4.0 img=1.0 sys=4.0
"cygiconv-2.dll" v0.0 ts=2011/10/16 13:01
190k 2011/11/16 C:\cygwin\bin\cygidn-11.dll - os=4.0 img=1.0 sys=4.0
"cygidn-11.dll" v0.0 ts=2011/11/16 9:51
31k 2005/11/20 C:\cygwin\bin\cygintl-3.dll - os=4.0 img=1.0 sys=4.0
"cygintl-3.dll" v0.0 ts=2005/11/19 21:04
35k 2011/10/16 C:\cygwin\bin\cygintl-8.dll - os=4.0 img=1.0 sys=4.0
"cygintl-8.dll" v0.0 ts=2011/10/16 1:38
241k 2008/04/02 C:\cygwin\bin\cygjasper-1-701-1.dll - os=4.0 img=1.0 sys=4.0
"cygjasper-1-701-1.dll" v0.0 ts=2008/4/2 11:19
246k 2010/05/20 C:\cygwin\bin\cygjasper-1.dll - os=4.0 img=1.0 sys=4.0
"cygjasper-1.dll" v0.0 ts=2010/5/20 1:04
47k 2009/12/23 C:\cygwin\bin\cygjbig-2.dll - os=4.0 img=1.0 sys=4.0
"cygjbig-2.dll" v0.0 ts=2009/12/23 11:59
125k 2009/08/08 C:\cygwin\bin\cygjpeg-62.dll - os=4.0 img=1.0 sys=4.0
"cygjpeg-62.dll" v0.0 ts=2009/8/8 16:48
193k 2009/08/08 C:\cygwin\bin\cygjpeg-7.dll - os=4.0 img=1.0 sys=4.0
"cygjpeg-7.dll" v0.0 ts=2009/8/8 15:39
200k 2010/08/09 C:\cygwin\bin\cygjpeg-8.dll - os=4.0 img=1.0 sys=4.0
"cygjpeg-8.dll" v0.0 ts=2010/8/9 3:02
39k 2008/09/07 C:\cygwin\bin\cyglber-2-3-0.dll - os=4.0 img=1.0 sys=4.0
"cyglber-2-3-0.dll" v0.0 ts=2008/9/7 8:28
173k 2010/06/25 C:\cygwin\bin\cyglcms-1.dll - os=4.0 img=1.0 sys=4.0
"cyglcms-1.dll" v0.0 ts=2010/6/25 5:50
232k 2011/11/09 C:\cygwin\bin\cyglcms2-2.dll - os=4.0 img=1.0 sys=4.0
"cyglcms2-2.dll" v0.0 ts=2011/11/9 12:22
189k 2008/09/07 C:\cygwin\bin\cygldap-2-3-0.dll - os=4.0 img=1.0 sys=4.0
"cygldap-2-3-0.dll" v0.0 ts=2008/9/7 8:29
201k 2008/09/07 C:\cygwin\bin\cygldap_r-2-3-0.dll - os=4.0 img=1.0 sys=4.0
"cygldap_r-2-3-0.dll" v0.0 ts=2008/9/7 8:31
5k 2011/12/05 C:\cygwin\bin\cyglsa.dll - os=4.0 img=1.0 sys=4.0
"cyglsa.dll" v0.0 ts=2011/12/5 13:03
9k 2011/12/05 C:\cygwin\bin\cyglsa64.dll - os=5.2 img=0.0 sys=5.2
30k 2010/09/23 C:\cygwin\bin\cygltdl-7.dll - os=4.0 img=1.0 sys=4.0
"cygltdl-7.dll" v0.0 ts=2010/9/23 15:45
125k 2010/04/09 C:\cygwin\bin\cyglzma-1.dll - os=4.0 img=1.0 sys=4.0
"cyglzma-1.dll" v0.0 ts=2010/4/9 11:54
123k 2011/05/19 C:\cygwin\bin\cyglzma-5.dll - os=4.0 img=1.0 sys=4.0
"cyglzma-5.dll" v0.0 ts=2011/5/18 22:41
116k 2011/11/16 C:\cygwin\bin\cyglzo2-2.dll - os=4.0 img=1.0 sys=4.0
"cyglzo2-2.dll" v0.0 ts=2011/11/16 17:27
99k 2011/11/02 C:\cygwin\bin\cygmagic-1.dll - os=4.0 img=1.0 sys=4.0
"cygmagic-1.dll" v0.0 ts=2011/11/2 18:05
314k 2010/01/19 C:\cygwin\bin\cygMagick++-1.dll - os=4.0 img=1.0 sys=4.0
"cygMagick++-1.dll" v0.0 ts=2010/1/19 7:53
391k 2006/11/05 C:\cygwin\bin\cygMagick++-10.dll - os=4.0 img=1.0 sys=4.0
"cygMagick++-10.dll" v0.0 ts=2006/11/5 9:43
1709k 2006/11/05 C:\cygwin\bin\cygMagick-10.dll - os=4.0 img=1.0 sys=4.0
"cygMagick-10.dll" v0.0 ts=2006/11/5 9:32
1801k 2010/01/19 C:\cygwin\bin\cygMagickCore-1.dll - os=4.0 img=1.0 sys=4.0
"cygMagickCore-1.dll" v0.0 ts=2010/1/19 7:27
789k 2010/01/19 C:\cygwin\bin\cygMagickWand-1.dll - os=4.0 img=1.0 sys=4.0
"cygMagickWand-1.dll" v0.0 ts=2010/1/19 7:48
25k 2010/01/02 C:\cygwin\bin\cygmenu-10.dll - os=4.0 img=1.0 sys=4.0
"cygmenu-10.dll" v0.0 ts=2010/1/2 9:48
21k 2009/03/01 C:\cygwin\bin\cygmenu-8.dll - os=4.0 img=1.0 sys=4.0
"cygmenu-8.dll" v0.0 ts=2009/3/1 1:31
25k 2009/11/20 C:\cygwin\bin\cygmenu-9.dll - os=4.0 img=1.0 sys=4.0
"cygmenu-9.dll" v0.0 ts=2009/11/20 14:13
25k 2010/01/02 C:\cygwin\bin\cygmenuw-10.dll - os=4.0 img=1.0 sys=4.0
"cygmenuw-10.dll" v0.0 ts=2010/1/2 12:30
24k 2008/10/30 C:\cygwin\bin\cygminires.dll - os=4.0 img=1.2 sys=4.0
"cygminires.dll" v0.0 ts=2008/10/30 19:53
213k 2011/07/31 C:\cygwin\bin\cygmp-3.dll - os=4.0 img=1.0 sys=4.0
"cygmp-3.dll" v0.0 ts=2011/7/31 1:12
64k 2009/11/09 C:\cygwin\bin\cygmpc-1.dll - os=4.0 img=1.0 sys=4.0
"cygmpc-1.dll" v0.0 ts=2009/11/8 20:21
269k 2009/06/07 C:\cygwin\bin\cygmpfr-1.dll - os=4.0 img=1.0 sys=4.0
"cygmpfr-1.dll" v0.0 ts=2009/6/7 17:10
1102k 2011/08/07 C:\cygwin\bin\cygmpfr-4.dll - os=4.0 img=1.0 sys=4.0
"cygmpfr-4.dll" v0.0 ts=2011/8/6 21:47
77k 2010/01/21 C:\cygwin\bin\cygMrm-2.dll - os=4.0 img=1.0 sys=4.0
"cygMrm-2.dll" v0.0 ts=2010/1/21 2:33
63k 2010/01/02 C:\cygwin\bin\cygncurses++-10.dll - os=4.0 img=1.0 sys=4.0
"cygncurses++-10.dll" v0.0 ts=2010/1/2 10:00
66k 2009/03/01 C:\cygwin\bin\cygncurses++-8.dll - os=4.0 img=1.0 sys=4.0
"cygncurses++-8.dll" v0.0 ts=2009/3/1 1:39
63k 2009/11/20 C:\cygwin\bin\cygncurses++-9.dll - os=4.0 img=1.0 sys=4.0
"cygncurses++-9.dll" v0.0 ts=2009/11/20 14:25
63k 2010/01/02 C:\cygwin\bin\cygncurses++w-10.dll - os=4.0 img=1.0 sys=4.0
"cygncurses++w-10.dll" v0.0 ts=2010/1/2 12:41
195k 2010/01/02 C:\cygwin\bin\cygncurses-10.dll - os=4.0 img=1.0 sys=4.0
"cygncurses-10.dll" v0.0 ts=2010/1/2 9:45
237k 2009/03/01 C:\cygwin\bin\cygncurses-8.dll - os=4.0 img=1.0 sys=4.0
"cygncurses-8.dll" v0.0 ts=2009/3/1 1:28
198k 2009/11/20 C:\cygwin\bin\cygncurses-9.dll - os=4.0 img=1.0 sys=4.0
"cygncurses-9.dll" v0.0 ts=2009/11/20 14:10
244k 2010/01/02 C:\cygwin\bin\cygncursesw-10.dll - os=4.0 img=1.0 sys=4.0
"cygncursesw-10.dll" v0.0 ts=2010/1/2 12:28
118k 2011/11/15 C:\cygwin\bin\cygneon-27.dll - os=4.0 img=1.0 sys=4.0
"cygneon-27.dll" v0.0 ts=2011/11/13 9:42
198k 2011/11/22 C:\cygwin\bin\cygnetpbm-10.dll - os=4.0 img=1.0 sys=4.0
"cygnetpbm-10.dll" v0.0 ts=2011/11/21 20:02
13k 2010/01/02 C:\cygwin\bin\cygpanel-10.dll - os=4.0 img=1.0 sys=4.0
"cygpanel-10.dll" v0.0 ts=2010/1/2 9:47
11k 2009/03/01 C:\cygwin\bin\cygpanel-8.dll - os=4.0 img=1.0 sys=4.0
"cygpanel-8.dll" v0.0 ts=2009/3/1 1:30
13k 2009/11/20 C:\cygwin\bin\cygpanel-9.dll - os=4.0 img=1.0 sys=4.0
"cygpanel-9.dll" v0.0 ts=2009/11/20 14:12
13k 2010/01/02 C:\cygwin\bin\cygpanelw-10.dll - os=4.0 img=1.0 sys=4.0
"cygpanelw-10.dll" v0.0 ts=2010/1/2 11:30
236k 2011/11/16 C:\cygwin\bin\cygpango-1.0-0.dll - os=4.0 img=1.0 sys=4.0
"cygpango-1.0-0.dll" v0.0 ts=2011/11/15 22:49
37k 2011/11/16 C:\cygwin\bin\cygpangocairo-1.0-0.dll - os=4.0 img=1.0 sys=4.0
"cygpangocairo-1.0-0.dll" v0.0 ts=2011/11/15 22:50
188k 2011/11/16 C:\cygwin\bin\cygpangoft2-1.0-0.dll - os=4.0 img=1.0 sys=4.0
"cygpangoft2-1.0-0.dll" v0.0 ts=2011/11/15 22:50
110k 2011/11/16 C:\cygwin\bin\cygpangox-1.0-0.dll - os=4.0 img=1.0 sys=4.0
"cygpangox-1.0-0.dll" v0.0 ts=2011/11/15 22:50
24k 2011/11/16 C:\cygwin\bin\cygpangoxft-1.0-0.dll - os=4.0 img=1.0 sys=4.0
"cygpangoxft-1.0-0.dll" v0.0 ts=2011/11/15 22:50
9k 2010/10/08 C:\cygwin\bin\cygpaper-1.dll - os=4.0 img=1.0 sys=4.0
"cygpaper-1.dll" v0.0 ts=2010/10/8 0:56
257k 2011/09/27 C:\cygwin\bin\cygpcre-0.dll - os=4.0 img=1.0 sys=4.0
"cygpcre-0.dll" v0.0 ts=2011/9/27 1:41
8k 2011/09/27 C:\cygwin\bin\cygpcreposix-0.dll - os=4.0 img=1.0 sys=4.0
"cygpcreposix-0.dll" v0.0 ts=2011/9/27 1:41
1640k 2011/09/17 C:\cygwin\bin\cygperl5_14.dll - os=4.0 img=1.0 sys=4.0
"cygperl5_14.dll" v0.0 ts=2011/9/16 10:36
428k 2011/08/22 C:\cygwin\bin\cygpixman-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygpixman-1-0.dll" v0.0 ts=2011/8/22 4:39
249k 2011/07/28 C:\cygwin\bin\cygpng12.dll - os=4.0 img=1.0 sys=4.0
"cygpng12.dll" v0.0 ts=2011/7/28 1:20
129k 2011/07/28 C:\cygwin\bin\cygpng14-14.dll - os=4.0 img=1.0 sys=4.0
"cygpng14-14.dll" v0.0 ts=2011/7/28 1:55
22k 2002/06/09 C:\cygwin\bin\cygpopt-0.dll - os=4.0 img=1.0 sys=4.0
"cygpopt-0.dll" v0.0 ts=2002/6/9 1:45
695k 2009/04/18 C:\cygwin\bin\cygppl-7.dll - os=4.0 img=1.0 sys=4.0
"cygppl-7.dll" v0.0 ts=2009/4/18 8:44
2481k 2009/04/18 C:\cygwin\bin\cygppl_c-2.dll - os=4.0 img=1.0 sys=4.0
"cygppl_c-2.dll" v0.0 ts=2009/4/18 8:47
103k 2009/01/07 C:\cygwin\bin\cygpq.dll - os=4.0 img=1.0 sys=4.0
"cygpq.dll" v0.0 ts=2009/1/7 11:46
27k 2009/09/07 C:\cygwin\bin\cygproxy-0.dll - os=4.0 img=1.0 sys=4.0
"cygproxy-0.dll" v0.0 ts=2009/9/6 20:56
122k 2011/10/05 C:\cygwin\bin\cygproxy-1.dll - os=4.0 img=1.0 sys=4.0
"cygproxy-1.dll" v0.0 ts=2011/10/5 0:45
6k 2011/11/13 C:\cygwin\bin\cygpspell-15.dll - os=4.0 img=1.0 sys=4.0
"cygpspell-15.dll" v0.0 ts=2011/11/10 19:42
18k 2009/04/18 C:\cygwin\bin\cygpwl-4.dll - os=4.0 img=1.0 sys=4.0
"cygpwl-4.dll" v0.0 ts=2009/4/18 8:44
155k 2009/06/23 C:\cygwin\bin\cygreadline6.dll - os=4.0 img=1.0 sys=4.0
"cygreadline6.dll" v0.0 ts=2009/6/23 8:20
164k 2011/01/26 C:\cygwin\bin\cygreadline7.dll - os=4.0 img=1.0 sys=4.0
"cygreadline7.dll" v0.0 ts=2011/1/25 22:25
179k 2011/11/16 C:\cygwin\bin\cygrsvg-2-2.dll - os=4.0 img=1.0 sys=4.0
"cygrsvg-2-2.dll" v0.0 ts=2011/11/16 3:12
84k 2010/07/02 C:\cygwin\bin\cygsasl2-2.dll - os=4.0 img=1.0 sys=4.0
"cygsasl2-2.dll" v0.0 ts=2010/7/1 23:19
54k 2011/03/04 C:\cygwin\bin\cygserf-0-1.dll - os=4.0 img=1.0 sys=4.0
"cygserf-0-1.dll" v0.0 ts=2011/3/4 12:45
58k 2011/09/11 C:\cygwin\bin\cygserf-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygserf-1-0.dll" v0.0 ts=2011/9/11 15:56
8k 2011/05/05 C:\cygwin\bin\cygsigsegv-2.dll - os=4.0 img=1.0 sys=4.0
"cygsigsegv-2.dll" v0.0 ts=2011/5/5 3:33
25k 2010/10/31 C:\cygwin\bin\cygSM-6.dll - os=4.0 img=1.0 sys=4.0
"cygSM-6.dll" v0.0 ts=2010/10/31 15:24
1613k 2010/12/01 C:\cygwin\bin\cygsqlite3-0.dll - os=4.0 img=1.0 sys=4.0
"cygsqlite3-0.dll" v0.0 ts=2010/12/1 7:20
122k 2010/11/03 C:\cygwin\bin\cygssh2-1.dll - os=4.0 img=1.0 sys=4.0
"cygssh2-1.dll" v0.0 ts=2010/11/3 2:44
263k 2011/03/16 C:\cygwin\bin\cygssl-0.9.8.dll - os=4.0 img=1.0 sys=4.0
"cygssl-0.9.8.dll" v0.0 ts=2011/3/16 16:54
8k 2011/10/26 C:\cygwin\bin\cygssp-0.dll - os=4.0 img=1.0 sys=4.0
"cygssp-0.dll" v0.0 ts=2011/10/23 9:33
780k 2011/10/26 C:\cygwin\bin\cygstdc++-6.dll - os=4.0 img=1.0 sys=4.0
"cygstdc++-6.dll" v0.0 ts=2011/10/23 9:58
290k 2011/10/21 C:\cygwin\bin\cygsvn_client-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_client-1-0.dll" v0.0 ts=2011/10/20 20:50
39k 2011/10/21 C:\cygwin\bin\cygsvn_delta-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_delta-1-0.dll" v0.0 ts=2011/10/20 20:41
56k 2011/10/21 C:\cygwin\bin\cygsvn_diff-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_diff-1-0.dll" v0.0 ts=2011/10/20 20:41
20k 2011/10/21 C:\cygwin\bin\cygsvn_fs-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_fs-1-0.dll" v0.0 ts=2011/10/20 20:43
143k 2011/10/21 C:\cygwin\bin\cygsvn_fs_base-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_fs_base-1-0.dll" v0.0 ts=2011/10/20 20:42
133k 2011/10/21 C:\cygwin\bin\cygsvn_fs_fs-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_fs_fs-1-0.dll" v0.0 ts=2011/10/20 20:42
7k 2011/10/21 C:\cygwin\bin\cygsvn_fs_util-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_fs_util-1-0.dll" v0.0 ts=2011/10/20 20:41
35k 2011/10/21 C:\cygwin\bin\cygsvn_ra-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_ra-1-0.dll" v0.0 ts=2011/10/20 20:46
23k 2011/10/21 C:\cygwin\bin\cygsvn_ra_local-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_ra_local-1-0.dll" v0.0 ts=2011/10/20 20:45
118k 2011/10/21 C:\cygwin\bin\cygsvn_ra_neon-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_ra_neon-1-0.dll" v0.0 ts=2011/10/20 20:42
131k 2011/10/21 C:\cygwin\bin\cygsvn_ra_serf-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_ra_serf-1-0.dll" v0.0 ts=2011/10/20 20:43
70k 2011/10/21 C:\cygwin\bin\cygsvn_ra_svn-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_ra_svn-1-0.dll" v0.0 ts=2011/10/20 20:42
146k 2011/10/21 C:\cygwin\bin\cygsvn_repos-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_repos-1-0.dll" v0.0 ts=2011/10/20 20:44
289k 2011/10/21 C:\cygwin\bin\cygsvn_subr-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_subr-1-0.dll" v0.0 ts=2011/10/20 20:41
470k 2011/10/21 C:\cygwin\bin\cygsvn_wc-1-0.dll - os=4.0 img=1.0 sys=4.0
"cygsvn_wc-1-0.dll" v0.0 ts=2011/10/20 20:42
330k 2010/12/09 C:\cygwin\bin\cygsyslog-ng-0.dll - os=4.0 img=1.0 sys=4.0
"cygsyslog-ng-0.dll" v0.0 ts=2010/12/9 8:33
231k 2009/09/15 C:\cygwin\bin\cygt1-5.dll - os=4.0 img=1.0 sys=4.0
"cygt1-5.dll" v0.0 ts=2009/9/15 5:59
58k 2011/11/14 C:\cygwin\bin\cygtasn1-3.dll - os=4.0 img=1.0 sys=4.0
"cygtasn1-3.dll" v0.0 ts=2011/11/14 14:35
26k 2011/10/04 C:\cygwin\bin\cygthai-0.dll - os=4.0 img=1.0 sys=4.0
"cygthai-0.dll" v0.0 ts=2011/10/4 16:22
48k 2010/01/02 C:\cygwin\bin\cygtic-10.dll - os=4.0 img=1.0 sys=4.0
"cygtic-10.dll" v0.0 ts=2010/1/2 9:45
48k 2009/11/20 C:\cygwin\bin\cygtic-9.dll - os=4.0 img=1.0 sys=4.0
"cygtic-9.dll" v0.0 ts=2009/11/20 14:10
48k 2010/01/02 C:\cygwin\bin\cygticw-10.dll - os=4.0 img=1.0 sys=4.0
"cygticw-10.dll" v0.0 ts=2010/1/2 12:28
347k 2011/04/08 C:\cygwin\bin\cygtiff-5.dll - os=4.0 img=1.0 sys=4.0
"cygtiff-5.dll" v0.0 ts=2011/4/7 21:27
9k 2011/04/08 C:\cygwin\bin\cygtiffxx-5.dll - os=4.0 img=1.0 sys=4.0
"cygtiffxx-5.dll" v0.0 ts=2011/4/7 21:27
68k 2010/01/21 C:\cygwin\bin\cygUil-2.dll - os=4.0 img=1.0 sys=4.0
"cygUil-2.dll" v0.0 ts=2010/1/21 2:33
41k 2011/08/16 C:\cygwin\bin\cygusb0.dll - os=4.0 img=1.0 sys=4.0
"cygusb0.dll" v0.0 ts=2011/8/16 14:28
137k 2009/11/16 C:\cygwin\bin\cygustr-1.dll - os=4.0 img=1.0 sys=4.0
"cygustr-1.dll" v0.0 ts=2009/11/16 2:46
16k 2010/06/24 C:\cygwin\bin\cyguuid-1.dll - os=4.0 img=1.0 sys=4.0
"cyguuid-1.dll" v0.0 ts=2010/6/24 15:19
697k 2006/11/05 C:\cygwin\bin\cygWand-10.dll - os=4.0 img=1.0 sys=4.0
"cygWand-10.dll" v0.0 ts=2006/11/5 9:41
2651k 2011/08/08 C:\cygwin\bin\cygwin1-2011-08-08-mybuild.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/8/8 14:40
2614k 2011/06/15 C:\cygwin\bin\cygwin1-20110429.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/4/29 16:14
2619k 2011/06/15 C:\cygwin\bin\cygwin1-20110504.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/5/4 20:57
2628k 2011/06/15 C:\cygwin\bin\cygwin1-20110505.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/5/5 18:35
2634k 2011/05/12 C:\cygwin\bin\cygwin1-20110510.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/5/10 15:12
2643k 2011/06/15 C:\cygwin\bin\cygwin1-20110520.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/5/20 14:59
2649k 2011/06/15 C:\cygwin\bin\cygwin1-20110528.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/5/28 14:22
2652k 2011/06/15 C:\cygwin\bin\cygwin1-20110530.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/5/30 13:11
2653k 2011/06/15 C:\cygwin\bin\cygwin1-20110531.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/5/30 21:35
2652k 2011/06/15 C:\cygwin\bin\cygwin1-20110601.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/5/31 21:53
2655k 2011/06/15 C:\cygwin\bin\cygwin1-20110613.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/6/13 19:54
2646k 2011/06/15 C:\cygwin\bin\cygwin1-20110614.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/6/14 18:05
2646k 2011/06/20 C:\cygwin\bin\cygwin1-20110616.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/6/16 19:05
2648k 2011/07/11 C:\cygwin\bin\cygwin1-20110711.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/7/10 20:08
2651k 2011/08/04 C:\cygwin\bin\cygwin1-20110803.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/8/3 14:12
2654k 2011/08/22 C:\cygwin\bin\cygwin1-20110822.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/8/21 21:28
2682k 2011/09/03 C:\cygwin\bin\cygwin1-20110829.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/8/29 9:58
2663k 2011/10/14 C:\cygwin\bin\cygwin1-20111013.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/10/13 19:37
2694k 2011/10/17 C:\cygwin\bin\cygwin1-20111015.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/10/15 18:42
2700k 2011/10/20 C:\cygwin\bin\cygwin1-20111020.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/10/20 10:35
2711k 2011/10/24 C:\cygwin\bin\cygwin1-20111023.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/10/23 15:07
2713k 2011/11/11 C:\cygwin\bin\cygwin1-20111108.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/11/8 1:31
2744k 2011/12/05 C:\cygwin\bin\cygwin1-20111205.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/12/5 13:02
2604k 2011/03/29 C:\cygwin\bin\cygwin1-prev.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/3/29 4:10
289k 2009/09/15 C:\cygwin\bin\cygwmf-0-2-7.dll - os=4.0 img=1.0 sys=4.0
"cygwmf-0-2-7.dll" v0.0 ts=2009/9/15 8:16
93k 2009/09/15 C:\cygwin\bin\cygwmflite-0-2-7.dll - os=4.0 img=1.0 sys=4.0
"cygwmflite-0-2-7.dll" v0.0 ts=2009/9/15 8:15
28k 2010/03/28 C:\cygwin\bin\cygwrap-0.dll - os=4.0 img=1.0 sys=4.0
"cygwrap-0.dll" v0.0 ts=2010/3/28 5:02
1045k 2011/08/22 C:\cygwin\bin\cygX11-6.dll - os=4.0 img=1.0 sys=4.0
"cygX11-6.dll" v0.0 ts=2011/8/22 4:25
6k 2011/08/22 C:\cygwin\bin\cygX11-xcb-1.dll - os=4.0 img=1.0 sys=4.0
"cygX11-xcb-1.dll" v0.0 ts=2011/8/22 4:26
11k 2010/08/03 C:\cygwin\bin\cygXau-6.dll - os=4.0 img=1.0 sys=4.0
"cygXau-6.dll" v0.0 ts=2010/8/2 20:32
337k 2011/02/04 C:\cygwin\bin\cygXaw-7.dll - os=4.0 img=1.0 sys=4.0
"cygXaw-7.dll" v0.0 ts=2011/2/4 2:02
254k 2010/05/18 C:\cygwin\bin\cygXaw3d-7.dll - os=4.0 img=1.0 sys=4.0
"cygXaw3d-7.dll" v0.0 ts=2010/5/18 18:11
75k 2010/12/21 C:\cygwin\bin\cygxcb-1.dll - os=4.0 img=1.0 sys=4.0
"cygxcb-1.dll" v0.0 ts=2010/12/20 20:36
51k 2010/12/21 C:\cygwin\bin\cygxcb-glx-0.dll - os=4.0 img=1.0 sys=4.0
"cygxcb-glx-0.dll" v0.0 ts=2010/12/20 20:36
22k 2010/12/21 C:\cygwin\bin\cygxcb-render-0.dll - os=4.0 img=1.0 sys=4.0
"cygxcb-render-0.dll" v0.0 ts=2010/12/20 20:36
11k 2011/05/23 C:\cygwin\bin\cygxcb-render-util-0.dll - os=4.0 img=1.0 sys=4.0
"cygxcb-render-util-0.dll" v0.0 ts=2011/5/23 4:25
8k 2010/12/21 C:\cygwin\bin\cygxcb-shm-0.dll - os=4.0 img=1.0 sys=4.0
"cygxcb-shm-0.dll" v0.0 ts=2010/12/20 20:36
10k 2010/11/01 C:\cygwin\bin\cygXcomposite-1.dll - os=4.0 img=1.0 sys=4.0
"cygXcomposite-1.dll" v0.0 ts=2010/10/31 20:59
30k 2011/08/22 C:\cygwin\bin\cygXcursor-1.dll - os=4.0 img=1.0 sys=4.0
"cygXcursor-1.dll" v0.0 ts=2011/8/22 13:26
11k 2010/08/03 C:\cygwin\bin\cygXdamage-1.dll - os=4.0 img=1.0 sys=4.0
"cygXdamage-1.dll" v0.0 ts=2010/8/3 0:25
17k 2010/10/31 C:\cygwin\bin\cygXdmcp-6.dll - os=4.0 img=1.0 sys=4.0
"cygXdmcp-6.dll" v0.0 ts=2010/10/31 15:29
52k 2011/05/23 C:\cygwin\bin\cygXext-6.dll - os=4.0 img=1.0 sys=4.0
"cygXext-6.dll" v0.0 ts=2011/5/23 4:32
17k 2011/03/17 C:\cygwin\bin\cygXfixes-3.dll - os=4.0 img=1.0 sys=4.0
"cygXfixes-3.dll" v0.0 ts=2011/3/16 21:50
66k 2010/11/01 C:\cygwin\bin\cygXft-2.dll - os=4.0 img=1.0 sys=4.0
"cygXft-2.dll" v0.0 ts=2010/10/31 21:10
46k 2011/06/07 C:\cygwin\bin\cygXi-6.dll - os=4.0 img=1.0 sys=4.0
"cygXi-6.dll" v0.0 ts=2011/6/7 0:48
8k 2010/11/01 C:\cygwin\bin\cygXinerama-1.dll - os=4.0 img=1.0 sys=4.0
"cygXinerama-1.dll" v0.0 ts=2010/10/31 21:11
119k 2010/11/01 C:\cygwin\bin\cygxkbfile-1.dll - os=4.0 img=1.0 sys=4.0
"cygxkbfile-1.dll" v0.0 ts=2010/10/31 21:33
1173k 2010/01/21 C:\cygwin\bin\cygXm-2.dll - os=4.0 img=1.0 sys=4.0
"cygXm-2.dll" v0.0 ts=2010/1/21 2:32
1071k 2011/06/07 C:\cygwin\bin\cygxml2-2.dll - os=4.0 img=1.0 sys=4.0
"cygxml2-2.dll" v0.0 ts=2011/6/6 19:12
75k 2010/11/01 C:\cygwin\bin\cygXmu-6.dll - os=4.0 img=1.0 sys=4.0
"cygXmu-6.dll" v0.0 ts=2010/10/31 21:19
11k 2010/11/01 C:\cygwin\bin\cygXmuu-1.dll - os=4.0 img=1.0 sys=4.0
"cygXmuu-1.dll" v0.0 ts=2010/10/31 21:19
53k 2010/11/01 C:\cygwin\bin\cygXpm-4.dll - os=4.0 img=1.0 sys=4.0
"cygXpm-4.dll" v0.0 ts=2010/10/31 21:19
25k 2011/08/22 C:\cygwin\bin\cygXrandr-2.dll - os=4.0 img=1.0 sys=4.0
"cygXrandr-2.dll" v0.0 ts=2011/8/22 12:55
32k 2010/08/03 C:\cygwin\bin\cygXrender-1.dll - os=4.0 img=1.0 sys=4.0
"cygXrender-1.dll" v0.0 ts=2010/8/3 0:48
200k 2010/05/12 C:\cygwin\bin\cygxslt-1.dll - os=4.0 img=1.0 sys=4.0
"cygxslt-1.dll" v0.0 ts=2010/5/12 5:59
278k 2011/06/07 C:\cygwin\bin\cygXt-6.dll - os=4.0 img=1.0 sys=4.0
"cygXt-6.dll" v0.0 ts=2011/6/6 23:40
76k 2010/08/01 C:\cygwin\bin\cygz.dll - os=4.0 img=1.0 sys=4.0
"cygz.dll" v0.0 ts=2010/8/1 17:04
2744k 2011/12/05 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2011/12/5 13:02
Cygwin DLL version info:
DLL version: 1.7.10
DLL epoch: 19
DLL old termios: 5
DLL malloc env: 28
Cygwin conv: 181
API major: 0
API minor: 255
Shared data: 5
DLL identifier: cygwin1
Mount registry: 3
Cygwin registry name: Cygwin
Program options name: Program Options
Installations name: Installations
Cygdrive default prefix:
Build date:
Snapshot date: 20111205-17:58:33
Shared id: cygwin1S5
Service : cygserver
Display name : CYGWIN cygserver
Current State : Running
Controls Accepted : Stop
Command : /usr/sbin/cygserver
stdin path : /dev/null
stdout path : /var/log/cygserver.log
stderr path : /var/log/cygserver.log
Process Type : Own Process
Startup : Automatic
Account : LocalSystem
Service : sshd
Display name : CYGWIN sshd
Current State : Running
Controls Accepted : Stop
Command : /usr/sbin/sshd -D
stdin path : /dev/null
stdout path : /var/log/sshd.log
stderr path : /var/log/sshd.log
Process Type : Own Process
Startup : Automatic
Dependencies : tcpip
Account : .\cyg_server
Service : syslog-ng
Display name : CYGWIN syslog-ng
Current State : Stopped
Command : /usr/sbin/syslog-ng -F
stdin path : /dev/null
stdout path : /var/log/syslog-ng.log
stderr path : /var/log/syslog-ng.log
Process Type : Own Process
Startup : Automatic
Account : LocalSystem
Cygwin Package Information
Last downloaded files to: C:\downloads\cygwin
Last downloaded files from: http://www.math.cornell.edu/~kbrown/
Package Version Status
_update-info-dir 01005-1 OK
alternatives 1.3.30c-10 OK
aspell 0.60.6.1-1 OK
aspell-en 7.1.0-1 OK
autoconf 10-1 OK
autoconf2.1 2.13-10 OK
autoconf2.5 2.68-1 OK
automake 4-10 OK
automake1.10 1.10.3-1 OK
automake1.11 1.11.1-1 OK
automake1.4 1.4p6-10 OK
automake1.5 1.5-10 OK
automake1.6 1.6.3-11 OK
automake1.7 1.7.9-10 OK
automake1.8 1.8.5-10 OK
automake1.9 1.9.6-10 OK
base-cygwin 3.0-1 OK
base-files 4.0-6 OK
bash 4.1.10-4 OK
bc 1.06-2 OK
binutils 2.22.51-1 OK
bison 2.4.2-1 OK
bzip2 1.0.6-2 OK
bzr 2.4.2-1 OK
ca-certificates 1.78-1 OK
cocom 0.996-1 OK
compositeproto 0.4.2-1 OK
coreutils 8.14-1 OK
cpio 2.11-1 OK
crypt 1.1-1 OK
csih 0.9.4-1 OK
cvs 1.12.13-10 OK
cvsps 2.2b1-1 OK
cygport 0.10.6-1 OK
cygrunsrv 1.34-1 OK
cygutils 1.4.6-1 OK
cygwin 1.7.9-1 OK
cygwin-doc 1.7-1 OK
damageproto 1.2.1-1 OK
dash 0.5.7-1 OK
dbus 1.4.16-1 OK
dconf-service 0.10.0-1 OK
diffstat 1.54-1 OK
diffutils 2.9-1 OK
dos2unix 5.3.1-1 OK
ed 1.0-1 OK
editrights 1.01-2 OK
emacs 24.0.92-2 OK
emacs-el 24.0.92-2 OK
emacs-X11 24.0.92-2 OK
file 5.09-1 OK
findutils 4.5.9-2 OK
fixesproto 5.0-1 OK
flex 2.5.35-1 OK
font-adobe-dpi75 1.0.2-1 OK
font-alias 1.0.3-1 OK
font-bitstream-vera-ttf 1.10-1 OK
font-cantarell-otf 0.0.7-1 OK
font-daewoo-misc 1.0.2-1 OK
font-encodings 1.0.4-1 OK
font-isas-misc 1.0.2-1 OK
font-jis-misc 1.0.2-1 OK
font-misc-misc 1.1.1-1 OK
fontconfig 2.8.0-1 OK
gamin 0.1.10-11 OK
gawk 4.0.0-1 OK
gcc-core 3.4.4-999 OK
gcc-g++ 3.4.4-999 OK
gcc-mingw-core 20050522-3 OK
gcc-mingw-g++ 20050522-3 OK
Empty package gcc4
gcc4 4.5.3-3 OK
gcc4-core 4.5.3-3 OK
gcc4-g++ 4.5.3-3 OK
gdb 7.3.50-3 OK
gettext 0.18.1.1-2 OK
gettext-devel 0.18.1.1-2 OK
ghostscript 9.04-1 OK
ghostscript-fonts-other 6.0-1 OK
ghostscript-fonts-std 8.11-1 OK
git 1.7.5.1-1 OK
glproto 1.4.14-1 OK
gmp 4.3.2-1 OK
gnome-icon-theme 3.2.1.2-1 OK
gnupg 1.4.9-2 OK
gnutls-devel 2.12.14-1 OK
grep 2.6.3-1 OK
groff 1.20.1-2 OK
gsettings-desktop-schemas 3.2.0-1 OK
gzip 1.4-1 OK
hicolor-icon-theme 0.12-1 OK
inputproto 2.0.2-1 OK
ipc-utils 1.0-1 OK
jbigkit 2.0-11 OK
kbproto 1.0.5-1 OK
less 444-1 OK
lftp 4.3.3-1 OK
libapr1 1.4.5-1 OK
libaprutil1 1.3.12-1 OK
libaspell15 0.60.6.1-1 OK
libatk1.0-devel 2.2.0-1 OK
libatk1.0_0 2.2.0-1 OK
libattr1 2.4.43-1 OK
libblkid1 2.17.2-1 OK
libbz2-devel 1.0.6-2 OK
libbz2_1 1.0.6-2 OK
libcairo-devel 1.10.2-1 OK
libcairo2 1.10.2-1 OK
libcharset1 1.14-2 OK
libcloog0 0.15.7-1 OK
libcroco0.6-devel 0.6.3-1 OK
libcroco0.6_3 0.6.3-1 OK
libcurl4 7.22.0-2 OK
libdatrie-devel 0.2.4-1 OK
libdatrie1 0.2.4-1 OK
libdb4.5 4.5.20.2-2 OK
libdb4.5-devel 4.5.20.2-2 OK
libdbus1-devel 1.4.16-1 OK
libdbus1_3 1.4.16-1 OK
libedit0 20090923-1 OK
libevtlog0 0.2.12-1 OK
libexpat1 2.0.1-1 OK
libexpat1-devel 2.0.1-1 OK
libfam0 0.1.10-11 OK
libffi4 4.5.3-3 OK
libfontconfig-devel 2.8.0-1 OK
libfontconfig1 2.8.0-1 OK
libfontenc1 1.1.0-1 OK
libfpx 1.3.1-1 OK
libfpx-devel 1.3.1-1 OK
libfpx1 1.3.1-1 OK
libfreetype-devel 2.4.7-1 OK
libfreetype6 2.4.7-1 OK
libgcc1 4.5.3-3 OK
libgcrypt-devel 1.4.6-1 OK
libgcrypt11 1.4.6-1 OK
libgdbm-devel 1.8.3-20 OK
libgdbm4 1.8.3-20 OK
libgdk_pixbuf2.0-devel 2.24.0-1 OK
libgdk_pixbuf2.0_0 2.24.0-1 OK
libgettextpo0 0.18.1.1-2 OK
libgif-devel 4.1.6-10 OK
libgif4 4.1.6-10 OK
libGL-devel 7.10.3-1 OK
libGL1 7.10.3-1 OK
libglib2.0-devel 2.30.2-1 OK
libglib2.0_0 2.30.2-1 OK
libglitz-devel 0.5.6-10 OK
libglitz1 0.5.6-10 OK
libGLU-devel 7.10.3-1 OK
libGLU1 7.10.3-1 OK
libgmp-devel 4.3.2-1 OK
libgmp3 4.3.2-1 OK
libgmpxx4 4.3.2-1 OK
libgnutls26 2.12.14-1 OK
libgomp1 4.5.3-3 OK
libgpg-error-devel 1.10-1 OK
libgpg-error0 1.10-1 OK
libgs8 8.63-2 OK
libgs9 9.04-1 OK
libgsf1-devel 1.14.21-1 OK
libgsf1_114 1.14.21-1 OK
libgtk2.0-devel 2.24.8-1 OK
libgtk2.0_0 2.24.8-1 OK
libgtk3-devel 3.2.2-1 OK
libgtk3_0 3.2.2-1 OK
libICE-devel 1.0.7-1 OK
libICE6 1.0.7-1 OK
libiconv 1.14-2 OK
libiconv2 1.14-2 OK
libidn11 1.22-1 OK
libImageMagick1 6.4.0.6-2 OK
libintl3 0.14.5-1 OK
libintl8 0.18.1.1-2 OK
libjasper-devel 1.900.1-11 OK
libjasper1 1.900.1-11 OK
libjasper1.701_0 1.701.0-3 OK
libjbig-devel 2.0-11 OK
libjbig2 2.0-11 OK
libjpeg-devel 8b-1 OK
libjpeg62 6b-21 OK
libjpeg7 7-10 OK
libjpeg8 8b-1 OK
liblcms-devel 1.19-2 OK
liblcms1 1.19-2 OK
liblcms2_2 2.2-1 OK
libltdl7 2.4-1 OK
liblzma1 4.999.9beta-11 OK
liblzma5 5.0.2_20110517-1 OK
liblzo2-devel 2.06-1 OK
liblzo2_2 2.06-1 OK
libMagick-devel 6.4.0.6-2 OK
libMagick10 6.3.0.1-2 OK
libmpc1 0.8-1 OK
libmpfr1 2.4.1-4 OK
libmpfr4 3.0.1-1 OK
libncurses-devel 5.7-18 OK
libncurses10 5.7-18 OK
libncurses8 5.5-10 OK
libncurses9 5.7-16 OK
libncursesw-devel 5.7-18 OK
libncursesw10 5.7-18 OK
libneon27 0.29.6-1 OK
libnetpbm10 10.56.3-1 OK
libopenldap2_3_0 2.3.43-1 OK
libopenssl098 0.9.8r-2 OK
libpango1.0-devel 1.29.4-1 OK
libpango1.0_0 1.29.4-1 OK
libpaper1 1.1.24-1 OK
libpcre-devel 8.13-1 OK
libpcre0 8.13-1 OK
libpixman1-devel 0.22.2-1 OK
libpixman1_0 0.22.2-1 OK
libpng12 1.2.46-1 OK
libpng12-devel 1.2.46-1 OK
libpng14 1.4.8-1 OK
libpng14-devel 1.4.8-1 OK
libpopt0 1.6.4-4 OK
libppl 0.10.2-1 OK
libpq5 8.2.11-1 OK
libproxy0 0.2.3-2 OK
libproxy1 0.4.7-1 OK
libpthread-stubs 0.2-1 OK
libreadline6 5.2.14-12 OK
libreadline7 6.1.2-2 OK
librsvg2-devel 2.34.2-1 OK
librsvg2_2 2.34.2-1 OK
libsasl2 2.1.23-1 OK
libserf0_1 0.7.1-1 OK
libserf1_0 1.0.0-1 OK
libsigsegv2 2.10-1 OK
libSM-devel 1.2.0-1 OK
libSM6 1.2.0-1 OK
libsqlite3_0 3.7.3-1 OK
libssh2_1 1.2.7-1 OK
libssp0 4.5.3-3 OK
libstdc++6 4.5.3-3 OK
libstdc++6-devel 4.5.3-3 OK
libtasn1-devel 2.10-1 OK
libtasn1_3 2.10-1 OK
libthai-devel 0.1.15-1 OK
libthai0 0.1.15-1 OK
libtiff-devel 3.9.4-1 OK
libtiff5 3.9.4-1 OK
libtool 2.4-1 OK
libusb-win32 1.2.5.0-1 OK
libustr1 1.0.4-11 OK
libuuid-devel 2.17.2-1 OK
libuuid1 2.17.2-1 OK
libwmf-devel 0.2.8.4-10 OK
libwmf027 0.2.8.4-10 OK
libwrap0 7.6-21 OK
libX11-devel 1.4.4-1 OK
libX11-xcb-devel 1.4.4-1 OK
libX11-xcb1 1.4.4-1 OK
libX11_6 1.4.4-1 OK
libXau-devel 1.0.6-1 OK
libXau6 1.0.6-1 OK
libXaw-devel 1.0.9-1 OK
libXaw3d7 1.5D-10 OK
libXaw7 1.0.9-1 OK
libxcb-devel 1.7-2 OK
libxcb-glx-devel 1.7-2 OK
libxcb-glx0 1.7-2 OK
libxcb-render-devel 1.7-2 OK
libxcb-render-util-devel 0.3.8-1 OK
libxcb-render-util0 0.3.8-1 OK
libxcb-render0 1.7-2 OK
libxcb-shm-devel 1.7-2 OK
libxcb-shm0 1.7-2 OK
libxcb1 1.7-2 OK
libXcomposite-devel 0.4.3-1 OK
libXcomposite1 0.4.3-1 OK
libXcursor-devel 1.1.12-1 OK
libXcursor1 1.1.12-1 OK
libXdamage-devel 1.1.3-1 OK
libXdamage1 1.1.3-1 OK
libXdmcp-devel 1.1.0-1 OK
libXdmcp6 1.1.0-1 OK
libXext-devel 1.3.0-1 OK
libXext6 1.3.0-1 OK
libXfixes-devel 5.0-1 OK
libXfixes3 5.0-1 OK
libXft-devel 2.2.0-1 OK
libXft2 2.2.0-1 OK
libXi-devel 1.4.3-1 OK
libXi6 1.4.3-1 OK
libXinerama-devel 1.1.1-1 OK
libXinerama1 1.1.1-1 OK
libxkbfile1 1.0.7-1 OK
libXm2 0.95.2-2 OK
libxml2 2.7.8-2 OK
libxml2-devel 2.7.8-2 OK
libXmu-devel 1.1.0-1 OK
libXmu6 1.1.0-1 OK
libXmuu1 1.1.0-1 OK
libXpm-devel 3.5.9-1 OK
libXpm4 3.5.9-1 OK
libXrandr-devel 1.3.2-1 OK
libXrandr2 1.3.2-1 OK
libXrender-devel 0.9.6-1 OK
libXrender1 0.9.6-1 OK
libxslt 1.1.26-2 OK
libxslt-devel 1.1.26-2 OK
libXt-devel 1.1.1-1 OK
libXt6 1.1.1-1 OK
lndir 1.0.2-1 OK
login 1.10-10 OK
luit 1.1.0-1 OK
m4 1.4.16-1 OK
make 3.82.90-1 OK
man 1.6g-1 OK
mingw-binutils 2.21-1 OK
mingw-bzip2 1.0.6-1 OK
mingw-gcc-core 4.5.2-1 OK
mingw-gcc-g++ 4.5.2-1 OK
mingw-libbz2-devel 1.0.6-1 OK
mingw-libbz2_2 1.0.6-1 OK
mingw-libgcrypt-devel 1.4.6-1 OK
mingw-libgcrypt11 1.4.6-1 OK
mingw-libgpg-error-devel 1.10-1 OK
mingw-libgpg-error0 1.10-1 OK
mingw-liblzma-devel 5.0.2_20110517-1 OK
mingw-liblzma5 5.0.2_20110517-1 OK
mingw-pthreads 20110507-1 OK
mingw-runtime 3.20-1 OK
mingw-w32api 3.17-2 OK
mingw-zlib 1.2.5-6 OK
mingw-zlib-devel 1.2.5-6 OK
mingw-zlib1 1.2.5-6 OK
minires 1.02-1 OK
mintty 1.0.2-1 OK
mkfontdir 1.0.6-1 OK
mkfontscale 1.0.9-1 OK
nasm 2.08.02-1 OK
ncurses 5.7-18 OK
netpbm 10.56.3-1 OK
openssh 5.9p1-1 OK
patch 2.5.8-9 OK
perl 5.14.1-2 OK
perl-Error 0.17016-1 OK
pkg-config 0.23b-10 OK
python 2.6.5-2 OK
python-crypto 2.0.1-2 OK
python-paramiko 1.7.6-2 OK
randrproto 1.3.2-1 OK
readline 6.1.2-2 OK
rebase 4.0.1-1 OK
renderproto 0.11.1-1 OK
rsync 3.0.9-1 OK
run 1.1.13-1 OK
run2 0.4.0-1 OK
sed 4.2.1-1 OK
shared-mime-info 0.90-1 OK
subversion 1.7.1-1 OK
syslog-ng 3.2.1-1 OK
t1lib5 5.1.2-10 OK
tar 1.25-1 OK
tcltk 20080420-1 OK
terminfo 5.7_20091114-14 OK
terminfo0 5.5_20061104-12 OK
texinfo 4.13-4 OK
time 1.7-2 OK
transfig 3.2.5d-1 OK
tzcode 2010j-1 OK
unison2.32 2.32.52-3 OK
unison2.40 2.40.61-2 OK
unzip 6.0-10 OK
util-linux 2.17.2-1 OK
w32api 3.17-2 OK
wget 1.13.4-1 OK
which 2.20-2 OK
xauth 1.0.6-1 OK
xbitmaps 1.1.1-1 OK
xcursor-themes 1.0.3-1 OK
xemacs-emacs-common 21.4.22-1 OK
xextproto 7.2.0-1 OK
xfig 3.2.5b-2 OK
xfig-lib 3.2.5b-2 OK
xineramaproto 1.2.1-1 OK
xinit 1.3.1-1 OK
xkbcomp 1.2.3-1 OK
xkeyboard-config 2.4.1-1 OK
xmodmap 1.0.5-1 OK
xorg-server 1.11.2-1 OK
xpdf 3.02-10 OK
xproto 7.0.22-1 OK
xrdb 1.0.9-1 OK
xterm 276-1 OK
xz 5.0.2_20110517-1 OK
zlib 1.2.5-1 OK
zlib-devel 1.2.5-1 OK
zlib0 1.2.5-1 OK
Use -h to see help about each section
[-- Attachment #3: Type: text/plain, Size: 218 bytes --]
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 13:57 ` Thorsten Kampe
@ 2011-12-06 19:38 ` David Rothenberger
0 siblings, 0 replies; 93+ messages in thread
From: David Rothenberger @ 2011-12-06 19:38 UTC (permalink / raw)
To: cygwin
On 12/6/2011 5:56 AM, Thorsten Kampe wrote:
> * Corinna Vinschen (Tue, 6 Dec 2011 10:37:46 +0100)
>> - Fifos have been rewritten and should now be more reliable.
>
> Trying to run GNU Screen:
> "open fifo /tmp/uscreens/S-thorsten/2756.cons1.hombre: Bad file
> descriptor"
I'm seeing this as well on Windows XP SP3. It starts with the 2011-12-04
snapshot; no problems with 2011-12-03.
--
David Rothenberger ---- daveroth@acm.org
heavy, adj.:
Seduced by the chocolate side of the force.
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 18:29 ` Ken Brown
@ 2011-12-06 20:03 ` Corinna Vinschen
2011-12-07 2:51 ` Ken Brown
0 siblings, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-06 20:03 UTC (permalink / raw)
To: cygwin
On Dec 6 13:28, Ken Brown wrote:
> On 12/6/2011 12:57 PM, Corinna Vinschen wrote:
> >On Dec 6 12:37, Ken Brown wrote:
> >>On 12/6/2011 4:37 AM, Corinna Vinschen wrote:
> >>>A lot of changes and fixes have been made in Cygwin since 1.7.9 has
> >>>been released, so we're looking forward to release Cygwin 1.7.10 soon.
> >>>
> >>>Please test the latest developer snapshots at http://cygwin.com/snapshots/
> >>>which should have "Release Candidate" quality.
> >>
> >>Here's an easily reproducible problem with the 2011-12-05
> >>cygwin1.dll snapshot:
> >>
> >>1. Download cygwin-inst-20111205.tar.bz2 .
> >>
> >>2. Start mintty from the Cygwin Terminal shortcut.
> >>
> >>3. tar -C/ -xf /path/to/cygwin-inst-20111205.tar.bz2
> >>--exclude=usr/bin/cygwin1.dll
> >>
> >>An hourglass appears and tar doesn't run. I'm on W7-64 if that
> >>makes a difference.
> >
> >Works for me. I just tried from mintty with bash as login shell as
> >well as with tcsh as login shell. I even left out the --exclude and
> >it worked ;)
> >
> >Does that really occur reproducible on your machine, every try?
>
> Yes. And I just tried twice more with the same behavior. Earlier
> today I had a similar thing occur on a different machine, on which
> the 2011-12-04 dll was installed instead of the 2011-12-05 dll. On
> that machine (again W7-64), the mintty window simply disappeared
> when I gave the tar command.
Hmm, that's weird.
> The only other detail I can think of is that I started mintty by
> right-clicking on the shortcut and choosing "Run as administrator".
Still works for me. That's puzzeling. Any chance to debug that?
Stracing, attaching with GDB, building your own debug-enabled Cygwin,
etc?
> I'm attaching cygcheck.out in case it helps you spot some difference
> between my environment and yours. I do see something strange in it:
>
> Cygwin installations found in the registry:
> System: Key: c5e39b7a9d22bafb Path: C:\cygwin
> System: Key: 2707db8e4ba5ae4f Path: C:\cygwin-a
> User: Key: c5e39b7a9d22bafb Path: C:\cygwin
> User: Key: 2707db8e4ba5ae4f Path: C:\cygwin-a
>
> I do have two Cygwin installations, but I don't know why they're
> each showing up twice, once as "System:" and once as "User:". I
> just looked at an old cygcheck output from last March, and only the
> "System:" entries are there.
In theory, if you're running your machine with an admin account under
UAC, you should practically always have an entry in HKCU as well as in
HKLM. One of them when running restricted (the default), one of them
when running with "Run as administrator".
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 15:31 ` Corinna Vinschen
@ 2011-12-06 20:18 ` Lars Bjørndal
2011-12-06 21:10 ` Samuel Thibault
2011-12-07 9:23 ` Lars Bjørndal
1 sibling, 1 reply; 93+ messages in thread
From: Lars Bjørndal @ 2011-12-06 20:18 UTC (permalink / raw)
To: cygwin; +Cc: samuel.thibault
[Corinna]
> On Dec 6 16:27, Corinna Vinschen wrote:
> > On Dec 6 16:21, Lars Bjørndal wrote:
> > > Hi
> > >
> > > Sorry, but now, with this new snapshot, BRLTTY doesn't work. I'm not
> > > sure how to figure out which snapshot I'm currently using, where the
> > > program does work.
> >
> > Uname -a. The build date will show.
>
> Btw., "brltty doesn't work" is a bit low on detail. It would also be
> helpful if you could find out with which snapshot brltty starts to
> misbehave.
I'll try when back in business. BRLTTY didn't start up. I only got the
initial startpu message from BRLTTY on the braille display. After
that, I was not able to read anything. Something under /dev is
changed, maybe that's the problem?
Copied Samuel from the BRLTTY team, maybe he knows anything more.
Regards,
Lars
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 20:18 ` Lars Bjørndal
@ 2011-12-06 21:10 ` Samuel Thibault
2011-12-06 22:01 ` Lars Bjørndal
0 siblings, 1 reply; 93+ messages in thread
From: Samuel Thibault @ 2011-12-06 21:10 UTC (permalink / raw)
To: Lars Bjørndal; +Cc: cygwin
Lars Bjørndal, le Tue 06 Dec 2011 21:17:37 +0100, a écrit :
> [Corinna]
> > On Dec 6 16:27, Corinna Vinschen wrote:
> > > On Dec 6 16:21, Lars Bjørndal wrote:
> > > > Hi
> > > >
> > > > Sorry, but now, with this new snapshot, BRLTTY doesn't work. I'm not
> > > > sure how to figure out which snapshot I'm currently using, where the
> > > > program does work.
> > >
> > > Uname -a. The build date will show.
> >
> > Btw., "brltty doesn't work" is a bit low on detail. It would also be
> > helpful if you could find out with which snapshot brltty starts to
> > misbehave.
>
> I'll try when back in business. BRLTTY didn't start up. I only got the
> initial startpu message from BRLTTY on the braille display. After
> that, I was not able to read anything.
Please try with a windows console. Iirc cygwin switched to rxvt or
something not windows-native. Brltty can't read that, only standard
windows consoles.
Samuel
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 21:10 ` Samuel Thibault
@ 2011-12-06 22:01 ` Lars Bjørndal
2011-12-06 22:25 ` Tim McDaniel
0 siblings, 1 reply; 93+ messages in thread
From: Lars Bjørndal @ 2011-12-06 22:01 UTC (permalink / raw)
To: cygwin
[Samuel]
> Lars Bjørndal, le Tue 06 Dec 2011 21:17:37 +0100, a écrit :
> > [Corinna]
> > > On Dec 6 16:27, Corinna Vinschen wrote:
> > > > On Dec 6 16:21, Lars Bjørndal wrote:
> > > > > Hi
> > > > >
> > > > > Sorry, but now, with this new snapshot, BRLTTY doesn't work. I'm not
> > > > > sure how to figure out which snapshot I'm currently using, where the
> > > > > program does work.
> > > >
> > > > Uname -a. The build date will show.
> > >
> > > Btw., "brltty doesn't work" is a bit low on detail. It would also be
> > > helpful if you could find out with which snapshot brltty starts to
> > > misbehave.
> >
> > I'll try when back in business. BRLTTY didn't start up. I only got the
> > initial startpu message from BRLTTY on the braille display. After
> > that, I was not able to read anything.
>
> Please try with a windows console.
I always start cygwin from the command line, after starting cmd.exe.
> Iirc cygwin switched to rxvt or
> something not windows-native. Brltty can't read that, only standard
> windows consoles.
What doew Iirc mean?
Regards,
Lars
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 22:01 ` Lars Bjørndal
@ 2011-12-06 22:25 ` Tim McDaniel
2011-12-07 21:50 ` Andrey Repin
0 siblings, 1 reply; 93+ messages in thread
From: Tim McDaniel @ 2011-12-06 22:25 UTC (permalink / raw)
Cc: cygwin
On Tue, 6 Dec 2011, Lars Bj_rndal wrote:
> What doew Iirc mean?
http://www.acronymfinder.com/ is often useful, but in this case, it
produces a lot of useless crud.
http://www.urbandictionary.com/define.php?term=iirc is often of more
use.
If I Recall Correctly.
--
Tim McDaniel, tmcd@panix.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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 20:03 ` Corinna Vinschen
@ 2011-12-07 2:51 ` Ken Brown
2011-12-07 3:22 ` Christopher Faylor
0 siblings, 1 reply; 93+ messages in thread
From: Ken Brown @ 2011-12-07 2:51 UTC (permalink / raw)
To: cygwin
On 12/6/2011 3:02 PM, Corinna Vinschen wrote:
> On Dec 6 13:28, Ken Brown wrote:
>> On 12/6/2011 12:57 PM, Corinna Vinschen wrote:
>>> On Dec 6 12:37, Ken Brown wrote:
>>>> On 12/6/2011 4:37 AM, Corinna Vinschen wrote:
>>>>> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
>>>>> been released, so we're looking forward to release Cygwin 1.7.10 soon.
>>>>>
>>>>> Please test the latest developer snapshots at http://cygwin.com/snapshots/
>>>>> which should have "Release Candidate" quality.
>>>>
>>>> Here's an easily reproducible problem with the 2011-12-05
>>>> cygwin1.dll snapshot:
>>>>
>>>> 1. Download cygwin-inst-20111205.tar.bz2 .
>>>>
>>>> 2. Start mintty from the Cygwin Terminal shortcut.
>>>>
>>>> 3. tar -C/ -xf /path/to/cygwin-inst-20111205.tar.bz2
>>>> --exclude=usr/bin/cygwin1.dll
>>>>
>>>> An hourglass appears and tar doesn't run. I'm on W7-64 if that
>>>> makes a difference.
>>>
>>> Works for me. I just tried from mintty with bash as login shell as
>>> well as with tcsh as login shell. I even left out the --exclude and
>>> it worked ;)
>>>
>>> Does that really occur reproducible on your machine, every try?
>>
>> Yes. And I just tried twice more with the same behavior. Earlier
>> today I had a similar thing occur on a different machine, on which
>> the 2011-12-04 dll was installed instead of the 2011-12-05 dll. On
>> that machine (again W7-64), the mintty window simply disappeared
>> when I gave the tar command.
>
> Hmm, that's weird.
>
>> The only other detail I can think of is that I started mintty by
>> right-clicking on the shortcut and choosing "Run as administrator".
>
> Still works for me. That's puzzeling. Any chance to debug that?
> Stracing, attaching with GDB, building your own debug-enabled Cygwin,
> etc?
I ran the tar command under strace. I'm not good at deciphering strace
output, but you can see it here:
http://www.math.cornell.edu/~kbrown/cygwin/strace.out
A few further observations:
- As the strace output shows, tar does in fact run, contrary to what I
originally thought; it's just that there's no indication in the terminal
that tar finished.
- When I finally get tired of waiting and kill mintty (and the
associated bash process) from another terminal, mintty leaves the
following stackdump on the desktop:
Exception: STATUS_ACCESS_VIOLATION at eip=610CD8B1
eax=0000010C ebx=0028C880 ecx=00000000 edx=0000010C esi=00000000
edi=0028C860
ebp=0028C7C8 esp=0028C790 program=C:\cygwin\bin\mintty.exe, pid 4972,
thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
0028C7C8 610CD8B1 (0000010C, 0028C95C, 0028C880, 0028C860)
0028C938 610CDC42 (00000002, 0028C95C, 00000000, 00000000)
20052168 610D1FE5 (00630072, 00000000, 00000018, 00000033)
200524F0 00000000 (6E776F72, 6D64612D, 2E2F6E69, 746E696D)
End of stack trace
- Other mintty windows that are open become unusable. The title bar
shows "not responding".
Does any of this help? Should I be stracing mintty rather than tar?
Ken
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 17:46 ` Corinna Vinschen
@ 2011-12-07 3:08 ` Christopher Faylor
2011-12-07 7:56 ` marco atzeri
2011-12-07 10:34 ` Yaakov (Cygwin/X)
0 siblings, 2 replies; 93+ messages in thread
From: Christopher Faylor @ 2011-12-07 3:08 UTC (permalink / raw)
To: cygwin
On Tue, Dec 06, 2011 at 06:45:35PM +0100, Corinna Vinschen wrote:
>On Dec 6 15:39, marco atzeri wrote:
>> On 12/6/2011 10:37 AM, Corinna Vinschen wrote:
>> >A lot of changes and fixes have been made in Cygwin since 1.7.9 has
>> >been released, so we're looking forward to release Cygwin 1.7.10 soon.
>> >[...]
>>
>> Hi Corinna,
>> I have the impression that 20111124 is working better than 20111129,
>> and that 20111204 and 05 have some additional problems.
>>
>> On 20111129, building atlas on W7/x64 I see the custom config
>> spinning and never ending, while on 20111124 is goes smooth.
>
>I can't say a lot about the FIFO stuff, but as far as these weird hangs,
>busy or not busy, are concerned, they were one of the problems we
>tackled in the last couple of days.
The FIFO problem will be fixed in the next snapshot.
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 2:51 ` Ken Brown
@ 2011-12-07 3:22 ` Christopher Faylor
2011-12-07 13:03 ` Ken Brown
0 siblings, 1 reply; 93+ messages in thread
From: Christopher Faylor @ 2011-12-07 3:22 UTC (permalink / raw)
To: cygwin
On Tue, Dec 06, 2011 at 09:51:32PM -0500, Ken Brown wrote:
>On 12/6/2011 3:02 PM, Corinna Vinschen wrote:
>> On Dec 6 13:28, Ken Brown wrote:
>>> On 12/6/2011 12:57 PM, Corinna Vinschen wrote:
>>>> On Dec 6 12:37, Ken Brown wrote:
>>>>> On 12/6/2011 4:37 AM, Corinna Vinschen wrote:
>>>>>> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
>>>>>> been released, so we're looking forward to release Cygwin 1.7.10 soon.
>>>>>>
>>>>>> Please test the latest developer snapshots at http://cygwin.com/snapshots/
>>>>>> which should have "Release Candidate" quality.
>>>>>
>>>>> Here's an easily reproducible problem with the 2011-12-05
>>>>> cygwin1.dll snapshot:
>>>>>
>>>>> 1. Download cygwin-inst-20111205.tar.bz2 .
>>>>>
>>>>> 2. Start mintty from the Cygwin Terminal shortcut.
>>>>>
>>>>> 3. tar -C/ -xf /path/to/cygwin-inst-20111205.tar.bz2
>>>>> --exclude=usr/bin/cygwin1.dll
>>>>>
>>>>> An hourglass appears and tar doesn't run. I'm on W7-64 if that
>>>>> makes a difference.
>>>>
>>>> Works for me. I just tried from mintty with bash as login shell as
>>>> well as with tcsh as login shell. I even left out the --exclude and
>>>> it worked ;)
>>>>
>>>> Does that really occur reproducible on your machine, every try?
>>>
>>> Yes. And I just tried twice more with the same behavior. Earlier
>>> today I had a similar thing occur on a different machine, on which
>>> the 2011-12-04 dll was installed instead of the 2011-12-05 dll. On
>>> that machine (again W7-64), the mintty window simply disappeared
>>> when I gave the tar command.
>>
>> Hmm, that's weird.
>>
>>> The only other detail I can think of is that I started mintty by
>>> right-clicking on the shortcut and choosing "Run as administrator".
>>
>> Still works for me. That's puzzeling. Any chance to debug that?
>> Stracing, attaching with GDB, building your own debug-enabled Cygwin,
>> etc?
>
>I ran the tar command under strace. I'm not good at deciphering strace
>output, but you can see it here:
>
> http://www.math.cornell.edu/~kbrown/cygwin/strace.out
>
>A few further observations:
>
>- As the strace output shows, tar does in fact run, contrary to what I
>originally thought; it's just that there's no indication in the terminal
>that tar finished.
>
>- When I finally get tired of waiting and kill mintty (and the
>associated bash process) from another terminal, mintty leaves the
>following stackdump on the desktop:
>
>Exception: STATUS_ACCESS_VIOLATION at eip=610CD8B1
>eax=0000010C ebx=0028C880 ecx=00000000 edx=0000010C esi=00000000
>edi=0028C860
>ebp=0028C7C8 esp=0028C790 program=C:\cygwin\bin\mintty.exe, pid 4972,
>thread main
>cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>Stack trace:
>Frame Function Args
>0028C7C8 610CD8B1 (0000010C, 0028C95C, 0028C880, 0028C860)
>0028C938 610CDC42 (00000002, 0028C95C, 00000000, 00000000)
>20052168 610D1FE5 (00630072, 00000000, 00000018, 00000033)
>200524F0 00000000 (6E776F72, 6D64612D, 2E2F6E69, 746E696D)
>End of stack trace
>
>- Other mintty windows that are open become unusable. The title bar
>shows "not responding".
>
>Does any of this help? Should I be stracing mintty rather than tar?
Apparently yes. I can't reproduce this either. The strace you provided
does look perfectly normal.
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 3:08 ` Christopher Faylor
@ 2011-12-07 7:56 ` marco atzeri
2011-12-09 6:14 ` marco atzeri
2011-12-07 10:34 ` Yaakov (Cygwin/X)
1 sibling, 1 reply; 93+ messages in thread
From: marco atzeri @ 2011-12-07 7:56 UTC (permalink / raw)
To: cygwin
On 12/7/2011 4:08 AM, Christopher Faylor wrote:
>>> I have the impression that 20111124 is working better than 20111129,
>>> and that 20111204 and 05 have some additional problems.
>>>
>>> On 20111129, building atlas on W7/x64 I see the custom config
>>> spinning and never ending, while on 20111124 is goes smooth.
>>
>> I can't say a lot about the FIFO stuff, but as far as these weird hangs,
>> busy or not busy, are concerned, they were one of the problems we
>> tackled in the last couple of days.
>
> The FIFO problem will be fixed in the next snapshot.
>
> cgf
Confirmed.
20111207 is forking as expected and no more strange fifo message.
For the spinning problem I put the test case here:
http://matzeri.altervista.org/works/test_case/prova2.tar.bz2
running ./system_test.sh
some of the tests should dump and return.
++ ./xprobe_3dnow.exe
./system_test.sh: line 14: 3256 Illegal instruction (core dumped)
./xprobe_3dnow.exe
on 20111124 that works, while from 20111129 to 20111207 the
programs never return and stay frozen.
At least on my CYGWIN_NT-6.1-WOW64
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz
stepping : 5
cpu MHz : 2394
cache size : 256 KB
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2
popcnt aes lahf_lm
TLB size : 0 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 15:31 ` Corinna Vinschen
2011-12-06 20:18 ` Lars Bjørndal
@ 2011-12-07 9:23 ` Lars Bjørndal
2011-12-07 11:46 ` Corinna Vinschen
1 sibling, 1 reply; 93+ messages in thread
From: Lars Bjørndal @ 2011-12-07 9:23 UTC (permalink / raw)
To: cygwin
[Corinna]
[...]
> Btw., "brltty doesn't work" is a bit low on detail. It would also be
> helpful if you could find out with which snapshot brltty starts to
> misbehave.
At 20111022. Now, I'm using the dll from 20111021, and it works.
Regards,
Lars
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 3:08 ` Christopher Faylor
2011-12-07 7:56 ` marco atzeri
@ 2011-12-07 10:34 ` Yaakov (Cygwin/X)
2011-12-07 11:19 ` Corinna Vinschen
1 sibling, 1 reply; 93+ messages in thread
From: Yaakov (Cygwin/X) @ 2011-12-07 10:34 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]
On Tue, 2011-12-06 at 22:08 -0500, Christopher Faylor wrote:
> On Tue, Dec 06, 2011 at 06:45:35PM +0100, Corinna Vinschen wrote:
> >On Dec 6 15:39, marco atzeri wrote:
> >> On 12/6/2011 10:37 AM, Corinna Vinschen wrote:
> >> >A lot of changes and fixes have been made in Cygwin since 1.7.9 has
> >> >been released, so we're looking forward to release Cygwin 1.7.10 soon.
> >> >[...]
> >>
> >> Hi Corinna,
> >> I have the impression that 20111124 is working better than 20111129,
> >> and that 20111204 and 05 have some additional problems.
> >>
> >> On 20111129, building atlas on W7/x64 I see the custom config
> >> spinning and never ending, while on 20111124 is goes smooth.
> >
> >I can't say a lot about the FIFO stuff, but as far as these weird hangs,
> >busy or not busy, are concerned, they were one of the problems we
> >tackled in the last couple of days.
>
> The FIFO problem will be fixed in the next snapshot.
Are you sure? I'm now unable to build any KDE4 packages due to a "hang"
in automoc4[1]. strace attached.
Yaakov
[1] http://quickgit.kde.org/?p=automoc.git&a=blob&h=ae2cff40a77979a62c76e05c57b1cd4eed709605&hb=afddb64aa0d6272cbae52fb8d8fa9355a0350e21&f=kde4automoc.cpp
[-- Attachment #2: automoc4.strace.xz --]
[-- Type: application/x-xz, Size: 19008 bytes --]
[-- Attachment #3: Type: text/plain, Size: 218 bytes --]
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 10:34 ` Yaakov (Cygwin/X)
@ 2011-12-07 11:19 ` Corinna Vinschen
2011-12-09 6:19 ` Yaakov (Cygwin/X)
0 siblings, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-07 11:19 UTC (permalink / raw)
To: cygwin
On Dec 7 04:33, Yaakov (Cygwin/X) wrote:
> On Tue, 2011-12-06 at 22:08 -0500, Christopher Faylor wrote:
> > On Tue, Dec 06, 2011 at 06:45:35PM +0100, Corinna Vinschen wrote:
> > >On Dec 6 15:39, marco atzeri wrote:
> > >> On 12/6/2011 10:37 AM, Corinna Vinschen wrote:
> > >> >A lot of changes and fixes have been made in Cygwin since 1.7.9 has
> > >> >been released, so we're looking forward to release Cygwin 1.7.10 soon.
> > >> >[...]
> > >>
> > >> Hi Corinna,
> > >> I have the impression that 20111124 is working better than 20111129,
> > >> and that 20111204 and 05 have some additional problems.
> > >>
> > >> On 20111129, building atlas on W7/x64 I see the custom config
> > >> spinning and never ending, while on 20111124 is goes smooth.
> > >
> > >I can't say a lot about the FIFO stuff, but as far as these weird hangs,
> > >busy or not busy, are concerned, they were one of the problems we
> > >tackled in the last couple of days.
> >
> > The FIFO problem will be fixed in the next snapshot.
>
> Are you sure? I'm now unable to build any KDE4 packages due to a "hang"
> in automoc4[1]. strace attached.
And it worked with the previous snapshot? I don't see automoc4 using
fifos in the strace.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 9:23 ` Lars Bjørndal
@ 2011-12-07 11:46 ` Corinna Vinschen
2011-12-07 12:40 ` Lars Bjørndal
0 siblings, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-07 11:46 UTC (permalink / raw)
To: cygwin
On Dec 7 10:23, Lars Bjørndal wrote:
> [Corinna]
> [...]
>
> > Btw., "brltty doesn't work" is a bit low on detail. It would also be
> > helpful if you could find out with which snapshot brltty starts to
> > misbehave.
>
> At 20111022. Now, I'm using the dll from 20111021, and it works.
Thanks!
Are you using Windows 7 by any chance? If so, I have a hunch what the
problem is. Can I send you the URL to a test DLL by private email?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 11:46 ` Corinna Vinschen
@ 2011-12-07 12:40 ` Lars Bjørndal
2011-12-07 15:47 ` Lars Bjørndal
0 siblings, 1 reply; 93+ messages in thread
From: Lars Bjørndal @ 2011-12-07 12:40 UTC (permalink / raw)
To: cygwin
[Corinna]
> On Dec 7 10:23, Lars Bjørndal wrote:
> > [Corinna]
> > [...]
> >
> > > Btw., "brltty doesn't work" is a bit low on detail. It would also be
> > > helpful if you could find out with which snapshot brltty starts to
> > > misbehave.
> >
> > At 20111022. Now, I'm using the dll from 20111021, and it works.
>
> Thanks!
>
> Are you using Windows 7 by any chance? If so, I have a hunch what the
> problem is.
Yes - 64bit version.
> Can I send you the URL to a test DLL by private email?
Sure.
Lars
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 3:22 ` Christopher Faylor
@ 2011-12-07 13:03 ` Ken Brown
2011-12-07 16:55 ` Thomas Wolff
` (2 more replies)
0 siblings, 3 replies; 93+ messages in thread
From: Ken Brown @ 2011-12-07 13:03 UTC (permalink / raw)
To: cygwin
On 12/6/2011 10:22 PM, Christopher Faylor wrote:
> On Tue, Dec 06, 2011 at 09:51:32PM -0500, Ken Brown wrote:
>> On 12/6/2011 3:02 PM, Corinna Vinschen wrote:
>>> On Dec 6 13:28, Ken Brown wrote:
>>>> On 12/6/2011 12:57 PM, Corinna Vinschen wrote:
>>>>> On Dec 6 12:37, Ken Brown wrote:
>>>>>> On 12/6/2011 4:37 AM, Corinna Vinschen wrote:
>>>>>>> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
>>>>>>> been released, so we're looking forward to release Cygwin 1.7.10 soon.
>>>>>>>
>>>>>>> Please test the latest developer snapshots at http://cygwin.com/snapshots/
>>>>>>> which should have "Release Candidate" quality.
>>>>>>
>>>>>> Here's an easily reproducible problem with the 2011-12-05
>>>>>> cygwin1.dll snapshot:
>>>>>>
>>>>>> 1. Download cygwin-inst-20111205.tar.bz2 .
>>>>>>
>>>>>> 2. Start mintty from the Cygwin Terminal shortcut.
>>>>>>
>>>>>> 3. tar -C/ -xf /path/to/cygwin-inst-20111205.tar.bz2
>>>>>> --exclude=usr/bin/cygwin1.dll
>>>>>>
>>>>>> An hourglass appears and tar doesn't run. I'm on W7-64 if that
>>>>>> makes a difference.
>>>>>
>>>>> Works for me. I just tried from mintty with bash as login shell as
>>>>> well as with tcsh as login shell. I even left out the --exclude and
>>>>> it worked ;)
>>>>>
>>>>> Does that really occur reproducible on your machine, every try?
>>>>
>>>> Yes. And I just tried twice more with the same behavior. Earlier
>>>> today I had a similar thing occur on a different machine, on which
>>>> the 2011-12-04 dll was installed instead of the 2011-12-05 dll. On
>>>> that machine (again W7-64), the mintty window simply disappeared
>>>> when I gave the tar command.
>>>
>>> Hmm, that's weird.
>>>
>>>> The only other detail I can think of is that I started mintty by
>>>> right-clicking on the shortcut and choosing "Run as administrator".
>>>
>>> Still works for me. That's puzzeling. Any chance to debug that?
>>> Stracing, attaching with GDB, building your own debug-enabled Cygwin,
>>> etc?
>>
>> I ran the tar command under strace. I'm not good at deciphering strace
>> output, but you can see it here:
>>
>> http://www.math.cornell.edu/~kbrown/cygwin/strace.out
>>
>> A few further observations:
>>
>> - As the strace output shows, tar does in fact run, contrary to what I
>> originally thought; it's just that there's no indication in the terminal
>> that tar finished.
>>
>> - When I finally get tired of waiting and kill mintty (and the
>> associated bash process) from another terminal, mintty leaves the
>> following stackdump on the desktop:
>>
>> Exception: STATUS_ACCESS_VIOLATION at eip=610CD8B1
>> eax=0000010C ebx=0028C880 ecx=00000000 edx=0000010C esi=00000000
>> edi=0028C860
>> ebp=0028C7C8 esp=0028C790 program=C:\cygwin\bin\mintty.exe, pid 4972,
>> thread main
>> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>> Stack trace:
>> Frame Function Args
>> 0028C7C8 610CD8B1 (0000010C, 0028C95C, 0028C880, 0028C860)
>> 0028C938 610CDC42 (00000002, 0028C95C, 00000000, 00000000)
>> 20052168 610D1FE5 (00630072, 00000000, 00000018, 00000033)
>> 200524F0 00000000 (6E776F72, 6D64612D, 2E2F6E69, 746E696D)
>> End of stack trace
>>
>> - Other mintty windows that are open become unusable. The title bar
>> shows "not responding".
>>
>> Does any of this help? Should I be stracing mintty rather than tar?
>
> Apparently yes. I can't reproduce this either. The strace you provided
> does look perfectly normal.
OK. I started mintty from the Cygwin Terminal shortcut, attached strace
to it in a second terminal, and ran the tar command in the first
terminal. The strace output is at
http://www.math.cornell.edu/~kbrown/cygwin/strace_mintty.out
Here's one more data point: The problem occurs only in a mintty started
from the shortcut. If I start mintty from an existing mintty, I can run
the tar command without a problem.
Ken
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 12:40 ` Lars Bjørndal
@ 2011-12-07 15:47 ` Lars Bjørndal
2011-12-08 8:48 ` Corinna Vinschen
0 siblings, 1 reply; 93+ messages in thread
From: Lars Bjørndal @ 2011-12-07 15:47 UTC (permalink / raw)
To: cygwin
On on., des. 07, 2011 at 01:40:25 +0100, Lars Bjørndal wrote:
> [Corinna]
> > On Dec 7 10:23, Lars Bjørndal wrote:
> > > [Corinna]
> > > [...]
> > >
> > > > Btw., "brltty doesn't work" is a bit low on detail. It would also be
> > > > helpful if you could find out with which snapshot brltty starts to
> > > > misbehave.
> > >
> > > At 20111022. Now, I'm using the dll from 20111021, and it works.
> >
> > Thanks!
> >
> > Are you using Windows 7 by any chance? If so, I have a hunch what the
> > problem is.
>
> Yes - 64bit version.
>
> > Can I send you the URL to a test DLL by private email?
>
> Sure.
I tried the patch you provided, but with no better result - sorry.
Lars
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 13:03 ` Ken Brown
@ 2011-12-07 16:55 ` Thomas Wolff
2011-12-07 17:07 ` Dima Pasechnik
2011-12-07 23:13 ` Christopher Faylor
2 siblings, 0 replies; 93+ messages in thread
From: Thomas Wolff @ 2011-12-07 16:55 UTC (permalink / raw)
To: cygwin
Am 07.12.2011 14:03, schrieb Ken Brown:
> On 12/6/2011 10:22 PM, Christopher Faylor wrote:
>> On Tue, Dec 06, 2011 at 09:51:32PM -0500, Ken Brown wrote:
>>> On 12/6/2011 3:02 PM, Corinna Vinschen wrote:
>>>> ...
>>> ...
>>> - When I finally get tired of waiting and kill mintty (and the
>>> associated bash process) from another terminal, mintty leaves the
>>> following stackdump on the desktop:
As a side note, I don't think applications should leave log files, stack
dumps etc on the desktop. The same applies to setup.exe (if started from
the desktop, where many people tend to place their downloads).
Maybe the Cygwin Terminal shortcut should get a working directory added
(currently it has none), e.g. the cygwin /tmp directory, to prevent this.
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 10:00 [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10 Corinna Vinschen
` (4 preceding siblings ...)
2011-12-06 17:38 ` Ken Brown
@ 2011-12-07 17:00 ` Bengt Larsson
2011-12-07 17:38 ` Corinna Vinschen
2011-12-07 23:18 ` Yaakov (Cygwin/X)
` (3 subsequent siblings)
9 siblings, 1 reply; 93+ messages in thread
From: Bengt Larsson @ 2011-12-07 17:00 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]
Corinna Vinschen wrote:
>- cygwin_conv_path and cygwin_conv_path_list: In CCP_WIN_A_TO_POSIX and
> CCP_POSIX_TO_WIN_A conversions, use the current Windows ANSI or OEM
> charset, depending on the return value of AreFileApisANSI. Up to Cygwin
> 1.7.9, both conversions used the current Cygwin charset for the conversion.
Is that the right thing to do? I have LANG=C.UTF-8. If I pass a
Windows-style filename on the command line, it's passed as UTF-8. How do
I then convert that to Unix-style, UTF-8?
Example program attached. Run with for example "testpath åäö.txt" and
"testpath 'C:\WINDOWS\åäö.txt'"
I tried with the snapshot DLL (not any other files) from 20111207 and
got garbage (double-encoded UTF-8).
[-- Attachment #2: testpath.c --]
[-- Type: application/octet-stream, Size: 331 bytes --]
#include <sys/cygwin.h>
#include <limits.h>
#include <stdio.h>
int
main(int argc, char *argv[])
{
char out[PATH_MAX];
if (argc > 1) {
if (cygwin_conv_path(CCP_WIN_A_TO_POSIX | CCP_RELATIVE, argv[1], out, PATH_MAX)) {
perror("Error in cygwin_conv_path");
return 1;
}
printf("out = %s\n", out);
}
return 0;
}
[-- Attachment #3: Type: text/plain, Size: 218 bytes --]
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 13:03 ` Ken Brown
2011-12-07 16:55 ` Thomas Wolff
@ 2011-12-07 17:07 ` Dima Pasechnik
2011-12-07 23:13 ` Christopher Faylor
2 siblings, 0 replies; 93+ messages in thread
From: Dima Pasechnik @ 2011-12-07 17:07 UTC (permalink / raw)
To: cygwin; +Cc: Ken Brown
On 7 December 2011 21:03, Ken Brown <kbrown@cornell.edu> wrote:
> On 12/6/2011 10:22 PM, Christopher Faylor wrote:
>>
>> On Tue, Dec 06, 2011 at 09:51:32PM -0500, Ken Brown wrote:
>>>
>>> On 12/6/2011 3:02 PM, Corinna Vinschen wrote:
>>>>
>>>> On Dec 6 13:28, Ken Brown wrote:
>>>>>
>>>>> On 12/6/2011 12:57 PM, Corinna Vinschen wrote:
>>>>>>
>>>>>> On Dec 6 12:37, Ken Brown wrote:
>>>>>>>
>>>>>>> On 12/6/2011 4:37 AM, Corinna Vinschen wrote:
>>>>>>>>
>>>>>>>> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
>>>>>>>> been released, so we're looking forward to release Cygwin 1.7.10
>>>>>>>> soon.
>>>>>>>>
>>>>>>>> Please test the latest developer snapshots at
>>>>>>>> http://cygwin.com/snapshots/
>>>>>>>> which should have "Release Candidate" quality.
>>>>>>>
>>>>>>>
>>>>>>> Here's an easily reproducible problem with the 2011-12-05
>>>>>>> cygwin1.dll snapshot:
>>>>>>>
>>>>>>> 1. Download cygwin-inst-20111205.tar.bz2 .
>>>>>>>
>>>>>>> 2. Start mintty from the Cygwin Terminal shortcut.
>>>>>>>
>>>>>>> 3. tar -C/ -xf /path/to/cygwin-inst-20111205.tar.bz2
>>>>>>> --exclude=usr/bin/cygwin1.dll
>>>>>>>
>>>>>>> An hourglass appears and tar doesn't run. I'm on W7-64 if that
>>>>>>> makes a difference.
>>>>>>
>>>>>>
>>>>>> Works for me. I just tried from mintty with bash as login shell as
>>>>>> well as with tcsh as login shell. I even left out the --exclude and
>>>>>> it worked ;)
>>>>>>
>>>>>> Does that really occur reproducible on your machine, every try?
>>>>>
>>>>>
>>>>> Yes. And I just tried twice more with the same behavior. Earlier
>>>>> today I had a similar thing occur on a different machine, on which
>>>>> the 2011-12-04 dll was installed instead of the 2011-12-05 dll. On
>>>>> that machine (again W7-64), the mintty window simply disappeared
>>>>> when I gave the tar command.
>>>>
>>>>
>>>> Hmm, that's weird.
>>>>
>>>>> The only other detail I can think of is that I started mintty by
>>>>> right-clicking on the shortcut and choosing "Run as administrator".
>>>>
>>>>
>>>> Still works for me. That's puzzeling. Any chance to debug that?
>>>> Stracing, attaching with GDB, building your own debug-enabled Cygwin,
>>>> etc?
>>>
>>>
>>> I ran the tar command under strace. I'm not good at deciphering strace
>>> output, but you can see it here:
>>>
>>> http://www.math.cornell.edu/~kbrown/cygwin/strace.out
>>>
>>> A few further observations:
>>>
>>> - As the strace output shows, tar does in fact run, contrary to what I
>>> originally thought; it's just that there's no indication in the terminal
>>> that tar finished.
>>>
>>> - When I finally get tired of waiting and kill mintty (and the
>>> associated bash process) from another terminal, mintty leaves the
>>> following stackdump on the desktop:
>>>
>>> Exception: STATUS_ACCESS_VIOLATION at eip=610CD8B1
>>> eax=0000010C ebx=0028C880 ecx=00000000 edx=0000010C esi=00000000
>>> edi=0028C860
>>> ebp=0028C7C8 esp=0028C790 program=C:\cygwin\bin\mintty.exe, pid 4972,
>>> thread main
>>> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>>> Stack trace:
>>> Frame Function Args
>>> 0028C7C8 610CD8B1 (0000010C, 0028C95C, 0028C880, 0028C860)
>>> 0028C938 610CDC42 (00000002, 0028C95C, 00000000, 00000000)
>>> 20052168 610D1FE5 (00630072, 00000000, 00000018, 00000033)
>>> 200524F0 00000000 (6E776F72, 6D64612D, 2E2F6E69, 746E696D)
>>> End of stack trace
>>>
>>> - Other mintty windows that are open become unusable. The title bar
>>> shows "not responding".
>>>
>>> Does any of this help? Should I be stracing mintty rather than tar?
>>
>>
>> Apparently yes. I can't reproduce this either. The strace you provided
>> does look perfectly normal.
>
>
> OK. I started mintty from the Cygwin Terminal shortcut, attached strace to
> it in a second terminal, and ran the tar command in the first terminal. The
> strace output is at
>
> http://www.math.cornell.edu/~kbrown/cygwin/strace_mintty.out
>
> Here's one more data point: The problem occurs only in a mintty started from
> the shortcut. If I start mintty from an existing mintty, I can run the tar
> command without a problem.
In the first case, mintty has explorer.exe as parent.
A case of bad parenting? :)
Dima
>
> Ken
>
>
> --
> 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
>
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 17:00 ` Bengt Larsson
@ 2011-12-07 17:38 ` Corinna Vinschen
2011-12-07 17:51 ` Bengt Larsson
0 siblings, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-07 17:38 UTC (permalink / raw)
To: cygwin
On Dec 7 18:00, Bengt Larsson wrote:
> Corinna Vinschen wrote:
>
> >- cygwin_conv_path and cygwin_conv_path_list: In CCP_WIN_A_TO_POSIX and
> > CCP_POSIX_TO_WIN_A conversions, use the current Windows ANSI or OEM
> > charset, depending on the return value of AreFileApisANSI. Up to Cygwin
> > 1.7.9, both conversions used the current Cygwin charset for the conversion.
>
> Is that the right thing to do? I have LANG=C.UTF-8. If I pass a
> Windows-style filename on the command line, it's passed as UTF-8. How do
> I then convert that to Unix-style, UTF-8?
First of all, don't do that. Use POSIX paths.
Second, it's not passed as UTF-8 if the called application is a
non-Cygwin application. In fact, Cygwin calls CreateProcessW, so all
strings are converted to UTF-16 (aka UNICODE) when starting a non-Cygwin
child process.
Third, as for Cygwin apps, don't use WIN_A, use WIN_W instead, because
that's encoding agnostic:
main (int argc, char **argv)
{
size_t len;
wchar_t *w32_path;
char *psx_path;
setlocale (LC_ALL, "");
len = mbstowcs (NULL, argv[1], 0) + 1;
w32_path = (wchar_t *) malloc (len * sizeof (wchar_t));
mbstowcs (w32_path, argv[1], len);
psx_path = (char *) cygwin_create_path (CCP_WIN_W_TO_POSIX, w32_path);
[...]
}
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 17:38 ` Corinna Vinschen
@ 2011-12-07 17:51 ` Bengt Larsson
2011-12-07 18:07 ` Corinna Vinschen
0 siblings, 1 reply; 93+ messages in thread
From: Bengt Larsson @ 2011-12-07 17:51 UTC (permalink / raw)
To: cygwin
Corinna Vinschen wrote:
>On Dec 7 18:00, Bengt Larsson wrote:
>> Corinna Vinschen wrote:
>>
>> >- cygwin_conv_path and cygwin_conv_path_list: In CCP_WIN_A_TO_POSIX and
>> > CCP_POSIX_TO_WIN_A conversions, use the current Windows ANSI or OEM
>> > charset, depending on the return value of AreFileApisANSI. Up to Cygwin
>> > 1.7.9, both conversions used the current Cygwin charset for the conversion.
>>
>> Is that the right thing to do? I have LANG=C.UTF-8. If I pass a
>> Windows-style filename on the command line, it's passed as UTF-8. How do
>> I then convert that to Unix-style, UTF-8?
>
>First of all, don't do that. Use POSIX paths.
>
>Second, it's not passed as UTF-8 if the called application is a
>non-Cygwin application. In fact, Cygwin calls CreateProcessW, so all
>strings are converted to UTF-16 (aka UNICODE) when starting a non-Cygwin
>child process.
>
>Third, as for Cygwin apps, don't use WIN_A, use WIN_W instead, because
>that's encoding agnostic:
OK, thanks.
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 17:51 ` Bengt Larsson
@ 2011-12-07 18:07 ` Corinna Vinschen
2011-12-08 1:10 ` Enrico Forestieri
0 siblings, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-07 18:07 UTC (permalink / raw)
To: cygwin
On Dec 7 18:50, Bengt Larsson wrote:
> Corinna Vinschen wrote:
> >On Dec 7 18:00, Bengt Larsson wrote:
> >> Corinna Vinschen wrote:
> >>
> >> >- cygwin_conv_path and cygwin_conv_path_list: In CCP_WIN_A_TO_POSIX and
> >> > CCP_POSIX_TO_WIN_A conversions, use the current Windows ANSI or OEM
> >> > charset, depending on the return value of AreFileApisANSI. Up to Cygwin
> >> > 1.7.9, both conversions used the current Cygwin charset for the conversion.
> >>
> >> Is that the right thing to do? I have LANG=C.UTF-8. If I pass a
> >> Windows-style filename on the command line, it's passed as UTF-8. How do
> >> I then convert that to Unix-style, UTF-8?
> >
> >First of all, don't do that. Use POSIX paths.
> >
> >Second, it's not passed as UTF-8 if the called application is a
> >non-Cygwin application. In fact, Cygwin calls CreateProcessW, so all
> >strings are converted to UTF-16 (aka UNICODE) when starting a non-Cygwin
> >child process.
> >
> >Third, as for Cygwin apps, don't use WIN_A, use WIN_W instead, because
> >that's encoding agnostic:
>
> OK, thanks.
Just so it's clear why I did that, maybe you want to have a look into
the brief discussion on the cygwin-developers list:
http://cygwin.com/ml/cygwin-developers/2011-11/msg00000.html
Basically, apart from external sources, the multibyte Windows paths you
have are either returned from a Windows function, or they are supposed
to be put into a Windows function. Since the multibyte Windows file
access functions use the ANSI or OEM codepage, it makes sense to use the
current ANSI or OEM codepage for the WIN_A conversions as well. But in
fact I agree with Daniel's comment on the list:
http://cygwin.com/ml/cygwin-developers/2011-11/msg00002.html
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 22:25 ` Tim McDaniel
@ 2011-12-07 21:50 ` Andrey Repin
0 siblings, 0 replies; 93+ messages in thread
From: Andrey Repin @ 2011-12-07 21:50 UTC (permalink / raw)
To: Tim McDaniel, cygwin
Greetings, Tim McDaniel!
> On Tue, 6 Dec 2011, Lars Bj_rndal wrote:
>> What doew Iirc mean?
> http://www.acronymfinder.com/ is often useful, but in this case, it
> produces a lot of useless crud.
If you search directly in Slang/Chat, it's usually more useful.
http://www.acronymfinder.com/Slang/IIRC.html
> http://www.urbandictionary.com/define.php?term=iirc is often of more
> use.
> If I Recall Correctly.
This.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 08.12.2011, <01:34>
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 13:03 ` Ken Brown
2011-12-07 16:55 ` Thomas Wolff
2011-12-07 17:07 ` Dima Pasechnik
@ 2011-12-07 23:13 ` Christopher Faylor
2011-12-08 3:19 ` Ken Brown
2 siblings, 1 reply; 93+ messages in thread
From: Christopher Faylor @ 2011-12-07 23:13 UTC (permalink / raw)
To: cygwin
On Wed, Dec 07, 2011 at 08:03:22AM -0500, Ken Brown wrote:
>On 12/6/2011 10:22 PM, Christopher Faylor wrote:
>> On Tue, Dec 06, 2011 at 09:51:32PM -0500, Ken Brown wrote:
>>> On 12/6/2011 3:02 PM, Corinna Vinschen wrote:
>>>> On Dec 6 13:28, Ken Brown wrote:
>>>>> On 12/6/2011 12:57 PM, Corinna Vinschen wrote:
>>>>>> On Dec 6 12:37, Ken Brown wrote:
>>>>>>> On 12/6/2011 4:37 AM, Corinna Vinschen wrote:
>>>>>>>> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
>>>>>>>> been released, so we're looking forward to release Cygwin 1.7.10 soon.
>>>>>>>>
>>>>>>>> Please test the latest developer snapshots at http://cygwin.com/snapshots/
>>>>>>>> which should have "Release Candidate" quality.
>>>>>>>
>>>>>>> Here's an easily reproducible problem with the 2011-12-05
>>>>>>> cygwin1.dll snapshot:
>>>>>>>
>>>>>>> 1. Download cygwin-inst-20111205.tar.bz2 .
>>>>>>>
>>>>>>> 2. Start mintty from the Cygwin Terminal shortcut.
>>>>>>>
>>>>>>> 3. tar -C/ -xf /path/to/cygwin-inst-20111205.tar.bz2
>>>>>>> --exclude=usr/bin/cygwin1.dll
>>>>>>>
>>>>>>> An hourglass appears and tar doesn't run. I'm on W7-64 if that
>>>>>>> makes a difference.
>>>>>>
>>>>>> Works for me. I just tried from mintty with bash as login shell as
>>>>>> well as with tcsh as login shell. I even left out the --exclude and
>>>>>> it worked ;)
>>>>>>
>>>>>> Does that really occur reproducible on your machine, every try?
>>>>>
>>>>> Yes. And I just tried twice more with the same behavior. Earlier
>>>>> today I had a similar thing occur on a different machine, on which
>>>>> the 2011-12-04 dll was installed instead of the 2011-12-05 dll. On
>>>>> that machine (again W7-64), the mintty window simply disappeared
>>>>> when I gave the tar command.
>>>>
>>>> Hmm, that's weird.
>>>>
>>>>> The only other detail I can think of is that I started mintty by
>>>>> right-clicking on the shortcut and choosing "Run as administrator".
>>>>
>>>> Still works for me. That's puzzeling. Any chance to debug that?
>>>> Stracing, attaching with GDB, building your own debug-enabled Cygwin,
>>>> etc?
>>>
>>> I ran the tar command under strace. I'm not good at deciphering strace
>>> output, but you can see it here:
>>>
>>> http://www.math.cornell.edu/~kbrown/cygwin/strace.out
>>>
>>> A few further observations:
>>>
>>> - As the strace output shows, tar does in fact run, contrary to what I
>>> originally thought; it's just that there's no indication in the terminal
>>> that tar finished.
>>>
>>> - When I finally get tired of waiting and kill mintty (and the
>>> associated bash process) from another terminal, mintty leaves the
>>> following stackdump on the desktop:
>>>
>>> Exception: STATUS_ACCESS_VIOLATION at eip=610CD8B1
>>> eax=0000010C ebx=0028C880 ecx=00000000 edx=0000010C esi=00000000
>>> edi=0028C860
>>> ebp=0028C7C8 esp=0028C790 program=C:\cygwin\bin\mintty.exe, pid 4972,
>>> thread main
>>> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>>> Stack trace:
>>> Frame Function Args
>>> 0028C7C8 610CD8B1 (0000010C, 0028C95C, 0028C880, 0028C860)
>>> 0028C938 610CDC42 (00000002, 0028C95C, 00000000, 00000000)
>>> 20052168 610D1FE5 (00630072, 00000000, 00000018, 00000033)
>>> 200524F0 00000000 (6E776F72, 6D64612D, 2E2F6E69, 746E696D)
>>> End of stack trace
>>>
>>> - Other mintty windows that are open become unusable. The title bar
>>> shows "not responding".
>>>
>>> Does any of this help? Should I be stracing mintty rather than tar?
>>
>> Apparently yes. I can't reproduce this either. The strace you provided
>> does look perfectly normal.
>
>OK. I started mintty from the Cygwin Terminal shortcut, attached strace
>to it in a second terminal, and ran the tar command in the first
>terminal. The strace output is at
>
> http://www.math.cornell.edu/~kbrown/cygwin/strace_mintty.out
>
>Here's one more data point: The problem occurs only in a mintty started
>from the shortcut. If I start mintty from an existing mintty, I can run
>the tar command without a problem.
Still can't duplicate it.
I can see that mintty is having problems but it isn't clear why.
I'm going to generate a new snapshot with more debugging. Could you
give it a try when it shows up?
I'd like to see both the above stack dump, if you get it and another
snapshot.
Thanks for your help. It's much appreciated.
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 10:00 [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10 Corinna Vinschen
` (5 preceding siblings ...)
2011-12-07 17:00 ` Bengt Larsson
@ 2011-12-07 23:18 ` Yaakov (Cygwin/X)
2011-12-08 7:04 ` Christopher Faylor
2011-12-08 10:51 ` Heiko Elger
` (2 subsequent siblings)
9 siblings, 1 reply; 93+ messages in thread
From: Yaakov (Cygwin/X) @ 2011-12-07 23:18 UTC (permalink / raw)
To: cygwin
On Tue, 2011-12-06 at 10:37 +0100, Corinna Vinschen wrote:
> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
> been released, so we're looking forward to release Cygwin 1.7.10 soon.
>
> Please test the latest developer snapshots at http://cygwin.com/snapshots/
> which should have "Release Candidate" quality.
With CVS HEAD as of this moment, ldd(1) hangs when run on any
Cygwin-dependent DLL, but not with Cygwin-dependent EXEs (even those
that depend on other DLLs) and other DLLs (e.g. cygwin1.dll itself or a
MinGW DLL).
(Yes, I did update my ldd/ldh as well.)
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 18:07 ` Corinna Vinschen
@ 2011-12-08 1:10 ` Enrico Forestieri
2011-12-08 8:29 ` Andy Koppe
2011-12-08 8:40 ` Corinna Vinschen
0 siblings, 2 replies; 93+ messages in thread
From: Enrico Forestieri @ 2011-12-08 1:10 UTC (permalink / raw)
To: cygwin
Corinna Vinschen writes:
>
> Just so it's clear why I did that, maybe you want to have a look into
> the brief discussion on the cygwin-developers list:
> http://cygwin.com/ml/cygwin-developers/2011-11/msg00000.html
All good reasons, but you are going to break backward compatibility.
At least, lyx is going to be affected. It currently works with unicode
without a glitch, but it will be broken with 1.7.10.
http://www.iwise.com/ar8tr
--
Enrico
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 23:13 ` Christopher Faylor
@ 2011-12-08 3:19 ` Ken Brown
2011-12-08 6:53 ` Christopher Faylor
0 siblings, 1 reply; 93+ messages in thread
From: Ken Brown @ 2011-12-08 3:19 UTC (permalink / raw)
To: cygwin
On 12/7/2011 6:13 PM, Christopher Faylor wrote:
> On Wed, Dec 07, 2011 at 08:03:22AM -0500, Ken Brown wrote:
>> On 12/6/2011 10:22 PM, Christopher Faylor wrote:
>>> On Tue, Dec 06, 2011 at 09:51:32PM -0500, Ken Brown wrote:
>>>> On 12/6/2011 3:02 PM, Corinna Vinschen wrote:
>>>>> On Dec 6 13:28, Ken Brown wrote:
>>>>>> On 12/6/2011 12:57 PM, Corinna Vinschen wrote:
>>>>>>> On Dec 6 12:37, Ken Brown wrote:
>>>>>>>> On 12/6/2011 4:37 AM, Corinna Vinschen wrote:
>>>>>>>>> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
>>>>>>>>> been released, so we're looking forward to release Cygwin 1.7.10 soon.
>>>>>>>>>
>>>>>>>>> Please test the latest developer snapshots at http://cygwin.com/snapshots/
>>>>>>>>> which should have "Release Candidate" quality.
>>>>>>>>
>>>>>>>> Here's an easily reproducible problem with the 2011-12-05
>>>>>>>> cygwin1.dll snapshot:
>>>>>>>>
>>>>>>>> 1. Download cygwin-inst-20111205.tar.bz2 .
>>>>>>>>
>>>>>>>> 2. Start mintty from the Cygwin Terminal shortcut.
>>>>>>>>
>>>>>>>> 3. tar -C/ -xf /path/to/cygwin-inst-20111205.tar.bz2
>>>>>>>> --exclude=usr/bin/cygwin1.dll
>>>>>>>>
>>>>>>>> An hourglass appears and tar doesn't run. I'm on W7-64 if that
>>>>>>>> makes a difference.
>>>>>>>
>>>>>>> Works for me. I just tried from mintty with bash as login shell as
>>>>>>> well as with tcsh as login shell. I even left out the --exclude and
>>>>>>> it worked ;)
>>>>>>>
>>>>>>> Does that really occur reproducible on your machine, every try?
>>>>>>
>>>>>> Yes. And I just tried twice more with the same behavior. Earlier
>>>>>> today I had a similar thing occur on a different machine, on which
>>>>>> the 2011-12-04 dll was installed instead of the 2011-12-05 dll. On
>>>>>> that machine (again W7-64), the mintty window simply disappeared
>>>>>> when I gave the tar command.
>>>>>
>>>>> Hmm, that's weird.
>>>>>
>>>>>> The only other detail I can think of is that I started mintty by
>>>>>> right-clicking on the shortcut and choosing "Run as administrator".
>>>>>
>>>>> Still works for me. That's puzzeling. Any chance to debug that?
>>>>> Stracing, attaching with GDB, building your own debug-enabled Cygwin,
>>>>> etc?
>>>>
>>>> I ran the tar command under strace. I'm not good at deciphering strace
>>>> output, but you can see it here:
>>>>
>>>> http://www.math.cornell.edu/~kbrown/cygwin/strace.out
>>>>
>>>> A few further observations:
>>>>
>>>> - As the strace output shows, tar does in fact run, contrary to what I
>>>> originally thought; it's just that there's no indication in the terminal
>>>> that tar finished.
>>>>
>>>> - When I finally get tired of waiting and kill mintty (and the
>>>> associated bash process) from another terminal, mintty leaves the
>>>> following stackdump on the desktop:
>>>>
>>>> Exception: STATUS_ACCESS_VIOLATION at eip=610CD8B1
>>>> eax=0000010C ebx=0028C880 ecx=00000000 edx=0000010C esi=00000000
>>>> edi=0028C860
>>>> ebp=0028C7C8 esp=0028C790 program=C:\cygwin\bin\mintty.exe, pid 4972,
>>>> thread main
>>>> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>>>> Stack trace:
>>>> Frame Function Args
>>>> 0028C7C8 610CD8B1 (0000010C, 0028C95C, 0028C880, 0028C860)
>>>> 0028C938 610CDC42 (00000002, 0028C95C, 00000000, 00000000)
>>>> 20052168 610D1FE5 (00630072, 00000000, 00000018, 00000033)
>>>> 200524F0 00000000 (6E776F72, 6D64612D, 2E2F6E69, 746E696D)
>>>> End of stack trace
>>>>
>>>> - Other mintty windows that are open become unusable. The title bar
>>>> shows "not responding".
>>>>
>>>> Does any of this help? Should I be stracing mintty rather than tar?
>>>
>>> Apparently yes. I can't reproduce this either. The strace you provided
>>> does look perfectly normal.
>>
>> OK. I started mintty from the Cygwin Terminal shortcut, attached strace
>> to it in a second terminal, and ran the tar command in the first
>> terminal. The strace output is at
>>
>> http://www.math.cornell.edu/~kbrown/cygwin/strace_mintty.out
>>
>> Here's one more data point: The problem occurs only in a mintty started
>>from the shortcut. If I start mintty from an existing mintty, I can run
>> the tar command without a problem.
>
> Still can't duplicate it.
>
> I can see that mintty is having problems but it isn't clear why.
>
> I'm going to generate a new snapshot with more debugging. Could you
> give it a try when it shows up?
>
> I'd like to see both the above stack dump, if you get it and another
> snapshot.
Here's the stack dump:
Exception: STATUS_ACCESS_VIOLATION at eip=610CD8B1
eax=0000010C ebx=0028C880 ecx=00000000 edx=0000010C esi=00000000
edi=0028C860
ebp=0028C7C8 esp=0028C7A0 program=C:\cygwin\bin\mintty.exe, pid 4396,
thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
0028C7C8 610CD8B1 (0000010C, 0028C95C, 0028C880, 0028C860)
0028C938 610CDD87 (00000002, 0028C95C, 00000000, 0028C860)
20052208 610D2045 (00630072, 00000000, 00000018, 00000033)
20052590 00000000 (6E776F72, 6D64612D, 2E2F6E69, 746E696D)
End of stack trace
And the strace output is at
http://www.math.cornell.edu/~kbrown/cygwin/strace_20111208_snap.out
By the way, ssh doesn't work with this snapshot; I get the error message
"PRNG is not seeded" when I run "ssh user@host", and I also can't start
sshd. (/var/log/sshd.log contains the same "PRNG is not seeded" error
message.)
Ken
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 3:19 ` Ken Brown
@ 2011-12-08 6:53 ` Christopher Faylor
2011-12-08 13:12 ` Ken Brown
0 siblings, 1 reply; 93+ messages in thread
From: Christopher Faylor @ 2011-12-08 6:53 UTC (permalink / raw)
To: cygwin
On Wed, Dec 07, 2011 at 10:18:40PM -0500, Ken Brown wrote:
>On 12/7/2011 6:13 PM, Christopher Faylor wrote:
>> On Wed, Dec 07, 2011 at 08:03:22AM -0500, Ken Brown wrote:
>>> On 12/6/2011 10:22 PM, Christopher Faylor wrote:
>>>> On Tue, Dec 06, 2011 at 09:51:32PM -0500, Ken Brown wrote:
>>>>> On 12/6/2011 3:02 PM, Corinna Vinschen wrote:
>>>>>> On Dec 6 13:28, Ken Brown wrote:
>>>>>>> On 12/6/2011 12:57 PM, Corinna Vinschen wrote:
>>>>>>>> On Dec 6 12:37, Ken Brown wrote:
>>>>>>>>> On 12/6/2011 4:37 AM, Corinna Vinschen wrote:
>>>>>>>>>> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
>>>>>>>>>> been released, so we're looking forward to release Cygwin 1.7.10 soon.
>>>>>>>>>>
>>>>>>>>>> Please test the latest developer snapshots at http://cygwin.com/snapshots/
>>>>>>>>>> which should have "Release Candidate" quality.
>>>>>>>>>
>>>>>>>>> Here's an easily reproducible problem with the 2011-12-05
>>>>>>>>> cygwin1.dll snapshot:
>>>>>>>>>
>>>>>>>>> 1. Download cygwin-inst-20111205.tar.bz2 .
>>>>>>>>>
>>>>>>>>> 2. Start mintty from the Cygwin Terminal shortcut.
>>>>>>>>>
>>>>>>>>> 3. tar -C/ -xf /path/to/cygwin-inst-20111205.tar.bz2
>>>>>>>>> --exclude=usr/bin/cygwin1.dll
>>>>>>>>>
>>>>>>>>> An hourglass appears and tar doesn't run. I'm on W7-64 if that
>>>>>>>>> makes a difference.
>>>>>>>>
>>>>>>>> Works for me. I just tried from mintty with bash as login shell as
>>>>>>>> well as with tcsh as login shell. I even left out the --exclude and
>>>>>>>> it worked ;)
>>>>>>>>
>>>>>>>> Does that really occur reproducible on your machine, every try?
>>>>>>>
>>>>>>> Yes. And I just tried twice more with the same behavior. Earlier
>>>>>>> today I had a similar thing occur on a different machine, on which
>>>>>>> the 2011-12-04 dll was installed instead of the 2011-12-05 dll. On
>>>>>>> that machine (again W7-64), the mintty window simply disappeared
>>>>>>> when I gave the tar command.
>>>>>>
>>>>>> Hmm, that's weird.
>>>>>>
>>>>>>> The only other detail I can think of is that I started mintty by
>>>>>>> right-clicking on the shortcut and choosing "Run as administrator".
>>>>>>
>>>>>> Still works for me. That's puzzeling. Any chance to debug that?
>>>>>> Stracing, attaching with GDB, building your own debug-enabled Cygwin,
>>>>>> etc?
>>>>>
>>>>> I ran the tar command under strace. I'm not good at deciphering strace
>>>>> output, but you can see it here:
>>>>>
>>>>> http://www.math.cornell.edu/~kbrown/cygwin/strace.out
>>>>>
>>>>> A few further observations:
>>>>>
>>>>> - As the strace output shows, tar does in fact run, contrary to what I
>>>>> originally thought; it's just that there's no indication in the terminal
>>>>> that tar finished.
>>>>>
>>>>> - When I finally get tired of waiting and kill mintty (and the
>>>>> associated bash process) from another terminal, mintty leaves the
>>>>> following stackdump on the desktop:
>>>>>
>>>>> Exception: STATUS_ACCESS_VIOLATION at eip=610CD8B1
>>>>> eax=0000010C ebx=0028C880 ecx=00000000 edx=0000010C esi=00000000
>>>>> edi=0028C860
>>>>> ebp=0028C7C8 esp=0028C790 program=C:\cygwin\bin\mintty.exe, pid 4972,
>>>>> thread main
>>>>> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>>>>> Stack trace:
>>>>> Frame Function Args
>>>>> 0028C7C8 610CD8B1 (0000010C, 0028C95C, 0028C880, 0028C860)
>>>>> 0028C938 610CDC42 (00000002, 0028C95C, 00000000, 00000000)
>>>>> 20052168 610D1FE5 (00630072, 00000000, 00000018, 00000033)
>>>>> 200524F0 00000000 (6E776F72, 6D64612D, 2E2F6E69, 746E696D)
>>>>> End of stack trace
>>>>>
>>>>> - Other mintty windows that are open become unusable. The title bar
>>>>> shows "not responding".
>>>>>
>>>>> Does any of this help? Should I be stracing mintty rather than tar?
>>>>
>>>> Apparently yes. I can't reproduce this either. The strace you provided
>>>> does look perfectly normal.
>>>
>>> OK. I started mintty from the Cygwin Terminal shortcut, attached strace
>>> to it in a second terminal, and ran the tar command in the first
>>> terminal. The strace output is at
>>>
>>> http://www.math.cornell.edu/~kbrown/cygwin/strace_mintty.out
>>>
>>> Here's one more data point: The problem occurs only in a mintty started
>>>from the shortcut. If I start mintty from an existing mintty, I can run
>>> the tar command without a problem.
>>
>> Still can't duplicate it.
>>
>> I can see that mintty is having problems but it isn't clear why.
>>
>> I'm going to generate a new snapshot with more debugging. Could you
>> give it a try when it shows up?
>>
>> I'd like to see both the above stack dump, if you get it and another
>> snapshot.
>
>Here's the stack dump:
>
>Exception: STATUS_ACCESS_VIOLATION at eip=610CD8B1
>eax=0000010C ebx=0028C880 ecx=00000000 edx=0000010C esi=00000000
>edi=0028C860
>ebp=0028C7C8 esp=0028C7A0 program=C:\cygwin\bin\mintty.exe, pid 4396,
>thread main
>cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>Stack trace:
>Frame Function Args
>0028C7C8 610CD8B1 (0000010C, 0028C95C, 0028C880, 0028C860)
>0028C938 610CDD87 (00000002, 0028C95C, 00000000, 0028C860)
>20052208 610D2045 (00630072, 00000000, 00000018, 00000033)
>20052590 00000000 (6E776F72, 6D64612D, 2E2F6E69, 746E696D)
>End of stack trace
>
>And the strace output is at
>
> http://www.math.cornell.edu/~kbrown/cygwin/strace_20111208_snap.out
>
>By the way, ssh doesn't work with this snapshot; I get the error message
>"PRNG is not seeded" when I run "ssh user@host", and I also can't start
>sshd. (/var/log/sshd.log contains the same "PRNG is not seeded" error
>message.)
Sigh. I screwed up select() so the test is suspect.
I'm generating a new snapshot now. The ssh should be fixed, assuming
that my grogginess hasn't introduced another stupid bug.
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 23:18 ` Yaakov (Cygwin/X)
@ 2011-12-08 7:04 ` Christopher Faylor
0 siblings, 0 replies; 93+ messages in thread
From: Christopher Faylor @ 2011-12-08 7:04 UTC (permalink / raw)
To: cygwin
On Wed, Dec 07, 2011 at 05:18:28PM -0600, Yaakov (Cygwin/X) wrote:
>On Tue, 2011-12-06 at 10:37 +0100, Corinna Vinschen wrote:
>> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
>> been released, so we're looking forward to release Cygwin 1.7.10 soon.
>>
>> Please test the latest developer snapshots at http://cygwin.com/snapshots/
>> which should have "Release Candidate" quality.
>
>With CVS HEAD as of this moment, ldd(1) hangs when run on any
>Cygwin-dependent DLL, but not with Cygwin-dependent EXEs (even those
>that depend on other DLLs) and other DLLs (e.g. cygwin1.dll itself or a
>MinGW DLL).
>
>(Yes, I did update my ldd/ldh as well.)
Should be fixed. That was amazingly difficult to debug.
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 1:10 ` Enrico Forestieri
@ 2011-12-08 8:29 ` Andy Koppe
2011-12-08 14:48 ` Enrico Forestieri
2011-12-08 8:40 ` Corinna Vinschen
1 sibling, 1 reply; 93+ messages in thread
From: Andy Koppe @ 2011-12-08 8:29 UTC (permalink / raw)
To: cygwin
On 8 December 2011 00:33, Enrico Forestieri wrote:
> Corinna Vinschen writes:
>>
>> Just so it's clear why I did that, maybe you want to have a look into
>> the brief discussion on the cygwin-developers list:
>> http://cygwin.com/ml/cygwin-developers/2011-11/msg00000.html
>
> All good reasons, but you are going to break backward compatibility.
> At least, lyx is going to be affected. It currently works with unicode
> without a glitch
That's impossible if it's using Ansi APIs.
Andy
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 1:10 ` Enrico Forestieri
2011-12-08 8:29 ` Andy Koppe
@ 2011-12-08 8:40 ` Corinna Vinschen
2011-12-08 12:38 ` Enrico Forestieri
1 sibling, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-08 8:40 UTC (permalink / raw)
To: cygwin
On Dec 8 00:33, Enrico Forestieri wrote:
> Corinna Vinschen writes:
> >
> > Just so it's clear why I did that, maybe you want to have a look into
> > the brief discussion on the cygwin-developers list:
> > http://cygwin.com/ml/cygwin-developers/2011-11/msg00000.html
>
> All good reasons, but you are going to break backward compatibility.
> At least, lyx is going to be affected. It currently works with unicode
> without a glitch, but it will be broken with 1.7.10.
Which raises the question why the Cygwin version of lyx uses
cygwin_conv_path at all. Does it call Windows functions with the paths?
If so, why? If not, why are the paths converted to Windows?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 15:47 ` Lars Bjørndal
@ 2011-12-08 8:48 ` Corinna Vinschen
2011-12-11 22:03 ` Samuel Thibault
0 siblings, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-08 8:48 UTC (permalink / raw)
To: cygwin
On Dec 7 16:47, Lars Bjørndal wrote:
> On on., des. 07, 2011 at 01:40:25 +0100, Lars Bjørndal wrote:
> > [Corinna]
> > > On Dec 7 10:23, Lars Bjørndal wrote:
> > > > [Corinna]
> > > > [...]
> > > >
> > > > > Btw., "brltty doesn't work" is a bit low on detail. It would also be
> > > > > helpful if you could find out with which snapshot brltty starts to
> > > > > misbehave.
> > > >
> > > > At 20111022. Now, I'm using the dll from 20111021, and it works.
> > >
> > > Thanks!
> > >
> > > Are you using Windows 7 by any chance? If so, I have a hunch what the
> > > problem is.
> >
> > Yes - 64bit version.
> >
> > > Can I send you the URL to a test DLL by private email?
> >
> > Sure.
>
> I tried the patch you provided, but with no better result - sorry.
Too bad. In that case, Samuel, can you please have a closer look to
see what broke brltty? I have not the faintest idea how to test it
and how to see if it works or not.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 10:00 [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10 Corinna Vinschen
` (6 preceding siblings ...)
2011-12-07 23:18 ` Yaakov (Cygwin/X)
@ 2011-12-08 10:51 ` Heiko Elger
2011-12-08 16:06 ` Bengt Larsson
2011-12-22 7:09 ` Shaddy Baddah
9 siblings, 0 replies; 93+ messages in thread
From: Heiko Elger @ 2011-12-08 10:51 UTC (permalink / raw)
To: cygwin
Hello,
I upgrade from snapshot 20110829 to current 20111208 qand I update the tools
too.
$ uname -a
CYGWIN_NT-6.1-WOW64 PCFX167 1.7.10s(0.255/5/3) 20111208 06:50:31 i686 Cygwin
I did rebaseall and peflagsall.
I got some "Bad address" errors while compiling with make while running shell
scripts, cygcheck or compilers.
I see the error while running mingw compiler too!
c:/programme/cygwin/bin/sh: /cygdrive/c/programme/cygwin/bin/cygcheck: Bad
address
c:/programme/cygwin/bin/sh:
C:/clearcase/xview/pid/pid_V3.7_2011.05.06_019/gnu/4.1.2-vxworks-6.7/x86-
win32/bin/ccpentium.exe: Bad address
c:/programme/cygwin/bin/sh: ../../tools/buildtools/arb/liters/liters.2_5/liters
: Bad address
But all errors are not reproduceable at the moment - so I cannot send a
testcase.
With snapshot 20110829 I only got some "forking errors" - but never "Bad
address" erros.
Can anyone explain me a little bit in detail the "Bad address".
So perhaps I can find a testcase.
In older postings I found "Bad errors" - but I think these are all related to
older cygwin version 1.7.7 and older.
regrads
Heiko
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 8:40 ` Corinna Vinschen
@ 2011-12-08 12:38 ` Enrico Forestieri
2011-12-08 14:32 ` Enrico Forestieri
0 siblings, 1 reply; 93+ messages in thread
From: Enrico Forestieri @ 2011-12-08 12:38 UTC (permalink / raw)
To: cygwin
Corinna Vinschen writes:
>
> Which raises the question why the Cygwin version of lyx uses
> cygwin_conv_path at all. Does it call Windows functions with the paths?
> If so, why? If not, why are the paths converted to Windows?
Because the user *could* enter Windows paths (e.g., for including images)
or a document created with a native Windows version could be opened with
the Cygwin version. The Cygwin version of lyx works internally with
posix paths, which are to be converted from the native Windows form.
Then, there is a case where the posix->windows conversion is needed.
Indeed, lyx allows to use either a Cygwin or native-Windows TeX engine.
There is a configuration check for this case. If a native-Windows TeX
engine is detected, all paths going to latex files should be converted
to Windows, otherwise the TeX engine would not understand them.
This is symmetric, i.e., if you compile a native Windows version of lyx
and use a Cygwin TeX engine, all paths going to latex files gets converted
to posix form. But this case is not of interest here, of course.
However, I experimented a bit with the last snapshot, and even using Greek
or Japanese characters in file names, lyx seems to be working fine. In part,
this may be due to the fact that, for compiling a latex file, all needed
ancillary files are copied to a temporary directory with their names
mangled such that only pure ascii characters are used. Anyway, when
converting from/to Windows, lyx assumes that cygwin_conv_path does not
play tricks with the encoding. It was so until now. If this changes, I
think it is bound to fail in some way.
--
Enrico
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 6:53 ` Christopher Faylor
@ 2011-12-08 13:12 ` Ken Brown
0 siblings, 0 replies; 93+ messages in thread
From: Ken Brown @ 2011-12-08 13:12 UTC (permalink / raw)
To: cygwin
On 12/8/2011 1:52 AM, Christopher Faylor wrote:
> On Wed, Dec 07, 2011 at 10:18:40PM -0500, Ken Brown wrote:
>> On 12/7/2011 6:13 PM, Christopher Faylor wrote:
>>> On Wed, Dec 07, 2011 at 08:03:22AM -0500, Ken Brown wrote:
>>>> On 12/6/2011 10:22 PM, Christopher Faylor wrote:
>>>>> On Tue, Dec 06, 2011 at 09:51:32PM -0500, Ken Brown wrote:
>>>>>> On 12/6/2011 3:02 PM, Corinna Vinschen wrote:
>>>>>>> On Dec 6 13:28, Ken Brown wrote:
>>>>>>>> On 12/6/2011 12:57 PM, Corinna Vinschen wrote:
>>>>>>>>> On Dec 6 12:37, Ken Brown wrote:
>>>>>>>>>> On 12/6/2011 4:37 AM, Corinna Vinschen wrote:
>>>>>>>>>>> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
>>>>>>>>>>> been released, so we're looking forward to release Cygwin 1.7.10 soon.
>>>>>>>>>>>
>>>>>>>>>>> Please test the latest developer snapshots at http://cygwin.com/snapshots/
>>>>>>>>>>> which should have "Release Candidate" quality.
>>>>>>>>>>
>>>>>>>>>> Here's an easily reproducible problem with the 2011-12-05
>>>>>>>>>> cygwin1.dll snapshot:
>>>>>>>>>>
>>>>>>>>>> 1. Download cygwin-inst-20111205.tar.bz2 .
>>>>>>>>>>
>>>>>>>>>> 2. Start mintty from the Cygwin Terminal shortcut.
>>>>>>>>>>
>>>>>>>>>> 3. tar -C/ -xf /path/to/cygwin-inst-20111205.tar.bz2
>>>>>>>>>> --exclude=usr/bin/cygwin1.dll
>>>>>>>>>>
>>>>>>>>>> An hourglass appears and tar doesn't run. I'm on W7-64 if that
>>>>>>>>>> makes a difference.
>>>>>>>>>
>>>>>>>>> Works for me. I just tried from mintty with bash as login shell as
>>>>>>>>> well as with tcsh as login shell. I even left out the --exclude and
>>>>>>>>> it worked ;)
>>>>>>>>>
>>>>>>>>> Does that really occur reproducible on your machine, every try?
>>>>>>>>
>>>>>>>> Yes. And I just tried twice more with the same behavior. Earlier
>>>>>>>> today I had a similar thing occur on a different machine, on which
>>>>>>>> the 2011-12-04 dll was installed instead of the 2011-12-05 dll. On
>>>>>>>> that machine (again W7-64), the mintty window simply disappeared
>>>>>>>> when I gave the tar command.
>>>>>>>
>>>>>>> Hmm, that's weird.
>>>>>>>
>>>>>>>> The only other detail I can think of is that I started mintty by
>>>>>>>> right-clicking on the shortcut and choosing "Run as administrator".
>>>>>>>
>>>>>>> Still works for me. That's puzzeling. Any chance to debug that?
>>>>>>> Stracing, attaching with GDB, building your own debug-enabled Cygwin,
>>>>>>> etc?
>>>>>>
>>>>>> I ran the tar command under strace. I'm not good at deciphering strace
>>>>>> output, but you can see it here:
>>>>>>
>>>>>> http://www.math.cornell.edu/~kbrown/cygwin/strace.out
>>>>>>
>>>>>> A few further observations:
>>>>>>
>>>>>> - As the strace output shows, tar does in fact run, contrary to what I
>>>>>> originally thought; it's just that there's no indication in the terminal
>>>>>> that tar finished.
>>>>>>
>>>>>> - When I finally get tired of waiting and kill mintty (and the
>>>>>> associated bash process) from another terminal, mintty leaves the
>>>>>> following stackdump on the desktop:
>>>>>>
>>>>>> Exception: STATUS_ACCESS_VIOLATION at eip=610CD8B1
>>>>>> eax=0000010C ebx=0028C880 ecx=00000000 edx=0000010C esi=00000000
>>>>>> edi=0028C860
>>>>>> ebp=0028C7C8 esp=0028C790 program=C:\cygwin\bin\mintty.exe, pid 4972,
>>>>>> thread main
>>>>>> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>>>>>> Stack trace:
>>>>>> Frame Function Args
>>>>>> 0028C7C8 610CD8B1 (0000010C, 0028C95C, 0028C880, 0028C860)
>>>>>> 0028C938 610CDC42 (00000002, 0028C95C, 00000000, 00000000)
>>>>>> 20052168 610D1FE5 (00630072, 00000000, 00000018, 00000033)
>>>>>> 200524F0 00000000 (6E776F72, 6D64612D, 2E2F6E69, 746E696D)
>>>>>> End of stack trace
>>>>>>
>>>>>> - Other mintty windows that are open become unusable. The title bar
>>>>>> shows "not responding".
>>>>>>
>>>>>> Does any of this help? Should I be stracing mintty rather than tar?
>>>>>
>>>>> Apparently yes. I can't reproduce this either. The strace you provided
>>>>> does look perfectly normal.
>>>>
>>>> OK. I started mintty from the Cygwin Terminal shortcut, attached strace
>>>> to it in a second terminal, and ran the tar command in the first
>>>> terminal. The strace output is at
>>>>
>>>> http://www.math.cornell.edu/~kbrown/cygwin/strace_mintty.out
>>>>
>>>> Here's one more data point: The problem occurs only in a mintty started
>>> >from the shortcut. If I start mintty from an existing mintty, I can run
>>>> the tar command without a problem.
>>>
>>> Still can't duplicate it.
>>>
>>> I can see that mintty is having problems but it isn't clear why.
>>>
>>> I'm going to generate a new snapshot with more debugging. Could you
>>> give it a try when it shows up?
>>>
>>> I'd like to see both the above stack dump, if you get it and another
>>> snapshot.
>>
>> Here's the stack dump:
>>
>> Exception: STATUS_ACCESS_VIOLATION at eip=610CD8B1
>> eax=0000010C ebx=0028C880 ecx=00000000 edx=0000010C esi=00000000
>> edi=0028C860
>> ebp=0028C7C8 esp=0028C7A0 program=C:\cygwin\bin\mintty.exe, pid 4396,
>> thread main
>> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>> Stack trace:
>> Frame Function Args
>> 0028C7C8 610CD8B1 (0000010C, 0028C95C, 0028C880, 0028C860)
>> 0028C938 610CDD87 (00000002, 0028C95C, 00000000, 0028C860)
>> 20052208 610D2045 (00630072, 00000000, 00000018, 00000033)
>> 20052590 00000000 (6E776F72, 6D64612D, 2E2F6E69, 746E696D)
>> End of stack trace
>>
>> And the strace output is at
>>
>> http://www.math.cornell.edu/~kbrown/cygwin/strace_20111208_snap.out
>>
>> By the way, ssh doesn't work with this snapshot; I get the error message
>> "PRNG is not seeded" when I run "ssh user@host", and I also can't start
>> sshd. (/var/log/sshd.log contains the same "PRNG is not seeded" error
>> message.)
>
> Sigh. I screwed up select() so the test is suspect.
No problem. I redid the test:
$ uname -a
CYGWIN_NT-6.1-WOW64 fiona 1.7.10s(0.255/5/3) 20111208 06:50:31 i686 Cygwin
$ cat ~kbrown-admin/*.stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=610CD801
eax=0000010C ebx=0028C880 ecx=00000000 edx=0028C95C esi=00000000
edi=0028C860
ebp=0028C7C8 esp=0028C7A0 program=C:\cygwin\bin\mintty.exe, pid 6532,
thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
0028C7C8 610CD801 (0000010C, 0028C95C, 0028C880, 0028C860)
0028C938 610CDB76 (00000002, 0028C95C, 00000000, 00000000)
20052208 610D1F25 (00630072, 00000000, 00000018, 00000033)
20052590 00000000 (6E776F72, 6D64612D, 2E2F6E69, 746E696D)
End of stack trace
The strace output is still at
http://www.math.cornell.edu/~kbrown/cygwin/strace_20111208_snap.out
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 12:38 ` Enrico Forestieri
@ 2011-12-08 14:32 ` Enrico Forestieri
2011-12-12 13:27 ` Corinna Vinschen
0 siblings, 1 reply; 93+ messages in thread
From: Enrico Forestieri @ 2011-12-08 14:32 UTC (permalink / raw)
To: cygwin
Enrico Forestieri writes:
>
> However, I experimented a bit with the last snapshot, and even using Greek
> or Japanese characters in file names, lyx seems to be working fine.
Sorry, it was a cursory test. Actually, cygwin_conv_path is only called
for absolute paths. Using an absolute Windows path containing any nonascii
character, makes lyx fail miserably.
I know this is a no-no for you (even if absolute Windows paths can sneak in
by opening a document created by a Windows version), so I will not insist,
but knowlingly breaking backward compatibility is not nice.
--
Enrico
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 8:29 ` Andy Koppe
@ 2011-12-08 14:48 ` Enrico Forestieri
2011-12-08 15:08 ` Ken Brown
0 siblings, 1 reply; 93+ messages in thread
From: Enrico Forestieri @ 2011-12-08 14:48 UTC (permalink / raw)
To: cygwin
Andy Koppe writes:
>
> On 8 December 2011 00:33, Enrico Forestieri wrote:
> > Corinna Vinschen writes:
> >>
> >> Just so it's clear why I did that, maybe you want to have a look into
> >> the brief discussion on the cygwin-developers list:
> >> http://cygwin.com/ml/cygwin-developers/2011-11/msg00000.html
> >
> > All good reasons, but you are going to break backward compatibility.
> > At least, lyx is going to be affected. It currently works with unicode
> > without a glitch
>
> That's impossible if it's using Ansi APIs.
That is not the issue. No Windows API is directly used, but there is the
need to convert from posix to Windows paths when the TeX engine is native
Windows. The assumption that cygwin_conv_path does not change the encoding
is made (this is so until 1.7.9) and if this is going to change it will cause
havoc. Indeed, the path should be written to the latex file according to the
encoding used (e.g., \usepackage[cp852]{inputenc}), and lyx takes care of the
needed conversion. But, if the encoding is changed by cygwin_conv_path ...
--
Enrico
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 14:48 ` Enrico Forestieri
@ 2011-12-08 15:08 ` Ken Brown
2011-12-08 15:56 ` Enrico Forestieri
0 siblings, 1 reply; 93+ messages in thread
From: Ken Brown @ 2011-12-08 15:08 UTC (permalink / raw)
To: cygwin
On 12/8/2011 9:48 AM, Enrico Forestieri wrote:
> Andy Koppe writes:
>>
>> On 8 December 2011 00:33, Enrico Forestieri wrote:
>>> Corinna Vinschen writes:
>>>>
>>>> Just so it's clear why I did that, maybe you want to have a look into
>>>> the brief discussion on the cygwin-developers list:
>>>> http://cygwin.com/ml/cygwin-developers/2011-11/msg00000.html
>>>
>>> All good reasons, but you are going to break backward compatibility.
>>> At least, lyx is going to be affected. It currently works with unicode
>>> without a glitch
>>
>> That's impossible if it's using Ansi APIs.
>
> That is not the issue. No Windows API is directly used, but there is the
> need to convert from posix to Windows paths when the TeX engine is native
> Windows. The assumption that cygwin_conv_path does not change the encoding
> is made (this is so until 1.7.9) and if this is going to change it will cause
> havoc. Indeed, the path should be written to the latex file according to the
> encoding used (e.g., \usepackage[cp852]{inputenc}), and lyx takes care of the
> needed conversion. But, if the encoding is changed by cygwin_conv_path ...
I don't use lyx (though I use tex extensively), so maybe there's
something I don't understand. But is it really necessary for Cygwin's
lyx to support a native Windows tex? Wouldn't it be more reasonable for
users of a native Windows tex to use a native Windows lyx?
Ken
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 15:08 ` Ken Brown
@ 2011-12-08 15:56 ` Enrico Forestieri
2011-12-08 16:23 ` Ken Brown
0 siblings, 1 reply; 93+ messages in thread
From: Enrico Forestieri @ 2011-12-08 15:56 UTC (permalink / raw)
To: cygwin
Ken Brown writes:
>
> I don't use lyx (though I use tex extensively), so maybe there's
> something I don't understand. But is it really necessary for Cygwin's
> lyx to support a native Windows tex?
Necessary? No. Useful? Yes.
> Wouldn't it be more reasonable for
> users of a native Windows tex to use a native Windows lyx?
Until recently, the only Cygwin TeX engine was teTeX, which does not
support XeTeX. If you wanted a Cygwin version of lyx, you could not
have used XeTeX, unless you used MikTeX, for example.
--
Enrico
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 10:00 [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10 Corinna Vinschen
` (7 preceding siblings ...)
2011-12-08 10:51 ` Heiko Elger
@ 2011-12-08 16:06 ` Bengt Larsson
2011-12-08 18:45 ` Christopher Faylor
2011-12-22 7:09 ` Shaddy Baddah
9 siblings, 1 reply; 93+ messages in thread
From: Bengt Larsson @ 2011-12-08 16:06 UTC (permalink / raw)
To: cygwin
With the DLL from 20111208, a bug seems to have returned:
Wildcard match fail from a windows shell with non-ASCII characters
http://cygwin.com/ml/cygwin/2009-12/msg01079.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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 15:56 ` Enrico Forestieri
@ 2011-12-08 16:23 ` Ken Brown
2011-12-08 17:00 ` Enrico Forestieri
0 siblings, 1 reply; 93+ messages in thread
From: Ken Brown @ 2011-12-08 16:23 UTC (permalink / raw)
To: cygwin
On 12/8/2011 10:56 AM, Enrico Forestieri wrote:
> Ken Brown writes:
>>
>> I don't use lyx (though I use tex extensively), so maybe there's
>> something I don't understand. But is it really necessary for Cygwin's
>> lyx to support a native Windows tex?
>
> Necessary? No. Useful? Yes.
>
>> Wouldn't it be more reasonable for
>> users of a native Windows tex to use a native Windows lyx?
>
> Until recently, the only Cygwin TeX engine was teTeX, which does not
> support XeTeX. If you wanted a Cygwin version of lyx, you could not
> have used XeTeX, unless you used MikTeX, for example.
That changed a couple of years ago. TeX Live has supported Cygwin since
TL2009.
Ken
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 16:23 ` Ken Brown
@ 2011-12-08 17:00 ` Enrico Forestieri
0 siblings, 0 replies; 93+ messages in thread
From: Enrico Forestieri @ 2011-12-08 17:00 UTC (permalink / raw)
To: cygwin
Ken Brown writes:
>
> On 12/8/2011 10:56 AM, Enrico Forestieri wrote:
[...]
> > Until recently, the only Cygwin TeX engine was teTeX, which does not
> > support XeTeX. If you wanted a Cygwin version of lyx, you could not
> > have used XeTeX, unless you used MikTeX, for example.
>
> That changed a couple of years ago. TeX Live has supported Cygwin since
> TL2009.
What I meant to say is that there was a reason to support a native TeX
engine.
--
Enrico
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 16:06 ` Bengt Larsson
@ 2011-12-08 18:45 ` Christopher Faylor
2011-12-08 22:00 ` Bengt Larsson
0 siblings, 1 reply; 93+ messages in thread
From: Christopher Faylor @ 2011-12-08 18:45 UTC (permalink / raw)
To: cygwin
On Thu, Dec 08, 2011 at 05:06:21PM +0100, Bengt Larsson wrote:
>With the DLL from 20111208, a bug seems to have returned:
>
>Wildcard match fail from a windows shell with non-ASCII characters
>
>http://cygwin.com/ml/cygwin/2009-12/msg01079.html
PLEASE be precise when reporting problems. Returned from where?
1.7.9? A snapshot from a week ago? A snapshot from a day ago?
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 18:45 ` Christopher Faylor
@ 2011-12-08 22:00 ` Bengt Larsson
2011-12-09 5:56 ` Christopher Faylor
0 siblings, 1 reply; 93+ messages in thread
From: Bengt Larsson @ 2011-12-08 22:00 UTC (permalink / raw)
To: cygwin
Christopher Faylor wrote:
>On Thu, Dec 08, 2011 at 05:06:21PM +0100, Bengt Larsson wrote:
>>With the DLL from 20111208, a bug seems to have returned:
>>
>>Wildcard match fail from a windows shell with non-ASCII characters
>>
>>http://cygwin.com/ml/cygwin/2009-12/msg01079.html
>
>PLEASE be precise when reporting problems. Returned from where?
>1.7.9? A snapshot from a week ago? A snapshot from a day ago?
From the time I reported the bug in the link. This bug behaves
identically. Should I describe it again or can you click the link?
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 22:00 ` Bengt Larsson
@ 2011-12-09 5:56 ` Christopher Faylor
2011-12-09 11:58 ` Bengt Larsson
0 siblings, 1 reply; 93+ messages in thread
From: Christopher Faylor @ 2011-12-09 5:56 UTC (permalink / raw)
To: cygwin
On Thu, Dec 08, 2011 at 11:00:11PM +0100, Bengt Larsson wrote:
>Christopher Faylor wrote:
>>On Thu, Dec 08, 2011 at 05:06:21PM +0100, Bengt Larsson wrote:
>>>With the DLL from 20111208, a bug seems to have returned:
>>>
>>>Wildcard match fail from a windows shell with non-ASCII characters
>>>
>>>http://cygwin.com/ml/cygwin/2009-12/msg01079.html
>>
>>PLEASE be precise when reporting problems. Returned from where?
>>1.7.9? A snapshot from a week ago? A snapshot from a day ago?
>
From the time I reported the bug in the link. This bug behaves
>identically. Should I describe it again or can you click the link?
Your use of "seem to have returned" implies that the problem went away
at some point. Since the above link is from a time when the problem was
extant it isn't really useful to point at it.
Again, what would be useful is some hint of when you think the problem
went away. Again, if you are reporting that it worked in 1.7.9 but
stopped working in a snapshot then that is something useful to know. If
you are just saying that you reported a bug two years ago and you notice
that the bug is still there, that is not something that we urgently need
to fix in 1.7.10 since it isn't a regression.
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 7:56 ` marco atzeri
@ 2011-12-09 6:14 ` marco atzeri
2011-12-11 6:34 ` Christopher Faylor
0 siblings, 1 reply; 93+ messages in thread
From: marco atzeri @ 2011-12-09 6:14 UTC (permalink / raw)
To: cygwin
On 12/7/2011 8:56 AM, marco atzeri wrote:
> For the spinning problem I put the test case here:
>
> http://matzeri.altervista.org/works/test_case/prova2.tar.bz2
>
> running ./system_test.sh
> some of the tests should dump and return.
>
> ++ ./xprobe_3dnow.exe
> ./system_test.sh: line 14: 3256 Illegal instruction (core dumped)
> ./xprobe_3dnow.exe
>
> on 20111124 that works, while from 20111129 to 20111207 the
> programs never return and stay frozen.
> At least on my CYGWIN_NT-6.1-WOW64
>
> vendor_id : GenuineIntel
> cpu family : 6
> model : 37
> model name : Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz
> stepping : 5
> cpu MHz : 2394
> cache size : 256 KB
> fpu : yes
> fpu_exception : yes
> cpuid level : 11
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni
> dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2
> popcnt aes lahf_lm
> TLB size : 0 4K pages
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
The issue is still present from 20111129 to current CVS (fith select).
Any clue ?
I also noticed on another program that on crashing it frozes
instead of return.
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-07 11:19 ` Corinna Vinschen
@ 2011-12-09 6:19 ` Yaakov (Cygwin/X)
0 siblings, 0 replies; 93+ messages in thread
From: Yaakov (Cygwin/X) @ 2011-12-09 6:19 UTC (permalink / raw)
To: cygwin
On Wed, 2011-12-07 at 12:18 +0100, Corinna Vinschen wrote:
> On Dec 7 04:33, Yaakov (Cygwin/X) wrote:
> > On Tue, 2011-12-06 at 22:08 -0500, Christopher Faylor wrote:
> > > On Tue, Dec 06, 2011 at 06:45:35PM +0100, Corinna Vinschen wrote:
> > > >On Dec 6 15:39, marco atzeri wrote:
> > > >> On 12/6/2011 10:37 AM, Corinna Vinschen wrote:
> > > >> >A lot of changes and fixes have been made in Cygwin since 1.7.9 has
> > > >> >been released, so we're looking forward to release Cygwin 1.7.10 soon.
> > > >> >[...]
> > > >>
> > > >> Hi Corinna,
> > > >> I have the impression that 20111124 is working better than 20111129,
> > > >> and that 20111204 and 05 have some additional problems.
> > > >>
> > > >> On 20111129, building atlas on W7/x64 I see the custom config
> > > >> spinning and never ending, while on 20111124 is goes smooth.
> > > >
> > > >I can't say a lot about the FIFO stuff, but as far as these weird hangs,
> > > >busy or not busy, are concerned, they were one of the problems we
> > > >tackled in the last couple of days.
> > >
> > > The FIFO problem will be fixed in the next snapshot.
> >
> > Are you sure? I'm now unable to build any KDE4 packages due to a "hang"
> > in automoc4[1]. strace attached.
>
> And it worked with the previous snapshot? I don't see automoc4 using
> fifos in the strace.
I was referring more to the "weird hangs" above. In any case, automoc4
still doesn't work with CVS HEAD (including tonight's "fifth time's the
charm" commit).
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-09 5:56 ` Christopher Faylor
@ 2011-12-09 11:58 ` Bengt Larsson
2011-12-14 12:28 ` Corinna Vinschen
0 siblings, 1 reply; 93+ messages in thread
From: Bengt Larsson @ 2011-12-09 11:58 UTC (permalink / raw)
To: cygwin
Christopher Faylor wrote:
>On Thu, Dec 08, 2011 at 11:00:11PM +0100, Bengt Larsson wrote:
>>Christopher Faylor wrote:
>>>On Thu, Dec 08, 2011 at 05:06:21PM +0100, Bengt Larsson wrote:
>>>>With the DLL from 20111208, a bug seems to have returned:
>>>>
>>>>Wildcard match fail from a windows shell with non-ASCII characters
>>>>
>>>>http://cygwin.com/ml/cygwin/2009-12/msg01079.html
>>>
>>>PLEASE be precise when reporting problems. Returned from where?
>>>1.7.9? A snapshot from a week ago? A snapshot from a day ago?
>>
>From the time I reported the bug in the link. This bug behaves
>>identically. Should I describe it again or can you click the link?
>
>Your use of "seem to have returned" implies that the problem went away
>at some point. Since the above link is from a time when the problem was
>extant it isn't really useful to point at it.
>
>Again, what would be useful is some hint of when you think the problem
>went away. Again, if you are reporting that it worked in 1.7.9 but
>stopped working in a snapshot then that is something useful to know.
Yes. That is what I'm reporting. It worked in 1.7.9 but had stopped
working in the snapshot from 20111208.
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-09 6:14 ` marco atzeri
@ 2011-12-11 6:34 ` Christopher Faylor
2011-12-11 7:07 ` marco atzeri
` (2 more replies)
0 siblings, 3 replies; 93+ messages in thread
From: Christopher Faylor @ 2011-12-11 6:34 UTC (permalink / raw)
To: cygwin
On Fri, Dec 09, 2011 at 07:14:13AM +0100, marco atzeri wrote:
>On 12/7/2011 8:56 AM, marco atzeri wrote:
>> For the spinning problem I put the test case here:
>>
>> http://matzeri.altervista.org/works/test_case/prova2.tar.bz2
>>
>> running ./system_test.sh
>> some of the tests should dump and return.
>>
>> ++ ./xprobe_3dnow.exe
>> ./system_test.sh: line 14: 3256 Illegal instruction (core dumped)
>> ./xprobe_3dnow.exe
>>
>> on 20111124 that works, while from 20111129 to 20111207 the
>> programs never return and stay frozen.
>> At least on my CYGWIN_NT-6.1-WOW64
>>
>> vendor_id : GenuineIntel
>> cpu family : 6
>> model : 37
>> model name : Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz
>> stepping : 5
>> cpu MHz : 2394
>> cache size : 256 KB
>> fpu : yes
>> fpu_exception : yes
>> cpuid level : 11
>> wp : yes
>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni
>> dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2
>> popcnt aes lahf_lm
>> TLB size : 0 4K pages
>> clflush size : 64
>> cache_alignment : 64
>> address sizes : 36 bits physical, 48 bits virtual
>> power management:
>
>The issue is still present from 20111129 to current CVS (fith select).
>Any clue ?
The hanging problem should be fixed in recent snapshots.
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-11 6:34 ` Christopher Faylor
@ 2011-12-11 7:07 ` marco atzeri
2011-12-11 19:25 ` Christopher Faylor
2011-12-11 21:00 ` Yaakov (Cygwin/X)
2011-12-13 18:48 ` Jim Reisert AD1C
2 siblings, 1 reply; 93+ messages in thread
From: marco atzeri @ 2011-12-11 7:07 UTC (permalink / raw)
To: cygwin
On 12/11/2011 7:34 AM, Christopher Faylor wrote:
>> The issue is still present from 20111129 to current CVS (fith select).
>> Any clue ?
>
> The hanging problem should be fixed in recent snapshots.
>
> cgf
>
it was fixed on yesterday CVS
Thanks
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-11 7:07 ` marco atzeri
@ 2011-12-11 19:25 ` Christopher Faylor
0 siblings, 0 replies; 93+ messages in thread
From: Christopher Faylor @ 2011-12-11 19:25 UTC (permalink / raw)
To: cygwin
On Sun, Dec 11, 2011 at 08:07:12AM +0100, marco atzeri wrote:
>On 12/11/2011 7:34 AM, Christopher Faylor wrote:
>
>>> The issue is still present from 20111129 to current CVS (fith select).
>>> Any clue ?
>>
>> The hanging problem should be fixed in recent snapshots.
>
>it was fixed on yesterday CVS
Actually, it should have been fixed a couple of days ago.
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-11 6:34 ` Christopher Faylor
2011-12-11 7:07 ` marco atzeri
@ 2011-12-11 21:00 ` Yaakov (Cygwin/X)
2011-12-12 1:11 ` Christopher Faylor
2011-12-13 18:48 ` Jim Reisert AD1C
2 siblings, 1 reply; 93+ messages in thread
From: Yaakov (Cygwin/X) @ 2011-12-11 21:00 UTC (permalink / raw)
To: cygwin
On Sun, 2011-12-11 at 01:34 -0500, Christopher Faylor wrote:
> The hanging problem should be fixed in recent snapshots.
Unfortunately not for automoc4. :-(
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 8:48 ` Corinna Vinschen
@ 2011-12-11 22:03 ` Samuel Thibault
2011-12-11 23:48 ` Christopher Faylor
2011-12-12 8:59 ` Corinna Vinschen
0 siblings, 2 replies; 93+ messages in thread
From: Samuel Thibault @ 2011-12-11 22:03 UTC (permalink / raw)
To: cygwin
Corinna Vinschen, le Thu 08 Dec 2011 09:47:45 +0100, a écrit :
> Too bad. In that case, Samuel, can you please have a closer look to
> see what broke brltty?
The switch to mintty, simply. Brltty uses ReadConsoleOutputCharacter()
to get the text from consoles, I bet mintty does not implement this.
Lars thus needs cygwin to be able to run from a standard windows console
too.
> I have not the faintest idea how to test it
Install brltty, and run
brltty -b xw
When the focus is on a windows console, a window on the top of the
screen will show up, representing the output that would show up on a
braille device.
> and how to see if it works or not.
Try to switch to mintty, the window will disappear, because
ReadConsoleOutputCharacter will stop working.
Samuel
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-11 22:03 ` Samuel Thibault
@ 2011-12-11 23:48 ` Christopher Faylor
2011-12-12 8:59 ` Corinna Vinschen
1 sibling, 0 replies; 93+ messages in thread
From: Christopher Faylor @ 2011-12-11 23:48 UTC (permalink / raw)
To: cygwin
On Sun, Dec 11, 2011 at 09:32:39PM +0100, Samuel Thibault wrote:
>Corinna Vinschen, le Thu 08 Dec 2011 09:47:45 +0100, a ?crit :
>> Too bad. In that case, Samuel, can you please have a closer look to
>> see what broke brltty?
>
>The switch to mintty, simply. Brltty uses ReadConsoleOutputCharacter()
>to get the text from consoles, I bet mintty does not implement this.
>Lars thus needs cygwin to be able to run from a standard windows console
>too.
>
>> I have not the faintest idea how to test it
>
>Install brltty, and run
>
>brltty -b xw
>
>When the focus is on a windows console, a window on the top of the
>screen will show up, representing the output that would show up on a
>braille device.
>
>> and how to see if it works or not.
>
>Try to switch to mintty, the window will disappear, because
>ReadConsoleOutputCharacter will stop working.
So, then, don't use mintty with brltty. If it is an issue, you as the
package maintainer, should provide a way to start brltty from a Windows
console.
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-11 21:00 ` Yaakov (Cygwin/X)
@ 2011-12-12 1:11 ` Christopher Faylor
2011-12-12 1:22 ` Christopher Faylor
0 siblings, 1 reply; 93+ messages in thread
From: Christopher Faylor @ 2011-12-12 1:11 UTC (permalink / raw)
To: cygwin
On Sun, Dec 11, 2011 at 02:59:49PM -0600, Yaakov (Cygwin/X) wrote:
>On Sun, 2011-12-11 at 01:34 -0500, Christopher Faylor wrote:
>> The hanging problem should be fixed in recent snapshots.
>
>Unfortunately not for automoc4. :-(
How do you duplicate your problem?
bash-4.1$ automoc4
bash: automoc4: command not found
bash-4.1$ cygcheck -p automoc4
Found 0 matches for automoc4
Also, in what snapshot did this problem first manifest?
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-12 1:11 ` Christopher Faylor
@ 2011-12-12 1:22 ` Christopher Faylor
0 siblings, 0 replies; 93+ messages in thread
From: Christopher Faylor @ 2011-12-12 1:22 UTC (permalink / raw)
To: cygwin
On Sun, Dec 11, 2011 at 08:10:15PM -0500, Christopher Faylor wrote:
>On Sun, Dec 11, 2011 at 02:59:49PM -0600, Yaakov (Cygwin/X) wrote:
>>On Sun, 2011-12-11 at 01:34 -0500, Christopher Faylor wrote:
>>> The hanging problem should be fixed in recent snapshots.
>>
>>Unfortunately not for automoc4. :-(
>
>How do you duplicate your problem?
>
> bash-4.1$ automoc4
> bash: automoc4: command not found
> bash-4.1$ cygcheck -p automoc4
> Found 0 matches for automoc4
>
>Also, in what snapshot did this problem first manifest?
And, also, more strace output would be useful from the snapshot which
will be showing up in the next ten minutes or so but please make sure
that you use the strace.exe from the latest snapshot. There have been
some changes made to strace.exe to accommodate corresponding changes in
the latest cygwin1.dll.
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-11 22:03 ` Samuel Thibault
2011-12-11 23:48 ` Christopher Faylor
@ 2011-12-12 8:59 ` Corinna Vinschen
2012-01-08 21:46 ` Lars Bjørndal
1 sibling, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-12 8:59 UTC (permalink / raw)
To: cygwin
On Dec 11 21:32, Samuel Thibault wrote:
> Corinna Vinschen, le Thu 08 Dec 2011 09:47:45 +0100, a écrit :
> > Too bad. In that case, Samuel, can you please have a closer look to
> > see what broke brltty?
>
> The switch to mintty, simply. Brltty uses ReadConsoleOutputCharacter()
> to get the text from consoles, I bet mintty does not implement this.
> Lars thus needs cygwin to be able to run from a standard windows console
> too.
Lars wrote in http://cygwin.com/ml/cygwin/2011-12/msg00124.html
that he always starts Cygwin from cmd.exe.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-08 14:32 ` Enrico Forestieri
@ 2011-12-12 13:27 ` Corinna Vinschen
2011-12-12 23:08 ` Enrico Forestieri
0 siblings, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-12 13:27 UTC (permalink / raw)
To: cygwin
On Dec 8 14:31, Enrico Forestieri wrote:
> Enrico Forestieri writes:
> >
> > However, I experimented a bit with the last snapshot, and even using Greek
> > or Japanese characters in file names, lyx seems to be working fine.
>
> Sorry, it was a cursory test. Actually, cygwin_conv_path is only called
> for absolute paths. Using an absolute Windows path containing any nonascii
> character, makes lyx fail miserably.
>
> I know this is a no-no for you (even if absolute Windows paths can sneak in
> by opening a document created by a Windows version), so I will not insist,
> but knowlingly breaking backward compatibility is not nice.
I'm not sure what to do here. Breaking backward compatibility is not
nice, you're right, but the current behaviour really doesn't make much
sense. The easiest way to handle this is to revert the change, but
still...
Would it be ok if it works the old way (WIN_A uses the Cygwin codeset)
for applications built under 1.7.9 and earlier, and the new way (WIN_A
uses Win32 ANSI/OEM codepage) for applications built under 1.7.10 and
later? That means the current lyx continues to work and you can patch
lyx upstream accordingly to follow the new behaviour.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-12 13:27 ` Corinna Vinschen
@ 2011-12-12 23:08 ` Enrico Forestieri
2011-12-13 15:12 ` Corinna Vinschen
0 siblings, 1 reply; 93+ messages in thread
From: Enrico Forestieri @ 2011-12-12 23:08 UTC (permalink / raw)
To: cygwin
Corinna Vinschen writes:
>
> Would it be ok if it works the old way (WIN_A uses the Cygwin codeset)
> for applications built under 1.7.9 and earlier, and the new way (WIN_A
> uses Win32 ANSI/OEM codepage) for applications built under 1.7.10 and
> later? That means the current lyx continues to work and you can patch
> lyx upstream accordingly to follow the new behaviour.
This would certainly preserve backward compatibility, so it is Ok.
However, may I suggest to add two other enums, namely, CCP_WIN_TO_POSIX
and CCP_POSIX_TO_WIN, that preserve encoding?
This is also useful, as not always one has to convert to/from Windows
style paths for calling native APIs.
Thanks,
--
Enrico
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-12 23:08 ` Enrico Forestieri
@ 2011-12-13 15:12 ` Corinna Vinschen
0 siblings, 0 replies; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-13 15:12 UTC (permalink / raw)
To: cygwin
On Dec 12 23:07, Enrico Forestieri wrote:
> Corinna Vinschen writes:
> >
> > Would it be ok if it works the old way (WIN_A uses the Cygwin codeset)
> > for applications built under 1.7.9 and earlier, and the new way (WIN_A
> > uses Win32 ANSI/OEM codepage) for applications built under 1.7.10 and
> > later? That means the current lyx continues to work and you can patch
> > lyx upstream accordingly to follow the new behaviour.
>
> This would certainly preserve backward compatibility, so it is Ok.
> However, may I suggest to add two other enums, namely, CCP_WIN_TO_POSIX
> and CCP_POSIX_TO_WIN, that preserve encoding?
> This is also useful, as not always one has to convert to/from Windows
> style paths for calling native APIs.
Never mind. I reverted the change so the WIN_A conversion will stick
to the Cygwin codeset.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-11 6:34 ` Christopher Faylor
2011-12-11 7:07 ` marco atzeri
2011-12-11 21:00 ` Yaakov (Cygwin/X)
@ 2011-12-13 18:48 ` Jim Reisert AD1C
2 siblings, 0 replies; 93+ messages in thread
From: Jim Reisert AD1C @ 2011-12-13 18:48 UTC (permalink / raw)
To: The Cygwin Mailing List
On Sat, Dec 10, 2011 at 11:34 PM, Christopher Faylor wrote:
> The hanging problem should be fixed in recent snapshots.
I can confirm this in the 12/12 and 12/13 snapshots - thanks!
Cygwin-X is working fine again without any hangs.
--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-09 11:58 ` Bengt Larsson
@ 2011-12-14 12:28 ` Corinna Vinschen
2011-12-15 0:25 ` Bengt Larsson
0 siblings, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-14 12:28 UTC (permalink / raw)
To: cygwin
On Dec 9 12:58, Bengt Larsson wrote:
> Christopher Faylor wrote:
> >On Thu, Dec 08, 2011 at 11:00:11PM +0100, Bengt Larsson wrote:
> >>Christopher Faylor wrote:
> >>>On Thu, Dec 08, 2011 at 05:06:21PM +0100, Bengt Larsson wrote:
> >>>>With the DLL from 20111208, a bug seems to have returned:
> >>>>
> >>>>Wildcard match fail from a windows shell with non-ASCII characters
> >>>>
> >>>>http://cygwin.com/ml/cygwin/2009-12/msg01079.html
> >>>
> >>>PLEASE be precise when reporting problems. Returned from where?
> >>>1.7.9? A snapshot from a week ago? A snapshot from a day ago?
> >>
> >>From the time I reported the bug in the link. This bug behaves
> >>identically. Should I describe it again or can you click the link?
> >
> >Your use of "seem to have returned" implies that the problem went away
> >at some point. Since the above link is from a time when the problem was
> >extant it isn't really useful to point at it.
> >
> >Again, what would be useful is some hint of when you think the problem
> >went away. Again, if you are reporting that it worked in 1.7.9 but
> >stopped working in a snapshot then that is something useful to know.
>
> Yes. That is what I'm reporting. It worked in 1.7.9 but had stopped
> working in the snapshot from 20111208.
This will probably be fixed in the next snapshot (not in 20111213).
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-14 12:28 ` Corinna Vinschen
@ 2011-12-15 0:25 ` Bengt Larsson
0 siblings, 0 replies; 93+ messages in thread
From: Bengt Larsson @ 2011-12-15 0:25 UTC (permalink / raw)
To: cygwin
Corinna Vinschen wrote:
>On Dec 9 12:58, Bengt Larsson wrote:
>> Christopher Faylor wrote:
>> >On Thu, Dec 08, 2011 at 11:00:11PM +0100, Bengt Larsson wrote:
>> >>Christopher Faylor wrote:
>> >>>On Thu, Dec 08, 2011 at 05:06:21PM +0100, Bengt Larsson wrote:
>> >>>>With the DLL from 20111208, a bug seems to have returned:
>> >>>>
>> >>>>Wildcard match fail from a windows shell with non-ASCII characters
>> >>>>
>> >>>>http://cygwin.com/ml/cygwin/2009-12/msg01079.html
>> >>>
>> >>>PLEASE be precise when reporting problems. Returned from where?
>> >>>1.7.9? A snapshot from a week ago? A snapshot from a day ago?
>> >>
>> >>From the time I reported the bug in the link. This bug behaves
>> >>identically. Should I describe it again or can you click the link?
>> >
>> >Your use of "seem to have returned" implies that the problem went away
>> >at some point. Since the above link is from a time when the problem was
>> >extant it isn't really useful to point at it.
>> >
>> >Again, what would be useful is some hint of when you think the problem
>> >went away. Again, if you are reporting that it worked in 1.7.9 but
>> >stopped working in a snapshot then that is something useful to know.
>>
>> Yes. That is what I'm reporting. It worked in 1.7.9 but had stopped
>> working in the snapshot from 20111208.
>
>This will probably be fixed in the next snapshot (not in 20111213).
Thank you.
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-06 10:00 [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10 Corinna Vinschen
` (8 preceding siblings ...)
2011-12-08 16:06 ` Bengt Larsson
@ 2011-12-22 7:09 ` Shaddy Baddah
2011-12-22 9:26 ` Corinna Vinschen
9 siblings, 1 reply; 93+ messages in thread
From: Shaddy Baddah @ 2011-12-22 7:09 UTC (permalink / raw)
To: cygwin
Hi,
On 06/12/11 20:37, Corinna Vinschen wrote:
> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
> been released, so we're looking forward to release Cygwin 1.7.10 soon.
>
> Please test the latest developer snapshots at http://cygwin.com/snapshots/
> which should have "Release Candidate" quality.
I'm having a problem with the most recent snapshot (at time of
writing), 2011-12-19 17:48:27 UTC. A regular non-privileged (not in
Administrators) user is unable to execute any commands from within a
Cygwin process itself.
The following copy/paste from a Command Prompt session should
illustrate the problem:
c:\Users\Public\portapps\cygwin\bin>ls /var
cache empty games lib log run tmp
c:\Users\Public\portapps\cygwin\bin>sh -c "/bin/ls /var"
sh: /bin/ls: Permission denied
c:\Users\Public\portapps\cygwin\bin>id -a
uid=1007(portapps) gid=513(None) groups=513(None),545(Users)
c:\Users\Public\portapps\cygwin\bin>sh -c "/bin/id -a"
sh: /bin/id: Permission denied
I am running Windows 7 64bit.
I have another user, who is in the Administrators group, but not being
run via “Run as administratorâ€, for whom it all works fine:
c:\Users\Public\portapps\cygwin\bin>ls /var
cache empty games lib log run tmp
c:\Users\Public\portapps\cygwin\bin>sh -c "/bin/ls /var"
cache empty games lib log run tmp
c:\Users\Public\portapps\cygwin\bin>id -a
uid=42037(sbaddah) gid=10513(Domain Users) groups=10513(Domain
Users),545(Users)
,...(quite a number, 10+ domain groups)
Using this user, I was able to verify that a problem I have described
in the thread of http://cygwin.com/ml/cygwin/2011-12/msg00460.html is
not resolved by 1.7.10.
I mention this because I had upgraded to the snapshot specifically
because of that problem. But I'll keep further updates about it on
that thread.
Regards,
Shaddy
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-22 7:09 ` Shaddy Baddah
@ 2011-12-22 9:26 ` Corinna Vinschen
2011-12-22 10:12 ` Shaddy Baddah
0 siblings, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-22 9:26 UTC (permalink / raw)
To: cygwin
On Dec 22 18:09, Shaddy Baddah wrote:
> Hi,
>
> On 06/12/11 20:37, Corinna Vinschen wrote:
> > A lot of changes and fixes have been made in Cygwin since 1.7.9 has
> > been released, so we're looking forward to release Cygwin 1.7.10 soon.
> >
> > Please test the latest developer snapshots at http://cygwin.com/snapshots/
> > which should have "Release Candidate" quality.
>
> I'm having a problem with the most recent snapshot (at time of
> writing), 2011-12-19 17:48:27 UTC. A regular non-privileged (not in
> Administrators) user is unable to execute any commands from within a
> Cygwin process itself.
>
> The following copy/paste from a Command Prompt session should
> illustrate the problem:
>
> c:\Users\Public\portapps\cygwin\bin>ls /var
> cache empty games lib log run tmp
>
> c:\Users\Public\portapps\cygwin\bin>sh -c "/bin/ls /var"
> sh: /bin/ls: Permission denied
>
> c:\Users\Public\portapps\cygwin\bin>id -a
> uid=1007(portapps) gid=513(None) groups=513(None),545(Users)
>
> c:\Users\Public\portapps\cygwin\bin>sh -c "/bin/id -a"
> sh: /bin/id: Permission denied
>
> I am running Windows 7 64bit.
Works for me. I tried this with a non-admin domain member account
as well as with a non-admin local SAM account. Did you check the
actual permissions?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-22 9:26 ` Corinna Vinschen
@ 2011-12-22 10:12 ` Shaddy Baddah
2011-12-22 10:45 ` Corinna Vinschen
2011-12-22 18:43 ` Buchbinder, Barry (NIH/NIAID) [E]
0 siblings, 2 replies; 93+ messages in thread
From: Shaddy Baddah @ 2011-12-22 10:12 UTC (permalink / raw)
To: cygwin
Hi Corinna,
On 22/12/11 20:25, Corinna Vinschen wrote:
> On Dec 22 18:09, Shaddy Baddah wrote:
>> Hi,
>>
>> On 06/12/11 20:37, Corinna Vinschen wrote:
>>> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
>>> been released, so we're looking forward to release Cygwin 1.7.10 soon.
>>>
>>> Please test the latest developer snapshots at http://cygwin.com/snapshots/
>>> which should have "Release Candidate" quality.
>>
>> I'm having a problem with the most recent snapshot (at time of
>> writing), 2011-12-19 17:48:27 UTC. A regular non-privileged (not in
>> Administrators) user is unable to execute any commands from within a
>> Cygwin process itself.
>>
>> The following copy/paste from a Command Prompt session should
>> illustrate the problem:
>>
>> c:\Users\Public\portapps\cygwin\bin>ls /var
>> cache empty games lib log run tmp
>>
>> c:\Users\Public\portapps\cygwin\bin>sh -c "/bin/ls /var"
>> sh: /bin/ls: Permission denied
>>
>> c:\Users\Public\portapps\cygwin\bin>id -a
>> uid=1007(portapps) gid=513(None) groups=513(None),545(Users)
>>
>> c:\Users\Public\portapps\cygwin\bin>sh -c "/bin/id -a"
>> sh: /bin/id: Permission denied
>>
>> I am running Windows 7 64bit.
>
> Works for me. I tried this with a non-admin domain member account
> as well as with a non-admin local SAM account. Did you check the
> actual permissions?
>
Yes. They all look right to me. Here is what I see for ls for example:
c:\Users\Public\portapps\cygwin\bin>ls -l /bin/ls
-rwxr-xr-x 1 portapps None 128526 Oct 28 15:00 /bin/ls
c:\Users\Public\portapps\cygwin\bin>sh -c "/bin/ls -l /bin/ls"
sh: /bin/ls: Permission denied
I install all packages as the portapps user, keeping the install
separate from my ordinary user that I run everyday.
At this point, I should make a disclosure. To do this as a
non-Administrator grouped user, I must rename setup.exe to
cygpkg.exe. This defeats the later Windows releases abilities to
automatically detect installer applications by their name, and force
privilege elevation. This is something that I have been meaning to
open up a discussion about for sometime (or may have tried to already,
I can't recall), but I'll leave it to stand at the moment.
In anycase, it has not caused me any issue until I upgraded from 1.7.9
now to the latest 1.7.10 snapshot. And whilst this unconventional step
may be a factor, at this time I'd find that dubious.
I don't have time right at this moment, but later I maybe able to help
with some DLL debugging (I've done this in the past for problems such
as with
http://www.cygwin.com/ml/cygwin-developers/2010-02/msg00052.html).
Thanks,
Shaddy
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-22 10:12 ` Shaddy Baddah
@ 2011-12-22 10:45 ` Corinna Vinschen
2011-12-22 11:12 ` Shaddy Baddah
2011-12-22 18:43 ` Buchbinder, Barry (NIH/NIAID) [E]
1 sibling, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-22 10:45 UTC (permalink / raw)
To: cygwin
On Dec 22 21:12, Shaddy Baddah wrote:
> On 22/12/11 20:25, Corinna Vinschen wrote:
> > On Dec 22 18:09, Shaddy Baddah wrote:
> >> On 06/12/11 20:37, Corinna Vinschen wrote:
> >>> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
> >>> been released, so we're looking forward to release Cygwin 1.7.10 soon.
> >>>
> >>> Please test the latest developer snapshots at http://cygwin.com/snapshots/
> >>> which should have "Release Candidate" quality.
> >>
> >> I'm having a problem with the most recent snapshot (at time of
> >> writing), 2011-12-19 17:48:27 UTC. A regular non-privileged (not in
> >> Administrators) user is unable to execute any commands from within a
> >> Cygwin process itself.
> >>
> >> The following copy/paste from a Command Prompt session should
> >> illustrate the problem:
> >>
> >> c:\Users\Public\portapps\cygwin\bin>ls /var
> >> cache empty games lib log run tmp
> >>
> >> c:\Users\Public\portapps\cygwin\bin>sh -c "/bin/ls /var"
> >> sh: /bin/ls: Permission denied
> >>
> >> c:\Users\Public\portapps\cygwin\bin>id -a
> >> uid=1007(portapps) gid=513(None) groups=513(None),545(Users)
> >>
> >> c:\Users\Public\portapps\cygwin\bin>sh -c "/bin/id -a"
> >> sh: /bin/id: Permission denied
> >>
> >> I am running Windows 7 64bit.
> >
> > Works for me. I tried this with a non-admin domain member account
> > as well as with a non-admin local SAM account. Did you check the
> > actual permissions?
> >
>
> Yes. They all look right to me. Here is what I see for ls for example:
>
> c:\Users\Public\portapps\cygwin\bin>ls -l /bin/ls
> -rwxr-xr-x 1 portapps None 128526 Oct 28 15:00 /bin/ls
>
> c:\Users\Public\portapps\cygwin\bin>sh -c "/bin/ls -l /bin/ls"
> sh: /bin/ls: Permission denied
> [...]
> I don't have time right at this moment, but later I maybe able to help
> with some DLL debugging
Does it really work if you replace the DLL with 1.7.9 again? If so,
you could try to find out which snapshot introduced the problem for you.
Also, you could start the whole thing from strace to see what happens:
CMD> strace -o my.trace sh -c "/bin/id -a"
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-22 10:45 ` Corinna Vinschen
@ 2011-12-22 11:12 ` Shaddy Baddah
2011-12-22 11:20 ` Corinna Vinschen
0 siblings, 1 reply; 93+ messages in thread
From: Shaddy Baddah @ 2011-12-22 11:12 UTC (permalink / raw)
To: cygwin
Hi Corinna,
On 22/12/11 21:44, Corinna Vinschen wrote:
> On Dec 22 21:12, Shaddy Baddah wrote:
>> On 22/12/11 20:25, Corinna Vinschen wrote:
>>> On Dec 22 18:09, Shaddy Baddah wrote:
>>>> On 06/12/11 20:37, Corinna Vinschen wrote:
>>>>> A lot of changes and fixes have been made in Cygwin since 1.7.9 has
>>>>> been released, so we're looking forward to release Cygwin 1.7.10 soon.
>>>>>
>>>>> Please test the latest developer snapshots at http://cygwin.com/snapshots/
>>>>> which should have "Release Candidate" quality.
>>>>
>>>> I'm having a problem with the most recent snapshot (at time of
>>>> writing), 2011-12-19 17:48:27 UTC. A regular non-privileged (not in
>>>> Administrators) user is unable to execute any commands from within a
>>>> Cygwin process itself.
>>>>
>>>> The following copy/paste from a Command Prompt session should
>>>> illustrate the problem:
>>>>
>>>> c:\Users\Public\portapps\cygwin\bin>ls /var
>>>> cache empty games lib log run tmp
>>>>
>>>> c:\Users\Public\portapps\cygwin\bin>sh -c "/bin/ls /var"
>>>> sh: /bin/ls: Permission denied
>>>>
>>>> c:\Users\Public\portapps\cygwin\bin>id -a
>>>> uid=1007(portapps) gid=513(None) groups=513(None),545(Users)
>>>>
>>>> c:\Users\Public\portapps\cygwin\bin>sh -c "/bin/id -a"
>>>> sh: /bin/id: Permission denied
>>>>
>>>> I am running Windows 7 64bit.
>>>
>>> Works for me. I tried this with a non-admin domain member account
>>> as well as with a non-admin local SAM account. Did you check the
>>> actual permissions?
>>>
>>
>> Yes. They all look right to me. Here is what I see for ls for example:
>>
>> c:\Users\Public\portapps\cygwin\bin>ls -l /bin/ls
>> -rwxr-xr-x 1 portapps None 128526 Oct 28 15:00 /bin/ls
>>
>> c:\Users\Public\portapps\cygwin\bin>sh -c "/bin/ls -l /bin/ls"
>> sh: /bin/ls: Permission denied
>> [...]
>> I don't have time right at this moment, but later I maybe able to help
>> with some DLL debugging
>
> Does it really work if you replace the DLL with 1.7.9 again? If so,
> you could try to find out which snapshot introduced the problem for you.
>
> Also, you could start the whole thing from strace to see what happens:
>
> CMD> strace -o my.trace sh -c "/bin/id -a"
I've done this with 1.7.10 still in place, once with portapps user
(the failure case), and with my own regular (domain) user. Comparing
the two outputs, there is an obvious ERROR_ACCESS_DENIED error in the
failure case:
69 126706 [main] sh 3824 build_env: envp 0x61266AB4, envc 47
37 126743 [main] sh 3824 child_info::child_info: subproc_ready 0x234
589 127332 [main] sh 3824 seterrno_from_win_error:
/netrel/src/cygwin-snapshot-20111219-1/winsup/cygwin/spawn.cc:692
windows error 5
59 127391 [main] sh 3824 geterrno_from_win_error: windows error 5 ==
errno 13
74 127465 [main] sh 3824 child_info_spawn::worker: CreateProcess
failed, Win32 error 5
196 127661 [main] sh 3824 stat64: entering
Any further hints?
Regards,
Shaddy
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-22 11:12 ` Shaddy Baddah
@ 2011-12-22 11:20 ` Corinna Vinschen
2011-12-22 13:08 ` Shaddy Baddah
0 siblings, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-22 11:20 UTC (permalink / raw)
To: cygwin
On Dec 22 22:11, Shaddy Baddah wrote:
> On 22/12/11 21:44, Corinna Vinschen wrote:
> > Does it really work if you replace the DLL with 1.7.9 again? If so,
> > you could try to find out which snapshot introduced the problem for you.
> >
> > Also, you could start the whole thing from strace to see what happens:
> >
> > CMD> strace -o my.trace sh -c "/bin/id -a"
>
> I've done this with 1.7.10 still in place, once with portapps user
> (the failure case), and with my own regular (domain) user. Comparing
> the two outputs, there is an obvious ERROR_ACCESS_DENIED error in the
> failure case:
>
> 69 126706 [main] sh 3824 build_env: envp 0x61266AB4, envc 47
> 37 126743 [main] sh 3824 child_info::child_info: subproc_ready 0x234
> 589 127332 [main] sh 3824 seterrno_from_win_error:
> /netrel/src/cygwin-snapshot-20111219-1/winsup/cygwin/spawn.cc:692
> windows error 5
> 59 127391 [main] sh 3824 geterrno_from_win_error: windows error 5 ==
> errno 13
> 74 127465 [main] sh 3824 child_info_spawn::worker: CreateProcess
> failed, Win32 error 5
> 196 127661 [main] sh 3824 stat64: entering
>
> Any further hints?
Well, CreateProcess fails with "access denied". There must be a reason
for that, but I don't know what it is and I don't know what to look for.
Try bisecting the snapshots.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-22 11:20 ` Corinna Vinschen
@ 2011-12-22 13:08 ` Shaddy Baddah
2011-12-22 14:34 ` Corinna Vinschen
0 siblings, 1 reply; 93+ messages in thread
From: Shaddy Baddah @ 2011-12-22 13:08 UTC (permalink / raw)
To: cygwin
Hi Corinna,
On 22/12/11 22:19, Corinna Vinschen wrote:
> On Dec 22 22:11, Shaddy Baddah wrote:
>> On 22/12/11 21:44, Corinna Vinschen wrote:
>>> Does it really work if you replace the DLL with 1.7.9 again? If so,
>>> you could try to find out which snapshot introduced the problem for you.
>>>
>>> Also, you could start the whole thing from strace to see what happens:
>>>
>>> CMD> strace -o my.trace sh -c "/bin/id -a"
>>
>> I've done this with 1.7.10 still in place, once with portapps user
>> (the failure case), and with my own regular (domain) user. Comparing
>> the two outputs, there is an obvious ERROR_ACCESS_DENIED error in the
>> failure case:
>>
>> 69 126706 [main] sh 3824 build_env: envp 0x61266AB4, envc 47
>> 37 126743 [main] sh 3824 child_info::child_info: subproc_ready 0x234
>> 589 127332 [main] sh 3824 seterrno_from_win_error:
>> /netrel/src/cygwin-snapshot-20111219-1/winsup/cygwin/spawn.cc:692
>> windows error 5
>> 59 127391 [main] sh 3824 geterrno_from_win_error: windows error 5 ==
>> errno 13
>> 74 127465 [main] sh 3824 child_info_spawn::worker: CreateProcess
>> failed, Win32 error 5
>> 196 127661 [main] sh 3824 stat64: entering
>>
>> Any further hints?
>
> Well, CreateProcess fails with "access denied". There must be a reason
> for that, but I don't know what it is and I don't know what to look for.
> Try bisecting the snapshots.
>
Sorry, it was always my intention to try the snapshots. I have got the
domestic duties out of the way now, and managed to determine the last
known good snapshot as the one listed as 2011-12-07 03:13:28 UTC. The
next one, the first known bad one is listed as 2011-12-08 06:55:55
UTC.
In between these there was a check-in of spawn.cc, if that is indeed
the culprit:
Revision 1.317, Wed Dec 7 10:48:17 2011 UTC (2 weeks, 1 day ago) by corinna
Branch: MAIN
CVS Tags: HEAD
Changes since 1.316: +11 -1 lines
* spawn.cc (child_info_spawn::worker): Add CREATE_BREAKAWAY_FROM_JOB
to all spawned processes. Explain why.
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/spawn.cc.diff?r1=1.316&r2=1.317&cvsroot=src
Looks rather innocuous, so don't understand why it is causing me
problems.
Thanks,
Shaddy
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-22 13:08 ` Shaddy Baddah
@ 2011-12-22 14:34 ` Corinna Vinschen
2011-12-22 14:47 ` Shaddy Baddah
0 siblings, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-22 14:34 UTC (permalink / raw)
To: cygwin
On Dec 23 00:07, Shaddy Baddah wrote:
> On 22/12/11 22:19, Corinna Vinschen wrote:
> > On Dec 22 22:11, Shaddy Baddah wrote:
> >> 69 126706 [main] sh 3824 build_env: envp 0x61266AB4, envc 47
> >> 37 126743 [main] sh 3824 child_info::child_info: subproc_ready 0x234
> >> 589 127332 [main] sh 3824 seterrno_from_win_error:
> >> /netrel/src/cygwin-snapshot-20111219-1/winsup/cygwin/spawn.cc:692
> >> windows error 5
> >> 59 127391 [main] sh 3824 geterrno_from_win_error: windows error 5 ==
> >> errno 13
> >> 74 127465 [main] sh 3824 child_info_spawn::worker: CreateProcess
> >> failed, Win32 error 5
> >> 196 127661 [main] sh 3824 stat64: entering
> >
> > Well, CreateProcess fails with "access denied". There must be a reason
> > for that, but I don't know what it is and I don't know what to look for.
> > Try bisecting the snapshots.
> >
> * spawn.cc (child_info_spawn::worker): Add CREATE_BREAKAWAY_FROM_JOB
> to all spawned processes. Explain why.
>
> Looks rather innocuous, so don't understand why it is causing me
> problems.
Indeed. I just tried again on another W7 64 bit machine and it still
works for me. I'm wondering if the culprit is a virus scanner or
something similar running on your system. Can you please check that?
Other than that I might have a solution. I applied a patch which only
adds the CREATE_BREAKAWAY_FROM_JOB flag if the calling process is member
of a job and the job allows a breakaway. It works in my limited
testing, but it would be important to know if it works for you, too, of
course. If you're not set up to build your own Cygwin DLL, please test
the next developer snapshot.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-22 14:34 ` Corinna Vinschen
@ 2011-12-22 14:47 ` Shaddy Baddah
2011-12-22 15:41 ` Corinna Vinschen
0 siblings, 1 reply; 93+ messages in thread
From: Shaddy Baddah @ 2011-12-22 14:47 UTC (permalink / raw)
To: cygwin
On 23/12/11 01:33, Corinna Vinschen wrote:
> On Dec 23 00:07, Shaddy Baddah wrote:
>> On 22/12/11 22:19, Corinna Vinschen wrote:
>>> On Dec 22 22:11, Shaddy Baddah wrote:
>>>> 69 126706 [main] sh 3824 build_env: envp 0x61266AB4, envc 47
>>>> 37 126743 [main] sh 3824 child_info::child_info: subproc_ready 0x234
>>>> 589 127332 [main] sh 3824 seterrno_from_win_error:
>>>> /netrel/src/cygwin-snapshot-20111219-1/winsup/cygwin/spawn.cc:692
>>>> windows error 5
>>>> 59 127391 [main] sh 3824 geterrno_from_win_error: windows error 5 ==
>>>> errno 13
>>>> 74 127465 [main] sh 3824 child_info_spawn::worker: CreateProcess
>>>> failed, Win32 error 5
>>>> 196 127661 [main] sh 3824 stat64: entering
>>>
>>> Well, CreateProcess fails with "access denied". There must be a reason
>>> for that, but I don't know what it is and I don't know what to look for.
>>> Try bisecting the snapshots.
>>>
>> * spawn.cc (child_info_spawn::worker): Add CREATE_BREAKAWAY_FROM_JOB
>> to all spawned processes. Explain why.
>>
>> Looks rather innocuous, so don't understand why it is causing me
>> problems.
>
> Indeed. I just tried again on another W7 64 bit machine and it still
> works for me. I'm wondering if the culprit is a virus scanner or
> something similar running on your system. Can you please check that?
Indeed we do run a virus scanner, McAfee VirusScan
Enterprise. However I can't turn it off by policy. In fact, we run a
desktop environment where there are a small number of actions limited
by policy. But nothing I have encountered so far that is overly
restrictive.
The virus scanner has an extensive access log. It doesn't list
anything with regards to my Cygwin activities that might account for
the problem. But you never know. I might ask our desktop admin
tomorrow if they'll allow me to disable the scanner briefly to test.
>
>
> Other than that I might have a solution. I applied a patch which only
> adds the CREATE_BREAKAWAY_FROM_JOB flag if the calling process is member
> of a job and the job allows a breakaway. It works in my limited
> testing, but it would be important to know if it works for you, too, of
> course. If you're not set up to build your own Cygwin DLL, please test
> the next developer snapshot.
Yes, unfortunately I am not set up at the moment to build dlls, so
I'll eagerly await the next snapshot.
Thanks for all your help in getting this far.
Regards,
Shaddy
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-22 14:47 ` Shaddy Baddah
@ 2011-12-22 15:41 ` Corinna Vinschen
2011-12-23 0:18 ` Shaddy Baddah
0 siblings, 1 reply; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-22 15:41 UTC (permalink / raw)
To: cygwin
On Dec 23 01:47, Shaddy Baddah wrote:
> On 23/12/11 01:33, Corinna Vinschen wrote:
> > Other than that I might have a solution. I applied a patch which only
> > adds the CREATE_BREAKAWAY_FROM_JOB flag if the calling process is member
> > of a job and the job allows a breakaway. It works in my limited
> > testing, but it would be important to know if it works for you, too, of
> > course. If you're not set up to build your own Cygwin DLL, please test
> > the next developer snapshot.
>
> Yes, unfortunately I am not set up at the moment to build dlls, so
> I'll eagerly await the next snapshot.
Uploaded.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* RE: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-22 10:12 ` Shaddy Baddah
2011-12-22 10:45 ` Corinna Vinschen
@ 2011-12-22 18:43 ` Buchbinder, Barry (NIH/NIAID) [E]
2011-12-22 19:24 ` Christopher Faylor
1 sibling, 1 reply; 93+ messages in thread
From: Buchbinder, Barry (NIH/NIAID) [E] @ 2011-12-22 18:43 UTC (permalink / raw)
To: cygwin
Shaddy Baddah sent the following at Thursday, December 22, 2011 5:12 AM
>At this point, I should make a disclosure. To do this as a
>non-Administrator grouped user, I must rename setup.exe to cygpkg.exe.
>This defeats the later Windows releases abilities to automatically
>detect installer applications by their name, and force privilege
>elevation. This is something that I have been meaning to open up a
>discussion about for some time (or may have tried to already, I can't
>recall), but I'll leave it to stand at the moment.
I would propose that <setup.exe> be renamed on cygwin.com to a name
lacking "setup", install", "inst", etc., so that one no longer needs
to jump through this hoop. If that seems like a good idea, I would
suggest the name <getcygwin.exe>.
- Barry
Disclaimer: Statements made herein are not made on behalf of NIAID.
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-22 18:43 ` Buchbinder, Barry (NIH/NIAID) [E]
@ 2011-12-22 19:24 ` Christopher Faylor
0 siblings, 0 replies; 93+ messages in thread
From: Christopher Faylor @ 2011-12-22 19:24 UTC (permalink / raw)
To: cygwin
On Thu, Dec 22, 2011 at 01:43:03PM -0500, Buchbinder, Barry (NIH/NIAID) [E] wrote:
>Shaddy Baddah sent the following at Thursday, December 22, 2011 5:12 AM
>>At this point, I should make a disclosure. To do this as a
>>non-Administrator grouped user, I must rename setup.exe to cygpkg.exe.
>>This defeats the later Windows releases abilities to automatically
>>detect installer applications by their name, and force privilege
>>elevation. This is something that I have been meaning to open up a
>>discussion about for some time (or may have tried to already, I can't
>>recall), but I'll leave it to stand at the moment.
>
>I would propose that <setup.exe> be renamed on cygwin.com to a name
>lacking "setup", install", "inst", etc., so that one no longer needs
>to jump through this hoop. If that seems like a good idea, I would
>suggest the name <getcygwin.exe>.
1) This has been suggested before.
2) It's amazing that this thread has stayed on topic for this long.
Please don't hijack it.
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-22 15:41 ` Corinna Vinschen
@ 2011-12-23 0:18 ` Shaddy Baddah
2011-12-23 4:12 ` Shaddy Baddah
2011-12-23 11:42 ` Corinna Vinschen
0 siblings, 2 replies; 93+ messages in thread
From: Shaddy Baddah @ 2011-12-23 0:18 UTC (permalink / raw)
To: cygwin
Hi Corinna,
On 23/12/11 02:40, Corinna Vinschen wrote:
> On Dec 23 01:47, Shaddy Baddah wrote:
>> On 23/12/11 01:33, Corinna Vinschen wrote:
>>> Other than that I might have a solution. I applied a patch which only
>>> adds the CREATE_BREAKAWAY_FROM_JOB flag if the calling process is member
>>> of a job and the job allows a breakaway. It works in my limited
>>> testing, but it would be important to know if it works for you, too, of
>>> course. If you're not set up to build your own Cygwin DLL, please test
>>> the next developer snapshot.
>> Yes, unfortunately I am not set up at the moment to build dlls, so
>> I'll eagerly await the next snapshot.
> Uploaded.
Yes, this is working now. Thank you very much.
I will still try and see if our desktop support will allow me to
disable the virus scanner for a short period to test if it made a
difference with that faltering dll. I'll report back in due course.
Thanks again,
Shaddy
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-23 0:18 ` Shaddy Baddah
@ 2011-12-23 4:12 ` Shaddy Baddah
2011-12-23 11:42 ` Corinna Vinschen
1 sibling, 0 replies; 93+ messages in thread
From: Shaddy Baddah @ 2011-12-23 4:12 UTC (permalink / raw)
To: cygwin
Hi Corinna,
On 23/12/11 11:18, Shaddy Baddah wrote:
> On 23/12/11 02:40, Corinna Vinschen wrote:
>> On Dec 23 01:47, Shaddy Baddah wrote:
>>> On 23/12/11 01:33, Corinna Vinschen wrote:
>>>> Other than that I might have a solution. I applied a patch which only
>>>> adds the CREATE_BREAKAWAY_FROM_JOB flag if the calling process is member
>>>> of a job and the job allows a breakaway. It works in my limited
>>>> testing, but it would be important to know if it works for you, too, of
>>>> course. If you're not set up to build your own Cygwin DLL, please test
>>>> the next developer snapshot.
>>> Yes, unfortunately I am not set up at the moment to build dlls, so
>>> I'll eagerly await the next snapshot.
>> Uploaded.
>
> Yes, this is working now. Thank you very much.
>
> I will still try and see if our desktop support will allow me to
> disable the virus scanner for a short period to test if it made a
> difference with that faltering dll. I'll report back in due course.
OK, I worked with desktop support and tried the previous snapshot with
the virus scanner disabled.
As I expected it didn't make a difference. There is still the
possibility that there is some specific policy enforcement on my
desktop at play here. But that is speculation.
Thanks again,
Shaddy
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-23 0:18 ` Shaddy Baddah
2011-12-23 4:12 ` Shaddy Baddah
@ 2011-12-23 11:42 ` Corinna Vinschen
1 sibling, 0 replies; 93+ messages in thread
From: Corinna Vinschen @ 2011-12-23 11:42 UTC (permalink / raw)
To: cygwin
On Dec 23 11:18, Shaddy Baddah wrote:
> Hi Corinna,
>
>
> On 23/12/11 02:40, Corinna Vinschen wrote:
> > On Dec 23 01:47, Shaddy Baddah wrote:
> >> On 23/12/11 01:33, Corinna Vinschen wrote:
> >>> Other than that I might have a solution. I applied a patch which only
> >>> adds the CREATE_BREAKAWAY_FROM_JOB flag if the calling process is member
> >>> of a job and the job allows a breakaway. It works in my limited
> >>> testing, but it would be important to know if it works for you, too, of
> >>> course. If you're not set up to build your own Cygwin DLL, please test
> >>> the next developer snapshot.
> >> Yes, unfortunately I am not set up at the moment to build dlls, so
> >> I'll eagerly await the next snapshot.
> > Uploaded.
>
> Yes, this is working now. Thank you very much.
I'm relieved to read that. Thanks for testing.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2011-12-12 8:59 ` Corinna Vinschen
@ 2012-01-08 21:46 ` Lars Bjørndal
2012-01-08 21:59 ` Larry Hall (Cygwin)
0 siblings, 1 reply; 93+ messages in thread
From: Lars Bjørndal @ 2012-01-08 21:46 UTC (permalink / raw)
To: cygwin
Hi
[Corinna Vinschen]
> On Dec 11 21:32, Samuel Thibault wrote:
>> Corinna Vinschen, le Thu 08 Dec 2011 09:47:45 +0100, a écrit :
>> > Too bad. In that case, Samuel, can you please have a closer look to
>> > see what broke brltty?
>>
>> The switch to mintty, simply. Brltty uses ReadConsoleOutputCharacter()
>> to get the text from consoles, I bet mintty does not implement this.
>> Lars thus needs cygwin to be able to run from a standard windows console
>> too.
>
> Lars wrote in http://cygwin.com/ml/cygwin/2011-12/msg00124.html
> that he always starts Cygwin from cmd.exe.
Yes, right. After starting Cygwin, I run BRLTTY to fire up my braille
display. Do you plan to drop Cygwin's support for running under CMD?
I don't hope so.
Regards,
Lars
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
2012-01-08 21:46 ` Lars Bjørndal
@ 2012-01-08 21:59 ` Larry Hall (Cygwin)
0 siblings, 0 replies; 93+ messages in thread
From: Larry Hall (Cygwin) @ 2012-01-08 21:59 UTC (permalink / raw)
To: cygwin
On 1/8/2012 4:45 PM, Lars Bjørndal wrote:
> Hi
>
> [Corinna Vinschen]
>
>> On Dec 11 21:32, Samuel Thibault wrote:
>>> Corinna Vinschen, le Thu 08 Dec 2011 09:47:45 +0100, a écrit :
>>>> Too bad. In that case, Samuel, can you please have a closer look to
>>>> see what broke brltty?
>>>
>>> The switch to mintty, simply. Brltty uses ReadConsoleOutputCharacter()
>>> to get the text from consoles, I bet mintty does not implement this.
>>> Lars thus needs cygwin to be able to run from a standard windows console
>>> too.
>>
>> Lars wrote in http://cygwin.com/ml/cygwin/2011-12/msg00124.html
>> that he always starts Cygwin from cmd.exe.
>
> Yes, right. After starting Cygwin, I run BRLTTY to fire up my braille
> display. Do you plan to drop Cygwin's support for running under CMD?
> I don't hope so.
It's always been possible to run Cygwin programs from cmd.exe and there is
no plan to change that. But the default is now to start mintty from
cygwin.bat where previously it was cmd.exe. Mintty is much more
configurable and generally provides a better user experience than cmd.exe.
That's the reason for the change.
--
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
^ permalink raw reply [flat|nested] 93+ messages in thread
end of thread, other threads:[~2012-01-08 21:59 UTC | newest]
Thread overview: 93+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-06 10:00 [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10 Corinna Vinschen
2011-12-06 12:07 ` Ken Brown
2011-12-06 12:14 ` Corinna Vinschen
2011-12-06 13:57 ` Thorsten Kampe
2011-12-06 19:38 ` David Rothenberger
2011-12-06 14:40 ` marco atzeri
2011-12-06 17:46 ` Corinna Vinschen
2011-12-07 3:08 ` Christopher Faylor
2011-12-07 7:56 ` marco atzeri
2011-12-09 6:14 ` marco atzeri
2011-12-11 6:34 ` Christopher Faylor
2011-12-11 7:07 ` marco atzeri
2011-12-11 19:25 ` Christopher Faylor
2011-12-11 21:00 ` Yaakov (Cygwin/X)
2011-12-12 1:11 ` Christopher Faylor
2011-12-12 1:22 ` Christopher Faylor
2011-12-13 18:48 ` Jim Reisert AD1C
2011-12-07 10:34 ` Yaakov (Cygwin/X)
2011-12-07 11:19 ` Corinna Vinschen
2011-12-09 6:19 ` Yaakov (Cygwin/X)
2011-12-06 15:21 ` Lars Bjørndal
2011-12-06 15:27 ` Corinna Vinschen
2011-12-06 15:31 ` Corinna Vinschen
2011-12-06 20:18 ` Lars Bjørndal
2011-12-06 21:10 ` Samuel Thibault
2011-12-06 22:01 ` Lars Bjørndal
2011-12-06 22:25 ` Tim McDaniel
2011-12-07 21:50 ` Andrey Repin
2011-12-07 9:23 ` Lars Bjørndal
2011-12-07 11:46 ` Corinna Vinschen
2011-12-07 12:40 ` Lars Bjørndal
2011-12-07 15:47 ` Lars Bjørndal
2011-12-08 8:48 ` Corinna Vinschen
2011-12-11 22:03 ` Samuel Thibault
2011-12-11 23:48 ` Christopher Faylor
2011-12-12 8:59 ` Corinna Vinschen
2012-01-08 21:46 ` Lars Bjørndal
2012-01-08 21:59 ` Larry Hall (Cygwin)
2011-12-06 17:38 ` Ken Brown
2011-12-06 17:58 ` Corinna Vinschen
2011-12-06 18:29 ` Ken Brown
2011-12-06 20:03 ` Corinna Vinschen
2011-12-07 2:51 ` Ken Brown
2011-12-07 3:22 ` Christopher Faylor
2011-12-07 13:03 ` Ken Brown
2011-12-07 16:55 ` Thomas Wolff
2011-12-07 17:07 ` Dima Pasechnik
2011-12-07 23:13 ` Christopher Faylor
2011-12-08 3:19 ` Ken Brown
2011-12-08 6:53 ` Christopher Faylor
2011-12-08 13:12 ` Ken Brown
2011-12-07 17:00 ` Bengt Larsson
2011-12-07 17:38 ` Corinna Vinschen
2011-12-07 17:51 ` Bengt Larsson
2011-12-07 18:07 ` Corinna Vinschen
2011-12-08 1:10 ` Enrico Forestieri
2011-12-08 8:29 ` Andy Koppe
2011-12-08 14:48 ` Enrico Forestieri
2011-12-08 15:08 ` Ken Brown
2011-12-08 15:56 ` Enrico Forestieri
2011-12-08 16:23 ` Ken Brown
2011-12-08 17:00 ` Enrico Forestieri
2011-12-08 8:40 ` Corinna Vinschen
2011-12-08 12:38 ` Enrico Forestieri
2011-12-08 14:32 ` Enrico Forestieri
2011-12-12 13:27 ` Corinna Vinschen
2011-12-12 23:08 ` Enrico Forestieri
2011-12-13 15:12 ` Corinna Vinschen
2011-12-07 23:18 ` Yaakov (Cygwin/X)
2011-12-08 7:04 ` Christopher Faylor
2011-12-08 10:51 ` Heiko Elger
2011-12-08 16:06 ` Bengt Larsson
2011-12-08 18:45 ` Christopher Faylor
2011-12-08 22:00 ` Bengt Larsson
2011-12-09 5:56 ` Christopher Faylor
2011-12-09 11:58 ` Bengt Larsson
2011-12-14 12:28 ` Corinna Vinschen
2011-12-15 0:25 ` Bengt Larsson
2011-12-22 7:09 ` Shaddy Baddah
2011-12-22 9:26 ` Corinna Vinschen
2011-12-22 10:12 ` Shaddy Baddah
2011-12-22 10:45 ` Corinna Vinschen
2011-12-22 11:12 ` Shaddy Baddah
2011-12-22 11:20 ` Corinna Vinschen
2011-12-22 13:08 ` Shaddy Baddah
2011-12-22 14:34 ` Corinna Vinschen
2011-12-22 14:47 ` Shaddy Baddah
2011-12-22 15:41 ` Corinna Vinschen
2011-12-23 0:18 ` Shaddy Baddah
2011-12-23 4:12 ` Shaddy Baddah
2011-12-23 11:42 ` Corinna Vinschen
2011-12-22 18:43 ` Buchbinder, Barry (NIH/NIAID) [E]
2011-12-22 19:24 ` Christopher Faylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).