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 s
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 appr
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 work
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 leas
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 “interoperability”?
>
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
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 approache
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 na
> 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 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.,
gi
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
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. Specifically,
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 o
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...
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 Mercurial: arbitrary code execut
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 u
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
>>> /var/log/setup.log.full
>>
>>
>> Mi M
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 18:4
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
>> zp_fontconfig_cache_1.sh exit code 2
>
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 pthread_at
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
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 conv
> 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 I
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
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
Cygwin
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 Foundatio
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 projec
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
inclu
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 which
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 certain
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 path
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 do
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 Cygwin/X with a
>> window manager (dw
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 otherw
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 my
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 conf
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 migrate
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
> >>inst
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
-Origina
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
> > kern
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. I
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 prob
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
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
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 small.
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.
>
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 the
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 w
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(&att);
> if (stat != 0)
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).
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 c
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 proce
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 worked
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 Mercur
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 applicati
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 document-ce
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
* mingw64-x
57 matches
Mail list logo
