Corinna Vinschen schrieb:
On Nov 25 18:30, Dave Korn wrote:
Thomas Wolff wrote:
Corinna Vinschen wrote:
Are you sure the share permissions are sufficient? In contrast to the
1.5 setup, the 1.7 setup tries to create files and directories with
explicit ACLs.
On the H:
On Thu, 26 Nov 2009, Lothar Brendel wrote:
Charles Wilson wrote:
Lothar Brendel wrote:
Unfortunately the situatiuon with ``startxwin.bat'' is worse now:
* ``checkX -t 12'' still doesn't wait (?!?)
I can't reproduce this.
Stupid me, sorry. When updating to pull in libustr1, run2 was
On 11/26/2009 2:30 AM, Lothar Brendel wrote:
Errh, yes. Hence, to make Cygwin/X+xterm run out of the box (using the
start menu shortcut), you have to install the CJK fonts. One more
noob-question, sorry: Which font-package does provide the CJK fonts? I
tried several ones but up to now in vain.
CVSROOT:/cvs/src
Module name:src
Changes by: cori...@sourceware.org 2009-11-26 10:58:06
Modified files:
winsup/cygwin : ChangeLog dtable.cc
Log message:
* dtable.cc (dtable::stdio_init): Use GetCurrentProcess() rather than
hMainProc as process handle
On Nov 26 01:03, Shaddy Baddah wrote:
Hi,
Please find attached a patch to allow for override-able
installation_root. I actually wrote this patch for release 1.7.0-52
motivated by the thread I started [1.7] Alternative root
directory. Sort of a regression.
On Nov 25 06:11, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 11/20/2009 7:15 AM:
* signal.cc (nanosleep): Support 'infinite' sleep times.
(sleep): Avoid uninitialized memory.
Sorry but, while I agree with the basic idea, this seems like
Hi,
Corinna Vinschen wrote:
Sorry, but no. We won't accept this patch. We have deliberately chosen
to get away from the dependency to the Windows registry, and we really
don't want to add it back again.
Thank you for the response. Fair enough. But is it no to the idea of an
overridable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 11/26/2009 4:21 AM:
How about the following, then? Same changelog.
Ping.
Do you think we need it in 1.7.1?
I suppose I can camp on it until after the release. It's not very likely
that someone does 'sleep 50d',
On Nov 26 22:56, Shaddy Baddah wrote:
Hi,
Corinna Vinschen wrote:
Sorry, but no. We won't accept this patch. We have deliberately chosen
to get away from the dependency to the Windows registry, and we really
don't want to add it back again.
Thank you for the response. Fair enough. But is
On Thu, Nov 26, 2009 at 12:21:21PM +0100, Corinna Vinschen wrote:
On Nov 25 06:11, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 11/20/2009 7:15 AM:
* signal.cc (nanosleep): Support 'infinite' sleep times.
(sleep): Avoid uninitialized memory.
On Nov 25 23:44, Charles Wilson wrote:
Yaakov (Cygwin/X) wrote:
I came across this error with run when launched from the cmd prompt with
an empty CYGWIN variable:
1 [main] xterm 1248 dtable::stdio_init: couldn't make stderr
distinct from stdout
If I set CYGWIN=tty then this
On Nov 26 10:35, Corinna Vinschen wrote:
However, Chuck, can you please try the below patch to run.c instead?
It makes the stdout and stderr handles already distinct in run:
Index: src/run.c
===
RCS file:
I'm having some serious slowness issues with Cygwin (1.7) on my Windows 7
x64 machine. Background research told me to test things with strace, and
I've noticed that every strace so far gives me major slowness on two
consecutive lines, e.g.:
$ strace ls
[...]
512680 [main] ls 3404 time:
Corinna Vinschen wrote:
On Nov 26 10:35, Corinna Vinschen wrote:
However, Chuck, can you please try the below patch to run.c instead?
It makes the stdout and stderr handles already distinct in run:
I can't reproduce the problem with the original run (my xterm dumps
core, for a different
Am 25.11.2009, 14:05 Uhr, schrieb Corinna Vinschen
corinna-cyg...@cygwin.com:
Hi folks,
I just uploaded a new Cygwin 1.7 test release, 1.7.0-66.
If this doesn't introduce any new regressions, this will (probably)
be the last test release.
Greetings,
after having played with Cygwin 1.5
On Nov 26 15:38, Matthias Andree wrote:
Am 25.11.2009, 14:05 Uhr, schrieb Corinna Vinschen
corinna-cyg...@cygwin.com:
Hi folks,
I just uploaded a new Cygwin 1.7 test release, 1.7.0-66.
If this doesn't introduce any new regressions, this will (probably)
be the last test release.
Dear list,
I've been using Cygwin daily for years and I'm very happy with it.
But today it threw a nice puzzle at me. I must confess I became
a list member just to report it.
My Cygwin /usr/bin/tar hangs when unpacking an archive:
curl
Reinier Post writes:
curl
ftp://ftp.debian.org/debian/pool/main/c/calcoo/calcoo_1.3.16.orig.tar.gz
| tar zxvf -
hangs after printing the line
calcoo-1.3.16/src/aux.c
This happens on two different i386 systems, both running an up to date Cygwin
on an up to date Windows XP with the
I wonder if some process has created the file in
question and still has it open. Then a call to
create, and a call to unlink, will both fail.
You might not see the file until the process
closes it or dies ...
Just a wondering ...
The procexp tool from sysinternals.com might
reveal an open file
Am 26.11.2009, 16:58 Uhr, schrieb Corinna Vinschen
corinna-cyg...@cygwin.com:
This circumvents a few installation problems and decouples the Cygwin
homedir by default from the Windows profile directory, which
especially starting with Vista results in performance problems due to
the
On Thu, Nov 26, 2009 at 04:39:39PM -0500, Eliot Moss wrote:
I wonder if some process has created the file in
question and still has it open. Then a call to
create, and a call to unlink, will both fail.
But the call to open is failing (the fd returned is -1),
which is why the unlink() is
On Thu, Nov 26, 2009 at 01:52:45PM -0500, Dave Steenburgh wrote:
It is my understanding that this problem is not easily reproducible.
Well, I've been reproducing it locally since last night. ?I'm going to
try leaving every cygwin-related process as-is as long as necessary,
in the hope of beating
On Fri, Nov 27, 2009 at 01:20:50AM +0100, Reinier Post wrote:
On Thu, Nov 26, 2009 at 04:39:39PM -0500, Eliot Moss wrote:
I wonder if some process has created the file in
question and still has it open. Then a call to
create, and a call to unlink, will both fail.
But the call to open is
I have cvs on a client machine connecting to a host over ssh. The cvs
procedure finishes, but the connection does not terminate until I hit
ctrl-c. The cvs process is then left running on the host. Regular ssh
connections (ie interactive login) do not have this problem.
The host machine is Cygwin
Here is the tail end of an strace of the hanging cvs process.
Jeremy
cvs.strace.out
Description: Binary data
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
cgf wrote:
Defunct processes are not necessarily indicative of a cygwin problem.
This could easily be a problem with gnuplot.
Given the sum of my own limited knowledge of the problem at hand (in
summary: every program involved is in my local cygwin directory), I
figured it was best to ask here
2009/11/27 Dave Steenburgh dave.steenbu...@gmail.com
cgf wrote:
Defunct processes are not necessarily indicative of a cygwin problem.
This could easily be a problem with gnuplot.
Given the sum of my own limited knowledge of the problem at hand (in
summary: every program involved is in my
Hello
When linking gnuplot-tikz.lua.exe, which is part of gnuplot for a lua related
terminal, the following
error appeared
gcc-4 -O3 -fomit-frame-pointer -L/usr/lib -o gnuplot-tikz.lua.exe
-lpangocairo-1.0 -lcairo
-lpangoft2-1.0 -lpixman-1 -lglitz -lpng12 -lxcb-render-util -lXrender
--- Ven 27/11/09, Tatsuro MATSUOKA ha scritto:
Hello
When linking gnuplot-tikz.lua.exe, which is part of gnuplot
for a lua related terminal, the following
error appeared
gcc-4 -O3 -fomit-frame-pointer -L/usr/lib -o
gnuplot-tikz.lua.exe -lpangocairo-1.0
-lcairo
-lpangoft2-1.0
A defunct process is not necesarily the real problem. All defunct
process are processes that their parent has NOT done a wait(2) yet.
Since these defunct processes have called exit(2), they must hang
around until a wait(2) is completed so that the exit status can be
returned to the parent.
30 matches
Mail list logo
