[ITA] fish
I'd like to adopt the fish package. The package seems to be abandoned. A new release is out upstream with multiple security fixes, but the Cygwin package hasn't been updated. Emails to the maintainer have bounced, and he hasn't answered recent discussions on the cygwin list about the need to update the package and fix some problems in it. I took the existing cygport script, revised it a bit, added fixes for all of the known problems, and rolled a new release (below). If it seems okay, I'll upload it. Andrew x86: http://home.comcast.net/~andrex2/cygwin/x86/setup.hint http://home.comcast.net/~andrex2/cygwin/x86/fish-2.1.1-2.tar.xz http://home.comcast.net/~andrex2/cygwin/x86/fish-2.1.1-2-src.tar.xz x86_64: http://home.comcast.net/~andrex2/cygwin/x86_64/setup.hint http://home.comcast.net/~andrex2/cygwin/x86_64/fish-2.1.1-2.tar.xz http://home.comcast.net/~andrex2/cygwin/x86_64/fish-2.1.1-2-src.tar.xz
Re: [ITA] fish
Hi Andrew, On Oct 13 04:33, Andrew Schulman wrote: I'd like to adopt the fish package. The package seems to be abandoned. A new release is out upstream with multiple security fixes, but the Cygwin package hasn't been updated. Emails to the maintainer have bounced, and he hasn't answered recent discussions on the cygwin list about the need to update the package and fix some problems in it. thanks for your willingness to take over. I just wrote another mail to Konrad, and so far it didn't bounce. If I don't get a reply during this week, the package is all yours. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp5xnWzXaOXw.pgp Description: PGP signature
[BUG] libffi needs to be rebuilt for i386
Hello! I have found another problem, this time in libffi. Something appears to be wrong with the binary, and on my system it failed to execute its DllMain. As a result, it did not register its .eh_frame contents, and upon module unload i got abort() in __deregister_frame_info_bases() I started to research it, but cygffi-6.dll contains no symbols. So, in order to get a version with symbols, i rebuilt it from the source using up to date gcc. The problem magically went away with the rebuilt binary. Perhaps it was some obscure gcc/ld bug. Is it possible for the maintainer to update the binary ? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
Re: [BUG] libffi needs to be rebuilt for i386
On 10/13/2014 11:39 AM, Pavel Fedin wrote: Hello! I have found another problem, this time in libffi. Something appears to be wrong with the binary, and on my system it failed to execute its DllMain. As a result, it did not register its .eh_frame contents, and upon module unload i got abort() in __deregister_frame_info_bases() I started to research it, but cygffi-6.dll contains no symbols. So, in FYI debug symbols are in libffi-debuginfo package order to get a version with symbols, i rebuilt it from the source using up to date gcc. The problem magically went away with the rebuilt binary. Perhaps it was some obscure gcc/ld bug. Is it possible for the maintainer to update the binary ? Kind regards, Pavel Fedin Regards Marco
Re: patch: typo fix in setup.exe
On 10/10/2014 11:28 AM, Corinna Vinschen wrote: On Oct 10 10:40, Eric Blake wrote: ping On 09/27/2014 10:27 AM, Eric Blake wrote: Assuming this is the right place for this patch - something I noticed today, when I got an error message including the word thelist. 2014-09-27 Eric Blake ebl...@redhat.com * res.rc: Fix missing space. Sure, please apply. Looks like I can't; although I'm a member of the cygwin group, I'm not a member of the cygwin-apps group. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: patch: typo fix in setup.exe
On Oct 13 06:51, Eric Blake wrote: On 10/10/2014 11:28 AM, Corinna Vinschen wrote: On Oct 10 10:40, Eric Blake wrote: ping On 09/27/2014 10:27 AM, Eric Blake wrote: Assuming this is the right place for this patch - something I noticed today, when I got an error message including the word thelist. 2014-09-27 Eric Blake ebl...@redhat.com * res.rc: Fix missing space. Sure, please apply. Looks like I can't; although I'm a member of the cygwin group, I'm not a member of the cygwin-apps group. I asked overseers to add you to the cygwin-apps group. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpNho03zTZi_.pgp Description: PGP signature
Re: [BUG] libffi needs to be rebuilt for i386
Hello, Marco. Monday, October 13, 2014, 13:56:57 you wrote: FYI debug symbols are in libffi-debuginfo package Thank you, i know this. Actually, when i started my research, i noticed that DllMain() and corresponding init code is not called for libffi. I started to examine that. I don't know the exact mechanism of how DllMain() becomes so special, but i suggested that it might be up to symbol name. I used objdump -t on libffi, and it displayed nothing. I became curious and checked some other libraries, including cygwin1.dll. All these libraries had populated symbol tables. I suggested that this may be the thing that goes wrong, rebuilt the libffi, and installed instripped version (just by copying the file). It perfectly worked, the problem is gone. Just for curiosity i tried 'make install' which strips the symbols. This variant also worked fine. So, apparently, the root cause was likely some bug in the linker which was used to build the original package. -- Kind regards, Pavel
Re: [ITA] fish
On 13/10/2014 09:33, Andrew Schulman wrote: I'd like to adopt the fish package. The package seems to be abandoned. A new release is out upstream with multiple security fixes, but the Cygwin package hasn't been updated. Emails to the maintainer have bounced, and he hasn't answered recent discussions on the cygwin list about the need to update the package and fix some problems in it. I took the existing cygport script, revised it a bit, added fixes for all of the known problems, and rolled a new release (below). If it seems okay, I'll upload it. Andrew x86: http://home.comcast.net/~andrex2/cygwin/x86/setup.hint http://home.comcast.net/~andrex2/cygwin/x86/fish-2.1.1-2.tar.xz http://home.comcast.net/~andrex2/cygwin/x86/fish-2.1.1-2-src.tar.xz x86_64: http://home.comcast.net/~andrex2/cygwin/x86_64/setup.hint http://home.comcast.net/~andrex2/cygwin/x86_64/fish-2.1.1-2.tar.xz http://home.comcast.net/~andrex2/cygwin/x86_64/fish-2.1.1-2-src.tar.xz I verified that the problem identified on the list is addressed. One comment regarding the new config.fish file - can you make the cd $HOME dependent upon the CHERE_INVOKING variable being unset? That way chere will work for those who set it up for fish. See /etc/profile for the bash equivalent. Thanks, Dave.
Re: [ITA] fish
One comment regarding the new config.fish file - can you make the cd $HOME dependent upon the CHERE_INVOKING variable being unset? That way chere will work for those who set it up for fish. See /etc/profile for the bash equivalent. Sure, that will go in revision -3.
Re: cygport upload command?
On 2014-07-07 20:14, Andrew Schulman wrote: Yaakov, would you consider adding an 'upload' command to cygport, that would handle the uploading details? That would take away the last bit of manual work in a routine package update. I'm a bit busy at the moment, but it sounds like a good idea to me. I have an implementation of this ready at https://github.com/andrex-e-schulman/cygport. What's new compared to upstream git: * New upload command (cygport up). * Documented upload command in manuals and README. * Currently only one upload client, lftp, is supported. I've tested the implementation a good bit, and it works well as long as there's no trouble, i.e. lftp can connect to sftp://cygwin.com. If it can't connect, then you get told max-retries exceeded and Upload failed, which doesn't help at all to figure out why the upload failed (can't connect, can't authenticate, ...). Unfortunately, it's hard to make lftp give much better information. * Simple API for adding support for other upload clients. The API is described in pkg_upload.cygpart. I'm planning to add support for sftp and rsync soon, and I hope it will be easier to get useful failure information from them if the upload fails. Please let me know if you have any comments or would like to see any changes. Andrew
cygwin macs failing siltently
With recent upgrade of cygwin, emacs is always crashing. Windows XP VirtualBox virtual machines (don't ask) setup.exe version 2.8.50 (32 bit) tried both emacs 24.3.93-1 and 24.3-2 X-server is cygin 64 bit on windows 7. It was working last week. Now silent crash, no log entries. Occassionally a core dump? More information - I had an older computer with an older version of cygwin 32 bit running an x-server and an older version of cygwin emacs 32 bit installed on a virtual machine. a) setting the DISPLAY to the new computer with the latest version doesn't help - the older emacs crashes with an illegal system call. However, there are no problems running xterm. b) after setting the DISPLAY to the old computer's cygwin x server, emacs runs fine on the old vm. Does anyone have suggestions? Thanks Gulliver -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: cygwin emacs failing siletnly
Follow up: It is only emacs for X-windows that fails silently. emacs-nox works perfectly. As I said, the silent failure has no core dump and no log messages anywhere. Nothing is displayed in the shell window. Thanks Gulliver -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: cygwin emacs failing siletnly
Try re-setting your fonts. See this post: https://cygwin.com/ml/cygwin/2013-12/msg00248.html -- Jim Reisert AD1C, jjreis...@alum.mit.edu, http://www.ad1c.us -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: cygwin emacs failing siletnly
Thanks for the pointer to fc-cache. On which machine should this be run? a) the machine hosting the X-Server b) the machine on which emacs is running fc-cache ran successfully on a - the machine hosting the x-server but fails silently on the virtual machine hosting emacs and xterm. Thanks Gulliver -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog net.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-10-13 08:18:19 Modified files: winsup/cygwin : ChangeLog net.cc Log message: * net.cc (cygwin_setsockopt): Drop redundant test for AF_LOCAL and SOCK_STREAM in SO_PEERCRED case, as in the original patch. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6535r2=1.6536 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/net.cc.diff?cvsroot=srcr1=1.319r2=1.320
Re: [PATCH] Disable AF_UNIX handshake with setsockopt(..., SO_PEERCRED, ...)
On Oct 13 10:20, Corinna Vinschen wrote: On Oct 13 07:37, Christian Franke wrote: Corinna Vinschen wrote: On Oct 10 20:04, Corinna Vinschen wrote: In short, the whole code is written under the assumption that any sane application calling nonblocking connect would always call select/poll to check if connect succeeded in the first place. Obviously, as postfix shows, this is a wrong assumption. I'm not yet sure how to fix this, but I'll look into this next week. I applied a fix which, I think, is much more elegant than the former solution. The af_local_connect call is now called as soon as an FD_CONNECT event is generated and read by a call to wait_event. It worked for me, so I have tender hopes that I didn't miss something. I also applied your patch on top of this new stuff and I'm just building a new developer snapshot for testing. A quick test of current postfix draft with the snapshot works as expected. Thanks. Did you run other network-related tools, too, in the meantime? Any fallout which could be a result my change? In setsockopt I added a check for socket family and type so setsockopt(SO_PEERCRED) only works for AF_LOCAL/SOCK_STREAM sockets, just as the entire handshake stuff. Probably not needed because this check was already in af_local_set_no_getpeereid() itself. Doh! I reverted this part of my change. I completely missed the redundancy here, sorry. I also added a comment to explain why we do this and a FIXME comment so we don't forget we're still looking for a more generic solution for the SO_PEERCRED exchange. Definitely, at least because the current AF_LOCAL emulation has some security issues. -v? Btw., I'd be grateful if we could discuss this on cygwin-developers, if you don't mind. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpQNuD7aE3st.pgp Description: PGP signature
Re: Necessary To Query SACL Information?
On Oct 12 20:37, Bryan Berns wrote: I noticed when I launch an executable, Cygwin queries SACL information on the executable (which I can see in Process Monitor as a 'QuerySecurityFile' operation). On some of my protected file servers, this generates a failure audit. Looking at the source code, I'm going to guess this might be from the NtQuerySecurityObject call in security.cc which requests SACL information by asking for for ALL_SECURITY_INFORMATION. Does Cygwin really need to query this information? Aside from keeping my audit logs clean, it seems like it might be an opportunity for optimizing the executable launch process if Cygwin doesn't really need this (or some of the other information that ALL_SECURITY_INFORMATION provides). As you found out yourself, Cygwin only reads and writes the owner/group information and the DACL. Accessing this information is required for POSIX permission handling, e.g. stat(2), chmod(2), chown(2), acl(2). Also, creating a file with open(2) requires to write the DACL to create valid POSIX permissions for a file. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpV3L2KUNcIP.pgp Description: PGP signature
Re: HEADSUP to Emacs users
On 10/11/14 19:36, Ken Brown wrote: In a continuing effort to track down the cause of the mysterious crashes that some Emacs users have reported, I'm now wondering if these are caused by the stack being too small. If you have been experiencing crashes, please issue the following command (as administrator, while emacs is not running): peflags -x0x8 /usr/bin/emacs-*.exe This increases the stack size to 8MB. And please let me know if you see any improvement as a result. Hello. I've seen emacs x86 crashing on Vista when X was used (while working fine in text mode); I cannot tell if the above helps in that case, since I don't have that computer anymore. Now, on Windows 7 with 64b Cygwin, emacs works fine in text mode and X, but will crash when I connect to this box via ssh and try to run it on a remote X terminal (while still working fine in text mode). The above command did not help. bye Thanks av. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: HEADSUP to Emacs users
On 10/13/2014 5:11 AM, Andrea Venturoli wrote: Now, on Windows 7 with 64b Cygwin, emacs works fine in text mode and X, but will crash when I connect to this box via ssh and try to run it on a remote X terminal (while still working fine in text mode). It works fine for me in that scenario. Do you get an error message when it crashes? Does it leave a stackdump file? Have you enabled X11 forwarding in /etc/sshd_config? Please provide as many details as possible, and please attach cygcheck output as requested here: http://cygwin.com/problems.html Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated (experimental): coreutils-8.23-3
On 10/12/2014 02:56 AM, Corinna Vinschen wrote: With coreutils 8.23-2 this suceeds, with the -3 release you'll get the error cp: cannot create directory ‘ACLtest/profile.d’: File exists It's even simpler than that: $ cd /tmp $ mkdir -p a/1/2 b/1/2 $ touch a/1/2/x b/1/2/y $ cp -rp a/1/2 b/1 cp: cannot create directory ‘b/1/2’: File exists D'oh - now I see it. In my .exe code additions, I had added a '!= 0' test that should have really been a ' 0' test; because directories cause an expected -1 return that should not have triggered an attempt at .exe magic. -4 coming soon. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
RE: HEADSUP to Emacs users
-Original Message- From: ... On Behalf Of Ken Brown Sent: Saturday, 2014 October 11 13:37 To: cygwin Subject: HEADSUP to Emacs users In a continuing effort to track down the cause of the mysterious crashes that some Emacs users have reported, I'm now wondering if these are caused by the stack being too small. If you have been experiencing crashes, please issue the following command (as administrator, while emacs is not running): peflags -x0x8 /usr/bin/emacs-*.exe This increases the stack size to 8MB. And please let me know if you see any improvement as a result. Thanks. Ken Can that command be run harmlessly while emacs happens to be running? (.bash_profile seems like a natural place to put it, but that could be run a second time.) peflags --help looks great but doesn't clearly answer that question. Thank you, and please forgive my ignorance. -- ,Doug Douglas Lewan Shubert Ticketing (201) 489-8600 ext 224 or ext 4335 This is a slow pup, he said continuing his ascent.
Re: what path to use that is not DOS??
On 10/11/2014 03:37 PM, Linda Walsh wrote: Eric Blake wrote: On 10/08/2014 01:55 PM, Linda Walsh wrote: I get this message the 1st time logging in via 'rlogin': MS-DOS style path detected: /Windows/System32/cygwin/usr/spool/mail/Bliss/law Preferred POSIX equivalent is: /Windows/System32/cygwin/usr/spool/mail/Bliss/law Could any prefix of that path be a symlink with questionable contents? Cygwin can't use any of the normal methods to find my home and because USERNAME isn't set it tries 'USER'. So for a mail-spool dir it looks for /usr/spool/mail/USER=Bliss\law Is it cygwin1.dll or rlogin that is trying to convert $USER into a determination of a mail spool directory? If it is cygwin, we should probably patch cygwin to ignore or modify any $USER containing backslash, rather than trying to treat it as a subdirectory. That is, tilde expansion will treat '~Bliss/law' as the username 'Bliss' with a subdirectory 'law', rather than as the single username 'Bliss\law'. I suspect the bug is in rlogin rather than cygwin, though, if you are only getting the message when trying to log in with rlogin, and since the message is about a mail spool and not about a $HOME. Meanwhile, I still wonder why the error message is printing 'Bliss/law' as the problematic string, when it appears that the reason the warning appeared is because rlogin was using $USER literally as 'Bliss\law'. We may still need to find and squash a cygwin bug that displays the message incorrectly. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: HEADSUP to Emacs users
On 10/13/14 13:37, Ken Brown wrote: It works fine for me in that scenario. I didn't report it earlier, since it's not that important to me; howerver if I could solve... Do you get an error message when it crashes? Yes: ** (emacs:3752): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-idEV6pXtAp: No such file or directory (... some seconds wait ...) Fatal error 12: Bad system call Bad system call (core dumped) emacs The second message is sometimes omitted, however. Does it leave a stackdump file? Yes: Stack trace: FrameFunctionArgs 00A85C0 0018006FA23 (00A8740, 000DF0DF046, 000, 000) 00C 00180070F9A (FFF0BDC0, 000, 5DC, 000) 00A87A0 0018011A2E7 (010, 001004E9820, 001009CF392, 00100992832) 0C1 0018011754E (00A8C50, 000, 000, 001004E9820) 00C 00180117A1B (000, 000, 000, 00C) 00C 00180117BEC (65007000690070, 6700790063005C, 2D006E00690077, 33006500350063) 00C 001801135DB (6700790063005C, 2D006E00690077, 33006500350063, 800) 00C 5C002E005C005C (2D006E00690077, 33006500350063, 800, 32003200640039) 00C 65007000690070 (33006500350063, 800, 32003200640039, 00C) 00C 6700790063005C (800, 32003200640039, 00C, 00600016000) 00C 2D006E00690077 (32003200640039, 00C, 00600016000, 001004E973E) 00C 33006500350063 (00C, 00600016000, 001004E973E, 02B04A8) 00C 800 (00600016000, 001004E973E, 02B04A8, 000) 00C 32003200640039 (001004E973E, 02B04A8, 000, 000) 00C 00C (02B04A8, 000, 000, 000) 00C 00600016000 (000, 000, 000, 0018013BE50) End of stack trace (more stack frames may be present) Have you enabled X11 forwarding in /etc/sshd_config? Xterm works, so I guess I did. Also emacs -nw works. Please provide as many details as possible The box from which I ssh into this runs FreeBSD... I'm using a domain user... X runs fine locally... Sorry, I really don't know what else to add. I'm willing to play any test you need, but I don't always have this box avaliable, so it might take time. and please attach cygcheck output as requested here: Please, find it attached. bye Thanks av. Cygwin Configuration Diagnostics Current System Time: Mon Oct 13 17:53:01 2014 Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Prog\Dev\VC\Common\MSDev98\Bin C:\Prog\Dev\VC\9\Common7\IDE C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE C:\ProgCache\Dev\ACIS\R25_VC11_32\InterOp\NT_VC11_DLL\code\bin C:\ProgCache\Dev\ACIS\R25_VC11_32\VizExchange\NT_VC11_DLL\code\bin \\SOTH\ANDREA\Prog\Dev\OpenCascade\654_vc9_32\ros\win32\vc9\bin \\SOTH\ANDREA\Prog\Dev\OpenCascade\654_vc9_32\3rdparty\freeimage-vc9-32\bin \\SOTH\ANDREA\Prog\Dev\OpenCascade\654_vc9_32\3rdparty\tbb30_018oss\bin\ia32\vc9 \\SOTH\ANDREA\Prog\Dev\OpenCascade\654_vc9_32\3rdparty\tbb30_018oss\bin\ia32\vc9\irml \\SOTH\ANDREA\Prog\Dev\QT\VC10_64_4.8.4\bin Output from C:\cygwin\bin\id.exe UID: 13000(andrea) GID: 10513(VENTU_Domain Users) 10513(VENTU_Domain Users) 545(Users) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'andrea' PWD = '/home/andrea' HOME = '/home/andrea' HOMEPATH = '\cygwin\home\andrea' HOSTNAME = 'GALDOV' TERM = 'xterm' SHELL = '/bin/bash' PROFILEREAD = 'true' WINDIR = 'C:\Windows' SSH_CLIENT = '10.1.2.18 20585 22' OLDPWD = '/home/andrea' ORIGINAL_PATH = '/bin:/cygdrive/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Prog/Dev/VC/Common/MSDev98/Bin:/cygdrive/c/Prog/Dev/VC/9/Common7/IDE:/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/Common7/IDE:/cygdrive/c/Program Files (x86)/Microsoft Visual Studio
[ANNOUNCEMENT] Updated: coreutils-8.23-4
A new release of coreutils, 8.23-4, has been uploaded, and will be available soon from your favorite mirror. This replaces the experimental 8.23-3 and stable 8.23-2, and leaves 8.15-1 (32-bit) or 8.15-3 (64-bit) as previous. NEWS: = This is a minor update that fixes a regression in the -3 build, where a rewrite of the cygwin-only .exe magic caused directories to fail during recursive copies. For upstream details, see /usr/share/doc/coreutils/NEWS. If you missed the note in 8.23-2, there is no longer an 'su' program in coreutils; this is an upstream decision (many Linux distros are getting su from other packages, and even though cygwin's su had come from coreutils, it was heavily patched and doesn't work as smoothly as on Linux). I'm still debating whether it is worth trying to capture the last release of coreutils' su, as patched to work on cygwin, for distribution as an independent package; help would be appreciated from anyone else interested in this task. If you encounter a regression, please report it here rather than upstream. See also the upstream documentation in /usr/share/doc/coreutils/. Help in porting the stdbuf utility to cygwin would be appreciated. DESCRIPTION: GNU coreutils provides a collection of commonly used utilities essential to a standard POSIX environment. It comprises the former textutils, sh-utils, and fileutils packages. The following executables are included: [ arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold gkill groups head hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep sort split stat stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes UPDATE: === To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'coreutils' from the 'Base' category. DOWNLOAD: = Note that downloads from cygwin.com aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Eric Blake volunteer cygwin coreutils package maintainer For more details on this list (including unsubscription), see: http://sourceware.org/lists.html signature.asc Description: OpenPGP digital signature
emacs auto-indentation bug
I haven't changed my ~/.emacs file since 2012, but sometime in the last several weeks I've noticed changes in emacs behavior. 1. I've never turned on automatic indentation--don't actually know how--yet if I indent a new line by pressing the tab key, when I hit the enter key, the next line has been automatically indented to align with the previous one. This happens even if I start emacs with the -q option. 2. What makes this worse is the fact that it inserts tab characters rather than spaces for this automatic indentation. I specifically have (setq-default tab-width 4) in .emacs, and my manual indentation is indeed created with space characters, but subsequent auto-indented lines are indented with tab characters. I perused the ChangeLog, but didn't see anything relevant since 2012. Curious about this change. Googling, I found this reference (http://www.emacswiki.org/emacs/AutoIndentation): NOTE: Recent changes, I think during Emacs 24.3, have swapped effects of RET and C-j, so RET typically does newline-and-indent. So, that pretty much explains it. Sounds like an upstream bug, but affecting this community as well. I was wondering if anyone can offer a workaround to restore the previous behavior. Also wondering if anyone has insight into this bug being possibly fixed upstream. FWIW: $ uname uname -srvmo CYGWIN_NT-6.1 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin $ type emacs emacs is hashed (/usr/bin/emacs) $ emacs --version GNU Emacs 24.3.93.1 Copyright (C) 2014 Free Software Foundation, Inc. GNU Emacs comes with ABSOLUTELY NO WARRANTY. You may redistribute copies of Emacs under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. $ ls -ld ~/.emacs -rwxr-xr-x 1 Administrators Domain Users 14090 Aug 1 2012 /home/knellis/.emacs $ cygcheck -c cygwin emacs Cygwin Package Information Package VersionStatus cygwin 1.7.32-1 OK emacs24.3.93-1 OK $ --Ken Nellis -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: HEADSUP to Emacs users
On 10/13/2014 12:21 PM, Doug Lewan wrote: -Original Message- From: ... On Behalf Of Ken Brown Sent: Saturday, 2014 October 11 13:37 To: cygwin Subject: HEADSUP to Emacs users In a continuing effort to track down the cause of the mysterious crashes that some Emacs users have reported, I'm now wondering if these are caused by the stack being too small. If you have been experiencing crashes, please issue the following command (as administrator, while emacs is not running): peflags -x0x8 /usr/bin/emacs-*.exe This increases the stack size to 8MB. And please let me know if you see any improvement as a result. Thanks. Ken Can that command be run harmlessly while emacs happens to be running? No. It actually changes the executable. (.bash_profile seems like a natural place to put it, There's no need. You just have to run it once, and then emacs will always use an 8MB stack after that. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: HEADSUP to Emacs users
On 10/13/2014 12:56 PM, Andrea Venturoli wrote: On 10/13/14 13:37, Ken Brown wrote: It works fine for me in that scenario. I didn't report it earlier, since it's not that important to me; howerver if I could solve... Do you get an error message when it crashes? Yes: ** (emacs:3752): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-idEV6pXtAp: No such file or directory This warning is normal (and harmless) when you login remotely. (... some seconds wait ...) Fatal error 12: Bad system call Bad system call (core dumped) emacs The second message is sometimes omitted, however. Does it leave a stackdump file? Yes: Stack trace: FrameFunctionArgs 00A85C0 0018006FA23 (00A8740, 000DF0DF046, 000, 000) 00C 00180070F9A (FFF0BDC0, 000, 5DC, 000) 00A87A0 0018011A2E7 (010, 001004E9820, 001009CF392, 00100992832) 0C1 0018011754E (00A8C50, 000, 000, 001004E9820) 00C 00180117A1B (000, 000, 000, 00C) 00C 00180117BEC (65007000690070, 6700790063005C, 2D006E00690077, 33006500350063) 00C 001801135DB (6700790063005C, 2D006E00690077, 33006500350063, 800) 00C 5C002E005C005C (2D006E00690077, 33006500350063, 800, 32003200640039) 00C 65007000690070 (33006500350063, 800, 32003200640039, 00C) 00C 6700790063005C (800, 32003200640039, 00C, 00600016000) 00C 2D006E00690077 (32003200640039, 00C, 00600016000, 001004E973E) 00C 33006500350063 (00C, 00600016000, 001004E973E, 02B04A8) 00C 800 (00600016000, 001004E973E, 02B04A8, 000) 00C 32003200640039 (001004E973E, 02B04A8, 000, 000) 00C 00C (02B04A8, 000, 000, 000) 00C 00600016000 (000, 000, 000, 0018013BE50) End of stack trace (more stack frames may be present) Have you enabled X11 forwarding in /etc/sshd_config? Xterm works, so I guess I did. It wouldn't hurt to double check; you should have a line that says X11Forwarding yes in /etc/sshd_config in the Cygwin installation. Also emacs -nw works. This doesn't use X. Please provide as many details as possible The box from which I ssh into this runs FreeBSD... I'm using a domain user... X runs fine locally... Sorry, I really don't know what else to add. I'm willing to play any test you need, but I don't always have this box avaliable, so it might take time. and please attach cygcheck output as requested here: Please, find it attached. It looks like you don't have the cygserver service running. My recollection is that you might need this for X11 forwarding of emacs to work. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: emacs auto-indentation bug
On 10/13/2014 2:26 PM, Nellis, Kenneth wrote:
I haven't changed my ~/.emacs file since 2012, but sometime in the last several
weeks I've noticed changes in emacs behavior.
1. I've never turned on automatic indentation--don't actually know how--yet if
I indent a new line by pressing the tab key, when I hit the enter key, the next
line has been automatically indented to align with the previous one. This
happens even if I start emacs with the -q option.
2. What makes this worse is the fact that it inserts tab characters rather than spaces
for this automatic indentation. I specifically have (setq-default tab-width
4) in .emacs, and my manual indentation is indeed created with space characters,
but subsequent auto-indented lines are indented with tab characters.
I perused the ChangeLog, but didn't see anything relevant since 2012. Curious
about this change.
Googling, I found this reference
(http://www.emacswiki.org/emacs/AutoIndentation):
NOTE: Recent changes, I think during Emacs 24.3, have swapped effects of RET and
C-j, so RET typically does newline-and-indent.
So, that pretty much explains it. Sounds like an upstream bug, but affecting this
community as well. I was wondering if anyone can offer a workaround to restore the
previous behavior. Also wondering if anyone has insight into this bug being
possibly fixed upstream.
This is not a bug. It's a deliberate upstream change. Browse the NEWS
file ('C-h n' from within emacs), and read the section entitled **
Indentation.
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: emacs auto-indentation bug
Nellis, Kenneth writes: I haven't changed my ~/.emacs file since 2012, but sometime in the last several weeks I've noticed changes in emacs behavior. 1. I've never turned on automatic indentation--don't actually know how--yet if I indent a new line by pressing the tab key, when I hit the enter key, the next line has been automatically indented to align with the previous one. This happens even if I start emacs with the -q option. Yes electric-indent-mode is now being on by default. You can switch it off globally or just for some modes. 2. What makes this worse is the fact that it inserts tab characters rather than spaces for this automatic indentation. I specifically have (setq-default tab-width 4) in .emacs, and my manual indentation is indeed created with space characters, but subsequent auto-indented lines are indented with tab characters. Make sure indent-tabs-mode is nil (it has been non-nil by default for quite some time). I perused the ChangeLog, but didn't see anything relevant since 2012. Curious about this change. You'd be better off looking in NEWS (type C-h C-n). So, that pretty much explains it. Sounds like an upstream bug, but affecting this community as well. I was wondering if anyone can offer a workaround to restore the previous behavior. Also wondering if anyone has insight into this bug being possibly fixed upstream. You can fix this bug by customizing the two variables I mentioned. And since these were both deliberate -- if somewhat contentious -- changes, reporting it as a bug upstream isn't going to help, but you can try. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: fish PATH problem
On 10/10/2014 14:46, Andrew Schulman wrote: OK, I rolled a new release of fish 2.1.1: x86: http://home.comcast.net/~andrex2/cygwin/x86/fish-2.1.1-1.tar.xz http://home.comcast.net/~andrex2/cygwin/x86/fish-2.1.1-1-src.tar.xz x86_64: http://home.comcast.net/~andrex2/cygwin/x86_64/fish-2.1.1-1.tar.xz http://home.comcast.net/~andrex2/cygwin/x86_64/fish-2.1.1-1-src.tar.xz Please try it out, and let me know how it works for you. If it's okay and if Konrad doesn't answer, then I'll adopt the package and put out the new release. I've switched to using fish as my default shell now, so I want to see it maintained. I downloaded both versions and verified that `fish -l` didn't show the path issue. Success. Thanks, Dave. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: emacs auto-indentation bug
Thanx to Achim and Ken for their responses, but especially to an off-list responder (who may prefer to remain anonymous), who told me specifically how to disable these (unwanted) features. In case this is useful to anyone: To cause auto-indenting to use spaces instead of tabs: (setq-default indent-tabs-mode nil) To disable automatic indentation: (electric-indent-mode 0) opineI would think one would have to opt-in for these features--not opt-out--but that's just me./opine --Ken Nellis -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: sharutils-4.14-2
A new release of sharutils, 4.14-2, has been uploaded and will soon be available at your favorite mirror. This leaves 4.14-1 as the previous build. NEWS: = This is a minor rebuild that removes the 'compress' dummy executable now that the 'ncompress' package is available without patent restrictions. If you have already installed 'ncompress', you will need to reinstall it after upgrading 'sharutils' in order to avoid a missing file. This build also adds a debuginfo package. Using shar on text mounts continues to have the possibility that line endings on text files might not be handled the way you want, but if it was truly a text file, that should not matter to you; the heuristic that shar uses to decide between text and binary files is whether it contains non-printing characters. It is safer to use shar/unshar on binary mounts (remembering that unshar is inherently unsafe). uuencode and uudecode, on the other hand, work reliably regardless of the underlying mount point. See also the package documentation found in /usr/share/doc/sharutils/. DESCRIPTION: The sharutils package contains the GNU shar utilities, a set of tools for encoding and decoding packages of files (in binary or text format) in a special plain text format called shell archives (shar). This format can be sent through e-mail (which can be problematic for regular binary files). The shar utility supports a wide range of capabilities (compressing, uuencoding, splitting long files for multi-part mailings, providing checksums), which make it very flexible at creating shar files. After the files have been sent, the unshar tool scans mail messages looking for shar files. Unshar automatically strips off mail headers and introductory text and then unpacks the shar files. Note that unshar is inherently unsafe by design, because it executes arbitrary shell scripts; therefore the creation of shar archives should be limited to situations where the receiver trusts the sender. However, uuencode and uudecode are useful in their own right, and are safe to use. UPDATE: === To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'sharutils' from the 'Archive' category. DOWNLOAD: = Note that downloads from cygwin.com aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Eric Blake volunteer cygwin sharutils package maintainer For more details on this list (including unsubscription), see: http://sourceware.org/lists.html signature.asc Description: OpenPGP digital signature
Updated: sharutils-4.14-2
A new release of sharutils, 4.14-2, has been uploaded and will soon be available at your favorite mirror. This leaves 4.14-1 as the previous build. NEWS: = This is a minor rebuild that removes the 'compress' dummy executable now that the 'ncompress' package is available without patent restrictions. If you have already installed 'ncompress', you will need to reinstall it after upgrading 'sharutils' in order to avoid a missing file. This build also adds a debuginfo package. Using shar on text mounts continues to have the possibility that line endings on text files might not be handled the way you want, but if it was truly a text file, that should not matter to you; the heuristic that shar uses to decide between text and binary files is whether it contains non-printing characters. It is safer to use shar/unshar on binary mounts (remembering that unshar is inherently unsafe). uuencode and uudecode, on the other hand, work reliably regardless of the underlying mount point. See also the package documentation found in /usr/share/doc/sharutils/. DESCRIPTION: The sharutils package contains the GNU shar utilities, a set of tools for encoding and decoding packages of files (in binary or text format) in a special plain text format called shell archives (shar). This format can be sent through e-mail (which can be problematic for regular binary files). The shar utility supports a wide range of capabilities (compressing, uuencoding, splitting long files for multi-part mailings, providing checksums), which make it very flexible at creating shar files. After the files have been sent, the unshar tool scans mail messages looking for shar files. Unshar automatically strips off mail headers and introductory text and then unpacks the shar files. Note that unshar is inherently unsafe by design, because it executes arbitrary shell scripts; therefore the creation of shar archives should be limited to situations where the receiver trusts the sender. However, uuencode and uudecode are useful in their own right, and are safe to use. UPDATE: === To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'sharutils' from the 'Archive' category. DOWNLOAD: = Note that downloads from cygwin.com aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Eric Blake volunteer cygwin sharutils package maintainer For more details on this list (including unsubscription), see: http://sourceware.org/lists.html signature.asc Description: OpenPGP digital signature
