Re: [ANNOUNCEMENT] tmux 3.2-0
Michael Wild via Cygwin-announce via Cygwin writes: > The following packages have been uploaded to the Cygwin distribution: > > * tmux-3.2-0 [nit] General releases should be numbered starting with 1. The mosh test suite breaks with this release (the same build tests OK again with tmux-3.1b), apparently because it is using control mode to test that zmux actually works and something seems to have changed there (the command line is 'tmux -C new-session true'). The symptom is that the whole test just hangs with absolutely no activity until I kill tmux, at which point the expected output from the control mode session does seem to appear (except with a return code of 99). Is the control mode working as intended and if yes, is there a way to get the old behaviour back that did send the output block to stdout and then terminated? Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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
realpath issue with native[strict] symlinks
I apologize for not replying to the message properly, I am not subscribed and am copy-pasting from web archive. On Sat, May 8, 2021 at 12:20 AM Corinna Vinschen wrote: > The changes have a behavioral change, but I think this is for the > better: Virtual drives are not treated as drives anymore, but as > symlinks. Given they are just pointers to other drives or directories, > tha't much closer to reality. I. e., in case of my above virtual drive > T:, what you'll see in the /cygdrive dir (unless your cygdrive prefix is > / only) is this: I am concerned about this behavior. The reason I was using subst to begin with was that some build tools encode the full path in their filenames, resulting in hitting MAX_PATH-related issues for not horribly long/deep paths. With this change, running a native Windows process (MinGW-w64) from a subst drive results in what it sees as the CWD being 'dereferenced' as though subst was not used, defeating the path-shortening purpose. For instance, using your example mapping: > $ ls -lG /cygdrive > total 16 > d---r-x---+ 1 TrustedInstaller 0 Apr 29 21:07 c > drwxr-xr-x 1 corinna 0 Dec 31 1979 e > lrwxrwxrwx 1 corinna 32 May 6 20:43 t -> > /cygdrive/c/cygwin64/home/corinna/tmp Prior to these changes would show $ cd /cygdrive/t && cmd /c cd T:\ But after these changes would show $ cd /cygdrive/t && cmd /c cd C:\cygwin64\home\corinna\tmp This path could well be long enough to trigger build issues for certain MINGW-packages. Sorry to be a nuisance... -- 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
cygport i686/x86 library build undefined type in sys/stat.h
Trying to build latest libssh2 1.9.0 using cygport, works under x86_64, but under i686/x86 fails with: In file included from */usr/i686-pc-cygwin/include/sys/stat.h*:22, from ...: /usr/include/cygwin/stat.h:27:3: error: unknown type name ‘timestruc_t’ 27 | timestruc_t st_atim; | ^~~ The equivalent include path to */usr/i686-pc-cygwin/include/sys/stat.h* does not exist under 64 bit as /usr/x86_64-pc-cygwin/include, and cygcheck -f does not come up with a hit. The only obvious work around the timeframe of these files appears to be a local test newlib-cygwin build and install for format_proc_cpuinfo and format_proc_swaps testing: $ head -v /proc/version ==> /proc/version <== CYGWIN_NT-10.0-19042-WOW64 version 3.2.1-340.i686 (...@...) (gcc version 10.2.0 (GCC) ) 2021-04-30 12:55 UTC Has anyone any idea, from seeing anything similar happen on their installs, where this directory and these files may have come from, what may have installed them, and whether it is likely to be safe to rename or remove them? -- 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 binary 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
Re: curl SFTP transfer from Cygwin on Win10 to Ubuntu 18.04 fails with Unknown host key type: 1835008
On 2021-05-13 22:40, Voris, Ben via Cygwin wrote: curl issue https://github.com/curl/curl/issues/7057 was closed with: "This seems to be purely a libssh2 issue and not a curl one." Curl reports "libssh2/1.7.0" On the same system, ssh reports " OpenSSH_8.5p1, OpenSSL 1.1.1f 31 Mar 2020" The curl code in https://github.com/curl/curl/blob/master/lib/vssh/libssh2.c has a number of defines to control what type of host keys it will accept, including LIBSSH2_KNOWNHOST_KEY_ED25519 Was the curl built with this set? Details are in the curl issue, but here they are again. Here is the curl failure: : curl -vvv -s -T t.cpp sftp://bvoris@nucnuc/tmp/t2.cpp * STATE: INIT => CONNECT handle 0x800085338; line 1634 (connection #-5000) * Added connection 0. The cache now contains 1 members * STATE: CONNECT => RESOLVING handle 0x800085338; line 1680 (connection #0) * family0 == v4, family1 == v6 * Trying 192.168.1.5:22... * STATE: RESOLVING => CONNECTING handle 0x800085338; line 1762 (connection #0) * Connected to nucnuc (192.168.1.5) port 22 (#0) * STATE: CONNECTING => PROTOCONNECT handle 0x800085338; line 1825 (connection #0) * SFTP 0x8000847c8 state change from SSH_STOP to SSH_INIT * Found host nucnuc in /home/BVoris/.ssh/known_hosts * Unknown host key type: 1835008 * SFTP 0x8000847c8 state change from SSH_INIT to SSH_SESSION_FREE * SFTP 0x8000847c8 state change from SSH_SESSION_FREE to SSH_STOP * multi_done * The cache now contains 0 members * SSH DISCONNECT starts now * SSH DISCONNECT is done * Closing connection 0 The curl/libcurl version: curl 7.76.1 (x86_64-pc-cygwin) libcurl/7.76.1 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.9 zstd/1.4.9 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.0.4) libssh2/1.7.0 nghttp2/1.37.0 Release-Date: 2021-04-14 Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS brotli Debug GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP TrackMemory UnixSockets zstd The known_hosts entry from the client: nucnuc ssh-ed25519 C3NzaC1lZDI1NTE5ICmjvQ5jehz5Jwt1PDGJBSgcXVhoMRnbn/E2p3srSK+c curl is run on CYGWIN_NT-10.0 3.2.0(0.340/5/3) 2021-03-29 08:42 x86_64 Cygwin The target system has: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 Looks like it will need libssh2 1.9.0+. The next version 1.9.1 is nearing release incorporating all the updated support as well as all CVE and other patches. I am working on a couple of build issues, with upstream, and also 32 bit x86 builds. If I can get those resolved, I could adopt libssh2 (also hosted/supported @haxx.se involving some of the same folks), releasing an update when the new libssh2 release is available, and releasing an updated curl release 2 with the updated libssh2. -- 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 binary 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
Re: cygport i686/x86 library build undefined type in sys/stat.h
On 15.05.2021 06:16, Brian Inglis wrote:
Trying to build latest libssh2 1.9.0 using cygport, works under x86_64,
but under i686/x86 fails with:
In file included from */usr/i686-pc-cygwin/include/sys/stat.h*:22,
from ...:
/usr/include/cygwin/stat.h:27:3: error: unknown type name ‘timestruc_t’
27 | timestruc_t st_atim;
| ^~~
The equivalent include path to */usr/i686-pc-cygwin/include/sys/stat.h*
does not exist under 64 bit as /usr/x86_64-pc-cygwin/include,
and cygcheck -f does not come up with a hit.
It is defined under:
/usr/include/machine/types.h
#ifndef __timestruc_t_defined
#define __timestruc_t_defined
typedef struct timespec timestruc_t;
#endif /*__timestruc_t_defined*/
check that the is included
$ cat prova.c
#include
int main(){
timestruc_t abstime;
}
$ gcc -c prova.c
$ ls -l prova.o
-rw-r--r-- 1 Marco Kein 656 May 15 07:59 prova.o
--
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
