Re: Bug in GCC / libstdc++: Space character categorized as non-printable by std::ctype

[Kristian Spangsege via Cygwin]

I have file this bug with GCC:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115524

On Sat, Jul 27, 2024 at 8:02 PM ASSI via Cygwin  wrote:

> ASSI via Cygwin writes:
> > This sounds like it might be a bug in newlib, so you should either
> > report it there or else it would be the newlib integration for gcc.  In
> > any case this needs to be fixed upstream.
>
> The latter turns out to be the case, this is actually the same bug (and
> will have the same fix) as:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104587
>
> If you go to the trouble of actually filing a bug with gcc it would be
> helpful to post the information here as well, so that somebody can
> follow up on it:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115524
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> SD adaptation for Waldorf rackAttack V1.04R1:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
>
> --
> 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: Updated: gcc-12.4.0-3

[Takashi Yano via Cygwin]

On Mon, 29 Jul 2024 23:02:17 +0900
Takashi Yano wrote:
> On Mon, 29 Jul 2024 07:18:53 +0200
> ASSI wrote:
> > Additionally, a new option '-mno-align-vector-insn' has been implemented
> > (following the lead of MSys2 and using a patch by Kai Tietz) to enable
> > an easier (more targeted) workaround for the underlying stack data
> > alignment problem when passing vector datatypes by value (which is due
> > to a conflict with alignment requirements for SEH and remains unsolved
> > upstream).  You can also use '-Wa,-muse-unaligned-vector-move', which is
> > more widely available.
> 
> gcc of MSYS2 enables -mno-align-vector-insn flag by default.
> However gcc 12.4.0-3 does not enable this flag by default.
> 
> Is this intentional?

Ah, I misunderstood.

For MSYS2,
/usr/bin/gcc   : without Kai's patch
/mingw64/bin/gcc   : -mno-align-vector-insn is enabled by default
/mingw32/bin/gcc   : -mno-align-vector-insn is enabled by default

For current cygwin,
/usr/bin/gcc (12.4.0-3)  : -mno-align-vector-insn is disabled by default
/usr/bin/x86_64-w64-mingw32-gcc : without Kai's patch (yet?)
/usr/bin/i686-w64-mingw32-gcc   : without Kai's patch (yet?)

-- 
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: Updated: gcc-12.4.0-3

[Takashi Yano via Cygwin]

On Mon, 29 Jul 2024 07:18:53 +0200
ASSI wrote:
> Additionally, a new option '-mno-align-vector-insn' has been implemented
> (following the lead of MSys2 and using a patch by Kai Tietz) to enable
> an easier (more targeted) workaround for the underlying stack data
> alignment problem when passing vector datatypes by value (which is due
> to a conflict with alignment requirements for SEH and remains unsolved
> upstream).  You can also use '-Wa,-muse-unaligned-vector-move', which is
> more widely available.

gcc of MSYS2 enables -mno-align-vector-insn flag by default.
However gcc 12.4.0-3 does not enable this flag by default.

Is this intentional?

-- 
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

Fw: Re: rpcd.exe solved

[Jim McNamara via Cygwin]

Hi all-

I've been testing out stuff like this now 
rsync -av -e "sshpass -p 'pass' ssh -o StrictHostKeyChecking=no -o 
UserKnownHostsFile=/dev/null" /home/user user@dockerip:/cygdrive/c/home/user

i will hook up to keys hopefully soon.

thanks all,
jim




Sent with Proton Mail secure email.

--- Forwarded Message ---
From: Jim McNamara via Cygwin 
Date: On Sunday, July 28th, 2024 at 8:19 PM
Subject: Fw: Re: rpcd.exe
To: cygwin@cygwin.com 


> Hi-
> 
> The AI really did go nuts like you said.
> I just read the man page for that and
> mkpassword -l isnt cutting it with setting up on win side first.
> 
> I dont know why it told me that. Crazy-town.
> 
> I will think of a command for a second..
> 
> I know what i will do i will create the user
> in windows and then wipe out the context of the
> /etc/passwd and then issue mkpasswd with the
> appropriate switch(es).
> 
> thanks
> 
> 
> 
> 
> 
> 
> Sent with Proton Mail secure email.
> 
> 
> --- Forwarded Message ---
> From: Jim McNamara via Cygwin cygwin@cygwin.com
> 
> Date: On Sunday, July 28th, 2024 at 8:06 PM
> Subject: Re: rpcd.exe
> To: cygwin@cygwin.com cygwin@cygwin.com
> 
> 
> 
> > Hi -
> > 
> > I dont want to give away your email by replying because I am
> > afraid it won't obfuscate when I reply back.
> > 
> > Thanks for the reply from you and the group!
> > 
> > I'm trying to issue this command
> > 
> > mkpasswd -l rsyncuser >> /etc/passwd
> > 
> > i thought it would append a line to the end of my /etc/passwd file
> > that would indicate that i now have a rsync user.
> > 
> > it malfunctions and doesnt append anything.
> > 
> > I might want to mention when i go to install from the installer at the
> > end of the installer wizard i get this m\sg.
> > 
> > Package: _/Unknown package
> > xinit.sh exit code 3
> > 
> > I dont know why mkpasswd is not working in this syntax.
> > I am about to add it (passwd file entry) in manually. I changed subjects 
> > for a while and
> > I am working on computing again at GMT -4 20:00 Jul 28
> > 
> > What I have accomplished so far is containerized with docker
> > grsync and rsync and forwarded it over x windows to cygwin.
> > It worked well, but they said i have to have a user both in
> > docker and cygwin with the same user and group id.
> > This is a step so that I can use rsync part of the app.
> > Then i can escalate with grsync gui with advanced commands of
> > rsync and sudo into a directory where i need elevated privileges.
> > I am also working on ssh with all this in the meantime but leaving
> > some of that off for now.
> > 
> > I am setting up this special container up as part of my "workbench" to work
> > on apache royale by spinning up docker containers with custom
> > PhP extensioins.
> > 
> > So, i just dont know at the moment about this mkpasswd and
> > what i did wrong.
> > 
> > I will keep after it.
> > 
> > P.S. i might mention that the AI gives a killer tutorial on
> > windows permissions. It teaches to do chmod on mingw
> > which doesnt have that command like cygwin via icalcs,
> > but so doens't Brian and he is not any AI ;-)
> > 
> > thanks for any help,
> > jim
> > 
> > Sent with Proton Mail secure email.
> > 
> > On Sunday, July 28th, 2024 at 7:11 PM, _ _ robainloy...@gmail.com wrote:
> > 
> > > Hey,
> > > 
> > > Welcome to the community!
> > > 
> > > To further help you with your problem, could you explain what are you 
> > > trying to do ?
> > > 
> > > For context, rpcd is a program who is responsible for Remote Procedure 
> > > Call on linux based system.
> > > 
> > > I'm not sure what did you ask Chat GPT but you should know that A.I. is 
> > > not a source of true.
> > > 
> > > Have a good day !
> > > 
> > > Le dim. 28 juil. 2024, 22:16, Jim McNamara via Cygwin cygwin@cygwin.com a 
> > > écrit :
> > > 
> > > > Hi the old chatgpt 3.5 thinks rpcd.exe is in inetutils package. Is it 
> > > > still available. It says I need it to run mkpasswd.
> > > > 
> > > > I ran the python script python3 ./rpc_bapahbah.py
> > > > 
> > > > it listens on 8000
> > > > 
> > > > but it cant install rpcd.exe when i get to that step with cygrunserv 
> > > > cmd.
> > > > 
> > > > I think it is because it is missing rpcd.exe as in

Fw: Re: rpcd.exe

[Jim McNamara via Cygwin]

Hi-

The AI really did go nuts like you said.
I just read the man page for that and
mkpassword -l isnt cutting it with setting up on win side first.

I dont know why it told me that. Crazy-town.

I will think of a command for a second..

I know what i will do i will create the user
in windows and then wipe out the context of the
/etc/passwd and then issue mkpasswd with the 
appropriate switch(es).

thanks






Sent with Proton Mail secure email.

--- Forwarded Message ---
From: Jim McNamara via Cygwin 
Date: On Sunday, July 28th, 2024 at 8:06 PM
Subject: Re: rpcd.exe
To: cygwin@cygwin.com 


> Hi -
>
> I dont want to give away your email by replying because I am
> afraid it won't obfuscate when I reply back.
>
> Thanks for the reply from you and the group!
>
> I'm trying to issue this command
>
> mkpasswd -l rsyncuser >> /etc/passwd
>
>
> i thought it would append a line to the end of my /etc/passwd file
> that would indicate that i now have a rsync user.
>
> it malfunctions and doesnt append anything.
>
> I might want to mention when i go to install from the installer at the
> end of the installer wizard i get this m\sg.
>
> Package: _/Unknown package
> xinit.sh exit code 3
>
> I dont know why mkpasswd is not working in this syntax.
> I am about to add it (passwd file entry) in manually. I changed subjects for 
> a while and
> I am working on computing again at GMT -4 20:00 Jul 28
>
> What I have accomplished so far is containerized with docker
> grsync and rsync and forwarded it over x windows to cygwin.
> It worked well, but they said i have to have a user both in
> docker and cygwin with the same user and group id.
> This is a step so that I can use rsync part of the app.
> Then i can escalate with grsync gui with advanced commands of
> rsync and sudo into a directory where i need elevated privileges.
> I am also working on ssh with all this in the meantime but leaving
> some of that off for now.
>
> I am setting up this special container up as part of my "workbench" to work
> on apache royale by spinning up docker containers with custom
> PhP extensioins.
>
> So, i just dont know at the moment about this mkpasswd and
> what i did wrong.
>
> I will keep after it.
>
> P.S. i might mention that the AI gives a killer tutorial on
> windows permissions. It teaches to do chmod on mingw
> which doesnt have that command like cygwin via icalcs,
> but so doens't Brian and he is not any AI ;-)
>
> thanks for any help,
> jim
>
> Sent with Proton Mail secure email.
>
> On Sunday, July 28th, 2024 at 7:11 PM, _ _ robainloy...@gmail.com wrote:
>
> > Hey,
> >
> > Welcome to the community!
> >
> > To further help you with your problem, could you explain what are you 
> > trying to do ?
> >
> > For context, rpcd is a program who is responsible for Remote Procedure Call 
> > on linux based system.
> >
> > I'm not sure what did you ask Chat GPT but you should know that A.I. is not 
> > a source of true.
> >
> > Have a good day !
> >
> > Le dim. 28 juil. 2024, 22:16, Jim McNamara via Cygwin cygwin@cygwin.com a 
> > écrit :
> >
> > > Hi the old chatgpt 3.5 thinks rpcd.exe is in inetutils package. Is it 
> > > still available. It says I need it to run mkpasswd.
> > >
> > > I ran the python script python3 ./rpc_bapahbah.py
> > >
> > > it listens on 8000
> > >
> > > but it cant install rpcd.exe when i get to that step with cygrunserv cmd.
> > >
> > > I think it is because it is missing rpcd.exe as in
> > >
> > > find / -name "rpcd.exe" equals zed.
> > >
> > > thanks,
> > > jim
> > >
> > > Sent with Proton Mail secure email.
> > >
> > > --
> > > Problem reports: https://cygwin.com/problems.html
> > > FAQ: https://cygwin.com/faq/
> > > Documentation: https://cygwin.com/docs.html
> > > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>
>
> --
> 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: rpcd.exe

[Jim McNamara via Cygwin]

Hi -

I dont want to give away your email by replying because I am
afraid it won't obfuscate when I reply back.

Thanks for the reply from you and the group!

I'm trying to issue this command

mkpasswd -l rsyncuser >> /etc/passwd

i thought it would append a line to the end of my /etc/passwd file
that would indicate that i now have a rsync user.

it malfunctions and doesnt append anything.

I might want to mention when i go to install from the installer at the
end of the installer wizard i get this m\sg.

Package: _/Unknown package
xinit.sh exit code 3

I dont know why mkpasswd is not working in this syntax.
I am about to add it (passwd file entry) in manually. I changed subjects for a 
while and
I am working on computing again at GMT -4 20:00 Jul 28

What I have accomplished so far is containerized with docker
grsync and rsync and forwarded it over x windows to cygwin.
It worked well, but they said i have to have a user both in
docker and cygwin with the same user and group id.
This is a step so that I can use rsync part of the app.
Then i can escalate with grsync gui with advanced commands of
rsync and sudo into a directory where i need elevated privileges.
I am also working on ssh with all this in the meantime but leaving
some of that off for now.

I am setting up this special container up as part of my "workbench" to work
on apache royale by spinning up docker containers with custom
PhP extensioins.

So, i just dont know at the moment about this mkpasswd and
what i did wrong.

I will keep after it.

P.S. i might mention that the AI gives a killer tutorial on
windows permissions. It teaches to do chmod on mingw
which doesnt have that command like cygwin via icalcs,
but so doens't Brian and he is not any AI ;-)

thanks for any help,
jim

Sent with [Proton Mail](https://proton.me/) secure email.

On Sunday, July 28th, 2024 at 7:11 PM, _ _  wrote:

> Hey,
>
> Welcome to the community!
>
> To further help you with your problem, could you explain what are you trying 
> to do ?
>
> For context, rpcd is a program who is responsible for Remote Procedure Call 
> on linux based system.
>
> I'm not sure what did you ask Chat GPT but you should know that A.I. is not a 
> source of true.
>
> Have a good day !
>
> Le dim. 28 juil. 2024, 22:16, Jim McNamara via Cygwin  a 
> écrit :
>
>> Hi the old chatgpt 3.5 thinks rpcd.exe is in inetutils package. Is it still 
>> available. It says I need it to run mkpasswd.
>>
>> I ran the python script python3 ./rpc_bapahbah.py
>>
>> it listens on 8000
>>
>> but it cant install rpcd.exe when i get to that step with cygrunserv cmd.
>>
>> I think it is because it is missing rpcd.exe as in
>>
>> find / -name "rpcd.exe" equals zed.
>>
>> thanks,
>> jim
>>
>> Sent with Proton Mail secure email.
>>
>> --
>> Problem reports: https://cygwin.com/problems.html
>> FAQ: https://cygwin.com/faq/
>> Documentation: https://cygwin.com/docs.html
>> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

-- 
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: calm not updating master x86_64/sha512.sum after setup updates

[Jon Turney via Cygwin-apps]

On 28/07/2024 00:06, Brian Inglis via Cygwin-apps wrote:

Hi folks,

After uploading packages, calm does not appear to be updating sha512.sum 
after updating setup.ini:


$ date -ud@`stat -c%Y ~/mirror/x86_64/sha512.sum`
2024 Jul 24 Wed 15:14:03

This is showing up in a script I run a minute or few later to check 
git/cygwin-packages/repo status, https://cygwin.com/pub/cygwin/x86_64/ 
timestamps, and download sha512.sum, setup.ini.sig, setup.xz.sig, 
setup.xz to check whether calm has updated every package as expected, 
checksums, and signatures, and it is okay to announce, using curl -I and 
a filter:


checking setup status https://cygwin.com/pub/cygwin/x86_64/sha512.sum:
     last-modified:  Wed, 24 Jul 2024 15:14:03 GMT
     content-length: 1278
checking setup status https://cygwin.com/pub/cygwin/x86_64/setup.ini:
     last-modified:  Sat, 27 Jul 2024 21:56:02 GMT
     content-length: 18169373
     content-type:   text/plain; charset=UTF-8


Uh, your expectations aren't well founded here.

The sha512.sum files aren't generated by calm, but by another process 
(which creates/updates them for the entire /var/ftp/pub/ area on sourceware)


I wish that calm could update these files but there are some 
isolation/permissions issues which prevent that currently. (or indeed, 
better still, have these checksums generated at the package build stage 
and passed through to setup.ini as an additional check on package 
integrity),

Re: DBD::mysql not reading host from config file

[ASSI via Cygwin]

Danny Rice via Cygwin writes:
>> it's more likely that the DB itself is the culprit
>
> In what way do you mean? As mentioned, it reads all the option data from
> the config file (except host) and connects without issue as long as you
> supply host in the dsn.

Again, the client library (not DBI) processes these statements, so if it
doesn't act on a host configured in your config file and you can
positively confirm that it actually did read the correct configuration
file and group within it, then the host key is most likely not getting
through to the module.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

-- 
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: Bug in GCC / libstdc++: Space character categorized as non-printable by std::ctype

[ASSI via Cygwin]

ASSI via Cygwin writes:
> This sounds like it might be a bug in newlib, so you should either
> report it there or else it would be the newlib integration for gcc.  In
> any case this needs to be fixed upstream.

The latter turns out to be the case, this is actually the same bug (and
will have the same fix) as:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104587

If you go to the trouble of actually filing a bug with gcc it would be
helpful to post the information here as well, so that somebody can
follow up on it:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115524


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

-- 
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: [:xdigit:] does not work with std::wstring in a Cygwin environment

[ASSI via Cygwin]

Hans-Bernhard Bröker writes:
> I've taken the liberty of filing this upstream as a GCC/libstdc++ issue.

Which has sat there for over two years without anybody looking at it
(please, if you file bugs at least let me know the bug number).  Great.

> The extremely condensed version of the issue is that libstdc++ builds
> by selecting config/os/newlib, but it does not pick
> --enable-clocale=newlib.

That works, thank you.  I'll have to figure out how to get the configury
use that setting automatically, then.

> Enabling the more global --with-newlib flag would do the latter for
> us, but it might have other, less desirable effects on top of that.

Hmm.  I gues I'll skip that for the time being.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

-- 
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: Package request fmt

[miloskomarcevic--- via Cygwin]

Hello,
Many thanks for looking into it.
We want to switch exiv2 to C++20 std::format, and Cygwin won't ship GCC 13 for 
a while...
https://github.com/Exiv2/exiv2/pull/2769

Best regards,Milos 
 
  On Sat, 27 Jul 2024 at 15:51, ASSI wrote:   
miloskomarcevic--- via Cygwin writes:
> Please package https://github.com/fmtlib/fmt
> See https://repology.org/project/fmt/versions

The library (11.0.2) compiles ootb with a minimal cygport file.

> Thanks, and best regards,Milos & the Exiv2 team

What do you need this for?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
  

-- 
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: Package request fmt

[Brian Inglis via Cygwin]

On 2024-07-27 07:51, ASSI via Cygwin wrote:

miloskomarcevic--- via Cygwin writes:

Please package https://github.com/fmtlib/fmt
See https://repology.org/project/fmt/versions


Provides C++ templates and methods for customizable, fast, robust, safe 
Python-like I/O format support alternative to iostreams and cstdio, using the 
Dragonbox algorithm for correctly rounded, fast, shortest floating point integer 
decomposition.



The library (11.0.2) compiles ootb with a minimal cygport file.


Thanks, and best regards,Milos & the Exiv2 team


What do you need this for?


Suggest perhaps:

- exiv2 graphics metadata r/w package speedup including for Gnome and KDE?

- leverage clang-tidy modernize-use-std-print to replace legacy I/O?

- Cygwin exiv2 maintainer would be interested in working with exiv2 team to help 
them become Cygwin package maintainers for libfmt and exiv2?


- and correct typo "Exiv" for Exif in exiv2 sdesc, ldesc? ;^>

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: Package request fmt

[ASSI via Cygwin]

miloskomarcevic--- via Cygwin writes:
> Please package https://github.com/fmtlib/fmt
> See https://repology.org/project/fmt/versions

The library (11.0.2) compiles ootb with a minimal cygport file.

> Thanks, and best regards,Milos & the Exiv2 team

What do you need this for?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

-- 
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: DBD::mysql not reading host from config file

[Danny Rice via Cygwin]

>
> it's more likely that the DB itself is the culprit

In what way do you mean? As mentioned, it reads all the option data from
the config file (except host) and connects without issue as long as you
supply host in the dsn. The cygwin command line mysql command reads all the
options, including host, from the config file. The database tested on both
cygwin and linux was the same database. I also did the same tests on two
completely independent hosts/databases.


> examples of this sort of DSN I've seen reverse the two keys

This doesn't change anything.


> versions available in Cygwin, which are almost certainly older than the
> ones on Linux

This has been an issue since at least 2020. The current cygwin DBD::mysql
is version is 4.052. The one I tested on linux is currently 4.046.


On Sat, Jul 27, 2024 at 2:50 AM ASSI via Cygwin  wrote:

> Danny Rice via Cygwin writes:
> > With a dsn like
> >
> > $dsn =
> >
> "dbi:mysql:mysql_ssl=1;mysql_read_default_file=test.cnf;mysql_read_default_group=test_group";
> > $dbh = DBI->connect($dsn);
> >
> > seemingly fails to read the host from [test_group] in test.cnf. Adding a
> > valid host=host_name to the $dsn succeeds in reading the user, password
> etc
> > from test.cnf and the connection succeeds
> >
> > This has been an issue since at least 2020 and I've had to just specify
> the
> > host in the $dsn on cygwin.
>
> I fail to see how this can be caused by DBD::mysql, so it's more likely
> that the DB itself is the culprit (you might want to check if that's a
> known issue with the versions available in Cygwin, whilch are almost
> certainly older than the ones on Linux).  Anyway, I'll just note that
> the examples of this sort of DSN I've seen reverse the two keys:
>
> $dsn = "dbi:mysql:mysql_ssl=1;"
>  . "mysql_read_default_group=test_group;"
>  . "mysql_read_default_file=test.cnf";
>
> so maybe give that a try.
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> Wavetables for the Terratec KOMPLEXER:
> http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
>
> --
> 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: Bug in GCC / libstdc++: Space character categorized as non-printable by std::ctype

[ASSI via Cygwin]

Kristian Spangsege via Cygwin writes:
> In C++, a space character is reported as non-printable by
> `std::ctype` in the "C" locale (the only locale supported by
> `std::ctype`). In other words, the following expression evaluates to
> `false`:
>
> ctype.is(std::ctype_base::print, ctype.widen(' '))
>
> where `ctype` is obtained by `std::use_facet>(loc)` and
> `loc` is the "C" locale.
>
> It should have been evaluated to `true` because a space character is
> required by the C++ standard to be categorized as printable.
>
> Also, it is reported as printable by `std::iswprint(int ch)`.
>
> Also, the non-wide space character is reported as printable, i.e,
> `std::use_facet>(loc)::is(std::ctype_base::print, ' ')` is
> `true`.
>
> Also, `ctype.is(std::ctype_base::print, ctype.widen(' '))` is `true` with
> MinGW, with GCC on Linux, and with Visual Studio.

This sounds like it might be a bug in newlib, so you should either
report it there or else it would be the newlib integration for gcc.  In
any case this needs to be fixed upstream.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

-- 
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: DBD::mysql not reading host from config file

[ASSI via Cygwin]

Danny Rice via Cygwin writes:
> With a dsn like
>
> $dsn =
> "dbi:mysql:mysql_ssl=1;mysql_read_default_file=test.cnf;mysql_read_default_group=test_group";
> $dbh = DBI->connect($dsn);
>
> seemingly fails to read the host from [test_group] in test.cnf. Adding a
> valid host=host_name to the $dsn succeeds in reading the user, password etc
> from test.cnf and the connection succeeds
>
> This has been an issue since at least 2020 and I've had to just specify the
> host in the $dsn on cygwin.

I fail to see how this can be caused by DBD::mysql, so it's more likely
that the DB itself is the culprit (you might want to check if that's a
known issue with the versions available in Cygwin, whilch are almost
certainly older than the ones on Linux).  Anyway, I'll just note that
the examples of this sort of DSN I've seen reverse the two keys:

$dsn = "dbi:mysql:mysql_ssl=1;"
 . "mysql_read_default_group=test_group;"
 . "mysql_read_default_file=test.cnf";

so maybe give that a try.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

-- 
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: Advice sought: Cygwin or gcc or ???: unable to figure out odd gcc error message [WITHDRAWN]

[ASSI via Cygwin]

Richard via Cygwin writes:
> As anticipated, after further investigation, it is NOT a
> Cygwin-related issue, hence I withdraw my request with apologies for
> noise.

You didn't say what you are trying to achieve, but since the exercise
seems to be to learn something about Linux kernel (module) programming,
you could save yourself some bother by doing this on an actual Linux
system, in a Linux VM or even in Windows' subsystem for Linux.  While
you might have pacified the Cygwin compiler for now by changing sone
options, you would really need to have a proper cross-compiler to Linux
for any of this to result in an actual working Linux kernel module.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

-- 
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: Rewriting the FIFO code

[Jameson Nash via Cygwin]

I am hopping in late to this conversation, after working on debugging a
confusing issue where my NamedPipe stopped working reliably after being
passed to a cygwin program, where I believe it used to work okay with older
versions of cygwin. I just want to point out that the current flag being
used (Win32 calls it PIPE_NOWAIT) is documented as do-not-use (e.g.
https://devblogs.microsoft.com/oldnewthing/20110114-00/?p=11753) as it
interferes with the reliable execution of other programs that are using the
same pipe end, and that do not want to use the inefficient busy-wait
polling that cygwin's implementation does. As the documentation points out,
there is no way to recover correct behavior of OVERLAPPED while the flag is
enabled. By contrast, however, with PIPE_WAIT mode, it is possible to
implement non-blocking IO, including select, with OVERLAPPED operations, by
using ReadFile (with a size of 0) followed by PeekNamedPipe (if you want to
estimate the number of bytes to read) followed by a ReadFile of that number
of bytes (or an estimated number) followed by an immediate CancelIOEx (or
CancelIO on older platforms). I can post some example code from libuv if
that would be helpful? Removing this `PIPE_WAIT` change would eventually
also allow fixing the implementation of `select` in cygwin to actually use
event-driven notifications for readable instead of emulating it with a slow
poll loop as is done now (https://cygwin.com/cygwin-ug-net/highlights.html).

Thanks!

-jameson

post note: I also wrote up some of this in
https://github.com/libuv/libuv/issues/4467 so that google hopefully indexes
it in case anyone manages to run across the same problem in nodejs and
searches for related issues, but I only wrote a few details there of how
libuv might be impacted by this, without the specifics of how cygwin could
be fixed

second post note: sorry if this is a duplicate email, but I tried to send
it yesterday and forgot to enable plain text mode so it was first sent as
html and didn't seem to have gotten through to the list

-- 
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: double-fork issue on Windows on ARM64

[Jeremy Drake via Cygwin]

Replying to cygwin@cygwin.com list due to determination that this thread
was incorrectly sent to cygwin-developers.  I apologize for the
inconvenience.

On Tue, 21 May 2024, Jeremy Drake wrote:

> On Mon, 20 May 2024, Jeremy Drake wrote:
>
> > Today, I was attempting to look at the TerminateThread situation.  The
> > call in question comes from the attempt to terminate the wait_thread of a
> > chld_procs entry.  I noticed elsewhere in cygwin code (flock.cc) that
> > CancelSynchronousIo was being called, and that stood out to me because
> > chances are that the wait thread (if running) is going to be blocked in
> > ReadFile.  I am testing with the following hack, and so far have not seen
> > a hang
>
>
> I left my reproducer running with this hack, and I did eventually get an
> error exit from the intermediate subprocess, which seems to have been a
> signal 11 (if I'm reading the status from waitpid correctly).
>
> What I noticed today is that in pinfo.cc, near the end of proc_waiter, it
> sets vchild.wait_thread = NULL;.  If my reading of this is correct, that
> does nothing useful, because vchild is a stack variable there and the
> function returns soon after.  I that what that *intended* to do was to
> NULL out the wait_thread pointer that would be checked in proc_terminate,
> but there's no guarantee that the entry in chld_procs is in the same place
> at the end of proc_waiter as it was at the start (so arg may point to
> some other pinfo entirely).
>
> Does any of this make any sense, or am I barking up the wrong tree here?

I tried adding a new "procstuff" enum member and case to proc_subproc to
loop through all chld_procs and NULL out wait_threads that equal the
pointer passed in as "val"  This was called from the proc_waiter before
it NULLed out its local copy of vchild.  This did not help.

I am still fairly sure that somehow this terminate_thread call is where
the hang is happening, but I'm not seeing why.  This is definitely not
helped by the fact that debuggers cannot attach to the main thread for
some reason.

-- 
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: Rewriting the FIFO code

[Jameson Nash via Cygwin]

I am hopping in late to this conversation, after working on debugging a
confusing issue where my NamedPipe stopped working reliably after being
passed to a cygwin program, where I believe it used to work okay with older
versions of cygwin. I just want to point out that the current flag being
used (Win32 calls it PIPE_NOWAIT) is documented as do-not-use (e.g.
https://devblogs.microsoft.com/oldnewthing/20110114-00/?p=11753) as it
interferes with the reliable execution of other programs that are using the
same pipe end, and that do not want to use the inefficient busy-wait
polling that cygwin's implementation does. As the documentation points out,
there is no way to recover correct behavior of OVERLAPPED while the flag is
enabled. By contrast, however, with PIPE_WAIT mode, it is possible to
implement non-blocking IO, including select, with OVERLAPPED operations, by
using ReadFile (with a size of 0) followed by PeekNamedPipe (if you want to
estimate the number of bytes to read) followed by a ReadFile of that number
of bytes (or an estimated number) followed by an immediate CancelIOEx (or
CancelIO on older platforms). I can post some example code from libuv if
that would be helpful? Removing this `PIPE_WAIT` change would eventually
also allow fixing the implementation of `select` in cygwin to actually use
event-driven notifications instead of emulating them with a slow loop as is
done now (https://cygwin.com/cygwin-ug-net/highlights.html).

Thanks!

-jameson

post note: I also wrote up some of this in
https://github.com/libuv/libuv/issues/4467 so that google hopefully indexes
it in case anyone manages to run across the same problem in nodejs and
searches for related issues, but I only wrote a few details there of how
libuv might be impacted by this, without the specifics of how cygwin could
be fixed

-- 
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: Changing Default SSH Directory to E:\ in Cygwin

[Andrey Repin via Cygwin]

Greetings, Adrian Breten!

> Hello,

> I am seeking assistance with configuring Cygwin to change the default
> directory when I SSH into my Windows machine.

> Currently, I have Cygwin installed on a Windows server 2016 machine on
> E:\Cygwin64. When I SSH into this machine, the default directory is set to
> `C:\`. However, I would like to change this so that I land in the `E:\` drive 
> instead.

> I have tried looking into SSH configuration files and user profiles but
> have not been successful in making this change. Could you please provide 
> guidance on how to achieve this?

> Any help would be greatly appreciated.

1. Make sure you are connecting to Cygwin's SSH, not Windows one.
This is likely what happens as Cygwin would have put you into your home
directory instead.


-- 
With best regards,
Andrey Repin
Wednesday, July 24, 2024 15:19:37

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: Read Windows event log from via Cygwin /proc, /dev, ...?

[Brian Inglis via Cygwin]

On 2024-07-23 18:07, Dan Shelton via Cygwin wrote:

Does Cygwin have a script API to read the Windows event log, maybe via /proc
or /dev?
Install package syslog-ng and set up Cygwin syslog, then set up other processes 
that can, to write to syslog, and read that at /var/log/syslog.


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: Parse output of "net use", but language varies - force language for "net use"?

[Bill Stewart via Cygwin]

On Mon, Jul 22, 2024 at 12:50 PM Csaba Ráduly wrote:

Plus, it sounds like a global solution to a local problem:
> https://devblogs.microsoft.com/oldnewthing/20081211-00/?p=19873
>

Good point. Parsing 'net use' output is not the correct way, or even a very
good way, to get the requested information.

Bill

-- 
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: Parse output of "net use", but language varies - force language for "net use"?

[Csaba Ráduly via Cygwin]

On 21/07/2024 05:57, Thomas Wolff via Cygwin wrote:



Am 21.07.2024 um 01:54 schrieb Takashi Yano via Cygwin:

On Sat, 20 Jul 2024 15:44:17 +0200
Mark Liam Brown wrote:

I am trying to parse the output of "net use" in a bash script, but hit
a roadblock:
The output of "net use" changes with the language of the system
(English, Danish, French, ...), so parsing becomes nearly impossible

How can I force the language used by "net use" to English, even if the
system default language is Danish or French?

Did you try
chcp.com 437

That could change the character encoding, for some (older) programs, not
the language.


Plus, it sounds like a global solution to a local problem: 
https://devblogs.microsoft.com/oldnewthing/20081211-00/?p=19873


Csaba

--
Life is complex, with real and imaginary parts.


--
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: Parse output of "net use", but language varies - force language for "net use"?

[Bill Stewart via Cygwin]

On Sat, Jul 20, 2024 at 8:57 AM Mark Liam Brown wrote:

Basically I need every bit of information out of "net use", "net
> config", "net statistics", "net view" and so on, parse it in bash or
> perl, process it in bash, and output it in JSON format from the bash
> script for our (Linux-based) admin report interface.
>

The 'net use' command output is not designed for parsing. For example, the
'net user' command outputs usernames in separate columns, and truncates
usernames that are longer than some number of characters (I forget how
many), so it's not a reliable source of truth anyway.

You will need to get the information a different way. As has been
mentioned, on the Windows platform, the best approach would be to use
PowerShell rather than trying to perform parsing on output that's not
designed to be parsed in the first place.

Bill

-- 
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: CYGPORT not setting CMAKE_SYSTEM_PROCESSOR when cross compiling with aarch64-w64-mingw32.

[Carlo B. via Cygwin]

Hello,
thank you for your reply.
The patch is a good start to me.
However, I think that it would be better to remove the error if CHOST
or CTARGET include something different from x86_64, i686 or aarch64.
Otherwise, you won't be able to cross compile anything with CMake,
except for those CPUs.
Instead, in my opinion it would be better to return an empty string,
to be assigned to a variable at the calling function.
So, if that variable will not empty, then CMAKE_SYSTEM_PROCESSOR will
be appended to crossargs with that value.
Otherwise, CMAKE_SYSTEM_PROCESSOR won't be added to crossargs and it
will work as it worked until now.
According to the documentation:
https://cmake.org/cmake/help/latest/variable/CMAKE_HOST_SYSTEM_PROCESSOR.html
when it is not cross compiling, CMake assignes the return value of
"uname" to CMAKE_SYSTEM_PROCESSOR.
So, some of the possible values of that variable could be:
alpha
arc
arm
aarch64_be (arm64 big endian)
aarch64 (arm64)
armv8b (arm64 compat big endian)
armv8l (arm64 compat little endian)
blackfin
c6x
cris
frv
h8300
hexagon
ia64
m32r
m68k
metag
microblaze
mips (native or compat)
mips64 (mips)
mn10300
nios2
openrisc
parisc (native or compat)
parisc64 (parisc)
ppc (powerpc native or compat)
ppc64 (powerpc)
ppcle (powerpc native or compat little endian)
ppc64le (powerpc little endian)
s390 (s390x compat)
s390x
score
sh
sh64 (sh)
sparc (native or compat)
sparc64 (sparc)
tile
unicore32
i386 (x86)
i686 (x86 compat)
x86_64 (x64)
xtensa
If there will be the need to add some of them in the future, somebody
may add them.
Perhaps, it would be useful to add also this information to the patch
as a comment, just for reference.
Thank you very much for your time.

Sincerely,

Carlo Bramini.

Il giorno sab 20 lug 2024 alle ore 20:18 Jon Turney
 ha scritto:
>
> On 19/07/2024 09:08, Carlo B. via Cygwin wrote:
> > Hello,
> >
> > GCC development branch includes experimental support Windows on ARM64
> > (WOA), which will be officially released next year with version 15, at
> > least according to latest news.
> > So, I compiled it and I created a number of packages for CYGWIN
> > including binutils, gcc, mingw runtime and several libraries, not
> > released yet to my repository.
> > Although the "aarch64-w64-mingw32" target is still experimental, I
> > have to say that this cross compiler worked very well, at least until
> > now.
>
> Great work! We'd certainly welcome and appreciate your help getting
> packages for this into our repository, also.
>
> > However, some problems appear because there are some thirdy party
> > tools not expecting to have mingw combined with something different
> > than i686 or x86_64.
> > For example, it is impossible to create a shared library when using
> > libtool, more details could be found here:
> > https://savannah.gnu.org/support/?111081
>
> Huh. I guess someone should fix that, then!
>
> I think for a start, the regex around line 5724 in libtool (near the
> comment about keeping it in sync with _LT_CHECK_MAGIC_METHOD) needs
> updating to match arm64 archives...
>
> > For this reason, you have to use CMake or other alternative tools
> > instead of autotools.
> >
> > Actually, another problem can happen when creating the packages for
> > CYGWIN with CYGPORT utility.
> > For example, I tried to build a noarch package of libpng for CYGWIN,
> > by using the new aarch64-w64-mingw32.
> > I have used CMake to bypass the above trouble with libtool.
> > Unfortunately, the build process still fails because it didn't compile
> > the sources for adding the functions with NEON acceleration.
> > The cause of the problem is the variable CMAKE_SYSTEM_PROCESSOR that is 
> > empty.
> > This is not a bug of CMake, because CMAKE_SYSTEM_PROCESSOR is
> > typically set into CMAKE_TOOLCHAIN_FILE by the user when cross
> > compiling.
> > At the moment, I bypassed the trouble by adding
> > "-DCMAKE_SYSTEM_PROCESSOR=aarch64" to CYGCMAKE_ARGS into my script.
> > I gave a look into /usr/share/cygport/cygclass/cmake.cygclass and it
> > seems to me that there is nothing for setting the CPU type.
> > Perhaps it would be worth to add support for setting
> > CMAKE_SYSTEM_PROCESSOR into cmake.cygclass, by checking the content of
> > ${CTARGET}, if it exists with a known CPU.
>
> Interesting.
>
> I took a look and there are several existing packages which have been
> cross-built for x86 and x86_64 MinGW using cmake, so either it seems
> this hasn't yet appeared as a problem for those arches and/or packages...
>
> It's not terribly clear what the valid values are for that cmake
> variable, and what it controls, but the answer [1] makes it seem like
> it's not a lot:
>
> [1]
> https://stackoverflow.com/questions/70475665/what-are-the-possible-values-of-cmake-system-processor
>
> But yeah, this seems eminently fixable in cygport, 

Re: setup: parameter stickiness

[Thomas Wolff via Cygwin-apps]

Am 21.07.2024 um 21:46 schrieb Jon Turney:

On 21/07/2024 16:21, Thomas Wolff via Cygwin-apps wrote:

Hi,
if I have two cygwin installations, e.g. C:\cygwin64 and
C:\cygwin64test, the setup program is sticky about its root directory,
local package directory, and download sites presettings. They tend to
stay at the second installation even after updating the first one, so
that I have to fix it manually every time I update my main installation
(unless I fiddle them out from the registry, or fix them via
command-line).
Would be good to remember the last-in-use values.


That is kind of how it's supposed to work:

The last-used root directory is stored in the registry

All other settings are read from /etc/setup/setup.rc in the selected
Cygwin root directory, if it exists.

If that doesn't seem to be what you are seeing, maybe you could give a
series of steps to reproduce, clearly stating what behavior you get
that is unexpected.

It's not, indeed. Having used setup regularly (to C:\cygwin64), I once
installed a second one (C:\cygwintest) and setup got stuck to that
directory, despite later updates to C:\cygwin64. Happened on more than
one machine. However, I did also use older versions of setup in various
combinations, like to C:\cygwin32 or C:\cygwinxp64. Maybe those older
versions are getting sticky in the registry in a way that confuses
current setup?



You might also find the setup option '--no-write-registry' useful to
stop your test installation from writing it's root directory into the
registry.


Thanks, I'll do that.
Thomas

Re: Parse output of "net use", but language varies - force language for "net use"?

[Andrey Repin via Cygwin]

Greetings, Thomas Wolff!

> Am 21.07.2024 um 01:54 schrieb Takashi Yano via Cygwin:
>> On Sat, 20 Jul 2024 15:44:17 +0200
>> Mark Liam Brown wrote:
>>> I am trying to parse the output of "net use" in a bash script, but hit
>>> a roadblock:
>>> The output of "net use" changes with the language of the system
>>> (English, Danish, French, ...), so parsing becomes nearly impossible
>>>
>>> How can I force the language used by "net use" to English, even if the
>>> system default language is Danish or French?
>> Did you try
>> chcp.com 437
> That could change the character encoding, for some (older) programs, not
> the language.

You'd be surprised…

>> or something like that?


-- 
With best regards,
Andrey Repin
Monday, July 22, 2024 00:09:30

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: Parse output of "net use", but language varies - force language for "net use"?

[Andrey Repin via Cygwin]

Greetings, Mark Liam Brown!

> I am trying to parse the output of "net use" in a bash script, but hit
> a roadblock:
> The output of "net use" changes with the language of the system
> (English, Danish, French, ...), so parsing becomes nearly impossible

> How can I force the language used by "net use" to English, even if the
> system default language is Danish or French?

chcp 65001

Make a symlink to chcp.com from /usr/local/bin/chcp for easier access.
Forcing unicode console CP makes many system programs (netsh, net, route,
ipconfig of what I tried) switch to what appears to be an equivalent of
C.UTF-8 locale, making their output consistent across different OS
localizations.

But frankly, if you really need automation in windows, PowerShell if here
to help. You would be able to do everything in a single, reasonable portable
script, and not need to involve Cygwin at all.


-- 
With best regards,
Andrey Repin
Monday, July 22, 2024 00:01:16

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: noacl no longer effective under /cygdrive. Still works in other locations

[Andrey Repin via Cygwin]

Greetings, ilya Basin!

> For several years I had this in my /etc/fstab.d/$USER

> C: /cygdrive/c none binary,noacl,posix=0,user 0 0

Unless you have a global /cygdrive override set to noacl as well, I have my
reservation about configuration.

> I switched from Cygwin x86 to x64 recently and I noticed that even if
> `mount` prints this:

> $ mount | grep C:
> C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
> C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
> C:/cygwin64 on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user)

> noacl seems to be ineffective:

> basin@basin /cygdrive/c/63/c
> $ rm -f aaa bbb; touch aaa; cmd /c "echo.>bbb"

> basin@basin /cygdrive/c/63/c
> $ cacls bbb
> C:\63\c\bbb BUILTIN\:(ID)F
> NT AUTHORITY\:(ID)F
> BUILTIN\:(ID)R
> NT AUTHORITY\ :(ID)C

> $ cacls aaa
> C:\63\c\aaa NULL SID:(DENY)(special access:)
>  READ_CONTROL
>  FILE_WRITE_EA
>  FILE_EXECUTE
>  FILE_DELETE_CHILD
> ...

> There's no suspicious $CYG* env var. I also tried to kill all cygwin
> processes and umount everything manually. I don't see what's wrong.

> Had to change the parent mount point to /cygnoacl in /etc/fstab.d/$USER and
> from there it works.

Just set /cygdrive to noacl. In my experience, this is a safer choice for
cross-system interaction.


-- 
With best regards,
Andrey Repin
Sunday, July 21, 2024 23:59:06

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: setup: parameter stickiness

[Jon Turney via Cygwin-apps]

On 21/07/2024 16:21, Thomas Wolff via Cygwin-apps wrote:

Hi,
if I have two cygwin installations, e.g. C:\cygwin64 and
C:\cygwin64test, the setup program is sticky about its root directory,
local package directory, and download sites presettings. They tend to
stay at the second installation even after updating the first one, so
that I have to fix it manually every time I update my main installation
(unless I fiddle them out from the registry, or fix them via command-line).
Would be good to remember the last-in-use values.


That is kind of how it's supposed to work:

The last-used root directory is stored in the registry

All other settings are read from /etc/setup/setup.rc in the selected 
Cygwin root directory, if it exists.


If that doesn't seem to be what you are seeing, maybe you could give a 
series of steps to reproduce, clearly stating what behavior you get that 
is unexpected.


You might also find the setup option '--no-write-registry' useful to 
stop your test installation from writing it's root directory into the 
registry.

Re: setup: --prune-install appears to be broken

[Jon Turney via Cygwin]

On 20/06/2024 14:36, David McFarland via Cygwin wrote:

Sorry for the delay in replying to this.



If I do a base install to a new root:

 setup-x86_64.exe --root "$(cygpath -wa .cygtest)" --no-admin \
 --no-shortcuts --no-replaceonreboot --no-version-check \
 --prune-install --verbose

And then run the same install again, I get:


[...]


 Can't happen.  No packagemeta for base

The "Can't happen" error results in all following transactions being skipped:

 // Can't happen - throw an exception?
 {
   Log (LOG_PLAIN) << "Can't happen.  No packagemeta for "
   << pv.Name() << endLog;
   return;
 }


Yeah, that's clearly a bug of some sort.

At the very least, if we're not going to terminate there, it probably 
should be a 'continue' rather than a 'return', so we actually process 
the rest of the transactions.



This results in setup always showing no pending changes, even if you
have installed additional packages that should be pruned by
--prune-install, or if setup.ini has different contents.

The problem seems to be that we use SOLVER_ERASE jobs to remove all
non-base installed packages, and they take precedence over keeping the
pseudo-package 'base' installed.


There's something else going on here I don't understand as there are 
other base or basedep packages in that list of things it wants to erase.



Making the erase jobs weak seems to solve the problem:

diff --git a/libsolv.cc b/libsolv.cc
index 3f083a4..95f21a2 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -850,7 +850,7 @@ SolverSolution::tasksToJobs(SolverTasks , updateMode 
update, Queue )
queue_push2(, SOLVER_INSTALL | SOLVER_SOLVABLE_PROVIDES, 
sv.name_id());
break;
  case SolverTasks::taskUninstall:
-  queue_push2(, SOLVER_ERASE | SOLVER_SOLVABLE, sv.id);
+  queue_push2(, SOLVER_ERASE | SOLVER_WEAK | SOLVER_SOLVABLE, 
sv.id);
break;
  case SolverTasks::taskReinstall:
// we don't know how to ask solver for this, so we just add the 
erase

However, I'm not sure if this is a good idea. Perhaps it should only be


Thanks very much for attempting to fix this and providing a patch.

But, yeah, that seems like probably the wrong approach.

(for e.g. seems like that's going make us silently ignore removing X at 
the same time as installing something else which depends on X, when we 
really should to indicate a conflict..)



--
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: Aborting Cygwin setup in unattended modes

[Jon Turney via Cygwin]

On 22/06/2024 07:45, David Allsopp via Cygwin wrote:

If Cygwin's setup requires input (for example, to select a mirror),
with --quiet-mode hidden it simply terminates (there's no apparent
exit status or message, though).

With --quiet-mode noinput, Cygwin setup sits at the appropriate
dialog, but it's of course non-responsive.

Would it be possible in these situations for Cygwin to abort,
preferably with a non-zero exit code?

The background to this was running Cygwin setup in GitHub Actions (so
UI not visible), _without_ specifying --site, where the Cygwin
installation had been restored by actions/cache but not the registry
setting in HKLM\SOFTWARE\Cygwin\setup meaning that setup could not
find setup.rc and consequently determine the last-used mirror. The GUI
therefore invisibly froze at mirror selection.

That issue has obviously been fixed, but it would seem sensible that
Cygwin's setup doesn't ever display a dialog _requiring_ input where
all that input has been disabled!


Thanks for reporting this!

Oh, this is a weird one:

The '--quiet-mode' implentation is all rather ad-hoc, and so there's 
been no comprehensive audit of the setup code to ensure that all the 
possible places where we potentially stop for interaction are instead 
handled automatically.


But, this is a deliberate choice in some ancient logic, which 
deliberately drops back into attended mode, just in this one specific 
place (when there are no package repository site URLs specified).


Since this seems counter-intuitive and completely unhelpful, I've 
applied a change as you suggest, so we'll stop with an error instead.



--
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: setup.exe: Improvements of DPI handling

[Jon Turney via Cygwin]

On 07/07/2024 03:46, Yang Yu Lin via Cygwin wrote:

When running setup on my device (Windows 11, connected with 2 screens
which use different DPI revolutions), the setup appears bluury on my
secondary screen (not on the primary screen).

Because current setup.exe.manifest just set the dpiAware element,
which causes the setup cannot handle different DPI on different
screen, the current solution is to add dpiAwareness element and
change the value of dpiAware to true/pm to handle DPI in per-moniter
mode (patch attached). More infomation can be found at
https://learn.microsoft.com/windows/win32/sbscs/application-manifests#dpiAware
and
https://learn.microsoft.com/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows


Yes, this is clearly needed. Thanks very much for the patch, I have 
applied it.



 Also, the necessary options to use the Unicode version of the
Windows API functions is also added in another patch to avoid
localized message is incorrectly encoded when using the --lang
option.


Uh, can you explain a bit more what specific problem this fixes.

Because we don't make use of TCHAR, and internally make a lot of use of 
char strings containing UTF-8 encoded unicode, I'm not sure that 
switching to *W API variants everywhere is a good idea (and have been 
trying to avoid it so far).



--
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: Parse output of "net use", but language varies - force language for "net use"?

[Takashi Yano via Cygwin]

On Sun, 21 Jul 2024 05:57:10 +0200
Thomas Wolff wrote:
> Am 21.07.2024 um 01:54 schrieb Takashi Yano via Cygwin:
> > On Sat, 20 Jul 2024 15:44:17 +0200
> > Mark Liam Brown wrote:
> >> I am trying to parse the output of "net use" in a bash script, but hit
> >> a roadblock:
> >> The output of "net use" changes with the language of the system
> >> (English, Danish, French, ...), so parsing becomes nearly impossible
> >>
> >> How can I force the language used by "net use" to English, even if the
> >> system default language is Danish or French?
> > Did you try
> > chcp.com 437
> That could change the character encoding, for some (older) programs, not
> the language.

You are right. However, in Japanese environment, net use command
output Japanese message on CP932 and English message on CP437.

So, I think that this might change the message language even in
Danish, French or Germany environment.

-- 
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: Parse output of "net use", but language varies - force language for "net use"?

[Thomas Wolff via Cygwin]

Am 21.07.2024 um 01:54 schrieb Takashi Yano via Cygwin:

On Sat, 20 Jul 2024 15:44:17 +0200
Mark Liam Brown wrote:

I am trying to parse the output of "net use" in a bash script, but hit
a roadblock:
The output of "net use" changes with the language of the system
(English, Danish, French, ...), so parsing becomes nearly impossible

How can I force the language used by "net use" to English, even if the
system default language is Danish or French?

Did you try
chcp.com 437

That could change the character encoding, for some (older) programs, not
the language.

or something like 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: Parse output of "net use", but language varies - force language for "net use"?

[Takashi Yano via Cygwin]

On Sat, 20 Jul 2024 15:44:17 +0200
Mark Liam Brown wrote:
> I am trying to parse the output of "net use" in a bash script, but hit
> a roadblock:
> The output of "net use" changes with the language of the system
> (English, Danish, French, ...), so parsing becomes nearly impossible
> 
> How can I force the language used by "net use" to English, even if the
> system default language is Danish or French?

Did you try
chcp.com 437
or something like that?

-- 
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: Parse output of "net use", but language varies - force language for "net use"?

[gs-cygwin.com--- via Cygwin]

On Sat, Jul 20, 2024 at 04:56:56PM +0200, Mark Liam Brown via Cygwin wrote:
> On Sat, Jul 20, 2024 at 4:31 PM Bill Stewart via Cygwin
>  wrote:
> >
> > On Sat, Jul 20, 2024 at 7:45 AM Mark Liam Brown via Cygwin wrote:
> >
> > I am trying to parse the output of "net use" in a bash script, but hit
> > > a roadblock:
> > > The output of "net use" changes with the language of the system
> > > (English, Danish, French, ...), so parsing becomes nearly impossible
> > >
> > > How can I force the language used by "net use" to English, even if the
> > > system default language is Danish or French?
> > >
> >
> > This sounds like an XY problem[1] to me
> >
> > What is the goal you're trying to accomplish? Enumerate existing
> > connections? Get drive mappings?
> 
> Basically I need every bit of information out of "net use", "net
> config", "net statistics", "net view" and so on, parse it in bash or
> perl, process it in bash, and output it in JSON format from the bash
> script for our (Linux-based) admin report interface.
> 
> Mark
> -- 
> IT Infrastructure Consultant
> Windows, Linux

Hello Mr Consultant.  You seem to have a NIH syndrome that you are
approaching your problem as if you are the first person to ever do this,
and therefore you are writing everything yourself, from scratch.
Do you honestly think you are the first person who would like the info
displayed by 'net use' in some form of structured data?

Using Powershell and its formatting options, as posted in Henry's
response, is probably the best answer *for scripting*.

If using Perl *for scripting*, there are numerous Perl modules such as
https://metacpan.org/pod/Win32::NetResource

If you were to try using a search engine more effectively, you might also
find C++ libraries or C# APIs to access all that info as structured data,
instead of trying to parse the `net use` command line output using bash,
and trying to fight with the registry settings to affect `net use`
display of the 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: Parse output of "net use", but language varies - force language for "net use"?

[Brian Inglis via Cygwin]

On 2024-07-20 08:56, Mark Liam Brown via Cygwin wrote:

On Sat, Jul 20, 2024 at 4:31 PM Bill Stewart via Cygwin
 wrote:


On Sat, Jul 20, 2024 at 7:45 AM Mark Liam Brown via Cygwin wrote:

I am trying to parse the output of "net use" in a bash script, but hit

a roadblock:
The output of "net use" changes with the language of the system
(English, Danish, French, ...), so parsing becomes nearly impossible

How can I force the language used by "net use" to English, even if the
system default language is Danish or French?



This sounds like an XY problem[1] to me

What is the goal you're trying to accomplish? Enumerate existing
connections? Get drive mappings?


Basically I need every bit of information out of "net use", "net
config", "net statistics", "net view" and so on, parse it in bash or
perl, process it in bash, and output it in JSON format from the bash
script for our (Linux-based) admin report interface.


Hi Mark,

Two suggestions for getting the information you need:

- set up a local user admin account locale with English language and regional 
settings


- look into registry virtualization, where you can temporarily replace part of 
the user registry with a saved hive, containing the keys to be changed.


You can also make these changes with group policy editor.

Below is the Cygwin view of significant user locale registry entries (easier to 
use with path lookup and completion); you can also use Windows `reg query`:


$ regtool list -v /proc/registry/HKEY_CURRENT_USER/Control\ 
Panel/International/User\ Profile/

en-CA\ ()
en-GB\ ()
en-US\ ()
Languages (REG_MULTI_SZ) = "en-CA", "en-GB", "en-US"
ShowAutoCorrection (REG_DWORD) = 0x0001 (1)
ShowTextPrediction (REG_DWORD) = 0x0001 (1)
ShowCasing (REG_DWORD) = 0x0001 (1)
ShowShiftLock (REG_DWORD) = 0x0001 (1)
UserLocaleFromLanguageProfileOptOut (REG_DWORD) = 0x0001 (1)
HttpAcceptLanguageOptOut (REG_DWORD) = 0x0001 (1)

$ regtool list -v /proc/registry/HKEY_CURRENT_USER/Control\ 
Panel/International/Geo/
Nation (REG_SZ) = "39"
Name (REG_SZ) = "CA"

$ regtool list -v /proc/registry/HKEY_CURRENT_USER/Control\ Panel/International/
Calendars\ ()
Geo\ ()
LanguageComponentsAvailable\ ()
User Profile\ ()
User Profile System Backup\ ()
\ ()
s1159 (REG_SZ) = "AM"
s2359 (REG_SZ) = "PM"
sCurrency (REG_SZ) = "$"
sDecimal (REG_SZ) = "."
sGrouping (REG_SZ) = "3;0"
sList (REG_SZ) = ","
sMonDecimalSep (REG_SZ) = "."
sMonGrouping (REG_SZ) = "3;0"
sMonThousandSep (REG_SZ) = ","
sNativeDigits (REG_SZ) = "0123456789"
sNegativeSign (REG_SZ) = "-"
sPositiveSign (REG_SZ) = ""
sThousand (REG_SZ) = ","
sTime (REG_SZ) = ":"
iCalendarType (REG_SZ) = "1"
iCountry (REG_SZ) = "1"
iCurrDigits (REG_SZ) = "2"
iCurrency (REG_SZ) = "0"
NumShape (REG_SZ) = "2"
iFirstWeekOfYear (REG_SZ) = "0"
iLZero (REG_SZ) = "1"
iNegNumber (REG_SZ) = "1"
iPaperSize (REG_SZ) = "1"
iTimePrefix (REG_SZ) = "0"
Locale (REG_SZ) = "1009"
LocaleName (REG_SZ) = "en-CA"
sCountry (REG_SZ) = "Canada"
sDate (REG_SZ) = "-"
sLanguage (REG_SZ) = "ENC"
sLongDate (REG_SZ) = "  dd "
sShortDate (REG_SZ) = "-MM-dd"
sTimeFormat (REG_SZ) = "HH:mm:ss"
sShortTime (REG_SZ) = "HH:mm"
sYearMonth (REG_SZ) = ", "
iDate (REG_SZ) = "2"
iDigits (REG_SZ) = "3"
iFirstDayOfWeek (REG_SZ) = "0"
iMeasure (REG_SZ) = "0"
iNegCurr (REG_SZ) = "1"
iTime (REG_SZ) = "1"
iTLZero (REG_SZ) = "1"

$ regtool list -v /proc/registry/HKEY_CURRENT_USER/Control\ 
Panel/International//

Calendar (REG_SZ) = "Gregorian"

$ regtool list -v /proc/registry/HKEY_CURRENT_USER/Control\ 
Panel/International/Calendars/TwoDigitYearMax/

1 (REG_SZ) = "2099"
2 (REG_SZ) = "2099"
9 (REG_SZ) = "2099"
10 (REG_SZ) = "2099"
11 (REG_SZ) = "2099"
12 (REG_SZ) = "2099"

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: [cygport] Avoid the package's provides appearing in requires

[ASSI via Cygwin-apps]

Jon Turney via Cygwin-apps writes:
>> You can just add any such package or provide names twice at the
>> beginning of the echo invocation, as any package that appears more than
>> once in the resulting output is not recorded as a dependency.
>
> Uh, what, really?
>
> I can't spot the mechanism in __list_deps which does that, which is
> certainly worthy of a comment if we're going to rely on it!

Not in the original code, but I implemented that in my patch (which I
linked).  The dependency mechanism goes to some length to avoid
duplication, so it's easy enough to insert a 'uniq -u' as the final
filter to get rid of the duplicates inserted at the beginning of the
pipeline (outside the dependency extraction).  That is way easier than
trying to filter those out in the middle of the extraction.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: CYGPORT not setting CMAKE_SYSTEM_PROCESSOR when cross compiling with aarch64-w64-mingw32.

[Jon Turney via Cygwin]

On 19/07/2024 09:08, Carlo B. via Cygwin wrote:

Hello,

GCC development branch includes experimental support Windows on ARM64
(WOA), which will be officially released next year with version 15, at
least according to latest news.
So, I compiled it and I created a number of packages for CYGWIN
including binutils, gcc, mingw runtime and several libraries, not
released yet to my repository.
Although the "aarch64-w64-mingw32" target is still experimental, I
have to say that this cross compiler worked very well, at least until
now.


Great work! We'd certainly welcome and appreciate your help getting 
packages for this into our repository, also.



However, some problems appear because there are some thirdy party
tools not expecting to have mingw combined with something different
than i686 or x86_64.
For example, it is impossible to create a shared library when using
libtool, more details could be found here:
https://savannah.gnu.org/support/?111081


Huh. I guess someone should fix that, then!

I think for a start, the regex around line 5724 in libtool (near the 
comment about keeping it in sync with _LT_CHECK_MAGIC_METHOD) needs 
updating to match arm64 archives...



For this reason, you have to use CMake or other alternative tools
instead of autotools.

Actually, another problem can happen when creating the packages for
CYGWIN with CYGPORT utility.
For example, I tried to build a noarch package of libpng for CYGWIN,
by using the new aarch64-w64-mingw32.
I have used CMake to bypass the above trouble with libtool.
Unfortunately, the build process still fails because it didn't compile
the sources for adding the functions with NEON acceleration.
The cause of the problem is the variable CMAKE_SYSTEM_PROCESSOR that is empty.
This is not a bug of CMake, because CMAKE_SYSTEM_PROCESSOR is
typically set into CMAKE_TOOLCHAIN_FILE by the user when cross
compiling.
At the moment, I bypassed the trouble by adding
"-DCMAKE_SYSTEM_PROCESSOR=aarch64" to CYGCMAKE_ARGS into my script.
I gave a look into /usr/share/cygport/cygclass/cmake.cygclass and it
seems to me that there is nothing for setting the CPU type.
Perhaps it would be worth to add support for setting
CMAKE_SYSTEM_PROCESSOR into cmake.cygclass, by checking the content of
${CTARGET}, if it exists with a known CPU.


Interesting.

I took a look and there are several existing packages which have been 
cross-built for x86 and x86_64 MinGW using cmake, so either it seems 
this hasn't yet appeared as a problem for those arches and/or packages...


It's not terribly clear what the valid values are for that cmake 
variable, and what it controls, but the answer [1] makes it seem like 
it's not a lot:


[1] 
https://stackoverflow.com/questions/70475665/what-are-the-possible-values-of-cmake-system-processor


But yeah, this seems eminently fixable in cygport, something like the 
attached I think.


From 5848205bc46e3598f40d4658e7a17eccd3bedbb6 Mon Sep 17 00:00:00 2001
From: Jon Turney 
Date: Sat, 20 Jul 2024 15:23:01 +0100
Subject: [PATCH cygport] cmake: Define CMAKE_SYSTEM_PROCESSOR when
 cross-compiling

---
 cygclass/cmake.cygclass | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/cygclass/cmake.cygclass b/cygclass/cmake.cygclass
index d2a7ef09..3ed4238e 100644
--- a/cygclass/cmake.cygclass
+++ b/cygclass/cmake.cygclass
@@ -82,6 +82,19 @@ __cmake_system() {
echo -n ${cmsys}
 }
 
+__cmake_proc() {
+   local cmproc
+
+   case ${CHOST} in
+   x86_64-*) cmproc="x86_64" ;;
+   i686-*)   cmproc="i686" ;;
+   aarch64-*)cmproc="aarch64" ;;
+   *)  error "Host ${CHOST} is not supported by CMake" ;;
+   esac
+
+   echo -n ${cmproc}
+}
+
 #C* cmake.cygclass/cygcmake
 #  SYNOPSIS
 #  cygcmake [OPTIONS]
@@ -142,6 +155,7 @@ cygcmake() {
if cross_compiling
then
crossargs="-DCMAKE_SYSTEM_NAME=$(__cmake_system)
+   -DCMAKE_SYSTEM_PROCESSOR=$(__cmake_proc)
-D_CMAKE_TOOLCHAIN_PREFIX=${CHOST}-
-DCMAKE_FIND_ROOT_PATH=$(${CC} -print-sysroot)
-DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY
@@ -236,4 +250,4 @@ src_install() {
 }
 #
 
-readonly -f __cmake_system cygcmake
+readonly -f __cmake_system __cmake_proc cygcmake
-- 
2.45.1


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [cygport] Avoid the package's provides appearing in requires

[Jon Turney via Cygwin-apps]

On 30/06/2024 13:02, ASSI via Cygwin-apps wrote:


This commit introduces a bug.  It will not work for packages that have
multiple provides or extra whitespace around the provides name as that
will produce a bogus regex for grep.


Oh, yeah, that's pretty dumb of me.


You can just add any such package or provide names twice at the
beginning of the echo invocation, as any package that appears more than
once in the resulting output is not recorded as a dependency.


Uh, what, really?

I can't spot the mechanism in __list_deps which does that, which is 
certainly worthy of a comment if we're going to rely on it!

Re: Parse output of "net use", but language varies - force language for "net use"?

[Henry S. Thompson via Cygwin]

Mark Liam Brown via Cygwin writes:

> I am trying to parse the output of "net use" in a bash script, but
> hit a roadblock: The output of "net use" changes with the language
> of the system (English, Danish, French, ...), so parsing becomes
> nearly impossible
>
> How can I force the language used by "net use" to English, even if the
> system default language is Danish or French?

Not sure what your execution environment is, but if you can run it
from under PowerShell, seems possible that a simple PowerShell script
might do the trick, using the right Get-... / Set-... cmdlets as
documented here:

  https://learn.microsoft.com/en-us/powershell/module/international/

Bullet-proofing this so that you don't leave the wrong setting in
place if "net use" etc. blow up is a further requirement for real
deployment.

I don't know enough Windows jargon to figure out _which_ pair will
affect the output from "net use" etc., but someone else may be able to
shed light on that question.

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND
   e-mail: h...@inf.ed.ac.uk
  URL: https://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

-- 
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: Parse output of "net use", but language varies - force language for "net use"?

[Mark Liam Brown via Cygwin]

On Sat, Jul 20, 2024 at 4:31 PM Bill Stewart via Cygwin
 wrote:
>
> On Sat, Jul 20, 2024 at 7:45 AM Mark Liam Brown via Cygwin wrote:
>
> I am trying to parse the output of "net use" in a bash script, but hit
> > a roadblock:
> > The output of "net use" changes with the language of the system
> > (English, Danish, French, ...), so parsing becomes nearly impossible
> >
> > How can I force the language used by "net use" to English, even if the
> > system default language is Danish or French?
> >
>
> This sounds like an XY problem[1] to me
>
> What is the goal you're trying to accomplish? Enumerate existing
> connections? Get drive mappings?

Basically I need every bit of information out of "net use", "net
config", "net statistics", "net view" and so on, parse it in bash or
perl, process it in bash, and output it in JSON format from the bash
script for our (Linux-based) admin report interface.

Mark
-- 
IT Infrastructure Consultant
Windows, Linux

-- 
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: Parse output of "net use", but language varies - force language for "net use"?

[Bill Stewart via Cygwin]

On Sat, Jul 20, 2024 at 7:45 AM Mark Liam Brown via Cygwin wrote:

I am trying to parse the output of "net use" in a bash script, but hit
> a roadblock:
> The output of "net use" changes with the language of the system
> (English, Danish, French, ...), so parsing becomes nearly impossible
>
> How can I force the language used by "net use" to English, even if the
> system default language is Danish or French?
>

This sounds like an XY problem[1] to me

What is the goal you're trying to accomplish? Enumerate existing
connections? Get drive mappings?

Bill

[1] https://xyproblem.info

-- 
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: Parse output of "net use", but language varies - force language for "net use"?

[marki via Cygwin]

Yeah, maybe there is another way of doing what you want. But you don't describe 
what you want to do. You have come up with a solution to an unknown problem but 
it does not work. May be an instance of the xy problem.

El 20 de julio de 2024 15:58:05 CEST, Eliot Moss via Cygwin  
escribió:
>On 7/20/2024 9:44 AM, Mark Liam Brown via Cygwin wrote:
>> Greetings!
>> 
>> I am trying to parse the output of "net use" in a bash script, but hit
>> a roadblock:
>> The output of "net use" changes with the language of the system
>> (English, Danish, French, ...), so parsing becomes nearly impossible
>> 
>> How can I force the language used by "net use" to English, even if the
>> system default language is Danish or French?
>> 
>> Mark
>
>Poking around on the web a little suggests that Windows does not use an
>environment variable like LANG to control the language.  Rather, the relevant
>settings seem to live in the registry.  It seems a little dangerous and
>fragile to me to change the registry and change it back, but that may be the
>only approach unless there's a concept of "change a registry entry for this
>session only" or something like that.
>
>HTH, and I'm more than happy to have someone more knowledgeable expand or
>correct this!
>
>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

-- 
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: Parse output of "net use", but language varies - force language for "net use"?

[Eliot Moss via Cygwin]

On 7/20/2024 9:44 AM, Mark Liam Brown via Cygwin wrote:

Greetings!

I am trying to parse the output of "net use" in a bash script, but hit
a roadblock:
The output of "net use" changes with the language of the system
(English, Danish, French, ...), so parsing becomes nearly impossible

How can I force the language used by "net use" to English, even if the
system default language is Danish or French?

Mark


Poking around on the web a little suggests that Windows does not use an
environment variable like LANG to control the language.  Rather, the relevant
settings seem to live in the registry.  It seems a little dangerous and
fragile to me to change the registry and change it back, but that may be the
only approach unless there's a concept of "change a registry entry for this
session only" or something like that.

HTH, and I'm more than happy to have someone more knowledgeable expand or
correct this!

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

Re: ssh vulnerability CVE-2024-6387

[Brian Inglis via Cygwin]

On 2024-07-17 07:25, Bill Stewart via Cygwin wrote:

On Wed, Jul 17, 2024 at 6:25 AM Lemons, Terry via Cygwin wrote:
Vulnerability scanners run at my company have detected the following

vulnerability in the Cygwin sshd:

CVE-2024-6387CVSS 3: 8.1

OpenSSH could allow a remote attacker to execute arbitrary code on the
system, caused by a signal handler race condition. By sending a specially
crafted request, an attacker could exploit this vulnerability to execute
arbitrary code with root privileges on glibc-based Linux systems.

OpenSSH Vulnerability: CVE-2024-6387

   *   Published: 07- 1-24 00:00
   *   Diagnosis:

A signal handler race condition was found in OpenSSH's server (sshd),
where a client does not authenticate within LoginGraceTime seconds (120 by
default, 600 in old OpenSSH versions), then sshd's SIGALRM handler is
called asynchronously. However, this signal handler calls various functions
that are not async-signal-safe, for example, syslog().

   *   Solution:

Upgrade to the latest version of OpenSSH

Download and apply the upgrade from:
ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH

The latest version of OpenSSH is 9.6.

While you can always build OpenSSH from source, many platforms and
distributions provide pre-built binary packages for OpenSSH. These
pre-built packages are usually customized and optimized for a particular
distribution, therefore we recommend that you use the packages if they are
available for your operating system.

Running SSH service
Product OpenSSH exists -- OpenBSD OpenSSH 9.8
Vulnerable version of product OpenSSH found -- OpenBSD OpenSSH 9.8
Vulnerable version of OpenSSH detected on Microsoft Windows

My Cygwin installation is using openssh 9.8p1-1 which, at this writing, is
the latest available version.

What are the plans to address this vulnerability in cygwin's openssh
component?



I'm not sure I understand the concern. When I look at CVE-2024-6387[1], it
says version 9.8 (which you are running) is not affected.

[1] https://nvd.nist.gov/vuln/detail/CVE-2024-6387


This appears to be a not so good vulnerability scan product report, as it does 
not definitively point to the path and version considered vulnerable, it says 
*9.6* is the latest version, which would make it 6 months out of date, and if it 
is Cygwin 9.8p1 it is reporting on, regreSSHion is reported as an OpenSSH sshd 
RCE with Linux glibc issue by RH CNA against RH CPEs which may have their own 
patches causing issues, and 9.8p1 should fix any issues.


It is more likely it may be detecting and reporting on Windows ancient version:

$ llgo /proc/cygdrive/c/windows/system32/OpenSSH/
total 3.0M
-rwxr-x---+ 2 387K May 19  2021 moduli*
-rwxr-x---+ 2 301K May 19  2021 scp.exe*
-rwxr-x---+ 2 366K May 19  2021 sftp.exe*
-rwxr-x---+ 2 300K May 19  2021 sftp-server.exe*
-rwxr-x---+ 2 924K May 19  2021 ssh.exe*
-rwxr-x---+ 2 470K May 19  2021 ssh-add.exe*
-rwxr-x---+ 2 374K May 19  2021 ssh-agent.exe*
-rwxr-x---+ 2 985K May 19  2021 sshd.exe*
-rwxr-x---+ 2 2.3K May 19  2021 sshd_config_default*
-rwxr-x---+ 2 647K May 19  2021 ssh-keygen.exe*
-rwxr-x---+ 2 545K May 19  2021 ssh-keyscan.exe*
-rwxr-x---+ 2 148K May 19  2021 ssh-shellhost.exe*
$ /proc/cygdrive/c/windows/system32/OpenSSH/ssh -V
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2

unless that has been purged from your systems.

That NVD report has a bunch of links to RH issues irrelevant to the RCE.

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: ssh vulnerability CVE-2024-6387

[Bill Stewart via Cygwin]

On Wed, Jul 17, 2024 at 6:25 AM Lemons, Terry via Cygwin wrote:

Vulnerability scanners run at my company have detected the following
> vulnerability in the Cygwin sshd:
>
> CVE-2024-6387CVSS 3: 8.1
>
> OpenSSH could allow a remote attacker to execute arbitrary code on the
> system, caused by a signal handler race condition. By sending a specially
> crafted request, an attacker could exploit this vulnerability to execute
> arbitrary code with root privileges on glibc-based Linux systems.
>
> OpenSSH Vulnerability: CVE-2024-6387
>
>   *   Published: 07- 1-24 00:00
>   *   Diagnosis:
>
> A signal handler race condition was found in OpenSSH's server (sshd),
> where a client does not authenticate within LoginGraceTime seconds (120 by
> default, 600 in old OpenSSH versions), then sshd's SIGALRM handler is
> called asynchronously. However, this signal handler calls various functions
> that are not async-signal-safe, for example, syslog().
>
>   *   Solution:
>
> Upgrade to the latest version of OpenSSH
>
> Download and apply the upgrade from:
> ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH
>
> The latest version of OpenSSH is 9.6.
>
> While you can always build OpenSSH from source, many platforms and
> distributions provide pre-built binary packages for OpenSSH. These
> pre-built packages are usually customized and optimized for a particular
> distribution, therefore we recommend that you use the packages if they are
> available for your operating system.
>
> Running SSH service
> Product OpenSSH exists -- OpenBSD OpenSSH 9.8
> Vulnerable version of product OpenSSH found -- OpenBSD OpenSSH 9.8
> Vulnerable version of OpenSSH detected on Microsoft Windows
>
> My Cygwin installation is using openssh 9.8p1-1 which, at this writing, is
> the latest available version.
>
> What are the plans to address this vulnerability in cygwin's openssh
> component?
>

I'm not sure I understand the concern. When I look at CVE-2024-6387[1], it
says version 9.8 (which you are running) is not affected.

[1] https://nvd.nist.gov/vuln/detail/CVE-2024-6387

-- 
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 application hangs on closing console

[Johannes Khoshnazar-Thoma via Cygwin]

Hi Takashi, Hi Corinna,

Your patch to the allocation of a unique identifier to use
as event name in closing the console seems to solve our client's
problems. Thank you so much again, is there a cygwin1.dll
release planned in the near future? I can of course compile
it on my own, but I feel a bit uneasy using intermediate git
commits in production, so I would like to wait for an
'official' cygwin release. Please let me know what the plans
are.

Best regards,

- Johannes

--
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: Urgent gcc update to GCC 13.3

[Csaba Ráduly via Cygwin]

On 15/07/2024 22:44, Mark Liam Brown via Cygwin wrote:

On Mon, Jul 15, 2024 at 9:35 PM Csaba Ráduly via Cygwin
 wrote:

On 09/07/2024 08:17, Cedric Blancher via Cygwin wrote:

I'd agree that newer gcc 13.x to compile Cygwin and as /usr/bin/gcc
would be a very good idea, not only for performance+STL fixes, but
also since by default the Cygwin distro lacks C++17 support,

Huh? GCC supports C++17 since GCC 7

https://en.cppreference.com/w/cpp/17

No, it does not. *Some* features work, but gcc 13.1 was the first
release where everything mandated by C++17 is working, or at least
compiling.
So far g++ in Cygwin 3.5.3 cannot compile anything in std::pmr:*, e.g.
std::pmr::monotonic_buffer_resource, std::pmr::polymorphic_allocator,
std::pmr::string, ruling out any realistic C++17 apps (of course,
HelloWorld will work).

Mark


A few examples of non-realistic, HelloWorld class projects:

LLVM:

~/wk/llvm-project $ ag -s --cpp -w pmr bolt/ clang* compiler-rt/ 
cross-project-tests/ flang/ libclc libunwind/ ll* mlir/ offload/ openmp/ 
polly/ pstl/ runtimes/ third-party/ utils/

clang/test/SemaCXX/overloaded-builtin-operators.cpp
116:  pmf  = (pmf_ref = ::f); // expected-error{{no viable 
overloaded '='}}

~/wk/llvm-project $

Abseil:

~/wk/abseil-cpp$ ag -s --cpp -w pmr absl/
absl/container/internal/raw_hash_set_allocator_test.cc
450:// This allocator is similar to std::pmr::polymorphic_allocator.
~/wk/abseil-cpp$

GCC:

~/wk/gcc-project$ ag -l -c -s --cpp -w --ignore libstdc++-v3 pmr
gcc/cp/std-name-hint.h:10
gcc/testsuite/g++.dg/rtti/typeid7.C:2
~/wk/gcc-project$

Electron

~/wk/electron$ ag -l -c -s --cpp -w pmr
~/wk/electron$

LibreOffice

~/wk/libreoffice$ ag -l -c -s --cpp -w pmr
~/wk/libreoffice$

TensorFlow

~/wk/tensorflow$ ag -l -c -s --cpp -w pmr
~/wk/tensorflow$

Polymorphic memory resources were supported by GCC 9, according to 
https://en.cppreference.com/w/cpp/compiler_support/17


Anyway, nobody cares about std::pmr::anything , except maybe John Lakos 
and the Intel TBB project. /hyperbole


Search results on github (thousands)

pmr::                8
set_symmetric_difference    8.4
lexicographical_compare    32
nth_element    25
std::rotate        17.5
vector            27000
std::vector    12100
std::string    16300


Csaba

--
Life is complex, with real and imaginary parts.


--
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: No Native Language Support in browser started from shell prompt

[Dr Bean via Cygwin]

On Mon, 24 Jun 2024, Andrey Repin wrote:

> Greetings, Dr Bean!
> 
> >> >
> >> > Am 14.06.2024 um 09:37 schrieb Dr Bean via Cygwin:
> >> > > With qutebrowser and Microsoft Edge started from a cygwin shell prompt,
> >> > > there is no Native Language Support.
> >> > > 
> >> > > Started from a cmd prompt,
> >> > > 
> >> > > "c:\Program Files\qutebrowser\qutebrowser.exe" 
> >> > > https://ja.wikipedia.org/wiki/%E8%A5%BF%E6%97%A5%E6%9C%AC%E3%81%AE%E5%A4%A7%E5%AD%A6%E4%B8%80%E8%A6%A7
> >> > > 
> >> > > qutebrowser has Chinese and Japanese support.
> >> > > 
> >> > > But in cygwin neither qutebrowser, started with cygstart or
> >> > > as /cygdrive/c/Program\ Files/qutebrowser/qutebrowser
> >> > > https://ja.wikipedia.org/wiki/%E8%A5%BF%E6%97%A5%E6%9C%AC%E3%81%AE%E5%A4%A7%E5%AD%A6%E4%B8%80%E8%A6%A7
> >> > > 
> >> > > nor Microsoft Edge as default browser started with cygstart, enjoy NLS 
> >> > > support.
> >> > That page displays fine for me, after starting /Program Files
> >> > (x86)/Microsoft/Edge/Application/msedge.exe with cygstart. What exactly
> >> > is the symptom of "no Japanese support"?
> >> 
> >> I spoke too soon. Microsoft Edge doesn't appear to lack NLS support when 
> >> started from a mintty window either with cygstart or the /cygdrive path.
> 
> > I installed Google Chrome, and Japanese and Korean 
> > keyboard entry appear to be supported by both IME when it is started 
> > from a mintty window with cygstart or directly with the cygdrive 
> > path.
> 
> If I'm allowed to hazard a guess, check if any of the environment variables
> set by Cygwin affecting your browser.
> My first suspicion would be LANG and LOCALE ones.

The environment variable involved appears to be QT_IM_MODULE 
(qutebrowser is a Qt app). Disabling it in the qutebrowser config 
file lets you input text in CJK scripts, when you open web pages with
'cygstart'.

> -- 
> With best regards,
> Andrey Repin
> Monday, June 24, 2024 17:12:27
> 
> Sorry for my terrible english...
> 

-- 
Greg "Dr Bean" Matheson Whereof we cannot speak, we must remain silent.
http://drbean.sdf.org   --Ludwig Wittgenstein
drb...@freeshell.org

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Urgent gcc update to GCC 13.3

[Brian Inglis via Cygwin]

On 2024-07-15 14:44, Mark Liam Brown via Cygwin wrote:

On Mon, Jul 15, 2024 at 9:35 PM Csaba Ráduly via Cygwin wrote:

On 09/07/2024 08:17, Cedric Blancher via Cygwin wrote:

I'd agree that newer gcc 13.x to compile Cygwin and as /usr/bin/gcc
would be a very good idea, not only for performance+STL fixes, but
also since by default the Cygwin distro lacks C++17 support,



Huh? GCC supports C++17 since GCC 7



https://en.cppreference.com/w/cpp/17



No, it does not. *Some* features work, but gcc 13.1 was the first
release where everything mandated by C++17 is working, or at least
compiling.
So far g++ in Cygwin 3.5.3 cannot compile anything in std::pmr:*, e.g.
std::pmr::monotonic_buffer_resource, std::pmr::polymorphic_allocator,
std::pmr::string, ruling out any realistic C++17 apps (of course,
HelloWorld will work).


Hi Mark,

You and others interested can either get involved by *volunteering* to assist 
[SWHTDI] the current *volunteer* maintainers progressing their heavy workloads, 
probably involving a lot of testing, failure diagnosis, gcc test discussion, 
patch submission and possibly revision, across various x86_64/amd64 processors, 
trying to be compatible with other uarches, processors, and platforms, or be 
patient while they do their best in their free time (another free to add for 
Cygwin software!)


As mentioned earlier gcc/-core/-g++/-ada/-fortran/objc/++ 13.2.1+20240426-0.1 is 
available for installation as a test package, which means that you also have to 
choose the test prerequisite packages at the same revision level, including: 
libatomic1, libgcc1, libgfortran5, libgnat13, libgomp1, libobjc4, libquadmath0, 
libstdc++6.


Installing and using these test versions and providing feedback to the package 
maintainers is also a valuable contribution, but please also be aware that this 
is a cooperative endeavour dependent on all participants availability, which may 
vary widely e.g. European contributors may take many weeks vacation time during 
summer, and life events and work commitments may also eliminate free time!


[BTW some testing indicates that most PMR can impose heavy penalties unless it 
just provides a light wrapper around the standard `malloc` allocator to support 
STL containers!
It must be nice to be able to ignore compilers that do not fully support the 
latest standards and features.
Perhaps you should look at e.g. Fedora or other Linux distros Cygwin or Windows 
cross or indeed native compilers.

Or maybe consider MSVC or a more up to date commercial offering.]

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: Urgent gcc update to GCC 13.3

[Mark Liam Brown via Cygwin]

On Mon, Jul 15, 2024 at 9:35 PM Csaba Ráduly via Cygwin
 wrote:
>
> On 09/07/2024 08:17, Cedric Blancher via Cygwin wrote:
> > I'd agree that newer gcc 13.x to compile Cygwin and as /usr/bin/gcc
> > would be a very good idea, not only for performance+STL fixes, but
> > also since by default the Cygwin distro lacks C++17 support,
>
> Huh? GCC supports C++17 since GCC 7
>
> https://en.cppreference.com/w/cpp/17

No, it does not. *Some* features work, but gcc 13.1 was the first
release where everything mandated by C++17 is working, or at least
compiling.
So far g++ in Cygwin 3.5.3 cannot compile anything in std::pmr:*, e.g.
std::pmr::monotonic_buffer_resource, std::pmr::polymorphic_allocator,
std::pmr::string, ruling out any realistic C++17 apps (of course,
HelloWorld will work).

Mark
-- 
IT Infrastructure Consultant
Windows, Linux

-- 
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: Urgent gcc update to GCC 13.3

[Csaba Ráduly via Cygwin]

On 09/07/2024 08:17, Cedric Blancher via Cygwin wrote:

I'd agree that newer gcc 13.x to compile Cygwin and as /usr/bin/gcc
would be a very good idea, not only for performance+STL fixes, but
also since by default the Cygwin distro lacks C++17 support,


Huh? GCC supports C++17 since GCC 7

https://en.cppreference.com/w/cpp/17

Csaba

--
Life is complex, with real and imaginary parts.


--
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: [ATTN] ca-certificates-letsencrypt maintainer

[Brian Inglis via Cygwin-apps]

On 2024-07-14 13:46, ASSI via Cygwin-apps wrote:

Brian Inglis via Cygwin-apps writes:

Re-installed last ca-certificates-letencrypt package and cygport
announce and git send-email are working again.


Then keep it installed one or two months longer, but I will not revive
that package.  The original problem with the R3 cross-signed through X3
went away at least a year ago already and the last R3 signed
certificates (that don't have this problem) should expire somewhere in
the next two or three months latest.  New certificates should be signed
by R10 or R11 already.


Sorry Achim,

But given that the Cygwin certs appear that they may require some of these, and 
does not expire until mid-August, might it not have been better to keep the 
package around until after then?



Some unexpired letsencrypt certificates should probably have been
migrated to ca-certificates or left in ca-certificates-letencrypt?


Nope.


so were any DigiCert certs harmed in the making of this package? ;^>


Bollocks.  If installing ca-certificates-letencrypt fixes it for you,
then it's either an old TrustID X3 or Let's Encrypt R3 certificate
(probably the latter) somewhere in the cert chain _plus_ an openssl
earlier than 1.2 (as these had a bug in cert validation that gets
triggered during validation of a cross-signed a CA).


I do not know how to figure out what is in these cert packages, and what 
correlation is significant between those, my email server, cygwin/sourceware 
email server, cygport pkg_upload(__pkg_announce) and git send-email.



Anyway, the current openssl has no problems with either of the servers
you mentioned:


It seems to me that both /usr/share/cygport/lib/pkg_upload.cygpart 
__pkg_announce() and /usr/libexec/git-core/git-send-email send_message() have 
Net::SMTP::SSL in common: those perl modules and dependencies all seem to be 
5.36, and I have no idea how they link to OpenSSL, but could they eventually 
link to the old OpenSSL 1.1.1w, and could that be causing an issue?


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: [ATTN] ca-certificates-letsencrypt maintainer

[ASSI via Cygwin-apps]

Brian Inglis via Cygwin-apps writes:
>> Re-installed last ca-certificates-letencrypt package and cygport
>> announce and git send-email are working again.

Then keep it installed one or two months longer, but I will not revive
that package.  The original problem with the R3 cross-signed through X3
went away at least a year ago already and the last R3 signed
certificates (that don't have this problem) should expire somewhere in
the next two or three months latest.  New certificates should be signed
by R10 or R11 already.

>> Some unexpired letsencrypt certificates should probably have been
>> migrated to ca-certificates or left in ca-certificates-letencrypt?

Nope.

> so were any DigiCert certs harmed in the making of this package? ;^>

Bollocks.  If installing ca-certificates-letencrypt fixes it for you,
then it's either an old TrustID X3 or Let's Encrypt R3 certificate
(probably the latter) somewhere in the cert chain _plus_ an openssl
earlier than 1.2 (as these had a bug in cert validation that gets
triggered during validation of a cross-signed a CA).

Anyway, the current openssl has no problems with either of the servers
you mentioned:

--8<---cut here---start->8---
~ (2012)# openssl s_client -connect mail.hover.com:465
CONNECTED(0004)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global 
Root G2
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA 
CA G1
verify return:1
depth=0 CN = *.hover.com
verify return:1
---
Certificate chain
 0 s:CN = *.hover.com
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA CA 
G1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jul 14 00:00:00 2024 GMT; NotAfter: Jul 13 23:59:59 2025 GMT
 1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA CA 
G1
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root 
G2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Nov  2 12:24:33 2017 GMT; NotAfter: Nov  2 12:24:33 2027 GMT
 2 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root 
G2
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root 
G2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug  1 12:00:00 2013 GMT; NotAfter: Jan 15 12:00:00 2038 GMT
---
Server certificate
-BEGIN CERTIFICATE-
MIIGIDCCBQigAwIBAgIQAsPHqBLbhyMzxknMGhWz5zANBgkqhkiG9w0BAQsFADBg
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMR8wHQYDVQQDExZSYXBpZFNTTCBUTFMgUlNBIENBIEcx
MB4XDTI0MDcxNDAwMDAwMFoXDTI1MDcxMzIzNTk1OVowFjEUMBIGA1UEAwwLKi5o
b3Zlci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMbFFzY5dq
Qo33T6P4s4cexUVhA+gMflpYyI/gA7betlbL6F7cB8JrDl/C9s4/UAvuG0smZI4a
ZrzbogtMcvjyhiV8czywWDibCwyrH7nRRidRxCPbtJcC/utRb+g2gTtnUNAFvqnv
Jcc3OPZCEo6mnx3RPHH3RpmfXM3faAHHI9VNwRSK8F9w9JDc5PtW5J7pEdxkat6y
+faiuYjqKw53a5kocj+9RQDH5X+0f6fltL1Ed3ehSo7n+qkONMn5SE+iYB2EX/Pt
VIIFB1deI7GRis9UU3Tfw9osuCxSz7RzE7I+YOMTRPHyi79ns9WthYTtzbS9Cezu
ZtMgIWWu4yrHAgMBAAGjggMeMIIDGjAfBgNVHSMEGDAWgBQM22yCSQ9KZwq4FO56
xEhSiOtWODAdBgNVHQ4EFgQUyuEEPsQ/asGApRPLTUAbr8YkstswIQYDVR0RBBow
GIILKi5ob3Zlci5jb22CCWhvdmVyLmNvbTA+BgNVHSAENzA1MDMGBmeBDAECATAp
MCcGCCsGAQUFBwIBFhtodHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwDgYDVR0P
AQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjA/BgNVHR8E
ODA2MDSgMqAwhi5odHRwOi8vY2RwLnJhcGlkc3NsLmNvbS9SYXBpZFNTTFRMU1JT
QUNBRzEuY3JsMHYGCCsGAQUFBwEBBGowaDAmBggrBgEFBQcwAYYaaHR0cDovL3N0
YXR1cy5yYXBpZHNzbC5jb20wPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYWNlcnRzLnJh
cGlkc3NsLmNvbS9SYXBpZFNTTFRMU1JTQUNBRzEuY3J0MAwGA1UdEwEB/wQCMAAw
ggF9BgorBgEEAdZ5AgQCBIIBbQSCAWkBZwB2ABLxTjS9U3JMhAYZw48/ehP457Vi
h4icbTAFhOvlhiY6AAABkLBAqI0AAAQDAEcwRQIhAP92rBnu2y8SKYSW4pOrS4YM
+8mrbG3xbE9M1oUbwq2rAiBJfWhIX7rg2jf5un7kzELaNAMfcVXbRG49HXsl03f2
2AB2AObSMWNAd4zBEEEG13G5zsHSQPaWhIb7uocyHf0eN45QAAABkLBAqO4AAAQD
AEcwRQIgM81EF1/VVPuuXEX1HqUlCg48C2SiD1hQ1oqM+E9cYYICIQCZYNIstjRL
29329bB5MaJYgh3S5im0sRXINCEuwd3ZHwB1AMz7D2qFcQll/pWbU87psnwi6YVc
DZeNtql+VMD+TA2wAAABkLBAqH0AAAQDAEYwRAIgYoYwHn1y70KNvvEHCSijHXHy
iKZyy0pihluxBUjHt14CIAmgx+C1vT4abtGvjyjUw3uCZbkIFhMFFtt7q1+Jlmke
MA0GCSqGSIb3DQEBCwUAA4IBAQCZGX+ib0vdW2XQge9rfKQiPzHSS8GjDXrWKNQG
Sb5aZHvdaaBtFDlHpbGf+EHg+9/0pbTGddNLxaXLHTlhBq4es1vPXfz5l7XojWEQ
XnyD7cLPCVU/D2rh2UjnhpKzF/XtRwqL7TzTXOMJDCW4qMNjsPQGMH5zUPzi2bGu
l8GOdKkOwLSgaqJOzXe9KZ8Pn0SwEVKx9mvKeNGmm/XlMjwJz74G2DApmYJNjcI8
c8sKPZZX0UWR1CFO+x5CaggwbS9+H44QlEcwvsUlTkIutl1gsKBwdk2stRbfSOmE
FbwafUaJeu0tNjwyIEahfxs3rut5MDsB6vkTzeqf3sPKk6vG
-END CERTIFICATE-
subject=CN = *.hover.com
issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA 
CA G1
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4263 bytes and written 416 bytes
Verification: OK
---
New, TLSv1.3, Cipher is 

Re: [ATTN] ca-certificates-letsencrypt maintainer

[Brian Inglis via Cygwin-apps]

On 2024-07-14 11:05, Brian Inglis via Cygwin-apps wrote:

On 2024-07-13 15:03, Brian Inglis wrote:

On 2024-07-13 14:43, Brian Inglis via Cygwin-apps wrote:

On 2024-06-30 05:31, ASSI wrote:


The following packages have been uploaded to the Cygwin distribution:

  ca-certificates-2024.2.66_v8.0.302-1

The ca-certificates-letsencrypt package has been removed, since all
signatures using the cross-signed certificate chain for Let's Encrypt
root servers have long expired.  In other words, the problem this
package was solving no longer exists.


Hi folks,

Any chance a cert may have been dropped inadvertently?

Or some other update I or others may have packaged could have messed up email.

I can no longer use cygport announce or git send-email via this mail server, 
but Windows Thunderbird still works!


Have any Let's Encrypt Intermediate certs been dropped?

While Cygwin uses ISRG Root X1 -> R3 -> Cygwin.com my email provider may use 
ISRG Root X1 -> R11 -> hover.com - all valid until later this year or much 
longer - checking if they may use a different email cert chain or CA.


Hi folks,

Re-installed last ca-certificates-letencrypt package and cygport announce and 
git send-email are working again.
Some unexpired letsencrypt certificates should probably have been migrated to 
ca-certificates or left in ca-certificates-letencrypt?


Trying cygport --debug and git send-email --smtp-debug=1 do not show any cert 
validation - any ideas how to see what certs are used in email auth?


Found an answer for that on
https://serverfault.com/questions/131627/how-to-inspect-remote-smtp-servers-tls-certificate/131628#131628

for example:

$ openssl s_client -connect mail.example.com:465

which using the correct servers and ports gives the certs in the attached log:

DigiCert Global Root G2 -> RapidSSL TLS RSA CA G1 -> *.hover.com

so were any DigiCert certs harmed in the making of this package? ;^>

Current DigiCert CA Root and Intermediate certs are shown in:

https://www.digicert.com/kb/digicert-root-certificates.htm

I have added some non-packaged CA certs in the past and I can try doing that 
again if it is required to help?


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry$ openssl s_client -connect mail.hover.com:465
CONNECTED(0004)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global 
Root G2
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA 
CA G1
verify return:1
depth=0 CN = *.hover.com
verify return:1
---
Certificate chain
 0 s:CN = *.hover.com
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA CA 
G1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jul 14 00:00:00 2024 GMT; NotAfter: Jul 13 23:59:59 2025 GMT
 1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA CA 
G1
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root 
G2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Nov  2 12:24:33 2017 GMT; NotAfter: Nov  2 12:24:33 2027 GMT
 2 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root 
G2
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root 
G2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug  1 12:00:00 2013 GMT; NotAfter: Jan 15 12:00:00 2038 GMT
---
Server certificate
-BEGIN CERTIFICATE-
MIIGIDCCBQigAwIBAgIQAsPHqBLbhyMzxknMGhWz5zANBgkqhkiG9w0BAQsFADBg
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMR8wHQYDVQQDExZSYXBpZFNTTCBUTFMgUlNBIENBIEcx
MB4XDTI0MDcxNDAwMDAwMFoXDTI1MDcxMzIzNTk1OVowFjEUMBIGA1UEAwwLKi5o
b3Zlci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMbFFzY5dq
Qo33T6P4s4cexUVhA+gMflpYyI/gA7betlbL6F7cB8JrDl/C9s4/UAvuG0smZI4a
ZrzbogtMcvjyhiV8czywWDibCwyrH7nRRidRxCPbtJcC/utRb+g2gTtnUNAFvqnv
Jcc3OPZCEo6mnx3RPHH3RpmfXM3faAHHI9VNwRSK8F9w9JDc5PtW5J7pEdxkat6y
+faiuYjqKw53a5kocj+9RQDH5X+0f6fltL1Ed3ehSo7n+qkONMn5SE+iYB2EX/Pt
VIIFB1deI7GRis9UU3Tfw9osuCxSz7RzE7I+YOMTRPHyi79ns9WthYTtzbS9Cezu
ZtMgIWWu4yrHAgMBAAGjggMeMIIDGjAfBgNVHSMEGDAWgBQM22yCSQ9KZwq4FO56
xEhSiOtWODAdBgNVHQ4EFgQUyuEEPsQ/asGApRPLTUAbr8YkstswIQYDVR0RBBow
GIILKi5ob3Zlci5jb22CCWhvdmVyLmNvbTA+BgNVHSAENzA1MDMGBmeBDAECATAp
MCcGCCsGAQUFBwIBFhtodHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwDgYDVR0P
AQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjA/BgNVHR8E
ODA2MDSgMqAwhi5odHRwOi8vY2RwLnJhcGlkc3NsLmNvbS9SYXBpZFNTTFRMU1JT
QUNBRzEuY3JsMHYGCCsGAQUFBwEBBGowaDAmBggrBgEFBQcwAYYaaHR0cDovL3N0
YXR1cy5yYXBpZHNzbC5jb20wPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYWNlcnRzLnJh
cGlkc3NsLmNvbS9SYXBpZFNTTFRMU1JTQUNBRzEuY3J

Re: [ITP] cmocka required for fortune-mod package update

[Brian Inglis via Cygwin-apps]

On 2024-07-14 04:15, Jon Turney wrote:

On 13/07/2024 21:10, Brian Inglis via Cygwin-apps wrote:
On 2024-07-13 13:28, cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org 
wrote:
ERROR: package 'fortune-mod-src' version '3.22.0-1' build-depends: 'cmocka', 
but nothing satisfies that

ERROR: error while validating merged x86_64 packages for Brian Inglis
SUMMARY: 2 ERROR(s)


Sorry, I forget to add cmocka to your packages.  Done now.


Thanks Jon,

I will redo that !ready.

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: [ITP] cmocka required for fortune-mod package update

[Jon Turney via Cygwin-apps]

On 13/07/2024 21:10, Brian Inglis via Cygwin-apps wrote:
On 2024-07-13 13:28, 
cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org wrote:
ERROR: package 'fortune-mod-src' version '3.22.0-1' build-depends: 
'cmocka', but nothing satisfies that

ERROR: error while validating merged x86_64 packages for Brian Inglis
SUMMARY: 2 ERROR(s)


Sorry, I forget to add cmocka to your packages.  Done now.

Re: [ITP] cmocka 1.1.7 - C unit testing framework

[Jon Turney via Cygwin-apps]

On 12/07/2024 03:31, Brian Inglis via Cygwin-apps wrote:

On 2024-07-10 15:05, Jon Turney wrote:

On 10/07/2024 00:35, Brian Inglis via Cygwin-apps wrote:

Description:
Elegant unit testing framework for C with support for mock objects,
derived from Google Cmockery.

License:    Apache-2.0

I would like to provide a Cygwin package for cmocka, as it is now
required for testing my fortune-mod package.

For more information see the project home pages:

 https://cmocka.org

It is packaged by major Linux and BSD distros:

 https://repology.org/project/cmocka/versions

There is an error building the docs using doxygen, and that hangs, using
either cmake/make or cmake/ninja builds, locally and in GH CI (see
previous job 8341 - had to cancel after 3 hours), with current stable 
and a local build of the latest doxygen release, and an issue has 
been raised upstream.


I suspect this is a problem in cygwin.

There is (what sounds like) a similar problem when building libxcb's 
documentation, in that it gets stuck somewhere in doxygen, waiting for 
a load of dot.exe processes to finish even after they're all done.


I bisected that to working under 3.3.6 and failing under 3.4.0, but 
there's nothing obviously related in that interval, and I haven't 
found the time to bisect the commits...


Thanks Jon,

They agree with that suspicion in doxygen:

 https://github.com/doxygen/doxygen/issues/10251

Looking at some hints and approaches for doxygen diagnostics and debugging:

 -DDOXYGEN_DOT_NUM_THREADS=1

Eliminating all other job paramaters, that is the one that switches 
hangs on and off.
When you have time, would you care to retry libxcb docs with that 
CYGCMAKE_ARGS or equivalent?
I can see if upstream can help us narrow the code down to a simple STC 
for us, or should we loop in, or punt to, Ken as maintainer? ;^>


I think the most productive investigation at this stage would be to 
confirm my observation of the range of commits in cygwin which 
introduces the regression, and try to bisect that


(Due to version skew, you'd probably have to hop in your time machine to 
make an installation using 3.3.4, then use that to build and test 
intermediate versions)

Re: Updated: ca-certificates-2024.2.66_v8.0.302-1

[Brian Inglis via Cygwin-apps]

On 2024-07-13 14:43, Brian Inglis via Cygwin-apps wrote:

On 2024-06-30 05:31, ASSI wrote:


The following packages have been uploaded to the Cygwin distribution:

  ca-certificates-2024.2.66_v8.0.302-1

The ca-certificates-letsencrypt package has been removed, since all
signatures using the cross-signed certificate chain for Let's Encrypt
root servers have long expired.  In other words, the problem this
package was solving no longer exists.


Hi folks,

Any chance a cert may have been dropped inadvertently?

Or some other update I or others may have packaged could have messed up email.

I can no longer use cygport announce or git send-email via this mail server, but 
Windows Thunderbird still works!


Have any Let's Encrypt Intermediate certs been dropped?

While Cygwin uses ISRG Root X1 -> R3 -> Cygwin.com my email provider may use 
ISRG Root X1 -> R11 -> hover.com - all valid until later this year or much 
longer - checking if they may use a different email cert chain or CA.


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: Updated: ca-certificates-2024.2.66_v8.0.302-1

[Brian Inglis via Cygwin-apps]

On 2024-06-30 05:31, ASSI wrote:


The following packages have been uploaded to the Cygwin distribution:

  ca-certificates-2024.2.66_v8.0.302-1

The ca-certificates-letsencrypt package has been removed, since all
signatures using the cross-signed certificate chain for Let's Encrypt
root servers have long expired.  In other words, the problem this
package was solving no longer exists.


Hi folks,

Any chance a cert may have been dropped inadvertently?

Or some other update I or others may have packaged could have messed up email.

I can no longer use cygport announce or git send-email via this mail server, but 
Windows Thunderbird still works!


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: [ITP] cmocka required for fortune-mod package update

[Brian Inglis via Cygwin-apps]

On 2024-07-13 13:28, cygwin-no-re...@cygwin.com wrote:

ERROR: package 'fortune-mod-src' version '3.22.0-1' build-depends: 'cmocka', 
but nothing satisfies that
ERROR: error while validating merged x86_64 packages for Brian Inglis
SUMMARY: 2 ERROR(s)


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: /proc/cpuinfo missing blank lines after each processor

[Brian Inglis via Cygwin]

On 2024-07-13 10:37, ASSI via Cygwin wrote:


There should be a blank line ("\n") after each processsor entry, which
is missing on Cygwin.  This actually includses the last processor, so
the output should always end with a blank line as well.

Some programs that parse the data based on what Linux specifies get
confused if this line is missing…


I can add that with regular changes to /proc/cpuinfo when next Linux release 
additions are finalized this week or the week after.


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: How to use '$RECYCLE.BIN' to recover files?

[Brian Inglis via Cygwin]

On 2024-07-12 15:12, Mark Liam Brown via Cygwin wrote:

On Fri, Jul 12, 2024 at 7:25 PM Brian Inglis via Cygwin wrote:

On 2024-07-12 10:33, Tom Legrady via Cygwin wrote:

Using cygwin on Windows 11, I ran a command that was over-enthusiastic in
deleting files. Now files I would like to have are in the $RECYCLE.BIN, with
names like '$I0BEVIM.pdf'.
How can I restore these files' original name and path?

See:
 https://en.wikipedia.org/wiki/Trash_(computing)#Microsoft_Windows
 https://superuser.com/a/1736690
for low level details for Vista onwards: original file or directory hard linked
in /proc/cygdrive/D/\$Recycle.Bin/S-1-5-21-*-*-*-UID/\$RXX.type and metadata
saved in /proc/cygdrive/D/\$Recycle.Bin/S-1-5-21-*-*-*-UID/\$IXX.type where
UID is often 1000 or 1001 with personal desktop local accounts, and you only
have access to your own, unless elevated as admin, e.g.
$ ls -glort /proc/cygdrive/d/\$Recycle.Bin/S-1-5-21-*-*-*-1001/
total 3
-rwx--+ 1 129 Apr  2  2020  desktop.ini
drwxr-xr-x  1   0 Dec 12  2021 '$RVW0RM1'
-rw-r--r--+ 1   0 Oct 22  2023 '$RQWOLZK.ini-save'
-rwx--+ 1 254 Oct 22  2023 '$IQWOLZK.ini-save'
-rwx--+ 1  82 Oct 22  2023 '$IVW0RM1'
$ xxd -c8 -g8 /proc/cygdrive/d/\$Recycle.Bin/S-1-5-21-*-*-*-1001/\$IVW0RM1
: 0200  # header (le)
0008:   # file size (le)
0010: e04bc8060b05da01  .K..# deleted time (le 100ns Windows)
0018: 1b0044003a00  D.:.# path length(le 4) path (4+ UCS-2)
0020: 5c00760061007200  \.v.a.r.
0028: 5c00630061006300  \.c.a.c.
0030: 680065005c007300  h.e.\.s.
0038: 6500740075007000  e.t.u.p.
0040: 5c00650074006300  \.e.t.c.
0048: 5c0070006b006900  \.p.k.i.
0050:   ..



I think the question was:
Does Cygwin have utilities which can restore the files from a script?
Or how can a user call powershell to do the job?


That was not what the OP asked - he asked how.

Asking in a Cygwin group implies he is looking for a Cygwin solution to a 
problem someone created with Cygwin utilities.


I doubt anyone has bothered, so some background info to do the job is referred 
to, and illustrated somewhat.


The easy Windows answer is open Explorer on your 'Recycle Bin' and select 
'Restore' after selecting all those files deleted by mistake.


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: How to use '$RECYCLE.BIN' to recover files?

[Mark Liam Brown via Cygwin]

On Fri, Jul 12, 2024 at 7:25 PM Brian Inglis via Cygwin
 wrote:
>
> On 2024-07-12 10:33, Tom Legrady via Cygwin wrote:
> > Using cygwin on Windows 11, I ran a command that was over-enthusiastic in
> > deleting files. Now files I would like to have are in the $RECYCLE.BIN, with
> > names like '$I0BEVIM.pdf'.
> >
> > How can I restore these files' original name and path?
>
> See:
>
> https://en.wikipedia.org/wiki/Trash_(computing)#Microsoft_Windows
>
> https://superuser.com/a/1736690
>
> for low level details for Vista onwards: original file or directory hard 
> linked
> in /proc/cygdrive/D/\$Recycle.Bin/S-1-5-21-*-*-*-UID/\$RXX.type and 
> metadata
> saved in /proc/cygdrive/D/\$Recycle.Bin/S-1-5-21-*-*-*-UID/\$IXX.type 
> where
> UID is often 1000 or 1001 with personal desktop local accounts, and you only
> have access to your own, unless elevated as admin, e.g.
>
> $ ls -glort /proc/cygdrive/d/\$Recycle.Bin/S-1-5-21-*-*-*-1001/
> total 3
> -rwx--+ 1 129 Apr  2  2020  desktop.ini
> drwxr-xr-x  1   0 Dec 12  2021 '$RVW0RM1'
> -rw-r--r--+ 1   0 Oct 22  2023 '$RQWOLZK.ini-save'
> -rwx--+ 1 254 Oct 22  2023 '$IQWOLZK.ini-save'
> -rwx--+ 1  82 Oct 22  2023 '$IVW0RM1'
> $ xxd -c8 -g8 /proc/cygdrive/d/\$Recycle.Bin/S-1-5-21-*-*-*-1001/\$IVW0RM1
> : 0200  # header (le)
> 0008:   # file size (le)
> 0010: e04bc8060b05da01  .K..# deleted time (le 100ns Windows)
> 0018: 1b0044003a00  D.:.# path length(le 4) path (4+ UCS-2)
> 0020: 5c00760061007200  \.v.a.r.
> 0028: 5c00630061006300  \.c.a.c.
> 0030: 680065005c007300  h.e.\.s.
> 0038: 6500740075007000  e.t.u.p.
> 0040: 5c00650074006300  \.e.t.c.
> 0048: 5c0070006b006900  \.p.k.i.
> 0050:   ..

I think the question was:
Does Cygwin have utilities which can restore the files from a script?
Or how can a user call powershell to do the job?

Mark
-- 
IT Infrastructure Consultant
Windows, Linux

-- 
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: How to use '$RECYCLE.BIN' to recover files?

[Brian Inglis via Cygwin]

On 2024-07-12 10:33, Tom Legrady via Cygwin wrote:
Using cygwin on Windows 11, I ran a command that was over-enthusiastic in 
deleting files. Now files I would like to have are in the $RECYCLE.BIN, with 
names like '$I0BEVIM.pdf'.


How can I restore these files' original name and path?


See:

https://en.wikipedia.org/wiki/Trash_(computing)#Microsoft_Windows

https://superuser.com/a/1736690

for low level details for Vista onwards: original file or directory hard linked 
in /proc/cygdrive/D/\$Recycle.Bin/S-1-5-21-*-*-*-UID/\$RXX.type and metadata 
saved in /proc/cygdrive/D/\$Recycle.Bin/S-1-5-21-*-*-*-UID/\$IXX.type where 
UID is often 1000 or 1001 with personal desktop local accounts, and you only 
have access to your own, unless elevated as admin, e.g.


$ ls -glort /proc/cygdrive/d/\$Recycle.Bin/S-1-5-21-*-*-*-1001/
total 3
-rwx--+ 1 129 Apr  2  2020  desktop.ini
drwxr-xr-x  1   0 Dec 12  2021 '$RVW0RM1'
-rw-r--r--+ 1   0 Oct 22  2023 '$RQWOLZK.ini-save'
-rwx--+ 1 254 Oct 22  2023 '$IQWOLZK.ini-save'
-rwx--+ 1  82 Oct 22  2023 '$IVW0RM1'
$ xxd -c8 -g8 /proc/cygdrive/d/\$Recycle.Bin/S-1-5-21-*-*-*-1001/\$IVW0RM1
: 0200  # header (le)
0008:   # file size (le)
0010: e04bc8060b05da01  .K..# deleted time (le 100ns Windows)
0018: 1b0044003a00  D.:.# path length(le 4) path (4+ UCS-2)
0020: 5c00760061007200  \.v.a.r.
0028: 5c00630061006300  \.c.a.c.
0030: 680065005c007300  h.e.\.s.
0038: 6500740075007000  e.t.u.p.
0040: 5c00650074006300  \.e.t.c.
0048: 5c0070006b006900  \.p.k.i.
0050:   ..

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: Follow up^^

[donaltwhite6896--- via Cygwin]

Hello,I am wondering if you got a  
chance to review my previous mail.Are you interested in Our  
Services?  Our price is so affordable.Please let me know the best  
time to reach you and your contact information.Thanks,style="font-size:14.6667px;font-family:Times New  
Roman,serif">Donaltclass="gmail_attr">On Wed, 10 Jul 2024 at 22:04, href="mailto:donaltwhite6...@gmail.com;>donaltwhite6...@gmail.com  
wrote:dir="ltr">style="margin-bottom:8pt;line-height:107%;font-family:Calibri;font-size:11pt">style="color:rgb(0,0,0);font-size:11pt">Hello,style="color:rgb(0,0,0);font-size:11pt">style="color:rgb(0,0,0);font-size:11pt">style="color:rgb(0,0,0);font-size:11pt">I hope youre doing  
well.class="MsoNormal"  
style="margin-bottom:8pt;line-height:107%;font-family:Calibri;font-size:11pt">style="color:rgb(0,0,0);font-size:11pt">I am pleased to provide you with a  
comprehensive proposal covering our offerings in Accounting, Bookkeeping,  
Financial Statements, Accounts Payable/Receivable, Payroll Processing,  
Financial Modelling, Tax Returns   CFO advisorystyle="color:rgb(0,0,0);font-size:11pt">style="margin-bottom:8pt;line-height:107%;font-family:Calibri;font-size:11pt">style="color:rgb(0,0,0);font-size:11pt">Please, could you let me know which  
services you are interested in hiring Dedicated Remote Accountants or  
Bookkeepers on full time or on hourly rates at a reasonable  
cost?class="MsoNormal"  
style="margin-bottom:8pt;line-height:107%;font-family:Calibri;font-size:11pt">style="color:rgb(0,0,0);font-size:11pt">Thanks,style="color:rgb(0,0,0);font-size:11pt">style="margin-bottom:8pt;line-height:107%;font-family:Calibri;font-size:11pt">style="font-family:Times New Roman,serif">Donaltstyle="color:rgb(0,0,0);font-size:11pt">

 
Email sent via href="https://gsuite.google.com/marketplace/app/simple_mass_mail_merge/1087023983878;>SM3


--
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 application hangs on closing console

[Takashi Yano via Cygwin]

On Fri, 12 Jul 2024 14:33:31 +0200
Johannes Khoshnazar-Thoma wrote:
> Am 03.07.24 um 16:09 schrieb Takashi Yano:
> > On Tue, 2 Jul 2024 19:45:15 +0900
> > Takashi Yano wrote:
> > I'll submit a patch for that and push it shortly.
> >
> Thank you so much for the fix. I built a cygwin1.dll containing
> your patch and forwarded it to our client. Tests are running
> since yesterday without any issues. Before after a few minutes
> the console_close() caused (at least) processes to hang for at
> least a few seconds.
> 
> We will keep the tests running over the weekend but I think we
> can assume that the hang in closing console is fixed.

Thanks for testing. If you could continue the test,
it is better to use head of cygwin-3_5-branch.

git clone https://cygwin.com/git/newlib-cygwin.git
cd newlib-cygwin
git switch cygwin-3_5-branch
winsup/autogen.sh
configure
make -j8

Then, copy x86_64-pc-cygwin/winsup/cygwin/new-cygwin1.dll to
your test environment.

> Thank you so much again, just wanted to ask: will you (and
> when) release cygwin DLL 3.5.4 shortly? Could you estimate
> when this will happen? Knowing that would help us in planning
> the next WinDRBD release (with the 3.5.4 cygwin DLL).

This is not under my control. :-)

Corinna, what do you think?
Some important fixes are now ready for 3.5.4. How about releasing
3.5.4 after the pipe fix?

-- 
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 application hangs on closing console

[Johannes Khoshnazar-Thoma via Cygwin]

Hi Takashi Yano,

Am 03.07.24 um 16:09 schrieb Takashi Yano:

On Tue, 2 Jul 2024 19:45:15 +0900
Takashi Yano wrote:
I'll submit a patch for that and push it shortly.


Thank you so much for the fix. I built a cygwin1.dll containing
your patch and forwarded it to our client. Tests are running
since yesterday without any issues. Before after a few minutes
the console_close() caused (at least) processes to hang for at
least a few seconds.

We will keep the tests running over the weekend but I think we
can assume that the hang in closing console is fixed.

Thank you so much again, just wanted to ask: will you (and
when) release cygwin DLL 3.5.4 shortly? Could you estimate
when this will happen? Knowing that would help us in planning
the next WinDRBD release (with the 3.5.4 cygwin DLL).

Best regards,

- Johannes

--
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: cygport - get package dependencies

[Brian Inglis via Cygwin]

On 2024-07-07 11:12, ASSI via Cygwin wrote:

Federico Kircheis via Cygwin writes:

I could move the REQUIRES from the cygport file to somewhere else and
use it only myself, but at that point, why not use the REQUIRES?


What you want might actually be BUILD_REQUIRES?


You need to know the BUILD_REQUIRES to be able to install the required devel 
library packages, and build tools which are not automatically installed as 
cygport dependencies, and to run Scallywag CI builds in GH Actions or Appveyor.


CI builds are useful as they run in pristine containers, so anything missing 
causes the build and/or tests to fail.


Look in the package README, INSTALL, or other build docs for build prereqs, and 
as we are affiliated via Sourceware with RedHat and Fedora and follow some of 
their approaches, look for latest Fedora Rawhide RPM specs for dependencies; if 
not Fedora, OpenSuSE Tumbleweed specs; otherwise Gentoo ebuild, Debian 
sid/unstable control + rules, or Arch PKGBUILD package build recipes, similar to 
cygport, and also any patches they provide, as they may be useful on Cygwin.


These are all accessible from repology.org by searching for a package, listing 
all platforms, and navigating from the package link beside each platform, until 
you find the package build source files.


You can refer to external source files and patches directly in cygport by 
appending to SRC_URI or PATCH_URI, linking directly to the *RAW* source files.


Given that you must know the build dependencies, you can follow the runtime 
dependencies by checking for any library packages provided and required by each 
of the devel packages in setup.ini (-S):


$ echo flac-devel, libao-devel, libavcodec-devel, libavformat-devel, 
libcddb-devel, libcdio_paranoia-devel, libdiscid-devel, libmad-devel, 
libmodplug-devel, libmpcdec-devel, libncurses-devel, libopusfile-devel, 
libpulse-devel, libsamplerate-devel, libvorbis-devel, libwavpack-devel | sed 
's/,//g' | xargs cygcheck-dep -cqSr

...

Then check for any (non-devel) packages needed by each of the library packages 
in setup.ini (-S):


$ cygcheck-dep -cqSn libFLAC{++10,12} libao{,4} libavcodec61 libavformat61 
libcddb2 libcdio_cdda2 libcdio_paranoia2 libdiscid0 libmad0 libmodplug1 
libmpcdec7 libncurses{,++}w10 libopusfile0 libpulse{-mainloop-glib,-simple,}0 
libsamplerate0 libvorbis{,0,enc2,file3} libwavpack1

...

which you may be able to simplify with some long command lines or short scripts.

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: SIGALRM is not interrupting a blocking write to a pipe

[Takashi Yano via Cygwin]

On Mon, 1 Jul 2024 20:43:28 +0900
Takashi Yano wrote:
> On Mon, 1 Jul 2024 20:40:38 +0900
> Takashi Yano wrote:
> > On Mon, 6 May 2024 23:01:49 +0300
> > ilya Basin wrote:
> > > I need your help with troubleshooting an issue with "pv": 
> > > https://codeberg.org/a-j-wood/pv/issues/87
> > > 
> > > This app uses SIGALRM to interrupt a blocking write to STDOUT and read 
> > > more data into the buffer.
> > > On Linuxes write() returns 0 after the signal, but on Cygwin even though 
> > > the signal handler is called, the write call does not return, at least 
> > > when writing to a pipe.
> > 
> > What Linux environment you assume? I run the STC below on Debuan GNU/Linux,
> > 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > 
> > void handler(int sig)
> > {
> > printf("sig=%d\n", sig);
> > }
> > 
> > int main()
> > {
> > int fd[2];
> > 
> > signal(SIGALRM, handler);
> > pipe(fd);
> > for (;;) {
> > int l = write(fd[1], "A", 1);
> > if (l == 1) {
> > printf("."); fflush(stdout); /* Normal */
> > } else {
> > printf("%d: %s\n", l, strerror(errno)); /* Interrupt */
> > }
> > }
> > }
> > 
> > but,
> > kill -ALRM 
> > does not make output /* Interrupt */ line, but only /* Normal */ line.
> 
> and
> sig=14
> as well.
> 
> > uname -a:
> > Linux debian2 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 
> > (2024-05-03) x86_64 GNU/Linux
> > 
> > The behaviour is same with cygwin.

I got it. signal() sets SA_RESTART flag which prevent write()
from interrupt. Without SA_RESTART, I can see the behaviour
difference between linux and cygwin.

Now we are discussing how to fix that problem. Thansk.

P.S.
Attached is the my second STC. The STC without argument behaves
differently on cygwin from linux.

-- 
Takashi Yano 
#include 
#include 
#include 
#include 
#include 
#include 

void handler(int sig)
{
	fprintf(stderr, "sig=%d\n", sig);
}

int main(int argc, char *argv[])
{
	int fd[2] = {0, 1};
	struct sigaction sa = {0,};

	sa.sa_handler = handler;
	if (argc > 1 && atoi(argv[1])) {
		sa.sa_flags = SA_RESTART;
	}
	sigaction(SIGALRM, , NULL);

	if (isatty(1)) {
		pipe(fd);
	}

	for (;;) {
		int l = write(fd[1], "A", 1);
		if (l == 1) {
			fprintf(stderr, "."); fflush(stderr);
		} else {
			fprintf(stderr, "%d: %s\n", l, strerror(errno));
		}
	}
}

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [ITP] cmocka 1.1.7 - C unit testing framework

[Jon Turney via Cygwin-apps]

On 10/07/2024 00:35, Brian Inglis via Cygwin-apps wrote:

Description:
Elegant unit testing framework for C with support for mock objects,
derived from Google Cmockery.

License:    Apache-2.0

I would like to provide a Cygwin package for cmocka, as it is now
required for testing my fortune-mod package.

For more information see the project home pages:

 https://cmocka.org

It is packaged by major Linux and BSD distros:

 https://repology.org/project/cmocka/versions

There is an error building the docs using doxygen, and that hangs, using
either cmake/make or cmake/ninja builds, locally and in GH CI (see
previous job 8341 - had to cancel after 3 hours), with current stable 
and a local build of the latest doxygen release, and an issue has been 
raised upstream.


I suspect this is a problem in cygwin.

There is (what sounds like) a similar problem when building libxcb's 
documentation, in that it gets stuck somewhere in doxygen, waiting for a 
load of dot.exe processes to finish even after they're all done.


I bisected that to working under 3.3.6 and failing under 3.4.0, but 
there's nothing obviously related in that interval, and I haven't found 
the time to bisect the commits...



For now, there is little justification to split into dll (40KB 1 file),
devel (100KB 8 files 2 dirs), doc (24KB 4 files 1 dir) packages, unless
for conformity, but can revisit if I can get docs built!


Since the DLL has a soversion number, not placing it in a separate 
package seems contraindicated.


(I take the point that we're *probably* not going to be packaging 
anything linked against is, but gratuitously breaking user-built 
executables linked against it if the soversion ever changes seems a bit 
mean... I guess maybe if we really think that's the only use-case, we 
should only build it as a static library?)

Re: Urgent gcc update to GCC 13.3

[Brian Inglis via Cygwin]

On 2024-07-09 00:17, Cedric Blancher via Cygwin wrote:

On Sat, 6 Jul 2024 at 21:55, Mark Liam Brown wrote:

Cygwin gcc is currently stuck at version 11.4:
$ gcc --version
gcc (GCC) 11.4.0
I would politely request an urgent update to GCC 13.3 (not 14.1, 13.3
is considered mature), as 11.4 causes severe problems:
1. Securly updates in the STL are not available in Cygwin
2. Everything relying on C++17, e.g. std::pmr::polymorphic_allocator,
does not work
3. Qt6 is not portable to Cygwin, which has a severe impact



I'd agree that newer gcc 13.x to compile Cygwin and as /usr/bin/gcc
would be a very good idea, not only for performance+STL fixes, but
also since by default the Cygwin distro lacks C++17 support, which VS
Studio has since VS 19.


As a rolling-release distro supported totally by volunteers, Cygwin does not 
support C or C++, only the current stable gcc compilers and libraries 
components, and g++ 11.4 supports -std=c++17, defaults to -std=gnu++17, with 
experimental -std=c/gnu++20 incompletely supported, some draft C++23 features 
supported by -std=c/gnu++2b, and various DRs resolved.


In g++ 12.4 (test - final GCC 12 release), C++17, and experimental C++20/C++23 
support is improved, and various DRs resolved, and this continues in g++ 13.2 
(test), where further experimental C++20 (library) and C++23 (compiler and 
library) improvements are supported, but there are no notes on DRs resolved.


Oh and guess what: Ada, C, Fortran, D, Objective C and Objective C++ compilers 
and libraries, and OpenAcc and OpenMP GPU offloading extensions, are supported 
and have to be upgraded successfully, as do the mingw64-i686 and mingw64-x86_64 
Cygwin Windows cross compilers and libraries, for each of those languages, in 
each of these releases, to allow them to be promoted to current stable.


It can take a lot of work and even more testing to get packages upgraded under 
Cygwin, in volunteers' spare time, sometimes requiring significant rebasing or 
reworking of Cygwin specific patches to get new releases running, support or 
functions added to newlib or Cygwin libc, days or weeks of upstream support 
interaction, including with upstream required build tool packages, sometimes 
requiring upstream fixes or synchronized build tool upgrades, which may involve 
other maintainers with their own timeframes.


So feel free to install and run test releases available, or even better: 
volunteer your time and effort to help upgrade the compilers, libraries, or 
other packages; SWHTDI!


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: Urgent gcc update to GCC 13.3

[Cedric Blancher via Cygwin]

On Sat, 6 Jul 2024 at 21:55, Mark Liam Brown via Cygwin
 wrote:
>
> Greetings!
>
> Cygwin gcc is currently stuck at version 11.4:
> $ gcc --version
> gcc (GCC) 11.4.0
>
> I would politely request an urgent update to GCC 13.3 (not 14.1, 13.3
> is considered mature), as 11.4 causes severe problems:
> 1. Securly updates in the STL are not available in Cygwin
> 2. Everything relying on C++17, e.g. std::pmr::polymorphic_allocator,
> does not work
> 3. Qt6 is not portable to Cygwin, which has a severe impact
>

I'd agree that newer gcc 13.x to compile Cygwin and as /usr/bin/gcc
would be a very good idea, not only for performance+STL fixes, but
also since by default the Cygwin distro lacks C++17 support, which VS
Studio has since VS 19.

Ced
-- 
Cedric Blancher 
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

-- 
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: bug? mintty with bash: tab key after semicolon char will hang

[Kevin Schnitzius via Cygwin]

 On Monday, July 8, 2024 at 10:17:37 PM EDT, Cyanryaku Ailet via Cygwin 
 wrote: 
> I typed a semicolon char and then pressed TAB key, then mintty hangs. It 
> can’t be closed even by Windows close button. 

Remove all the unavailable network shares from $PATH.  By default, tab is 
command completion.

Kevin

-- 
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: crontab: no changes made to crontab

[Andrey Repin via Cygwin]

Greetings, Brian Inglis via Cygwin!

> On 2024-07-06 04:50, Andrey Repin via Cygwin wrote:
>> I'm trying to install a new cron job, and the thing fails claiming that it
>> didn't see the edits I made to the file.

 # echo "USER=$USER" | crontab -

 # crontab -l
 # DO NOT EDIT THIS FILE - edit the master and reinstall.
 # (- installed on Sat Jul  6 13:35:43 2024)
 # (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie 
 Exp $)
 USER=anrdaemon

 # crontab -e
 ### do some edits…
 crontab: no changes made to crontab

> What is your editor, how is it configured, how is it invoked, and how are
> VISUAL and EDITOR defined?

> Most commands that use an editor for some commands effectively invoke 
> ${VISUAL:-${EDITOR:-vi}}.

My $EDITOR is a small wrapper script launching Far manager in editor mode.

>> cygstart "--directory=$( dirname "$1" )" --shownormal --wait -- 
>> "C:\\Programs\\Far3\\Far.exe" -i -co -e0:0 "$( cygpath -alw "${1:-.}" 2> 
>> /dev/null )"

> Your editor also has to behave as if it updates the temporary filename it is 
> invoked with, as from:

> $ mktemp --tmpdir crontab.XX

> for example /tmp/crontab.??, save changes into that file, and leave
> it changed when exiting, and other than nano's own /tmp/nano.?? files, I 
> see no special handling.

> The source has the following note:

> https://github.com/vixie/cron/blob/master/crontab.c#L389

> which assumes that editors rewrite original files rather than
> renaming/unlinking because that allows security issues, so it compares the
> fstat mtime to the saved value to detect changes.

But that has a potential of losing the file contents.

>> Piping a new file to the crontab works, but that's "slightly" cumbersome.
>> What is it missing why it does not want to just work?
>> -- Few moments later… ---
>> It seems crontab dislikes safe file writes.

> What do you mean by safe file writes?

Hardlink original to temp. name, write to a new file, rename to original,
delete temp. name only if write and rename was successful.
This is a core function in Far's builtin editor and is not configurable.

 $ stat x > 1; nano x; stat x > 2; diff -u0 1 2

 $ stat x > 1; $EDITOR x; stat x > 2; diff -u0 1 2

> What do these show?

That nano rewrites original, where Far does not.

> If you are using `nano`, that should work, as it is used in almost every
> example from RaspberryPi, and someone would have complained!
> Unless the Cygwin package config differs from the Debian config, and it does
> not appear to significantly.

Naay… nano works. Running `EDITOR=nano crontab -e` works around the issue.

>> Is there a way around it that does not involve replacing crontab tool with my
>> own script that has no such issue?

> See above to fix the issue, or use:

> $ $VISUAL $HOME/$USER.crontab
> $ crontab $HOME/$USER.crontab
> $ crontab -l

Figured as much, given the code comment you mentioned above.


-- 
With best regards,
Andrey Repin
Monday, July 8, 2024 01:08:52

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: crontab: no changes made to crontab

[Brian Inglis via Cygwin]

On 2024-07-06 04:50, Andrey Repin via Cygwin wrote:

I'm trying to install a new cron job, and the thing fails claiming that it
didn't see the edits I made to the file.



# echo "USER=$USER" | crontab -

# crontab -l
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (- installed on Sat Jul  6 13:35:43 2024)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
USER=anrdaemon

# crontab -e
### do some edits…
crontab: no changes made to crontab


What is your editor, how is it configured, how is it invoked, and how are VISUAL 
and EDITOR defined?


Most commands that use an editor for some commands effectively invoke 
${VISUAL:-${EDITOR:-vi}}.


For example, I run gvim under X, it backgrounds, so I have VISUAL='gvim -f' and 
EDITOR=vim so gvim stays in the foreground for crontab, git, etc. and the same 
process and PID is used as forked.

For cygport, it only looks at EDITOR, so in ~/.cygwin_aliases, I have:

alias cygport="EDITOR=\"$VISUAL\" cygport"

Your editor also has to behave as if it updates the temporary filename it is 
invoked with, as from:


$ mktemp --tmpdir crontab.XX

for example /tmp/crontab.??, save changes into that file, and leave it 
changed when exiting, and other than nano's own /tmp/nano.?? files, I see no 
special handling.


The source has the following note:

https://github.com/vixie/cron/blob/master/crontab.c#L389

which assumes that editors rewrite original files rather than renaming/unlinking 
because that allows security issues, so it compares the fstat mtime to the saved 
value to detect changes.



Piping a new file to the crontab works, but that's "slightly" cumbersome.
What is it missing why it does not want to just work?
-- Few moments later… ---
It seems crontab dislikes safe file writes.


What do you mean by safe file writes?


$ stat x > 1; nano x; stat x > 2; diff -u0 1 2



$ stat x > 1; $EDITOR x; stat x > 2; diff -u0 1 2


What do these show?

If you are using `nano`, that should work, as it is used in almost every example 
from RaspberryPi, and someone would have complained!
Unless the Cygwin package config differs from the Debian config, and it does not 
appear to significantly.



Is there a way around it that does not involve replacing crontab tool with my
own script that has no such issue?


See above to fix the issue, or use:

$ $VISUAL $HOME/$USER.crontab
$ crontab $HOME/$USER.crontab
$ crontab -l

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: crontab: no changes made to crontab

[Adam Dinwoodie via Cygwin]

On Sat, 6 Jul 2024 at 12:06, Andrey Repin via Cygwin  wrote:
> I'm trying to install a new cron job, and the thing fails claiming that it
> didn't see the edits I made to the file.
>
> 
>
> Is there a way around it that does not involve replacing crontab tool with my
> own script that has no such issue?

I don't have a solution that's not essentially your own script, but
FWIW if you install the moreutils package, the following Bash
one-liner will do the job and is what I use:

crontab -l | tail +4 | vipe | crontab -

I haven't bothered writing this as a script, and just have it in
memory as the command to use. Or, more accurately, the above without
the `tail` part, as I use Vim as my editor and just enter "d3d" as
soon as the window launches. If I were going to write a script,
though, I'd include that to save those extra three keystrokes…

-- 
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: cygport - get package dependencies

[ASSI via Cygwin]

Federico Kircheis via Cygwin writes:
> I could move the REQUIRES from the cygport file to somewhere else and
> use it only myself, but at that point, why not use the REQUIRES?

What you want might actually be BUILD_REQUIRES?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

-- 
Problem reports:  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: Urgent gcc update to GCC 13.3

[gs-cygwin.com--- via Cygwin]

On Sat, Jul 06, 2024 at 09:53:00PM +0200, Mark Liam Brown via Cygwin wrote:
> Greetings!
> 
> Cygwin gcc is currently stuck at version 11.4:
> $ gcc --version
> gcc (GCC) 11.4.0
> 
> I would politely request an urgent update to GCC 13.3 (not 14.1, 13.3
> is considered mature), as 11.4 causes severe problems:
> 1. Securly updates in the STL are not available in Cygwin
> 2. Everything relying on C++17, e.g. std::pmr::polymorphic_allocator,
> does not work
> 3. Qt6 is not portable to Cygwin, which has a severe impact
> 
> Mark
> -- 
> IT Infrastructure Consultant
> Windows, Linux

Greetings, Mark.

I take umbrage with excessive use of adjectives such as "urgent" and
"severe" when neither applies generically, and detailed context is
largely absent.

The subject line: "Urgent gcc update to GCC 13.3" is obnoxious, IMNSHO.

The gcc version in cygwin is not "sudden" news.

Why is this "urgent"?

What is this "severe impact" that someone "must" run qt6?

If some commercial product "needs" to run on Cygwin, apparently someone
failed to test on Cygwin during development and QA.

If this is "urgent" and "severe", then are you offering expert help
and/or offering to pay one of the cygwin volunteers to act in an
"urgent" manner to address this?

Prior to posting, have you looked at the list archives to see prior
discussions of the hurdles involved in updating the compiler?

I politely request that you please "urgently" adjust your expectations.
Cygwin largely exists through the time and effort of volunteers.

I am but one volunteer who maintains one package, and I speak only for
myself.

Cheers, Glenn

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [3.5.3] Application gets into WAIT MODE with error from sig_send signaling error from cygwin1.dll

[Takashi Yano]

On Fri, 5 Jul 2024 23:58:18 +0900
Takashi Yano  wrote:
> I mean Simple Test Case) in C langguate by STC.

"Simple Test Case in C language"

Sorry for typo.

-- 
Takashi Yano 

Re: [3.5.3] Application gets into WAIT MODE with error from sig_send signaling error from cygwin1.dll

[Takashi Yano]

On Fri, 5 Jul 2024 14:52:06 +
"Abinash Mohanty (amohanty)" wrote:
> STC was already attached with the email. Attaching again.

I mean Simple Test Case) in C langguate by STC.

-- 
Takashi Yano 

Re: [3.5.3] Application gets into WAIT MODE with error from sig_send signaling error from cygwin1.dll

[Takashi Yano]

On Fri, 5 Jul 2024 13:15:09 +
"Abinash Mohanty \(amohanty\) wrote:
> Hi,
> 
> Problem Statement
> Our application is getting into wait mode after running for some time and 
> Cygwin continues to throw the below  Exception Error:
> 1599350352 [sig] my_app 741 sig_send: error sending signal 11, pid 741, pipe 
> handle 0x130, nb 0, packsize 176, Win32 error 0
> 
> Problem Description
> We have initialized and used SIGUSR1, SIGALARAM and SIGPIPE signals in our 
> code. We are using below Cygwin APIs for initializing or adding the signals
>  sigset_t signal_set;
> 
>  sigemptyset(_set);
>  sigaddset(_set, SIGUSR1);
>  sigaddset(_set, SIGALRM);
>  sigaddset(_set, SIGPIPE);
> 
> 
> Masking the signals using  pthread_sigmask()
> 
> Catch the signals and process them
> void HandleSignals()
> {
> int sig_number;
> 
> for(;;) {
> 
> sig_wait(signal_set,sig_number);
> 
> switch(sig_number) {
> case SIGUSR1:
> {
> pthread_mutex_lock(_mutex);
> 
> //Handing the SIGUSR1 signals
> pthread_mutex_unlock(_mutex);
> }
> break;
> case SIGALRM:
> //Handing the SIGALRM signals
> break;
> default:
> break;
> } /* end switch */
> 
> }
> }
> 
> However after running my application multiple times which makes use of Cygwin 
> Signaling our application goes into WAIT MODE(probably waiting for signals) 
> and we get the  below error message continuously in our console.
> 1599350352 [sig] my_app 741 sig_send: error sending signal 11, pid 741, pipe 
> handle 0x130, nb 0, packsize 176, Win32 error 0
> 
> Our application is blocked due to this error and we are unable to proceed 
> further.
> Attaching strace logs and adding few error log here as well:-
> 
>   165 46400560 [main] my_app 6964 select_stuff::wait: m 4, us 10, 
> wmfo_timeout -1
>81 46400641 [socksel] my_app 6964 SetThreadName: SetThreadDescription() 
> failed.  1000
>   100 46400741 [socksel] my_app 6964 thread_socket: stuff_start 0x7B198, 
> timeout 4294967295
>58 46400799 [socksel] my_app 6964 peek_socket: read_ready: 0, write_ready: 
> 0, except_ready: 0
> 76569 46477368 [sig] my_app 6964 sigpacket::process: signal 30 processing
>86 46477454 [sig] my_app 6964 init_cygheap::find_tls: sig 30
> --- Process 5016 (pid: 6964), exception c005 at 7ffb486aaffa
>   162 46477616 [sig] my_app 6964 exception::handle: In cygwin_except_handler 
> exception 0xC005 at 0x7FFB486AAFFA sp 0x289C990
>36 46477652 [sig] my_app 6964 exception::handle: In cygwin_except_handler 
> signal 11 at 0x7FFB486AAFFA
>53 46477705 [sig] my_app 6964 break_here: break here
> --- Process 5016 (pid: 6964), exception c005 at 7ffb486aaffa
> --- Process 5016 (pid: 6964), exception c005 at 7ffb486aaffa
> --- Process 5016 (pid: 6964), exception c005 at 7ffb486aaffa
> --- Process 5016 (pid: 6964), exception c005 at 7ffb486aaffa
> --- Process 5016 (pid: 6964), exception c005 at 7ffb486aaffa
> --- Process 5016 (pid: 6964), exception c005 at 7ffb486aaffa
> --- Process 5016 (pid: 6964), exception c005 at 7ffb486aaffa
> --- Process 5016 (pid: 6964), exception c005 at 7ffb486aaffa
> --- Process 5016 (pid: 6964), exception c005 at 7ffb486aaffa
> --- Process 5016 (pid: 6964), exception c005 at 7ffb486aaffa
> 
> Also attaching the output of cygcheck -s -v -r > cygcheck.out
> 
> As this is a blocker issue for our application , quick resolution would 
> really help to proceed further.
> Please let us know if you need more information.

Full STC source code please.

-- 
Takashi Yano 

Re: ssh server vulnerable to regreSSHion?

[Brian Inglis via Cygwin]

On 2024-07-04 09:31, Tom Kent via Cygwin wrote:

For anyone not aware, a major, remotely exploitable, vulnerability has been
found in OpenSSH servers.

It has been assigned CVE-2024-6387 [1] and titled "regreSSHion" [2] because
it is actually a regression of a pair of early 2000s bugs:
CVE-2006-5051 and CVE-2008-4109.

The vulnerability is a race condition related to its interaction with
glibc. Because of the way cygwin is built, it isn't clear to me if this is
something that could possibly be impacting or not, thus I wanted to see if
smarter heads could identify if this is a potential (or actual) issue.

Either way, it might be nice to get a determination posted somewhere for
people to find, as I expect there will be more out there wondering about
this in the next days/weeks.


If you subscribed to Cygwin Announce mailing list

https://cygwin.com/mailman/listinfo/cygwin-announce

https://inbox.sourceware.org/cygwin-announce/

you would have seen the openssh 9.8p1-1 upgrade announcement

https://cygwin.com/pipermail/cygwin-announce/2024-July/011846.html

https://inbox.sourceware.org/cygwin-announce/20240702194232.2039121-1-corinna-cyg...@cygwin.com

which should take care of any potential issues whether vulnerable or not.

The Cygwin OpenSSH maintainer was also involved in pre-release testing:

https://marc.info/?l=openssh-unix-dev=171956630724852=2

validated the release, and caught an out-of-tree build test bug, so they are 
taking care on Cygwin, as Cygwin developers and package maintainers are likely 
to be dependent on OpenSSH servers and clients.


The regression issues are dependent on how certain libc functions are 
implemented and used, in Cygwin's case by newlib and/or Cygwin functions.
Other newlib and other libc, like musl, hosted implementations may have similar 
or independent issues.
Certainly Ubuntu and Debian (both 32 bit) have similar issues with significant 
differences.

As the OpenSSH announcement included above says:
"Exploitation on 64-bit systems is believed to be possible but has not been 
demonstrated at this time."
It requires weak ALSR applied to sshd and async-signal-unsafe syslog() calling 
malloc() allowing it to be be vulnerable to a race condition exploitable by 
SIGALARM, for the demonstrated vulnerability.


The ObscureKeystrokeTiming password timing attack is assigned as:

https://www.cve.org/CVERecord?id=CVE-2024-39894


[1] https://www.cve.org/CVERecord?id=CVE-2024-6387
[2]
https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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 application hangs on closing console

[Johannes Khoshnazar-Thoma via Cygwin]

Hi Takashi Yano,

Am 03.07.24 um 16:09 schrieb Takashi Yano:

On Tue, 2 Jul 2024 19:45:15 +0900
Takashi Yano wrote:

On Mon, 1 Jul 2024 22:20:20 +0900
Takashi Yano wrote:

On Mon, 1 Jul 2024 13:47:56 +0200
Johannes Khoshnazar-Thoma wrote:

Note that the hang does not happen when just running cygwin
applications via terminal windows (like cmd, powershell and
MinTTY). It triggers however when a cygwin application is
run both as a service (I think as SYSTEM account, but I
can ask again) and from a terminal window.


Service process usually does not have console. So I think
fhandler_console::open()/close() are not called.

Do you allocate console for your service process somehow?


I could reproduce your problem by allocating console for
service process.

I'll look into the problem. Thanks.


The cause has been clear. As a result, your points and patches
were very spot on.

get_minor() retuns unique number for each console in a session,
but not unique accross sessions. I looked over that point.

This is because EnumWindows(), which is used to look for console
windows, cannot enumerate windows accross sessions. This causes
conflict on shared name between sessions (e.g. sessions of different
users, different services, a service and a user session, etc.).

I'll use GetConsoleWindow() instead of get_minor() to create
shared name.

Thank you very much for finding this problem.
I'll submit a patch for that and push it shortly.


Thank you very much that is awesome news. I will build and
forward a package to our client to verify that this issue
is fixed now as soon as the patch is pushed.

Thanks again for your hard work on cygwin, it is hard to find
bugs in there because there are not that many ... :)

Best regards,

- Johannes

--
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 application hangs on closing console

[Takashi Yano via Cygwin]

On Tue, 2 Jul 2024 19:45:15 +0900
Takashi Yano wrote:
> On Mon, 1 Jul 2024 22:20:20 +0900
> Takashi Yano wrote:
> > On Mon, 1 Jul 2024 13:47:56 +0200
> > Johannes Khoshnazar-Thoma wrote:
> > > Note that the hang does not happen when just running cygwin
> > > applications via terminal windows (like cmd, powershell and
> > > MinTTY). It triggers however when a cygwin application is
> > > run both as a service (I think as SYSTEM account, but I
> > > can ask again) and from a terminal window.
> > 
> > Service process usually does not have console. So I think
> > fhandler_console::open()/close() are not called.
> > 
> > Do you allocate console for your service process somehow?
> 
> I could reproduce your problem by allocating console for
> service process.
> 
> I'll look into the problem. Thanks.

The cause has been clear. As a result, your points and patches
were very spot on.

get_minor() retuns unique number for each console in a session,
but not unique accross sessions. I looked over that point.

This is because EnumWindows(), which is used to look for console
windows, cannot enumerate windows accross sessions. This causes
conflict on shared name between sessions (e.g. sessions of different
users, different services, a service and a user session, etc.).

I'll use GetConsoleWindow() instead of get_minor() to create
shared name.

Thank you very much for finding this problem.
I'll submit a patch for that and push it shortly.

-- 
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 application hangs on closing console

[Takashi Yano via Cygwin]

On Mon, 1 Jul 2024 22:20:20 +0900
Takashi Yano wrote:
> On Mon, 1 Jul 2024 13:47:56 +0200
> Johannes Khoshnazar-Thoma wrote:
> > Note that the hang does not happen when just running cygwin
> > applications via terminal windows (like cmd, powershell and
> > MinTTY). It triggers however when a cygwin application is
> > run both as a service (I think as SYSTEM account, but I
> > can ask again) and from a terminal window.
> 
> Service process usually does not have console. So I think
> fhandler_console::open()/close() are not called.
> 
> Do you allocate console for your service process somehow?

I could reproduce your problem by allocating console for
service process.

I'll look into the problem. 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: cygwin application hangs on closing console

[Takashi Yano via Cygwin]

On Mon, 1 Jul 2024 13:47:56 +0200
Johannes Khoshnazar-Thoma wrote:
> Could you maybe point to the place in the cygwin (winsup)
> source code where the minor is allocated?

As for console, fhandler_console::set_unit() does that.

-- 
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 application hangs on closing console

[Takashi Yano via Cygwin]

On Mon, 1 Jul 2024 13:47:56 +0200
Johannes Khoshnazar-Thoma wrote:
> Note that the hang does not happen when just running cygwin
> applications via terminal windows (like cmd, powershell and
> MinTTY). It triggers however when a cygwin application is
> run both as a service (I think as SYSTEM account, but I
> can ask again) and from a terminal window.

Service process usually does not have console. So I think
fhandler_console::open()/close() are not called.

Do you allocate console for your service process somehow?

-- 
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 application hangs on closing console

[Johannes Khoshnazar-Thoma via Cygwin]

Hi Takashi Yano,

Thank you for your reply, comments inline.

Am 28.06.24 um 17:32 schrieb Takashi Yano via Cygwin:

On Fri, 28 Jun 2024 21:17:26 +0900
Takashi Yano wrote:

Sorry for very late replay.

No problem we are all sometimes very busy :)



On Mon, 3 Jun 2024 15:20:32 +0200
Johannes Khoshnazar-Thoma wrote:

We did more testing and it looks like the name of the event
that signals console master thread start and end is shared between
unrelated processes (it uses the console minor which is always (?)
0 when running from a powershell).

So since it is a two-state event (as opposed to a semaphore)
in theory the following can happen:

Process A   Process B
SetEvent(e)
SetEvent(e)
Waitforevent(e)
Waitforevent(e)


This should not happen. Master thread is unique to console.
get_minor() number is always 0 for the first opened console.
If you open another powershell window and start cygwin process
while the first cygwin process is still active, the get_minor()
returns 1.

Waiting for thread_sync_event is executed only
   if (shared_console_info[unit] && con.owner == myself->pid)
con.owner is in the shared memory which is shared among all
processes started in the same console. Therefore, only the
one process start to wait the event.


The second SetEvent does nothing. As a result the
later Waitforevent is stuck (which is what we observe).

So the question is: why should this event be used in
unrelated cygwin processes? Is there a technical reason
we don't understand (yet) for doing that (sharing the event).

We patched cygwin to use pseudo random event names (the
tm_usec field of gettimeofday()) and the stuckness vanished.
So unless there is a reason for sharing the event between
cygwin processes this patch should work:


Do you really confirm that your patch resolves the issue?
If so, the cause might be some kind of race issue.



This patch solved the issue for our case. It was running for
3 days (instead of about 30 minutes) and the hang in console
close did not trigger.

Note that the hang does not happen when just running cygwin
applications via terminal windows (like cmd, powershell and
MinTTY). It triggers however when a cygwin application is
run both as a service (I think as SYSTEM account, but I
can ask again) and from a terminal window.


There was similar bug in cygwin 3.5.1, however, it has been
already fixed in 3.5.3.
https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=fc5e9525453fea7c27b0e13635ae54abaa0db69d

I believe your problem is reproducible with 3.5.3. Right?


Yes it is. We did long running tests and it is reproducible
with 3.5.3. I also did tests that force the minor being the
same for two cygwin processes (by patching the source code)
and the hang also triggers (after a few minutes).

So can it be that separate cygwin processes can have the
same minor? For example when on is started as a service
and the other is started interactively?

Could you maybe point to the place in the cygwin (winsup)
source code where the minor is allocated?

Thanks again for your hard work on cygwin.

Best regards,

- Johannes

--
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: SIGALRM is not interrupting a blocking write to a pipe

[Takashi Yano via Cygwin]

On Mon, 1 Jul 2024 20:40:38 +0900
Takashi Yano wrote:
> On Mon, 6 May 2024 23:01:49 +0300
> ilya Basin wrote:
> > I need your help with troubleshooting an issue with "pv": 
> > https://codeberg.org/a-j-wood/pv/issues/87
> > 
> > This app uses SIGALRM to interrupt a blocking write to STDOUT and read more 
> > data into the buffer.
> > On Linuxes write() returns 0 after the signal, but on Cygwin even though 
> > the signal handler is called, the write call does not return, at least when 
> > writing to a pipe.
> 
> What Linux environment you assume? I run the STC below on Debuan GNU/Linux,
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> void handler(int sig)
> {
>   printf("sig=%d\n", sig);
> }
> 
> int main()
> {
>   int fd[2];
> 
>   signal(SIGALRM, handler);
>   pipe(fd);
>   for (;;) {
>   int l = write(fd[1], "A", 1);
>   if (l == 1) {
>   printf("."); fflush(stdout); /* Normal */
>   } else {
>   printf("%d: %s\n", l, strerror(errno)); /* Interrupt */
>   }
>   }
> }
> 
> but,
> kill -ALRM 
> does not make output /* Interrupt */ line, but only /* Normal */ line.

and
sig=14
as well.

> uname -a:
> Linux debian2 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 
> (2024-05-03) x86_64 GNU/Linux
> 
> The behaviour is same with cygwin.

-- 
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: SIGALRM is not interrupting a blocking write to a pipe

[Takashi Yano via Cygwin]

On Mon, 6 May 2024 23:01:49 +0300
ilya Basin wrote:
> I need your help with troubleshooting an issue with "pv": 
> https://codeberg.org/a-j-wood/pv/issues/87
> 
> This app uses SIGALRM to interrupt a blocking write to STDOUT and read more 
> data into the buffer.
> On Linuxes write() returns 0 after the signal, but on Cygwin even though the 
> signal handler is called, the write call does not return, at least when 
> writing to a pipe.

What Linux environment you assume? I run the STC below on Debuan GNU/Linux,

#include 
#include 
#include 
#include 
#include 
#include 

void handler(int sig)
{
printf("sig=%d\n", sig);
}

int main()
{
int fd[2];

signal(SIGALRM, handler);
pipe(fd);
for (;;) {
int l = write(fd[1], "A", 1);
if (l == 1) {
printf("."); fflush(stdout); /* Normal */
} else {
printf("%d: %s\n", l, strerror(errno)); /* Interrupt */
}
}
}

but,
kill -ALRM 
does not make output /* Interrupt */ line, but only /* Normal */ line.

uname -a:
Linux debian2 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 
(2024-05-03) x86_64 GNU/Linux

The behaviour is same with cygwin.

-- 
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: ssh-add -l hangs under cygwin test 3.6.0-0.139.g...

[Takashi Yano via Cygwin]

On Mon, 1 Jul 2024 17:43:53 +0900
Takashi Yano wrote:
> On Sun, 30 Jun 2024 22:55:22 +0900
> Takashi Yano wrote:
> > On Sun, 30 Jun 2024 20:33:19 +0900
> > jojelino wrote:
> > > On 6/29/2024 2:39 PM, Brian Inglis via Cygwin wrote:
> > > > Reran cygport --debug upload and command hanging was ssh-add -l!
> > > > 
> > >296   72109 [main] ssh-add 63275 win32env_to_cygenv: 0xA000232E0: 
> > > TERM_PROGRAM=mintty
> > >189   72298 [main] ssh-add 63275 win32env_to_cygenv: 0xA00023300: 
> > > TERM_PROGRAM_VERSION=3.7.1
> > > 
> > > I was able to reproduce this problem by entering below command with 
> > > ffmpeg from https://www.gyan.dev/ffmpeg/builds/ , this ffmpeg build 
> > > spams putc. So, without piping its output to `tee', It would not 
> > > possible track down any cause among lengthy trace output.
> > > 
> > > strace mintty -e /bin/timeout 10 sh -c './ffmpeg -h full|& tee'
> > > 
> > > In summary, When `timeout' expires, `timeout' signals SIGHUP to pgrp of 
> > > itself, btw some member of the pgrp may have acquired any of 
> > > synchronization object of some part of cygwin internal when a member 
> > > process of the pgrp did encounter the signal interrupt from `timeout'. 
> > > In my case it was output_mutex of pty.
> > > 
> > >   1565 10693297 [main] timeout 745 kill_pgrp: pid 0, signal 15
> > >   2701 15224348 [main] mintty 744 
> > > fhandler_pty_master::process_slave_output: bytes read 256
> > >   1736 9525442 [sig] sh 746 proc_subproc: args: 4, 1
> > >   3137 6700294 [main] tee 748 fhandler_pty_slave::write: pty5, 
> > > write(0x7C780, 1024)
> > >   1347 9526789 [sig] sh 746 proc_subproc: clear waiting threads
> > >   2084 15226432 [main] mintty 744 
> > > fhandler_pty_master::process_slave_output: returning 256
> > >   1110 6701404 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
> > > output_mutex (0x4C0): waiti
> > > -1 ms
> > >732 9527521 [sig] sh 746 checkstate: child_procs count 2
> > >   3648 10696945 [main] timeout 745 open_shared: name cygpid.724, shared 
> > > 0x1A005 (wanted 0x1A
> > > ), h 0x16C, m 6, created 0
> > >   1055 6702459 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
> > > output_mutex: acquired
> > > 
> > >   2092 15753306 [main] mintty 744 fhandler_pty_master::close: (2095): 
> > > pty output_mutex (0x4AC):
> > > ting -1 ms
> > > 
> > > And below is a location where `tee' did hang.
> > > 
> > > #3  0x7ffd0e408fdf in fhandler_pty_slave::write (this=0x89a10,
> > >  ptr=0x7c780, len=)
> > >  at ../../.././winsup/cygwin/fhandler/pty.cc:1268
> > > 1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
> > > false,
> > > (gdb)  li
> > > 1263  termios_printf ("pty%d, write(%p, %lu)", get_minor (), ptr, 
> > > len);
> > > 1264
> > > 1265  push_process_state process_state (PID_TTYOU);
> > > 1266
> > > 1267  acquire_output_mutex (mutex_timeout);
> > > 1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
> > > false,
> > > 1269 get_ttyp (), is_nonblocking ()))
> > > 
> > > 
> > > I ended up prepending two CancelIo call just above of 
> > > acquire_output_mutex located in fhandler_pty_master::close of pty.cc.
> > > 
> > >  >  CancelIo(get_ttyp()->to_master());
> > >  >  CancelIo(get_ttyp()->to_master_nat());
> > > acquire_output_mutex (mutex_timeout);
> > > 
> > > Hope it helps
> > 
> > I cannot reproduce the issue.
> > 
> > 1) Which cygwin version do you use?
> > 2) Is this really the same problem with the problem original post reported?
> >(i.e. reproducible with 3.6.0-0.139 and not reproduced with 3.5.3)
> 
> I could reproduce this (the problem reported by jojelino) by:
> mintty -e timeout 1 dash -c 'yes  | cat'
> 
> This also occurs with cygwin 3.5.3, so it's another problem than Brian 
> reported.
> 
> This does not occur by:
> mintty -e timeout 1 dash -c 'yes '
> mintty -e timeout 1 tcsh -c 'yes  | cat'
> script /dev/null -c timeout 1 dash -c 'yes  | 
> cat'
> 
> I looked into this probelm and found the cause.
> 
> When the child process (timeout) is terminated, mintty seems to stop reading
> pty master even if yes or cat still alive. (Is this right? >> Thomas)
> (This behaviour seems to be a side efect of patch_319(?) in mintty.)
> 
> If the the pipe used to transfer output from pty slave to pty master is full
> due to lack of master reader, WriteFile() to the pipe is blocked. WriteFile()
> cannot be canceled by cygwin signal, therefore, pty slave hangs.
> 
> I'll submit and push a patch to fix this.
> 
> Thanks for finding this issue. >> jojelino

Please test cygwin-3.6.0-0.145.gc4fb5da27876

Cygwin 3.5.4 will come with this fix.

-- 
Takashi Yano 

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:

Re: ssh-add -l hangs under cygwin test 3.6.0-0.139.g...

[Takashi Yano via Cygwin]

On Sun, 30 Jun 2024 22:55:22 +0900
Takashi Yano wrote:
> On Sun, 30 Jun 2024 20:33:19 +0900
> jojelino wrote:
> > On 6/29/2024 2:39 PM, Brian Inglis via Cygwin wrote:
> > > Reran cygport --debug upload and command hanging was ssh-add -l!
> > > 
> >296   72109 [main] ssh-add 63275 win32env_to_cygenv: 0xA000232E0: 
> > TERM_PROGRAM=mintty
> >189   72298 [main] ssh-add 63275 win32env_to_cygenv: 0xA00023300: 
> > TERM_PROGRAM_VERSION=3.7.1
> > 
> > I was able to reproduce this problem by entering below command with 
> > ffmpeg from https://www.gyan.dev/ffmpeg/builds/ , this ffmpeg build 
> > spams putc. So, without piping its output to `tee', It would not 
> > possible track down any cause among lengthy trace output.
> > 
> > strace mintty -e /bin/timeout 10 sh -c './ffmpeg -h full|& tee'
> > 
> > In summary, When `timeout' expires, `timeout' signals SIGHUP to pgrp of 
> > itself, btw some member of the pgrp may have acquired any of 
> > synchronization object of some part of cygwin internal when a member 
> > process of the pgrp did encounter the signal interrupt from `timeout'. 
> > In my case it was output_mutex of pty.
> > 
> >   1565 10693297 [main] timeout 745 kill_pgrp: pid 0, signal 15
> >   2701 15224348 [main] mintty 744 
> > fhandler_pty_master::process_slave_output: bytes read 256
> >   1736 9525442 [sig] sh 746 proc_subproc: args: 4, 1
> >   3137 6700294 [main] tee 748 fhandler_pty_slave::write: pty5, 
> > write(0x7C780, 1024)
> >   1347 9526789 [sig] sh 746 proc_subproc: clear waiting threads
> >   2084 15226432 [main] mintty 744 
> > fhandler_pty_master::process_slave_output: returning 256
> >   1110 6701404 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
> > output_mutex (0x4C0): waiti
> > -1 ms
> >732 9527521 [sig] sh 746 checkstate: child_procs count 2
> >   3648 10696945 [main] timeout 745 open_shared: name cygpid.724, shared 
> > 0x1A005 (wanted 0x1A
> > ), h 0x16C, m 6, created 0
> >   1055 6702459 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
> > output_mutex: acquired
> > 
> >   2092 15753306 [main] mintty 744 fhandler_pty_master::close: (2095): 
> > pty output_mutex (0x4AC):
> > ting -1 ms
> > 
> > And below is a location where `tee' did hang.
> > 
> > #3  0x7ffd0e408fdf in fhandler_pty_slave::write (this=0x89a10,
> >  ptr=0x7c780, len=)
> >  at ../../.././winsup/cygwin/fhandler/pty.cc:1268
> > 1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
> > false,
> > (gdb)  li
> > 1263  termios_printf ("pty%d, write(%p, %lu)", get_minor (), ptr, len);
> > 1264
> > 1265  push_process_state process_state (PID_TTYOU);
> > 1266
> > 1267  acquire_output_mutex (mutex_timeout);
> > 1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
> > false,
> > 1269 get_ttyp (), is_nonblocking ()))
> > 
> > 
> > I ended up prepending two CancelIo call just above of 
> > acquire_output_mutex located in fhandler_pty_master::close of pty.cc.
> > 
> >  >CancelIo(get_ttyp()->to_master());
> >  >CancelIo(get_ttyp()->to_master_nat());
> >   acquire_output_mutex (mutex_timeout);
> > 
> > Hope it helps
> 
> I cannot reproduce the issue.
> 
> 1) Which cygwin version do you use?
> 2) Is this really the same problem with the problem original post reported?
>(i.e. reproducible with 3.6.0-0.139 and not reproduced with 3.5.3)

I could reproduce this (the problem reported by jojelino) by:
mintty -e timeout 1 dash -c 'yes  | cat'

This also occurs with cygwin 3.5.3, so it's another problem than Brian reported.

This does not occur by:
mintty -e timeout 1 dash -c 'yes '
mintty -e timeout 1 tcsh -c 'yes  | cat'
script /dev/null -c timeout 1 dash -c 'yes  | 
cat'

I looked into this probelm and found the cause.

When the child process (timeout) is terminated, mintty seems to stop reading
pty master even if yes or cat still alive. (Is this right? >> Thomas)
(This behaviour seems to be a side efect of patch_319(?) in mintty.)

If the the pipe used to transfer output from pty slave to pty master is full
due to lack of master reader, WriteFile() to the pipe is blocked. WriteFile()
cannot be canceled by cygwin signal, therefore, pty slave hangs.

I'll submit and push a patch to fix this.

Thanks for finding this issue. >> jojelino

-- 
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: ssh-add -l hangs under cygwin test 3.6.0-0.139.g...

[Takashi Yano via Cygwin]

On Sun, 30 Jun 2024 20:33:19 +0900
jojelino wrote:
> On 6/29/2024 2:39 PM, Brian Inglis via Cygwin wrote:
> > Reran cygport --debug upload and command hanging was ssh-add -l!
> > 
>296   72109 [main] ssh-add 63275 win32env_to_cygenv: 0xA000232E0: 
> TERM_PROGRAM=mintty
>189   72298 [main] ssh-add 63275 win32env_to_cygenv: 0xA00023300: 
> TERM_PROGRAM_VERSION=3.7.1
> 
> I was able to reproduce this problem by entering below command with 
> ffmpeg from https://www.gyan.dev/ffmpeg/builds/ , this ffmpeg build 
> spams putc. So, without piping its output to `tee', It would not 
> possible track down any cause among lengthy trace output.
> 
> strace mintty -e /bin/timeout 10 sh -c './ffmpeg -h full|& tee'
> 
> In summary, When `timeout' expires, `timeout' signals SIGHUP to pgrp of 
> itself, btw some member of the pgrp may have acquired any of 
> synchronization object of some part of cygwin internal when a member 
> process of the pgrp did encounter the signal interrupt from `timeout'. 
> In my case it was output_mutex of pty.
> 
>   1565 10693297 [main] timeout 745 kill_pgrp: pid 0, signal 15
>   2701 15224348 [main] mintty 744 
> fhandler_pty_master::process_slave_output: bytes read 256
>   1736 9525442 [sig] sh 746 proc_subproc: args: 4, 1
>   3137 6700294 [main] tee 748 fhandler_pty_slave::write: pty5, 
> write(0x7C780, 1024)
>   1347 9526789 [sig] sh 746 proc_subproc: clear waiting threads
>   2084 15226432 [main] mintty 744 
> fhandler_pty_master::process_slave_output: returning 256
>   1110 6701404 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
> output_mutex (0x4C0): waiti
> -1 ms
>732 9527521 [sig] sh 746 checkstate: child_procs count 2
>   3648 10696945 [main] timeout 745 open_shared: name cygpid.724, shared 
> 0x1A005 (wanted 0x1A
> ), h 0x16C, m 6, created 0
>   1055 6702459 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
> output_mutex: acquired
> 
>   2092 15753306 [main] mintty 744 fhandler_pty_master::close: (2095): 
> pty output_mutex (0x4AC):
> ting -1 ms
> 
> And below is a location where `tee' did hang.
> 
> #3  0x7ffd0e408fdf in fhandler_pty_slave::write (this=0x89a10,
>  ptr=0x7c780, len=)
>  at ../../.././winsup/cygwin/fhandler/pty.cc:1268
> 1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
> false,
> (gdb)  li
> 1263  termios_printf ("pty%d, write(%p, %lu)", get_minor (), ptr, len);
> 1264
> 1265  push_process_state process_state (PID_TTYOU);
> 1266
> 1267  acquire_output_mutex (mutex_timeout);
> 1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
> false,
> 1269 get_ttyp (), is_nonblocking ()))
> 
> 
> I ended up prepending two CancelIo call just above of 
> acquire_output_mutex located in fhandler_pty_master::close of pty.cc.
> 
>  >  CancelIo(get_ttyp()->to_master());
>  >  CancelIo(get_ttyp()->to_master_nat());
> acquire_output_mutex (mutex_timeout);
> 
> Hope it helps

I cannot reproduce the issue.

1) Which cygwin version do you use?
2) Is this really the same problem with the problem original post reported?
   (i.e. reproducible with 3.6.0-0.139 and not reproduced with 3.5.3)

-- 
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: ssh-add -l hangs under cygwin test 3.6.0-0.139.g...

[jojelino via Cygwin]

On 6/29/2024 2:39 PM, Brian Inglis via Cygwin wrote:

Reran cygport --debug upload and command hanging was ssh-add -l!

  296   72109 [main] ssh-add 63275 win32env_to_cygenv: 0xA000232E0: 
TERM_PROGRAM=mintty
  189   72298 [main] ssh-add 63275 win32env_to_cygenv: 0xA00023300: 
TERM_PROGRAM_VERSION=3.7.1


I was able to reproduce this problem by entering below command with 
ffmpeg from https://www.gyan.dev/ffmpeg/builds/ , this ffmpeg build 
spams putc. So, without piping its output to `tee', It would not 
possible track down any cause among lengthy trace output.


strace mintty -e /bin/timeout 10 sh -c './ffmpeg -h full|& tee'

In summary, When `timeout' expires, `timeout' signals SIGHUP to pgrp of 
itself, btw some member of the pgrp may have acquired any of 
synchronization object of some part of cygwin internal when a member 
process of the pgrp did encounter the signal interrupt from `timeout'. 
In my case it was output_mutex of pty.


 1565 10693297 [main] timeout 745 kill_pgrp: pid 0, signal 15
 2701 15224348 [main] mintty 744 
fhandler_pty_master::process_slave_output: bytes read 256

 1736 9525442 [sig] sh 746 proc_subproc: args: 4, 1
 3137 6700294 [main] tee 748 fhandler_pty_slave::write: pty5, 
write(0x7C780, 1024)

 1347 9526789 [sig] sh 746 proc_subproc: clear waiting threads
 2084 15226432 [main] mintty 744 
fhandler_pty_master::process_slave_output: returning 256
 1110 6701404 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
output_mutex (0x4C0): waiti

-1 ms
  732 9527521 [sig] sh 746 checkstate: child_procs count 2
 3648 10696945 [main] timeout 745 open_shared: name cygpid.724, shared 
0x1A005 (wanted 0x1A

), h 0x16C, m 6, created 0
 1055 6702459 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
output_mutex: acquired


 2092 15753306 [main] mintty 744 fhandler_pty_master::close: (2095): 
pty output_mutex (0x4AC):

ting -1 ms

And below is a location where `tee' did hang.

#3  0x7ffd0e408fdf in fhandler_pty_slave::write (this=0x89a10,
ptr=0x7c780, len=)
at ../../.././winsup/cygwin/fhandler/pty.cc:1268
1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
false,

(gdb)  li
1263  termios_printf ("pty%d, write(%p, %lu)", get_minor (), ptr, len);
1264
1265  push_process_state process_state (PID_TTYOU);
1266
1267  acquire_output_mutex (mutex_timeout);
1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
false,

1269 get_ttyp (), is_nonblocking ()))


I ended up prepending two CancelIo call just above of 
acquire_output_mutex located in fhandler_pty_master::close of pty.cc.


>  CancelIo(get_ttyp()->to_master());
>  CancelIo(get_ttyp()->to_master_nat());
  acquire_output_mutex (mutex_timeout);

Hope it helps


--
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: ssh-add -l hangs under cygwin test 3.6.0-0.139.g...

[Andrey Repin via Cygwin]

Greetings, Brian Inglis via Cygwin!

>> I have experienced otherwise inexplicable hangs of ssh that have been 
>> resolved
>> by killing ssh-agent and restarting it. This doesn't happen very often, so 
>> it is
>> usually mystifying when it does occur -- until I remember.

> I have *NEVER* had *ANY* issues using (Open)ssh etc. for remote login,
> shell, commands, file trees, or git (and earlier vcs) access, professionally
> and personally, over many years, releases, and systems, mainly from
> Cygwin/-X shells and sessions (due to using mainly Windows desktops with
> various Unix servers), with/out authorized_keys, passphrases, and/or
> keychain, until these recent instances under the test build.

Notebook goes to sleep with agent running.
Notebook comes from sleep a few days later.
Any request to agent hangs infinitely.

I have a guard script running that kill and restart the agent every hour if
it is not responding within five seconds.

This is not 100% reproducible, and hard to test due to timing issue, but the
pattern is very noticeable.


-- 
With best regards,
Andrey Repin
Sunday, June 30, 2024 11:42:51

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: ssh-add -l hangs under cygwin test 3.6.0-0.139.g...

[Norton Allen via Cygwin]

On 6/29/2024 8:21 PM, Norton Allen via Cygwin wrote:


On 6/29/2024 5:29 PM, Brian Inglis via Cygwin wrote:

On 2024-06-29 14:20, Norton Allen via Cygwin wrote:

On 6/29/2024 1:39 AM, Brian Inglis via Cygwin wrote:
Installed cygwin test to try to diagnose another issue - but not 
involved there.

Attempting to cygport upload - just hung without start ftp connection.
Reran cygport --debug upload and command hanging was ssh-add -l!
Confirmed by rerunning command ssh-add -l from bash.
Killed eventually with series of ctrl-C and ctrl-\.
Reran under strace and output log attached.
No version or help output from ssh-add so:
$ ssh -V
OpenSSH_9.7p1, OpenSSL 3.0.14 4 Jun 2024
After running setup and reinstalling 3.5.3, ssh-add -l works 
normally, and cygport upload succeeds to ftp package.

Only variable was the cygwin version installed.


I have experienced otherwise inexplicable hangs of ssh that have 
been resolved by killing ssh-agent and restarting it. This doesn't 
happen very often, so it is usually mystifying when it does occur -- 
until I remember.


I have *NEVER* had *ANY* issues using (Open)ssh etc. for remote 
login, shell, commands, file trees, or git (and earlier vcs) access, 
professionally and personally, over many years, releases, and 
systems, mainly from Cygwin/-X shells and sessions (due to using 
mainly Windows desktops with various Unix servers), with/out 
authorized_keys, passphrases, and/or keychain, until these recent 
instances under the test build.


I'm not above suspecting my problems arise from something unique in my 
setup, but it hasn't occurred often enough for me to investigate further.


It wasn't clear to me whether your problem was readily reproducible. You 
repeated the ssh-add command, and it hung, but you didn't report having 
killed ssh-agent. If it was actually ssh-agent that was hung, I would 
absolutely expect ssh or ssh-add to hang trying to talk to it.


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple