Re: Perl 5.22.0
On 7/14/2015 10:40 PM, Marco Atzeri wrote: On 7/14/2015 9:51 PM, Achim Gratz wrote: Achim Gratz writes: There are a few Perl distribution packages that are captive in another source package. The hopefully complete list of such packages: perl-Graphics-Magick perl-gv perl-Image-Magick perl-ming perl-Net-Libproxy perl-Xfce4-Xfconf perl-zinnia This means that again Yaakov as well as Marco and Volker need to re-release those. Yaakov has volunteered to update Volker's packages while he's away, I hope the offer still stands. perl-Graphics-Magick perl-Image-Magick are already available as test These packages place module files into vendor_perl while the package name has nothing to do with Perl (not all of them are available for both architectures): amanda biber git-svn git irssi net-snmp-perl po4a pristine-tar sendxmpp subversion-perl irssi postgresql-plperl are also available as test And lastly, two packages put files in site_perl which should not happen for official packages, so that should be corrected anyway: grepmail stow Regards MArco
Re: ACL Hell
I'm using cygwin for years already. I didn't use to have this problem in the past. It's something relatively new, that became way more intense in the past few months where I both re-installed windows at home, and got a fresh PC at work. I had similar problems - and to fix them I did this: Edit the file: /etc/fstab Add “noacl” as an option for mount points - I just let all mount points be “windows default” and leave it. It is in my opinion, the ACL stuff was well intended but ended up causing big problems for me. Windows is just a very different beast, and does not implement POSIX very well, and no attempt at putting a square peg in a round hole ends well. . I think what Cygnus, then Redhat - etc has done is a marvelous and great good - but this ACL stuff - yuck. I firmly believe “ACL = ON” by default is wrong headed. -Duane. -- 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
Serial Port communication issues in Cygwin
Hello, I am trying to use Cygwin to automate some testing of an external device. The external device communicates to the PC running Cygwin over a serial cable at 115200 baud. I have been able to manually send and receive data from the external device using PuTTY, Teraterm, and Powershell, but I am having troubles doing the same with Cygwin. These are the commands I am using in Cygwin to initialize the serial port, open it for read and write, and capture the output: stty -F /dev/ttyS2 speed 115200 exec 4 /dev/ttyS2 cat 4 /cygdrive/c/path/to/file When I execute those commands, and power on the device, I receive nothing. The file remains empty. If I then close Cygwin and immediately open PuTTY or Teraterm or Powershell to the correct serial port, I start receiving correct/valid data. I attempted opening the serial port only for read, but that did not work. If I open a PuTTY session first (to use PuTTY to set the correct parameters for the serial port), and then open the serial port with Cygwin and cat the output, I again receive nothing. The one way that I have been able to correctly read data in from the serial port with Cygwin is if I replace file descriptor 4 in my above exec command with file descriptor 0. If I run that command (exec 0 /dev/ttyS2), I am no longer able to manually type anything into the terminal window, but if I power on my external device, each line of text from the device is read in correctly, but, obviously, that is not very useful to me for my testing... If it helps, the serial port configuration in cygwin after opening/closing the serial port with PuTTY: $ stty -F /dev/ttyS2 speed 115200 baud; line = 0; intr = undef; quit = undef; erase = undef; kill = undef; eof = undef; swtch = undef; susp = undef; rprnt = undef; werase = undef; lnext = undef; flush = undef; min = 0; time = 0; -cread -brkint -icrnl ixoff -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke I have tried this with the latest download of cygwin, and I've tried it with older versions. I have tried using the 32bit and 64bit versions. My device is doing a BIOS boot to an EFI shell, where I'd like to enter in some test commands, and then I would be doing a pxe boot of a custom linux. The BIOS boot, test commands, and pxe boot are all dumping data over the serial port. I'd like to be able to capture and monitor that output with cygwin in an automated fashion, but I am having issues with reading that data in with Cygwin. Can someone help me figure out or understand why I am unable to read data in from the serial port with cygwin except with file descriptor 0, but I am able to read/write the serial port with PuTTY, Teraterm, and Powershell? Thanks! --Jesse -- 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: ACL Hell
Greetings, Sky Diver! Hi, in the past several months or so, cygwin started giving me ACL pain in small surges which are gradually growing.. Here's a basic scenario that is slowly, but surely, driving me NUTZ: $ ln -s /cygdrive/c/tmp /tmp ln: failed to create symbolic link ‘/tmp’: Operation not permitted Are you running with superadmin credentials? Unlike Linux, Windows doesn't let regular users make symlinks. -- With best regards, Andrey Repin Wednesday, July 15, 2015 11:30:47 Sorry for my terrible english...
Re: SIGINT generated by Control-C, is not delivered in mintty
On 7/14/2015 9:44 AM, Ronald Fischer wrote: Using Cygwin 64 on Windows 7: In a bash or zsh running inside mintty, pressing Control-C has no effect. In a bash or zsh running in a Windows Console, it works fine. This can be verified in two ways: (1) Using 'trap': In the shell, we do a trap 'echo trapped' INT as Achim mentioned, it works also for me on both 32bit and 64bit $ trap 'echo trapped' INT $ ^Ctrapped $ ^Ctrapped Regards Marco -- 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: SIGINT generated by Control-C, is not delivered in mintty
On Tue, Jul 14, 2015, at 11:27, Achim Gratz wrote: Ronald Fischer ynnor at mm.st writes: Using Cygwin 64 on Windows 7: In a bash or zsh running inside mintty, pressing Control-C has no effect. In a bash or zsh running in a Windows Console, it works fine. This can be verified in two ways: (1) Using 'trap': In the shell, we do a trap 'echo trapped' INT Now whenever we hit Control-C, we expect trapped to be printed on stdout. This is not the case when the shell runs inside mintty. (2) Using 'cat': In the shell, we do a cat which has the effect that cat reads from stdin. A control-C should abort it. Again, this doesn't work when we run inside mintty. WJFFM. Make sure that the stuff in GW (GNUwin?) and Linux64 does not interfer. Also, you have multiple cygwin1.dll on your path (p/nano), fix that and see if it makes any difference. Good point, but did not help: I have removed the GNUwin Utilities and the path to my second cygwin1.dll from my PATH (which is a good idea anyway), verified it, and repeated the test - same result. Next - to be really sure that we don't have any interference - I did a PATH=/usr/bin mintty and inside mintty did a echo $PATH to verify, that I really have only /usr/bin in my PATH, and here too, the same effect - Control-C not delivered. BTW, the last time I worked with mintty (on a different project) - it was about 3 years ago - it worked fine, so I guess the bug sneaked in recently. Ronald -- 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: TEST RELEASE: Cygwin 2.1.0-0.4
Hi guys, On Jul 14 22:07, Ken Brown wrote: On 7/14/2015 6:03 PM, Eric Blake wrote: On 07/08/2015 01:39 PM, Warren Young wrote: A search for sigaltstack” on code.openhub.net found only 95 projects with this string in their source code, almost entirely consisting of *receivers* of that call, such as NetBSD, glibc, and a bunch of Linux forks. libsigsegv is a cygwin package (currently 32-bit only) that has configure checks to use sigaltstack if present; I have not yet tested if it can be configured to work with the new API, but hope to do so in the near future. In fact, if sigaltstack works, it may finally be possible to port libsigsegv to 64-bit cygwin (the reason the current package is not ported to 64-bit is that libsigsegv is relying on raw assembly and Windows native calls to emulate the lack of sigaltstack; but if sigaltstack works, then we don't need to port the 64-bit counterpart for the 32-bit specific hacks). I just did a quick test, and it looks promising. I removed all Cygwin-specific code from configure.ac and Makefile.am (see attached patch), and it then built on 64-bit Cygwin. Here's the result of 'make check': Entering directory '/home/kbrown/src/cyglibsigsegv/libsigsegv-2.10-1.x86_64/build/tests' Test passed. PASS: sigsegv1.exe Test passed. PASS: sigsegv2.exe Doing SIGSEGV pass 1. Stack overflow 1 caught. Doing SIGSEGV pass 2. Stack overflow 2 caught. Test passed. PASS: sigsegv3.exe SKIP: stackoverflow1.exe SKIP: stackoverflow2.exe Any idea why these two tests have been skipped? That means the HAVE_STACK_OVERFLOW_RECOVERY autoconf test failed. You removed cygwin from the explicit mingw* | cygwin*) sv_cv_have_stack_overflow_recovery=yes ;; which is the right thing to do, but that means CFG_LEAVE has been set to leave-none.c, apparently. I haven't much time to look into that right now, but will later today if you don't beat me to it. == All 3 tests passed (2 tests were not run) == [...] Please send the following summary line via email to the main author Bruno Haible br...@clisp.org for inclusion into the list of successfully tested platforms (see PORTING file). libsigsegv: x86_64-unknown-cygwin | yes | no | 2.10 I'm not the cygwin packager for libsigsegv, No one is; it's orphaned. but am one of the upstream contributors, and so this thread has piqued my interest. So it seems that you would be the obvious person to maintain it, if you have the time. If you don't have the time, I'd be willing to ITA it just to get it into the 64-bit distro. But in that case I'd appreciate it if you would review my build after I send the ITA, since you actually know something about libsigsegv, and I don't. Thanks a lot, this is most helpful. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqCvWAkl6n0.pgp Description: PGP signature
Mintty 32bit: False Positive
All, for your info Regards Marco Forwarded Message Subject: [No Reply] False Positive Submission [3822135] Date: Wed, 15 Jul 2015 06:49:33 +0100 From: Symantec FP Incident Response falsepositi...@symantec.com To: marco.atz...@gmail.com In relation to submission [3822135]. Upon further analysis and investigation we have verified your submission and as such this detection will be removed from our products. The updated detection will be distributed in the next set of virus definitions, available via LiveUpdate or from our website at http://securityresponse.symantec.com/avcenter/defs.download.html Please note that whitelisting can take up to 24 hours to take effect. Decisions made by Symantec are subject to change if alterations to the Software are made over time or as classification criteria and/or the policy employed by Symantec changes over time to address the evolving landscape. If you are a software vendor, why not take part in our whitelisting program? To participate in this program, please complete the following form: https://submit.symantec.com/whitelist Sincerely, Symantec Security Response http://securityresponse.symantec.com -- 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: missing 64bit ports
On Jul 15, 2015, at 8:24 AM, Marco Atzeri marco.atz...@gmail.com wrote: I spent a bit of time checking the real situation of the packages still missing as 64 bit port. Thank you for doing this research. ...we are down to ~44. ...half of them are dead upstream so we can directly obsolete and don't worry anynore. Wow. I’ve updated my related answer on Stack Overflow (http://goo.gl/yOAqAn) to reflect this drastic shrinkage of this list’s size.
Re: missing 64bit ports
On Jul 15, 2015, at 11:39 AM, Marcos Vives Del Sol socram8...@gmail.com wrote: Reason I didn't port libnfc was because I lost my SSH key due to a hard drive crash. Any procedure on how to get a new one so I can compile and upload it? $ ssh-keygen I assume those in charge of maintaining the list of allowed keys will be willing to accept a different key from you, so just resubmit it as if you were doing it for the first time.
Re: missing 64bit ports
Reason I didn't port libnfc was because I lost my SSH key due to a hard drive crash. Any procedure on how to get a new one so I can compile and upload it? 2015-07-15 16:24 GMT+02:00 Marco Atzeri marco.atz...@gmail.com: Dear All, I spent a bit of time checking the real situation of the packages still missing as 64 bit port. After xdelta, bsdiff and iperf porting, without counting the few mingw ones, the duplicates we are down to ~44. Please see here the analysis : https://docs.google.com/spreadsheets/d/1Hn7Eaq6djEN9X0jS_AM8-DH_LvP43G9_DXnpTt09Asc/edit#gid=0 Feel free to insert comments on the cells. For what I found : - half of them are dead upstream so we can directly obsolete and don't worry anynore. - Few are Jary's scripts, so the only porting issue is Jary's time. - Very few have real porting issue The only one really interesting for me is Mathomatic and eventually catdoc if works with latest word documents. (of course I will port pure-ftpd) Regards Marco -- Marcos Vives Del Sol https://github.com/socram miniLock: NscWdW8fh2E5SBoRtrnXWrDwmQmwaR5awMKE78tQW1Ffx
Re: [ADOPT] iperf 2.0.8
You are the new maintainer Congratulation. Gold star awarded! https://cygwin.com/goldstars/#JJ
Re: TEST RELEASE: Cygwin 2.1.0-0.4
On Jul 15 09:51, Corinna Vinschen wrote:
Hi guys,
On Jul 14 22:07, Ken Brown wrote:
Entering directory
'/home/kbrown/src/cyglibsigsegv/libsigsegv-2.10-1.x86_64/build/tests'
Test passed.
PASS: sigsegv1.exe
Test passed.
PASS: sigsegv2.exe
Doing SIGSEGV pass 1.
Stack overflow 1 caught.
Doing SIGSEGV pass 2.
Stack overflow 2 caught.
Test passed.
PASS: sigsegv3.exe
SKIP: stackoverflow1.exe
SKIP: stackoverflow2.exe
Any idea why these two tests have been skipped? That means the
HAVE_STACK_OVERFLOW_RECOVERY autoconf test failed. You removed cygwin
from the explicit
mingw* | cygwin*) sv_cv_have_stack_overflow_recovery=yes ;;
which is the right thing to do, but that means CFG_LEAVE has been
set to leave-none.c, apparently.
I haven't much time to look into that right now, but will later today if
you don't beat me to it.
Got it. What's needed is a Cygwin-specific fault-*.h file which exposes
how to fetch the stack pointer register from mcontext_t. As you can see
from the plethora of fault-*.h files in the src subdir, this is highly
system-specific anyway.
Here's the set of files you need to rebuild libsigsegv for Cygwin 2.1.0,
with all tests running and passing on i686 and x86_64. No other patch
is requied.
So, who of you is going to maintain it?
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
NAME=libsigsegv
VERSION=2.10
RELEASE=2
CATEGORY=Libs
SUMMARY=Handling page faults in user mode
DESCRIPTION=Library for handling page faults in user mode. A page fault occurs
when a program tries to access to a region of memory that is currently not
available. Mainly required to build clisp from source.
HOMEPAGE=http://libsigsegv.sourceforge.net/;
# SRC_URI=ftp://www.gnu.ftp.uni-erlangen.de/pub/gnu/${PN}/${PN}-${PV}.tar.gz;
#
SRC_URI=http://puzzle.dl.sourceforge.net/sourceforge/${PN}/${PN}-${PV}.tar.bz2;
# SRC_URI=ftp://ftp.gnu.org/pub/gnu/${PN}/${PN}-${PV}.tar.gz;
SRC_URI=http://ftpmirror.gnu.org/${PN}/${PN}-${PV}.tar.gz;
DLLREV=2
MAKEOPTS=-j1
CYGCONF_ARGS=--enable-shared
PKG_NAMES=${PN} ${PN}${DLLREV}
PKG_CONTENTS[0]=--exclude=usr/bin/cygsigsegv-${DLLREV}.dll usr
PKG_CONTENTS[1]=usr/bin/cygsigsegv-${DLLREV}.dll
--- origsrc/libsigsegv-2.10/configure.ac2011-04-03 17:30:16.0
+0200
+++ src/libsigsegv-2.10/configure.ac2015-07-15 14:30:22.264452393 +0200
@@ -419,6 +419,9 @@ if test -z $CFG_FAULT test $sv_cv_
;;
esac
;;
+ cygwin*)
+ CFG_FAULT=fault-cygwin-i386.h
+ ;;
*)
CFG_FAULT=fault-posix-ucontext.h
;;
@@ -522,16 +525,6 @@ case $host_os in
FAULT_CONTEXT_INCLUDE='#include windows.h'
CFG_FAULT=fault-win32.h # nonexistent, just a dummy
;;
- cygwin*)
-FAULT_CONTEXT='CONTEXT'
-FAULT_CONTEXT_INCLUDE='#include windows.h'
-# Cygwin 1.7 uses fault-posix.h. Cygwin 1.5.x needs a hacky workaround.
-if test -z $CFG_FAULT; then
- CFG_FAULT=fault-cygwin-old.h
- AC_DEFINE([OLD_CYGWIN_WORKAROUND], [1],
-[Define to 1 on Cygwin versions older than 1.7.])
-fi
-;;
esac
if test -n $CFG_FAULT; then
sv_cv_have_sigsegv_recovery=yes
@@ -858,7 +851,7 @@ AC_CACHE_CHECK([if the system supports c
sv_cv_have_stack_overflow_recovery=yes
else
case $host_os in
- mingw* | cygwin*) sv_cv_have_stack_overflow_recovery=yes ;;
+ mingw*) sv_cv_have_stack_overflow_recovery=yes ;;
*)
if test $CFG_LEAVE != 'leave-none.c'; then
if test $sv_cv_sigaltstack != no; then
@@ -927,7 +920,7 @@ dnl Requires AC_CANONICAL_HOST, CFG_HAND
dnl HAVE_SIGSEGV_RECOVERY, HAVE_STACK_OVERFLOW_RECOVERY.
case $host_os in
- mingw* | cygwin*) CFG_HANDLER=handler-win32.c ;;
+ mingw*) CFG_HANDLER=handler-win32.c ;;
*)
if test -z $CFG_HANDLER; then
if test $sv_cv_have_sigsegv_recovery = no \
--- origsrc/libsigsegv-2.10/src/fault-cygwin-i386.h 1970-01-01
01:00:00.0 +0100
+++ src/libsigsegv-2.10/src/fault-cygwin-i386.h 2015-07-15 14:30:47.562341412
+0200
@@ -0,0 +1,33 @@
+/* Fault handler information. Cygwin/i386 and Cygwin/x86_64 version.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software Foundation,
+ Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */
+
+#include
Re: ACL Hell
Hey Andrey, Are you running with superadmin credentials? Unlike Linux, Windows doesn't let regular users make symlinks. I'm using cygwin for years already. I didn't use to have this problem in the past. It's something relatively new, that became way more intense in the past few months where I both re-installed windows at home, and got a fresh PC at work. On both machines I'm referring to the main user, which is part of the Administrators group. I believe that answers your question. Both machine are Windows 8.1 64-bit, standalone station at home and part of a domain at work. One more thing, here's my CYGWIN env. varv: $ echo $CYGWIN winsymlinks:nativestrict This is the only way to produce windows compliant links (at least in my case). Thanks. -- 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: TEST RELEASE: Cygwin 2.1.0-0.4
On Jul 15 09:08, Eric Blake wrote: On 07/15/2015 08:24 AM, Ken Brown wrote: Got it. What's needed is a Cygwin-specific fault-*.h file which exposes how to fetch the stack pointer register from mcontext_t. As you can see from the plethora of fault-*.h files in the src subdir, this is highly system-specific anyway. Here's the set of files you need to rebuild libsigsegv for Cygwin 2.1.0, with all tests running and passing on i686 and x86_64. No other patch is requied. Awesome! Makes my work easier. Great! Thanks. So, who of you is going to maintain it? I'll defer to Eric, but if he doesn't want it then I'll take it. I'll take it. Expect a package up later this week, as well as a rebuilt 64-bit m4 that uses it. Sounds good, thanks! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp7v1Sq3IZRd.pgp Description: PGP signature
Re: missing 64bit ports
On 7/15/2015 2:28 PM, Corinna Vinschen wrote: On Jul 15 16:24, Marco Atzeri wrote: Dear All, I spent a bit of time checking the real situation of the packages still missing as 64 bit port. After xdelta, bsdiff and iperf porting, without counting the few mingw ones, the duplicates we are down to ~44. Please see here the analysis : https://docs.google.com/spreadsheets/d/1Hn7Eaq6djEN9X0jS_AM8-DH_LvP43G9_DXnpTt09Asc/edit#gid=0 Feel free to insert comments on the cells. For what I found : - half of them are dead upstream so we can directly obsolete and don't worry anynore. - Few are Jary's scripts, so the only porting issue is Jary's time. - Very few have real porting issue The only one really interesting for me is Mathomatic and eventually catdoc if works with latest word documents. (of course I will port pure-ftpd) Thanks for looking into this. Two points: - Shall we remove all 32b-bit only orphaned packages for which we don't get a maintainer until, say, end of August? That seems reasonable, as long as there are exceptions for packages where the lack of a 64-bit package is due to genuine porting difficulties. libsigsegv was in that category until yesterday. Another one I'm aware of is ffcall. - We should probably consider to remove the mingw.org packages. All of them. They are hopelessly outdated and mingw-w64 does the same job better hands down. +1 Ken
Re: missing 64bit ports
On Jul 15, 2015, at 12:28 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: - Shall we remove all 32b-bit only orphaned packages for which we don't get a maintainer until, say, end of August? If a package is available only for 32-bit, there should be a place to learn that prior to running setup.exe. The fact that some items are on that list because they’re orphaned and thus have no immediate prospect of getting off the list is inconsequential to the end users who consult it. If your goal is to evaporate this list, I’d prefer that you just removed orphaned packages from both the 32- and 64-bit repositories on the justification that Cygwin should only offer packages available for both architectures. And going forward, refuse new uploads if packages for both architectures aren’t provided promptly. There can be exceptions, as with the recent libsigsegv thing. I also thought I saw some talk about Perl currently being somewhat desynchronized at the moment. I’m not talking about such cases. The existing packages are maintained, and ownership of the solution for the missing packages is known. I think this is going to far, but it would be well within your prerogative. - We should probably consider to remove the mingw.org packages. All of them. They are hopelessly outdated and mingw-w64 does the same job better hands down. I can’t see why anyone would adopt those old abandoned packages. Not only do I have no objection to you nuking them, I think it would be an actual improvement, since it removes a point of confusion in the setup.exe package selection screen.
startx-xwin seg fault, signal 11
I've been running cygwin/x (x86) under xp pro for YEARS, with it working perfectly. The last update to 1.17 has been a disaster. I've read about using -listen tcp, and DISPLAY=:0.0 ; however, nothing I've tried resolves the seg fault error i'm getting. using 1.17.1-5; have also tried 1.17.2-0 to no avail; back on 1-5. any help or direction would be appreciated! TIA - Bob here's a copy of my xwin.log: Could not load crashreporter dll Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.17.1.0 OS: CYGWIN_NT-5.1 myxppropc 2.0.4(0.287/5/3) 2015-06-09 12:20 i686 OS: Windows XP Service Pack 3 [Windows NT 5.1 build 2600] (Win32) Package: version 1.17.1-5 built 2015-06-02 XWin was started with the following command line: /usr/bin/X :3 -auth /home/bob/.serverauth.4656 ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1440 h 900 winInitializeScreenDefaults - native DPI x 96 y 96 [104131.312] Could not load crashreporter dll [104131.343] Fatal signal received in thread 0x2038 [0x1164] [104131.343] (EE) Segmentation fault at address 0x1 [104131.484] (EE) /usr/bin/xorg-backtrace failed with returncode 0 [104131.484] (EE) Fatal server error: [104131.484] (EE) Caught signal 11 (Segmentation fault). Server aborting [104131.484] (EE) Server terminated with error (1). Closing log file. -- 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: missing 64bit ports
On Jul 15 16:24, Marco Atzeri wrote: Dear All, I spent a bit of time checking the real situation of the packages still missing as 64 bit port. After xdelta, bsdiff and iperf porting, without counting the few mingw ones, the duplicates we are down to ~44. Please see here the analysis : https://docs.google.com/spreadsheets/d/1Hn7Eaq6djEN9X0jS_AM8-DH_LvP43G9_DXnpTt09Asc/edit#gid=0 Feel free to insert comments on the cells. For what I found : - half of them are dead upstream so we can directly obsolete and don't worry anynore. - Few are Jary's scripts, so the only porting issue is Jary's time. - Very few have real porting issue The only one really interesting for me is Mathomatic and eventually catdoc if works with latest word documents. (of course I will port pure-ftpd) Thanks for looking into this. Two points: - Shall we remove all 32b-bit only orphaned packages for which we don't get a maintainer until, say, end of August? - We should probably consider to remove the mingw.org packages. All of them. They are hopelessly outdated and mingw-w64 does the same job better hands down. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpTFG2_nwsGB.pgp Description: PGP signature
Re: ACL Hell
To Larry Hall: 1. I'd love to reply to your post, but I'm new to this mailing-list concept so I neglected to subscribe to the mailing list (yeah, I'm an old fashioned kinda guy, work only with thread-level google-groups / StackOverflow forum types ;) TBH: If Andrey wouldn't have CC'ed me on his reply, I wouldn't even know that someone addressed my case... 2. I admit I didn't read the whole Reporting Problems page. As soon as I found the 'appropriate mailing list' link, I was off to another page. 2.1. Having read the page in full, I apologize for violating 3+ rules. 3. To the matter at hand: first of all, I attached cygcheck.out to this mail. Second, indeed I am using a non-default symlink mode: winsymlinks:nativestrict. This is the only mode that work for my needs (I can elaborate upon request). Have to say that even after re-reading the documentation now, I don't see it mentioning anything about elevated privileges. I AM aware of the fact that with an elevated session, the problem doesn't exist. However, I avoided using this mode because every new file/directory were created as Administrators:None instead of sky:None. For some weird reason, I just tried creating both a file and a directory with an elevated session and they were created with sky:None... I can't tell what's what anymore (sorry, I just got totally baffled). Still, how can I get a normal behavior (i.e. normal Windows symlinks as produces in winsymlinks:nativestrict mode) in a regular session w/o elevation? Thanks! On Wed, Jul 15, 2015 at 10:17 PM, Sky Diver skydive...@gmail.com wrote: Hey Andrey, Are you running with superadmin credentials? Unlike Linux, Windows doesn't let regular users make symlinks. I'm using cygwin for years already. I didn't use to have this problem in the past. It's something relatively new, that became way more intense in the past few months where I both re-installed windows at home, and got a fresh PC at work. On both machines I'm referring to the main user, which is part of the Administrators group. I believe that answers your question. Both machine are Windows 8.1 64-bit, standalone station at home and part of a domain at work. One more thing, here's my CYGWIN env. varv: $ echo $CYGWIN winsymlinks:nativestrict This is the only way to produce windows compliant links (at least in my case). Thanks. cygcheck.out Description: Binary data -- 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
SSH key for upload access
Name: Joel Johnson Package: iperf BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAABAQDKriVs95VDFMOF8u2QeRNWKF/MamVoL9CTP20SUs IScF6up0c1U6TiNCgcPHXPw6QCPafaE73AoMIojKly5lr2N6LbspfcSiu4/USau/gAGLsS xyG7Zq/P8S3GmOVP5i/INjWJwB3AjIfIJx5JAUS49QC6iI+3BXxNczihIXUQmJoQDlKQnf 21epPiMXbscS7mEvYtV7IBOcS9M4eonlcDhGeVOJDOCIl0D8qkDLZdoEK90QA7VgHNQCKZ ZR2YNBycwPGucK90xJH5mHk1nlOInVWHe4OdVrKrXmBczU1kXsy74sOGm24r6uL4d8i3vV 2YQYl6WJU8byhEz6hf5srl END SSH2 PUBLIC KEY
Re: Perl 5.22.0
On 7/15/2015 1:34 AM, Achim Gratz wrote: Ken Brown writes: On 7/14/2015 3:51 PM, Achim Gratz wrote: biber This all set and uploaded to my release area. Thanks. Just to be sure, this build uses the system supplied Unicode modules or did you fatpack them? I've downgraded Unicode-Normalize to 1.17 just for Biber, so I'd be a bit bummed if the latter… :-) I used Unicode-Normalize-1.17 that I had built myself, using the cygport file attached here: https://cygwin.com/ml/cygwin-apps/2015-07/msg00036.html Ken
Re: SIGINT generated by Control-C, is not delivered in mintty
On 15.07.2015 10:46, Marco Atzeri wrote: On 7/14/2015 9:44 AM, Ronald Fischer wrote: Using Cygwin 64 on Windows 7: In a bash or zsh running inside mintty, pressing Control-C has no effect. In a bash or zsh running in a Windows Console, it works fine. This can be verified in two ways: (1) Using 'trap': In the shell, we do a trap 'echo trapped' INT Ronald, does it happen that you start mintty from a Cygwin console window? In that case, it might be the same problem I had reported myself a few months ago: https://sourceware.org/ml/cygwin/2015-02/msg00122.html I have analysed this a little bit further; the problem as I see it happens in cygwin 1.7.32 but does not happen in cygwin 1.7.10 (I could try to narrow that down with the cygwin time machine...). In addition, if I compile the current version of mintty in cygwin 1.7.10, the problem does not occur which makes me quite sure it's not a mintty problem although (as I had written) it does not seem to happen with xterm. Thomas -- 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
missing 64bit ports
Dear All, I spent a bit of time checking the real situation of the packages still missing as 64 bit port. After xdelta, bsdiff and iperf porting, without counting the few mingw ones, the duplicates we are down to ~44. Please see here the analysis : https://docs.google.com/spreadsheets/d/1Hn7Eaq6djEN9X0jS_AM8-DH_LvP43G9_DXnpTt09Asc/edit#gid=0 Feel free to insert comments on the cells. For what I found : - half of them are dead upstream so we can directly obsolete and don't worry anynore. - Few are Jary's scripts, so the only porting issue is Jary's time. - Very few have real porting issue The only one really interesting for me is Mathomatic and eventually catdoc if works with latest word documents. (of course I will port pure-ftpd) Regards Marco
Re: TEST RELEASE: Cygwin 2.1.0-0.4
On 7/15/2015 8:44 AM, Corinna Vinschen wrote: On Jul 15 09:51, Corinna Vinschen wrote: Hi guys, On Jul 14 22:07, Ken Brown wrote: Entering directory '/home/kbrown/src/cyglibsigsegv/libsigsegv-2.10-1.x86_64/build/tests' Test passed. PASS: sigsegv1.exe Test passed. PASS: sigsegv2.exe Doing SIGSEGV pass 1. Stack overflow 1 caught. Doing SIGSEGV pass 2. Stack overflow 2 caught. Test passed. PASS: sigsegv3.exe SKIP: stackoverflow1.exe SKIP: stackoverflow2.exe Any idea why these two tests have been skipped? That means the HAVE_STACK_OVERFLOW_RECOVERY autoconf test failed. You removed cygwin from the explicit mingw* | cygwin*) sv_cv_have_stack_overflow_recovery=yes ;; which is the right thing to do, but that means CFG_LEAVE has been set to leave-none.c, apparently. I haven't much time to look into that right now, but will later today if you don't beat me to it. Got it. What's needed is a Cygwin-specific fault-*.h file which exposes how to fetch the stack pointer register from mcontext_t. As you can see from the plethora of fault-*.h files in the src subdir, this is highly system-specific anyway. Here's the set of files you need to rebuild libsigsegv for Cygwin 2.1.0, with all tests running and passing on i686 and x86_64. No other patch is requied. Great! Thanks. So, who of you is going to maintain it? I'll defer to Eric, but if he doesn't want it then I'll take it. 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: SIGSEGV before main ? and gcc-debuginfo
On 7/15/2015 3:11 PM, Corinna Vinschen wrote: Hi Marco, I seem to have missed this... On Jul 11 09:22, Marco Atzeri wrote: trying to debug latest release candidate of netcdf I hit this SIGSEGV before reaching main $ gdb .libs/ctest.exe GNU gdb (GDB) Cygwin 7.9.1-1 . Reading symbols from .libs/ctest.exe...done. (gdb) break main Breakpoint 1 at 0x100401171: file /pub/devel/netcdf/prova/netcdf-c-4.4.0-rc2/ncdump/ctest.c, line 32. (gdb) run Starting program: /cygdrive/e/cyg_pub/devel/netcdf/prova/netcdf-c-4.4.0-rc2_build64/ncdump/.libs/ctest.exe [New Thread 9476.0x2a88] [New Thread 9476.0x1fa0] [New Thread 9476.0x9a8] Program received signal SIGSEGV, Segmentation fault. ___chkstk_ms () at /usr/src/debug/gcc-4.9.3-1/libgcc/config/i386/cygwin.S:146 146 orq $0x0, (%rcx)/* probe there */ I thought it was a stack issue and I raised from 2M to 8M It *is* a stack issue of some sort, otherwise it wouldn't have called ___chkstk_ms, which is the guard page handler. Did you find out in the meantime? No. I put at side the issue and reported as upstream regression http://www.unidata.ucar.edu/mailing_lists/archives/netcdfgroup/2015/msg00192.html As the crash is on initialization of a test program is not too high on my TODO. SizeOfStackReserve 0020 SizeOfStackReserve 007a1200 with no success. May be it is not a netcdf bug ? Ideas what to look for ? If it's prior to main, it must be some constructor. Other than that, no idea. Hmm, the relative path might break finding the debuginfo. You should be able to help gdb by calling (gdb) dir /usr/src/debug/gcc-4.9.3-1/libgcc/config/i386 thanks. I will try Corinna -- 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: SIGSEGV before main ? and gcc-debuginfo
Hi Marco, I seem to have missed this... On Jul 11 09:22, Marco Atzeri wrote: trying to debug latest release candidate of netcdf I hit this SIGSEGV before reaching main $ gdb .libs/ctest.exe GNU gdb (GDB) Cygwin 7.9.1-1 . Reading symbols from .libs/ctest.exe...done. (gdb) break main Breakpoint 1 at 0x100401171: file /pub/devel/netcdf/prova/netcdf-c-4.4.0-rc2/ncdump/ctest.c, line 32. (gdb) run Starting program: /cygdrive/e/cyg_pub/devel/netcdf/prova/netcdf-c-4.4.0-rc2_build64/ncdump/.libs/ctest.exe [New Thread 9476.0x2a88] [New Thread 9476.0x1fa0] [New Thread 9476.0x9a8] Program received signal SIGSEGV, Segmentation fault. ___chkstk_ms () at /usr/src/debug/gcc-4.9.3-1/libgcc/config/i386/cygwin.S:146 146 orq $0x0, (%rcx)/* probe there */ I thought it was a stack issue and I raised from 2M to 8M It *is* a stack issue of some sort, otherwise it wouldn't have called ___chkstk_ms, which is the guard page handler. Did you find out in the meantime? SizeOfStackReserve 0020 SizeOfStackReserve 007a1200 with no success. May be it is not a netcdf bug ? Ideas what to look for ? If it's prior to main, it must be some constructor. Other than that, no idea. $ uname -svr CYGWIN_NT-6.1 2.0.4(0.287/5/3) 2015-06-09 12:22 In addition there is a problem with gcc-debuginfo $ cygcheck -l gcc-debuginfo |grep cygwin.S /usr/src/debug/gcc-4.9.3-1/libgcc/config/i386/cygwin.S (gdb) break ___chkstk_ms Breakpoint 2 at 0x100407a60: ___chkstk_ms. (5 locations) (gdb) run Starting program: /cygdrive/e/cyg_pub/devel/netcdf/prova/netcdf-c-4.4.0-rc2_build64/ncdump/.libs/ctest.exe [New Thread 6656.0x2980] Breakpoint 2, ___chkstk_ms () at ../../../libgcc/config/i386/cygwin.S:137 137 ../../../libgcc/config/i386/cygwin.S: No such file or directory. Hmm, the relative path might break finding the debuginfo. You should be able to help gdb by calling (gdb) dir /usr/src/debug/gcc-4.9.3-1/libgcc/config/i386 Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpVkrVjY1Y6L.pgp Description: PGP signature
Updated: Cygwin 2.1.0-1
Hi Cygwin friends and users, I released another version of Cygwin. The version number is 2.1.0-1. What's new: --- - Handle pthread stacksizes as in GLibc: Default to RLIMIT_STACK resource. Allow to set RLIMIT_STACK via setrlimit. Default RLIMIT_STACK to value from executable header as described on https://msdn.microsoft.com/en-us/library/windows/desktop/ms686774.aspx Default stacksize to 2 Megs in case RLIMIT_STACK is set to RLIM_INFINITY. - First cut of an implementation to allow signal handlers running on an alternate signal stack. - New API sigaltstack, plus definitions for SA_ONSTACK, SS_ONSTACK, SS_DISABLE, MINSIGSTKSZ, SIGSTKSZ. - New API: sethostname. Bug Fixes - - Enable non-SA_RESTART behaviour on threads other than main thread. Addresses: https://cygwin.com/ml/cygwin/2015-06/msg00260.html - Try to handle concurrent close on socket more gracefully Addresses: https://cygwin.com/ml/cygwin/2015-06/msg00235.html - Fix fork failing after the parent recovered from a stack overflow. Addresses: https://cygwin.com/ml/cygwin/2015-06/msg00384.html - Fix a crash on 64 bit XP/2003 when opening /proc/$PID/maps. - Apparently on some Windows systems timezones differ in case from the standard. Fix the tzset tool to check case-insensitive. Addresses: https://cygwin.com/ml/cygwin/2015-07/msg00113.html Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
[ANNOUNCEMENT] Updated: Cygwin 2.1.0-1
Hi Cygwin friends and users, I released another version of Cygwin. The version number is 2.1.0-1. What's new: --- - Handle pthread stacksizes as in GLibc: Default to RLIMIT_STACK resource. Allow to set RLIMIT_STACK via setrlimit. Default RLIMIT_STACK to value from executable header as described on https://msdn.microsoft.com/en-us/library/windows/desktop/ms686774.aspx Default stacksize to 2 Megs in case RLIMIT_STACK is set to RLIM_INFINITY. - First cut of an implementation to allow signal handlers running on an alternate signal stack. - New API sigaltstack, plus definitions for SA_ONSTACK, SS_ONSTACK, SS_DISABLE, MINSIGSTKSZ, SIGSTKSZ. - New API: sethostname. Bug Fixes - - Enable non-SA_RESTART behaviour on threads other than main thread. Addresses: https://cygwin.com/ml/cygwin/2015-06/msg00260.html - Try to handle concurrent close on socket more gracefully Addresses: https://cygwin.com/ml/cygwin/2015-06/msg00235.html - Fix fork failing after the parent recovered from a stack overflow. Addresses: https://cygwin.com/ml/cygwin/2015-06/msg00384.html - Fix a crash on 64 bit XP/2003 when opening /proc/$PID/maps. - Apparently on some Windows systems timezones differ in case from the standard. Fix the tzset tool to check case-insensitive. Addresses: https://cygwin.com/ml/cygwin/2015-07/msg00113.html Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: ACL Hell
On 07/15/2015 04:32 AM, Andrey Repin wrote: Greetings, Sky Diver! Hi, in the past several months or so, cygwin started giving me ACL pain in small surges which are gradually growing.. Here's a basic scenario that is slowly, but surely, driving me NUTZ: $ ln -s /cygdrive/c/tmp /tmp ln: failed to create symbolic link ‘/tmp’: Operation not permitted Are you running with superadmin credentials? Unlike Linux, Windows doesn't let regular users make symlinks. Well, we're missing the cygcheck information from the OP (see the problem report guidelines at this link - http://cygwin.com/problems.html) to know if he's set one of the non-default modes of creating symlinks (see https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks). The default method for creating Cygwin symlinks wouldn't require elevated permissions. If this is the issue, then the solution is to either create symlinks with elevated permissions or to use the default symlink mode which works even without the elevated permissions. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: TEST RELEASE: Cygwin 2.1.0-0.4
On 07/15/2015 08:24 AM, Ken Brown wrote: Got it. What's needed is a Cygwin-specific fault-*.h file which exposes how to fetch the stack pointer register from mcontext_t. As you can see from the plethora of fault-*.h files in the src subdir, this is highly system-specific anyway. Here's the set of files you need to rebuild libsigsegv for Cygwin 2.1.0, with all tests running and passing on i686 and x86_64. No other patch is requied. Awesome! Makes my work easier. Great! Thanks. So, who of you is going to maintain it? I'll defer to Eric, but if he doesn't want it then I'll take it. I'll take it. Expect a package up later this week, as well as a rebuilt 64-bit m4 that uses it. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
