Version 1.3.20-1 of
GraphicsMagick
libGraphicsMagick-devel
libGraphicsMagick3
perl-Graphics-Magick
have been uploaded for cygwin
DESCRIPTION
GraphicsMagick is the swiss army knife of image processing.
It provides a robust and efficient collection of tools and
libraries which support
Version 1.3.20-1 of
GraphicsMagick
libGraphicsMagick-devel
libGraphicsMagick3
perl-Graphics-Magick
have been uploaded for cygwin
DESCRIPTION
GraphicsMagick is the swiss army knife of image processing.
It provides a robust and efficient collection of tools and
libraries which support
Interactively rbash seems to work fine:
bash-2.05b$ uname -a; ln -s /bin/bash /bin/rbash;rbash
CYGWIN_NT-4.0 ws011206 1.3.20(0.73/3/2) 2003-02-08 12:10 i686 unknown unknown Cygwin
rbash-2.05b$ cd /
rbash: cd: restricted
When I set the login shell to /bin/rbash in /etc/passwd
and login
Interactively rbash seems to work fine:
bash-2.05b$ uname -a; ln -s /bin/bash /bin/rbash;rbash
CYGWIN_NT-4.0 ws011206 1.3.20(0.73/3/2) 2003-02-08 12:10 i686 unknown unknown Cygwin
rbash-2.05b$ cd /
rbash: cd: restricted
When I set the login shell to /bin/rbash and login through ssh
On Mon, 21 Jul 2003, Henry Da Costa wrote:
Larry Hall wrote:
Why do you only have the executable? Also, why can't the provider of
this executable give you with the support you need? Strictly
speaking, if the provider hasn't purchased a commercial license from
Red Hat, they are legally
Hello Mr. Faylor,
I hope you can help me. I'm looking for a complete Cygwin version 1.3.20
set of packages but have so far been unable to find it. I need that
particular version of Cygwin because other versions including the latest
one give us an error when used from a development tool for which
Henry Da Costa wrote:
Hello Mr. Faylor,
You have sent this message to a public mailing list.
I hope you can help me. I'm looking for a complete Cygwin version 1.3.20
set of packages but have so far been unable to find it.
The phrase complete Cygwin version 1.3.20 set of packages
Max Bowsher wrote:
You have sent this message to a public mailing list.
Thanks for replying. I didn't realize that the Christopher Faylor link
at http://www.cygwin.com/ led to the cygwin mailing list. I should have
been more vigilant.
The phrase complete Cygwin version 1.3.20 set of packages
reading that pege in it's entirity (I mean the bottom of) would have
helped.
The phrase complete Cygwin version 1.3.20 set of packages is
meaningless.
A Cygwin DLL version number does not uniquely identify a set of
packages.
I realize that each package has its own versioning and is released
Elfyn McBratney wrote:
I will add this though: If you have a program that worked on 1.3.20*
which does
not work on 1.3.22* it's more productive to try and find out the cause
of the
problem rather than going back in time. If it turns out to be a
problem in the
Cygwin DLL, matbe the royal we can
Henry Da Costa wrote:
Elfyn McBratney wrote:
I will add this though: If you have a program that worked on 1.3.20*
which does
not work on 1.3.22* it's more productive to try and find out the cause
of the
problem rather than going back in time. If it turns out to be a
problem in the
Cygwin DLL
Larry Hall wrote:
Why do you only have the executable? Also, why can't the provider of
this executable give you with the support you need? Strictly
speaking, if the provider hasn't purchased a commercial license from
Red Hat, they are legally bound by the GPL. If they aren't providing
On Tue, Apr 01, 2003 at 07:06:45PM -0800, gavin bowlby wrote:
$ uname -a
CYGWIN_NT-5.0 reptilicus 1.3.20(0.73/3/2) 2003-02-08
12:10 i686 unknown unknown
Cygwin
Could you test with 1.3.22 please?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin
Bowlby
([EMAIL PROTECTED])
==
On Tue, Apr 01, 2003 at 07:06:45PM -0800, gavin bowlby
wrote:
$ uname -a
CYGWIN_NT-5.0 reptilicus 1.3.20(0.73/3/2) 2003-02-08
12:10 i686 unknown unknown
Cygwin
Could you test with 1.3.22 please?
Corinna
On Wed, Apr 02, 2003 at 12:20:56PM -0800, gavin bowlby wrote:
Thanks for your suggestion. Sorry I didn't upgrade before reporting
this problem. I still see the same problem with 1.3.22.
Ok. In that event, please provide a simple test case.
cgf
--
Unsubscribe info:
Ok. In that event, please provide a simple test
case.
Christopher, Corinna:
Thanks for you help on this!
Here's a short program to recreate this problem:
(main.c)
=
int main(int argc, char *argv[]) {
int pid, sid, rc;
if ((pid =
On Wed, Apr 02, 2003 at 06:43:16PM -0800, gavin bowlby wrote:
Ok. In that event, please provide a simple test case.
Here's a short program to recreate this problem:
(main.c)
=
int main(int argc, char *argv[]) {
int pid, sid, rc;
if
$ uname -a
CYGWIN_NT-5.0 reptilicus 1.3.20(0.73/3/2) 2003-02-08
12:10 i686 unknown unknown
Cygwin
Windows 2K box.
Process A creates Process B.
I kill Process B with a kill -9 process B's pid
Process A then does a:
sid = getpgid(pid));
pid is set to process B's pid
sid is not returned as -1
Hi,
I am using cygwin-1.3.20-1 on a W2K machine, as another UNIX
OS on a UNIX network viewed via Samba 2.0.
When creating relative symlinks on the local drive (e.g.,
c:\), execvp finds the script through the symlink. When
creating a similar relative symlink on the network share,
execvp skips
I just upgraded from 1.3.20 to 1.3.22 and noticed the the DBDoracle module
(1.13 and 1.12( Oracle.dll) fails on the new version. I tried recompiling
agianst the same libraries on both cygwins, and though the compile gives
the same output and result under both, the dll fails to load under
version info:
DLL version: 1.3.20
tcltk20030214-1
Best regards,
Jerzy Witkowski
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ
of them are named `tclsh.exe' and
`wish.exe', but I cannot find the last ones. It is strange, because the
compile libraries (e.g. lib/libitcl.a) and startup files (e.g.
usr/share/itcl3.2/) for them are still supplied. Please help.
Cygwin DLL version info:
DLL version: 1.3.20
I find that I can successfully pass long args to echo.exe using the @arglist
method. It is not too convenient though as using cmd.exe for a shell is
pretty awful. And I couldn't get g++ to work under cmd.exe (The dynamicl
link library cygwin1.dll could not be found...)
For the time being, I guess
On Wed, 12 Mar 2003, Randall R Schulz wrote:
At 16:00 2003-03-12, Igor Pechtchanski wrote:
On Wed, 12 Mar 2003, Randall R Schulz wrote:
...
Just got another idea. See if this helps:
http://cygwin.com/cygwin-ug-net/using-specialnames.html#AEN733
I believe the @argFileName
Matt,
Re: the g++ problem, looks like you're missing c:\cygwin\bin from your
system (windows) PATH.
As for your original problem, since noone else here is able to reproduce
it, would you be willing to try compiling bash from sources and inserting
some debugging output? It would be interesting
Igor wrote:
Matt,
A virus checker *shouldn't* affect your command line length limit...
Try running the offending command under strace, e.g.,
strace -o echo.strace /usr/bin/echo ${PATH}${PATH}
and look at the tail of the output. That should give you a clue of where
it's hanging. If you're
On Wed, 12 Mar 2003, Willis, Matthew wrote:
Igor wrote:
Matt,
A virus checker *shouldn't* affect your command line length limit...
Try running the offending command under strace, e.g.,
strace -o echo.strace /usr/bin/echo ${PATH}${PATH}
and look at the tail of the output. That should
Igor wrote:
You may be hitting the command-line limit with bash. Try the above with
cmd.exe. See below.
c:\cygwin\bin\echo.exe %PATH%-- works fine
c:\cygwin\bin\echo.exe %PATH%%PATH% -- fails, immediately returns to
command line
Try stracing the last line above...
Igor
I
On Wed, 12 Mar 2003, Willis, Matthew wrote:
Igor wrote:
You may be hitting the command-line limit with bash. Try the above with
cmd.exe. See below.
c:\cygwin\bin\echo.exe %PATH%-- works fine
c:\cygwin\bin\echo.exe %PATH%%PATH% -- fails, immediately returns to
command line
Igor,
At 15:24 2003-03-12, Igor Pechtchanski wrote:
On Wed, 12 Mar 2003, Willis, Matthew wrote:
...
which will run when I pass long arguments using bash.exe as my shell. I can
also pass long arguments to this program under cmd.exe. The only difference
seems to be that bash.exe fully expands
On Wed, 12 Mar 2003, Randall R Schulz wrote:
Igor,
At 15:24 2003-03-12, Igor Pechtchanski wrote:
On Wed, 12 Mar 2003, Willis, Matthew wrote:
...
which will run when I pass long arguments using bash.exe as my shell. I can
also pass long arguments to this program under cmd.exe. The
At 16:00 2003-03-12, Igor Pechtchanski wrote:
On Wed, 12 Mar 2003, Randall R Schulz wrote:
...
Just got another idea. See if this helps:
http://cygwin.com/cygwin-ug-net/using-specialnames.html#AEN733
I believe the @argFileName syntax only works when a non-Cygwin program
invokes a Cygwin
Max Bowsher wrote:
Richard H. Broberg wrote:
In the meantime I'll
happily use rxvt in place of bash, since it does what I need.
You are confused.
rxvt is a terminal.
bash is a shell.
Looked at another way:
rxvt is a GUI application.
bash is a console application.
When
* Francis Litterio (03-03-11 21:03 +0100)
Max Bowsher wrote:
Richard H. Broberg wrote:
In the meantime I'll
happily use rxvt in place of bash, since it does what I need.
You are confused.
rxvt is a terminal.
bash is a shell.
Looked at another way:
rxvt is a GUI application.
?). I could work around the too-many-object-files issue in my
makefile by using ar rv to create libs, one object file at a time.
Since I updated to 1.3.20-1, I find the magic number of characters has
dropped to 730. More importantly, g++-2 doesn't work any more. This seems to
be similarly true
. (Theory: intermediary command lines were shorter with
g++-2.exe?). I could work around the too-many-object-files issue in my
makefile by using ar rv to create libs, one object file at a time.
Since I updated to 1.3.20-1, I find the magic number of characters has
dropped to 730. More importantly
Hi everybody,
could somebody with Win2K/XP and cygwin1.dll 1.3.20 please try
this:
insert an audio-cd into your cd-rom/cd-writer
enter the following:
cd /tmp (or whatever)
cdrecord -scanbus (gives you a list of devices)
cdda2wav dev=1,5,0 -paranoia -B (modify dev)
Be warned: your Win2K
Resent-To: [EMAIL PROTECTED]
Resent-From: [EMAIL PROTECTED]
From: Max Bowsher [EMAIL PROTECTED]
Date: Sat, 8 Mar 2003 01:17:25 -
[snip]
Richard H. Broberg wrote:
From: Max Bowsher [EMAIL PROTECTED]
An unfortunate consequence of how Windows handles console windows.
Richard H. Broberg wrote:
In the meantime I'll
happily use rxvt in place of bash, since it does what I need.
You are confused.
rxvt is a terminal.
bash is a shell.
You are very likely running bash in rxvt.
Max.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug
).
Randall Schulz
At 03:22 2003-03-10, [EMAIL PROTECTED] wrote:
Hi everybody,
could somebody with Win2K/XP and cygwin1.dll 1.3.20 please try this:
insert an audio-cd into your cd-rom/cd-writer
enter the following:
cd /tmp (or whatever)
cdrecord -scanbus (gives you a list of devices)
cdda2wav dev
Resent-To: [EMAIL PROTECTED]
Resent-From: [EMAIL PROTECTED]
From: Max Bowsher [EMAIL PROTECTED]
[snip]
Richard H. Broberg wrote:
In the meantime I'll
happily use rxvt in place of bash, since it does what I need.
You are confused.
rxvt is a terminal.
bash is a shell.
Hello
I have made a little progress, I found mail about a problem similar to
mine
The solution was:
chmod a+x /bin
chmod a+x /lib/gcc-lib/i686-pc-cygwin/3.2/
now I get
gcc hello.c -o hello
/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-pc-cygwin/bin/ld:
cannot open crt0.o: No such file
to the
executable and re-'make' the program_exe was build finally.
Best,
Konstantinos
From: Igor Pechtchanski [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Konstantinos Makrodimitris [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: 1.3.20-1 CYGWIN ; csh,bash and ./config
Date: Tue, 4 Mar
using gcc3). So, I insist: there is a bug in
1.3.20-1 (reproducable by building xemacs-21.4.12) that has not been in
1.3.18.
Perhaps. But, for the record, it is very unlikely that anyone here is
going to download the Xemacs sources and attempt a compilation. If you
can come up with a simple test
On Fri, Mar 07, 2003 at 01:23:22PM +0100, Michael Graff Andersen wrote:
Hello
I have made a little progress, I found mail about a problem similar to
mine
The solution was:
chmod a+x /bin
chmod a+x /lib/gcc-lib/i686-pc-cygwin/3.2/
now I get
gcc hello.c -o hello
using gcc3). So, I insist: there is a bug in
1.3.20-1 (reproducable by building xemacs-21.4.12) that has not been in
1.3.18.
I have loosly followed this thread... I have had a similar problem after
updating
to 1.3.20. When compiling I got random signal 11 crashes while running
a makefile... After
: [EMAIL PROTECTED]
Date: Thu, 6 Mar 2003 14:21:33 +0800
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: RE: 1.3.20: bug: UID over 65536: I have no name!
Hello,
Even after changing my UID in /etc/passwd from 65558 to 22, I still get the
following permission errors when I open
In non-cygwin unix I'm familiar with being able to do the following in a
shell (bash or other):
$ nohup long-running-command
$ exit
and be able to leave it running.
However, under cygwin (this has been true for at least back to cygwin/1.3.6
for me), when I start a process in the background
Richard H. Broberg wrote:
In non-cygwin unix I'm familiar with being able to do the following
in a shell (bash or other):
$ nohup long-running-command
$ exit
and be able to leave it running.
However, under cygwin (this has been true for at least back to
cygwin/1.3.6 for me), when I
On Fri, Mar 07, 2003 at 10:00:28PM -, Max Bowsher wrote:
Richard H. Broberg wrote:
In non-cygwin unix I'm familiar with being able to do the following
in a shell (bash or other):
$ nohup long-running-command
$ exit
and be able to leave it running.
However, under cygwin (this has been
Christopher Faylor wrote:
On Fri, Mar 07, 2003 at 10:00:28PM -, Max Bowsher wrote:
Richard H. Broberg wrote:
In non-cygwin unix I'm familiar with being able to do the following
in a shell (bash or other):
$ nohup long-running-command
$ exit
and be able to leave it running.
Works for me using rxvt.
Richard H. Broberg [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
In non-cygwin unix I'm familiar with being able to do the following in a
shell (bash or other):
$ nohup long-running-command
$ exit
and be able to leave it running.
However, under
Works for me using rxvt.
Richard H. Broberg [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
In non-cygwin unix I'm familiar with being able to do the following in a
shell (bash or other):
$ nohup long-running-command
$ exit
and be able to leave it running.
However, under
On Fri, 7 Mar 2003, Max Bowsher wrote:
Christopher Faylor wrote:
On Fri, Mar 07, [EMAIL PROTECTED]:00:28PM -, Max Bowsher wrote:
Richard H. Broberg wrote:
In non-cygwin unix I'm familiar with being able to do the following
in a shell (bash or other):
$ nohup long-running-command
On Fri, Mar 07, 2003 at 06:17:17PM -0500, Igor Pechtchanski wrote:
On Fri, 7 Mar 2003, Max Bowsher wrote:
Christopher Faylor wrote:
On Fri, Mar 07, [EMAIL PROTECTED]:00:28PM -, Max Bowsher wrote:
Richard H. Broberg wrote:
In non-cygwin unix I'm familiar with being able to do the
Christopher Faylor wrote:
On Fri, Mar 07, 2003 at 06:17:17PM -0500, Igor Pechtchanski wrote:
On Fri, 7 Mar 2003, Max Bowsher wrote:
Christopher Faylor wrote:
This works for me:
nohup sleep 30 /dev/null foo 21
at least with the latest version of cygwin...
Doesn't work for me, running
* Richard H. Broberg (03-03-07 22:47 +0100)
In non-cygwin unix I'm familiar with being able to do the following in a
shell (bash or other):
$ nohup long-running-command
$ exit
and be able to leave it running.
However, under cygwin (this has been true for at least back to cygwin/1.3.6
Please keep replies on the list.
Richard H. Broberg wrote:
From: Max Bowsher [EMAIL PROTECTED]
An unfortunate consequence of how Windows handles console windows.
I believe it would be possible to write an alternative
implementation of nohup using fork/setsid, or perhaps even hack
some
Randal, Igor,
On Wed, Mar 05, 2003 at 08:15:09AM -0800, Randall R Schulz wrote:
If you're asking me, I'd say it's probably a good idea. It would
probably help keep lunkheads like me from doing stupid things like
copying tcsh to csh...
I've uploaded a new release with a postinstall script.
Hi,
after upgrading to cygwin 1.3.20-1, I noticed that my XEmacs 2.4.11
crashes under unreproducable circumstances. So I though OK, upgrade
XEmacs to 2.4.12, maybe this helps.
I downloaded the XEmacs 2.4.12 sources from www.xemacs.org, unpacked and
configured with ./configure --with-msw=yes
,
after upgrading to cygwin 1.3.20-1, I noticed that my XEmacs 2.4.11
crashes under unreproducable circumstances. So I though OK, upgrade
XEmacs to 2.4.12, maybe this helps.
I downloaded the XEmacs 2.4.12 sources from www.xemacs.org, unpacked and
configured with ./configure --with-msw=yes
Hi Rick,
I think you are missing an important point: I can build xemacs
successfully when I use the older (1.3.18) cygwin1.ddl! That's the only
thing I have changed about the environment (as you can see in the
environment dump, I'm still using gcc3). So, I insist: there is a bug in
1.3.20-1
On Tue, Mar 04, 2003 at 03:20:52PM -0500, Igor Pechtchanski wrote:
Konstantinos,
First off, the script is written for csh. Why would you expect sh or bash
to be able to interpret it? These shells use different syntax.
The original script failed because you don't have csh installed.
On Wed, 5 Mar 2003, Corinna Vinschen wrote:
On Tue, Mar 04, [EMAIL PROTECTED]:20:52PM -0500, Igor Pechtchanski wrote:
Konstantinos,
First off, the script is written for csh. Why would you expect sh or bash
to be able to interpret it? These shells use different syntax.
The original
At 01:47 2003-03-05, Corinna Vinschen wrote:
On Tue, Mar 04, 2003 at 03:20:52PM -0500, Igor Pechtchanski wrote:
Konstantinos,
First off, the script is written for csh. Why would you expect sh or bash
to be able to interpret it? These shells use different syntax.
The original script failed
On Wed, Mar 05, 2003 at 07:38:17AM -0800, Randall R Schulz wrote:
At 01:47 2003-03-05, Corinna Vinschen wrote:
P.S.: No, it doesn't. Create your own symlink or change the first
script line to `#!/bin/tcsh'
Corinna, Igor,
I wonder what this means:
% ll /bin/{t,}csh.exe
-rwxrwxrwx1
On Wed, 5 Mar 2003, Corinna Vinschen wrote:
At 01:47 2003-03-05, Corinna Vinschen wrote:
P.S.: No, it doesn't. Create your own symlink or change the first
script line to `#!/bin/tcsh'
Would you think it makes sense to create a csh symlink to tcsh.exe in
the package? Seems to be common
Corinna,
At 08:04 2003-03-05, Corinna Vinschen wrote:
...
Would you think it makes sense to create a csh symlink to tcsh.exe in
the package? Seems to be common on Linux at least.
If you're asking me, I'd say it's probably a good idea. It would
probably help keep lunkheads like me from doing
This was with 1.3.20. I found that others had the same problem on the
mailing list archives, and one person mentioned that going back to
1.3.19 fixed the problem for him.
I removed my cygwin folder and the registry keys, and reinstalled the
same packages as before, but this time selecting cygwin 1.3.19
Keith Hopkins wrote:
Hi!
1.3.20-1 on Win2k, downloaded 20030306.
I saw this when a friend of mine, and myself were trying to install
1.3.20 yesterday (dl, then install from dl).
The install would go fine, but when you started the shell, $UID would
have dropped the high bits from the NT
is not being recognized.
(B
(BBest regards,
(BFred Ulmer
(B
(B
(B-Original Message-
(BFrom: Larry Hall (RFK Partners, Inc.) [mailto:[EMAIL PROTECTED]
(BSent: Thursday, March 06, 2003 3:15 PM
(BTo: Keith Hopkins
(BCc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
(BSubject: Re: 1.3.20: bug: UID over
[EMAIL PROTECTED] wrote:
Hello,
Even after changing my UID in /etc/passwd from 65558 to 22, I still get the
following permission errors when I open a shell:
/usr/share/texmf/ls-R: Permission denied
/usr/share/texmf/aliases: Permission denied
Also, my .bashrc file in my home directory
Hi,
I am trying to run a configure file
./config Cygwin-i686
in order then to :
cd Cygwin-i686
make
The file config is like:
_
#!/bin/csh -f
goto begin
syntax:
echo ''
echo 'Usage: config [debug] [tcl] [fftw]
Konstantinos,
First off, the script is written for csh. Why would you expect sh or bash
to be able to interpret it? These shells use different syntax.
The original script failed because you don't have csh installed. Cygwin
does not have a csh package, but it does have a tcsh package that
Konstantinos Makrodimitris wrote:
I am trying to run a configure file
./config Cygwin-i686
The file config is like:
_
#!/bin/csh -f
Changing the first line of the config in sh mode
#!/bin/sh f
You do realize that csh
I am using cygwin 1.3.20 on Windows 98, and using the
gdbm 1.8.0-4 package that comes with this version of
cygwin.
In this environment I am having file access problems which
I've read elsewhere might be particular to this version
of gdbm on Win9x.
Is is possible to provide the latest gdbm
I'm trying to do a rsh without password but cygwin replies Permission
Denied message.
So I've created a .rhosts file in the home directory of the user who I'm
using to do the rsh containing a + symbol.
CYGWIN creates a file with 777 rights permissions, but I've changed to
600 and 644 without
On Wednesday, February 26, 2003 at 17:14:24, Ronald Landheer-Cieslakq wrote:
[...]
Has someone a script to fix the permissions of all standard
files to a reasonable value instead of +rx for all dirs and
+r for all files?
$ chmod -R a+r *
?
or
$ find -type d -exec chmod go+rx \{\} \;
your actual system configuration (the
output of cygcheck -svr) as a *non-compressed* text *attachment*
(as per http://cygwin.com/bugs.html).
Igor
Here it is the good 1.30.19-1 and the bad 1.3.20-1
Hmm, still having the problem. After upgrading to 1.3.20-1,
I just
' and
`wish.exe', but I cannot find the last ones. It is strange, because the
compile libraries (e.g. lib/libitcl.a) and startup files (e.g.
usr/share/itcl3.2/) for them are still supplied. Please help.
Cygwin DLL version info:
DLL version: 1.3.20
tcltk20030214-1
Best regards
On Wednesday, February 26, 2003 at 13:15:54, Ronald Landheer-Cieslak wrote:
This won't help you fix your problem, but might stop you from
running into new ones.. (see below)
o.k. so I keep with one installation ...
On Tue, 25 Feb 2003 [EMAIL PROTECTED] wrote:
[...]
You *cannot* have two
On Wed, 26 Feb 2003 [EMAIL PROTECTED] wrote:
On Wednesday, February 26, 2003 at 13:15:54, Ronald Landheer-Cieslak wrote:
This won't help you fix your problem, but might stop you from
running into new ones.. (see below)
o.k. so I keep with one installation ...
Good. :)
On Wednesday,
:53 PM
Please respond to cygwin
To: Jurgen Defurne/BRG/CE/[EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:Re: 1.3.20 most recent upgrades : rxvt creates 100% load on CPU
Classification:
On Fri, 21 Feb 2003 [EMAIL PROTECTED] wrote:
Hello, list
:53 PM
Please respond to cygwin
To: Jurgen Defurne/BRG/CE/[EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject:Re: 1.3.20 most recent upgrades : rxvt creates 100% load on CPU
Classification:
On Fri, 21 Feb 2003 [EMAIL PROTECTED] wrote:
Hello, list
On Tue, Feb 25, 2003 at 01:16:02AM -0500, Christopher Faylor wrote:
On Tue, Feb 25, 2003 at 04:51:33PM +1100, [EMAIL PROTECTED] wrote:
The seg fault only occurs in version 1.3.20. The TEST_FILE macro needs
to be set to the name of a file that is larger than 16 system pages +
32 bytes
* text *attachment*
(as per http://cygwin.com/bugs.html).
Igor
Here it is the good 1.30.19-1 and the bad 1.3.20-1
Hmm, still having the problem. After upgrading to 1.3.20-1,
I just copied the old version of cygwin1.dll into /bin and
it works.
I used strace in order to see
Accessing the mapped region of memory after an mmap call
with a non-zero offset results in a seg fault. A zero
offset will not result in a seg fault.
Cygwin1.dll version 1.3.19 doesn't experience this problem.
Cygcheck output is attached.
Example:
if (rslt = mmap(0, size, prot, MAP_SHARED,
On Tue, Feb 25, 2003 at 12:49:45PM +1100, [EMAIL PROTECTED] wrote:
Accessing the mapped region of memory after an mmap call
with a non-zero offset results in a seg fault. A zero
offset will not result in a seg fault.
Cygwin1.dll version 1.3.19 doesn't experience this problem.
Cygcheck output
Despite your warm welcome to the group, I have attached a
full test case. After further inspection it appears
that the seg fault only occurs if the file offset is greater
than 16 system pages. The seg fault only occurs in version
1.3.20. The TEST_FILE macro needs to be set to the name of a
file
= mmap(0, size, prot, MAP_SHARED, fd, offset)) == MAP_FAILED)
The seg fault only occurs in version 1.3.20. The TEST_FILE macro needs
to be set to the name of a file that is larger than 16 system pages +
32 bytes.
Although you've taken great offense at the suggestion that a real test
case
/3/12 5:38
889k 2003/02/08 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
cygwin1.dll v0.0 ts=2003/2/8 18:10
Cygwin DLL version info:
DLL version: 1.3.20
DLL epoch: 19
DLL bad signal mask: 19005
DLL old termios: 5
DLL malloc env: 28
On Fri, 21 Feb 2003 [EMAIL PROTECTED] wrote:
Hello, list,
I was experimenting with emacs, found out about C-h and Backspace
problem, and then, in suggestion to found answers, I decided to try
rxvt.
rxvt seems to have a load problem, however. I haven't found anything
in the mailing list
On Friday 21 Feb 03, [EMAIL PROTECTED] writes:
Hello, list,
I was experimenting with emacs, found out about C-h and Backspace
problem, and then, in suggestion to found answers, I decided to try
rxvt.
rxvt seems to have a load problem, however. I haven't found anything
in the mailing list
On Fri, Feb 21, 2003 at 05:00:55AM -0700, [EMAIL PROTECTED] wrote:
On Thu, 20 Feb 2003 14:04:58 -0500, Christopher Faylor wrote:
I've generate a snapshot with this fix included (thanks Corinna)
if anyone wants to try it.
I've replaced cygwin1.dll with 1.3.21
I presume that you mean the
On Tue, Feb 18, 2003 at 11:17:02PM +0300, Dmitry Rozmanov wrote:
It looks like Cygwin has a bug.
It was and is fixed in Cygwin CVS:
http://cygwin.com/ml/cygwin-cvs/2003-q1/msg00252.html
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405
On Thu, Feb 20, 2003 at 02:01:36PM -0500, Jason Tishler wrote:
On Tue, Feb 18, 2003 at 11:17:02PM +0300, Dmitry Rozmanov wrote:
It looks like Cygwin has a bug.
It was and is fixed in Cygwin CVS:
http://cygwin.com/ml/cygwin-cvs/2003-q1/msg00252.html
I've generate a snapshot with this fix
whorfin wrote:
I'll toss this on Jakarta's doorstep (or, if I get
really ambitious, attempt to fix their script myself).
This would be the ant shell script, no? I've opened up bug 17212
(http://issues.apache.org/bugzilla/show_bug.cgi?id=17212) at
issues.apache.org.
--
Unsubscribe info:
Hello,
I did not see any postings on this so far, so maybe I am the
only one having this problem ...
after upgrading to cygwin-1.3.20-1 all terminal progs
(tcsh,bash,jmacs,...) complain about terminal type not
found
Hi,
I use a python script (NTLM APS, see http://apserver.sourceforge.net/) to
access the web from cygwin (and other windows apps) at work.
This proxy software allows you to authenticate via an MS Proxy Server using
the proprietary NTLM protocol.
Since I upgraded cygwin to 1.3.20, it's
the proprietary NTLM protocol.
Since I upgraded cygwin to 1.3.20, it's not working anymore.
Details? For example, does APS hang? Or, does it just fail with an
error? Does APS use threads?
I am currently tracking down two Python regression test (i.e.,
test_asynchat and test_socket) hangs with 1.3.20-1
1 - 100 of 141 matches
Mail list logo
