Re: Cygwin man does not recognise PerlRE ?

[Yaakov Selkowitz]

On Fri, 2015-10-16 at 19:33 +0300, Andrey Repin wrote:
> It was bugging me for quite some time now. I don't like POSIX RE - they are
> cumbersome and unwieldy.
> Is there a possibility to build man for Cygwin with PerlRE support?

Presumably that would come via PCRE, which man-db does not currently
support.  Perhaps PTC upstream.

--
Yaakov



--
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

git gui: assertion "font != NULL" failed

[Matt Seitz (matseitz)]

A few days ago, I ran Setup to update my currently installed package, including 
my git packages.  Since then, whenever I run git gui, I get the following error:

$ git gui
assertion "font != NULL" failed: file 
"/usr/src/ports/fontconfig/fontconfig-2.11.1-3.x86_64/src/fontconfig-2.11.1/src/fcmatch.c",
 line 453, function: FcFontRenderPrepare
error: git-gui died of signal 6

cygcheck and xwin logs attached




cygcheck.out
Description: cygcheck.out


XWin.0.log
Description: XWin.0.log


XWin.0.log.old
Description: XWin.0.log.old


XWin.1.log
Description: XWin.1.log


XWin.1.log.old
Description: XWin.1.log.old
--
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: git gui: assertion "font != NULL" failed

[Yaakov Selkowitz]

On Fri, 2015-10-16 at 17:09 +, Matt Seitz (matseitz) wrote:
> A few days ago, I ran Setup to update my currently installed package, 
> including my git packages.  Since then, whenever I run git gui, I get the 
> following error:
> 
> $ git gui
> assertion "font != NULL" failed: file 
> "/usr/src/ports/fontconfig/fontconfig-2.11.1-3.x86_64/src/fontconfig-2.11.1/src/fcmatch.c",
>  line 453, function: FcFontRenderPrepare
> error: git-gui died of signal 6
> 
> cygcheck and xwin logs attached

You don't have any Fontconfig-controlled fonts installed on your system.
On mine, the default seems to be dejavu-fonts, so try installing that,
although xorg-x11-fonts-Type1 might work as well.

--
Yaakov



--
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: setup.exe not logging on Windows 10 with MS accounts

[Warren Young]

On Oct 15, 2015, at 2:29 PM, Warren Young wrote:
> 
> Achim Gratz noted that my default permissions may be weird because I am 
> running with a Microsoft Account rather than a local one.

I just poked a hole in that theory last night: I have a Windows 8 VM at home 
that also uses a MS Account instead of a local one, and its /var/log/setup.log 
*has* been touched recently.

Re: Cygwin man does not recognise PerlRE ?

[Warren Young]

On Oct 16, 2015, at 10:33 AM, Andrey Repin  wrote:
> 
> Is there a possibility to build man for Cygwin with PerlRE support?

I’m curious: what sort of incantations do you frequently give to man which 
involve REs?

Maybe I’m just too old-school, but I wasn’t aware that modern man programs even 
supported REs.  Back when I was a boy, we said “man -k whatsit” and we liked 
it! :)

I think if I wanted to grep man pages with Perl syntax, I’d say

   grep -PRsl whatsit /usr/share/man

Poking around on machines near me, I see Lucifredi’s version of man — which 
doesn’t seem to support regexes — on OS X 10.10, FreeBSD 10.1, and CentOS 5.  
Apparently RHEL moved to man-db in EL6 or EL7, since it’s on an EL7 box nearby.
--
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: [ANNOUNCEMENT] New: gimp-2.8.14-2

[Doug Lewan]

I tried Evolution, but it wasn't obvious how to get it going and I wasn't 
patient. It also loaded lots of extra stuff, including gamin which runs 
gam_server (IIRC) like a service. It was eating CPU on occasion, and I couldn't 
figure out how to stop it, and that made updating CYGWIN difficult if not 
impossible.

However, you're inspiring me to go back and see if I can find anything like a 
HOWTO for Evolution.

-- 
,Doug
Douglas Lewan
Shubert Ticketing
(201) 994-4335

Nonfirstorderizability. It's a thing.


> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Andrey Repin
> Sent: Friday, 2015 October 16 11:44
> To: Yaakov Selkowitz; cygwin@cygwin.com
> Subject: Re: [ANNOUNCEMENT] New: gimp-2.8.14-2
> 
> Greetings, Yaakov Selkowitz!
> 
> >> In the world of windows I use only Outlook (frequently) and The Gimp
> (occasionally).
> >> Having The Gimp under CYGWIN remove all the tiny bits of clumsiness
> that I have now.
> 
> And introduce a new clumsiness in requiring to run X server.
> Sorry, but I prefer native GIMP.
> 
> >> (Now to go to work on Outlook.)
> 
> > I already did; it's called 'evolution', which I use on a daily basis
> for
> > both mail and calendaring.
> 
> Doesn't trump The Bat!…
> 
> 
> --
> With best regards,
> Andrey Repin
> Friday, October 16, 2015 18:42:19
> 
> Sorry for my terrible english...

Re: Cygwin man does not recognise PerlRE ?

[Warren Young]

On Oct 16, 2015, at 2:29 PM, Mike Cappella wrote:
> 
>> On Oct 16, 2015, at 12:18 PM, Yaakov Selkowitz wrote:
>>> 
>>> On Fri, 2015-10-16 at 19:33 +0300, Andrey Repin wrote:
 Is there a possibility to build man for Cygwin with PerlRE support?
>>> 
>>> Presumably that would come via PCRE, which man-db does not currently
>>> support.  Perhaps PTC upstream.
>> 
>> If there were such a mode, would it be allowed to enable it, since that 
>> would effectively put libpcre into Base?
> 
> Maybe someone can rebuild less(1) to build with PCRE, and then you can set 
> MANPAGER=less.

I don’t think Andrey means PCRE when searching the man page he is reading right 
now.  I think he means he wants PCRE support in “man --regex whatsit”.


--
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: Cygwin man does not recognise PerlRE ?

[Warren Young]

On Oct 16, 2015, at 12:18 PM, Yaakov Selkowitz wrote:
> 
> On Fri, 2015-10-16 at 19:33 +0300, Andrey Repin wrote:
>> Is there a possibility to build man for Cygwin with PerlRE support?
> 
> Presumably that would come via PCRE, which man-db does not currently
> support.  Perhaps PTC upstream.

If there were such a mode, would it be allowed to enable it, since that would 
effectively put libpcre into Base?


--
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: Error Installing Cygwin (setup-x86_64.exe & setup-x86) - No setup.ini.sig found.

[Ken Brown]

On 10/16/2015 4:52 PM, Achim Gratz wrote:

Robert Pace writes:

I downloaded the very latest setup-x86_64.exe and setup-x86.exe from
www.cygwin.com yesterday (version 2.872). I started trying to install
the 64bit version of cygwin and selected "download only".  I chose a
mirror from the list, and the download concluded fine.  I then re-ran
the setup application and chose "install from local directory" and
selected the folder which held the downloaded files.  The setup
application then halts installation due to a missing setup.ini.sig.


Could you check if the setup.ini.sig file is just not stored to disk and
that setup would commence installing if you downloaded it manually and
put alongside the setup.ini file?


Is there a new requirement that a local repository has to have a 
signature file?  And does it have to be setup.ini.sig (rather than, for 
example, setup.bz2.sig)?


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: Cygwin man does not recognise PerlRE ?

[Mike Cappella]

> On Oct 16, 2015, at 12:18 PM, Yaakov Selkowitz wrote:
> > 
> > On Fri, 2015-10-16 at 19:33 +0300, Andrey Repin wrote:
> >> Is there a possibility to build man for Cygwin with PerlRE support?
> > 
> > Presumably that would come via PCRE, which man-db does not currently
> > support.  Perhaps PTC upstream.
> 
> If there were such a mode, would it be allowed to enable it, since that would 
> effectively put libpcre into Base?

Maybe someone can rebuild less(1) to build with PCRE, and then you can set 
MANPAGER=less.
--
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: How to correctly rebase?

[Warren Young]

On Oct 16, 2015, at 1:18 AM, Achim Gratz wrote:
> 
> Warren Young writes:
>> It would be nice if rebase were smart enough to look for *.mex and *.oct
> only in known Octave directories, but
>> it isn’t my itch, so I’m not going to be doing anything about it.
> 
> I'll see if that's possible without running yet another find

How about something like 

find /usr -name ${extensions} | grep -vP '(?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: Cygwin man does not recognise PerlRE ?

[Yaakov Selkowitz]

On Fri, 2015-10-16 at 14:19 -0600, Warren Young wrote:
> On Oct 16, 2015, at 12:18 PM, Yaakov Selkowitz wrote:
> > 
> > On Fri, 2015-10-16 at 19:33 +0300, Andrey Repin wrote:
> >> Is there a possibility to build man for Cygwin with PerlRE support?
> > 
> > Presumably that would come via PCRE, which man-db does not currently
> > support.  Perhaps PTC upstream.
> 
> If there were such a mode, would it be allowed to enable it, since that
> would effectively put libpcre into Base?

grep already requires libpcre1.

--
Yaakov



--
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: Error Installing Cygwin (setup-x86_64.exe & setup-x86) - No setup.ini.sig found.

[Achim Gratz]

Robert Pace writes:
> I downloaded the very latest setup-x86_64.exe and setup-x86.exe from
> www.cygwin.com yesterday (version 2.872). I started trying to install
> the 64bit version of cygwin and selected "download only".  I chose a
> mirror from the list, and the download concluded fine.  I then re-ran
> the setup application and chose "install from local directory" and
> selected the folder which held the downloaded files.  The setup
> application then halts installation due to a missing setup.ini.sig.

Could you check if the setup.ini.sig file is just not stored to disk and
that setup would commence installing if you downloaded it manually and
put alongside the setup.ini file?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

--
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: Error Installing Cygwin (setup-x86_64.exe & setup-x86) - No setup.ini.sig found.

[Robert Pace]

I can verify that the setup.ini.sig is not stored in the download
folder.  I earlier today downloaded the setup.ini.sig from the mirror
site and put that file in the mirror folder and it complained that the
setup.ini was corrupt.

On Fri, Oct 16, 2015 at 4:52 PM, Achim Gratz  wrote:
> Robert Pace writes:
>> I downloaded the very latest setup-x86_64.exe and setup-x86.exe from
>> www.cygwin.com yesterday (version 2.872). I started trying to install
>> the 64bit version of cygwin and selected "download only".  I chose a
>> mirror from the list, and the download concluded fine.  I then re-ran
>> the setup application and chose "install from local directory" and
>> selected the folder which held the downloaded files.  The setup
>> application then halts installation due to a missing setup.ini.sig.
>
> Could you check if the setup.ini.sig file is just not stored to disk and
> that setup would commence installing if you downloaded it manually and
> put alongside the setup.ini file?
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> Wavetables for the Terratec KOMPLEXER:
> http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
>
> --
> 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
>



-- 
Robert Pace
Cell: (606) 621-9012
Moore #125 Spatial Data Research Lab
EKU Herbarium Memorial Science #170
robert_pa...@mymail.eku.edu
robert.p...@eku.edu
http://people.eku.edu/pacer/
Richmond, KY
USA
--

--
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: Evolution

[Yaakov Selkowitz]

On Fri, 2015-10-16 at 20:27 +, Doug Lewan wrote:
> It also loaded lots of extra stuff, including gamin which runs
> gam_server (IIRC) like a service. It was eating CPU on occasion,
> and I couldn't figure out how to stop it, and that made updating
> CYGWIN difficult if not impossible.

gamin is a session service; it will exit shortly after the X session
ends.  As for CPU usage, I have the following:

$ cat ~/.gaminrc
fsset ntfs poll 10
fsset vfat none

Obviously this means that gamin will be a bit slower to catch changes,
but that's usually sufficient.

> However, you're inspiring me to go back and see if I can find anything
> like a HOWTO for Evolution.

Make sure you have the cygserver service installed and running, then
start an X session (such as XWin Server or a desktop).  If you want to
use a Google or Windows Live account, first configure those through
Preferences->Online Accounts (in gnome-control-center).  Otherwise, just
run Office->Evolution and follow the wizard to get started.

--
Yaakov



--
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: Xserver corresponds to display :1.0 instead of :0.0

[Markus Hoenicka]

At 2015-10-16 07:41, paul was heard to say:

I have a very simple ~/.startxwinrc:

   xrdb -load $HOME/.Xresources
   xterm -display :0.0 # xterm &
   exec sleep infinity

Recently, I found that the xterm wasn't launching.  I googled, read
some cygwin threads about X authorities, but have to admit, I have a
lot to learn about X windows.  Anyway, since I could open an xterm by
right clicking on the Cygwin/Xserver:1.0 app in the notification area
of Windows 7, I sneakily (OK, it wasn't the craftiest thing in the
world) echo'd $DISPLAY.  Lo, it was 1.0, and the following works fine:

   xterm -display :1.0 &

Yes, I know it says 1.0 in the tip for the Cygwin/Xserver:1.0 app, but
I didn't actually look at that detail until now, as I'm posting.

A google for the following doesn't turn up anything:

   cygwin xterm "-display :0.0" "display :1.0"

I'm wondering if this was a planned change in how X-windows works or
if something is awry with my setup, causing a server with display :0.0
to fail, and making go to :1.0.  I did a browse of the cygin announce
list on gmane (since the X-windows announce list is now obsolete), but
no joy.  And I would have expected anything to show up in my google
search.

Can anyone point me to the description of this change?  If it is not a
deliberate change, what would be a good approach to troubleshoot it?
I have a file ~/.xsession-errors, but it is dated 2015-09-16, and I've
used X-windows plenty since then.



Hi,

you may have a leftover lock file from a crashed X session. Check if 
there is a /tmp/.X0-lock (IIRC) before you start your X server.


regards,
Markus

--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: How to correctly rebase?

[Achim Gratz]

Warren Young  etr-usa.com> writes:
> It would be nice if rebase were smart enough to look for *.mex and *.oct
only in known Octave directories, but
> it isn’t my itch, so I’m not going to be doing anything about it.

I'll see if that's possible without running yet another find  or at least
not running them more than once on the same directory.

> > The following DLLs couldn't be rebased due to errors:
> >  /usr/bin/cygintl-8.dll
> >  /usr/bin/cygiconv-2.dll
> 
> I got similar errors in my testing, though with different libraries.  I
reinstalled those library packages
> and the errors went away.

The most likely source of those errors is that some Cygwin process still
hangs around in the background.  Next up is that the files are inaccessible,
which can be fixed by reinstalling.  Last but not least if BLODA opens the
DLL while rebase is trying to work on it, then rebase will fail as well (if
it's always different DLL that throw the error then that's the most likely
axplanation even).


Regards,
Achim.

Re: How to correctly rebase?

[Dr Rainer Woitok]

Ken,

On Thursday, 2015-10-15 17:10:38 -0400, you wrote:

> ...
> Another possibility is that those DLLs were in use.  Rainer, did you make 
> sure 
> that no Cygwin processes were running other than dash?

Well, at least  I tried to.   I ran "/bin/ps -ef"  and only saw one "ps"
and one "ash" process.

> ...
> No, it's because rebase is called with the -s option, which implies the -d 
> option, which means that it starts at 0x7000 and works down.

Thanks for the explanation.  This had escaped me.

>   Rainer, you 
> can run 'rebase -is' to see the full list of base addresses.

I did, and I think this list os more or less the same as the output from
"rebaslst".  But I'll compare more thoroughly later.  What caught my eye
though is that both lists seemed sorted more or less with respect to de-
scending file names, except for

/usr/bin/cygLLVM-3.1.dll base 0x5ca9 size 0x0128a000  
/home/Rainer/repo/netcdf/bin/cygnetcdf-7.dll base 0x5dd2 size 0x032a  
/usr/bin/cygORBitCosNaming-2-0.dll   base 0x6158 size 0xc000  

All my other local DLLs appear at the very end  of these lists.  Is this
just the way "rebase" works internally or does this indicate a problem?

Talking about problems:  Python still  does not work  (and perhaps other
stuff I just haven't yet tried).  Should I try re-installing Python?

But I would be more at rest if this all would be sort of explainable.

Sincerely,
  Rainer

PS: Please also reply to me personally, as I am currently not subscribed
to this list (though I'm considering to join it,  due to urgent pleas by
others :-)

 --
| Rainer M Woitok| Phone : (+49 60 93) 487 95 95   |
| Kolpingstraße 3| Mobile: (+49 172) 813 6 831 |
| D-63846 Laufach| Mail  : rainer.woi...@gmail.com |
| Germany| |
 --

--
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: How to correctly rebase?

[Ken Brown]

On 10/16/2015 4:49 AM, Dr Rainer Woitok wrote:

Ken,

On Thursday, 2015-10-15 17:10:38 -0400, you wrote:


...
Another possibility is that those DLLs were in use.  Rainer, did you make sure
that no Cygwin processes were running other than dash?


Well, at least  I tried to.   I ran "/bin/ps -ef"  and only saw one "ps"
and one "ash" process.


...
No, it's because rebase is called with the -s option, which implies the -d
option, which means that it starts at 0x7000 and works down.


Thanks for the explanation.  This had escaped me.


   Rainer, you
can run 'rebase -is' to see the full list of base addresses.


I did, and I think this list os more or less the same as the output from
"rebaslst".  But I'll compare more thoroughly later.  What caught my eye
though is that both lists seemed sorted more or less with respect to de-
scending file names, except for

/usr/bin/cygLLVM-3.1.dll base 0x5ca9 size 0x0128a000
/home/Rainer/repo/netcdf/bin/cygnetcdf-7.dll base 0x5dd2 size 0x032a
/usr/bin/cygORBitCosNaming-2-0.dll   base 0x6158 size 0xc000

All my other local DLLs appear at the very end  of these lists.  Is this
just the way "rebase" works internally or does this indicate a problem?


I don't know off the top of my head, but I wouldn't worry about this.


Talking about problems:  Python still  does not work  (and perhaps other
stuff I just haven't yet tried).  Should I try re-installing Python?

But I would be more at rest if this all would be sort of explainable.


As Warren and Achim have both suggested, you may just have too many DLLs for 
32-bit Cygwin.  Can you uninstall some unneeded packages?  Or switch to 64-bit 
Cygwin?


By the way, I don't think you have yet attached cygcheck output as requested in 
http://cygwin.com/problems.html:  "Run cygcheck -s -v -r > cygcheck.out and 
include that file as an attachment in your report.  Please do not compress or 
otherwise encode the output.  Just attach it as a straight text file so that it 
can be easily viewed."  Maybe someone will spot something.


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: Https proxy auth issue with git in cygwin 2.2.1

[Johan Laenen]

Adam Dinwoodie  dinwoodie.org> writes:

> I think I've found the problem, and you're right -- Git has changed the
> way it makes the curl call.  The culprit is commit 5841520b in the
> upstream Git repository, which has the following commit message:
> 
> | http: always use any proxy auth method available
> |
> | We set CURLOPT_PROXYAUTH to use the most secure authentication
> | method available only when the user has set configuration variables
> | to specify a proxy.  However, libcurl also supports specifying a
> | proxy through environment variables.  In that case libcurl defaults
> | to only using the Basic proxy authentication method, because we do
> | not use CURLOPT_PROXYAUTH.
> |
> | Set CURLOPT_PROXYAUTH to always use the most secure authentication
> | method available, even when there is no git configuration telling us
> | to use a proxy. This allows the user to use environment variables to
> | configure a proxy that requires an authentication method different
> | from Basic.
> 
> I can't confirm this is the problem, though, as I don't have a test
> environment that uses NTLM.
> 
> Do you have the ability to either run a test version of Git I can
> produce that patches out this change, or (better) to build Git yourself
> without this patch to see if that is indeed the change that's causing
> the problem?
> 

Hi There,

I can into the exact same problem after upgrading to the latest cygwin version. 

So, following your advice, I took git-2.6.1.tar.gz from github, untarred,
and modified http.c:

$ diff git-2.6.1/http.c t/git-2.6.1/http.c
466,467c466,468
< if (curl_http_proxy) {
< curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
---
>   if (curl_http_proxy) {
>   curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
>   }
469c470
< curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
---
>   curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
471d471
< }

One make configure, ./configure, make and make install I can confirm that
unpatching the change undoes the problem :)

> Adam
> 
> 


Johan


--
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: [ANNOUNCEMENT] New: gimp-2.8.14-2

[Doug Lewan]

Whoo hoo!

In the world of windows I use only Outlook (frequently) and The Gimp 
(occasionally). Having The Gimp under CYGWIN remove all the tiny bits of 
clumsiness that I have now.

Thanks. (Now to go to work on Outlook.)

-- 
,Doug
Douglas Lewan
Shubert Ticketing
(201) 994-4335

Nonfirstorderizability. It's a thing.


> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Yaakov Selkowitz
> Sent: Thursday, 2015 October 15 13:35
> To: cygwin@cygwin.com
> Subject: [ANNOUNCEMENT] New: gimp-2.8.14-2
> 
> The following packages have been added to the Cygwin distribution:
> 
> * gimp-2.8.14-2
> * gimp-devel-2.8.14-2
> * gimp-doc-2.8.14-2
> * gimp-help-*-2.8.1-1
> * gimp-python-2.8.14-2
> * libbabl0.1_0-0.1.12-1
> * libbabl-devel-0.1.12-1
> * gegl-0.2.0-7
> * libgegl0.2_0-0.2.0-7
> * libgegl0.2-devel-0.2.0-7
> * libopenraw1-0.0.9-3
> * libopenraw-devel-0.0.9-3
> * libopenrawgnome1-0.0.9-3
> * libopenrawgnome-devel-0.0.9-3
> * gdk-pixbuf2.0-openraw-0.0.9-3
> 
> The GNU Image Manipulation Program is a multi-platform photo
> manipulation tool. It can be used as a simple paint program, an expert
> quality photo retouching program, an online batch processing system, a
> mass production image renderer, an image format converter, etc.  GIMP
> is
> expandable and extensible.  It is designed to be augmented with plug-
> ins
> and extensions to do just about anything. The advanced scripting
> interface allows everything from the simplest task to the most complex
> image manipulation procedures to be easily scripted.
> 
> --
> Yaakov
> 
> --
> 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: How to correctly rebase?

[Ken Brown]

On 10/16/2015 8:58 AM, Ken Brown wrote:

On 10/16/2015 4:49 AM, Dr Rainer Woitok wrote:

Ken,

On Thursday, 2015-10-15 17:10:38 -0400, you wrote:


...
Another possibility is that those DLLs were in use.  Rainer, did you make sure
that no Cygwin processes were running other than dash?


Well, at least  I tried to.   I ran "/bin/ps -ef"  and only saw one "ps"
and one "ash" process.


...
No, it's because rebase is called with the -s option, which implies the -d
option, which means that it starts at 0x7000 and works down.


Thanks for the explanation.  This had escaped me.


   Rainer, you
can run 'rebase -is' to see the full list of base addresses.


I did, and I think this list os more or less the same as the output from
"rebaslst".  But I'll compare more thoroughly later.  What caught my eye
though is that both lists seemed sorted more or less with respect to de-
scending file names, except for

/usr/bin/cygLLVM-3.1.dll base 0x5ca9 size 0x0128a000
/home/Rainer/repo/netcdf/bin/cygnetcdf-7.dll base 0x5dd2 size 0x032a
/usr/bin/cygORBitCosNaming-2-0.dll   base 0x6158 size 0xc000

All my other local DLLs appear at the very end  of these lists.  Is this
just the way "rebase" works internally or does this indicate a problem?


I don't know off the top of my head, but I wouldn't worry about this.


Talking about problems:  Python still  does not work  (and perhaps other
stuff I just haven't yet tried).  Should I try re-installing Python?

But I would be more at rest if this all would be sort of explainable.


As Warren and Achim have both suggested, you may just have too many DLLs for
32-bit Cygwin.  Can you uninstall some unneeded packages?  Or switch to 64-bit
Cygwin?

By the way, I don't think you have yet attached cygcheck output as requested in
http://cygwin.com/problems.html:  "Run cygcheck -s -v -r > cygcheck.out and
include that file as an attachment in your report.  Please do not compress or
otherwise encode the output.  Just attach it as a straight text file so that it
can be easily viewed."  Maybe someone will spot something.


I have one other suggestion: If you rebase because of a fork failure, reboot 
before retrying the application that failed.  I just had the following experience:


I was running emacs on my 32-bit Cygwin installation and got a fork failure 
involving /usr/bin/cygMagickCore-6.Q16-2.dll.  Windows had loaded this DLL at a 
very low address.  I did a full rebase and restarted emacs, but that DLL was 
still loaded at a low address, even though rebasing had put the base address at 
a very reasonable 0x6e55.  [You can see where a DLL is loaded in a process's 
address space by examining the file /proc//maps.]  I then rebooted, 
restarted emacs, and verified that the DLL was now loaded at 0x6e55, as 
expected.


I've seen this happen many times.  I don't know the explanation, but my guess is 
that Windows does some caching that causes it to try to load a given DLL at the 
same base address as it used the last time that DLL was loaded.  Rebooting 
clears the cache.  Can someone who understands this stuff confirm my guess or 
provide a better explanation?


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: How to correctly rebase?

[cyg Simple]

On 10/16/2015 11:07 AM, Ken Brown wrote:
> On 10/16/2015 8:58 AM, Ken Brown wrote:
>> On 10/16/2015 4:49 AM, Dr Rainer Woitok wrote:
>>> Ken,
>>>
>>> On Thursday, 2015-10-15 17:10:38 -0400, you wrote:
>>>
 ...
 Another possibility is that those DLLs were in use.  Rainer, did you
 make sure
 that no Cygwin processes were running other than dash?
>>>
>>> Well, at least  I tried to.   I ran "/bin/ps -ef"  and only saw one "ps"
>>> and one "ash" process.
>>>
 ...
 No, it's because rebase is called with the -s option, which implies
 the -d
 option, which means that it starts at 0x7000 and works down.
>>>
>>> Thanks for the explanation.  This had escaped me.
>>>
   
 Rainer, you
 can run 'rebase -is' to see the full list of base addresses.
>>>
>>> I did, and I think this list os more or less the same as the output from
>>> "rebaslst".  But I'll compare more thoroughly later.  What caught my eye
>>> though is that both lists seemed sorted more or less with respect to de-
>>> scending file names, except for
>>>
>>> /usr/bin/cygLLVM-3.1.dll base 0x5ca9 size
>>> 0x0128a000
>>> /home/Rainer/repo/netcdf/bin/cygnetcdf-7.dll base 0x5dd2 size
>>> 0x032a
>>> /usr/bin/cygORBitCosNaming-2-0.dll   base 0x6158 size
>>> 0xc000
>>>
>>> All my other local DLLs appear at the very end  of these lists.  Is this
>>> just the way "rebase" works internally or does this indicate a problem?
>>
>> I don't know off the top of my head, but I wouldn't worry about this.
>>>
>>> Talking about problems:  Python still  does not work  (and perhaps other
>>> stuff I just haven't yet tried).  Should I try re-installing Python?
>>>
>>> But I would be more at rest if this all would be sort of explainable.
>>
>> As Warren and Achim have both suggested, you may just have too many
>> DLLs for
>> 32-bit Cygwin.  Can you uninstall some unneeded packages?  Or switch
>> to 64-bit
>> Cygwin?
>>
>> By the way, I don't think you have yet attached cygcheck output as
>> requested in
>> http://cygwin.com/problems.html:  "Run cygcheck -s -v -r >
>> cygcheck.out and
>> include that file as an attachment in your report.  Please do not
>> compress or
>> otherwise encode the output.  Just attach it as a straight text file
>> so that it
>> can be easily viewed."  Maybe someone will spot something.
> 
> I have one other suggestion: If you rebase because of a fork failure,
> reboot before retrying the application that failed.  I just had the
> following experience:
> 
> I was running emacs on my 32-bit Cygwin installation and got a fork
> failure involving /usr/bin/cygMagickCore-6.Q16-2.dll.  Windows had
> loaded this DLL at a very low address.  I did a full rebase and
> restarted emacs, but that DLL was still loaded at a low address, even
> though rebasing had put the base address at a very reasonable
> 0x6e55.  [You can see where a DLL is loaded in a process's address
> space by examining the file /proc//maps.]  I then rebooted,
> restarted emacs, and verified that the DLL was now loaded at 0x6e55,
> as expected.
> 
> I've seen this happen many times.  I don't know the explanation, but my
> guess is that Windows does some caching that causes it to try to load a
> given DLL at the same base address as it used the last time that DLL was
> loaded.  Rebooting clears the cache.  Can someone who understands this
> stuff confirm my guess or provide a better explanation?

Could it be something similar to
http://windowsitpro.com/systems-management/how-can-i-stop-windows-caching-dll-file-after-i-close-program-was-accessing-it?

-- 
cyg Simple

--
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: [ANNOUNCEMENT] New: gimp-2.8.14-2

[Yaakov Selkowitz]

On Fri, 2015-10-16 at 14:04 +, Doug Lewan wrote:
> Whoo hoo!
> 
> In the world of windows I use only Outlook (frequently) and The Gimp 
> (occasionally).
> Having The Gimp under CYGWIN remove all the tiny bits of clumsiness that I 
> have now.
> 
> Thanks. 

You're welcome.

> (Now to go to work on Outlook.)

I already did; it's called 'evolution', which I use on a daily basis for
both mail and calendaring.

--
Yaakov




--
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: How to correctly rebase?

[Ken Brown]

On 10/16/2015 11:15 AM, cyg Simple wrote:

On 10/16/2015 11:07 AM, Ken Brown wrote:

I've seen this happen many times.  I don't know the explanation, but my
guess is that Windows does some caching that causes it to try to load a
given DLL at the same base address as it used the last time that DLL was
loaded.  Rebooting clears the cache.  Can someone who understands this
stuff confirm my guess or provide a better explanation?


Could it be something similar to
http://windowsitpro.com/systems-management/how-can-i-stop-windows-caching-dll-file-after-i-close-program-was-accessing-it?


That article only talks about shell-extension DLLs, but it does sound similar.

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

Error Installing Cygwin (setup-x86_64.exe & setup-x86) - No setup.ini.sig found.

[Robert Pace]

Hi all,

I downloaded the very latest setup-x86_64.exe and setup-x86.exe from
www.cygwin.com yesterday (version 2.872). I started trying to install
the 64bit version of cygwin and selected "download only".  I chose a
mirror from the list, and the download concluded fine.  I then re-ran
the setup application and chose "install from local directory" and
selected the folder which held the downloaded files.  The setup
application then halts installation due to a missing setup.ini.sig.  I
downloaded the setup application again, and chose a different mirror
site and and had the setup application save to a different folder.
Again the installation failed due to setup.ini.sig.  I tried three
more different mirror sites with the same problem.  I then tried using
the 32bit setup application and again received the same missing
setup.ini.sig error.  I read that one can also try running the setup
application with the -X argument which setup the subfolders for the
cygwin directory but did not populate them with any of the packages.

I am running Windows 10 Professional (64bit) build 10565.

I did install an older version of Cygwin which I had downloaded back
in January 2015 without issue.  Indicating that there is an issue with
the latest cygwin setup application.

--
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: Jemalloc under CYGWIN

[Yucong Sun]

Hi,

Throught some frustrating and furious debugging I now understand the
core issue here.  CYGWIN calls malloc provided by jemalloc during
initializations,  which in turn calls pthreads functions, which in
turn uses malloc, which also uses pthreads, causing a deadlock.

Now,  is there anyway to workaround this issue?

On Wed, Oct 7, 2015 at 7:17 PM, Yucong Sun  wrote:
> Hi there,
>
> I'm trying to make jemalloc work with CYGWIN. and I've been meeting
> with a mysterious deadlock issue on startup (from CYGWIN's
> malloc-wrapper to jemalloc and pthread_mutex_lock get deadlock).
>
> Has anyone else tried this?
>
> Thanks

--
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: How to correctly rebase?

[Andrey Repin]

Greetings, Ken Brown!

> I have one other suggestion: If you rebase because of a fork failure, reboot
> before retrying the application that failed.  I just had the following 
> experience:

> I was running emacs on my 32-bit Cygwin installation and got a fork failure 
> involving /usr/bin/cygMagickCore-6.Q16-2.dll.  Windows had loaded this DLL at 
> a
> very low address.  I did a full rebase and restarted emacs, but that DLL was 
> still loaded at a low address, even though rebasing had put the base address 
> at
> a very reasonable 0x6e55.  [You can see where a DLL is loaded in a 
> process's
> address space by examining the file /proc//maps.]  I then rebooted, 
> restarted emacs, and verified that the DLL was now loaded at 0x6e55, as 
> expected.

> I've seen this happen many times.  I don't know the explanation, but my guess 
> is
> that Windows does some caching that causes it to try to load a given DLL at 
> the
> same base address as it used the last time that DLL was loaded.  Rebooting 
> clears the cache.  Can someone who understands this stuff confirm my guess or 
> provide a better explanation?

prefetch/superfetch ?
I normally disable this crap. I can live with boot times 15 seconds longer,
and these kinds of services proved to slow down the system over the years at
all times, no matter what is claimed in advertising.


-- 
With best regards,
Andrey Repin
Friday, October 16, 2015 18:40:11

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: [ANNOUNCEMENT] New: gimp-2.8.14-2

[Andrey Repin]

Greetings, Yaakov Selkowitz!

>> In the world of windows I use only Outlook (frequently) and The Gimp 
>> (occasionally).
>> Having The Gimp under CYGWIN remove all the tiny bits of clumsiness that I 
>> have now.

And introduce a new clumsiness in requiring to run X server.
Sorry, but I prefer native GIMP.

>> (Now to go to work on Outlook.)

> I already did; it's called 'evolution', which I use on a daily basis for
> both mail and calendaring.

Doesn't trump The Bat!…


-- 
With best regards,
Andrey Repin
Friday, October 16, 2015 18:42:19

Sorry for my terrible english...

Re: Error Installing Cygwin (setup-x86_64.exe & setup-x86) - No setup.ini.sig found.

[Andrey Repin]

Greetings, Robert Pace!

> I downloaded the very latest setup-x86_64.exe and setup-x86.exe from
> www.cygwin.com yesterday (version 2.872). I started trying to install
> the 64bit version of cygwin and selected "download only".  I chose a
> mirror from the list, and the download concluded fine.  I then re-ran
> the setup application and chose "install from local directory" and
> selected the folder which held the downloaded files.  The setup
> application then halts installation due to a missing setup.ini.sig.  I
> downloaded the setup application again, and chose a different mirror
> site and and had the setup application save to a different folder.
> Again the installation failed due to setup.ini.sig.  I tried three
> more different mirror sites with the same problem.  I then tried using
> the 32bit setup application and again received the same missing
> setup.ini.sig error.  I read that one can also try running the setup
> application with the -X argument which setup the subfolders for the
> cygwin directory but did not populate them with any of the packages.

> I am running Windows 10 Professional (64bit) build 10565.

> I did install an older version of Cygwin which I had downloaded back
> in January 2015 without issue.  Indicating that there is an issue with
> the latest cygwin setup application.

I can confirm the issue.

---
Cygwin Setup
---
Unable to get
...\cygwin\install/http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwinports%2f//x86_64/setup.ini.sig
from 
---
ОК   
---


-- 
With best regards,
Andrey Repin
Friday, October 16, 2015 18:44:11

Sorry for my terrible english...

Re: Cygwin man does not recognise PerlRE ?

[Andrey Repin]

Greetings, Yaakov Selkowitz!

>> It was bugging me for quite some time now. I don't like POSIX RE - they are
>> cumbersome and unwieldy.
>> Is there a possibility to build man for Cygwin with PerlRE support?

> Presumably that would come via PCRE, which man-db does not currently
> support.  Perhaps PTC upstream.

All my Linux boxes recognize PerlRE in man. >.<
Given, they are all Debian based... And most of them are Ubuntu. I don't know
how it is widespread.


-- 
With best regards,
Andrey Repin
Saturday, October 17, 2015 03:16: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: Cygwin man does not recognise PerlRE ?

[Andrey Repin]

Greetings, Warren Young!

> On Oct 16, 2015, at 10:33 AM, Andrey Repin  wrote:
>> 
>> Is there a possibility to build man for Cygwin with PerlRE support?

> I’m curious: what sort of incantations do you frequently give to man which 
> involve REs?

Typical ones. F.e.

^\s+\b

to quickly find term references.

> Maybe I’m just too old-school, but I wasn’t aware that modern man programs
> even supported REs.  Back when I was a boy, we said “man -k whatsit” and we 
> liked it! :)

> I think if I wanted to grep man pages with Perl syntax, I’d say

>grep -PRsl whatsit /usr/share/man

> Poking around on machines near me, I see Lucifredi’s version of man — which
> doesn’t seem to support regexes — on OS X 10.10, FreeBSD 10.1, and CentOS 5.
> Apparently RHEL moved to man-db in EL6 or EL7, since it’s on an EL7 box 
> nearby.


-- 
With best regards,
Andrey Repin
Saturday, October 17, 2015 03:18:02

Sorry for my terrible english...

Re: Cygwin man does not recognise PerlRE ?

[Andrey Repin]

Greetings, Warren Young!

> Is there a possibility to build man for Cygwin with PerlRE support?
 
 Presumably that would come via PCRE, which man-db does not currently
 support.  Perhaps PTC upstream.
>>> 
>>> If there were such a mode, would it be allowed to enable it, since that 
>>> would effectively put libpcre into Base?
>> 
>> Maybe someone can rebuild less(1) to build with PCRE, and then you can set 
>> MANPAGER=less.

> I don’t think Andrey means PCRE when searching the man page he is reading
> right now.

But I did mean exactly that.
Sorry, probably I should have been clearer. And, well, think my question more
thoroughly.
It seems like Mike's right, and the actual culprit is "less", rather than man.


-- 
With best regards,
Andrey Repin
Saturday, October 17, 2015 03:24:49

Sorry for my terrible english...

Re: Xserver corresponds to display :1.0 instead of :0.0

[paul]

Markus Hoenicka  mhoenicka.de> writes:
> you may have a leftover lock file from a crashed X session. Check if
> there is a /tmp/.X0-lock (IIRC) before you start your X server.

Thank you, Markus.  That was *exactly* the problem, and removing the
lock file solved it.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Cygwin man does not recognise PerlRE ?

[Andrey Repin]

Greetings, All!

It was bugging me for quite some time now. I don't like POSIX RE - they are
cumbersome and unwieldy.
Is there a possibility to build man for Cygwin with PerlRE support?


-- 
With best regards,
Andrey Repin
Friday, October 16, 2015 17:58:20

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