Plans to update meson version?

[Dave Trombley via Cygwin]

Meson appears to be two majore versions behind in cygwin (1.2.3 is latest
available, 1.4.0 was released mid-March this year).

Major projects are starting to not be compilable on Cygwin, consequently,
short of manually building a custom meson that is up to date (for example,
libcairo requires 1.3).

Are there plans to update this at some point?


Thanks,
-David

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

Signature files missing

[dave--- via Cygwin]

.sig files seem to have gone missing from (at least some) mirrors.

e.g. https://mirrors.kernel.org/sourceware/cygwin/x86_64/

--
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: newlib-cygwin.git repository: Switching "master" to "main"

[Dave McGuire via Cygwin]

On 1/13/23 14:57, Adam Dinwoodie wrote:

On Fri, Jan 13, 2023 at 02:23:44PM -0500, Mike Frysinger via Cygwin wrote:

thanks for doing this!
-mike


Seconded!  This clearly isn't going to solve racism in a single step,
but making our community that bit more welcoming -- particularly when
the cost of the change is essentially zero -- has to be a positive move.


  You guys have GOT to be kidding me.

--
Dave McGuire, AK4HZ
New Kensington, PA


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

Possible cygwin scp bug

[Knight, Dave]

I am running cygwin virtualbox running a WinDev2206Eval "appliance" (.ova
from microsoft).  Everything else I've tested so far in cygwin runs as
expected except scp when the  file path is an absolute path, e.g.
/tmp/foo.  Scp  references to that file using a relative path, e.g.
../../tmp/foo, work fine.  For example:

$ ls > /tmp/foo   # create a /tmp/file
$ ls -l /tmp/foo
$ scp /tmp/foo bcserver:foobar  # fails with /tmp/foo "file not found"
$ pwd# (CWD is /Users/dmk)
$ scp ../../tmp/foo bcserver:foobar   # this works
$ cd /tmp
$ scp foo bcserver:foobar   # this also works

Please see the attached (script) log file scp.log for the actual results
using these commands.
See also the attached cygcheck.out file.

Note that:

  1 -  absolute paths work OK for an scp  pathname

  2 - the "scp /tmp/foo bcserver:foobar" command works OK in win11's
PowerShell

  3 - the scp target host (bcserver) is a FreeBSD 12 OS running in a
TrueNAS "jail".
Script started on 2022-07-16 05:37:23-07:00 [TERM="xterm" TTY="/dev/pty0" COLUMNS="80" LINES="24"]
[?2004h]0;~

dmk@WinDev2206Eval ~

$ which scp
[?2004l
/cygdrive/c/Windows/System32/OpenSSH/scp
[?2004h]0;~

dmk@WinDev2206Eval ~

$ ls
[?2004l
cygcheck.out   scp.log		   tst_ctlm	 tst_rep   tst_tag%bar
dailyPrayers%  test_DOSfmt	   tst_info	 tst_rep%  tst_tag%foo
foo	   testing		   tst_info%xxx  tst_rep%foo
foo11138   testing.standalone  tst_misc	 tst_rep%foo%
foo3162tst_bug		   tst_ncoAll	 tst_tag
[?2004h]0;~

dmk@WinDev2206Eval ~

$ ls > /tmp/foo
[?2004l
[?2004h]0;~

dmk@WinDev2206Eval ~

$ ls -l /tmp/foo
[?2004l
-rw-r--r-- 1 dmk None 228 Jul 16 05:37 /tmp/foo
[?2004h]0;~

dmk@WinDev2206Eval ~

$ scp /tmp/foo bcserver:foobar
[?2004l
[?25h/tmp/foo: No such file or directory
[?2004h]0;~

dmk@WinDev2206Eval ~

$ pwd
[?2004l
/home/dmk
[?2004h]0;~

dmk@WinDev2206Eval ~

$ scp ../../tmp/foo bcserver:foobar
[?2004l
[?25hfoo 0%0 0.0KB/s   --:-- ETA
foo   100%  228 7.2KB/s   00:00
[?2004h]0;~

dmk@WinDev2206Eval ~

$ cd /tmp
[?2004l
[?2004h]0;/tmp

dmk@WinDev2206Eval /tmp

$ scp foo bcserver:foobar
[?2004l
[?25hfoo 0%0 0.0KB/s   --:-- ETA
foo   100%  22814.2KB/s   00:00
[?2004h]0;/tmp

dmk@WinDev2206Eval /tmp

$ ssh bcserverer ls -l foobar
[?2004l
[?25h-rw-r--r--  1 dmk  dmk  228 Jul 16 08:39 foobar
[?2004h]0;/tmp

dmk@WinDev2206Eval /tmp

$ [?2004l

exit

Script done on 2022-07-16 05:40:24-07:00 [COMMAND_EXIT_CODE="0"]


cygcheck.out
Description: Binary data

-- 
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: EXT: Re: cygpath -u converts quoted UNC paths to local

[Garber, Dave (BHGE, Non-GE)]

Not completely the shell.

From a Windows command prompt:
c:\Apps\cygwin64\bin\cygpath.exe  -u 
\\123.456.789.321\wwwroot\ccenter\bin\online.sh
//123.456.789.321/wwwroot/ccenter/bin/online.sh

c:\Apps\cygwin64\bin\cygpath.exe  -u 
"\\123.456.789.321\wwwroot\ccenter\bin\online.sh"
/cygdrive/c/123.456.789.321/wwwroot/ccenter/bin/online.sh

c:\Apps\cygwin64\bin\cygpath.exe  -u 
"\\\123.456.789.321\wwwroot\ccenter\bin\online.sh"
//123.456.789.321/wwwroot/ccenter/bin/online.sh

c:\Apps\cygwin64\bin\cygpath.exe  -u 
"123.456.789.321\wwwroot\ccenter\bin\online.sh"
//123.456.789.321/wwwroot/ccenter/bin/online.sh

Looks like cygpath is doing something different when the argument is enclosed 
in quotes (same behavior if single-quote ' is used).
 
> -Original Message-
> From: cygwin-ow...@cygwin.com  On Behalf
> Of Achim Gratz
> Sent: Wednesday, April 03, 2019 1:12 PM
> To: cygwin@cygwin.com
> Subject: EXT: Re: cygpath -u converts quoted UNC paths to local
> 
> Andrey Repin writes:
> > This can be considered "working by design", but it really imposes some
> > serious restrictions on interoperability with Cygwin, that I think can be
> avoided.
> 
> But cygpath never sees the quotes, so whatever is done to the path that it
> gets is actually the work of your shell.  In other words, you need to shell-
> quote the backslashes as appropriate for your shell.
> 
> 
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk
> Blofeld]>+
> 
> DIY Stuff:
> http://Synth.Stromeko.net/DIY.html
> 
> --
> 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


--
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: EXT: Re: ps -W now showing STIME Dec 31

[Garber, Dave (BHGE, Non-GE)]

> -Original Message-
> From: cygwin-ow...@cygwin.com  On Behalf
> Of Corinna Vinschen
> Sent: Thursday, March 21, 2019 10:53 AM
> To: cygwin@cygwin.com
> Subject: EXT: Re: ps -W now showing STIME Dec 31
> 
> On Mar 21 08:07, Brian Inglis wrote:
> > With latest Cygwin ps -W is now showing STIME Dec 31 for Windows
> > startup processes - these should be limited to actual start or uptime if
> possible.
> 
> It's not possible.  Starttime requires ability to open process.


Run from an elevated shell it shows correctly.

But Windows command 'wmic process get name, creationdate' in a non-elevated 
command prompt also works.  So it looks like it should be possible.

> 
> 
> Corinna
> 
> --
> Corinna Vinschen
> Cygwin Maintainer

RE: 2 [main] bash 13792 find_fast_cwd: WARNING

[Dave Barker]

Thank you, an unbelievably quick response excellent English

Regards

Dave

-Original Message-
From: Andrey Repin [mailto:anrdae...@yandex.ru] 
Sent: 23 December 2018 22:51
To: Dave Barker; cygwin@cygwin.com
Subject: Re: 2 [main] bash 13792 find_fast_cwd: WARNING

Greetings, Dave Barker!

>   Hi, I'm trying to unbrick a Samsung Galaxy Ace S5830I and received
> this message

>  

> 2 [main] bash 13792 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
> pointer.  Please report this problem to

> the public mailing list cygwin@cygwin.com

>  

> Any help would be appreciated

This is merely a warning, which is also an indication that your Cygwin
installation is very old.
The problem was resolved over a decade ago.
For details, see
https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings


-- 
With best regards,
Andrey Repin
Monday, December 24, 2018 1:50:00

Sorry for my terrible english...


---
This email has been checked for viruses by AVG.
https://www.avg.com


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

2 [main] bash 13792 find_fast_cwd: WARNING

[Dave Barker]

  Hi, I'm trying to unbrick a Samsung Galaxy Ace S5830I and received
this message

 

2 [main] bash 13792 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer.  Please report this problem to

the public mailing list cygwin@cygwin.com

 

Any help would be appreciated

 

Dave



---
This email has been checked for viruses by AVG.
https://www.avg.com

--
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: update batch file

[Dave Caswell]

On Mon, Apr 30, 2018 at 2:33 AM, Vlado  wrote:
> On 30.4.2018 3:57, Dave Caswell wrote:
>>
>> Has anyone created a batch file that stops the cygwin services, runs
>> setup to get updates in the background, and then restarts the
>> services??
>
>
> Hi Dave.
>
> I created similar script:
> https://gist.github.com/Vlado-99/1d59bf05b70481377ff90bb53e13bb2d
>
> Add more services as You wish.
> Add --quiet-mode and (probably) --upgrade-also to %SETUP%.exe (line 289).

Thank You!   That's just the sort of script I was hoping to find.

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

update batch file

[Dave Caswell]

Has anyone created a batch file that stops the cygwin services, runs
setup to get updates in the background, and then restarts the
services??

Doing it manually, I occasionally forget to restart the services and
things stop working until I remember to start them up  again.

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: Bug in Python3 ('tempfile', 'subprocess', '_hashlib')

[Dave Caswell]

On Thu, Apr 5, 2018 at 7:14 PM, Giuseppe Scelsi
 wrote:
> Hi,
>
> Using freshly-updated Cygwin 64-bit under Windows 7 Enterprise Ver 6.1
> and Python 3 version 3.6.4.
>
> The execution of the following script:
>
> import subprocess
> import _hashlib
> import _sha3
> subprocess.run('pwd')
>
> always results in 'BlockingIOError: [Errno 11] Resource temporarily
> unavailable'.
>
> I saw this error first in a script that imported 'tempfile' together
> with 'subprocess' (in any order):
>
> import subprocess
> import tempfile
> subprocess.run('pwd')
>
> I then managed to narrow down the problem to the '_sha3' module.
> Notice that you need to import both '_hashlib' and '_sha3' *in that
> order*.  If I swap the order and import '_sha3' before '_hashlib', the
> error becomes sporadic, sometimes it happens and sometimes not.
>
> This problem makes it impossible to use 'tempfile' and 'subprocess' in
> the same script.  My workaround is currently to disable '_sha3' in
> '/lib/python3.6/hashlib.py' by adding at line 62:
>
> __always_supported = __always_supported[0:8]
>
> This problem only happens in Cygwin 64, 32-bit Cygwin works ok.
>
> Can anyone reproduce this problem?
>
> Best regards,
>
> Giuseppe
>

Tried to reproduce:

davec@SodiumWin ~/tmp
$ cat py3t.py
#!/usr/bin/python3

import subprocess
import _hashlib
import _sha3
subprocess.run('pwd')

davec@SodiumWin ~/tmp
$ ./py3t.py
/home/davec/tmp

Everything seems to work OK for me.  This is with a recently updated Cygwin 64.

--
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: Run command in new window

[Dave Caswell]

> and for some reason any spaces must be quoted - not escaped - these work:
>
>cygstart bash -c '"echo 1;read"'
>cygstart bash -c "'echo 1;read'"
>
> these fail:
>
>cygstart bash -c 'echo\ 1;read'
>cygstart bash -c "echo\ 1;read"


The '-v' option to cygstart gives the key to understanding this by
showing what actually gets passed along by cygstart.
WORKS:
davec@SodiumWin ~
$ cygstart -v bash -c " ' echo  TT; sleep 5 ' "
ShellExecute(NULL, "(null)", "bash", "-c  ' echo  TT; sleep 5 ' ", "(null)", 1)
The quotes surrounding the argument to -c get passed along to the executed bash.

WORKS:
davec@SodiumWin ~
$  cygstart -v bash -c '"echo 1;read"'
ShellExecute(NULL, "(null)", "bash", "-c "echo 1;read"", "(null)", 1)
Same here, the echo and read are both contained in one argument to -c.

DOES NOT WORK
davec@SodiumWin ~
$ cygstart -v bash -c 'echo\ 1;read'
ShellExecute(NULL, "(null)", "bash", "-c echo\ 1;read", "(null)", 1)
Without the quotes to group the echo and read together, when the
executed bash breaks the line up into words, the -c only sees echo\ as
its command.

WORKS:
davec@SodiumWin ~
$ cygstart -v bash -c \'echo 1\;read \'
ShellExecute(NULL, "(null)", "bash", "-c 'echo 1;read '", "(null)", 1)
By escaping the quotes and semicolon so they get passed along intact,
the executed bash also gets an intact command string.

Does this help at all?

--
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: Run command in new window

[Dave Caswell]

On Sun, Dec 24, 2017 at 9:34 PM, Steven Penny  wrote:
>
> yes, that is good if you want to use a script - but a command does not work:
>
>cygstart bash -c 'echo hello; sleep 5'
>
Ah, OK.  Here you go:

davec@SodiumWin ~
$ cygstart /usr/bin/bash '-c "echo hello; sleep 5"'

I wish I could explain just why this quotation pattern works here.  A
long time ago I found that dicking around with the quotes could often
get things working faster than trying to understand it in detail.

--
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: Run command in new window

[Dave Caswell]

On Sun, Dec 24, 2017 at 8:50 PM, Steven Penny  wrote:
> On Mon, 25 Dec 2017 06:28:50, Andrey Repin wrote:
>>
>> The usual way - prevent the closing of the new window.
>> I.e. by adding a sleep.
>
>
> no, that doesnt work
>
> have you tried it?
>
> if so provide sample command

Here's an example:

davec@SodiumWin ~
$ cygstart bash -e TT

davec@SodiumWin ~
$ cat TT
#! /usr/bin/bash

echo TEST
sleep 240

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

problem with gnupg2 not prompting for passphrase

[Garber, Dave (GE Oil & Gas, Non-GE)]

> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of jeff
> Sent: Tuesday, July 11, 2017 1:56 PM
> To: cygwin@cygwin.com
> Subject: EXT: Re: problem with gnupg2 not prompting for passphrase
> 
> On 7/11/2017 10:51 AM, Brian Inglis wrote:
> > On 2017-07-10 23:07, Thomas Wolff wrote:
> >> Am 11.07.2017 um 00:38 schrieb jeff:
> >>> On 7/10/2017 1:21 PM, Achim Gratz wrote:
>  jeff writes:
> > jeff_xeon:/cygdrive/u:503: gpg2 --output fred.good --decrypt
> > fred.gpg
> > gpg: encrypted with 4096-bit RSA key, ID A3791E7DD935A424, created
> > 2013-03-21
> >"Jeff Deifik "
> > gpg: public key decryption failed: No such device or address
> > gpg: decryption failed: No secret key
> >
> > I have uninstalled the standalone version of gnupg2 before I did this.
> > It seems most likely that the version of gpg2 being invoked is a
> > cygwin version.
>  It fails to find your private key, so it is quite obviously not in
>  a place where gpg2 expects to find it.
> >>> I have my keys stored in $HOME/.gnupg which is where gnupg v1
> expects them.
> >
> > gnupg2 uses the same --homedir paths, $GNUPGHOME env var, native
> > Windows reg key, and native Windows portable apps homedir as gnupg1.
> >
> >> Just guessing: Some software does not look in $HOME for config files (e.g.
> >> openssh) but expects them in /home/...
> >
> > OpenSSH expects user config files in ~/.ssh/ where ~ is $HOME, or the
> > home directory from "getent passwd $LOGNAME", which defaults to /.
> >
> > They'd better expect $HOME, not /home/$LOGNAME, as $HOME could
> also be
> > /u/$LOGNAME, /mnt/nfs/OrkeyDorkey, or /mnt/Network\ Users/Orkey\
> > Dorkey! ;^>
> >
> 
> The problem almost certainly lies with pinentry. It seems to be a new feature

See https://sourceware.org/ml/cygwin/2017-07/msg00100.html for the solution.

> of gnupg2. As I demonstrated, there is no problem finding my public key, nor
> my private key, which are located in the default place.
> The problem is the method used to get the passphrase is very broken.
> After reading some stuff via google, I added
> 
> GPG_TTY=$(tty)
> export GPG_TTY
> 
> to my .bashrc file, with no observable changes.
> 
> jeff
> 
> 
> --
> 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: fstab /tmp usertemp error after Windows Update

[Garber, Dave (GE Oil & Gas, Non-GE)]

Your TMP or TEMP environment variable is probably set to that value.  Exit 
Cygwin, fix the environment variable and then go into Cygwin and check it.

Dave

> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Jeff Howard
> Sent: Tuesday, June 27, 2017 2:43 PM
> To: cygwin@cygwin.com
> Subject: EXT: fstab /tmp usertemp error after Windows Update
> 
> Hello -
> 
> After a recent Windows Update (and reboot) the following fstab entry we
> used directly from the Cygwin documentation (https://cygwin.com/cygwin-
> ug-net/using.html) is no longer working.  After digging a little deeper, it
> appears to be attempting to mount /tmp to a directory that doesn't exist on
> my local filesystem.
> 
> I can of course create the directory in my temp folder, but that would defeat
> the purpose in our multi-user environment.  Since we're in a multi-user
> environment, our intention is for each user to seamlessly mount /tmp to
> their own temporary folder to prevent permissions issues.  I also updated
> the Cygwin binaries for good measure, and the issue still persists.
> 
> Examples of my fstab and output from "mount" are in-line below.  Note that
> the directory "/3" does not exist in my local temp folder -
> "C:/Users/Jeff/AppData/Local/Temp" does not exist in my local temp folder:
> 
> $ cat fstab
> # /etc/fstab
> #
> #This file is read once by the first process in a Cygwin process tree.
> #To pick up changes, restart all Cygwin processes.  For a description
> #see https://cygwin.com/cygwin-ug-net/using.html#mount-table
> 
> # This is default anyway:
> none /cygdrive cygdrive binary,posix=0,user 0 0
> none /tmp usertemp binary,posix=0 0 0
> 
> Jeff@CM /etc
> $ mount
> C:/Users/Jeff/AppData/Local/Temp/3 on /tmp type ntfs
> (binary,posix=0,usertemp)
> C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
> C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
> C:/cygwin on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
> E: on /cygdrive/e type ntfs (binary,posix=0,user,noumount,auto)
> 
> 
> - Jeff
> 
> 
> --
> 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


--
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 2.880 release candidate - please test

[Garber, Dave (GE Oil & Gas, Non-GE)]

Looks good.  I did fond one other behavior that I believe should be changed.  
When you are typing in the search box, if you press the enter key, it's the 
same as pressing the Next button and starts the install.  My $.02 is that Enter 
should be ignored when focus is in the search box.

Thanks,
Dave

> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Jon Turney
> Sent: Wednesday, June 07, 2017 1:08 PM
> To: The Cygwin Mailing List 
> Subject: EXT: setup 2.880 release candidate - please test
> 
> 
> A new setup release candidate is available at:
> 
>https://cygwin.com/setup/setup-2.880.x86.exe(32 bit version)
>https://cygwin.com/setup/setup-2.880.x86_64.exe (64 bit version)
> 
> Please test and report problems to cygwin@cygwin.com. If no regressions
> are discovered in the next week or so, it will be promoted to release.
> 
> Changes compared to 2.879:
> 
> - "Internet Explorer Proxy Settings" is renamed to "System Proxy Settings".
> 
> - Remove support for the syntax "requires: A | B" in setup.ini, which
> calm/upset/genini never generated, and was just treated as "requires:
> A", anyhow.
> 
> - Fix a bug where installing a version other than the current version the 
> first
> time a package is installed might lead to it's dependencies not being 
> installed.
> 
> - Add some progress reporting during preremove and uninstall operations.
> 
> - Fix a bug which caused orphaned packages to be omitted from the picker.
> (A regression introduced in 2.878)
> 
> - Correctly account for source packages to be installed due to the --include-
> source option in the total amount of data to checksum.
> 
> - Rename the category "Misc" to "Orphaned".
> 
> - Fix an infinite recursion in the setup.ini parser for "depends:"
> 
> - Error recovery in setup.ini parsing is now slightly improved, so the same
> parse error isn't reported multiple times.
> 
> - Add the option "--user-agent" to override the user-agent string sent in
> HTTP requests.
> (Addresses: https://cygwin.com/ml/cygwin/2012-02/msg00857.html etc.)
> 
> - The default user-agent string now contains the setup version.
> 
> - Fix that clicking on any column can change "Keep" to "Uninstall".
> (Addresses: https://cygwin.com/ml/cygwin/2017-05/msg00525.html)
> 
> - Allow click-to-activate in the package list control.
> 
> - Improve the unhelpful error message "Can't open (null) for reading: No
> such file".
> 
> - Remove some messagebox spam when using file:// protocol URLs for a
> package repository without a compressed setup.ini.
> 
> - Some source code cleanups and cruft removal.
> 
> --
> 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 release candidate - please test

[Dave Caswell via cygwin]

Execution blocked by Windows 10 anti-virus.(Microsoft Security Essentials.)

On Mon, May 8, 2017 at 5:10 AM, Dave Caswell  wrote:
> Execution blocked by Windows 10 anti-virus.(Microsoft Security
> Essentials.)
>
> On Mon, May 8, 2017 at 5:06 AM, Jon Turney 
> wrote:
>>
>>
>> A setup release candidate is available at:
>>
>>   https://cygwin.com/setup/setup-2.878.x86.exe
>>   https://cygwin.com/setup/setup-2.878.x86_64.exe
>>
>> Since this changes the way we download files, I think this can use some
>> wider testing before release.
>>
>> Please test and give feedback to cygwin@cygwin.com. If no regressions are
>> discovered in the next few days, it will be promoted to release.
>>
>>
>> Changes compared to 2.877:
>>
>> - "Direct Connection" now uses the WinINet API to fetch URLs.
>>
>> This enables HTTPS and FTPS protocol support, and caching of mirrors.lst
>> and setup.ini.
>>
>> The existing, hand-built URL fetching, which only supports HTTP and FTP,
>> is still available by choosing "Direct (legacy)".
>>
>> - Fixes to "Use Internet Explorer Proxy Settings" mode
>>
>> Progress is now reported for downloads.
>>
>> Unwanted caching in "Temporary Internet Files" of package archives has
>> been fixed.
>> (Addresses: https://cygwin.com/ml/cygwin/2016-09/msg00403.html)
>>
>> A bug causing a long delay before downloading setup.ini from package
>> repositories without a compressed setup.ini has been fixed.
>>
>> - Add --allow-unsupported-windows option
>>
>> Don't check the windows version.
>>
>> The Cygwin mirror list is not read, so a URL (e.g. a Cygwin time machine
>> circa) should be given with --site or via the GUI.
>>
>> - Remove support for some long-obsolete setup.ini syntax (omitted
>> version:, omitted size and checksum, various undocumented tokens)
>>
>> - Remove cruft
>>
>> --
>> 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
>>
>

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

Python 3.5.2

[Dave Caswell]

Does anyone know when we can expect python3 to be upgraded to 3.5??

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

Can't use install-path longer than 15 chars after 2.875 update

[Garber, Dave (GE Oil & Gas, Non-GE)]

> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Corinna Vinschen
> Sent: Wednesday, August 31, 2016 3:26 PM
> To: cygwin@cygwin.com
> Subject: EXT: Re: Can't use install-path longer than 15 chars after 2.875
> update
> 
> On Aug 31 18:59, Garber, Dave (GE Oil & Gas, Non-GE) wrote:
> > > -Original Message-
> > > From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com]
> On
> > > Behalf Of Corinna Vinschen
> > > Sent: Wednesday, August 31, 2016 2:39 PM
> > > To: cygwin@cygwin.com
> > > Subject: EXT: Re: Can't use install-path longer than 15 chars after
> > > 2.875 update
> > >
> > > On Aug 31 20:22, Jacek Sowiński wrote:
> > > > After updating to setup-x86_64.exe version 2.875 I can't use
> > > > install paths longer than 15 chars and error is throwed:
> > > >
> > > > > The install directory must be absolute, with both a drive letter
> > > > > and leading slash, like C:\Cygwin
> > >
> > > So what was your actual install path?
> > >
> > > FYI, I just used setup-2.875 to installed Cygwin into
> > > C:\cygwin-test-blubber- test\test\test and it just worked.
> >
> > I can confirm that C:\apps\Cygwin64 does NOT work but C:\apps\Cygwin6
> > does.  I also get the error with C:\cygwin-test-blubber-test\test\test.
> 
> On what OS?  You're not running it on XP by any chance?  Is that on
> 32 or 64 bit?
> 
> [...time passes...]
> 
> I could reproduce it on W7 32 bit for some reaosn, while it works fine all the
> time on W10 64 bit.
> 

Fails on Win7 64 bit also.

> FWIW, I reverted setup to version 2.874 for the time being.
> 
> 
> Corinna
> 
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat

Can't use install-path longer than 15 chars after 2.875 update

[Garber, Dave (GE Oil & Gas, Non-GE)]

> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Corinna Vinschen
> Sent: Wednesday, August 31, 2016 2:39 PM
> To: cygwin@cygwin.com
> Subject: EXT: Re: Can't use install-path longer than 15 chars after 2.875
> update
> 
> On Aug 31 20:22, Jacek Sowiński wrote:
> > After updating to setup-x86_64.exe version 2.875 I can't use install
> > paths longer than 15 chars and error is throwed:
> >
> > > The install directory must be absolute, with both a drive letter and
> > > leading slash, like C:\Cygwin
> 
> So what was your actual install path?
> 
> FYI, I just used setup-2.875 to installed Cygwin into C:\cygwin-test-blubber-
> test\test\test and it just worked.

I can confirm that C:\apps\Cygwin64 does NOT work but C:\apps\Cygwin6 does.  I 
also get the error with C:\cygwin-test-blubber-test\test\test.

> 
> 
> Corinna
> 
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat

Re: Permission Problems

[Dave Caswell]

On Mon, Apr 25, 2016 at 12:09 AM, Marco Atzeri  wrote:
> On 25/04/2016 02:29, Dave Caswell wrote:
>>
>> This is a followup to: https://cygwin.com/ml/cygwin/2016-03/msg00345.html
>>
>> To recap, making three nested directories  on a non-C drive produces a
>> third level which is unusable.
>>
>> davec@MERCURYWIN ~/python
>> $ rm -rf g1
>> davec@MERCURYWIN ~/python
>> $ mkdir g1 g1/g2 g1/g2/g3
>> davec@MERCURYWIN ~/python
>> $ ls -la g1 g1/g2 g1/g2/g3
>> g1:
>> total 12
>> drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ./
>> drwxrwx---+ 1 davec Users 0 Mar 16 20:23 ../
>> drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 g2/
>> g1/g2:
>> total 0
>> drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 ./
>> drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ../
>> d--Srws--T+ 1 davec None 0 Mar 16 20:23 g3/
>> ls: cannot open directory 'g1/g2/g3': Permission denied
>>
>> The problem went away with Cygwin 2.5.0-0.7 but is back with 2.5.1-1,
>> and goes away when I downgrade back to 2.5.0-1
>>
>> More info:  I tested on a couple of external drives and things worked
>> properly there.   Can I have screwed up the permissions on my D drive
>> so that cygwin gets confused but Windows still works?
>>
>> thanks
>
>
> It works fine for me.
> "E:" is an external NTFS USB disk
>
> $ mount
> E:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
> E:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
> E:/cygwin64 on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> E: on /cygdrive/e type ntfs (binary,posix=0,user,noumount,auto)
>
>  $ cd /cygdrive/e/temp
>
>  $ mkdir g1 g1/g2 g1/g2/g3
>
>  $ ls -la g1 g1/g2 g1/g2/g3
> g1:
> total 4.0K
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 .
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 ..
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 g2
>
> g1/g2:
> total 0
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 .
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 ..
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 g3
>
> g1/g2/g3:
> total 0
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 .
> drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 ..
>
>  $ icacls .
> . GE-MATZERI-EU\0356EU:(F)
>   BUILTIN\Administrators:(RX)
>   Everyone:(RX)
>   NT AUTHORITY\SYSTEM:(OI)(CI)(F)
>   CREATOR OWNER:(OI)(CI)(IO)(F)
>   CREATOR GROUP:(OI)(CI)(IO)(RX)
>   Everyone:(OI)(CI)(IO)(RX)
>
> $ icacls g1/g2/g3
> g1/g2/g3 NULL SID:(DENY)(Rc,S,REA,X,DC)
>  GE-MATZERI-EU\0356EU:(F)
>  BUILTIN\Administrators:(RX)
>  NT AUTHORITY\SYSTEM:(RX,W,DC)
>  Everyone:(RX)
>  NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,X,DC)
>  CREATOR OWNER:(OI)(CI)(IO)(F)
>  CREATOR GROUP:(OI)(CI)(IO)(RX)
>  NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC)
>  Everyone:(OI)(CI)(IO)(RX)
>
> I suggest to use icacls and eventually "setfacl -b"
> for permission cleaning if needed.

What wound up doing was backing up all the files from my documents
disk to a scratch disk, reformatting the documents disk, and restoring
the backup, and finally running icacls /reset on the whole drive.
This seems to have my system working ok now.

But there is still something different about 2.5.0-1 that prevented it
from writing a confused ACL.

--
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: Permission Problems

[Dave Caswell]

On Mon, Apr 25, 2016 at 4:30 AM, Tatsuro MATSUOKA
 wrote:
>> From: Dave Caswell
>> To: cygwin
>> Cc:
>> Date: 2016/4/25, Mon 09:29
>> Subject: Permission Problems
>>
>>T his is a followup to: https://cygwin.com/ml/cygwin/2016-03/msg00345.html
>>
>> To recap, making three nested directories  on a non-C drive produces a
>> third level which is unusable.
>>
>> davec@MERCURYWIN ~/python
>> $ rm -rf g1
>> davec@MERCURYWIN ~/python
>> $ mkdir g1 g1/g2 g1/g2/g3
>> davec@MERCURYWIN ~/python
>> $ ls -la g1 g1/g2 g1/g2/g3
>> g1:
>> total 12
>> drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ./
>> drwxrwx---+ 1 davec Users 0 Mar 16 20:23 ../
>> drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 g2/
>> g1/g2:
>> total 0
>> drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 ./
>> drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ../
>> d--Srws--T+ 1 davec None 0 Mar 16 20:23 g3/
>> ls: cannot open directory 'g1/g2/g3': Permission denied
>>
>> The problem went away with Cygwin 2.5.0-0.7 but is back with 2.5.1-1,
>> and goes away when I downgrade back to 2.5.0-1
>>
>> More info:  I tested on a couple of external drives and things worked
>> properly there.   Can I have screwed up the permissions on my D drive
>> so that cygwin gets confused but Windows still works?
>>
>> thanks
>>
> Perhaps workaround is to use the beloe
> $ cygstart --action=runas (cygwin command)
>
> In your case,
> $ cygstart --action=runas ls -la g1 g1/g2 g1/g2/g3
> Tatsuro

The problem is the creation of a directory (or file) with a mangled
ACL..  at least windows isn't capable of dealing with the directory
either.

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

Permission Problems

[Dave Caswell]

This is a followup to: https://cygwin.com/ml/cygwin/2016-03/msg00345.html

To recap, making three nested directories  on a non-C drive produces a
third level which is unusable.

davec@MERCURYWIN ~/python
$ rm -rf g1
davec@MERCURYWIN ~/python
$ mkdir g1 g1/g2 g1/g2/g3
davec@MERCURYWIN ~/python
$ ls -la g1 g1/g2 g1/g2/g3
g1:
total 12
drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ./
drwxrwx---+ 1 davec Users 0 Mar 16 20:23 ../
drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 g2/
g1/g2:
total 0
drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 ./
drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ../
d--Srws--T+ 1 davec None 0 Mar 16 20:23 g3/
ls: cannot open directory 'g1/g2/g3': Permission denied

The problem went away with Cygwin 2.5.0-0.7 but is back with 2.5.1-1,
and goes away when I downgrade back to 2.5.0-1

More info:  I tested on a couple of external drives and things worked
properly there.   Can I have screwed up the permissions on my D drive
so that cygwin gets confused but Windows still works?

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: Seg Fault from strace

[Garber, Dave (GE Oil & Gas, Non-GE)]

$ cygcheck  /usr/bin/strace.exe
C:\Apps\cygwin64\bin\strace.exe
  C:\Windows\system32\ADVAPI32.dll
C:\Windows\system32\msvcrt.dll
  C:\Windows\system32\KERNELBASE.dll
C:\Windows\system32\ntdll.dll
  C:\Windows\system32\API-MS-Win-Core-Console-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-DateTime-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll
C:\Windows\system32\API-MS-WIN-Service-Core-L1-1-0.dll
C:\Windows\system32\API-MS-WIN-Service-winsvc-L1-1-0.dll
C:\Windows\system32\API-MS-WIN-Service-Management-L1-1-0.dll
C:\Windows\system32\API-MS-WIN-Service-Management-L2-1-0.dll
C:\Windows\system32\API-MS-Win-Core-LocalRegistry-L1-1-0.dll
C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll
C:\Windows\system32\KERNEL32.dll
  C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll
C:\Windows\system32\RPCRT4.dll
  C:\Windows\system32\API-MS-Win-Core-Interlocked-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-DelayLoad-L1-1-0.dll


-Original Message-
From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
Marco Atzeri
Sent: Monday, April 11, 2016 3:38 PM
To: cygwin@cygwin.com
Subject: Re: Seg Fault from strace

On 11/04/2016 21:27, Garber, Dave (GE Oil & Gas, Non-GE) wrote:
> Strace always seg faults.  Tried reverting back to 2.4.1 and had the same 
> issue.
>
> $ uname -a
> CYGWIN_NT-6.1 G7TD3H72E 2.5.0(0.297/5/3) 2016-04-11 09:58 x86_64 Cygwin
>
> $ strace echo foo
> Segmentation fault
>
> $ strace -o foo.strace echo foo
> Segmentation fault
>

what is the output of

cygcheck  /usr/bin/strace.exe

Regards
Marco

--
Problem reports:   
https://urldefense.proofpoint.com/v2/url?u=http-3A__cygwin.com_problems.html&d=CwIC-g&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=zKv0lhngryQuti7TIhTXmU0cAjgLim0Fyr3Kz3GnA-Y&m=jk_SH9X7F8MLqaGkBLK9G5Av654QuI2cV-fGTmtH-xI&s=xWHXEBPd6owmgonvE-e6uGM_tu94KD77XmkutT3QNWM&e=
 
FAQ:   
https://urldefense.proofpoint.com/v2/url?u=http-3A__cygwin.com_faq_&d=CwIC-g&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=zKv0lhngryQuti7TIhTXmU0cAjgLim0Fyr3Kz3GnA-Y&m=jk_SH9X7F8MLqaGkBLK9G5Av654QuI2cV-fGTmtH-xI&s=SPqzLM63IgRhnrQe3neiokXxtxfNZIM-XtLYnHehOj0&e=
 
Documentation: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__cygwin.com_docs.html&d=CwIC-g&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=zKv0lhngryQuti7TIhTXmU0cAjgLim0Fyr3Kz3GnA-Y&m=jk_SH9X7F8MLqaGkBLK9G5Av654QuI2cV-fGTmtH-xI&s=Vv2bTBb8SZVT0YTnQzxHE1okOrNCl7iUZ_7-CP-IC-M&e=
 
Unsubscribe info:  
https://urldefense.proofpoint.com/v2/url?u=http-3A__cygwin.com_ml_-23unsubscribe-2Dsimple&d=CwIC-g&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=zKv0lhngryQuti7TIhTXmU0cAjgLim0Fyr3Kz3GnA-Y&m=jk_SH9X7F8MLqaGkBLK9G5Av654QuI2cV-fGTmtH-xI&s=5tas5aST6H_TW7qRtEY74ky_6j4cUVj0yOvjwj8F884&e=
 


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

Seg Fault from strace

[Garber, Dave (GE Oil & Gas, Non-GE)]

Strace always seg faults.  Tried reverting back to 2.4.1 and had the same issue.

$ uname -a
CYGWIN_NT-6.1 G7TD3H72E 2.5.0(0.297/5/3) 2016-04-11 09:58 x86_64 Cygwin

$ strace echo foo
Segmentation fault

$ strace -o foo.strace echo foo
Segmentation fault

$ gdb --args strace echo foo
GNU gdb (GDB) (Cygwin 7.10.1-1) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from strace...Reading symbols from 
/usr/lib/debug//usr/bin/strace.exe.dbg...done.
done.
(gdb) run
Starting program: /usr/bin/strace echo foo
[New Thread 13744.0x22ac]
warning: dll path for "c:\windows\system32\dgapi64.dll" can not be evaluated
warning: Could not load shared library symbols for 
c:\windows\system32\dgapi64.dll.
Do you need "set solib-search-path" or "set sysroot"?
[New Thread 13744.0x3438]
warning: dll path for "C:\Program 
Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\AE_MailSensor_Plugin64.dll"
 can not be evaluated
warning: Could not load shared library symbols for C:\Program 
Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\AE_MailSensor_Plugin64.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: dll path for "C:\Program 
Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\ame_outlooksensor64.dll"
 can not be evaluated
warning: Could not load shared library symbols for C:\Program 
Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\ame_outlooksensor64.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: dll path for "C:\Program 
Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\ame_smtpsensor64.dll"
 can not be evaluated
warning: Could not load shared library symbols for C:\Program 
Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\ame_smtpsensor64.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: dll path for "C:\Program 
Files\DGAgent\plugins\8E4EA70A-6128-4B57-BD3F-8E9E0F0DA6BB\OS_Plugin64.dll" can 
not be evaluated
warning: Could not load shared library symbols for C:\Program 
Files\DGAgent\plugins\8E4EA70A-6128-4B57-BD3F-8E9E0F0DA6BB\OS_Plugin64.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: dll path for "C:\Program 
Files\DGAgent\plugins\8E4EA70A-6128-4B57-BD3F-8E9E0F0DA6BB\COM_Sensor64.dll" 
can not be evaluated
warning: Could not load shared library symbols for C:\Program 
Files\DGAgent\plugins\8E4EA70A-6128-4B57-BD3F-8E9E0F0DA6BB\COM_Sensor64.dll.
Do you need "set solib-search-path" or "set sysroot"?

Program received signal SIGSEGV, Segmentation fault.
0x7728c52c in KERNEL32!GetVolumePathNamesForVolumeNameW () from 
/cygdrive/c/Windows/system32/kernel32.dll


cygcheck.out
Description: cygcheck.out
--
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

Bug report, but already fixed in TEST RELEASE: Cygwin 2.5.0-0.7

[Dave Caswell]

I delete all cygwin directories and do a
Fresh minimal install of cygwin (2.4.1-1) on a windows 7 ultimate 64 bit box


davec@MERCURYWIN ~
$ cd python

davec@MERCURYWIN ~/python
$ rm -rf g1

davec@MERCURYWIN ~/python
$ mkdir g1 g1/g2 g1/g2/g3

davec@MERCURYWIN ~/python
$ ls -la g1 g1/g2 g1/g2/g3
g1:
total 12
drwxrwxr-x+ 1 davec None  0 Mar 16 20:23 ./
drwxrwx---+ 1 davec Users 0 Mar 16 20:23 ../
drwsrwsr-t+ 1 davec None  0 Mar 16 20:23 g2/

g1/g2:
total 0
drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 ./
drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ../
d--Srws--T+ 1 davec None 0 Mar 16 20:23 g3/
ls: cannot open directory 'g1/g2/g3': Permission denied

Now a strange thing is that if I make myself a home directory in /home
everything works fine.

davec@MERCURYWIN ~/python
$ cd /home

davec@MERCURYWIN /home
$ ls

davec@MERCURYWIN /home
$ mkdir davec

davec@MERCURYWIN /home
$ cd davec

davec@MERCURYWIN /home/davec
$ mkdir g1 g1/g2 g1/g2/g3

davec@MERCURYWIN /home/davec
$ ls -la . g1 g1/g2 g1/g2/g3
.:
total 0
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 ./
drwxrwxrwt+ 1 davec None 0 Mar 16 20:28 ../
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 g1/

g1:
total 0
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 ./
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 ../
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 g2/

g1/g2:
total 0
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 ./
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 ../
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 g3/

g1/g2/g3:
total 0
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 ./
drwxr-xr-x+ 1 davec None 0 Mar 16 20:28 ../

davec@MERCURYWIN /home/davec

Now I install cygwin package version 2.5.0-7 and everything starts to
work as expected.

davec@MERCURYWIN /cygdrive/d
$ cd python

davec@MERCURYWIN /cygdrive/d/python
$ rm -rf g1

davec@MERCURYWIN /cygdrive/d/python
$ mkdir g1 g1/g2 g1/g2/g3

davec@MERCURYWIN /cygdrive/d/python
$ ls -la  g1 g1/g2 g1/g2/g3

g1:
total 12
drwxr-xr-x+ 1 davec None  0 Mar 16 20:32 ./
drwxrwx---+ 1 davec Users 0 Mar 16 20:32 ../
drwxr-xr-x+ 1 davec None  0 Mar 16 20:32 g2/

g1/g2:
total 0
drwxr-xr-x+ 1 davec None 0 Mar 16 20:32 ./
drwxr-xr-x+ 1 davec None 0 Mar 16 20:32 ../
drwxr-xr-x+ 1 davec None 0 Mar 16 20:32 g3/

g1/g2/g3:
total 0
drwxr-xr-x+ 1 davec None 0 Mar 16 20:32 ./
drwxr-xr-x+ 1 davec None 0 Mar 16 20:32 ../

davec@MERCURYWIN /cygdrive/d/python
$

So Thank You to whoever fixed this!!

--
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: chere Bash Prompt Here window closes immediately

[Dave Kilroy]

On 23/10/2015 16:16, Matt Seitz (matseitz) wrote:
> When I right click a folder in Windows Explorer and select
> "Bash Prompt Here", a window opens briefly and then closes
> immediately.  If I select "Applications -> Xterm" from the
> Cygwin/X Server tray icon, XTerm opens fine.
> 
> Cygcheck and Xwin logs attached.  Chere -lr output below.
> 
> matseitz@MATSEITZ-WS02 ~
> $ chere -lr
> --- bash keys ---
> Directory menu item (all users)
> &Bash Prompt Here
> 
> Drive command (all users)
> C:\cygwin64\bin\run.exe -p /usr/X11R6/bin C:\cygwin64\bin\xterm.exe -display 
> %DISPLAY% -e /bin/xhere /bin/bash.exe "%L"

I suspect this may be due to the use of %DISPLAY% (which I don't
recall). I see that in your environment this is set to ":1.0"

What happens if you run the following from cmd:

cd c:\cygwin64\usr\x11r6\bin
c:\cygwin64\bin\xterm.exe -display %DISPLAY% -e /bin/xhere /bin/bash.exe c:

Is it any different if you run
c:\cygwin64\bin\xterm.exe -display :1 -e /bin/xhere /bin/bash.exe c:

or
c:\cygwin64\bin\xterm.exe -display :0 -e /bin/xhere /bin/bash.exe c:

Also, I presume the X server is already running?


Dave.

--
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: linux libertine mono in mintty ?

[Dave Laub]

On Mon, 28 Sep 2015 08:53:17 +0200, Thomas Wolff  wrote:
> Am 27.09.2015 um 19:29 schrieb J.D. Laub:
>> In windows7 I've installed the Linux Libertine Mono O Mono font, and
use
>> it for putty.  Wanting to use the same in cygwin, I've installed the
>> latest
>> linux-libertine-fonts, xorg-server, & xfs, but I can't get latest
mintty
>> to
>> offer it as a font, from either the console or X.  (It does offer
>> Liberation Mono.)  Suggestions on things I can try besides the reboot
>> I've
>> already done?
> Mintty is not an X windows program. To make fonts available for mintty, 
> you have to install them with Windows, not X11 (I'll add a note to the 
> Tips wiki page).
> Even if you do that, Linux Libertine Mono is not listed in the mintty 
> font menu. The reason for that is probably that the font file is missing

> an explicit flag to identify it as a monospace font. I suggest to file a

> bug with Linux Libertine about that.
> You can still use it, though, with this invocation:
>  mintty -o Font="Linux Libertine Mono"

Thank you very much.  I bumped
https://sourceforge.net/p/linuxlibertine/bugs/229/ , but in the meantime,
the "-o Font" force works.

--
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: FW: [cygwin] Cygwin's git says "error: failed to read delta-pack base object"

[Dave L]

Jason Pyeron has patched Cygwin's git so that it works for me (cloning
to Windows network shares).

He says:

"TLDR = Cygwin remote filesystem sometimes has strange failures ->
workaround is to use rename, not link/unlink"

but:

"The fix as is, is a sledge hammer with many side effects. A better
way to include this work around will be discussed on the git list. The
real issues may lay in both cygwin and git, caused by BLODA."

See thread below for details. (Some irrelevant stuff omitted for brevity.)

My deep thanks to Jason - I'm up and running now.

--Dave

-- Forwarded message --
From: Jason Pyeron 
Date: Sun, Dec 7, 2014 at 12:21 PM
Subject: RE: FW: [cygwin] Cygwin's git says "error: failed to read
delta-pack base object"
To: Dave L 

...

The fix as is, is a sledge hammer with many side effects. A better way
to include this work around will be discussed on the git list. The
real issues may lay in both cygwin and git, caused by BLODA.

>   > On Sat, Dec 6, 2014 at 8:33 PM, Jason Pyeron
>  wrote:
>   >
>   >
>   >   TLDR = Cygwin remote filesystem sometimes has strange
>   > failures -> workaround is to use rename, not link/unlink;
>   >   see
>   > https://github.com/pdinc-oss/git/commit/5a36824ed01d4335148ca3
>   846e75cc99c11650e2
>   >   > -Original Message-
>   >   > From: Jason Pyeron
>   >   > Sent: Friday, December 05, 2014 10:30
>   >   >
>   >   > > -Original Message-
>   >   > > From: Jason Pyeron
>   >   > > Sent: Thursday, December 04, 2014 16:34
>   >   > >
>   >   > > > -Original Message-
>   >   > > > From: brian m. carlson
>   >   > > > Sent: Wednesday, December 03, 2014 19:55
>   >   > > >
>   >   > > > On Wed, Dec 03, 2014 at 06:31:18PM -0500, Jason
>   > Pyeron wrote:
>   >   > > > > I remember hitting this a while ago,
> but just gave up.
>   >   > > > >
>   >   > > > > It seems to be a problem for others too.
>   >   > > > >
>   >   > > > > Any ideas on how to debug this so it
> can be patched?
>   >   > > > >
>   >   > > > > -Original Message-
>   >   > > > > From: Dave Lindbergh
>   >   > > > > Sent: Wednesday, December 03, 2014 18:07
>   >   > > > > To: cygwin
>   >   > > > >
>   >   > > > > Aha - you're right.
>   >   > > > >
>   >   > > > > It works fine on a local NTFS volume.
>   >   > > > >
>   >   > > > > I get the error when I do it on Z:,
> which is mapped to a
>   >   > > > network drive
>   >   > > > > (on another Windows box).
>   >   > > > >
>   >   > > > > Is there a workaround? Why does this happen?
>   >
>   >   I have a really hacky workaround, commit
>   > 5a36824ed01d4335148ca3846e75cc99c11650e2 comments out the
>   > logic and forces a rename instead of link and unlink.
>   >
>   >
>   >
> https://github.com/pdinc-oss/git/tree/cygwin-issue-remoteCIFS-rename
>   >
>   >   
>   >
>   >   > Pseudo code and observations
>   >   > ./sha1_file.c:write_loose_object(sha1)
>   >   > {
>   >   >  filename=sha1_file_name(sha1)
>   >   >  (fd,tmp_file)=create_tmpfile(filename)
>   >   >  write_buffer(fd)
>   >   >  close_sha1_file(fd)
>   >   >  return move_temp_to_file(tmp_file, filename)
>   >   > }
>   >   >
>   >   > move_temp_to_file(tmpfile, filename)
>   >   > {
>   >   >  // I am thinking about forcing renames to
> see if the problem
>   >   > exists then as well
>   >   >  // if that "works" then a per repo config
> option allowing
>   >   > for forced renames
>   >   >  if (OBJECT_CREATION_USES_RENAMES) goto try_rename
>   >   >  else if link(tmpfile,filename)
>   >   >
>   >
>   >   Dave has tested a build I made for 

Re: [cygwin] Cygwin's git says "error: failed to read delta-pack base object"

[Dave L]

On Fri, Dec 5, 2014 at 6:35 AM, Corinna Vinschen
 wrote:
>
> ...
>
> This looks suspiciously like a bug in the remote filesystem.  Link
> succeeded, so there are two links to the same file in the directory.
> Unlinking link 1 succeeds, so there's still one link to the file in the
> directory, but link 2 is inaccessible as if the file has been deleted
> completely.  Thus, a full POSIX git on this drive is broken.
>
> Can you please run
>
>   /usr/lib/csih/getVolInfo /cygdrive/z
>
> and paste the output here?  Maybe I can workaround this in the next
> Cygwin version.

 Here you go:

$ /usr/lib/csih/getVolInfo /cygdrive/Z
Device Type: 7
Characteristics: 10
Volume Name: <>
Serial Number  : 1646121781
Max Filenamelength : 255
Filesystemname : 
Flags  : c700ff
  FILE_CASE_SENSITIVE_SEARCH  : TRUE
  FILE_CASE_PRESERVED_NAMES   : TRUE
  FILE_UNICODE_ON_DISK: TRUE
  FILE_PERSISTENT_ACLS: TRUE
  FILE_FILE_COMPRESSION   : TRUE
  FILE_VOLUME_QUOTAS  : TRUE
  FILE_SUPPORTS_SPARSE_FILES  : TRUE
  FILE_SUPPORTS_REPARSE_POINTS: TRUE
  FILE_SUPPORTS_REMOTE_STORAGE: FALSE
  FILE_VOLUME_IS_COMPRESSED   : FALSE
  FILE_SUPPORTS_OBJECT_IDS: TRUE
  FILE_SUPPORTS_ENCRYPTION: TRUE
  FILE_NAMED_STREAMS  : TRUE
  FILE_READ_ONLY_VOLUME   : FALSE
  FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
  FILE_SUPPORTS_TRANSACTIONS  : FALSE

Thanks for looking into this.  FWIW, @Kai on StackExchange has been
able to reproduce the problem. See last comment here:

http://stackoverflow.com/questions/27156413/how-to-configure-cygwin-git-for-two-factor-authentication-at-github-com/27176547?noredirect=1#comment43088817_27176547

--
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] Cygwin's git says "error: failed to read delta-pack base object"

[Dave Lindbergh]

>> It works fine on a local NTFS volume.
>>
>> I get the error when I do it on Z:, which is mapped to a network drive
>> (on another Windows box).
>
>It works fine for me on a network drive mounted from another Windows
>machine used via the cygdrive prefix:
>[..]
>I tried with two different mount points, one to a Cygwin-created remote
>dir, one to a Windows-created remote dir.
>
>> Is there a workaround? Why does this happen?
>
>No idea.  How do you mount the drive, e.g., what does `mount' print for
>the drive?  Or could this be a permission problem?  If all else fails
>you could try to find out what happens via strace.

Mount gives:

   Z: on /cygdrive/z type ntfs (binary,posix=0,user,noumount,auto)

It's an ordinary LAN share on another local Windows box, mapped to
drive Z: via "Map network drive" in Explorer (Win7). I have full
permissions.

You are more than welcome to read the strace output if that'll give
you a clue (it doesn't give me one). All 1.7 MBytes of it are at
http://nerdfever.com/files/strace.txt

(That comes from "strace git clone
https://github.com/nerdfever/pic32mx-bmf >strace.txt")

I'm still stumped.

--
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] Cygwin's git says "error: failed to read delta-pack base object"

[Dave Lindbergh]

On Wed, Dec 3, 2014 at 3:42 PM, Jason Pyeron  wrote:
> [copy off list, because the sourceware system admins throws temper tantrums]
>> -Original Message-
>> From: Dave L
>> Sent: Wednesday, December 03, 2014 15:30
>>
>> ...but the git from github.com works fine.
>>
>> I installed Cygwin's version of git, and get this:
>>
>> $ git clone https://github.com/nerdfever/pic32mx-bmf
>> Cloning into 'pic32mx-bmf'...
>> remote: Counting objects: 12, done.
>> remote: Total 12 (delta 0), reused 0 (delta 0)
>> error: failed to read delta-pack base object
>> 300bdeb2fd209d24afb865584da10b78aa8fefc4
>> fatal: unpack-objects failed
>
> What file system are you on? Local NTFS or remote?

Aha - you're right.

It works fine on a local NTFS volume.

I get the error when I do it on Z:, which is mapped to a network drive
(on another Windows box).

Is there a workaround? Why does this happen?

--Dave

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

Cygwin's git says "error: failed to read delta-pack base object"

[Dave L]

...but the git from github.com works fine.

I installed Cygwin's version of git, and get this:

$ git clone https://github.com/nerdfever/pic32mx-bmf
Cloning into 'pic32mx-bmf'...
remote: Counting objects: 12, done.
remote: Total 12 (delta 0), reused 0 (delta 0)
error: failed to read delta-pack base object
300bdeb2fd209d24afb865584da10b78aa8fefc4
fatal: unpack-objects failed

When I run the git that came from github (the MINGW32 version), it works
fine.

I'm pretty sure this is operator error, but I'm stumped. What am I doing
wrong?

(that repository is public - you can try it yourself)

--
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] TEST RELEASE: Cygwin 1.7.33-0.4

[Habermann, Dave (DA)]

On Oct 29 19:06, Habermann, Dave (DA) wrote:
>> does NOT work, because my user ID is defaulting to U012345 (upper case
>> U).  In this case, however, I can STILL log in if I enter my password.
>> 
>This has been discussed a few months back, but there was no majority
>for "always lower-case the Cygwin user name".

Must have missed that discussion, but I don't have any problem with it as
you've developed it, just was hoping to flag it to help others as they 
make the transition.

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.4

[Habermann, Dave (DA)]

On Oct 29 19:27, Habermann, Dave (DA) wrote:
>> issue to a line in the /bin/ssh-user-config file:
>> 
>>   pwdhome=$(awk -F: '{ if ( $3 == '${uid}' ) print $6; }' < 
>> ${SYSCONFDIR}/passwd)
>>
> Ouch.  I missed that when scanning the ssh scripts.
>
> Sorry, but I'm pretty sure this isn't the only place in the distro
> still checking the passwd and group files :(

No worries...I've got my keys rebuilt and working.  My Dad always told me that
"beggars can't be choosers", and I'm clearly the "beggar" here.  I use your 
stuff routinely every day and am so grateful for the power it brings into my
forced-to-be-on-windows environment.  Hopefully I can be of more service some 
day.

Dave

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.4

[Habermann, Dave (DA)]

Using the new AD system, and trying to regenerate ssh keys using 
ssh-user-config I find that I'm getting an error.  I've traced the issue to a 
line in the /bin/ssh-user-config file:

  pwdhome=$(awk -F: '{ if ( $3 == '${uid}' ) print $6; }' < 
${SYSCONFDIR}/passwd)

where we are apparently trying to parse the old passwd file (which I've renamed 
off to the side for testing quality).  I can make this work for me right now 
with an ugly hack, but wanted to point it.

$ ssh -V
OpenSSH_6.7p1, OpenSSL 1.0.1j 15 Oct 2014

Dave
 

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.4

[Habermann, Dave (DA)]

Found one interesting observation today after switching to the new AD 
authentication.  My ability to use password-less login via SSH suddenly went 
missing.  Although I haven't fully resolved it yet (which I suspect may take 
regeneration/proliferation of keys), it would appear that I've been the victim 
of case sensitivity.  In my old passwd file I had my user ID present in all 
lower case, but apparently in Active Directory my user ID is present as upper 
case.  I am still able to make it log password-less using

ssh u012356@cr

but

ssh cr

does NOT work, because my user ID is defaulting to U012345 (upper case U).  In 
this case, however, I can STILL log in if I enter my password.

I don't really think there is anything to correct here, but just wanted to 
point out the oddity in case anyone else suffers from a similar issue.

Dave

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, Dave (DA)]

>> should be created.  I would think that some instructions in the docs
>> near the statement mentioned above would be more than sufficient,
>> since this is a "fine tuning" sort of thing.

> Agreed.  Do you have some idea how to phrase this?  I'd be grateful
> for a nice two or three paragraphs discussing this.

Have a look...don't hesitate to re-work if my phrasing doesn't fit


The advantage of cygserver caching is that it's system-wide and, as long as 
cygserver is running, unforgetful. Every Cygwin process on the system will have 
the cygserver cache at its service. Additionally, all information requested 
from cygserver once, will be cached inside the process itself and, again, 
propagated to child processes.

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, Dave (DA)]

>> should be created.  I would think that some instructions in the docs
>> near the statement mentioned above would be more than sufficient,
>> since this is a "fine tuning" sort of thing.

> Agreed.  Do you have some idea how to phrase this?  I'd be grateful
> for a nice two or three paragraphs discussing this.

Will do, but it will take me a bit as I'd like to make sure I've got 
it right, plus I've got some "day job interference" for the next day
or so.

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, Dave (DA)]

-Original Message-
From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
Corinna Vinschen
Sent: Monday, October 27, 2014 5:27 PM
To: cygwin@cygwin.com
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

On Oct 27 18:35, Habermann, Dave (DA) wrote:

>> Question:  In the documentation you indicate that "If cygserver is
>> running it will provide passwd and group entry caching for all
>> processes in every Cygwin process tree started after cygserver."
>> Normally I have several processes (specifically sshd, cygserver, cron
>> and httpd2) automatically start up as services when my system boots
>> up, and I have not specified the order.  Would it now be desirable to
>> have cygserver starting up first, followed by the others?  If so, what
>> would be the preferred way to create such a dependency/startup timing?
>> Would a service dependency be sufficient?

>Now that you mention it... yes, a service dependency might be helpful.
>Unfortunately it's tricky to automate this.  Is it possible to add
>service deps after having installed a service?

According to 
http://serverfault.com/questions/24821/how-to-add-dependency-on-a-windows-service-after-the-service-is-installed
 it is possible to add a dependency to an already existing service.  I agree it 
would be hard to automate in the install scripts, as one would have to either 
ask the user about their intent to run other services or rely that they 
configured cygserver first and then check to see if it has been already 
configured to determine if a dependency should be created.  I would think that 
some instructions in the docs near the statement mentioned above would be more 
than sufficient, since this is a "fine tuning" sort of thing.

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, Dave (DA)]

Loaded the test release here today and found that it seems to work as expected, 
both without the /etc/nsswitch.conf file (operates as before) and with both 
passwd and group set to "db" in the file.  Only two slightly negative 
observations I've made so far are 1) ps -ef only allows for 8 character UIDs, 
and thus longer UIDs (for example MyMachine+cyg_server) don't show up well and 
2) the very first cygwin process I start seems to take a bit longer to start up 
now (in either mode) than before (7-10 seconds depending on the contents of 
nsswitch).  Perhaps this is possibly due to the fact that I'm accessing AD at 
some distance over a VPN?  However, the SECOND process and all subsequent ones 
seem to start significantly faster than before (THANKS FOR THAT!).

Question:  In the documentation you indicate that "If cygserver is running it 
will provide passwd and group entry caching for all processes in every Cygwin 
process tree started after cygserver."  Normally I have several processes 
(specifically sshd, cygserver, cron and httpd2) automatically start up as 
services when my system boots up, and I have not specified the order.  Would it 
now be desirable to have cygserver starting up first, followed by the others?  
If so, what would be the preferred way to create such a dependency/startup 
timing?  Would a service dependency be sufficient?

Thanks again for your efforts on this!

Dave

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, Dave (DA)]

Read through https://cygwin.com/preliminary-ntsec.html and in general found it 
to be quite useful.  I'm hoping to do some testing perhaps later this week or 
early next.  I have a couple of questions:

1) Any thoughts about the rough timing of this "going live"?

2) The documentation says (as I read it): Well-known/builtin accounts named as 
in Windows, then (for domain member) "Local machine accounts of a domain member 
machine get a Cygwin user name the same way as accounts from another domain: 
The local machine name gets prepended".  As I read this, cyg_serv account 
(under which I currently run SSHD) would now have a new name 
MYMACHINE+cyg_serv.  Am I reading this correctly?  Is there some 
reconfiguration I'll need to do to get SSHD to run properly?

3) I also read "Cygwin implements the Solaris API to access Windows ACLs in a 
Unixy way" (although your email says "Revamp Solaris ACL implementation to more 
closely work like POSIX ACLs are supposed to work").  So is it Solaris or is it 
POSIX, and if Solaris then I wonder why since it seems that everywhere else 
you've tried to be as POSIX as possible.

Thanks for all your hard work on this, I will certainly be one of the 
benefactors (12 Mb group file, takes hours to refresh so not done since this 
time last year).

Dave

Re: fish PATH problem

[Dave Kilroy]

On 10/10/2014 14:46, Andrew Schulman wrote:


OK, I rolled a new release of fish 2.1.1:

x86:
http://home.comcast.net/~andrex2/cygwin/x86/fish-2.1.1-1.tar.xz
http://home.comcast.net/~andrex2/cygwin/x86/fish-2.1.1-1-src.tar.xz

x86_64:
http://home.comcast.net/~andrex2/cygwin/x86_64/fish-2.1.1-1.tar.xz
http://home.comcast.net/~andrex2/cygwin/x86_64/fish-2.1.1-1-src.tar.xz

Please try it out, and let me know how it works for you.  If it's okay and if 
Konrad
doesn't answer, then I'll adopt the package and put out the new release.  I've
switched to using fish as my default shell now, so I want to see it maintained.

I downloaded both versions and verified that `fish -l` didn't show the 
path issue. Success.



Thanks,

Dave.

--
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: fish PATH problem

[Dave Kilroy]

On 09/10/2014 18:26, Andrey Repin wrote:

Greetings, Andrew Schulman!


Bad news: the PATH problem is back.  When I run
C:\cygwin64\bin\fish.exe -l
I get the same error messages as before on startup, and PATH doesn't
include /bin /usr/bin /sbin /usr/sbin.
How are /bin /usr/bin etc. normally added to the PATH?  I don't see any
logic to do it in /usr/share/fish/config.fish.

That logic probably should be included.
At least, bash does that in login files.



That was my conclusion as well*. Question is, should fish provide the 
configuration, or should base-files cover all shells?


Andrew: thanks for confirming. If you're still looking for the logic and 
where to put it, I suggested something in * as well.



Regards,

Dave.

* https://cygwin.com/ml/cygwin/2014-04/msg00175.html

--
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: fish PATH problem

[Dave Kilroy]

On 08/10/2014 18:36, Alive4Ever wrote:

On Wednesday, October 08, 2014 11:08:43 AM you wrote:

Does that work. It seemed to have the same issue as noted in the
following thread https://cygwin.com/ml/cygwin/2014-04/msg00111.html

Dave.

It should work, although I don't recommend running cygwin apps directly
via wincmd, unless the underlying shell is invoked as interactive login
shell.
So I just re-tested starting a fish login shell after updating cygwin64. 
As I suspected, fish has not been updated since the thread I quoted (Apr 
2014), and the issue remains (with my install). Google doesn't show the 
maintainer on list since the announcement (Oct 2013), and his e-mail 
bounces. Cc'ing anyway, just in case.

You can find the example of how to invoke cygwin correctly by looking at
Cygwin.bat file on cygwin root directory.

I'm aware of how to invoke login shells and start cygwin, thanks.

Andrew: appreciated if you can confirm whether simply invoking as a 
login shell works for you.



Regards,

Dave.

--
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: fish PATH problem

[Dave Kilroy]

On 08/10/2014 10:57, Andrew Schulman wrote:

On Wednesday, October 08, 2014 05:13:54 AM Andrew Schulman wrote:

When I try to start fish directly from the Windows shell instead of from
bash, I get a boatload of errors, like this:

I suggest you to read fish manual page, and find how to invoke fish as login
shell. On bash and zsh, there is '-l' flag so that they behave with fresh
environment variables.

Doh! Right. Thanks.


Does that work. It seemed to have the same issue as noted in the 
following thread https://cygwin.com/ml/cygwin/2014-04/msg00111.html


Dave.

--
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: Deafult to bash so $chere will work (possibly?)

[Dave Kilroy]

On 24/08/2014 11:02, Michelle Pace wrote:

HOORAY! Thanks Andrey, this command worked for me:

$ chere -i -t mintty -s bash


I'm glad you got it to work. chere is attempting to use the shell 
defined in your passwd (as retrieved by getent). The shell being 
returned is '/bin/sh'.


It looks like I forget to add an entry handle to handle sh... I'll try 
to fix this up for the next version.


Thanks for the report,

Dave.


--
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: Possible bug with chere 1.4 when configuring for fish

[Dave Kilroy]

On 10/04/2014 11:06, Ronald Fischer wrote:

I've had more time to look around. If you add the following to the file
~/.config/fish/config.fish (create it if you haven't already got one),
then things should work as intended:

if status --is-login
set PATH /usr/local/bin /usr/bin $PATH
end

Alternatively drop it in the fish global startup file,
/usr/share/fish/config.fish.

I tried the variant of putting it into the global startup file, it
doesn't resolve the problem for me. I'll play around a bit with it as
soon as I have time (I'm a first-time user of fish and am busy with
other things right now, so this might take some time).

You're right, when using the default -2. If you switch to -1, things get 
better, but then the chere functionality of cd'ing to a directory fails. 
Fun.


-2 mode fails because fish recognizes a login shell by $0 being exactly 
"-fish", but chere is using "-/bin/fish". There's a trivial patch* to 
fish.cpp which could make this work better for us.


-1 mode fails because fish would prefer cygpath was run on the argument 
first. I'm not sure why this works in bash.


I'll try put together a fix for the latter issue, but it may be a while 
before I can upload*.


Konrad, are you able to chase the former issue? NB Konrad's email 
provider is out of action.


Ronald, your choices as the moment:
- Add cygwin\bin to your windows path
- Use the above snippet without the check for a login shell, and method 
-2. If you don't start too many subshells you're probably OK. If you do 
need subshells, you could change the check to test if /bin is already in 
the path.




Dave.

* New employer, need to clarify status of open source contributions etc.

--
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: Possible bug with chere 1.4 when configuring for fish

[Dave Kilroy]

On 07/04/2014 23:35, Dave Kilroy wrote:

On 07/04/2014 13:02, Ronald Fischer wrote:

I have installed fish 2.1.0. Works fine, when invoking a new fish shell
manually.

However, when doing a

chere -ifcm -t mintty -s fish

and invoke the new fish shell from the Windows Explorer context menu, I
get plenty of error messages, like this:



(more of this kind follow).

This looks like there is a problem the PATH, but this happens even when
I use the -2 on chere when installing the shell. Note that bash or zsh
shells installed via cygwin work fine.


Thanks for the report.

I've just checked my x86_64 and x86 installation. Things are working 
on my installation as I have c:\cygwin\bin on my standard windows 
path. When I remove it and invoke fish, I get the errors that you 
highlight. Similarly when echo'ing $PATH under the broken fish, 
/usr/bin is not one of the entries.


I need to have a play around to see how I can fix this, but I thought 
cygwin prepended /usr/bin to the path...


I've had more time to look around. If you add the following to the file 
~/.config/fish/config.fish (create it if you haven't already got one), 
then things should work as intended:


if status --is-login
set PATH /usr/local/bin /usr/bin $PATH
end

Alternatively drop it in the fish global startup file, 
/usr/share/fish/config.fish. Konrad, would you consider adding the above 
fragment to config.fish in the next release? That should bring fish into 
line with the other shells*. You might also consider adding some of the 
other environment variables like PRINTER etc etc.



Thanks,

Dave.
---
* FYI
Bash gets /usr/local/bin and /usr/bin prefixed to its path by 
/etc/profile (supplied by base-files)

mksh and posh also use /etc/profile
tcsh gets these prefixed by /etc/csh.login (supplied by tcsh)
zsh uses /etc/zprofile (supplied by zsh)




--
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: Possible bug with chere 1.4 when configuring for fish

[Dave Kilroy]

On 07/04/2014 13:02, Ronald Fischer wrote:

I have installed fish 2.1.0. Works fine, when invoking a new fish shell
manually.

However, when doing a

chere -ifcm -t mintty -s fish

and invoke the new fish shell from the Windows Explorer context menu, I
get plenty of error messages, like this:



(more of this kind follow).

This looks like there is a problem the PATH, but this happens even when
I use the -2 on chere when installing the shell. Note that bash or zsh
shells installed via cygwin work fine.

In this 'broken' fish shell, I enter

 echo $PATH; uname

and get the following output:


/cygdrive/c/windows/system32 /cygdrive/c/windows
/cygdrive/c/windows/System32/Wbem
/cygdrive/c/windows/System32/WindowsPowerShell/v1.0
/cygdrive/c/windows/System32/WindowsPowerShell/v1.0 /cygdrive/c/Program
Files (x86)/Common Files/Citrix/System32 /cygdrive/c/Program Files
(x86)/Citrix/ICAService /cygdrive/c/Program Files (x86)/Citrix/System32

To compare with, when I output the PATH from a "normal" fish shell (i.e.
one which I have invoked from, say, a bash shell), I get:

 echo $PATH
.:/home/ronald.fischer/bin:/usr/local/bin:/usr/bin:/cygdrive/c/windows/system32:/cygdrive/c/windows:/cygdrive/c/windows/System32/Wbem:/cygdrive/c/windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program
Files (x86)/Common Files/Citrix/System32:/cygdrive/c/Program Files
(x86)/Citrix/ICAService:/cygdrive/c/Program Files
(x86)/Citrix/System32:/usr/lib/lapack

We see that in fish, /usr/bin is missing from the PATH. This is strange,
in particular if I install chere fish with option -2, because in this
case, fish will be invoked via bash.

Ronald


Thanks for the report.

I've just checked my x86_64 and x86 installation. Things are working on 
my installation as I have c:\cygwin\bin on my standard windows path. 
When I remove it and invoke fish, I get the errors that you highlight. 
Similarly when echo'ing $PATH under the broken fish, /usr/bin is not one 
of the entries.


I need to have a play around to see how I can fix this, but I thought 
cygwin prepended /usr/bin to the path...



Regards,

Dave.

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

[ANNOUNCEMENT] Updated: chere-1.4-1 (x86 and x86_64)

[Dave Kilroy]

Version 1.4-1 of "chere" has been uploaded and should be available from 
mirrors shortly.


chere is a script allowing you to add Explorer context menus to start 
cygwin in the selected directory.


This script supports x86 and x86_64 simultaneously. If you have 32 and 
64 bit cygwin installed on the same machine, you can add separate 
context menu entries to start 32 or 64 bit terminals. The default menu 
text does not differentiate between 32 and 64 bit, so if you do this you 
should use the -e option.


Changes:
* Use getent to identify the user login shell when the shell is 
unspecified or set as passwd

* Support fish shell

Fixes:
* Allow cd'ing to directories containing single quotes when using 
registry one-liners (-1)


  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look 
at the "List-Unsubscribe: " tag in the email header of this message. 
Send email to the address specified there. It will be in the format:


cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available 
starting at this URL.


--
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: Testers needed: New passwd/group handling in Cygwin

[Dave Kilroy]

On 13/02/2014 21:48, David Stacey wrote:

On 13/02/2014 19:36, m0viefreak wrote:

Grepping through /bin I found at least one other package
that makes use of /etc/passwd as a file directly (cvsbug), but
since I don't have everything installed I can only assume there
are more cygwin-packages and other programs someone might build
from source.


My complete install is proving quite useful this week:

chere
xhere

All of these reference /etc/passwd; some of the above also use 
/etc/group.
chere (with the -s passwd) reads etc/passwd and starts the default shell 
of the current user from the explorer context menu. For now, I will 
expect users wanting this functionality to keep using/etc/passwd. If we 
grow a mechanism where the login shell can be queried easily, I'll 
update chere to use that.



Regards,

Dave.

--
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: Are there any plans to add chere in the x64 version?

[Dave Kilroy]

On 12/12/2013 17:01, klonos wrote:
Is there a feature request filed and any link to it so I can follow? 
Thanx in advance.



In case you missed it, I've just released an initial version of chere 
for x86_64



Dave.

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

[ANNOUNCEMENT] Updated: chere-1.3-1 (x86 and x86_64)

[Dave Kilroy]

Version 1.3-1 of "chere" has been uploaded and should be available from 
mirrors shortly.


chere is a script allowing you to add Explorer context menus to start 
cygwin in the selected directory.


This version of the script supports x86 and x86_64. If you have 32 and 
64 bit cygwin installed on the same machine, you can add separate 
context menu entries to start 32 or 64 bit terminals. The default menu 
text does not differentiate between 32 and 64 bit, so if you do this you 
should use the -e option.


Changes:
* Add background context menus on Windows 7 and later
* Support 64 bit cygwin

Fixes:
* Change to appropriate drive when shell is cmd
* Quote path for cmd correctly
* Uninstall correctly when cygwin not in path


  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look 
at the "List-Unsubscribe: " tag in the email header of this message. 
Send email to the address specified there. It will be in the format:


cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available 
starting at this URL.


--
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: Are there any plans to add chere in the x64 version?

[Dave Kilroy]

On 12/12/2013 17:01, klonos wrote:
Is there a feature request filed and any link to it so I can follow? 
Thanx in advance.


There's no feature request or link. I suspect the 32 bit package will 
work with x64 but haven't had time to check.



Dave.

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

Permissions Issue with Nested and/or local Groups

[Garber, Dave (GE Power & Water, Non-GE)]

We have a file share on machine1.  Machine1 has a local group, share_read, that 
contains a domain group share_readers and share_readers has a list of 
individuals with access to the share.  From Windows access is fine.  In Cygwin, 
ls -l is showing no access to the files for the users.  Adding the domain group 
directly to the share solves the problem.  I'm even able to duplicate this 
behavior locally on my machine with a group and a folder local to the machine, 
so it's not the fact that it's a network share.  And adding my domain account 
directly to the local group does not work either.  So it appears the culprit 
might be the local group.  Any thoughts?

Thanks In Advance,
Dave


--
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: chere + mintty doesn't work with mapped drives

[Dave Kilroy]

On 03/12/2013 10:21, Corinna Vinschen wrote:

On Dec  2 23:58, Charles Butterfield wrote:

Any suggestions on how to have a shortcut (or something similar) that
runs mintty as admin, but has no global effect on other mintty launches?

You seem to have gotten something else wrong here.  If the shortcut has
the "run as admin" flag, it only affects this shortcut.  I have two
shortcuts on the desktop, one called "Cygwin64 Terminal", the other one
"Cygwin64 Admin".
I think the difference is where you select the checkbox. There's one in 
Compatibility->Privilege Level->Run as admin, and another in 
Shortcut->Advanced->Run as admin. The compatibility one is telling 
windows that to execute mintty correctly it needs admin privileges, so 
it always runs mintty this way. The latter is the one that just affects 
the shortcut.


Glad you got to the bottom of this in the end.


Dave.

--
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: chere + mintty doesn't work with mapped drives

[Dave Kilroy]

On 01/12/2013 21:09, Corinna Vinschen wrote:

On Dec  1 15:48, Charles Butterfield wrote:

-Original Message-
From: David Kilroy [mailto:kilr...@googlemail.com]
Can you run the following commands from mintty running bash vs cmd
running bash:

cygpath -u "y:\apps"
test -d /cygdrive/y/apps
echo $?

Result of the first command should be /cygdrive/y/apps 2nd command
shouldn't output anything Result of 3rd command should be 0 (true)

Dave.

Results from MINTTY+BASH:
--
$ cygpath -u "y:\apps"
/cygdrive/y/apps

$ test -d /cygdrive/y/apps

$ echo $?
1

Results from CMD+BASH
--
$ cygpath -u "y:\apps"
/cygdrive/y/apps

$ test -d /cygdrive/y/apps

$ echo $?
0

Are you starting mintty with "run as administrator" by any chance?
Corrina's right - check that the same user is being used in both cases. 
I don't think this would explain why it's not working from the context 
menus though. Finding out why bash under mintty doesn't think 
/cygdrive/y/apps is a directory is the key.


Workaround: if you change everything in the if [ ! -z "$2" ] test in 
xhere to the snippet below, chere will attempt to change to the 
directory (but may fail)



Regards,

Dave.

if [ ! -z "$2" ]; then
 CHERE_DIR=`$CYGPATH "$2"`
 NETWORK_PATH=/$CHERE_DIR
 if [ -d "$CHERE_DIR" ]; then
  cd "$CHERE_DIR"

 # If the full path doesn't exist, this is prob a network path
 elif [ -d "$NETWORK_PATH" ]; then
  cd "$NETWORK_PATH"

 # Not a directory? Take a guess...
 else
  cd "$CHERE_DIR"

 fi
fi


--
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: chere + mintty doesn't work with mapped drives

[Dave Kilroy]

On 29/11/2013 22:11, Charles Butterfield wrote:

Dave wrote:

Can you clarify which isn't working:
a) a network share mapped to a drive letter, e.g N:\my\network\location

This is my situation.  I have my Y: drive mapped to a Linux Samba server.  See 
more details below


b) network share accessed via \\ e.g. \\server\path\my\network\location

Not doing this.


Are you right clicking on a directory and selecting the menu item, or right 
clicking a blank spot in the RH pane? The two result in different logic, with
the latter having to guess it's a network path.

I am right clicking on a directory name in either (tried both) the LH or RH 
pane of an explore.exe window.  In both cases what happens
Is that a new window is launched (good) with an initial title of the form 
"/bin/xhere /bin/bash.exe Y:\apps".  After a brief pause, I see
"Starting /bin/bash.exe", than another brief pause and the window title changes to 
"/cygdrive/c/WINDOWS/system32" and I get a
Bash command prompt.  The PWD is just what the title indicates (i.e. 
.../system32)
The xhere script should pass y:\apps to cygpath to get the cygwin path, 
which should be /cygdrive/y/apps. IIRC /cygdrive/y may not be visible 
via ls, but it should be usable. I'm guessing the path is failing the 
directory test... in which case adding a trailing else to always cd 
$CHERE_DIR would fix things for you



Dave.

P.S. I'm also having trouble figuring out how to post replies to what I see on 
the web archive.  I did NOT get any email reply to my prior post, it just 
showed up on the web archive (that was good).  I carefully checked my spam 
quarantine areas several times to be sure.  Actually my first post on this 
topic was my second attempt to  post.  I had to add myself to the white-list 
which I didn't notice at first since the white-list suggestion was stuck in MY 
stupid stupid Outlook spam filter (Thanks so much Outlook).

In any event, I have cobbled together something that resembles a reply to an email that I 
have really scraped off the web archive.  That seems awfully complicated.  Surely I'm 
missing something.  But I just cannot see the "Reply" button on the archive.  
Is this like when my wife says, its right there and points to it and yep, its really 
right there?  :-(

I just replied to list on the last message. This time I've made sure 
you're in cc.


--
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: chere + mintty doesn't work with mapped drives

[Dave Kilroy]

On 29/11/2013 17:29, Charles Butterfield wrote:

I've noticed that if I install a right-click shell entry via "chere" and use 
"minty" as the terminal that I cannot start a shell on a network share.  This is true 
regardless of which of the following two installation commands I execute:

chere -I -t mintty -s bash
chere -i -2 -t mintty -s bash

A related clue is that when using a mintty terminal I cannot see network shares 
in /cygdrive, but when using the default chere shell I can see the network 
shares mapped to drives (e.g. /cygdrive/y/...).

Any suggestions?

Can you clarify which isn't working:

a) a network share mapped to a drive letter, e.g N:\my\network\location
b) network share accessed via \\ e.g. \\server\path\my\network\location

I think a) should always work.

Are you right clicking on a directory and selecting the menu item, or 
right clicking a blank spot in the RH pane? The two result in different 
logic, with the latter having to guess it's a network path. You may be 
able to figure out what's going on by adding a few echos to /bin/xhere



Dave.

--
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] Updated: expat 2.1.0-1

[Dave Korn]

On 16/04/2013 14:25, Warren Young wrote:
> On 4/11/2013 14:38, Dave Korn wrote:
>> 
>> The static archive /usr/lib/libexpat.a was present in 2.0.1-1(*) and is 
>> missing in 2.1.0-1(**), was that intentional?
> 
> I think I got that, um, "feature" for free when I converted to cygport for
> that package.  Someone is passing --disable-static to the configure script,
> and it isn't me.
> 
> I've fixed this with CYGCONF_ARGS="--enable-static"  The static library 
> does now appear in the -devel package.
> 
> The .a is about 3x the size of the .dll.  Is that normal, or am I supposed
> to be stripping the .a before packaging it?

  Yes, totally normal, it's a whole set of individual object files with all
their overhead, rather than just the linked text/data content of those files.
 No, don't strip it, that decision should be left until linking a final
executable.

> Does someone actually want this static library?  I'm going to RFU it 
> anyway, since I've gone to the trouble of fixing it, but I was curious if
> it actually mattered to someone.

  GDB apparently prefers linking statically to libexpat.  Dunno why, but it
saves me adjusting my dependencies in a package I'm shipping to a customer, so
thanks :)

cheers,
  DaveK


--
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: Debugging totally broken with latest everything?

[Dave Korn]

On 15/04/2013 18:14, Christopher Faylor wrote:
> On Mon, Apr 15, 2013 at 05:03:17PM +0100, Dave Korn wrote:
>>  Some notes on the above:
>>
>>  The same happens with both the previous version and current snapshot of the
>> cygwin dll.  It also happens with both current gdb and an old gdb
>> 6.8.0.20080328-cvs that I have lying around.
>>
>>  The hw.exe in question is your bog-standard hello world, compiled with "-g
>> -O0" using gcc4-4.5.3-3.
>>
>>  "kill -9" won't kill gdb; I have to use Windows task manager.  If I've
>> attached gdb to the hung gdb, I can kill it from there using the "k" 
>> instruction.
>>
>>  Anyone else having similar problems?
> 
> You're probably seeing a known bug in gdb where it no longer works well
> when run from a console window.  There is a race where gdb tries to get
> tty information from a stopped cygwin process.  Although I didn't
> introduce the problem, I have tried to fix it from time to time without
> much luck.

  It must be an interaction between gdb and the cygwin dll, since my
old-and-previously-working-just-fine-in-a-console gdb-6 has also stopped 
working.

> Debugging from mintty will probably work better.

  It certainly does.  Thanks for the tip.

cheers,
  DaveK


--
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] Updated: expat 2.1.0-1

[Dave Korn]

On 12/06/2012 13:31, Warren Young wrote:
> PACKAGE DESCRIPTION
> ===
> 
> Homepage: http://sourceforge.net/projects/expat/
> License : MIT-like
> 
> Expat is a C library for parsing XML, originally created and maintained
> by James Clark, but since 2001 taken over by a loose group of contributors.
> 
> 
> CYGWIN-SPECIFIC CHANGES SINCE LAST RELEASE
> ==
> 
> None.  This release simply tracks the 2.0.1 -> 2.1.0 upstream release.

  The static archive /usr/lib/libexpat.a was present in 2.0.1-1(*) and is
missing in 2.1.0-1(**), was that intentional?

cheers,
  DaveK
--
*  - http://cygwin.com/packages/libexpat1-devel/libexpat1-devel-2.0.1-1
** - http://cygwin.com/packages/libexpat1-devel/libexpat1-devel-2.1.0-1


--
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] Updated: experimental package: gcc4-4.7.2-2

[Dave Korn]

On 11/04/2013 00:58, Dave Korn wrote:

>   I would like to express my gratitude to JonY for stepping into the breach
> caused by my absence from the Cygwin community and releasing the first test
> version of GCC 4.7 series.  He did a very difficult job and did it well and
> deserves the highest of praise for doing so.

  It was suggested to me off-list, and I concur, that this is worthy of a gold
star, if not two.  May it please the maintainer of the stars to consider my
request?

cheers,
  DaveK

--
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: FIXED: GCC can't find its header directoriescy

[Dave Korn]

On 11/04/2013 07:08, Duncan Roe wrote:
> Thanks Dave - removing the old cygwin dlls from C:\WINDOWS fixed gcc &
> alternatives.

  Glad to hear it!

> I put them there because I like to have the odd cygwin utility available
> to CMD.EXE. 
> 
> May put them back - but will take more care with them in future,

  The better way to do that is just to add your cygwin\bin dir to your PATH in
the Windows environment variables.  That way you get all your cygwin stuff
available in cmd.exe but it's always the up-to-date stuff from your main
installation.

  (The only problem I've ever run into in this approach is that both Cygwin
and MSVC have a "link.exe" command, so you can end up getting the wrong one.
You can avoid this by any combination of specifying full paths to the
particular one you want, choosing whether to put cygwin\bin at the start or
end of your Windows PATH, or customising your vcvars.bat to make sure the MSVC
version is earlier in the PATH when you launch it.  I've never found it to be
a big problem compared to the convenience of having a real grep available in
cmd.exe!)

cheers,
  DaveK


--
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: GCC can't find its header directoriescy

[Dave Korn]

On 11/04/2013 06:12, Duncan Roe wrote:
> Thanks guys for the pointers to cygmpfr-4.dll. Got it.
> 
> This problem with headers started happening on an old installation so I
> reinstalled but it still happens:

> ignoring nonexistent directory "/usr/include"

> strerror.c:2:19: error: no include path in which to search for stdio.h

> 12:33:27$ ls /usr/include

> locale.hnetdb.h reent.h stdio.h  termios.h   wait.h

> /usr/include definitely exists but gcc / cpp claims it does not.
> Since this "just started happening" I wonder whether it is caused by
> some update to Windows. (Win XP SP3).
> 
> Anyone else seen anything like it? I'm stuck,

  Bizarre.  I've never seen anything like it, nor your problem with "altdir
invalid".  However I've got one guess about what might be interfering, from
your cygcheck.out:

>45k 2010/08/15 C:\WINDOWS\cyggcc_s-1.dll - os=4.0 img=1.0 sys=4.0
>   "cyggcc_s-1.dll" v0.0 ts=2010/8/15 8:57
>   982k 2009/12/23 C:\WINDOWS\cygiconv-2.dll - os=4.0 img=1.0 sys=4.0
>   "cygiconv-2.dll" v0.0 ts=2009/12/24 0:25
>31k 2011/11/28 C:\WINDOWS\cygintl-1.dll - os=4.0 img=1.0 sys=4.0
>   "cygintl-8.dll" v0.0 ts=2009/4/3 12:15
>31k 2009/04/03 C:\WINDOWS\cygintl-2.dll - os=4.0 img=1.0 sys=4.0
>   "cygintl-8.dll" v0.0 ts=2009/4/3 12:15
>31k 2009/04/03 C:\WINDOWS\cygintl-8.dll - os=4.0 img=1.0 sys=4.0
>   "cygintl-8.dll" v0.0 ts=2009/4/3 12:15
>   224k 2010/06/15 C:\WINDOWS\cygpcre-0.dll - os=4.0 img=1.0 sys=4.0
>   "cygpcre-0.dll" v0.0 ts=2010/6/15 14:10
>10k 2009/12/14 C:\WINDOWS\cygsigsegv-2.dll - os=4.0 img=1.0 sys=4.0
>   "cygsigsegv-2.dll" v0.0 ts=2009/12/14 23:56
>  2586k 2010/08/31 C:\WINDOWS\cygwin1.dll - os=4.0 img=1.0 sys=4.0
>   "cygwin1.dll" v0.0 ts=2010/8/31 17:58
> Cygwin DLL version info:
> DLL version: 1.7.7

  Those could well have been interfering.  Get rid of all Cygwin-related DLLs
from your C:\WINDOWS folder (maybe stash them away somewhere safe in case they
turn out to be needed by some Cygwin-dependent application you've got on your
system), then reinstall everything using setup.exe (click on "Default" next to
the "All" category in the Category view until it switches to "Reinstall",
ignore the couple of warning boxes that pop up on the way there) and see if it
all works better once that's completed.

cheers,
  DaveK



--
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: 1.7.15: gcc fails to load: missing cygmpfr-4.dll

[Dave Korn]

On 11/04/2013 02:57, Duncan Roe wrote:
> I have just installed cygwin on this system.
> When I try to compile a small program, I get this error:
> 
> /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe: error while loading shared
> libraries: cygmpfr-4.dll: cannot open shared object file: No such file
> or directory

  Sorry about that, I missed a dependency when I uploaded it.

  It's actually fixed as of a few hours ago, but the fix must not have reached
your mirror yet.

  Just use setup.exe to install libmpfr4.

cheers,
  DaveK


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

[ANNOUNCEMENT] Updated: experimental package: gcc4-4.7.2-2

[Dave Korn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


  I have just uploaded an updated GCC-4 package to cygwin.com.  It will be
arriving at your favourite mirror next time it synchronizes itself with the
official Cygwin repository.

  This is a test release of GCC 4.7.2 which replaces the earlier
test release.  It reverts the package dependencies in the Cygwin repository to
those that are correct for the current full version of GCC, 4.5.3-3, as
setup.exe can only support one set of dependencies for all versions of a
package.  This means you may need to select some of the new packages manually,
depending on the set of languages you are installing; see the "important note"
section in "From the README" below.

  In addition, this release restores libffi and java which were unavailable
from the previous test version.

  It also makes linking against shared libgcc the default for executables as
well as DLLs, which is necessary for correct sharing of thread-local variables
imported by executables from DLLs.

  I would like to express my gratitude to JonY for stepping into the breach
caused by my absence from the Cygwin community and releasing the first test
version of GCC 4.7 series.  He did a very difficult job and did it well and
deserves the highest of praise for doing so.


--ooOOOoo--
PLEASE SEND BUG REPORTS, PROBLEMS, ETC. TO THE CYGWIN MAILING LIST.
--ooOOOoo--


OBTAINING THE RELEASE
=

To update your installation, click on the "Install Cygwin now" link on the
http://cygwin.com/ web page. This downloads setup.exe to your system. Then,
run setup.exe, fill in all of the options, and make appropriate choices on the
"Select Packages" screen. Because this is a "test" version release, you will
need to manually select any packages and dependent libraries you require: see
below for full details.


NEWS


> > From the README:

IMPORTANT NOTE ABOUT DEPENDENCIES AND RUNTIME LIBRARIES
===

Cygwin's setup.exe does not handle a situation where an experimental package
version has different dependencies from the main current version.  For this
reason, the dependencies listed in the Cygwin package repository are those
required by the mainstream (4.5.3-3) release of Cygwin GCC, as those will be
correct for the majority of users.  Anyone wishing to install the test version
of GCC will need to ensure they select manually select the corresponding new
versions of the runtime libraries required.  These dependencies are:

gcc4-java: Requires libgcj13.
gcc4-objc: Requires libobjc4.
gcc4-ada: Requires libgnat4.7.
gcc4-fortran: Requires libquadmath0, libquadmath0-devel.
libgfortran3: Requires libquadmath0.

Cygwin port maintained by: Dave Korn

Please address all questions to the main Cygwin mailing list.

This is the key used for signing Cygwin GCC releases:

pub   1024D/6A388C3E 2008-05-31
uid  Dave Korn (release signing key)
 
sub   4096g/D4E41590 2008-05-31

Also available at a key-server near you!

- -BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.4.9 (Cygwin)

mQGiBEhBdVwRBADGS7UWOR8lvHOcOs161cRjTw1Yp3Qj4Xy5JbaSQFZ6m+DTM7GD
y4tPrM1jr6uYGzikdNzYL6tWKUDvVYjs7bwYJXBQ7ryeLJ4LXs+8cmIFIl4uMc8P
BEpT67gs1+MchBemr1B/s4V8s9laX81mMYd73qqefuCnbUU8+iBKBzfDhwCg6xQU
yIORoWJz5qIHwO23N2uuuKUD/0AsLJOMV1Ig/NVK8ZMss4ozIsgOiBBJ7ZQ9bzzR
8D5EhahVTwPJ7dMXGKWfb21gJHtYjOtwDYJyc5HdIHBPWylI0u6vkiIDD4TZjSDA
fIMBgTKp9SjKBtr4ZJzYZUguTFGJFBDLyieyUDWTXBVQSaDASzEjwwdbbKo5/wzY
GzvYA/458txhAz1GoB3hnaEJgIK0HaOVjetvZif9QQ1L0x10EIjdwgxN8pMR3Gv8
d+pALJpivIe5eMrU2QLpSbiK5QRkndJBYdiEobLCY3Ca6elRB8/ioKUyOzngtAe9
ny0dUNEWDxwtk2yJSxMrcfRjSJMs+4efCqXrRIkfXr1ibE1JybQ8RGF2ZSBLb3Ju
IChyZWxlYXNlIHNpZ25pbmcga2V5KSA8ZGF2ZS5rb3JuLmN5Z3dpbkBnbWFpbC5j
b20+iGMEExECACMCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCSMUtrgIZAQAK
CRBN0oLlajiMPrQTAKCJhzyfI8MKSJjYNTXYCo/GITfvTQCgp2Jw70u5NQojF09f
uPhfnX+xed+IYwQTEQIAIwIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheABQJIVRdm
AhkBAAoJEE3SguVqOIw+l4QAoJSM49UfFNHx3jSTV3+o+TQF9Uo/AKDa5iFeDTuO
10t5Rpng0OWJPTR7N7kEDQRIQXVcEBAAnOffXRQSAPcJKW9z8OXwd0UmNFGZbjb5
CW53i2HYmqiYfMLL6XHyyB2o0e0jZuao/+PgxnoVaqpPh7DXYfjup/u5ll2kAK2I
VImGIFYifRLQAWCivQa4LXWR2EvIi1MURrmEjN+JKStBAySiED21QELetUGNzeYT
rsWBpHmAibcBAbwFPw0mhFPqvApcrpMJhALehCqPEu/rfeUnziqo8pdpeKkL0ENl
GsNONGYhDIjzexclRNFFYwzmK2cS5sxwyH94OxBABfgwxsVYB0+zsdjPk3JybK52
+MIcYQU4NBoCYo184pFJ4QhzKmt/8sAicaxLsU4DHqyy9SwFH1cV1Su5RN3DGG2S
0hFImqyTeCiSW2FDSgOtAF0ImEY3HNkfLgych5nFKRj0itPdFG/t6qCJKLf8JsZP
2QDaLQO+42jwn6Y47PaBEMJGttPaY6guATJqVefqayKI4j22w2le4PLxYJ3fIlqi
5rS5m6mJV2ZFRuqSgmGPDgb8+vnvTG/PCTCcK3j4jzUvJ3bX9FtyV9cFnlF+CfQc
ZMdx4qHrhKgoiqJt19Mk8rb19L6KqyLNgJyqvwOcsX8P2yM8t/FAuUeg1EgnYbMz
RywEHEa2+rj2R1FPJGtJdOQLgrPgd4m9t5Eq7zFPuJgKNlWHf1Y0M82A37iYnWna
DyqON5+pPQ8ABAsP/jOOvQjU79Pd8ph7c2LK+UUjGPQVYO5bwUOCDs9ctSIbQgPh
R4l

Re: starting cygwin shell

[Dave Korn]

On 07/04/2013 19:50, Christopher Faylor wrote:
> On Sun, Apr 07, 2013 at 06:16:17PM +, Gene wrote:

>> save: fork_level=1 SetHandleInformation() failed: fd 0 handle 0x3 type
>> 2: Th e parameter is incorrect.
> 
> That error message doesn't seem to be coming from Cygwin.  I have
> grepped the Cygwin DLL and *sh* and don't see it anywhere.
> 
> Are you possibly using other binaries besides Cygwin ones?

  A quick google suggests it comes from MKS.  Trying to mix Cygwin tools and
MKS ones at the same time won't generally work well, and is probably the cause
of the shell problems too - MKS apparently is known to have problems under Win7.

  Gene, try removing MKS from your PATH setting.

cheers,
  DaveK


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

[coreutils] Bug in du with -x flag?

[Dave Korn]

Hi list,

  I always used to use du with the -cxhs options, but since updating to the
latest (8.15-1) version there appears to be a problem caused by -x:

> $ ls -la
> total 392188
> drwxr-xr-x+ 1 DKAdmin None 0 Apr  6 00:35 .
> drwxr-xr-x+ 1 DKAdmin None 0 Apr  3 05:58 ..
> drwxr-xr-x+ 1 DKAdmin None 0 Apr  3 16:28 gcc4
> -rw-r--r--  1 DKAdmin None 40157 Apr  6 00:43 gcc472-2-dist.tar.bz2
> 
> $ du -xh gcc472-2-dist.tar.bz2
> 
> $ du -h gcc472-2-dist.tar.bz2
> 383Mgcc472-2-dist.tar.bz2
> 
> $

  Unless I'm misunderstanding it badly, -x shouldn't make any difference when
counting a real file in the current directory.  I wonder if it could have
perhaps been introduced by the recent related bugfix that I read about in
/usr/share/doc/coreutils/NEWS:

>   du -x no longer counts root directories of other file systems.
>   [bug introduced in coreutils-5.1.0]

or perhaps some interaction between that and Cygwin's path conversion code?

cheers,
  DaveK


--
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: Problems with GCC-4.7.2-1 (test)

[Dave Korn]

On 05/04/2013 20:52, Ryan Johnson wrote:
> On 05/04/2013 3:07 PM, Angelo Graziosi wrote:
>> Dave Korn wrote:
>>> Did you install the manually-required runtime libs as well?
>>
>> I don't understand here. I have installed GCC-4.7.2-1 with setup.exe
>> choosing "Exp" packages and then leaving only 4.7.2-1 for
>> installation. Which runtime libs it needs? "manually-required"?
>>
>> Shouldn't test packages be installed only with setup.exe? I am
>> confused now... :-(
> I think he means the other gcc-related packages in setup.exe;
> dependencies of test packages aren't tracked because they tend to pull
> in experimental versions of dependencies for non-experimental packages
> you might have installed. A shortcoming of setup.exe.
> 
> I don't know which dependencies those might be, though...

  They were listed in the announcement:

> 2. Setup does not pull all required dependencies.
> This is done on purpose to allow the default 4.5.3-3 release to work out
> of the box. There are 3 new packages that should be noted if you install
> this version of gcc.
> 
> libgnat4.7, libobjc4 and libquadmath0 for gcc4-ada, gcc4-objc and
> gcc4-fortran respectively.

  Probably not related, I guess.

cheers,
  DaveK


--
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: Problems with GCC-4.7.2-1 (test)

[Dave Korn]

On 05/04/2013 12:22, Angelo Graziosi wrote:
> Just for completeness...
> 
> This morning I have installed the test release of GCC-4.7 (4.7.2-1) and
> after that a few applications do not work any more.
> 
> For example, Terminator, installed via Cygwinports, does not start. From
> command line I have:
> 
> $ terminator
> 
> You need to install the python bindings for gobject, gtk and pango to
> run Terminator.

> I have also a GTK-build of Emacs trunk and
> 
> $ emacs -Q
> 
> /usr/local/emacs/bin/emacs-24.3.50.exe: error while loading shared
> libraries: ?: cannot open shared object file: No such file or directory

  This looks like the quickest point to try tracking it down.  Does cygcheck
on the exe show any missing DLLs?

> Reverting to GCC-4.5.3 all works fine.
> 
> BTW, I did the Emacs build using CLANG (3.1, i386-pc-cygwin), so I don't
> understand much why the new GCC-4.7 interferes with Emacs.

  Did you install the manually-required runtime libs as well?

cheers,
  DaveK

--
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: cygport debuginfo problem: packaging fails.

[Dave Korn]

On 01/04/2013 09:56, Dave Korn wrote:
> Hi Yaakov et al.,
> 
>   I'm confused by the output from cygport (0.11.3) when building GCC.  During
> the packaging step, after the final binary package from PKG_NAMES has been
> tarballed, I see:
> 
>> *** Info: No debug files, skipping debuginfo subpackage

  OK, so this means that ${D}/usr/src/debug does not exist, and that's because
nothing was installed there by __prepdebugsrc().  That has something to do
with the fact that none of my source files got listed in ${T}/.dbgsrc.out, and
I think that in turn is because objdumping the built exes doesn't reveal any
paths to source files that begin with '/usr/src/debug'.

  That seems to be because no -fdebug-prefix-map options got added during the
build stage.  Or rather, the options did get added, but that was before
/usr/bin/cygport included my .cygport script, which went and unset them again.
 I'm not sure why I originally included that any more, I left a comment about
how setting them in the environment "confuses auto-detection process during
gcc build stages", which isn't as clear as I now wish, so I guess I'll just
delete that bit and try again.  Looks like the problem is my fault, anyway;
pardon the noise.

cheers,
  DaveK



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

cygport debuginfo problem: packaging fails.

[Dave Korn]

Hi Yaakov et al.,

  I'm confused by the output from cygport (0.11.3) when building GCC.  During
the packaging step, after the final binary package from PKG_NAMES has been
tarballed, I see:

> 
> *** Info: No debug files, skipping debuginfo subpackage
> 
 Checking packages for missing or duplicate files
> *** Warning: Packages are missing files:
> -usr/lib/debug/usr/bin/c++-4.exe.dbg
> -usr/lib/debug/usr/bin/cpp-4.exe.dbg
> -usr/lib/debug/usr/bin/cygffi-4.dll.dbg
> -usr/lib/debug/usr/bin/cyggcc_s-1.dll.dbg

  I don't understand this.  First it's complaining that there aren't any debug
files, so it won't package them, but then they actually are there after all
and it complains they haven't been packaged.  That appears self-contradictory!

  Any idea what might be causing this?  Do I have to create -debuginfo
packages manually if I'm using the PKG_NAMES and (package)_CONTENTS variables?
 Or could it perhaps be because the PN package itself has no contents at all,
serving only as a dummy to draw in dependencies through the requires: line in
its setup.hint?  (In my cygport script, PKG_NAMES contains "${PN}" but there
is no ${PN}_CONTENTS defined anywhere.)

cheers,
  DaveK


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

Missing mime types lead to broken pages in the package list.

[Dave Korn]

Hi folks,

  There are a lot of broken entries in the lower levels of the package list on
the website.  Clicking a package name at http://cygwin.com/packages/ takes you
to the page that lists the available binary and source package versions, as
before, but attempting to follow the link to one of the versions to see the
package contents works for some packages, displaying a webpage, but for others
triggers a file download dialog in your browser.  A few examples:

http://cygwin.com/packages/expat/ - broken
http://cygwin.com/packages/fcgi/ - broken
http://cygwin.com/packages/flawfinder/ - working
http://cygwin.com/packages/gnupg/ - broken

  According to wget, the working links are being served up with text/html mime
type, but the broken ones are coming down as application/x-troff-man.

  Fallout from the recent upgrade?

cheers,
  DaveK


--
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: Why libquadmath0-4.7.2

[Dave Korn]

On 11/03/2013 22:12, JonY wrote:
> On 3/12/2013 02:03, Dave Korn wrote:
>> On 05/03/2013 16:22, Christopher Faylor wrote:
>>> On Tue, Mar 05, 2013 at 05:11:34PM +0100, Angelo Graziosi wrote:
>>>> I have GCC-4.5.3 installed and I am not going to install the test 
>>>> version 4.7.2-1, but setup.exe *wants* to install libquadmath0-4.7.2-1 
>>>> even if I have selected "Curr" packages (which should exclude any 
>>>> reference to 4.7.2 version...).
>>>>
>>>> Have we sure it isn't a packaging bug?
>>> The crude dependency handling in setup.exe isn't up to the task of
>>> allowing per-version dependencies.  So this probably came along because
>>> it's required for a newer version of gcc.
>>   When last we spoke (on the -apps list), it was suggested that the
>> dependencies should remain correct for the curr: version, and people
>> installing the test: version should manually install the required 
>> dependencies.
>>
>>   If it would help, I could upload a 4.7.2-2 later tonight which restores 
>> java
>> and has the original 4.5.3-3 dependencies?
> 
> You'll be retaking maintainership again? I don't mind that, but please
> push as much of the patches as possible upstream, it was kind of hard to
> wrap my head around the patches to manually apply them.

  I would like to resume maintaining it, subject to any discussions necessary.
 Being an upstream maintainer makes it easier for me to push patches.

cheers,
  DaveK



--
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: Why libquadmath0-4.7.2

[Dave Korn]

On 11/03/2013 23:21, Christopher Faylor wrote:
> On Mon, Mar 11, 2013 at 06:03:08PM +0000, Dave Korn wrote:
>> On 05/03/2013 16:22, Christopher Faylor wrote:
>>> On Tue, Mar 05, 2013 at 05:11:34PM +0100, Angelo Graziosi wrote:
>>>> I have GCC-4.5.3 installed and I am not going to install the test 
>>>> version 4.7.2-1, but setup.exe *wants* to install libquadmath0-4.7.2-1 
>>>> even if I have selected "Curr" packages (which should exclude any 
>>>> reference to 4.7.2 version...).
>>>>
>>>> Have we sure it isn't a packaging bug?
>>> The crude dependency handling in setup.exe isn't up to the task of
>>> allowing per-version dependencies.  So this probably came along because
>>> it's required for a newer version of gcc.
>> When last we spoke (on the -apps list), it was suggested that the
>> dependencies should remain correct for the curr: version, and people
>> installing the test: version should manually install the required
>> dependencies.
> 
> Dave, I've pinged you on the -apps list and you haven't responded.

  How recently?  I've got a backlog of 2400 unread mails there (and 8682 mails
here).  Yes, I've been away, but I can now commit to being back on the case;
the project I've been working on for the past god-knows-how-long is done.
I've already got back to work on upstream GCC and would like to get back to
work on Cygwin.

cheers,
  DaveK

--
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: Why libquadmath0-4.7.2

[Dave Korn]

On 05/03/2013 16:22, Christopher Faylor wrote:
> On Tue, Mar 05, 2013 at 05:11:34PM +0100, Angelo Graziosi wrote:
>> I have GCC-4.5.3 installed and I am not going to install the test 
>> version 4.7.2-1, but setup.exe *wants* to install libquadmath0-4.7.2-1 
>> even if I have selected "Curr" packages (which should exclude any 
>> reference to 4.7.2 version...).
>>
>> Have we sure it isn't a packaging bug?
> 
> The crude dependency handling in setup.exe isn't up to the task of
> allowing per-version dependencies.  So this probably came along because
> it's required for a newer version of gcc.

  When last we spoke (on the -apps list), it was suggested that the
dependencies should remain correct for the curr: version, and people
installing the test: version should manually install the required dependencies.

  If it would help, I could upload a 4.7.2-2 later tonight which restores java
and has the original 4.5.3-3 dependencies?

  (Many thanks to JonY for stepping up to the plate while I've been away.)

cheers,
  DaveK


--
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: Weird threading / __thread behavior

[Dave Korn]

On 18/02/2013 11:59, Ryan Johnson wrote:
> On 17/02/2013 10:38 PM, Zach Saw wrote:
>> The following test case fails on Cygwin but passes on Linux (both
>> tested using
>> GCC 4.7.2).
> Cygwin doesn't have a gcc-4.7.2 package yet (not even for testing);
> 4.5.3 is the highest I see this morning in setup.exe.

  Sorry gang, I've been on hiatus.

  I have almost got 4.7.2 GTG, and I'm starting to pay some attention to GCC
trunk again.

cheers,
  DaveK

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

cygwin problem - installation halting at 00ash.sh

[Dave Goodall]

In Sep 2012 we tried installing cygwin with the then latest setup.exe
version 2.573.2.2 on a new Windows 2008 Server (x64) and the
installation hung at 98%.

Yesterday Feb 12 2013 we downloaded the latest cygwin DLL setup.exe (1.7.17-1)
Prior to running the install on a Windows Server 2008 server we
cleaned the registry of prior cygwin entries and turned off virus
checking.

The install hangs executing the post-install script
"/etc/postinstall/00ash.sh".

A search of the mailing list archives (http://cygwin.com/ml/cygwin/) for 00ssh
returns 61 results, the latest of which is Steven Julian (2009/08/07).
The issue goes back a long way:
Sep 2005 (http://www.cygwin.com/ml/cygwin/2005-09/msg00164.html)
Aug 2006 ( http://cygwin.com/ml/cygwin/2006-08/msg00813.html)

Reading through the posts i don't see that the root cause and
definitive resolution have been determined.

The issue is still with us in Feb 2013.

The latest install is:
  Cygwin setup.exe version : 2.774 (As reported in Setup.log)
  Cygwin DLL version   : 1.7.17-1 (As stated on cywin.com home page)
  Cygwin DLL version   : 1.5.25 (As reported by cygcheck -s)
  Cygwin DLL Build date: Fri Dec 14 19:21:07 CET 2007 (As reported
by cygcheck -s)

 The www.cygwin.com home page states "The Cygwin DLL currently works with
  all recent, commercially released x86 32 bit and 64 bit versions of Windows,
  with the exception of Windows CE and Windows NT4." which I read as
meaning that
  Windows Server 2008 (x64) is a supported platform.

  FAQ 1.2 ( http://cygwin.com/faq-nochunks.html#faq.what.supported)
  states : 'Cygwin can be expected to run on all modern 32 bit
versions of Windows
  This includes, as of the time of writing this, Windows 2000, Windows XP,
  Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7,
  as well as the WOW64 32 bit environment on released 64 bit versions
of Windows
  (XP/2003/Vista/2008/7/2008 R2).

  However, cygcheck -s -v -r outputs (see below) this as the first
line of it's output:
  C:\cygwin\bin>cygcheck -s
  Cygwin Configuration Diagnostics
  Current System Time: Wed Feb 13 16:55:23 2013
  Windows Longhorn/Vista (not yet supported!) Ver 6.0 Build 6002 Service Pack 2
  Running under WOW64 on AMD64

  Per http://en.wikipedia.org/wiki/Windows_Server_2008
  Longhorn is Windows Server 2008 (built on the same codebase as
Windows Vista).

So, apologising for this somewhat lengthy pre-amble, I would
appreciate input from the community:

1. The cygwin.com home page and FAQ appears to state that Cygwin is
supported on Windows Server 2008.
The cygcheck author(s) explicitly state that Longhorn (aka Windows
Server 2008) is not supported.
 Which is right?

2. Is a definitive root cause known for the 00ash.sh / 98% halting problem?

3. Is there a definitive work around for this?  The best I can find to date is
 http://cygwin.com/ml/cygwin/2006-09/msg00551.html which provides only the
 assurance that 'Hopefully one of these two procedures will get all your
 postinstall scripts to run.'

---
 Attached : Output from  cygcheck -s -v -r > cygcheck.out

--- The actual user name string has been replaced with USERNAME ---

c:\cygwin\bin>cygcheck -s -v -r > cygcheck_s_r_v.txt
'id' program not found
'id' program not found

c:\cygwin\bin>type cygcheck.out

Cygwin Configuration Diagnostics
Current System Time: Wed Feb 13 16:55:23 2013

Windows Longhorn/Vista (not yet supported!) Ver 6.0 Build 6002 Service Pack 2

Running under WOW64 on AMD64

Running in Terminal Service session

Path:   C:\Program Files (x86)\MKS Toolkit\mksnt
C:\PROGRA~2\MKSTOO~1\bin64
C:\PROGRA~2\MKSTOO~1\bin
C:\PROGRA~2\MKSTOO~1\bin\X11
C:\PROGRA~2\MKSTOO~1\mksnt
D:\IBM\InformationServer\ASBNode\apps\jre\bin\classic
D:\IBM\InformationServer\ASBNode\lib\cpp
D:\IBM\InformationServer\ASBNode\apps\proxy\cpp\vc60\MT_dll\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\IBM\ITM\bin
C:\IBM\ITM\TMAITM6
C:\IBM\ITM\InstallITM

SysDir: C:\Windows\system32
WinDir: C:\Users\USERNAME\WINDOWS

HOME = 'C:\Users\USERNAME'
Path = 'C:\Program Files (x86)\MKS
Toolkit\mksnt;C:\PROGRA~2\MKSTOO~1\bin64;C:\PROGRA~2\MKSTOO~1\bin;C:\PROGRA~2\MKSTOO~
1\bin\X11;C:\PROGRA~2\MKSTOO~1\mksnt;D:\IBM\InformationServer\ASBNode\apps\jre\bin\classic;D:\IBM\InformationServer\ASBN
ode\lib\cpp;D:\IBM\InformationServer\ASBNode\apps\proxy\cpp\vc60\MT_dll\bin;C:\Windows\system32;C:\Windows;C:\Windows\Sy
stem32\Wbem;C:\IBM\ITM\bin;C:\IBM\ITM\TMAITM6;C:\IBM\ITM\InstallITM'

ALLUSERSPROFILE = 'C:\ProgramData'
APPDATA = 'C:\Users\USERNAME\AppData\Roaming'
CANDLE_HOME = 'C:\IBM\ITM'
CLIENTNAME = 'USCHCTXPS13'
CommonProgramFiles = 'C:\Program Files (x86)\Common Files'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
CommonProgramW6432 = 'C:\Program

[ANNOUNCEMENT] Obsolete Package: mlcscope-99-1

[Dave And Diane]

The package mlcscope-99-1 has been obsoleted and replaced by 
cscope-15.8.0.1-1


mlcscope was a Lucent Technologies implementation of cscope which is no 
longer maintained.


cscope is commonly found in Linux distributions such as Debian and other 
Unix O/S's.


Cygwin setup has been updated to automatically install cscope if 
mlcscope was installed.


Instead of using 'mlcscope' to interrogate source code, use 'cscope' 
going forward.


Cheers
Dave


--

Diane & Dave
http://www.velvetstarbears.com/  http://www.kringlecottage.com/
Fortune: The difference between America and England is that the
English think 100 miles is a long distance and the Americans
think 100 years is a long time.


--
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: gcc-4.7.0-RC-20120302 fails to build for i686-pc-cygwin

[Dave Korn]

On 07/03/2012 13:34, Ryan Johnson wrote:
> On 07/03/2012 8:07 AM, Corinna Vinschen wrote:
>> On Mar  7 07:54, Ryan Johnson wrote:
>>> Hi all,
>>>
>>> I tried to bootstrap the gcc-4.7 RC and it fails because it expects
>>> to find  and the file actually lives in
>>>   (see
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52513).
>>>
>>> I'm asking here because the gcc devs thought this would mean 4.6 is
>>> broken as well, but I have 4.6.2 running. Did process.h perhaps move
>>> between 1.7.10 and 1.7.11? I guess configure must be using linker
>>> rather than preprocessor tests for presence of spawnve, because it
>>> thinks (correctly) that the function exists.
>> See http://cygwin.com/ml/cygwin-announce/2012-02/msg00041.html
>> We moved it back.  If you have it in cygwin/process.h, you didn't
>> update from 1.7.10 to 1.7.11.
> Ah, I do remember that, now that you mention, but I was running a 1.7.11
> snapshot and forgot to upgrade...
> 
> Thanks for the quick reply,
> Ryan

  Thanks for spotting that Ryan.  FTR, I figure it's not worth delaying the
GCC release to add a fix to support .10, since there were other significant
problems with it, and anyone who has it should be moving to .11 anyway.

cheers,
  DaveK


--
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: [SOLVED:] Re: make producing basename error that can't be captured by "make &> make.out"

[Dave Korn]

On 02/03/2012 07:06, Paul Allen Newell wrote:

> I'll go and figure out some way to filter $(PWD) to be acceptable to
> basename.

  It just needs quotes around it to prevent the space being taken as a 
separator.

cheers,
  DaveK

--
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: [NEARLY SOLVED:] Re: make producing basename error that can't be captured by "make &> make.out"

[Dave Korn]

On 02/03/2012 06:25, Paul Allen Newell wrote:

> +++
> type make; which -a make
> make is aliased to `settitle Making $(basename $PWD) && make "$@"'
> /usr/bin/make
> /usr/bin/make
> +++
> 
> I groaned when I saw this as it is obvious the $(PWD) is feeding
> basename and that's the "make" error. Thanks.
> 
> However, I am still trying to understand why this potentially incorrect
> alias is creating text output to the screen which can't be redirected as
> it isn't stdout or stderr ... or "3/4/5" as someone suggested I test.

  I think it's because aliases are just simple text substitutions.  So if you
have 'make' being transformed to 'settitle Making $(basename $PWD) && make
"$@"' then you would get 'make >& make.out' becoming 'settitle Making
$(basename $PWD) && make "$@" >& make.out' and as you see the redirect only
gets applied to the command after the '&&'.

cheers,
  DaveK


--
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: make producing basename error that can't be captured by "make &> make.out"

[Dave Korn]

On 02/03/2012 02:52, Paul Allen Newell wrote:
> [ weird problem symptoms ]

  You probably have a script or shell alias getting in between you and the
real make.  Please run "type make ; which -a make" in a bash shell and show us
the results.

cheers,
  DaveK


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

Fork failure from git

[Dave Kilroy]

Originally seen with 1.7.11. I've run rebaseall, and the 20120227
snapshot, and still get this error.

Originally the error was during a git pull. I separated things out and
managed to do the git fetch first, but repeating the pull still
results in a fork failure.

$ uname -a
CYGWIN_NT-6.1-WOW64 machine 1.7.12s(0.260/5/3) 20120227 12:56:51 i686 Cygwin

$ git pull --rebase origin master
  1 [main] git 5276 fork: child -1 - forked process died
unexpectedly, retry 0, exit code -1073741515, errno 11
error: cannot fork() for rev-list: Resource temporarily unavailable
error: Could not run 'git rev-list'
  15547 [main] git 5276 fork: child -1 - forked process died
unexpectedly, retry 0, exit code -1073741515, errno 11
error: cannot fork() for rev-list: Resource temporarily unavailable
error: Could not run 'git rev-list'
error: git://xxx.com/yyy did not send all necessary objects

I did an strace with the snapshot, and the bit aroung the fork failure says:

   22  820839 [main] git 7408 fork: entering
   55  820894 [main] git 7408 sig_send: sendsig 0xA0, pid 7408, signal
-40, its_me 1
   24  820918 [main] git 7408 sig_send: wakeup 0x290
   30  820948 [sig] git 7408 wait_sig: signalling pack.wakeup 0x290
2  820950 [main] git 7408 sig_send: Waiting for pack.wakeup 0x290
   40  820990 [main] git 7408 sig_send: returning 0x0 from sending signal -40
   32  821022 [main] git 7408 frok::parent: priority class 32
   97  821119 [main] git 7408 frok::parent: stack - bottom 0x29,
top 0x267000, addr 0x0, guardsize 0x0
   30  821149 [main] git 7408 frok::parent: CreateProcessW
(C:\cygwin\lib\git-core\git.exe, C:\cygwin\lib\git-core\git.exe, 0, 0,
1, 0x20, 0, 0, 0x28A5C0, 0x28A620)
   25  821174 [main] git 7408 time: 1330600890 = time(0)
 1926  823100 [main] git 7408 frok::parent: forked pid 6460
   36  823136 [main] git 7408 child_info::sync: n 2, waiting for
subproc_ready(0x288) and child process(0x2A0)
 3097  826233 [main] git 7408 child_info::sync: pid 6460, WFMO
returned 1, exit_code 0xC135, res 0
   93  826326 [main] git 7408 frok::parent: returning -1
   52  826378 [main] git 7408 sig_send: sendsig 0xA0, pid 7408, signal
-41, its_me 1
   31  826409 [main] git 7408 sig_send: wakeup 0x290
   54  826463 [main] git 7408 sig_send: Waiting for pack.wakeup 0x290
   23  826486 [sig] git 7408 wait_sig: signalling pack.wakeup 0x290
   27  826513 [main] git 7408 sig_send: returning 0x0 from sending signal -41
   88  826601 [main] git 7408 fork: child -1 - forked process died
unexpectedly, retry 0, exit code -1073741515, errno 11
  266  826867 [main] git 7408 __set_errno: int fork():685 setting errno 11

An earlier fork appears to have worked for git.exe, but with the
exectuable in a different directory (does this matter?)

   22   64382 [main] git 7908 fork: entering
   61   64443 [main] git 7908 sig_send: sendsig 0x9C, pid 7908, signal
-40, its_me 1
   23   64466 [main] git 7908 sig_send: wakeup 0x130
   25   64491 [main] git 7908 sig_send: Waiting for pack.wakeup 0x130
5   64496 [sig] git 7908 wait_sig: signalling pack.wakeup 0x130
   42   64538 [main] git 7908 sig_send: returning 0x0 from sending signal -40
   29   64567 [main] git 7908 frok::parent: priority class 32
   91   64658 [main] git 7908 frok::parent: stack - bottom 0x29,
top 0x252000, addr 0x0, guardsize 0x0
   21   64679 [main] git 7908 frok::parent: CreateProcessW
(C:\cygwin\bin\git.exe, C:\cygwin\bin\git.exe, 0, 0, 1, 0x20, 0, 0,
0x28A8C0, 0x28A920)
   21   64700 [main] git 7908 time: 1330600885 = time(0)
24016   88716 [main] git 7908 frok::parent: forked pid 6608
   57   88773 [main] git 7908 child_info::sync: n 2, waiting for
subproc_ready(0x128) and child process(0x138)
1   1 [main] git (6608) **
   52  53 [main] git (6608) Program name: C:\cygwin\bin\git.exe
(windows pid 6608)
   19  72 [main] git (6608) OS version:   Windows NT-6.1
   17  89 [main] git (6608) Heap size:4160157172
   17 106 [main] git (6608) **

Note: may want to s/frok/fork/

The following command does work after the fetch:

$ git rebase origin master

So I'm not too worried, so this is more an FYI in case the strace helps.



Dave.

--
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: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing

[Dave Korn]

On 27/02/2012 16:12, Paul Keir wrote:
> Thanks Dave, it's fixed. It looks like the problem was the cygwin1.dll
> in C:\Windows\SYSTEM. I have no idea why that was there. (I am not the
> first to use this machine.)

  Well, you may just find out when something else stops working - it's not
unknown for people to ship custom toolchains built on Cygwin that install the
DLL into the SYSTEM directory.  (In which case, put the DLL you found there
into the binaries dir alongside the tools involved.)

> As a precaution I have also removed
> C:\Users\\home\apps\gcc-4.7-20120128\bin from my PATH. I had
> built it with --program-suffix=-4.7, but the following potentially
> conflicting files remain there with their names untouched:
> 
> cyggfortran-3.dll
> cygssp-0.dll
> cygstdc++-6.dll

  Although having them later in the path than the system versions in /usr/bin
should in theory make that safe, mixing DW2 and SJLJ is asking for trouble to
crop up somewhere down the line.

cheers,
  DaveK

--
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: Automating setup - --no-verify doesn't seem to work

[Dave Korn]

On 24/02/2012 19:56, Andrew DeFaria wrote:
> I'm trying to automate the setup of cygwin and I'm running setup.exe
> with many additional options. All in all it's working fairly nicely but
> the --no-verify doesn't seem to work. The help says that --no-verify is
> "Don't verify setup.ini signatures" yet when I run it I see a lot of
> "Checking MD5 for ". Isn't there an option to turn off this MD5
> checking?

  No, those are actually two separate things.  The --no-verify option means
that setup.exe will accept any setup.ini file with any values for the md5sums
for packages, not just the official version; it doesn't stop the md5sums from
being checked, just means that a custom mirror can supply its own versions of
packages with their own md5sums, but they always get checked no matter what.

cheers,
  DaveK

--
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: Spawning Java from C

[Dave Korn]

On 24/02/2012 15:07, Eliot Moss wrote:
> On 2/24/2012 9:57 AM, Jim Rome wrote:
>> Larry Hall (Cygwin  cygwin.com>  writes:
>>>
>>> To the OP, run the same from an elevated prompt and these
>>> errors should disappear.
>>>
>>
>> I tried it also with windows style paths, both using \\ and / as
>> separators with the same results.
>>
>> What does "to the OP" mean?  And are you implying it has to be run
>> as an administrator? MinGW does not require that.
> 
> OP = Original Poster (see the cygwin standard acronyms :-) )
> 
> Yes, the responder *is* saying that you need to run this as
> administrator.  

  No.  He was saying that if you run *cygcheck* from an elevated prompt, you
won't get the "Can't open service" errors.

cheers,
  DaveK

--
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: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing

[Dave Korn]

On 24/02/2012 15:36, Paul Keir wrote:
> echo $? returns 1 after using gcc.

  Right, that's "helpful" of it!  That's clearly just a fail status but not an
errno value.

  Anyway, I think your cygcheck reveals the problem.  You have multiple
cygwin1.dlls of different versions in your path at the same time.  You also
have a homebrew build of gcc 4.7 in your path, and it's using SJLJ exceptions
rather than DW2, which means that its runtime DLLs will be incompatible with
the standard system ones.

  Try removing the cygwin1.dll from C:\Windows\SYSTEM, and cutting
C:\Users\\home\apps\gcc-4.7-20120128\bin out of your PATH, and see if
that fixes it.

cheers,
  DaveK

--
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: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing

[Dave Korn]

On 24/02/2012 13:52, Paul Keir wrote:
> Thanks. No, it's not full. The permissions are:
> drwxrwxrwt+ 1 Paul root  0 Feb 24 13:36 tmp
> and I can create the same file manually.

  Oh well, always worth checking the basics first, but no real surprise!

> The output of gcc -v hello.c is attached. I am running Windows 7
> Professional - Service Pack 1.
> 
> I'm afraid I can't send the output of cygcheck to the mailing list for
> confidentiality reasons. I could either send it to you directly, or
> perhaps run cygcheck in a way to generate less data. 

  If you're that worried I don't mind if you'd rather send it to me offlist,
go ahead, but it's not like you know me well enough to trust either, so I'd
suggest you redact any sensitive data (user names? passwords in environment
vars?) before posting it either way.

> By the way I get
> the following errors from cygcheck, only when I redirect the output:
> 
> /usr/bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch': Win32
> error 5
> Access is denied.
> /usr/bin/cygrunsrv: warning: OpenService failed for 'ose': Win32 error 5
> Access is denied.
> /usr/bin/cygrunsrv: warning: OpenService failed for 'osppsvc': Win32
> error 5
> Access is denied.
> /usr/bin/cygrunsrv: warning: OpenService failed for 'pla': Win32 error 5
> Access is denied.
> /usr/bin/cygrunsrv: warning: OpenService failed for 'QWAVE': Win32 error 5
> Access is denied.
> /usr/bin/cygrunsrv: warning: OpenService failed for 'RpcEptMapper':
> Win32 error 5
> Access is denied.
> /usr/bin/cygrunsrv: warning: OpenService failed for 'RpcSs': Win32 error 5
> Access is denied.

  That's not unexpected if you're running under a non-administrative account.

  There was nothing unusual in the output from "gcc -v".  If the cygcheck
output doesn't show anything, I'll have to get you to run cc1.exe under
strace.  However, before we do that, there's one other thing I forgot to ask:
what's the exit status after gcc fails?  "echo $?" should show it, assuming
you're using bash.

cheers,
  DaveK


--
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: strange bug that doesn't occur in Linux, OpenBSD or ITS

[Dave Korn]

On 18/02/2012 18:32, Jeremiah Bishop wrote:
> the  bash commands used are: 1) gcc "cygwin puzzle.c"
> 
> 2) ./a.out a b
> Now either version used on a file with a shorter set of lines, works just
> fine but strangely, that single digit difference aborts the program without
> throwing any error on the sample input or text files with similarly long
> lines.

  Your program is overflowing the stack.  The default amount of stack space
allocated by windows for a program is 2MB, but you can increase it using the
"-Wl,--stack," option (GCC passes -Wl options through to the linker, see
'man ld' for details of the --stack option).  I found your program could run
to completion when I compiled it with "-Wl,--stack,1000" for a ~10MB stack.

  However the better fix would not to be to nest forty-three thousand
recursive stack calls.  Your code is very slow because it starts at the
beginning of the list every time and recursively works its way to the end,
costing a function call and stack frame for every node along the way.  Iterate
if you really have to do it that way, or even better, keep a pointer to the
end node of the list and just go straight there.

cheers,
  DaveK






--
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: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing

[Dave Korn]

On 24/02/2012 09:22, Paul Keir wrote:
> Hello,
> 
> After installing a package (libxrandr-dev I think) GCC 4.5.3 (from Exp)
> has a problem. Even Hello World gives me:
> 
> hello.c:1:0: fatal error: can't open /tmp/ccc6IHTT.s for writing: No
> such file or directory
> compilation terminated.
> 
> I have tried reinstalling GCC with no luck. Can anyone offer advice?

  Is the drive where your /tmp dir is located full?  Does it have the right
permissions?  Can you create the same named file manually (e.g. run a command
like "ls >/tmp/ccc6IHTT.s")?

  If none of that sheds any light on it, please run "cygcheck -s -v -r >
cygcheck.out" and send that file **as an attachment only please** with your
next post.  Also, re-run the gcc compile command that's failing, but add the
"-v" option to the command-line, and show us all the output it generates.

cheers,
  DaveK


--
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: cygport: broken vs. autotools by "set -e"

[Dave Korn]

On 20/01/2012 12:50, Andy Moreton wrote:
> On Thu 19 Jan 2012, Dave Korn wrote:
> 
>>   Commenting-out the "set -e;" line at the start of /usr/bin/cygport
>> has fixed this problem, and my builds now run just fine, but huh? I
>> checked in git; that line has been there since like forever, so why is
>> it giving me trouble now? Is there something I could have changed in
>> my environment or startup scripts that is causing this -e to propagate
>> to subshells that it didn't used to, or did there used to be a
>> mechanism in cygport that would have had the effect of turning it off
>> for subshells that has now been removed for some reason?
> 
> Hi Dave,
> 
> As a WAG it could be that you have differences in behaviour from
> updating bash - check the docs for 'set -e' changes in bash 4.x

Hi Andy,

  Bash wasn't one of the packages updated - we've been on bash 4 since
February last year, and I already had it installed last september when I was
successfully using cygport to build the gcc-4.5.3-1 release.  So I figure that
the 4.x set -e behaviour might be part of this problem, but there must have
been a change in cygport that's exposing it when it was previously hidden.

cheers,
  DaveK


PS. Hope everything's well with you and happy new year!  We should arrange a
pub meet sometime soon on the pig list.

--
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: hard-coded library search path in gcc-4

[Dave Korn]

On 20/01/2012 04:07, Ilguiz Latypov wrote:
> I found that gcc-4 from a recent setup.exe could not start cc1 because the
> latter could not find some shared object file.
> 
> I confirmed that by running cc1 alone with an empty PATH variable.

  Running "cygcheck /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe" should show you
what library is missing.  Setup.exe should have considered all the
dependencies but maybe we've got a bug or a missing one somewhere.

cheers,
  DaveK


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

cygport: broken vs. autotools by "set -e"

[Dave Korn]

Hi list,

  I just updated my Cygwin installation for the first time since Oct 26 last
year, and now I'm unable to successfully run cygport builds any more.  The
builds fail because of the spontaneous exiting of one or other of the scripts
that cygport invokes - I've had autoconf-2.68 spontaneously exiting during the
autoreconf stage, and if I skip over that the configure scripts do the same 
thing.

  On closer inspection, it turns out that they were exiting first time they
executed subcommands that failed.  I added 'set -o' to my cygport script, both
inline so it would be executed when the script gets sourced, and inside my
override of src_compile so I could see what was happening just before the
configure call, and sure enough it showed me that errexit was off at the start
of the run but had been set on by the time execution reached src_compile.

  Commenting-out the "set -e;" line at the start of /usr/bin/cygport has fixed
this problem, and my builds now run just fine, but huh?  I checked in git;
that line has been there since like forever, so why is it giving me trouble
now?  Is there something I could have changed in my environment or startup
scripts that is causing this -e to propagate to subshells that it didn't used
to, or did there used to be a mechanism in cygport that would have had the
effect of turning it off for subshells that has now been removed for some 
reason?

cheers,
  DaveK


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

[Dave Korn]

On 18/01/2012 19:49, Ashlar wrote:
> I have cygwin installed with a number of directories named following this
> format:
> 
> C:/Documents\040and\040Settings/Administrator/_web/crhub /webroot ntfs
> binary,posix=0 0 0
> 
> When I use the Mount command it includes the assignment for the line
> 
> When I enter 'cd /webroot from the command line I get an error message
> 'bash: cd: /webroot: no such file or directory'
> 
> These directory names worked until I deleted the path in .bash_profile
> accidentally.  Now these pathnames are no longer recognized.  I have tried
> to rewrite the Path=$path... line in the file .bash_profile, but do not know
> what to include in it. My windows path is being loaded and contains paths
> for C:/cygwin, C:/cygwin/etc/ and the absolute paths for the /webroot
> directory.  Any suggestions are appreciated.

  There are default copies of a lot of these sorts of installable scripts
under /etc/defaults.  You'll find the original .bash_profile at
/etc/defaults/etc/skel/.bash_profile.  (Note that that's a default for the
version that goes into /etc/skel, which is the 'current' one that's then used
to set up new home dirs the first time a user runs the cygwin shell.)

cheers,
  DaveK

--
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: "Bad address" error with redirection (stdout and stderr) in background process

[Dave Korn]

On 16/01/2012 06:47, Heiko Elger wrote:
> Dave Korn gmail.com> writes:
> 
>> looks like there was a second snapshot later the same day that replaced the
>> one you had installed.
> 
> That's it! Thanks a lot ..
> I never see a snapshot released twice a day 
> 
> Just one question:
> How can I figure out whether a snapshot is released more than once a day?

  Well, if ...

- you download a snapshot
- you find a bug
- you report it and discuss it on the list
- cgf says he's just created a snapshot to fix your bug

... you can infer by pure logic alone that he's not talking about the snapshot
that was uploaded *before* you reported your bug.

  You can also look at the hours and minutes in the timestamp listed on
http://cygwin.com/snapshots/ as well as the date and compare it to the one you
downloaded earlier in the day.

cheers,
  DaveK


--
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: "Bad address" error with redirection (stdout and stderr) in background process

[Dave Korn]

On 15/01/2011 19:41, Heiko Elger wrote:
> Christopher Faylor writes:
> 
>> If you are saying that the problem is not fixed in the most recent
>> snapshot then please clearly say that.  Otherwise, I don't understand
>> what you are asking.  I sent my email on January 11 shortly before the
>> January 11 snapshot was uploaded.  There is no reason for you to expect
>> a newer snapshot than that.
>>
> 
> In my first posting concerning this problem I posted tne used snapshot too
> (20110111)
> 
>> I'm using latest snapshot and updated cygwin installation.
>>
>> $ uname -a
>> CYGWIN_NT-6.1-WOW64 PCFX166 1.7.10s(0.259/5/3) 20120111 01:45:50 i686
> Cygwin
>> I've done rebaseall and peflagsall.
> 
> So I already used teh snapshot of January 11th.

  http://cygwin.com/snapshots/ currently says "2012-01-11 22:44:48 UTC", so it
looks like there was a second snapshot later the same day that replaced the
one you had installed.

cheers,
  DaveK


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