please update cygwin lighttpd pkg to version 1.4.55
Please update cygwin lighttpd pkg to version 1.4.55 lighttpd 1.4.55 was released 31 Jan 2020 (upstream). Thank you. Glenn -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: please update cygwin lighttpd pkg to version 1.4.55
On Tue, Mar 24, 2020 at 11:51:40AM +0100, Marco Atzeri via Cygwin wrote: > Am 24.03.2020 um 06:50 schrieb gs-cygwin@gluelogic.com: > > Please update cygwin lighttpd pkg to version 1.4.55 > > > > lighttpd 1.4.55 was released 31 Jan 2020 (upstream). > > > > Thank you. Glenn > > -- > > In this moment the package is without a maintainer. > Any specific reason why you need absolutely the last version ? There are numerous bugs in lighttpd 1.4.54 (and fixed in lighttpd 1.4.55) which prevent usage of lighttpd if using one of the modules with bugs, e.g. mod_webdav and mod_deflate. bug: mod_deflate fix error choosing encoding parser (1.4.54 regression) bug: mod_webdav startup crash in config conditional (1.4.54 regression) bug: mod_webdav fix file upload limit bug: mod_accesslog fails to parse multiple cookies bug: preserve %2b and %2B in query string normalization There are numerous security enhancements (hardenings) in lighttpd 1.4.55 security: HTTP Basic/Digest Auth security (attack mitigations) security: HTTP request header parsing restrictions (attack mitigations) Cheers, Glenn -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Compiling C-Kermit 9.0.305 Alpha.02 on Cygwin
On Mon, Nov 30, 2020 at 05:31:46PM -0500, Eliot Moss wrote: > On 11/30/2020 5:17 PM, Keith Christian via Cygwin wrote: > > On Mon, Nov 30, 2020 at 2:44 PM Jeffrey Altman > > wrote: > > > I suspect building C-Kermit with SSH, OpenSSL, Kerberos v5 support is > > > going to be problematic since none of that code has been updated in more > > > than a decade to keep up with the latest upstream packages. I suggest > > > you start by trying to build for a generic linux target without any > > > security features. > > > > > > Jeffrey Altman > > > former Kermit developer > > > > Jeffrey, > > > > Thanks so much, appreciate your taking the time to respond. I was > > puzzled when C-Kermit was dropped from Cygwin several years ago. > > Former Kermit developer, quite the credentials! > > Just checked, and this does not compile out of the box for either the linux > or posix target. Not sure how much work will be required. Too bad it is > not set up to use ./configure to see what's actually available on the > platform / how to use it ... > > Best wishes - Eliot Moss For kicks, I got the *basic* C-Kermit to build under Linux and under Cygwin. https://github.com/gstrauss/ckermit The make command line options are in the commit messages. It is based on http://www.columbia.edu/kermit/archive.html C-Kermit 9.0.302 2011/07/11 cku302.tar.gz I realized afterwards that I should have used C-Kermit 9.0.305 Alpha.02. In any case, compiling is a first step, but does not suggest it is fully functional. Mostly #include and minor changes were needed, except for one big mess with the cygwin custom struct hostent being defined with const char *h_name Cheers, Glenn -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Compiling C-Kermit 9.0.305 Alpha.02 on Cygwin
On Tue, Dec 01, 2020 at 09:20:51AM -0700, Keith Christian wrote:
> On Mon, Nov 30, 2020 at 9:23 PM wrote:
> > For kicks, I got the *basic* C-Kermit to build under Linux and under Cygwin.
> > https://github.com/gstrauss/ckermit
> > The make command line options are in the commit messages.
> >
> > It is based on
> > http://www.columbia.edu/kermit/archive.html
> > C-Kermit 9.0.302 2011/07/11 cku302.tar.gz
> >
> > I realized afterwards that I should have used C-Kermit 9.0.305 Alpha.02.
> >
> > In any case, compiling is a first step, but does not suggest it is fully
> > functional. Mostly #include and minor changes were needed, except for
> > one big mess with the cygwin custom struct hostent being defined with
> > const char *h_name
> >
> > Cheers, Glenn
>
> Glenn,
>
> I tried "make linux" this morning on the 9.0.305 version, got this
> output, (I_am_not_expecting_any_assistance_,) more of a report:
>
> -rw-r-+ 1 keith keith 382913 Sep 19 14:17 makefile
>
> CYGWIN_NT-10.0 DESKTOP-OLN71TE 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
>
> 1 Making C-Kermit for Linux...
> 2 /bin/sh: line 68: -f: command not found
> 3 make[1]: Entering directory 'kermit_downloads/kermitsource'
> 4 Making C-Kermit "9.0.305" for Linux 1.2 or later...
> 5 IMPORTANT: Read the comments in the linux section of the
> 6 makefile if you have trouble.
> 7 make xermit KTARGET=${KTARGET:-linuxa} "CC = gcc" "CC2 = gcc" \
> 8 "CFLAGS = -O -DLINUX -pipe -funsigned-char -DFNFLOAT -DCK_POSIX_SIG \
> 9 -DCK_NEWTERM -DTCPSOCKET -DLINUXFSSTND -DNOCOTFMC -DPOSIX \
> 10 -DUSE_STRERROR -DCK_NCURSES -I/usr/include/ncurses
> -DHAVE_CRYPT_H -DHAVE_OPENPTY " "LNKFLAGS = " \
> 11 "LIBS = -lutil -lncurses -lresolv -lcrypt -lm"
> 12 make[2]: Entering directory 'kermit_downloads/kermitsource'
> 13 gcc -O -DLINUX -pipe -funsigned-char -DFNFLOAT -DCK_POSIX_SIG
> -DCK_NEWTERM -DTCPSOCKET -DLINUXFSSTND -DNOCOTFMC -DPOSIX
> -DUSE_STRERROR -DCK_NCURSES -I/usr/include/ncurses -DHAVE_CRYPT_H
> -DHAVE_OPENPTY -DKTARGET=\"linux\" -c ckucmd.c
> 14 ckucmd.c: In function ‘cmdconchk’:
> 15 ckucmd.c:7579:22: error: ‘__FILE’ has no member named ‘_IO_read_end’
> 16 7579 | x = (int) ((stdin->_IO_read_end) - (stdin->_IO_read_ptr));
> 17| ^~
> 18 ckucmd.c:7579:46: error: ‘__FILE’ has no member named ‘_IO_read_ptr’
> 19 7579 | x = (int) ((stdin->_IO_read_end) - (stdin->_IO_read_ptr));
> 20| ^~
> 21 make[2]: *** [makefile:988: ckucmd.o] Error 1
> 22 make[2]: Leaving directory 'kermit_downloads/kermitsource'
> 23 make[1]: *** [makefile:6067: linuxa] Error 2
> 24 make[1]: Leaving directory 'kermit_downloads/kermitsource'
> 25 make: *** [makefile:6100: linux] Error 2
>
> Only two .o files were created:
>
> -rw-r--r--+ 1 keith keith 48034 Dec 1 08:55 ckcmai.o
> -rw-r--r--+ 1 keith keith 37108 Dec 1 08:55 ckclib.o
>
> Keith
Keith, kindly look at the commits in
https://github.com/gstrauss/ckermit
https://github.com/gstrauss/ckermit/commits/master
> output, (I_am_not_expecting_any_assistance_,) more of a report:
Why bother posting before taking half a second to look at the commits?
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mmap failing with MAP_FIXED
On Fri, Jul 01, 2022 at 05:33:31PM +0100, David Allsopp wrote:
> This program fails at the second mmap call with EINVAL:
>
> #include
> #include
> #include
>
> int main (void) {
> void * mem;
> /* Reserve 256MB address space for the minor heaps */
> mem = mmap(0, 268439552, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> if (mem == MAP_FAILED)
> error(1, 0, "Reservation failed");
> /* Commit the first 2MB heap */
> if (mmap(mem, 2097152, PROT_READ | PROT_WRITE, MAP_PRIVATE |
> MAP_ANONYMOUS | MAP_FIXED, -1, 0) == MAP_FAILED)
> error(1, 0, "Commit failed");
> }
>
> Is this something that's expected to fail for Cygwin, or a bug? The example
> is extracted from OCaml 5.0's runtime, which reserves an area of address
> space and then commits chunks of it as required. The above snippet comes
> from the Linux side, on Windows we're using VirtualAlloc with PAGE_NOACCESS
> to reserve the address space and then VirtualAlloc with MEM_COMMIT and
> PAGE_READWRITE to commit smaller portions of it.
>
> Is there a way to do that with Cygwin's mmap?
Have you tried 'msync()' with MS_ASYNC flag as an alternative approach?
Cheers, Glenn
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: stack grow direction wrongly detected
On Fri, Mar 05, 2021 at 11:31:04PM +0900, Takashi Yano via Cygwin wrote:
> On Fri, 5 Mar 2021 13:18:38 +0100
> Marco Atzeri wrote:
> > Hi Guys,
> > noted trying to rebuild guile 1.8.8.
> >
> > The following piece of code in the past
> > was setting SCM_I_GSC_STACK_GROWS_UP=0
> > and now produces SCM_I_GSC_STACK_GROWS_UP=1
> >
> > I assume some change in the gcc compiler is causing the issue.
> > I presume most of the programs and libraries do not care,
> > but some special one like guile crashes during build for this issue,
> > so be aware.
> >
> > Regards
> > Marco
> >
> >
> > #
> > #
> > # Which way does the stack grow?
> > #
> > # Following code comes from Autoconf 2.61's internal _AC_LIBOBJ_ALLOCA
> > # macro (/usr/share/autoconf/autoconf/functions.m4). Gnulib has
> > # very similar code, so in future we could look at using that.
> > #
> > # An important detail is that the code involves find_stack_direction
> > # calling _itself_ - which means that find_stack_direction (or at
> > # least the second find_stack_direction() call) cannot be inlined.
> > # If the code could be inlined, that might cause the test to give
> > # an incorrect answer.
> > #
> >
> > SCM_I_GSC_STACK_GROWS_UP=0
> > AC_RUN_IFELSE([AC_LANG_SOURCE(
> > [AC_INCLUDES_DEFAULT
> > int
> > find_stack_direction ()
> > {
> >static char *addr = 0;
> >auto char dummy;
> >if (addr == 0)
> > {
> >addr = &dummy;
> >return find_stack_direction ();
> > }
> >else
> > return (&dummy > addr) ? 1 : -1;
> > }
> >
> > int
> > main ()
> > {
> >return find_stack_direction () < 0;
> > }])],
> > [SCM_I_GSC_STACK_GROWS_UP=1],
> > [],
> > [AC_MSG_WARN(Guessing that stack grows down -- see
> > scmconfig.h)])
>
> This seems to be a result of optimization. With gcc v10.2.0,
> the return value of the code is:
> -O0: 1
> -O1: 1
> -O2: 0
> -O3: 1
> -O4: 1
>
> If find_stack_direction() is implemented as recursive call,
> and auto variable is allocated in the stack every time,
> in the first call, addr is initialized to the first stack
> position, and in the second call, second address of dummy
> is reduced because stack of x86 is reverse direction.
> Therefore (&dummy > addr) ? 1 : -1; returns -1.
> As a result, the return value find_stack_direction() < 0
> is 1. With -O0 or -O1 this implemented as recursive call,
> so the return value is 1.
If the compiler is gcc or clang:
__attribute__(__noinline__)
int
find_stack_direction ()
{
...
}
Cheers, Glenn
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Lighttpd and Perl
On Thu, Sep 30, 2021 at 10:07:24AM +, Andy Romens via Cygwin wrote: > Good morning all, > > I am running into a bit of what appears a noob issue with lighttpd. > > Short and sweet version is I am transitioning from Apache to lighttpd. > > Gotten pretty far, except now I am having issues with parsing. > > Our website will run a command in a browser like > ‘server/cgi-bin/myscript.pl?prod,eventhist’ in the web browser. With Apache, > it will split everything after the ‘?’ As variables, and return a nicely > formatted html result page. > > However, after switching to lighttpd, it’s not passing those variables > anymore. When I run the script in Cygwin, it works just fine. > > I’ve been banging my head on this problem for a few days now, so any > assistance would be greatly appreciated. I'd suggest starting at https://wiki.lighttpd.net/#Documentation and carefully reading through the link for "How to get help". Then, you can post your improved questions in the lighttpd Support Forum, perhaps with more details about your script. When running CGI scripts such as "myscript.pl", lighttpd creates a standard CGI environment [1], including environment variables such as QUERY_STRING, so the problem is likely in your Perl script, and likely a misunderstanding of standard CGI environment variables. [1] The Common Gateway Interface (CGI) Version 1.1 https://datatracker.ietf.org/doc/html/rfc3875 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: rsync gives me error 12
On Sat, Mar 26, 2022 at 11:49:18PM -0500, Neil Aggarwal wrote: > The big stumper for me is that scp works. What could cause rsync to act > differently? Likely answer: your server configuration, such as ssh config, shell configuration, PATH, etc. which are a bit off-topic for the cygwin list. Manually ssh to the server and try to run `rsync -h`. $ ssh -vvv user@server rsync -h You can also get verbose ssh information from rsync using $ rsync -e 'ssh -vvv' ... You can also turn on verbose sshd logging $ man sshd_config See LogLevel and LogVerbose -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin Perl has slowed in recent months
On Tue, May 24, 2022 at 11:36:21PM -0700, David Christensen wrote: > I went back to the desktop computer that I have been using for Cygwin Perl > testing: > [...] > > 'make test' produced the following result: > > 99 wallclock secs ( 1.76 usr 0.41 sys + 342.21 cusr 375.40 csys = 719.78 > CPU) > [...] > I ran Cygwin setup-x86_64.exe version 2.918 and upgraded all Cygwin > packages. [...] > I ran the cpan(1) shell and upgraded Perl modules: [...] > > 'make test' now produces: > > 211 wallclock secs ( 2.39 usr 2.71 sys + 525.68 cusr 998.78 csys = 1529.57 > CPU) You have merely demonstrated that there is a change in timing after upgrading *all* of cygwin environment and packages. Basic troubleshooting by any competent admin involves making changes stepwise in steps as small as (reasonably) possible, and reperforming tests each step. Next step: go back to your older system and upgrade only the Perl packages, then repeat the test. If you are capable, try testing your cygwin environment on a different machine, preferably not a corporate machine with hidden BLODA, and with Microsoft Defender disabled (for the tests) (as previously asked by others). If you are capable, try testing older and newer Perl installations on a different OS. Annecdotally, I noticed about month or two ago that running my Perl Test::Harness slowed down dramatically after an upgrade of both kernel and packages on a Linux (*not Cygwin*) system. I have not yet seen compelling evidence from you that the slowdown is due to Cygwin, and have seen data suggesting it is more directly related to Perl changes. Other than your 'make test', do you have any evidence that anything else has slowed down as dramatically between the old and new cywgin packages? Any other shell scripts for which you tested the timing? Any other Perl scripts for which you tested the timing? (and not run under 'make test') -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
