Re: [ANNOUNCEMENT] sshfs 3.7.2-1
Thomas Wolff wrote: Am 04.04.2022 um 01:20 schrieb Mark Geisert: [...] A couple of things. Windows differs from Unix/Linux (yet again!) in that directories mounted upon cannot exist beforehand. So if you rmdir servmount, sshfs 192.168.178.75: servmount ought to succeed, but instead you will get "read: Software caused connection abort", so supply a username@hostname and it should work. The abort is some sort of problem with sshfs which I'll investigate. On my machine, sshfs mark@m0: /mnt/servmount works fine. Yes, that works. Thank you, great feature. Maybe another interactive hint in this case would help. man sshfs? sshfs --help? Both are present already :-) (Though the latter has badly formatted WinFSP info.. that's an issue for upstream.) ..mark -- 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: [ANNOUNCEMENT] sshfs 3.7.2-1
Am 04.04.2022 um 01:20 schrieb Mark Geisert: Hi Thomas, Thomas Wolff wrote: Am 03.04.2022 um 08:48 schrieb Mark Geisert: The following package has been uploaded to the Cygwin distribution: * sshfs-3.7.2-1 This is a port of the reference version of sshfs. It allows access to local or remote file folders via an ssh (more precisely, sftp) connection. The folder appears as a local folder on the user's system. Sshfs requires cygfuse and a Windows FUSE provider to function. Please send questions or concerns to the main Cygwin mailing list as usual. Thanks for building this package. You're welcome. Thank YOU for your patience. cygfuse: initialization failed: winfsp-x64.dll not found I suggest to add a hint to WinFSP installation to this message. I had thought the hint on the cygfuse announcement was enough :-) But no trouble to add it on any FUSE apps that are ported. Thanks. Then: /mnt> mkdir servmount /mnt> sshfs 192.168.178.75: servmount Cannot create WinFsp-FUSE file system: mount point in use. /mnt> it fails to mount. A couple of things. Windows differs from Unix/Linux (yet again!) in that directories mounted upon cannot exist beforehand. So if you rmdir servmount, sshfs 192.168.178.75: servmount ought to succeed, but instead you will get "read: Software caused connection abort", so supply a username@hostname and it should work. The abort is some sort of problem with sshfs which I'll investigate. On my machine, sshfs mark@m0: /mnt/servmount works fine. Yes, that works. Thank you, great feature. Maybe another interactive hint in this case would help. Thomas -- 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: [ANNOUNCEMENT] sshfs 3.7.2-1
Hi Thomas, Thomas Wolff wrote: Am 03.04.2022 um 08:48 schrieb Mark Geisert: The following package has been uploaded to the Cygwin distribution: * sshfs-3.7.2-1 This is a port of the reference version of sshfs. It allows access to local or remote file folders via an ssh (more precisely, sftp) connection. The folder appears as a local folder on the user's system. Sshfs requires cygfuse and a Windows FUSE provider to function. Please send questions or concerns to the main Cygwin mailing list as usual. Thanks for building this package. You're welcome. Thank YOU for your patience. cygfuse: initialization failed: winfsp-x64.dll not found I suggest to add a hint to WinFSP installation to this message. I had thought the hint on the cygfuse announcement was enough :-) But no trouble to add it on any FUSE apps that are ported. Thanks. Then: /mnt> mkdir servmount /mnt> sshfs 192.168.178.75: servmount Cannot create WinFsp-FUSE file system: mount point in use. /mnt> it fails to mount. A couple of things. Windows differs from Unix/Linux (yet again!) in that directories mounted upon cannot exist beforehand. So if you rmdir servmount, sshfs 192.168.178.75: servmount ought to succeed, but instead you will get "read: Software caused connection abort", so supply a username@hostname and it should work. The abort is some sort of problem with sshfs which I'll investigate. On my machine, sshfs mark@m0: /mnt/servmount works fine. ..mark -- 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] Updated: Perl distributions
The following Perl distributions have been updated to their latest release version available on CPAN: x86/x86_64 -- perl-HTML-Parser-3.78-1 noarch -- perl-Mojolicious-9.23-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: 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] Re: OpenSSH 8.9p1-1 Connects successfully but then hangs - Killing ssh-agent resolves the issue
On 4/3/2022 9:50 AM, Henry S. Thompson wrote: Jason Pyeron writes: -Original Message- From: Henry S. Thompson Sent: Friday, April 1, 2022 5:21 AM Jim Garrison via Cygwin writes: My Cygwin ssh client stopped working... It would successfully connect to ... There are reports out there of ssh-agent getting stuck: just out of curiousity if this happens again, check to see if ssh-agent is using 100% of a CPU. If so then search for "ssh-agent" "100% CPU" to see I did not find much with that search. I found https://cygwin.com/pipermail/cygwin/2010-January/183237.html but the issue description and resolution was useless. Do you have certain search results in mind? This happens to me several times a month - on multiple systems. Note this started within the past 3 years. There are three distinct groups of possibly relevant threads, to do with interactions between ssh-agent and one of ServerTree [no idea what that is] GitHub gnome-keyring-daemon Also, if (my own case), I use gpg-agent maskerading as ssh-agent, and _it_ has the 100% problem sometimes. Of course, none of this is relevant if the OP's problem with ssh is not co-occuring with ssh-agent chewing up an entire processor. The problem has not recurred (yet) so I don't know if ssh-agent was at 100% CPU. All I know at this point is that ssh-agent is *definitely* involved because killing that process restored ssh functionality. I.e. before killing ssh-agent: ssh connects but no prompt is displayed after killing ssh-agent: ssh connects and operates normally -- Jim Garrison -- 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: Problems with python3 pip
On 2022-03-28 09:36, Chad Dougherty wrote: It seems to me like the ensurepip module has some problems. Shouldn't the following be working? $ cygcheck -c -d|grep python3 python3 3.9.10-1 python3-devel 3.9.10-1 python39 3.9.10-1 python39-devel 3.9.10-1 python39-pip 21.3.1-3 python39-setuptools 59.5.0-1 $ type python3.9 python3.9 is hashed (/usr/bin/python3.9) $ type pip3.9 pip3.9 is hashed (/usr/bin/pip3.9) $ pip3.9 --version pip 21.3.1 from /usr/lib/python3.9/site-packages/pip (python 3.9) $ pip3.9 list Package Version -- --- pip 21.3.1 setuptools 59.5.0 WARNING: You are using pip version 21.3.1; however, version 22.0.4 is available. You should consider upgrading via the '/usr/bin/python3.9.exe -m pip install --upgrade pip' command. $ python3.9 -m ensurepip Traceback (most recent call last): File "/usr/lib/python3.9/runpy.py", line 188, in _run_module_as_main mod_name, mod_spec, code = _get_module_details(mod_name, _Error) File "/usr/lib/python3.9/runpy.py", line 147, in _get_module_details return _get_module_details(pkg_main_name, error) File "/usr/lib/python3.9/runpy.py", line 111, in _get_module_details __import__(pkg_name) File "/usr/lib/python3.9/ensurepip/__init__.py", line 30, in _SETUPTOOLS_VERSION = _get_most_recent_wheel_version("setuptools") File "/usr/lib/python3.9/ensurepip/__init__.py", line 27, in _get_most_recent_wheel_version return str(max(_wheels[pkg], key=distutils.version.LooseVersion)) ValueError: max() arg is an empty sequence $ python3.9 -m ensurepip --user Traceback (most recent call last): File "/usr/lib/python3.9/runpy.py", line 188, in _run_module_as_main mod_name, mod_spec, code = _get_module_details(mod_name, _Error) File "/usr/lib/python3.9/runpy.py", line 147, in _get_module_details return _get_module_details(pkg_main_name, error) File "/usr/lib/python3.9/runpy.py", line 111, in _get_module_details __import__(pkg_name) File "/usr/lib/python3.9/ensurepip/__init__.py", line 30, in _SETUPTOOLS_VERSION = _get_most_recent_wheel_version("setuptools") File "/usr/lib/python3.9/ensurepip/__init__.py", line 27, in _get_most_recent_wheel_version return str(max(_wheels[pkg], key=distutils.version.LooseVersion)) ValueError: max() arg is an empty sequence $ This causes the failure of "-m venv", which is what I ultimately want to do: $ python3.9 -m venv /home/crd/testvenv Error: Command '['/home/crd/testvenv/bin/python3.9.exe', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1. I also tried python38 and had similar problems. Thanks... The problem appears to be that the python-pip-wheel and python-setuptools-wheel packages were not installed on my system. Apparently they were a requirement for the python35 packages but that requirement was removed in python36 and later. At some point in the past when I removed python35, I was also able to remove python-pip-wheel and python-setuptools-wheel which got me into this problem. After reinstalling python-pip-wheel and python-setuptools-wheel, ensurepip and venv are both working from python39. It seems to me like python-pip-wheel and python-setuptools-wheel should probably be re-added as dependencies for newer python3 packages. Thanks... -- -Chad -- 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] Re: OpenSSH 8.9p1-1 Connects successfully but then hangs - Killing ssh-agent resolves the issue
Jason Pyeron writes: >> -Original Message- >> From: Henry S. Thompson >> Sent: Friday, April 1, 2022 5:21 AM >> >> Jim Garrison via Cygwin writes: >> >> > My Cygwin ssh client stopped working... It would successfully connect to >> > ... >> There are reports out there of ssh-agent getting stuck: just out of >> curiousity if this happens again, check to see if ssh-agent is using >> 100% of a CPU. If so then search for "ssh-agent" "100% CPU" to see > I did not find much with that search. I found > https://cygwin.com/pipermail/cygwin/2010-January/183237.html but the > issue description and resolution was useless. > > Do you have certain search results in mind? This happens to me > several times a month - on multiple systems. Note this started > within the past 3 years. There are three distinct groups of possibly relevant threads, to do with interactions between ssh-agent and one of ServerTree [no idea what that is] GitHub gnome-keyring-daemon Also, if (my own case), I use gpg-agent maskerading as ssh-agent, and _it_ has the 100% problem sometimes. Of course, none of this is relevant if the OP's problem with ssh is not co-occuring with ssh-agent chewing up an entire processor. 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
RE: [cygwin] Re: OpenSSH 8.9p1-1 Connects successfully but then hangs - Killing ssh-agent resolves the issue
> -Original Message- > From: Henry S. Thompson > Sent: Friday, April 1, 2022 5:21 AM > > Jim Garrison via Cygwin writes: > > > My Cygwin ssh client stopped working... It would successfully connect to > > the remote (Debian) host but then hang without displaying the command > > prompt. See debug output attached, as well as cygcheck output. > > > > I decided to run setup to see if there was a newer version of openssh. > > In preparation for that I always terminate all Cygwin processes because > > they will interfere with the update. I killed the ssh-agent process and > > on a whim decided to try connecting again. This time it worked. > > > > This would seem to indicate something in ssh-agent is interfering with > > the connection. There are no credentials loaded into ssh-agent. > > There are reports out there of ssh-agent getting stuck: just out of > curiousity if this happens again, check to see if ssh-agent is using > 100% of a CPU. If so then search for "ssh-agent" "100% CPU" to see > what the likely culprits are. I did not find much with that search. I found https://cygwin.com/pipermail/cygwin/2010-January/183237.html but the issue description and resolution was useless. Do you have certain search results in mind? This happens to me several times a month - on multiple systems. Note this started within the past 3 years. -- 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: [ANNOUNCEMENT] sshfs 3.7.2-1
Am 03.04.2022 um 08:48 schrieb Mark Geisert: The following package has been uploaded to the Cygwin distribution: * sshfs-3.7.2-1 This is a port of the reference version of sshfs. It allows access to local or remote file folders via an ssh (more precisely, sftp) connection. The folder appears as a local folder on the user's system. Sshfs requires cygfuse and a Windows FUSE provider to function. Please send questions or concerns to the main Cygwin mailing list as usual. Thanks for building this package. cygfuse: initialization failed: winfsp-x64.dll not found I suggest to add a hint to WinFSP installation to this message. Then: /mnt> mkdir servmount /mnt> sshfs 192.168.178.75: servmount Cannot create WinFsp-FUSE file system: mount point in use. /mnt> it fails to mount. -- 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