Corinna Vinschen writes:
> I patched setfacl to not require trailing colons anymore. This also
> fixes a bug in terms of the allowed acl entries when deleting.
Great, thanks!
[…]
> I just created a new snapshot on https://cygwin.com/snapshots/
> containing these patches. Please give them a try.
On Sep 2 22:23, Achim Gratz wrote:
> Corinna Vinschen writes:
> > $ setfacl -d g:system: filename
> >
> > Note the trailing colon.
>
> That's not what the man page specifies, however. I'll keep it in mind.
I patched setfacl to not require trailing colons anymore. This also
fixes a bug in t
Corinna Vinschen writes:
> $ setfacl -d g:system: filename
>
> Note the trailing colon.
That's not what the man page specifies, however. I'll keep it in mind.
>> Removing the group
>> owner ACL instead did the right thing in at least one instance.
>
> ??? It shouldn't. Removing the standard
On Sep 2 21:42, Achim Gratz wrote:
> Corinna Vinschen writes:
> > More or less, just compare the ACLs and see if you find strange
> > differences. This only works for the ACLs created or modified with
> > `setfacl' and the snapshot DLL.
>
> I see, I'll have to make extra tests for this. Usually
Corinna Vinschen writes:
> More or less, just compare the ACLs and see if you find strange
> differences. This only works for the ACLs created or modified with
> `setfacl' and the snapshot DLL.
I see, I'll have to make extra tests for this. Usually I just have to
live with some inherited ACL tha
On Sep 2 19:29, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> Installed, everything looks fine so far.
> >
> > Thanks for testing! Maybe you'd like to have a view into the simple
> > as well as the more complex ACLs created by Cygwin? Icacls output
> > is moderately easy to read. If you ha
Corinna Vinschen writes:
>> Installed, everything looks fine so far.
>
> Thanks for testing! Maybe you'd like to have a view into the simple
> as well as the more complex ACLs created by Cygwin? Icacls output
> is moderately easy to read. If you have questions or concerns...
I've used icacls in
On Sep 1 19:38, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Over the weekend it occured to me that the acl(2) function created ACLs
> > which not aligned well with the ACLs created by open(2),chmod(2), etc.
> > Yesterday I fixed the acl(2) function to create ACLs the same way as
> > the oth
Corinna Vinschen writes:
> Over the weekend it occured to me that the acl(2) function created ACLs
> which not aligned well with the ACLs created by open(2),chmod(2), etc.
> Yesterday I fixed the acl(2) function to create ACLs the same way as
> the other functions, especially in terms of the owner
On Aug 29 09:58, Achim Gratz wrote:
> Achim Gratz NexGo.DE> writes:
> > > Please test.
> >
> > This fixes the "read-only" problem in Emacs (so that hunch was correct).
> > Perl still doesn't play, but I think the 5.18 version should get it correct.
> > Will need to switch a test installation ove
On Aug 30 03:32, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
>
> > What needs to be done is to fix the ssh-host-config script. It adds an
> > ACE for SYSTEM on /var/empty, /etc, and /var/log for no apparent reason.
>
> If it's not apparent: you can actually prevent system from accessing t
Greetings, Corinna Vinschen!
> What needs to be done is to fix the ssh-host-config script. It adds an
> ACE for SYSTEM on /var/empty, /etc, and /var/log for no apparent reason.
If it's not apparent: you can actually prevent system from accessing the file
by removing access from SYSTEM user to th
On Aug 29 15:36, Ken Brown wrote:
> On 8/29/2014 3:23 PM, Achim Gratz wrote:
> >Ken Brown writes:
> >>With the latest snapshot I can't start the sshd service. The
> >>Application Log just says, "`sshd' service stopped, exit
> >>status:255". The problem doesn't occur with the 2014-08-27 snapshot.
>
On 8/29/2014 4:00 PM, Achim Gratz wrote:
> Ken Brown writes:
>> I just checked /var/log/sshd.log. (I hadn't thought to do that
>> before.) The last message in it is, "/var/empty must be owned by root
>> and not group or world-writable." So the problem seems to be that
>> /var/empty appears to ssh
Greetings, Ken Brown!
>>> With the latest snapshot I can't start the sshd service. The
>>> Application Log just says, "`sshd' service stopped, exit
>>> status:255". The problem doesn't occur with the 2014-08-27 snapshot.
>>> I guess this has something to do with the new permissions on various
>>>
Ken Brown writes:
> I just checked /var/log/sshd.log. (I hadn't thought to do that
> before.) The last message in it is, "/var/empty must be owned by root
> and not group or world-writable." So the problem seems to be that
> /var/empty appears to sshd to be group writable under the latest
> snaps
On 8/29/2014 3:23 PM, Achim Gratz wrote:
Ken Brown writes:
With the latest snapshot I can't start the sshd service. The
Application Log just says, "`sshd' service stopped, exit
status:255". The problem doesn't occur with the 2014-08-27 snapshot.
I guess this has something to do with the new per
Ken Brown writes:
> With the latest snapshot I can't start the sshd service. The
> Application Log just says, "`sshd' service stopped, exit
> status:255". The problem doesn't occur with the 2014-08-27 snapshot.
> I guess this has something to do with the new permissions on various
> files, but I'm
On 8/29/2014 7:09 AM, Corinna Vinschen wrote:
On Aug 29 09:58, Achim Gratz wrote:
Achim Gratz NexGo.DE> writes:
Please test.
This fixes the "read-only" problem in Emacs (so that hunch was correct).
Perl still doesn't play, but I think the 5.18 version should get it correct.
Will need to swit
On Aug 29 09:58, Achim Gratz wrote:
> Achim Gratz NexGo.DE> writes:
> > > Please test.
> >
> > This fixes the "read-only" problem in Emacs (so that hunch was correct).
> > Perl still doesn't play, but I think the 5.18 version should get it correct.
> > Will need to switch a test installation ove
Achim Gratz NexGo.DE> writes:
> > Please test.
>
> This fixes the "read-only" problem in Emacs (so that hunch was correct).
> Perl still doesn't play, but I think the 5.18 version should get it correct.
> Will need to switch a test installation over for that, though.
With that snapshot in place
On Aug 28 21:00, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
>
> >> > It's what "acl" means on Cygwin. "acl" means that Windowsd ACLs are used
> >> > and permissions are handled and converted to and from POSIX permissions.
> >> > "noacl" means, Cygwin ignores all ACLs and fakes ownership a
Greetings, Achim Gratz!
>> Here's the prerequisite:
>>
>> Would more than one person want that *and* be willing to give this a
>> *thorough* testing?
> That really becomes an issue only if you have to use external shares
> that are set up in peculiar ways and AD integration.
I've managed to
Corinna Vinschen writes:
> Here's the prerequisite:
>
> Would more than one person want that *and* be willing to give this a
> *thorough* testing?
That really becomes an issue only if you have to use external shares
that are set up in peculiar ways and AD integration. The number of
people tha
Andrey Repin writes:
>> What Cygwin could do is to perform ACL-based access checks independently of
>> the "acl"/"noacl" mount mode on FSes supporting ACLs. However, if you want
>> ACLs, why not use the "acl" mount mode in the first place?
>
> ACL inheritance, mostly. POSIX'ized permissions break
Greetings, Corinna Vinschen!
>> > It's what "acl" means on Cygwin. "acl" means that Windowsd ACLs are used
>> > and permissions are handled and converted to and from POSIX permissions.
>> > "noacl" means, Cygwin ignores all ACLs and fakes ownership and POSIX
>> > permissions only based only on fi
Corinna Vinschen cygwin.com> writes:
> Since the CLASS_OBJ and DEF_CLASS_OBJ entries only exist if secondary
> user and group (default) entries exist, that means the default
> permission entry only consists of 3 ACEs. This in turn means, the
> constant MIN_ACL_ENTRIES changed from 4 to 3.
>
> Th
On Aug 28 15:04, Achim Gratz wrote:
> Corinna Vinschen cygwin.com> writes:
> > I implemented this preliminary and uploaded a snapshot to
> > https://cygwin.com/snapshots/
>
> Oh, great! I'll bump my machine to that snapshot tomorrow.
>
> Since I can now compile my own DLL, would that be a good
Corinna Vinschen cygwin.com> writes:
> I implemented this preliminary and uploaded a snapshot to
> https://cygwin.com/snapshots/
Oh, great! I'll bump my machine to that snapshot tomorrow.
Since I can now compile my own DLL, would that be a good time to ask what
could be done for that link count
On Aug 28 17:23, Andrey Repin wrote:
> > It's what "acl" means on Cygwin. "acl" means that Windowsd ACLs are used
> > and permissions are handled and converted to and from POSIX permissions.
> > "noacl" means, Cygwin ignores all ACLs and fakes ownership and POSIX
> > permissions only based only on
Greetings, Corinna Vinschen!
>> > faccessat/access/eaccess don't try to be intelligent by themselves.
>> > Rather they just call a Windows function if the filesystem is mounted
>> > with "acl" mount flags:
>>
>> > - Fetch file's security descriptor
>> > - Create process impersonation token.
>> >
On Aug 28 11:55, Corinna Vinschen wrote:
> On Aug 28 07:25, Achim Gratz wrote:
> > As a concrete example, in the following the directory x86 shows up on Cygwin
> > as follows:
> >
> > > getfacl x86
> > # file: x86
> > # owner: otheruser
> > # group: Domain Users
> > user::---
> > group::---
> > gr
On 08/27/2014 09:15 AM, Achim Gratz wrote:
> Ken Brown cornell.edu> writes:
>> Achim, could you send me a recipe for reproducing the problem so that I
>> can test further? Please be very detailed; I have no experience with ACLs.
>
> Let's get one issue out of the way first that may be a Cygwin
On Aug 28 01:02, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
>
> > faccessat/access/eaccess don't try to be intelligent by themselves.
> > Rather they just call a Windows function if the filesystem is mounted
> > with "acl" mount flags:
>
> > - Fetch file's security descriptor
> > - Create
On Aug 28 07:25, Achim Gratz wrote:
> Achim Gratz NexGo.DE> writes:
> > Let's get one issue out of the way first that may be a Cygwin bug: on Linux
> > a file with all access removed via standard POSIX modes and then access
> > granted via ACL would place the mask bits of the ACL (the maximum perm
Achim Gratz NexGo.DE> writes:
> Let's get one issue out of the way first that may be a Cygwin bug: on Linux
> a file with all access removed via standard POSIX modes and then access
> granted via ACL would place the mask bits of the ACL (the maximum permission
> that can be granted via ACL, usuall
Greetings, Corinna Vinschen!
> faccessat/access/eaccess don't try to be intelligent by themselves.
> Rather they just call a Windows function if the filesystem is mounted
> with "acl" mount flags:
> - Fetch file's security descriptor
> - Create process impersonation token.
> - Call NtAccessCheck
On 8/27/2014 10:40 AM, Eric Blake wrote:
On 08/27/2014 07:47 AM, Corinna Vinschen wrote:
Works for vim. Does the Emacs configure test only check for POSIX
ACL functions and not for Solaris ACL functions, by any chance?
I spoke too soon. It does detect that Cygwin has certain ACL functions.
Ken Brown cornell.edu> writes:
> Achim, could you send me a recipe for reproducing the problem so that I
> can test further? Please be very detailed; I have no experience with ACLs.
Let's get one issue out of the way first that may be a Cygwin bug: on Linux
a file with all access removed via st
On 08/27/2014 07:47 AM, Corinna Vinschen wrote:
>>>
>>> Works for vim. Does the Emacs configure test only check for POSIX
>>> ACL functions and not for Solaris ACL functions, by any chance?
>>
>> I spoke too soon. It does detect that Cygwin has certain ACL functions.
>> But the feature that Achi
On Aug 27 08:52, Ken Brown wrote:
> On 8/27/2014 4:42 AM, Corinna Vinschen wrote:
> >On Aug 26 18:12, Ken Brown wrote:
> >>On 8/26/2014 2:55 PM, Achim Gratz wrote:
> >>>2) Files that have no POSIX permissions (filemode ) and where access
> >>>is granted via ACL only get always opened as "read-o
On 8/27/2014 4:42 AM, Corinna Vinschen wrote:
On Aug 26 18:12, Ken Brown wrote:
On 8/26/2014 2:55 PM, Achim Gratz wrote:
2) Files that have no POSIX permissions (filemode ) and where access
is granted via ACL only get always opened as "read-only" and you have to
C-x C-q them before saving.
On Aug 26 18:12, Ken Brown wrote:
> On 8/26/2014 2:55 PM, Achim Gratz wrote:
> >Ken Brown writes:
> >>It looks like my idea is going to work, but it needs testing to make
> >>sure I've implemented it correctly. If anyone is willing to test it,
> >>you can download emacs-24.3.93-2 from my personal
On 8/26/2014 2:55 PM, Achim Gratz wrote:
Ken Brown writes:
It looks like my idea is going to work, but it needs testing to make
sure I've implemented it correctly. If anyone is willing to test it,
you can download emacs-24.3.93-2 from my personal Cygwin repository:
http://sanibeltranquility
Ken Brown writes:
> It looks like my idea is going to work, but it needs testing to make
> sure I've implemented it correctly. If anyone is willing to test it,
> you can download emacs-24.3.93-2 from my personal Cygwin repository:
>
> http://sanibeltranquility.com/cygwin/
>
> Instructions can be
On Mon, Aug 25, 2014 at 8:00 PM, Ken Brown wrote:
> It looks like my idea is going to work, but it needs testing to make sure
> I've implemented it correctly. If anyone is willing to test it, you can
> download emacs-24.3.93-2 from my personal Cygwin repository:
I've downloaded it - no problems s
On 8/18/2014 8:28 AM, Ken Brown wrote:
On 8/8/2014 9:26 AM, Ken Brown wrote:
On 8/7/2014 5:42 PM, Eric Blake wrote:
On 08/07/2014 12:53 PM, Ken Brown wrote:
On 8/7/2014 11:30 AM, Eric Blake wrote:
On 08/07/2014 05:51 AM, Ken Brown wrote:
I think I found the problem with NORMAL mutexes. ema
On 08/18/2014 10:58 AM, Peter Hull wrote:
On Mon, Aug 18, 2014 at 1:28 PM, Ken Brown wrote:
I've just made a new emacs test release that includes a workaround for this
bug. I think I see a way to make emacs use Cygwin's malloc; if this works,
it will provide a better fix for the bug.
I'd like
On Mon, Aug 18, 2014 at 1:28 PM, Ken Brown wrote:
> I've just made a new emacs test release that includes a workaround for this
> bug. I think I see a way to make emacs use Cygwin's malloc; if this works,
> it will provide a better fix for the bug.
I'd like to give this a try. I've selected Exp m
On 8/8/2014 9:26 AM, Ken Brown wrote:
On 8/7/2014 5:42 PM, Eric Blake wrote:
On 08/07/2014 12:53 PM, Ken Brown wrote:
On 8/7/2014 11:30 AM, Eric Blake wrote:
On 08/07/2014 05:51 AM, Ken Brown wrote:
I think I found the problem with NORMAL mutexes. emacs calls
pthread_atfork after initializi
On 8/8/2014 11:39 AM, Peter Hull wrote:
A bug in Emacs? Gosh I thought it was probably just me doing something silly!
Thanks for your help everyone in tracking this down.
Ken, do you know if it's possible to subscribe to the bug report - I'd
be interested in knowing how it pans out.
No, I don
A bug in Emacs? Gosh I thought it was probably just me doing something silly!
Thanks for your help everyone in tracking this down.
Ken, do you know if it's possible to subscribe to the bug report - I'd
be interested in knowing how it pans out.
Pete
--
Problem reports: http://cygwin.com/pr
On 8/7/2014 5:42 PM, Eric Blake wrote:
On 08/07/2014 12:53 PM, Ken Brown wrote:
On 8/7/2014 11:30 AM, Eric Blake wrote:
On 08/07/2014 05:51 AM, Ken Brown wrote:
I think I found the problem with NORMAL mutexes. emacs calls
pthread_atfork after initializing the mutexes, and the resulting
'prep
On 08/07/2014 12:53 PM, Ken Brown wrote:
> On 8/7/2014 11:30 AM, Eric Blake wrote:
>> On 08/07/2014 05:51 AM, Ken Brown wrote:
>>>
>>> I think I found the problem with NORMAL mutexes. emacs calls
>>> pthread_atfork after initializing the mutexes, and the resulting
>>> 'prepare' handler locks the m
On 8/7/2014 11:30 AM, Eric Blake wrote:
On 08/07/2014 05:51 AM, Ken Brown wrote:
I think I found the problem with NORMAL mutexes. emacs calls
pthread_atfork after initializing the mutexes, and the resulting
'prepare' handler locks the mutexes. (The parent and child handlers
unlock them.) So
On 8/7/2014 8:51 AM, Corinna Vinschen wrote:
Hi Ken,
On Aug 7 07:51, Ken Brown wrote:
Hi Corinna,
On 8/5/2014 2:40 PM, Corinna Vinschen wrote:
I'm glad to read that, but I'm still a little bit concerned. If your
code works with ERRORCHECK mutexes but hangs with NORMAL mutexes, you
*might* m
On 08/07/2014 05:51 AM, Ken Brown wrote:
>
> I think I found the problem with NORMAL mutexes. emacs calls
> pthread_atfork after initializing the mutexes, and the resulting
> 'prepare' handler locks the mutexes. (The parent and child handlers
> unlock them.) So when emacs calls fork, the mutexe
Hi Ken,
On Aug 7 07:51, Ken Brown wrote:
> Hi Corinna,
>
> On 8/5/2014 2:40 PM, Corinna Vinschen wrote:
> >I'm glad to read that, but I'm still a little bit concerned. If your
> >code works with ERRORCHECK mutexes but hangs with NORMAL mutexes, you
> >*might* miss an error case.
> >
> >I'd sugg
Hi Corinna,
On 8/5/2014 2:40 PM, Corinna Vinschen wrote:
Hi Ken,
On Aug 5 13:55, Ken Brown wrote:
On 8/5/2014 9:58 AM, Corinna Vinschen wrote:
On Aug 5 08:21, Ken Brown wrote:
=== modified file 'src/gmalloc.c'
--- src/gmalloc.c 2014-03-04 19:02:49 +
+++ src/gmalloc.c 2014-0
Greetings, Katsumi Yamaoka!
>>> % ./autogen.sh
>>> [...]
>>> Running 'autoreconf -fi -I m4' ...
>>> 0 [main] perl 4508 child_info_fork::abort: address space needed by
>>> 'POSIX.dll' (0x2D) is already occupied
> [...]
>> You definitely have a DLL collision. What about perlrebase?
> Oh
On Wed, 06 Aug 2014 10:48:49 +0200, Corinna Vinschen wrote:
> On Aug 6 11:30, Katsumi Yamaoka wrote:
>> % ./autogen.sh
>> [...]
>> Running 'autoreconf -fi -I m4' ...
>> 0 [main] perl 4508 child_info_fork::abort: address space needed by
>> 'POSIX.dll' (0x2D) is already occupied
[...]
> Y
On Aug 6 11:30, Katsumi Yamaoka wrote:
> On Tue, 05 Aug 2014 13:55:31 -0400, Ken Brown wrote:
> > Angelo and Katsumi, could you test it and see if it solves the
> > problems you reported? If so, I'll issue new emacs releases.
>
> Thanks. But currently I cannot test it since the autogen.sh
> scr
On Tue, 05 Aug 2014 13:55:31 -0400, Ken Brown wrote:
> Angelo and Katsumi, could you test it and see if it solves the
> problems you reported? If so, I'll issue new emacs releases.
Thanks. But currently I cannot test it since the autogen.sh
script doesn't work as the following. I must make it w
Ciao, Ken
Ken Brown wrote:
Angelo and Katsumi, could you test it and see if it solves the problems you
reported?
for what I can see, with your patch (pthread_mutex.patch), the things
work better.. at least the build does not hang and with repeated 'make
-j3' it was also completed in Cygwin-
Hi Ken,
On Aug 5 13:55, Ken Brown wrote:
> On 8/5/2014 9:58 AM, Corinna Vinschen wrote:
> >On Aug 5 08:21, Ken Brown wrote:
> >>=== modified file 'src/gmalloc.c'
> >>--- src/gmalloc.c 2014-03-04 19:02:49 +
> >>+++ src/gmalloc.c 2014-08-05 01:35:38 +
> >>@@ -490,8 +490,8 @@
>
On 8/5/2014 9:58 AM, Corinna Vinschen wrote:
On Aug 5 08:21, Ken Brown wrote:
On 8/4/2014 9:45 AM, Corinna Vinschen wrote:
...this, and the fact that fork/exec (vfork == fork on Cygwin) still
works nicely in other scenarios points to some problem with the usage of
pthread_mutexes in the applic
In my experiments, not calling pthread_mutexattr_init caused errors
such that the final mutex was invalid and could not be locked.
The difference between the explicitly initialised mutex and the
statically initialised one is that the latter does get 'lazily'
initialised when the mutex is first loc
On Aug 5 08:21, Ken Brown wrote:
> On 8/4/2014 9:45 AM, Corinna Vinschen wrote:
> >...this, and the fact that fork/exec (vfork == fork on Cygwin) still
> >works nicely in other scenarios points to some problem with the usage of
> >pthread_mutexes in the application may be the culprit.
> >
> >For i
On Tue, Aug 5, 2014 at 1:21 PM, Ken Brown wrote:
> - pthread_mutex_init (&_malloc_mutex, NULL);
> - pthread_mutex_init (&_aligned_blocks_mutex, NULL);
> + pthread_mutexattr_t attr1, attr2;
> + pthread_mutexattr_settype (&attr1, PTHREAD_MUTEX_NORMAL);
> + pthread_mutexattr_settype (&attr2, PTH
On 8/4/2014 9:45 AM, Corinna Vinschen wrote:
On Aug 4 09:34, Ken Brown wrote:
On 8/4/2014 4:00 AM, Corinna Vinschen wrote:
On Aug 3 21:02, Ken Brown wrote:
On 8/1/2014 9:32 AM, Corinna Vinschen wrote:
It could be a problem with the new default pthread mutexes being
NORMAL, rather then ERROR
On Aug 4 09:34, Ken Brown wrote:
> On 8/4/2014 4:00 AM, Corinna Vinschen wrote:
> >On Aug 3 21:02, Ken Brown wrote:
> >>On 8/1/2014 9:32 AM, Corinna Vinschen wrote:
> >>>It could be a problem with the new default pthread mutexes being
> >>>NORMAL, rather then ERRORCHECK mutexes.
> >>
> >>That doe
On 8/4/2014 4:05 AM, Peter Hull wrote:
On Mon, Aug 4, 2014 at 2:02 AM, Ken Brown wrote:
That does seem to be the problem, since I can reproduce the bug starting
with the 2014-07-14 snapshot. More precisely, I can reproduce it using
emacs-nox (which is what the OP was using according to his cyg
On 8/4/2014 4:00 AM, Corinna Vinschen wrote:
On Aug 3 21:02, Ken Brown wrote:
On 8/1/2014 9:32 AM, Corinna Vinschen wrote:
On Aug 1 14:17, Peter Hull wrote:
On Fri, Aug 1, 2014 at 1:50 PM, Angelo Graziosi
wrote:
Since I upgraded to Cygwin-1.7.31*, I see similar issue in building Emacs
trun
On Mon, Aug 4, 2014 at 2:02 AM, Ken Brown wrote:
> That does seem to be the problem, since I can reproduce the bug starting
> with the 2014-07-14 snapshot. More precisely, I can reproduce it using
> emacs-nox (which is what the OP was using according to his cygcheck output)
> but not using emacs-
On Aug 3 21:02, Ken Brown wrote:
> On 8/1/2014 9:32 AM, Corinna Vinschen wrote:
> >On Aug 1 14:17, Peter Hull wrote:
> >>On Fri, Aug 1, 2014 at 1:50 PM, Angelo Graziosi
> >> wrote:
> >>>Since I upgraded to Cygwin-1.7.31*, I see similar issue in building Emacs
> >>>trunk (--with-w32 build)... The
On 8/1/2014 9:32 AM, Corinna Vinschen wrote:
On Aug 1 14:17, Peter Hull wrote:
On Fri, Aug 1, 2014 at 1:50 PM, Angelo Graziosi
wrote:
Since I upgraded to Cygwin-1.7.31*, I see similar issue in building Emacs
trunk (--with-w32 build)... The build always hangs in compiling some .el
file. CTRL-C
On Aug 1 14:17, Peter Hull wrote:
> On Fri, Aug 1, 2014 at 1:50 PM, Angelo Graziosi
> wrote:
> > Since I upgraded to Cygwin-1.7.31*, I see similar issue in building Emacs
> > trunk (--with-w32 build)... The build always hangs in compiling some .el
> > file. CTRL-C does not work and I have to sear
On Fri, Aug 1, 2014 at 1:50 PM, Angelo Graziosi
wrote:
> Since I upgraded to Cygwin-1.7.31*, I see similar issue in building Emacs
> trunk (--with-w32 build)... The build always hangs in compiling some .el
> file. CTRL-C does not work and I have to search the running processes with
> "ps" and kill
Katsumi Yamaoka wrote:
I'm troubled with a similar problem since Wednesday[1].
/usr/bin/emacs that Cygwin distributed (24.3) seems ok, but
/usr/local/bin/emacs that I built from the Emacs trunk Tuesday
(24.4.50) got not to work conditionally. With that version of
Emacs:
Evaluating the form `(c
On Fri, Aug 1, 2014 at 11:22 AM, Katsumi Yamaoka wrote:
> On Thu, 31 Jul 2014 15:51:49 +0100, Peter Hull wrote:
> I'm troubled with a similar problem since Wednesday[1].
I checked my /var/log/setup.log. The last time I installed anything
was 2014/07/30 (Wednesday). That update included the 'cygwi
On Thu, 31 Jul 2014 15:51:49 +0100, Peter Hull wrote:
> VC integration in emacs has stopped working for me in the past few
> days. Using emacs debugger I found the last function call was to
> call-process which never returns.
> I can reproduce this by evaluating in Lisp Interaction mode (using ^J)
>I can't reproduce this. I tested both emacs-X11 and emacs-w32, on both
>32-bit Cygwin and 64-bit Cygwin. Can you think of anything on your
>system that has changed in the last few days? And have you tried
>starting emacs with the '-Q' option to rule out a problem in your
>initialization files?
On 7/31/2014 10:51 AM, Peter Hull wrote:
VC integration in emacs has stopped working for me in the past few
days. Using emacs debugger I found the last function call was to
call-process which never returns.
I can reproduce this by evaluating in Lisp Interaction mode (using ^J)
(call-process "pwd
VC integration in emacs has stopped working for me in the past few
days. Using emacs debugger I found the last function call was to
call-process which never returns.
I can reproduce this by evaluating in Lisp Interaction mode (using ^J)
(call-process "pwd" nil t)
I would expect to see the PWD and
84 matches
Mail list logo
