How to check cygwin version?

[Jeffrey Walton via Cygwin]

I think the documentation leaves a lot to be desired... I'm trying to
tell someone what version of Cygwin I am using.

There's a FAQ item at
https://cygwin.com/faq/faq.html#faq.what.version. It gives this
useless advice:

   To find the version of the Cygwin DLL installed, you can use uname
   as on Linux or cygcheck. Refer to each command's --help output and
   the Cygwin User's Guide for more information.

OK, let's try it:

$ cygcheck -v
Usage: cygcheck [-v] [-h] PROGRAM
   cygcheck -c [-d] [PACKAGE]
   cygcheck -s [-r] [-v] [-h]
   cygcheck -k
   ...

OK, -v is what we need:

$ cygcheck -v cygwin
cygcheck: could not find 'cygwin'

OK, another failure.

RTFM does not work. Why the hell don't you just state how to check the
god damn version?
--
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: WARNING: Couldn't compute FAST_CWD pointer.

[Jeffrey Walton]

On Mon, Apr 15, 2019 at 9:04 PM Geno Chandler  wrote:
>
> ./zip2john.exe
> "C:\Users\Jinko\Desktop\Tools\Forensics\Interesting-Files\Submit_To_boss.zip"
> | cut -d ':' -f 2 > Submit.hash
>   0 [main] zip2john 11916 find_fast_cwd: WARNING: Couldn't compute
> FAST_CWD pointer.  Please report this problem to
> the public mailing list cygwin@cygwin.com
>   0 [main] zip2john 11916 find_fast_cwd: WARNING: Couldn't compute
> FAST_CWD pointer.  Please report this problem to
>
> the public mailing list cygwin@cygwin.com
> cygwin warning:
>   MS-DOS style path detected:
> C:\Users\Jinko\Desktop\Tools\Forensics\Interesting-Files\Submit_To_boss.zip
>   Preferred POSIX equivalent is:
> /cygdrive/c/Users/Jinko/Desktop/Tools/Forensics/Interesting-Files/Submit_To_boss.zip
>   CYGWIN environment variable option "nodosfilewarning" turns off this
> warning.
>   Consult the user's guide for more details about POSIX paths:
> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
> C:\Users\Jinko\Desktop\Tools\Forensics\Interesting-Files\Submit_To_boss.zip->Submit_To_boss/
> is not encrypted!
> ver a
> C:\Users\Jinko\Desktop\Tools\Forensics\Interesting-Files\Submit_To_boss.zip->Submit_To_boss/
> is not encrypted, or stored with non-handled compression type
> ver 14  efh 5455  efh 7875
> Submit_To_boss.zip->Submit_To_boss/Conversation.docx PKZIP Encr: 2b chk,
> TS_chk, cmplen=10754, decmplen=13460, crc=92472119

https://cygwin.com/faq/faq.html#faq.using.fixing-find_fast_cwd-warnings

--
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: mintty 2.9.9

[Jeffrey Walton]

On Thu, Mar 28, 2019 at 4:44 AM Thomas Wolff  wrote:
> ...
> Björn Stabel wrote:
> > On 27/03/2019 23:59, Yaakov Selkowitz wrote:
> >> On Wed, 2019-03-27 at 21:02 +0100, Thomas Wolff wrote:
> >>> I used to use tar rather than cygport package to generate the packages.
> >>> One reason was that I didn’t want my local user/group to appear in them.
> >> They won't show up like that once installed.
> > Sorry for commenting from the peanut gallery, but his problem may be
> > that he doesn't want to disclose his user name to anyone nosy enough to
> > snoop around in the package files.
> Thanks for expressing the point. Indeed, I consider this a privacy
> issue. So unless I get the information how to generate that
> mintty.exe.dbg file, I could only unpack the debug package and repackage
> it again, blowing up the production process unnecessarily. Or stay
> without debug package for another while...

A potential solution is, add another user to your system named cygwin.
When you build you packages use the cygwin user. The debug information
will reference your cygwin user, and not your real user account.

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: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Jeffrey Walton]

On Wed, Mar 27, 2019 at 4:36 PM Achim Gratz  wrote:
> ...
> > I removed -s as suggested by Achim, added -g as advised by Corinna,
> > but cygport still says:
> > *** Info: No debug files, skipping debuginfo subpackage
>
> Well, do not reset CFLAGS in your Makefile and cygport helpfully
> provides all the scaffolding you need.  You might have noticed I
> replaced the ":=" in your Makefile for exactly that reason.  A build
> system is supposed to be able to pre-configure CFLAGS without your
> Makefile nixing all of that effort.

Also of interest is GNU Coding Standards, 7.2.3 Variables for
Specifying Commands
(https://www.gnu.org/prep/standards/html_node/Command-Variables.html):

If there are C compiler options that must be used for proper
compilation of certain files, do not include them in CFLAGS. Users
expect to be able to specify CFLAGS freely themselves. Instead,
arrange to pass the necessary options to the C compiler independently
of CFLAGS, by writing them explicitly in the compilation commands or
by defining an implicit rule, like this:

CFLAGS = -g
ALL_CFLAGS = -I. $(CFLAGS)
.c.o:
$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<

Do include the ‘-g’ option in CFLAGS, because that is not required for
proper compilation. You can consider it a default that is only
recommended. If the package is set up so that it is compiled with GCC
by default, then you might as well include ‘-O’ in the default value
of CFLAGS as well.

Put CFLAGS last in the compilation command, after other variables
containing compiler options, so the user can use CFLAGS to override
the others.

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: Emacs and CTRL key problems using Cygwin 3.0.3

[Jeffrey Walton]

On Fri, Mar 15, 2019 at 2:29 AM Jeffrey Walton  wrote:
>
> ...
> I used Cygwin x86_64 flavor and SSH'd into a Linux box. I opened a
> text file with emacs and tried to delete a line with CTRL+K. Notice
> the '5;5u' where the delete was supposed to occur:

The updates that were applied earlier today fixed the issue.

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: Emacs and CTRL key problems using Cygwin 3.0.3

[Jeffrey Walton]

On Fri, Mar 15, 2019 at 12:05 PM Andrey Repin  wrote:
> Greetings, Jeffrey Walton!
> >> Am 15.03.2019 um 07:29 schrieb Jeffrey Walton:
> >> > ...
> >> >  IS_APK=$(command -v apk 2>/dev/null | grep -v "^no " | wc -l)
> >> >
> >> >  5;5u5;5u5;5u
> >> >
> >> >  if [ "$IS_DNF" -ne 0 ]; then
> >> >
> >> > Formerly emacs worked as expected.
> >> Fixed with mintty 2.9.8.
>
> > I just updated, and saw mintty was the only package. But I am still
> > seeing the issue.
>
> 2.9.7 was released very recently. You probably grabbed that version, and 2.9.8
> did not hit your mirror yet.

OK, thank. I updated again today and there were no updates.

I rebooted in case something old was in memory. The problem is still present.

> Please teach your mail agent to not quote raw email addresses.

Yes, certainly. How does one do it?

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: Emacs and CTRL key problems using Cygwin 3.0.3

[Jeffrey Walton]

On Fri, Mar 15, 2019 at 5:59 AM Thomas Wolff  wrote:
>
> Am 15.03.2019 um 07:29 schrieb Jeffrey Walton:
> > Hi Everyone,
> >
> > I just upgraded to Cygwin 3.0.3. 3.0.3 was an in-place upgrade over
> > top the previous version. I don't recall the previous version.
> >
> > I used Cygwin x86_64 flavor and SSH'd into a Linux box. I opened a
> > text file with emacs and tried to delete a line with CTRL+K. Notice
> > the '5;5u' where the delete was supposed to occur:
> >
> >  IS_APK=$(command -v apk 2>/dev/null | grep -v "^no " | wc -l)
> >
> >  5;5u5;5u5;5u
> >
> >  if [ "$IS_DNF" -ne 0 ]; then
> >
> > Formerly emacs worked as expected.
> Fixed with mintty 2.9.8.

I just updated, and saw mintty was the only package. But I am still
seeing the issue.

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

Emacs and CTRL key problems using Cygwin 3.0.3

[Jeffrey Walton]

Hi Everyone,

I just upgraded to Cygwin 3.0.3. 3.0.3 was an in-place upgrade over
top the previous version. I don't recall the previous version.

I used Cygwin x86_64 flavor and SSH'd into a Linux box. I opened a
text file with emacs and tried to delete a line with CTRL+K. Notice
the '5;5u' where the delete was supposed to occur:

IS_APK=$(command -v apk 2>/dev/null | grep -v "^no " | wc -l)

5;5u5;5u5;5u

if [ "$IS_DNF" -ne 0 ]; then

Formerly emacs worked as expected.

Any ideas what might be going sideways?

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: portable use of dos2unix WAS: Re: textmode for stdout, what is "correct" now?

[Jeffrey Walton]

On Mon, Feb 18, 2019 at 5:01 AM Michael Haubenwallner
 wrote:
>
> On 2/15/19 10:00 PM, Corinna Vinschen wrote:
> > On Feb 15 20:33, Michael Haubenwallner wrote:
> >> On 2/15/19 7:35 PM, Andrey Repin wrote:
> >>> I have a different question though. The commands you presented in the OP
> >>> look like you aren't using Cygwin-suppied OpenSSL binary.
> >>
> >> This is true: The Cygwin distro does provide openssl-1.0.2p, but I'm 
> >> building
> >> the *portable* Gentoo Prefix distro on Cygwin, with openssl-1.1.1a already.
> >> But whenever the Cygwin distro would bump to openssl-1.1, the same problem
> >> would arise there as well, just becomes noticed much later probably.
> >
> > Does OpenSSH build with OpenSSL 1.1.1a these days?  If so, we might
> > want to switch OpenSSL finally, too.
>
> Well, OpenSSH-7.9_p1 maybe does, according to https://bugs.gentoo.org/592578

I believe OpenSSH sidestepped OpenSSL. That is, it no longer depends
on it in a way that things matter. I don't recall the details.

As far as building OpenSSH against OpenSSL 1.1, see
https://github.com/openssh/openssh-portable/pull/48 .

Also see https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes,
which documents some [former] incompatibilities between other programs
and OpenSSL.

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: textmode for stdout, what is "correct" now?

[Jeffrey Walton]

On Thu, Feb 14, 2019 at 10:23 AM Michael Haubenwallner
 wrote:
>
> so I find myself struggling with textmode versus binmode for stdio again.
>
> Running the openssl command (from within the apps/ build directory here) does
> yield different results regarding carriage return depending on the version:
>
> $ ./apps/openssl version
> OpenSSL 1.0.2p  14 Aug 2018
> $ ./apps/openssl x509 -hash -noout -in /etc/pki/tls/cert.pem | xxd
> : 6139 3464 3039 6535 0a   a94d09e5.
>
>
> $ ./apps/openssl version
> OpenSSL 1.1.0j  20 Nov 2018
> $ ./apps/openssl x509 -hash -noout -in /etc/pki/tls/cert.pem | xxd
> : 6139 3464 3039 6535 0d0a a94d09e5..
>
> Some subsequent shell script does create wrong symlink filenames
> (with embedded CR) when used with openssl-1.1.x.
>
> The commit that changed this behaviour in openssl-1.1 is:
> https://github.com/openssl/openssl/commit/bdd58d98467e9f0f6635c1628e1eae304383afb1
>
> From an openssl developer's point of view, I can understand to set
> textmode when the intent is to output some text, and to set
> binmode when the intent is to output some binary data.
>
> Question now is: These days, what is the correct way to handle this?


RFC 1421, Privacy Enhanced Mail (PEM)
(https://www.ietf.org/rfc/rfc1421.txt), is the controlling document.
Lines should break at 64 characters, and EOL is CRLF pairs.

 * 64-char lines is covered in section 4.3.2.4, Printable Encodings
 * CRLF is covered in section 4.3.1  Constraints

Line breaks at 64 chars is an anachronism (in my opinion), but some
software still enforces it. Some software will reject keys and
certificates if not properly broken.

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

Is Cygwin supposed to know _get_pgmptr?

[Jeffrey Walton]

Hi Everyone,

I have some code that looks like so:

#if defined(_WINDOWS)
char* pgmptr = NULLPTR;
errno_t err = _get_pgmptr(&pgmptr);
if (err == 0 && pgmptr != NULLPTR)
exePath = pgmptr;
#endif

The code gets the full path of the executable. It sidsteps some
problems with finding the full path of an executable. Posix realpath
is a little messier and has some inherent problem with path lengths.

The code fails to compile with Cygwin.

I am wondering if the failure is expected.

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: Please report this problem to the public mailing list cygwin@cygwin.com

[Jeffrey Walton]

On Thu, Sep 27, 2018 at 9:00 PM, Joshua Sokolowski
 wrote:
> Hi guys,
>
> i don‘t know if you wanted to report me this but if yes please tell me how to 
> fix it i tried 3 houres… I am tired now ist 3 AM in Germany now….
> ...
>
> process_begin: CreateProcess(NULL, touch 
> C:/Users/Joshua/Desktop/Grafikrechner/projects/imageviewer-master/src/versionProvider.cpp,
>  ...) failed.
>   0 [main] [ 11288 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
> pointer.  Please report this problem to ...

https://cygwin.com/faq/faq.html#faq.using.fixing-find_fast_cwd-warnings

You should probably report the bug to the originating project so they
can fix it once and for all. It is more economical to fix it in one
place (at the project) than multiple places (each developer).

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: bzip.org

[Jeffrey Walton]

On Mon, Sep 24, 2018 at 9:17 AM, cyg Simple  wrote:
> On 9/23/2018 4:15 AM, Roland DOT Schwingel AT onevision DOT com wrote:
>
> Please keep on the conversation on the list.
>
>>
>>> Sadly our beloved http://www.bzip.org has hit
>> the bit bucket.  Does
>>> anyone know where upstream support for bzip2 went?
>>
>> It appears that bzip.org is just coming back (as announced on the
>> valgrind list)
>>
>
> So it is, and from there we find:
>
> ```
> Find the latest version on SourceForge.
>
> Author admin
> Posted on 22 September 2018
> ```

Something looks fishy to me.

I don't think an old school guy like Sewards would be running a
WordPress site. They would use plain HTML 3 crafted in Vi or Emacs.
They would also probably avoid SourceForge due to the malware
packaging of old.

Finally, WHOIS does not indicate Sewards is the owner. They are still
showing register.com.

I would not trust any downloads from that site.

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: bzip.org

[Jeffrey Walton]

On Fri, Sep 21, 2018 at 11:33 AM, cyg Simple  wrote:
> Sadly our beloved http://www.bzip.org has hit the bit bucket.  Does
> anyone know where upstream support for bzip2 went?

>From https://sourceforge.net/p/valgrind/mailman/message/36403434/  :

> Unfortunately the bzip.org domain is no longer available to the
> bzip2 project. The plan is to move back to sourceware:
> https://sourceware.org/bzip2/
> https://sourceware.org/pub/bzip2/

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: Why does -std=c++11 hide certain function calls

[Jeffrey Walton]

On Thu, Sep 6, 2018 at 2:45 AM, John Selbie  wrote:
>> For Unixy builds, just don't specify -std. Only specify -std if you want
> to ensure that builds will work with earlier standards, compilers, or
> libraries, or for -std=c* without any special language or library features,
> in which case you may also want to add -pedantic or more restrictive
> options.
>
> A…. that was my mistake.  I had erroneously assumed that not specifying
> -std would result in the oldest version of C++.  A quick check:
>
> $ g++ foo.cpp -c -dM -E  | grep cplus
> #define __cplusplus 201402L
>
> I was compiling with C++ 14 the whole time.  And it appears that when -std
> is used, the GNU defines are taken out, which ultimately influence how
> POSIX_VISIBLE Is defined within .

By default GCC uses a -std=gnu++NN, not -std=c++NN. So you are getting
mostly the latest C++ but it is GNU's flavor with non-standard things
like Variable Length Arrays (VLA's).

> I'm not sure if I agree that -std should hide the functions from unix
> headers. (tldr: unix headers are explicitly outside the c++ standard, so
> the moment they are included, you might as well assume the developer wants
> it all...)

Cygwin and Newlib conflate options in unexpected ways.

I think they are making incorrect leaps about options. For example if
you want Posix you may not want a GCC extension like VLA's. I doubt it
will change, though. You just have to work around it.

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: Help me!

[Jeffrey Walton]

On Wed, Aug 29, 2018 at 8:10 AM, Andrea Guerrieri  wrote:
> C:\Users\Qualità.CAPALLE.002\Desktop\john\run>zip2john.exe ambra.zip >
> ambra.hash
>   2 [main] zip2john 6100 find_fast_cwd: WARNING: Couldn't compute
> FAST_CWD pointer.  Please report this problem to
> ...
> --
> 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

I understand the Cygwin FAQ is your next stop.

--
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: scrolling through history in cygwin terminal window line gets garbled

[Jeffrey Walton]

On Sat, Aug 18, 2018 at 6:20 PM, Steven Penny  wrote:
> On Sat, 18 Aug 2018 16:17:49, cyg Simple wrote:
>> ...
>> So just for grins I went to the Windows Explorer and started with the
>> cygwin.bat file and performed your test again using the .bash_history
>> with no issues.  This time the TERM=cygwin which comes from
>> /usr/share/terminfo/63/cygwin.
>
>
> all i can say to this is that you arent using windows 7, so perhaps the
> newer
> version of conhost has fixed the issue - at this point we would need another
> windows 7 user to confirm the issue - further tests with win 10 wont be
> helpful.

I was not able to reproduce on Windows 7 x86.

--
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: AllowGroups in SSHD not working for domain accounts

[Jeffrey Walton]

On Wed, Aug 1, 2018 at 2:21 PM, Michal Zindulka
 wrote:
> Hi Cygwin team,
>
> I'm trying to setup SSHD with 'AllowGroups' option, but I've encountered
> following troubles.
>
> When I setup the 'AllowGroups SSHGROUP' option in 'sshd_config' file, then
> a local users who are members of 'SSHGROUP' are able to login without any
> issue. When I do the same for domain user, who is also member of local
> group 'SSHGROUP', the login will fail with following error in the log:
>
> 'User SSHUSER from  not allowed because non of user's groups are listed
> in AllowGroups.
>
> When I try to list all users for my domain user using 'groups' command, it
> show only domain groups where the user belong + primary groups which is set
> in 'passwd' file.
>
> I was able to make it work, using a workaround, by set a local 'SSHGROUP'
> as a primary group in 'passwd' file for my domain user. Then this groups is
> was also displayed using 'groups' command and user was able to login, but
> it's not a suitable solution for me.
>
> I've tried also to assign my domain user to 'SSHGROUP' in 'group' file, but
> didn't help.

Not sure if it is related, but...

On Windows domains you are supposed to follow the UGLY model. The
letters of UGLY stand for:

   Users into Global groups
   Global into domain Local groups
   You assign permissions

SSHGROUP should be a local group with members from the domain and global groups.

Of course, scratch this if the machinery is doing something different.

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: Incorrect /proc/cpuinfo for AMD A6-9220

[Jeffrey Walton]

On Fri, Apr 13, 2018 at 7:51 AM, Corinna Vinschen
 wrote:
> On Apr 12 23:01, Jeffrey Walton wrote:
>> Hi Everyone,
>>
>> I'm working on an AMD A6-9220 and seeing unusual results from
>> /proc/cpuinfo. I think this may be an issue with the latest Cygwin. It
>> may be present in earlier versions, too.
>>
>> Russinovich's coreinfo is shown below
>> (https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo).
>> Notice /proc/cpuinfo is missing aesni, pclmul, rdrand, SSE4.1, SSE4.2,
>> AVX, etc.
>
> Note that, in theory, cpuinfo has to be extended for each new CPU
> generation.  That's a lot of work for marginal gain (Cygwin's not a real
> kernel) so I'm doing this only very seldomly.
>
> Patches welcome, of course!

Thanks Corinna. I think I found the file of interest at fhandler_proc.cc.

Whitespace is a bit off. It is a mix of tabs and space:

  if (features1 & (1 << 0))
print (" fpu");
  if (features1 & (1 << 1))
print (" vme");

Should I perform a whitespace check-in before things begin? Or can you
knock it out?

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

Incorrect /proc/cpuinfo for AMD A6-9220

[Jeffrey Walton]

Hi Everyone,

I'm working on an AMD A6-9220 and seeing unusual results from
/proc/cpuinfo. I think this may be an issue with the latest Cygwin. It
may be present in earlier versions, too.

Russinovich's coreinfo is shown below
(https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo).
Notice /proc/cpuinfo is missing aesni, pclmul, rdrand, SSE4.1, SSE4.2,
AVX, etc.

Jeff

* Coreinfo *

C:\Users\Test>coreinfo

Coreinfo v3.31 - Dump information on system CPU and memory topology
Copyright (C) 2008-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

AMD A6-9220e RADEON R4, 5 COMPUTE CORES 2C+3G
AMD64 Family 21 Model 112 Stepping 0, AuthenticAMD
Microcode signature: 06006704
HTT *   Multicore
HYPERVISOR  -   Hypervisor is present
VMX -   Supports Intel hardware-assisted virtualization
SVM *   Supports AMD hardware-assisted virtualization
X64 *   Supports 64-bit mode

SMX -   Supports Intel trusted execution
SKINIT  *   Supports AMD SKINIT

NX  *   Supports no-execute page protection
SMEP*   Supports Supervisor Mode Execution Prevention
SMAP-   Supports Supervisor Mode Access Prevention
PAGE1GB *   Supports 1 GB large pages
PAE *   Supports > 32-bit physical addresses
PAT *   Supports Page Attribute Table
PSE *   Supports 4 MB pages
PSE36   *   Supports > 32-bit address 4 MB pages
PGE *   Supports global bit in page tables
SS  -   Supports bus snooping for cache operations
VME *   Supports Virtual-8086 mode
RDWRFSGSBASE*   Supports direct GS/FS base access

FPU *   Implements i387 floating point instructions
MMX *   Supports MMX instruction set
MMXEXT  *   Implements AMD MMX extensions
3DNOW   -   Supports 3DNow! instructions
3DNOWEXT-   Supports 3DNow! extension instructions
SSE *   Supports Streaming SIMD Extensions
SSE2*   Supports Streaming SIMD Extensions 2
SSE3*   Supports Streaming SIMD Extensions 3
SSSE3   *   Supports Supplemental SIMD Extensions 3
SSE4a   *   Supports Streaming SIMDR Extensions 4a
SSE4.1  *   Supports Streaming SIMD Extensions 4.1
SSE4.2  *   Supports Streaming SIMD Extensions 4.2

AES *   Supports AES extensions
AVX *   Supports AVX intruction extensions
FMA *   Supports FMA extensions using YMM state
MSR *   Implements RDMSR/WRMSR instructions
MTRR*   Supports Memory Type Range Registers
XSAVE   *   Supports XSAVE/XRSTOR instructions
OSXSAVE *   Supports XSETBV/XGETBV instructions
RDRAND  *   Supports RDRAND instruction
RDSEED  -   Supports RDSEED instruction

CMOV*   Supports CMOVcc instruction
CLFSH   *   Supports CLFLUSH instruction
CX8 *   Supports compare and exchange 8-byte instructions
CX16*   Supports CMPXCHG16B instruction
BMI1*   Supports bit manipulation extensions 1
BMI2*   Supports bit manipulation extensions 2
ADX -   Supports ADCX/ADOX instructions
DCA -   Supports prefetch from memory-mapped device
F16C*   Supports half-precision instruction
FXSR*   Supports FXSAVE/FXSTOR instructions
FFXSR   *   Supports optimized FXSAVE/FSRSTOR instruction
MONITOR *   Supports MONITOR and MWAIT instructions
MOVBE   *   Supports MOVBE instruction
ERMSB   -   Supports Enhanced REP MOVSB/STOSB
PCLMULDQ*   Supports PCLMULDQ instruction
POPCNT  *   Supports POPCNT instruction
LZCNT   *   Supports LZCNT instruction
SEP *   Supports fast system call instructions
LAHF-SAHF   *   Supports LAHF/SAHF instructions in 64-bit mode
HLE -   Supports Hardware Lock Elision instructions
RTM -   Supports Restricted Transactional Memory instructions

DE  *   Supports I/O breakpoints including CR4.DE
DTES64  -   Can write history of 64-bit branch addresses
DS  -   Implements memory-resident debug buffer
DS-CPL  -   Supports Debug Store feature with CPL
PCID-   Supports PCIDs and settable CR4.PCIDE
INVPCID -   Supports INVPCID instruction
PDCM-   Supports Performance Capabilities MSR
RDTSCP  *   Supports RDTSCP instruction
TSC *   Supports RDTSC instruction
TSC-DEADLINE-   Local APIC supports one-shot deadline timer
TSC-INVARIANT   *   TSC runs at constant rate
xTPR-   Supports disa

Re: Incorrect /proc/cpuinfo for AMD A6-9220

[Jeffrey Walton]

Please disregard. I fat fingered the mouse pad and sent it too early.

On Thu, Apr 12, 2018 at 10:56 PM, Jeffrey Walton  wrote:
> Hi Everyone,
>
> I'm working on an AMD A6-9220 and seeing unusual results from
> /proc/cpuinfo. I think this may be an issue with the latest Cygwin. It
> may be present in earlier versions, too.
>
> Russinovich's coreinfo shows
> (https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo)
> shows below.
>
> Jeff
>
> * /proc/cpuinfo *

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

Incorrect /proc/cpuinfo for AMD A6-9220

[Jeffrey Walton]

Hi Everyone,

I'm working on an AMD A6-9220 and seeing unusual results from
/proc/cpuinfo. I think this may be an issue with the latest Cygwin. It
may be present in earlier versions, too.

Russinovich's coreinfo shows
(https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo)
shows below.

Jeff

* /proc/cpuinfo *

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

Re: Error: unknown type name ‘pthread_attr_t’ in signal.h

[Jeffrey Walton]

On Mon, Oct 16, 2017 at 3:12 AM, Jeffrey Walton  wrote:
> Hi Everyone,
>
> I'm trying to build Emacs on Cygwin. I use the platform as a test bed
> because of Newlib. Emacs is failing with:

Forgive my ignorance... Should this question go to the Newlib folks?

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: Error: unknown type name ‘pthread_attr_t’ in signal.h

[Jeffrey Walton]

On Mon, Oct 16, 2017 at 3:12 AM, Jeffrey Walton  wrote:
> Hi Everyone,
>
> I'm trying to build Emacs on Cygwin. I use the platform as a test bed
> because of Newlib. Emacs is failing with:
>
> gcc -DHAVE_CONFIG_H -I. -I../lib -I../src -I../src
> -I/usr/local/include -DNDEBUG -pthread -D_XOPEN_SOURCE=600-m64 -MT
> close-stream.o -MD -MP -MF .deps/close-stream.Tpo -c -o close-stream.o
> close-stream.c
> In file included from /usr/include/sys/signal.h:22:0,
>  from /usr/include/signal.h:6,
>  from ./signal.h:52,
>  from ./sys/select.h:107,
>  from /usr/include/sys/time.h:47,
>  from ./sys/time.h:39,
>  from ./sys/select.h:86,
>  from /usr/include/sys/types.h:68,
>  from ./sys/types.h:28,
>  from ./fcntl.h:50,
>  from binary-io.h:23,
>  from binary-io.c:3:
> /usr/include/cygwin/signal.h:175:3: error: unknown type name ‘pthread_attr_t’
>pthread_attr_t *sigev_notify_attributes; /* notification attributes */
>^~
>
> Examining /usr/include/cygwin/signal.h around 175, I see:
>
> typedef struct sigevent
> {
>   sigval_t sigev_value; /* signal value */
>   int sigev_signo;  /* signal number */
>   int sigev_notify; /* notification type */
>   void (*sigev_notify_function) (sigval_t); /* notification function */
>   pthread_attr_t *sigev_notify_attributes; /* notification attributes */
> } sigevent_t;
>
> But I don't see an include for the pthread gear in the signal.h header file.
>
> I found one past message that's similar
> (https://cygwin.com/ml/cygwin/2016-06/msg00458.html), but its reported
> as an upstream bug. I don't think it applies here since the pthread
> data structure is used without an apparent declaration.
>
> Can anyone confirm things are (not?) working as expected? If things
> are working as expected, then hints to work around the failure would
> be appreciated.

I think something is borked with the Cygwin headers. If I am parsing
http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html
and https://cygwin.com/ml/cygwin/2006-01/msg00642.html correctly, it
should be sufficient to define _XOPEN_SOURCE to 600. From the section
"The _XOPEN_SOURCE Feature Test Macro":

Since this volume of IEEE Std 1003.1-2001 is aligned with the ISO C
standard, and since all functionality enabled by _POSIX_C_SOURCE set
equal to 200112L is enabled by _XOPEN_SOURCE set equal to 600, there
should be no need to define _POSIX_C_SOURCE if _XOPEN_SOURCE is so
defined. Therefore, if _XOPEN_SOURCE is set equal to 600 and
_POSIX_C_SOURCE is set equal to 200112L, the behavior is the same as
if only _XOPEN_SOURCE is defined and set equal to 600...

Perhaps the Cygwin FAQ should say something about the macros to enable
features. Right now, the only discussion relates to __CYGWIN__ and
_WIN32. Confer, "6.39. What preprocessor macros do I need to know
about?" in https://www.cygwin.com/faq.html . It seems like there's a
lot more macros we need to know about.

I would still appreciate some help in working around the compile failures.

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

Error: unknown type name ‘pthread_attr_t’ in signal.h

[Jeffrey Walton]

Hi Everyone,

I'm trying to build Emacs on Cygwin. I use the platform as a test bed
because of Newlib. Emacs is failing with:

gcc -DHAVE_CONFIG_H -I. -I../lib -I../src -I../src
-I/usr/local/include -DNDEBUG -pthread -D_XOPEN_SOURCE=600-m64 -MT
close-stream.o -MD -MP -MF .deps/close-stream.Tpo -c -o close-stream.o
close-stream.c
In file included from /usr/include/sys/signal.h:22:0,
 from /usr/include/signal.h:6,
 from ./signal.h:52,
 from ./sys/select.h:107,
 from /usr/include/sys/time.h:47,
 from ./sys/time.h:39,
 from ./sys/select.h:86,
 from /usr/include/sys/types.h:68,
 from ./sys/types.h:28,
 from ./fcntl.h:50,
 from binary-io.h:23,
 from binary-io.c:3:
/usr/include/cygwin/signal.h:175:3: error: unknown type name ‘pthread_attr_t’
   pthread_attr_t *sigev_notify_attributes; /* notification attributes */
   ^~

Examining /usr/include/cygwin/signal.h around 175, I see:

typedef struct sigevent
{
  sigval_t sigev_value; /* signal value */
  int sigev_signo;  /* signal number */
  int sigev_notify; /* notification type */
  void (*sigev_notify_function) (sigval_t); /* notification function */
  pthread_attr_t *sigev_notify_attributes; /* notification attributes */
} sigevent_t;

But I don't see an include for the pthread gear in the signal.h header file.

I found one past message that's similar
(https://cygwin.com/ml/cygwin/2016-06/msg00458.html), but its reported
as an upstream bug. I don't think it applies here since the pthread
data structure is used without an apparent declaration.

Can anyone confirm things are (not?) working as expected? If things
are working as expected, then hints to work around the failure would
be appreciated.

Thanks in advance,

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: Fwd: Suspicious EXE named "[.exe" in c:\cygwin\bin?

[Jeffrey Walton]

On Sun, Dec 12, 2010 at 12:15 PM, Christopher Faylor
 wrote:
> On Sun, Dec 12, 2010 at 11:53:28AM -0500, Jeffrey Walton wrote:
>>2nd try.
>
> The input is sanitized.
Hmm

> It is not a database and it is not PHP.
My bad CGI then...

>
> The "Internal Server Error" just means that the search took too long and
> that is likely because someone has been attempting a DDOS on
> sourceware.org for a couple of weeks.
Nope, no DDOS. Just a simple 1= 1.

Are you sure it does not mean the error was due to using too much
memory when joining tables (or something similar)? Otherwise, I would
expect a 4xx error due to a bad client request.

>
> And, the "[.exe" program is really supposed to be there.
Thanks. It looked very suspicious.

> Since this is a regex search, the search term would be \[\.exe
OK. Thanks.

> If you have further questions please use the cygwin mailing list.
OK. The Internal Server Error 500 page stated to use
sourcemas...@sourceware.org.

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: Suspicious EXE named "[.exe" in c:\cygwin\bin?

[Jeffrey Walton]

An email to sourcemas...@sourceware.org bounced. Can anyone bring this
to the attention of the webmaster?

==
Internal Server Error

The server encountered an internal error or misconfiguration and was
unable to complete your request.

Please contact the server administrator, sourcemas...@sourceware.org
and inform them of the time the error occurred, and anything you might
have done that may have caused the error.

More information about this error may be available in the server error log.
Apache/2.0.52 (Red Hat) Server at cygwin.com Port 80

On Sun, Dec 12, 2010 at 11:50 AM, Jeffrey Walton  wrote:
>  "[1 = 1]" gets an Internal Server error. The PHP is probably trying
> to cough up everything
>
> On Sun, Dec 12, 2010 at 11:44 AM, Jeffrey Walton  wrote:
>> BTW, Since the web interface tried to interpret my input ("Invalid
>> regular expression search string"), this database is probably
>> vulnerable to a SQL injection.
>>
>> GNU just got pwn'd
>>
>> Has anyone tried thew 1 =1 trick lately? Are passwords residing in
>> another table?
>>
>> Jeff
>>
>> Am 12.12.2010 12:29, schrieb Jeffrey Walton:
>>> Hi Guys,
>>>
>>> The executable name is suspicious at best. Attempting to search
>>
>> On the contrary, it's a standard utility mentioned in IEEE Std 1003.1.
>>
>>> http://cygwin.com/packages/ results in an error "Invalid regular
>>> expression search string: `[.exe`". Quotes, double quotes, and back
>>> ticks do not help during the search.
>>
>> Problem of the web interface.
>>
>>> What is this program supposed to do?
>>
>> The same as "test", except that "[" will expect and consume the closing 
>> bracket.
>>  Used in scripting with shells that don't have [ built-in.
>>
>> Details with "man test" ("man [" is missing on my Cygwin system), or in bash
>> with "help [".
>>
>> --
>> Matthias Andree
>>
>> --
>> 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: Suspicious EXE named "[.exe" in c:\cygwin\bin?

[Jeffrey Walton]

 "[1 = 1]" gets an Internal Server error. The PHP is probably trying
to cough up everything

On Sun, Dec 12, 2010 at 11:44 AM, Jeffrey Walton  wrote:
> BTW, Since the web interface tried to interpret my input ("Invalid
> regular expression search string"), this database is probably
> vulnerable to a SQL injection.
>
> GNU just got pwn'd
>
> Has anyone tried thew 1 =1 trick lately? Are passwords residing in
> another table?
>
> Jeff
>
> Am 12.12.2010 12:29, schrieb Jeffrey Walton:
>> Hi Guys,
>>
>> The executable name is suspicious at best. Attempting to search
>
> On the contrary, it's a standard utility mentioned in IEEE Std 1003.1.
>
>> http://cygwin.com/packages/ results in an error "Invalid regular
>> expression search string: `[.exe`". Quotes, double quotes, and back
>> ticks do not help during the search.
>
> Problem of the web interface.
>
>> What is this program supposed to do?
>
> The same as "test", except that "[" will expect and consume the closing 
> bracket.
>  Used in scripting with shells that don't have [ built-in.
>
> Details with "man test" ("man [" is missing on my Cygwin system), or in bash
> with "help [".
>
> --
> Matthias Andree
>
> --
> 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: Suspicious EXE named "[.exe" in c:\cygwin\bin?

[Jeffrey Walton]

BTW, Since the web interface tried to interpret my input ("Invalid
regular expression search string"), this database is probably
vulnerable to a SQL injection.

GNU just got pwn'd

Has anyone tried thew 1 =1 trick lately? Are passwords residing in
another table?

Jeff

Am 12.12.2010 12:29, schrieb Jeffrey Walton:
> Hi Guys,
>
> The executable name is suspicious at best. Attempting to search

On the contrary, it's a standard utility mentioned in IEEE Std 1003.1.

> http://cygwin.com/packages/ results in an error "Invalid regular
> expression search string: `[.exe`". Quotes, double quotes, and back
> ticks do not help during the search.

Problem of the web interface.

> What is this program supposed to do?

The same as "test", except that "[" will expect and consume the closing bracket.
 Used in scripting with shells that don't have [ built-in.

Details with "man test" ("man [" is missing on my Cygwin system), or in bash
with "help [".

-- 
Matthias Andree

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

Suspicious EXE named "[.exe" in c:\cygwin\bin?

[Jeffrey Walton]

Hi Guys,

The executable name is suspicious at best. Attempting to search
http://cygwin.com/packages/ results in an error "Invalid regular
expression search string: `[.exe`". Quotes, double quotes, and back
ticks do not help during the search.

What is this program supposed to do?

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: Problem installing packages

[Jeffrey Walton]

On Sun, Dec 12, 2010 at 12:10 AM, Huang Bambo  wrote:
> It's a windows' behavier.
> It will open this box while running a program named setup.exe, just ignore
> it.
Thanks Huang. Unfortunately, I still cannot install packages :/ Are
there "unofficial" instructions anywherethat work as expected?

> On Sun, Dec 12, 2010 at 12:26 PM, Jeffrey Walton  wrote:
>>
>> Hi All,
>>
>> According to http://www.cygwin.com/, "Run setup.exe any time you want
>> to update or install a Cygwin package. ":
>>
>> jeff...@descartes ~
>> $ setup.exe
>>
>> Result is a message box that states "Please go to the Control Panel to
>> install and configure system components."
>>
>> Navigate to Control Panel -> Add/Remove Programs. Cygwin is *not* listed.
>>
>> I'm obviously doing something wrong. Any ideas where my ability (or
>> lack of) to follow instructions failed?
>>
>> Thanks,
>>
>> 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

Suspicious EXE named .exe in c:\cygwin\bin?

[Jeffrey Walton]

Hi Guys,

The executable name is suspicious at best. Attempting to search
http://cygwin.com/packages/ results in an error "Invalid regular
expression search string: `.exe`". Quotes, double quotes, and back
ticks do not help during the search.

What is this program supposed to do?

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

Executable named "[.exe" in c:\cygwin\bin?

[Jeffrey Walton]

Hi Guys,

The executable name is suspicious at best. Attempting to search
http://cygwin.com/packages/ results in an error "Invalid regular
expression search string: `[.exe`". Qoutes, double quotes, and back
ticks do not help during the search.

What is this program supposed to do?

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

[Jeffrey Walton]

Hi All,

According to http://www.cygwin.com/, "Run setup.exe any time you want
to update or install a Cygwin package. ":

jeff...@descartes ~
$ setup.exe

Result is a message box that states "Please go to the Control Panel to
install and configure system components."

Navigate to Control Panel -> Add/Remove Programs. Cygwin is *not* listed.

I'm obviously doing something wrong. Any ideas where my ability (or
lack of) to follow instructions failed?

Thanks,

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

'cygcheck -p' timeout on WinXP (Winsock error 12002)

[Jeffrey Walton]

Hi All,

Windows XP, fully patched. Cygwin, latest download from website
(installed today).

It appears cygcheck times out on Windows XP. The timeout occurs with
the Windows firewall up and down. Other downloads are function fine.

Attached is a Wireshark trace for your enjoyment.

Jeff

jeff...@descartes ~
$ cygwin -version
bash: cygwin: command not found

jeff...@descartes ~
$ cygwin --version
bash: cygwin: command not found

jeff...@descartes ~
$ cygcheck -p 'make'
cygcheck: unable to contact cygwin.com site, InternetOpenUrl() failed: The opera
tion timed out
 (win32 error 12002)

jeff...@descartes ~
$ cygcheck -p make
cygcheck: unable to contact cygwin.com site, InternetOpenUrl() failed: The opera
tion timed out
 (win32 error 12002)


cygcheck.pcap
Description: Binary data
--
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