Re: Resend: pdfseparate does nothing for me?
On 15/11/2016 23:16, Ian Lambert wrote: On Tue, 11/15/16, Achim Gratzwrote: Subject: Re: Resend: pdfseparate does nothing for me? To: cygwin@cygwin.com Date: Tuesday, November 15, 2016, 3:34 PM Ian Lambert writes: > I try to stay up to date, but it is difficult because setup would not > accept network proxy settings the last time I tried, Then you need to fix that or maintain a local mirror that setup can use. A full local mirror (~80 GB) is too big to be an option. Automating a partial one is still a mystery. ( https://sourceware.org/cygwin-apps/package-server.html ) I can't fix setup without help. User and passwd options appear in setup source; however, it never asks me to enter them. I'm happy to test changes, but fixing it myself now isn't feasible. on "select connection type" Window, use "Internet Explorer Settings" -- 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: pure-ftpd fatal error in forked process - fork: can't reserve memory for parent Cygwin x86 Operating Systems
pure-ftpd is run using the following command: /usr/sbin/pure-ftpd.exe -S 0.0.0.0,21 -lpuredb:/etc/pureftpd.pdb -g /var/run/pure-ftpd.pid & I can't get any FTP account to work. Attached is the cygcheck.out. Thanks for taking a look. cygcheck.out Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Resend: pdfseparate does nothing for me?
Ian Lambert writes: > cygcheck did say "OK" for the previous version, however :) The "OK" in this case means (only) that at all the files the package is supposed to have are still present. > I try to stay up to date, but it is difficult because setup would not > accept network proxy settings the last time I tried, Then you need to fix that or maintain a local mirror that setup can use. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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: Resend: pdfseparate does nothing for me?
On Tue, 11/15/16, Ken Brownwrote: Subject: Re: Resend: pdfseparate does nothing for me? To: cygwin@cygwin.com Date: Tuesday, November 15, 2016, 1:56 PM On 11/15/2016 9:59 AM, Ian Lambert wrote: >> The procedure entry point nghttp2_http2_strerror could not >> be located >> in the dynamic link library cygnghttp2-14.dll. >> [...] >> A redacted cygcheck -svr output is attached. > libnghttp2_14 1.7.1-1 You don't have the current version of libnghttp2_14 installed. Ken Moving to version 1.14.0-1 fixed it. cygcheck did say "OK" for the previous version, however :) libnghttp2_14 1.7.1-1 OK I try to stay up to date, but it is difficult because setup would not accept network proxy settings the last time I tried, so I'm using apt-cyg download and setup local installs as a workaround, and this does not always get me the latest versions of packages (and requires many painful copy/pastes from Update Announcements). Thank you! -- 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: Resend: pdfseparate does nothing for me?
On 11/15/2016 9:59 AM, Ian Lambert wrote: The procedure entry point nghttp2_http2_strerror could not be located in the dynamic link library cygnghttp2-14.dll. [...] A redacted cygcheck -svr output is attached. libnghttp2_14 1.7.1-1 You don't have the current version of libnghttp2_14 installed. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Return the correct value for sysconf(_SC_PAGESIZE)
On Nov 15 16:47, Erik Bray wrote: > On Tue, Nov 15, 2016 at 3:58 PM, Corinna Vinschen >wrote: > > On Nov 15 14:51, Erik Bray wrote: > >> Greetings, > >> > >> Currently sysconf(_SC_PAGESIZE) returns the value of > >> wincap.allocation_granularity()--a change I *think* had to have been > >> made by mistake in > >> https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;f=winsup/cygwin/sysconf.cc;h=177dc6c7f6d0608ef6540fd997d9b444e324cae2 > >> > >> There's no obvious reason, anyways, that this value should be returned > >> and not the actual page size. > > > > That's no accident, but a deliberate decision. Originally we used the > > page size at this point, but that's long ago. This has been discussed > > on the cygwin-developers mailing list years ago. The problem is the > > POSIX assumption that the allocation granularity equals the page size. > > The only working solution which does not break assumptions is to return > > the allocation granularity as page size. > > Okay, sorry for suggesting otherwise. When I looked at that commit it > seemed like a there was a lot of mass renaming going on, so I thought > it might have been an accident. I didn't see the threads where this > was discussed. > > I see the reason for the change now, but the fact remains > sysconf(_SC_PAGESIZE) cannot, then, be relied on to make any > memory-related calculations from page counts. What do you mean? If you call sysconf(_SC_PHYS_PAGES) or sysconf(_SC_AVPHYS_PAGES) you get the number of pages in _SC_PAGESIZE chunks so all is good. > Is there a different > (posix-compliant) way to get the actual page size, or at least maybe > it could be somewhere in /proc? There is no good reason to use the non-POSIXy page size. It doesn't help you in the least for any pagesize-related functionality. Mmap as well as malloc and friends only work with _SC_PAGESIZE sized pages. It sounds as if you're looking for a solution for which there's no problem... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Return the correct value for sysconf(_SC_PAGESIZE)
On Tue, Nov 15, 2016 at 3:58 PM, Corinna Vinschenwrote: > On Nov 15 14:51, Erik Bray wrote: >> Greetings, >> >> Currently sysconf(_SC_PAGESIZE) returns the value of >> wincap.allocation_granularity()--a change I *think* had to have been >> made by mistake in >> https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;f=winsup/cygwin/sysconf.cc;h=177dc6c7f6d0608ef6540fd997d9b444e324cae2 >> >> There's no obvious reason, anyways, that this value should be returned >> and not the actual page size. > > That's no accident, but a deliberate decision. Originally we used the > page size at this point, but that's long ago. This has been discussed > on the cygwin-developers mailing list years ago. The problem is the > POSIX assumption that the allocation granularity equals the page size. > The only working solution which does not break assumptions is to return > the allocation granularity as page size. Okay, sorry for suggesting otherwise. When I looked at that commit it seemed like a there was a lot of mass renaming going on, so I thought it might have been an accident. I didn't see the threads where this was discussed. I see the reason for the change now, but the fact remains sysconf(_SC_PAGESIZE) cannot, then, be relied on to make any memory-related calculations from page counts. Is there a different (posix-compliant) way to get the actual page size, or at least maybe it could be somewhere in /proc? Sorry otherwise for the noise. Thanks, Erik
Re: Return the correct value for sysconf(_SC_PAGESIZE)
On Nov 15 14:51, Erik Bray wrote: > Greetings, > > Currently sysconf(_SC_PAGESIZE) returns the value of > wincap.allocation_granularity()--a change I *think* had to have been > made by mistake in > https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;f=winsup/cygwin/sysconf.cc;h=177dc6c7f6d0608ef6540fd997d9b444e324cae2 > > There's no obvious reason, anyways, that this value should be returned > and not the actual page size. That's no accident, but a deliberate decision. Originally we used the page size at this point, but that's long ago. This has been discussed on the cygwin-developers mailing list years ago. The problem is the POSIX assumption that the allocation granularity equals the page size. The only working solution which does not break assumptions is to return the allocation granularity as page size. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Return the correct value for sysconf(_SC_PAGESIZE)
Greetings, Currently sysconf(_SC_PAGESIZE) returns the value of wincap.allocation_granularity()--a change I *think* had to have been made by mistake in https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;f=winsup/cygwin/sysconf.cc;h=177dc6c7f6d0608ef6540fd997d9b444e324cae2 There's no obvious reason, anyways, that this value should be returned and not the actual page size. Thanks, Erik (P.S. Took me about a half-dozen tries to get a message through to this ML due to a very picky mailer-daemon--I think it doesn't like gmail aliases--hopefully this does the trick :) 0001-Return-wincap.page_size-for-sysconf-_SC_PAGESIZE-not.patch Description: Binary data
Re: Cygwin Setup Command-line Arguments - Paths with a Space Incorrectly Parsed
Greetings, OwN-3m-All! > Thanks guys. That was it. I decided to remove the trailing slash for > my purposes. > set WD=%~dp0 > set WD=%WD:~0,-1% > It's working now! Alternatively, you could translate backslashes to regular slashes. Should work too. SETLOCAL ENABLEEXTENSIONS SET CWD=%CD:\=/% P.S. This list is in "no top posting, please, thank you" mode. -- With best regards, Andrey Repin Tuesday, November 15, 2016 16:13:53 Sorry for my terrible english... -- 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: pure-ftpd fatal error in forked process - fork: can't reserve memory for parent Cygwin x86 Operating Systems
On 15/11/2016 08:33, OwN-3m-All wrote: Hi, Has anyone else run into this issue when trying to get pure-ftpd to work? ./pure-ftpd.exe 9 [main] pure-ftpd 3032 C:\OGP\usr\sbin\pure-ftpd.exe: *** fatal error in forked process - fork: can't reserve memory for parent stack 0x1B - 0x3B, (child has 0x14 - 0x34), Win32 error 487 1022 [main] pure-ftpd 3032 cygwin_exception::open_stackdumpfile: Dumping stack trace to pure-ftpd.exe.stackdump 9 [main] pure-ftpd 2936 fork: child -1 - forked process 3032 died unexpectedly, retry 0, exit code 0x100, errno 11 Full stack trace from log: Stack trace: Frame Function Args 0033F9F0 7744D2E9 (7FFD9000, 77A16100, , ) 0033FA30 778B1603 (00AD1000, 7FFD9000, , 77917B2E) 0033FA48 778B15D6 (00AD1000, 7FFD9000, , ) End of stack trace I get the reserve memory error when a FTP connection to pure-ftpd is opened. pure-ftpd immediately crashes with the above error and the FTP connection is never established. I have installed pure-ftpd the same way on a Windows Server 2008 SP2 x86 instance and a Windows 7 x86 instance. I run into the same error on each, and each machine has plenty of RAM available. Other packages aren't doing this. It happens with the built-in anonymous user along with any new users that eventually are added in /etc/pureftpd.passwd Setup.exe version 2.876 (32 bit) pure-ftpd version installed is 1.0.43-1 How are you running pure-ftpd ? Do you have problem with normal users ? It may be a problem of authorization to change user owner for the process. Anyone have any clue what the issue is? There is no log entry in /var/log and I see pure-ftpd.exe running as a process... it just crashes every time a connection is opened. Thanks OwN Please attach the cygcheck.out. PS: I can not follow up the matter in detail until next week. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
httpd-service is blocked and also blocks cygwin terminal
Hello, I have a problem with blocking requests to the httpd-service since some months. And the most surprising thing: As long as the httpd-service is blocked, I can't open a cygwin terminal. Start of the terminal is also blocked. As soon as I stop the httpd-service, the terminal appears. I did a fresh installation of cygwin and deleted all NT-users created by cygwin before, but the problem is still there. These are the services I have running: Service : cygserver Display name: CYGWIN cygserver Current State : Running Controls Accepted : Stop Command : /usr/sbin/cygserver stdin path : /dev/null stdout path : /var/log/cygserver.log stderr path : /var/log/cygserver.log Process Type: Own Process Startup : Automatic Account : LocalSystem Service : httpd Display name: CYGWIN Apache HTTP Server Current State : Stopped Command : /usr/sbin/httpd.exe -DNO_DETACH -k start stdin path : /dev/null stdout path : /var/log/httpd.log stderr path : /var/log/httpd.log Environment : CYGWIN="" Process Type: Own Process Startup : Automatic Account : LocalSystem Service : sshd Display name: CYGWIN sshd Current State : Running Controls Accepted : Stop Command : /usr/sbin/sshd -D stdin path : /dev/null stdout path : /var/log/sshd.log stderr path : /var/log/sshd.log Environment : CYGWIN="binmod ntsec" Process Type: Own Process Startup : Automatic Dependencies: tcpip Account : .\cyg_server I seems only to happen when having PHP and jquery in the HTML-file. Pure HTML-files seems to work. The first call of the HTML-file always works. But at the latest the tenth call of the page leads to the block. The httpd-service simply never comes back. The jquery function "$( document ).ready" never gets executed, so I think the page is never loaded by the httpd-service. Any hint? Thanks Klaus -- 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