Re: Resend: pdfseparate does nothing for me?

2016-11-15 Thread Marco Atzeri



On 15/11/2016 23:16, Ian Lambert wrote:

On Tue, 11/15/16, Achim Gratz  wrote:

 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

2016-11-15 Thread OwN-3m-All
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?

2016-11-15 Thread Achim Gratz
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?

2016-11-15 Thread Ian Lambert


On Tue, 11/15/16, Ken Brown  wrote:

 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?

2016-11-15 Thread Ken Brown

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)

2016-11-15 Thread Corinna Vinschen
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)

2016-11-15 Thread Erik Bray
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.  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)

2016-11-15 Thread Corinna Vinschen
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)

2016-11-15 Thread Erik Bray
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

2016-11-15 Thread Andrey Repin
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

2016-11-15 Thread Marco Atzeri

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

2016-11-15 Thread Klaus Musch

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