Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
I don't know why I didn't get the reply in email, but this is representative of
the real world code.
- Jay
From: Jay K
Sent: Wednesday, January 12, 2022 6:27 AM
To: cyg...@sourceware.org
Subject: Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
Ok, here is a small demonstration of the problem.
#include
#include
#include
unsigned __stdcall thread(void* p)
{
unsigned i;
for (i = 0; i < 100; ++i)
system("./a.exe");
return 0;
}
int main()
{
unsigned i;
HANDLE threads[100] = {0};
FILE* f = fopen("a.c", "w");
fprintf(f, "int main() { return 0; }\n");
fclose(f);
system("g++ a.c");
for (i = 0; i < 100; ++i)
threads[i] = CreateThread(0, 0, thread, 0,0,0);
for (i = 0; i < 100; ++i)
WaitForSingleObject(threads[i], -1);
}
$ ./1.exe
0 [main] sh 9287 C:\cygwin64\bin\sh.exe: *** fatal error - internal error
reading the windows environment - too many environment variables?
3001 [main] sh 9287
cygwin_exception::open_stackdumpfile: Dumping stack trace to sh.exe.stackdump
0 [main] sh 9286
C:\cygwin64\bin\sh.exe: *** fatal error - internal error reading the windows
environment - too many environment variables?
Stack trace:
Frame Function Args
000CD30 00180061C6E (001802795F0, 00180269E81, 000, 000BB20)
000CD30 0018004849A (228, 0080160, 000, 000CD30)
000CD30 001800484D2 (000, 000, 000, 000)
000CD30 0018005F12D (00180158C19, 000, 000, 000CD30)
000CD30 00180103AE4 (000, 000, 000, 000)
000CD30 00180048BC2 (000, 000, 000, 000)
000FFF0 00180047746 (000, 000, 000, 000)
000FFF0 001800477F4 (000, 000, 000, 000)
End of stack trace
0 [waitproc] 1 9269 proc_waiter: error on read of child
wait pipe 0x0, Win32 error 6
1078 [waitproc] 1 9269 proc_waiter: error on read of child wait
pipe 0x0, Win32 error 6
4452 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
sh: ./a.exe: Bad address
11522 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
sh: ./a.exe: Bad address
sh: ./a.exe: Bad address
38623 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
48009 [waitproc] 1 9269 proc_waiter: error on read of child wait
pipe 0x0, Win32 error 6
48660 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
49909 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
I understand I can workaround this, in that the use of threads is silly.
Is this invalid, to mix Win32 threads with cygwin system()?
- Jay
From: Jay K
Sent: Wednesday, January 12, 2022 5:57 AM
To: cyg...@sourceware.org
Subject: Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
Um, I know this isn't (yet) diligent/scientific, but must system create this
thread?
#0 0x7ff811e09e47 in KERNEL32!CreateThread () from
/cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#1 0x0001800468eb in cygthread::create() () from /usr/bin/cygwin1.dll
#2 0x00018010645f in pinfo::wait() () from /usr/bin/cygwin1.dll
#3 0x00018012e562 in proc_subproc(unsigned int, unsigned long) () from
/usr/bin/cygwin1.dll
#4 0x000180134e85 in child_info_spawn::worker(char const*, char const*
const*, char const* const*, int, int, int) () from /usr/bin/cygwin1.dll
#5 0x000180136729 in spawnve () from /usr/bin/cygwin1.dll
#6 0x000180136d05 in spawnvp () from /usr/bin/cygwin1.dll
#7 0x000180144683 in system () from /usr/bin/cygwin1.dll
#8 0x00018018effb in _sigfe () from /usr/bin/cygwin1.dll
#9 0x00010052884b in QMachine__ExecCommand (t_L_563=0x448ef0
"\260\324\005",
'cause i.e. it complicates any lifetime/management.
I do understand some of the problems here, like needing separate threads to
read stdout/stderr, if they are not equal.
- Jay
From: Jay K
Sent: Wednesday, January 12, 2022 4:12 AM
To: cyg...@sourceware.org
Subject: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
I get this a lot:
0 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0,
ExitProcess does not work in Cygwin?
ExitProcess does not work in Cygwin?
$ rm *.exe
# u is for Unix
# w is for Windows
$ cat u.c
#include
int main()
{
exit(1);
}
$ gcc u.c
$ ./a.exe
$ echo $?
1
=> as expected
$ cat w.c
#include
int main()
{
ExitProcess(1);
}
$ gcc w.c
$ ./a.exe
$ echo $?
0
=> not expected
$ uname -a
CYGWIN_NT-10.0 jayk-tp4 3.3.3(0.341/5/3) 2021-12-03 16:35 x86_64 Cygwin
works in debugger:
$ /cygdrive/c/bin/amd64/windbg.exe .\\a.exe
$ echo $?
1
?
- Jay
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ITP] biosig [was: Re: newcomer issues when packaging biosig, stimfit, etc.]
Am 1/12/22 um 06:47 schrieb Marco Atzeri:
In the meantime, please find below the status for the libb64 and
biosig packages.
Thanks that was helpful. Attached is an updated version for biosig
and libb64.
cygport libb64.cygport all
cygport biosig.cygport all
runs now w/o error. How can I test whether result can be installed
and used ?
One major problem.
Never build in the source directory, the final src.patch
must fit with you desired patch.
So only what you patched should come out.
For this package that does not respect the build in a
different directory than source, you shoud start
with something like:
src_compile() {
cd ${S}
lndirs
cd ${B}
cygautoreconf
cygconf
cygmake
}
I've adapted biosig.cygport accordingly and addressed this in the
attached version. It runs fine when doing
cygport biosig.cygport all
runs w/o error. Also testing the package with
tar -C / -xvf
biosig-2.3.3-1.x86_64/dist/biosig/biosig-tools/biosig-tools-2.3.3-1.tar.xz
tar -C / -xvf
biosig-2.3.3-1.x86_64/dist/biosig/libbiosig/libbiosig-2.3.3-1.tar.xz
tar -C / -xvf
biosig-2.3.3-1.x86_64/dist/biosig/libbiosig-devel/libbiosig-devel-2.3.3-1.tar.xz
and running
save2gdf -h
works fine.
Moreover, I understand now why my libb64.cygport file is not ready.
ecause libb64 is not necessary for libbiosig's support of Stimfit, I'll
omit libb64 for now.
Would you please check whether Biosig is ready to be included in cygwin ?
Cheers,
Alois
# package name
NAME="biosig"
VERSION=2.3.3
RELEASE=1
# .hint generation
CATEGORY="Libs,Science"
SUMMARY="Tools for biomedical signal processing."
DESCRIPTION="BioSig is an open source software library for
biomedical signal processing, featuring for example the
analysis of biosignals such as the electroencephalogram (EEG),
electrocorticogram (ECoG), electrocardiogram (ECG),
electrooculogram (EOG), electromyogram (EMG), respiration,
and so on. Major application areas are: Neuroinformatics,
brain-computer interfaces, neurophysiology, psychology, c
ardiovascular systems and sleep research. The aim of the
BioSig project is to foster research in biomedical signal
processing by providing open source software tools for many
different applications. Generally, many concerns have to be a
ddressed in this scientific field. BioSig handles this by providing
solutions for data acquisition, artifact processing, quality control,
feature extraction, classification, modeling, data visualization, etc. "
# source and patch files
SRC_URI="https://sourceforge.net/projects/biosig/files/BioSig%20for%20C_C%2B%2B/src/biosig-2.3.3.src.tar.gz;
# PATCH_URI="biosig-2.3.3-fix-build.patch"
# use the standard src_compile, src_install and src_test
PKG_NAMES="libbiosig libbiosig-devel biosig-tools"
biosig_tools_CONTENTS="
usr/bin/save2gdf.exe
usr/bin/physicalunits.exe
usr/bin/biosig2gdf.exe
usr/share/man/man1/save2gdf.1.gz
usr/share/man/man1/biosig2gdf.1.gz
usr/share/man/man1/biosig_fhir.1.gz
usr/share/man/man1/physicalunits.1.gz
usr/share/doc/biosig/COPYING
usr/share/doc/biosig/README
"
# not included yet
# usr/share/man/biosig_fhir.1 usr/share/man/sigviewer.1
libbiosig_CONTENTS="
usr/bin/libbiosig.dll
usr/bin/libphysicalunits.dll
"
libbiosig_devel_CONTENTS="
usr/include/biosig-dev.h
usr/include/biosig.h
usr/include/biosig2.h
usr/include/gdftime.h
usr/include/physicalunits.h
usr/include/biosig-network.h
usr/include/mdc_ecg_codes.h
usr/lib/libbiosig.a
usr/lib/libbiosig.dll.a
usr/lib/libphysicalunits.a
usr/lib/libphysicalunits.dll.a
usr/lib/pkgconfig/libbiosig.pc
"
DIFF_EXCLUDES="depend"
# use not standard src_compile, src_install and src_test
src_compile() {
cd ${S}
lndirs
cd ${B}
cygautoreconf
cygconf # --prefix=/usr
# libbiosig
cygmake lib
# biosig-tools w/o biosig_fhir
cygmake -C biosig4c++ save2gdf physicalunits biosig2gdf
# python3-biosig
}
src_install() {
cd ${S}
doinclude ${S}/biosig4c++/*.h
dobin ${B}/biosig4c++/save2gdf.exe
# dobin ${B}/biosig4c++/biosig_fhir.exe
dobin ${B}/biosig4c++/biosig2gdf.exe
dobin ${B}/biosig4c++/physicalunits.exe
dobin ${B}/biosig4c++/libbiosig.dll
dobin ${B}/biosig4c++/libphysicalunits.dll
dolib ${B}/biosig4c++/libbiosig.dll.a
dolib ${B}/biosig4c++/libbiosig.a
dolib ${B}/biosig4c++/libphysicalunits.dll.a
dolib ${B}/biosig4c++/libphysicalunits.a
dopkgconfig ${B}/biosig4c++/libbiosig.pc
# doman ${S}/biosig4c++/doc/bin2rec.1
doman ${S}/biosig4c++/doc/biosig2gdf.1
doman ${S}/biosig4c++/doc/biosig_fhir.1
doman ${S}/biosig4c++/doc/physicalunits.1
doman ${S}/biosig4c++/doc/save2gdf.1
}
src_test() {
cd ${S}
biosig4c++/physicalunits.exe
biosig4c++/save2gdf.exe --help
#
Re: python-numpy (1.22.0-1) can't be imported
On 12.01.2022 12:47, ggl329 wrote: Hi Marco, I upgraded python39-numpy to 1.22.0-1, and failed to import numpy. It seems that mtrand.cpython-39-x86_64-cygwin.dll does not have PyInit_mtrand. Could you check if numpy can be imported in your environment? working on it. In theory I have not changed the build between the two versions but there was a patch in 1.19.4-1 for similar issue. Regards Marco -- 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: Dependency of python39-pip
On 12.01.2022 12:21, marco atzeri wrote: On Wed, Jan 12, 2022 at 11:33 AM ggl329 wrote: Hi Marco, Dependency of python39-pip is misdirected, isn't it? [setup.ini] setup-timestamp: 1641920391 @ python39-pip depends2: alternatives, ca-certificates, python38-setuptools, python39 ^^^python39-setuptools? Regards, clearly yes. Let me check and I will re-upload later in the day Thanks for the report Marco -3 on the way. It was always wrong for a typo Regards Marco -- 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: posix_spawn issues on i686
> > > Sorry, I am not subscribed to the list so don't have the message to reply > > > to for threading purposes > New developer snapshot is up at https://cygwin.com/snapshots/ > Please test. This works, and make's "make check" now gets the same results as it does when built with --disable-posix-spawn in i686 cygwin. 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: [PATCH] Cygwin: doc: drop mention of 32-bit installer
On Jan 12 19:17, Jon Turney wrote: > On 12/01/2022 18:51, Corinna Vinschen wrote: > > On Jan 12 15:52, Jon Turney wrote: > > > Drop mention of 32-bit installer, since it's offically discouraged, and > > > planned to be dropped soon. > > > > > > Adjust various references to be something more generic, like 'the Cygwin > > > Setup program' to accomodate this. > > > --- > > > winsup/doc/faq-setup.xml | 12 +++ > > > winsup/doc/setup-net.xml | 74 > > > 2 files changed, 34 insertions(+), 52 deletions(-) > > > [...] > > > > > > -On Windows Vista and later, setup.exe will check by > > > +On Windows Vista and later, setup will check by > >^ > > This will have to be changed for the master branch to mention W7 > > instead. Vista is a dead stinkin' fish at that time. That reminds me, > > we have to do this throughout. Do you want to or shall I? > > Please go ahead. > > In this particular case, the leading clause can simply be dropped, since > "setup will check by default if it runs with administrative privileges ..." > describes the behaviour on all supported Windows versions. Yeah, makes sense. Corinna
Re: [PATCH] Cygwin: doc: drop mention of 32-bit installer
On 12/01/2022 18:51, Corinna Vinschen wrote: On Jan 12 15:52, Jon Turney wrote: Drop mention of 32-bit installer, since it's offically discouraged, and planned to be dropped soon. Adjust various references to be something more generic, like 'the Cygwin Setup program' to accomodate this. --- winsup/doc/faq-setup.xml | 12 +++ winsup/doc/setup-net.xml | 74 2 files changed, 34 insertions(+), 52 deletions(-) [...] -On Windows Vista and later, setup.exe will check by +On Windows Vista and later, setup will check by ^ This will have to be changed for the master branch to mention W7 instead. Vista is a dead stinkin' fish at that time. That reminds me, we have to do this throughout. Do you want to or shall I? Please go ahead. In this particular case, the leading clause can simply be dropped, since "setup will check by default if it runs with administrative privileges ..." describes the behaviour on all supported Windows versions.
Re: [PATCH] Cygwin: doc: drop mention of 32-bit installer
On Jan 12 15:52, Jon Turney wrote: > Drop mention of 32-bit installer, since it's offically discouraged, and > planned to be dropped soon. > > Adjust various references to be something more generic, like 'the Cygwin > Setup program' to accomodate this. > --- > winsup/doc/faq-setup.xml | 12 +++ > winsup/doc/setup-net.xml | 74 > 2 files changed, 34 insertions(+), 52 deletions(-) > [...] > > -On Windows Vista and later, setup.exe will check by > +On Windows Vista and later, setup will check by ^ This will have to be changed for the master branch to mention W7 instead. Vista is a dead stinkin' fish at that time. That reminds me, we have to do this throughout. Do you want to or shall I? Other than that, :+1: and push at your discretion. Corinna
Re: [PATCH] fhandler_proc.cc(format_proc_cpuinfo): add Linux 5.16 Gobble Gobble flags
On Jan 12 09:32, Brian Inglis wrote: > On 2022-01-12 03:18, Corinna Vinschen wrote: > > On Jan 11 23:04, Brian Inglis wrote: > > > Subject: [PATCH] fhandler_proc.cc(format_proc_cpuinfo): add Linux 5.16 > > > Gobble Gobble flags > > > > Gobble Gobble? > > > > Did I miss something or is that a preliminary subject line? :) > > Linux 5.16 codename from rc3 which came out about US Thanksgiving; see > bottom of thread: > > https://lkml.kernel.org/lkml/163789349650.12632.8523698126811716771.pr-tracker-...@kernel.org/t/#u > > noticed: > > https://www.phoronix.com/scan.php?page=news_item=Linux-5.16-rc3 > > from scripts monitoring cpuid usage and cpuinfo changes across releases: > > diff -pu linux-prev/Makefile linux-next/Makefile > --- linux-prev/Makefile 2021-10-31 14:53:10.0 -0600 > +++ linux-next/Makefile 2022-01-11 07:45:05.0 -0700 > @@ -1,9 +1,9 @@ > # SPDX-License-Identifier: GPL-2.0 > VERSION = 5 > -PATCHLEVEL = 15 > +PATCHLEVEL = 16 > SUBLEVEL = 0 > EXTRAVERSION = > -NAME = Trick or Treat > +NAME = Gobble Gobble Heh, ok. Thanks and pushed. Corinna
Re: posix_spawn issues on i686
On 1/12/2022 5:41 AM, Corinna Vinschen wrote: On Jan 11 16:08, Ken Brown wrote: I don't have time to check this carefully, but it looks to me like the problem is that process_spawnattr calls setegid and seteuid instead of setegid32 and seteuid32. This causes truncation of the gid and uid. You're right. Additionally the calls to getgid and getuid have to use the internal getgid32 and getuid32 functions. I'll be glad when this 32-bit cruft can be removed. It is *very* confusing to read the code and see a function called getuid that is really only used by old applications, except when it's accidentally used internally. I introduced a 32-bit-only bug a couple years ago because of a similar confusion between fstat and fstat64. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH] fhandler_proc.cc(format_proc_cpuinfo): add Linux 5.16 Gobble Gobble flags
On 2022-01-12 03:18, Corinna Vinschen wrote: On Jan 11 23:04, Brian Inglis wrote: Subject: [PATCH] fhandler_proc.cc(format_proc_cpuinfo): add Linux 5.16 Gobble Gobble flags Gobble Gobble? Did I miss something or is that a preliminary subject line? :) Linux 5.16 codename from rc3 which came out about US Thanksgiving; see bottom of thread: https://lkml.kernel.org/lkml/163789349650.12632.8523698126811716771.pr-tracker-...@kernel.org/t/#u noticed: https://www.phoronix.com/scan.php?page=news_item=Linux-5.16-rc3 from scripts monitoring cpuid usage and cpuinfo changes across releases: diff -pu linux-prev/Makefile linux-next/Makefile --- linux-prev/Makefile 2021-10-31 14:53:10.0 -0600 +++ linux-next/Makefile 2022-01-11 07:45:05.0 -0700 @@ -1,9 +1,9 @@ # SPDX-License-Identifier: GPL-2.0 VERSION = 5 -PATCHLEVEL = 15 +PATCHLEVEL = 16 SUBLEVEL = 0 EXTRAVERSION = -NAME = Trick or Treat +NAME = Gobble Gobble ... -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
Re: Cygwin setup writing incorrect symlinks for native
On 12/01/2022 16:03, David Allsopp wrote: Jon Turney wrote: 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! Great! Thanks for reporting this problem and testing my several attempts at fixing it :) -- 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: setup (2.915)
A new version of Setup (2.915) has been uploaded to: https://cygwin.com/setup-x86_64.exe (64 bit version) https://cygwin.com/setup-x86.exe (32 bit version) Changes compared to 2.912: - Various fixes for symlinks to absolute paths made when '--symlink-type native' is used Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250398.html - When in unattended mode, ignore attempts to close setup via GUI Addresses: https://cygwin.com/pipermail/cygwin/2021-November/250079.html For instructions on obtaining and building the source code for setup, see https://sourceware.org/cygwin-apps/setup.html Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT 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
Updated: setup (2.915)
A new version of Setup (2.915) has been uploaded to: https://cygwin.com/setup-x86_64.exe (64 bit version) https://cygwin.com/setup-x86.exe (32 bit version) Changes compared to 2.912: - Various fixes for symlinks to absolute paths made when '--symlink-type native' is used Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250398.html - When in unattended mode, ignore attempts to close setup via GUI Addresses: https://cygwin.com/pipermail/cygwin/2021-November/250079.html For instructions on obtaining and building the source code for setup, see https://sourceware.org/cygwin-apps/setup.html Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT com.
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
[PATCH] Cygwin: doc: drop mention of 32-bit installer
Drop mention of 32-bit installer, since it's offically discouraged, and planned to be dropped soon. Adjust various references to be something more generic, like 'the Cygwin Setup program' to accomodate this. --- winsup/doc/faq-setup.xml | 12 +++ winsup/doc/setup-net.xml | 74 2 files changed, 34 insertions(+), 52 deletions(-) diff --git a/winsup/doc/faq-setup.xml b/winsup/doc/faq-setup.xml index c04ffe9a5..740c6fefb 100644 --- a/winsup/doc/faq-setup.xml +++ b/winsup/doc/faq-setup.xml @@ -12,9 +12,8 @@ There is only one recommended way to install Cygwin, which is to use the -Cygwin Setup program, a GUI installer named -setup-x86_64.exe for 64 bit Windows, or -setup-x86.exe for 32 bit Windows. It is flexible and easy to use. +Cygwin Setup program, a GUI installer. +It is flexible and easy to use. You can pick and choose the packages you wish to install, and update them individually. Full source code is available for all packages and tools. @@ -191,7 +190,6 @@ Here is how Cygwin secures the installation and update process to counter The Cygwin website provides the Cygwin Setup program -(setup-x86.exe or setup-x86_64.exe) using HTTPS (SSL/TLS). This authenticates that the Cygwin Setup program came from the Cygwin website @@ -261,8 +259,7 @@ widely-used SHA-2 suite of cryptographic hashes). To best secure your installation and update process, download -the Cygwin Setup program setup-x86_64.exe (64-bit) or -setup-x86.exe (32-bit), and then +the Cygwin Setup program, and then check its signature (using a signature-checking tool you trust) using the Cygwin public key (https://cygwin.com/key/pubring.asc"/>). @@ -318,8 +315,7 @@ archives. If this happens to you, consider disabling your anti-virus software when running the Cygwin Setup program. The following procedure should be a fairly safe way to do that: -Download setup-x86_64.exe or -setup-x86.exe and scan it explicitly. +Download the Cygwin Setup program and scan it explicitly. Turn off the anti-virus software. diff --git a/winsup/doc/setup-net.xml b/winsup/doc/setup-net.xml index 82b1e0dc9..db39bb66c 100644 --- a/winsup/doc/setup-net.xml +++ b/winsup/doc/setup-net.xml @@ -8,9 +8,7 @@ Internet Setup To install the Cygwin net release, go to https://cygwin.com/"/> and run either -https://cygwin.com/setup-x86.exe;>setup-x86.exe -to install the 32 bit version of Cygwin, or +url="https://cygwin.com/"/> and run https://cygwin.com/setup-x86_64.exe;>setup-x86_64.exe to install the 64 bit version of Cygwin. This will download a GUI installer which can be run to download a complete cygwin installation @@ -18,33 +16,21 @@ via the internet. Follow the instructions on each screen to install Cygwin. - -For easier reading the installer is called setup.exe -throughout the following sections. This refers likewise to both -installer applications, -https://cygwin.com/setup-x86.exe;>setup-x86.exe -for 32 bit, as well as -https://cygwin.com/setup-x86_64.exe;>setup-x86_64.exe -for 64 bit. Apart from the target architecture they are the same thing. - - - - -The setup.exe installer is designed to be easy +The setup installer is designed to be easy for new users to understand while remaining flexible for the experienced. The volunteer development team is constantly working -on setup.exe; before requesting a new feature, +on setup; before requesting a new feature, check the wishlist in the https://sourceware.org/git/gitweb.cgi?p=cygwin-setup.git;a=blob_plain;f=README;hb=HEAD;>Git README . It may already be present in the Git version! -On Windows Vista and later, setup.exe will check by +On Windows Vista and later, setup will check by default if it runs with administrative privileges and, if not, will try to elevate the process. If you want to avoid this behaviour and install under an unprivileged account just for your own usage, run -setup.exe with the --no-admin option. +setup with the --no-admin option. @@ -54,7 +40,7 @@ installed by simply clicking the Next button at each page. The only exception to this is choosing a Cygwin mirror, which you can choose by experimenting with those listed at https://cygwin.com/mirrors.html"/>. For more details about each of page of the -setup.exe installation, read on below. +setup installation, read on below. Please note that this guide assumes that you have a basic understanding of Unix (or a Unix-like OS). If you are new to Unix, you will also want to make use of http://www.google.com/search?q=new+to+unix;> @@ -65,7 +51,7 @@ other resources. Cygwin uses packages to manage installing various software. When the default Install from Internet option is chosen, -setup.exe creates a local directory to store +setup creates a local directory to store the packages before actually installing the contents. Download from Internet performs only the first part (storing the packages locally), while @@ -79,8 +65,8
python-numpy (1.22.0-1) can't be imported
Hi Marco, I upgraded python39-numpy to 1.22.0-1, and failed to import numpy. It seems that mtrand.cpython-39-x86_64-cygwin.dll does not have PyInit_mtrand. Could you check if numpy can be imported in your environment? $ python3.9 Python 3.9.9 (main, Dec 5 2021, 13:29:55) [GCC 11.2.0] on cygwin Type "help", "copyright", "credits" or "license" for more information. import numpy Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.9/site-packages/numpy/__init__.py", line 155, in from . import random File "/usr/lib/python3.9/site-packages/numpy/random/__init__.py", line 180, in from . import _pickle File "/usr/lib/python3.9/site-packages/numpy/random/_pickle.py", line 1, in from .mtrand import RandomState ImportError: dynamic module does not define module export function (PyInit_mtrand) == python39-numpy 1.22.0-1 == $ objdump.exe -x /usr/lib/python3.9/site-packages/numpy/random/mtrand.cpython-39-x86_64-cygwin.dll (snip) [Ordinal/Name Pointer] Table [ 0] random_beta [ 1] random_binomial [ 2] random_bounded_bool_fill [ 3] random_bounded_uint16_fill [ 4] random_bounded_uint32_fill ... == python39-numpy 1.21.4-1 == $ objdump.exe -x /usr/lib/python3.9/site-packages/numpy/random/mtrand.cpython-39-x86_64-cygwin.dll (snip) [Ordinal/Name Pointer] Table [ 0] PyInit_mtrand [ 1] __gcc_deregister_frame [ 2] __gcc_register_frame [ 3] __pyx_module_is_main_numpy__random__mtrand [ 4] legacy_beta ... ## 1.21.4-1 has PyInit_mtrand. Regards, -- ggl329 -- 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: posix_spawn issues on i686
On Jan 12 11:41, Corinna Vinschen wrote: > On Jan 11 16:08, Ken Brown wrote: > > On 1/11/2022 1:45 PM, Jeremy Drake via Cygwin wrote: > > > Sorry, I am not subscribed to the list so don't have the message to reply > > > to for threading purposes, but attached please find a C reproducer that > > > works on x86_64 but fails on i686. The particular issue seems to be the > > > POSIX_SPAWN_RESETIDS flag - not setting that allows i686 to succeed too. > > Thanks for the STC, Jeremy! > > > I don't have time to check this carefully, but it looks to me like the > > problem is that process_spawnattr calls setegid and seteuid instead of > > setegid32 and seteuid32. This causes truncation of the gid and uid. > > You're right. Additionally the calls to getgid and getuid have to use > the internal getgid32 and getuid32 functions. > > I'll apply a fix. New developer snapshot is up at https://cygwin.com/snapshots/ Please test. Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Dependency of python39-pip
On Wed, Jan 12, 2022 at 11:33 AM ggl329 wrote: > > Hi Marco, > > Dependency of python39-pip is misdirected, isn't it? > > [setup.ini] > setup-timestamp: 1641920391 > @ python39-pip > depends2: alternatives, ca-certificates, python38-setuptools, python39 > >^^^python39-setuptools? > > Regards, clearly yes. Let me check and I will re-upload later in the day Thanks for the report Marco -- 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: posix_spawn issues on i686
On Jan 11 16:08, Ken Brown wrote: > On 1/11/2022 1:45 PM, Jeremy Drake via Cygwin wrote: > > Sorry, I am not subscribed to the list so don't have the message to reply > > to for threading purposes, but attached please find a C reproducer that > > works on x86_64 but fails on i686. The particular issue seems to be the > > POSIX_SPAWN_RESETIDS flag - not setting that allows i686 to succeed too. Thanks for the STC, Jeremy! > I don't have time to check this carefully, but it looks to me like the > problem is that process_spawnattr calls setegid and seteuid instead of > setegid32 and seteuid32. This causes truncation of the gid and uid. You're right. Additionally the calls to getgid and getuid have to use the internal getgid32 and getuid32 functions. I'll apply a fix. Thanks guys! Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Dependency of python39-pip
Hi Marco, Dependency of python39-pip is misdirected, isn't it? [setup.ini] setup-timestamp: 1641920391 @ python39-pip depends2: alternatives, ca-certificates, python38-setuptools, python39 ^^^python39-setuptools? Regards, -- ggl...@gmail.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
Re: [PATCH] fhandler_proc.cc(format_proc_cpuinfo): add Linux 5.16 Gobble Gobble flags
On Jan 11 23:04, Brian Inglis wrote: > Subject: [PATCH] fhandler_proc.cc(format_proc_cpuinfo): add Linux 5.16 Gobble > Gobble flags Gobble Gobble? Did I miss something or is that a preliminary subject line? :) Corinna
[ANNOUNCEMENT] file 5.41-2
The following packages have been uploaded to the Cygwin distribution: * file-5.41-2 * file-devel-5.41-2 * python3-magic-5.41-2 This update rectifies a wrong dependency to python 3.8 in the 32 bit package and removes the obsolete python2 bindings. --- With file you can obtain information on the file type of a specified file. File type recognition is controlled by the file /usr/share/file/magic which contains the classification criteria. -- 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
file 5.41-2
The following packages have been uploaded to the Cygwin distribution: * file-5.41-2 * file-devel-5.41-2 * python3-magic-5.41-2 This update rectifies a wrong dependency to python 3.8 in the 32 bit package and removes the obsolete python2 bindings. --- With file you can obtain information on the file type of a specified file. File type recognition is controlled by the file /usr/share/file/magic which contains the classification criteria.
Re: Duplicate ACLs? - Can't copy file even with Admin permissions
On Jan 10 14:46, Corinna Vinschen wrote: > On Jan 10 11:07, Corinna Vinschen wrote: > > On Jan 7 15:56, cyg...@kosowsky.org wrote: > > > > Corinna Vinschen wrote: > > > > On Jan 6 16:11, cyg...@kosowsky.org wrote: > > > > It is. I realized belatedly, that 3da9e136.acl is apparently a > > > > directory, not a file. > > > > > > It's actually a file... > > > > This is weird. The meaning of the OI and CI markers are "Object > > inheritance" and "Container inheritance". These bits only make sense > > for directories and they control how ACEs are inherited by child objects > > (files) and child containers (subdirs). > > [...] > > I'll have a look into the sources later, but I sure would prefer if > > I could create such a file locally. > > I tried to create a file with equivalent ACL including the inheritence > flags on W7, W10 and W11, but to no avail. Success! I hacked a Q application which opens a file, reads its security descriptor (SD) and just adds the object and container inherit flags to all its DACL' ACEs and writes the SD back. Albeit Windows tools and some of the security functions under the hood don't allow to add inherit flags to files, some functions just write the SD verbatim without checking. So I was finally able to reproduce your issue: $ ./hackup acltest $ icacls acltest acltest NT AUTHORITY\SYSTEM:(OI)(CI)(F) Everyone:(OI)(CI)(RX) BUILTIN\Administrators:(OI)(CI)(F) Successfully processed 1 files; Failed processing 0 files $ getfacl acltest # file: acltest # owner: Administrators # group: SYSTEM user::rwx group::rwx other::r-x user::rwx group::rwx group:SYSTEM:rwx mask::rwx other::r-x The Cygwin DLL reads the DACL and converts it to a POSIX ACL. An ACE with inherit flags set is converted to a POSIX access ACE and additionally to a POSIX default ACE. The latter is done independently of the file type. The calling function (still in Cygwin) doesn't expect default ACEs for files and treats them as access ACEs. That's what you see in the getfacl output above. I fixed this in Cygwin by ignoring inheritance flags unless the object is a directory, so the core function in Cygwin only creates default ACEs for directories. The result when calling getfacl on such a file is thus: $ getfacl acltest # file: acltest # owner: Administrators # group: SYSTEM user::rwx group::rwx other::r-x I uploaded a developer snapshot to https://cygwin.com/snapshots Please give it a try. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Inconsistent results from ls
On Jan 11 18:30, David wrote: > 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? As soon as you use Windows path syntax, file ACLs are ignored and permissions are just faked. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] file 5.41-1
On Jan 12 06:55, Marco Atzeri wrote: > On 12.01.2022 03:01, Brian Inglis wrote: > > On 2022-01-11 11:45, Corinna Vinschen via Cygwin-announce wrote: > > > The following packages have been uploaded to the Cygwin distribution: > > > > > > * file-5.41-1 > > > * file-devel-5.41-1 > > > > Shouldn't this be obsolete: > > > > > * python2-magic-5.41-1 > > I guess file a basic utility and we can leave it around > until we really have nothing serious on python2 I can remove python2-magic, it's not in fedora anymore either. > > replaced by: > > > > > * python3-magic-5.41-1 > > > > which should now depend on python38/39? > > > > just one of them, preferebly the 39 > > Currently is a strange hybrid > > depends: file-devel, python38 (x86), python39 (x86_64) D'oh, sorry. I just rebuilt file and didn't notice this. I'll upload a new version which fixes that. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
