Re: cygrunsrv does not start cygsshd at boot
On 2020-01-28 15:28, Brian Inglis wrote: > On 2020-01-28 14:56, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: >>> As the reg entries show, you can also do this by adding or setting registry >>> entries using Cygwin regtool, Windows reg, or regedit commands. >> >> It is better and much safer to use native Windows service controller >> commands, than tweaking the registry: >> >> sc config cygsshd start= delayed-auto > > Agreed, reg is useful for checking and doing in non-scripting languages. > >> Also, you won't need (or generally want) to use service pre-shutdown, as it >> can cause a very long delay when Windows restarts. If you mean by "delay when restarts" => "before shutdown", it may take up to three (3) minutes by default before Windows times out preshutdown services, then it may take up to two (2) minutes by default before Windows times out service process shutdown. Is that not better than abruptly terminating an sshd session, or abandoning sending a large email? I would expect UPS shutdown handlers to do whatever is required to expedite a speedy shutdown within a a few tens of ms/a mains power cycle or two. >> https://docs.microsoft.com/en-us/windows/win32/services/service-control-handler-function > > Don't see where you read that? > Preshutdown happens before regular service shutdown starts. > Nothing to do with startup or restart! -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: headache on build repeatibility: octave vs BLODA ?
Am 29.01.2020 um 01:02 schrieb Hans-Bernhard Bröker:
Am 25.01.2020 um 17:55 schrieb Marco Atzeri:
The problem occurs the same way, here, running Win10 Pro 1909 fully
updated (a.k.a. Version 10.0.18363.592), no extra AntiVirus running
besides Defender.
Be aware that build time is very long (~ 4 hours) and requires
a ton of mathematical libraries.
The build itself completed in ~30 minutes, here ;-). But then this is a
fresh i9, 8-core, 16-thread box.
Nice toy. Here just a notebook with i5 4-core
cygport install took ages to complete, though, because objcopy takes
spectacularly long to strip those DLLs --- longer than it took to build
the whole package! And it does them one at a time. That could profit
from some parallelization.
there are only 2 gigant dll`s
$ find . -name "cyg*dll" -exec du -sh {} \;
55M ./libgui/.libs/cygoctgui-5.dll
536M./libinterp/.libs/cygoctinterp-7.dll
213M./liboctave/.libs/cygoctave-7.dll
the rest is penauts
$ find . -name "*oct" -exec du -sh {} \;
67M ./libgui/graphics/__init_qt__.oct
1.3M./libinterp/dldfcn/amd.oct
3.0M./libinterp/dldfcn/audiodevinfo.oct
1.8M./libinterp/dldfcn/audioread.oct
1.4M./libinterp/dldfcn/ccolamd.oct
1.6M./libinterp/dldfcn/chol.oct
1.5M./libinterp/dldfcn/colamd.oct
1.4M./libinterp/dldfcn/convhulln.oct
1.2M./libinterp/dldfcn/dmperm.oct
1.2M./libinterp/dldfcn/fftw.oct
1.3M./libinterp/dldfcn/gzip.oct
1.7M./libinterp/dldfcn/qr.oct
1.3M./libinterp/dldfcn/symbfact.oct
1.3M./libinterp/dldfcn/symrcm.oct
1.4M./libinterp/dldfcn/__delaunayn__.oct
2.6M./libinterp/dldfcn/__eigs__.oct
1.3M./libinterp/dldfcn/__fltk_uigetfile__.oct
1.4M./libinterp/dldfcn/__glpk__.oct
3.8M./libinterp/dldfcn/__init_fltk__.oct
2.8M./libinterp/dldfcn/__init_gnuplot__.oct
2.5M./libinterp/dldfcn/__ode15__.oct
1.5M./libinterp/dldfcn/__voronoi__.oct
on the x86 build takes longer :-(
So while I waited, I decided to try it with the distributed octave.exe
instead.
It passes the critical tests without issue.
my experience also. I was not able to make crash the old (by one month)
version
Next step, after cygport inst is done: run the test with the executable
in cygport's "inst" directory (to bypass libtool): Success, again!
So I tried running the test via libtool, i.e. the run-octave script. And
boom it goes.
So re-run it in gdb, via libtool (run-octave -g ...). Still crashes,
but I didn't manage to get around the SIGSEGV handler in octave. It
always caught the SEGV before gdb managed to get there.
So my finding, so far, would be that this is related to libtool. Maybe
some update to Windows broke the way libtool interacts with
not-quite-finished executables...
I had also the fresh executable installed and it also can fail.
My guess is that it is in someplace different as behaviour than the old
one.
So libtool can help to trigger but it is not necessary.
Regards
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: headache on build repeatibility: octave vs BLODA ?
Am 29.01.2020 um 01:02 schrieb Hans-Bernhard Bröker: So re-run it in gdb, via libtool (run-octave -g ...). Still crashes, but I didn't manage to get around the SIGSEGV handler in octave. It always caught the SEGV before gdb managed to get there. So my finding, so far, would be that this is related to libtool. Maybe some update to Windows broke the way libtool interacts with not-quite-finished executables... This is getting curiouser. I was intrigued that the stackdump file written was not from 'octave' per se, but rather 'octave-cli'. And indeed some further experiments shows that ../../inst/usr/bin/octave-cli-5.1.0.exe --norc --silent --no-history -p mex ../../src/octave-5.1.0/test/fntests.m ../../src/octave-5.1.0/test fails, while ../../inst/usr/bin/octave-5.1.0.exe --norc --silent --no-history -p mex ../../src/octave-5.1.0/test/fntests.m ../../src/octave-5.1.0/test passes. I don't see how 'run-octave' would end up running octave-cli, though, unless it had been given the option '-cli'. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: headache on build repeatibility: octave vs BLODA ?
Am 25.01.2020 um 17:55 schrieb Marco Atzeri: libinterp/corefcn/file-io.cc-tst ...fatal: caught signal Segmentation fault -- stopping myself... /bin/sh: line 1: 3771 Segmentation fault (core dumped) /bin/sh ../run-octave --norc --silent --no-history -p /cygdrive/d/cyg_pub/devel/octave/prova_311_510/octave-5.1.0-2.x86_64/build/test/mex /cygdrive/d/cyg_pub/devel/octave/prova_311_510/octave-5.1.0-2.x86_64/src/octave-5.1.0/test/fntests.m /cygdrive/d/cyg_pub/devel/octave/prova_311_510/octave-5.1.0-2.x86_64/src/octave-5.1.0/test Can anyone try to rebuild the Octave package and let me know if the segfault during test is present or not in your system ? The problem occurs the same way, here, running Win10 Pro 1909 fully updated (a.k.a. Version 10.0.18363.592), no extra AntiVirus running besides Defender. Be aware that build time is very long (~ 4 hours) and requires a ton of mathematical libraries. The build itself completed in ~30 minutes, here ;-). But then this is a fresh i9, 8-core, 16-thread box. cygport install took ages to complete, though, because objcopy takes spectacularly long to strip those DLLs --- longer than it took to build the whole package! And it does them one at a time. That could profit from some parallelization. So while I waited, I decided to try it with the distributed octave.exe instead. It passes the critical tests without issue. Next step, after cygport inst is done: run the test with the executable in cygport's "inst" directory (to bypass libtool): Success, again! So I tried running the test via libtool, i.e. the run-octave script. And boom it goes. So re-run it in gdb, via libtool (run-octave -g ...). Still crashes, but I didn't manage to get around the SIGSEGV handler in octave. It always caught the SEGV before gdb managed to get there. So my finding, so far, would be that this is related to libtool. Maybe some update to Windows broke the way libtool interacts with not-quite-finished executables... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: git on mounted CIFS is it Git or Cygwin
> -Original Message- > From: L A Walsh > Sent: Monday, January 27, 2020 7:01 AM > Sorry for the delay in the follow up test, it took me some time to get back to the system. > On 2020/01/26 13:56, Jason Pyeron wrote: > > I have an issue with git in Cygwin on windows shares - this is recent > > (worked months ago). > > > Just to be clear, you are running 'git' on Cygwin and not on linux > or some other OS? There is a 'git' that runs on window natively. Have Yes - Cygwin packaged git, as the cygcheck output indicated below. And indeed the files are on a \\server\share with a corresponding fstab entry. Cannot use other applications - not approved. I worked hard to get Cygwin approved on DoD computers. > My first guess was something in git had changed, but in writing this > out, > I think it more likely that it has something to do with 1) your umask > settings > being set overly restrictively. Created a testdir w/no acls on it. By > default > it had acls on my system: > > > cd /tmp; > > mkdir testdir > > lsacl testdir > [u::rwx,g::rwx,g:Untrusted:r-x,m::rwx,o::rwx/u::rwx,g::rwx,g:Untrusted:r-x,m::rwx,o::rwx] > testdir > # of note: my system created those acls by defaults setup on my system. > # Simply creating a directory anywhere on my system will likely have some > # ACL's applied by default > # so for this test, I removed them: > > chacl -B testdir > > lsacl testdir > [u::rwx,g::rwx,o::rwx] testdir > > # above acl corresponds to: > > ll -da testdir lsacl and ll tools are not available on my system. They do not appear to be for Cygwin at all https://cygwin.com/cgi-bin2/package-grep.cgi?grep=bin%2Fll.exe&arch=x86_64 and https://cygwin.com/cgi-bin2/package-grep.cgi?grep=bin%2Flsacl.exe&arch=x86_64 > drwxrwxrwx 2 36 Jan 27 03:34 testdir/ > (user, group and other all have full access) That was with a umask of 0. > Then I created 3 files with my umask set to different settings: > > umask 0; touch u0 > > umask 02; touch u02 > > umask 0377; touch u377 > #looking at permission settings: > > ll testdir > total 0 > -rw-rw-rw- 1 0 Jan 27 03:33 u0 > -rw-rw-r-- 1 0 Jan 27 03:33 u02 > -r 1 0 Jan 27 03:34 u377 > # Note the last case, gave the user read-only access and nothing > to group and other. So something that changed the umask could > duplicate your symptoms. > > So a setting in 'git' might have changed to change the bits > in the permissions or in the umask (aside from something changing your > default umask value). #bare repo $ umask 0022 $ git fetch remote: Counting objects: 410, done. fatal: write error: Permission denied fatal: index-pack failed $ dir objects/pack/*tmp* -r--r--r-- 1 USER GROUPXXX 12 Jan 28 17:27 objects/pack/tmp_pack_kxvLWs $ touch objects/pack/tmp_test_touch_sdfsdfsdf $ mktemp -p objects/pack/ tmp_test_mktemp_XX objects/pack/tmp_test_mktemp_ZwIIZw $ dir objects/pack/*tmp* -r--r--r-- 1 USER GROUPXXX 12 Jan 28 17:27 objects/pack/tmp_pack_kxvLWs -rw-r--r-- 1 USER GROUPXXX 0 Jan 28 17:28 objects/pack/tmp_test_mktemp_ZwIIZw -rw-r--r-- 1 USER GROUPXXX 0 Jan 28 17:27 objects/pack/tmp_test_touch_sdfsdfsdf > Possibly using 'strace' would allow you to see how or why > the file is created with the wrong permissions. I can strace /bin/echo - so it is possible to do that, but it is the pack sub command, I will have to ponder on how to strace the sub process. > > Also, if you really are working on a network disk -- how you mount > and how the disk is exported can also set default permissions and $ cat /etc/fstab | grep -v ^# none /cygdrive cygdrive binary,posix=0,user 0 0 //host/share/ /mnt// ntfs binary,notexec,noacl,user 1 1 $ mount //host/share on /mnt/ type hgfs (binary,notexec,noacl,user) C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) C:/cygwin64 on / type ntfs (binary,auto) B: on /cygdrive/b type hgfs (binary,posix=0,user,noumount,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) Z: on /cygdrive/z type hgfs (binary,posix=0,user,noumount,auto) > umask effects. There can be ALOT of things that could be causing > your problem, BUT, the simplest, and easiest to break w/o knowing > it, would be something changing somethign like the umask or default > permissions on the directory (i.e. the same symptom could be created > by ACLs). Touch and mktemp are not impacted, so why is git (pushing away from strace for now, trying logical discussion first) > > Hope this gives you some ideas on what to check -- if lucky > it's an easy find, if not, well, could take alot more investigation. > > good luck! > Linda > > > Renaming the file works in either case. > > > > What I need help in is determining if this is a bug or a special case of > > mounting a windows share? Is this a Cygwin issue or a git issue? > > Performi
Re: cygrunsrv does not start cygsshd at boot
On 2020-01-28 14:56, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: >> As the reg entries show, you can also do this by adding or setting registry >> entries using Cygwin regtool, Windows reg, or regedit commands. > > It is better and much safer to use native Windows service controller > commands, than tweaking the registry: > > sc config cygsshd start= delayed-auto Agreed, reg is useful for checking and doing in non-scripting languages. > Also, you won't need (or generally want) to use service pre-shutdown, as it > can cause a very long delay when Windows restarts. > https://docs.microsoft.com/en-us/windows/win32/services/service-control-handler-function Don't see where you read that? Preshutdown happens before regular service shutdown starts. Nothing to do with startup or restart! -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: I don't really know... ALSO: I am not sending mail to Andrew, when I enter the word cygwin, it gets converted somehow...
On 2020-01-28 15:02, aimedtech wrote: > No doubt Andy's a great guy, I just don't want him to think I'm trying to > bother him. > > Now about my install problem: > > I think the problem MIGHT HAVE BEEN (and still is,) that I'm running windoz 7. > > People got angry that I didn't provide additional info, but every method I > tried failed; Each said setup couldn't load the correct info. Probably 25% of the users still use Windows 7. Check your AV, blockers, network, policies. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygrunsrv does not start cygsshd at boot
On 2020-01-28 14:26, Andrey Repin wrote: >> $ cygrunsrv -VQ cygsshd >> Service : cygsshd >> Display name: CYGWIN sshd >> Current State : Running >> Controls Accepted : Stop, Preshutdown >> Command : /usr/sbin/sshd -D >> stdin path : /dev/null >> stdout path : /var/log/cygsshd.log >> stderr path : /var/log/cygsshd.log >> Process Type: Own Process >> Startup : Manual >> Dependencies: dnscache, cygserver, syslog-ng > > I strongly suggest adding "tcpip" here. No - causes problems as tcpip is a kernel driver which is early and low level BOOT_START - other BOOT_START and SYSTEM_START kernel drivers and services depend on tcpip, and later AUTO_START services like dhcp and dnscache depend on those - once those are available, we have a gateway, resolver, and the other network services which we need available to use the network, which is why we need to start Cygwin network services as Delayed auto start (HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/cygsshd Start=2 DelayedAutostart=1) and Preshutdown (cygrunsrv -O, --preshutdown HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/cygsshd/Parameters Preshutdown=1). -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
I don't really know... ALSO: I am not sending mail to Andrew, when I enter the word cygwin, it gets converted somehow...
No doubt Andy's a great guy, I just don't want him to think I'm trying to bother him. Now about my install problem: I think the problem MIGHT HAVE BEEN (and still is,) that I'm running windoz 7. People got angry that I didn't provide additional info, but every method I tried failed; Each said setup couldn't load the correct info. Sent with [ProtonMail](https://protonmail.com) Secure Email.
RE: Is there a way to clone-install Cygwin?
> Yes, this is possible. Thank you. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygrunsrv does not start cygsshd at boot
> As the reg entries show, you can also do this by adding or setting registry > entries using Cygwin regtool, Windows reg, or regedit commands. It is better and much safer to use native Windows service controller commands, than tweaking the registry: sc config cygsshd start= delayed-auto Also, you won't need (or generally want) to use service pre-shutdown, as it can cause a very long delay when Windows restarts. https://docs.microsoft.com/en-us/windows/win32/services/service-control-handler-function My $.02 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Is there a way to clone-install Cygwin?
Greetings, Lavrentiev, Anton (NIH/NLM/NCBI) [C]! > I have a question, is there a way to clone-install Cygwin? > Like I have installed whatever packages I selected on some PC, then > maintained that installation for a while, doing upgrades etc. Now I need to > install the exact same set on another PC. > Can I pull up a list and use it in a sort of a batch install with setup.exe? > I want to avoid to dumb-copy the entire C:\cygwin tree from one PC to another, > rather use a semi-automatic install procedure from scratch, if possible, > using the list of packages that I need. > Thanks for all the insights you can provide. Yes, this is possible. In two ways even. The list you are looking for is, as has been mentioned, /etc/setup/installed.db (you can `cut "-d " -f 1 < installed.db`), then you could call setup.exe with necessary switches to install the set of packages you want. If you want to avoid downloading from external servers, you will have to move your installation cache along with setup binary. -- With best regards, Andrey Repin Wednesday, January 29, 2020 0:15:54 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygrunsrv does not start cygsshd at boot
Greetings, Brian Inglis! > $ cygrunsrv -VQ cygsshd > Service : cygsshd > Display name: CYGWIN sshd > Current State : Running > Controls Accepted : Stop, Preshutdown > Command : /usr/sbin/sshd -D > stdin path : /dev/null > stdout path : /var/log/cygsshd.log > stderr path : /var/log/cygsshd.log > Process Type: Own Process > Startup : Manual > Dependencies: dnscache, cygserver, syslog-ng I strongly suggest adding "tcpip" here. > Account : LocalSystem -- With best regards, Andrey Repin Wednesday, January 29, 2020 0:26:12 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: gmp-6.2.0-1
GNU Multiple Precision Arithmetic Library = GMP is a free library for arbitrary precision arithmetic, operating on signed integers, rational numbers, and floating point numbers. There is no practical limit to the precision except the ones implied by the available memory in the machine GMP runs on. GMP has a rich set of functions, and the functions have a regular interface. --8<---cut here---start->8--- Changes between GMP version 6.1.* and 6.2.0 BUGS FIXED gmp_snprintf now correctly reports an error (returns -1) when snprintf does. Conversion to double is now more robust even if the configuration process does not recognize the float format. mpz_powm could return a not completely normalised value, when the exponent was 1 and the base < 0. mpf_set_str could create invalid mpf_t variables for input strings with many leading zeros. FEATURES New C++ functions factorial, primorial and fibonacci for mpz_class. Functions to detect primality now substitute the first 24 Miller-Rabin iterations with the BPSW test. Mini-GMP: new functions mpz_2fac_ui and mpz_mfac_uiui. Mini-GMP: mpz_sizeinbase, mpz_get_str, and mpz_set_str now support bases up to 62. Mini-GMP: added support for the mpq_t layer. MIPS r6 cores are now supported. SPEEDUPS Major speedup for AMD Ryzen and Epyc thanks to an extensive set of assembly code. Major speedup for IBM POWER9 thanks to assembly code making use of new madd instruction. Speedup for 64-bit ARM CPUs thanks to new/improved assembly code. The n-over-k function mpz_bin_ui has been reimplemented for great speedups for large operands. Speedup for the worst case of mpz_perfect_power_p. Speedup for gcd for small and medium size operands. Speedup for really huge multiplies thanks to much larger FFT tables. MISC Internal representation of the mpz_t variables now supports lazy allocation; memory is allocated only when a value is stored. Small improvements and better coverage for the test suite. The tune/speed program can measure some more functions. The low-level function mpn_mul no longer diverts to mpn_sqr, users should call mpn_sqr directly when applicable. New installed files gmp.pc and gmpxx.pc, for use with pkg-config. Contributed by Hugh McMaster. --8<---cut here---end--->8--- -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: headache on build repeatibility: octave vs BLODA ?
Marco Atzeri writes: > I just found that my W10 Home is 1909 build 18363.592 so probably was > updated as your around mid Jan > > https://docs.microsoft.com/en-us/windows/release-information/ > > But Corporate versions have different time table and patch Enterprise is, yes. > the one I have is Version 1709 Build 16299.15 > It seems Corporate IT is forgetting to update it at all. They currently have at least three different release branches which are supported (for the clients, server versions is yet another story). At my company they switched us to 1803 recently. Going forward I think there will be fewer supported options even for Enterprise if I read things correctly. But MS will have to wait out until the current support periods end. > This release had caused problems to some AV, so may be is changing > the play in area that are causing problems also to us. I still think it's a latent bug that manifests just now. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: headache on build repeatibility: octave vs BLODA ?
Am 28.01.2020 um 18:25 schrieb ASSI: Achim Gratz writes: Same thing here… Since some of the discussion revolved on Windows versions: that is on Win10 Pro 1909, fully patched. I no longer have a system with 1809 since the period where you could hold up the update has expired recently. There is an ISO image for Windows Server 2016 LTS (essentially 1709 I think) that you can use for free for 90 days (you can install it into a VHD and then boot that). To (offixcially) get other Windows versions for testing you'd either have to have the licenses or have some sort of subscription with MSDN. If you do have older install media or ISO, then of course you can do the install into the VHD trick again. A Win 10 Pro can boot the VHD in a Hyper-V instance. Regards, Achim. Ok Achim, you destroyed my theory I just found that my W10 Home is 1909 build 18363.592 so probably was updated as your around mid Jan https://docs.microsoft.com/en-us/windows/release-information/ But Corporate versions have different time table and patch the one I have is Version 1709 Build 16299.15 It seems Corporate IT is forgetting to update it at all. May be Takashi one is also behind in update and currently free from the new bug/behaviour. What I found interesting is that https://docs.microsoft.com/en-us/windows/release-information/status-windows-10-1909 This release had caused problems to some AV, so may be is changing the play in area that are causing problems also to us. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: headache on build repeatibility: octave vs BLODA ?
Achim Gratz writes: > Same thing here… Since some of the discussion revolved on Windows versions: that is on Win10 Pro 1909, fully patched. I no longer have a system with 1809 since the period where you could hold up the update has expired recently. There is an ISO image for Windows Server 2016 LTS (essentially 1709 I think) that you can use for free for 90 days (you can install it into a VHD and then boot that). To (offixcially) get other Windows versions for testing you'd either have to have the licenses or have some sort of subscription with MSDN. If you do have older install media or ISO, then of course you can do the install into the VHD trick again. A Win 10 Pro can boot the VHD in a Hyper-V instance. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: headache on build repeatibility: octave vs BLODA ?
On Tue, 28 Jan 2020 07:41:43 +0100 Marco Atzeri wrote: > So I am now almost sure that the recent MS updates changed/broke > something in W10 Home. :-(( I have tried now in Win10 Home 1909, and segmentagion fault has occured at the same place as you. Microsoft Windows [Version 10.0.18363.592] -- Takashi Yano -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cin and read(*,*) not waiting for kbd input in gdb
On 27/01/2020 16:44, Rockefeller, Harry wrote: I don't know if this is a gdb or a Cygwin implementation of gdb that is a problem. Since I can go back to gdb version 8.1.1-1 this is not a problem for me now. Here is a test case using the Fortran source above: $ gfortran -g test1.f -o test1.exe harryr@HARRYR-PC ~/d62sim/Excel $ gdb test1 GNU gdb (GDB) (Cygwin 8.3.1-1) 8.3.1 [...] (gdb) 277 fflush (stdin); (gdb) /wip/cygport-git/gdb/gdb-8.3.1-1.x86_64/src/gdb-8.3.1/gdb/infrun.c:2602: internal-error: void resume_1(gdb_signal): Assertion `pc_in_thread_step_range (pc, tp)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n)y Thanks for reporting this problem, and the reproduction steps. I can reproduce this, but this doesn't seem to be a regression as I can also reproduce it with 8.1.1-1 (and with 7.9.1-1). On a brief investigation this seems to be related to trying to step through an import stub. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: grace broken installation
On 1/28/2020 1:38 AM, Brian Inglis wrote: > Links should only be applied during build processes to allow building and > testing to complete successfully. > Build link types may not be compatible with tar or the target file system and > should not be included in packages for distribution e.g. they may only work on > systems configured for WSL and with WSL installed. > Distributed package links should be generated during post-install processing > and > should fall back to file copies if links are unsupported on the target file > system. Many Cygwin packages contain symlinks that are not generated during post-install. setup handles them just fine. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
