Re: [PATCH] Change linker to gcc for cygwin
On Aug 15, 2015, at 7:52 AM, Achim Gratz strom...@nexgo.de wrote: [Cygwin Perl maintainer here] Ivan Pozdeev writes: Currently, g++ is specified in hints/cygwin.sh It is quite a weighty install - approaches 100M with dependencies - and since it isn't really needed (see below), requiring it is completely unnecessary. Moreover, as a consequence, it's also required when building modules. I'm in general sympathetic with trying to keep dependencies small. yes, g++ is not required, only for -devel. g++ is not needed as perl run-time dep, only as build dep and devel dep, for people compiling XS modules. The current choice was introduced in commit 4f3b19ea9f1065e1d9d263b4c07fca1ba8f29276 as a replacement for `ld2'; related cygwin maillist message by Reini Urban: https://www.cygwin.com/ml/cygwin/2007-07/msg00665.html Neither the message not the linked perl5-porters thread contain any information on the choice of g++ over gcc. Maybe Reini himself can comment on his decision? g++ as ld was needed to be able to link C++ projects which also link to libperl, like gnome I think. Maybe you could discuss things concerning Cygwin on the Cygwin mailing list first before proposing changes for Cygwin upstream. I don't pretend to know every detail of how and where Perl is used on Cygwin and you shouldn't either. Maybe using g++ as a linker was something that just happened or for reasons that are not valid anymore, but it's one of the things I wouldn't want to change on a whim. It is still valid, Yaakov needed that. -- 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: The future of clisp-gdi
2015-02-24 0:55 GMT+01:00 Ken Brown: Reini, Do you plan to resume development of the gdi module? If not, I think clisp-gdi will have to be dropped from the distribution the next time there's a new release of clisp. gdi no longer compiles with the current clisp development trunk, and I don't have the interest or the expertise to fix it. Currently I have zero time to fix it for 2.49. Maybe in a year or so. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: ffcall
On 02/19/2015 06:19 PM, Ken Brown wrote: On 2/19/2015 11:46 AM, Ken Brown wrote: On 2/19/2015 10:43 AM, Reini Urban wrote: On 02/19/2015 10:38 AM, Corinna Vinschen wrote: On Feb 18 17:41, Ken Brown wrote: Help with basic x86_64 assembler is ok, I did it for Cygwin with help from Kai Tietz. The main difference to Linux you have to look out for is the different calling convention and how the registers are used: http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention So the job is typically to rearrange the register usage and to account for the only four registers used for the first arguments to a function, rather than the 6 registers in the SYSV ABI. I might give it a try at some point, but I'm not highly motivated unless someone who really cares about clisp steps forward to help. I'll concentrate first on seeing if I can get some 64-bit version of clisp built without ffcall. Should be doable without. Yes, it seems to be. So far I've built and am testing a version with no non-default modules, and with the default regexp module disabled. I had to do the latter because of the gcc problem I encountered while trying to compile regexi.c: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939 The same sort of error occurs with several other modules. Huh, that's a good one! Something for Kai. I tried to test my build by using it to build xindy. It appeared to work, as far as it went, but it didn't go too far because xindy requires the regexp module. So I think I'm stuck until the gcc problem is resolved. I don't whether it's worth uploading my crippled clisp at this point to let it get some testing. Reini, is clisp without regexp at all useful? Usually clisp users don't need the regexp module, they usually have better matchers. But xindy needs it, so... :) And the deal with the latest clisp 2.49 was that modules can be dynaloaded. If the gnulib steps would work. I never did for me. And I fixed most of the other module compilation problems before.
Re: HEADSUP: Packages with obsolete dependencies
On 02/11/2015 07:56 AM, Achim Gratz wrote: Of the orphaned packages, as said in another thread, I'd make rakudo and parrot obsolete. I can maybe resurrect them after the Perl update if there's still interest in those or maybe a new maintainer shows up. yes, please. parrot is now dead upstream, and rakudo needs now moarvm and jvm dependencies. The planned stable rakudo release is Dec 2015, so there's enough time to get a maintainer. They work mostly on windows.
Re: ffcall
On 02/19/2015 10:38 AM, Corinna Vinschen wrote: On Feb 18 17:41, Ken Brown wrote: Help with basic x86_64 assembler is ok, I did it for Cygwin with help from Kai Tietz. The main difference to Linux you have to look out for is the different calling convention and how the registers are used: http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention So the job is typically to rearrange the register usage and to account for the only four registers used for the first arguments to a function, rather than the 6 registers in the SYSV ABI. I might give it a try at some point, but I'm not highly motivated unless someone who really cares about clisp steps forward to help. I'll concentrate first on seeing if I can get some 64-bit version of clisp built without ffcall. Should be doable without. In the meantime I started here: https://github.com/rurban/ffcall/tree/win64 with a win64 port, time permits. win64 also needs 32byte shadow stack space to spill rcx, rdx, r8 and r9. libffi added win64 and cygwin64 support recently, but ffcall is easier to understand, and faster.
Re: perl-5.14.4
On 02/05/2015 05:13 PM, Achim Gratz wrote: BTW, does anyone know what repository the SHA1 in the patch files refer to? One of them is in the official perl.git, but the rest I cannot find in either rurban/perl.git nor the Cygports repository. Regards, Achim. Which SHA1? In the filenames of my patches? Probably old rebased away commits in rurban/perl.git branch cygwin, sorry. Do you need them?
Re: perl-5.14.4
On 02/04/2015 11:10 PM, Achim Gratz wrote: David Stacey writes: On 04/02/15 20:41, Achim Gratz wrote: If this sounds like a good idea to everybody else I'd remove the current test package for 5.18.4 on 32bit and replace it with another test package for 5.14.4, likely in about two weeks. Comments or suggestions? Do you expect the XS modules built against 5.14.2 to be compatible with 5.14.4, or would you like them rebuilt? I expect them to be compatible, but I haven't tested that assumption yet. You need to keep the useint* and usemymalloc settings from 5.14.2, then it should be ok. For the new 5.22 one you need to disable usemymalloc and remove the _0/.0 suffix in the dll and archname directory name to provide seemless upgrades to 5.22.1 and 5.22.2 later, to fix the .0 bugs. Typically a .0 perl release is of very poor quality. The plan sounds good.
Re: [HEADSUP] Dropping libopenssl098 from distro
On 01/14/2015 03:19 PM, Ken Brown wrote: On 1/14/2015 12:46 PM, Achim Gratz wrote: Corinna Vinschen writes: Clisp is not yet ported to 64bit and it has problems under 32bit as well (temporary file generation) that also affect Maxima from ports. If it's a problem with the Cygwin DLL, it would be nice to get a bug report and, preferredly, an STC, so we have a chance to fix this. AFAIK it's the same problem that produced the same symptoms in sqlite: using a non-Cygwin API. So no, I don't think the Cygwin DLL is to blame. Apart from that, I was only talking about the 32 bitr version anyway. It requires the wrong libopenssl and needs a simple rebuild for now. One of the things holding a port off is libsigsegv, IIRC. This is a bit annoying. Libsigsegv should be optional, not required. I have no idea whether that's possible for clisp. It is. There's a configure option --ignore-absence-of-libsigsegv. But there are more serious problems, affecting both the 32-bit and 64-bit versions. (So even just rebuilding clisp for 32-bit Cygwin will take some work.) The problem is that lisp.exe, which is built and used in the course of trying to build clisp.exe, crashes with a SEGV shortly after it's started. My reason for looking at this was that clisp is needed for building xindy, an optional component of TeX Live. I did successfully build clisp in the 32-bit case four years ago, but I can't any more. My guess (untested) is that this is because the location of the heap has changed since then, and maybe the source code makes unwarranted assumptions about memory layout. It's a shame that Reini isn't available to help with this. 64bit is not yet possible, yes. on 32bit, just use 2.48, which should work ok. but the build system is tricky. 2.49 never really worked. I've tried a few times to fix modules support. Most of my fixes are upstream, but the last released version was not fixable anymore. A gnulib problem.
Re: perl-5.18.4
On 01/23/2015 06:39 AM, Corinna Vinschen wrote: On Jan 23 05:50, Reini Urban wrote: 2015-01-19 4:02 GMT-06:00 Corinna Vinschen: On Jan 19 10:36, Marco Atzeri wrote: On 1/19/2015 9:55 AM, Corinna Vinschen wrote: Still, why? Is it real backward incompat, or just due to DLL versioning? Does DLL versioning really make sense here? Usually, if the new DLL is only providing new stuff but not breaking backward compat, we're not bumping the DLL version. Corinna looking at the Changelog, they are breaking API http://perldoc.perl.org/perl5180delta.html#Incompatible-Changes http://perldoc.perl.org/perl5200delta.html#Incompatible-Changes Oh well. Yes. BTW: 5.22 will be about 1.8 times faster on perl-heavy tasks. So you are still here, somehow? You didn't bother to reply for the last three months, so I'm wondering, what are your plans as Cygwin maintainer? You maintain quite a couple of packages, some of them not yet available as 64 bit packages: catdoc clisp ctris fcgi ffcall libsigsegv libtextcat mathomatic parrot perl-io-tty perl-libwin32 perl-win32-gui rakudo scsh tesseract-ocr Are you still with us? Not really, sorry. Just lurking, but not much time to work in cygwin anymore. All my packages are up for grabs. clisp was broken upstream with the change to dynamic modules, the rest should be trivial to maintain. signature.asc Description: OpenPGP digital signature
Re: perl-5.18.4
2015-01-19 4:02 GMT-06:00 Corinna Vinschen: On Jan 19 10:36, Marco Atzeri wrote: On 1/19/2015 9:55 AM, Corinna Vinschen wrote: On Jan 15 18:51, Achim Gratz wrote: I've finally managed to produce a working Perl including debuginfo via cygport. Thanks! Corinna Vinschen writes: However, why does a bump from 5.x to 5.y require a rebuild of other packages? Is the perl stuff backward incompatible from one minor version to the other?!? Anything linked against the Perl DLL must be rebuilt. Still, why? Is it real backward incompat, or just due to DLL versioning? Does DLL versioning really make sense here? Usually, if the new DLL is only providing new stuff but not breaking backward compat, we're not bumping the DLL version. Corinna looking at the Changelog, they are breaking API http://perldoc.perl.org/perl5180delta.html#Incompatible-Changes http://perldoc.perl.org/perl5200delta.html#Incompatible-Changes Oh well. Yes. BTW: 5.22 will be about 1.8 times faster on perl-heavy tasks.
Re: perl-5.18.2-1
2014-10-29 12:17 GMT+01:00 Corinna Vinschen corinna-cyg...@cygwin.com: On Oct 28 12:41, Ken Brown wrote: On 8/16/2014 3:04 AM, Achim Gratz wrote: Yaakov Selkowitz writes: Thanks for the reminder. Where did we leave off wrt breaking out perl_vendor? I've offered a practical way to do this for everyone to test on a 32bit install. If that works and is agreeable, I've also offered to ITA/ITP the packages in question plus any other Perl distributions that maintainers want to be taken off their hands. That's the way I've been running my own installations for about two years now and I haven't been looking back. This way was not practical. You cannot ensure a proper rebased initial set this way, hence 32bit rebase error will be more likely. I didn't make progress in the autorebaser for cpan installs. Another two months have passed and there's still no response from Reini, nor do we have a release of perl-5.18 on x86_64. Can someone suggest a way to move forward? Is Reini still with us? Reini? Ping? Your last reply to the issue is from Aprl 9th, and you never replied to the problems outlined by Yaakov the same day. I'm reading but I cannot work on it, since my machines are still on the ship from the US to Europe. P.S: If Reini doesn't reply within the next two or three weeks, I'd say perl is up for grabs. But I'm fine if Achim takes it, since he caused too many troubles in his x86_64 packaging changes for the 32bit port, which I didn't want to follow. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: [ANNOUNCEMENT] Updated: perl-5.18.2-1 (x86) [test] Attn Maintainers with perl reqs
On May 2, 2014, at 3:32 AM, Achim Gratz wrote: Reini Urban writes: perl, perl_vendor, perl_manpages, perl_debugbuild The debug package is actually named perl_debuginfo at the moment, but perhaps it should be renamed perl-debuginfo to conform to all other packages? probably. I also found out that several vendor packages are now separated on x86_64, so I’ll have to split them also for 32bit. Lot more work todo for me, but apparently some guys just went ahead. @INC looks strange: why do you keep vendor_perl for 5.10, but not for 5.14? Do we really want to fall back to site_perl 5.10 and 5.8 these days? oops, vendor_perl/5.14 is missing. yes, falling back to good old arch-unspecific code is no problem and saves installation time and space. and we did support those versions. still working on unexpected socketpair problems with 64bit. -- 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: perl-5.18.2-1 (x86) [test] Attn Maintainers with perl reqs
I've uploaded the first test packages for the new perl-5.18.2, x86 only, today, as test package. Most problems in the last weeks were on 32bit only, 64bit has a much better address space. perl, perl_vendor, perl_manpages, perl_debugbuild I'll upload the new 64bit version and my own missing perl subpackages in the next few days also. No problems expected, as my smoker is pretty stable on 64bit. Note that perl-5.18 has some new and maybe unexpected syntax warnings. And there are still some minor bugs lurking. That's the price we have to pay. See http://perldoc.perl.org/index-history.html There are also some shiny new features, such as with Unicode. I'll probably skip 5.20, and wait for 5.22 as this will probably have improved hashtables and better security. Changes: - updated perlrebase to use the rebase -s database with a systemperl in /usr/bin - improved automatic rebase with EUMM, not with Module::Build (using rebase -s) - changed gcc-4 to gcc, g++-4 to g++ as there are no -4 variants anymore Changes in perl_vendor: - Replaced Crypt::SSLeay for CPAN::Reporter with Net::SSLeay, LWP::Protocol::https and IO::Socket::SSL to support hostname verification. In the next few weeks I hope that all maintainers with perl as requirement will have updated their packages as test, or can verify that they don't need to update, so that we can have a unified switch over as with 5.14. Only packages which link to libperl or are building XS libs need to update as soon as possible. The others might want to check if their perl scripts are still running, so that the pain after the switch is minimized. It's really easy now with cygport and only 2 lines needed: CPAN_AUTHOR=who inherit perl It's only 173 setup.hints in those packages :) perl/perl-libwin32 perl/perl-Win32-GUI parrot/parrot-devel parrot/rakudo-star perl-ExtUtils-Depends perl-Clone perl/perl-Text-CSV ?? perl/perl-Text-CSV_XS perl/perl-IO-Tty perl/perl-Error delta copyright-update cvsutils autobuild postgresql/postgresql-plperl openssl sendxmpp groff/groff-perl perl-Locale-gettext perl-Tk subversion weechat/weechat-perl gtk-doc stow help2man w3m icon-naming-utils texi2html atool llvm/clang-analyzer cdrkit/genisoimage man/manlint stunnel snownews grepmail ddir libproxy/perl-Net-Libproxy TeXmacs openldap/openldap-server boost/libboost-devel colorgcc net-snmp libbonobo2 quilt lftp monotone mm-common netpbm vim/vim-common docbook-utils aspell -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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
Updated: perl-5.18.2-1 (x86) [test] Attn Maintainers with perl reqs
I've uploaded the first test packages for the new perl-5.18.2, x86 only, today, as test package. Most problems in the last weeks were on 32bit only, 64bit has a much better address space. perl, perl_vendor, perl_manpages, perl_debugbuild I'll upload the new 64bit version and my own missing perl subpackages in the next few days also. No problems expected, as my smoker is pretty stable on 64bit. Note that perl-5.18 has some new and maybe unexpected syntax warnings. And there are still some minor bugs lurking. That's the price we have to pay. See http://perldoc.perl.org/index-history.html There are also some shiny new features, such as with Unicode. I'll probably skip 5.20, and wait for 5.22 as this will probably have improved hashtables and better security. Changes: - updated perlrebase to use the rebase -s database with a systemperl in /usr/bin - improved automatic rebase with EUMM, not with Module::Build (using rebase -s) - changed gcc-4 to gcc, g++-4 to g++ as there are no -4 variants anymore Changes in perl_vendor: - Replaced Crypt::SSLeay for CPAN::Reporter with Net::SSLeay, LWP::Protocol::https and IO::Socket::SSL to support hostname verification. In the next few weeks I hope that all maintainers with perl as requirement will have updated their packages as test, or can verify that they don't need to update, so that we can have a unified switch over as with 5.14. Only packages which link to libperl or are building XS libs need to update as soon as possible. The others might want to check if their perl scripts are still running, so that the pain after the switch is minimized. It's really easy now with cygport and only 2 lines needed: CPAN_AUTHOR=who inherit perl It's only 173 setup.hints in those packages :) perl/perl-libwin32 perl/perl-Win32-GUI parrot/parrot-devel parrot/rakudo-star perl-ExtUtils-Depends perl-Clone perl/perl-Text-CSV ?? perl/perl-Text-CSV_XS perl/perl-IO-Tty perl/perl-Error delta copyright-update cvsutils autobuild postgresql/postgresql-plperl openssl sendxmpp groff/groff-perl perl-Locale-gettext perl-Tk subversion weechat/weechat-perl gtk-doc stow help2man w3m icon-naming-utils texi2html atool llvm/clang-analyzer cdrkit/genisoimage man/manlint stunnel snownews grepmail ddir libproxy/perl-Net-Libproxy TeXmacs openldap/openldap-server boost/libboost-devel colorgcc net-snmp libbonobo2 quilt lftp monotone mm-common netpbm vim/vim-common docbook-utils aspell -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: GIT (was: Coverity Scan)
On Fri, Apr 25, 2014 at 11:22 AM, Corinna Vinschen wrote: On Apr 25 15:24, Jim Garrison wrote: Corinna Vinschen Yeah, I'm n ot exactly looking forward to it since I'm very familiar with CVS or SVN, but have nothing but trouble with git. But since everybody else is so very happy with git, I guess I'll have to adapt. Teeth-gnashingly. I recently went through the same reluctant switch to Git from SVN. I can tell you from personal experience that there's a period of disorientation when even the simplest tasks require a quick trip to Google. And Git requires a major shift in your mental model of how things work. Instead of 2 places where stuff is (local and remote) there are now 4 (workspace, stage, local repo, remote repo). ... Yeah, I'm trying to get a grip via the book http://git-scm.com/book/ Only experience helps. I needed about a year to not loose too much changes after the switch from svn to git, but feeling very happy now. It helps having backups for the beginning if you try out rebase or reset --hard or git pull --force. -- 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: 64-bit: Missing perl modules
On Tue, Apr 8, 2014 at 4:27 PM, Achim Gratz wrote: Reini Urban writes: Only if you register each and every user module with the system. But we don't want that. Wait, weren't we talking about vendor-perl, possibly site-perl? These two locations are already registered with the system. The only head-scratcher for me are always inline modules compiled on the fly and stuffed into private directories. Rebase doesn't provide for any private libraries and really it can't since this is a system-wide issue. So why are you discussing this with me that long when you have no idea how the systems works, and how it should work? FYI: vendor-perl is provided by perl_vendor and pre-rebased, and then post-rebased by setup. site-perl is populated by cpan and rebased with EUMM hooks and perlrebase. Without proper rebasing of all dll's perl will not be able to fork or call itself, and it does it very often. The most prominent case being EUMM and CPAN. This is only an issue for 32 bit, 64 bit has a much friendlier address space.
Re: 64-bit: Missing perl modules
On Tue, Apr 8, 2014 at 1:01 PM, Achim Gratz wrote: Reini Urban writes: Nope. Care to explain? Already did. It's vastly easier to keep perl_vendor than to split it up. For all parties. You can do individual perlrebase or wait for the full autorebase for every XS installation. Or do an ephemeral rebase that is taking the rebase map of the rest of the system correctly into account. Only if you register each and every user module with the system. But we don't want that. I know that you want to cygport every single perl module, but this is a very extreme position. With individual split perl_vendor packages the user needs to wait for every single rebase update. No. You can run the incremental rebase directly if you wish and as long as the rest of the system had been rebased correctly it will only touch the new stuff. With the combined perl_vendor I'll do it as part of the build step and the user only needs to wait for one rebase run. You wouldn't need a special perlrebase for that, that's the whole point. True. With proper EUMM and MB integration we would need no perlrebase. But MB is a mess. And Module::Install even more. And I wonder what will come up next. MB::Lite is already in the works just to bypass GNU make. Sure, that's automatic of you care to package everything. But updates come every week, not every two years. In my case I have to package things anyway since I need to distribute the to a bunch of machines that have no outward connection. Besides the need for an internal CPAN mirror, I'd generally not trust a random user to run a CPAN update and make a judgment of whether or not everything worked as expected. Packaging some 300 Perl distributions really is less work than any of the alternatives and keeping things up-to-date isn't all that time-consuming so far. Fair enough. But then I would keep them uptodate with a simple cpan or rsync, which is better than setup.exe. No need to stop all services. I maintain about 40 VM's this way, cross-version and platform. cpan ensures proper testing and with CPAN::Reporter being integrated the authors even get feedback. strawberry perl does the same.
Re: 64-bit: Missing perl modules
On Sun, Apr 6, 2014 at 1:59 PM, David Stacey wrote: On 06/04/14 17:38, Achim Gratz wrote: David Stacey writes: Thank you for your reply. Yes, I was aware of that discussion. I'm not talking about breaking up 'perl_vendor' for 32-bit Cygwin (although IMHO that would be a good thing in the long term). I'd just like to see the perl modules I mentioned adding to 64-bit Cygwin - and I'm happy to maintain those packages myself if no-one else want to claim ownership. I don't see why it should be a good idea to have different packaging for the two architectures, so I still think this issue needs to be decided. Agreed. Hopefully the different collections of perl modules that are available in the two architectures can be unified with the next perl release. Anyway, here's what I have: Yes, those are more or less identical to the packages that I prepared - I could have done with those links a few days ago :-) It's rather nice (albeit inefficient) to have two people trying to do the same thing - so often in open source programmes no-one has the time! You've obviously put some thought and effort into this, so I'm happy to step back and let you (or Reini) to maintain these perl modules. The important thing is that they end up in 64-bit Cygwin at some point. Thankfully, cygport makes most perl modules absurdly easy to maintain. So if you need someone to adopt a few if and when 'perl_vendor' gets split up then please let me know. Dave. The new 5.18.2 package will be unified for 32bit and 64bit, yes. perl_vendor will probably stay as is, as it is the easiest for the user and the maintainer. I still need to rebase all most-used XS modules esp. on 32bit perl to make sense and avoid dll base collisions on forks, which happens with CPAN, a basic bootstrap problem. My cygwin-specific rebase framework for CPAN modules still needs some love, esp. on 32bit. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: 64-bit: Missing perl modules
On Mon, Apr 7, 2014 at 2:29 PM, Achim Gratz wrote: Reini Urban writes: The new 5.18.2 package will be unified for 32bit and 64bit, yes. Looking forward to it... perl_vendor will probably stay as is, as it is the easiest for the user and the maintainer. I beg to differ. It would be vastly easier for everyone if perl_vendor simply depended on those packages that are now hidden inside it. Let me know what's inside the new perl_vendor and I'll help to produce those single distribution packages. Nope. I still need to rebase all most-used XS modules esp. on 32bit perl to make sense and avoid dll base collisions on forks, which happens with CPAN, a basic bootstrap problem. I've not been doing that for more than two years now and have actually backed out the respective changes in MakeMaker, IIRC. As long as I'm using cygport I'm not running into problems (except for PDL since this produces several DLL that initially occupy the same address space, which is easily taken care of with an ephemeral rebase before testing). You can do individual perlrebase or wait for the full autorebase for every XS installation. With individual split perl_vendor packages the user needs to wait for every single rebase update. With the combined perl_vendor I'll do it as part of the build step and the user only needs to wait for one rebase run. My cygwin-specific rebase framework for CPAN modules still needs some love, esp. on 32bit. I'm doing incremental auto-rebase on install, YMMV. Sure, that's automatic of you care to package everything. But updates come every week, not every two years. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: Cygwin 1.7.25-1.7.28 - the perl process couldn't wake up after system call
On Mon, Apr 7, 2014 at 11:37 AM, Larry Hall (Cygwin) wrote: On 4/7/2014 8:03 AM, Eduard wrote: Hi, We run Cygwin 1.7.25-1.7.28 on Win7-64bit. perl version is v5.14.2. Sometimes during system call from perl we see the following error: 0 [sig] perl 9852 stopped_or_terminated: couldn't wake up wait event 0x110, Win32 error 6 The process hangs and cannot be terminated by kill command. The only way to kill process is with windows task manager. Our tasks require many system calls to complete Please advise how to resolve this. Eduard: Please advise (off-list if too much data) how I could reproduce this problem. I never stumbled on that. Esp. the 64 bit version is much safer than the 32bit version. Is it any better or worse with Cygwin 1.7.29 that was just released? -- 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: perl update?
On Sun, Mar 2, 2014 at 5:50 PM, Ken Brown kbr...@cornell.edu wrote: Reini, This is a followup to http://cygwin.com/ml/cygwin-apps/2013-06/msg00152.html Are you planning a perl update in the near future? I'm starting to work on TeX Live 2014, and it would be nice to be able to include the current version of biber (and biblatex). With perl-5.14, I have to ship biber-1.5. Upstream biber is now three releases later, at 1.8. Oh sorry. I was waiting for the latest socket fix upstream to fix the problem with processes from the the CPAN shell not reacting to input, but it didn't happen. There are 12 test cases failing 32bit and 3 for 64bit so I guess it's time now. http://perl514.cpanel.net/build/builders/perl5-cygwin http://perl514.cpanel.net/build/builders/perl5-cygwin64 -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: Executing a perl script from Windows 7
perl core has a script called pl2bat.pl to create an executable bat file. It's in win32/bin/pl2bat.pl See http://perl5.git.perl.org/perl.git/blob_plain/HEAD:/win32/bin/pl2bat.pl -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: gcc-4.7.3-1
On Tue, Dec 17, 2013 at 11:04 AM, marco atzeri wrote: ... Note that this also needs to be done when building perl XS extensions. With the next perl update we will use gcc then. in your ~/bin or /usr/local/bin ln -s /usr/bin/gcc gcc4 -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
On Wed, Dec 4, 2013 at 2:18 PM, bartel wrote: Rebase is fine now; all I get is this harmless (?) message: /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll: skipped because nonexistent. Nonexistent is not the whole truth: it's just a dangling symlink. Sibling cygperl5_14.dll is fine Is that a bug or my doing? That is a known packaging glitch in perl, yes. You can ignore it. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: mosh-1.2.4-2 (x86)
I've fixed mosh on x86 adding the missing /usr/bin/mosh perl-wrapper, not x86_64 not needed. Thanks to Egon Ojamaa See http://cygwin.com/ml/cygwin/2013-11/msg00464.html -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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
Updated: mosh-1.2.4-2 (x86)
I've fixed mosh on x86 adding the missing /usr/bin/mosh perl-wrapper, not x86_64 not needed. Thanks to Egon Ojamaa See http://cygwin.com/ml/cygwin/2013-11/msg00464.html -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: mosh-1.2.4-1 (x86) missing mosh executable in package !
On 11/29/2013 02:38 AM, Egon Ojamaa wrote: https://sourceware.org/ml/cygwin/2013-11/msg00381.html I have tried several mirrors and i get no mosh or mosh.exe or any bash alias for mosh command. As I peek into binary package file.. I see there is only 2 files (mosh-client.exe,mosh-server.exe) , but the man page speaks of using mosh command. admin9000@Win764bitTestMachine~ $ mosh -bash: mosh: command not found admin9000@Win764bitTestMachine~ $ ls /usr/bin/mos* /usr/bin/mosh-client.exe /usr/bin/mosh-server.exe oops, I'll fix it ASAP admin9000@Win764bitTestMachine~ If i use x64 cygwin. Everything works fine. admin@T64TW7Poff ~ $ mosh Usage: /usr/bin/mosh [options] [--] [user@]host [command...] admin@T64TW7Poff ~ $ ls /usr/bin/mos* /usr/bin/mosh /usr/bin/mosh-client.exe /usr/bin/mosh-server.exe -- 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: mosh-1.2.4-1 (x86_64)
I've updated mosh on x86_64 to the latest version 1.2.4 also. See http://cygwin.com/ml/cygwin-announce/2013-11/msg00017.html for the 32 bit announcement -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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
Updated: mosh-1.2.4-1 (x86_64)
I've updated mosh on x86_64 to the latest version 1.2.4 also. See http://cygwin.com/ml/cygwin-announce/2013-11/msg00017.html for the 32 bit announcement -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
[ANNOUNCEMENT] Updated: protobuf-2.5.0-1 (x86)
I've updated protobuf-2.5.0-1 on x86 only so far, with libprotobuf-devel and the new libprotobuf8, required by mosh. This is now the same version as on cygwinports. It is a feature release, adding support for import public and a new enum option allow_alias See http://protobuf.googlecode.com/svn/trunk/CHANGES.txt -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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
Updated: protobuf-2.5.0-1 (x86)
I've updated protobuf-2.5.0-1 on x86 only so far, with libprotobuf-devel and the new libprotobuf8, required by mosh. This is now the same version as on cygwinports. It is a feature release, adding support for import public and a new enum option allow_alias See http://protobuf.googlecode.com/svn/trunk/CHANGES.txt -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
[ANNOUNCEMENT] Updated: mosh-1.2.4-1 (x86)
I've updated mosh on x86 to the latest version 1.2.4, x86_64 not yet. Changes largely include bug fixes, improved robustness, and added platform support. This reinstates the original perl wrapper, as the failing perl IO::Tty module is not used anymore. See http://mailman.mit.edu/pipermail/mosh-users/2013-March/000167.html -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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
Updated: mosh-1.2.4-1 (x86)
I've updated mosh on x86 to the latest version 1.2.4, x86_64 not yet. Changes largely include bug fixes, improved robustness, and added platform support. This reinstates the original perl wrapper, as the failing perl IO::Tty module is not used anymore. See http://mailman.mit.edu/pipermail/mosh-users/2013-March/000167.html -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: The upload system is live (Re: Major changes coming to procedure for uploading to sourceware)
On Wed, Oct 16, 2013 at 11:52 AM, Christopher Faylor wrote: On Sat, Oct 12, 2013 at 04:22:37PM -0400, Christopher Faylor wrote: I think I now have a system set up which will allow maintainers to upload their own packages to sourceware. This system means that package maintainers won't have to find a public web server to make their packages available for the cygwin release. Every package maintainer will be able to upload their own stuff. General login access to sourceware will no longer be required to update the cygwin release. This system is now live. Anyone who sent in their ssh key should be able to access sourceware via lftp/sftp. Make sure that you use the user cygwin with no password and that you are using the same ssh key as the one that you specified previously. Also, please create a !mail file at the top level of your area with the email address where any upset errors should be sent. Note: !mail Remember also that you need to create a !ready file somewhere above the directory holding the packages that you want to end up in the release. So, if you have uploaded x86 and x86_64 packages put the !ready at the root level. If you have uploaded x86 and are working on x86_64 you can put the !ready in the x86 directory and then put another !ready in the x86_64 directory when you're done. Putting the !ready directly in the package directory should work too. Note: root !ready doesn't work yet. You need a !ready in x86 and x86_64 Packages won't be moved unless upset thinks everything is ok. If there is something broken and your have an email address in the !email file then you should get email telling you what's wrong. You'll get the email even if the problem isn't your fault so don't panic. Note: !email Question: !mail or !email ? The original message only had !mail Refer to: http://cygwin.com/ml/cygwin-apps/2013-10/msg00117.html for more detail about what's going on. Note that the sftp command used there should be something like: -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: Updated: make-4.0-1 (x86 and x86_64)
I'm very happy to have make-4.0, contrary to most other distros. make-4.0 fixed some crazy bugs I was chasing which appeared with make-3.81 -j4 and I was scratching my head for months. I even added .NOTPARALLEL: hints to no avail. v4 fixed it, so it was not my fault. Thanks! -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Broken symlinks in ed, pwget and perl?
On Tue, Jul 9, 2013 at 12:35 AM, Balaji Venkataraman wrote: I see some broken symlinks in /usr in my install - AFAIK, in the latest versions of these packages. Since I couldn't find any related report, thought I'd report it. Not sure if the maintainers are already aware of these. Noticed I have ed because of texlive-collection-basic. Thanks, I am aware of this one. It's harmless. lrwxrwxrwx 1 user Users 26 Jul 17 2012 /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll - /usr/bin/cygperl5 _14_2.dll -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: [64bit] Biber packaging questions
On Tue, Jun 18, 2013 at 5:51 PM, Yaakov (Cygwin/X) wrote: On 2013-06-15 07:37, Achim Gratz wrote: Reini Urban writes: If you really want to maintain 2000+ packages do it. I don't care. Nobody suggested that all of a sudden Cygwin should come with all CPAN distributions pre-bundled. My current guess, based on my own usage, would be on the order of 300 packages. Let's hope it will stay with this low number. 300 is ok. If that. There are currently 81 CPAN packages in the 64-bit distro after Ken added biber's deps, and a few dozen more may be needed to fill in what was provided by perl_vendor. Even Ports provides only 133 CPAN packages to support all the software therein, so it really shouldn't be that big of a number in all. I hope you know what happens over at debian, macports and redhat with this scheme. Been there, done that. I'm not sure to what you're referring, Reini, but this can and does work. Works for them barely, but not for us. 1. Not easy with our limited cygwin setup UI. It's better now with the filter, but still horrible compared to linux distro packagers, and cmdline tools. 2. Horrible update scenarios, constantly back several releases. Also, our UI setup selector cannot handle that. It's easy enough to provide bundle packages and the normal user would never need to look at the individual distribution packages. They could even be hidden if seeing those in the chooser window really is a problem. We don't need bundles, and we certainly don't want to hide packages from users. Even a couple hundred packages in their own category should work just fine. At cygwin we favor cpan over cygwin packages. According to whom? That may work for LFS-type scenarios, but distributions can't say oh, BTW, this 'biber' program you want to use needs a few dozen Perl libraries, go get them yourself from CPAN. Perl modules that are dependencies of other packages need to be properly packaged for the distribution to work OOTB. According to the perl package maintainers in the past and present. Seperate module packages are only needed as dependency for main packages. If the urgent need for a local patch arises the user can always cpan it, until the lazy maintainer updates his package. Patching really isn't so much the problem here; adding new modules, and keeping things updated is. As I said. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: [64bit] Biber packaging questions
On Wed, Jun 12, 2013 at 10:18 AM, Corinna Vinschen wrote: On Jun 12 10:10, Ken Brown wrote: Here are my questions: 1. Should these build prerequisites be added to the 64bit distro? Otherwise it will be difficult for others to rebuild biber from source. In theory, yes. Ideally for 32 and 64 bit, even if you don't really need it for 32 bit. 2. Biber requires perl 5.16 or later, so I did a quick and dirty build of perl-5.16.3. By quick and dirty I mean that I simply took Yaakov's perl.cygport and removed all patches that wouldn't apply. This is no problem for *users* of biber.exe, since the latter includes the perl DLL. But again it makes it difficult for others to replicate the build until the official perl is updated. I have no idea what to do about this. AFAIR Reini wrote something about perl 5.16 having some serious bugs, or problems which makes it unfeasible for the distro. Reini, can you chime in here? With enabling unicode symbols 5.16 silently started allowing \0 in symbol and package names, without any protection and further support, which makes it unusable for me in serious environments. Since I'm not considering cygwin a serious environment it's probably no big deal. Unfortunately p5p and the security team is in denial and ignores the issues involved. I'm favoring 5.18, and started writing the patches. It will probably be 5.18.1-1. I found nothing critical so far. Just minor Time::HiRes and alarm problems (we are too slow), stat, a new regex regression, some new Storable problems. And mainly discspace problems with my win8 64bit vm. As if 17GB is not enough. Failed 8 tests out of 2338, 99.66% okay. ../cpan/CGI/t/tmpdir.t ../cpan/Time-HiRes/t/alarm.t ../cpan/Time-HiRes/t/ualarm.t ../ext/XS-APItest/t/call_checker.t ../lib/File/stat.t ../lib/locale.t op/filetest.t op/stat.t 3. There is a completely different approach I could take. Namely, I could simply package Biber as a perl module and forget about packing it into a Perl Archive. If I do this, then users will need perl 5.16 or later, as well as most or all of the perl modules listed above, so the RFU will have to wait for a perl update; but that's probably not serious. Would this be preferable? I'm not aware of any Linux distros that do this, though someone did do it unofficially for Fedora: http://www.linux.cz/pipermail/texlive/2012-August/000563.html I would say that's up to you, but it doesn't really sound like the right thing to do. I would also favor using biber as non-packaged perl script. Since you need so many perl deps, do you really want to keep them seperate? I would just bundle them to something like a perl-biber-bundle package, into vendor_perl. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: [64bit] Biber packaging questions
On Fri, Jun 14, 2013 at 1:49 PM, Yaakov (Cygwin/X) wrote: On 2013-06-14 13:37, Reini Urban wrote: I would just bundle them to something like a perl-biber-bundle package, into vendor_perl. No, perl_vendor needs to go away, not get bigger. I said vendor_perl, the location. You meant perl_vendor the package. Achim: Since you need so many perl deps, do you really want to keep them seperate? Yes, I would want _all_ non-core Perl distributions as separate cygwin packages. That's the only sane way to deal with these when the need for local patches arises. This is admittedly rare, but it does happen. If you really want to maintain 2000+ packages do it. I don't care. I hope you know what happens over at debian, macports and redhat with this scheme. Been there, done that. Also, our UI setup selector cannot handle that. At cygwin we favor cpan over cygwin packages. If the urgent need for a local patch arises the user can always cpan it, until the lazy maintainer updates his package. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: [64bit] Request for mhash
On Wed, May 29, 2013 at 10:27 AM, Dr. Volker Zell wrote: Is it possible to get a 64bit version of mhash. I need it for mcrypt. By the way there is a newer version (0.9.9.9) on http://sourceforge.net/projects/mhash/files/mhash/ Yes, but anybody can beat me, I don't care too much. I was a bit behind in 64bit packaging because my VM was way too unstable so far to be able to use it. Yesterday I uninstalled MSIE 10 and disabled paging and it looks much better now. My Win8 64bit VM is still running :) I hope I can catch up soon, perl-5.18 being the most important. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: cygutils Postinstall Script Errors With Exit Code 128
On Tue, May 28, 2013 at 2:43 Paul.Nickerson wrote: I am attempting to install Cygwin, and am getting errors near the end of the process. I am using version 2.774 of setup.exe on Microsoft Windows Server 2003 R2 Datacenter x64 Edition Service Pack 2 and the default Cygwin packages. This is an Amazon AWS EC2 instance, and I am remote desktopping in. In the Cygwin Setup GUI, after it goes through the install procedure, I get a window titled Postinstall script errors, with the below output text: Package: base-cygwin 000-cygwin-post-install.sh exit code 128 Package: terminfo terminfo.sh exit code 128 Package: bash bash.sh exit code 128 Package: coreutils coreutils.sh exit code 128 Package: _autorebase autorebase.bat exit code -1073741819 Package: base-files base-files-profile.sh exit code 2816 base-files-mketc.sh exit code 128 Package: cygutils cygutils.sh exit code 127 Package: man man.sh exit code 128 I got the cygutils postinstall error also, caused by missing dependencies. $ cat /etc/postinstall/cygutils.sh /usr/bin/update-desktop-database /usr/bin/update-mime-database /usr/share/mime both scripts do not exist, and are no cygutils reqs. please test against it. like: test -f /usr/bin/update-desktop-database /usr/bin/update-desktop-database test -f /usr/bin/update-mime-database /usr/bin/update-mime-database /usr/share/mime If I then open Cygwin Terminal using the Desktop shortcut, I get a window titled -sh and a prompt that says -sh-4.1$. The command ls returns -sh: ls: command not found, but echo works. I have tried re-running setup.exe, removing the cygwin directory, re-downloading the setup.exe, removing HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygwin from the registry, setting Turn on DEP for essential Windows programs and services only and rebooting, altering file and folder permissions, deleting the cache and using different mirrors, and using rdesktop in CentOS vs. mstsc.exe in Windows to remote desktop in, but none of this changes the behavior. I have an odd and possibly related behavior. If I open Command Prompt, run C:\cygwin\bin\bash.exe --norc --noprofile to get a bash-4.1$ prompt, then in there run if [ foo = foo ]; then echo Expression evaluated as true.; fi the bash prompt will exit back to command prompt, and %ERRORLEVEL% has been set to 128. Running that if statement in the window brought up by the Cygwin Terminal Desktop shortcut will sometimes make the window close, but not always. I have not explored how I might be triggering the Desktop shortcut to work or not work. I have attached setup.log and setup.log.full. When I run cygcheck -s -v -r cygcheck.out, it hangs and does not exit. Checking Task Manager, I see that it's using ~45% CPU (I have 2 virtual cores). It does write some things out to cygcheck.out, which I have attached. When I run the command in Command Prompt without redirecting output to a file, I get a little more information before it hangs, which I have copied out of the command prompt and attached as cygcheck-no-redirect.out. I do not know why it's saying I have multiple cygwin1.dlls on my path. There is only C:\cygwin\bin\cygwin1.dll. Looking at cygcheck.out, I am running in a Terminal Service session, which makes sense as I am remote desktopped in. My problem might be related to FAQ #2.14 (http://cygwin.com/faq-nochunks.html#faq.setup.setup-fails-on-ts ), but the DEP solution is not helping me. I tried running C:\cygwin\binpeflags --tsaware=true --tsaware * in Command Prompt, but it did not change anything. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Were the Perl multithreading problems ever fixed?
On Mon, May 20, 2013 at 1:14 PM, KARR, DAVID wrote: Last year I had reported some problems with a Perl script that utilizes multithreading. I believe it was Reini Urban who told me that there were known problems with Perl multithreading and that an ETA for a set of fixes was not known yet. Does anyone know if those particular Perl multithreading issues have been dealt with in later Cygwin releases? I'm still on 1.7.17. These were entirely perl related and not cygwin. And most of the known problems were fixed with the change from non-thread safe usemymalloc (perl internal malloc) to the thread-safe system malloc with 5.14.2. There are still minor thread problems within perl, but nothing dramatic. The upcoming 5.18.0 should have fixed more. Do you have a link to your report? So I can test it. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: clamav-0.97.8-1
I've updated clamav to the latest version 0.97.8 Release Notes 0.97.8: This release addresses several reported potential security bugs. 0.97.7: This is a bugfix release. See http://www.clamav.net/ or http://freecode.com/projects/clamav/ -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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
Updated: clamav-0.97.8-1
I've updated clamav to the latest version 0.97.8 Release Notes 0.97.8: This release addresses several reported potential security bugs. 0.97.7: This is a bugfix release. See http://www.clamav.net/ or http://freecode.com/projects/clamav/ -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: perl-5.14.2
On Mon, Apr 29, 2013 at 1:52 PM, Achim Gratz wrote: today I was trying to clean up my Perl installation by removing all of site_perl on Cygwin and I noticed that Class:ISA (which is supposed to be a core module) was suddenly missing. Is there a particular reason Perl has been packaged without it (whereas perl-5.10.1 had it)? It's gone. (removed upstream) perl5140delta.pod:LClass::ISA has been removed from the Perl core. Prior version was 0.36 -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: the DBI for perl
On Sat, Mar 23, 2013 at 5:55 AM, Wynfield Henman wrote: Thank you Csaba and Reini for the information in helping me build the Perl database interface code. I downloaded the gcc-4 and the build process worked. And Reini, thanks for the 64 number significance explanation. And while we are here: I hope you are not using the unpatched cygwin DBI for any public facing server. DBI 1.624 still needs my use-after-free patch from https://github.com/rurban/distroprefs/blob/master/sources/authors/id/R/RU/RURBAN/patches/DBI-1.622_921.patch It's just cygwin, but who knows. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: perl (why 64int on 32int machine)
On Fri, Mar 22, 2013 at 6:48 AM, Wynfield Henman wrote: I just downloaded and tried to build and install Perl's Database Interface, DBI (yes the hard way, using Marefile.PL). Configure completed fine, but make fails with: make gcc-4 -c-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -g -fno-strict-aliasing -pipe -fstack-protector -DUSEIMPORTLIB -O3 -DVERSION=\1.623\ -DXS_VERSION=\1.623\ -I/usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE -W -Wall -Wpointer-arith -Wbad-function-cast -Wno-comment -Wno-sign-compare -Wno-cast-qual -Wmissing-noreturn -Wno-unused-parameter Perl.c /bin/sh: gcc-4: command not found Makefile:625: recipe for target `Perl.o' failed So you need to install gcc-4 The above also mentions /usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int which I do have on my system. I did not select it and I don't have a 64 bit system. Would this indicate a setup ini problem for perl? No, i686 is 32bit, optimized for i686. 64bit would be x86_64 -64int means that the internal int size is 8 byte and optimized for 64bit systems. but it works also on pure non-pentium 32bit intel CPUs. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: [mosh-devel] Please test Mosh 1.2.4 release candidate
[initially crosspost'ed to mosh-devel]
On 03/12/2013 01:07 PM, Christoph von Stuckrad wrote:
On 11.03.2013 03:35, Keith Winstein wrote:
...
Testers on the BSDs, Cygwin, and Solaris/AIX are especially helpful.
OK, so here is my (very short, WORKING)
test on 'current' Cygwin (on WinXP):
Stucki,
Your tests are very appreciated.
My cygwin vm's are pretty slow and I'm very busy with other projects.
Do you want to take over cygwin package maintenance from me?
Just check out the cygports file, remove the cxx and src patch and
checks the deps.
$ cat mosh-1.2.3.95rc1-1.cygport
# -*- sh -*-
DESCRIPTION=Mobile Shell
HOMEPAGE=http://mosh.mit.edu/;
SRC_URI=https://github.com/downloads/keithw/${PN}/${PN}-${PV}.tar.gz;
LICENSE=GPL 3
You can add your test results to your release announcement.
In my tests I can connect from cygwin to other mosh servers,
but not yet from debian to mosh on cygwin. (firewall off)
I'm investigating...xx
Also big thanks to Anton Lundin for the IO::Pty fix. Very much appreciated.
* Support port ranges with -p LOWPORT:HIGHPORT (Luke
Mewburn)
not tested - did not want to mess with the firewalls between home(DSL)
and workplace ...
* Ctrl-^ Ctrl-Z suspends mosh client (Nikolai Zeldovich)
works in Cygwin too (but may be dangerous, because 'kills' work
different from normal UNIX under Cygwin and might collaterally
kill mosh(s) running on the same window.
* mm:ss display of lost-contact times (Kevin Ballard)
* Show infobar with control chars when Ctrl-^ is typed
both work of course
* Put terminal in altscreen mode (Anders Kaseorg)
THIS did NOT work on 'Cygwin MinTTY' with mosh (while the same program
/usr/games/worms on a ssh-connection did switch screen back!)
Do you need more Infos? Shall I test something explicitely?
Yours Stucki
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/
Re: Perl DBD::Oracle 'make test' fails: Oracle.dll permission denied
On Mon, Mar 4, 2013 at 1:01 PM, Bob McGowan wrote: I have DBI 1.623 installed, and am attempting to install DBD::Oracle 1.27. I'm using Oracle instant client for Oracle 11.2, and I created my own oci.def file using 'pexports' and 'dlltool', as described in the header of the original oci.def file. The 'perl Makefile.PL' generates no errors. My 'make' creates Oracle.dll without any major issues (a few minor complaints about mismatched types in printf, pointer casts, ...). The 'make test' fails the first test: Can't load ... Oracle.dll for module DBD::Oracle: Permission denied... I'm not sure if the Dynaloader fails, or if the connection to the oracle db fails with this error. If it's the Dynaloader be sure that all dependencies can be loaded. ldd blib/arch/Oracle/Oracle.dll will tell you that. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Binutils objcopy bug (was Re: rebase segfault)
On Sat, Jan 26, 2013 at 1:52 AM, marco atzeri wrote: On 1/26/2013 7:32 AM, Reini Urban wrote: rebase is not to blame. I agree ;-) Someone else is incorrectly managing the reloc table, and also objcopy seems innocent ... Postgresql dll's are built in this way: My strong guess is dllwrap. No other packages uses the ancient dllwrap anymore. I tried to get rid of it, but got stuck somewhere else. Hi Reini, I agree dllwrap seems the coolprit, and gcc -shared seems a better alternative, at least on a single test with this dll. I looked on the postgresql makefiles and it is a big mess to replace dllwrap; upstream is crazy, they crippled configure forcing a specific version and refusing to use Automake. Autoconf+Automake will be a much cleaner approach, and will allow to avoid at all the platform checks. Yes, I had the same impression but it is unfortunately not realistic. I worked against dllwrap removal but got stuck somewhere. When I find my old patches I'll hand it over to you. Just came back from holidays. Could you make another check on 9.2.2 package before a new RFU http://matzeri.altervista.org/cygwin-1.7/postgresql/ Sorry, holidays. Gold star please. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Binutils objcopy bug (was Re: rebase segfault)
On Fri, Jan 25, 2013 at 8:11 AM, marco atzeri wrote: On 1/25/2013 4:00 PM, Corinna Vinschen wrote: On Jan 25 14:19, Kai Tietz wrote: 2013/1/25 marco atzeri marco.atz...@gmail.com: On 1/24/2013 11:00 AM, Corinna Vinschen wrote: I already explained why: The SEGV happens during relocation. The file header has been changed already. If you call the same rebase, it will try to rebase the file to the same new address. If current file base address == requested file base address, rebase will return without performing any action. Hi Corinna, I would like your opinion on this .reloc strange issue of dict_snowball, as I have the impression I found the root cause. [...] Questions: - Is it anomalous to have a .reloc portion addressing the debug_* sections (so the original build file is broken) - or should strip recognize and remove reloc portion not anymore relevant ? rebase is choking on this portion of the .reloc table Corinna Thansk in advance Marco Well, here are my 2-cents about that issue. In general it is a flaw to have an base-relocation in debug-section, as this means such a section can't be moved into a separate debug-file anymore, due that has no relocation-information. Nevertheless it would be good, if objcopy gets adjusted to eliminated base-relocations of stripped sections. But the tool generating these debug relocs is gas, isn't it? Why on earth does it do that?!? I still think rebase is not to blame here. It has to assume that the relocation info is correct, doesn't it? rebase is not to blame. I agree ;-) Someone else is incorrectly managing the reloc table, and also objcopy seems innocent ... Postgresql dll's are built in this way: My strong guess is dllwrap. No other packages uses the ancient dllwrap anymore. I tried to get rid of it, but got stuck somewhere else. gcc -ggdb -O2 -pipe -fdebug-prefix-map=/pub/devel/postgresql/postgresql-9.2.2-1/build=/usr/src/debug/postgresql-9.2.2-1 -fdebug-prefix-map=/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2=/usr/src/debug/postgresql-9.2.2-1 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -I/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/include/snowball -I/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/include/snowball/libstemmer -I../../../src/include -I/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/include -c -o dict_snowball.o /pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/backend/snowball/dict_snowball.c dllwrap -o dict_snowball.dll --dllname dict_snowball.dll --def libdict_snowballdll.def dict_snowball.o api.o utilities.o stem_ISO_8859_1_danish.o stem_ISO_8859_1_dutch.o stem_ISO_8859_1_english.o stem_ISO_8859_1_finnish.o stem_ISO_8859_1_french.o stem_ISO_8859_1_german.o stem_ISO_8859_1_hungarian.o stem_ISO_8859_1_italian.o stem_ISO_8859_1_norwegian.o stem_ISO_8859_1_porter.o stem_ISO_8859_1_portuguese.o stem_ISO_8859_1_spanish.o stem_ISO_8859_1_swedish.o stem_ISO_8859_2_romanian.o stem_KOI8_R_russian.o stem_UTF_8_danish.o stem_UTF_8_dutch.o stem_UTF_8_english.o stem_UTF_8_finnish.o stem_UTF_8_french.o stem_UTF_8_german.o stem_UTF_8_hungarian.o stem_UTF_8_italian.o stem_UTF_8_norwegian.o stem_UTF_8_porter.o stem_UTF_8_portuguese.o stem_UTF_8_romanian.o stem_UTF_8_russian.o stem_UTF_8_spanish.o stem_UTF_8_swedish.o stem_UTF_8_turkish.o -L../../../src/port -Wl,--allow-multiple-definition -Wl,--enable-auto-import -L/usr/local/lib -Wl,--as-needed -L../../../src/backend -lpostgres -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: [ITA] postgresql-9.2.2-1
On Mon, Jan 14, 2013 at 12:40 AM, marco atzeri wrote: wget -r -np -nH --cut-dirs=1 \ http://matzeri.altervista.org/cygwin-1.7/postgresql/index.html /etc/rc.d/init.d/postgresql needs an +x, and the .exe in DAEMON is wrong ls -al /usr/sbin/postmaster /usr/sbin/postmaster - postgres.exe /usr/sbin/initdb -D /usr/share/postgresql/data required a rebaseall $ psql Segmentation fault (core dumped) 891446 [main] psql 960 fhandler_pipe::create: name \\.\pipe\cygwin-c5e39b7a9d22bafb-960-sigwait, size 164, mode PIPE_TYPE_MESSAGE 1021548 [main] psql 960 fhandler_pipe::create: pipe read handle 0x788 4501998 [main] psql 960 fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-c5e39b7a9d22bafb-960-sigwait 712069 [main] psql 960 fhandler_pipe::create: pipe write handle 0x784 652134 [main] psql 960 dll_crt0_0: finished dll_crt0_0 initialization 32675401 [sig] psql 960 wait_sig: entering ReadFile loop, my_readsig 0x788, my_sendsig 0x784 7756176 [main] psql 960 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\rurban, no-keep-rel, no-add-slash) 3436519 [main] psql 960 normalize_win32_path: C:\cygwin\home\rurban = normalize_win32_path (C:\cygwin\home\rurban) 756594 [main] psql 960 mount_info::conv_to_posix_path: /home/rurban = conv_to_posix_path (C:\cygwin\home\rurban) --- Process 960, exception C005 at F8D3 1526746 [main] psql 960 exception::handle: In cygwin_except_handler exception 0xC005 at 0xF8D3 sp 0x22AC7C 526798 [main] psql 960 exception::handle: In cygwin_except_handler signal 11 at 0xF8D3 3847182 [main] psql 960 exception::handle: In cygwin_except_handler calling 0x0 7237 [main] psql 960 exception::handle: Exception: STATUS_ACCESS_VIOLATION 557237 [main] psql 960 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1637400 [main] psql 960 try_to_debug: debugger_command '' 8116 [main] psql 960 open_stackdumpfile: Dumping stack trace to psql.exe.stackdump $ gdb psql Program received signal SIGSEGV, Segmentation fault. 0xf8d3 in ?? () (gdb) bt #0 0xf8d3 in ?? () #1 0x610fc95c in pthread::init_mainthread () at /usr/src/cygwin/src/winsup/cygwin/thread.cc:336 #2 0x61006cf5 in dll_crt0_1 () at /usr/src/cygwin/src/winsup/cygwin/dcrt0.cc:832 #3 0x6100533d in _cygtls::call2 (this=optimized out, func=0x61006c50 dll_crt0_1(void*), arg=0x0, buf=0x610054cb _cygtls::call(unsigned long (*)(void*, void*), void*)+91) at /usr/src/cygwin/src/winsup/cygwin/cygtls.cc:99 #4 0x0022ff78 in ?? () #5 0x004330c2 in ?? () #6 0x00401015 in ?? () #7 0x7c81776f in RegisterWaitForInputIdle () from /cygdrive/c/windows/system32/kernel32.dll #8 0x in ?? () Can we have a gold star please. BTW: We have a nice GNU extension find postgresql -name index.html -o -name md5.sum -delete I checked the md5 sums. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: postgres initdb: error while loading shared libraries: ?
On Wed, Jan 9, 2013 at 5:05 PM, Ryan Johnson wrote: On 08/01/2013 11:43 PM, Ryan Johnson wrote: On 08/01/2013 9:20 PM, Yaakov (Cygwin/X) wrote: On Tue, 08 Jan 2013 20:44:10 -0800, Ryan Johnson wrote: The error message is: $ initdb -D /usr/share/postgresql/data /usr/sbin/initdb.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory Any ideas? I can't reproduce it on my own machine. Running cygcheck on /usr/sbin/initdb give very normal-looking results, and BLODA checks are coming up empty. Is there something obviously wrong in my instructions? Or should I have them send their cygcheck output and let folks on the list try to diagnose the problem? cygcheck output would be helpful, as always, but my wild guess is that they have the wrong, or more than one, libpq installed. If I'm right, reinstalling libpq5 should fix this. ! I just checked the cygcheck output again and found this: cygcheck: track_down: could not find cygldap-2-3-0.dll Not sure how I missed seeing that before... cygcheck on my machine says the .dll belongs to libopenldap2_3_0-2.3.43-3; acursory check of setup.ini didn't turn up an obvious dependency listing. Is there a chance the dependency didn't get pulled in automatically like it should have? It turns out the 2_4_2 openldap package got pulled in instead of 2_3_0, but pgsql wants the latter. I verified that my local install has the correct (older) package and not the newer one. Thoughts? I'm tired of postgresql. Anyone wants to take over? Should build OOTB, but my improvements to the antique build system and ntlm auth never made it in. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Rebuilding make
On Wed, Jan 9, 2013 at 7:02 AM, Fedin Pavel wrote: 1. doc/fdl.texi and doc/make-stds.texi files are missing from the archive. 2. configure seems to incorrectly determine HAVE_DOS_PATHS as true. This breaks $abspath() function. I solved (1) by adding these files from the original UNIX archive. Of course i can solve (2) by tweaking config/dospaths.m4, however perhaps i don't know something ? How do you build make ? Just FYI: i have tweaked dospaths.m4 and built a working make. After this i successfully patched it to use spawn(). For benchmarking i used 'all' then 'clean' targets on make's own source code. --- cut --- p.fedin@fedinw7x64 /usr/src/make-3.82.90-1 $ time make.old [skip] real0m45.759s user0m23.206s sys 0m19.410s p.fedin@fedinw7x64 /usr/src/make-3.82.90-1 $ time make.old clean [skip] real0m7.520s user0m2.767s sys 0m4.268s p.fedin@fedinw7x64 /usr/src/make-3.82.90-1 $ time make [skip] real0m31.869s user0m16.470s sys 0m14.061s p.fedin@fedinw7x64 /usr/src/make-3.82.90-1 $ time make clean [skip] real0m2.740s user0m0.748s sys 0m1.643s p.fedin@fedinw7x64 /usr/src/make-3.82.90-1 $ --- cut --- 'clean' target runs especially faster, you see the difference with a naked eye. I believe in case of gcc there's disk access factor. 0m45.759s+0m7.520s = 0m31.869s+0m2.740s Great! Can you gist the patches somewhere please? -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Updated: perl-DBI-1.623-1
On Tue, Jan 8, 2013 at 10:35 PM, Yaakov wrote: The following package has been updated in the Cygwin distribution: *** perl-DBI-1.623-1 The Perl Database Interface (DBI) provides a single API to access a wide variety of databases, support for which is provided by a DBD::* driver module (such as perl-DBD-mysql for MySQL servers). This is an update to the latest upstream release. Note: I strongly advise against the use of DBI-1.622 and 1.623 on public facing systems, because of https://rt.cpan.org/Ticket/Display.html?id=75614 This is the currently biggest known perl security problem, besides require strict.pm\0shellcode; and similar nul-char syscalls. Not that is likely that cygwin is used on public servers, but who knows... The patches are at also at https://github.com/rurban/distroprefs -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Strange and very annoying bug/problem with CPAN
On Sun, Dec 16, 2012 at 3:45 PM, pierre masci wrote: Hi all, CPAN does strange things here. I installed Cygwin 1.7.17 on WinXP a few days ago, and am using Perl 5.14.2. Often when i'm installing a module from CPAN, it stops near the start on an error, telling me that it Couldn't move $temporary_module_folder to $cpan_build_folder. I have put the complete copy-pasted error below this text that explains the problem. The very strange thing is that it only does it sometimes (too often), and it seems to be unpredictable : the same module will sometimes start installing, and sometimes just die on this error 20 times in a row; and then 10 minutes later it will work. It is extremely annoying : i start an install, stay for the first minute just in case this error happens, then start to do other work related tasks, and when i come back to it one of the dependencies has failed with this error. And keep on failing for 10 minutes, until suddenly it works. It takes me hours/days to install all the dependencies of a single module that i need. And i have to keep on checking every 5 minutes that the install hasn't been stopped. Or sometimes realize after an hour that it had stopped after only 2 minutes. If anybody has an idea, please help :-) Pierre aka mascip I also sometimes get this error, and it's an upstream CPAN error with the unpacking logic. https://rt.cpan.org//Dist/Display.html?Queue=CPAN doesn't list it, though I remember having it reported some time ago. Please file a new report there, Andy will remember maybe. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Request for upgrade to clamav package
On Sun, Dec 23, 2012 at 3:52 PM, Jonathan D Johnston wrote: Hello clamav maintainer, Often when I update my ClamAV database with freshclam (1), I get the following message: WARNING: Your ClamAV installation is OUTDATED! WARNING: Local version: 0.97.4 Recommended version: 0.97.6 Could the Cygwin clamav package be upgraded? Oops, I missed that. Thanks for the heads up. Will be uploaded shortly. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: clamav-0.97.6-1
I've updated clamav to the latest version 0.97.6 I've also added the 55K bytecode database file, but be sure to enable this option in /etc/freshclam.conf otherwise it will be deleted and will be downloaded again when you enable it there. If you enable the google safebrowsing database you will download 15M. Release Notes 0.97.6: A bug were CL_EFORMAT: Bad format or broken data ERROR was reported as the scan result was fixed. 0.97.5 (missed) This release addresses possible evasion cases in some archive formats (CVE-2012-1457, CVE-2012-1458, and CVE-2012-1459). It also addresses stability issues in portions of the bytecode engine. This release is recommended for all users. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Rebase/Perl packaging problem?
On Mon, Nov 26, 2012 at 5:21 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote: For me, this is only a problem because of the rebaseall error message. (In other words, it is merely a slight annoyance.) I've no idea whether this causes a problem for perl as I do not usually use perl (at least directly). c:\cygwin\bin dash -c rebaseall /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll: skipped because nonexistent. Yes, I know already. It will be fixed with the next update. But since 5.14.3 much is worse than 5.14.2 and all 5.16 releases are also not much better so far, I'll wait for the next good release upstream. The wrong symlink can be ignored, and you can delete it by yourself. There should be a symlink of /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14.dll to /usr/bin/cygperl5_14.dll only. /c ls -og /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll lrwxrwxrwx 1 26 2012-10-22 15:00:36 /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll - /usr/bin/cygperl5_14_2.dll /c ls -og /usr/bin/cygperl5_14_2.dll /bin/ls: cannot access /usr/bin/cygperl5_14_2.dll: No such file or directory Perhaps usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll is meant to point to /usr/bin/cygperl5_14.dll and not to /usr/bin/cygperl5_14_2.dll? -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: [mosh-devel] mosh 1.2.3 error when using on Cygwin
On Fri, Nov 9, 2012 at 4:10 PM, nyc4bos wrote: [My cygcheck.out was somehow not included, so I am resending] Reini Urban re...@cpanel.net writes: On 11/05/2012 06:47 PM, nyc4bos wrote: After starting up mosh on Cygwin and then attempting to type `ls', I see the following on my screen: $ ls select: No error mosh did not shut down cleanly. Please note that the mosh-server process may still be running on the server. [mosh is exiting.] 1 [main] mosh-client 4524 cygthread::detach: called detach but inuse 0, th read 0xF7C? Sometimes I am able to type a few commands but mostly it is only after one command before I see the select: No error message. The mosh-server.exe process is still running. I am on Windows XP and I am running a freshly installed Cygwin using Cygwin setup 1.7.17-1 (the latest) and mosh 1.2.3. Thanks. I am afraid, I could not get any insight into your problem. The cygcheck looks fine I would check for windows unusual hooks in your system, like antivirus checkers or bloda. It looks like you are using mosh-1.2.2-1 (the perl wrapper) and not the latest version. If so, please upgrade your mosh to latest which is mosh-1.2.3-1 If not, please send us a the output of cygcheck -s -v -r cygcheck.out as explained in http://cygwin.com/problems.html Owner@station03 ~ $ which mosh /usr/bin/mosh Owner@station03 ~ $ mosh --version mosh 1.2.3 Copyright 2012 Keith Winstein mosh-de...@mit.edu License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Thanks. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: [mosh-devel] mosh 1.2.3 error when using on Cygwin
On 11/05/2012 06:47 PM, nyc4...@aol.com wrote: After starting up mosh on Cygwin and then attempting to type `ls', I see the following on my screen: $ ls select: No error mosh did not shut down cleanly. Please note that the mosh-server process may still be running on the server. [mosh is exiting.] 1 [main] mosh-client 4524 cygthread::detach: called detach but inuse 0, th read 0xF7C? Sometimes I am able to type a few commands but mostly it is only after one command before I see the select: No error message. The mosh-server.exe process is still running. I am on Windows XP and I am running a freshly installed Cygwin using Cygwin setup 1.7.17-1 (the latest) and mosh 1.2.3. Thanks. It looks like you are using mosh-1.2.2-1 (the perl wrapper) and not the latest version. If so, please upgrade your mosh to latest which is mosh-1.2.3-1 If not, please send us a the output of cygcheck -s -v -r cygcheck.out as explained in http://cygwin.com/problems.html Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html -- Reini Working towards a true Modern Perl. Slim, functional, unbloated, compile-time optimizable -- 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: catdoc-0.94.2-4 [SECURITY]
I've updated the catdoc package, which dumps Word, Excel and Powerpoint files contents. http://pkgs.fedoraproject.org/cgit/catdoc.git/plain/catdoc-0.94.2-bufferoverflow-rh872390-rh872391.patch Thanks Yaakov -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: A cygwin mosh question
On Thu, Nov 1, 2012 at 8:14 PM, Eliot Moss wrote: On 11/1/2012 9:05 PM, Eliot Moss wrote: On 10/31/2012 1:46 PM, Eliot Moss wrote: After seeing the announcement on mosh, I decided to install it and try it out. I installed it on a remote server running Red Hat style Linux using yum, and on my laptop using cygwin. Sadly, I have run into some problems: 1) The cygwin install does not include the dependency on the IO:Tty package. I installed that manually, using cpan. Because I removed the perl wrapper, yes. 2) When I try to mosh to my remote server, all I ever get is Hangup. Since there does not seem to be any verbose mode, I am not sure how to diagnose this further. I installed the latest version today and was able to get things working. (It prints out more about issues connecting, which allowed me to resolve them.) - The remote end was not setting LANG for UTF-8. I had to do this by: mosh --server='mosh-server new -l LANG=en_US.UTF-8' - I discovered that mosh does not support an xterm escape sequence that I use, namely one to *read* the window icon label: CSI 20 t and also CSI 11 t (reports whether the window is iconified). My main purpose is to save and use the icon label as the base for setting a longer label or title I have worked around this by setting an extra environment variable when using mosh, and skipping the reading of the icon label in that case. However, all of this is not really cygwin-specific, so I'll stop there. The LANG issue needs to be reported upstream, yes. The special icon getter, hmm. You can try to add a patch upstream for this weird use-case. However, the failure to install the IO:Tty dependency may be relevant. Is there an easy way I can test that again? What would I uninstall and reinstall to check? That is, cpan will install things, but how would I *un*-install IO:Tty to check whether cygwin install of mosh loads it? Oh, I think I get it now, after digging further into what the install of mosh actually does: the newer versions do not use perl, but work directly -- is that right? If so, then the lack of dependence is correct, and I apologize for the extra chatter! Yes. Perl caused problems in forks using IO::Pty and reading from STDIN. This was explained in the announcement of the experimental mosh-1.2.2-2 package. http://sourceware.org/ml/cygwin-announce/2012-07/msg00021.html -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: A problem with perl and cygpixman-1-0.dll
On Wed, Oct 31, 2012 at 5:00 PM, marco atzeri wrote: On 10/31/2012 10:24 PM, Zdzislaw Meglicki wrote: funny, I build it but forgot and never installed. At least you can remove the third one. Err... which is the third one? Let me list the three here and you tell me which can be removed: to know if a file belongs to any package, use: cygcheck -f name_with_path $ cygcheck -f /usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int/auto/Graphics/Magick/Magick.dll perl-Graphics-Magick-1.3.16-1 $ pwd /usr/lib/perl5 $ find . -name Magick.dll -print ./site_perl/5.14/i686-cygwin-threads-64int/auto/Image/Magick/Magick.dll ./vendor_perl/5.14/i686-cygwin-threads-64int/auto/Graphics/Magick/Magick.dll ./vendor_perl/5.14/i686-cygwin-threads-64int/auto/Image/Magick/Magick.dll $ Is the one in site_perl superfluous or the ones in vendor_perl? Will perl scripts automatically switch to the one left? I guess so No. You cannot just delete an shared perl library. If you delete ./site_perl/5.14/i686-cygwin-threads-64int/auto/Image/Magick/Magick.dll you also need to delete the according pm's, which are listed in the .packlist. Perl searches the @INC path for libraries. site_perl comes before vendor_perl. So if you delete ./site_perl/5.14/i686-cygwin-threads-64int/auto/Image/Magick/Magick.dll alone, your Image::Magic will be broken until you reinstall it via CPAN or delete totally via .packlist. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Problem with HTTPS in LWP module in Perl
On Thu, Nov 1, 2012 at 1:05 PM, Björn Kautler wrote: I'm having a problem with https requests to https://www.geocaching.com; in perl. Nothing was done at all, then I found out I need to install LWP::Protocol:https which I did with cpan LWP::Protocol:https. Now according to Wireshark at least SSL communication is started. But after the Client Hello it just hangs until a timeout happens, waiting for the Server Hello. With other HTTPS pages like https://www.google.com; it works fine. The exact same Perl script works fine under Ubuntu. The https request to the same page works fine with curl under cygwin. If I change the SSL socket class to Net::SSL instead of IO::Socket::SSL, it also hangs after the Client Hello, but then retries with SSLv3 instead of TLSv1 according to Wireshark and this at least works a bit better though not completely. So I guess something is weird in the Cygwin port of IO::Socket::SSL. :-/ Probably, but I cannot reproduce it. If it is, you need to file a rt.cpan.org ticket for this, with some wireshark loggings and the exact request. $ lwp-request https://www.geocaching.com/ 501 Protocol scheme 'https' is not supported (LWP::Protocol::https not installed) $ cpan LWP::Protocol::https ... (built and installed SULLR/IO-Socket-SSL-1.77.tar.gz, GAAS/LWP-Protocol-https-6.03.tar.gz) /usr/bin/make install -- OK $ lwp-request -USed https://www.geocaching.com/ GET https://www.geocaching.com/ User-Agent: lwp-request/6.03 libwww-perl/6.04 500 Can't connect to www.geocaching.com:443 Content-Type: text/plain Client-Date: Thu, 01 Nov 2012 18:21:07 GMT Client-Warning: Internal response From debian: $ lwp-request -USed https://www.geocaching.com/ GET https://www.geocaching.com/ User-Agent: lwp-request/5.834 libwww-perl/6.04 GET https://www.geocaching.com/ -- 500 Can't connect to www.geocaching.com:443 Content-Type: text/plain Client-Date: Thu, 01 Nov 2012 18:18:49 GMT Client-Warning: Internal response $ lwp-request -USed https://www.google.com/ - 200 OK -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Problem with HTTPS in LWP module in Perl
On Thu, Nov 1, 2012 at 1:22 PM, Reini Urban wrote: On Thu, Nov 1, 2012 at 1:05 PM, Björn Kautler wrote: I'm having a problem with https requests to https://www.geocaching.com; in perl. Nothing was done at all, then I found out I need to install LWP::Protocol:https which I did with cpan LWP::Protocol:https. Now according to Wireshark at least SSL communication is started. But after the Client Hello it just hangs until a timeout happens, waiting for the Server Hello. With other HTTPS pages like https://www.google.com; it works fine. The exact same Perl script works fine under Ubuntu. The https request to the same page works fine with curl under cygwin. If I change the SSL socket class to Net::SSL instead of IO::Socket::SSL, it also hangs after the Client Hello, but then retries with SSLv3 instead of TLSv1 according to Wireshark and this at least works a bit better though not completely. So I guess something is weird in the Cygwin port of IO::Socket::SSL. :-/ Probably, but I cannot reproduce it. If it is, you need to file a rt.cpan.org ticket for this, with some wireshark loggings and the exact request. $ lwp-request https://www.geocaching.com/ 501 Protocol scheme 'https' is not supported (LWP::Protocol::https not installed) $ cpan LWP::Protocol::https ... (built and installed SULLR/IO-Socket-SSL-1.77.tar.gz, GAAS/LWP-Protocol-https-6.03.tar.gz) /usr/bin/make install -- OK $ lwp-request -USed https://www.geocaching.com/ GET https://www.geocaching.com/ User-Agent: lwp-request/6.03 libwww-perl/6.04 500 Can't connect to www.geocaching.com:443 Content-Type: text/plain Client-Date: Thu, 01 Nov 2012 18:21:07 GMT Client-Warning: Internal response From debian: $ lwp-request -USed https://www.geocaching.com/ GET https://www.geocaching.com/ User-Agent: lwp-request/5.834 libwww-perl/6.04 GET https://www.geocaching.com/ -- 500 Can't connect to www.geocaching.com:443 Content-Type: text/plain Client-Date: Thu, 01 Nov 2012 18:18:49 GMT Client-Warning: Internal response $ lwp-request -USed https://www.google.com/ - 200 OK I got a bit more information from some other version: $ perl5.14.3 -S lwp-request -USed https://www.geocaching.com/ GET https://www.geocaching.com/ User-Agent: lwp-request/5.834 libwww-perl/6.04 GET https://www.geocaching.com/ -- 500 Can't connect to www.geocaching.com:443 (Crypt-SSLeay can't verify hostnames) Content-Type: text/plain Client-Date: Thu, 01 Nov 2012 18:22:57 GMT Client-Warning: Internal response So I think it's on the application level, not the library. This is with Crypt::SSLeay 0.64. My Cygwin has 0.60, and debian had 0.58. See http://stackoverflow.com/questions/12116244/https-proxy-and-lwpuseragent how to utilize PERL_LWP_SSL_VERIFY_HOSTNAME=0 -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: mosh-1.2.3-1
I updated mosh to 1.2.3-1 on cygwin, which includes the previously experimental cxxwrapper for /usr/bin/mosh.exe as described in http://sourceware.org/ml/cygwin-announce/2012-07/msg00021.html This maintenance release makes a number of improvements to mosh 1.2.2 to improve speed, robustness, and security. It includes new implementations of AES and OCB that are more resilient to possible timing leakage and adds support for Solaris, licensing compatibility with Apple's iOS, and power-saving improvements to benefit the Android client. * Missing features: * --predict=experimental mode to local echo not yet implemented * Detect bogus MOSH_IP earlier is not yet implemented. * Security improvements: * Use OpenSSL AES implementation * Update AES-OCB implementation (Keegan McAllister) * Don't let bad server dictate IP (Felix Groebert) * New features: * Client hops ports to survive challenging client-side firewall * Server stops sending to save client power (Daniel Drown) * Set DiffServ code point and ECN-capable (Dave Täht) * Slow down if explicit congestion notification received * Warn about unattached Mosh sessions on login * Compatible with KDE konsole (uses BEL to terminate OSC) * Improved heuristic about color of predicted characters * Bug fixes: * Improved performance on systems with expensive time * No longer choke on :: address for hosts with IPv6 * More conservative MTU and datagram sizing * Platform support: * Build on Solaris and IllumOS (Timo Sirainen, Ira Cooper) * Build on ARM with gcc 4.7 (Alexander Chernyakhovsky) * Licensing changes: * Allow distribution on Apple App Stores * Allow linking with OpenSSL mosh 1.2.3 is backwards-compatible with mosh clients back to 0.96 and mosh servers back to 1.0.9. Please let us know of any problems (https://github.com/keithw/mosh/issues). Best regards from the Mosh team, -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: A problem with perl and cygpixman-1-0.dll
On Wed, Oct 31, 2012 at 1:56 PM, Zdzislaw Meglicki wrote: ./vendor_perl/5.14/i686-cygwin-threads- 64int/auto/Image/Magick/Magick.dll the other two are probably coming from your build, are the same or installed in different times ? I have by now overwritten my own installation with the vanilla Cygwin perl-Image-Magick and perl-Graphics-Magick. Good. There should not be any non-Cygwin stuff there. They both use the above Magick.dll, don't they? No, they are totally different. They just have the same basename, by accident. All three versions of Magick.dll are different. The other two, the ones that live in vendor_perl have dates July 26 and April 28. I have not been doing anything with them at the time, so these must be some earlier versions installed by Cygwin itself. I am surprised perl reinstall, which I did recently, did not get rid of them. If you are not using any perl site_lib dlls, rebaseall is enough. If you are using perl site_lib dlls, you need to do perlrebase also. In your case you did not have perl-Image-Magick installed, you installed it seperately via CPAN into site_lib. This might create conflicts, if they are from different versions. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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
Updated: mosh-1.2.3-1
I updated mosh to 1.2.3-1 on cygwin, which includes the previously experimental cxxwrapper for /usr/bin/mosh.exe as described in http://sourceware.org/ml/cygwin-announce/2012-07/msg00021.html This maintenance release makes a number of improvements to mosh 1.2.2 to improve speed, robustness, and security. It includes new implementations of AES and OCB that are more resilient to possible timing leakage and adds support for Solaris, licensing compatibility with Apple's iOS, and power-saving improvements to benefit the Android client. * Missing features: * --predict=experimental mode to local echo not yet implemented * Detect bogus MOSH_IP earlier is not yet implemented. * Security improvements: * Use OpenSSL AES implementation * Update AES-OCB implementation (Keegan McAllister) * Don't let bad server dictate IP (Felix Groebert) * New features: * Client hops ports to survive challenging client-side firewall * Server stops sending to save client power (Daniel Drown) * Set DiffServ code point and ECN-capable (Dave Täht) * Slow down if explicit congestion notification received * Warn about unattached Mosh sessions on login * Compatible with KDE konsole (uses BEL to terminate OSC) * Improved heuristic about color of predicted characters * Bug fixes: * Improved performance on systems with expensive time * No longer choke on :: address for hosts with IPv6 * More conservative MTU and datagram sizing * Platform support: * Build on Solaris and IllumOS (Timo Sirainen, Ira Cooper) * Build on ARM with gcc 4.7 (Alexander Chernyakhovsky) * Licensing changes: * Allow distribution on Apple App Stores * Allow linking with OpenSSL mosh 1.2.3 is backwards-compatible with mosh clients back to 0.96 and mosh servers back to 1.0.9. Please let us know of any problems (https://github.com/keithw/mosh/issues). Best regards from the Mosh team, -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: ITP: phplint -- Lint tool for PHP code (VOTE)
On Oct 9, 2012, at 6:19 AM, Jari Aalto wrote: Notes Not yet included in any distributions, so needs votes. +1
Re: ITP: xlsx2csv -- Convert xslx xml files to csv format
On Oct 23, 2012, at 5:14 PM, Chris Sutcliffe wrote: On 13 October 2012 15:59, Jari Aalto wrote: Notes Not yet included in any distributions, so needs votes. +1 Chris +1 Reini
Re: peflags makes perl not print to stdout
On 09/27/2012 09:14 AM, Saurabh T wrote: Hi, I asked this before and havent gotten a reply. Is there any other information I can provide? This is currently quite a bummer for me. Any help will be greatly appreciated. Thanks. From: saurabh To: cygwin Subject: peflags makes perl not print to stdout Date: Mon, 24 Sep 2012 17:29:42 + I have been trying to get perl to use 2GB of memory (this is on a 32 bit xp machine with 4 GB total memory). As per http://cygwin.com/cygwin-ug-net/setup-maxmem.html I tried peflags --cygwin-heap=2048 /usr/bin/perl However this causes perl to not write to screen. On further investigation, I found the magic number to be 1040: $ peflags --cygwin-heap=1039 /usr/bin/perl /usr/bin/perl: initial Cygwin heap size: 1039 (0x40f) MB $ perl -e 'print Hello\n;' Hello $ peflags --cygwin-heap=1040 /usr/bin/perl /usr/bin/perl: initial Cygwin heap size: 1040 (0x410) MB $ perl -e 'print Hello\n;' In other words, anything 1040 and above, perl stops writing to screen. I have the latest cygwin (1.7.16) and perl (5.14.2). Any idea what might be wrong? Thank you. Yes, strange. I'm not aware of any heap magic or IO limits within perl. (contrary to clisp or other binaries using a copying gc). It's pure malloc, and it memory and io is purely dynamic. If cgf has no idea either you need to ask that on p5p. -- 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: [RFE][PATCH] cygport: allow for subdirectory specification via CPAN_AUTHOR
On 09/26/2012 06:51 AM, Achim Gratz wrote:
Hi Yaakov,
several Perl distributions have chosen to put the actual archives in a
subdirectory (e.g. Inline::Files). So far I've dealt with those by editing
SRC_URI after inherit perl, but I'd like something more straigtforward. I
propose that CPAN_AUTHOR should optionally include this additional subdirectory
as a /subdir suffix. Patch to that effect:
Just for easier understanding:
How would that look like for e.g.
A/AM/AMBS/Inline/Inline-Files-0.68.tar.gz
NAME=Inline-Files
inherit perl
CPAN_AUTHOR=AMBS/Inline
Looks a bit weird. Don't we have a better field for this cpan quirks?
Like a new CPAN_DIR which defaults to CPAN_AUTHOR?
Support subdirectories in CPAN download URL
* cygclass/perl.cygclass: Allow CPAN_AUTHOR to have a /subdir suffix.
This is necessary for some modules that put the distribution files
in some subdirectory. Only upcase the actual author name (up until
the first /) and preserve case for the suffix part.
Modified cygclass/perl.cygclass
diff --git a/cygclass/perl.cygclass b/cygclass/perl.cygclass
index b4aecdf..4dbe824 100644
--- a/cygclass/perl.cygclass
+++ b/cygclass/perl.cygclass
@@ -139,9 +139,12 @@ HOMEPAGE=http://search.cpan.org/dist/${ORIG_PN}/;
# SEE ALSO
# mirror_cpan
#
-cpan_author_ftp=${CPAN_AUTHOR^^}
-SRC_URI=mirror://cpan/authors/id/${cpan_author_ftp:0:1}
/${cpan_author_ftp:0:2}/${cpan_author_ftp}
/${ORIG_PN}-${PV}.${CPAN_TARBALL_SUFFIX:-tar.gz}
+cpan_author_ftp=${CPAN_AUTHOR%%/*}
+cpan_module_ftp=${CPAN_AUTHOR#${cpan_author_ftp}}
+cpan_author_ftp=${cpan_author_ftp^^}
+SRC_URI=mirror://cpan/authors/id/${cpan_author_ftp:0:1}
/${cpan_author_ftp:0:2}/${cpan_author_ftp}$cpan_module_ftp
/${ORIG_PN}-${PV}.${CPAN_TARBALL_SUFFIX:-tar.gz}
unset cpan_author_ftp
+unset cpan_module_ftp
fi# defined CPAN_AUTHOR
(Watch for the linewrap)
Regards,
Achim
--
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
--
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: perl-5.14.2-3 installs broken symlinks
On Thu, Sep 27, 2012 at 5:26 AM, Steven Hartland wrote: The following are dangling symlinks after a clean cygwin install updated today. /lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll $ cygcheck -p cygperl5_14_2.dll Found 1 matches for cygperl5_14_2.dll perl/perl-5.14.2-3 Larry Wall's Practical Extracting and Report Language Yes, I already know since every rebase prints this warning. It's just a packaging artefact, does no harm and will be fixed in the next update. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: perl_vendor
On Thu, Aug 30, 2012 at 11:28 AM, Achim Gratz wrote: Reini Urban writes: What's the problem? Lack of upates for these? My problem is that I need quite a bunch of additional Perl distributions, I need to package them into Cygwin packages since they will need to be installed with setup.exe and the way things are bundled in perl_vendor makes dependency tracking more difficult. Which one? I have no idea. When you start proposing your stuff I can remove these packages from perl_vendor. But I still don't get the point. Now you have one dependency: perl_vendor. With your scheme you have many dependencies. I already have a solution, I simply don't use perl_vendor and re-package everything I need from it (essentially all of it, so the selection is quite sound). That's what I linked to, I wasn't proposing that everything in this bundle should go into Cygwin. I won't bring this up again, I think everybody has said what they wanted to say. You need to bring this up when you ITP them. Because clashes are disallowed. You cannot provide the same files with different packages. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: perl: inconsistent archname in build config?
On Fri, Sep 7, 2012 at 8:30 PM, bert Dvornik wrote: Summary: Cygwin's perl 5.14 uses cygwin-thread-multi-64int as the archname for user module directories (i.e. those based on PERL5LIB), but i686-cygwin-threads-64int as the archname for system module directories and for installing files via cpan. This seems to be based on the build configuration (there are two settings in different places). It doesn't make sense to me, though maybe I'm missing something. Long version: I ran into a problem with local module paths after updating to perl-5.14.2-3. I usually install Perl modules locally into ~/perl-lib/ by setting the prefix via CPAN's makepl_arg and mbuildpl_arg configuration options. Then I can set my PERL5LIB to get that installation tree automatically used by perl. This worked fine up to and including perl 5.10. But with 5.14 something strange started happening. If I look at the @INC in the perl -V output, I see this: Summary of my perl5 (revision 5 version 14 subversion 2) configuration: [...lots of verbiage removed; see below for full output...] %ENV: PERL5LIB=/home/bert/perl-lib/lib/perl5:/home/bert/perl-lib/lib/perl5/site_perl/5.14:/home/bert/perl-lib/lib/perl5/5.14 @INC: /home/bert/perl-lib/lib/perl5/cygwin-thread-multi-64int /home/bert/perl-lib/lib/perl5 /home/bert/perl-lib/lib/perl5/site_perl/5.14/cygwin-thread-multi-64int /home/bert/perl-lib/lib/perl5/site_perl/5.14 /home/bert/perl-lib/lib/perl5/5.14/cygwin-thread-multi-64int /home/bert/perl-lib/lib/perl5/5.14 /usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int /usr/lib/perl5/site_perl/5.14 /usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int /usr/lib/perl5/vendor_perl/5.14 /usr/lib/perl5/5.14/i686-cygwin-threads-64int /usr/lib/perl5/5.14 /usr/lib/perl5/site_perl/5.10 /usr/lib/perl5/vendor_perl/5.10 /usr/lib/perl5/site_perl/5.8 . There are two odd things about this. First, the @INC directories from PERL5LIB use cygwin-thread-multi-64int, but the system ones use i686-cygwin-threads-64int. Second, when CPAN installs packages, they go into i686-cygwin-threads-64int, which is why the ones in my perl-lib directory are not being found in @INC. Looking more closely at the output of perl -V, I can see what's probably causing the confusion: Summary of my perl5 (revision 5 version 14 subversion 2) configuration: Platform: osname=cygwin, osvers=1.7.15(0.26053), archname=cygwin-thread-multi-64int uname='cygwin_nt-5.1 winxp 1.7.15(0.26053) 2012-05-09 10:25 i686 cygwin ' config_args='-de -Dlibperl=cygperl5_14.dll -Dcc=gcc-4 -Dld=g++-4 -Darchname=i686-cygwin-threads-64int -Dmksymlinks -Dusethreads -Accflags=-g' So the platform settings have archname=cygwin-thread-multi-64int, but config_args include -Darchname=i686-cygwin-threads-64int. (Is config_args the arg list passed to the sh Configure when building perl? If so, shouldn't -Darchname ACTUALLY set the archname? Or is there some other weirdness going on here?) Very interesting catch, thank you! I will need to think a bit how to fix this, not to break too much. Or if it needs t be fixed at all. EU::MM seems to work okay, just MB and local::lib seems to be affected. Yes, config_args is the cmdline, but archname is overridden elsewhere in the old Configure system, most likely the hints. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: perl man pages not working.
On Tue, Sep 4, 2012 at 8:11 PM, Larry Hall (Cygwin) wrote: On 9/4/2012 4:07 PM, Erwin Waterlander wrote: I have installed the perl man pages via setup.exe, but they don't work: $ man perl No manual entry for perl It seems they are not there, while setup.exe says I have installed perl_manpages version 5.14.2-3. $ ls /usr/share/man/*/perl* ls: cannot access /usr/share/man/*/perl*: No such file or directory Also a reinstall via setup.exe does not help. The man pages are there. See the list of those installed here: http://cygwin.com/cgi-bin2/package-cat.cgi?file=perl_manpages%2Fperl_manpages-5.14.2-3grep=perl_manpages But it does look like there are some key ones missing in 5.14.2 (such as perl.1). Oops, blush. Thanks for the report -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: perl_vendor
On Sat, Aug 4, 2012 at 10:18 AM, Achim Gratz wrote: [Summary of previous discussion] I think that each perl module distribution should have its own Cygwin package. Since our perl installation at work needs quite a few more distributions, I created the missing cygport files while the switch to 5.14 was pending. To ease installation I also made a bundle package that does nothing but list all those individual packages as dependencies so they can be installed together by selecting a single package. I am aware that splitting perl_vendor up into individual packages would require great effort and I fully understand that you don't want to shoulder that alone. As a transitory measure with much less impact, the distributions inside perl_vendor could each get empty packages that depend on perl_vendor (sort of the reverse of what I've been doing with my umbrella package), which would at least make it more explicit what is available even though the install (and update) still happens en bloc. If you like this idea better, I should be able to provide corresponding Cygwin packages (or just the definitions, whatever your preference) in about two weeks. You can have all packages in vendor, but I doubt that they are all needed and that it is useful. The reasoning for having them together was to support self-installation via CPAN and reporting tests results automatically in case of errors, not to bother the list with such minor issues. Splitting them up will break this idea. People will complain how to install perl packages and upstream maintainers will complain about missing cygwin feedback. There are only some package with are not needed for CPAN and CPAN::Reporter, which others found useful to have as default. DBI should be added also IMHO, esp. since using the default DBI from CPAN is still a security risk for three quarters of a year now. What's the problem? Lack of upates for these? Updates via cpan are easier than updates via setup.exe Moving a distribution out from perl_vendor into its own package later on (LWP springs to mind, which is about the only distribution that I update with some regularity) would require a coordinated release of two packages, but that seems manageable. As for taking over maintainership of all (or the majority) of these perl distribution packages: I am open to the idea in general, but would want to have a co-maintainer in the beginning and I would need access to a build host at least for the XS modules. The cygport definitions I have in hand certainly need some more work before they would be good for general release, but so far I've got zero feedback on them. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: Perl 5.14 and XML::Parser
On Thu, Aug 16, 2012 at 6:55 AM, Christopher Faylor wrote: On Wed, Aug 15, 2012 at 10:04:48PM -0600, Thomas Wicklund wrote: The update of perl on to 5.14 moved some perl modules to a new perl_vendor package which is not installed by default. The announcement I found stated that perl_vendor is modules which are mainly required to build and test and report test results of other CPAN modules. That was the short summary, yes. I find that the XML::Parser module (at least) has been moved. I've been using this module for years to parse XML output for a set of Subversion tools. I had a couple hours of digging today to figure out why a coworker started getting errors after updating Cygwin, then figuring out the new package. As an request from Yaakov and also from upstream p5p I have moved all non-core packages to the new perl_vendor. As an occasional user of perl I would much prefer that the maximum number of packages be included in the distribution (since disk space and bandwidth are constantly becoming cheaper) than to have to spend time figuring out why something can't be found. This is right. I really sympathize with you and all others. But unfortunately I had to made this move for political reasons, not technical ones. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Perl 5.14.2 seems to expect gcc-4
On Wed, Aug 1, 2012 at 5:14 PM, Aaron Schneider wrote: On 01/08/2012 19:46, Reini Urban wrote: On Wed, Aug 1, 2012 at 10:46 AM, Matt Seitz (matseitz) wrote: Did Cygwin setup.exe prompt you to install the gcc-4 package when you updated perl? I thought setup.exe would prompt the user if any additional packages needed to be installed. no. gcc-4, make and more are not automatically installed with perl. you will only need when you compile your own XS packages with cpan. XML::LibXML is included in the new package perl_vendor Since a lot of people are having issues because 'perl_vendor' is not installed when should, wouldn't be better to set perl_vendor as a mandatory dependency of perl so just everyone gets it installed? I guess package size won't be an issue. Sure. But Yakoov explicitly wanted a perl independent from perl_vendor. Yakoov? -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Perl 5.14.2 seems to expect gcc-4
On Thu, Aug 2, 2012 at 1:08 PM, Achim Gratz wrote: Aaron Schneider writes: Since a lot of people are having issues because 'perl_vendor' is not installed when should, wouldn't be better to set perl_vendor as a mandatory dependency of perl so just everyone gets it installed? I guess package size won't be an issue. No, please don't — I have compiled my own perl packages and need perl_vendor to stay out of the way. If anything this would be a hint that hiding packages in perl_vendor, while helping to keep the number of packages down, doesn't help people finding what they need. Please don't spread fud. Self-compiled cpan packages are always favored over vendor packages. See your @INC. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Perl 5.14.2 seems to expect gcc-4
On Thu, Aug 2, 2012 at 2:46 PM, Achim Gratz wrote: Reini Urban writes: Please don't spread fud. Self-compiled cpan packages are always favored over vendor packages. See your @INC. I really meant packages, of the Cygwin variant (I've got cygport definitions for all of them and posted a link to them over in cygwin-apps). Managing dependencies with an opaque blob like perl_vendor seemed more trouble than creating some 240 or so packages that include all that are in perl_vendor, but one package for each distribution (and an umbrella package for installing them all in one go). I would be happy to assign it over to you if you are happy with it. I have no time to maintain hundreds of packages which change monthly. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Perl 5.14.2 seems to expect gcc-4
On Wed, Aug 1, 2012 at 10:46 AM, Matt Seitz (matseitz) wrote: On Wed, Aug 1, 2012 at 11:12 AM, Nikolai Weibull wrote: Cygwin updated perl to 5.14.2 on my system and now I can’t compile XML::LibXML. It seems that c:\lib\perl5\5.14\i686-cygwin-threads-64int\Config.pm expects cc to be gcc-4. Gcc-4 doesn’t exist yet, it seems. What’s going on here? Sorry, scratch that, gcc-4 is available. I got confused by the separate version schemes (which I realize are necessary, but easy to miss when you’re a bit stressed out.) Did Cygwin setup.exe prompt you to install the gcc-4 package when you updated perl? I thought setup.exe would prompt the user if any additional packages needed to be installed. no. gcc-4, make and more are not automatically installed with perl. you will only need when you compile your own XS packages with cpan. XML::LibXML is included in the new package perl_vendor -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: sshd crashing
On Mon, Jul 30, 2012 at 5:50 PM, Pawel Jasinski wrote: checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/usr/src/openssh-6.0p1-2/build': configure: error: C compiler cannot create executables See `config.log' for more details *** ERROR: configure failed If I look at config,log the things look funny around gcc invocation, but I am kind of novice to cygport and can not figure out what's going on: gcc -ggdb -O2 -pipe -fdebug-prefix-map=/usr/src/openssh-6.0p1-2/build=/usr/src/debug/openssh-6.0p1-2 -fdebug-prefix-ma p=/usr/src/openssh-6.0p1-2/src/openssh-6.0p1=/usr/src/debug/openssh-6.0p1-2 conftest.c 5 cc1: error: unrecognized command line option -fdebug-prefix-map=/usr/src/openssh-6.0p1-2/build=/usr/src/debug/openssh-6.0p1-2 cc1: error: unrecognized command line option -fdebug-prefix-map=/usr/src/openssh-6.0p1-2/src/openssh-6.0p1=/usr/src/debug/openssh-6.0 What am I missing? You are using gcc (version 3) and not gcc4. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Rebase: still struggling with it
On Tue, Jul 31, 2012 at 4:44 AM, Charles Smith wrote: $ /bin/rebaseall /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll: skipped because nonexistent. And this is caused by a minor perl packaging problem. You can simply ignore this warning. I'll fix it with the next perl update. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: install package from cpan report address space needed by ... is already occupied
On Fri, Jul 27, 2012 at 5:20 AM, Aaron Schneider wrote: On 25/07/2012 3:13, ping wrote: I'm trying to install App::Asciio in cygwin, but got following error, please advice, or what info are still needed to proceed, thanks! CPAN: Module::Build loaded ok (v0.3613) CPAN.pm: Going to build N/NK/NKH/App-Asciio-1.02.71.tar.gz 0 [main] perl 6432 child_info_fork::abort: address space needed by 'Base64.dll' (0xC6) is already occupied 1 [main] perl 3844 child_info_fork::abort: unable to remap Util.dll to same address as parent (009A) - try running rebaseall 0 [main] perl 10708 child_info_fork::abort: address space needed by 'Base64.dll' (0xC6) is already occupied 0 [main] perl 11276 child_info_fork::abort: unable to remap Util.dll to same address as parent (009A) - try running rebaseall 0 [main] perl 1976 child_info_fork::abort: address space needed by 'Base64.dll' (0xC6) is already occupied Could you rename your c:\cygwin folder to c:\cygwin_bak and try a fresh install and see if happens the same? Are you installing cpan modules from binaries or compiling them with 'perl Build.PL'? - There should be no need to rebase any dll, try installing all cpan modules from source code (the tar.gz). Install only perl from cygwin's setup.exe. If there are any compilation issues with any cpan module you will see it right away. All modules should compile and pass all t tests. You will need to install dependencies like gcc, gcc4, libbz2-devel, pkg-config and probably more from setup.exe. - Remember to keep closed all terminals and cygwin sessions when running setup.exe - I wasn't able to compile a lot of cpan modules under cygwin, for example P/PD/PDENIS/Test-Strict-0.14.tar.gz with either perl 5.10 or perl 5.14. This is not the case for Ubuntu, for example, at least trying to install all cpan dependencies for App-Asciio-1.02.71. This part is a problem of a wrong test in Test-Strict-0.14/t/01all.t. It falsely assumes cygwin is MSWin32 because Win32 is loadable and then tries to convert paths by Win32::GetLongPathName(). Expand the attached two files into .cpan/ to apply my patch automatically on your next cpan attempt. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ Test-Strict-0.14.tar.gz Description: GNU Zip compressed 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
Re: sshd crashing
On Fri, Jul 27, 2012 at 4:44 PM, Pawel Jasinski wrote: I have a fresh installation of cygwin on xp and win7 (both run 1.17.16-1). I have run ssh-host-config followed by rebaseall. The CYGWIN variable for sshd is not set. I have tried with and without priv. separation. It is started with cygrunsrv -S sshd I can connect with ssh localhost. Things are ok until I do vi /etc/profile. At this moment it crashes. Now if I try the version without priv separation to start by hand: /usr/sbin/sshd -D -d -e things go well and it does not crashes when in ssh session /etc/profile is edited. Am I missing something in config? Inspect /var/log/sshd.log for obvious rebase errors and run rebaseall then. I fixed the same problem this way. sshd: PID 484: service `sshd' failed: signal 11 raised -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Maxima can't write to /dev/stdout
On Thu, Jul 26, 2012 at 12:57 PM, Achim Gratz wrote: Corinna Vinschen writes: If you can nail that down to the actual calls and decisions clisp is doing, it might help to find the cause. I'm trying to, but it seems I still miss some dependencies to actually build clisp with debug information. Unfortunately the build is structured in a way that it tells you each missing dependency piecemeal after an ever increasing amount of stuff that it actually succeeded building. Right now it seems that it specifically wants BDB 4.5 rather than 4.8 even though configure said earlier it found BDB... I'll get there eventually, just not as fast as I had hoped for. Agreed. But note that clisp already should come with debug info. -g is required for the (disassemble) function to work. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Maxima can't write to /dev/stdout
On Thu, Jul 26, 2012 at 2:10 PM, Achim Gratz wrote:
Reini Urban writes:
But note that clisp already should come with debug info.
Where to look for it? I'm assuming that I need to step into the open
function from the lisp open call via gdb to see where the trailing
/1 gets stripped of from the file name pointed to by the symlink, so
I'd need to have at least a symbol file with that entry point.
Don't know yet. I'm still busy at work.
-g is required for the (disassemble) function to work.
You mean in CFLAGS for the build?
Yes, and
src_install() {
# do not strip for (disassemble)
_CYGPORT_RESTRICT_strip_=1
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/
--
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: No DBI module when installing Perl 5.14
On Mon, Jul 23, 2012 at 9:32 AM, Andrew DeFaria wrote: I recently updated my Cygwin to 1.7.16. With this came Perl 5.14.2. While the update when fine, after updating I restarted a service that I wrote in Perl that used DBI. To my surprise it failed saying it couldn't find the DBI module. I used cpan to reinstall it but I was wondering if it was intentional that DBI would be missing after upgrading to 5.14.2. DBI also did not come with perl-5.10, you installed it by yourself. Check my update recipe from the announcement mail: http://cygwin.com/ml/cygwin-announce/2012-07/msg00011.html Update recommendations from 5.10: -- Since 5.14 is not installed in parallel to 5.10, all your old 5.10 binary XS modules will need to be reinstalled for 5.14. BEFORE INSTALLATION of this 5.14 # get the list of your installed 5.10 modules $ perl -MExtUtils::Installed \ -e'print join(\n, new ExtUtils::Installed-modules)' module.list AFTER INSTALLATION of 5.14 # install all previous modules for 5.10 and older $ cpan `cat module.list` PS: doing the cpanm dance with xargs is not recommended as it forks too much. $ perl -MExtUtils::Installed \ -e'print join(\n, new ExtUtils::Installed-modules)' | xargs cpan -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Irssi returns error message after Perl update
On Mon, Jul 23, 2012 at 11:14 AM, Sean Murphy wrote: On Mon, Jul 23, 2012 at 12:30 AM, Reini Urban wrote: You have three possibilities. Install perl 5.10 from the tarball in parallel as explained in the 5.14 announcement, or bug the irssi maintainer to update irssi, or go back to perl 5.10 After spending some time with this over the rest of the weekend, I came to the same conclusions. I don't want to be a pain, so I think I'll let the irssi maintainer get to it at their own pace. I will, however, attempt to install 5.10 in parallel as you suggest. I'd rather have the updated version of perl, as I've just installed mosh, and mosh will not operate with the older perl package. Then you can also try the experimental mosh-1.2.2-2 which is a 1.3 pre-release and does not use perl anymore: http://cygwin.com/ml/cygwin-announce/2012-07/msg00021.html -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: Irssi returns error message after Perl update
On Sat, Jul 21, 2012 at 2:47 PM, Sean Murphy wrote: After recently updating Perl to the most recent version (5.14.2-3), I've noticed that Irssi (0.8.15-2) will return the following error message: /usr/bin/irssi.exe: error while loading shared libraries: cygperl5_10.dll: cannot open shared object file: No such file or directory You have three possibilities. Install perl 5.10 from the tarball in parallel as explained in the 5.14 announcement, or bug the irssi maintainer to update irssi, or go back to perl 5.10 -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: length in gawk returns wrong value
On Thu, Jul 19, 2012 at 12:02 PM, Eric Blake wrote: On 07/19/2012 10:53 AM, Aaron Schneider wrote: I can't find such csh or cshell on my system, I've searched from packages and I only see scsh, slsh, posh, mosh, tcsh, zsh, mksh that I Both scsh and tcsh are from the csh family of shells. posh, zsh, mksh, bash, dash, and ksh are from the Bourne family of shells No idea what slsh or mosh are No login shells. mosh is a a remote shell, a better ssh for slow or varying connections. http://mosh.mit.edu/ slsh is the S-Lang shell. A different beast. http://www.jedsoft.org/slang/doc/html/slang-2.html#ss2.1 -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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: mosh-1.2.2-2 (experimental)
For those who have problems with mosh to connect from cygwin to hosts which require ssh client keyboard interaction (host keys, yes/no, passphrase) I've uploaded an experimental build using this branch: https://github.com/piannucci/mosh/tree/patch-3 /usr/bin/mosh in perl is gone, there's now a mosh.exe for the frontend client. Missing features: --predict=experimental mode to local echo not yet implemented Detect bogus MOSH_IP earlier is not yet implemented. See http://blogs.perl.org/users/rurban/2012/07/i-had-to-remove-perl-from-mosh.html -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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
Updated: mosh-1.2.2-2 (experimental)
For those who have problems with mosh to connect from cygwin to hosts which require ssh client keyboard interaction (host keys, yes/no, passphrase) I've uploaded an experimental build using this branch: https://github.com/piannucci/mosh/tree/patch-3 /usr/bin/mosh in perl is gone, there's now a mosh.exe for the frontend client. Missing features: --predict=experimental mode to local echo not yet implemented Detect bogus MOSH_IP earlier is not yet implemented. See http://blogs.perl.org/users/rurban/2012/07/i-had-to-remove-perl-from-mosh.html -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: [ITP] mosh with protobuf and perl-IO-Tty
On Tue, Jul 17, 2012 at 9:57 PM, Yaakov (Cygwin/X) wrote: On 2012-07-17 18:00, Reini Urban wrote: mosh-1.2.2-1 protobuf-2.4.1-1 perl-IO-Tty-1.10-1 hints and packages here: http://perl514.cpanel.net/cygwin/ I'm getting connection timeout errors. I got firewalled somehow. Sorry. I put it now here: http://rurban.xarch.at/software/cygwin/release/perl-IO-Tty/ http://rurban.xarch.at/software/cygwin/release/mosh/ http://rurban.xarch.at/software/cygwin/release/protobuf/ -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: cygheap base mismatch detected
On Tue, Jul 17, 2012 at 9:37 PM, Andrew DeFaria wrote: On 7/17/2012 6:56 PM, Reini Urban wrote: On Tue, Jul 17, 2012 at 7:02 PM, Andrew DeFaria wrote: Is there a workaround for the problem mentioned in http://cygwin.com/ml/cygwin/2006-11/msg00580.html? I suddenly started getting this error like every other time I run perl. perlrebase When I run perlrebase I get: Ltsdo-adefaria:perlrebase 3 [main] perl5.10.1 (6808) C:\Cygwin\bin\perl5.10.1.exe: *** fatal error - cygheap base mismatch detected - 0x612768B0/0xD268B0. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. and proceeds to consume about 10% of CPU for like 10 minutes. Am I just supposed to let it crank along? No. This looks like you really got 2 cygwin1.dll's running. Strange. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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] New packages: mosh, protobuf, perl-Io-Tty
mosh has been uploaded to cygwin. The mosh people are now happy to point their windows folks over here. Oh my :) See http://mosh.mit.edu/ New remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes. Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links. The necessary deps are protobuf and perl-IO-Tty. protobuf existed before in cygwinports and has been moved over to cygwin. Thanks Yaakov! http://code.google.com/p/protobuf/ Protocol Buffers are a way of encoding structured data in an efficient yet extensible format. Google uses Protocol Buffers for almost all of its internal RPC protocols and file formats. libprotobuf-devel contains /usr/bin/protoc, the compiler. perl-IO-Tty is just the IO::Tty perl cpan module from my fellow coworker toddr. Hi Todd! New packages: * mosh-1.2.2-1 * libprotobuf7-2.4.1-1 * libprotobuf-devel-2.4.1-1 * perl-IO-Tty-1.10-1 -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- 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
New packages: mosh, protobuf, perl-Io-Tty
mosh has been uploaded to cygwin. The mosh people are now happy to point their windows folks over here. Oh my :) See http://mosh.mit.edu/ New remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes. Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links. The necessary deps are protobuf and perl-IO-Tty. protobuf existed before in cygwinports and has been moved over to cygwin. Thanks Yaakov! http://code.google.com/p/protobuf/ Protocol Buffers are a way of encoding structured data in an efficient yet extensible format. Google uses Protocol Buffers for almost all of its internal RPC protocols and file formats. libprotobuf-devel contains /usr/bin/protoc, the compiler. perl-IO-Tty is just the IO::Tty perl cpan module from my fellow coworker toddr. Hi Todd! New packages: * mosh-1.2.2-1 * libprotobuf7-2.4.1-1 * libprotobuf-devel-2.4.1-1 * perl-IO-Tty-1.10-1 -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
[ITP] mosh with protobuf and perl-IO-Tty
I want to maintain mosh on cygwin. See http://mosh.mit.edu/ The necessary deps are protobuf and perl-IO-Tty. All three exist on most major distros, e.g. debian. mosh-1.2.2-1 protobuf-2.4.1-1 perl-IO-Tty-1.10-1 hints and packages here: http://perl514.cpanel.net/cygwin/ -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
