Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?
I've found you must also copy the matching cygwin-console-helper.exe for everything to work correctly! On 2021-08-31 14:23, Chris Roehrig wrote: I did a 'git pull' of the latest topic/pipe and rebuilt and I now do indeed get 100MB/s transfers using both rsync and scp (without pipe_byte). (It turns out last time I forgot 'make install' -- Doh!) I still get the procps error however. On Tue Aug 31 2021, at 12:53 PM, Chris Roehrig wrote: Thanks, I did some more tests: scp also shows no improvement with topic/pipe.I tried running cygsshd with CYGWIN=pipe_byte as well as empty (in the registry HKLM/SYSTEM/CurrentControlSet/Services/cygsshd/Parameters/Environment/), using net stop cygsshd + net start cygsshd to restart it. Not sure if that CYGWIN only applies to cygsshd or to all cygwin tasks. I get the procps error just running 'procps' command with no args from mintty (/usr/bin/procps). Looking at the procps-ng source (procps-ng 3.3.17-1 is what setup_x86_64 reports as my installed package), it appears to be a mmap() failure. I'm wondering if I built/installed cygwin1.dll correctly because I don't get the procps error using the latest stock cygwin1.dll as installed by setup_ On Tue Aug 31 2021, at 12:05 PM, Ken Brown via Cygwin wrote: On 8/30/2021 7:58 PM, Chris Roehrig wrote: I got it to build and tried out the topic/pipe branch (checked out on Monday around 4:30pm PDT): 1. I didn't see any improvement in my sshd+rsync time, still 3-4 MB/sec. 2. I get the following error from procps: procps:ps/output.c:2195: please report this bug (I also get this using the main branch build). I first updated my cygwin normally using setup-x86_64.exe, then built and copied only the cygwin1.dll into /bin from the install/bin directory (quitting all cygwin tasks first). Thanks for testing. We're still working on this. (The discussion has moved to the cygwin-developers mailing list.) I'll let you know when it's stable, and maybe you can try again. As to the procps error, can you give details so that someone can try to reproduce it and debug it? -- 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
[ITP] man-pages-linux 5.13
Hi folks,
I would like to provide Cygwin packages for the Linux kernel man pages
project, for those who are concerned about interoperability and
portability, from Michael Kerrisk (http://man7.org/), who also releases
man-pages-posix, and just released Linux man-pages 5.13.
I do it for my own use anyway, to have the latest docs, just to save
flipping to Linux from Cygwin or Windows.
Comments, feedback, issues, opinions, thoughts, suggestions?
I have other approaches I could consider for others' convenience:
* the standard approach where each new release of man-pages-linux
obsoletes the previous; or
* allowing parallel installs with each release under it's own versioned
package man-pages-linux-5.?? and subdirectory and postinstall symlink
linux to the last installed; or
* use update-alternatives to select the release, with the default the
highest version as usual?
Comments, feedback, issues, opinions, thoughts, suggestions?
The install location is under the standard /usr/share/man/linux{,-5.??}
which can only by default be used by specifying
$ man -m|--systems linux ...
but can also be added explicitly to a users MANPATH or alias e.g.
$ alias man='man -m man,linux'
or swap the order to prioritize Linux, or for parallel installs add each
in your preferred order.
Comments, feedback, issues, opinions, thoughts, suggestions?
I have Linux 5.05-5.13 packages available for review as man-pages-linux:
https://drive.google.com/drive/folders/1r3vhlN4fsCAGAtxpVD9PJPVpahCmnIPE
Comments, feedback, issues, opinions, thoughts, suggestions?
If there is sufficient interest in other man-pages-* packages that I
could contemplate offering similarly, I also have kept around *a*
release of each of the below currently linked under my
/usr/local/share/man/ and others may be available including HOW-TOs:
CentOS-7.1 Darwin-7.0.1HP-UX-11.22 RedHat-9-i386
SunOS-5.10 Suse-11.3
FreeBSD-12-current FreeBSD-ports-11.1-RELEASE NetBSD-7.1
OpenBSD-6.2
X11R7.4
although I am unsure about the availability of releases for some.
Comments, feedback, issues, opinions, thoughts, suggestions?
--
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.]
Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?
I did a 'git pull' of the latest topic/pipe and rebuilt and I now do indeed get 100MB/s transfers using both rsync and scp (without pipe_byte). (It turns out last time I forgot 'make install' -- Doh!) I still get the procps error however. On Tue Aug 31 2021, at 12:53 PM, Chris Roehrig wrote: > Thanks, I did some more tests: > scp also shows no improvement with topic/pipe.I tried running > cygsshd with CYGWIN=pipe_byte as well as empty (in the registry > HKLM/SYSTEM/CurrentControlSet/Services/cygsshd/Parameters/Environment/), > using net stop cygsshd + net start cygsshd to restart it. Not sure if that > CYGWIN only applies to cygsshd or to all cygwin tasks. > > I get the procps error just running 'procps' command with no args from mintty > (/usr/bin/procps). Looking at the procps-ng source (procps-ng 3.3.17-1 is > what setup_x86_64 reports as my installed package), it appears to be a mmap() > failure. > > I'm wondering if I built/installed cygwin1.dll correctly because I don't get > the procps error using the latest stock cygwin1.dll as installed by > setup_x86_64. > > -- Chris > > > > On Tue Aug 31 2021, at 12:05 PM, Ken Brown via Cygwin > wrote: > >> On 8/30/2021 7:58 PM, Chris Roehrig wrote: >>> I got it to build and tried out the topic/pipe branch (checked out on >>> Monday around 4:30pm PDT): >>> 1. I didn't see any improvement in my sshd+rsync time, still 3-4 MB/sec. >>> 2. I get the following error from procps: procps:ps/output.c:2195: >>> please report this bug >>> (I also get this using the main branch build). >>> I first updated my cygwin normally using setup-x86_64.exe, then built and >>> copied only the cygwin1.dll into /bin from the install/bin directory >>> (quitting all cygwin tasks first). >> >> Thanks for testing. >> >> We're still working on this. (The discussion has moved to the >> cygwin-developers mailing list.) I'll let you know when it's stable, and >> maybe you can try again. >> >> As to the procps error, can you give details so that someone can try to >> reproduce it and debug it? >> >> 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 > > > -- > 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 -- 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: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?
Thanks, I did some more tests: scp also shows no improvement with topic/pipe.I tried running cygsshd with CYGWIN=pipe_byte as well as empty (in the registry HKLM/SYSTEM/CurrentControlSet/Services/cygsshd/Parameters/Environment/), using net stop cygsshd + net start cygsshd to restart it. Not sure if that CYGWIN only applies to cygsshd or to all cygwin tasks. I get the procps error just running 'procps' command with no args from mintty (/usr/bin/procps). Looking at the procps-ng source (procps-ng 3.3.17-1 is what setup_x86_64 reports as my installed package), it appears to be a mmap() failure. I'm wondering if I built/installed cygwin1.dll correctly because I don't get the procps error using the latest stock cygwin1.dll as installed by setup_x86_64. -- Chris On Tue Aug 31 2021, at 12:05 PM, Ken Brown via Cygwin wrote: > On 8/30/2021 7:58 PM, Chris Roehrig wrote: >> I got it to build and tried out the topic/pipe branch (checked out on Monday >> around 4:30pm PDT): >> 1. I didn't see any improvement in my sshd+rsync time, still 3-4 MB/sec. >> 2. I get the following error from procps: procps:ps/output.c:2195: please >> report this bug >> (I also get this using the main branch build). >> I first updated my cygwin normally using setup-x86_64.exe, then built and >> copied only the cygwin1.dll into /bin from the install/bin directory >> (quitting all cygwin tasks first). > > Thanks for testing. > > We're still working on this. (The discussion has moved to the > cygwin-developers mailing list.) I'll let you know when it's stable, and > maybe you can try again. > > As to the procps error, can you give details so that someone can try to > reproduce it and debug it? > > 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 -- 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: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?
On 8/30/2021 7:58 PM, Chris Roehrig wrote: I got it to build and tried out the topic/pipe branch (checked out on Monday around 4:30pm PDT): 1. I didn't see any improvement in my sshd+rsync time, still 3-4 MB/sec. 2. I get the following error from procps: procps:ps/output.c:2195: please report this bug (I also get this using the main branch build). I first updated my cygwin normally using setup-x86_64.exe, then built and copied only the cygwin1.dll into /bin from the install/bin directory (quitting all cygwin tasks first). Thanks for testing. We're still working on this. (The discussion has moved to the cygwin-developers mailing list.) I'll let you know when it's stable, and maybe you can try again. As to the procps error, can you give details so that someone can try to reproduce it and debug it? 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: requestedExecutionLevel "asInvoker" is ignored for setup-x86_64.exe
Never mind. Just found in the FAQ that the installer tries to spawn an elevated child instead of using the manifest. So in "setup-x86_64.exe -B" the "-B" switch does the trick. On 31.08.2021 18:38, ilya Basin wrote: > Hi. > I noticed that despite having: > > > > in setup-x86_64.exe the UAC prompt is not bypassed and when I click Cancel > the program is not started. > > Previously I used the same binary to install Cygwin for "Just me" on a host > where regular users are simply not allowed to trigger a UAC prompt. > > I have downloaded some other software installers and they work as intended: > > cf7_installer.exe > Git-2.33.0-64-bit.exe > pgadmin4-5.6-x64.exe > > The following env var also failed: > > set __COMPAT_LAYER=RunAsInvoker > > Then I tried to un-UPX and remove the manifest with ResHacker and I also > renamed "setup-x86_64.exe" to "putes-x86_64.exe" because I heard that UAC > looks for keyword in .exe name without a manifest, but the resulting binary > still triggers the UAC. > > > Reproducible on: > Windows 10 20-H2 build 19042.746 > Windows 7 sp1 buld 7601 > -- 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
requestedExecutionLevel "asInvoker" is ignored for setup-x86_64.exe
Hi. I noticed that despite having: in setup-x86_64.exe the UAC prompt is not bypassed and when I click Cancel the program is not started. Previously I used the same binary to install Cygwin for "Just me" on a host where regular users are simply not allowed to trigger a UAC prompt. I have downloaded some other software installers and they work as intended: cf7_installer.exe Git-2.33.0-64-bit.exe pgadmin4-5.6-x64.exe The following env var also failed: set __COMPAT_LAYER=RunAsInvoker Then I tried to un-UPX and remove the manifest with ResHacker and I also renamed "setup-x86_64.exe" to "putes-x86_64.exe" because I heard that UAC looks for keyword in .exe name without a manifest, but the resulting binary still triggers the UAC. Reproducible on: Windows 10 20-H2 build 19042.746 Windows 7 sp1 buld 7601 -- 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] mpfi-1.5.3: multiple precision floating-point interval library
On Mon, 30 Aug 2021 20:57:50 +0900, Lemures Lemniscati > Hi ! > > [ITP] A new package proposal: mpfi > > * libmpfi-devel-1.5.3-1 > * libmpfi-doc-1.5.3-1 > * libmpfi0-1.5.3-1 > > * mpfi-1.5.3-1-src > * mpfi-debuginfo-1.5.3-1 > > > > > mpfi 1.5.3 > > Summary: MPFI: Multiple Precision Floating-Point Interval Library > Description: > A library for interval arithmetic, > which is built upon the MPFR multiple precision floating-point > arithmetic library. > License: LGPL2.1 > Category: Math Libs > > Homepage: https://gitlab.inria.fr/mpfi/mpfi/ > News: https://gitlab.inria.fr/mpfi/mpfi/-/blob/1.5.3/mpfi/NEWS > > > > Corresponding Linux/Unix packages are searched: > https://repology.org/project/mpfi/versions > > Current cygport file is in a git repository: > https://github.com/cygwin-lem/mpfi-cygport/tree/mpfi-1.5.3-1 > > Current package files are placed at > https://cygwin-lem.github.io/mpfi-cygport/ > or in a git branch > https://github.com/cygwin-lem/mpfi-cygport/tree/mpfi-1.5.3-1_gh-pages > > > > Although mpfi-1.5.4 is released, it seems to be left incomplete and > unable to pass its testsuite. > So, I guess, mpfi-1.5.3 is better than 1.5.4. > By the way, I wonder if the maintainer of mpfr and gmp. to which mpfi is closely linked, would take a maintainership of mpfi, also. What would you think of it, Achim? Regards, Lem
