Aborting Cygwin setup in unattended modes
If Cygwin's setup requires input (for example, to select a mirror), with --quiet-mode hidden it simply terminates (there's no apparent exit status or message, though). With --quiet-mode noinput, Cygwin setup sits at the appropriate dialog, but it's of course non-responsive. Would it be possible in these situations for Cygwin to abort, preferably with a non-zero exit code? The background to this was running Cygwin setup in GitHub Actions (so UI not visible), _without_ specifying --site, where the Cygwin installation had been restored by actions/cache but not the registry setting in HKLM\SOFTWARE\Cygwin\setup meaning that setup could not find setup.rc and consequently determine the last-used mirror. The GUI therefore invisibly froze at mirror selection. That issue has obviously been fixed, but it would seem sensible that Cygwin's setup doesn't ever display a dialog _requiring_ input where all that input has been disabled! David -- 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
setup: --prune-install appears to be broken
If I do a base install to a new root:
setup-x86_64.exe --root "$(cygpath -wa .cygtest)" --no-admin \
--no-shortcuts --no-replaceonreboot --no-version-check \
--prune-install --verbose
And then run the same install again, I get:
libsolv: orphaned packages:
libsolv: base-0.0-0.any (erased)
libsolv: _windows-10.0.19045.any (kept)
libsolv:
libsolv: ordering transaction
libsolv: transaction elements: 33
libsolv: edges: 41, edge space: 70
libsolv: edge creation took 0 ms
libsolv: cycles broken: 0
libsolv: cycle breaking took 0 ms
libsolv: invedge space: 76
libsolv: creating new transaction took 0 ms
libsolv: transaction ordering took 0 ms
libsolv: 33 erased packages:
libsolv: - base-0.0-0.any
libsolv: - ca-certificates-2023.2.62_v7.0.401-2.any
libsolv: - cygutils-1.4.17-1.any
libsolv: - file-5.44-1.any
libsolv: - gawk-5.3.0-1.any
libsolv: - groff-1.23.0-1.any
libsolv: - less-643-1.any
libsolv: - libfdisk1-2.39.3-2.any
libsolv: - libffi6-3.2.1-2.any
libsolv: - libgdbm6-1.18.1-1.any
libsolv: - liblz4_1-1.9.4-1.any
libsolv: - liblzma5-5.6.2-1.any
libsolv: - libmpfr6-4.2.1-1.any
libsolv: - libp11-kit0-0.23.20-1.any
libsolv: - libpcre1-8.45-1.any
libsolv: - libpipeline1-1.5.6-1.any
libsolv: - libpopt-common-1.19-1.any
libsolv: - libpopt0-1.19-1.any
libsolv: - libsmartcols1-2.39.3-2.any
libsolv: - libssl1.1-1.1.1w-1.any
libsolv: - libssl3-3.0.14-1.any
libsolv: - libstdc++6-11.4.0-1.any
libsolv: - libtasn1_6-4.14-1.any
libsolv: - libuchardet0-0.0.8-1.any
libsolv: - libuuid1-2.39.3-2.any
libsolv: - man-db-2.12.1-1.any
libsolv: - openssl-3.0.14-1.any
libsolv: - p11-kit-0.23.20-1.any
libsolv: - p11-kit-trust-0.23.20-1.any
libsolv: - tar-1.35-2.any
libsolv: - util-linux-2.39.3-2.any
libsolv: - xz-5.6.2-1.any
libsolv: - zstd-1.5.6-1.any
libsolv:
Can't happen. No packagemeta for base
The "Can't happen" error results in all following transactions being skipped:
// Can't happen - throw an exception?
{
Log (LOG_PLAIN) << "Can't happen. No packagemeta for "
<< pv.Name() << endLog;
return;
}
This results in setup always showing no pending changes, even if you
have installed additional packages that should be pruned by
--prune-install, or if setup.ini has different contents.
The problem seems to be that we use SOLVER_ERASE jobs to remove all
non-base installed packages, and they take precedence over keeping the
pseudo-package 'base' installed.
Making the erase jobs weak seems to solve the problem:
diff --git a/libsolv.cc b/libsolv.cc
index 3f083a4..95f21a2 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -850,7 +850,7 @@ SolverSolution::tasksToJobs(SolverTasks , updateMode
update, Queue )
queue_push2(, SOLVER_INSTALL | SOLVER_SOLVABLE_PROVIDES,
sv.name_id());
break;
case SolverTasks::taskUninstall:
- queue_push2(, SOLVER_ERASE | SOLVER_SOLVABLE, sv.id);
+ queue_push2(, SOLVER_ERASE | SOLVER_WEAK | SOLVER_SOLVABLE,
sv.id);
break;
case SolverTasks::taskReinstall:
// we don't know how to ask solver for this, so we just add the erase
However, I'm not sure if this is a good idea. Perhaps it should only be
done for pruned packages, and not explicitly uninstalled ones. I did try
various things to strengthen the requirement on 'base', but had no luck.
--
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: new git update fails with fatal: fetch-pack: invalid index-pack output
Thank you for your ideas! I have made no changes but can't reproduce the issue today both with a very short path of /usr/bin and the original path I tried with VPN off or on I would be happy to try a few other experiments - but I don't even need the workaround of reverting to an older git $ which git /usr/bin/git $ git --version git version 2.45.1 OPATH="$PATH" PATH="/usr/bin" git clone -v https://github.com/lxml/lxml.git mv lxml lxml- PATH="$OPATH" git clone -v https://github.com/lxml/lxml.git while rm -rf lxml && time git clone -v https://github.com/lxml/lxml.git ; do date ; done at the moment the above loop runs hundreds of times without errors On Mon, May 27, 2024 at 1:31 PM Adam Dinwoodie wrote: > > > I've just set up a test sandbox with the same set of Cygwin > applications installed, and I'm still not able to replicate this > failure, which is going to make it difficult to work out what's going > wrong for you! > > I note your Cygwin PATH has several entries before /bin, including a > ~/bin that apparently contains a perl executable; can you see if you > can reproduce the problem with a clean PATH? > > In any case, I'm having to conclude the issue is something odd about > your environment that doesn't seem to be affecting most people. > Working out what's going wrong will probably require isolating what > difference is relevant here. I think there's two obvious routes to > doing that: you can work out what's odd about your environment (maybe > use Windows Sandbox, given you're running Windows Enterprise? I've > attached a .wsb file that should give you a starting point for setting > up test environments, based on your cygcheck.out), or you can work out > what's changed in Git between 2.42.0 and 2.45.1, which will probably > mean building and bisecting Git yourself; once we know what change is > the culprit, that'll make it much easier to work out what's going > wrong. > > If it'd be useful, I can provide some test builds of Git to help > narrow down where the problem is, but if you can do the builds > yourself, that'll be a lot quicker than trying to do a binary chop by > email… > -- 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
new git update fails with fatal: fetch-pack: invalid index-pack output
I upgraded to the most recent git and I get the following error ( stable2.45.1-1x86_648597 KiB2024-05-25 18:58 ) $ git clone -v https://github.com/lxml/lxml.git Cloning into 'lxml'... POST git-upload-pack (175 bytes) POST git-upload-pack (gzip 8652 to 4281 bytes) remote: Enumerating objects: 33933, done. remote: Counting objects: 100% (3778/3778), done. remote: Compressing objects: 100% (1322/1322), done. remote: Total 33933 (delta 2356), reused 3471 (delta 2241), pack-reused 30155 Receiving objects: 100% (33933/33933), 20.19 MiB | 15.38 MiB/s, done. fatal: fetch-pack: invalid index-pack output when I downgraded to 2.43.0-1x86_648402 KiB2024-01-07 20:32 I was able to get the repository download $ git clone -v https://github.com/lxml/lxml.git Cloning into 'lxml'... POST git-upload-pack (175 bytes) POST git-upload-pack (gzip 8652 to 4281 bytes) remote: Enumerating objects: 33933, done. remote: Counting objects: 100% (3778/3778), done. remote: Compressing objects: 100% (1322/1322), done. remote: Total 33933 (delta 2356), reused 3471 (delta 2241), pack-reused 30155 Receiving objects: 100% (33933/33933), 20.19 MiB | 13.13 MiB/s, done. Resolving deltas: 100% (16518/16518), done. -- 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: 3.5.x regression: misquoting command line arguments from native processes
Hi Corinna, > On Apr 9 22:38, Corinna Vinschen via Cygwin wrote: > > On Apr 3 16:53, David Allsopp via Cygwin wrote: > > > I have what appears to be a regression in Cygwin 3.5.0 which, owing to > > > a CI system lagging behind, we've only just discovered. > > > [...] > > > $ ./t.exe 'C:\Devel\реализация-mingw64\flexdll\flexdll_mingw64.o' > > > stat: cannot stat > > > '"C:\Devel\'$'\360\237\220\253''реализация-mingw64\flexdll\flexdll_mingw64.o': > > > No such file or directory > > > > Thanks a lot for the STC! > > > > I think I fixed that for 3.5.4. I pushed a patch and the test release > > cygwin-3.6.0-0.115.g579064bf4d40 is just building and should be ready > > for testing in an hour or two. > > > > Please give it a try. > > Sorry for nagging, but do you have some feedback, be it bad or good? Sorry for having needed nagging! It does indeed fix it, thank you - our smoke-test Bactrian camels can be restored All best, David -- 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
3.5.x regression: misquoting command line arguments from native processes
I have what appears to be a regression in Cygwin 3.5.0 which, owing to
a CI system lagging behind, we've only just discovered.
In order to torture our Unicode support, OCaml's Windows CI compiles
its sources in C:\projects\реализация-mingw64 (that's a directory
under C:\projects with the camel emoji U+1F42A followed, I am told, by
the word "implementation" in Russian then with the name of the "port"
of OCaml appended in ASCII).
AppVeyor updated to Cygwin 3.5.1 at the weekend and now, during the
build, we end up with the following kind of error seen in, say,
https://ci.appveyor.com/project/avsm/ocaml/builds/49538801#L711. What
is happening here is that Cygwin's make has passed
C:\projects\реализация-mingw64\byte\bin\flexdll_mingw64.o to a
non-Cygwin program (flexlink.exe) which has called back to Cygwin's
x86_64-w64-mingw32-gcc ultimately via CreateProcess and which has then
failed.
I have reduced this chain to the following program, which takes
argv[1] and calls Cygwin's stat program using _wsystem with argv[1]
"-quoted:
#include
#include
int wmain(int argc, wchar_t **argv) {
int len = 2 + 6 + wcslen(argv[1]);
wchar_t *cmd = (wchar_t *)malloc(len * sizeof(wchar_t));
wcscpy(cmd, L"stat ");
cmd[5] = L'"';
cmd[6] = 0;
wcscat(cmd, argv[1]);
cmd[len - 1] = L'"';
cmd[len] = 0;
_wsystem(cmd);
}
Compile with x86_64-w64-mingw32-gcc -municode -DUNICODE -D_UNICODE and
then see it works on Cygwin 3.4.10:
$ ./t.exe 'C:\Devel\реализация-mingw64\flexdll\flexdll_mingw64.o'
File: C:\Devel\реализация-mingw64\flexdll\flexdll_mingw64.o
Size: 11441 Blocks: 12 IO Block: 65536 regular file
Device: 35525,39577 Inode: 3659174698707368 Links: 1
Access: (0644/-rw-r--r--) Uid: (1049719/ DRA) Gid: (1049089/Domain Users)
Access: 2024-04-03 16:43:36.782037800 +0100
Modify: 2024-04-03 14:09:08.012955600 +0100
Change: 2024-04-03 14:09:08.012955600 +0100
Birth: 2024-04-03 14:09:08.006955500 +0100
but fails on 3.5.1+ (including the latest 3.6.0-0.109 snapshot):
$ ./t.exe 'C:\Devel\реализация-mingw64\flexdll\flexdll_mingw64.o'
stat: cannot stat
'"C:\Devel\'$'\360\237\220\253''реализация-mingw64\flexdll\flexdll_mingw64.o':
No such file or directory
Note the stray double-quote at the start of the error. This appears to
be down to the presence of the emoji, rather than the Cyrillic
characters, this is fine in both:
$ ./t.exe 'C:\Devel\реализация\flexdll\flexdll_mingw64.o'
File: C:\Devel\реализация\flexdll\flexdll_mingw64.o
Size: 11441 Blocks: 12 IO Block: 65536 regular file
Device: 35525,39577 Inode: 16607023627376791 Links: 1
Access: (0644/-rw-r--r--) Uid: (1049719/ DRA) Gid: (1049089/Domain Users)
Access: 2024-04-03 16:48:43.003742000 +0100
Modify: 2024-04-03 14:09:08.012955600 +0100
Change: 2024-04-03 16:32:35.648039600 +0100
Birth: 2024-04-03 16:32:35.647539400 +0100
All best,
David
--
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 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 3/30/2024 8:25 AM, Jon Turney wrote: On 29/03/2024 18:32, David Rothenberger via Cygwin-apps wrote: On 3/28/2024 10:50 AM, Jon Turney via Cygwin-apps wrote: [...] David, Is it possible to update/rebuild rdiff-backup, which replies upon the soon-to-be removed python36? (Or indicate that you are no longer interested in maintaining this package, which will probably lead to it's removal). Please remove me as the maintainer from that package. I no longer use it, and no longer have an environment for building packages for Cygwin. No problem. Thanks for maintaining it in the past. Is the same true for your other packages? $ grep Rothenberger cygwin-pkg-maint | grep -v ORPHANED cyrus-sasl David Rothenberger flac David Rothenberger libao David Rothenberger libapr1 David Rothenberger libaprutil1 David Rothenberger libkate David Rothenberger libogg David Rothenberger librsync David Rothenberger libtheora David Rothenberger libvorbis David Rothenberger rdiff-backup David Rothenberger speex David Rothenberger speexdsp David Rothenberger vorbis-tools David Rothenberger which David Rothenberger whois David Rothenberger Yes, I'm afraid it is. Regards, David -- David Rothenberger daver...@acm.org
Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 3/28/2024 10:50 AM, Jon Turney via Cygwin-apps wrote: On 24/03/2024 17:46, Jon Turney via Cygwin-apps wrote: On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote: On 24/03/2024 15:07, Jon Turney wrote: On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote: I assume you are OK with the removal of python 3.5 (EOL Sept 2020) and 3.6 (EOL Dec 2021)? (I'm still dealing with cleaning up the final pieces of python27 detritus, but these should hopefully be much smaller tasks) nothing should depend from 3.5 not sure for 3.6 I've automated some of the analysis I was doing for python2 packages and the results are now available at [1]. So yeah, it looks like nothing uses 3.5. There are just a couple of packages using 3.6, I guess I'll ping the maintainers about those. [1] https://cygwin.com/packages/reports/python_rebuilds.html David, Is it possible to update/rebuild rdiff-backup, which replies upon the soon-to-be removed python36? (Or indicate that you are no longer interested in maintaining this package, which will probably lead to it's removal). Please remove me as the maintainer from that package. I no longer use it, and no longer have an environment for building packages for Cygwin. Thanks, David -- David Rothenberger daver...@acm.org Katz' Law: Men and nations will act rationally when all other possibilities have been exhausted. History teaches us that men and nations behave wisely once they have exhausted all other alternatives. -- Abba Eban
Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel
On Fri, 1 Mar 2024 at 08:03, Takashi Yano via Cygwin wrote: > Please try: cygwin 3.6.0-0.66.gc77a5689f7bd (TEST) I can confirm this fixes the issue for me, thank you! David -- 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: Creating a desktop shortcut to Cygwin emacs
Ok. I forgot I had to add that package. However, now there's another odd problem. The command line still doesn't start anything, but it does print an error message, saying that it can't find "/usr/local/bin/emacs.xml". I can copy that file from the old laptop, but is that file supposed to be generated by something? On Thu, Feb 22, 2024 at 1:12 PM Ken Brown wrote: > On 2/22/2024 2:44 PM, David Karr via Cygwin wrote: > > Every three years or so I have to set up a new laptop, and several things > > that I only do in that period I either lose the notes on it, or something > > has changed that I'm not aware of. > > > > I'm installing Cygwin on a new laptop, version 3.5.0-1.x86_64. I had > 3.4.6 > > on the old laptop. > > > > My desktop shortcut on the old laptop goes to: > > > > C:\cygwin64\bin\run2.exe --display 127.0.0.1:0.0 > /usr/local/bin/emacs.xml > > > > I tried to set this up on the new laptop, and I noticed that "run2" > doesn't > > exist, but "run" does. > > The run2 package still exists: > >https://cygwin.com/packages/summary/run2.html > > 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
Creating a desktop shortcut to Cygwin emacs
Every three years or so I have to set up a new laptop, and several things that I only do in that period I either lose the notes on it, or something has changed that I'm not aware of. I'm installing Cygwin on a new laptop, version 3.5.0-1.x86_64. I had 3.4.6 on the old laptop. My desktop shortcut on the old laptop goes to: C:\cygwin64\bin\run2.exe --display 127.0.0.1:0.0 /usr/local/bin/emacs.xml I tried to set this up on the new laptop, and I noticed that "run2" doesn't exist, but "run" does. I tried just changing the command line to call "run" instead, but that resulting command line doesn't appear to do anything. No errors, just returns to the prompt and nothing happens. I tried googling for this, and I found a page on the EmacsWiki, but I can't tell if that is up to date. -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Sat, 3 Feb 2024 at 19:25, Corinna Vinschen wrote: > > Sorry to say that, but SetThreadErrorMode/CreateProcess don't do what we > > want them to do. I just tested this myself with a modified Cygwin DLL > > (code below) and it turns out that the child process error mode is > > the same as the parent's process error mode. Changing the thread > > error mode from the Cygwin default 3 (aka SEM_FAILCRITICALERRORS | > > SEM_NOGPFAULTERRORBOX) to 0 doesn't have any effect. > > [...etc.] Oh dear, what a mess! > MSYS2 has introduced the environment variable option CYGWIN=winjitdebug. > I backported this patch now. So default is back to propagating Cygwin's > error mode and if you want to reset the error mode of a non-Cygwin child > process back to OS default, just set the option, for instance, like > this: > > $ CYGWIN=winjitdebug env > > This patch will be in Cygwin 3.5.1. For the time being, it will be > available in the next test release cygwin-3.6.0-0.28.g918c3eda4176 as > well. This completely fixes it for us, thank you very much Thanks, David -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote: > > On Feb 2 13:35, David Allsopp via Cygwin wrote: > > Jon Turney via Cygwin wrote: > > > > > > I'm sympathetic, and personally I would prefer to revert the patch and > > > > stick to SEM_FAILCRITICALERRORS by default. > > > > > > > > The question is this: Why does, apparently, everybody expect Cygwin to > > > > do the "right thing", with different definitions of "right", when in > > > > fact the executable in question can easily call SetErrorMode by itself? > > > > > > Yeah, if cygwin wasn't involved in the process ancestry, how would you > > > get the behaviour you want? > > > > Ah, but that's how I hit this (and started digging further) - > > precisely because the non-Cygwin program I'm using _has_ called > > SetErrorMode and its direct calls to the faulty program _are_ doing > > what's wanted (no popup dialog) but the calls which happen via Cygwin > > are then torching that preference. > > > > Not really suggesting it be done this way (it feels more complicated > > than just reverting the change), but in some ways perhaps Cygwin > > should be using GetErrorMode on startup and instead of not inheriting > > it, ensuring that it sets whatever it received? i.e. just before the > > call to CreateProcess for a non-Cygwin binary, Cygwin restores the > > error mode (for that thread only) to the value read at startup, calls > > CreateProcess and then sets the error mode back. > > This sounds like a good ide, but... > > Is it actually a safe bet that the error mode set by SetThreadErrorMode > is then propagated as process error mode to the child process? > > I have to ask that because Microsoft conveniently forgot to document > this scenario in the MSDN docs. :o) Never knowingly clear, are they! It would seem to be the intent of SetThreadErrorMode that it would behave that way but who knows. Happy to set up a quick experiment to check that it does work (i.e. the invoked process has GetErrorMode set as expected) and that there's no possible race between two threads in the calling process with differing values (i.e. that having SEM_FAILCRITICALERRORS in one thread and not in another behaves as expected. If it does appear to work consistently, would you be willing to go down this route? Happy to do the patch, although it'd be very helpful to have a couple of pointers: I'm guessing the value would want to be captured just before the one place where SetErrorMode is already called, but in which structure should it then be stashed away to be reused in spawn? David -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
Jon Turney via Cygwin wrote: > > I'm sympathetic, and personally I would prefer to revert the patch and > > stick to SEM_FAILCRITICALERRORS by default. > > > > The question is this: Why does, apparently, everybody expect Cygwin to > > do the "right thing", with different definitions of "right", when in > > fact the executable in question can easily call SetErrorMode by itself? > > Yeah, if cygwin wasn't involved in the process ancestry, how would you > get the behaviour you want? Ah, but that's how I hit this (and started digging further) - precisely because the non-Cygwin program I'm using _has_ called SetErrorMode and its direct calls to the faulty program _are_ doing what's wanted (no popup dialog) but the calls which happen via Cygwin are then torching that preference. Not really suggesting it be done this way (it feels more complicated than just reverting the change), but in some ways perhaps Cygwin should be using GetErrorMode on startup and instead of not inheriting it, ensuring that it sets whatever it received? i.e. just before the call to CreateProcess for a non-Cygwin binary, Cygwin restores the error mode (for that thread only) to the value read at startup, calls CreateProcess and then sets the error mode back. To explain in the context of the actual call chain: - I have opam.exe (compiled with mingw-w64), which is calling SetErrorMode in main - It's calling ocamlc.exe (in PATH) which requires the zstd DLL, but that has not been put in PATH - A direct call - not via Cygwin - to ocamlc -vnum therefore returns an exit code - Another call, already there from the Unix side, instead does sh -c "ocamlc -config | sed ..." but Cygwin has then _removed_ the calling applications preference Thanks, David -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Fri, 2 Feb 2024 at 12:55, Corinna Vinschen via Cygwin wrote: > On Feb 2 09:43, David Allsopp via Cygwin wrote: > > On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin > > wrote: > > > > > > The behaviour changed in 2020 > > > > > > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912 > > > > > > not without a discussion > > > > > > https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html > > > > Aha, thank you! (congrats on the 3.5 release, in passing, btw). > > Definitely not a regression, then (subject edited). > > > > However, this patch came from MSYS2, and subsequently they seem to > > have found it problematic for the same reason as me > > (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624) > > and have just recently reintroduced the flag > > (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50) > > to control it. > > > > The reasoning in > > https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as > > valid now as it did in 2006. > > > > Is it possible to revisit having the flag, or even just reverting the > > behaviour? > > > > FWIW, it's been "hurting" us over in OCaml-land since zstd support was > > added roughly a year ago - configure can tell us that mingw-w64's zstd > > is available, but woe betide us if we run the test program to see if > > it actually works, but the user forgot to add the sys-root into PATH, > > because at that point the CI system is down... > > I'm sympathetic, and personally I would prefer to revert the patch and > stick to SEM_FAILCRITICALERRORS by default. > > The question is this: Why does, apparently, everybody expect Cygwin to > do the "right thing", with different definitions of "right", when in > fact the executable in question can easily call SetErrorMode by itself? The executable can't, though (at least, I'm not aware that it can)? The DLL not found case is being triggered by the loader, before the entrypoint code is running? I did have a look to see if there are manifest flags or some such which can be set to indicate this, but it does seem to be the responsibility of the caller, coupled with a "best practice" recommendation on MSDN to call SetErrorMode (as Cygwin is of course doing). The whole system with it feels like unfortunate Windows legacy, but I guess the behaviour vastly predates Event Viewer, etc., and slightly better (and non-blocking) ways of reporting loader errors. Perils of a nearly 40 year old API, if not OS Thanks, David -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin wrote: > > The behaviour changed in 2020 > > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912 > > not without a discussion > > https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html Aha, thank you! (congrats on the 3.5 release, in passing, btw). Definitely not a regression, then (subject edited). However, this patch came from MSYS2, and subsequently they seem to have found it problematic for the same reason as me (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624) and have just recently reintroduced the flag (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50) to control it. The reasoning in https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as valid now as it did in 2006. Is it possible to revisit having the flag, or even just reverting the behaviour? FWIW, it's been "hurting" us over in OCaml-land since zstd support was added roughly a year ago - configure can tell us that mingw-w64's zstd is available, but woe betide us if we run the test program to see if it actually works, but the user forgot to add the sys-root into PATH, because at that point the CI system is down... Thanks, David -- 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: Aren't Windows System Error popups meant to be disabled in Cygwin?
> x86_64-w64-mingw32-gcc produces a Windows program, why Cygwin should > be involved in the execution ? I perhaps should have made that crystal clear - in running "./test", I'm invoking that excecutable _from_ a Cygwin program (in this case mintty / bash / sh), so Cygwin is very much involved - it's the caller. In the actual problem which hit this, I have a non-Cygwin executable which has called SetErrorMode(SEM_FAILCRITICALERRORS). If that program calls test, there is no popup displayed. However, it also calls Cygwin's sh and _that_ executes that program too, so something like "C:\cygwin64\bin\sh -c "./test.exe | sed ..." but then the popup error message appears. So somewhere along the line, Cygwin appears to be resetting the system error mode, and that appears contrary to previous (old) messages on the subject. Thanks, David -- 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: Aren't Windows System Error popups meant to be disabled in Cygwin?
On Wed, 31 Jan 2024 at 22:27, Brian Inglis via Cygwin wrote:
>
> On 2024-01-31 06:40, David Allsopp via Cygwin wrote:
> > Starting with this very trivial C program:
> >
> > #include
> > #include
> >
> > int main(void) {
> >printf("Zstandard v%d\n", ZSTD_versionNumber());
> > }
> >
> > and compiling with
> >
> > x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
> >
> > when I then run ./test.exe, I get the Windows critical-error-handler
> > dialog stating "The code execution cannot proceed because
> > libzstd-1.dll was not found. Reinstalling the program may fix this
> > problem."
> >
> > My question is not how to fix the problem (I'm well aware of that),
> > but rather why that message is being displayed at all, and is it a bug
> > in Cygwin somewhere? All I could find Googling was previous
> > suggestions that Cygwin routinely calls SetErrorMode with, amongst
> > other things, SEM_FAILCRITICALERRORS with the intention of suppressing
> > this dialog.
> >
> > Is that correct, and if so is this just me? :o)
> >
> > Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty.
> > I also get the same popup if I run C:\cygwin64\bin\sh -c
> > "/cygdrive/c/path/to/test" either from a Command Prompt or even from
> > "Start -> Run". Running this via "sh" called from a non-Cygwin process
> > (itself invoked from a Command Prompt) which has also called
> > SetErrorMode is how I hit this.
>
> Better to let you know that there is a problem, and what the problem is, so
> you
> can fix it!
Thank you, but no - as I made clear by:
> My question is not how to fix the problem (I'm well aware of that)
I'm fully aware what has caused the issue to arise, and how to fix it
- that's not the issue. The problem is that according to previous
messages, and the Cygwin code, my impression was that mintty / bash /
sh (*Cygwin* programs) calling this executable should be returning an
exit code here, not freezing on a message dialog. The problem appears
to be a bug in the Cygwin DLL, and from previous messages on the list,
my question is whether it's a regression, and can be fixed.
The reason it's a problem is, say, a script _in Cygwin_ which is
handed a command to run, runs it, and is then completely blocked by
that popup dialog. It's the responsibility of the _caller_ (a Cygwin
program) to indicate the mode in which a program is executed - the
message box may be owned by the program called, but it's caused by it
being loaded, before it has a chance to run any code.
My understanding, based on this line:
https://github.com/cygwin/cygwin/blob/main/winsup/cygwin/dcrt0.cc#L721
in dll_crt0_0
is that Cygwin executables (in this case mintty / bash / sh, etc.)
should be running with SEM_FAILCRITICALERRORS enabled, following the
best practice recommendations in
https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-seterrormode
and that that setting should be correctly inherited by processes they
call (including non-Cygwin ones).
Some ancient history, reporting my same issue in 2004:
https://cygwin.com/pipermail/cygwin/2004-March/115553.html and this
thread from 2006
https://cygwin.com/pipermail/cygwin/2006-August/150038.html strongly
indicating that that line dcrt0.cc is there precisely to stop this
popup.
Thanks,
David
--
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
Aren't Windows System Error popups meant to be disabled in Cygwin?
Starting with this very trivial C program:
#include
#include
int main(void) {
printf("Zstandard v%d\n", ZSTD_versionNumber());
}
and compiling with
x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
when I then run ./test.exe, I get the Windows critical-error-handler
dialog stating "The code execution cannot proceed because
libzstd-1.dll was not found. Reinstalling the program may fix this
problem."
My question is not how to fix the problem (I'm well aware of that),
but rather why that message is being displayed at all, and is it a bug
in Cygwin somewhere? All I could find Googling was previous
suggestions that Cygwin routinely calls SetErrorMode with, amongst
other things, SEM_FAILCRITICALERRORS with the intention of suppressing
this dialog.
Is that correct, and if so is this just me? :o)
Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty.
I also get the same popup if I run C:\cygwin64\bin\sh -c
"/cygdrive/c/path/to/test" either from a Command Prompt or even from
"Start -> Run". Running this via "sh" called from a non-Cygwin process
(itself invoked from a Command Prompt) which has also called
SetErrorMode is how I hit this.
Thanks!
David
--
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
Tmux crashes on copy
When using the copy function in tmux it crashes on Enter. Steps: ctrl-[ (enter copy mode) Navigate to text space (start copy) Navigate to end of text Enter (to select highlighted text) at this point tmux crashes cygcheck.out (email redacted) and tmux.exe.stackdump attached Thanks cygcheck.out Description: Binary data tmux.exe.stackdump 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
Re: Ruby EOL in Cygwin 3.4.9?
On 10/12/2023 2:46 PM, Eric Hendrickson via Cygwin wrote: And your point about the effort involved and no known bugs is well taken of course but Cygwin is still distributing EOL software. This is why I asked, would it make sense to just not release new non emergency versions of Cygwin with EOL packages, until that can be remedied. Cygwin "releases" are just releases of the compatibility library, similar to the kernel in a Linux distribution. Cygwin doesn't have the equivalent of Debian releases, where all packages are tested for compatibility and released as a unit. For that reason, it doesn't make sense to pause Cygwin "releases" just because some of the packages are out-of-date, since Cygwin is itself just another one of these packages. -- David Rothenberger daver...@acm.org -- 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
setup-x86_64.exe can not create download folder
Hi! I just downloaded https://www.cygwin.com/setup-x86_64.exe version 2.925 After starting, I: - selected "Install from Internet" (actually it was already selected) - left defaults: root dir=C:\cygwin64 , Install For: all users - the Local Package Directory was: C:\Users\AdminGuy\Downloads\ I added cygwin_download_temp to it to get: C:\Users\AdminGuy\Downloads\cygwin_download_temp After clicking I got an error dialog: --- Cygwin Setup --- Directory C:\Users\AdminGuy\Downloads\cygwin_download_temp does not exist, would you like me to create it? --- Yes No --- I clicked Yes and got an error that it could not create the directory. So I created the folder in Explorer and then continued. Notes: I tried to reproduce it in a second instance of setup-x86_64.exe but could not, it created the folder without a problem. So I closed (clicked the Cancel button) both instances and run it again, and I could reproduce the problem. After changing the local path, I pressed the enter key instead of clicking next. The in the error dialog asking to create the folder, I pressed space. Then I got the dialog: --- Cygwin Setup --- Couldn't create directory , sorry. (Is drive full or read-only?) --- OK --- Very strange, sometimes clicking Yes in the "would you like me to create it" dialog just brings up the same dialog again and again, until a few iterations is shows the "Couldn't create directory , sorry." dialog. Can be workarounded, but a bit annoying. OS: Windows Server 2019 version 1809 When I start setup-x86_64.exe the UAC dialog pops up where I click Yes. Regards, David -- 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: Another confusing error from someone else's Cygwin setup
The line endings were the issue, thanks. They were that way because I
didn't realize I should force those files in git to have eol=lf in a
.gitattributes file. This is now all fixed.
On Mon, Jun 26, 2023 at 7:08 PM Mike Gran wrote:
> > On Monday, June 26, 2023 at 04:36:30 PM PDT, David Karr via Cygwin <
> cygwin@cygwin.com> wrote:
>
> > m seeing a problem with someone else's Cygwin setup, sort of similar to a
> > problem I asked about a couple of weeks ago, in that it's a problem with
> > the same user, but seemingly a completely different problem.
>
> ...
>
> > He was getting a weird error on line 3, just saying this:
> > -
> > ...: line 3: syntax error near unexpected token `$'{\r''
> > ...: line 3: `main() {
> > ---
>
> If you run bash with the "-o igncr" option, it will ignore extraneous
> carriage return characters.
>
> But the characters are there in the first place because your
> script has been converted into using Windows line endings:
> carriage return + linefeed.
>
> You didn't say how the script was transferred, but lots
> of programs could add returns when you transfer something
> to windows: git or ftp just to name a few.
>
> You both could try running "bash --version". The first line should
> say something like
> "GNU bash, version 5.2.15(3)-release (x86_64-pc-cygwin)"
>
> Note the "pc-cygwin" at the end.
>
> HTH,
> Mike Gran
>
--
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
Another confusing error from someone else's Cygwin setup
I'm seeing a problem with someone else's Cygwin setup, sort of similar to a
problem I asked about a couple of weeks ago, in that it's a problem with
the same user, but seemingly a completely different problem.
He is using a Bash script that I wrote, and he gets a seemingly nonsensical
error that I don't understand.
The script starts out pretty simply, just like this:
--
#! /bin/bash
#set -x
main() {
if [ "$1" == "" ]; then
usage;
exit;
fi
...
-
He was getting a weird error on line 3, just saying this:
-
...: line 3: syntax error near unexpected token `$'{\r''
...: line 3: `main() {
---
This was pretty perplexing, so I asked him to uncomment the "set -x" line
to see if that provided any useful information, and that fails with a
different error:
---
: invalid option...: line 2: set: -
set: usage: set [-abefhkmnptuvxBCEHPT] [-o option-name] [--] [-] [arg ...]
--
This also makes no sense to me. I compared our "uname -a" outputs, and
they are almost identical. However, I then had him run "bash --version",
and I compared it to mine. Ironically, I'm using an OLDER version of bash
than he is. I'm on v4.4.12(3)-release, and he's on v5.2.15(3)-release. Is
there something in 5.x versions of Bash that could cause these issues?
--
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 test 3.5.0 tar symlinks error messages and failure status
Achim Gratz wrote: > Brian Inglis writes: > > Problem writing tar (with Cygwin default sys) symlinks before target > > created under Cygwin 3.5.0 - error messages are issued and tar exits > > with failure status! > […] > > The only likely culprit between 3.4.6 and that commit seems to be > > commit 2023-04-18 fa84aa4dd2fb43eaf7fcdfb040aef854f2f19d01 Cygwin: fix > > errno values set by readlinkat. > > > > Still seems to work as expected despite the error messages and failure > > status. > > > > Runs without any messages or failure under Cygwin stable 3.4.6. > > The interface mentioned above is known to be wonky on various systems. > You might need to re-build tar in oder for it to detect any changed > level of wonkiness and adapt accordingly. On Cygwin 3.4.7, recompiling tar from the source package fixes this problem; the resulting binary then seems to be fine on Cygwin 3.4.6 as well. Please could tar 1.34 be re-packaged? All best, David -- 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: Trying to figure out what is wrong in a colleague's Cygwin setup
Actually, I was mistaken. I was given incomplete information. I'm getting much of this second hand. Adding that to the PATH made no difference. It appears this is something specific to "kubectl". They ended up setting the KUBECONFIG environment variable to "C:\Users\\.kube\config", which is very odd, as that is basically the default value of it, and I have never set that, and I've never seen this problem. Whatever. They're working now. On Fri, Jun 16, 2023 at 12:17 PM Mike Gran wrote: > > Ok, well, we managed to resolve this, but I don't understand why what we > > did would fix this. > > > In system environment variables in Windows, they added "c:\cygwin64\bin" > to > > the end of the PATH. That fixes the problem. That just doesn't make any > > sense to me. In a Cygwin shell, "/usr/bin" is in the PATH, which is the > > same as "c:\cygwin64\bin". > > Hello David- > The fact that their uname said MINGW implies they weren't running > "real" Cygwin, but, actually MSYS, which is the slightly modified Cygwin > that is bundled with MINGW to allow it to run bash and other > coreutils. > > MSYS has its own location for '/usr/bin', which is probably > c:/msys64/usr/bin or similar. It won't look in c:/cygwin64 by default. > > Just a guess, but, hope this helps. > -Mike Gran > -- 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: Trying to figure out what is wrong in a colleague's Cygwin setup
Ok, well, we managed to resolve this, but I don't understand why what we did would fix this. In system environment variables in Windows, they added "c:\cygwin64\bin" to the end of the PATH. That fixes the problem. That just doesn't make any sense to me. In a Cygwin shell, "/usr/bin" is in the PATH, which is the same as "c:\cygwin64\bin". On Thu, Jun 15, 2023 at 2:07 PM David Karr wrote: > (I replied with this earlier directly to someone who I didn't realize had > only replied to me.) > > I do have a couple other clues that I've noticed while continuing to debug > this. > > This person also has "git bash" installed, which is certainly similar to > Cygwin, but not quite the same. In his gitbash shell, he does not get this > error. > > If it matters, here is the "uname -a" output (hostname elided): > > CYGWIN_NT-10.0-22000 ... 3.4.6-1.x86_64 2023-02-14 13:23 UTC x86_64 > Cygwin > > If it matters, here is the same from his gitbash shell: > > MINGW64_NT-10.0-22000 ... 3.1.7-340.x86_64 2021-03-26 22:17 UTC x86_64 > Msys > > He is running Windows 11 (as I am). > > What else can I try to narrow this down? > > On Tue, Jun 13, 2023 at 2:54 PM David Karr > wrote: > >> I have been using Cygwin for many years, although I wouldn't call myself >> an advanced user. >> >> I'm working with some much newer users. They set up Cygwin, but I didn't >> see them do it. I ran "uname -a" and it was about the same as mine. I >> compared the output of "env|sort" and I saw some differences, but I can't >> tell if they were significant. >> >> When I run the following command: >> >> kubectl config use-context dev2ff >> >> It works perfectly fine, setting the correct context. When this user I'm >> working with runs the same command, he gets this (replacing his userid with >> "..."): >> >> error: FindFirstFile C:\cygwin64\home\.../.kube/config: The directory >> name is invalid. >> >> He did have "HOME=/c/Users/...", but I had him change it to "/home/...", >> but that didn't make any difference. >> >> I'm not sure what could be happening here. >> > -- 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: Trying to figure out what is wrong in a colleague's Cygwin setup
(I replied with this earlier directly to someone who I didn't realize had only replied to me.) I do have a couple other clues that I've noticed while continuing to debug this. This person also has "git bash" installed, which is certainly similar to Cygwin, but not quite the same. In his gitbash shell, he does not get this error. If it matters, here is the "uname -a" output (hostname elided): CYGWIN_NT-10.0-22000 ... 3.4.6-1.x86_64 2023-02-14 13:23 UTC x86_64 Cygwin If it matters, here is the same from his gitbash shell: MINGW64_NT-10.0-22000 ... 3.1.7-340.x86_64 2021-03-26 22:17 UTC x86_64 Msys He is running Windows 11 (as I am). What else can I try to narrow this down? On Tue, Jun 13, 2023 at 2:54 PM David Karr wrote: > I have been using Cygwin for many years, although I wouldn't call myself > an advanced user. > > I'm working with some much newer users. They set up Cygwin, but I didn't > see them do it. I ran "uname -a" and it was about the same as mine. I > compared the output of "env|sort" and I saw some differences, but I can't > tell if they were significant. > > When I run the following command: > > kubectl config use-context dev2ff > > It works perfectly fine, setting the correct context. When this user I'm > working with runs the same command, he gets this (replacing his userid with > "..."): > > error: FindFirstFile C:\cygwin64\home\.../.kube/config: The directory > name is invalid. > > He did have "HOME=/c/Users/...", but I had him change it to "/home/...", > but that didn't make any difference. > > I'm not sure what could be happening here. > -- 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
Trying to figure out what is wrong in a colleague's Cygwin setup
I have been using Cygwin for many years, although I wouldn't call myself an advanced user. I'm working with some much newer users. They set up Cygwin, but I didn't see them do it. I ran "uname -a" and it was about the same as mine. I compared the output of "env|sort" and I saw some differences, but I can't tell if they were significant. When I run the following command: kubectl config use-context dev2ff It works perfectly fine, setting the correct context. When this user I'm working with runs the same command, he gets this (replacing his userid with "..."): error: FindFirstFile C:\cygwin64\home\.../.kube/config: The directory name is invalid. He did have "HOME=/c/Users/...", but I had him change it to "/home/...", but that didn't make any difference. I'm not sure what could be happening here. -- 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: python2 removal
On 1/15/2023 4:52 AM, Jon Turney via Cygwin-apps wrote: net-snmp-python net-snmp David Rothenberger [2] Getting net-snmp to compile is currently beyond me, so please consider it orphaned. -- David Rothenberger daver...@acm.org lighthouse, n.: A tall building on the seashore in which the government maintains a lamp and the friend of a politician.
Re: Mailing list subscription problems
On 12/19/22, Kyle Marek via Cygwin wrote: > (CC'd the public mailing list for visibility of problems that may be > affecting others) > > Hello, > > Today I received an email from cygwin-boun...@cygwin.com with the > subject line of "You have been unsubscribed from the Cygwin mailing > list". I also just noticed that my Cygwin directory doesn't have any > emails since the email identified by the following headers: > > Date: Thu, 24 Nov 2022 00:42:07 -0800 > Message-ID: > Subject: You have been added to Newcommercial08 > From: Newcommercial08 > To: cygwin@cygwin.com > > I'm pretty sure the from address is so bounces are returned to an > address that monitors for bounces. I am guessing that Google has been > bouncing emails from the Cygwin mailing servers, and mailman > automatically unsubscribed me after 25 days of not being able to deliver > a single email to me. However, I am still receiving emails from mailman > itself. > > I re-subscribed, logged into the mailman web interface, and confirming > that I am re-subscribed as of 02:47 UTC. I can see on the online archive > that the mailing list has received emails since then, but I am still not > receiving them. Note that they are NOT being sent to my spam directory. > > So... Are the mailing list emails being bounced by Google? > > Thank you, > Kyle Marek > > -- > 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 > I've experienced the same problem. I reactivated my subscription a couple times. More cygwin mail has been getting through to me that last few days. Hopefully google has relaxed their filtering, David -- 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: dirsfile incorrect on startup?
On 11/12/22, Lester Ingber via Cygwin wrote: > When I login to my cygwin I see > /cygdrive/c/Users/ingber/My: Command not found. > > I have tried to edit my ~/.dirsfile (in /home/ingber/ which is where I > wish to start) but those changes do not persist between login sessions? > > The problem likely stems from may of my files now in a G: drive (a > virtual drive added by Google) that starts at C:/Users/ingber (which I do > not want to land in on login). It may be that windows sets HOMEDRIVE env to G: when you're connected. I don't know the preferred solution. Here are a couple things that may work. You can set HOME env to override, You can also configure your user home in /etc/passwd. I see mention of setting db_home in /etc/nsswitch.conf. David -- 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 malloc crash in gdb
On Tue, 18 Oct 2022 at 20:09, Jon Turney wrote: > > On 18/10/2022 11:35, David Allsopp wrote: > > I'm wondering if I may be able to have some pointers for debugging what > > seems to be an unexpected interaction between mmap/mprotect/munmap and > > malloc with the OCaml runtime. > > > > At the moment, I know that we crash in malloc, so my main question is how to > > go further in gdb. I installed the cygwin-debuginfo package, but all I'm > > getting is: > > Firstly, if the crash is inside the cygwin DLL, you must follow the > advice in [1], and use 'set cygwin-exceptions on' to tell gdb to stop on > an exception inside cygwin itself. > > [1] https://cygwin.com/faq.html#faq.programming.debugging-cygwin > > > > /cygdrive/d/a/scallywag/gdb/gdb-11.2-1.x86_64/src/gdb-11.2/gdb/infrun.c:2550 > > : internal-error: void resume_1(gdb_signal): Assertion > > `pc_in_thread_step_range (pc, tp)' failed. I'm not sure now which combination of stepping directly into the malloc call, adding set cygwin-exceptions on or switching to gdb 12.1, but either way I was able to get to an invalid memory access in mmap_alloc in malloc.cc. At this point, p was a pointer to the start of the 256M block which had been passed to munmap. What I then noticed from that is a bug in our code - the mmap'd region was actually 256M+64K but the size passed to munmap was 256M... so the munmap call was not releasing the entire block. Fixing that on the OCaml side fixes the error completely - I don't know whether what we were seeing before counts as a bug in Cygwin's allocator? Many thanks! David -- 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
Debugging malloc crash in gdb
I'm wondering if I may be able to have some pointers for debugging what
seems to be an unexpected interaction between mmap/mprotect/munmap and
malloc with the OCaml runtime.
At the moment, I know that we crash in malloc, so my main question is how to
go further in gdb. I installed the cygwin-debuginfo package, but all I'm
getting is:
/cygdrive/d/a/scallywag/gdb/gdb-11.2-1.x86_64/src/gdb-11.2/gdb/infrun.c:2550
: internal-error: void resume_1(gdb_signal): Assertion
`pc_in_thread_step_range (pc, tp)' failed.
The reproduction case is below (it's the OCaml runtime, so it's not exactly
minimal, but it seems to be very repeatable to get gdb to the position of
the crash).
In terms of memory, what OCaml is doing:
- At startup, 256M of address space is reserved (with mmap) for garbage
collected minor heaps ("minor arena")
- The first 2M of this is "committed" with mprotect for use by the program's
main thread
- The program then instructs the runtime to double the size of the minor
arena
- The 2M portion is "decommitted" with mprotect
- The 256M mmap'd region is munmap'd
- A new 512M region of address space is reserved
- The first 4M of this is "committed" with mprotect for use by the program's
main thread
- The program performs some assertion checks
- Book-keeping at the end of this causes malloc to be called, which
segfaults.
The crashing call to malloc is the first call to malloc since the 256M ->
512M munmap/map dance.
If the call to caml_mem_unmap at the end of unreserve_minor_heaps in
runtime/domain.c is omitted, then this program succeeds - i.e. malloc does
not appear to crash if the 256M region is left mapped. Obviously, I realise
this may well be unrelated to what's going wrong.
Any assistance to debug this further hugely appreciated!
Thanks,
David
---
Full repro instructions
Cygwin packages required: gcc-core, make, flexdll
Build:
git clone https://github.com/dra27/ocaml -b restore-cygwin-break --depth 1
cd ocaml
./configure --disable-native-compiler --disable-debugger
--disable-ocamldoc && make -j
runtime/ocamlrun.exe ./ocamlc.exe -nostdlib -I stdlib
testsuite/tests/regression/pr9326/gc_set.ml -o gc_set.byte.exe
Crash:
runtime/ocamlrun.exe ./gc_set.byte.exe
Debug:
OCAMLRUNPARAM=v=0x1FFF gdb runtime/ocamlrun.exe
break caml_gc_get
run ./gc_set.byte.exe
continue
break alloc_generic_table
continue
break caml_stat_alloc_noexc
continue
step
step
step
*boom*
--
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: bash from local mounted drive with subst command
We're running into this same issue on my project. We're trying to shorten path names to get around Visual Studio limitations in path lengths, which are unfortunately very long for us since we're generating filenames based on package names and the like. If subst won't work to let us shorten path names, is there any other solution? We'd really like something that behaves like bind mounts rather than symlinks. 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
RE: [ITA] ocaml 4.14.0
Corinna Vinschen wrote: > On Aug 23 20:00, David Allsopp wrote: > > Jon Turney wrote: > > > I'm confused here: /usr/lib/ocaml/camlheaderd[di] look like > > > executables (according to file etc.) > > > > > > If they genuinely aren't, then perhaps they shouldn't have execute > > > permission (which is I think what is causing them to be caught by > > > that piece of code in cygport...) > > > > ocamlc won't care about the executable bit, but these files are _data_ > > and so it will care if they end up with a .exe extension, because they > > are open'd not exec'd. > > > > The files themselves form the start of executables produced by ocamlc. > > For both Cygwin and native Windows, it's a tiny C program responsible > > for locating ocamlrun (on Unix, it's just a shebang line) and the > > bytecode itself gets appended. > > Why is ocaml for Cygwin not produing shebang files as well? After all, > we're trying to be as Unix-compatible as possible. I'm not 100% that this is the correct history, but I think it's down to being able to start the programs from outside a Cygwin bash prompt - i.e. the programs emitted want to have a .exe by default and it's strange to have ".exe" files with a shebang header (at least from outside Cygwin). This part of OCaml is actually old enough (late nineties) that this executable was also used on "real" Unix systems where shebang didn't work properly :) It is possible to configure Cygwin OCaml to use shebang headers (although at the moment only by changing Makefile.config after running configure) All best, David
RE: [ITA] ocaml 4.14.0
Jon Turney wrote:
> On 13/07/2022 16:41, David Allsopp wrote:
> >
> >> 3) Interesting - on my machine, the camlheader[di] files had the .exe
> >> extensions. I did some digging around and found the files are *built*
> >> without the .exe suffix, and even *initially installed* without the
> >> .exe suffix, but ultimately come out with the .exe suffix. I ran
> >> cyport in debug mode and apparently the files are being renamed with
> >> the suffix
> >> post-install:
> >>
> >> + case "${exe##*/}" in
> >> + mv usr/lib/ocaml/camlheaderd usr/lib/ocaml/camlheaderd.exe
> >> + exe+=.exe
> >>
> >> and did a little more digging and I think these lines in cygport are
> >> the
> >> cause:
> >> https://github.com/cygwin/cygport/blob/096f27644bd3b28f29d7522e816beb
> >> d327c
> >> f24cb/lib/src_postinst.cygpart#L1010
>
> Yeah, that seems plausible, but I'm not clear why we are seeing different
> behaviour...
>
> >> On the topic of "testing more thoroughly", I attempted to use ocamlc
> >> to compile a simple program and it fails with "Cannot find file
> >> camlheader" but works when I remove the ".exe", so it seems that the
> >> presence of the .exe suffixes breaks the compiler. Is there a way to
> >> prevent cygport from adding it?
> >
> > The camlheader files are data files and definitely mustn't be
> > installed with a .exe extension (nor do they need to be executable).
>
> I'm confused here: /usr/lib/ocaml/camlheaderd[di] look like executables
> (according to file etc.)
>
> If they genuinely aren't, then perhaps they shouldn't have execute
> permission (which is I think what is causing them to be caught by that
> piece of code in cygport...)
ocamlc won't care about the executable bit, but these files are _data_ and so
it will care if they end up with a .exe extension, because they are open'd not
exec'd.
The files themselves form the start of executables produced by ocamlc. For both
Cygwin and native Windows, it's a tiny C program responsible for locating
ocamlrun (on Unix, it's just a shebang line) and the bytecode itself gets
appended.
All best,
David
RE: [ITA] ocaml 4.14.0
William Hu wrote: > Hi David, > > > What were the missing symbols? With the OCaml 4.10 package, I hit > problems with this: > > > > echo 'print_endline "hello, world"' > hello.ml > > > > ocamlc -custom -runtime-variant _shared -o hello.exe hello.ml > > > > I think that may be an issue upstream (libasmrun_shared.so IIRC is > broken on all platforms - on Cygwin, you can just about to persuade it to > get to the same symbol errors because of the extra .dll.a file which gets > generated). > > It's a very long list of missing symbols (~400) so it's included as an > attachment in case the mailing list truncates extremely lengthy emails. > Also, just to note, the .dll.a file doesn't seem to be automatically > generated by upstream OCaml. I think this down to neglect - the PIC/shared versions of the runtime were contributed for a specific purpose and aren't properly maintained/tested AFAICT. I'm not sure that libcamlrun_shared can ever have worked on Cygwin, at least certainly not since OCaml 3.11 (which is a lng time ago). The patch builds cygcamlrun_shared.dll as a plugin DLL - so the symbols will have been stripped and moved into symtbl (hence the huge number of missing symbols when linking against it when it gets passed to a normal linker). What normally happens with flexlink is that either an executable or a "main program DLL" (compiled with flexlink -maindll) would receive that symtbl from a DLL it flexdll_dlopen's and the DLL receives static_symtbl from the executable. That then means that the DLL can relocate any symbols it expected from the main executable and any other flexdll_dlopen'd DLLs. However, that's all meant to happen at runtime - I don't think flexlink has ever supported compiling an executable _itself_ which must flexdll_dlopen DLLs _before_ its main function. I think it's quite feasible to add that to flexlink, but it's not a small piece of work - in the meantime I'd suggest instead deleting the BYTECODE_SHARED_LIBRARIES += and NATIVE_SHARED_LIBRARIES += lines in runtime/Makefile instead of patching them. > > What's the full configuration command and what gets inferred for the > build, host and target triplets? fma should work without emulation in > Cygwin32 and it should be detecting as failing on Cygwin64 but the > emulation should be enabled by default unless you explicitly passed -- > disable-imprecise-c99-float-ops. > > Configuration command: > ./configure --prefix=/usr --enable-ocamltest > > If it's relevant, I'm compiling on a 64-bit machine with Cygwin32 > installed to compile the 32-bit version. Inferred build/host/target: > configure:2779: Configuring OCaml version 4.14.0 > configure:3007: checking build system type > configure:3021: result: i686-pc-cygwin > configure:3041: checking host system type > configure:3054: result: i686-pc-cygwin > configure:3074: checking target system type > configure:3087: result: i686-pc-cygwin > > On Cygwin64, the test does fail and emulate by default: > > configure:14872: result: no > configure:14896: WARNING: fma does not work; emulation enabled > > However, on Cygwin32, I get > > configure:14872: result: no > configure:14894: error: fma does not work, enable emulation with --enable- > imprecise-c99-float-ops > > config.log conveniently includes the program that fails, so I copy-pasted > some very redundant code (attached) and ran it on the different > architectures: > > Cygwin64: > t264| ans: 0x0p+0 accept: 0x1.0989687cp-1044 0x1.09df287cp-1044 0x1.0ap- > 1044 > t264| pass?: 0 > t265| ans: 0x0p+0 accept: 0x1.0988p-1060 0x1.09ep-1060 0x1.0ap-1060 > t265| pass?: 0 > t266| ans: 0x1p-1074 accept: 0x1p-1073 > t266| pass?: 0 > > Cygwin32: > t264| ans: 0x1.0ap-1044 accept: 0x1.0989687cp-1044 0x1.09df287cp-1044 > 0x1.0ap-1044 > t264| pass?: 1 > t265| ans: 0x1.0ap-1060 accept: 0x1.0988p-1060 0x1.09ep-1060 0x1.0ap- > 1060 > t265| pass?: 1 > t266| ans: 0x1p-1073 accept: 0x1p-1073 > t266| pass?: 1 > > The numbers look like they agree but configure doesn't think so for some > reason. Would you be able to send the entire config.log file (off-list is fine!). I'm not seeing this at all in Cygwin32 here! All best, David
RE: [ITA] ocaml 4.14.0
> 1) libcamlrun: Oops, that's another oversight, forgot to look at the old
> patches. The other 3 patches seem unnecessary, but I had trouble linking
> either libcamlrun_shared.so or libcamlrun_shared.dll.a into a program
> (unresolved symbol errors). Added but it possibly needs further patching.
> I'll keep on digging.
What were the missing symbols? With the OCaml 4.10 package, I hit problems with
this:
echo 'print_endline "hello, world"' > hello.ml
ocamlc -custom -runtime-variant _shared -o hello.exe hello.ml
I think that may be an issue upstream (libasmrun_shared.so IIRC is broken on
all platforms - on Cygwin, you can just about to persuade it to get to the same
symbol errors because of the extra .dll.a file which gets generated).
> 1.5) I checked for other differences between the cygports to make sure I
> didn't miss anything else. I made some edits to src_install: I removed
> `dodoc Updating` since there doesn't seem to be a file named "Updating".
> I also removed symlinking header files to /usr/include. From what I
> understood, the OCaml documentation says the headers should "reside in
> the caml/ subdirectory of the OCaml standard library directory, which is
> returned by the command ocamlc -where (usually /usr/local/lib/ocaml or
> /usr/lib/ocaml)". Obviously the symlink doesn't move anything, but since
> their location is well documented I didn't see a reason to have the extra
> symlinks. Please let me know if this is too large of a change or there's
> a Cygwin (or non-Cygwin) convention that precludes this - I'm still
> getting the hang of this.
> 2) fma on x86: I'm actually getting the same error, but the tests should
> ostensibly pass on Cygwin32. I'll also look into this.
What's the full configuration command and what gets inferred for the build,
host and target triplets? fma should work without emulation in Cygwin32 and it
should be detecting as failing on Cygwin64 but the emulation should be enabled
by default unless you explicitly passed --disable-imprecise-c99-float-ops.
> 3) Interesting - on my machine, the camlheader[di] files had the .exe
> extensions. I did some digging around and found the files are *built*
> without the .exe suffix, and even *initially installed* without the .exe
> suffix, but ultimately come out with the .exe suffix. I ran cyport in
> debug mode and apparently the files are being renamed with the suffix
> post-install:
>
> + case "${exe##*/}" in
> + mv usr/lib/ocaml/camlheaderd usr/lib/ocaml/camlheaderd.exe
> + exe+=.exe
>
> and did a little more digging and I think these lines in cygport are the
> cause:
> https://github.com/cygwin/cygport/blob/096f27644bd3b28f29d7522e816bebd327c
> f24cb/lib/src_postinst.cygpart#L1010
>
> On the topic of "testing more thoroughly", I attempted to use ocamlc to
> compile a simple program and it fails with "Cannot find file camlheader"
> but works when I remove the ".exe", so it seems that the presence of the
> .exe suffixes breaks the compiler. Is there a way to prevent cygport from
> adding it?
The camlheader files are data files and definitely mustn't be installed with a
.exe extension (nor do they need to be executable).
Incidentally, OCaml 4.12+ is also likely to run into problems if flexlink is
older than 0.39 - I just removed the test mark from the flexdll 0.39 package
(which I thought I'd done quite some time ago...)
HTH,
David
mmap failing with MAP_FIXED
This program fails at the second mmap call with EINVAL:
#include
#include
#include
int main (void) {
void * mem;
/* Reserve 256MB address space for the minor heaps */
mem = mmap(0, 268439552, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (mem == MAP_FAILED)
error(1, 0, "Reservation failed");
/* Commit the first 2MB heap */
if (mmap(mem, 2097152, PROT_READ | PROT_WRITE, MAP_PRIVATE |
MAP_ANONYMOUS | MAP_FIXED, -1, 0) == MAP_FAILED)
error(1, 0, "Commit failed");
}
Is this something that's expected to fail for Cygwin, or a bug? The example
is extracted from OCaml 5.0's runtime, which reserves an area of address
space and then commits chunks of it as required. The above snippet comes
from the Linux side, on Windows we're using VirtualAlloc with PAGE_NOACCESS
to reserve the address space and then VirtualAlloc with MEM_COMMIT and
PAGE_READWRITE to commit smaller portions of it.
Is there a way to do that with Cygwin's mmap?
Thanks,
David
--
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 Perl has slowed in recent months
On 5/25/22 08:04, gs-cygwin@gluelogic.com wrote: On Tue, May 24, 2022 at 11:36:21PM -0700, David Christensen wrote: I went back to the desktop computer that I have been using for Cygwin Perl testing: [...] 'make test' produced the following result: 99 wallclock secs ( 1.76 usr 0.41 sys + 342.21 cusr 375.40 csys = 719.78 CPU) [...] I ran Cygwin setup-x86_64.exe version 2.918 and upgraded all Cygwin packages. [...] I ran the cpan(1) shell and upgraded Perl modules: [...] 'make test' now produces: 211 wallclock secs ( 2.39 usr 2.71 sys + 525.68 cusr 998.78 csys = 1529.57 CPU) You have merely demonstrated that there is a change in timing after upgrading *all* of cygwin environment and packages. Basic troubleshooting by any competent admin involves making changes stepwise in steps as small as (reasonably) possible, and reperforming tests each step. Next step: go back to your older system and upgrade only the Perl packages, then repeat the test. If you are capable, try testing your cygwin environment on a different machine, preferably not a corporate machine with hidden BLODA, and with Microsoft Defender disabled (for the tests) (as previously asked by others). If you are capable, try testing older and newer Perl installations on a different OS. Annecdotally, I noticed about month or two ago that running my Perl Test::Harness slowed down dramatically after an upgrade of both kernel and packages on a Linux (*not Cygwin*) system. I have not yet seen compelling evidence from you that the slowdown is due to Cygwin, and have seen data suggesting it is more directly related to Perl changes. Other than your 'make test', do you have any evidence that anything else has slowed down as dramatically between the old and new cywgin packages? Any other shell scripts for which you tested the timing? Any other Perl scripts for which you tested the timing? (and not run under 'make test') I do not have the interest nor the means to bisect Cygwin, Perl, and/or CPAN looking for performance issues. For my use-case (SOHO devops), Cygwin Perl performance is a "nice to have"; not a "must have". "Correctness" is the "must have". I will continue to consider this question: On 5/24/22 08:03, David Christensen wrote: > What is a suitable Perl benchmark? David -- 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 Perl has slowed in recent months
cygwin: I went back to the desktop computer that I have been using for Cygwin Perl testing: motherboard:Intel DQ67SW processor: Intel Core i7-2600S memory: Corsair CMV8GX3M2A1333C9 2 @ 4 GB disk: Intel SSD 520 Series 180 GB OS Name:Microsoft Windows 7 Professional OS Version: 6.1.7601 Service Pack 1 Build 7601 See cygcheck-old.txt in the attached tarball for a listing of Cygwin packages installed. 'make test' produced the following result: 99 wallclock secs ( 1.76 usr 0.41 sys + 342.21 cusr 375.40 csys = 719.78 CPU) I ran Windows Update, which indicated one optional update was available (Windows Defender). I installed the update. I ran Cygwin setup-x86_64.exe version 2.918 and upgraded all Cygwin packages. See cygcheck-new.txt in the attached tarball for a listing of current Cygwin packages installed. I ran the cpan(1) shell and upgraded Perl modules: cpan[1]> upgrade /(.*)/ See cpan-upgrade.txt and current-perl-modules.txt in the attached tarball for a listing of Perl modules that were out-of-date and a listing of the current Perl modules installed. 'make test' now produces: 211 wallclock secs ( 2.39 usr 2.71 sys + 525.68 cusr 998.78 csys = 1529.57 CPU) David cygwin-20220524-2330.tar.gz Description: application/gzip -- 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 Perl has slowed in recent months
On 5/24/22 08:59, Sam Edge wrote: On 24/05/2022 16:03, David Christensen wrote: On 5/24/22 01:47, Sam Edge wrote: On 24/05/2022 09:25, Csaba Raduly wrote: > On Mon, 23 May 2022 at 20:47, Lee wrote: >> >> On 5/22/22, David Christensen wrote: >>> On 5/21/22 10:55, Hans-Bernhard Bröker wrote: >>>> Am 18.05.2022 um 03:53 schrieb David Christensen: >>>> >>>> > I am working on a Perl module that runs on various Unix-like platforms. >>>> > When I 'make test' on similar computers: >>>> > >>>> > FreeBSD 12.3-RELEASE 28 wallclock secs >>>> > Debian GNU/Linux 11.3 31 wallclock secs >>>> > macOS 11.6.2 36 wallclock secs >>>> > Windows 7 / Cygwin 3.3.5-1 509 wallclock secs >>>> >>>> Given the complete lack of information about what that Perl module of >>>> yours might be doing, that's hard to have a meaningful discussion about. >>> >>> >>> Thank you for the response. I was hoping there was a known issue. >>> Apparently, not. >> >> What I consider a well known issue is that process start up time is >> _very_ slow. If your 'make test' starts lots of processes that could >> be a problem. >> > > While Cygwin''s fork emulation is indeed slow (I once measured 1000:1 > between Cygwin and Linux * ), > "make test" likely started roughly the same number of processes "then" > as it does "now". > In which case the increase in the run time could be attributed to Cygwin. Indeed. But perhaps what the Cygwin core and/or Cygwin Perl maintainers need is a simple test case Perl script that can be shown to be much slower on the current releases than it was on a named earlier pair of releases. And maybe some testing by the original poster to see if it is the Cygwin or Perl release change that causes the issue. Anecdotal observations do not an issue report make. ;-) So, we are discussing running a Perl benchmark for various combinations of Cygwin version and/or Cygwin Perl version. That is an O(n) and/or O(n**2) problem. If multiple benchmarks are considered, increase the O() exponent by one. If multiple versions of Windows are considered, increase the O() exponent by one. If multiple computers are considered, increase the O() exponent by one. Does the Cygwin project do any of the above? If so, how? Where are the test plans and assets? Where is the raw data? Where are the reports? If end users are expected to do the above, please advise: 1. How to install multiple versions of Cygwin on Windows 7 Professional 64-bit Service Pack 1 on an x86_64 computer such that each instance of Cygwin does not interact with any other instance of Cygwin. 2. How to install multiple versions of Cygwin Perl on each of many Cygwin installations on Windows 7 Professional 64-bit Service Pack 1 on an x86_64 computer such that each instance of Cygwin Perl does not interact with any other instance of Cygwin Perl or Cygwin. 3. What is a suitable Perl benchmark? David The Cygwin core & Perl maintainers do not get paid for their work. I do not get paid for working on Cygwin and/or Perl. But, I have been paid for using and programming both. If you believe you have spotted a regression, it's up to you to isolate at what revision of Perl or of Cygwin core it started to happen. If Cygwin provides me with the means; fair enough. You can get older revisions of Cygwin & Perl from the Cygwin Time Machine (GFGI). https://html.duckduckgo.com/html?q=site%3Acygwin.org%20cygwin%20time%20machine https://cygwin.cygwin.narkive.com/cSRkGFjw/time-machine http://www.fruitbat.org/Cygwin/index.html#cygwincirca http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html I built a similar hack years ago. GFGI Programming Systems Product You can have as many parallel installations of Cygwin and its packages as you like simply by specifying different install paths when running the setup program (RTFM). Section? Page? Like most FOSS, Cygwin & its packages are provided with no warranty. https://cygwin.org/faq.html#faq.what.free If they are so vital to your business, you need to be doing regression testing yourself before upgrading production systems Have you been spying on me? ;-) and maintaining your own Cygwin repo so you have a copy of the production releases. https://cygwin.org/faq.html#faq.what.version https://cygwin.org/faq.html#faq.setup.old-versions I would say "disappointing", but I think you found the answer (below). This is all SOP for using FOSS in a business context, TIMTOWTDI. unless you're willing to pay someone else to do it for you, which is how Red Hat et al make their money. I think you have found the answer. David -- 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 Perl has slowed in recent months
On 5/24/22 01:47, Sam Edge wrote: On 24/05/2022 09:25, Csaba Raduly wrote: > On Mon, 23 May 2022 at 20:47, Lee wrote: >> >> On 5/22/22, David Christensen wrote: >>> On 5/21/22 10:55, Hans-Bernhard Bröker wrote: >>>> Am 18.05.2022 um 03:53 schrieb David Christensen: >>>> >>>> > I am working on a Perl module that runs on various Unix-like platforms. >>>> > When I 'make test' on similar computers: >>>> > >>>> > FreeBSD 12.3-RELEASE 28 wallclock secs >>>> > Debian GNU/Linux 11.3 31 wallclock secs >>>> > macOS 11.6.2 36 wallclock secs >>>> > Windows 7 / Cygwin 3.3.5-1 509 wallclock secs >>>> >>>> Given the complete lack of information about what that Perl module of >>>> yours might be doing, that's hard to have a meaningful discussion about. >>> >>> >>> Thank you for the response. I was hoping there was a known issue. >>> Apparently, not. >> >> What I consider a well known issue is that process start up time is >> _very_ slow. If your 'make test' starts lots of processes that could >> be a problem. >> > > While Cygwin''s fork emulation is indeed slow (I once measured 1000:1 > between Cygwin and Linux * ), > "make test" likely started roughly the same number of processes "then" > as it does "now". > In which case the increase in the run time could be attributed to Cygwin. Indeed. But perhaps what the Cygwin core and/or Cygwin Perl maintainers need is a simple test case Perl script that can be shown to be much slower on the current releases than it was on a named earlier pair of releases. And maybe some testing by the original poster to see if it is the Cygwin or Perl release change that causes the issue. Anecdotal observations do not an issue report make. ;-) So, we are discussing running a Perl benchmark for various combinations of Cygwin version and/or Cygwin Perl version. That is an O(n) and/or O(n**2) problem. If multiple benchmarks are considered, increase the O() exponent by one. If multiple versions of Windows are considered, increase the O() exponent by one. If multiple computers are considered, increase the O() exponent by one. Does the Cygwin project do any of the above? If so, how? Where are the test plans and assets? Where is the raw data? Where are the reports? If end users are expected to do the above, please advise: 1. How to install multiple versions of Cygwin on Windows 7 Professional 64-bit Service Pack 1 on an x86_64 computer such that each instance of Cygwin does not interact with any other instance of Cygwin. 2. How to install multiple versions of Cygwin Perl on each of many Cygwin installations on Windows 7 Professional 64-bit Service Pack 1 on an x86_64 computer such that each instance of Cygwin Perl does not interact with any other instance of Cygwin Perl or Cygwin. 3. What is a suitable Perl benchmark? David -- 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 Perl has slowed in recent months
On 5/23/22 11:47, Lee wrote: On 5/22/22, David Christensen wrote: On 5/21/22 10:55, Hans-Bernhard Bröker wrote: Am 18.05.2022 um 03:53 schrieb David Christensen: > I am working on a Perl module that runs on various Unix-like platforms. > When I 'make test' on similar computers: > > FreeBSD 12.3-RELEASE 28 wallclock secs > Debian GNU/Linux 11.3 31 wallclock secs > macOS 11.6.2 36 wallclock secs > Windows 7 / Cygwin 3.3.5-1509 wallclock secs I was hoping there was a known issue. What I consider a well known issue is that process start up time is _very_ slow. If your 'make test' starts lots of processes that could be a problem. [Replying to off-list message.] Thank you for the reply. 'make test' starts a large number of processes -- perhaps a thousand. Another huge slowdown is Windows Defender. Try turning that off and seeing how long your 'make test' takes then. Of all the test scripts, 02-compile.t consumes the most time on all platforms. Using 02-compile.t as a benchmark, here is the compile time with Windows Defender enabled: $ time perl -Ilib t/02-compile.t real2m1.404s user3m20.490s sys 4m24.476s Here is the compile time with Windows Defender disabled: $ time perl -Ilib t/02-compile.t real1m56.606s user3m14.374s sys 4m20.106s Both of the above tests were run in Cygwin64 Terminal. Using Debian and SSH: $ time perl -Ilib t/02-compile.t real1m18.733s user2m32.187s sys 2m29.652s So, Cygwin64 Terminal is also a problem. In all cases, Resource Monitor indicates the script is CPU bound. David -- 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 Perl has slowed in recent months
On 5/21/22 10:55, Hans-Bernhard Bröker wrote: Am 18.05.2022 um 03:53 schrieb David Christensen: > I am working on a Perl module that runs on various Unix-like platforms. > When I 'make test' on similar computers: > > FreeBSD 12.3-RELEASE 28 wallclock secs > Debian GNU/Linux 11.3 31 wallclock secs > macOS 11.6.2 36 wallclock secs > Windows 7 / Cygwin 3.3.5-1 509 wallclock secs Given the complete lack of information about what that Perl module of yours might be doing, that's hard to have a meaningful discussion about. Thank you for the response. I was hoping there was a known issue. Apparently, not. The above module is proprietary, so I thought I would profile some similar CPAN modules to generate discussion information: 2022-05-22 01:25:39 dpchrist@dht4s3r1 ~ $ systeminfo | egrep '^OS (Name|Version)' ; uname -a ; cygcheck -c cygwin OS Name: Microsoft Windows 7 Professional OS Version:6.1.7601 Service Pack 1 Build 7601 CYGWIN_NT-6.1-7601 dht4s3r1 3.3.5-341.x86_64 2022-05-13 12:27 UTC x86_64 Cygwin Cygwin Package Information Package VersionStatus cygwin 3.3.5-1OK 2022-05-22 01:26:45 dpchrist@dht4s3r1 ~ $ cpan install Devel::NYTProf t/50-errno.t . 1/8 # Failed test '$! should not be altered by NYTProf i/o' # at t/50-errno.t line 58. # got: '0' # expected: '3' # Looks like you failed 1 test of 8. t/50-errno.t . Dubious, test returned 1 (wstat 256, 0x100) Failed 1/8 subtests Test Summary Report --- t/50-errno.t (Wstat: 256 Tests: 8 Failed: 1) Failed test: 6 Non-zero exit status: 1 Files=55, Tests=4736, 570 wallclock secs ( 0.64 usr 1.06 sys + 104.19 cusr 403.73 csys = 509.62 CPU) Result: FAIL Failed 1/55 test programs. 1/4736 subtests failed. make: *** [Makefile:1284: test_dynamic] Error 255 JKEENAN/Devel-NYTProf-6.11.tar.gz /usr/bin/make test -- NOT OK //hint// to see the cpan-testers results for installing this module, try: reports JKEENAN/Devel-NYTProf-6.11.tar.gz STFW: https://github.com/Perl/perl5/issues/12389 Any suggestions? David -- 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 Perl has slowed in recent months
cygwin: I have a computer: 2022-05-17 18:46:12 dpchrist@dht4s3r1 ~/src/perl/Dpchrist-Perl $ systeminfo | egrep '^OS (Name|Version)' ; uname -a ; cygcheck -c cygwin OS Name: Microsoft Windows 7 Professional OS Version:6.1.7601 Service Pack 1 Build 7601 CYGWIN_NT-6.1 dht4s3r1 3.3.5(0.341/5/3) 2022-05-13 12:27 x86_64 Cygwin Cygwin Package Information Package VersionStatus cygwin 3.3.5-1OK I am working on a Perl module that runs on various Unix-like platforms. When I 'make test' on similar computers: FreeBSD 12.3-RELEASE 28 wallclock secs Debian GNU/Linux 11.331 wallclock secs macOS 11.6.2 36 wallclock secs Windows 7 / Cygwin 3.3.5-1 509 wallclock secs A few months ago, I seem to recall that Cygwin was about 4 times slower. Now it is over 14 times slower. Is this expected? If not, how do I find the bottleneck? TIA, David -- 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
alternatives package dose not install /sbin executables
Due to security I had to remove some lines from cygcheck report I successfully installed: alternatives1.3.30c-10 OK According to the alternatives package file list I should have the following executables installed: alternatives.exe and update-alternatives.exe, see sbin.log I checked my /sbin directory after installation and the two files for alternatives were not installed: see attached file, cygcheck.log sbin.log Description: sbin.log cygcheck.log Description: cygcheck.log -- 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] cygwin 3.3.4-1
For those of us who are experiencing this problem, what is the actual method of resolving this problem? It's not obvious to me. THANKS David Schuler On 1/31/2022 5:20 PM, Adam Dinwoodie wrote: On Mon, Jan 31, 2022 at 06:49:01PM +, Allen Hewes wrote: From: Cygwin On Behalf Of David Rothenberger Sent: Monday, January 31, 2022 1:39 PM To: cygwin@cygwin.com Subject: Re: [ANNOUNCEMENT] cygwin 3.3.4-1 On 1/31/2022 10:34 AM, Jim Reisert AD1C wrote: The following packages have been uploaded to the Cygwin distribution: * cygwin-3.3.4-1 * cygwin-devel-3.3.4-1 * cygwin-doc-3.3.4-1 I've tried two mirrors, both with the same result: dash.exe - Bad Image C:\Cygwin64\bin\cygwin1.dll is either not designed to run on Windows or it contains an errorError status 0xc07b. I'm running Windows 11 Pro (21H2), OS Build 22000.469 The previous version has been working just fine. I saw the same errors this morning with Windows 10 Pro for Workstations (10.0.19044). I also tried two mirrors. I ended up rolling back to the previous version as well. Same here. There's something amiss with 3.3.4-1, IMHO. I grabbed the XZ's manually from mirrors.dotsrc.org. Windows 10 Pro Microsoft Windows [Version 10.0.19044.1503] Working Cygwin: CYGWIN_NT-10.0-19044 FOUREYES 3.3.3-341.x86_64 2021-12-03 16:35 UTC x86_64 Cygwin Replying here to close the loop on this thread: I suspect this is now fixed in the 3.3.4-2 release: https://cygwin.com/pipermail/cygwin-announce/2022-January/010439.html -- 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] cygwin 3.3.4-1
On 1/31/2022 10:34 AM, Jim Reisert AD1C wrote: The following packages have been uploaded to the Cygwin distribution: * cygwin-3.3.4-1 * cygwin-devel-3.3.4-1 * cygwin-doc-3.3.4-1 I've tried two mirrors, both with the same result: dash.exe - Bad Image C:\Cygwin64\bin\cygwin1.dll is either not designed to run on Windows or it contains an errorError status 0xc07b. I'm running Windows 11 Pro (21H2), OS Build 22000.469 The previous version has been working just fine. I saw the same errors this morning with Windows 10 Pro for Workstations (10.0.19044). I also tried two mirrors. I ended up rolling back to the previous version as well. -- David Rothenberger daver...@acm.org Doubt is not a pleasant condition, but certainty is absurd. -- Voltaire -- 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 setup writing incorrect symlinks for native
Jon Turney wrote: > On 09/01/2022 09:35, David Allsopp wrote: > > Jon Turney wrote: > >> On 06/01/2022 16:45, David Allsopp wrote: > >>> Jon Turney wrote: > >>>> On 06/01/2022 10:46, David Allsopp wrote: > >>>>> Running Cygwin setup 2.912 with --symlink-type native (or > >>>>> CYGWIN=winsymlinks:native) is not correctly translating all > symlinks. > >>>>> A default install has these faulty ones: > >>>>> > >>>>> /etc/pki/tls/cert.pem -> > >>>>> \??\/etc\pki\ca-trust\extracted\pem\tls-ca-bundle.pem > >>>>> /etc/pki/tls/certs/ca-bundle.crt -> > >>>>> \??\/etc\pki\ca-trust\extracted\pem\tls-ca-bundle.pem > >>>>> /etc/pki/tls/certs/ca-bundle.trust.crt -> > >>>>> \??\/etc\pki\ca-trust\extracted\openssl\ca-bundle.trust.crt > >>>>> /etc/ssl/certs -> \??\/etc\pki\tls\certs /lib/security/cacerts -> > >>>>> \??\/etc\pki\ca-trust\extracted\java\cacerts > >>>>> /usr/share/doc/groff-1.22.4/pdf/mom-pdf.pdf -> > >>>>> \??\/usr\share\doc\groff-1.22.4\examples\mom\mom-pdf.pdf > >>>> > >>>> > [...] > >> > >> Thanks for testing. It seems I still didn't have this quite right > >> and these symlinks just happened to work for cygwin, but not native > tools. > >> > >> Please try > >> > >> https://cygwin.com/setup/setup-2.914.x86_64.exe > >> https://cygwin.com/setup/setup-2.914.x86.exe > > > > I'm afraid that's just changed the \??\ to \\?\ on those symlinks. > > Well, that has the advantage of being correct :) > > (since it's the 'Win32 File Namespace' prefix, which > CreateSymbolicLinkW() is documented to accept for the target filename, and > is required when that exceeds MAX_PATH (260) characters) > > In my (brief) testing, e.g. the CMD builtin 'type' is able to open > symlinks of this form. However, it seems there are some parts of Windows > (e.g. DIR, File Explorer), which don't handle symlinks like that well. > > So, I've copied the behaviour of the cygwin DLL, which avoids using that > prefix if the target is less than MAX_PATH characters. This seem to work > better in those cases with typical paths (but I'd claim we're just working > around a bug in Windows here, as things will still be broken if the cygwin > root is a path long enough that we can't do that). > > Please try: > >https://cygwin.com/setup/setup-2.915.x86_64.exe >https://cygwin.com/setup/setup-2.915.x86.exe That's working (for cmd as well), thanks! David -- 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
Inconsistent results from ls
Folks I tried executing 'ls -l' on a file. I addressed the file in various ways, with my current directory (in Windows) set to c:\temp ls -l test.txt ls -l /cygdrive/c/temp/test.txt ls -l ls -l * ls -l c:/temp/test.txt In all cases, the owner, group, date and size are the same, as I would hope them to be. However, the last result showed a mode setting displayed was different than the value shown in the others. This doesn't seem right, and I'm not sure what the correct value should be. Any ideas? David Pasted from my example, with the name of the owner changed to "myself": c:\temp>ls -l test.txt -rwxrwx---+ 1 myself None 14 Jan 11 18:23 test.txt c:\temp>ls -l /cygdrive/c/temp/test.txt -rwxrwx---+ 1 myself None 14 Jan 11 18:23 /cygdrive/c/temp/test.txt c:\temp>ls -l total 1 -rwxrwx---+ 1 myself None 14 Jan 11 18:23 test.txt c:\temp>ls -l * -rwxrwx---+ 1 myself None 14 Jan 11 18:23 test.txt c:\temp>ls -l c:/temp/test.txt -rw-r--r-- 1 myself None 14 Jan 11 18:23 c:/temp/test.txt c:\temp> -- 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 setup writing incorrect symlinks for native
Jon Turney wrote: > On 06/01/2022 16:45, David Allsopp wrote: > > Jon Turney wrote: > >> On 06/01/2022 10:46, David Allsopp wrote: > >>> Running Cygwin setup 2.912 with --symlink-type native (or > >>> CYGWIN=winsymlinks:native) is not correctly translating all symlinks. > >>> A default install has these faulty ones: > >>> > >>> /etc/pki/tls/cert.pem -> > >>> \??\/etc\pki\ca-trust\extracted\pem\tls-ca-bundle.pem > >>> /etc/pki/tls/certs/ca-bundle.crt -> > >>> \??\/etc\pki\ca-trust\extracted\pem\tls-ca-bundle.pem > >>> /etc/pki/tls/certs/ca-bundle.trust.crt -> > >>> \??\/etc\pki\ca-trust\extracted\openssl\ca-bundle.trust.crt > >>> /etc/ssl/certs -> \??\/etc\pki\tls\certs /lib/security/cacerts -> > >>> \??\/etc\pki\ca-trust\extracted\java\cacerts > >>> /usr/share/doc/groff-1.22.4/pdf/mom-pdf.pdf -> > >>> \??\/usr\share\doc\groff-1.22.4\examples\mom\mom-pdf.pdf > >> > >> > >> Thanks for reporting this. > >> > >> Yes, it seems this is messed up where the target of the symlink is an > >> absolute path. > >> > >> I've uploaded setup 2.913 with an attempted fix. > >> > >> https://cygwin.com/setup/setup-2.913.x86_64.exe > >> https://cygwin.com/setup/setup-2.913.x86.exe > >> > >> Please try that (you'll have to reinstall the effected packages), and > >> see if it improves things for you? > > > > Thank you! This fixes it for the Cygwin side, although the symlinks are > > still technically not right from the Windows side. They're still showing > > up prefixed \??\. > > > > It's an age since I mucked around with those functions - IIRC the API > > function for writing them adds the \??\ itself and doesn't expect it > > to have been supplied? However, when you read the reparse point you > > have to remember to remove it yourself because who needs consistency > > :o) > > Thanks for testing. It seems I still didn't have this quite right and > these symlinks just happened to work for cygwin, but not native tools. > > Please try > >https://cygwin.com/setup/setup-2.914.x86_64.exe >https://cygwin.com/setup/setup-2.914.x86.exe I'm afraid that's just changed the \??\ to \\?\ on those symlinks. All best, David -- 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 setup writing incorrect symlinks for native
Jon Turney wrote: > On 06/01/2022 10:46, David Allsopp wrote: > > Running Cygwin setup 2.912 with --symlink-type native (or > > CYGWIN=winsymlinks:native) is not correctly translating all symlinks. > > A default install has these faulty ones: > > > > /etc/pki/tls/cert.pem -> > > \??\/etc\pki\ca-trust\extracted\pem\tls-ca-bundle.pem > > /etc/pki/tls/certs/ca-bundle.crt -> > > \??\/etc\pki\ca-trust\extracted\pem\tls-ca-bundle.pem > > /etc/pki/tls/certs/ca-bundle.trust.crt -> > > \??\/etc\pki\ca-trust\extracted\openssl\ca-bundle.trust.crt > > /etc/ssl/certs -> \??\/etc\pki\tls\certs /lib/security/cacerts -> > > \??\/etc\pki\ca-trust\extracted\java\cacerts > > /usr/share/doc/groff-1.22.4/pdf/mom-pdf.pdf -> > > \??\/usr\share\doc\groff-1.22.4\examples\mom\mom-pdf.pdf > > > Thanks for reporting this. > > Yes, it seems this is messed up where the target of the symlink is an > absolute path. > > I've uploaded setup 2.913 with an attempted fix. > >https://cygwin.com/setup/setup-2.913.x86_64.exe >https://cygwin.com/setup/setup-2.913.x86.exe > > Please try that (you'll have to reinstall the effected packages), and see > if it improves things for you? Thank you! This fixes it for the Cygwin side, although the symlinks are still technically not right from the Windows side. They're still showing up prefixed \??\. It's an age since I mucked around with those functions - IIRC the API function for writing them adds the \??\ itself and doesn't expect it to have been supplied? However, when you read the reparse point you have to remember to remove it yourself because who needs consistency :o) C:\cygwin64>dir /s | findstr ?? 01/06/2022 04:30 PM cert.pem [\??\C:\cygwin64\etc\pki\ca-trust\extracted\pem\tls-ca-bundle.pem] 01/06/2022 04:30 PM ca-bundle.crt [\??\C:\cygwin64\etc\pki\ca-trust\extracted\pem\tls-ca-bundle.pem] 01/06/2022 04:30 PM ca-bundle.trust.crt [\??\C:\cygwin64\etc\pki\ca-trust\extracted\openssl\ca-bundle.trust.crt] 01/06/2022 04:30 PM certs [\??\C:\cygwin64\etc\pki\tls\certs] 01/06/2022 04:30 PM cacerts [\??\C:\cygwin64\etc\pki\ca-trust\extracted\java\cacerts] 01/06/2022 04:30 PM mom-pdf.pdf [\??\C:\cygwin64\usr\share\doc\groff-1.22.4\examples\mom\mom-pdf.pdf] All best, David -- 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 setup writing incorrect symlinks for native
Running Cygwin setup 2.912 with --symlink-type native (or CYGWIN=winsymlinks:native) is not correctly translating all symlinks. A default install has these faulty ones: /etc/pki/tls/cert.pem -> \??\/etc\pki\ca-trust\extracted\pem\tls-ca-bundle.pem /etc/pki/tls/certs/ca-bundle.crt -> \??\/etc\pki\ca-trust\extracted\pem\tls-ca-bundle.pem /etc/pki/tls/certs/ca-bundle.trust.crt -> \??\/etc\pki\ca-trust\extracted\openssl\ca-bundle.trust.crt /etc/ssl/certs -> \??\/etc\pki\tls\certs /lib/security/cacerts -> \??\/etc\pki\ca-trust\extracted\java\cacerts /usr/share/doc/groff-1.22.4/pdf/mom-pdf.pdf -> \??\/usr\share\doc\groff-1.22.4\examples\mom\mom-pdf.pdf In particular, we noticed that /etc/ssl/certs being invalid breaks git. David -- 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: lost of admin right
You need --no-admin option to setup if you don't have administrative privileges, if that's all you're after. If you are asking how to modify/update your existing installation that was installed as administrator, that might be impossible, if you no longer have privileges there. Regards, David -Original Message- From: Cygwin On Behalf Of Sharuzzaman Ahmat Raslan Sent: 14 December 2021 14:10 To: e...@iol.it Cc: The Cygwin Mailing List Subject: Re: lost of admin right Hi Valerio, Have you tried using the "-B" command line option when running setup-x86_64.exe ? Thank you. On Tue, Dec 14, 2021 at 9:33 PM Valerio Messina via Cygwin < cygwin@cygwin.com> wrote: > hi, > I have a company PC where I was admin and installed Cygwin in a non > supported path: > D:\Program Files (x86)\cygwin64 > /cygdrive/d/Program Files (x86)/cygwin64 and worked like a sharm for > years, with a quite complex env. > > Now admin right was revoked to me, and the update via setup.exe cannot > proceed. > I can ask to the company admin to update the distribution every time, > but this is impractical. > > 1) Do you know if re-installing to supported path something like: > D:\ProgramFiles\cygwin64 > /cygdrive/d/ProgramFiles/cygwin64 > let me update the distro without admin right? > > I made a backup of the about 800 installed packages with: > $ cygcheck -c -d | cut -d' ' -f1 | tail -n+3 > > installedPackages2021-12.txt I never tryed to restore the backup with: > $ setup -M -P package1,package2, ... > > 2) Someone know if that work well ? > > thank you, > -- > Valerio > > -- > 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 > -- Sharuzzaman Ahmat Raslan -- 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
[ANNOUNCEMENT] nmh 1.7.1-2
The following packages have been uploaded to the Cygwin distribution: * nmh-1.7.1-2 A capable MIME-email-handling system with a command-line interface. nmh is a collection of single-purpose programs that send, receive, show, search, and otherwise manipulate emails, including MIME. They combine well with other Unix programs, easing the development of custom shorthand commands as shell scripts. Optional GUI interfaces are provided by the external xmh and exmh projects. nmh is a descendant of the RAND MH, Mail Handler, project. Rebuilt package to try to remove dependency on libopenssl100. -- 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
nmh 1.7.1-2
The following packages have been uploaded to the Cygwin distribution: * nmh-1.7.1-2 A capable MIME-email-handling system with a command-line interface. nmh is a collection of single-purpose programs that send, receive, show, search, and otherwise manipulate emails, including MIME. They combine well with other Unix programs, easing the development of custom shorthand commands as shell scripts. Optional GUI interfaces are provided by the external xmh and exmh projects. nmh is a descendant of the RAND MH, Mail Handler, project. Rebuilt package to try to remove dependency on libopenssl100.
Re: emacs 28.0.60-1.f7e6c199bf (TEST)
On 14/10/2021 07:22, Jim Reisert AD1C wrote: I have noticed one slight performance issue, which may not be related to Cygwin at all. After creating a keyboard macro, the first time the macro is used/called (^x^e), it does not start right away. Subsequent uses are as fast as expected. Could some sort of run-time compilation going on in the background before the keyboard macro executes the first time? As I said, this may not be related to Cygwin at all. This is mentioned in the announcement for emacs 28.0.60-1.f7e6c199bf (TEST) The first few times you run Emacs, it might seem slow to start. This is because it is compiling the elisp libraries that are needed for your init file (usually .emacs). For the same reason, you might see occasional pauses the first time you use a command. But otherwise you should see a noticeable speed-up of Emacs. -- 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
tcl3270 failure in new Cygwin install
I just performed a new Cygwin install (32 bit) and chose to install package tcl3270, version 3.3.15ga9-1. Installation of Cygwin, tcl3270 prerequisites, and tcl3270 completed successfully, but when I run tcl3270.exe within Cygwin I get the following error. C:/cygwin/bin/tcl3270.exe: error while loading shared libraries: libtcl8.5.dll: cannot open shared object file: No such file or directory In Cygwin setup, it shows that tcl 8.6.11-1 is installed. I suspect that tcl3270 needs to be compiled against the new tcl package. Is the tcl3270 package still maintained, and if so, can the package maintainer compile against tcl 8.6.11.1 (assuming this is the problem)? Thanks, David -- 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
Request for catalogue
Hello cygwin@cygwin.com I am David from IMEX sourcing company. Our customer finds your product interesting, as such we request that you send an official catalogue so we can send PO. Also be informed that our company charges 4% of the value of goods bought from the supplier which will be included in the proforma invoice. Thanks and best regards. we await your earliest reply. David Liu IMEX Sourcing service E-mail: o-lightin...@ovovs.com mailto:o-lightin...@ovovs.com Phone: +86 1326532 2461 Wechat: markkyyo https://imexsourcingservices.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
Duplicates in /proc/partitions
Before, during and after plugging in a n USB stick: $ cat /proc/partitions major minor #blocks name win-mounts 8 0 1000204632 sda 8 1102400 sda1 8 2 16384 sda2 8 3 999571820 sda3 C:\ 8 4510976 sda4 $ cat /proc/partitions major minor #blocks name win-mounts 8 0 1000204632 sda 8 1102400 sda1 8 2 16384 sda2 8 3 999571820 sda3 C:\ 8 4510976 sda4 816 62522712 sdb 817 4096000 sdb1 D:\ 818 58424664 sdb2 816 62522712 sdb 817 4096000 sdb1 D:\ 818 58424664 sdb2 E:\ $ cat /proc/partitions major minor #blocks name win-mounts 8 0 1000204632 sda 8 1102400 sda1 8 2 16384 sda2 8 3 999571820 sda3 C:\ 8 4510976 sda4 816 62522712 sdb 817 4096000 sdb1 D:\ 818 58424664 sdb2 E:\ So the second listing shows sdb twice. Also E: does not seem to exist (see below). After that I run: $ cygcheck -s -v -r > cygcheck.out cygcheck: dump_sysinfo: GetVolumeInformation() for drive E: failed: 1005 In attached cygcheck.out i swapped out company name and abbreviation with . Windows sees no E: drive: DISKPART> list volume Volume ### Ltr LabelFs TypeSize Status Info -- --- --- - -- --- - Volume 0 CNTFS Partition953 GB HealthyBoot Volume 1 FAT32 Partition100 MB HealthySystem Volume 2 NTFS Partition499 MB HealthyHidden Volume 3 D FFT2 FATRemovable 4000 MB Healthy (there is no mention of E: in Disk Management GUI either) Regards, David -- 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: many cygwin shells/tools (tcsh, fish, bash, and zsh) crashing STATUS_ACCESS_VIOLATION
On Wed, Aug 11, 2021 at 10:10 PM Mark Geisert wrote: > > Hi David, > > David Dyck via Cygwin wrote: > > First, thanks for digging further into this. > > > > I'm guessing that I am missing some of the developer pieces that > > assisted you in deducing from > > No problem. I was curious about the possible Win 11 Preview connection and > happened to have a bit of free time to investigate. Installing the > ncurses-debuginfo package gave me debugging symbols for use with gdb. > Calculating > minus from your strace gave me the > offset > into the ncurses DLL of the exception on your system. Then on my own system I > have a different but adding the offset gives me the > corresponding on my own system. The rest was using gdb. > Thank you, I appreciate your contributing to my education. > I didn't consider that your original libncursesw-10.dll might have been > damaged. > I was kinda fixated on the possibility of Win 11 Preview brokenness ;-). > That's right, you're back to the version you started with but things are > working > now. I'm now inclined to think your original ncurses DLL was damaged > somehow. I > don't know how deeply 'cygcheck -c' checks a package.. It can tell when > individual > files are missing from the package but I don't know if it checksums the > files, for > instance, to discover individual file damage. Maybe there's an opportunity to have cygcheck include a checksum of each file in its report - but too late now. > I don't think there's anything more to do here but run your working system > :-). Thank you, I am doing just that! David -- 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: many cygwin shells/tools (tcsh, fish, bash, and zsh) crashing STATUS_ACCESS_VIOLATION
First, thanks for digging further into this. I'm guessing that I am missing some of the developer pieces that assisted you in deducing from On Tue, Aug 10, 2021 at 10:28 PM Mark Geisert wrote: > > Replying to myself, ahem... > > Mark Geisert wrote: > > You could try downgrading ncurses via Cygwin setup. Best case: things > > work. Worst > > case: things break but at a different address within the DLL. > > On another branch of this thread David reported that downgrading worked. We > still > don't know what the issue with current ncurses is, so I did try the following: > > > Another tack could be for somebody *on a working system* install the > > debuginfo for > > ncurses, figure out the exception's address *in the ncurses installed > > locally*, > > run 'more' under gdb after setting a breakpoint at that address. Poke > > around to > > see what ncurses is doing in that area. Maybe it's acting on a Windows > > result > > that's busted on the Windows preview. Or something else. Good luck with > > this > > route :-/. > > Here's the gdb session from my own Windows 10 machine... ... thank you for looking at this in gdb > > That is all the help/damage I can do at this point. > Cheers, > > ..mark I started setup today and observed that the only "pending" actions were a bunch of ncurses installs. I clicked ok ( and enabled source just in case :-) ) and watched the action begin. Uninstall libncurses-devel 6.0-11.20170617 (automatically added) Uninstall libncursesw10 6.0-11.20170617 (automatically added) Uninstall ncurses 6.0-11.20170617 (automatically added) Install libncurses++w10 6.1-1.20190727 Install libncurses++w10-src 6.1-1.20190727 (source) Install libncurses-devel 6.1-1.20190727 Install libncurses-devel-src 6.1-1.20190727 (source) Install libncursesw10 6.1-1.20190727 Install libncursesw10-src 6.1-1.20190727 (source) Install ncurses 6.1-1.20190727 Install ncurses-src 6.1-1.20190727 (source) both bash and more worked ( e.g. bash starts and more doesn't stack dump in this simple case c:\cygwin64>cd bin c:\cygwin64\bin>path c:\cygwin64\bin;%PATH% c:\cygwin64\bin>which which /usr/bin/which c:\cygwin64\bin>more < NUL c:\cygwin64\bin> looking back at the downgrade log I see Uninstall libncursesw10 6.1-1.20190727 (automatically added) Uninstall ncurses 6.1-1.20190727 (automatically added) so I think that I just upgraded to what I had before, not sure if something was corrupted before. I did search for ncurses in the cygcheck.out from before $ ag -i ncurses cygcheck.out 1248: 301k 2019/07/28 c:\cygwin64\bin\cygncursesw-10.dll - os=4.0 img=0.0 sys=5.2 1249: "cygncursesw-10.dll" v0.0 ts=2019-07-28 09:30 1969:libncursesw10 6.1-1.20190727 OK 2132:ncurses 6.1-1.20190727 OK -- 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: many cygwin shells/tools (tcsh, fish, bash, and zsh) crashing STATUS_ACCESS_VIOLATION
On Tue, Aug 10, 2021 at 12:50 PM Mark Geisert wrote: > > > You could try downgrading ncurses via Cygwin setup. Best case: things work. Best case achieved Ran setup this is what it said it would do Uninstall libncursesw10 6.1-1.20190727 (automatically added) Uninstall ncurses 6.1-1.20190727 (automatically added) Install libncurses-devel 6.0-11.20170617 Install libncursesw10 6.0-11.20170617 Install ncurses 6.0-11.20170617 now I can click on my C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico - and get my beloved bash prompt again Thank you all for getting me back up and running. I am willing to try other experiments, though responses may be delayed at times. -- 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: many cygwin shells/tools (tcsh, fish, bash, and zsh) crashing STATUS_ACCESS_VIOLATION
On Tue, Aug 10, 2021 at 10:56 AM Brian Inglis wrote: > Apparently that Windows Version is for the Windows 11 Preview. > That appears to be an alpha quality product, from bug fix announcements. > I didn't find anything much useful from MS or articles only features. > You might want to reach out for help via the Windows Feedback Hub, > and/or MS App Assure re compatibility if your org has 150+ licenses. I'm interested in what could be going wrong that would cause only some cygwin programs to fail. I'd be happy to report the issue via Windows Feedback if I could point to something specific. Maybe I should rebuild "more.exe" from source? comparing the mentioned more.exe.stackdump and bash.exe.stackdump it appears that cygwin creates different formats of files but seems to call them *.stackdump -- 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: many cygwin shells/tools (tcsh, fish, bash, and zsh) crashing STATUS_ACCESS_VIOLATION
On Mon, Aug 9, 2021 at 10:04 PM Brian Inglis wrote: > It's a known problem that after Windows updates, especially Insider, > quarterly, or biannually e.g. [20]20H2 [20]2009, it's often advisable to > rerun Cygwin Setup and allow packages to be upgraded in case patches are > made for new releases, and DLLs be rebased in case address space is > occupied by updated Windows components. I did run cygwin setup, and it did not indicate any pending updates that were required. I'll try to do that more frequently, but now I am stuck, any other ideas to try to get the tools running again would there be any clues offered from strace? any other sources of information -- 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: many cygwin shells/tools (tcsh, fish, bash, and zsh) crashing STATUS_ACCESS_VIOLATION
On Mon, Aug 9, 2021 at 10:08 PM Takashi Yano wrote: > > On Mon, 9 Aug 2021 21:36:15 -0700 > David Dyck wrote: > > I've had it running for many years, but recently upgraded to windows 10 > > c:\cygwin64\bin>ver > > > > Microsoft Windows [Version 10.0.22000.120] > > This does not seem to be a version number of Windows10 but > a version number of latest Windows11 insider preview. > > However, in my environment, cygwin works as expected in > Windows11 insider prevew as well as Windows10. Yes, you are correct, it is Windows 11 insider preview and I have another computer that is also running Win 11 preview with cygwin just fine. I was surprised to have these exceptions on what used to be a reliable system. -- 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 with mingw64-x86_64-qt5ct
My apologies for sending this request to the wrong list (cygwin-apps). I have been trying to run the following command from my cygwin environment: /usr/x86_64-w64-mingw32/sys-root/mingw/bin/qt5ct.exe This results in a dialog saying that the following library could not be found: libqt5ct-style.so I did a search for this file both here and online and could not find it. Is there a solution for this issue? Sincerely, David R. Bergstein -- 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: Fix nanosleep returning negative rem
> On Jul 20 16:16, David Allsopp wrote: > > I've pushed a repro case for this to > > https://github.com/dra27/cygwin-nanosleep-bug.git > > > > Originally noticed as the main CI system for OCaml has been failing > > sporadically for the signal.ml test mentioned in that repo. This > > morning I tried hammering that test on my dev machine and discovered > > that it fails very frequently. No idea if that's drivers, Windows 10 > > updates, number of cores or what, but it was definitely happening, and > > easily. > > > > Drilling further, it appears that NtQueryTimer is able to return a > > negative value in the TimeRemaining field even when SignalState is > > false. The values I've seen have always been < 15ms - i.e. less than > > the timer resolution, so I wonder if there is a point at which the > > timer has elapsed but has not been signalled, but WaitForMultipleObjects > returns because of the EINTR signal. > > Mildly surprising that it seems to be so reproducible. > > > > Anyway, a patch is attached which simply guards a negative return > > value. The test on tbi.SignalState is in theory unnecessary. > > Thanks for the patch, I think your patch is fine. However, I'd like to > dig a bit into this to see what exactly happens. Do you have a very > simple testcase in plain C, by any chance? https://github.com/dra27/cygwin-nanosleep-bug/blob/main/signal.c was as simple as I'd gone at this stage (eliminating OCaml from the equation!). It might be possible to get it to happen without all the pthreads stuff: having confirmed it definitely wasn't OCaml and been able to put the appropriate system_printf's into cygwait to see that NtQueryTimer really was returning this small negative value, I stopped simplifying. Does that repro case trigger on your system too? Best, D
Fix nanosleep returning negative rem
I've pushed a repro case for this to https://github.com/dra27/cygwin-nanosleep-bug.git Originally noticed as the main CI system for OCaml has been failing sporadically for the signal.ml test mentioned in that repo. This morning I tried hammering that test on my dev machine and discovered that it fails very frequently. No idea if that's drivers, Windows 10 updates, number of cores or what, but it was definitely happening, and easily. Drilling further, it appears that NtQueryTimer is able to return a negative value in the TimeRemaining field even when SignalState is false. The values I've seen have always been < 15ms - i.e. less than the timer resolution, so I wonder if there is a point at which the timer has elapsed but has not been signalled, but WaitForMultipleObjects returns because of the EINTR signal. Mildly surprising that it seems to be so reproducible. Anyway, a patch is attached which simply guards a negative return value. The test on tbi.SignalState is in theory unnecessary. All best, David 0001-Ensure-nanosleep-2-never-returns-negative-rem.patch Description: Binary data
Regenerate Cygwin FAQ
The instructions for building Cygwin changed in April and the FAQ was updated (c66797ee), but the website doesn't appear to have been regenerated (https://cygwin.com/faq.html#faq.programming.building-cygwin). Thanks! David -- 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 with mingw64-x86_64-qt5ct
I have been trying to run the following command from my cygwin environment: /usr/x86_64-w64-mingw32/sys-root/mingw/bin/qt5ct.exe This results in a dialog saying that the following library could not be found: libqt5ct-style.so I did a search for this file both here and online and could not find it. Is there a solution for this issue? Sincerely, David R. Bergstein
Re: Difficult getting pure-ftpd to work under Cygwin on Windows 10, esp anonymous ftp
cygrunsrv is an EXCELLENT solution, thankyou. So for those looking for a quick make-it-work, install pure-ftpd as a service thus (from a bash you have started as "Run as Administrator") : cygrunsrv --install pure-ftpd --path /usr/sbin/pure-ftpd --chdir /tmp --args "-l puredb:/full-path-to/pure-ftpd/pureftpd.pdb" and then cygrunsrv --start pure-ftpd This solves the seteuid() limitation, so now the one server will work with anonymous (but still needs "ftp" as a Windows user) and any other user in the puredb passwd file. Matthew, re the Windows privileges you suggest, sadly and according to Murphy's law I did all this on my one and only Windows 10 Home Edition ... no group policy editor :-( I **could** try it on a Windows 10 Pro PC, or I could regedit I suppose, but hey cygrunsrv works so thankyou. Perhaps an ancillary issue is the cryptic way in some code paths pure-ftpd gives the error "Unable to set up secure anonymous FTP", sometimes with, but sometimes without, a syslog... I needed to use gdb extensively to one by one eliminate blockages and get anonymous to work. Perhaps more importantly the recipe (cygrunsrv) would be great to have in the man page of the Cygwin package, and certainly in the README.Windows file of the source package. I'll cross-post this to pure-ftpd.org Thanks for your help ! - Message from matthew patton - Date: Tue, 29 Jun 2021 00:04:12 + (UTC) From: matthew patton Subject: Re: Difficult getting pure-ftpd to work under Cygwin on Windows 10, esp anonymous ftp To: David Oppenheim and look at cygrunsrv --start On Monday, June 28, 2021, 08:00:10 PM EDT, matthew patton wrote: specifically SeAssignPrimaryTokenPrivilege SeCreateTokenPrivilege SeTcbPrivilege SeIncreaseQuotaPrivilege SeServiceLogonRight On Monday, June 28, 2021, 07:58:41 PM EDT, matthew patton via Cygwin wrote: have you tried applying the notable permissions from this to your 'ftp' windows user?https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/user-rights-assignment On Monday, June 28, 2021, 06:48:18 PM EDT, David Oppenheim wrote: I have debugged various obstacles getting logins to pure-ftpd to work under Cygwin on Windows 10 (Home edition 20H2 on this particular PC), especially getting anonymous ftp to login successfully. My pure-ftpd is version 1.0.46-1 as downloaded by the Cygwin installer. There are problems with how it looks up username/password, with it calling seteuid(), and sometimes with pathnames for the user's home directory, and the user's shell. This is particularly fraught if you try to use anonymous ftp. My solution is a simple recipe, albeit limited but fine for personal or small group use ... technical problem details after this recipe. I hope this helps anyone else trying to get it to work ! --- recipe for setting up pure-ftpd on Cygwin Set up pure-ftp passwd file first with pure-pw -f filename.passwd then convert to puredb format with pure-pw mkdb filename.pdb -f filename.passwd Note that sometimes pure-pw and/or pure-ftpd imply a /etc prefix for the filename, seems that's overridden if you use an absolute pathname. Run pure-ftpd as you. From the ftp client login as you with the puredb file password not the Windows password. Your starting directory once logged in will be the homne directory as set up in the puredb entry for your username ... probably /home/yourloginname (as viewed from inside Cygwin). --- end recipe Re anonymous login ... Internally pure-ftpd translates "anonymous" to "ftp" Anonymous login is not checked in the -l puredb file, it does a getpwnam() call, so "ftp" ** must ** be a user in Windows Needs /home/ftp (pathname from inside Cygwin) and perhaps ~/home/ftp for user running pure-ftpd For any ftp login, if the ftp username is not the same as the Windows user running pure-ftpd, pure-ftpd fails on seteuid() ... see Windows event logger (or Cygwin syslog if that's installed), the ftp client sees "Unable to set up secure anonymous FTP" This happens even if running pure-ftpd from Explorer by "Run as Administrator" So for anonymous login you have to run pure-ftpd as Windows user ftp More generally, because of that seteuid issue, if you want to ftp login as uuu then you need to run pure-ftpd as Windows user uuu ... although having uuu in a pure-pw database permits the password to be different from the Windows login password. Nb: if you run pure-ftpd directly from Explorer (incl "Run as Administrator") the place it looks for the home directory may be ./ or the Windows user's home (C:\Users\uuu) and I have also seen failures setting user shell because it's looking for e.g. /bin/bash somewhere else. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https
Difficult getting pure-ftpd to work under Cygwin on Windows 10, esp anonymous ftp
I have debugged various obstacles getting logins to pure-ftpd to work under Cygwin on Windows 10 (Home edition 20H2 on this particular PC), especially getting anonymous ftp to login successfully. My pure-ftpd is version 1.0.46-1 as downloaded by the Cygwin installer. There are problems with how it looks up username/password, with it calling seteuid(), and sometimes with pathnames for the user's home directory, and the user's shell. This is particularly fraught if you try to use anonymous ftp. My solution is a simple recipe, albeit limited but fine for personal or small group use ... technical problem details after this recipe. I hope this helps anyone else trying to get it to work ! --- recipe for setting up pure-ftpd on Cygwin Set up pure-ftp passwd file first with pure-pw -f filename.passwd then convert to puredb format with pure-pw mkdb filename.pdb -f filename.passwd Note that sometimes pure-pw and/or pure-ftpd imply a /etc prefix for the filename, seems that's overridden if you use an absolute pathname. Run pure-ftpd as you. From the ftp client login as you with the puredb file password not the Windows password. Your starting directory once logged in will be the homne directory as set up in the puredb entry for your username ... probably /home/yourloginname (as viewed from inside Cygwin). --- end recipe Re anonymous login ... Internally pure-ftpd translates "anonymous" to "ftp" Anonymous login is not checked in the -l puredb file, it does a getpwnam() call, so "ftp" ** must ** be a user in Windows Needs /home/ftp (pathname from inside Cygwin) and perhaps ~/home/ftp for user running pure-ftpd For any ftp login, if the ftp username is not the same as the Windows user running pure-ftpd, pure-ftpd fails on seteuid() ... see Windows event logger (or Cygwin syslog if that's installed), the ftp client sees "Unable to set up secure anonymous FTP" This happens even if running pure-ftpd from Explorer by "Run as Administrator" So for anonymous login you have to run pure-ftpd as Windows user ftp More generally, because of that seteuid issue, if you want to ftp login as uuu then you need to run pure-ftpd as Windows user uuu ... although having uuu in a pure-pw database permits the password to be different from the Windows login password. Nb: if you run pure-ftpd directly from Explorer (incl "Run as Administrator") the place it looks for the home directory may be ./ or the Windows user's home (C:\Users\uuu) and I have also seen failures setting user shell because it's looking for e.g. /bin/bash somewhere else. -- 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: Fwd: outdated git-review version
Hi Marco, I would greatly appreciate you adopting and updating this package. I no longer use it in my day job. Regards, David On 5/18/2021 9:49 AM, Marco Atzeri via Cygwin-apps wrote: David, It seems this package is still python 2.7 one. If you want I can take over and adapt to python 3.8 Forwarded Message Subject: outdated git-review version Date: Tue, 18 May 2021 11:50:38 + From: Rutkowska, Anna (Nokia - PL/Wroclaw) Hi, Latest available git-review package is 1.26 which currently cases following problem $ git review remote: error: branch refs/publish/master: remote: If you are using git-review, update to at least git-review 1.27. Could you make 1.27 or 1.28 available? Best regards, Anna Rutkowska - Regards Marco -- David Rothenberger daver...@acm.org Badges? We don't need no stinking badges.
RE: Building Coq in Cygwin
Marco Atzeri wrote: > On 06.05.2021 02:56, Eliot Moss wrote: > > Folks - Before I try to Coq mailing lists, I am wondering if anyone > > here has had success building Coq under Cygwin. I've tried the dune > > and the make approaches, and both fail, in different ways, but > > seemingly because some components can't deal with the uniquenesses of > > Cygwin - though they seem to try to provide for it. > > > > Regards - Eliot > > > > another of those software that thinks Automake/cmake are non needed ... > usually they are a mess to port to un-forecasted platforms. This has nothing to do with the build systems of these packages and everything to do with the fact the ocaml on Cygwin64 has been broken for a while... > $ ./configure >0 [main] ocamlrun 740 child_info_fork::abort: address space needed > by 'dllunix.so' (0x40) is already occupied ... > by 'dllunix.so' (0x40) is already occupied >0 [main] ocamlrun 744 child_info_fork::abort: address space needed > by 'dllunix.so' (0x40) is already occupied I can not automatically > find the name of your architecture. > Give me a name, please [win32 for Win95, Win98 or WinNT]: >^^ frontline technology I see :) Amusingly, the git history shows it has been preserved through updates 13 and 8 years ago, but the line was originally written in 1999. Mature and (formally) proven is possibly the description the Coq team might prefer! > How we solve the reloc issue on 64 bit ? I am a bit ocalm rust I fixed the underlying problem in OCaml 4.12, but I haven't had time to propose adopting the Cygwin packages yet - I'm hoping to over the next few months. The short-term workaround is either to use Cygwin32 or to install the opam, libgmp-devel and flexdll 0.39 packages and run: opam init opam switch -y create coq ocaml-base-compiler.4.12.0 # This takes a looong time, especially the "make install" step opam install -y coq eval $(opam env) coqtop Quit. (NB flexdll 0.39 must be selected manually or using the new flexdll=0.39-1 syntax on the command line, as I've left it marked test until ocaml 4.12 is packaged) HTH, David -- 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 base install no longer has iconv binary
[Continuing second point in https://cygwin.com/pipermail/cygwin-apps/2021-April/041212.html] The man-db package prior to 2.9.3-1 on 3 Jan depended on the libiconv package which, unusually, includes the iconv binary itself. I noticed as OCaml has assumed since 2017 that iconv would be available in base, and thus on "any" Cygwin installation. I was already working on removing OCaml's dependency on the iconv binary, so I don't have a strong opinion either way, but should libiconv be put in the Base category in order to keep the installed commands consistent? David -- 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: [ITA] man-db
On 03 January 2021 11:17, Achim Gratz wrote: > Update to version 2.9.3 and cleaning up patches. > > Change packaging so that index creation can be triggered by installing the > man-db-create-index package. Postinstall index update is done in the > background by default so it won't block setup from progressing anymore, > but can be made synchronous again if needed, via installation of the man- > db-index-synchronously package. > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/man- > db.git;a=shortlog;h=refs/heads/playground > https://ci.appveyor.com/project/cygwin/scallywag/builds/37084308 (Apologies if this should go the main Cygwin list) This version of the package removes the dependency on libiconv, which means that the base Cygwin install no longer includes the iconv command. Was that an intentional consequence? David
RE: [PATCH setup] Add --allow-test-versions
Jon Turney wrote: > On 20/04/2021 15:37, David Allsopp via Cygwin-apps wrote: > > Attached adds -t/--allow-test-packages to Setup which controls the > > initial state of the "Test" checkbox. > > > > Motivation is to allow one CI cron job to be installing test versions > > of packages, then we can help identify things like [1] before they're > released. > > Nice. Thanks. > > > +static BoolOption AllowTestOption (false, 't', "allow-test-packages", > > +"Permit installation of package versions marked test"); > > The only quibble I have is the help text here. The user has always been > permitted to choose test packages, this checkbox allows setup to decide to > use them itself. > > So maybe something like "Consider package versions marked test". No problem - see attached. All best, David 0001-Add-allow-test-packages.patch Description: 0001-Add-allow-test-packages.patch
[PATCH setup] Add --allow-test-versions
Attached adds -t/--allow-test-packages to Setup which controls the initial state of the "Test" checkbox. Motivation is to allow one CI cron job to be installing test versions of packages, then we can help identify things like [1] before they're released. David [1] https://cygwin.com/pipermail/cygwin/2021-April/248300.html 0001-Add-allow-test-packages.patch Description: Binary data
RE: [PATCH setup] Handle '--packages package=version'
Jon Turney wrote: > Handle '--packages package=version' to allow specifing the version of a > package to install on the command line. > > isManuallyWanted() now returns the target packageversion (if specified), > or an empty packageversion (which is translated into an instruction to > the solver to choose the version). > > In the 'upgrade' case, this changes from using the complex logic of > packagemeta::trustp() to determine the target version, when unspecified > on the command line, to allowing the solver to make that decision (which > should be broadly the same i.e. not downgrading test versions, etc.). > > This also subtly changes the behaviour when the package version is not > specified. Instead of forcing the current version, we allow the solver > to choose the version, so it may not pick that version, if other > constraints exist, which prevent a solution containing that version. > > There's probably some future work which can be done to simplify the > remaining uses packagemeta::trustp(), which are only related to the UI. This is really useful (tested locally for a couple of use-cases: one wanting a downgrade from latest and the other to manually specify a test version). Does libsolv give the ability to put more complex constraints? In opam, for example, I can issue `opam install 'utop<2.7.0' and get the last version before 2.7.0. `--packages mingw64-x86_64-binutils=2.35.2-1` is already very useful but `--packages mingw64-x86_64-binutils<2.36` is even more so. David
RE: [PATCH 0/2] Fix race issues.
Corinna Vinschen wrote: > On Apr 19 19:30, Takashi Yano wrote: > > Takashi Yano (2): > > Cygwin: console: Fix race issue regarding cons_master_thread(). > > Cygwin: pty: Fix race issue in inheritance of pseudo console. > > > > winsup/cygwin/fhandler_console.cc | 10 ++- > > winsup/cygwin/fhandler_tty.cc | 108 ++ > > winsup/cygwin/tty.cc | 15 ++--- > > winsup/cygwin/tty.h | 2 +- > > 4 files changed, 77 insertions(+), 58 deletions(-) > > > > -- > > 2.31.1 > > Pushed. Armed with this morning's Cygwin snapshot, OCaml builds again as well. Many thanks! David
[PATCH 1/1] cherry-pick fix for pkg-config
This PR removes a recently added -R/usr/lib from the linker flags, which is
incompatible with gcc:
$ cc $(pkg-config --libs libbrotlidec)
cc: error: unrecognized command-line option ‘-R’
---
brotli.cygport | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/brotli.cygport b/brotli.cygport
index dbf43b7..91deb5c 100644
--- a/brotli.cygport
+++ b/brotli.cygport
@@ -4,7 +4,7 @@ inherit cmake python-wheel
NAME="brotli"
VERSION=1.0.9
-RELEASE=1
+RELEASE=2
CATEGORY="Libs"
SUMMARY="Brotli compression format library"
DESCRIPTION="Brotli is a generic-purpose lossless compression algorithm that
@@ -14,6 +14,7 @@ comparable to the best currently available general-purpose
compression methods.
It is similar in speed with deflate but offers more dense compression."
HOMEPAGE="https://github.com/google/brotli;
SRC_URI="${HOMEPAGE}/archive/v${VERSION}/brotli-v${VERSION}.tar.gz"
+PATCH_URI="${HOMEPAGE}/commit/092446fafb4bfb81738853b7c7f76b293cd92a80.patch"
BUILD_REQUIRES="\
cmake\
--
2.31.1
--
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
[PATCH 0/1] libbrotli has broken pkg-config
I'm a little lost on the exact process for sending patches for packages, so excuse me if I'm in the wrong place. I found this problem when trying to build something that depends on libbrotli. This patch pulls the fix from this PR: https://github.com/google/brotli/pull/838 David McFarland (1): cherry-pick fix for pkg-config brotli.cygport | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.31.1 -- 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: Regression in Cygwin 3.2.0
Takashi Yano wrote: > On Fri, 16 Apr 2021 11:17:50 +0100 > David Allsopp wrote: > > I'm unable to build OCaml using the mingw-w64 compilers with Cygwin > 3.2.0. > > Windows 10.0.19042.928 (and tried on three different machines so far) > > > > Repro: > > > > - Fresh Cygwin64 installation with make, libiconv, > > mingw64-x86_64-gcc-core and git added; fire up mintty > > - git clone --depth 1 --recursive https://github.com/ocaml/ocaml > > - cd ocaml && ./configure --host=x86_64-w64-mingw32 && make -j8 > > flexdll && make -j8 world.opt > > > > This is consistently hanging with Cygwin 3.2.0 and seems possibly to > > have something to do with linking (the creation of > > runtime/ocamlrun.exe and stdlib/camlheader, which is also an > > executable, seem to be part of the problem). > > > > It can be immediately fixed by downgrading to Cygwin 3.1.7, cleaning > > the tree and repeating the build. > > > > I'm of course very happy to try to reduce this to a smaller repro > > case, but is there an obvious culprit in Cygwin 3.2.0 to check before I > do? > > Thanks for the report. I looked into this problem and found that the > caused is the combination of some race issues for non-cygwin processes in > pty and console code. > > I will submit the patches fixing this issue. Fantastic, thanks - I'll keep an eye on cygwin-patches and test. David -- 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: Regression in Cygwin 3.2.0
Thomas Wolff wrote: > Am 16.04.2021 um 16:07 schrieb David Allsopp via Cygwin: > > Thomas Wolff wrote: > >> Am 16.04.2021 um 12:17 schrieb David Allsopp via Cygwin: > >>> I'm unable to build OCaml using the mingw-w64 compilers with Cygwin > >>> 3.2.0. Windows 10.0.19042.928 (and tried on three different machines > >>> so far) > >>> > >>> Repro: > >>> > >>>- Fresh Cygwin64 installation with make, libiconv, > >>> mingw64-x86_64-gcc-core and git added; fire up mintty > >>>- git clone --depth 1 --recursive https://github.com/ocaml/ocaml > >>>- cd ocaml && ./configure --host=x86_64-w64-mingw32 && make -j8 > >>> flexdll && make -j8 world.opt > >>> > >>> This is consistently hanging with Cygwin 3.2.0 and seems possibly to > >>> have something to do with linking (the creation of > >>> runtime/ocamlrun.exe and stdlib/camlheader, which is also an > >>> executable, seem to be part of the problem). > >>> > >>> It can be immediately fixed by downgrading to Cygwin 3.1.7, cleaning > >>> the tree and repeating the build. > >>> > >>> I'm of course very happy to try to reduce this to a smaller repro > >>> case, but is there an obvious culprit in Cygwin 3.2.0 to check > >>> before I do? > >> The build fails for me with error messages but it does not hang. > > Thanks for confirming! > > > >> You could have tried at least building without -j option, and running > >> the build steps separately for better diagnostics. > > Indeed - the repro case above was intended to be small and fast. I was > > still at the "is this just me/us", stage. Suggesting a non-parallel > > build of OCaml would have been mean, as it takes about an hour if it > > doesn't crash...! > > > > That said, the non-parallel build I think reveals the Cygwin problem: > > there are console windows constantly flashing up (it renders the > > workstation unusable for the duration of the build). The first stage > > of the build compiles ocamlrun.exe which is non-Cygwin in this case > > and then it uses that throughout the build, so I guess it's the conpty > > changes which are biting. > > > > However, the build did succeed when run without -j, however this > > (which will take about 20 mins or so): > > > > ./configure --build=x86_64-w64-mingw32 --disable-native-compiler make > > flexdll runtop > > > > causes a new console Window to pop up with an OCaml prompt (which can > > be quit by taking #quit;;) rather than the same prompt being connected > > to mintty. > > > > With make -j, it doesn't appear to flash up all the console Windows, > > but it's also reliably failing. I tried with the cygwin1.dll snapshot > > from this morning which seems to be doing the same. > Maybe a non-cygwin tool is injected in your build process? > What if you strip your PATH from all non-cygwin directories? There always has been a non-Cygwin tool - it's calling an ocamlrun.exe it us built at the start of the process with x86_64-w64-mingw32. Is that no longer permitted?! However, I'm not sure how the environment has anything to do with this: everything goes back to working just by downgrading cygwin1.dll to 3.1.7. David -- 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: Regression in Cygwin 3.2.0
Thomas Wolff wrote: > Am 16.04.2021 um 12:17 schrieb David Allsopp via Cygwin: > > I'm unable to build OCaml using the mingw-w64 compilers with Cygwin > > 3.2.0. Windows 10.0.19042.928 (and tried on three different machines > > so far) > > > > Repro: > > > > - Fresh Cygwin64 installation with make, libiconv, > > mingw64-x86_64-gcc-core and git added; fire up mintty > > - git clone --depth 1 --recursive https://github.com/ocaml/ocaml > > - cd ocaml && ./configure --host=x86_64-w64-mingw32 && make -j8 > > flexdll && make -j8 world.opt > > > > This is consistently hanging with Cygwin 3.2.0 and seems possibly to > > have something to do with linking (the creation of > > runtime/ocamlrun.exe and stdlib/camlheader, which is also an > > executable, seem to be part of the problem). > > > > It can be immediately fixed by downgrading to Cygwin 3.1.7, cleaning > > the tree and repeating the build. > > > > I'm of course very happy to try to reduce this to a smaller repro > > case, but is there an obvious culprit in Cygwin 3.2.0 to check before I > > do? > The build fails for me with error messages but it does not hang. Thanks for confirming! > You could have tried at least building without -j option, and running the > build steps separately for better diagnostics. Indeed - the repro case above was intended to be small and fast. I was still at the "is this just me/us", stage. Suggesting a non-parallel build of OCaml would have been mean, as it takes about an hour if it doesn't crash...! That said, the non-parallel build I think reveals the Cygwin problem: there are console windows constantly flashing up (it renders the workstation unusable for the duration of the build). The first stage of the build compiles ocamlrun.exe which is non-Cygwin in this case and then it uses that throughout the build, so I guess it's the conpty changes which are biting. However, the build did succeed when run without -j, however this (which will take about 20 mins or so): ./configure --build=x86_64-w64-mingw32 --disable-native-compiler make flexdll runtop causes a new console Window to pop up with an OCaml prompt (which can be quit by taking #quit;;) rather than the same prompt being connected to mintty. With make -j, it doesn't appear to flash up all the console Windows, but it's also reliably failing. I tried with the cygwin1.dll snapshot from this morning which seems to be doing the same. David -- 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
Regression in Cygwin 3.2.0
I'm unable to build OCaml using the mingw-w64 compilers with Cygwin 3.2.0. Windows 10.0.19042.928 (and tried on three different machines so far) Repro: - Fresh Cygwin64 installation with make, libiconv, mingw64-x86_64-gcc-core and git added; fire up mintty - git clone --depth 1 --recursive https://github.com/ocaml/ocaml - cd ocaml && ./configure --host=x86_64-w64-mingw32 && make -j8 flexdll && make -j8 world.opt This is consistently hanging with Cygwin 3.2.0 and seems possibly to have something to do with linking (the creation of runtime/ocamlrun.exe and stdlib/camlheader, which is also an executable, seem to be part of the problem). It can be immediately fixed by downgrading to Cygwin 3.1.7, cleaning the tree and repeating the build. I'm of course very happy to try to reduce this to a smaller repro case, but is there an obvious culprit in Cygwin 3.2.0 to check before I do? Many thanks, David -- 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: rsync password prompt doesn't capture input and shows password in clear
On 3/10/21 6:20 PM, Marki wrote: > Only then I showed that the same is not true for rsync. When I input a > password, it will get echoed and also rsync will not process it, since > standard input somehow goes elsewhere. If I had to guess, it's probably the same as the problems I was seeing with gpg-agent not being able to capture the tty correctly to prompt for the password. I never had a problem with the ssh agent though. Unfortunately I do not have a good solution for it, as it seems to happen only to some people some time on some systems. After fighting with it for an afternoon, I simply wrote a pinentry program with my password hardcoded into it. Yay for security. The hack is here for reference (DO NOT USE ON PUBLIC PRODUCTION MACHINES!) -> https://x.cygwin.com/ml/cygwin/2019-01/msg00178.html I recheck the stock program every few months, and this problem still exists. -- David Dombrowsky | Chief Software Engineer 6th Street Radio LLC | 6thstreetradio.org | 518-374-3204 https://www.linkedin.com/in/david-dombrowsky-94334415 VHVlIE1hciAgOSAwMjoxMzowMiBFU1QgMjAyMQo= signature.asc Description: OpenPGP digital signature -- 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: Latest update seems to have broken Mercurial
On Sat, 30 Jan 2021 14:09:20 +0100, Marco Atzeri via Cygwin wrote: > On 30.01.2021 10:41, David Monksfield wrote: > > Mercurial was working fine for me until my last Cywin update (yesterday). > > [...] > > Hi David, > yes I am aware, current mercurial package still requires python 2.7. > > You can see the situation with > > --- > $ alternatives --display python > python - status is auto. > link currently points to /usr/bin/python3.8 > /usr/bin/python3.7 - priority 37 > /usr/bin/python2.7 - priority 27 > /usr/bin/python3.6 - priority 36 > /usr/bin/python3.8 - priority 38 > Current `best' version is /usr/bin/python3.8. > - > > and change it with > > - > $ alternatives --config python Brilliant, thanks - that worked! I'll make sure I change the python default back to 3.8 once the Mercurial package has been updated. David -- 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
Latest update seems to have broken Mercurial
Mercurial was working fine for me until my last Cywin update (yesterday).
I have Mercurial 5.5.1-1. I don't know enough about python to unpick this,
but it looks suspicious that there is a mixture of python2.7 and python3.8
in the traceback.
I now get this:
$ hg status
Traceback (most recent call last):
File "/usr/bin/hg", line 43, in
dispatch.run()
File "/usr/lib/python3.8/importlib/util.py", line 245, in __getattribute__
self.__spec__.loader.exec_module(self)
File "", line 783, in exec_module
File "", line 219, in _call_with_frames_removed
File "/usr/lib/python2.7/site-packages/mercurial/dispatch.py", line 22, in
from .i18n import _
File "/usr/lib/python3.8/importlib/util.py", line 245, in __getattribute__
self.__spec__.loader.exec_module(self)
File "/usr/lib/python2.7/site-packages/mercurial/i18n.py", line 112, in
if _plain():
File "/usr/lib/python2.7/site-packages/mercurial/i18n.py", line 104, in _plain
b'HGPLAIN' not in encoding.environ
File "/usr/lib/python3.8/importlib/util.py", line 245, in __getattribute__
self.__spec__.loader.exec_module(self)
File "/usr/lib/python2.7/site-packages/mercurial/encoding.py", line 40, in
charencode = policy.importmod('charencode')
File "/usr/lib/python2.7/site-packages/mercurial/policy.py", line 116, in
importmod
mod = _importfrom(pn, mn)
File "/usr/lib/python2.7/site-packages/mercurial/policy.py", line 67, in
_importfrom
pkg = __import__(pkgname, globals(), fakelocals, [modname], level=1)
File "/usr/lib/python3.8/importlib/util.py", line 286, in create_module
return self.loader.create_module(spec)
ImportError: dynamic module does not define module export function
(PyInit_parsers)
Any help or suggestions would be appreciated.
Thanks,
David
--
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: misterious GIT failure (SOLVED)
On Sun, Jan 17, 2021 at 1:08 PM matthew patton via Cygwin wrote: > I haven't run into a scenario yet where 'readlink' doesn't work. > Here's a unrelated example where symbolic links don't work the same as on unix/linux ( not sure this is a readlink issue ) When I try to write through /proc to to a processes stdout I get errors e.g. $ ls -l /proc/1708/fd/1 lrwxrwxrwx 1 DavidD Domain Users 0 Jan 17 14:20 /proc/1708/fd/1 -> /dev/pty2 $ printf "\033]0;foo\7" > /proc/1708/fd/1 -bash: printf: write error: Bad file descriptor but $ printf "\033]0;foo\7" > /dev/pty2 works I'm not sure if this is a readlink issue or just a bug in the cygwin implementation of /proc :-) -- 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: Fortran Installation
On 4/01/2021 08:03, Brian Inglis via Cygwin wrote: It looks like Dislin is a proprietary closed source plotting package which you will have to find, acquire, install, and configure separately, or migrate settings from your old system. DISLIN is a library graphics subroutines and functions -- https://www.dislin.de The (binary) distribution can be used freely. Source code is obtained for a small fee. Recent 32-bit and 64-bit cygwin binaries are available from https://www.dislin.de/downloads.html -- 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: flexdll 0.39-1 (TEST)
The following packages have been updated in the Cygwin distribution as test: * flexdll-0.39-1.tar.xz This is an update to the latest upstream release in advance of OCaml 4.12.0, which requires it in order to work correctly on x86_64 Cygwin. *** 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.com cygwin.com If you need more information on unsubscribing, start reading here: https://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
Updated: flexdll 0.39-1 (TEST)
The following packages have been updated in the Cygwin distribution as test: * flexdll-0.39-1.tar.xz This is an update to the latest upstream release in advance of OCaml 4.12.0, which requires it in order to work correctly on x86_64 Cygwin. *** 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.com cygwin.com If you need more information on unsubscribing, start reading here: https://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
RE: SSH key for David Allsopp
Jon Turney wrote: > Sent: 01 December 2020 15:21 > To: cygwin-apps@cygwin.com; David Allsopp > Subject: Re: SSH key for David Allsopp > > On 01/12/2020 09:27, David Allsopp via Cygwin-apps wrote: > > > > Thanks. I can connect via sftp (or run alive) but I'm getting a > > publickey error on cyg...@cygwin.com:/git/cygwin-packages/flexdll > > trying to push a playground branch. Should I be able to? > > Yes. > > Can you be more explicit about what error you are getting? > > I don't know what could cause 'ssh cyg...@cygwin.com alive' to work, but > 'git push ssh://cyg...@cygwin.com/git/cygwin-packages/flexdll.git' to > fail. Ugh - please forgive the noise. PEBKAC and misconfigured Git...
RE: SSH key for David Allsopp
Jon Turney wrote: > On 30/11/2020 17:30, David Allsopp via Cygwin-apps wrote: > > Name: David Allsopp > > BEGIN SSH2 PUBLIC KEY > > Comment: "Cygwin Packaging Key" > > C3NzaC1lZDI1NTE5IAExhdEPx3iOcR+dSXb/dByk/3+2+SRSU1UYLqGI11u9 > > END SSH2 PUBLIC KEY > > Done. Thanks. Thanks. I can connect via sftp (or run alive) but I'm getting a publickey error on cyg...@cygwin.com:/git/cygwin-packages/flexdll trying to push a playground branch. Should I be able to?
SSH key for David Allsopp
Name: David Allsopp BEGIN SSH2 PUBLIC KEY Comment: "Cygwin Packaging Key" C3NzaC1lZDI1NTE5IAExhdEPx3iOcR+dSXb/dByk/3+2+SRSU1UYLqGI11u9 END SSH2 PUBLIC KEY
[ITA] flexdll
OCaml has been partially broken on Cygwin64 since 2018. I did some recent work upstream to fix it and we're expecting OCaml 4.12.0 by the end of the year to restore full support. This requires a new release of flexdll (I also maintain upstream for that). We could do with an updated FlexDLL package before OCaml 4.12.0 is released to simplify testing on CI servers. I'd like to offer to adopt the Cygwin flexdll package, therefore. The changes for 0.39 are trivial: https://github.com/dra27/cygport-flexdll/commit/2cb2d6787c56eb1367d7aa4588c5 24db92e45492 and test packages are in https://github.com/dra27/cygport-flexdll/commit/eb544170af8f2a37b7ec8c7eac95 6a47ae9fef4d. Thanks, David
