httpd/sshd will not start due to "failed to create proxy mutex" error

I can't remember if I've ever set up Apache on Cygwin before, but I'm trying to do so now and I'm not getting anywhere. I'm trying to install them as services and it's not working. I'm trying to run these commands in an administrator shell: $ cygrunsrv -I httpd -p /usr/sbin/httpd (The service

Re: git and absolute Windows-style paths

On 4/20/2016 7:14 PM, Ernie Rael wrote: On 4/20/2016 1:37 PM, Eliot Moss wrote: I think this will do it: function git { declare -a ARGS for n in "$@" ; do ARGS+=("$(cygpath -u -- "${n}")") ; done command git "${ARGS[@]}" } The reason this is a little more complicated than some other

Re: git and absolute Windows-style paths

On 4/20/2016 1:37 PM, Eliot Moss wrote: I think this will do it: function git { declare -a ARGS for n in "$@" ; do ARGS+=("$(cygpath -u -- "${n}")") ; done command git "${ARGS[@]}" } The reason this is a little more complicated than some other approaches might be is that it will also

Re: introduction, fix for npm w.r.t. git, and questions

On Wed, Apr 20, 2016 at 11:17:35PM +0200, silverwind wrote: > On 4/20/16 10:59 PM, Adam Dinwoodie wrote: > >native Windows and Cygwin. It's been a while since I tried it, but I > >_think_ you can generally use Cygwin Git and Windows Git on the same > >working copy without any difficulties, at

Re: native Linux userland in Windows 10

On Apr 15, 2016, at 4:04 AM, Andrey Repin wrote: > >> And yet, despite the free >> availability of top-quality VM technology, Cygwin continues to thrive. > > Because interoperability. So the ability to run native Linux ELF binaries without recompilation on Windows is not

Re: introduction, fix for npm w.r.t. git, and questions

On 4/20/16 10:59 PM, Adam Dinwoodie wrote: native Windows and Cygwin. It's been a while since I tried it, but I _think_ you can generally use Cygwin Git and Windows Git on the same working copy without any difficulties, at least if you avoid the common pain points like line ending rewriting and

Re: git and absolute Windows-style paths

On Wed, Apr 20, 2016 at 04:37:34PM -0400, Eliot Moss wrote: > I think this will do it: > > function git { > declare -a ARGS > for n in "$@" ; do ARGS+=("$(cygpath -u -- "${n}")") ; done > command git "${ARGS[@]}" > } > > The reason this is a little more complicated than some other

Re: introduction, fix for npm w.r.t. git, and questions

On Wed, Apr 20, 2016 at 09:30:33PM +0200, silverwind wrote: > >I think the "correct" fix would be to get npm (or possibly the > >JavaScript engine itself?) to stop acting as if it's in a Windows > >environment > You're on the right track. The root issue is that Node.js (on which > npm runs) is a

Re: unison-2.48.3-1 cannot sync to a server running unison2.48.3 (ocaml 4.02)

> unison 2.48.3-1 crashes while trying to sync single files to my server. > The server is running unison 2.48.3 compiled against ocaml 4.02. > I think this might be an issue with ocaml 4.01 and 4.02 binary > incompability. ( > http://blog.gmane.org/gmane.network.unison.general/month=20150801 )

Re: git and absolute Windows-style paths

I think this will do it: function git { declare -a ARGS for n in "$@" ; do ARGS+=("$(cygpath -u -- "${n}")") ; done command git "${ARGS[@]}" } The reason this is a little more complicated than some other approaches might be is that it will also work for arguments that have space, e.g.,

Re: introduction, fix for npm w.r.t. git, and questions

I think the "correct" fix would be to get npm (or possibly the JavaScript engine itself?) to stop acting as if it's in a Windows environment You're on the right track. The root issue is that Node.js (on which npm runs) is a native Windows binary in pretty much all cases, as it's not possible to

Re: introduction, fix for npm w.r.t. git, and questions

On Wed, Apr 20, 2016 at 03:21:27PM +, Brian Clifton wrote: > (I've never joined a mailing list so please bear with me as I learn how this > works) Hi Brian, welcome! > I saw the email chain regarding Git using Windows paths; I wanted to > share that I've been fighting that too.

Re: pthread_attr_init() returning errors

On 4/20/2016 10:22 AM, Canham, Timothy K (348C) wrote: I think I understand what happened now. The call to pthread_attr_init() is contained within a function we use to start threads. It is called successive times and it fails on the second call. It would appear that the stack entry gets laid

Re: git and absolute Windows-style paths

On 4/20/2016 9:10 AM, Brian Clifton wrote: I agree completely- Faking out git by wrapping it as a function in your .bashrc would be an ideal approach. I was the person championing that PR which got rejected, unfortunately. The NPM folks were recommending to use mingw which *is* supported...

Re: Security update needed for mercurial (upload error: doesn't follow naming convention)

On Apr 20, 2016, at 10:56 AM, Jari Aalto wrote: > >> 3.7.3 as a security release, with fixes for: >> >> CVE-2016-3630 Mercurial: remote code execution in binary delta decoding >> CVE-2016-3068 Mercurial: arbitrary code execution with Git subrepos >> CVE-2016-3069

unison-2.48.3-1 cannot sync to a server running unison2.48.3 (ocaml 4.02)

Hi, unison 2.48.3-1 crashes while trying to sync single files to my server. The server is running unison 2.48.3 compiled against ocaml 4.02. I think this might be an issue with ocaml 4.01 and 4.02 binary incompability. ( http://blog.gmane.org/gmane.network.unison.general/month=20150801 ) I

Re: Just finished updating my 64-bit Cygwin; at the end I have an exit code of 2 from zp_fontconfig_cache_1.sh

On Wed, Apr 20, 2016 at 10:52 AM, Marco Atzeri wrote: > > > On 20/04/2016 19:38, Kenneth Wolcott wrote: >> >> On Tue, Apr 19, 2016 at 10:57 PM, Marco Atzeri wrote: >>> >>> On 20/04/2016 04:01, Kenneth Wolcott wrote: >>> >>> check error on >>>

Re: Just finished updating my 64-bit Cygwin; at the end I have an exit code of 2 from zp_fontconfig_cache_1.sh

On 20/04/2016 19:38, Kenneth Wolcott wrote: On Tue, Apr 19, 2016 at 10:57 PM, Marco Atzeri wrote: On 20/04/2016 04:01, Kenneth Wolcott wrote: check error on /var/log/setup.log.full Mi Marco; Here is an excerpt from /var/logs/setup.log.full that might be pertinent: 2016/04/19

Re: Just finished updating my 64-bit Cygwin; at the end I have an exit code of 2 from zp_fontconfig_cache_1.sh

On Tue, Apr 19, 2016 at 10:57 PM, Marco Atzeri wrote: > On 20/04/2016 04:01, Kenneth Wolcott wrote: >> >> Hi; >> >> Just finished updating my 64-bit Cygwin; at the end I have an exit >> code of 2 from zp_fontconfig_cache_1.sh >> >> Package: z/Perpetual >>

RE: pthread_attr_init() returning errors

I think I understand what happened now. The call to pthread_attr_init() is contained within a function we use to start threads. It is called successive times and it fails on the second call. It would appear that the stack entry gets laid out the exact same way as the previous call, so

Re: Security update needed for mercurial (upload error: doesn't follow naming convention)

On 20/04/2016 17:56, Jari Aalto wrote: 3.7.3 as a security release, with fixes for: CVE-2016-3630 Mercurial: remote code execution in binary delta decoding CVE-2016-3068 Mercurial: arbitrary code execution with Git subrepos CVE-2016-3069 Mercurial: arbitrary code execution when converting Git

Re: Security update needed for mercurial (upload error: doesn't follow naming convention)

On Apr 20 19:56, Jari Aalto wrote: > > 3.7.3 as a security release, with fixes for: > > > > CVE-2016-3630 Mercurial: remote code execution in binary delta decoding > > CVE-2016-3068 Mercurial: arbitrary code execution with Git subrepos > > CVE-2016-3069 Mercurial: arbitrary code execution when

Re: Security update needed for mercurial (upload error: doesn't follow naming convention)

> 3.7.3 as a security release, with fixes for: > > CVE-2016-3630 Mercurial: remote code execution in binary delta decoding > CVE-2016-3068 Mercurial: arbitrary code execution with Git subrepos > CVE-2016-3069 Mercurial: arbitrary code execution when converting Git repos New release uploaded, but

Re: git and absolute Windows-style paths

On Wed, Apr 20, 2016 at 05:44:47PM +0200, silverwind wrote: > > I can't immediately see what's going wrong, so I'm going to report > this upstream. > > Thanks. I came upon this issue through npm which is using these > Windows paths for certain git operations. Unfortunately, The npm > team is very

Re: git and absolute Windows-style paths

Hey, I think that tackling this with a script/function is a better approach ... That's seems like a bandaid solution from which the general user base would not be able to profit. I think a floating patch to Cygwin's git package would be more appropriate, unless it can be addressed in

[ANNOUNCEMENT] New package: gdal-2.0.2-1

Version 2.0.2-1 of gdal libgdal-devel libgdal20 have been uploaded for cygwin. The Geospatial Data Abstraction Library is a translator library for raster and vector geospatial data formats that is released under an X/MIT style Open Source license by the Open Source Geospatial

New package: gdal-2.0.2-1

Version 2.0.2-1 of gdal libgdal-devel libgdal20 have been uploaded for cygwin. The Geospatial Data Abstraction Library is a translator library for raster and vector geospatial data formats that is released under an X/MIT style Open Source license by the Open Source Geospatial

Re: git and absolute Windows-style paths

I agree completely- Faking out git by wrapping it as a function in your .bashrc would be an ideal approach. I was the person championing that PR which got rejected, unfortunately. The NPM folks were recommending to use mingw which *is* supported... but I haven't seen any updates to that

New package: geos-3.5.0

Version 3.5.0-1 of geos (source only) libgeos-devel libgeos_3_5 libgeos_c1 have been uploaded for cygwin. GEOS (Geometry Engine - Open Source) is a C++ port of the Topology Suite (JTS). As such, it aims to contain the complete functionality of JTS in C++. This

[ANNOUNCEMENT] New package: geos-3.5.0

Version 3.5.0-1 of geos (source only) libgeos-devel libgeos_3_5 libgeos_c1 have been uploaded for cygwin. GEOS (Geometry Engine - Open Source) is a C++ port of the Topology Suite (JTS). As such, it aims to contain the complete functionality of JTS in C++. This

Re: git and absolute Windows-style paths

On 4/20/2016 11:44 AM, silverwind wrote: Hey, Does it work if you do: git add c:/test/file Nope, won't work either. No file is added, exit code 0 is given. > I can't immediately see what's going wrong, so I'm going to report this upstream. Thanks. I came upon this issue through npm

Re: git and absolute Windows-style paths

Hey, Does it work if you do: git add c:/test/file Nope, won't work either. No file is added, exit code 0 is given. > I can't immediately see what's going wrong, so I'm going to report this upstream. Thanks. I came upon this issue through npm which is using these Windows paths for

Re: introduction, fix for npm w.r.t. git, and questions

I see no reason why a function similar on concept to what you write, i.e., one that applies cygpath to convert full Windows paths to cygwin style paths, should not work. I have a number of simple function that do the opposite, allowing me to invoke Windows programs (such as Word) with cygwin

introduction, fix for npm w.r.t. git, and questions

Hi folks, (I've never joined a mailing list so please bear with me as I learn how this works) Quick intro My name is Brian, I'm a developer at a hosting company in Arizona, USA and I really enjoy Cygwin. I mostly use it at home and I appreciate all of the work everyone has

Re: Cygwin/X windowed single window mode not working properly on Windows 10

Thank you Jon. With the '-engine 1' option it works ok. My graphics drivers are up to date, so I have no clue what causes this behavior. On 4/20/16, Jon Turney wrote: > On 19/04/2016 10:13, Yos T wrote: >> Recently I upgraded from Win8 to Win10. I used to run

Re: Process map and fork problems

Corinna Vinschen cygwin.com> writes: > ASLR is toxic to fork... Well, that was the reason for the '--noaslr' switch in rebaselst, which can be activated by the peflags argument to rebase-trigger. However, in the case of emacs-x11 I've just tested ASLR allowed it to work through what would

Re: pthread_attr_init() returning errors

On Apr 20 14:20, Canham, Timothy K (348C) wrote: >> From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] >> On Apr 19 19:49, Canham, Timothy K (348C) wrote: >> > I have some code to start a task that suddenly started failing. This >> > is pretty mature code. Here is the code fragment with

Re: Process map and fork problems

On Apr 20 14:29, Achim Gratz wrote: > Corinna Vinschen cygwin.com> writes: > > It can't fragment, it can only grow. The Unix heap management doesn't > > have the notion of multiple application heaps. There's only the sbrk > > call to raise or shrink the size of the heap. > > Thanks for the

Re: Process map and fork problems

Corinna Vinschen cygwin.com> writes: > It can't fragment, it can only grow. The Unix heap management doesn't > have the notion of multiple application heaps. There's only the sbrk > call to raise or shrink the size of the heap. Thanks for the confirmation. It looks like I am allowed to

Re: git clone fails with error chmod on config.lock failed: Invalid argument

On Apr 20 15:05, Tomas Jura wrote: > On 04/19/2016 03:39 PM, Corinna Vinschen wrote: > >>BTW: My machine is Windows Server 2008, yesterday I also run the Windows > >>update procedure before I notified the chmod error. > >>A months ago, I had to migrate to the new AD account. The cygwin was >

RE: pthread_attr_init() returning errors

So what you are saying is that when pthread_attr_init() checked for the magic number in supposedly uninitialized memory it found the exact value of the magic number? That seems highly suspect. Seems like it may be pointing to a valid previous entry. Tim Canham JPL Flight Software

Re: Process map and fork problems

On Apr 20 11:24, Achim Gratz wrote: > Corinna Vinschen cygwin.com> writes: > > > I think all the affected machines have 4GB memory installed, but the > > > option may not have been default when they were installed. > > > > They never are default. Default is 2 Gigs application VM, 2 Gigs > >

Re: git clone fails with error chmod on config.lock failed: Invalid argument

On 04/19/2016 03:39 PM, Corinna Vinschen wrote: BTW: My machine is Windows Server 2008, yesterday I also run the Windows update procedure before I notified the chmod error. A months ago, I had to migrate to the new AD account. The cygwin was installed using my old account, which is deleted now.

Re: Process map and fork problems

On 20/04/2016 13:01, Achim Gratz wrote: No I don't think I have an overly large Cygwin installation, but Perl, Octave and Python pull in a lot of images. I guess what pushed it over the edge is the LLVM stuff that something pulls in since a few months, so that explains the timeframe of the

Re: Cygwin/X windowed single window mode not working properly on Windows 10

On 19/04/2016 10:13, Yos T wrote: Recently I upgraded from Win8 to Win10. I used to run Cygwin/X with a window manager (dwm) without any problems. After the upgrade this did not work properly anymore. I can still run the X server and dwm starts as expected. However the window does not seem to be

Re: Process map and fork problems

Corinna Vinschen cygwin.com> writes: > > I think all the affected machines have 4GB memory installed, but the > > option may not have been default when they were installed. > > They never are default. Default is 2 Gigs application VM, 2 Gigs > kernel̇ memory space. Specifying /3Gb means 3 Gigs

[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.1-0.1

Hi Cygwin friends and users, I just released a new Cygwin TEST version 2.5.1-0.1. 2.5.1 will be basically a bugfix release only. I plan to release it *this* Friday at the latest. Please give it a try ASAP. Bug Fixes - - Fix strxfrm/wcsxfrm return value if output buffer is too

TEST RELEASE: Cygwin 2.5.1-0.1

Hi Cygwin friends and users, I just released a new Cygwin TEST version 2.5.1-0.1. 2.5.1 will be basically a bugfix release only. I plan to release it *this* Friday at the latest. Please give it a try ASAP. Bug Fixes - - Fix strxfrm/wcsxfrm return value if output buffer is too

Re: Process map and fork problems

On Apr 20 11:01, Achim Gratz wrote: > Corinna Vinschen cygwin.com> writes: > > This is one heap. The first region is just the already committed > > part, the remainder is the reserved part. > > > > THis is the standard Cygwin heap area on 32 bit machines, which always > > starts at 0x2000.

Re: Process map and fork problems

Corinna Vinschen cygwin.com> writes: > This is one heap. The first region is just the already committed > part, the remainder is the reserved part. > > THis is the standard Cygwin heap area on 32 bit machines, which always > starts at 0x2000. So, shouldn't rebase keep this area clear on

Re: [ITP] gdal-2.0.2

On Apr 20 12:22, Marco Atzeri wrote: > > Already present in most of the distributions > > - > GDAL is a translator library for raster and vector geospatial data formats > that is released under an X/MIT style Open Source license

Re: Process map and fork problems

On Apr 20 12:46, Corinna Vinschen wrote: > Hi Achim, > > On Apr 20 10:27, Achim Gratz wrote: > > I'm chasing a problem on some 32bit Windows installs that supposedly > > happened after one of the Windows updates (and probably other software > > updates) in the last few months (the affected users

Re: pthread_attr_init() returning errors

On Apr 19 19:49, Canham, Timothy K (348C) wrote: > I have some code to start a task that suddenly started failing. This is > pretty mature code. Here is the code fragment with my added printf() > > pthread_attr_t att; > int stat = pthread_attr_init(); > if (stat != 0) { >

Re: Process map and fork problems

Hi Achim, On Apr 20 10:27, Achim Gratz wrote: > I'm chasing a problem on some 32bit Windows installs that supposedly > happened after one of the Windows updates (and probably other software > updates) in the last few months (the affected users were unable to pin it > down further unfortunately).

Re: Process map and fork problems

Achim Gratz NexGo.DE> writes: > I'm chasing a problem on some 32bit Windows installs that supposedly > happened after one of the Windows updates (and probably other software > updates) in the last few months (the affected users were unable to pin it > down further unfortunately). It's obviously

[newlib-cygwin] Add release message for commit 9409c53

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=1f02aa08d1c9510f87c329a6fce2932e9df1fc9e commit 1f02aa08d1c9510f87c329a6fce2932e9df1fc9e Author: Corinna Vinschen Date: Wed Apr 20 12:34:07 2016 +0200 Add release message for commit 9409c53 Diff: ---

[newlib-cygwin] Don't test pthread objects for being already initialized at init time

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=9409c5335bfac54ccd89fbe931e670b797462e05 commit 9409c5335bfac54ccd89fbe931e670b797462e05 Author: Corinna Vinschen Date: Wed Apr 20 12:31:45 2016 +0200 Don't test pthread objects for being already initialized

Process map and fork problems

I'm chasing a problem on some 32bit Windows installs that supposedly happened after one of the Windows updates (and probably other software updates) in the last few months (the affected users were unable to pin it down further unfortunately). It's obviously caused by two heap sections in the

[ITP] gdal-2.0.2

Already present in most of the distributions - GDAL is a translator library for raster and vector geospatial data formats that is released under an X/MIT style Open Source license by the Open Source Geospatial Foundation. As

Re: [ITP] geos-3.5.0

On Apr 20 10:49, Marco Atzeri wrote: > > Already present in most of the distributions > > - > GEOS (Geometry Engine - Open Source) is a C++ port of the ​Java Topology > Suite (JTS). As such, it aims to contain the complete

Re: git and absolute Windows-style paths

On Tue, Apr 19, 2016 at 05:58:18PM -0400, Ken Brown wrote: > On 4/19/2016 5:31 PM, Marco Atzeri wrote: > >On 19/04/2016 22:34, silverwind wrote: > >>Hey, > >> > >>I noticed that Cygwin's git does not seem to correctly process > >>Windows-style paths in at least v2.7.4 and v2.8.1. It may have

Re: Security update needed for mercurial

On Apr 19 17:30, Andy Moreton wrote: > On Sat 02 Apr 2016, Andy Moreton wrote: > > > Hi, > > > > The current package is for mercurial 3.5.1, but upstream have released Actually the Cygwin mercurial package is at 3.6.3. > > 3.7.3 as a security release, with fixes for: > > > > CVE-2016-3630

[newlib-cygwin] Introduce __socklen_t for BSD compatibility

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=cb376b255da5d4300efb4723dd8a8d09eae9f7c6 commit cb376b255da5d4300efb4723dd8a8d09eae9f7c6 Author: Sebastian Huber Date: Mon Apr 18 15:29:22 2016 +0200 Introduce __socklen_t for BSD compatibility

[newlib-cygwin] BSD compatibility for

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=76a2110b473c12eb7a9c9e5d15d54309db5f8b9c commit 76a2110b473c12eb7a9c9e5d15d54309db5f8b9c Author: Sebastian Huber Date: Mon Apr 18 15:29:21 2016 +0200 BSD compatibility for Introduce

[newlib-cygwin] Introduce __sa_family_t for BSD compatibiliy

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=e03a7056a67a24a0c63192e5d9ec334fc96291ac commit e03a7056a67a24a0c63192e5d9ec334fc96291ac Author: Sebastian Huber Date: Mon Apr 18 15:29:23 2016 +0200 Introduce __sa_family_t for BSD

[newlib-cygwin] Provide in_port_t via

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=7d22dc338d5aeb61f049776b85b2c87b94f7878d commit 7d22dc338d5aeb61f049776b85b2c87b94f7878d Author: Sebastian Huber Date: Mon Apr 18 15:29:25 2016 +0200 Provide in_port_t via Provide

[newlib-cygwin] Provide in_addr_t via

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=3ce1e7901e9b9b8f161df3fad0aa5ef3167d4afb commit 3ce1e7901e9b9b8f161df3fad0aa5ef3167d4afb Author: Sebastian Huber Date: Mon Apr 18 15:29:24 2016 +0200 Provide in_addr_t via Provide

[ANNOUNCEMENT] gnumeric 1.12.28-1

The following packages have been uploaded to the Cygwin distribution: * gnumeric-1.12.28-1 * gnumeric-devel-1.12.28-1 The Gnumeric spreadsheet is part of the GNOME desktop environment. The goal of Gnumeric is to be the best possible spreadsheet. We are not attempting to clone existing

gnumeric 1.12.28-1

The following packages have been uploaded to the Cygwin distribution: * gnumeric-1.12.28-1 * gnumeric-devel-1.12.28-1 The Gnumeric spreadsheet is part of the GNOME desktop environment. The goal of Gnumeric is to be the best possible spreadsheet. We are not attempting to clone existing

[ANNOUNCEMENT] goffice0.10 0.10.28-1

The following packages have been uploaded to the Cygwin distribution: * libgoffice0.10_10-0.10.28-1 * libgoffice0.10-devel-0.10.28-1 * libgoffice0.10-doc-0.10.28-1 * girepository-GOffice0.10-0.10.28-1 * mingw64-i686-goffice0.10-0.10.28-1 * mingw64-x86_64-goffice0.10-0.10.28-1 A set of

[ANNOUNCEMENT] libgsf 1.14.36-1

The following packages have been uploaded to the Cygwin distribution: * libgsf-1.14.36-1 * libgsf-common-1.14.36-1 * libgsf1_114-1.14.36-1 * libgsf1-devel-1.14.36-1 * libgsf1-doc-1.14.36-1 * girepository-Gsf1-1.14.36-1 * gsf-office-thumbnailer-1.14.36-1 * mingw64-i686-libgsf1-1.14.36-1 *

libgsf 1.14.36-1

The following packages have been uploaded to the Cygwin distribution: * libgsf-1.14.36-1 * libgsf-common-1.14.36-1 * libgsf1_114-1.14.36-1 * libgsf1-devel-1.14.36-1 * libgsf1-doc-1.14.36-1 * girepository-Gsf1-1.14.36-1 * gsf-office-thumbnailer-1.14.36-1 * mingw64-i686-libgsf1-1.14.36-1 *