Re: Resend: ca-certificates postinstall permission denied error
Shaddy Baddah writes: > Getting consistent permission denied errors on postinstall of > ca-certificate. > > It appears to be oversight, out of a well-intentioned attempt to > protect script generated reference files. This is caused by p11-kit removing write permissions even for the user from the hash directory when it is finished. This went unnoticed for essentially forever (the commit doing this is over 10 years old), most likely since an admin on Windows will be able to write a new directory entry anyway by way of SeRestorePrivilege and similarly root on UNIX system can still create new files in such directories (unless a suitably restricted SELinux policy is active). > I've experienced this on two installs, both where I run setup exe with > -B, no privelege elevation). Both installs have had an manual > manipulation of the directory, or its parents up to /etc. See above. And since it's p11-kit doing this, just patching up the postinstall script to change permissions won't do, as update-ca-trust will run p11-kit by itself before it tries to create the symlink. Can you try if these patches fiy your issue (if you havent installed ca-certificates-letsencrypt then obviously the second one will not apply)? --8<---cut here---start->8--- --- /usr/bin/update-ca-trust.orig +++ /usr/bin/update-ca-trust @@ -23,9 +23,12 @@ # Hashed directory of BEGIN TRUSTED-style certs (usable as OpenSSL CApath and # by GnuTLS) /usr/bin/p11-kit extract --format=pem-directory-hash --filter=ca-anchors --overwrite --purpose server-auth $DEST/pem/directory-hash +# p11-kit removes write permission to the directory +chmod u+w $DEST/pem/directory-hash # Debian compatibility: their /etc/ssl/certs has this bundle /usr/bin/ln -s ../tls-ca-bundle.pem $DEST/pem/directory-hash/ca-certificates.crt # Backwards compatibility: RHEL/Fedora provided a /etc/ssl/certs/ca-bundle.crt # since https://bugzilla.redhat.com/show_bug.cgi?id=572725 /usr/bin/ln -s ../tls-ca-bundle.pem $DEST/pem/directory-hash/ca-bundle.crt +chmod a-w $DEST/pem/directory-hash --8<---cut here---end--->8--- --8<---cut here---start->8--- --- /etc/postinstall/ca-certificates-letsencrypt.sh.orig +++ /mnt/cygwin32/etc/postinstall/ca-certificates-letsencrypt.sh @@ -1,3 +1,4 @@ +chmod u+w /etc/pki/ca-trust/extracted/pem/directory-hash /usr/bin/ln -s /usr/share/pki/letsencrypt/isrg-intermediate-r3.pem /usr/share/pki/ca-trust-source/anchors/ /usr/bin/ln -s /usr/share/pki/letsencrypt/trustid-root-x3.pem /usr/share/pki/ca-trust-source/blacklist /usr/bin/update-ca-trust --8<---cut here---end--->8--- Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: minor correction: ca-certificates postinstall permission denied error
Hi, On 26/08/2022 1:22 pm, Shaddy Baddah wrote: -B, no privelege elevation). Both installs have had an manual manipulation of the directory, or its parents up to /etc. Both installs have *not* had any manual manipulation... -- Regards, Shaddy -- 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
Resend: ca-certificates postinstall permission denied error
Hi, On 26/08/2022 1:10 pm, Shaddy Baddah wrote: Hi, Getting consistent permission denied errors on postinstall of Apologies for the rendering of the original email. Email client did something unexpected with line breaks. I've loopback tested this resend first. Getting consistent permission denied errors on postinstall of ca-certificate. It appears to be oversight, out of a well-intentioned attempt to protect script generated reference files. There error as it appears in setup.log.full: 2022/08/26 11:39:07 running: e:\cygwin-x86_64\bin\bash.exe --norc --noprofile "/etc/postinstall/ca-certificates.sh" /usr/bin/ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-certificates.crt': Permission denied /usr/bin/ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-bundle.crt': Permission denied 2022/08/26 11:39:21 abnormal exit: exit code=1 The directory permissions are: $ ls -ld /etc/pki/ca-trust/extracted/pem/directory-hash/ dr-xr-xr-x 1 joebloggs Domain Users 0 Aug 26 11:39 /etc/pki/ca-trust/extracted/pem/directory-hash/ I've experienced this on two installs, both where I run setup exe with -B, no privelege elevation). Both installs have had an manual manipulation of the directory, or its parents up to /etc. -- Regards, Shaddy -- 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
ca-certificates postinstall permission denied error
Hi, Getting consistent permission denied errors on postinstall of ca-certificate. It appears to be oversight, out of a well-intentioned attempt to protect script generated reference files. There error as it appears in setup.log.full: 2022/08/26 11:39:07 running: e:\cygwin-x86_64\bin\bash.exe --norc --noprofile "/etc/postinstall/ca-certificates.sh" /usr/bin/ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-certificates.crt': Permission denied /usr/bin/ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-bundle.crt': Permission denied 2022/08/26 11:39:21 abnormal exit: exit code=1 The directory permissions are: $ ls -ld /etc/pki/ca-trust/extracted/pem/directory-hash/ dr-xr-xr-x 1 joebloggs Domain Users 0 Aug 26 11:39 /etc/pki/ca-trust/extracted/pem/directory-hash/ I've experienced this on two installs, both where I run setup exe with -B, no privelege elevation). Both installs have had an manual manipulation of the directory, or its parents up to /etc. -- Regards, Shaddy -- 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: Error when building autoconf2.1, broken package?
Hello,
Il giorno mer 3 ago 2022 alle ore 21:52 Jon Turney
ha scritto:
>
> On 22/07/2022 15:44, Carlo B. wrote:
> > Hello,
> > it works, thank you very much.
> > I also added AUTOCONF_VERSION=2.13 directly into the cygport script,
> > before calling cygconf and it also worked fine without manually
> > setting that environment variable.
> > I think that it would be worth to update the cygport script into
> > autoconf2.1-2.13-12-src.tar.bz2 to make it working again also for
> > other people.
>
> Is there something wrong with our supplied autconf2.1 package?
>
Nowadays, it is not possible to make the autconf2.1 package from "src"
because the errors written in previous emails.
I don't know if the fault is caused by a regression into cygport or it
is needed to fix the "src" package of autconf2.1 for supporting a new
syntax or something like that. Unfortunately, the main problem is that
running the cygport script for autoconf 2.1 still hangs, so perhaps it
would be useful to fix it, in one way or another one.
Thank you very much for your time and your reply.
Sincerely,
Carlo Bramini.
> >
> > Sincerely,
> >
> > Carlo Bramini.
> >
> > Il giorno gio 21 lug 2022 alle ore 15:07 Takashi Yano
> > ha scritto:
> >>
> >> On Tue, 19 Jul 2022 12:42:47 +0200
> >> "Carlo B." wrote:
> >>> Hello,
> >>> I did these actions:
> >>> 1) Downloaded autoconf2.1-2.13-12-src.tar.bz2
> >>> 2) Unpack that file.
> >>> 3) I run this command:
> >>>
> >>> cygport autoconf2.1.cygport all
> >>>
> >>> and this is the output on screen:
> >>>
> >>>>>> Preparing autoconf2.1-2.13-12.x86_64
> >>>>>> Unpacking source autoconf-2.13.tar.gz
> >>> *** Info: applying patch autoconf2.1-texinfo.patch (-p2):
> >>> patching file autoconf.texi
> >>>>>> Preparing working source directory
> >>> *** Info: applying patch autoconf2.1-2.13-12.cygwin.patch (-p2):
> >>> patching file CYGWIN-PATCHES/autoconf2.1.README
> >>>>>> Compiling autoconf2.1-2.13-12.x86_64
> >>> *** ERROR: could not detect autoconf version; perhaps set
> >>> AUTOCONF_VERSION?
>
> This is a regression in cygport, which I'll see about fixing.
>
> (Briefly: cygport tries to detect the version of autoconf which was used
> to generate the ./configure script, so it knows what option arguments to
> supply to it. Recently this was extended to detect autoconf 2.7x, but
> that seems to have broken detecting autoconf 2.1x)
>
> >>>
> >>> Have you an idea of the cause of the problem?
> >>> I tried to download and rebuild also autoconf2.5 and autoconf2.7 and
> >>> they worked fine, only 2.1 fails.
> >>> Thank you very much for your time.
> >>
> >> I could build autoconf2.1 successfully by the following steps.
> >>
> >>
> >> 1) Modify autoconf2.1.cygport as follows.
> >>
> >> diff --git a/autoconf2.1.cygport.orig b/autoconf2.1.cygport
> >> index c8b075f..6876c3c 100755
> >> --- a/autoconf2.1.cygport.orig
> >> +++ b/autoconf2.1.cygport
> >> @@ -28,7 +28,7 @@ src_compile() {
> >> cd ${B}
> >> cygconf --program-suffix=-2.13
> >> cygmake -j1
> >> - (makeinfo --no-split -I ${S} -o autoconf2.13.info autoconf.texi)
> >> + (makeinfo --no-split -o autoconf2.13.info ${S}/autoconf.texi)
>
> I'm not sure why this change is needed.
>
> >> }
> >>
> >> DIFF_EXCLUDES="autoconf.info standards.info stamp-vti version.texi"
> >>
> >> 2) Run 'export AUTOCONF_VERSION=2.13'
> >> 3) Run 'cygport autoconf2.1.cygport all'
--
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: Error when building autoconf2.1, broken package?
On 22/07/2022 15:44, Carlo B. wrote:
Hello,
it works, thank you very much.
I also added AUTOCONF_VERSION=2.13 directly into the cygport script,
before calling cygconf and it also worked fine without manually
setting that environment variable.
I think that it would be worth to update the cygport script into
autoconf2.1-2.13-12-src.tar.bz2 to make it working again also for
other people.
Is there something wrong with our supplied autconf2.1 package?
Sincerely,
Carlo Bramini.
Il giorno gio 21 lug 2022 alle ore 15:07 Takashi Yano
ha scritto:
On Tue, 19 Jul 2022 12:42:47 +0200
"Carlo B." wrote:
Hello,
I did these actions:
1) Downloaded autoconf2.1-2.13-12-src.tar.bz2
2) Unpack that file.
3) I run this command:
cygport autoconf2.1.cygport all
and this is the output on screen:
Preparing autoconf2.1-2.13-12.x86_64
Unpacking source autoconf-2.13.tar.gz
*** Info: applying patch autoconf2.1-texinfo.patch (-p2):
patching file autoconf.texi
Preparing working source directory
*** Info: applying patch autoconf2.1-2.13-12.cygwin.patch (-p2):
patching file CYGWIN-PATCHES/autoconf2.1.README
Compiling autoconf2.1-2.13-12.x86_64
*** ERROR: could not detect autoconf version; perhaps set AUTOCONF_VERSION?
This is a regression in cygport, which I'll see about fixing.
(Briefly: cygport tries to detect the version of autoconf which was used
to generate the ./configure script, so it knows what option arguments to
supply to it. Recently this was extended to detect autoconf 2.7x, but
that seems to have broken detecting autoconf 2.1x)
Have you an idea of the cause of the problem?
I tried to download and rebuild also autoconf2.5 and autoconf2.7 and
they worked fine, only 2.1 fails.
Thank you very much for your time.
I could build autoconf2.1 successfully by the following steps.
1) Modify autoconf2.1.cygport as follows.
diff --git a/autoconf2.1.cygport.orig b/autoconf2.1.cygport
index c8b075f..6876c3c 100755
--- a/autoconf2.1.cygport.orig
+++ b/autoconf2.1.cygport
@@ -28,7 +28,7 @@ src_compile() {
cd ${B}
cygconf --program-suffix=-2.13
cygmake -j1
- (makeinfo --no-split -I ${S} -o autoconf2.13.info autoconf.texi)
+ (makeinfo --no-split -o autoconf2.13.info ${S}/autoconf.texi)
I'm not sure why this change is needed.
}
DIFF_EXCLUDES="autoconf.info standards.info stamp-vti version.texi"
2) Run 'export AUTOCONF_VERSION=2.13'
3) Run 'cygport autoconf2.1.cygport all'
--
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
cloc error - doubled perl in shebang line
Hi, there is an error in the cloc latest release. This has been reported before (https://www.mail-archive.com/cygwin@cygwin.com/msg169201.html), but still isn't fixed as far as I can tell. It appears as if work has started, but has not yet been completed. ( https://github.com/jaalto/cygwin-package--cloc/blob/master/cygwin-announce.mail ) There is still an extra 'perl' in the header in v1.92+20220620+git6777048-1 It can be fixed by manually removing the extra 'perl' in the shebang line. thanks! Karl Brown -- 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: Vim gives error message since 8.2.3755-1
There was a bug upstream and it has been fixed upstream. I'm confident that eventually it will get to us. Meanwhile, I found that if you simply create an empty ~/.exrc, the bug is avoided. See https://bugzilla.redhat.com/show_bug.cgi?id=1969936 Regards, John Ruckstuhl On Mon, Jul 25, 2022 at 2:38 AM marco atzeri wrote: > On Mon, Jul 25, 2022 at 3:12 AM Thomas DiModica via Cygwin wrote: > > > > Since 8.2.3755-1, Vim has given me an error message about being unable > to open the defaults.vim file whenever I open a file with vi. I do not see > this message with 8.2.0486-1. Notably, vi --version for the last two > updates tell me that the user vimrc file is "/home/Marco/.virc", rather > than "$HOME/.virc". Possibly, the problem is that I'm the only person who > actually uses vi to do simple tasks who doesn't customize it to death. > Anyway, it's a nuisance to me, probably will be mysterious to others. > > > > Thanks, > > Thomas D > > > > thanks for the report > > I will look on it for the next release > > 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 > -- 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: Vim gives error message since 8.2.3755-1
On Mon, Jul 25, 2022 at 3:12 AM Thomas DiModica via Cygwin wrote: > > Since 8.2.3755-1, Vim has given me an error message about being unable to > open the defaults.vim file whenever I open a file with vi. I do not see this > message with 8.2.0486-1. Notably, vi --version for the last two updates tell > me that the user vimrc file is "/home/Marco/.virc", rather than > "$HOME/.virc". Possibly, the problem is that I'm the only person who actually > uses vi to do simple tasks who doesn't customize it to death. Anyway, it's a > nuisance to me, probably will be mysterious to others. > > Thanks, > Thomas D > thanks for the report I will look on it for the next release 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: Vim gives error message since 8.2.3755-1
On 7/24/2022 8:11 PM, Thomas DiModica via Cygwin wrote: Since 8.2.3755-1, Vim has given me an error message about being unable to open the defaults.vim file whenever I open a file with vi. I do not see this message with 8.2.0486-1. Notably, vi --version for the last two updates tell me that the user vimrc file is "/home/Marco/.virc", rather than "$HOME/.virc". [snip] Depends on what you are really using, my vim is the alias of vi, and the "user vimrc file: "$HOME/.vimrc", not .virc $ which vi /usr/bin/vi $ type vi vi is aliased to `vim' $ vi --version VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 13 2022 22:15:51) ... system vimrc file: "/etc/vimrc" user vimrc file: "$HOME/.vimrc" 2nd user vimrc file: "~/.vim/vimrc" user exrc file: "$HOME/.exrc" defaults file: "$VIMRUNTIME/defaults.vim" ... My guess is that one of those files have changed things up. Also I think vim detects that it was called with an alias, and may behave differently. -- R.B. -- 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
Vim gives error message since 8.2.3755-1
Since 8.2.3755-1, Vim has given me an error message about being unable to open the defaults.vim file whenever I open a file with vi. I do not see this message with 8.2.0486-1. Notably, vi --version for the last two updates tell me that the user vimrc file is "/home/Marco/.virc", rather than "$HOME/.virc". Possibly, the problem is that I'm the only person who actually uses vi to do simple tasks who doesn't customize it to death. Anyway, it's a nuisance to me, probably will be mysterious to others. Thanks, Thomas D -- 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: Error when building autoconf2.1, broken package?
Hello,
it works, thank you very much.
I also added AUTOCONF_VERSION=2.13 directly into the cygport script,
before calling cygconf and it also worked fine without manually
setting that environment variable.
I think that it would be worth to update the cygport script into
autoconf2.1-2.13-12-src.tar.bz2 to make it working again also for
other people.
Sincerely,
Carlo Bramini.
Il giorno gio 21 lug 2022 alle ore 15:07 Takashi Yano
ha scritto:
>
> On Tue, 19 Jul 2022 12:42:47 +0200
> "Carlo B." wrote:
> > Hello,
> > I did these actions:
> > 1) Downloaded autoconf2.1-2.13-12-src.tar.bz2
> > 2) Unpack that file.
> > 3) I run this command:
> >
> > cygport autoconf2.1.cygport all
> >
> > and this is the output on screen:
> >
> > >>> Preparing autoconf2.1-2.13-12.x86_64
> > >>> Unpacking source autoconf-2.13.tar.gz
> > *** Info: applying patch autoconf2.1-texinfo.patch (-p2):
> > patching file autoconf.texi
> > >>> Preparing working source directory
> > *** Info: applying patch autoconf2.1-2.13-12.cygwin.patch (-p2):
> > patching file CYGWIN-PATCHES/autoconf2.1.README
> > >>> Compiling autoconf2.1-2.13-12.x86_64
> > *** ERROR: could not detect autoconf version; perhaps set AUTOCONF_VERSION?
> >
> > Have you an idea of the cause of the problem?
> > I tried to download and rebuild also autoconf2.5 and autoconf2.7 and
> > they worked fine, only 2.1 fails.
> > Thank you very much for your time.
>
> I could build autoconf2.1 successfully by the following steps.
>
>
> 1) Modify autoconf2.1.cygport as follows.
>
> diff --git a/autoconf2.1.cygport.orig b/autoconf2.1.cygport
> index c8b075f..6876c3c 100755
> --- a/autoconf2.1.cygport.orig
> +++ b/autoconf2.1.cygport
> @@ -28,7 +28,7 @@ src_compile() {
> cd ${B}
> cygconf --program-suffix=-2.13
> cygmake -j1
> - (makeinfo --no-split -I ${S} -o autoconf2.13.info autoconf.texi)
> + (makeinfo --no-split -o autoconf2.13.info ${S}/autoconf.texi)
> }
>
> DIFF_EXCLUDES="autoconf.info standards.info stamp-vti version.texi"
>
> 2) Run 'export AUTOCONF_VERSION=2.13'
> 3) Run 'cygport autoconf2.1.cygport all'
>
> --
> Takashi Yano
--
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: Error when building autoconf2.1, broken package?
On Tue, 19 Jul 2022 12:42:47 +0200
"Carlo B." wrote:
> Hello,
> I did these actions:
> 1) Downloaded autoconf2.1-2.13-12-src.tar.bz2
> 2) Unpack that file.
> 3) I run this command:
>
> cygport autoconf2.1.cygport all
>
> and this is the output on screen:
>
> >>> Preparing autoconf2.1-2.13-12.x86_64
> >>> Unpacking source autoconf-2.13.tar.gz
> *** Info: applying patch autoconf2.1-texinfo.patch (-p2):
> patching file autoconf.texi
> >>> Preparing working source directory
> *** Info: applying patch autoconf2.1-2.13-12.cygwin.patch (-p2):
> patching file CYGWIN-PATCHES/autoconf2.1.README
> >>> Compiling autoconf2.1-2.13-12.x86_64
> *** ERROR: could not detect autoconf version; perhaps set AUTOCONF_VERSION?
>
> Have you an idea of the cause of the problem?
> I tried to download and rebuild also autoconf2.5 and autoconf2.7 and
> they worked fine, only 2.1 fails.
> Thank you very much for your time.
I could build autoconf2.1 successfully by the following steps.
1) Modify autoconf2.1.cygport as follows.
diff --git a/autoconf2.1.cygport.orig b/autoconf2.1.cygport
index c8b075f..6876c3c 100755
--- a/autoconf2.1.cygport.orig
+++ b/autoconf2.1.cygport
@@ -28,7 +28,7 @@ src_compile() {
cd ${B}
cygconf --program-suffix=-2.13
cygmake -j1
- (makeinfo --no-split -I ${S} -o autoconf2.13.info autoconf.texi)
+ (makeinfo --no-split -o autoconf2.13.info ${S}/autoconf.texi)
}
DIFF_EXCLUDES="autoconf.info standards.info stamp-vti version.texi"
2) Run 'export AUTOCONF_VERSION=2.13'
3) Run 'cygport autoconf2.1.cygport all'
--
Takashi Yano
--
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 update, gvim 8.2. file type plugin, perl script error
On 2022-07-19, Kutty, Rejeesh wrote: > Hi, > > I recently ran the installer and it updated vim to 8.2 > > :version > VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 13 2022 22:00:24) > Included patches: 1-4372 > > > Now when I open a perl script, I get the following message: > > Command terminated > Error detected while processing BufRead Autocommands for "*.pl"..function > dist#ft#FTpl[10]..FileType > Autocommands for "*"..function 11_LoadFTPlugin[18]..script > /usr/share/vim/vim82/ftplugin/perl. > vim[57]..BufRead Autocommands for "*.pl"..function dist#ft#FTpl[10]..FileType > Autocommands for "*".. > function 11_LoadFTPlugin[18]..script > /usr/share/vim/vim82/ftplugin/perl.vim: > line 50: > E484: Can't open file /tmp/vveXImd/0 > Press ENTER or type command to continue > > > And all syntax is lost. > > This only happens with perl-scripts. > > I opened Verilog/SystemVerilog/Shell/CPP/C/TCL files, and all these opened > without problems. > > Not sure if I should ask this in the vim/github help, thought I will start > here. I tried the following: $ /usr/bin/vim -N -u NONE -i NONE -c 'syntax on' -c 'e /usr/share/perl5/5.32/perl5db.pl' where the perl file is one I thought you might have on your system and vim is the current Cygwin package version, 8.2.4372. I don't get any error messages. If that works for you, then there seems to be something in your Vim configuration, e.g., your vimrc, that's causing the problem, but I haven't given a whole lot of thought to what that might be. As for where to ask about the problem, this is probably the right place to start and where the best group of folks is to figure out whether it's a Cygwin problem, a Vim problem, or a configuration problem. Regards, Gary -- 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 update, gvim 8.2. file type plugin, perl script error
Hi, I recently ran the installer and it updated vim to 8.2 :version VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 13 2022 22:00:24) Included patches: 1-4372 Now when I open a perl script, I get the following message: Command terminated Error detected while processing BufRead Autocommands for "*.pl"..function dist#ft#FTpl[10]..FileType Autocommands for "*"..function 11_LoadFTPlugin[18]..script /usr/share/vim/vim82/ftplugin/perl. vim[57]..BufRead Autocommands for "*.pl"..function dist#ft#FTpl[10]..FileType Autocommands for "*".. function 11_LoadFTPlugin[18]..script /usr/share/vim/vim82/ftplugin/perl.vim: line 50: E484: Can't open file /tmp/vveXImd/0 Press ENTER or type command to continue And all syntax is lost. This only happens with perl-scripts. I opened Verilog/SystemVerilog/Shell/CPP/C/TCL files, and all these opened without problems. Not sure if I should ask this in the vim/github help, thought I will start here. Thanks, Rejeesh -- 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
Error when building autoconf2.1, broken package?
Hello, I did these actions: 1) Downloaded autoconf2.1-2.13-12-src.tar.bz2 2) Unpack that file. 3) I run this command: cygport autoconf2.1.cygport all and this is the output on screen: >>> Preparing autoconf2.1-2.13-12.x86_64 >>> Unpacking source autoconf-2.13.tar.gz *** Info: applying patch autoconf2.1-texinfo.patch (-p2): patching file autoconf.texi >>> Preparing working source directory *** Info: applying patch autoconf2.1-2.13-12.cygwin.patch (-p2): patching file CYGWIN-PATCHES/autoconf2.1.README >>> Compiling autoconf2.1-2.13-12.x86_64 *** ERROR: could not detect autoconf version; perhaps set AUTOCONF_VERSION? Have you an idea of the cause of the problem? I tried to download and rebuild also autoconf2.5 and autoconf2.7 and they worked fine, only 2.1 fails. Thank you very much for your time. Sincerely, Carlo Bramini. -- 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: weird error gpg
Greetings, Jim McNamara! > I took the bottom of the sha256sum > file where it was ascii armor and pasted it into notepad and saved it. Thus destroyed the very possiblity of checking your setup. Do not touch the signature file. Save it literal. > I don't know why it isn't verifying. You did that. > I named that file fedora.asc. Here is what the original file looks like. Original. The key word. > This is what i copied and pasted into notepad and called fedora.asc (see > below): > -BEGIN PGP SIGNATURE- It is a signature of the file itself. It is useless without the entire file. Wondering who told you to do that. -- With best regards, Andrey Repin Friday, June 24, 2022 22:25:03 Sorry for my terrible english... -- 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: weird error gpg
Hi, Two things come to mind: 1. Is the file fedora.asc being through an editor? Does it have \r\n terminators by accident? i.e. is DOS formated, not the original format. 2. You should be using the original file, I don't see the point of what you pasted into Notepad, and Notepad by default will mangle the file anyway (i.e. with the wrong line terminators). BTW gpg expects the original file, w/o the sha256 sums it can't do its checking (of the .iso file). Regards. On 6/24/2022 11:41 AM, Jim McNamara via Cygwin wrote: > Hi Rene- > > Everything you mentioned checked out. I took the bottom of the sha256sum file where it was ascii armor and pasted it into notepad and saved it. > > I don't know why it isn't verifying. I named that file fedora.asc. Here is what the original file looks like. > > Please see below for the part that I copied and pasted into notepad. > # Fedora-Cinnamon-Live-x86_64-36-1.5.iso: 2220474368 bytes SHA256 (Fedora-Cinnamon-Live-x86_64-36-1.5.iso) = 03db083afb8e25dcf3f433c1c07064650010dfc99ebc930b58ee34d328758cf6 # Fedora-KDE-Live-x86_64-36-1.5.iso: 2214592512 bytes SHA256 (Fedora-KDE-Live-x86_64-36-1.5.iso) = b1da6062ee2e90695557f93a3e13a594884d8ab08ac48a93118eca68bc9108a8 # Fedora-LXDE-Live-x86_64-36-1.5.iso: 1478590464 bytes SHA256 (Fedora-LXDE-Live-x86_64-36-1.5.iso) = 57aa7b4df1138e755fdfebf8c60e49609f86f6f096baa578afabc1e91ef8576a # Fedora-LXQt-Live-x86_64-36-1.5.iso: 1502576640 bytes SHA256 (Fedora-LXQt-Live-x86_64-36-1.5.iso) = 8fc59e536571dd146f1f73272097e3355860fa54fff9ff0461c8243a58cadefb # Fedora-MATE_Compiz-Live-x86_64-36-1.5.iso: 2195668992 bytes SHA256 (Fedora-MATE_Compiz-Live-x86_64-36-1.5.iso) = ccf352edf7286e15968048abcc7b3f760067e74da27e904efab8302c40f8ada4 # Fedora-SoaS-Live-x86_64-36-1.5.iso: 1229389824 bytes SHA256 (Fedora-SoaS-Live-x86_64-36-1.5.iso) = 09bbbdd5c92aff25db54ff0db683844d1cd9ed5dc0918b22a0f1ddb561b921d2 # Fedora-Xfce-Live-x86_64-36-1.5.iso: 1694498816 bytes SHA256 (Fedora-Xfce-Live-x86_64-36-1.5.iso) = 8c175c901393788a4a46ffeeb29b7f1eebde66d8c3226bd83675c2e7212a891d # Fedora-i3-Live-x86_64-36-1.5.iso: 1482964992 bytes SHA256 (Fedora-i3-Live-x86_64-36-1.5.iso) = c66c9521a1d73ac5505e1b523974c9604a4cf3d9823ee1e83fdf82d99174886c > > This is what i copied and pasted into notepad and called fedora.asc (see below): > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEEU97Sy5Iti42eY/0YmZ98vzircfQFAmJ1Lu8ACgkQmZ98vzir > cfRuDA/+IoCBqNW8kGoVXyrf6OfUjoaDrPF48EdIHLh0rBLaPCFu0dCNr5hjJijy > bINk5ogc4dRteC+qHNa6HWpRh4hDv+YfMxtrNlMXc0udW79uZWNrUR4zsWiX1aOS > mgyCSTIwcxUi59Brzh12iFjb6Gg4AeiUBOY8C5joLkrreT6Z6lQ2FcQySdj5SSmk > dyEyZZI5eJQQ3yBtfVeNY+JnvobvGpENS3V4IlDDfLgjmlbgNaUdCZIy0QNkAH/P > VhMPNrnQXMvcrH9uhLXxpseqpN+ZfhK64F47iHpXQGpfZyPdII3qjE/hW1vCL4UK > AV8TqFRYPK5wXu/HSqz0Mg9TCtf95oPVqgug0Czme7x8ObQ8i2x+uU9QoOjEr8oP > 5U0DhrsUKzn7ogw6TfmBTDv3e+w0FBMqrHysWy9yU/SvsVKZRfz5l1fxYDI/Ifvn > K+oSCMG1wIhwVDBPO0rz/PdmeVnHNrLndrboJxYTApfJAZdVjoMwRivGtFtBjOPu > okSnkheDIwMnW3CvEwdxTrfZD2AL/nfm5I3qnJ6WSAwcF96TFWJj1/KDYrA1mE+b > hVbBkL7m+WCTN/DqegYefxDHEE09qvOLSDCSYOuZJpwVKxXame8C5/Zoe9AAJVDj > t8lbWKKPMauFFN/SXQ18JT0mECWWx84qmBvbezma2ecH2frMAuc= > =KcCN > -END PGP SIGNATURE- > > thanks for helping, > jim > > > > > > On Friday, June 24, 2022, 12:23:19 PM EDT, René Berber wrote: > > > > > > On 6/24/2022 10:55 AM, Jim McNamara via Cygwin wrote: > >> $ gpg --verify fedora.asc Fedora-KDE-Live-x86_64-36-1.5.iso >> gpg: can't handle text lines longer than 19995 characters >> gpg: Signature made Fri May 6 10:21:35 2022 EDT using RSA key ID 38AB71F4 >> gpg: BAD signature from "Fedora (36) " >> >> I am having a difficult time. I think they are breaking into my computer. >> They made it so I can't verify files. >> >> Is there any way I can fix it so that this error goes away? > > Start by checking gpg itself. > > > $ which gpg > /usr/bin/gpg > > $ gpg --version > gpg (GnuPG) 1.4.23 > Copyright (C) 2015 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Home: ~/.gnupg > Supported algorithms: > Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, > CAMELLIA128, CAMELLIA192, CAMELLIA256 > Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > Compression: Uncompressed, ZIP, ZLIB, BZIP2 > > $ sha256sum /usr/bin/gpg > a72cb1fd7a1dcf94c7c8de2a2e749bce22f16af59c2b2157b01f73518e0bece7 > */usr/bin/gpg > > > Or... > > $ which gpg2 > /usr/bin/gpg2 > > $ gpg2 --version > gpg: WARNING: unsafe perm
Re: weird error gpg
Hi Rene- Everything you mentioned checked out. I took the bottom of the sha256sum file where it was ascii armor and pasted it into notepad and saved it. I don't know why it isn't verifying. I named that file fedora.asc. Here is what the original file looks like. Please see below for the part that I copied and pasted into notepad. -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 # Fedora-Cinnamon-Live-x86_64-36-1.5.iso: 2220474368 bytes SHA256 (Fedora-Cinnamon-Live-x86_64-36-1.5.iso) = 03db083afb8e25dcf3f433c1c07064650010dfc99ebc930b58ee34d328758cf6 # Fedora-KDE-Live-x86_64-36-1.5.iso: 2214592512 bytes SHA256 (Fedora-KDE-Live-x86_64-36-1.5.iso) = b1da6062ee2e90695557f93a3e13a594884d8ab08ac48a93118eca68bc9108a8 # Fedora-LXDE-Live-x86_64-36-1.5.iso: 1478590464 bytes SHA256 (Fedora-LXDE-Live-x86_64-36-1.5.iso) = 57aa7b4df1138e755fdfebf8c60e49609f86f6f096baa578afabc1e91ef8576a # Fedora-LXQt-Live-x86_64-36-1.5.iso: 1502576640 bytes SHA256 (Fedora-LXQt-Live-x86_64-36-1.5.iso) = 8fc59e536571dd146f1f73272097e3355860fa54fff9ff0461c8243a58cadefb # Fedora-MATE_Compiz-Live-x86_64-36-1.5.iso: 2195668992 bytes SHA256 (Fedora-MATE_Compiz-Live-x86_64-36-1.5.iso) = ccf352edf7286e15968048abcc7b3f760067e74da27e904efab8302c40f8ada4 # Fedora-SoaS-Live-x86_64-36-1.5.iso: 1229389824 bytes SHA256 (Fedora-SoaS-Live-x86_64-36-1.5.iso) = 09bbbdd5c92aff25db54ff0db683844d1cd9ed5dc0918b22a0f1ddb561b921d2 # Fedora-Xfce-Live-x86_64-36-1.5.iso: 1694498816 bytes SHA256 (Fedora-Xfce-Live-x86_64-36-1.5.iso) = 8c175c901393788a4a46ffeeb29b7f1eebde66d8c3226bd83675c2e7212a891d # Fedora-i3-Live-x86_64-36-1.5.iso: 1482964992 bytes SHA256 (Fedora-i3-Live-x86_64-36-1.5.iso) = c66c9521a1d73ac5505e1b523974c9604a4cf3d9823ee1e83fdf82d99174886c -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEU97Sy5Iti42eY/0YmZ98vzircfQFAmJ1Lu8ACgkQmZ98vzir cfRuDA/+IoCBqNW8kGoVXyrf6OfUjoaDrPF48EdIHLh0rBLaPCFu0dCNr5hjJijy bINk5ogc4dRteC+qHNa6HWpRh4hDv+YfMxtrNlMXc0udW79uZWNrUR4zsWiX1aOS mgyCSTIwcxUi59Brzh12iFjb6Gg4AeiUBOY8C5joLkrreT6Z6lQ2FcQySdj5SSmk dyEyZZI5eJQQ3yBtfVeNY+JnvobvGpENS3V4IlDDfLgjmlbgNaUdCZIy0QNkAH/P VhMPNrnQXMvcrH9uhLXxpseqpN+ZfhK64F47iHpXQGpfZyPdII3qjE/hW1vCL4UK AV8TqFRYPK5wXu/HSqz0Mg9TCtf95oPVqgug0Czme7x8ObQ8i2x+uU9QoOjEr8oP 5U0DhrsUKzn7ogw6TfmBTDv3e+w0FBMqrHysWy9yU/SvsVKZRfz5l1fxYDI/Ifvn K+oSCMG1wIhwVDBPO0rz/PdmeVnHNrLndrboJxYTApfJAZdVjoMwRivGtFtBjOPu okSnkheDIwMnW3CvEwdxTrfZD2AL/nfm5I3qnJ6WSAwcF96TFWJj1/KDYrA1mE+b hVbBkL7m+WCTN/DqegYefxDHEE09qvOLSDCSYOuZJpwVKxXame8C5/Zoe9AAJVDj t8lbWKKPMauFFN/SXQ18JT0mECWWx84qmBvbezma2ecH2frMAuc= =KcCN -END PGP SIGNATURE- This is what i copied and pasted into notepad and called fedora.asc (see below): -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEU97Sy5Iti42eY/0YmZ98vzircfQFAmJ1Lu8ACgkQmZ98vzir cfRuDA/+IoCBqNW8kGoVXyrf6OfUjoaDrPF48EdIHLh0rBLaPCFu0dCNr5hjJijy bINk5ogc4dRteC+qHNa6HWpRh4hDv+YfMxtrNlMXc0udW79uZWNrUR4zsWiX1aOS mgyCSTIwcxUi59Brzh12iFjb6Gg4AeiUBOY8C5joLkrreT6Z6lQ2FcQySdj5SSmk dyEyZZI5eJQQ3yBtfVeNY+JnvobvGpENS3V4IlDDfLgjmlbgNaUdCZIy0QNkAH/P VhMPNrnQXMvcrH9uhLXxpseqpN+ZfhK64F47iHpXQGpfZyPdII3qjE/hW1vCL4UK AV8TqFRYPK5wXu/HSqz0Mg9TCtf95oPVqgug0Czme7x8ObQ8i2x+uU9QoOjEr8oP 5U0DhrsUKzn7ogw6TfmBTDv3e+w0FBMqrHysWy9yU/SvsVKZRfz5l1fxYDI/Ifvn K+oSCMG1wIhwVDBPO0rz/PdmeVnHNrLndrboJxYTApfJAZdVjoMwRivGtFtBjOPu okSnkheDIwMnW3CvEwdxTrfZD2AL/nfm5I3qnJ6WSAwcF96TFWJj1/KDYrA1mE+b hVbBkL7m+WCTN/DqegYefxDHEE09qvOLSDCSYOuZJpwVKxXame8C5/Zoe9AAJVDj t8lbWKKPMauFFN/SXQ18JT0mECWWx84qmBvbezma2ecH2frMAuc= =KcCN -END PGP SIGNATURE- thanks for helping, jim On Friday, June 24, 2022, 12:23:19 PM EDT, René Berber wrote: On 6/24/2022 10:55 AM, Jim McNamara via Cygwin wrote: > $ gpg --verify fedora.asc Fedora-KDE-Live-x86_64-36-1.5.iso > gpg: can't handle text lines longer than 19995 characters > gpg: Signature made Fri May 6 10:21:35 2022 EDT using RSA key ID 38AB71F4 > gpg: BAD signature from "Fedora (36) " > > I am having a difficult time. I think they are breaking into my computer. > They made it so I can't verify files. > > Is there any way I can fix it so that this error goes away? Start by checking gpg itself. $ which gpg /usr/bin/gpg $ gpg --version gpg (GnuPG) 1.4.23 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 $ sha256sum /usr/bin/gpg a72cb1fd7a1dcf94c7c8de2a2e749bce22f16af59c2b2157b01f73518e0bece7 */usr/bin/gpg Or... $ which gpg2 /usr/bin/gpg2 $ gpg2 --version gpg: WARNING: unsafe permissions on homedir '/home/reneb/.gnupg' gpg (GnuPG) 2.2.35-un
Re: weird error gpg
On 6/24/2022 10:55 AM, Jim McNamara via Cygwin wrote: $ gpg --verify fedora.asc Fedora-KDE-Live-x86_64-36-1.5.iso gpg: can't handle text lines longer than 19995 characters gpg: Signature made Fri May 6 10:21:35 2022 EDT using RSA key ID 38AB71F4 gpg: BAD signature from "Fedora (36) " I am having a difficult time. I think they are breaking into my computer. They made it so I can't verify files. Is there any way I can fix it so that this error goes away? Start by checking gpg itself. $ which gpg /usr/bin/gpg $ gpg --version gpg (GnuPG) 1.4.23 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 $ sha256sum /usr/bin/gpg a72cb1fd7a1dcf94c7c8de2a2e749bce22f16af59c2b2157b01f73518e0bece7 */usr/bin/gpg Or... $ which gpg2 /usr/bin/gpg2 $ gpg2 --version gpg: WARNING: unsafe permissions on homedir '/home/reneb/.gnupg' gpg (GnuPG) 2.2.35-unknown libgcrypt 1.10.1-unknown Copyright (C) 2022 g10 Code GmbH License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/reneb/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 $ sha256sum /usr/bin/gpg2 87f54df3c700c2bae6211cdb71540b8cc26b43bed60c8b2821e156e070c625f9 */usr/bin/gpg2 -- R.Berber -- 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
weird error gpg
Hi guys- $ cd /cygdrive/c/Users/DeathDealer/Downloads $ gpg --verify fedora.asc Fedora-KDE-Live-x86_64-36-1.5.iso gpg: can't handle text lines longer than 19995 characters gpg: Signature made Fri May 6 10:21:35 2022 EDT using RSA key ID 38AB71F4 gpg: BAD signature from "Fedora (36) " I am having a difficult time. I think they are breaking into my computer. They made it so I can't verify files. Is there any way I can fix it so that this error goes away? thanks, jim -- 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
Netcdf error using Generic Mapping Tools
I have compiled Generic Mapping Tools (GMT; www.generic-mapping-tools.org) version 6.3.0 on Cygwin without any errors using the same workflow as for previous versions. Previous versions have worked fine. I now get the following errors from GMT when trying to access the accompanying gshhg database of coastal outlines (Netcdf files). I have used the netcdf libraries etc. from the Cygwin depository when compiling GMT. gshhg_version: cannot open file "/GMT6/gshhg-gmt-2.3.6/binned_border_f.nc" (-101). gmtget [ERROR]: 1. GSHHG: Found /GMT6/gshhg-gmt-2.3.6/binned_border_f.nc but cannot read it due to wrong permissions gshhg_version: cannot open file "/GMT6/gmt-6.3.0/share/coast/binned_border_f.nc" (-101). Permissions are all ok with read and write access. I believe the -101 in brackets is a Netcdf error code indicating a HDF5 error (#define NC_EHDFERR (-101) // Error at HDF5 layer). Any hints would be appreciated. Best regards Carl Fredrik The confidentiality or integrity of this message can not be guaranteed following transmission on the Internet. The addressee should be aware of this before using the contents of this message. -- 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: Re: meson build error on gedit-3.32.2
> - Original Message - > > From: "Jon Turney" > To: "Tatsuro MATSUOKA"; "The Cygwin Mailing List" < > Date: 2022/06/13 月 01:29 > Subject: Re: meson build error on gedit-3.32.2 > > > On 08/06/2022 06:48, Tatsuro MATSUOKA wrote: > > I am trying to build gedit-3.32.2 by meson. > > May I ask, why did you choose that particular version? > > > $ meson _build > > : > > > > : > > Program python3 found: YES (/usr/bin/python3) > > WARNING: Python files installed by Meson might not be found by python > > interpreter. > > This warning can be avoided by setting "python.platlibdir" option. > > WARNING: Python files installed by Meson might not be found by python > > interpreter. > > This warning can be avoided by setting "python.purelibdir" option. > > Configuring config.h using configuration > > I can't reproduce this. > > I think perhaps maybe you are encountering a meson bug (already fixed in > upstream) that this warning is emitted when you make an unusual choice > of prefix? I upgrade the meson by pip install --upgrade (to meson-0.62.2) The WARNINGs are disappeared. > > data/meson.build:19:0: ERROR: Function does not take positional arguments. > > To fix this error, you'll need to backport the patch from > > https://gitlab.gnome.org/GNOME/gedit/-/merge_requests/124/diffs > Backporting the patch, the error is disappeared. Thanks. Tatsuro -- 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: meson build error on gedit-3.32.2
On 08/06/2022 06:48, Tatsuro MATSUOKA wrote: I am trying to build gedit-3.32.2 by meson. May I ask, why did you choose that particular version? $ meson _build : : Program python3 found: YES (/usr/bin/python3) WARNING: Python files installed by Meson might not be found by python interpreter. This warning can be avoided by setting "python.platlibdir" option. WARNING: Python files installed by Meson might not be found by python interpreter. This warning can be avoided by setting "python.purelibdir" option. Configuring config.h using configuration I can't reproduce this. I think perhaps maybe you are encountering a meson bug (already fixed in upstream) that this warning is emitted when you make an unusual choice of prefix? data/meson.build:19:0: ERROR: Function does not take positional arguments. To fix this error, you'll need to backport the patch from https://gitlab.gnome.org/GNOME/gedit/-/merge_requests/124/diffs Please give me suggestions for setting "python.platlibdir" and "python.purelibdir" options. -- 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
meson build error on gedit-3.32.2
I am trying to build gedit-3.32.2 by meson. $ meson _build : : Program python3 found: YES (/usr/bin/python3) WARNING: Python files installed by Meson might not be found by python interpreter. This warning can be avoided by setting "python.platlibdir" option. WARNING: Python files installed by Meson might not be found by python interpreter. This warning can be avoided by setting "python.purelibdir" option. Configuring config.h using configuration data/meson.build:19:0: ERROR: Function does not take positional arguments. Please give me suggestions for setting "python.platlibdir" and "python.purelibdir" options. Tatsuro -- 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: error: CYGWIN_NT-10.0-x86_64 is not supported (yet?) on Windows 10
Thank you! This looks like it may help. 8< From: Cygwin on behalf of Brian Inglis Sent: Sunday, April 24, 2022 1:08 PM To: cygwin@cygwin.com Subject: Re: error: CYGWIN_NT-10.0-x86_64 is not supported (yet?) on Windows 10 On 2022-04-24 08:02, John Balkunas wrote: > Hello, > > I installed Cywin64 Terminal so that I can compile chrony-4.2 for use with > Windows 10 Pro 64-bit. I used the Cygwin Setup program/installer named > setup-x86_64.exe for 64 bit Windows. The install appeared to go well. After > the install, from within the Cywin64 Terminal, I see the following 3 results: > > Command: "cygcheck -V" > Result: > cygcheck (cygwin) 3.3.4 > System Checker for Cygwin > Copyright (C) 1998 - 2022 Cygwin Authors > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > Command: "gcc --version" > Result: > gcc (GCC) 11.2.0 > Copyright (C) 2021 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > Command: "g++ --version" > Result: > g++ (GCC) 11.2.0 > Copyright (C) 2021 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > Thus, this leads me to think everything is ready to go on my Win10 machine > for compiling. However, when I switch to the directory I unpacked the > chrony-4.2 to and run the "./configure" command (I used no switches) from > within the Cygwin64 Terminal I see the following: > > Command: "./configure" > Result: > error: CYGWIN_NT-10.0-x86_64 is not supported (yet?) > > I have tried searching for this error (was really hard trying to go through > the Cygwin web archives) and haven't seen it discussed. I am pretty computer > literate, but at this juncture I'm not sure how to proceed. I've compiled a > few programs before (from within Linux), have done some programming in the > past, but am in no way "comfortable" or that knowledgeable about it and am > officially stuck. > > ANY responses would likely be appreciated. Thank you in advance for any > help/suggestions/clues! BTDT, IIRC too many Linux dependencies. Still running NTP from Meinberg: https://www.meinbergglobal.com/english/sw/ntp.htm#ntp_stable https://www.meinbergglobal.com/download/ntp/windows/ntp-4.2.8p15-v2-win32-setup.exe https://www.meinbergglobal.com/english/sw/ntp-server-monitor.htm https://www.meinbergglobal.com/download/ntp/windows/time-server-monitor/ntp-time-server-monitor-104.exe You can download the sources and build the daemon and utilities with older VS releases, but Meinberg provides a service installer and monitor utility. With serial driver and PPS DLL, service and other setup tweaking, you can run a serial GPS with PPS at Realtime priority and get microsecond stability. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- 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: error: CYGWIN_NT-10.0-x86_64 is not supported (yet?) on Windows 10
On 2022-04-24 08:02, John Balkunas wrote: Hello, I installed Cywin64 Terminal so that I can compile chrony-4.2 for use with Windows 10 Pro 64-bit. I used the Cygwin Setup program/installer named setup-x86_64.exe for 64 bit Windows. The install appeared to go well. After the install, from within the Cywin64 Terminal, I see the following 3 results: Command: "cygcheck -V" Result: cygcheck (cygwin) 3.3.4 System Checker for Cygwin Copyright (C) 1998 - 2022 Cygwin Authors This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Command: "gcc --version" Result: gcc (GCC) 11.2.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Command: "g++ --version" Result: g++ (GCC) 11.2.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Thus, this leads me to think everything is ready to go on my Win10 machine for compiling. However, when I switch to the directory I unpacked the chrony-4.2 to and run the "./configure" command (I used no switches) from within the Cygwin64 Terminal I see the following: Command: "./configure" Result: error: CYGWIN_NT-10.0-x86_64 is not supported (yet?) I have tried searching for this error (was really hard trying to go through the Cygwin web archives) and haven't seen it discussed. I am pretty computer literate, but at this juncture I'm not sure how to proceed. I've compiled a few programs before (from within Linux), have done some programming in the past, but am in no way "comfortable" or that knowledgeable about it and am officially stuck. ANY responses would likely be appreciated. Thank you in advance for any help/suggestions/clues! BTDT, IIRC too many Linux dependencies. Still running NTP from Meinberg: https://www.meinbergglobal.com/english/sw/ntp.htm#ntp_stable https://www.meinbergglobal.com/download/ntp/windows/ntp-4.2.8p15-v2-win32-setup.exe https://www.meinbergglobal.com/english/sw/ntp-server-monitor.htm https://www.meinbergglobal.com/download/ntp/windows/time-server-monitor/ntp-time-server-monitor-104.exe You can download the sources and build the daemon and utilities with older VS releases, but Meinberg provides a service installer and monitor utility. With serial driver and PPS DLL, service and other setup tweaking, you can run a serial GPS with PPS at Realtime priority and get microsecond stability. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: error: CYGWIN_NT-10.0-x86_64 is not supported (yet?) on Windows 10
On 4/24/2022 10:37 AM, René Berber wrote: On 4/24/2022 10:3 AM, John Balkunas wrote: Thank you! It makes sense. Upon further reading it looks like chrony's docs say it does not run on/support Windows. That is not the same as not supporting Cygwin. [snip] Taken from chrony's FAQ: "7.1. Does chrony support Windows? No. The chronyc program (the command-line client used for configuring chronyd while it is running) has been successfully built and run under Cygwin in the past. chronyd is not portable, because part of it is very system-dependent. It needs adapting to work with Windows' equivalent of the adjtimex() call, and it needs to be made to work as a service." Running as a service is not a problem in Cygwin, there's a helper program for that. I'm not sure about the support for adjtimex()... Its not in any header so I guess its not supported. There is an adjtime() in sys/time.h, but that is not the same. -- 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: error: CYGWIN_NT-10.0-x86_64 is not supported (yet?) on Windows 10
On 4/24/2022 10:3 AM, John Balkunas wrote: Thank you! It makes sense. Upon further reading it looks like chrony's docs say it does not run on/support Windows. That is not the same as not supporting Cygwin. Looks like I should be trying to get NTP running instead of Chrony for time clock syncing/updating on this Win10 machine. Bet that will be fun. I wouldn't give up, chrony probably works out of the box, it just needs to accept that the environment is Linux-like. Thanks again. You are welcome. -- René Berber -- 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: error: CYGWIN_NT-10.0-x86_64 is not supported (yet?) on Windows 10
On 4/24/2022 9:02 AM, John Balkunas wrote: I installed Cywin64 Terminal so that I can compile chrony-4.2 for use with Windows 10 Pro 64-bit. I used the Cygwin Setup program/installer named setup-x86_64.exe for 64 bit Windows. The install appeared to go well. After the install, from within the Cywin64 Terminal, I see the following 3 results: [snip] Command: "./configure" Result: error: CYGWIN_NT-10.0-x86_64 is not supported (yet?) That message is from chrony, there's no apparent problem with Cygwin. The message is just telling you that the OS CYGWIN* is not one known to work, or the project being already ported if that is needed. Perhaps its time to look into configure's options, there may be one to (force) build for Linux and, depending on how portable that project is, it usually works. Another detail which is often overlooked, you need to install the pre-requisites (listed by the specific project) and its development libraries (as in -devel in setup). Hope this helps. -- R.Berber -- 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
error: CYGWIN_NT-10.0-x86_64 is not supported (yet?) on Windows 10
Hello, I installed Cywin64 Terminal so that I can compile chrony-4.2 for use with Windows 10 Pro 64-bit. I used the Cygwin Setup program/installer named setup-x86_64.exe for 64 bit Windows. The install appeared to go well. After the install, from within the Cywin64 Terminal, I see the following 3 results: Command: "cygcheck -V" Result: cygcheck (cygwin) 3.3.4 System Checker for Cygwin Copyright (C) 1998 - 2022 Cygwin Authors This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Command: "gcc --version" Result: gcc (GCC) 11.2.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Command: "g++ --version" Result: g++ (GCC) 11.2.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Thus, this leads me to think everything is ready to go on my Win10 machine for compiling. However, when I switch to the directory I unpacked the chrony-4.2 to and run the "./configure" command (I used no switches) from within the Cygwin64 Terminal I see the following: Command: "./configure" Result: error: CYGWIN_NT-10.0-x86_64 is not supported (yet?) I have tried searching for this error (was really hard trying to go through the Cygwin web archives) and haven't seen it discussed. I am pretty computer literate, but at this juncture I'm not sure how to proceed. I've compiled a few programs before (from within Linux), have done some programming in the past, but am in no way "comfortable" or that knowledgeable about it and am officially stuck. ANY responses would likely be appreciated. Thank you in advance for any help/suggestions/clues! -- 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: Possible xpdf packaging error?
On 4/7/2022 3:03 PM, Eliot Moss wrote: But it's odd to have a man page for something in one package and the executable in another, no? Yes. The man page shouldn't be in the xpdf package. I'll fix that the next time I update xpdf. 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: Possible xpdf packaging error?
On 4/7/2022 11:13 AM, airplanemath via Cygwin wrote: > On Thu, Apr 07 2022, Eliot Moss wrote: > >> Dear Cygwin-ers -- >> >> Today I had use for pdftotext. It man page is installed, but the program >> itself is missing. On Ubuntu (etc.) it is part of the xpdf package, the >> Cygwin version of which I have installed. pdftotext.cc is in the source >> package, but its executable is not present in the binary package. >> > $ cygcheck -p bin/pdftotext > Found 6 matches for bin/pdftotext > poppler-debuginfo-0.88.0-1 - poppler-debuginfo: Debug info for poppler > poppler-debuginfo-0.88.0-2 - poppler-debuginfo: Debug info for poppler > poppler-debuginfo-21.01.0-1 - poppler-debuginfo: Debug info for poppler > poppler-0.88.0-1 - poppler: PDF manipulation utilities > poppler-0.88.0-2 - poppler: PDF manipulation utilities > poppler-21.01.0-1 - poppler: PDF manipulation utilities > > Try installing poppler > >> So I am wondering if this is intentional (is pdftotext somewhere else?) or an >> oversight. The situation seems the same from at least the 4.01.01 release >> onward to 4.03 (current) release. > > This looks to be intentional, given the mention in the last several > announcements, e.g. > https://cygwin.com/pipermail/cygwin-announce/2021-February/009922.html > >> >> I suppose I can try getting all the necessary dependencies and building from >> source, if need be, but though this worth asking about. >> >> Regards - Eliot Moss > > Other ways to check are cygcheck -p pdftotext.exe or > https://cygwin.com/cgi-bin2/package-grep.cgi?grep=bin%2Fpdftotext=x86_64, Thanks - I had noticed, but not connected, that pdftotext is in poppler-utilsfor Ubuntu. But it's odd to have a man page for something in one package and the executable in another, no? No worries - I'll install poppler. Regards - Eliot -- 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: Possible xpdf packaging error?
On Thu, Apr 07 2022, Eliot Moss wrote: > Dear Cygwin-ers -- > > Today I had use for pdftotext. It man page is installed, but the program > itself is missing. On Ubuntu (etc.) it is part of the xpdf package, the > Cygwin version of which I have installed. pdftotext.cc is in the source > package, but its executable is not present in the binary package. > $ cygcheck -p bin/pdftotext Found 6 matches for bin/pdftotext poppler-debuginfo-0.88.0-1 - poppler-debuginfo: Debug info for poppler poppler-debuginfo-0.88.0-2 - poppler-debuginfo: Debug info for poppler poppler-debuginfo-21.01.0-1 - poppler-debuginfo: Debug info for poppler poppler-0.88.0-1 - poppler: PDF manipulation utilities poppler-0.88.0-2 - poppler: PDF manipulation utilities poppler-21.01.0-1 - poppler: PDF manipulation utilities Try installing poppler > So I am wondering if this is intentional (is pdftotext somewhere else?) or an > oversight. The situation seems the same from at least the 4.01.01 release > onward to 4.03 (current) release. This looks to be intentional, given the mention in the last several announcements, e.g. https://cygwin.com/pipermail/cygwin-announce/2021-February/009922.html > > I suppose I can try getting all the necessary dependencies and building from > source, if need be, but though this worth asking about. > > Regards - Eliot Moss Other ways to check are cygcheck -p pdftotext.exe or https://cygwin.com/cgi-bin2/package-grep.cgi?grep=bin%2Fpdftotext=x86_64, -- 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
Possible xpdf packaging error?
Dear Cygwin-ers -- Today I had use for pdftotext. It man page is installed, but the program itself is missing. On Ubuntu (etc.) it is part of the xpdf package, the Cygwin version of which I have installed. pdftotext.cc is in the source package, but its executable is not present in the binary package. So I am wondering if this is intentional (is pdftotext somewhere else?) or an oversight. The situation seems the same from at least the 4.01.01 release onward to 4.03 (current) release. I suppose I can try getting all the necessary dependencies and building from source, if need be, but though this worth asking about. Regards - Eliot Moss -- 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
WARNING **: Error retrieving accessibility bus address:
When I execute some GUI application like gedit, gvim, and etcs, warning messages appear. WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying If there is method to surpress these, please let me know. Tatsuro -- 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
WARNING **: Error retrieving accessibility bus address:
When I execute some GUI application like gedit, gvim, and etcs, warning messages appear. WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying If there is method to surpress these, please let me know. Tatsuro -- 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 gives me error 12
> Please pause here for a moment. Are you using Cygwin ssh or MS Windows provided > variant? Cygwin rsync is unable to use native Windows apps as tunnel wrappers. > Be it OpenSSH or PuTTY's plink. With exactly the message you see above. This was the problem. I installed OpenSSH from Cygwin, copied my keys to my .ssh directory, and then issued this command: rsync r...@marketing.propfinancing.com:/var/www/svnDumps/* "/cygdrive/c/Tmp" It worked perfectly. Thank you Andrey! Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! -- 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 gives me error 12
> Please pause here for a moment. Are you using Cygwin ssh or MS Windows provided > variant? Cygwin rsync is unable to use native Windows apps as tunnel wrappers. > Be it OpenSSH or PuTTY's plink. With exactly the message you see above. I think we may (finally!) be getting somewhere now. I am using the Cygwin provided one. Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! -- 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 gives me error 12
Greetings, Neil Aggarwal! > Adam: >> this reads to me like the remote >> server is closing the connection > When I run this command on my Windows machine: > rsync --debug=ALL r...@marketing.propfinancing.com:/var/www/svnDumps > /cygdrive/c/Tmp > I get this output on the screen: > opening connection using: ssh -l root marketing.propfinancing.com rsync > --server --sender -e.LsfxCIvu . /var/www/svnDumps (10 args) > rsync: connection unexpectedly closed (0 bytes received so far) [sender] > rsync error: error in rsync protocol data stream (code 12) at io.c(226) > [sender=3.1.3] > rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] > rsync error: error in rsync protocol data stream (code 12) at io.c(228) > [Receiver=3.2.4dev] > [Receiver] _exit_cleanup(code=12, file=io.c, line=228): about to call > exit(12) Please pause here for a moment. Are you using Cygwin ssh or MS Windows provided variant? Cygwin rsync is unable to use native Windows apps as tunnel wrappers. Be it OpenSSH or PuTTY's plink. With exactly the message you see above. > It is connecting to the Linux server and immediately disconnecting, here > is what I see in /var/log/secure: > Mar 25 12:11:00 marketing sshd[43597]: Postponed publickey for root from > 99.137.191.183 port 64715 ssh2 [preauth] > Mar 25 12:11:00 marketing sshd[43597]: Accepted publickey for root from > 99.137.191.183 port 64715 ssh2: RSA SHA256:[removed] > Mar 25 12:11:00 marketing sshd[43597]: pam_unix(sshd:session): session > opened for user root by (uid=0) > Mar 25 12:11:00 marketing sshd[43600]: Received disconnect from > 99.137.191.183 port 64715:11: disconnected by user > Mar 25 12:11:00 marketing sshd[43600]: Disconnected from user root > 99.137.191.183 port 64715 > Mar 25 12:11:00 marketing sshd[43597]: pam_unix(sshd:session): session > closed for user root > I'm stumped at this point. > Thank you, > Neil > -- > Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com > We offer 30 year loans on single family houses! -- With best regards, Andrey Repin Monday, March 28, 2022 16:24:44 Sorry for my terrible english... -- 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 gives me error 12
> Manually ssh to the server and try to run `rsync -h`. I ran this command: ssh -vvv r...@marketing.propfinancing.com rsync -h It seemed to work. It gave me the output from rsync-h > You can also get verbose ssh information from rsync using I ran this command: rsync -e 'ssh -vvv' r...@marketing.propfinancing.com:/var/www/svnDumps/* "/cygdrive/c/Tmp" It seems to have a problem at this point: debug1: Sending command: rsync --server --sender -e.LsfxCIvu . /var/www/svnDumps/* debug2: channel 0: request exec confirm 1 debug3: send packet: type 98 debug2: channel_input_open_confirmation: channel 0: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 2097152 debug3: receive packet: type 99 debug2: channel_input_status_confirm: type 99 id 0 debug2: exec request accepted on channel 0 debug3: read - ERROR from cb :87, io:027479707820 debug2: channel 0: read<=0 rfd 4 len 4294967295 debug2: channel 0: read failed > You can also turn on verbose sshd logging I set the LogLevel to DEBUG3 on the server. When I tried the rsync command on my Windows machine, I get a bunch of logs in /var/log/secure. I think the relevant part is attached. It seems to say the channel is closed, but not why it is closing. Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! Mar 27 09:24:14 marketing sshd[3257]: debug3: mm_audit_run_command entering command rsync --server --sender -e.LsfxCIvu . /var/www/svnDumps/* Mar 27 09:24:14 marketing sshd[3257]: debug3: mm_request_send entering: type 114 Mar 27 09:24:14 marketing sshd[3257]: debug3: mm_request_receive_expect entering: type 115 Mar 27 09:24:14 marketing sshd[3257]: debug3: mm_request_receive entering Mar 27 09:24:14 marketing sshd[3254]: debug3: mm_request_receive entering Mar 27 09:24:14 marketing sshd[3254]: debug3: monitor_read: checking request 114 Mar 27 09:24:14 marketing sshd[3254]: debug3: mm_answer_audit_command entering Mar 27 09:24:14 marketing sshd[3254]: debug2: session_new: allocate (allocated 0 max 10) Mar 27 09:24:14 marketing sshd[3254]: debug3: session_unused: session id 0 unused Mar 27 09:24:14 marketing sshd[3254]: debug1: session_new: session 0 Mar 27 09:24:14 marketing sshd[3254]: debug3: mm_request_send entering: type 115 Mar 27 09:24:14 marketing sshd[3257]: debug2: fd 5 setting TCP_NODELAY Mar 27 09:24:14 marketing sshd[3257]: debug3: ssh_packet_set_tos: set IP_TOS 0x20 Mar 27 09:24:14 marketing sshd[3257]: debug2: fd 17 setting O_NONBLOCK Mar 27 09:24:14 marketing sshd[3257]: debug2: fd 16 setting O_NONBLOCK Mar 27 09:24:14 marketing sshd[3257]: debug2: fd 19 setting O_NONBLOCK Mar 27 09:24:14 marketing sshd[3257]: debug3: mm_forward_audit_messages: entering Mar 27 09:24:14 marketing sshd[3258]: debug3: mm_request_send entering: type 124 Mar 27 09:24:14 marketing sshd[3258]: debug3: Copy environment: SELINUX_ROLE_REQUESTED= Mar 27 09:24:14 marketing sshd[3258]: debug3: Copy environment: SELINUX_LEVEL_REQUESTED= Mar 27 09:24:14 marketing sshd[3258]: debug3: Copy environment: SELINUX_USE_CURRENT_RANGE= Mar 27 09:24:14 marketing sshd[3258]: debug3: Copy environment: XDG_SESSION_ID=24 Mar 27 09:24:14 marketing sshd[3258]: debug3: Copy environment: XDG_RUNTIME_DIR=/run/user/0 Mar 27 09:24:14 marketing sshd[3258]: debug3: Copy environment: DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/0/bus Mar 27 09:24:14 marketing sshd[3257]: debug3: send packet: type 99 Mar 27 09:24:14 marketing sshd[3254]: debug3: mm_request_receive entering Mar 27 09:24:14 marketing sshd[3254]: debug3: monitor_read: checking request 124 Mar 27 09:24:14 marketing sshd[3257]: debug3: receive packet: type 96 Mar 27 09:24:14 marketing sshd[3257]: debug2: channel 0: rcvd eof Mar 27 09:24:14 marketing sshd[3257]: debug2: channel 0: output open -> drain Mar 27 09:24:14 marketing sshd[3257]: debug2: channel 0: obuf empty Mar 27 09:24:14 marketing sshd[3257]: debug2: channel 0: chan_shutdown_write (i0 o1 sock -1 wfd 16 efd 19 [read]) Mar 27 09:24:14 marketing sshd[3257]: debug2: channel 0: output drain -> closed Mar 27 09:24:14 marketing sshd[3257]: debug2: channel 0: read 160 from efd 19 Mar 27 09:24:14 marketing sshd[3257]: debug2: channel 0: rwin 2097148 elen 160 euse 1 Mar 27 09:24:14 marketing sshd[3257]: debug2: channel 0: sent ext data 160 Mar 27 09:24:14 marketing sshd[3257]: debug1: Received SIGCHLD. Mar 27 09:24:14 marketing sshd[3257]: debug1: session_by_pid: pid 3258 Mar 27 09:24:14 marketing sshd[3257]: debug1: session_exit_message: session 0 channel 0 pid 3258 Mar 27 09:24:14 marketing sshd[3257]: debug2: channel 0: request exit-status confirm 0 Mar 27 09:24:14 marketing sshd[3257]: debug3: send packet: type 98 Mar 27 09:24:14 marketing sshd[3257]: debug1: session_exit_message: release channel 0 Mar 27 09:24:14 marketing sshd[3257]: debug2: channel 0: read<=0 rfd 17 len 0 Mar 27 09:24:14 marketing sshd[3257]:
Re: rsync gives me error 12
On Sat, Mar 26, 2022 at 11:49:18PM -0500, Neil Aggarwal wrote: > The big stumper for me is that scp works. What could cause rsync to act > differently? Likely answer: your server configuration, such as ssh config, shell configuration, PATH, etc. which are a bit off-topic for the cygwin list. Manually ssh to the server and try to run `rsync -h`. $ ssh -vvv user@server rsync -h You can also get verbose ssh information from rsync using $ rsync -e 'ssh -vvv' ... You can also turn on verbose sshd logging $ man sshd_config See LogLevel and LogVerbose -- 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 gives me error 12
Wayne: > Perhaps the networking drivers are buggy This is an AlmaLinux 8 server, which is a binary clone of RHEL. It is possible but hard to believe the networking drivers would be a problem. > Perhaps you have firewall or selinux rules that are closing the > connection. I configured the firewall using nftables. It only allows incoming tcp connections to port 22 and drops everything else. For outbound, it is set to drop all connections with specific ports allowed. I have selinux set to: SELINUX=permissive SELINUXTYPE=targeted > Your /var/log files might have a clue. I looked at /var/log/messages, it has this: Mar 26 23:38:44 marketing systemd[1]: Started Session 3 of user root. Mar 26 23:38:44 marketing systemd-logind[849]: New session 3 of user root. Mar 26 23:38:44 marketing systemd[1]: session-3.scope: Succeeded. Mar 26 23:38:44 marketing systemd-logind[849]: Session 3 logged out. Waiting for processes to exit. Mar 26 23:38:44 marketing systemd-logind[849]: Removed session 3. I did not see anything else which seemed related. The big stumper for me is that scp works. What could cause rsync to act differently? They are both connecting through port 22. Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! -- 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 gives me error 12
On Fri, Mar 25, 2022 at 10:01 PM wrote: > On the server, I got a /tmp/rsync-3191.out file which I am attaching here. > I can't make sense of what it is trying to tell me. It shows you the system calls being made. If you read down to the end, rsync writes 4 bytes and then tries to read 4 bytes from the remote side. At that point it gets a closed socket error. Thus, the issue isn't rsync but that the connection is closing without either side being able to send/receive any data. (Both sides are seeing the connection go away.) Perhaps the networking drivers are buggy. Or perhaps you have firewall or selinux rules that are closing the connection. Your /var/log files might have a clue. ..wayne.. -- 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 gives me error 12
Adam: Thanks for the opinion on the version differences. Regarding my server setup, this command works: scp r...@marketing.propfinancing.com:/var/www/svnDumps/* "c:\\Tmp" So I am not completely convinced the problem lies in the network or my server. It would be nice to get rsync working since it will be a more efficient solution. But, I am not going to spend a lot of effort on it. Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! -- 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 gives me error 12
On Fri, Mar 25, 2022 at 12:36:55PM -0500, Neil Aggarwal wrote: > Adam: > > I tried doing an upload using this command: > rsync test.xml r...@marketing.propfinancing.com:/tmp > > I still get an error: > rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] > rsync error: error in rsync protocol data stream (code 12) at io.c(226) > [Receiver=3.1.3] > rsync: connection unexpectedly closed (0 bytes received so far) [sender] > rsync error: error in rsync protocol data stream (code 12) at io.c(228) > [sender=3.2.4dev] > > Could it be the rsync versions are somehow incompatible? That seems unlikely: this is an incredibly generic error, and there are *many* possible causes for it. I've never heard of version incompatibilities causing this sort of behaviour, and if they did, I'd expect that would be very widely documented. I'd expect the versions would need to differ much more substantially before that would cause an issue. At this point, I don't think there's any evidence there's a problem with Cygwin itself, or with the rsync packaging for Cygwin; this looks like a problem with either your server setup or your rsync configuration. As such -- at least unless I've missed something that points to it being a problem with Cygwin or the Cygwin rsync package in particular -- I think we're rapidly veering off topic for the Cygwin mailing list. > Would it help if I create a login for you on the server so > you can try doing an rsync yourself? If you can provide steps by which someone could set up their own ssh+rsync server and reproduce this problem, you might be able to get further help on some other open source forum. If those steps necessarily require Cygwin, you might even be able to get further help on this mailing list. I'm afraid, however, that connecting to your server to help diagnose problems there is the sort of thing you probably need to pay someone to do. -- 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 gives me error 12
Wayne: When I run this command on my Windows machine: echo hi | ssh r...@marketing.propfinancing.com cat I get back: hi When I run this command: rsync --debug=ALL --msgs2stderr -M--msgs2stderr r...@marketing.propfinancing.com:/var/www/svnDumps /cygdrive/c/Tmp I get this output: opening connection using: ssh -l root marketing.propfinancing.com rsync --server --sender -e.LsfxCIvu --msgs2stderr --msgs2stderr . /var/www/svnDumps (12 args) rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.3] rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(228) [Receiver=3.2.4dev] [Receiver] _exit_cleanup(code=12, file=io.c, line=228): about to call exit(12) I put the rsync-debug script in /tmp on the server and then ran this command on my Windows machine: rsync -av --rsync-path=/tmp/rsync-debug r...@marketing.propfinancing.com:/var/www/svnDumps /cygdrive/c/Tmp I got the same output on my local machine. On the server, I got a /tmp/rsync-3191.out file which I am attaching here. I can't make sense of what it is trying to tell me. Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! rsync-3191.out Description: Binary data -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: rsync gives me error 12
On Fri, Mar 25, 2022 at 10:37 AM Neil Aggarwal wrote: > I still get an error: > rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] > rsync error: error in rsync protocol data stream (code 12) at io.c(226) > [Receiver=3.1.3] > rsync: connection unexpectedly closed (0 bytes received so far) [sender] > rsync error: error in rsync protocol data stream (code 12) at io.c(228) > [sender=3.2.4dev] As the rsync issues & debugging page mentions, you should try forcing errors to stderr to see if it makes the remote rsync report its error to you: --msgs2stderr -M--msgs2stderr It also mentions an rsync-debug script that you can put on the remote host and use to get the strace output of what is happening and get a core dump (if it is dumping core). https://rsync.samba.org/issues.html Also, try running the following test command and make sure you see the word "hi" and nothing else: echo hi | ssh r...@marketing.propfinancing.com cat ..wayne.. -- 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 gives me error 12
Adam: I tried doing an upload using this command: rsync test.xml r...@marketing.propfinancing.com:/tmp I still get an error: rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.3] rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(228) [sender=3.2.4dev] Could it be the rsync versions are somehow incompatible? Would it help if I create a login for you on the server so you can try doing an rsync yourself? Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! -- 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 gives me error 12
Adam: > this reads to me like the remote > server is closing the connection When I run this command on my Windows machine: rsync --debug=ALL r...@marketing.propfinancing.com:/var/www/svnDumps /cygdrive/c/Tmp I get this output on the screen: opening connection using: ssh -l root marketing.propfinancing.com rsync --server --sender -e.LsfxCIvu . /var/www/svnDumps (10 args) rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.3] rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(228) [Receiver=3.2.4dev] [Receiver] _exit_cleanup(code=12, file=io.c, line=228): about to call exit(12) It is connecting to the Linux server and immediately disconnecting, here is what I see in /var/log/secure: Mar 25 12:11:00 marketing sshd[43597]: Postponed publickey for root from 99.137.191.183 port 64715 ssh2 [preauth] Mar 25 12:11:00 marketing sshd[43597]: Accepted publickey for root from 99.137.191.183 port 64715 ssh2: RSA SHA256:[removed] Mar 25 12:11:00 marketing sshd[43597]: pam_unix(sshd:session): session opened for user root by (uid=0) Mar 25 12:11:00 marketing sshd[43600]: Received disconnect from 99.137.191.183 port 64715:11: disconnected by user Mar 25 12:11:00 marketing sshd[43600]: Disconnected from user root 99.137.191.183 port 64715 Mar 25 12:11:00 marketing sshd[43597]: pam_unix(sshd:session): session closed for user root I'm stumped at this point. Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! -- 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 gives me error 12
Adam: > Looking slightly closer at the logs, this reads to me like the remote > server is closing the connection, so I expect you'll need help from > whoever provides/supports that remote server to work out why it's doing > that. I am responsible for the remote server. I will look into that. Thank you for putting me on the right track! Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! -- 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 gives me error 12
On Fri, Mar 25, 2022 at 08:25:16AM -0500, Neil Aggarwal wrote: > > I suspect the `-e ssh` part is the problem here. That's supposed to > > specify the remote shell, not the method for connecting. What are you > > attempting to achieve with that? > > I am trying to do the sync over an SSH connection. > > When I remove it: > rsync --debug=ALL r...@marketing.propfinancing.com:/var/www/svnDumps > /cygdrive/c/Tmp > > I still get the error: > opening connection using: ssh -l root marketing.propfinancing.com > rsync --server --sender -e.LsfxCIvu . /var/www/svnDumps (10 args) > rsync: connection unexpectedly closed (0 bytes received so far) [sender] > rsync error: error in rsync protocol data stream (code 12) at io.c(226) > [sender=3.1.3] > rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] > rsync error: error in rsync protocol data stream (code 12) at io.c(228) > [Receiver=3.2.4dev] > [Receiver] _exit_cleanup(code=12, file=io.c, line=228): about to call > exit(12) Works just fine for me. (Indeed, it works just fine even if I add `-e ssh`, which surprised me -- clearly I have the wrong impression of what that `-e` argument is for!) Looking slightly closer at the logs, this reads to me like the remote server is closing the connection, so I expect you'll need help from whoever provides/supports that remote server to work out why it's doing that. -- 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 gives me error 12
> I suspect the `-e ssh` part is the problem here. That's supposed to > specify the remote shell, not the method for connecting. What are you > attempting to achieve with that? I am trying to do the sync over an SSH connection. When I remove it: rsync --debug=ALL r...@marketing.propfinancing.com:/var/www/svnDumps /cygdrive/c/Tmp I still get the error: opening connection using: ssh -l root marketing.propfinancing.com rsync --server --sender -e.LsfxCIvu . /var/www/svnDumps (10 args) rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.3] rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(228) [Receiver=3.2.4dev] [Receiver] _exit_cleanup(code=12, file=io.c, line=228): about to call exit(12) Thanks, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! -- 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 gives me error 12
On Thu, Mar 24, 2022 at 12:22:12AM -0500, Neil Aggarwal wrote: > I am trying to use rsync to pull all backups from a linux server > to my local Windows machine. > > I tried this rsync command: > > $ rsync --debug=ALL -e ssh r...@marketing.propfinancing.com:/var/www/svnDumps > /cygdrive/c/Tmp > > Here is the output: > > opening connection using: ssh -l root marketing.propfinancing.com rsync > --server --sender -e.LsfxCIvu . /var/www/svnDumps (10 args) > > rsync: connection unexpectedly closed (0 bytes received so far) [sender] > > rsync error: error in rsync protocol data stream (code 12) at io.c(226) > [sender=3.1.3] > > rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] > > rsync error: error in rsync protocol data stream (code 12) at io.c(228) > [Receiver=3.2.4dev] > > [Receiver] _exit_cleanup(code=12, file=io.c, line=228): about to call > exit(12) > > From what I can find online, code 12 is insufficient disk space, missing > remote > rsync, or a connection error. I don’t think any of those are the case > here and the > debug output is not helping me. > > Any ideas what could be happening? I suspect the `-e ssh` part is the problem here. That's supposed to specify the remote shell, not the method for connecting. What are you attempting to achieve with that? -- 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
rsync gives me error 12
Hello: I am trying to use rsync to pull all backups from a linux server to my local Windows machine. I tried this rsync command: $ rsync --debug=ALL -e ssh r...@marketing.propfinancing.com:/var/www/svnDumps /cygdrive/c/Tmp Here is the output: opening connection using: ssh -l root marketing.propfinancing.com rsync --server --sender -e.LsfxCIvu . /var/www/svnDumps (10 args) rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.3] rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(228) [Receiver=3.2.4dev] [Receiver] _exit_cleanup(code=12, file=io.c, line=228): about to call exit(12) From what I can find online, code 12 is insufficient disk space, missing remote rsync, or a connection error. I don’t think any of those are the case here and the debug output is not helping me. Any ideas what could be happening? Thank you, Neil -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses! -- 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 subpackage build error ... not a supported wheel on this platform
On 2022-03-13 07:04, Jon Turney wrote:
On 12/03/2022 17:54, Brian Inglis wrote:
Building locally I get the message below on 64 & 32 bit package builds:
ERROR: python_nghttp2-1.47.0-cp38-cp38-cygwin_3_3_4_x86_64.whl is not
a supported wheel on this platform.
but not in the confines of a scallywag build: what do I need to remove
or change to build locally?
What have you tried?
Installing every python*-{devel,pip,setuptools,wheel} package in sight!
See bottom for inherited and installed package lists.
The packages installed by scallywag are recorded in the build log, so
have you looked at that to see what's installed there but not locally?
At a guess, it might be that you need python38-wheel or python38-pip
installed, which scallywag arranges to be installed when it sees
'inherit python-wheel' [1]
[1]
https://github.com/cygwin/scallywag/blob/85647ca84422616d22537d728332130b4462/analyze.py#L171
Tried config with --enable-python-bindings as well as usual opposite to
build with cygport using cython.
Just tried uninstalling python*-{tox,virtualenv} and dependencies
python-{pip,setuptools,wheel}-wheel with no change!
Will next try inherit python3-wheel instead of python-wheel and use
python3_wheel_{compile,install}.
That gets me further and results in:
python38-nghttp2-1.47.0-1.tar.xz
tar: usr/lib/python3.8/site-packages/*nghttp2*: Cannot stat: No such
file or directory
tar: Exiting with failure status due to previous errors
*** ERROR: Binary package creation failed: python38-nghttp2
Reading through cygport cygclass python/3-wheel docs, it implies that
using generic python-nghttp2 in PKG_NAMES should expand to specified
(default) versions (now python38-nghttp2, python39-nghttp2) rather than
having to explicitly specify the latter?
Will try and see if that works as expected and perhaps helps: no - only
latest version built, not both 3.8 and 3.9.
Now local and scallywag consistently fail not building python 3.8 package!
Reverting to python-wheel from python3-wheel.
Just found /usr/local/bin/pip{,3,3.8} with explicit #!/usr/bin/python3.8
same date as curl 7.75 release over a year ago, so there must have been
some issue to workaround, which never had any impact until this package
and release! Sorry for the noise!
That all now seems to work properly locally and on scallywag.
#
#Inherited and Installed Scallywag and Local Packages
#
$ egrep inherits scallywag/*86*/6_*.log | cut -d' ' -f3- | sort -ur
scallywag: cygport inherits: python-wheel
scallywag: build dependencies (deduced from inherits):
python2-pip,python2-wheel,python3-devel,python36-pip,python36-wheel,python37-pip,python37-wheel,python38-pip,python38-wheel,python39-pip,python39-wheel
# above does not include python2/7-devel, python3[67]-devel
$ egrep 'install\spython[^-]*-(devel|pip|setuptools|wheel)' \
scallywag/*86*/[46]_*.log | awk '{print $5}' | sort -u
python27-pip
python27-setuptools
python27-wheel
python36-pip
python36-setuptools
python36-wheel
python37-pip
python37-setuptools
python37-wheel
python38-devel
python38-pip
python38-setuptools
python38-wheel
python39-devel
python39-pip
python39-setuptools
python39-wheel
python3-devel
$ apt-cyg l python*-{devel,pip,setuptools,wheel} | cut -d' ' -f1 | \
sort -u
python27-devel
python27-pip
python27-setuptools
python27-wheel
python2-devel
python2-setuptools
python36-devel
python36-pip
python36-setuptools
python36-wheel
python37-devel
python37-pip
python37-setuptools
python37-wheel
python38-devel
python38-pip
python38-setuptools
python38-wheel
python39-devel
python39-pip
python39-setuptools
python39-wheel
python3-devel
python3-pip
python3-setuptools
python3-wheel
python-pip-wheel
python-setuptools
python-setuptools-wheel
python-wheel-wheel
--
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: python subpackage build error ... not a supported wheel on this platform
On 12/03/2022 17:54, Brian Inglis wrote: Building locally I get the message below on 64 & 32 bit package builds: ERROR: python_nghttp2-1.47.0-cp38-cp38-cygwin_3_3_4_x86_64.whl is not a supported wheel on this platform. but not in the confines of a scallywag build: what do I need to remove or change to build locally? What have you tried? The packages installed by scallywag are recorded in the build log, so have you looked at that to see what's installed there but not locally? At a guess, it might be that you need python38-wheel or python38-pip installed, which scallywag arranges to be installed when it sees 'inherit python-wheel' [1] [1] https://github.com/cygwin/scallywag/blob/85647ca84422616d22537d728332130b4462/analyze.py#L171
python subpackage build error ... not a supported wheel on this platform
Building locally I get the message below on 64 & 32 bit package builds:
ERROR: python_nghttp2-1.47.0-cp38-cp38-cygwin_3_3_4_x86_64.whl is not a
supported wheel on this platform.
but not in the confines of a scallywag build: what do I need to remove
or change to build locally?
Most relevant lines from cygport ... all are attached (sanitized).
--
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.]$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/src/nghttp2-1.47.0/configure
--srcdir=$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/src/nghttp2-1.47.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--infodir=/usr/share/info --mandir=/usr/share/man -C --enable-shared
--disable-static --disable-python-bindings --enable-python-bindings
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for a Python interpreter with version >= 3.8... python
checking for python... /usr/bin/python
checking for python version... 3.9
checking for python platform... cygwin
checking for GNU default python prefix... ${prefix}
checking for GNU default python exec_prefix... ${exec_prefix}
checking for python script directory (pythondir)...
${PYTHON_PREFIX}/lib/python3.9/site-packages
checking for python extension module directory (pyexecdir)...
${PYTHON_EXEC_PREFIX}/lib/python3.9/site-packages
checking for python3.9... (cached) /usr/bin/python
checking for Python include path... -I/usr/include/python3.9
checking for Python library path... -L/usr/lib -lpython3.9
checking for Python site-packages path... /usr/lib/python3.9/site-packages
checking python extra libraries... -lcrypt -lintl -ldl
checking python extra linking flags...
checking consistency of all components of python development environment... yes
config.status: creating python/Makefile
config.status: creating python/setup.py
config.status: creating doc/python-apiref.rst
CFLAGS: -ggdb -O2 -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4
-fdebug-prefix-map=$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/build=/usr/src/debug/nghttp2-1.47.0-1
-fdebug-prefix-map=$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/src/nghttp2-1.47.0=/usr/src/debug/nghttp2-1.47.0-1
CXXFLAGS: -ggdb -O2 -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4
-Werror=return-type
-fdebug-prefix-map=$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/build=/usr/src/debug/nghttp2-1.47.0-1
-fdebug-prefix-map=$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/src/nghttp2-1.47.0=/usr/src/debug/nghttp2-1.47.0-1
Python: /usr/bin/python
pyexecdir: ${PYTHON_EXEC_PREFIX}/lib/python3.9/site-packages
PYTHON_CPPFLAGS:-I/usr/include/python3.9
PYTHON_LIBS:-L/usr/lib -lpython3.9
Making all in python
make[2]: Entering directory
'$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/build/python'
cython -3 -o nghttp2.c
$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/src/nghttp2-1.47.0/python/nghttp2.pyx
/usr/bin/python setup.py build
gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -ggdb -O2
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fstack-protector-strong --param=ssp-buffer-size=4
-fdebug-prefix-map=$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/build=/usr/src/debug/nghttp2-1.47.0-1
-fdebug-prefix-map=$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/src/nghttp2-1.47.0=/usr/src/debug/nghttp2-1.47.0-1
-I$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/src/nghttp2-1.47.0/lib
-I$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/src/nghttp2-1.47.0/lib/includes
-I../lib/includes -I/usr/include/python3.9 -c nghttp2.c -o
build/temp.cygwin-3.3.4-x86_64-3.9/nghttp2.o
gcc -shared -Wl,--enable-auto-image-base -ggdb -O2 -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong
--param=ssp-buffer-size=4
-fdebug-prefix-map=$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/build=/usr/src/debug/nghttp2-1.47.0-1
-fdebug-prefix-map=$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/src/nghttp2-1.47.0=/usr/src/debug/nghttp2-1.47.0-1
build/temp.cygwin-3.3.4-x86_64-3.9/nghttp2.o -L../lib/.libs -L../lib -L..
-L/usr/lib/python3.9/config -L/usr/lib -lnghttp2 -lpython3.9 -o
build/lib.cygwin-3.3.4-x86_64-3.9/nghttp2.cpython-39-x86_64-cygwin.dll
make[2]: Leaving directory
'$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/build/python'
/usr/lib/python3.9/site-packages/Cython/Compiler/Main.py:369: FutureWarning:
Cython directive 'language_level' not set, using 2 for now (Py2). This will
change in a later release! File:
$HOME/src/cygwin/nghttp2/nghttp2-1.47.0-1.x86_64/src/nghttp2-1.47.0/python/nghttp2.pyx
gcc -Wno-unused-result -Wsign-
Re: minor error in skel/.bashrc
Greetings, Adam Dinwoodie!
> On Sat, Mar 05, 2022 at 09:26:06AM +0300, lvm wrote:
>> The identical /etc/skel/.bashrc and /etc/defaults/etc/skel/.bashrc contain
>> the same line
>>
>> # export HISTCONTROL=$HISTCONTROL${HISTCONTROL+,}ignoredups
Not a nitpick or anything, but I've found a slightly clearer technique on the
internet:
export HISTCONTROL=${HISTCONTROL:+$HISTCONTROL:}ignoredups
>>
>> But HISTCONTROL values should be colon separated, not comma separated. This
>> line is commented out, but if someone like me tries to use it without much
>> thinking...
> Confirmed.
> Achim, I've attached a patch that should fix this, based on the tip of
> https://sourceware.org/git/cygwin-apps/base-files.git
--
With best regards,
Andrey Repin
Tuesday, March 8, 2022 11:14:29
Sorry for my terrible english...
--
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: minor error in skel/.bashrc
On Sat, Mar 05, 2022 at 09:26:06AM +0300, lvm wrote:
> The identical /etc/skel/.bashrc and /etc/defaults/etc/skel/.bashrc contain
> the same line
>
> # export HISTCONTROL=$HISTCONTROL${HISTCONTROL+,}ignoredups
>
> But HISTCONTROL values should be colon separated, not comma separated. This
> line is commented out, but if someone like me tries to use it without much
> thinking...
Confirmed.
Achim, I've attached a patch that should fix this, based on the tip of
https://sourceware.org/git/cygwin-apps/base-files.git
HTH
Adam
>From 90bd8c6b46a467b26972f5ecac5c2f05ed321f49 Mon Sep 17 00:00:00 2001
From: Adam Dinwoodie
Date: Sat, 5 Mar 2022 13:14:42 +
Subject: [PATCH] Correct HISTCONTROL in .bashrc
Per bash.1, HISTCONTROL values should be colon-separated, not
comma-separated, so correct the sample line for adding "ignoredups" to
HISTCONTROL to use the correct separator.
At the same time, use the separator if and only if there is a non-null
value already set in HISTCONTROL. The previous version of this sample
code would insert the separator if HISTCONTROL were defined as the empty
string, where it'd be exactly as unnecessary as if it weren't defined at
all.
---
etc/defaults/etc/skel/.bashrc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/etc/defaults/etc/skel/.bashrc b/etc/defaults/etc/skel/.bashrc
index 3a4f59a..b6a48cf 100644
--- a/etc/defaults/etc/skel/.bashrc
+++ b/etc/defaults/etc/skel/.bashrc
@@ -54,7 +54,7 @@
# History Options
#
# Don't put duplicate lines in the history.
-# export HISTCONTROL=$HISTCONTROL${HISTCONTROL+,}ignoredups
+# export HISTCONTROL=$HISTCONTROL${HISTCONTROL:+:}ignoredups
#
# Ignore some controlling instructions
# HISTIGNORE is a colon-delimited list of patterns which should be excluded.
--
2.35.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
minor error in skel/.bashrc
The identical /etc/skel/.bashrc and /etc/defaults/etc/skel/.bashrc contain
the same line
# export HISTCONTROL=$HISTCONTROL${HISTCONTROL+,}ignoredups
But HISTCONTROL values should be colon separated, not comma separated. This
line is commented out, but if someone like me tries to use it without much
thinking...
--
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: pty, console: Fix handle leak which occurs on exec() error.
- This patch fixes the handle leak which occurs when exec() fails
with an error. The duplicated handles will be closed when the
exec'ed process is terminated. However, if exec() fails, the code
path does not reach to the code closing the duplicated handles.
To implement this fix more appropriately, the setup, cleanup and
closing pty codes which was previously located in spawn.cc are
encapsulated into the fhandler_pty_slave class functions.
---
winsup/cygwin/fhandler.h | 20 +++-
winsup/cygwin/fhandler_console.cc | 17 ++-
winsup/cygwin/fhandler_tty.cc | 70 +++-
winsup/cygwin/spawn.cc| 182 +++---
winsup/cygwin/tty.cc | 2 +-
5 files changed, 157 insertions(+), 134 deletions(-)
diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
index 4fadbd82a..40dab9346 100644
--- a/winsup/cygwin/fhandler.h
+++ b/winsup/cygwin/fhandler.h
@@ -2249,9 +2249,8 @@ private:
static void close_handle_set (handle_set_t *p);
static void cons_master_thread (handle_set_t *p, tty *ttyp);
- pid_t get_owner (void) { return shared_console_info->con.owner; }
- void setup_console_for_non_cygwin_app ();
- void cleanup_console_for_non_cygwin_app ();
+ void setup_for_non_cygwin_app ();
+ static void cleanup_for_non_cygwin_app (handle_set_t *p);
static void set_console_mode_to_native ();
friend tty_min * tty_list::get_cttyp ();
@@ -2325,6 +2324,14 @@ class fhandler_pty_slave: public fhandler_pty_common
void fch_close_handles ();
public:
+ struct handle_set_t
+ {
+HANDLE from_master_nat;
+HANDLE input_available_event;
+HANDLE input_mutex;
+HANDLE pcon_mutex;
+ };
+
/* Constructor */
fhandler_pty_slave (int);
@@ -2381,13 +2388,18 @@ class fhandler_pty_slave: public fhandler_pty_common
void reset_switch_to_pcon (void);
void mask_switch_to_pcon_in (bool mask, bool xfer);
void setup_locale (void);
- tty *get_ttyp () { return (tty *) tc (); } /* Override as public */
void create_invisible_console (void);
static void transfer_input (tty::xfer_dir dir, HANDLE from, tty *ttyp,
HANDLE input_available_event);
HANDLE get_input_available_event (void) { return input_available_event; }
bool pcon_activated (void) { return get_ttyp ()->pcon_activated; }
void cleanup_before_exit ();
+ void get_duplicated_handle_set (handle_set_t *p);
+ static void close_handle_set (handle_set_t *p);
+ void setup_for_non_cygwin_app (bool nopcon, PWCHAR envblock,
+bool stdin_is_ptys);
+ static void cleanup_for_non_cygwin_app (handle_set_t *p, tty *ttyp,
+ bool stdin_is_ptys);
};
#define __ptsname(buf, unit) __small_sprintf ((buf), "/dev/pty%d", (unit))
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index 03ec88804..ec33a9d3c 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -507,10 +507,8 @@ fhandler_console::set_output_mode (tty::cons_mode m, const
termios *t,
ReleaseMutex (p->output_mutex);
}
-static fhandler_console::handle_set_t NO_COPY duplicated_handle_set;
-
void
-fhandler_console::setup_console_for_non_cygwin_app ()
+fhandler_console::setup_for_non_cygwin_app ()
{
/* Setting-up console mode for non-cygwin app. */
/* If conmode is set to tty::native for non-cygwin apps
@@ -521,22 +519,21 @@ fhandler_console::setup_console_for_non_cygwin_app ()
(get_ttyp ()->getpgid ()== myself->pgid) ? tty::native : tty::restore;
set_input_mode (conmode, ()->ti, get_handle_set ());
set_output_mode (conmode, ()->ti, get_handle_set ());
- /* Console handles will be already closed by close_all_files()
- when cleaning up, therefore, duplicate them here. */
- get_duplicated_handle_set (_handle_set);
}
void
-fhandler_console::cleanup_console_for_non_cygwin_app ()
+fhandler_console::cleanup_for_non_cygwin_app (handle_set_t *p)
{
+ termios dummy = {0, };
+ termios *ti =
+shared_console_info ? &(shared_console_info->tty_min_state.ti) :
/* Cleaning-up console mode for non-cygwin app. */
/* conmode can be tty::restore when non-cygwin app is
exec'ed from login shell. */
tty::cons_mode conmode =
(con.owner == myself->pid) ? tty::restore : tty::cygwin;
- set_output_mode (conmode, ()->ti, _handle_set);
- set_input_mode (conmode, ()->ti, _handle_set);
- close_handle_set (_handle_set);
+ set_output_mode (conmode, ti, p);
+ set_input_mode (conmode, ti, p);
}
/* Return the tty structure associated with a given tty number. If the
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index a25690a0e..10026b995 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -235,7 +235,7 @@ atexit_func (void)
force_switch_to = GetProcessId (h_gd
Re: Apache error when enabling ssl
On 16.02.2022 23:34, Scott Wood wrote: Whenever I try to enable the ssl module in apache2 (original dist version or custom compiled version) I get the following error: $ apachectl -k start [Wed Feb 16 17:29:11.188154 2022] [core:emerg] [pid 47724] (88)Function not implemented: AH00023: Couldn't create the mpm-accept mutex (88)Function not implemented: could not create accept mutex AH00015: Unable to open logs /usr/local/bin/apachectl: line 79: 47724 Segmentation fault (core dumped) $HTTPD "$@" Any help? are you running the cygserver ? -- 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
Apache error when enabling ssl
Whenever I try to enable the ssl module in apache2 (original dist version or custom compiled version) I get the following error: $ apachectl -k start [Wed Feb 16 17:29:11.188154 2022] [core:emerg] [pid 47724] (88)Function not implemented: AH00023: Couldn't create the mpm-accept mutex (88)Function not implemented: could not create accept mutex AH00015: Unable to open logs /usr/local/bin/apachectl: line 79: 47724 Segmentation fault (core dumped) $HTTPD "$@" Any help? -- 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: Log.text error
On 2022-02-02 21:34, Niclas Helbig wrote: The log Text told me to send you this. I am no Code-wizzard, so I dont really know what this means. I dont have Surface Wind Layer and WAFS Turbulence unfortunatly. Would really like to fix that but dont know how. ... 0 [main] WIN32wgrib2 5128 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com 328371 [main] WIN32wgrib2 5128 exception::handle: Exception: STATUS_STACK_OVERFLOW 331088 [main] WIN32wgrib2 5128 open_stackdumpfile: Dumping stack trace to WIN32wgrib2.exe.stackdump 0 [main] WIN32wgrib2 10104 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com ... Your ancient version of Cygwin is incompatible with your version of Windows - please update Cygwin: https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Log.text error
Hello there,
The log Text told me to send you this.
I am no Code-wizzard, so I dont really know what this means.
I dont have Surface Wind Layer and WAFS Turbulence unfortunatly.
Would really like to fix that but dont know how.
Greetings,
Niclas
0 [main] WIN32wgrib2 5128 find_fast_cwd: WARNING: Couldn't compute
FAST_CWD pointer. Please report this problem to
the public mailing list cygwin@cygwin.com
328371 [main] WIN32wgrib2 5128 exception::handle: Exception:
STATUS_STACK_OVERFLOW
331088 [main] WIN32wgrib2 5128 open_stackdumpfile: Dumping stack trace to
WIN32wgrib2.exe.stackdump
0 [main] WIN32wgrib2 10104 find_fast_cwd: WARNING: Couldn't compute
FAST_CWD pointer. Please report this problem to
the public mailing list cygwin@cygwin.com
1:0:d=2022020218:PRMSL:mean sea level:9 hour fcst:
2:263017:d=2022020218:TMP:150 mb:9 hour fcst:
3:491150:d=2022020218:UGRD:150 mb:9 hour fcst:
4:669734:d=2022020218:VGRD:150 mb:9 hour fcst:
5:846211:d=2022020218:TMP:200 mb:9 hour fcst:
6:1076611:d=2022020218:UGRD:200 mb:9 hour fcst:
7:1259370:d=2022020218:VGRD:200 mb:9 hour fcst:
8:1441117:d=2022020218:TMP:300 mb:9 hour fcst:
9:1673187:d=2022020218:UGRD:300 mb:9 hour fcst:
10:1863564:d=2022020218:VGRD:300 mb:9 hour fcst:
11:2058164:d=2022020218:TMP:400 mb:9 hour fcst:
12:2282507:d=2022020218:UGRD:400 mb:9 hour fcst:
13:2466463:d=2022020218:VGRD:400 mb:9 hour fcst:
14:2655380:d=2022020218:TMP:500 mb:9 hour fcst:
15:2877717:d=2022020218:UGRD:500 mb:9 hour fcst:
16:3054789:d=2022020218:VGRD:500 mb:9 hour fcst:
17:3234940:d=2022020218:TMP:600 mb:9 hour fcst:
18:3460754:d=2022020218:UGRD:600 mb:9 hour fcst:
19:3633291:d=2022020218:VGRD:600 mb:9 hour fcst:
20:3807624:d=2022020218:TMP:700 mb:9 hour fcst:
21:4038732:d=2022020218:UGRD:700 mb:9 hour fcst:
22:4211679:d=2022020218:VGRD:700 mb:9 hour fcst:
23:4386381:d=2022020218:TMP:850 mb:9 hour fcst:
24:4638098:d=2022020218:UGRD:850 mb:9 hour fcst:
25:4815995:d=2022020218:VGRD:850 mb:9 hour fcst:
26:4998729:d=2022020218:LCDC:low cloud layer:9 hour fcst:
27:5243931:d=2022020218:LCDC:low cloud layer:6-9 hour ave fcst:
28:5491117:d=2022020218:MCDC:middle cloud layer:9 hour fcst:
29:5679383:d=2022020218:MCDC:middle cloud layer:6-9 hour ave fcst:
30:5874880:d=2022020218:HCDC:high cloud layer:9 hour fcst:
31:6089765:d=2022020218:HCDC:high cloud layer:6-9 hour ave fcst:
32:6324000:d=2022020218:PRES:low cloud bottom level:6-9 hour ave fcst:
33:6676205:d=2022020218:PRES:middle cloud bottom level:6-9 hour ave fcst:
34:6978111:d=2022020218:PRES:high cloud bottom level:6-9 hour ave fcst:
35:7345909:d=2022020218:PRES:low cloud top level:6-9 hour ave fcst:
36:7704032:d=2022020218:PRES:middle cloud top level:6-9 hour ave fcst:
37:814:d=2022020218:PRES:high cloud top level:6-9 hour ave fcst:
38:8367797:d=2022020218:PRES:tropopause:9 hour fcst:
39:8762649:d=2022020218:TMP:tropopause:9 hour fcst:
Feb 03 05:18:50 ---
Feb 03 05:18:50 Starting server
Feb 03 05:18:50 ---
Feb 03 05:18:50 ['X:\\only 4 Xplane/steamapps/common/X-Plane
11\\Resources\\plugins\\PythonPlugins\\noaweather\\weatherServer.py', 'X:\\only
4 Xplane/steamapps/common/X-Plane 11']
Feb 03 05:18:50 Saving Settings to X:\only 4 Xplane/steamapps/common/X-Plane
11\Resources\plugins\PythonPlugins\noaweather\weatherServer.pkl
Feb 03 05:18:50 Server started.
Feb 03 05:18:50 Downloading part of
https://www.aviationweather.gov/docs/metar/stations.txt with params:
{'context': }
Feb 03 05:18:51 Downloading: 20220202_gfs.t18z.pgrb2full.0p50.f009
Feb 03 05:18:51 Downloading part of
https://nomads.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gfs.20220202/18/atmos/gfs.t18z.pgrb2full.0p50.f009.idx
with params: {'context': }
Feb 03 05:18:51 Updating metar stations.
Feb 03 05:18:51 Downloading part of
https://aviationweather.gov/adds/dataserver_current/current/metars.cache.csv.gz
with params: {'context': }
Feb 03 05:18:51 9258 metar stations updated.
Feb 03 05:18:51 Downloading: 2022020218_gfs.t18z.wafs_0p25_unblended.f12.grib2
Feb 03 05:18:51 Downloading part of
https://www.ftp.ncep.noaa.gov/data/nccf/com/gfs/prod/gfs.20220202/18/atmos/gfs.t18z.wafs_0p25_unblended.f12.grib2
with params: {'context': }
Feb 03 05:18:53 Downloading part of
https://nomads.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gfs.20220202/18/atmos/gfs.t18z.pgrb2full.0p50.f009
with params: {'context': }
Feb 03 05:18:54 Downloading part of
https://nomads.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gfs.20220202/18/atmos/gfs.t18z.pgrb2full.0p50.f009
with params: {'context': }
Feb 03 05:18:55 Downloading part of
https://nomads.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gfs.20220202/18/atmos/gfs.t18z.pgrb2full.0p50.f009
with params: {'context': }
Feb 03 05:18:57 Downloading part of
https://nomads.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gfs.20220202/18/atmos/gfs.t18z.pgrb2full.0p50.f009
with params: {'context': }
Feb 03 05:18:58 Downloading part of
Re: GitHub Action Error
On Tue, Feb 01, 2022 at 12:34:45AM +0900, Lemures Lemniscati wrote: > On Mon, 31 Jan 2022 14:15:41 +, © Fxzx mic > > > > running: C:\cygwin\bin\dash.exe "/etc/postinstall/0p_000_autorebase.dash" > > > > abnormal exit: exit code=-1073741701 > > > > > > > I don't know why. Can anyone help me? > > Although the installed packages are different, my other Github Action is > > similar to this one, but that Github Action has no problem. > > I've got similar experience: > https://github.com/cygwin/scallywag/runs/5007960186?check_suite_focus=true > > This worked well on 2022-01-22: > https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=libdeflate==3754 > > > I wonder cygwin-3.3.4-1 might have an issue. > When I updated to cygwin-3.3.4-1, an error occurred with cygwin1.dll. > And then I downgraded to cygwin-3.3.3-1, it worked again. 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: GitHub Action Error
On Mon, 31 Jan 2022 14:15:41 +, © Fxzx mic > I am installing these packages with cygwin/cygwin-install-action@master: > > > > cmake make gdb mingw64-x86_64-gcc-g++ > > > > on Github Action. However, the following error occurred: > > > > Changing gid back to original > > running: C:\cygwin\bin\dash.exe "/etc/postinstall/0p_000_autorebase.dash" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\dash.exe "/etc/postinstall/0p_update-info-dir.dash" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\bash.exe --norc --noprofile > "/etc/postinstall/000-cygwin-post-install.sh" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\bash.exe --norc --noprofile > "/etc/postinstall/coreutils.sh" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/bash.sh" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\bash.exe --norc --noprofile > "/etc/postinstall/base-files-mketc.sh" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\bash.exe --norc --noprofile > "/etc/postinstall/base-files-profile.sh" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\bash.exe --norc --noprofile > "/etc/postinstall/p11-kit.sh" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\bash.exe --norc --noprofile > "/etc/postinstall/ca-certificates.sh" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\bash.exe --norc --noprofile > "/etc/postinstall/crypto-policies.sh" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\dash.exe "/etc/postinstall/openssl.dash" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\bash.exe --norc --noprofile > "/etc/postinstall/libxml2.sh" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\bash.exe --norc --noprofile > "/etc/postinstall/libsasl2_3.sh" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\bash.exe --norc --noprofile > "/etc/postinstall/python38-pip.sh" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\bash.exe --norc --noprofile > "/etc/postinstall/python38.sh" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\dash.exe "/etc/postinstall/man-db.dash" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\bash.exe --norc --noprofile > "/etc/postinstall/mintty.sh" > > abnormal exit: exit code=-1073741701 > > running: C:\cygwin\bin\dash.exe "/etc/postinstall/zp_man-db-update-index.dash" > > abnormal exit: exit code=-1073741701 > > Changing gid to Administrators > > Ending cygwin install > > I don't know why. Can anyone help me? > Although the installed packages are different, my other Github Action is > similar to this one, but that Github Action has no problem. I've got similar experience: https://github.com/cygwin/scallywag/runs/5007960186?check_suite_focus=true This worked well on 2022-01-22: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=libdeflate==3754 I wonder cygwin-3.3.4-1 might have an issue. When I updated to cygwin-3.3.4-1, an error occurred with cygwin1.dll. And then I downgraded to cygwin-3.3.3-1, it worked again. Lem -- 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: GitHub Action Error
On Mon, Jan 31, 2022 at 3:16 PM © Fxzx mic wrote: > > I am installing these packages with cygwin/cygwin-install-action@master: > > cmake make gdb mingw64-x86_64-gcc-g++ > on Github Action. However, the following error occurred: > > Changing gid back to original > running: C:\cygwin\bin\dash.exe "/etc/postinstall/0p_000_autorebase.dash" > abnormal exit: exit code=-1073741701 -1073741701 is also 0X C000 007B so the error means: The Application was Unable to Start Correctly (0xc07b) > I don't know why. Can anyone help me? > Although the installed packages are different, my other Github Action is > similar to this one, but that Github Action has no problem. I would guess you need to install also the needed packages required by those packages or there is something interfering with Cygwin Have you tested to install only the Base category ? 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
GitHub Action Error
I am installing these packages with cygwin/cygwin-install-action@master: cmake make gdb mingw64-x86_64-gcc-g++ on Github Action. However, the following error occurred: Changing gid back to original running: C:\cygwin\bin\dash.exe "/etc/postinstall/0p_000_autorebase.dash" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\dash.exe "/etc/postinstall/0p_update-info-dir.dash" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/000-cygwin-post-install.sh" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/coreutils.sh" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/bash.sh" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/base-files-mketc.sh" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/base-files-profile.sh" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/p11-kit.sh" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/ca-certificates.sh" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/crypto-policies.sh" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\dash.exe "/etc/postinstall/openssl.dash" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/libxml2.sh" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/libsasl2_3.sh" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/python38-pip.sh" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/python38.sh" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\dash.exe "/etc/postinstall/man-db.dash" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/mintty.sh" abnormal exit: exit code=-1073741701 running: C:\cygwin\bin\dash.exe "/etc/postinstall/zp_man-db-update-index.dash" abnormal exit: exit code=-1073741701 Changing gid to Administrators Ending cygwin install I don't know why. Can anyone help me? Although the installed packages are different, my other Github Action is similar to this one, but that Github Action has no problem. --- From: Fxzx mic fxzx...@outlook.com<mailto:fxzx...@outlook.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: CI system cryptic error
On 22/01/2022 05:34, Marco Atzeri wrote: On 21.01.2022 17:03, Hamish McIntyre-Bhatty wrote: On 21/01/2022 14:06, Jon Turney wrote: On 20/01/2022 15:50, Hamish McIntyre-Bhatty wrote: Hi there, Recently, I created a test package for python-imaging, and the CI system gave a build error that I didn't see locally: *** ERROR: unknown wheel filename. This only occurred for the Python 3.8 build (3.6 and 3.7 are unaffected). Considering some of the library name changes between these versions, is it possible that this is a bug in the CI tool setup or in cygport? Weird. I assume it's this job: https://github.com/cygwin/scallywag/actions/runs/1592256829 Yep, sorry I forgot to add the link. In which case further note it only failed with this error on i686, x86_64 seems to have built ok. That might explain why you don't see it locally, at least, but it's still puzzling that there's a difference. No I did a local i686 build too, and it was fine... This error comes from here: https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=blob;f=cygclass/python-wheel.cygclass;h=90b0faac71eea6005401b4232e5b334bdc81b756;hb=HEAD#l190 and means something more like "couldn't find the wheel file for python $ver" I downloaded the builddir archive, and inspecting that it seems that a wheel for python3.8 (and 3.9!) isn't being generated. $ tar -tf builddir.tar.xz | grep whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp36-cp36m-cygwin_3_3_3_i686.whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp37-cp37m-cygwin_3_3_3_i686.whl There seems to be completely different output between x86_64 and i686 when building the python wheel, but I have no idea why! Hmm, very strange. Maybe just a freak error? I'll try building again, seeing as I have a new version now anyway, and see what happens. I guess seeing as 64-bit builds are the future for Cygwin, I'll just ignore this issue if it happens again, as long as I check the 32-bit builds I built work. Hamish I saw something similar but I do not remember the details. Cygport is looking for something that has changed name or it is not available anymore. Probably the old name is still used by Python2 and it is the reason why the error seldom show up in local build of maintainers. cygport --debug should provide some hints Good idea, I'll try that, and I'll also remove python 2 from my cygwin install if I can. Cheers, Hamish
Re: CI system cryptic error
On 21.01.2022 17:03, Hamish McIntyre-Bhatty wrote: On 21/01/2022 14:06, Jon Turney wrote: On 20/01/2022 15:50, Hamish McIntyre-Bhatty wrote: Hi there, Recently, I created a test package for python-imaging, and the CI system gave a build error that I didn't see locally: *** ERROR: unknown wheel filename. This only occurred for the Python 3.8 build (3.6 and 3.7 are unaffected). Considering some of the library name changes between these versions, is it possible that this is a bug in the CI tool setup or in cygport? Weird. I assume it's this job: https://github.com/cygwin/scallywag/actions/runs/1592256829 Yep, sorry I forgot to add the link. In which case further note it only failed with this error on i686, x86_64 seems to have built ok. That might explain why you don't see it locally, at least, but it's still puzzling that there's a difference. No I did a local i686 build too, and it was fine... This error comes from here: https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=blob;f=cygclass/python-wheel.cygclass;h=90b0faac71eea6005401b4232e5b334bdc81b756;hb=HEAD#l190 and means something more like "couldn't find the wheel file for python $ver" I downloaded the builddir archive, and inspecting that it seems that a wheel for python3.8 (and 3.9!) isn't being generated. $ tar -tf builddir.tar.xz | grep whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp36-cp36m-cygwin_3_3_3_i686.whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp37-cp37m-cygwin_3_3_3_i686.whl There seems to be completely different output between x86_64 and i686 when building the python wheel, but I have no idea why! Hmm, very strange. Maybe just a freak error? I'll try building again, seeing as I have a new version now anyway, and see what happens. I guess seeing as 64-bit builds are the future for Cygwin, I'll just ignore this issue if it happens again, as long as I check the 32-bit builds I built work. Hamish I saw something similar but I do not remember the details. Cygport is looking for something that has changed name or it is not available anymore. Probably the old name is still used by Python2 and it is the reason why the error seldom show up in local build of maintainers. cygport --debug should provide some hints
Re: CI system cryptic error
On 21/01/2022 14:06, Jon Turney wrote: On 20/01/2022 15:50, Hamish McIntyre-Bhatty wrote: Hi there, Recently, I created a test package for python-imaging, and the CI system gave a build error that I didn't see locally: *** ERROR: unknown wheel filename. This only occurred for the Python 3.8 build (3.6 and 3.7 are unaffected). Considering some of the library name changes between these versions, is it possible that this is a bug in the CI tool setup or in cygport? Weird. I assume it's this job: https://github.com/cygwin/scallywag/actions/runs/1592256829 Yep, sorry I forgot to add the link. In which case further note it only failed with this error on i686, x86_64 seems to have built ok. That might explain why you don't see it locally, at least, but it's still puzzling that there's a difference. No I did a local i686 build too, and it was fine... This error comes from here: https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=blob;f=cygclass/python-wheel.cygclass;h=90b0faac71eea6005401b4232e5b334bdc81b756;hb=HEAD#l190 and means something more like "couldn't find the wheel file for python $ver" I downloaded the builddir archive, and inspecting that it seems that a wheel for python3.8 (and 3.9!) isn't being generated. $ tar -tf builddir.tar.xz | grep whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp36-cp36m-cygwin_3_3_3_i686.whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp37-cp37m-cygwin_3_3_3_i686.whl There seems to be completely different output between x86_64 and i686 when building the python wheel, but I have no idea why! Hmm, very strange. Maybe just a freak error? I'll try building again, seeing as I have a new version now anyway, and see what happens. I guess seeing as 64-bit builds are the future for Cygwin, I'll just ignore this issue if it happens again, as long as I check the 32-bit builds I built work. Hamish
Re: CI system cryptic error
On 20/01/2022 15:50, Hamish McIntyre-Bhatty wrote: Hi there, Recently, I created a test package for python-imaging, and the CI system gave a build error that I didn't see locally: *** ERROR: unknown wheel filename. This only occurred for the Python 3.8 build (3.6 and 3.7 are unaffected). Considering some of the library name changes between these versions, is it possible that this is a bug in the CI tool setup or in cygport? Weird. I assume it's this job: https://github.com/cygwin/scallywag/actions/runs/1592256829 In which case further note it only failed with this error on i686, x86_64 seems to have built ok. That might explain why you don't see it locally, at least, but it's still puzzling that there's a difference. This error comes from here: https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=blob;f=cygclass/python-wheel.cygclass;h=90b0faac71eea6005401b4232e5b334bdc81b756;hb=HEAD#l190 and means something more like "couldn't find the wheel file for python $ver" I downloaded the builddir archive, and inspecting that it seems that a wheel for python3.8 (and 3.9!) isn't being generated. $ tar -tf builddir.tar.xz | grep whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp36-cp36m-cygwin_3_3_3_i686.whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp37-cp37m-cygwin_3_3_3_i686.whl There seems to be completely different output between x86_64 and i686 when building the python wheel, but I have no idea why!
Re: Help needed with wxWidgets3.1 tests compilation error
On 20/01/2022 20:38, Brian Inglis wrote: On 2022-01-20 10:10, Hamish McIntyre-Bhatty wrote: I've been having trouble compiling the unit tests for wxWidgets3.1-3.1.5 on Cygwin. The same tests build just fine on my Linux Mint 20.3 install, however that is using GCC 9.3.0 instead of Cygwin's 11.2.0. Attached is the full build log, but I will also point out my ideas about particular issues here. Note: -Werror=format-security is used in the Makefile. I couldn't find exactly what this does, but I'm probably looking in the wrong place - the manpage. Perhaps the following could also be explained by differences from GCC 9 to 11? I check first as in `info GCC Wformat-security` should only care about *printf string variables without using a separate format string. Ah okay, I guess that doesn't explain the -Werror=zero-as-null-pointer-constant errors later. I guess that might be a GCC default change. The first is: In file included from /usr/include/unistd.h:4, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/filefn.h:23, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/utils.h:20, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/cursor.h:75, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/event.h:22, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/evtloop.h:14, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/testprec.h:5, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:433: /usr/include/sys/unistd.h:23:9: error: redundant redeclaration of ‘int chmod(const char*, mode_t)’ in same scope [-Werror=redundant-decls] 23 | int chmod (const char *__path, mode_t __mode); | ^ In file included from /usr/include/sys/_default_fcntl.h:211, from /usr/include/sys/fcntl.h:3, from /usr/include/fcntl.h:12, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:83: /usr/include/sys/stat.h:137:9: note: previous declaration of ‘int chmod(const char*, mode_t)’ 137 | int chmod (const char *__path, mode_t __mode ); | ^ This doesn't happen on my Linux Mint 20.3 (Ubuntu 20.04) host, so I'm assuming this is something to do with the standard library? Next is: In file included from /usr/include/unistd.h:4, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/filefn.h:23, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/utils.h:20, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/cursor.h:75, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/event.h:22, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/evtloop.h:14, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/testprec.h:5, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:433: /usr/include/sys/unistd.h:179:9: error: redundant redeclaration of ‘int pthread_atfork(void (*)(), void (*)(), void (*)())’ in same scope [-Werror=redundant-decls] 179 | int pthread_atfork (void (*)(void), void (*)(void), void (*)(void)); | ^~ In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr-default.h:35, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr.h:148, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ext/atomicity.h:35, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/ios_base.h:39, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/iomanip:40, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:63: /usr/include/pthread.h:65:5: note: previous declaration of ‘int pthread_atfork(void (*)(), void (*)(), void (*)())’ 65 | int pthread_atfork (void (*)(void), void (*)(void), void (*)(void)); | ^~ Ditto. Looking at chmod(3p), pthread_atfork(3p), pthread.h(0p) sys_stat.h(0p), unistd.h(0p) those definitions should *NOT* normally be accessible from unistd.h so there should be no conflict, as POSIX specifies what is visible. Perhaps they are there for compatibility with older systems like BSD
Re: Help needed with wxWidgets3.1 tests compilation error
On 2022-01-20 10:10, Hamish McIntyre-Bhatty wrote: I've been having trouble compiling the unit tests for wxWidgets3.1-3.1.5 on Cygwin. The same tests build just fine on my Linux Mint 20.3 install, however that is using GCC 9.3.0 instead of Cygwin's 11.2.0. Attached is the full build log, but I will also point out my ideas about particular issues here. Note: -Werror=format-security is used in the Makefile. I couldn't find exactly what this does, but I'm probably looking in the wrong place - the manpage. Perhaps the following could also be explained by differences from GCC 9 to 11? I check first as in `info GCC Wformat-security` should only care about *printf string variables without using a separate format string. The first is: In file included from /usr/include/unistd.h:4, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/filefn.h:23, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/utils.h:20, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/cursor.h:75, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/event.h:22, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/evtloop.h:14, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/testprec.h:5, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:433: /usr/include/sys/unistd.h:23:9: error: redundant redeclaration of ‘int chmod(const char*, mode_t)’ in same scope [-Werror=redundant-decls] 23 | int chmod (const char *__path, mode_t __mode); | ^ In file included from /usr/include/sys/_default_fcntl.h:211, from /usr/include/sys/fcntl.h:3, from /usr/include/fcntl.h:12, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:83: /usr/include/sys/stat.h:137:9: note: previous declaration of ‘int chmod(const char*, mode_t)’ 137 | int chmod (const char *__path, mode_t __mode ); | ^ This doesn't happen on my Linux Mint 20.3 (Ubuntu 20.04) host, so I'm assuming this is something to do with the standard library? Next is: In file included from /usr/include/unistd.h:4, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/filefn.h:23, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/utils.h:20, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/cursor.h:75, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/event.h:22, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/evtloop.h:14, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/testprec.h:5, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:433: /usr/include/sys/unistd.h:179:9: error: redundant redeclaration of ‘int pthread_atfork(void (*)(), void (*)(), void (*)())’ in same scope [-Werror=redundant-decls] 179 | int pthread_atfork (void (*)(void), void (*)(void), void (*)(void)); | ^~ In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr-default.h:35, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr.h:148, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ext/atomicity.h:35, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/ios_base.h:39, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/iomanip:40, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:63: /usr/include/pthread.h:65:5: note: previous declaration of ‘int pthread_atfork(void (*)(), void (*)(), void (*)())’ 65 | int pthread_atfork (void (*)(void), void (*)(void), void (*)(void)); | ^~ Ditto. Looking at chmod(3p), pthread_atfork(3p), pthread.h(0p) sys_stat.h(0p), unistd.h(0p) those definitions should *NOT* normally be accessible from unistd.h so there should be no conflict, as POSIX specifies what is visible. Perhaps they are there for compatibility with older systems like BSD or Solaris and should be suppressed when newer feature macros are defined or specific legacy system macros are not defined? Also of note, is that Cygwin is several times slower
Help needed with wxWidgets3.1 tests compilation error
Hi there, I've been having trouble compiling the unit tests for wxWidgets3.1-3.1.5 on Cygwin. The same tests build just fine on my Linux Mint 20.3 install, however that is using GCC 9.3.0 instead of Cygwin's 11.2.0. Attached is the full build log, but I will also point out my ideas about particular issues here. Note: -Werror=format-security is used in the Makefile. I couldn't find exactly what this does, but I'm probably looking in the wrong place - the manpage. Perhaps the following could also be explained by differences from GCC 9 to 11? The first is: In file included from /usr/include/unistd.h:4, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/filefn.h:23, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/utils.h:20, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/cursor.h:75, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/event.h:22, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/evtloop.h:14, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/testprec.h:5, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:433: /usr/include/sys/unistd.h:23:9: error: redundant redeclaration of ‘int chmod(const char*, mode_t)’ in same scope [-Werror=redundant-decls] 23 | int chmod (const char *__path, mode_t __mode); | ^ In file included from /usr/include/sys/_default_fcntl.h:211, from /usr/include/sys/fcntl.h:3, from /usr/include/fcntl.h:12, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:83: /usr/include/sys/stat.h:137:9: note: previous declaration of ‘int chmod(const char*, mode_t)’ 137 | int chmod (const char *__path, mode_t __mode ); | ^ This doesn't happen on my Linux Mint 20.3 (Ubuntu 20.04) host, so I'm assuming this is something to do with the standard library? Next is: In file included from /usr/include/unistd.h:4, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/filefn.h:23, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/utils.h:20, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/cursor.h:75, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/event.h:22, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/evtloop.h:14, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/testprec.h:5, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:433: /usr/include/sys/unistd.h:179:9: error: redundant redeclaration of ‘int pthread_atfork(void (*)(), void (*)(), void (*)())’ in same scope [-Werror=redundant-decls] 179 | int pthread_atfork (void (*)(void), void (*)(void), void (*)(void)); | ^~ In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr-default.h:35, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr.h:148, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ext/atomicity.h:35, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/ios_base.h:39, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/iomanip:40, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:63: /usr/include/pthread.h:65:5: note: previous declaration of ‘int pthread_atfork(void (*)(), void (*)(), void (*)())’ 65 | int pthread_atfork (void (*)(void), void (*)(void), void (*)(void)); | ^~ Ditto. Then there are some wxwidgets-specific ones, but I'll make a separate thread for those because I have an idea about what might be causing them. I'll probably need to ask the wxWidgets people. Hopefully someone here with more experience can help. Also of note, is that Cygwin is several times slower at compiling pretty much everything for me. Does anyone know if this is GCC 9 vs 11 speed, or running Cygwin in Windows 11 in KVM, or something else? I am running on AMD Ryzen 3000, if that has anything to do with it. Hamish /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/build/gtk2/bk-deps g++ -c -o test_allheaders_allheaders.o -I/home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/build/gtk2/lib/wx/include
CI system cryptic error
Hi there,
Recently, I created a test package for python-imaging, and the CI system
gave a build error that I didn't see locally:
*** ERROR: unknown wheel filename.
This only occurred for the Python 3.8 build (3.6 and 3.7 are
unaffected). Considering some of the library name changes between these
versions, is it possible that this is a bug in the CI tool setup or in
cygport?
Attached is the offending cygport file that caused the error.
Hamish
ORIG_PN="Pillow"
PYTHON_WHEEL_VERSIONS="3.6:3.7:3.8:3.9"
inherit python-wheel
NAME="python-imaging"
VERSION=8.4.0
RELEASE=1
CATEGORY="Python"
SUMMARY="Python Imaging Library"
DESCRIPTION="The Python Imaging Library (PIL) adds image processing capabilities
to your Python interpreter. This library supports many file formats, and
provides
powerful image processing and graphics capabilities."
HOMEPAGE="https://python-pillow.github.io/;
SRC_URI="https://files.pythonhosted.org/packages/7d/2a/2fc11b54e2742db06297f7fa7f420a0e3069fdcf0e4b57dfec33f0b08622/Pillow-8.4.0.tar.gz;
SRC_DIR="Pillow-${VERSION}"
PATCH_URI=""
BUILD_REQUIRES="libjpeg-devel libjpeg8 zlib-devel zlib0 libtiff-devel libtiff6
libfreetype-devel libfreetype6 liblcms2-devel lcms2 libwebp libwebp-devel
tcl-devel tcl libimagequant-devel libimagequant0 libraqm-devel libraqm0
libX11-xcb-devel libX11-xcb1 libxcb-devel libxcb1 python36 python36-devel
python36-setuptools python36-wheel python36-pip python36-olefile python37
python37-devel python37-setuptools python37-wheel python37-pip python37-olefile
python38 python38-devel python38-setuptools python38-wheel python38-pip
python38-olefile python39 python39-devel python39-setuptools python39-wheel
python39-pip python39-olefile"
DIFF_EXCLUDES="build"
src_test() {
cd ${B}
for v in ${PYTHON_WHEEL_VERSIONS//:/ }
do
echo PYTHONPATH="${B}/build/lib.cygwin-$(uname -r | sed -e
's|s*(.*||')-$(uname -m)-$v"
PYTHONPATH="${B}/build/lib.cygwin-$(uname -r | sed -e
's|s*(.*||')-$(uname -m)-$v" \
python$v selftest.py
done
}
PKG_NAMES=" python36-imaging python36-imaging-tk"
PKG_NAMES+=" python37-imaging python37-imaging-tk"
PKG_NAMES+=" python38-imaging python38-imaging-tk"
PKG_NAMES+=" python39-imaging python39-imaging-tk"
# ImageQt no longer imports PyQt or PySide, but simply integrates with
# whatever has already been imported. Therefore there is no need to
# break it out separately, as it has no hard dependencies of its own.
python36_imaging_REQUIRES="python36 python36-olefile"
python36_imaging_OBSOLETES+=" python3-imaging-devel python3-imaging-qt"
python36_imaging_CONTENTS="
--exclude=_imagingtk*
--exclude=ImageTk*
--exclude=SpiderImagePlugin*
${python36_imaging_CONTENTS}
"
python36_imaging_tk_OBSOLETES="python3-imaging-tk"
python36_imaging_tk_REQUIRES="python36-imaging python36-tkinter"
python36_imaging_tk_CONTENTS="
usr/lib/python3.6/site-packages/PIL/_imagingtk*
usr/lib/python3.6/site-packages/PIL/ImageTk*
usr/lib/python3.6/site-packages/PIL/SpiderImagePlugin*
usr/lib/python3.6/site-packages/PIL/__pycache__/ImageTk*
usr/lib/python3.6/site-packages/PIL/__pycache__/SpiderImagePlugin*
"
python37_imaging_REQUIRES="python37 python37-olefile"
python37_imaging_CONTENTS="
--exclude=_imagingtk*
--exclude=ImageTk*
--exclude=SpiderImagePlugin*
${python37_imaging_CONTENTS}
"
python37_imaging_tk_REQUIRES="python37-imaging python37-tkinter"
python37_imaging_tk_CONTENTS="
usr/lib/python3.7/site-packages/PIL/_imagingtk*
usr/lib/python3.7/site-packages/PIL/ImageTk*
usr/lib/python3.7/site-packages/PIL/SpiderImagePlugin*
usr/lib/python3.7/site-packages/PIL/__pycache__/ImageTk*
usr/lib/python3.7/site-packages/PIL/__pycache__/SpiderImagePlugin*
"
python38_imaging_REQUIRES="python38 python38-olefile"
python38_imaging_CONTENTS="
--exclude=_imagingtk*
--exclude=ImageTk*
--exclude=SpiderImagePlugin*
${python38_imaging_CONTENTS}
"
python38_imaging_tk_REQUIRES="python38-imaging python38-tkinter"
python38_imaging_tk_CONTENTS="
usr/lib/python3.8/site-packages/PIL/_imagingtk*
usr/lib/python3.8/site-packages/PIL/ImageTk*
usr/lib/python3.8/site-packages/PIL/SpiderImagePlugin*
usr/lib/python3.8/site-packages/PIL/__pycache__/ImageTk*
usr/lib/python3.8/site-packages/PIL/__pycache__/SpiderImagePlugin*
"
python39_imaging_REQUIRES="python39 python39-olefile"
python39_imaging_CONTENTS="
--exclude=_imagingtk*
--exclude=ImageTk*
--exclude=SpiderImagePlugi
Re: [PATCH] Cygwin: resolver: cygwin_query() skip response header on internal error
On Jan 19 08:12, Anton Lavrentiev via Cygwin-patches wrote: > - When dn_comp() failed internally there is no longer any need to > fill the response header since it's now all cleared upon entry > --- > winsup/cygwin/libc/minires-os-if.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Pushed. Thanks, Corinna
[PATCH] Cygwin: resolver: cygwin_query() skip response header on internal error
- When dn_comp() failed internally there is no longer any need to
fill the response header since it's now all cleared upon entry
---
winsup/cygwin/libc/minires-os-if.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/libc/minires-os-if.c
b/winsup/cygwin/libc/minires-os-if.c
index c6fde776a..4e8e9cf21 100644
--- a/winsup/cygwin/libc/minires-os-if.c
+++ b/winsup/cygwin/libc/minires-os-if.c
@@ -266,6 +266,7 @@ static int cygwin_query(res_state statp, const char *
DomName, int Class, int Ty
if ((len = dn_comp(rr->pName, ptr, AnsLength - 4,
dnptrs, [DIM(dnptrs) - 1])) < 0) {
statp->res_h_errno = NETDB_INTERNAL; /* dn_comp sets errno */
+ AnsLength = 0;
len = -1;
goto done;
}
@@ -283,7 +284,7 @@ static int cygwin_query(res_state statp, const char *
DomName, int Class, int Ty
DPRINTF(debug, "Unexpected section order for \"%s\" %d\n", DomName,
Type);
continue;
}
-section = rr->Flags.DW & 0x3;
+section = rr->Flags.DW & 0x3;
ptr = write_record(ptr, rr, AnsPtr + AnsLength, dnptrs,
[DIM(dnptrs) - 1], debug);
--
2.33.0
Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
On Thu, 13 Jan 2022 16:11:04 -0800
Mark Geisert wrote:
> Takashi Yano wrote:
> > On Wed, 12 Jan 2022 07:41:41 +0100
> > Marco Atzeri wrote:
> >> On 12.01.2022 07:27, Jay K wrote:
> >>> 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);
> >>
> >>
> >> so you are mixing Cygwin and Windows calls ?
> >> That is looking for trouble.
> >>
> >> Or it is a tentative to produce a test case ?
> >
> > I found that the same happens even with pthread rather than
> > win32 thread functions.
> >
> > #include
> > #include
> >
> > void *thread(void *p)
> > {
> > system("true");
> > return NULL;
> > }
> >
> > int main()
> > {
> > int i;
> > pthread_t threads[2];
> >
> > for (i = 0; i < 2; i++)
> > pthread_create([i], NULL, thread, NULL);
> >
> > for (i = 0; i < 2; i++)
> > pthread_join(threads[i], NULL);
> >
> > return 0;
> > }
> >
> > Executing above code results in hang with message:
> >0 [waitproc] a 786 proc_waiter: error on read of child wait pipe
> > 0x0, Win32 error 6
> >
>
> POSIX does not require system() to be thread-safe. On Cygwin, it isn't.
> When I
> ran into this a while back, I implemented an application wrapper around
> system()
> to serialize calls. It's tricky because you want to serialize just the
> mechanism
> of system(), not the programs that the multiple system()s call.
Ah, indeed.
https://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html
says:
"The system() function need not be thread-safe."
while Linux's system() is MT-safe.
Thanks.
--
Takashi Yano
--
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: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
Takashi Yano wrote:
On Wed, 12 Jan 2022 07:41:41 +0100
Marco Atzeri wrote:
On 12.01.2022 07:27, Jay K wrote:
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);
so you are mixing Cygwin and Windows calls ?
That is looking for trouble.
Or it is a tentative to produce a test case ?
I found that the same happens even with pthread rather than
win32 thread functions.
#include
#include
void *thread(void *p)
{
system("true");
return NULL;
}
int main()
{
int i;
pthread_t threads[2];
for (i = 0; i < 2; i++)
pthread_create([i], NULL, thread, NULL);
for (i = 0; i < 2; i++)
pthread_join(threads[i], NULL);
return 0;
}
Executing above code results in hang with message:
0 [waitproc] a 786 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
POSIX does not require system() to be thread-safe. On Cygwin, it isn't. When I
ran into this a while back, I implemented an application wrapper around system()
to serialize calls. It's tricky because you want to serialize just the mechanism
of system(), not the programs that the multiple system()s call.
..mark
--
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: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
On Wed, 12 Jan 2022 07:41:41 +0100
Marco Atzeri wrote:
> On 12.01.2022 07:27, Jay K wrote:
> > 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);
>
>
> so you are mixing Cygwin and Windows calls ?
> That is looking for trouble.
>
> Or it is a tentative to produce a test case ?
I found that the same happens even with pthread rather than
win32 thread functions.
#include
#include
void *thread(void *p)
{
system("true");
return NULL;
}
int main()
{
int i;
pthread_t threads[2];
for (i = 0; i < 2; i++)
pthread_create([i], NULL, thread, NULL);
for (i = 0; i < 2; i++)
pthread_join(threads[i], NULL);
return 0;
}
Executing above code results in hang with message:
0 [waitproc] a 786 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
--
Takashi Yano
--
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: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
On 1/13/2022 1:40 AM, Jay K wrote:
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);
}
Again, Cygwin is designed to provide a POSIX-like interface.
Maybe you should just be using a Windows C compiler?
EM
--
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: 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
Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
On 12.01.2022 07:27, Jay K wrote:
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);
so you are mixing Cygwin and Windows calls ?
That is looking for trouble.
Or it is a tentative to produce a test case ?
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: 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:
FrameFunctionArgs
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,
Win32 error 6
452 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
716 [waitproc] cm3 7641 proc_waiter: e
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, Win32 error 6 452 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 716 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 1652 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 0 [main] sh 7775 C:\cygwin64\bin\sh.exe: *** fatal error - internal error reading the windows environment - too many environment variables? Scenario is multi-threaded "launching" a bunch of invocations of gcc. "launching" was usually spawnve or fork/execve but I changed the code to use system and it still happens. I might try to make a small reproducing, if this is not known. It seems a bit difficult to believe I could cause this internal looking error. Thank you, - 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
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, Win32 error 6 452 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 716 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 1652 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 0 [main] sh 7775 C:\cygwin64\bin\sh.exe: *** fatal error - internal error reading the windows environment - too many environment variables? Scenario is multi-threaded "launching" a bunch of invocations of gcc. "launching" was usually spawnve or fork/execve but I changed the code to use system and it still happens. I might try to make a small reproducing, if this is not known. It seems a bit difficult to believe I could cause this internal looking error. Thank you, - 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
Re: Cygwin/X fatal error
Hi all - and happy 2022 to everybody. > I ran > $ rm -vrf /tmp/.X11* > in order to enable a "fresh start" and all is good. I have the same problem after the last update. I usually start cygwin with Xlaunch, and I get the same error message; now, every time I start cygwin I have to go and delete /tmp/.X11-unix/X0 manually. It won't be deleted when I close cygwin. Any chance I can do something to prevent this behavior, or shall I wait the next update for a fix? ciao! Massi -- 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/X fatal error
On 08.01.2022 07:57, Fergus Daly wrote: > Not quite sure what recent update has caused this failure. > Up to now (and for a very long time indeed) typing > $ /bin/xinit /bin/xterm -- -nolock -multiwindow > at the mintty prompt has successfully started an xterm process. > Now I get: > "A fatal error has occurred and Cygwin/X will now exit. > Cannot establish any listening sockets." > Over the years the one-liner typed above has had to evolve with changing > execs so I'm not surprised, or bothered, at this glitch. > But can anybody please advise the necessary change in syntax that will again > enable a successful xterm from mintty? > Thank you! Marco Atzero replied: > Hi Fergus, > It works for me, so it seems not due to the sintax > Can you start X with startxwin ? > Please provide the cygcheck.out as mentioned on > Problem reports: https://cygwin.com/problems.html > Regards > Marco SOLVED I ran $ rm -vrf /tmp/.X11* in order to enable a "fresh start" and all is good. On all devices and for both Cygwin32 and Cygwin64. Thank you, Marco. Fergus -- 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/X fatal error
On 08.01.2022 07:57, Fergus Daly wrote: Not quite sure what recent update has caused this failure. Up to now (and for a very long time indeed) typing $ /bin/xinit /bin/xterm -- -nolock -multiwindow at the mintty prompt has successfully started an xterm process. Now I get: "A fatal error has occurred and Cygwin/X will now exit. Cannot establish any listening sockets." Over the years the one-liner typed above has had to evolve with changing execs so I'm not surprised, or bothered, at this glitch. But can anybody please advise the necessary change in syntax that will again enable a successful xterm from mintty? Thank you! Hi Fergus, It works for me, so it seems not due to the sintax Can you start X with startxwin ? Please provide the cygcheck.out as mentioned on Problem reports: https://cygwin.com/problems.html 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
Cygwin/X fatal error
Not quite sure what recent update has caused this failure. Up to now (and for a very long time indeed) typing $ /bin/xinit /bin/xterm -- -nolock -multiwindow at the mintty prompt has successfully started an xterm process. Now I get: "A fatal error has occurred and Cygwin/X will now exit. Cannot establish any listening sockets." Over the years the one-liner typed above has had to evolve with changing execs so I'm not surprised, or bothered, at this glitch. But can anybody please advise the necessary change in syntax that will again enable a successful xterm from mintty? Thank you! -- 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
cygport qt5-base.cygport compile fails ( *** ERROR: configure failed )
cygport qt5-base.cygport compile fails ( *** ERROR: configure failed ) Error massage ERROR: Feature 'dbus-linked' was enabled, but the pre-condition 'features.dbus && libs.dbus' failed. ERROR: Feature 'system-pcre2' was enabled, but the pre-condition 'libs.pcre2' failed. ERROR: Feature 'openssl-linked' was enabled, but the pre-condition '!features.securetransport && libs.openssl' failed. ERROR: Feature 'openssl' was enabled, but the pre-condition '!features.securetransport && (features.openssl-linked || libs.openssl_headers)' failed. ERROR: Feature 'xkbcommon-system' was enabled, but the pre-condition 'libs.xkbcommon_x11' failed. ERROR: Feature 'sql-mysql' was enabled, but the pre-condition 'libs.mysql' failed. ERROR: Feature 'sql-odbc' was enabled, but the pre-condition 'features.datestring && libs.odbc' failed. ERROR: Feature 'sql-psql' was enabled, but the pre-condition 'libs.psql' failed. ERROR: Feature 'sql-tds' was enabled, but the pre-condition 'features.datestring && libs.tds' failed. ERROR: Feature 'system-sqlite' was enabled, but the pre-condition 'features.sql-sqlite && libs.sqlite3' failed. Check config.log for details. *** ERROR: configure failed Tatsuro -- 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: raise(-1) has stopped returning an error recently
On Nov 27 10:43, Duncan Roe wrote: > On Wed, Nov 24, 2021 at 10:25:46AM +0100, cygwin wrote: [...] > > > > What is that "permanent restriction" in Cygwin? Is that something we > > could fix or something unfixable? Did you try to debug Cygwin in terms > > of that problem? If not, could you extract a reduced, very simple > > stand-alone testcase for further debugging? > > > The restriction is in grep/gnulib source. From > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27555#5 > > >> I've determined the cause, at least. The sole caller of mbstoupper > >> (which contained the relevant __CYGWIN__-specific > >> surrogate-pair-handling code) was removed by the improvements of > >> v2.21-63-g8a33cde, and not long after, I noticed that mbstoupper was > >> no longer used, so removed it altogether. > > I submitted a patch to save anyone else wasting time over this. So please > don't > you, Great, 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: Remmina: error while loading shared libraries: cygssh_threads-4.dll: cannot open shared object file: No such file or directory
On 11/28/2021 3:50 PM, Verachten Bruno via Cygwin wrote: Hello there, I installed Remmina tonight, and got this error when launching it: "error while loading shared libraries: cygssh_threads-4.dll: cannot open shared object file: No such file or directory That DLL used to be provided by the libssh4 package, but it's not in the latest version due to upstream changes. As a workaround, you could try reverting to libssh4-0.7.5-1, but I don't know if that will break something else. The real solution is probably to rebuild remmina using the current versions of the development packages. Unfortunately, remmina is orphaned, so someone would have to adopt it or do a non-maintainer upload. 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
Remmina: error while loading shared libraries: cygssh_threads-4.dll: cannot open shared object file: No such file or directory
Hello there, I installed Remmina tonight, and got this error when launching it: "error while loading shared libraries: cygssh_threads-4.dll: cannot open shared object file: No such file or directory ". Could it be linked to https://bugzilla.redhat.com/show_bug.cgi?id=1618616 ? Best regards, -- Bruno Verachten -- 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: raise(-1) has stopped returning an error recently
On Wed, Nov 24, 2021 at 11:01:46AM -0700, cygwin wrote: [...] > Trying to rerun cygport build most tests are now "skipped test: failed to > find an adequate shell SKIP ... (exit status: 77)"! Something more may have > changed (in gnulib?) to invalidate Cygwin shell(s) in something updated > since that grep release in August, as I am getting the same skipped tests > under GitHub CI, although it could just be that something expects say bash > > 4.4 or even >= 5! > They all pass for me in a directory tree created by 'make dist' under Linux. Maybe something changed in your test environment? N.B. grep maintainer replaced my patch with a fancier one that creates new surrogate-search test that Cygwin skips. Cheers ... Duncan. PASS: backref PASS: backref-alt PASS: backref-multibyte-slow PASS: backref-word PASS: backslash-dot PASS: backslash-s-and-repetition-operators PASS: backslash-s-vs-invalid-multibyte big-hole: skipped test: expensive: disabled by default SKIP: big-hole big-match: skipped test: expensive: disabled by default SKIP: big-match PASS: binary-file-matches PASS: bogus-wctob PASS: bre PASS: c-locale PASS: case-fold-backref PASS: case-fold-backslash-w PASS: case-fold-char-class PASS: case-fold-char-range PASS: case-fold-char-type PASS: case-fold-titlecase PASS: char-class-multibyte PASS: char-class-multibyte2 PASS: context-0 PASS: count-newline PASS: dfa-coverage PASS: dfa-heap-overrun PASS: dfa-infloop PASS: dfa-invalid-utf8 PASS: dfaexec-multibyte PASS: empty PASS: empty-line PASS: empty-line-mb PASS: encoding-error PASS: epipe XFAIL: equiv-classes PASS: ere PASS: euc-mb false-match-mb-non-utf8: skipped test: no support for the zh_CN.gb18030 locale SKIP: false-match-mb-non-utf8 PASS: fedora PASS: fgrep-infloop PASS: fgrep-longest PASS: file PASS: filename-lineno.pl PASS: fmbtest PASS: foad1 PASS: grep-dev-null PASS: grep-dev-null-out PASS: grep-dir ratio=0 PASS: hash-collision-perf PASS: help-version PASS: high-bit-range PASS: in-eq-out-infloop PASS: include-exclude PASS: inconsistent-range PASS: initial-tab PASS: invalid-multibyte-infloop PASS: khadafy PASS: kwset-abuse long-line-vs-2GiB-read: skipped test: expensive: disabled by default SKIP: long-line-vs-2GiB-read long-pattern-perf: skipped test: expensive: disabled by default SKIP: long-pattern-perf many-regex-performance: skipped test: expensive: disabled by default SKIP: many-regex-performance PASS: match-lines PASS: max-count-overread PASS: max-count-vs-context PASS: mb-dot-newline PASS: mb-non-UTF8-overrun PASS: mb-non-UTF8-perf-Fw mb-non-UTF8-performance: skipped test: expensive: disabled by default SKIP: mb-non-UTF8-performance PASS: mb-non-UTF8-word-boundary warning: \s failed to match \x0a in the en_US.UTF-8 locale warning: \s failed to match \x85 in the en_US.UTF-8 locale warning: \s failed to match \xe2\x80\x8b in the en_US.UTF-8 locale warning: \S mistakenly matched \xe2\x80\x8b in the en_US.UTF-8 locale PASS: multibyte-white-space PASS: multiple-begin-or-end-line PASS: null-byte PASS: options pcre: skipped test: no PCRE support SKIP: pcre pcre-abort: skipped test: no PCRE support SKIP: pcre-abort pcre-context: skipped test: no PCRE support SKIP: pcre-context pcre-count: skipped test: no PCRE support SKIP: pcre-count pcre-infloop: skipped test: no PCRE support SKIP: pcre-infloop pcre-invalid-utf8-infloop: skipped test: no PCRE support SKIP: pcre-invalid-utf8-infloop pcre-invalid-utf8-input: skipped test: no PCRE support SKIP: pcre-invalid-utf8-input pcre-jitstack: skipped test: no PCRE support SKIP: pcre-jitstack pcre-o: skipped test: no PCRE support SKIP: pcre-o pcre-utf8: skipped test: no PCRE support SKIP: pcre-utf8 pcre-w: skipped test: no PCRE support SKIP: pcre-w pcre-wx-backref: skipped test: no PCRE support SKIP: pcre-wx-backref pcre-z: skipped test: no PCRE support SKIP: pcre-z PASS: posix-bracket PASS: prefix-of-multibyte PASS: proc PASS: r-dot PASS: repetition-overflow PASS: reversed-range-endpoints PASS: sjis-mb PASS: skip-device PASS: skip-read PASS: spencer1 PASS: spencer1-locale PASS: stack-overflow PASS: status PASS: surrogate-pair surrogate-search: skipped test: surrogate-pair search string on Cygwin, where it cannot work SKIP: surrogate-search PASS: symlink triple-backref: expect malfunction on glibc systems due to https://sourceware.org/bugzilla/show_bug.cgi?id=11053 XFAIL: triple-backref PASS: turkish-I PASS: turkish-I-without-dot turkish-eyes: skipped test: your tr_TR.UTF-8 locale appears to be broken SKIP: turkish-eyes PASS: two-chars PASS: two-files PASS: unibyte-binary PASS: unibyte-bracket-expr PASS: unibyte-negated-circumflex PASS: utf8-bracket PASS: warn-char-classes PASS: word-delim-multibyte PASS: word-multi-file PASS: word-multibyte PASS: write-error-msg PASS: yesno PASS: z-anchor-newline Testsuite summary for GNU grep 3.7.42-9c15
Re: raise(-1) has stopped returning an error recently
On 2021-11-25 05:54, Corinna Vinschen via Cygwin wrote: On Nov 24 11:01, Brian Inglis via Cygwin wrote: On 2021-11-24 02:25, Corinna Vinschen via Cygwin wrote: On Tue, Nov 23, 2021 at 11:18:25AM -0700, Brian Inglis wrote: Do Cygwin and/or Windows support surrogate pairs in UTF-8? You mean UTF-16. UTF-8 doesn't know surrogate pairs, UTF-16 does. Originally there was UCS-2, 16 bits, with only 65536 code points. However, Unicode left the BMP already with version 2.0 in 1996, so UTF-16 and surrogate pairs became necessary. Windows as well as Cygwin support them. How does Cygwin support UTF-16 locales with surrogate pairs? UTF-16 locales? There's no such thing. UTF-16 is just the 16 bit representation for Unicode, and as such, is independent of the locale. On the user side, Cygwin only supports UTF-8 as Unicode representation. Internally you can then convert them to wchar_t which is UTF-16. Are they the "native" locales inherited from Windows if others are not specified e.g. UTF-8, some OEM SBCS or MBCS? Just try `locale -av' and you'll see all supported locales and their respective default codeset. All of them can be used with .utf8 specifier to use UTF-8 instead of the default codeset. Some of them use UTF-8 as default codeset anyway, e. g., fa_IR or yo_NG. There are 3 tests in surrogate-pair and only the 3rd one failed. So I guess surrogate pairs in UTF-8 "mostly work". UTF-16. The surrogate stuff is evil at times. Have a look at the __utf8_wctomb function in https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/wctomb_r.c Lone surrogate halfs in an input stream are a problem, for instance. Thus the confusion with grep surrogate pair tests which appear to be running under a UTF-8 locale: see attached surrogate pair extract from cygport --debug grep.cygport check. An STC in plain C might be helpful. I think I might finally have got the point of the test, not knowing much about legacy UTF-16 UCS encoding nor surrogate pairs. From what I can see: Ѕ U+010405 f0 90 90 85 DESERET CAPITAL LETTER LONG OO fails to match itself, presumably others do also. Presumably this is converted internally on some platforms, including Cygwin, to a UTF-16 surrogate pair, and a grep comparison fails, although a bash comparison succeeds. $ printf '\U10405\n' | iconv -f utf-8 -t utf-16be | xxd -g2 : d801 dc05 000a $ printf '\U10405\n' > t $ grep -f t t; echo $? 1 $ oo=`printf '\U10405\n'`; [ $oo = $oo ] && echo same || echo diff same -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: raise(-1) has stopped returning an error recently
On Wed, Nov 24, 2021 at 10:25:46AM +0100, cygwin wrote: [...] > > What is that "permanent restriction" in Cygwin? Is that something we > could fix or something unfixable? Did you try to debug Cygwin in terms > of that problem? If not, could you extract a reduced, very simple > stand-alone testcase for further debugging? > The restriction is in grep/gnulib source. From https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27555#5 >> I've determined the cause, at least. The sole caller of mbstoupper >> (which contained the relevant __CYGWIN__-specific >> surrogate-pair-handling code) was removed by the improvements of >> v2.21-63-g8a33cde, and not long after, I noticed that mbstoupper was >> no longer used, so removed it altogether. I submitted a patch to save anyone else wasting time over this. So please don't you, Cheers ... Duncan. -- 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
