Apparent bug in either (1) Cygwin default Package-list or (2) Package "bzr" dependency-list

[My Name via Cygwin]

I found an apparent dependency problem in Cygwin, and I'm not enough of a
Cygwin expert to know whether the bug is in Cygwin or Bazaar (Package
"bzr"); but if I had to guess, I'd guess it's in Cygwin, and I've already
reported the issue to the Bazaar forum.

In summary, after I installed Cygwin and Cygwin-Package "bzr", bzr failed
as it attempted to execute "python27". A detailed description of the issue,
including input and output from several tests I ran, and including the
solution posted by someone else (solution = install Cygwin-Package
"python27") is here, https://answers.launchpad.net/bzr/+question/691381,
and it's rather concise so I'll end here and refer you to that thread.

Per the directions here, https://cygwin.com/problems.html, I'm
email-attaching the output from "cygcheck -s -v -r".


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: Find_fast_cwd : warning

[Brian Inglis]

Your Cygwin version does not support your Windows version:
you must upgrade Cygwin and all packages using Cygwin setup;
see:
https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings
and choose:
https://cygwin.com/setup-x86_64.exe
or:
https://cygwin.com/setup-x86.exe

On 2020-06-18 08:23, Srikantaiah, Jagadesh via Cygwin wrote:
> I still finding the same warnings , could you let me what's other possibility 
> to resolve this issue

>> I am facing below warning many times when I am using 
>> cygwin\lib\gcc\i686-pc-cygwin\4.8.3 ..please do me know what is the 
>> solution for this issue

>> 1 [main] sh 18352 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
>> pointer.  Please report this problem to the public mailing list 
>> cygwin@cygwin.com

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

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
--
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

[ANNOUNCEMENT] lcms2 2.11-1

[Ken Brown via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* lcms2-2.11-1
* liblcms2_2-2.11-1
* liblcms2-devel-2.11-1

Little CMS intends to be an Open Source small-footprint color
management engine, with special focus on accuracy and performance.  It
uses the International Color Consortium standard (ICC), which is the
modern standard regarding color management.  The ICC specification is
widely used and is referred to in many International and other
de-facto standards.

This is an update to the latest upstream release.  It is a maintenance
release, to fix some bugs in 2.10.  See

  https://sourceforge.net/p/lcms/mailman/message/37039030/

for details.

Ken Brown
Cygwin's lcms2 maintainer
--
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

lcms2 2.11-1

[Ken Brown via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* lcms2-2.11-1
* liblcms2_2-2.11-1
* liblcms2-devel-2.11-1

Little CMS intends to be an Open Source small-footprint color
management engine, with special focus on accuracy and performance.  It
uses the International Color Consortium standard (ICC), which is the
modern standard regarding color management.  The ICC specification is
widely used and is referred to in many International and other
de-facto standards.

This is an update to the latest upstream release.  It is a maintenance
release, to fix some bugs in 2.10.  See

  https://sourceforge.net/p/lcms/mailman/message/37039030/

for details.

Ken Brown
Cygwin's lcms2 maintainer

Re: Is this a valid synopsis of Cygwin Permission Handling?

[Ken Brown via Cygwin]

On 6/18/2020 12:15 PM, KARL BOTTS via Cygwin wrote:


I wrote the following to a colleague in a private chat channel. Colleague is
pure Windows: knows little of cygwin or Linux.  He helps me with hardware and
Windows.

We had gotten the WinExplorer dialog saying: "The permissions on volume I: are
incorrectly ordered, which may cause some entries to be ineffective." This was
after I had run, with cygwin, 'chmod -R 777 .' in the root of that drive.

I am not complaining, reporting a bug, or anything like that. I am only asking
the cygwin experts, whether my synopsis of cygwin permission handling, is
reasonably and logically correct.

Thanks.


#

Karl Botts, [18.06.20 09:17]
On that dialog box: I must confess, you should know: I may have caused that,
by running in root of I: drive, aka in I:/  :

chmod -R 777 .

I did that _after_ screwing around with WinExplorer security dialogs. Was not
getting anywhere, so I tried the chmod out of desperation. Probably should not
have.

How cygwin works, with respect to permissions:

When the first cygwin1.dll is launched (one is being loaded into a process,
and no other is loaded), it queries from WinDomainController, all security
info it can get. Including SIDs, ACLs, practically everything. That
cygwin1.dll builds, in  shared memory private to cygwin, a database expressing
all that data, in Linux terms. That database emulates what a Linux kernel
reads from /etc/passwd, /etc/groups, more places, including other hosts.

All cygwin processes started as descendants of that first process, are passed
pointer to that DB in shm. (That DB is built just once.) (Remember, in
Linux/cygwin model, every process is a child of some other process.)
Thereafter, that DB is almost all a cygwin process knows about perms. I think,
occasionally, it may call to DomainController again, or to refresh, but tries
to avoid that, because is very slow. (If every cygwin process queried
DomainController, would be unacceptably slow.)

Problem is that emulation, Linux perms <==> Win perms, is not perfect.  A few
concepts in each, unknown to other.

In particular: in Win, the AccessControlEntries in an AccessControlList, must
be in a certain order, or the ACL is invalid. No such concept in Linux: all
orders valid. When ACL is invalid for that reason, WinExplorer is known to be
helpless, hence dialog above. Per cygwin mailing list, Win program
'icacls.exe' can straighten that out. But requires extreme complex commands to
icacls; has varied over time; me not know exactly how to do it. So I get
stuck.

What 'chmod -R 777 .' means is: Assign complete Read,Write,Execute perms, for
all of User,Group,Other, from current working dir (the .), recursively, all
the way down. To all files, all dirs, all everything.

Those concepts of 'complete' and 'all' and 'recursively all the way down', do
not map perfectly to Windows. It seems to refuse to believe that intent.
Somehow, some ACLs wind up in 'wrong ACE order' state. WinExplorer now
helpless: you get that dialog. Snafu.

I think I did that.


I haven't read this carefully, but I did notice one inaccuracy.  It's not true 
that the Windows ACEs must be in a certain order or the ACL is invalid.  Windows 
prefers a certain order, in which case the ACL is called "canonical".  But 
Windows deals perfectly well with non-canonical ACLs, even though Windows 
Explorer complains.  See


  https://cygwin.com/cygwin-ug-net/ntsec.html

for details, as well as for an explanation of why Cygwin sometimes produces 
non-canonical ACLs.


Ken
--
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: [off topic] RE: Re: Country Of Origin Verification - 8944

[ASSI]

Jason Pyeron writes:
> Unless Cygwin and its packages are never to be used by business
> and government, these are legitimate concerns. Just because some of
> the users and volunteers do not care or understand does not mean it is
> not important.

Well, even if any user or volunteer does care and understand, that still
does not put them into a position to provide the information that was
asked.

For the original question: It is clear from earlier communication on
this list that Cygwin is in use by various branches of the
U.S. government, so if you can get hold of the people who've done that
before you'll likely be able to re-use their trail(s) and get 80…90% of
your answers by copy

> Supply Chain Risk is a real issue.
[…]
> But this approach cannot work for Centos, Cygwin, and other
> collections of open source.

Right.  For Cygwin in particular, there is the additional issue that it
is very much a rolling distribution, and packages come and go and change
versions all the time.  So by the time you've cut through all the red
tape you'll have to start over again.

I use Cygwin in environments that need to be auditable.  While the
actual auditing thankfully has not yet been necessary, I've put in place
some of the preparations for that nevertheless:

1. The install is from a local repository and setup has been modified to
allow only signed installs and been outfitted with a different signing
key so users can't go around the local repo and install from the
internet (yes, they've tried).

2. The install will always leave you with the same set of packages when
successful for each type of installation supported and the install
script knows which type of installation belongs on each machine.  I
could nail that part down harder, but at the moment it suffices. All
add-on software for Cygwin that is not in the upstream repository is
properly packaged locally and put into the local repository

3. If proper auditing ever becomes necessary I can switch to a phased
install model where I can keep certain machines to whatever the audited
state is and keep updating the other installs as I do at the moment for
all of them.  Right now I just have a staging repo that I update
frequently and gets copied to the live repo when I tested the staging
install OK.

4. I've convinced myself that I could build all packages from source if
I had to, but I've not actually done it yet.  That would not be a
requirement for us anyway, but as requirements change all the time it's
better to have that fallback in place.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
--
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: "kubectl exec" in Cygwin gets "Upgrade request required", but not in cmd shell

[David Karr via Cygwin]

On Wed, Jun 17, 2020 at 6:06 PM Brian Inglis  wrote:

> On 2020-06-17 10:39, David Karr via Cygwin wrote:
> > On Mon, Jun 15, 2020 at 9:10 AM David Karr wrote:
> >> On Sun, Jun 14, 2020 at 12:32 PM David Karr wrote:
> >>> On Sun, Jun 14, 2020 at 12:09 PM Brian Inglis wrote:
>  On 2020-06-14 12:16, David Karr via Cygwin wrote:
> > On Sun, Jun 14, 2020 at 10:20 AM Brian Inglis wrote:
> >> On 2020-06-14 09:38, David Karr via Cygwin wrote:
> >>> On Sun, Jun 14, 2020 at 2:25 AM Marco Atzeri wrote:
>  On 14.06.2020 08:12, David Karr wrote:
> > On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
> >> On 13.06.2020 20:53, David Karr via Cygwin wrote:
> >>> I've been using kubectl in Cygwin on Windows 10 for quite a
>  while,
> >>> to communicate to our in-house k8s clusters. I often use
> "kubectl
> >>> exec" to open a shell in a container or directly execute a
> shell
> >>> command.
> >>> This has worked perfectly fine for a long time.
> >>> A couple of days ago, I discovered that all of these attempts
>  were
> >>> failing with "Upgrade request required".  I hadn't upgraded
>  kubectl
> >>> or Cygwin in quite a while. I doubt our clusters had a k8s
>  upgrade,
> >>> but it's entirely possible.
> >>> A colleague of mine has a very similar desktop configuration
> >>> (Windows 10, Cygwin), and he's not seeing this symptom.
> >>> I noticed that when I ran "kubectl exec" with max verbosity, it
>  shows
> >>> the resulting "curl" command that it runs. I tried that
> resulting
> >>> command, and it results in the same response. I then tried
>  updating
> >>> my Cygwin tools and retesting, no change.> I then took the
> >> entire resulting "kubectl exec" command line and ran
> >>> it in a "cmd" shell.  No problem at all.  No error.
> >>> I know I haven't provided much useful information yet. I wanted
>  to
> >>> get an initial response before I started providing those
>  diagnostics.
> >>> Is there a clear issue here that I'm not aware of?
> >>
> > from where is kubectl coming from ?
> > In cygwin I found only a kubectl.py in the ansible package
> >>
> >> It's from here:
> >>
> >>
> 
> https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
> >>
>  so it is NOT a cygwin program.
>  If the warning is coming about curl, it is likely
>  that using from cygwin you are using the cygwin curl
>  and from CMD the windows one
>  $ which -a curl
>  /usr/bin/curl
>  /cygdrive/c/WINDOWS/system32/curl
>  $ /cygdrive/c/WINDOWS/system32/curl -V
>  curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
>  Release-Date: 2017-11-14, security patched: 2019-11-05
>  Protocols: dict file ftp ftps http https imap imaps pop3 pop3s
> smtp
> >> smtps
>  telnet tftp
>  Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
> 
>  $ /usr/bin/curl -V
>  curl 7.66.0 (x86_64-pc-cygwin) libcurl/7.66.0 OpenSSL/1.1.1f
>  zlib/1.2.11
>  brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.0.4)
>  libssh/0.8.7/openssl/zlib nghttp2/1.37.0
>  Release-Date: 2019-09-11
>  Protocols: dict file ftp ftps gopher http https imap imaps ldap
>  ldaps
>  pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
>  Features: AsynchDNS brotli Debug GSS-API HTTP2 HTTPS-proxy IDN
> IPv6
>  Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL
> TLS-SRP
>  TrackMemory UnixSockets
>  the support Forum https://discuss.kubernetes.io/
>  is probably the most indicate place for guidance
> >>
> >>> I thought it was obvious that it was not working because it was
>  calling
> >> the
> >>> Cygwin curl. I wouldn't have posted here if that wasn't obvious to
>  me.
> >>> And since I'm well aware of the k8s community, I already posted
>  questions
> >>> about this in the appropriate place, before I posted here.
> >>> What I was hoping to get here was some indication or thoughts on
> why
>  a
> >>> process using Windows curl doesn't have a problem, but does have a
> >> problem
> >>> when using Cygwin Curl. This isn't likely something that Cygwin
> curl
>  is
> >>> doing "wrong", it's just that it's doing something different.
> >>> If it matters, the following is an elided version of the resulting
>  curl
> >>> command:
> >>> curl -k -v -XPOST  -H "User-Agent: kubectl.exe/v1.18.0
> >> (windows/amd64)
> >>> kubernetes/9e99141" -H "Authorization: Bearer ..." -H
> >>> "X-Stream-Protocol-Version: v4.channel.k8s.io" -H
> >>> "X-Stream-Protocol-Version: 

Fonts: Cygwin/X, ssh -Y, TigerVNC -- who's in charge?

[Henry S. Thompson via Cygwin]

[Warning, gnarly X-windows issues below, read at your own risk]

I run XEmacs on several Linux servers, and sometimes (always for the
time being) access them via (Cygwin) ssh -Y and/or (Windows)TigerVNC.

XEmacs and fonts are problematic in their own right, but I'm struggling
to understand the X-windows-as-such issues of this configuration, to try
to isolate my problem, which is that I'm not seeing things displayed in
the fonts I want.

In particular, I'm trying to understand as between the X servers running
on my remote servers (there has to be one, however simple, whichever way
I connect, because that's where my XEmacs instances are running, right?) 
and the Cygwin/X server on my machine at home.

Configuration 1)

I _think_ I understand that if I launch XEmacs inside an Xvnc instance
on a server, viewed using a vncviewer instance on my home machine, the
fonts available to it are determined by what fonts are available within
the remote Xvnc instance, in whatever form.

Am I also right in thinking that it does _not_ matter what fonts
TigerVNC-for-Windows finds on my Cygwin box at home?

Configuration 2)

If OTOH I launch Cygwin/XWin, and ssh -Y from a local xterm to a remote
server, where I launch XEmacs, I really don't know what happens.  Does
the sshd X server include a font server, or search for font.dirs, or???
Or does _all_ font-related activity depend on the Cygwin/X server?

Configuration 3)

Unfortunately, the configuration I like best is a mixture.  I launch
XEmacs inside an Xvnc instance on a server, viewed using a vncviewer
instance on my home machine, and fire up gnuserv inside it.  I close the
viewer, and ssh -Y back to the server from home, then run gnuclient from
the resulting shell, which brings up a separate window on the original
XEmacs instance.  I have no idea whose fonts matter in this case, can
anyone explain?

A related question: when running setup and looking at font packages, how
can I tell whether they contain new-style (fc-list will will list them,
they have names such as "DejaVu Sans Mono", or old-style (xlsfonts will
list them, they have names such as "-b")?

Thanks,

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

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

Is this a valid synopsis of Cygwin Permission Handling?

[KARL BOTTS via Cygwin]

I wrote the following to a colleague in a private chat channel. Colleague is
pure Windows: knows little of cygwin or Linux.  He helps me with hardware and
Windows.

We had gotten the WinExplorer dialog saying: "The permissions on volume I: are
incorrectly ordered, which may cause some entries to be ineffective." This was
after I had run, with cygwin, 'chmod -R 777 .' in the root of that drive.

I am not complaining, reporting a bug, or anything like that. I am only asking
the cygwin experts, whether my synopsis of cygwin permission handling, is
reasonably and logically correct.

Thanks.


#

Karl Botts, [18.06.20 09:17]
On that dialog box: I must confess, you should know: I may have caused that,
by running in root of I: drive, aka in I:/  :

chmod -R 777 .

I did that _after_ screwing around with WinExplorer security dialogs. Was not
getting anywhere, so I tried the chmod out of desperation. Probably should not
have.

How cygwin works, with respect to permissions:

When the first cygwin1.dll is launched (one is being loaded into a process,
and no other is loaded), it queries from WinDomainController, all security
info it can get. Including SIDs, ACLs, practically everything. That
cygwin1.dll builds, in  shared memory private to cygwin, a database expressing
all that data, in Linux terms. That database emulates what a Linux kernel
reads from /etc/passwd, /etc/groups, more places, including other hosts.

All cygwin processes started as descendants of that first process, are passed
pointer to that DB in shm. (That DB is built just once.) (Remember, in
Linux/cygwin model, every process is a child of some other process.)
Thereafter, that DB is almost all a cygwin process knows about perms. I think,
occasionally, it may call to DomainController again, or to refresh, but tries
to avoid that, because is very slow. (If every cygwin process queried
DomainController, would be unacceptably slow.)

Problem is that emulation, Linux perms <==> Win perms, is not perfect.  A few
concepts in each, unknown to other.

In particular: in Win, the AccessControlEntries in an AccessControlList, must
be in a certain order, or the ACL is invalid. No such concept in Linux: all
orders valid. When ACL is invalid for that reason, WinExplorer is known to be
helpless, hence dialog above. Per cygwin mailing list, Win program
'icacls.exe' can straighten that out. But requires extreme complex commands to
icacls; has varied over time; me not know exactly how to do it. So I get
stuck.

What 'chmod -R 777 .' means is: Assign complete Read,Write,Execute perms, for
all of User,Group,Other, from current working dir (the .), recursively, all
the way down. To all files, all dirs, all everything.

Those concepts of 'complete' and 'all' and 'recursively all the way down', do
not map perfectly to Windows. It seems to refuse to believe that intent.
Somehow, some ACLs wind up in 'wrong ACE order' state. WinExplorer now
helpless: you get that dialog. Snafu.

I think I did that.


---
Karl Botts, kdbo...@usa.net

--
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: [ITP] python36-wx 4.0.7.post2

[Hamish McIntyre-Bhatty via Cygwin-apps]

On 18/06/2020 15:08, Jon Turney wrote:
> Done.
>
> Perhaps 'python-wx' should be renamed to 'python2-wx', at some point
> in the future, to make it clear what it contains?

Thanks. Packages are uploaded now.

Yes, I agree, but I'm not sure how to handle that transition smoothly.

Hamish



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Test: python3-wx-4.0.7.post2-1

[Hamish McIntyre-Bhatty via Cygwin-announce]

Version 4.0.7.post2-1 of "python3-wx" has been uploaded.

python3-wx is the Python 3 version of the cross-platform GUI toolkit,
wxPython.

This is the initial revision, and it provides the following packages:

python3-wx (the source package)

python3-wx-common (common files)

python3-wx-debuginfo

python36-wx (wxPython built for Python 3.6)

python37-wx (wxPython built for Python 3.7)

A package will be provided for Python 3.8 once python38-numpy has been
packaged.

These are test packages - please test them and report any issues. If
there are no issues reported in a week or so, I will release these as
stable.


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

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

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







0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
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

Test: python3-wx-4.0.7.post2-1

[Hamish McIntyre-Bhatty via Cygwin-announce]

Version 4.0.7.post2-1 of "python3-wx" has been uploaded.

python3-wx is the Python 3 version of the cross-platform GUI toolkit,
wxPython.

This is the initial revision, and it provides the following packages:

python3-wx (the source package)

python3-wx-common (common files)

python3-wx-debuginfo

python36-wx (wxPython built for Python 3.6)

python37-wx (wxPython built for Python 3.7)

A package will be provided for Python 3.8 once python38-numpy has been
packaged.

These are test packages - please test them and report any issues. If
there are no issues reported in a week or so, I will release these as
stable.


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

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

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







0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

RE: [EXTERNAL] Re: Find_fast_cwd : warning

[Srikantaiah, Jagadesh via Cygwin]

Hello team,

I still finding the same warnings , could you let me what's other possibility 
to resolve this issue


Regards
Jagadesh.A.S



-Original Message-
From: cygwinautore...@sourceware.org  
Sent: Tuesday, June 16, 2020 10:32 AM
To: Srikantaiah, Jagadesh 
Cc: cygwin@cygwin.com
Subject: [EXTERNAL] Re: Find_fast_cwd : warning

>Hello team,

>I am facing below warning many times when I am using 
>cygwin\lib\gcc\i686-pc-cygwin\4.8.3 ..please do me know what is the 
>solution for this issue


>1 [main] sh 18352 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
>pointer.  Please report this problem to the public mailing list 
>cygwin@cygwin.com

>Regards
>Jagadesh.A.S


https://clicktime.symantec.com/3VmEPBxnYmzakjtpQXw935m7Vc?u=https%3A%2F%2Fcygwin.com%2Ffaq.html%23faq.using.fixing-find_fast_cwd-warnings
--
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: [ITP] python36-wx 4.0.7.post2

[Jon Turney]

On 18/06/2020 12:31, Hamish McIntyre-Bhatty via Cygwin-apps wrote:

sure.

https://cygwin.com/packaging/key.html#sshkey


SSH key is already all set-up (I took maintainership of python-wx before).

Can't upload my test packages yet though because they aren't in the
package list.


Done.

Perhaps 'python-wx' should be renamed to 'python2-wx', at some point in 
the future, to make it clear what it contains?

Updated: mutt-1.14.3-1

[Marco Atzeri via Cygwin-announce]

New version 1.14.3-1 of

  mutt

is available in the Cygwin distribution:

CHANGES
Last upstream bugfix update release.

Full details on:
https://gitlab.com/muttmua/mutt/raw/master/UPDATING

DESCRIPTION
The Mutt E-Mail Client
"All mail clients suck. This one just sucks less."

Mutt is a small but very powerful text-based mail client
for Unix operating systems.

HOMEPAGE
http://www.mutt.org/

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

[ANNOUNCEMENT] Updated: mutt-1.14.3-1

[Marco Atzeri via Cygwin-announce]

New version 1.14.3-1 of

  mutt

is available in the Cygwin distribution:

CHANGES
Last upstream bugfix update release.

Full details on:
https://gitlab.com/muttmua/mutt/raw/master/UPDATING

DESCRIPTION
The Mutt E-Mail Client
"All mail clients suck. This one just sucks less."

Mutt is a small but very powerful text-based mail client
for Unix operating systems.

HOMEPAGE
http://www.mutt.org/

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .
--
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: [ITP] python36-wx 4.0.7.post2

[Hamish McIntyre-Bhatty via Cygwin-apps]

> sure.
>
> https://cygwin.com/packaging/key.html#sshkey

SSH key is already all set-up (I took maintainership of python-wx before).

Can't upload my test packages yet though because they aren't in the
package list.

Hamish



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: [ITP] python36-wx 4.0.7.post2

[Marco Atzeri via Cygwin-apps]

On 18.06.2020 10:20, Hamish McIntyre-Bhatty via Cygwin-apps wrote:

On 17/06/2020 22:23, Hamish McIntyre-Bhatty via Cygwin-apps wrote:

On 17/06/2020 20:24, Marco Atzeri via Cygwin-apps wrote:

On 17.06.2020 10:41, Hamish McIntyre-Bhatty via Cygwin-apps wrote:

On 15/06/2020 19:26, Achim Gratz wrote:

Hamish McIntyre-Bhatty via Cygwin-apps writes:

Turns out just running "rebaseall" worked for me. I don't get any
fork-related warnings/errors any more.

No it doesn't, it's a mere coincidence that it worked in your case.
You
shouldn't manually run rebaseall on Cygwin at all in fact, setup
perpetual postinstall actions take care of maintaing the rebase map.
If you ever have reason to believe that the rebase map needs a complete
rebuild, run "rebase-trigger full" and then run setup again.

Fitting newly built DLL into the rebase map is correctly done by an
ephemeral rebase like the script Marco has shown you does.

Good to know and thanks for the script Marco, seems to work well for me.

The only patch Fedora seems to be using is one to disable the bundled
SIP for building (which I think we need), so I believe this is now
finished. Do I need to rebuild against the new version of Python that
came out a few days ago for cygwin?

Hamish


If still work NO. If don't, we need to understand why as they should be
binary compatible.


Still works with the build from before, just double-checked.

Am I good to go now?

Hamish



sure.

https://cygwin.com/packaging/key.html#sshkey

Re: [ITP] python36-wx 4.0.7.post2

[Hamish McIntyre-Bhatty via Cygwin-apps]

On 17/06/2020 22:23, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 17/06/2020 20:24, Marco Atzeri via Cygwin-apps wrote:
>> On 17.06.2020 10:41, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>>> On 15/06/2020 19:26, Achim Gratz wrote:
 Hamish McIntyre-Bhatty via Cygwin-apps writes:
> Turns out just running "rebaseall" worked for me. I don't get any
> fork-related warnings/errors any more.
 No it doesn't, it's a mere coincidence that it worked in your case. 
 You
 shouldn't manually run rebaseall on Cygwin at all in fact, setup
 perpetual postinstall actions take care of maintaing the rebase map.
 If you ever have reason to believe that the rebase map needs a complete
 rebuild, run "rebase-trigger full" and then run setup again.

 Fitting newly built DLL into the rebase map is correctly done by an
 ephemeral rebase like the script Marco has shown you does.
>>> Good to know and thanks for the script Marco, seems to work well for me.
>>>
>>> The only patch Fedora seems to be using is one to disable the bundled
>>> SIP for building (which I think we need), so I believe this is now
>>> finished. Do I need to rebuild against the new version of Python that
>>> came out a few days ago for cygwin?
>>>
>>> Hamish
>>>
>> If still work NO. If don't, we need to understand why as they should be
>> binary compatible.

Still works with the build from before, just double-checked.

Am I good to go now?

Hamish



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: several python packages

[Marco Atzeri via Cygwin-announce]

Several python packages have been uploaded

python27-six-1.15.0-1

python36-appdirs-1.4.4-1
python36-pip-20.1.1-1
python36-pip-20.1.1-2   (Test)
python36-setuptools-46.4.0-1
python36-six-1.15.0-1
python36-virtualenv-20.0.23-1
python36-wheel-0.34.2-1

python37-appdirs-1.4.4-1
python37-pip-20.1.1-1
python37-pip-20.1.1-2   (Test)
python37-setuptools-46.4.0-1
python37-six-1.15.0-1
python37-virtualenv-20.0.23-1
python37-wheel-0.34.2-1

python38-appdirs-1.4.4-1
python38-pip-20.1.1-1
python38-pip-20.1.1-2   (Test)
python38-setuptools-46.4.0-1
python38-six-1.15.0-1
python38-virtualenv-20.0.23-1
python38-wheel-0.34.2-1

python-wheel-wheel-0.34.2-1

The test versions change the default from
python 3.6 to python 3.8


CHANGES
This is the latest upstream release


DESCRIPTION
Python is a programming language that lets you work quickly
and integrate systems more effectively.
Python is powerful... and fast; plays well with others;
runs everywhere; is friendly & easy to learn; is Open.

HOMEPAGE
https://www.python.org/

Regards
Marco Atzeri


If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .
--
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

Updated: several python packages

[Marco Atzeri via Cygwin-announce]

Several python packages have been uploaded

python27-six-1.15.0-1

python36-appdirs-1.4.4-1
python36-pip-20.1.1-1
python36-pip-20.1.1-2   (Test)
python36-setuptools-46.4.0-1
python36-six-1.15.0-1
python36-virtualenv-20.0.23-1
python36-wheel-0.34.2-1

python37-appdirs-1.4.4-1
python37-pip-20.1.1-1
python37-pip-20.1.1-2   (Test)
python37-setuptools-46.4.0-1
python37-six-1.15.0-1
python37-virtualenv-20.0.23-1
python37-wheel-0.34.2-1

python38-appdirs-1.4.4-1
python38-pip-20.1.1-1
python38-pip-20.1.1-2   (Test)
python38-setuptools-46.4.0-1
python38-six-1.15.0-1
python38-virtualenv-20.0.23-1
python38-wheel-0.34.2-1

python-wheel-wheel-0.34.2-1

The test versions change the default from
python 3.6 to python 3.8


CHANGES
This is the latest upstream release


DESCRIPTION
Python is a programming language that lets you work quickly
and integrate systems more effectively.
Python is powerful... and fast; plays well with others;
runs everywhere; is friendly & easy to learn; is Open.

HOMEPAGE
https://www.python.org/

Regards
Marco Atzeri


If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .