public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Ken Brown <kbrown@cornell.edu>
To: cygwin@cygwin.com
Subject: Re: Emacs-w32 28.1-2 (marked as test) fails with: "Doing vfork: Resource temporarily unavailable"
Date: Sun, 17 Jul 2022 17:20:15 -0400	[thread overview]
Message-ID: <2d3de62a-1b6c-b842-3f8a-830ca69ca2ff@cornell.edu> (raw)
In-Reply-To: <8bbc40d4-a355-33c9-0065-5d8cfa5b7267@SystematicSw.ab.ca>

On 7/17/2022 12:35 PM, Brian Inglis wrote:
> On 2022-07-17 08:15, Ken Brown wrote:
>> On 7/17/2022 7:08 AM, Oleksandr Gavenko wrote:
>>> I saw a new version of emacs-w32 28.1-2 (has 28.1-1) and gave it a try.
>>> If has a problem with forking processes:
>>> Doing vfork: Resource temporarily unavailable
> 
>> Please see the release announcement:
>>    https://cygwin.com/pipermail/cygwin-announce/2022-April/010529.html
> 
> Could you not perhaps at emacs (initial) startup add the rebase userpath 
> eln-cache entry,

This is not practical currently because on most Cygwin installations, 
administrator privileges are required to write to /var/lib/rebase/userpath.d, 
but the user(s) running emacs might not have those privileges.  (That's true of 
my own installations, for example.)  But maybe there's a way around that.  Achim?

> and create a shell script to rebase the eln-cache entries which 
> could be e.g. ~/.emacs.d/cygwin-rebase-eln-cache or elsewhere, and perhaps that 
> script could also initially add the rebase userpath eln-cache entry, to make 
> life easier for users.

A script is a good idea.

> You could document the manual instructions and any commands or scripts provided 
> in /usr/share/doc/cygwin/emacs.README for reference in every release notice, as 
> well as in issues here, rather than documenting it in and referring to release 
> notices.

I had actually intended to document it in /usr/share/doc/emacs/README.Cygwin, 
but I apparently forgot to do that.  In the meantime, I've documented it 
upstream, and future emacs releases will contain that documentation in 
/usr/share/emacs/<version>/etc/PROBLEMS.  So I can put a pointer to that 
documentation in release announcements and in /usr/share/doc/emacs/README.Cygwin.

BTW, this may all turn out to be moot, since I don't actually know at the moment 
whether any Cygwin users care about native compilation.  The last paragraph of 
my release announcement asked for feedback from people who try the test release, 
and so far the only feedback has come from someone who didn't read the 
announcement and so didn't know how to use the test release.

Thanks for your suggestions.

Ken

      reply	other threads:[~2022-07-17 21:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-17 11:08 Oleksandr Gavenko
2022-07-17 14:15 ` Ken Brown
2022-07-17 16:35   ` Brian Inglis
2022-07-17 21:20     ` Ken Brown [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2d3de62a-1b6c-b842-3f8a-830ca69ca2ff@cornell.edu \
    --to=kbrown@cornell.edu \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).