Hi John,
On Sep 13 10:33, John Morrison wrote:
It is with regrets that I give up the maintainership of the cygwin
base-files and base-passwd packages.
I've been unable to find sufficient time to do these packages justice a
situation which is unlikely to improve at this time.
The source
On Sep 13 16:59, Steven Monai wrote:
Please upload
wget http://dev.monai.ca/cygwin/maradns/maradns-1.4.04-1.tar.bz2 \
http://dev.monai.ca/cygwin/maradns/maradns-1.4.04-1-src.tar.bz2
Uploaded.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Hi,
I finally solved the qhull problems casued by an hidden
bump of soversion from upstream and my still limited
knowledge of cmake. This time seems all right.
2010.1-1 versions to be removed and 2009.1.1-1 to be left as previous for qhull
and libqhull-devel.
libqhull_5 stays as 2009.1.1
new
On Tue, Sep 14, 2010 at 10:54:05AM +0200, Corinna Vinschen wrote:
Hi John,
On Sep 13 10:33, John Morrison wrote:
It is with regrets that I give up the maintainership of the cygwin
base-files and base-passwd packages.
I've been unable to find sufficient time to do these packages
Hi,
On Tue, September 14, 2010 9:54 am, Corinna Vinschen wrote:
Hi John,
Thanks for the time and effort you invested into these packages.
Thanks to you (and Chris) for putting so much effort in. I only wish I
had the time and skills to help more. I learnt a lot from the Cygwin
project and
On Sep 14 11:07, David Sastre wrote:
On Tue, Sep 14, 2010 at 10:54:05AM +0200, Corinna Vinschen wrote:
Hi John,
On Sep 13 10:33, John Morrison wrote:
It is with regrets that I give up the maintainership of the cygwin
base-files and base-passwd packages.
I've been unable to
On Sep 14 10:22, John Morrison wrote:
Hi,
On Tue, September 14, 2010 9:54 am, Corinna Vinschen wrote:
Hi John,
Thanks for the time and effort you invested into these packages.
Thanks to you (and Chris) for putting so much effort in. I only wish I
had the time and skills to help
On Sep 14 09:06, Marco Atzeri wrote:
Hi,
I finally solved the qhull problems casued by an hidden
bump of soversion from upstream and my still limited
knowledge of cmake. This time seems all right.
2010.1-1 versions to be removed and 2009.1.1-1 to be left as previous for
qhull and
--- Mar 14/9/10, Corinna Vinschen ha scritto:
On Sep 14 09:06, Marco Atzeri wrote:
Hi,
I finally solved the qhull problems casued by an
hidden
bump of soversion from upstream and my still limited
knowledge of cmake. This time seems all right.
2010.1-1 versions to be removed and
On Sep 14 10:05, Marco Atzeri wrote:
--- Mar 14/9/10, Corinna Vinschen ha scritto:
On Sep 14 09:06, Marco Atzeri wrote:
Hi,
I finally solved the qhull problems casued by an
hidden
bump of soversion from upstream and my still limited
knowledge of cmake. This time seems all
On 14/09/2010 10:30, Corinna Vinschen wrote:
On Sep 14 11:07, David Sastre wrote:
On Tue, Sep 14, 2010 at 10:54:05AM +0200, Corinna Vinschen wrote:
On Sep 13 10:33, John Morrison wrote:
It is with regrets that I give up the maintainership of the cygwin
base-files and base-passwd packages.
Hi,
On 09/14/2010 09:36 PM, Jon TURNEY wrote:
On 14/09/2010 10:30, Corinna Vinschen wrote:
On Sep 14 11:07, David Sastre wrote:
On Tue, Sep 14, 2010 at 10:54:05AM +0200, Corinna Vinschen wrote:
On Sep 13 10:33, John Morrison wrote:
It is with regrets that I give up the maintainership of the
I'd also appreciate it if this could be looked into while updating base-files:
http://sourceware.org/ml/cygwin/2010-05/msg0.html
Thank you,
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
On 14/09/2010 12:36, Jon TURNEY wrote:
On 14/09/2010 10:30, Corinna Vinschen wrote:
On Sep 14 11:07, David Sastre wrote:
On Tue, Sep 14, 2010 at 10:54:05AM +0200, Corinna Vinschen wrote:
On Sep 13 10:33, John Morrison wrote:
It is with regrets that I give up the maintainership of the cygwin
Since so little is in the base-cygwin and base-passwd packages, might
it make sense to fold them into base-files?
- Barry
Disclaimer: Statements made herein are not made on behalf of NIAID.
On Tue, Sep 14, 2010 at 10:22:18AM +0100, John Morrison wrote:
On Tue, September 14, 2010 9:54 am, Corinna Vinschen wrote:
Thanks for the time and effort you invested into these packages.
Thanks to you (and Chris) for putting so much effort in. I only wish I
had the time and skills to help more.
On Tue, Sep 14, 2010 at 05:58:08AM +0100, Andy Koppe wrote:
On 13 September 2010 18:26, Charles Wilson wrote:
On 9/13/2010 6:52 AM, JonY wrote:
OK, new headers tarballs up. Thanks for keeping an eye out.
All packages are uploaded.
A big round of applause for JonY, Chuck, and Yaakov for the
On 9/14/2010 9:35 AM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
Since so little is in the base-cygwin and base-passwd packages, might
it make sense to fold them into base-files?
No, IIRC there are issues with circular dependencies. Since these
packages live very close to the root of the
On Tue, Sep 14, 2010 at 10:22:18AM +0100, John Morrison wrote:
On Tue, September 14, 2010 9:54 am, Corinna Vinschen wrote:
Thanks for the time and effort you invested into these packages.
Thanks to you (and Chris) for putting so much effort in. I only wish I
had the time and skills to help
On Tue, Sep 14, 2010 at 01:36:34PM -0400, Andrew Schulman wrote:
On Tue, Sep 14, 2010 at 10:22:18AM +0100, John Morrison wrote:
On Tue, September 14, 2010 9:54 am, Corinna Vinschen wrote:
Thanks for the time and effort you invested into these packages.
Thanks to you (and Chris) for putting
On Tue, September 14, 2010 6:49 pm, Andrew Schulman wrote:
Gold watch awarded: http://cygwin.com/goldstars/#JM .
Awesome. Thanks Andrew. I was hoping that you'd take the challenge of
delivering on a gold watch.
No image is too great to scale here at cygwin.com.
Thankyou :) I'll
Hi,
My keyboard layout is not automatically detected. Relevant info
according to your FAQ is below:
/var/log/XWin.0.log :
[ 4704.046] (--) Windows keyboard layout: 041F (041f)
Turkish Q, type 4
[ 4704.046] (EE) Keyboardlayout Turkish Q (041F) is unknown,
using X server default
On 14/09/2010 09:15, Ozgur Murat Homurlu wrote:
My keyboard layout is not automatically detected. Relevant info
according to your FAQ is below:
/var/log/XWin.0.log :
[ 4704.046] (--) Windows keyboard layout: 041F (041f)
Turkish Q, type 4
[ 4704.046] (EE) Keyboardlayout Turkish Q
0x041f Turkish Q = layout tr
0x0001041f Turkish F = layout tr variant f
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
hw/xwin/winlayouts.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/hw/xwin/winlayouts.h b/hw/xwin/winlayouts.h
index f5397e3..d7a9f27
On 14/09/2010 18:51, Brian Kelly wrote:
I've been using Cygwin X trouble-free for years, and am running the latest
distribution of X and the Cygwin1.dll for at least two weeks (since the
Cygwin 1.7.7.1 release). It's been fine until this morning when it started
locking on me whenever I used the
Thanks Jon for the quick reply. I attached a new log file generated with an
attempt to highlight - followed by the hang.
Again, this worked PERFECTLY just yesterday. I ran a chkdsk on my system just
about an hour ago, and while it repaired a few files, the problem remains.
I'll try your
Also - tried GVim, and it locked when I only got one character highlighted.
Tried minTTY, and it works perfectly (of course it's not X-based). The
cut-and-paste works flawlessly.
Again, why X highlighting and cut-and-paste worked yesterday and not today is
the real mystery. The machine has
On 9/14/2010 4:05 PM, Brian Kelly wrote:
Also - tried GVim, and it locked when I only got one character highlighted.
Tried minTTY, and it works perfectly (of course it's not X-based). The
cut-and-paste works flawlessly.
Again, why X highlighting and cut-and-paste worked yesterday and not today
Jon - I tried the -noclipboard option, and you were right. I can now highlight
and cut-and-paste within the X environment. Hope that helps you. In the
meantime, I will use minTTY, and try to get along without X-based GVim. I sure
hope you can find something to correct. I will cooperate and try
CVSROOT:/cvs/src
Module name:src
Changes by: cori...@sourceware.org 2010-09-14 14:10:40
Modified files:
winsup/cygwin : ChangeLog path.cc
Log message:
* path.cc (symlink_info::check): Make sure AllocationSize and EndOfFile
are stored in the right order
On Sep 13 13:28, Yoni Londner wrote:
Hi,
However, isn't that kind of a chicken/egg situation? If you want to
reuse the content of the FILE_BOTH{_ID}_DIRECTORY_INFORMATION structure
from a previous call to readdir, you would have to call the
I am not talking about reusing info from a
On 9/14/2010 13:11, Andy Koppe wrote:
On 14 September 2010 03:13, JonY wrote:
Version 4.5.1-1 of mingw64-x86_64-gcc has been uploaded.
mingw64-x86_64-gcc contains GCC sources used by the 64bit target toolchain.
See mingw64-x86_64-gcc-core, mingw64-x86_64-gcc-objc,
mingw64-x86_64-gcc-ada,
On 9/14/2010 2:57 AM, JonY wrote:
That is weird.
Do you have mingw64 binutils installed? Somehow the cygwin binutils was
used.
I don't know about Andy, but I sure do -- and I can reproduce his
problem. I suspect there is a bug in how the cross tool locates the
On 9/14/2010 15:29, Charles Wilson wrote:
On 9/14/2010 2:57 AM, JonY wrote:
That is weird.
Do you have mingw64 binutils installed? Somehow the cygwin binutils was
used.
I don't know about Andy, but I sure do -- and I can reproduce his
problem. I suspect there is a bug in how the cross tool
On Sep 14 15:30, JonY wrote:
On 9/14/2010 15:29, Charles Wilson wrote:
I don't know about Andy, but I sure do -- and I can reproduce his
problem. I suspect there is a bug in how the cross tool locates the
/usr/x86_64-w64-mingw32/bin
directory, given the mount structure:
/usr/bin =
On Sep 13 19:47, John Carey wrote:
On Sep 11 03:30, Corinna Vinschen:
Given that, wouldn't it be potentially possible to override the content
of curCwd? The problem is probably (just as in my old Cygwin code up to
1.7.5) to make sure that this is thread safe. Probably we would still
On Sep 13 14:20, Earl Chew wrote:
I have a Makefile which performs rm -f -r as part of a clean target.
On Win7 with 1.7.5-1 this can fail with:
rm -f -r win32
rm: cannot remove directory `win32': Directory not empty
I tried 1.7.7-1 but the problem still seems to be there.
Doing a
--- Mar 14/9/10, ha scritto:
On 9/14/2010 13:11, Andy Koppe
wrote:
On 14 September 2010 03:13, JonY wrote:
Version 4.5.1-1 of mingw64-x86_64-gcc has been
uploaded.
mingw64-x86_64-gcc contains GCC sources used by
the 64bit target toolchain.
See mingw64-x86_64-gcc-core,
On 9/14/2010 16:03, Corinna Vinschen wrote:
On Sep 14 15:30, JonY wrote:
On 9/14/2010 15:29, Charles Wilson wrote:
I don't know about Andy, but I sure do -- and I can reproduce his
problem. I suspect there is a bug in how the cross tool locates the
/usr/x86_64-w64-mingw32/bin
On 14 September 2010 11:15, Marco Atzeri wrote:
Is this to be expected?
$ x86_64-w64-mingw32-gcc hello.c
[compiles fine]
$ /bin/x86_64-w64-mingw32-gcc hello.c
/Users/Andy/AppData/Local/Temp/cckcwv49.s: Assembler
messages:
/Users/Andy/AppData/Local/Temp/cckcwv49.s:10: Error:
bad
On 9/14/2010 18:46, Andy Koppe wrote:
On 14 September 2010 11:15, Marco Atzeri wrote:
Is this to be expected?
$ x86_64-w64-mingw32-gcc hello.c
[compiles fine]
$ /bin/x86_64-w64-mingw32-gcc hello.c
/Users/Andy/AppData/Local/Temp/cckcwv49.s: Assembler
messages:
On 14 September 2010 11:40, JonY wrote:
On 9/14/2010 18:46, Andy Koppe wrote:
On 14 September 2010 11:15, Marco Atzeri wrote:
Is this to be expected?
$ x86_64-w64-mingw32-gcc hello.c
[compiles fine]
$ /bin/x86_64-w64-mingw32-gcc hello.c
/Users/Andy/AppData/Local/Temp/cckcwv49.s:
On Sep 14 18:15, JonY wrote:
On 9/14/2010 16:03, Corinna Vinschen wrote:
On Sep 14 15:30, JonY wrote:
On 9/14/2010 15:29, Charles Wilson wrote:
I don't know about Andy, but I sure do -- and I can reproduce his
problem. I suspect there is a bug in how the cross tool locates the
New versions 2010.1-2 of
libqhull-devel, libqhull_6, qhull
have been uploaded for cygwin.
libqhull_5 version revert to previous 2009.1.1-1
CHANGES
The previous 2010.1-1 was faulty as a soversion
bump was needed for libqhull. As all the linux distributions
as still on 2009 or 2003 version the
On 9/14/2010 7:18 AM, Corinna Vinschen wrote:
On Sep 14 18:15, JonY wrote:
What do you suggest the fix should be?
I really don't know, but it's certainly not a fix in Cygwin. The fact
that /usr/bin is a mount point to /bin is nothing which wouldn't be
allowed under Linux as well. There's
Version 1.4.04-1 of 'maradns' has been uploaded to the Cygwin archive,
superceding 1.4.03-2, which remains available as the previous version.
MaraDNS is a package that implements the Domain Name Service (DNS), an
essential internet service. For full details, see the project website:
Hi,
While trying to run 'gvim', we get the following messages:
**
bash-3.2$ gvim
4 [main] gvim 6964 exception::handle: Exception: STATUS_ACCESS_VIOLATION
1184 [main] gvim 6964 open_stackdumpfile:
On 9/14/2010 10:40 AM, טל ח wrote:
4 [main] gvim 7236 C:\cygwin\bin\gvim.exe: *** fatal error -
unable to remap
_\\?\C:\cygwin\lib\gtk-2.0\2.10.0\loaders\cygpixbufloader-xpm.dll to
same address as parent: 0x5D != 0x60 Stack trace:
Try installing the 'rebase' package,
reading
Hi, All.
I've searched quite a lot for the subj and found no solution yet.
I've installed the last cygwin+openssh on Windows XP. I want to
connect from linux and run some native console applications
(non-cygwin CUI, particularly, cdb and cmd) and I need these
applications to correctly handle
On Sep 14 10:12, Corinna Vinschen wrote:
On Sep 13 19:47, John Carey wrote:
Anyway, it looks to me as if overwriting the path in an existing
VistaCwd instance would confuse RtlGetCurrentDirectory_U() and
probably other Win32 API functions. (It may be that the same is
true for the handle
On Sep 14 18:11, Corinna Vinschen wrote:
On Sep 14 10:12, Corinna Vinschen wrote:
On Sep 13 19:47, John Carey wrote:
Anyway, it looks to me as if overwriting the path in an existing
VistaCwd instance would confuse RtlGetCurrentDirectory_U() and
probably other Win32 API functions. (It
There shouldn't be any race. When you set the delete disposition,
the file is actually deleted as soon as the last handle to the file
is closed. If the file isn't opened by another process, it will
disappear right at the NtClose at the end of unlink_nt. Please note
that the call to
On Sep 14 09:39, Earl Chew wrote:
There shouldn't be any race. When you set the delete disposition,
the file is actually deleted as soon as the last handle to the file
is closed. If the file isn't opened by another process, it will
disappear right at the NtClose at the end of unlink_nt.
On Sep 14 01:12, Corinna Vinschen wrote:
On Sep 13 19:47, John Carey wrote:
On Sep 11 03:30, Corinna Vinschen:
Anyway, it looks to me as if overwriting the path in an existing
VistaCwd instance would confuse RtlGetCurrentDirectory_U() and
probably other Win32 API functions. (It may be
Hi there.
I've had the same problem in the past.
Posted a temporary solution here:
http://www.cygwin.com/ml/cygwin/2009-02/msg00403.html
Best regards,
KarHeng
Ilia K. wrote:
Hi, All.
I've searched quite a lot for the subj and found no solution yet.
I've installed the last cygwin+openssh on
Might there be something else a little off?
The text from the latest stackdump:
Stack trace:
Frame Function Args
The rest is blank. Should I be concerned, or is this something that will
work itself out?
Steve W.
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On Sep 14 17:39, John Carey wrote:
On Sep 14 01:12, Corinna Vinschen wrote:
On Sep 13 19:47, John Carey wrote:
On Sep 11 03:30, Corinna Vinschen:
Anyway, it looks to me as if overwriting the path in an existing
VistaCwd instance would confuse RtlGetCurrentDirectory_U() and
probably
On Sep 14 20:59, Corinna Vinschen wrote:
On Sep 14 17:39, John Carey wrote:
On Sep 14 01:12, Corinna Vinschen wrote:
Hmm, I'm still wondering. In theory we don't have to replace the
directory name. We just have to InterlockedExchange the handle, since
we only need to replace the
Corinna Vinschen wrote:
...or having a cwd below the directory. Trying to remove a directory
which is the CWD of some process is the most common reason that the
directory is blocked, because the Win32 CWD is opened without the
FILE_SHARE_DELETE flag. Especially something like `rm -rf ../foo'
SJ Wright wrote:
Might there be something else a little off?
The text from the latest stackdump:
Stack trace:
Frame Function Args
The rest is blank. Should I be concerned, or is this something that
will work itself out?
Steve W.
A little more information that seems pertinent to this
For the sake of completeness, I would ask if with these packages one can
build applications which run on Win Xp 32.
Thanks,
Angelo.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
No. They are not multilib capable, so they only target a single system - Win64.
I am assuming that Jon will be providing toolchains that target Win32
shortly. These will be separate packages.
On Tue, Sep 14, 2010 at 5:21 PM, Angelo Graziosi
angelo.grazi...@alice.it wrote:
For the sake of
On Sep 14 09:11, Corinna Vinschen wrote:
I applied the below patch to Cygwin CVS and it appears to work nicely.
The only potential race I can think of is, if another thread of the same
Cygwin process calls SetCurrentDirectory. I'm inclined to let this
situation slip through the cracks since
On Sep 14 12:02, Corinna Vinschen wrote:
True. Implementing a full replacement for SetCurrentDirectory as in
your PoC is still an option. However, I can't do that anymore since
I'm tainted by reading your code. If you would contemplate to sign
a copyright assignment(**), we could create a
On Tue, Sep 14, 2010 at 7:58 PM, Chan Kar Heng chankarh...@gmail.com wrote:
Hi there.
I've had the same problem in the past.
Posted a temporary solution here:
http://www.cygwin.com/ml/cygwin/2009-02/msg00403.html
This is an interesting hack, but unfortunately it won't work for
native apps,
Just setting up a new XP pro box, can't find Pine.
So what MUA is supported atm?
Thanks,
Wes
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
On 09/14/2010 08:39 AM, Ilia K. wrote:
Hi, All.
I've searched quite a lot for the subj and found no solution yet.
I've installed the last cygwin+openssh on Windows XP. I want to
connect from linux and run some native console applications
(non-cygwin CUI, particularly, cdb and cmd) and I need
On 14/09/2010 19:47, SJ Wright wrote:
Might there be something else a little off?
The text from the latest stackdump:
Stack trace:
Frame Function Args
The rest is blank. Should I be concerned, or is this something that will
work itself out?
This is a bit of a guess, but try
About a year ago I was able to get assistance compiling my MUD client
Tinyfuge, with a special add-on python library, using cywgin. That
problem turned out needing to send the location of the python library
in the ./configure command.
Now that we have a new major release of cygwin with a new(er)
% cygcheck -c cygwin tcsh
Cygwin Package Information
Package Version Status
cygwin 1.7.5-1 OK
tcsh 6.17.00.1-1 OK
I've noticed that certain file matching patterns in tcsh under Cygwin
are matching more files than they should. In the
New versions 2010.1-2 of
libqhull-devel, libqhull_6, qhull
have been uploaded for cygwin.
libqhull_5 version revert to previous 2009.1.1-1
CHANGES
The previous 2010.1-1 was faulty as a soversion
bump was needed for libqhull. As all the linux distributions
as still on 2009 or 2003 version the
Version 1.4.04-1 of 'maradns' has been uploaded to the Cygwin archive,
superceding 1.4.03-2, which remains available as the previous version.
MaraDNS is a package that implements the Domain Name Service (DNS), an
essential internet service. For full details, see the project website:
72 matches
Mail list logo
