Supporting new Windows UDP offload features
Hello, Starting from Windows 10 version 2004, Windows supports UDP segmentation offload and UDP receive coalescing as described in https://docs.microsoft.com/en-us/windows-hardware/drivers/network/udp-segmentation-offload-uso-#ndis-interface-changes and in https://docs.microsoft.com/en-us/windows/win32/winsock/ipproto-udp-socket-options It seems that in order to support UDP segmentaion offload and UDP receive coalescing, cygwin needs to add support for UDP_SEND_MSG_SIZE and UDP_RECV_MAX_COALESCED_SIZE socket options for IPPROTO_UDP Could you please add it? If so, could you please estimate when it will be available? Thanks you, Rony -- 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: [Attn: mercurial maintainer] hg fails with python3.9
On 2022-04-30 15:16, Jon Turney wrote: > > My mistake. I had the development environment in wrong server, so only 5.7 > > was in there and I forgot to check the latest in Cygwin. > > > > 6.1.1-1 uploaded > > No problem. I'll see if I can improve that error message sometime. > > I notice that mercurial appears to be pure python, so maybe we can upload it > as noarch in future? Sure. I'll adjust it for the next upload. Jari -- 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: Supporting new Windows UDP offload features
On 2022-05-02 08:11, Rony Ross wrote: Starting from Windows 10 version 2004, Windows supports UDP segmentation offload and UDP receive coalescing as described in https://docs.microsoft.com/en-us/windows-hardware/drivers/network/udp-segmentation-offload-uso-#ndis-interface-changes and in https://docs.microsoft.com/en-us/windows/win32/winsock/ipproto-udp-socket-options It seems that in order to support UDP segmentaion offload and UDP receive coalescing, cygwin needs to add support for UDP_SEND_MSG_SIZE and UDP_RECV_MAX_COALESCED_SIZE socket options for IPPROTO_UDP Could you please add it? If so, could you please estimate when it will be available? Cygwin is an all-volunteer non-commercial open source POSIX/Linux emulation project, typically driven by developers' needs and interests, sometimes offering patchsets to add or enable features previously available in BSD flavours. If you are not a developer capable of doing so, you will have to wait and see if any developer is inspired by your post, and has the free time to work on it. You might want to help this along by expanding on some description of use cases, impacts, advantages, benefits, downsides, Unix parameters and implementations to be supported for emulation, Unix and Windows configuration of features, and availability on NICs, of those network features. -- 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: Supporting new Windows UDP offload features
On May 2 17:11, Rony Ross wrote: > Hello, > > Starting from Windows 10 version 2004, Windows supports UDP > segmentation offload and UDP receive coalescing as described in > https://docs.microsoft.com/en-us/windows-hardware/drivers/network/udp-segmentation-offload-uso-#ndis-interface-changes > and in > https://docs.microsoft.com/en-us/windows/win32/winsock/ipproto-udp-socket-options > It seems that in order to support UDP segmentaion offload and UDP > receive coalescing, cygwin needs to add support for UDP_SEND_MSG_SIZE > and UDP_RECV_MAX_COALESCED_SIZE socket options for IPPROTO_UDP > > Could you please add it? Reading about those, it looks like they might be drop-in solutions to implement the Linux UDP_SEGMENT and UDP_GRO socket options. Knowing Windows however, I'm sure there's a twist somewhere... > If so, could you please estimate when it will be available? In the hopes they work the same way, I can make the UDP_SEGMENT and UDP_GRO socket options available in the next major Cygwin version. Availability, probably at some point late this year. Or later. We're not at a point where this is safe to say. However, test versions can be made available rather soon, I think. Corinna -- 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: {,mingw64-{i686,x86_64}-}binutils-2.38-1
The binutils packages for Cygwin and MingW64 cross-compilation toolchains have been updated to the upstream feature release 2.38, with additional patches applied to remove upstream changes that are incompatible with Cygwin. binutils-2.38-1 mingw64-i686-binutils-2.38-1 mingw64-x86_64-binutils-2.38-1 The GNU Binutils are a collection of binary tools. Most of these programs use BFD, the Binary File Descriptor library, to do low-level manipulation. Many of them also use the opcodes library to assemble and disassemble machine instructions. Note This release still allows one to apparently use weak symbols (depending on exactly how you test for them), which however don't actually work on Windows nor Cygwin as they are unsupported by the loader. These symbols should always resolve as NULL, but since release 2.37 they sometimes don't. https://sourceware.org/bugzilla/show_bug.cgi?id=28719 After further changes and bugfixes in this area a workaround that was identified earlier no longer has the desired effect and investigation into the real root cause is still ongoing. This change in behaviour triggered a latent bug in gnulib's detection of weak symbols for pthreads that leads to non-debuggable crashes of applications erroneously built with weak symbols. Either update gnulib (or at least threadlib.m4) or add export gl_cv_have_weak=no to the cygport (or set it as an environment variable during configure). -- *** 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
[ANNOUNCEMENT] Updated: {,mingw64-{i686,x86_64}-}gcc-11.3.0-1
The native and mingw-w64 cross compilers have been updated for both architectures to the latest upstream release version of the gcc-11 branch: gcc-11.3.0-1 mingw64-i686-gcc-11.3.0-1 mingw64-x86_64-gcc-11.3.0-1 This release includes libgccjit as a separate package for the native toolchain on both architectures. Since Cygwin can't use ASLR, any nontrivial dynamic objects that get created in this way will likely need to get rebased before they can be used (especially on 32bit). It is unlikely that build systems recognize the need for doing that at the moment. The support libraries and binutils have been rebuilt with the new compiler. -- *** 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
[ANNOUNCEMENT] cygport 0.35.0-1
The following packages have been uploaded to the Cygwin distribution: * cygport-0.35.0-1 cygport is the standard method for building and maintaining packages for the Cygwin distribution. Highlights of this release: * New subcommands 'vars' and 'srcpackage' * cygtest() no longer ignores errors from 'make check' (making the default src_test function consistent with more specialized versions) * Automatic dependency detection now generates a dependency on the perl5_0xy provide for packages which install files into a versioned vendor_perl directory or link with cygperl5_xy.dll. Shortlog: Achim Gratz (2): cygclass/perl.cygclass: do not clobber HOMEPAGE and provide a correct default lib/pkg_info.cygport: implement automatic determination of the appropriate perl5_0xy requirement Adam Dinwoodie (1): autotools.cygclass: correctly detect Autoconf 2.70+ Jon Turney (11): Updates to tests for further rusting of python2 CI: Don't use a relative path with hashfiles() testsuite: Add more expected hints Don't ignore errors from make in cygtest() Add 'vars' command to output arbitrary .cygport variables Add srcpackage command Add git-archive-all to build-depends Updates to tests for package updates xorg.cygclass: Allow configuration of default SRC_URI compression autotools.cygclass: Report an error if ./configure version could not be detected Bump version to 0.35.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
mintty phantom key presses
Hi, I had previously reported this issue as "Possible phantom control-key state..." I observe that moving between cygwin mintty windows and Windows windows causes unexpected behavior in the cygwin world. I took a new approach, using vi :) . In cygwin, I open a new file, enter insert mode, hit Ctrl-V, and mouse out of the window. When I mouse back into the cygwin edit window, my screen contains the display string "^[[O" (note that the "^[" is vi-speak for "esc"). Examining the resulting file with od shows: > od -ah fdsa 000 esc [ O nl 5b1b0a4f Here, the nl character is inserted by vi. This smells like an incomplete escape sequence. If it's left at the command line, just waiting for the user to type something, there might be trouble. Am I completely off? Thanks, Eric Adams. fdsa Description: Binary data 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
Offer to collaborate with cygwin com
Hello! My name is William, I am a marketing specialist of Softorino.com I liked the content of your site and would like to offer you cooperation. We have a product that solves the problem of users who need to organize their workspace. We could give you our lifetime Universal License https://softorino.com/universal-license/ (which already includes 16 premium apps) for FREE to organize your workspace and make your workflow pleasant. All we ask in return, is that you write a review-article about one of our apps that the Universal License includes, and include a link to product in the article. It would be great if you could write a review within 1 working week of receiving your license. Write to me if you are interested in my proposal. Best, William -- 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: mintty phantom key presses
Am 02.05.2022 um 23:54 schrieb Eric Adams: Hi, I had previously reported this issue as "Possible phantom control-key state..." I observe that moving between cygwin mintty windows and Windows windows causes unexpected behavior in the cygwin world. I took a new approach, using vi :) . In cygwin, I open a new file, enter insert mode, hit Ctrl-V, and mouse out of the window. When I mouse back into the cygwin edit window, my screen contains the display string "^[[O" (note that the "^[" is vi-speak for "esc"). Examining the resulting file with od shows: od -ah fdsa 000 esc [ O nl 5b1b0a4f Here, the nl character is inserted by vi. This smells like an incomplete escape sequence. If it's left at the command line, just waiting for the user to type something, there might be trouble. Am I completely off? Thanks, Eric Adams. CSI O is the focus off notification (CSI I is the focus in notification). Someone has switched on focus reporting mode (CSI ? 1004 h) in your session (and isn't catching the notifications). Run your application in a fresh mintty, with no other software, to test. 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