Corinna Vinschen
http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-1.5.2-1-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-1.5.2-1.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/mercurial/setup.hint
Uploaded. Can the 1.4 versions be removed?
Yes.
After installing 2.6.5-1:
$ python -V
sh: /usr/bin/python: Permission denied
$ /usr/bin/python2.6.exe -V
sh: /usr/bin/python2.6.exe: Permission denied
$ ls -la /usr/bin/python*
lrwxrwxrwx 1 jaalto root 13 Jun 3 09:42 /usr/bin/python - python2.6.exe
lrwxrwxrwx 1
Hi guys,
pine is the only package still using the really crufty openssl-0.9.7.
Since Igor Peshansky is AWOL for quite some time now, I'd like to remove
the pine and openssl097 packages from the distro. ASAP. Does anybody
have a problem with that? If so, would you take over maintainership
for
Jari,
On Thu, Jun 03, 2010 at 10:26:50AM +0300, Jari Aalto wrote:
After installing 2.6.5-1:
$ python -V
sh: /usr/bin/python: Permission denied
$ /usr/bin/python2.6.exe -V
sh: /usr/bin/python2.6.exe: Permission denied
[snip]
WFM:
$ python -V
Python 2.6.5
$
New upstream version
to download:
wget -r -np -nH --cut-dirs=2 http://matzeri.altervista.org/cygwin-1.7/glpk/
glpk-4.44-1-src.tar.bz2
glpk-4.44-1.tar.bz2
libglpk-devel/libglpk-devel-4.44-1.tar.bz2
libglpk-devel/setup.hint
libglpk0/libglpk0-4.44-1.tar.bz2
libglpk0/outpb.lp
libglpk0/setup.hint
Corinna Vinschen wrote:
pine is the only package still using the really crufty openssl-0.9.7.
Since Igor Peshansky is AWOL for quite some time now, I'd like to
remove the pine and openssl097 packages from the distro. ASAP. Does
anybody have a problem with that? If so, would you take over
Updated list for this week:
* ImageMagick: upgrade to at least 6.5.2.9 (latest is 6.6.2.1)
* lighttpd: update to latest 1.4.26
* nano: upgrade to latest 2.2.4
wchar support can also be added as in Ports:
http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/apps/nano/
*
On 2 June 2010 21:39, Thomas Wolff wrote:
Before making it the only default, however, there's still two issues to
consider concerning interoperability with Windows programs:
* The known limitation with certain Windows (or even DOS) programs
due to the incompatibility of some of the
On Wed, Jun 02, 2010 at 06:54:12PM -0500, Yaakov wrote:
On Wed, 02 Jun 2010 14:30:52 +0100, Dave Korn wrote:
Let's call the shortcuts Cygwin Console and Cygwin GUI Terminal,
and then people will think it's obvious why there's two of them.
KISS: having two options *will* lead to confusion.
On Thu, Jun 3, 2010 at 3:54 AM, Yaakov wrote:
KISS: having two options *will* lead to confusion. Whenever mintty
becomes the default Cygwin shell, then the default Cygwin shortcuts
should point to mintty -, period.
Though I personally use rxvt-unicode and will continue to do so while
it works
On 6/2/2010 7:02 PM, Christopher Faylor wrote:
Does mintty currently work around any such problems?
I really don't understand the question in light of the observations that
there will be problems with some MS-DOS applications if we switch to
mintty because of cygwin's pty implementation.
On 6/3/2010 5:39 AM, Corinna Vinschen wrote:
Does anybody
have a problem with that? If so, would you take over maintainership
for pine?
Aren't all the cool kids using alpine now instead?
Am 03.06.2010 20:17, schrieb Andy Koppe:
On 2 June 2010 21:39, Thomas Wolff wrote:
...
* Another issue with even those Windows/DOS programs that do work in
general: They assume the Windows ANSI encoding so their output
(and input assumption) will not match the mintty character
Jason Tishler jason-/+chcdctalzr7s880jo...@public.gmane.org writes:
Jari,
On Thu, Jun 03, 2010 at 10:26:50AM +0300, Jari Aalto wrote:
After installing 2.6.5-1:
$ python -V
sh: /usr/bin/python: Permission denied
$ /usr/bin/python2.6.exe -V
sh: /usr/bin/python2.6.exe: Permission denied
Yaakov (Cygwin/X)
Today being 01 June, the due date for Python 2.6:
Jari Aalto:
bzr
codeville
getmail
mercurial
offlineimap
planet
python-crypto
python-feedparser
python-paramiko
spambayes
stgit
tailor
urlgrabber
Will be out ASAP when I get 2.6.x
On Thu, Jun 03, 2010 at 02:14:29PM -0600, Warren Young wrote:
On 6/2/2010 7:02 PM, Christopher Faylor wrote:
Does mintty currently work around any such problems?
I really don't understand the question in light of the observations that
there will be problems with some MS-DOS applications if we
On Thu, Jun 03, 2010 at 07:17:34PM +0100, Andy Koppe wrote:
On 2 June 2010 21:39, Thomas Wolff wrote:
Before making it the only default, however, there's still two issues to
consider concerning interoperability with Windows programs:
?? * The known limitation with certain Windows (or even DOS)
On Thu, Jun 03, 2010 at 02:16:21PM -0600, Warren Young wrote:
On 6/3/2010 5:39 AM, Corinna Vinschen wrote:
Does anybody
have a problem with that? If so, would you take over maintainership
for pine?
Aren't all the cool kids using alpine now instead?
That's what I hear. Also, from my very
On 3 June 2010 21:25, Thomas Wolff wrote:
Ah, right! I had not noticed this, only that error message are not fixed.
Something else that *is* fixed this way is e.g.
cmd /c help
(which also shows that cmd has a built-in chcp in addition to the
stand-alone chcp.com that at least Windows XP has).
On 2 June 2010 21:39, Thomas Wolff wrote:
Am 02.06.2010 15:30, schrieb Dave Korn:
We already get plenty of questions about the difference between a
console
and a terminal. Don't think it'll be any different really. Let's call
the
shortcuts Cygwin Console and Cygwin GUI Terminal, and then
Using Windows XP and cygwin started with the command
%RUN% XWin -multiwindow -clipboard -silent-dup-error -xkblayout ca
-xkbvariant multix -xkbmodel pc104
If the Windows keyboard is set to US, cygwin works fine. If the Windows
keyboard is set to Canadian Multilingual Standard, cygwin doesn't get
Hello,
SUMMARY:
I installed cygwin 1.7.5 on windows 7 (64 bit OS), and when I run some
command which uses perl, I get the following error:
0 [main] perl 2528 C:\cygwin\bin\perl.exe: *** fatal error - Internal
error: TP_NUM_W_BUFS too small.
DETAILS:
I installed cygwin, all of it on
On 2010.06.03 0:39, Eli Zaretskii wrote:
From: Oleksandr Gavenkogaven...@gmail.com
Date: Wed, 02 Jun 2010 23:40:46 +0300
I use Emacs 23.2 under Windows.
(call-process
echo.exe
nil (get-buffer *Messages*) nil
--bla {rev} }}}xxx{1}xxx{2}xxx{{{ )
put in Message buffer
Quoting n...@12000.org:
Hello,
SUMMARY:
I installed cygwin 1.7.5 on windows 7 (64 bit OS), and when I run some
command which uses perl, I get the following error:
0 [main] perl 2528 C:\cygwin\bin\perl.exe: *** fatal error - Internal
error: TP_NUM_W_BUFS too small.
SNIP
fyi;
I found this
PACKAGE DESCRIPTION
===
Homepage: http://mercurial.selenic.com
License : GPL
Distributed, efficient Python based source control system. Mercurial is
designed for efficient handling of very large distributed projects.
CHANGES SINCE LAST RELEASE
==
I've updated the version of OpenSSL to 0.9.8o-1. This also includes the
openssl-devel packages.
This is an upstream security release. The Cygwin release is build from
the vanilla sources, no additional patches.
Official release message:
For example Mercurial VCS hg distributed as python script.
To able invoke hg from cmd.exe (I some times use Far file manager
and all time native GNU Emacs) I wrote wrapper:
$ cat /bin/hg.bat
@echo off
python /bin/hg %*
This script work fine except case then one of argument
contain new line
I quite often notice that when I try to close gnus, which is using
(several instances of) openssl, it appears to hang. Today I for some
reason got so ed off with it, I started closing the processes I
thought belonged to it, starting with the openssl ones. As soon as I
closed the last one, gnus
On 6/3/2010 3:46 AM, Oleksandr Gavenko wrote:
On 2010.06.03 0:39, Eli Zaretskii wrote:
From: Oleksandr Gavenkogaven...@gmail.com
Date: Wed, 02 Jun 2010 23:40:46 +0300
I use Emacs 23.2 under Windows.
(call-process
echo.exe
nil (get-buffer *Messages*) nil
--bla {rev} }}}xxx{1}xxx{2}xxx{{{ )
On 6/3/2010 3:43 AM, n...@12000.org wrote:
perl-ming 0.4.3-1 Incomplete
That's not right. I'd suggest reinstalling perl-ming.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK
On 6/3/2010 8:08 AM, Larry Hall (Cygwin) wrote:
On 6/3/2010 3:43 AM, n...@12000.org wrote:
perl-ming 0.4.3-1 Incomplete
That's not right. I'd suggest reinstalling perl-ming.
I did the following:
1. reinstalled.
2. tried different source, downloaded, reinstalled
I still get the same thing,
Hi,
I would like to use perlMagick.
I installed perl-Image-Magick with setup.exe but I can't get it work.
What's the trick ?
$ perl -e use Image::Magick;
Can't load
'/usr/lib/perl5/vendor_perl/5.10/i686-cygwin/auto/Image/Magick/Magick.dll' for
module Image::Magick: No such file or directory
Using strace I was able to look at some of the functions that are
enumerated by debugging calls.
The trace below is done by ls.exe for each file (approximately 95k files @
88 mSecs/file), approximately 40 mSecs are spent in lstat64() and another
47 mSecs are spent in getacl().
It also *looks*
On 6/3/2010 12:32 PM, Nasser M. Abbasi wrote:
On 6/3/2010 8:08 AM, Larry Hall (Cygwin) wrote:
On 6/3/2010 3:43 AM, n...@12000.org wrote:
perl-ming 0.4.3-1 Incomplete
That's not right. I'd suggest reinstalling perl-ming.
I did the following:
1. reinstalled.
2. tried different source,
Larry Hall (Cygwin) wrote:
On 6/3/2010 3:43 AM, n...@12000.org wrote:
perl-ming 0.4.3-1 Incomplete
That's not right. I'd suggest reinstalling perl-ming.
Perhaps it has something to do with the colons in the manpage filenames?
Yaakov
--
Problem
On 6/3/2010 1:40 PM, Yaakov (Cygwin/X) wrote:
Larry Hall (Cygwin) wrote:
On 6/3/2010 3:43 AM, n...@12000.org wrote:
perl-ming 0.4.3-1 Incomplete
That's not right. I'd suggest reinstalling perl-ming.
Perhaps it has something to do with the colons in
On 6/3/2010 12:43 AM, n...@12000.org wrote:
Hello,
SUMMARY:
I installed cygwin 1.7.5 on windows 7 (64 bit OS), and when I run some
command which uses perl, I get the following error:
0 [main] perl 2528 C:\cygwin\bin\perl.exe: *** fatal error - Internal
error: TP_NUM_W_BUFS too small.
To make sure I'm understanding the implication of your response, let me
summarize...
According to the link you sent, the different user environment is
resulting not because of something that the ssh server (or cygwin) is
doing/configured to do but because of how Windows handles remote log-ins
On 6/3/2010 3:02 PM, Nasser M. Abbasi wrote:
Should I try building cygwin from sources on my PC?
Debugging it further would certainly be helpful. But if you don't actually
want to build Cygwin from source, you can always use a recent snapshot with
its source and debugging information as a
On 6/3/2010 2:56 PM, jayn...@us.ibm.com wrote:
To make sure I'm understanding the implication of your response, let me
summarize...
According to the link you sent, the different user environment is
resulting not because of something that the ssh server (or cygwin) is
doing/configured to do but
Can someone explain why if I use c:/some/path as an argument to git
clone, it fails. But if I use /cygdrive/c/some/path it works.
Here is an example:
GIT_TRACE=1 git clone c:/Users/hoffman/Work/My\
Builds/CMake-gmake/Tests/ExternalProject/LocalRepositories/GIT foobar
trace: built-in: git
On 6/3/2010 12:17 PM, Larry Hall (Cygwin) wrote:
On 6/3/2010 3:02 PM, Nasser M. Abbasi wrote:
Should I try building cygwin from sources on my PC?
Debugging it further would certainly be helpful. But if you don't actually
want to build Cygwin from source, you can always use a recent
On 06/03/2010 02:03 PM, Bill Hoffman wrote:
Can someone explain why if I use c:/some/path as an argument to git
clone, it fails. But if I use /cygdrive/c/some/path it works.
Because c:/some/path looks like you are asking for protocol:file for
talking to a remote machine, while
On 6/3/2010 4:19 PM, Nasser M. Abbasi wrote:
On 6/3/2010 12:17 PM, Larry Hall (Cygwin) wrote:
On 6/3/2010 3:02 PM, Nasser M. Abbasi wrote:
Should I try building cygwin from sources on my PC?
Debugging it further would certainly be helpful. But if you don't actually
want to build Cygwin
On 6/3/2010 4:20 PM, Eric Blake wrote:
On 06/03/2010 02:03 PM, Bill Hoffman wrote:
Can someone explain why if I use c:/some/path as an argument to git
clone, it fails. But if I use /cygdrive/c/some/path it works.
Because c:/some/path looks like you are asking for protocol:file for
talking to
On 06/03/2010 02:32 PM, Bill Hoffman wrote:
On 6/3/2010 4:20 PM, Eric Blake wrote:
On 06/03/2010 02:03 PM, Bill Hoffman wrote:
Can someone explain why if I use c:/some/path as an argument to git
clone, it fails. But if I use /cygdrive/c/some/path it works.
Because c:/some/path looks like
On 2010-06-03 18:04, Larry Hall (Cygwin) wrote:
On 6/3/2010 3:46 AM, Oleksandr Gavenko wrote:
On 2010.06.03 0:39, Eli Zaretskii wrote:
From: Oleksandr Gavenkogaven...@gmail.com
Date: Wed, 02 Jun 2010 23:40:46 +0300
I use Emacs 23.2 under Windows.
(call-process
echo.exe
nil (get-buffer
On 6/3/2010 4:39 PM, Eric Blake wrote:
On 06/03/2010 02:32 PM, Bill Hoffman wrote:
In that case, git is just blindly treating c: as ./c: - that is, the
relative file named c: in the current directory. Since POSIX allows
this interpretation, there's no reason for git to special case it and
Greetings, Dave Korn!
Erm... how about :type suffix? Don't know how POSIXy it is, but it's
close
enough to similar functionality of NTFS (file streams).
To save having the whole discussion again, here's the summary from last time:
On 06/03/2010 03:07 PM, Bill Hoffman wrote:
Again, I don't think this is git specific, but I would like to
understand at what level of cygwin this is coming from.
You've got the source code, go debug it if you'd like. But I could care
less about DOS names - either they work or they don't; in
Ok. Thanks for the help. I'll give it a try next week when I have access
again to the environment.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
On Thu, Jun 03, 2010 at 10:35:55AM -0700, Christopher Wingert wrote:
Using strace I was able to look at some of the functions that are
enumerated by debugging calls.
The trace below is done by ls.exe for each file (approximately 95k files @
88 mSecs/file), approximately 40 mSecs are spent in
On Thu, Jun 03, 2010 at 10:35:55AM -0700, Christopher Wingert wrote:
Using strace I was able to look at some of the functions that are
enumerated by debugging calls.
The trace below is done by ls.exe for each file (approximately 95k files
@
88 mSecs/file), approximately 40 mSecs are spent in
On Thu, Jun 03, 2010 at 05:32:46PM -0700, Christopher Wingert wrote:
On Thu, Jun 03, 2010 at 10:35:55AM -0700, Christopher Wingert wrote:
Using strace I was able to look at some of the functions that are
enumerated by debugging calls.
The trace below is done by ls.exe for each file
On Thu, Jun 03, 2010 at 05:32:46PM -0700, Christopher Wingert wrote:
Yeah, that's what I thought you were doing. Given that the timestamps
don't indicate elapsed time of function X, it's not always possible to
figure out how long a function takes by subtracting. Subtracting
timestamps shows
At 08:57 AM 6/3/2010, Adi B Treiner wrote:
Hello,
After upgrading to version 1.7.5 running cron tasks for normal local
users doesnt work anymore.
For those users cron always reports the following error:
cron.exe: *** fatal error - could not load user32, Win32 error 1114
This seems to be
On 6/3/2010 8:34 PM, surendar jeyadev wrote:
I have been using Cygwin for about 5 years on the same computer, without
a problem (but for a strange change in bash history behaviour about a few
months back -- more on that later, or in a separate thread). Suddenly,
today, something strange has
On Thu, Jun 03, 2010 at 07:57:31PM -0700, Christopher Wingert wrote:
On Thu, Jun 03, 2010 at 05:32:46PM -0700, Christopher Wingert wrote:
Yeah, that's what I thought you were doing. Given that the timestamps
don't indicate elapsed time of function X, it's not always possible
to figure out how
PACKAGE DESCRIPTION
===
Homepage: http://mercurial.selenic.com
License : GPL
Distributed, efficient Python based source control system. Mercurial is
designed for efficient handling of very large distributed projects.
CHANGES SINCE LAST RELEASE
==
I've updated the version of OpenSSL to 0.9.8o-1. This also includes the
openssl-devel packages.
This is an upstream security release. The Cygwin release is build from
the vanilla sources, no additional patches.
Official release message:
60 matches
Mail list logo
