Re: Ctrl+C is sometimes ignored on Windows Terminal

[Russell VT via Cygwin]

If you're running things from under Windows Terminal, rather than the
Cygwin terminal, the behavior is likely going to be inconsistent or
unpredictable (and things like interrupts may be handled at a lower level
within the terminal, first, before passing to a higher level and received
by Cygwin).

I'd work on trying to reproduce this in any of the terminals provided by
Cygwin... otherwise, chances are you might need to dig deeper in
MSTerminal, or even WIndows, first.

Regards,
Russell VT


On Mon, Nov 1, 2021 at 1:34 AM Naoto Aoki via Cygwin 
wrote:

> Hi,
>
> When I'm using some programs such as bash and python from cygwin under
> Windows Terminal, Ctrl+C is sometimes ignored.
> https://github.com/microsoft/terminal
>
> Normally holding 'Ctrl' and pressing 'C' will make new line.
> But, sometimes it does not and unholding 'Ctrl' makes new line under
> Windows Terminal.
> bash from msys2 does also reproduce this issue.
>
> I dug into this issue and found that this is related to
> readline and Windows 10's pseudo console (ConPTY).
> I made simple programs to reproduce this issue.
>
>  - EchoCon.cpp
>- modification of ConPty sample code provided by Microsoft.
>  This program execute bash on pseudo console.
>  to be compiled with MSVC.
>  - getkey.cpp
>- simple program to check Ctrl+C is passed to Cygwin program.
>  to be compiled with Cygwin gcc.
>  - rltest.cpp
>- simple program to check SIGINT handling.
>  This program reproduces the issue.
>  If you replace readline("> ") with gets(buf),
>  then the issue does not happen.
>  to be compiled with Cygwin gcc.
>
> - The machine and OS that it is running on
>   - OS: Windows 10 Pro 19043.1288
>   - Windows Terminal: 1.11.2921.0
>
> Regards,
> Naoto Aoki
>
> --
> 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
>


-- 
Russell M. Van Tassell 

-- 
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: A Bug related to ImageTk in Python on Cygwin

[Russell VT via Cygwin]

I'll just throw out the obvious "is it plugged in" type question... but,
are we to assume you have a fully functional X Server and Client working on
your Cygwin install? Any particular desktop/window manager? Have you tried
others? Did you compile it yourself, or did you install the package
directly from the distro?

Sorry, sometimes the "oops" questions can help... and, it helps those
interested in reproducing it. (but, I will confess I didn't actually go
READ the bug - which, admittedly, is another "is it plugged in" type
query... LOL)

RVT


On Tue, Oct 19, 2021 at 3:13 AM Friedrich Romstedt via Cygwin <
cygwin@cygwin.com> wrote:

> Hi,
>
> Some months ago (in August 2021) I tried using ImageTk in Python on
> Cygwin and stumbled over a dysfunction.  To help tracking down the
> issue I wrote up an HTML document and uploaded it to
> https://github.com/friedrichromstedt/bughunting-02.  There is a
> minimal Test Case included in this github repo.
>
> I updated my whole Cygwin installation just this moment and found the
> behaviour unchanged with respect to what I've observed that time.
>
> Any pointer would be very much appreciated.
>
> Best,
> Friedrich
>
> --
> 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
>


-- 
Russell M. Van Tassell 

-- 
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: Terminator 2.0

[Russell VT via Cygwin]

This developer seems to have taken on the role as "main distributor,"
rather than making this a simple Python module that's distributed through
the likes of PyPy. Judging from the number of "unsupported"
distributions/versions in their list,
 I
would think you should take this up with the module owner, rather than with
any Cygwin maintainer.

If they would, instead, distribute this over a more-common
software repository... then, maybe I would answer this differently.

Cheers -
RVT


On Fri, Oct 8, 2021 at 12:59 AM mray271 via Cygwin 
wrote:

>
> Now that Terminator development is reinvigorated and Python 3 compat, is
> there a way I can get it working in Cygwin ?
>
> https://github.com/gnome-terminator/terminator
>
> Both the current offerings of Terminator and Guake are reliant on Python
> 2.7 and severely buggy or no longer working on Windows 10.
>
> Thanks!
>
>
> --
> 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
>


-- 
Russell M. Van Tassell 

-- 
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: cloc: hashbang header has "perl" twice

[Russell VT via Cygwin]

Replying to add the package maintainer, as-per Cygwin's source distribution
files.

This would be something I'd consider installing directly from source,
though it looks like the upstream may not make that *quite* as easily as
one would like... but, I'll take a better look, after I've slept (HaHa).

Cheers -
RVT


On Sat, Sep 25, 2021 at 3:32 AM Russell VT  wrote:

> Looking at the current Cygwin source, the she-bang is actually:
>
> #!/usr/bin/env perl
>
>
> ...which means it's going to pick up the first perl interpreter in your
> path.
>
> You can confirm this in the cloc code, itself, as well.
> 
>
> Please note that, because this is a Perl module, you can likely just
> uninstall the Cygwin package, and then use something like "CPAN install
> cloc" to get the latest version in your perl environment (HIGHLY recommend
> to install this in your local perl modules, under your home directory).
>
> That said, it looks like someone screwed the pooch on the Cygwin
> installer... I installed it via the Cygwin setup utility and have confirmed
> your findings. It *SHOULD* be safe to just manually change the she-bang to
> "env," if you want to use the Cygwin package, directly.
>
> [image: image.png]
>
> Cheers -
> Russell VT
>
>
> On Sat, Sep 25, 2021 at 12:36 AM Eyal Rozenberg via Cygwin <
> cygwin@cygwin.com> wrote:
>
>> I'm not sure how bug reporting "etiquette" works here on the list, but -
>> I was sort of expecting an acknowledgement. Or - was I wrong to post my
>> bug report here in the first place?
>>
>> I have another bug (two actually) to report regarding meld, and I want
>> to get that report right and not have it lost in the noise.
>>
>> Eyal
>>
>> On 22/09/2021 17:20, Eyal Rozenberg via Cygwin wrote:
>> > I'm using:
>> >
>> > Package  VersionStatus
>> > cloc 1.82+20190726+git608f376-1 OK
>> >
>> > updated today. The first line of /usr/bin/cloc is:
>> >
>> > #!/usr/bin/perl perl
>> >
>> > while it should just be:
>> >
>> > #!/usr/bin/perl
>> >
>> > (like it is on my Linux machine)
>> >
>> > Obviously this causes an error when running cloc:
>> >
>> > Can't open perl script "perl": No such file or directory
>> >
>> >
>> > I would also suggest that you consider using a newer version of cloc, as
>> > there have been several releases since 1.82
>> >
>> > Eyal
>> >
>>
>> --
>> 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
>>
>
>
> --
> Russell M. Van Tassell 
>


-- 
Russell M. Van Tassell 

-- 
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: cloc: hashbang header has "perl" twice

[Russell VT via Cygwin]

Looking at the current Cygwin source, the she-bang is actually:

#!/usr/bin/env perl


...which means it's going to pick up the first perl interpreter in your
path.

You can confirm this in the cloc code, itself, as well.


Please note that, because this is a Perl module, you can likely just
uninstall the Cygwin package, and then use something like "CPAN install
cloc" to get the latest version in your perl environment (HIGHLY recommend
to install this in your local perl modules, under your home directory).

That said, it looks like someone screwed the pooch on the Cygwin
installer... I installed it via the Cygwin setup utility and have confirmed
your findings. It *SHOULD* be safe to just manually change the she-bang to
"env," if you want to use the Cygwin package, directly.

[image: image.png]

Cheers -
Russell VT


On Sat, Sep 25, 2021 at 12:36 AM Eyal Rozenberg via Cygwin <
cygwin@cygwin.com> wrote:

> I'm not sure how bug reporting "etiquette" works here on the list, but -
> I was sort of expecting an acknowledgement. Or - was I wrong to post my
> bug report here in the first place?
>
> I have another bug (two actually) to report regarding meld, and I want
> to get that report right and not have it lost in the noise.
>
> Eyal
>
> On 22/09/2021 17:20, Eyal Rozenberg via Cygwin wrote:
> > I'm using:
> >
> > Package  VersionStatus
> > cloc 1.82+20190726+git608f376-1 OK
> >
> > updated today. The first line of /usr/bin/cloc is:
> >
> > #!/usr/bin/perl perl
> >
> > while it should just be:
> >
> > #!/usr/bin/perl
> >
> > (like it is on my Linux machine)
> >
> > Obviously this causes an error when running cloc:
> >
> > Can't open perl script "perl": No such file or directory
> >
> >
> > I would also suggest that you consider using a newer version of cloc, as
> > there have been several releases since 1.82
> >
> > Eyal
> >
>
> --
> 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
>


-- 
Russell M. Van Tassell 

-- 
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: Missing Python.h

[Russell VT via Cygwin]

I am NOT saying there's a problem having "both" versions installed at the
same time... I am merely pointing out that, apparently, you have a chicken
and egg type issue, likely coming down to "which symlink" is created for
/usr/bin/python ... and more specifically, if it points to version 2, or
version 3 as "default" (these can also be managed in /etc/alternatives).

But, it's tough to tell because you've only included minimal evidence that
would appear to be python3 complaining about python2 libraries ... which
isn't a big surprise, really. Considering that it is HIGHLY advised to no
longer use Python2, it would not surprise me if something may change those
base symlinks

For example. from one of my own Cygwin installs...

[image: image.png]

So, at least my own Cygwin *DEFAULTS* to Python3, not Python2 (which again,
given current coding standards, is not at all surprising). You can use the
"alternative" command to see how your environment(s) are setup.

[image: image.png]

So yeah, you may want to argue that having a Python environment manager
such as pyenv (a simple git pull) is "too much complexity," but I can tell
you as a large scale devops type that it actually simplifies a lot of the
complexities, especially if you need to manage multiple module versions
across more-than-one Python interpreter. And, if you do *ANY* sort of
automated testing, these environments are literally a blessing you may
want to check out tox, or any of the other github/gitlab sort of
automations, for example.

As far as "tossing" Python3, I would *highly* advise you to work towards
upgrading to it NOW, rather than running away from it. If you write
*anything* that requires something like SSL libraries, you literally can't
completely avoid SSL vulnerabilities without considerable effort in the
older Python2 stuff.

Anyway, hope that helps...

RVT


On Wed, Sep 22, 2021 at 7:19 AM Dennis Putnam  wrote:

> Hi Russell,
>
> Thanks for the reply. I program Python 2 and 3 on various Linux systems
> but not much on Cygwin. It normally is not a problem to have both so I
> didn't think it would be a problem on Cygwin. Since I have scripts for 2 on
> Cygwin, I'm thinking I should toss 3,at least for now, and just stick with
> 2. I have a lot to think about at this point. Using  an environment layer
> adds more complexity when I want to launch a script from a Windows
> application or bat file.
>
> On 9/22/2021 5:49 AM, Russell VT wrote:
>
> First off, this *probably* isn't a Cygwin problem ... but it looks like
> your environment is confused as it's using BOTH Python2 and Python3 modules
> to try to fulfill the requirements (including resources that have already
> been cached).
>
> For the most part, pip and pip3 can differentiate, but there's a "cart"
> and "horse" problem, as if you install things in a weird order at the
> system level, it may or may not do the right thing. But, I'd recommend
> "dumping" Python2, if you can at this point (it was EOL'd in December of
> 2020 and WILL NOT receive more updates, except for security ... and
> more-over, Python 3.7+ (approx) is going to demand newer SSL libraries that
> will REALLY confuse earlier versions).
>
> For working with Python (as a Python devops type), I generally recommend
> using 'pyenv' and 'pyenv-virtualenv' and trying to do *as little as
> possible* to modify the system-level Python ...this gets HARD with a system
> like Cygwin, where the generic user can generally overwrite system
> binaries, without any real sort of warning (and NO, UAC does NOT adequately
> fix anything).
>
> That also said, pyenv kinda really "fights" with Cygwin in some of the
> library placement (specifically things like FFI, IIRC, which is stored in a
> different library directory than it is, anywhere else I've found).
>
> Where I MIGHT start is to "Force Reinstall" the Python3 stuff from Setup.
> Look to see if requests_html is part of the Cygwin-supported modules, and
> use THAT... use the hell out of anything you see in the actual Python
> packages list, as those will at least be done RIGHT, and will leave you
> with more cycles to not worry about too much, except your development.
>
> For "Advanced" handling in Python, you're going to want to use "pyenv" or
> some other multi-python managers that are out there (virtualenv and
> virtualenv-wrapper are good, but ONLY manage the library path). Pretty much
> "pyenv" and "pipenv" are the top two, IIRC. I use pyenv, and haven't dug
> too deep in to pipenv, at this point. But, like I said, it's already tough
> enough to manage on older systems with older libraries (SSL, specifically,
> throws wrenches in to *everything*).
>
> Feel free to hit me up for other ideas... I write too much Python code, as
> it is, and on too many different environments (yes, some still do Python2.3
> through 2.6, and it makes me want to shoot myself, sometimes... LOL).
>
> Hope that helps -
> Russell VT
>
>
> On Tue, Sep 21, 2021 at 11:38 AM Dennis Putnam  wrote:
>
>> I am 

Re: Missing Python.h

[Russell VT via Cygwin]

First off, this *probably* isn't a Cygwin problem ... but it looks like
your environment is confused as it's using BOTH Python2 and Python3 modules
to try to fulfill the requirements (including resources that have already
been cached).

For the most part, pip and pip3 can differentiate, but there's a "cart" and
"horse" problem, as if you install things in a weird order at the system
level, it may or may not do the right thing. But, I'd recommend "dumping"
Python2, if you can at this point (it was EOL'd in December of 2020 and
WILL NOT receive more updates, except for security ... and more-over,
Python 3.7+ (approx) is going to demand newer SSL libraries that will
REALLY confuse earlier versions).

For working with Python (as a Python devops type), I generally recommend
using 'pyenv' and 'pyenv-virtualenv' and trying to do *as little as
possible* to modify the system-level Python ...this gets HARD with a system
like Cygwin, where the generic user can generally overwrite system
binaries, without any real sort of warning (and NO, UAC does NOT adequately
fix anything).

That also said, pyenv kinda really "fights" with Cygwin in some of the
library placement (specifically things like FFI, IIRC, which is stored in a
different library directory than it is, anywhere else I've found).

Where I MIGHT start is to "Force Reinstall" the Python3 stuff from Setup.
Look to see if requests_html is part of the Cygwin-supported modules, and
use THAT... use the hell out of anything you see in the actual Python
packages list, as those will at least be done RIGHT, and will leave you
with more cycles to not worry about too much, except your development.

For "Advanced" handling in Python, you're going to want to use "pyenv" or
some other multi-python managers that are out there (virtualenv and
virtualenv-wrapper are good, but ONLY manage the library path). Pretty much
"pyenv" and "pipenv" are the top two, IIRC. I use pyenv, and haven't dug
too deep in to pipenv, at this point. But, like I said, it's already tough
enough to manage on older systems with older libraries (SSL, specifically,
throws wrenches in to *everything*).

Feel free to hit me up for other ideas... I write too much Python code, as
it is, and on too many different environments (yes, some still do Python2.3
through 2.6, and it makes me want to shoot myself, sometimes... LOL).

Hope that helps -
Russell VT


On Tue, Sep 21, 2021 at 11:38 AM Dennis Putnam  wrote:

> I am trying to install 'requests_html' and when it tries to do a compile
> it fails because Python.h is missing. I have python2-devl installed. I
> notice that it is looking for it in /pub which apparently does not
> exist. Can someone help? TIA.
>
> Here is the entire 'pip' output:
>
> $ pip install requests_html
> Collecting requests_html
>Using cached requests_html-0.10.0-py3-none-any.whl (13 kB)
> Collecting requests
>Using cached requests-2.26.0-py2.py3-none-any.whl (62 kB)
> Collecting w3lib
>Using cached w3lib-1.22.0-py2.py3-none-any.whl (20 kB)
> Collecting parse
>Using cached parse-1.19.0.tar.gz (30 kB)
> Collecting fake-useragent
>Using cached fake-useragent-0.1.11.tar.gz (13 kB)
> Collecting pyquery
>Using cached pyquery-1.4.3-py3-none-any.whl (22 kB)
> Collecting bs4
>Using cached bs4-0.0.1.tar.gz (1.1 kB)
> Collecting pyppeteer>=0.0.14
>Using cached pyppeteer-0.2.6-py3-none-any.whl (83 kB)
> Requirement already satisfied: tqdm<5.0.0,>=4.42.1 in
> /usr/local/lib/python3.8/site-packages (from
> pyppeteer>=0.0.14->requests_html) (4.62.3)
> Requirement already satisfied: urllib3<2.0.0,>=1.25.8 in
> /usr/local/lib/python3.8/site-packages (from
> pyppeteer>=0.0.14->requests_html) (1.26.6)
> Collecting appdirs<2.0.0,>=1.4.3
>Using cached appdirs-1.4.4-py2.py3-none-any.whl (9.6 kB)
> Collecting importlib-metadata>=1.4
>Using cached importlib_metadata-4.8.1-py3-none-any.whl (17 kB)
> Requirement already satisfied: pyee<9.0.0,>=8.1.0 in
> /usr/local/lib/python3.8/site-packages (from
> pyppeteer>=0.0.14->requests_html) (8.2.2)
> Requirement already satisfied: websockets<10.0,>=9.1 in
> /usr/local/lib/python3.8/site-packages (from
> pyppeteer>=0.0.14->requests_html) (9.1)
> Requirement already satisfied: zipp>=0.5 in
> /usr/local/lib/python3.8/site-packages (from
> importlib-metadata>=1.4->pyppeteer>=0.0.14->requests_html) ( 3.5.0)
> Requirement already satisfied: beautifulsoup4 in
> /usr/local/lib/python3.8/site-packages (from bs4->requests_html) (4.10.0)
> Requirement already satisfied: soupsieve>1.2 in
> /usr/local/lib/python3.8/site-packages (from
> beautifulsoup4->bs4->requests_html) (2.2.1)
> Collecting cssselect>0.7.9
>Using cached cssselect-1.1.0-py2.py3-none-any.whl (16 kB)
> Collecting lxml>=2.1
>Using cached lxml-4.6.3.tar.gz (3.2 MB)
> Collecting idna<4,>=2.5
>Using cached idna-3.2-py3-none-any.whl (59 kB)
> Collecting certifi>=2017.4.17
>Using cached certifi-2021.5.30-py2.py3-none-any.whl (145 kB)
> Collecting 

Re: META: Fix the signup procedure?

[Russell VT via Cygwin]

On Thu, Aug 12, 2021 at 12:43 AM Sam Edge via Cygwin 
wrote:

> On 12/08/2021 08:18, Russell VT via Cygwin wrote:
>
>  > I've seen teamseasily
>  > handle higher traffic lists with a pretty small moderation team.
>
> Sounds like an offer to me. Thanks Russell. ;-)
>

LMAO...  Sorry, ummm... /gulp.  No, thank you? LOL

I think you also "missed" (/s) the quote where I said I couldn't blame our
awesome hosts, here, for NOT wanting to spend their entire lives fiddling
around with a stupid-but-necessary mailing list.

That said, this place is STILL more-helpful than Reddit. ;-)

Cheers!
RVT

-- 
Russell M. Van Tassell 

-- 
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: META: Fix the signup procedure?

[Russell VT via Cygwin]

On Wed, Aug 11, 2021 at 10:24 PM Christopher Faylor <
cgf-use-the-mailinglist-ple...@cygwin.com> wrote:

> On Wed, Aug 11, 2021 at 04:26:18AM -0700, Russell VT wrote:
> >Can one of you powerful folks, please, fix the signup approvals and
> >make it a bit more difficult to signup and account that is "allowed" to
> >post on this list?
>
> The cygwin list has been open for around 23 years or so.


Indeed... this is a crucial point, actually.


> Making the
> list subscriber-only (which seems to be what you're asking for) raises
> the barrier to asking questions and impedes the purpose of a "help"
> mailing list.


I was actually talking maybe "one-step-over" subscriber-only (going back to
the general Majordomo premise of "anyone can subscribe/unsubscribe anyone,
with enough ingenuity and desire. So, being "on" the list isn't really a
factor, in that it's trivial to spoof all the "important" sides of the
conversation.

That said, GIVEN the age of this mailing list, with "a well-known name and
a long history," there's probably not a single public advertised email
address, at such an old and well-known domain, that isn't literally
pummeled with SPAM, daily. It's already remarkable how little spam we see
here... so, there's clearly *more* happening here.

In short, spammers scripts are likely "figuring out" how to bypass the
signup features on the older Mailman Python scripts, and are getting around
the captchas or whatever else is in-place on this "not-too-terribly-old"
version.

FWIW, I've also been noticing more form-spam, lately, that's managed to get
through a couple of my own sites. So, time to make things session based,
and multiple interlaced pages (also, those are amusing logs to monitor...
but, I digress).



> Moderation is an option but I doubt anyone really wants
> to moderate every message here.
>

Can't say I would disagree, though back it the time, I've seen teams easily
handle higher traffic lists with a pretty small moderation team.


>
> cgf
> -- cygwin.com/sourceware.org administrator
>
>

-- 
Russell M. Van Tassell 

-- 
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: META: Fix the signup procedure?

[Russell VT via Cygwin]

Holy over-quote, batman!

On Wed, Aug 11, 2021 at 4:37 AM Brian S. Wilson via Cygwin <
cygwin@cygwin.com> wrote:

> As a long time user I would oppose an "age" related test to invalidate
>
emails.  Long time users are less likely to be spammers than new email
> sign ups.


That's kind of... the point??? Extending the required account age increases
the "cost" of trying to use that account for spam by several magnitudes of
"cost." If they have to create a new account, and wait a week prior to
posting... that's going to decrease the number of spambots.

It's detrimental, in that any one "worthy" of decidedly running Cygwin on
any platform, likely has the wherewithal to have done their initial
research, prior to checking with the list. So, it naturally increases their
overall time. prior to being able to seek an adequate solution.

Either that, or you turn on every-post-moderation ... or, "only approved
senders" - but that is an enormous request/offload to the mod team, here.

That said, it does seem that we are getting quite a bit of
> spam from the Cygwin email list and it would be nice if something along
> the lines of email verification could be done to prevent this.
>

And, *that's what I originally said*... /sighs

Currently the list is running Mailman version 2.1.29 (2018-07-24)
 ... that's "eons" in
Internet Time (tm). The latest in the 2.1 timeline is v.2.1.34 (2020-06-27)
 with 2.1.35 receiving
active maintenance commits. There's a new major release (3.0), though like
most-things GNU, it's still not in stable-release mode... that said,
there's already a Version 3.1
 branch,
in alpha/pre-alpha).

Point being, there are plenty of things that can be done to "fix" this sort
of thing... but, we are at the mercy of the list admins, or listserv owners
for those sorts of fixes.

But, IIRC, email verification has been in the mailman configuration
options, pretty much since Majordomo owned the vast majority of public
mailing lists. ;-)

Cheers -
RVT

-- 
Russell M. Van Tassell 

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

META: Fix the signup procedure?

[Russell VT via Cygwin]

List Admins -

Can one of you powerful folks, please, fix the signup approvals and make it
a bit more difficult to signup and account that is "allowed" to post on
this list?

Generally, it's at least an email verification loop. But, maybe it's time
to induce an "age" as well? That said, I will concede that it unfairly
targets those folks who need legitimate help, for a current or new problem
that may have escaped regression checks, or general tool obscurity.

Regards,
Russell VT
grey beard

-- 
Russell M. Van Tassell 

-- 
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: virtualenv 20.2.2-1 dependencies: filelock and distlib

[Russell VT via Cygwin]

Well, it's been a hot minute since I've used virtualenv, by itself... but,
generally you're going to want to use "mkvirtualenv" and related tools to
create and then access your Python libraries (often under the
projects 'venv' directory).Your mileage may vary, trying to invoke it
directly from the command line with a module argument.

Myself, I tend to like to distance my Python environments from the
Operating System version(s)... and I use pyenv
 with pyenv-virtualenv
, and then provided I have a
decent compiler environment, you can install Python from distribution
(though, full disclosure and in all fairness, I've had a few issues with
non-standard directory locations for things like ffi/cffi (IIRC), when
compiling newer Python versions (though I've not checked, recently).

Hope that helps in some way.



On Mon, Aug 9, 2021 at 9:38 AM Friedrich Romstedt via Cygwin <
cygwin@cygwin.com> wrote:

> Hi there,
>
> This is about a small issue I ran into with using virtualenv-20.2.2-1
> (package name python38-virtualenv) with Python 3.8.10 (package
> python38) in Cygwin (64-bit).
>
> After having installed python38-virtualenv (and its automatically
> picked dependencies), using virtualenv by:
>
> $ python -m virtualenv 
>
> presented me the output attached as file [a02.txt]. "filelock" is a
> Python package, part of the cygwin package database. Having installed
> it, the same command as above yielded [a03.txt] (attached); there was
> no more output. Having treated the package "distlib" mentioned there
> the same way as "filelock", creating a virtual environment now
> succeeds.
>
> I did some googling:
>
> site:sourceware.org/pipermail/cygwin virtualenv filelock
>
> virtualenv filelock cygwin
>
> without substantial results; thus posting here.
>
> Judging from [a02.txt], "filelock" is a *direct* dependency of
> "virtualenv".  I do not know if the same holds for "distlib".
>
> Since I feel that this is a pretty obvious result I am skipping the
> "cygcheck -svr" output here.
>
> Best,
> Friedrich
>
> --
> 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
>


-- 
Russell M. Van Tassell 

-- 
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: Incorrect expansion of a program argument that is a special character?

[Russell VT via Cygwin]

Note that Powershell and BASH wildcard (globbing) may be notably different,
which includes how items may be "escaped" to prevent such globbing
operations.

Moreover, in a UN*X shell, it is generally thought that it's the user's
responsibility to declare how how file expansion should work, generally
defaulting to the "one or more" presence (where true regular expressions
use an asterisk as "zero or more"). In this way, shells and general regular
expressions may differ.

TLDR; In any environment, "arguments" are different between the command
line, and the program itself.

Basically, you need to understand how any given shell will pass arguments
to your program, and that exercise is generally outside of general
executable-type discussion (ie. it is almost a "religious war" as to how
various shells may process arguments, regular expressions, or wildcards ...
along with what options a user may specify to change the behaviour)

Do you have an example of where the program functions as-expected, along
with examples as to how the identical binary functions differently in
other environments?

Hope that lights a few lightbulbs for ya!

Russell VT


On Wed, Jul 21, 2021 at 4:44 AM Ev Drikos via Cygwin 
wrote:

> Hello,
>
> When I run the program below from my home directory in a PowerShell
> Console (Windows 8-1) I've to use an extra backslash character as
> shown below or the star is expanded. Which happens only when the
> program has been compiled in Cygwin.
>
> Is this a bug or a known feature?
>
> Ev. Drikos
>
> --
> PS C:\Users\suser> .\args.exe '\*'
>
> *
> argc=1
> PS C:\Users\suser>
> --
>
> #include 
> int main(int argc, char *argv[]){
> int i;
> for (i=1; i < argc; i++) {
>   printf("\n%s",argv[i]);
> }//for
>  printf("\nargc=%d\n",argc-1);
> return 0;
> }
>
> --
> 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
>


-- 
Russell M. Van Tassell 

-- 
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: Debugging PHP with GDB and php-debuginfo

[Russell VT via Cygwin]

There's the "Magic Method" in PHP for __debuginfo()
.

Also see PHP RFC: __debugInfo() .

You may have better luck asking the PHP devs how to best use this with GDB,
or the GDB folks how to use the extension.

Hope that helps!

Russell VT


On Tue, Jul 20, 2021 at 3:55 PM Jim Hyslop  wrote:

> Hi, all
>
> I've installed the php-debuginfo extension for gdb, but I can't figure
> out how to set a breakpoint with it. Is there a manual for
> php-debuginfo? All I can find is the package information.
>
> I'm trying to debug why a unit test is passing (it should fail). I'm
> using the CakePHP framework (www.cakephp.org). From the command line, I
> normally just execute `vendor/bin/phpunit`.
>
> With gdb, I execute `gdb $(which php)`, then at the command line in GDB
> I type ` b ./tests/TestCase/Controller/UsersControllerTest.php:80`
>
> GDB responds with:
> No source file named
> ./tests/TestCase/Controller/UsersControllerTest.php.
> Make breakpoint pending on future shared library load? (y or [n])
>
> The file name is valid. I've tried using the full path instead of the
> relative path.
>
> When I run the tests with `r vendor/bin/phpunit` the unit tests all
> execute, but GDB doesn't stop at the breakpoint.
>
> Do I need to modify php.ini to use gdb? Any pointers?
>
> --
> Jim Hyslop
>
> --
> 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
>


-- 
Russell M. Van Tassell 

-- 
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: bug in cygwin tar reading unexpected input(s)...

[Russell VT via Cygwin]

Replay by from my phone, so it's a bit brief...

Try opening a Cygwin terminal AS administrator, making sure it gives you
the "process may modify the system" warning dialog, etc... Then repeat

If it works, or complains less, then the problem is permissions at *some*
level.

Despite Windows having "administrator" type groups, they are STILL
protected parts of the filesystem, etc. There will be fewer protections by
using the "system" account, etc.

WARNING: Using this account MAY produce irreparable harm to the system. Do
this at your own risk.

-- 
Russell M. Van Tassell
russel...@gmail.com

This message was sent from my wireless handheld device.

On Tue, Jun 15, 2021, 14:14 L A Walsh  wrote:

>
>
> On 2021/06/15 00:16, Russell VT wrote:
> > I think we need more context, here... as what does Windows versus Cygwin
> > think those permissions are...???
> ---
> Which permissions?  The error is 'no such object', not
> 'access denied'.  I believe it is similar to trying to read (or
> modify) xattr's or acl's on linux symlinks.
>
> >
> > Are you running your terminal, as you... or did you run it as
> Administrator?
> ---
> I am in group Administrators as well as Domain Admins
> (Samba Domain).  Domain Admins and System are both in the
> local Administrators group.
>
>
> > Have you run an update, and not rebooted?
> ---
> I don't believe so at that time, but I have rebooted since then.
> The problem only occurred on files that were symlinks as seen by Windows
> and Cygwin.
> >
> > There should be some "basic shell debugging" done here, first...
> ---
> I'm not sure what you mean.  Oops, I forgot to list the
> command line, but thought that "--xattrs" might be implied from the
> fact that the error was about retrieving xattrs.
>
> Cmdline was using shell script calling a function, "backup_dir"
> with "ProgramData" from the root directory, where the function was:
>
> backup_dir() {
>   my DIR=${1:?}
>   tar c --acls --xattrs --sparse -b 2048 --one-file-system "$DIR" |
> dd bs=1M iflag=fullblock of="/b/June_backups/$DIR" oflag=nonblock
> }
>
>
> > since
> > there's a disconnect from when tar gets its file list, and when it
> > physically goes to retrieve a (possibly temporary) file. It will also
> > complain about directories it can read, but not access.
> ---
> Those were symlinks, not directories.
> > So, it would be
> > better to figure out what the "difference" is between what you expect,
> > and what actually happened with the tar.
> ---
> I would expect it might not complain about not being
> able to read xattr's on symlinks?  I don't think it complains about
> not being able to read them on linux -- or at least I've never seen
> such.
>
> > Unfortunately, permission issues between Windows and Cygwin can be
> > */extremely/* complex (ie. there are a ton of details missing here,
> > which might make it easier to help troubleshoot).
> ---
> What necessary details are missing?
>
> >
> > Hope that helps point you in a good direction.
> ---
> Not sure. I thought I was reporting a bug in cygwin tar
> giving an error about trying to read xattrs on symlinks, as I don't
> believe it gives an error on linux doing the same thing.  Does it?
> Thanks for your questions, but I'm still not very clear on what
> I left out.
>
> I'd tend to ignore the error on what appeared to be
> a misspelled filename, as I'm not even sure how to recreate
> that file, but attempting to dump xattrs on a symlink seems like
> a pretty straight forward symptom/testcase.  What more details
> do you think would be pertinent?
>
> Thanks!
> -Linda
>
>
> >
> > Cheers!
> > Russell VT
> >
> > On Mon, Jun 14, 2021 at 9:22 PM L A Walsh  > > wrote:
> >
> > Tar'ing up a windows dir (ProgData) had some unexected failures:
> >
> > Several of the sort:
> >
> > tar: Dbgview: Warning: Cannot llistxattrat: No such file or directory
> > tar: Desktops: Warning: Cannot llistxattrat: No such file or
> directory
> > tar: DiskView: Warning: Cannot llistxattrat: No such file or
> directory
> > tar: LoadOrd: Warning: Cannot llistxattrat: No such file or directory
> > tar: portmon: Warning: Cannot llistxattrat: No such file or directory
> >
> > Where the item listed (Dbgview, DiskView, etc) is a
> > windows symlink like:
> >
> > 2019/02/07  22:53  Dbgview [SI\Dbgview.exe]
> > 2019/02/07  22:53  Desktops [SI\Desktops.exe]
> > 2019/02/07  22:53  DiskView [SI\DiskView.exe]
> >
> > and stems from the use of the --xattrs switch.
> >
> > Win7SP1x64
> > cygcheck (cygwin) 3.2.0
> >
> > The tar continued and finished much as it would after an unreadable
> > file.
> >
> > Another error, maybe similar,
> >
> >
> > tar: C\:Prog64FastPictureViewer: Warning: Cannot file_has_acl_at: No
> > such file or directory
> >
> >  From a file in "C:\Program Files\FastPictureViewer" 

Re: bug in cygwin tar reading unexpected input(s)...

[Russell VT via Cygwin]

I think we need more context, here... as what does Windows versus Cygwin
think those permissions are...???

Are you running your terminal, as you... or did you run it as Administrator?

Have you run an update, and not rebooted?

There should be some "basic shell debugging" done here, first... since
there's a disconnect from when tar gets its file list, and when it
physically goes to retrieve a (possibly temporary) file. It will also
complain about directories it can read, but not access. So, it would be
better to figure out what the "difference" is between what you expect, and
what actually happened with the tar.

Unfortunately, permission issues between Windows and Cygwin can be
*extremely* complex (ie. there are a ton of details missing here, which
might make it easier to help troubleshoot).

Hope that helps point you in a good direction.

Cheers!
Russell VT

On Mon, Jun 14, 2021 at 9:22 PM L A Walsh  wrote:

> Tar'ing up a windows dir (ProgData) had some unexected failures:
>
> Several of the sort:
>
> tar: Dbgview: Warning: Cannot llistxattrat: No such file or directory
> tar: Desktops: Warning: Cannot llistxattrat: No such file or directory
> tar: DiskView: Warning: Cannot llistxattrat: No such file or directory
> tar: LoadOrd: Warning: Cannot llistxattrat: No such file or directory
> tar: portmon: Warning: Cannot llistxattrat: No such file or directory
>
> Where the item listed (Dbgview, DiskView, etc) is a
> windows symlink like:
>
> 2019/02/07  22:53  Dbgview [SI\Dbgview.exe]
> 2019/02/07  22:53  Desktops [SI\Desktops.exe]
> 2019/02/07  22:53  DiskView [SI\DiskView.exe]
>
> and stems from the use of the --xattrs switch.
>
> Win7SP1x64
> cygcheck (cygwin) 3.2.0
>
> The tar continued and finished much as it would after an unreadable file.
>
> Another error, maybe similar,
>
>
> tar: C\:Prog64FastPictureViewer: Warning: Cannot file_has_acl_at: No
> such file or directory
>
>  From a file in "C:\Program Files\FastPictureViewer" [likely mis-]named
> "C:Prog64FastPictureViewer"
>
> It seems to be a .dll, that somehow got its name mangled.
>
> Not sure what it was trying to do, but the file seems to be 'in-use'.
>
>
>
>
> --
> 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
>


-- 
Russell M. Van Tassell 

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

[Russell VT via Cygwin]

Quick search on find_fast_cwd leads here...

https://stackoverflow.com/questions/22821467/cygwin-win-8-1-error-find-fast-cwd-warning-couldnt-compute-fast-cwd-pointer

When was the last time you updated Cygwin? What version of Windows are you
running? What version of Cygwin? More details would be helpful...



On Tue, Jun 8, 2021 at 6:30 PM Serendipity via Cygwin 
wrote:

> 3 [main] cpnmld.x86-cygwin 4556 find_fast_cwd: WARNING: Couldn't compute
> FAST_CWD pointer. Please report this problem to
> the public mailing list cygwin@cygwin.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
>


-- 
Russell M. Van Tassell 

-- 
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: Python for Windows reports wrong local time when run under Cygwin on Europe/Moscow TZ

[Russell VT via Cygwin]

What version(s) of the timezone files are installed on each?

Also, seems one of the Python versions came from Windows, rather than
Cygwin?



On Mon, Jun 7, 2021 at 12:01 AM Mike Kaganski via Cygwin 
wrote:

> Hello,
>
> Running Cygwin 3.1.7-1 on Windows 10 Version 21H1 (OS Build 19043.985),
> I have this issue:
>
> when I start Cygwin's Python, I have correct time reported:
>
> > mikek@DESKTOP-8SHAE9Q ~
> > $ python
> > Python 3.8.9 (default, Apr 21 2021, 23:14:29)
> > [GCC 10.2.0] on cygwin
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import datetime
> > >>> datetime.datetime.now()
> > datetime.datetime(2021, 6, 7, 9, 40, 15, 318391)
>
> But running Python for Windows (it doesn't matter which, specifically
> for the test I used the one from MS Store [1]), I have incorrect local
> time:
>
> > mikek@DESKTOP-8SHAE9Q ~
> > $ "C:/Program
> >
> Files/WindowsApps/PythonSoftwareFoundation.Python.3.8_3.8.2800.0_x64__qbz5n2kfra8p0/python3.8.exe"
> > Python 3.8.10 (tags/v3.8.10:3d8993a, May  3 2021, 11:48:03) [MSC
> > v.1928 64 bit (AMD64)] on win32
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import datetime
> > >>> datetime.datetime.now()
> > datetime.datetime(2021, 6, 7, 7, 40, 55, 503775)
>
> Note how the latter output reports 2021-06-07 07:40, while the former
> reports 2021-06-07 09:40. The difference is 2 hours.
>
> Starting the same Python for Windows from cmd.exe has it correct:
>
> > C:\Users\mikek>python
> > Python 3.8.10 (tags/v3.8.10:3d8993a, May  3 2021, 11:48:03) [MSC
> > v.1928 64 bit (AMD64)] on win32
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import datetime
> > >>> datetime.datetime.now()
> > datetime.datetime(2021, 6, 7, 9, 41, 21, 925240)
>
> Cygwin reports correct timezone:
>
> > $ echo $TZ
> > Europe/Moscow
>
> Starting Python for Windows using a different timezone (specifically, '$
> TZ=UTC "C:/Program
> Files/WindowsApps/PythonSoftwareFoundation.Python.3.8_3.8.2800.0_x64__qbz5n2kfra8p0/python3.8.exe"')
>
> gives correct time for *that* time zone.
>
> This is a problem, because in our project (LibreOffice), we use Cygwin
> as environment for unit testing, where LibreOffice's own Python (also
> built natively for Windows) is used, and at some times (from 00:00 till
> 02:00) it reports wrong dates, which makes tests fail locally on
> affected systems(see [2]).
>
> Thank you!
>
>
> [1] https://www.microsoft.com/en-us/p/python-38/9mssztt1n39l
>
> [2]
>
> https://gerrit.libreoffice.org/c/core/+/92217/2#message-f55091795e7cde9d75adc00ddb69451121b644f6
>
>
> --
>
> Best regards,
>
> Mike Kaganski
>
>
> --
> 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
>


-- 
Russell M. Van Tassell 

-- 
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: Cygwin now on Python 3? What about Mercurial?

[Russell VT via Cygwin]

On Thu, Mar 4, 2021 at 8:39 AM Ken Brown via Cygwin 
wrote:

> On 3/4/2021 6:05 AM, marco atzeri via Cygwin wrote:
> > On Thu, Mar 4, 2021 at 10:27 AM Russell VT via Cygwin  wrote:
> >> Cygwin Enthusiasts!
> >
> > It seems the current package maintainer for Mercurial is not available
> for
> > the upgrade from 2.7 to 3.8.
> > We need to decide how to proceed
>
> The Mercurial maintainer (Jari) doesn't always follow the mailing list.
> I've
> added him to the CC.
>

Thanks Ken!

In the meantime, I'll  take a look at the Package Contributors' Guide, as
was suggested by another... and maybe I can hell fill in some blocks with
some of my own resources.

Cheers!
Russell VT

-- 
Russell M. Van Tassell 
--
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

Cygwin now on Python 3? What about Mercurial?

[Russell VT via Cygwin]

Cygwin Enthusiasts!

Well, I was going to hold back on this one, but having now watched the list
for a bit, I think this is a fair question (feel free to smack me if I'm
feeling too entitled, albeit maybe a bit on the rambling side).

TLDR; Cygwin 64 Mercurial (5.5.1) blows chunks with default Python install.
I'm still not sure if this is a package dependency error, given the recent
Python 2.7 Deprecation "worldwide," or the way that Mercurial is packaged,
or even if the package installation order on-down the line screwed me up at
some point in the past.

TLDR2; Am I really the "only" one on Cygwin still using Mercurial in a
Complex Python Environment?

Here;s my primary operating environment, devoid of whatever tricks I may
try to play with Python Development environments (read: Path to /usr/bin
with no funny stuff getting in the way)
.

Cygwin: CYGWIN_NT-10.0 3.17(0.340/5/3) 2020-08-22 17:48 x86_64
Python: 3.8.7
Python2: 2.7.18
Python3: 3.8.7

$ ls -1 /usr/bin/python[0-9\.]*

/usr/bin/python2@

/usr/bin/python2.7.exe*

/usr/bin/python3@

/usr/bin/python3-config@

/usr/bin/python3.5@

/usr/bin/python3.5m.exe*

/usr/bin/python3.6@

/usr/bin/python3.6-config@

/usr/bin/python3.6m-config*

/usr/bin/python3.6m.exe*

/usr/bin/python3.7@

/usr/bin/python3.7m.exe*

/usr/bin/python3.8-config*

/usr/bin/python3.8.exe*



Now, running mercurial (hg) with no real options, trying to let python just
use the meta version (3.8.7), and it starts to break with JSONDecoder
issues.

ImportError: cannot import name 'JSONDecodeError'

Of course, Mercurial is also *evil*, and embeds annoying pieces of code,
like the following...
 (pretty much making my "fix" necessary - potentially intentional, to make
people fix their mercurial package prior to the end of the year, as well)

>> libdir = '../lib/python2.7/site-packages'

...and REALLY hates pylint/pyflakes (in case your vim editor hates-on your
non PEP-8 code as much as mine is set to do.

So, with all that in-mind, here is whatt I summarize:

*Fixes and Workarounds:*
Update /etc/alternatives to point at Python2 (Bad Idea! No no no!)
Update Mercurial to specify /usr/bin/python2 to "stay behind" (Well, "it
works")
 . But, I think "the default" is that it should work... which either means
updating Python

So, digging deeper, and correct me if I'm wrong... but iott looks like the
meta version of Python on Cygwin is now at Python3, which is a good thing.
But with Mercurial depending on the meta Python, rather than sticking
themselves on Python2 (since the JSON import blows). So, the current
Mercurial seems to be 5.5.1 on Cygwin x86_64... which is only a short time
behind. But that's pretty easy, right?

Or to channel my BOFH persona (only because it's already the third month
following a long anticipated date), the Python 2 deprecation wasn't loud
enough for everyone? And now we're only two revisions behind (one major and
one bug fix)... though did Mercurial ever "force" Python 3, or at least get
"sensitive" to it?

So, I understand... that's a LONG way to go to ask all of y'all, how do we
fix this thing? Can someone point me at a good reference to being a Cygwin
contributor, to the point that I can actually help move some things along,
like this, rather than bitching to all y'all about getting it fixed? (Read:
Can I compile this myself, and submit it back to chief stakeholders so that
they may publish a new package? I'm "git" and "devops" fluent, though my C
and its close relatives are on the weak-side, these days - one of
the reasons I want good Python environments!)

Cheers!
Russell VT

-- 
Russell M. Van Tassell 
--
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