I've updated clisp plus the subpackages
clisp-clx, clisp-gtk2 and clisp-gdi to 2.48-2, to fix the issues
reported at http://cygwin.com/ml/cygwin/2009-08/msg00265.html
2.48-2
* chmod +x /usr/lib/clisp-2.48/full*/svm.dll
* fixed wrong libdb4.6 dependency to libdb4.5
* fixed clisp-gdi.src.patch
O
2009/8/11 Reini Urban:
> 2009/8/10 Corinna Vinschen:
>> On Aug 10 20:11, Alexey Borzenkov wrote:
>>> On Mon, Aug 10, 2009 at 5:25 PM, Corinna
>>> Vinschen wrote:
>>> > That's a bug in your testsuite. I assume you're running the tests as
>>> > administrator, right? Administrators have the right to
Charles Wilson wrote:
> OK...new plan: jpeg-v7 will be released for cygwin-1.7 only, using
> gcc4/dw2/shared-libgcc only, and will have the name "cygjpeg-7.dll". It
> will NOT have lossless jpeg support.
>
> I'll do this soon.
I've just posted, for 1.7 only, an update for libjpeg to jpeg v7. T
The tiff package provides libraries and utilities for manipulating
TIFF image files.
This is a security update.
[[ compiled using gcc-3.4.4-999 ]]
This release is specific to cygwin-1.5. It imports a number of new
security patches from Debian.
CHANGES (since 3.8.2-4)
o
The tiff package provides libraries and utilities for manipulating
TIFF image files.
This is a security update.
[[ compiled using gcc-3.4.4-999 ]]
This release is specific to cygwin-1.7. It is compiled against the
(cygwin-1.7-only) libjpeg7 release, and imports a number of new security
patches f
The jpeg package contains the Independent JPEG Group's libjpeg library
and various utility programs for manipulating jpeg files and images.
This is a major update to the new upstream release. Also, support for
"lossless jpeg" has been removed (see below). Because these changes
break the ABI, the
The jpeg package contains the Independent JPEG Group's libjpeg library
and various utility programs for manipulating jpeg files and images.
This is a backwards-compatibility package, now that the jpeg-7 library
has been released.
[[ compiled using gcc-3.4.4-999 ]]
CHANGES (since 6b-20)
=
Eric,
Can you please update your git repo at git://repo.or.cz/libsigsegv/ericb.git
to latest libsigsegv-2.7 so that I can roll a 2.7+
Or should I rather ignore 2.7 totally? I see no cygwin relevant
changes in 2.7 at all.
Bruno did not include your cygwin fixes for the SEH chain corruption into 2.7.
2009/8/10 Corinna Vinschen:
> On Aug 10 20:11, Alexey Borzenkov wrote:
>> On Mon, Aug 10, 2009 at 5:25 PM, Corinna
>> Vinschen wrote:
>> > That's a bug in your testsuite. I assume you're running the tests as
>> > administrator, right? Administrators have the right to write to all
>> > files, even
On Mon, Aug 10, 2009 at 5:17 PM, Christopher Faylor wrote:
> Actually, I meant Cgywin 1.7. Sorry for the cornfusion.
cgf apologizes! In writing! Alert the media!
:)
--
Mark J. Reed
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Docum
On Mon, Aug 10, 2009 at 04:44:09PM -0400, Larry Hall (Cygwin) wrote:
>On 08/10/2009 04:07 PM, Ralph Hempel wrote:
>> Christopher Faylor wrote:
>>> On Mon, Aug 10, 2009 at 02:54:28PM -0400, Larry Hall (Cygwin) wrote:
On 08/10/2009 12:44 PM, Corinna Vinschen wrote:
> And ther
On 08/10/2009 04:07 PM, Ralph Hempel wrote:
Christopher Faylor wrote:
On Mon, Aug 10, 2009 at 02:54:28PM -0400, Larry Hall (Cygwin) wrote:
On 08/10/2009 12:44 PM, Corinna Vinschen wrote:
And there's no way back after an update. But as I noted in my zillion
(apparently unread) test announcem
Christopher Faylor wrote:
On Mon, Aug 10, 2009 at 02:54:28PM -0400, Larry Hall (Cygwin) wrote:
On 08/10/2009 12:44 PM, Corinna Vinschen wrote:
And there's no way back after an update. But as I noted in my zillion
(apparently unread) test announcements, it's no problem to run 1.5 and
1.7 ins
On Mon, Aug 10, 2009 at 02:54:28PM -0400, Larry Hall (Cygwin) wrote:
>On 08/10/2009 12:44 PM, Corinna Vinschen wrote:
>
>
>
>> And there's no way back after an update. But as I noted in my zillion
>> (apparently unread) test announcements, it's no problem to run 1.5 and
>> 1.7 installations in sep
Alexey Borzenkov wrote:
> On Mon, Aug 10, 2009 at 8:11 PM, Alexey Borzenkov wrote:
>> Anyway, it means there is a bug in perl, because on Linux:
>
> On second though, it is actually bug in Cygwin. Programs and libraries expect
> superuser behavior only when user id is zero, which is clearly not th
On Mon, Aug 10, 2009 at 8:40 PM, Corinna
Vinschen wrote:
> That's a bug in perl. There are other OSes out there which have
> root-like permissions for non-0 uids. Perl should use the access()
> function to check for read/write/execute permissions, which always
> returns the correct result indepen
On 08/10/2009 12:44 PM, Corinna Vinschen wrote:
And there's no way back after an update. But as I noted in my zillion
(apparently unread) test announcements, it's no problem to run 1.5 and
1.7 installations in separate directories side-by-side.
I don't know about anyone else, but I plan to
On Mon, Aug 10, 2009 at 8:11 PM, Alexey Borzenkov wrote:
> Anyway, it means there is a bug in perl, because on Linux:
On second though, it is actually bug in Cygwin. Programs and libraries
expect superuser behavior only when user id is zero, which is clearly
not the case in Cygwin 1.7. I think tha
On Aug 10 19:04, Corinna Vinschen wrote:
> On Aug 10 17:42, Jon TURNEY wrote:
> > I also have this problem in it's second (noacl) form. With this mount
> >
> > //necker/jon on /home/jon type smbfs (binary,exec,noacl,user)
> >
> > running the t.sh test script fails in a directory on this mount
> >
The run package provides a simple application to launch console programs
with their console hidden.
[[ compiled using gcc-3.4.4-999 ]]
CHANGES since run-1.1.10
* New maintainer (Charles Wilson took over from Alexander Gottwald)
* Updated build machinery
* Added patch
The run package provides a simple application to launch console programs
with their console hidden.
[[ compiled using gcc-3.4.4-999 ]]
CHANGES since run-1.1.10
* Fork for cygwin-1.7 packaging. Underlying source branch will occur
later, with 1.2.x.
* New maintainer (
On Aug 10 17:42, Jon TURNEY wrote:
> On 06/08/2009 18:50, Nahor wrote:
>> Corinna Vinschen wrote:
>>> On Aug 5 13:40, Nahor wrote:
If I mount with "noacl", I get a slightly different error but still
no cigar:
$ ./t.sh
-bash: ./t.sh: /bin/sh: bad interpreter: Permission denied
>>
On Aug 10 18:31, Thorsten Kampe wrote:
> * Corinna Vinschen (Mon, 10 Aug 2009 16:38:54 +0200)
> > On Aug 10 14:15, Thorsten Kampe wrote:
> > > * Corinna Vinschen (Mon, 10 Aug 2009 13:34:25 +0200)
> > > > On Aug 10 12:57, Thorsten Kampe wrote:
> > > > > I upgraded to Windows 7 on Sunday and now when
On Mon, Aug 10, 2009 at 06:31:53PM +0200, Thorsten Kampe wrote:
>* Corinna Vinschen (Mon, 10 Aug 2009 16:38:54 +0200)
>>On Aug 10 14:15, Thorsten Kampe wrote:
>>>* Corinna Vinschen (Mon, 10 Aug 2009 13:34:25 +0200)
On Aug 10 12:57, Thorsten Kampe wrote:
>I upgraded to Windows 7 on Sunday an
On 06/08/2009 18:50, Nahor wrote:
Corinna Vinschen wrote:
On Aug 5 13:40, Nahor wrote:
If I mount with "noacl", I get a slightly different error but still
no cigar:
$ ./t.sh
-bash: ./t.sh: /bin/sh: bad interpreter: Permission denied
$
This only happens if your account doesn't have execute perm
On Aug 10 20:11, Alexey Borzenkov wrote:
> On Mon, Aug 10, 2009 at 5:25 PM, Corinna
> Vinschen wrote:
> > That's a bug in your testsuite. I assume you're running the tests as
> > administrator, right? Administrators have the right to write to all
> > files, even R/O files, according to POSIX rule
* Corinna Vinschen (Mon, 10 Aug 2009 16:38:54 +0200)
> On Aug 10 14:15, Thorsten Kampe wrote:
> > * Corinna Vinschen (Mon, 10 Aug 2009 13:34:25 +0200)
> > > On Aug 10 12:57, Thorsten Kampe wrote:
> > > > I upgraded to Windows 7 on Sunday and now whenever cron runs a job,
> > > > the new forked cron
cormoran wrote:
> Hello, I'm having trouble with dll remaping and I've tried to run rebaseall
> but when I issue the command I get the following error message:
> gzip: stdin: unexpected end of file
> Does anyone know how this can be fixed?
Argh. You must have had a crash sometime while run
On Mon, Aug 10, 2009 at 5:25 PM, Corinna
Vinschen wrote:
> That's a bug in your testsuite. I assume you're running the tests as
> administrator, right? Administrators have the right to write to all
> files, even R/O files, according to POSIX rules. Your test would fail
> on Linux as well, if you
Corinna Vinschen wrote:
> On Aug 10 16:24, Steven Hartland wrote:
>> It might be a silly idea but would it potentially be an option to alter
>> this behaviour based on an cygwin environment variable, so that the past
>> behaviour is restored for wider compatibility.
>
> Sorry, but no. The switch
On Aug 10 16:24, Steven Hartland wrote:
> In this example the result was nothing worked as the myexe is a none native
> binary only myexe.exe is a windows exe, but I wouldnt be surprised if there
> are cases where you have and exe and a data file with the name the same
> just the app with the .exe
- Original Message -
From: "Corinna Vinschen"
On Aug 8 03:16, Steven Hartland wrote:
If you extract a tar.gz file with an executable file and
an excitable file of the same name but with the .exe extension
on extract the .exe file is inexplicably deleted.
e.g.
tar -xvzf test.tar.gz
my
On Aug 10 13:23, Robert Bogomip wrote:
> This works under 1.5 (though I seem to remember that, many moons ago, it
> used to fail in the same way there too). Consider:
>
> $ while svn ls svn+ssh://myserver/myrepo/ >/dev/null; do date; done
> Mon Aug 10 12:57:09 GMTDT 2009
> Mon Aug 10 12:57:10 GMTD
On Aug 10 14:15, Thorsten Kampe wrote:
> * Corinna Vinschen (Mon, 10 Aug 2009 13:34:25 +0200)
> > On Aug 10 12:57, Thorsten Kampe wrote:
> > > I upgraded to Windows 7 on Sunday and now whenever cron runs a job,
> > > the new forked cron process is visible in a console window. I
> > > suspect that t
* Thorsten Kampe (Mon, 10 Aug 2009 16:28:30 +0200)
> The current version is "RTM" - "Released to manufacturing" since last
> Thursday.
Actually it's RTM for a month now. Available on Technet and MSDN since
last Thursday.
Thorsten
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On Mon, Aug 10, 2009 at 10:28 AM, Thorsten Kampe wrote:
> The current version is "RTM" - "Released to manufacturing" since last
> Thursday.
Ah, missed that milestone. I retract the observation then.
--
Mark J. Reed
--
Problem reports: http://cygwin.com/problems.html
FAQ:
* Mark J. Reed (Mon, 10 Aug 2009 09:35:06 -0400)
> On Mon, Aug 10, 2009 at 9:29 AM, Thorsten Kampe wrote:
> > Only if you assume that Windows 7 is still in beta (which it is not).
>
> It won't be released until October.
Make that "it won't be available in the shops until October".
> The current
Ken Brown-6 wrote:
>
> Have you tried the latest snapshot (2009-08-04)?
>
Not yet, but now I downloaded it...
In fact, I'll try it only if things become unbearable,
or if my X crashes.
I tend to keep my things up for a few days...
It takes some time to set everything up.
Thanks,
Marc
--
Vie
Hello, I'm having trouble with dll remaping and I've tried to run rebaseall
but when I issue the command I get the following error message:
gzip: stdin: unexpected end of file
Does anyone know how this can be fixed?
--
View this message in context:
http://www.nabble.com/cygwin-rebaseall-not
On 8/10/2009 9:25 AM, Marc Girod wrote:
Hello,
I upgraded to 1.7.0-56, then did my usual rebaseall/peflagsall.
It went well, but now, I keep getting failures to start new shells
under GNU emacs.
I get the following error:
Can't exec program: /usr/bin/bash
Process shell<4> exited abnormally wit
On Mon, Aug 10, 2009 at 9:29 AM, Thorsten Kampe wrote:
> Only if you assume that Windows 7 is still in beta (which it is not).
It won't be released until October. The current version is a "release
candidate". How is that different from being in beta? Regardless of
terminology, both Windows 7 an
* Mark J. Reed (Mon, 10 Aug 2009 08:46:11 -0400)
> n Mon, Aug 10, 2009 at 8:15 AM, Thorsten Kampe wrote:
> >> > I upgraded to Windows 7 ...
>
> > I'll probably wait until 1.7 is out of beta and an "official" migration
> > document is
> > released.
>
> OK, but why are you willing to upgrade to Wi
Hello,
I upgraded to 1.7.0-56, then did my usual rebaseall/peflagsall.
It went well, but now, I keep getting failures to start new shells
under GNU emacs.
I get the following error:
Can't exec program: /usr/bin/bash
Process shell<4> exited abnormally with code 127
It succeeded first a few tim
On Aug 10 17:19, Alexey Borzenkov wrote:
> Hi,
>
> $ echo foo >test.txt
> $ chmod 0444 test.txt
> $ echo bar >test.txt
>
> This succeeds, even though the file is readonly, and permissions don't
> allow writing to the file. What's even stranger is that other programs
> (i.e. Notepad and other edit
Hi,
$ echo foo >test.txt
$ chmod 0444 test.txt
$ echo bar >test.txt
This succeeds, even though the file is readonly, and permissions don't
allow writing to the file. What's even stranger is that other programs
(i.e. Notepad and other editors) can't write to this file, because
there are no writing
On Aug 8 03:16, Steven Hartland wrote:
> If you extract a tar.gz file with an executable file and
> an excitable file of the same name but with the .exe extension
> on extract the .exe file is inexplicably deleted.
>
> e.g.
> tar -xvzf test.tar.gz
> mydir/myexe.exe
> mydir/myexe
>
> ls myddir
> my
n Mon, Aug 10, 2009 at 8:15 AM, Thorsten Kampe wrote:
>> > I upgraded to Windows 7 ...
> I'll probably wait until 1.7 is out of beta and an "official" migration
> document is
> released.
OK, but why are you willing to upgrade to Windows 7 while *it's* still
in beta but reluctant to upgrade to t
Bruno Haible wrote:
Hi,
The attached test program for pthread_once uses the following basic POSIX
threads functions:
pthread_create
pthread_join
pthread_mutex_init
pthread_mutex_lock
pthread_mutex_unlock
pthread_once
pthread_rwlock_init
pthread_rwlock_rdlock
pthread_rwlock_unlo
This works under 1.5 (though I seem to remember that, many moons
ago, it used to fail in the same way there too). Consider:
$ while svn ls svn+ssh://myserver/myrepo/ >/dev/null; do date; done
Mon Aug 10 12:57:09 GMTDT 2009
Mon Aug 10 12:57:10 GMTDT 2009
Mon Aug 10 12:57:11 GMTDT 2009
Mon Aug 10
* Corinna Vinschen (Mon, 10 Aug 2009 13:34:25 +0200)
> On Aug 10 12:57, Thorsten Kampe wrote:
> > I upgraded to Windows 7 on Sunday and now whenever cron runs a job,
> > the new forked cron process is visible in a console window. I
> > suspect that this might be related to the new "Console Window H
On Aug 10 12:57, Thorsten Kampe wrote:
> Hi,
>
> I upgraded to Windows 7 on Sunday and now whenever cron runs a job, the
> new forked cron process is visible in a console window. I suspect that
> this might be related to the new "Console Window Host" (conhost.exe) as
> I also get this window wh
On Aug 10 12:13, Bruno Haible wrote:
> Hi,
>
> The attached test program for pthread_once uses the following basic POSIX
> threads functions:
> pthread_create
> pthread_join
> pthread_mutex_init
> pthread_mutex_lock
> pthread_mutex_unlock
> pthread_once
> pthread_rwlock_init
> pthr
On Aug 10 15:20, Huang Bambo wrote:
> Run "net star cygserver" first
Actually you have to install the service first, using the cygserver-config
script, or you can just run /usr/sbin/cygserver under your own account
for testing. Note that under Cygwin 1.5.x you still have to use the
CYGWIN=server
Hi,
I upgraded to Windows 7 on Sunday and now whenever cron runs a job, the
new forked cron process is visible in a console window. I suspect that
this might be related to the new "Console Window Host" (conhost.exe) as
I also get this window when I run screen inside a shell.
Thorsten
--
Prob
2009/8/9 Mark Harig:
> Thank you for providing clisp version 2.48.
>
> I am unable to start clisp if I specify the full linking set:
>
> $ clisp -Kfull
> /usr/lib/clisp-2.48/full/lisp.exe: error while loading shared libraries:
> svm.dll: cannot open shared object file: No such file or directory
>
>
Hi,
The attached test program for pthread_once uses the following basic POSIX
threads functions:
pthread_create
pthread_join
pthread_mutex_init
pthread_mutex_lock
pthread_mutex_unlock
pthread_once
pthread_rwlock_init
pthread_rwlock_rdlock
pthread_rwlock_unlock
pthread_rwlock_wr
Run "net star cygserver" first
2009/8/10 Scott
>
> When I compile and run the following example code within cygwin (gcc msgsnd.c
> -o msgsnd), I get an error "Bad system call"
>
> This seems to be a bug; it runs fine under linux.
>
> #include
>
> int main() {
> int msqid = 0;
> int rc;
>
When I compile and run the following example code within cygwin (gcc
msgsnd.c -o msgsnd), I get an error "Bad system call"
This seems to be a bug; it runs fine under linux.
#include
int main() {
int msqid = 0;
int rc;
size_t msgsz;
struct {
long int mtype;
char
58 matches
Mail list logo
