[PATCH] Cygwin: Suppress a warning generated with w32api >= 12.0.0

[Jon Turney]

w32api 12.0.0 adds the returns_twice attribute to RtlCaptureContext().
There's some data-flow interaction with using it inside a while loop
which causes a maybe-uninitialized warning.

../../../../winsup/cygwin/exceptions.cc: In member function 'int 
_cygtls::call_signal_handler()':
│
../../../../winsup/cygwin/exceptions.cc:1720:33: error: '' may be 
used uninitialized in this function [-Werror=maybe-uninitialized]   
│
---
 winsup/cygwin/exceptions.cc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
index a2a6f9d4c..28d0431d5 100644
--- a/winsup/cygwin/exceptions.cc
+++ b/winsup/cygwin/exceptions.cc
@@ -1717,7 +1717,10 @@ _cygtls::call_signal_handler ()
 context, unwind to the caller and in case we're called
 from sigdelayed, fix the instruction pointer accordingly. */
  context.uc_mcontext.ctxflags = CONTEXT_FULL;
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
  RtlCaptureContext ((PCONTEXT) _mcontext);
+#pragma GCC diagnostic pop
  __unwind_single_frame ((PCONTEXT) _mcontext);
  if (stackptr > stack)
{
-- 
2.45.1

Re: New Mirror

[Jon Turney via Cygwin]

On 06/06/2024 15:59, mirrors neterra via Cygwin wrote:


Hello,

We would like to become your mirror.
On our side, everything is configured and you can check the content on the 
following links:

https://mirrors.neterra.net/cygwin/


We support http, https, ftp, rsync

We are located in Europe, Sofia City, Bulgaria.
20GBs global connectivity from most Tier1 providers

We'd love for you to add us to your lists.


I added this to our mirror list.

Thanks for providing a cygwin mirror!


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

Re: [PATCH cygport] bin/cygport.in: Allow `-fdebug-prefix-map` to be selected instead of `-ffile-prefix-map`

[Daisuke Fujimura via Cygwin-apps]

The issue about debug_counter.h was resolved by merging the pull
request upstream.

https://github.com/ruby/ruby/pull/10895

Therefore, this patch is no longer needed and will be withdrawn.

On Tue, May 28, 2024 at 11:07 PM Jon Turney  wrote:
>
> On 25/05/2024 08:25, Daisuke Fujimura via Cygwin-apps wrote:
> > Having seen this commit (
> > https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=commit;h=9e82685e32f6717675e9f6bf55dd1336e3fc3831
> > ),
> > I understand that this is problematic from a reproducibility point of
> > view, but I would like to be able to specify a `-fdebug-prefix-map`
> > because C sources with code like `#include __FILE__` cannot be
> > compiled.
> >
> > https://github.com/cygwin/scallywag/actions/runs/9002845391/job/24732313857#step:6:1302
> >
> > ```
> > /cygdrive/d/a/scallywag/ruby/ruby-3.3.1-1.x86_64/src/ruby-3.3.1/debug_counter.h:359:10:
> > fatal error: /usr/src/debug/ruby-3.3.1-1/debug_counter.h: No such file
> > or directory
> > 359 | #include __FILE__
> > | ^~~~
> > compilation terminated.
> > ```
> >
> > The patch is as follows.
>
> Thanks very much for the patch.
>
> Yeah, I tripped over this when I was testing your previous patch.
>
> This seems like a generic problem which everyone is going to have with
> ruby, though.  And from a brief look at the debug_counter.h header, it
> does seem like a case of excessive cleverness - on first glance, it
> looks like this could just be written using a separate header, rather
> than recursively including itself with some define set...
>
> (and I guess it's actually a gcc bug, or at least misfeature, that you
> can make '#include __FILE__' do something other than it's plain meaning)
>
> Nevertheless, I guess this is needed.
>
> > Shell variable names in the patch should be changed to appropriate ones.
>
> Yeah, not sure what a good name for this is. Something like
> 'DEBUGINFO_ONLY_DEBUG_PREFIX_MAP', maybe?
>
> It needs to be mentioned in the documentation somewhere, as well.
>

Re: Cygwin generates syscalls for *.lnk files on filesystems with native symlink support?

[Roland Mainz via Cygwin]

On Mon, Jan 8, 2024 at 2:56 PM Corinna Vinschen via Cygwin
 wrote:
>
> On Dec 18 13:04, Cedric Blancher via Cygwin wrote:
> > On Fri, 1 Sept 2023 at 13:00, Corinna Vinschen via Cygwin
> >  wrote:
> > >
> > > On Sep  1 06:23, Cedric Blancher via Cygwin wrote:
> > > > Good morning!
> > > >
> > > > During a Cygwin 3.4.8-1.x86_64 debugging session I noticed something
> > > > odd when I looked at the network traffic generated by one of our
> > > > cluster nodes:
> > > > It seems that for each call to a tool (i.e. starting "sed" from
> > > > "bash") Cygwin searches for *.lnk files.
> > > >
> > > > Is this correct even when the filesystem in question has native
> > > > symlink support (e.g. NFS)?
> > >
> > > Yes.  During file handling, Cygwin doesn't know what filesystem a
> > > file is on until it could actually open the file and request file
> > > and filesystem info from the open handle.
> >
> > Why? If you have the path name you could lookup the (cached) mount
> > points, and determine the filesystem type. Same solution applies for
> > UNC paths, where you can easily lookup the filesystem type, and cache
> > it per-process or in Cygserver.
>
> No can do.
>
> We *do* filesystem info caching, but this requires to be able to
> open the file in the first place.  If the file exists, we're done, but
> if not, we have to evaluate all symbolic links in the path first.
> Simply reducing the path to the mount point and then translate it into
> a Windows path doesn't cut it.
>
> After the file (or its parent dir) could be opened, so we know the path
> is valid, we can fetch the filesystem info right from the open file
> handle.  At this point, we can shortcut the whole thing, reducing
> the three necessary calls to kernel functions to only the first one
> and skipping all the filesystem evaluation code.
>
> > > So if Cygwin couldn't open
> > > "foo" because the NtCreateFile call returned with status
> > > STATUS_OBJECT_PATH_NOT_FOUND or STATUS_OBJECT_NAME_NOT_FOUND, or
> > > STATUS_NO_SUCH_FILE, or one of the countless other status codes the
> > > kernel (or the driver) might return in case a file doesn't exist,
> > > it will tack on .lnk and .exe and, for historical reasons, .exe.lnk,
> > > and try again.
> >
> > Can this machinery please be turned off via CYGWIN env var option? As
> > discussed in https://www.mail-archive.com/cygwin@cygwin.com/msg174547.html
> > this machinery causes very bad filesystem lookup performance, and it
> > would IMO a good idea to have an option to turn this off, and just
> > allow and expect native links (for NTFS, ReFS and NFS). Maybe CYGWIN
> > env var option winsymlinks_expect:native? winsymlinks_expect takes a :
> > seperated list which symlink types are to be expected.
>
> We won't add any more options to the CYGWIN env variable if it's not
> necessary, and there's no proof at all that this is necessary in this
> case.
>
> If the file exists as specified, there will be no further check for
> .exe or .lnk.  If it doesn't exist, *and* the return code from
> the kernel is STATUS_OBJECT_PATH_NOT_FOUND (or any one of a
> number of equivalent return values) we're done here and are going
> to fall back to checking for symlinks in the leading path components.
>
> If we got over that, the check for .exe is unavoidable.
[snip]

What about doing lookups in parallel, e.g. use |NtCreateFile()| with
an |IO_STATUS_BLOCK|, and do lookups for *.exe, *.lnk etc. in parallel
?
That might not help for all filesystem drivers, but some of them are
multithreaded (e.g. SMB, ms-nfs41-client, ...) and would greatly
benefit from that since the requests would go async& over the
network, instead of sequentially like it is now.



Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&& programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

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

Test: ruby-3.3.2-2

[Daisuke Fujimura via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution
as test releases:

* ruby-3.3.2-2
* ruby-devel-3.3.2-2
* ruby-doc-3.3.2-2
* ruby-tcltk-3.3.2-2

- https://cygwin.com/packages/summary/ruby-src.html

This is an update to a more recent upstream release:

- https://www.ruby-lang.org/en/news/2024/05/30/ruby-3-3-2-released/
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

SDL2 2.30.3-2

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libSDL2_2.0_0-2.30.3-2
* libSDL2-devel-2.30.3-2

This is the Simple DirectMedia Layer, a general API that provides
low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL,
and 2D framebuffer across multiple platforms.

- Enable Direct3D renderer as well as X11. This allows faster rendering than
  X11 in some older environments.
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

[ITP] dav1d

[Takashi Yano via Cygwin-apps]

dav1d is a decoder for AV1 video codec, which is faster
as twice as libaom.

This package is available also for fedora.
https://src.fedoraproject.org/rpms/dav1d

I'am planning to release ffmpeg where dav1d is enabled
as fedora.

Thanks in advance.

-- 
Takashi Yano 
NAME=dav1d
VERSION=1.4.2
RELEASE=1
LICENSE="BSD-2-Clause AND ISC"
CATEGORY="Video"
SUMMARY="AV1 cross-platform decoder"
DESCRIPTION="dav1d is a new AV1 cross-platform Decoder, open-source, and 
focused on speed and correctness."
HOMEPAGE=https://code.videolan.org/videolan/dav1d
SRC_URI=https://code.videolan.org/videolan/dav1d/-/archive/${VERSION}/${NAME}-${VERSION}.tar.bz2

inherit meson

PKG_NAMES="dav1d libdav1d7 libdav1d-devel"
dav1d_CONTENTS="usr/bin/*.exe usr/share"
libdav1d7_CONTENTS="usr/bin/*.dll"
libdav1d_devel_CONTENTS="usr/lib usr/include"

BUILD_REQUIRES="nasm meson pkg-config libxxhash-devel"

fribidi 1.0.15-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* fribidi-1.0.15-1
* libfribidi0-1.0.15-1
* libfribidi-devel-1.0.15-1
* libfribidi-doc-1.0.15-1

A library that implements the Unicode Bidirectional Algorithm
(also knows as BiDi).
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: Native posix_spawn() in Cygwin?

[Mark Geisert via Cygwin]

On 6/6/2024 4:09 PM, Dan Shelton via Cygwin wrote:

On Wed, 6 Mar 2024 at 01:08, Mark Geisert via Cygwin  wrote:


On 3/5/2024 2:42 PM, Dan Shelton via Cygwin wrote:

[...]

posix_spawn() was added to POSIX so a Win32 implementation can use Win32 spawn()


...now I see what you're getting at:

If posix_spawn() is intended to launch truly unrelated processes, with
minimal or no coordination with the launching process, why can't it just
use Windows' CreateProcess? I assume here that's what Win32 spawn() does.



Kindly let me interject this first.

Could the implementor(s) of Cygwin's posix_spawn() possibly comment on 
why it ends up doing a fork(), if I understand correctly, rather than 
doing what Win32 (or even Cygwin's) spawn() does?




I'm not sure, but I think this would benefit Cygwin greatly to
implement a native posix_spawn(). It should be faster and scale
better. Also the only stuff which do really need fork() are
bash/dash/ksh, and maybe daemon stuff like sshd.


I think I remember back in the last century Cygwin's 'make' got some 
attention because fork()s were judged to be slow during Cygwin's early 
years. I don't know if the shells got the same attention then or since. 
Somebody would have to look.




Re CreateProcess: Maybe CreateProcess() breaks access token or newgrp support?


We prefer dealing with detailed bug reports as opposed to speculation :-)
That said, Cygwin does implement system(), popen(), and the spawn*() 
family of functions that all launch subprocesses with CreateProcess() 
rather than using fork(). Perhaps one of them would work for you?




Does Cygwin do bounties (paid bug fixes), or Google Summer Of Code?


Not that I know of.

..mark

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

Re: Native posix_spawn() in Cygwin?

[Dan Shelton via Cygwin]

On Wed, 6 Mar 2024 at 01:08, Mark Geisert via Cygwin  wrote:
>
> On 3/5/2024 2:42 PM, Dan Shelton via Cygwin wrote:
> > On Mon, 4 Mar 2024 at 07:45, Mark Geisert via Cygwin  
> > wrote:
> >>
> >> On 3/3/2024 7:27 PM, Dan Shelton via Cygwin wrote:
> [...]
> >>> strace does not help, as I need the Win32 calls BELOW posix_spawn(),
> >>> to see the implementation details.
> >>
> >> Check the source code, then. It's at:
> >>   https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/fork.cc
> >>
> >> Look at line 587; there's the static function dofork(). Look at the
> >> thirty or so lines above that; there's both fork() and
> >> __posix_spawn_fork() calling dofork(). So both those user-level
> >> functions call into the exact same internals. (BTW __posix_spawn_fork()
> >> is called from posix_spawn(); the latter is in newlib and not Cygwin.)
> >>
> >> You can even see the reason it's done this way by reading the comment.
> >
> > Yes, but it is as I feared, Cygwin posix_spawn() does not use Win32
> > spawn() at all, and instead uses a rather inefficient vfork()
> > solution.
>
> Cygwin's vfork() is just a wrapper around fork(), so yes. But anyway...
>
> > posix_spawn() was added to POSIX so a Win32 implementation can use Win32 
> > spawn()
>
> ...now I see what you're getting at:
>
> If posix_spawn() is intended to launch truly unrelated processes, with
> minimal or no coordination with the launching process, why can't it just
> use Windows' CreateProcess? I assume here that's what Win32 spawn() does.
>

I'm not sure, but I think this would benefit Cygwin greatly to
implement a native posix_spawn(). It should be faster and scale
better. Also the only stuff which do really need fork() are
bash/dash/ksh, and maybe daemon stuff like sshd.

Re CreateProcess: Maybe CreateProcess() breaks access token or newgrp support?

Does Cygwin do bounties (paid bug fixes), or Google Summer Of Code?

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

-- 
Problem reports:  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: [Ms-nfs41-client-devel] WinSG Re: ANN: NFSv4.1 filesystem client Windows driver binaries for Windows 10/11 for testing, 2024-05-28 ...

[Dan Shelton via Cygwin]

On Sat, 1 Jun 2024 at 14:50, Roland Mainz via Cygwin  wrote:
>
> On Wed, May 29, 2024 at 4:28 AM Dan Shelton  wrote:
> >
> > On Tue, 28 May 2024 at 22:15, Cedric Blancher via Cygwin
> >  wrote:
> > >
> > > Good evening!
> > >
> > > For your consideration - we need FEEDBACK, please!
> > >
> > > New is support running it as service (sc start
> > > ms-nfs41-client-service), setgid()/newgrp support (with a new winsg
> > > utility to run Windows applications with different primary group),
> > > 32bit kernel support, ACL+UNC path (cd //host@port/path1/path2 work in
> > > bash and ksh93)+chgrp+nfs:// support, and the NFS server no longer
> > > needs the "insecure" export switch.
> >
> > The WinSG utility is actually cool, because it can be used like a
> > normal Windows utility, and brings support for using multiple groups
> > to native Windows.
> >
> > Just a couple of ideas:
> > - Native Windows doesn't have an easy way to list group memberships
> > for the current user, so a WinSG -l to list available groups would be
> > good
>
> Done, I used -L (instead of -l) to avoid colliding with other
> newgrp(1) implementations (see
> https://github.com/kofemann/ms-nfs41-client/commit/65cec8f29cda6b8f4a1446203f6ab1cb988496ad?diff=unified=1).
>
> But in general I think Linux, Solaris/Illumos and Cygwin should
> standatise sg(1) with features like "-c cmdline" (like $ bash -c
> cmdline #) and -L (list groups suitable for -g), and make "-g
> groupname" mandatory.
>

Cool.

Are you going to make new binaries soon?

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

-- 
Problem reports:  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: WinSG Re: [Ms-nfs41-client-devel] ANN: NFSv4.1 filesystem client Windows driver binaries for Windows 10/11 for testing, 2024-05-28 ...

[Dan Shelton via Cygwin]

On Fri, 31 May 2024 at 23:20, Andrey Repin via Cygwin  wrote:
>
> Greetings, Bill Stewart!
>
> >> - WinSG should be installed in C:\Windows\system32\ alongside cmd.exe
>
> > Not IMHO.
>
> Agreed. If you want a single tool available in command line, use AppPaths
> registry entry.

How does that work?

>
> >> - Native Windows utilities use /? for help, not --help
>
> > This is really only a loosely followed convention and not all Windows tools
> > follow it. (Example: Windows PowerShell cmdlet parameters use "-", not "/".)
>
> Many tools don't care if you are using / or -, many yet use /h or -h or
> --help.
>
> True, "/?" is old, but not prevalent. Especially not in modern Windows.

Maybe, but this is what I would have tried first. dir cmd uses it, as
most other things in the Windows console.

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

-- 
Problem reports:  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] python-license-expression and cygport PoC patch

[Brian Inglis via Cygwin-apps]

On 2024-06-06 13:03, Brian Inglis via Cygwin-apps wrote:
I found github/nexB/license-expression Python package to do SPDX licence checks 
developed by the same team doing SPDX-toolkit for SPDX, using the same current 
data, by and working with Fedora folks et al.


Successful attempt to package Python license-expression (without tests):

 https://cygwin.com/cgi-bin2/jobs.cgi?id=8210


https://cygwin.com/cgi-bin2/jobs.cgi?id=8210=playground=Brian+Inglis


log at:

 https://github.com/cygwin/scallywag/actions/runs/9293093201

cygport attached and at:

https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a

The package installs and runs using PoC attached in spdx-license-expression.py 
script hooked into /usr/share/cygport/lib/pkg_pkg.cygpart license hint addition 
patch attached.


I also ran a test of the Python script and module against all package source 
cygport files declaring licences which I maintain or ever looked at, including a 
git/cygwin-packages/*.cygport download from 2023-02, showing the results in the 
attached log.
I also attempted to trap the exceptions in the script, but that does not seem to 
work in any documented obvious manner, but I do not know enough Python to 
address this fully.


If someone else who knows python cared to adopt and improve this in a more 
normal manner, and incorporate this more smoothly into cygport, we could all 
appreciate that.

Alternatively, some candid comments and frank feedback might allow me to do so! 
;^>


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

[ITP] python-license-expression and cygport PoC patch

[Brian Inglis via Cygwin-apps]

I found github/nexB/license-expression Python package to do SPDX licence checks 
developed by the same team doing SPDX-toolkit for SPDX, using the same current 
data, by and working with Fedora folks et al.


Successful attempt to package Python license-expression (without tests):

https://cygwin.com/cgi-bin2/jobs.cgi?id=8210

log at:

https://github.com/cygwin/scallywag/actions/runs/9293093201

cygport attached and at:

https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a

The package installs and runs using PoC attached in spdx-license-expression.py 
script hooked into /usr/share/cygport/lib/pkg_pkg.cygpart license hint addition 
patch attached.


I also ran a test of the Python script and module against all package source 
cygport files declaring licences which I maintain or ever looked at, including a 
git/cygwin-packages/*.cygport download from 2023-02, showing the results in the 
attached log.
I also attempted to trap the exceptions in the script, but that does not seem to 
work in any documented obvious manner, but I do not know enough Python to 
address this fully.


If someone else who knows python cared to adopt and improve this in a more 
normal manner, and incorporate this more smoothly into cygport, we could all 
appreciate that.

Alternatively, some candid comments and frank feedback might allow me to do so! 
;^>

--
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#|/usr/bin/cygport
# python-license-expression.cygport - Python license-expression Cygwin package 
build control script definitions

inherit python-wheel

NAME=python-license-expression
VERSION=30.3.0
RELEASE=1

BASE=${NAME#python-}

CATEGORY=Python
SUMMARY="Python license expression utility library"
DESCRIPTION="Python utility library to parse, compare, simplify and normalize
license expressions (such as SPDX license expressions)."

ARCH=noarch

LICENSE=Apache-2.0
LICENSE_SPDX="SPDX-License-Identifier: $LICENSE"
# SPDX-License-Identifier: Apache-2.0
LICENSE_URI="NOTICE apache-2.0.LICENSE"

DOCS="
license-expression.ABOUT
AUTHORS.rst CHANGELOG.rst CODE_OF_CONDUCT.rst README.rst
$LICENSE_URI
"

#!/usr/bin/python
"""spdx-license-expression.py - validate SPDX licence expression

Usage: spdx-license-expression.py 

Author: Brian Inglis 
"""

from license_expression import get_spdx_licensing
import sys

def main(args):
if len(args) != 1:
print("usage: " + sys.argv[0] + " ",
  file=sys.stderr)
return 1

licensing = get_spdx_licensing()
expression = args[0]
errs = licensing.validate(expression).errors
#ExpressionInfo(
#   original_expression='... and MIT and GPL-2.0+',
#   normalized_expression=None,
#   errors=['Unknown license key(s): ...'],
#   invalid_symbols=['...']
#)
for e in errs:
print(e, file=sys.stderr)
if len(errs) >= 1:
return 2

if __name__ == "__main__":
sys.exit(main(sys.argv[1:]))

--- origsrc/lib/pkg_pkg.cygpart.orig2023-03-08 06:07:57.0 -0700
+++ src/lib/pkg_pkg.cygpart 2024-05-29 14:18:46.534998000 -0600
@@ -625,6 +641,7 @@ _EOF
fi
if [ -n "${LICENSE}" ]
then
+   spdx-license-expression.py "${LICENSE}" || true
cat >> ${distdir}/${PN}/${PN}-${PVR}-src.hint 
<<-_EOF
 license: ${LICENSE}
 _EOF
$ for licp in $(grep -l '^LICENSE=.\+$' */*.cygport)
  do
pkg=${licp%/*}
cp=${licp#*/}
cd $pkg/
eval $(cygport $cp vars LICENSE)
echo $pkg $cp "$LICENSE"
spdx-license-expression.py "$LICENSE" && \
echo SPDX licence validated: "$LICENSE"
cd -
  done

a2ps a2ps.cygport GPL-3.0-or-later
SPDX licence validated: GPL-3.0-or-later

asr-manpages asr-manpages.cygport Authors
Unknown license key(s): Authors

bash-completion bash-completion.cygport GPL-2.0-or-later
SPDX licence validated: GPL-2.0-or-later

bash-completion bash-completion-spec.cygport GPL-2.0-or-later
SPDX licence validated: GPL-2.0-or-later

bind bind.cygport MPL-2.0 AND ISC AND MIT AND BSD-3-Clause AND BSD-2-Clause
SPDX licence validated: MPL-2.0 AND ISC AND MIT AND BSD-3-Clause AND 
BSD-2-Clause

bison bison.cygport GPL-3.0-or-later
SPDX licence validated: GPL-3.0-or-later

ca-certificates ca-certificates.cygport Mozilla Public Licence 2.0
Unknown license key(s): Mozilla Public Licence 2.0

calm calm.cygport MIT
SPDX licence validated: MIT

c-ares c-ares.cygport MIT
SPDX licence validated: MIT

coreutils coreutils.cygport GPL-3.0-or-later AND GFDL-1.3-or-later
SPDX licence validated: GPL-3.0-or-later AND GFDL-1.3-or-later

cpuid 

Re: [ITA] ctags

[Brian Inglis via Cygwin-apps]

On 2024-06-06 12:31, Brian Inglis via Cygwin-apps wrote:

On 2024-06-06 02:32, Brian Inglis via Cygwin-apps wrote:

On 2024-06-05 12:48, Jon Turney via Cygwin-apps wrote:

On 12/08/2016 20:41, Corinna Vinschen wrote:

On Aug 12 11:57, Warren Young wrote:

On Aug 12, 2016, at 7:57 AM, Corinna Vinschen

Cool!  If you want to take over ctags and test universal ctags for
Cygwin, feel free if Warren agrees.

I'm interested in doing ITA on ctags as gvim-X user to get onto u-ctags!


Frank,
It looks like we never got a universal-ctags package, so I'm not sure what 
the status of exuberant-ctags maintainer-ship is...


Frank was a contributor to u-ctags ~2015 but seemed mainly for Windows and 
Notepad++ plug in development.


I would like to adopt ctags and update it to successor universal-ctags.

Successful package build with a couple of failed tests with known causes:

 https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=ctags

log at:

 https://github.com/cygwin/scallywag/actions/runs/9399504588

cygport attached and at:

https://cygwin.com/cgit/cygwin-packages/ctags/tree/ctags.cygport?h=playground


Packaged universal-ctags 6.1 performance was:

Timetagspackage
 6s  8MBctags source tree including multi-language test examples
12s 22MBnewlib-cygwin source tree

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

[ITA] ctags

[Brian Inglis via Cygwin-apps]

On 2024-06-06 02:32, Brian Inglis via Cygwin-apps wrote:

On 2024-06-05 12:48, Jon Turney via Cygwin-apps wrote:

On 12/08/2016 20:41, Corinna Vinschen wrote:

On Aug 12 11:57, Warren Young wrote:

On Aug 12, 2016, at 7:57 AM, Corinna Vinschen

Cool!  If you want to take over ctags and test universal ctags for
Cygwin, feel free if Warren agrees.

I'm interested in doing ITA on ctags as gvim-X user to get onto u-ctags!


Frank,
It looks like we never got a universal-ctags package, so I'm not sure what the 
status of exuberant-ctags maintainer-ship is...


Frank was a contributor to u-ctags ~2015 but seemed mainly for Windows and 
Notepad++ plug in development.


I would like to adopt ctags and update it to successor universal-ctags.

Successful package build with a couple of failed tests with known causes:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=ctags

log at:

https://github.com/cygwin/scallywag/actions/runs/9399504588

cygport attached and at:

https://cygwin.com/cgit/cygwin-packages/ctags/tree/ctags.cygport?h=playground

--
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#|/usr/bin/cygport
# ctags.cygport - ctags Cygwin package build control script definitions
# converted by rpmspec2cygport.sh 1.1 2024-06-06 07:47:49+

NAME=ctags
VERSION=6.1.0
RELEASE=1

CATEGORY="Text Devel"
SUMMARY="Programming language source indexing and cross-reference tool"
DESCRIPTION="Generates an index (tag) file of language objects found in
source files.
The index makes it easy for text editors or other utilities to locate
the indexed items.
Ctags can also generate a cross reference file which lists information
about the various objects found in a set of language files in human
readable form.
Exuberant Ctags improves on ctags because it can find all types of
language tags, including macro definitions, enumerated values (values
inside enum{...}), function and method definitions, enum/struct/union
tags, external function prototypes, typedef names and variable
declarations.
Exuberant Ctags is far less likely to be fooled by code containing
preprocessor conditional constructs than ctags.
Exuberant ctags supports output of Emacs style TAGS files and can be
used to print out a list of selected objects found in source files.
Install ctags if you are going to use your system for C programming."

PROJECT=universal-$NAME
HOMEPAGE=https://github.com/$PROJECT/$NAME
HOMEPAGE=https://$NAME.io/
SRC_DIR=$PROJECT-$VERSION
SRC_URI=https://github.com/$PROJECT/$NAME/releases/download/v$VERSION/$PROJECT-$VERSION.tar.gz
DEBIAN=https://sources.debian.org/data/main/${NAME:0:1}/$NAME/$VERSION-$RELEASE/debian/patches
FEDORA=https://src.fedoraproject.org/rpms/$NAME/raw/master/f
OPENSUSE=https://raw.githubusercontent.com/bmwiedemann/openSUSE/master/packages/${NAME:0:1}/$NAME
PATCH_URI=

DEPEND="libiconv-devel libjansson-devel libpcre2-devel"
DEPEND+=" libxml2-devel libyaml-devel"  # libseccomp-devel(Linux)
DEPEND+=" autoconf automake gcc-core make pkg-config python39-docutils"
BUILD_REQUIRES="$DEPEND"
unset DEPEND

CYGCONF_ARGS=--enable-etags
#--enable-coverage-gcov enable 'gcov' coverage testing tool [no]
#--enable-cross-guesses={conservative|risky}specify policy for 
cross-compilation guesses
#--enable-custom-config=FILEenable custom config file for site-wide 
defaults
#--enable-debugging enable debugging features
#--enable-dependency-tracking   do not reject slow dependency extractors
#   --disable-dependency-tracking   speeds up one-time build
#--enable-etags enable the installation of links for 
etags
#   --disable-extended-format   disable extension flags; use original 
ctags file format only
#   --disable-external-sort use internal sort algorithm instead of 
sort program
#   --disable-iconv disable multibyte character encoding 
support
#   --disable-json  disable json support
#   --disable-largefile omit support for large files
#--enable-macro-patternsuse patterns as default method to locate
#   macros instead of line numbers
#   --disable-option-checking   ignore unrecognized --enable/--with 
options
#   --disable-pcre2 disable pcre2 support
#   --disable-readcmd   do not include readtags command during 
install
#   --disable-seccomp   disable seccomp support
#--enable-silent-rules  less verbose build output (undo: "make 
V=1")
#   --disable-silent-rules  verbose build output (undo: "make V=0")
#

New Mirror

[mirrors neterra via Cygwin]

From: "mirrors neterra"  
To: "root"  
Sent: Thursday, June 6, 2024 2:32:25 PM 
Subject: New Mirror 

Hello, 

We would like to become your mirror. 
On our side, everything is configured and you can check the content on the 
following links: 

https://mirrors.neterra.net/cygwin/ 


We support http, https, ftp, rsync 

We are located in Europe, Sofia City, Bulgaria. 
20GBs global connectivity from most Tier1 providers 

We'd love for you to add us to your lists. 

Best regards, 
Neterra Team 


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

Re: new git update fails with fatal: fetch-pack: invalid index-pack output

[Roland Mainz via Cygwin]

On Sun, May 26, 2024 at 6:08 AM David Dyck via Cygwin  wrote:
> I upgraded to the most recent git and I get the following error
> (  stable2.45.1-1x86_648597 KiB2024-05-25 18:58 )
>
> $ git clone -v https://github.com/lxml/lxml.git
> Cloning into 'lxml'...
> POST git-upload-pack (175 bytes)
> POST git-upload-pack (gzip 8652 to 4281 bytes)
> remote: Enumerating objects: 33933, done.
> remote: Counting objects: 100% (3778/3778), done.
> remote: Compressing objects: 100% (1322/1322), done.
> remote: Total 33933 (delta 2356), reused 3471 (delta 2241), pack-reused
> 30155
> Receiving objects: 100% (33933/33933), 20.19 MiB | 15.38 MiB/s, done.
> fatal: fetch-pack: invalid index-pack output
>
> when I downgraded to 2.43.0-1x86_648402 KiB2024-01-07 20:32
> I was able to get the repository download
>
> $ git clone -v https://github.com/lxml/lxml.git
> Cloning into 'lxml'...
> POST git-upload-pack (175 bytes)
> POST git-upload-pack (gzip 8652 to 4281 bytes)
> remote: Enumerating objects: 33933, done.
> remote: Counting objects: 100% (3778/3778), done.
> remote: Compressing objects: 100% (1322/1322), done.
> remote: Total 33933 (delta 2356), reused 3471 (delta 2241), pack-reused
> 30155
> Receiving objects: 100% (33933/33933), 20.19 MiB | 13.13 MiB/s, done.
> Resolving deltas: 100% (16518/16518), done.
[snip]

I am still getting this with Cygwin 3.6.0-0.115.g579064bf4d40.x86_64
with git 2.45, cloning from a local bundle (so no network involved):
 snip 
$ git --version
git version 2.45.1
+ git -c 'checkout.workers=16' clone -b releases/gcc-13.1.0
--single-branch ../gcc.bundle
Cloning into 'gcc'...
hint: Using 'master' as the name for the initial branch. This default
branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint:   git config --global init.defaultBranch 
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint:   git branch -m 
fatal: premature end of pack file, 16 bytes missing
error: index-pack died
fatal: remote transport reported error
 snip 



Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&& programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

-- 
Problem reports:  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: Up for adoption: ctags and expat

[Brian Inglis via Cygwin-apps]

On 2024-06-05 12:48, Jon Turney via Cygwin-apps wrote:

On 12/08/2016 20:41, Corinna Vinschen wrote:

On Aug 12 11:57, Warren Young wrote:
On Aug 12, 2016, at 7:57 AM, Corinna Vinschen 

Cool!  If you want to take over ctags and test universal ctags for
Cygwin, feel free if Warren agrees.

I'm interested in doing ITA on ctags as gvim-X user to get onto u-ctags!


Frank,
It looks like we never got a universal-ctags package, so I'm not sure what the 
status of exuberant-ctags maintainer-ship is...


Frank was a contributor to u-ctags ~2015 but seemed mainly for Windows and 
Notepad++ plug in development.


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

Vlad from Infatica to cygwin's team | App Monetization

[Vlad from Infatica via Cygwin]

 
Hi cygwin's team!

While you haven't asked these questions about our SDK solution yet,
I'm reaching out with all the answers!

* Up to 0.06 USD for DAU (daily average users).
* The SDK source code is open and not obfuscated - we send it to
potential partners for examination.
* We don't use personal data.

Anything else you'd love to clarify?

Best regards,

Vlad Khrinenko

Proxy and data expert at Infatica.io

 

-- 
Problem reports:  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: Up for adoption: ctags and expat

[Jon Turney via Cygwin-apps]

On 12/08/2016 20:41, Corinna Vinschen wrote:

On Aug 12 11:57, Warren Young wrote:

On Aug 12, 2016, at 7:57 AM, Corinna Vinschen 
 wrote:



Cool!  If you want to take over ctags and test universal ctags for
Cygwin, feel free if Warren agrees.  I'll change over maintainership
then.

Warren, does that sound good to you?

Doug, I hope you don't feel overlooked.  Expat is still yours if
Warren has no problems with that.


Sounds like a plan.


I added Frank as ctags maintainer to cygwin-pkg-maint but didn't remove
you for the time being until the move over is complete.


I've been looking for maintainer ssh keys which have been unused for a 
very long time, with a view to disabling them.


One of the keys identified was for Warren Young.

Looking at this piece of history, I guess I should remove Warren as a 
maintainer, and his ssh key.



Frank,

It looks like we never got a universal-ctags package, so I'm not sure 
what the status of exuberant-ctags maintainer-ship is...

Re: Please update keychain to 2.8.5 (Updated .cygport file attached)

[Jeremy Drake via Cygwin]

On Wed, 5 Jun 2024, Ken Takata via Cygwin wrote:

> > I've updated keychain.cygport for the latest version of keychain.
> > Please find the attached file.
> > Could you include this in the cygwin package repository and release a new 
> > version?
>
> How can we proceed to update keychain to 2.8.5?
>
> There were several requests for updating it.


Maybe try cygwin-a...@cygwin.com list?  I think that's where packaging is
supposed to happen

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

[PATCH v2] Cygwin: /proc//mount*: escape strings.

[Jeremy Drake via Cygwin-patches]

In order for these formats to be machine-parseable, characters used as
delimiters must be escaped.  Linux escapes space, tab, newline,
backslash, and hash (because code that parses mounts/mtab and fstab
would handle comments) using octal escapes.  Replicate that behavior
here.

Addresses: https://cygwin.com/pipermail/cygwin/2024-June/256082.html
Signed-off-by: Jeremy Drake 
---

Changes from original:
* forgot to include tab '\t' in characters that need escaping
* I mis-iterpreted how octal escapes work: they don't require a leading 0,
but Linux uses a fixed 3 digit format, which makes calculating the length
cleaner.

 winsup/cygwin/fhandler/process.cc | 76 +++
 1 file changed, 66 insertions(+), 10 deletions(-)

diff --git a/winsup/cygwin/fhandler/process.cc 
b/winsup/cygwin/fhandler/process.cc
index 37bdff84e3..db1763d702 100644
--- a/winsup/cygwin/fhandler/process.cc
+++ b/winsup/cygwin/fhandler/process.cc
@@ -1317,9 +1317,39 @@ extern "C" {
   struct mntent *getmntent (FILE *);
 };

+static size_t
+escape_string_length (const char *str, const char *escapees)
+{
+  size_t i, len = 0;
+
+  for (i = strcspn (str, escapees);
+   str[i];
+   i += strcspn (str + i + 1, escapees) + 1)
+len += 3;
+  return len + i;
+}
+
+static size_t
+escape_string (char *destbuf, const char *str, const char *escapees)
+{
+  size_t s, i;
+  char *p = destbuf;
+
+  for (s = 0, i = strcspn (str, escapees);
+   str[i];
+   s = i + 1, i += strcspn (str + s, escapees) + 1)
+{
+  p = stpncpy (p, str + s, i - s);
+  p += __small_sprintf (p, "\\%03o", (int)(unsigned char) str[i]);
+}
+  p = stpcpy (p, str + s);
+  return (p - destbuf);
+}
+
 static off_t
 format_process_mountstuff (void *data, char *, bool mountinfo)
 {
+  static const char MOUNTSTUFF_ESCAPEES[] = " \t\n\\#";
   _pinfo *p = (_pinfo *) data;
   user_info *u_shared = NULL;
   HANDLE u_hdl = NULL;
@@ -1369,9 +1399,9 @@ format_process_mountstuff (void *data, char *, 
bool mountinfo)
continue;
}
   destbuf = (char *) crealloc_abort (destbuf, len
- + strlen (mnt->mnt_fsname)
- + strlen (mnt->mnt_dir)
- + strlen (mnt->mnt_type)
+ + escape_string_length 
(mnt->mnt_fsname, MOUNTSTUFF_ESCAPEES)
+ + escape_string_length 
(mnt->mnt_dir, MOUNTSTUFF_ESCAPEES)
+ + escape_string_length 
(mnt->mnt_type, MOUNTSTUFF_ESCAPEES)
  + strlen (mnt->mnt_opts)
  + 30);
   if (mountinfo)
@@ -1380,18 +1410,44 @@ format_process_mountstuff (void *data, char *, 
bool mountinfo)
  dev_t dev = pc.exists () ? pc.fs_serial_number () : -1;

  len += __small_sprintf (destbuf + len,
- "%d %d %d:%d / %s %s - %s %s %s\n",
+ "%d %d %d:%d / ",
  iteration, iteration,
- major (dev), minor (dev),
- mnt->mnt_dir, mnt->mnt_opts,
- mnt->mnt_type, mnt->mnt_fsname,
+ major (dev), minor (dev));
+ len += escape_string (destbuf + len,
+   mnt->mnt_dir,
+   MOUNTSTUFF_ESCAPEES);
+ len += __small_sprintf (destbuf + len,
+ " %s - ",
+ mnt->mnt_opts);
+ len += escape_string (destbuf + len,
+   mnt->mnt_type,
+   MOUNTSTUFF_ESCAPEES);
+ destbuf[len++] = ' ';
+ len += escape_string (destbuf + len,
+   mnt->mnt_fsname,
+   MOUNTSTUFF_ESCAPEES);
+ len += __small_sprintf (destbuf + len,
+ " %s\n",
  (pc.fs_flags () & FILE_READ_ONLY_VOLUME)
  ? "ro" : "rw");
}
   else
-   len += __small_sprintf (destbuf + len, "%s %s %s %s %d %d\n",
-   mnt->mnt_fsname, mnt->mnt_dir, mnt->mnt_type,
-   mnt->mnt_opts, mnt->mnt_freq, mnt->mnt_passno);
+{
+ len += escape_string (destbuf + len,
+   mnt->mnt_fsname,
+   MOUNTSTUFF_ESCAPEES);
+ destbuf[len++] = ' ';
+ len += escape_string (destbuf + len,
+   mnt->mnt_dir,
+   MOUNTSTUFF_ESCAPEES);
+ destbuf[len++] = ' ';
+ len += escape_string (destbuf + len,
+   

[PATCH] Cygwin: /proc//mount*: escape strings.

[Jeremy Drake via Cygwin-patches]

In order for these formats to be machine-parseable, characters used as
delimiters must be escaped.  Linux escapes space, newline, backslash,
and hash (because code that parses mounts/mtab and fstab would handle
comments) using octal escapes.  Replicate that behavior here.

Addresses: https://cygwin.com/pipermail/cygwin/2024-June/256082.html
Signed-off-by: Jeremy Drake 
---

I took a crack at adding escaping to "mountstuff".  It seems like there
might be other such /proc entries that are expected to be machine-readable
that might need escaping.  As such, perhaps the escape_string* functions
should be in some other file (and not static) so other source files can
call them too.

I made some effort to match formatting, but I may well have missed
something (I just noticed I missed space between function name and open
paren on the new functions, I went ahead and fixed that in the patch
manually in the email client).

 winsup/cygwin/fhandler/process.cc | 81 +++
 1 file changed, 71 insertions(+), 10 deletions(-)

diff --git a/winsup/cygwin/fhandler/process.cc 
b/winsup/cygwin/fhandler/process.cc
index 37bdff84e3..0ab07bd119 100644
--- a/winsup/cygwin/fhandler/process.cc
+++ b/winsup/cygwin/fhandler/process.cc
@@ -1317,9 +1317,44 @@ extern "C" {
   struct mntent *getmntent (FILE *);
 };

+static size_t
+escape_string_length (const char *str, const char *escapees)
+{
+  size_t i, len = 0;
+
+  for (i = strcspn (str, escapees);
+   str[i];
+   i += strcspn (str + i + 1, escapees) + 1)
+if ((unsigned char) str[i] < 8)
+  len += 2;
+else if ((unsigned char) str[i] < 64)
+  len += 3;
+else
+  len += 4;
+  return len + i;
+}
+
+static size_t
+escape_string (char *destbuf, const char *str, const char *escapees)
+{
+  size_t s, i;
+  char *p = destbuf;
+
+  for (s = 0, i = strcspn (str, escapees);
+   str[i];
+   s = i + 1, i += strcspn (str + s, escapees) + 1)
+{
+  p = stpncpy (p, str + s, i - s);
+  p += __small_sprintf (p, "\\0%o", (int)(unsigned char) str[i]);
+}
+  p = stpcpy (p, str + s);
+  return (p - destbuf);
+}
+
 static off_t
 format_process_mountstuff (void *data, char *, bool mountinfo)
 {
+  static const char MOUNTSTUFF_ESCAPEES[] = " \n\\#";
   _pinfo *p = (_pinfo *) data;
   user_info *u_shared = NULL;
   HANDLE u_hdl = NULL;
@@ -1369,9 +1404,9 @@ format_process_mountstuff (void *data, char *, 
bool mountinfo)
continue;
}
   destbuf = (char *) crealloc_abort (destbuf, len
- + strlen (mnt->mnt_fsname)
- + strlen (mnt->mnt_dir)
- + strlen (mnt->mnt_type)
+ + escape_string_length 
(mnt->mnt_fsname, MOUNTSTUFF_ESCAPEES)
+ + escape_string_length 
(mnt->mnt_dir, MOUNTSTUFF_ESCAPEES)
+ + escape_string_length 
(mnt->mnt_type, MOUNTSTUFF_ESCAPEES)
  + strlen (mnt->mnt_opts)
  + 30);
   if (mountinfo)
@@ -1380,18 +1415,44 @@ format_process_mountstuff (void *data, char *, 
bool mountinfo)
  dev_t dev = pc.exists () ? pc.fs_serial_number () : -1;

  len += __small_sprintf (destbuf + len,
- "%d %d %d:%d / %s %s - %s %s %s\n",
+ "%d %d %d:%d / ",
  iteration, iteration,
- major (dev), minor (dev),
- mnt->mnt_dir, mnt->mnt_opts,
- mnt->mnt_type, mnt->mnt_fsname,
+ major (dev), minor (dev));
+ len += escape_string (destbuf + len,
+   mnt->mnt_dir,
+   MOUNTSTUFF_ESCAPEES);
+ len += __small_sprintf (destbuf + len,
+ " %s - ",
+ mnt->mnt_opts);
+ len += escape_string (destbuf + len,
+   mnt->mnt_type,
+   MOUNTSTUFF_ESCAPEES);
+ destbuf[len++] = ' ';
+ len += escape_string (destbuf + len,
+   mnt->mnt_fsname,
+   MOUNTSTUFF_ESCAPEES);
+ len += __small_sprintf (destbuf + len,
+ " %s\n",
  (pc.fs_flags () & FILE_READ_ONLY_VOLUME)
  ? "ro" : "rw");
}
   else
-   len += __small_sprintf (destbuf + len, "%s %s %s %s %d %d\n",
-   mnt->mnt_fsname, mnt->mnt_dir, mnt->mnt_type,
-   mnt->mnt_opts, mnt->mnt_freq, mnt->mnt_passno);
+{
+ len += escape_string 

Updated: mingw64-x86_64/i686-win-iconv 0.0.8

[Cygwin win-iconv Maintainer]

Windows iconv() library (Win64/Win32 development)

Windows iconv implementation using Win32 API conversions.
Package provides Mingw MS VC RT-linked binaries, NOT Cygwin binaries,
for use with the mingw64-{x86_64,i686}-gcc cross compiler, installed in
/usr/{x86_64,i686}-w64-mingw32/sys-root/mingw/{bin,lib,include}/.

See the package home page for more info:

https://github.com/win-iconv/win-iconv

The following packages have been upgraded in the Cygwin distribution:

* mingw64-x86_64-win-iconv  0.0.8
* mingw64-i686-win-iconv0.0.8

Thanks to Bruno Haible for reporting issues, requesting an update, and
testing the update, so it could be promoted from test to current stable.

For changes since the previous Cygwin release, see below or
/usr/share/doc/mingw64-x86_64-win-iconv/ChangeLog after installation.


2016-01-30

- win_iconv.c, win_iconv_test.c: Make >=0x80 byte illegal in ascii.
- iconv.h: Add WINICONV_CONST macro.
- win_iconv.c: Added alias.  ISO_8859-* ISO_8859_*
- win_iconv.c, win_iconv_test.c: Fixed for compiler warning.

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Cygwin data erasure request - from Edward Shakeshaft - request: E32ZCWJJ

[edwardshakeshaft4--- via Cygwin]

Hi Cygwin (cygwin.com),,

My name is Edward Shakeshaft, I've used your service in the past.
However, I'm now making the conscious decision to reduce my digital
footprint and as a result I ask you to please delete any personal data of
mine you have stored on your systems.

I have initiated this request myself and it was sent from my own personal
inbox (see From address of this email).
Would appreciate your cooperation and an email confirming when the deletion
has been completed.

My personal details are:
• Name: Edward Shakeshaft
• Email: edwardshakesha...@gmail.com

Context: I received an email from your company on 2023 October 30 which
indicates your systems hold my personal data.

Companies: If you would like additional context and assistance to complete
this request, please visit the secured Mine portal.

Thanks,
Edward Shakeshaft
Powered by Mine®
Mine Request: E32ZCWJJ

2023 Mine® All rights reserved
23 Derech Begin - Tel Aviv-Yafo - 6618356 - Israel

-- 
Problem reports:  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: ftp.acc.umu.se domain move

[Niklas Edmundsson via Cygwin]

On Tue, 4 Jun 2024, Jon Turney wrote:


File archive host name:

Official name changes from ftp.acc.umu.se to mirror.accum.se. The old
host name will continue to work for quite some time (years), but new
deployments should move to using a non-acc.umu.se name.  Since we are
lazy sysadmins, we have also registered the ac2.se (ACC=AC^2) domain
and lots of aliases so ftp.ac2.se also works.

If you have references to other acc.umu.se services (for example
www.acc.umu.se), replace the domain part with accum.se (ie
www.accum.se).


I've updated this in our mirror list.


Hmm. Looking at https://cygwin.com/mirrors.html it seems that our old host 
name ftp.acc.umu.se is still listed?


Yeah, unfortunately we currently don't have a good mechanism to migrate any 
existing Cygwin installations which are configured with the old URL.


OK.

Once that's been sorted out (or if it stops working first), I'll remove the 
old URL.


I'd recommend removing the old host name from the mirror list, so new 
installs doesn't pick it up. That's what's been done for other 
projects.


/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Niklas Edmundsson, Admin @ {ACC,HPC2N}   | ni...@accum.se
---
 I'll just nip off and shoot myself. Don't worry, it'll be very humane.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
Problem reports:  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: newer version of mingw64-*-win-iconv ?

[Jon Turney via Cygwin-apps]

On 04/06/2024 00:14, Brian Inglis via Cygwin-apps wrote:

On 2024-06-03 13:27, Jon Turney via Cygwin-apps wrote:

On 03/06/2024 06:37, Brian Inglis via Cygwin-apps wrote:

On 2024-06-02 08:56, Jon Turney via Cygwin-apps wrote:

On 29/05/2024 07:58, Brian Inglis via Cygwin wrote:

[...]
Could someone please do any further tweaks for this source git if 
required, and do NMU builds and deploys of these?


I've given you NMU privileges, so now that someone can be you!


Thanks Jon,


[...]


No previous debuginfo packages exist - are these not useful with cross 
builds?


I suspect that maybe the previous package is so old we didn't have 
automatic debuginfo generation when it was built...

Re: ftp.acc.umu.se domain move

[Jon Turney via Cygwin]

On 31/05/2024 07:43, Niklas Edmundsson via Cygwin wrote:

On Thu, 30 May 2024, Jon Turney wrote:


On 23/05/2024 15:13, Niklas Edmundsson via Cygwin wrote:





File archive host name:

Official name changes from ftp.acc.umu.se to mirror.accum.se. The old
host name will continue to work for quite some time (years), but new
deployments should move to using a non-acc.umu.se name.  Since we are
lazy sysadmins, we have also registered the ac2.se (ACC=AC^2) domain
and lots of aliases so ftp.ac2.se also works.

If you have references to other acc.umu.se services (for example
www.acc.umu.se), replace the domain part with accum.se (ie
www.accum.se).


I've updated this in our mirror list.


Hmm. Looking at https://cygwin.com/mirrors.html it seems that our old 
host name ftp.acc.umu.se is still listed?


Yeah, unfortunately we currently don't have a good mechanism to migrate 
any existing Cygwin installations which are configured with the old URL.


Once that's been sorted out (or if it stops working first), I'll remove 
the old URL.



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

Re: Request for support: some web pages on your site not responding

[Andrey Repin via Cygwin]

Greetings, Brian Inglis via Cygwin!

> On 2024-06-03 21:14, Isabella Parker via Cygwin wrote:
>> I've encountered difficulties accessing specific resources on your website
>> cygwin.org as some pages fail to load. Would you mind providing me with the
>> contact details of the responsible person to resolve this issue?
>> Appreciate your assistance!

> This mailing list is where available volunteers respond to help project users.

That's most likely a spam bot harvesting email addresses.


-- 
With best regards,
Andrey Repin
Tuesday, June 4, 2024 16:06:58

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: Request for support: some web pages on your site not responding

[Brian Inglis via Cygwin]

On 2024-06-03 21:14, Isabella Parker via Cygwin wrote:

I've encountered difficulties accessing specific resources on your website
cygwin.org as some pages fail to load. Would you mind providing me with the
contact details of the responsible person to resolve this issue?
Appreciate your assistance!


This mailing list is where available volunteers respond to help project users.

Please use cygwin.com in case of difficulties with cygwin.{org,net} - they were 
registered to protect the name, and some issues may still occasionally occur at 
the edge.


Please include precise details of your system and browser setup, and all issues 
you encounter on cygwin.com.


Someone with relevant experience will respond to your issues, and if necessary, 
ask the infrastructure team to deal with any problems.


--
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: newer version of mingw64-*-win-iconv ?

[Brian Inglis via Cygwin-apps]

On 2024-06-03 20:45, Bruno Haible wrote:

Brian Inglis wrote:

Packages are test builds for now.
If Bruno reports no issues, can untest to stable.


I report: No issues.

I installed these two packages in my Cygwin 3.5.3 machine
(from the mirrors.kernel.org mirror) and built a testdir of nearly
all of Gnulib — which contains between 30 and 50 unit tests that
are sensitive to the quality of the 'iconv' implementation —, and
all these tests pass.


Thanks Bruno,
Just untest-ed these to promote to stable.
Will announce when I see confirmation of the updates.

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

Request for support: some web pages on your site not responding

[Isabella Parker via Cygwin]

Hi!

I've encountered difficulties accessing specific resources on your website
cygwin.org as some pages fail to load. Would you mind providing me with the
contact details of the responsible person to resolve this issue?

Appreciate your assistance!

-- 
Problem reports:  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: mount points with whitespace are not escaped

[Jeremy Drake via Cygwin]

On Mon, 3 Jun 2024, Jeremy Drake via Cygwin wrote:

> /proc/self/mounts and /proc/self/mountinfo use octal escapes for ' ' and
> \n (I was rather surprised they didn't escape \r also, but I guess they
> don't have to because only ' ' and \n are used as delimiters):

Went looking at Linux source code, I guess they escape ' ' \n and \, and
"recently" added #
(https://github.com/torvalds/linux/commit/ed5fce76b5ea40c87b44cafbe4f3222da8ec981a)

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

mount points with whitespace are not escaped

[Jeremy Drake via Cygwin]

Steps to reproduce:

$ mkdir /$'My New\r\nFolder'
$ mount c: /$'My New\r\nFolder'
$ mount
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 /My New
Folder type ntfs (binary,user)

$ cat /proc/self/mounts
C:/cygwin64/bin /usr/bin ntfs binary,auto 1 1
C:/cygwin64/lib /usr/lib ntfs binary,auto 1 1
C:/cygwin64 / ntfs binary,auto 1 1
C: /My New
Folder ntfs binary,user 1 1

$ cat /proc/self/mountinfo
0 0 39488:20815 / /usr/bin binary,auto - ntfs C:/cygwin64/bin rw
1 1 39488:20815 / /usr/lib binary,auto - ntfs C:/cygwin64/lib rw
2 2 39488:20815 / / binary,auto - ntfs C:/cygwin64 rw
3 3 39488:20815 / /My New
Folder binary,user - ntfs C: rw


Expected (what happens on Linux) is that mount outputs the \r\n as ??, but
/proc/self/mounts and /proc/self/mountinfo use octal escapes for ' ' and
\n (I was rather surprised they didn't escape \r also, but I guess they
don't have to because only ' ' and \n are used as delimiters):

$ mount
...
/dev/mapper/XXX on /My New??Folder type ext3 (rw,noatime,data=ordered)

$ cat /proc/self/mounts | xxd
...
0400: 6564 2030 2030 0a2f 6465 762f 646d 2d30  ed 0 0./dev/dm-0
0410: 202f 4d79 5c30 3430 4e65 770d 5c30 3132   /My\040New.\012
0420: 466f 6c64 6572 2065 7874 3320 7277 2c6e  Folder ext3 rw,n
0430: 6f61 7469 6d65 2c64 6174 613d 6f72 6465  oatime,data=orde
0440: 7265 6420 3020 300a  red 0 0.

$ cat /proc/self/mountinfo | xxd
...
04f0: 2f62 696e 202f 4d79 5c30 3430 4e65 770d  /bin /My\040New.
0500: 5c30 3132 466f 6c64 6572 2072 772c 6e6f  \012Folder rw,no
0510: 6174 696d 6520 2d20 6578 7433 202f 6465  atime - ext3 /de
0520: 762f 646d 2d30 2072 772c 6461 7461 3d6f  v/dm-0 rw,data=o
0530: 7264 6572 6564 0ardered.

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

cleanup of in-use files moved to recycle bin

[Jeremy Drake via Cygwin]

I'm not necessarily sure that the subject is clear enough, so I want to be
explicit that I'm talking about files (or I guess potentially directories,
though I've never seen that) generated by the `try_to_bin` function in
winsup/cygwin/syscalls.cc.  Specifically, you can generate one with this
simple bash reproducer:

cp /usr/bin/sleep.exe .
./sleep 1000 &
rm -f ./sleep.exe
kill %1
fg

My questions are (starting at the beginning with what I'm trying to
accomplish, and wandering off into the weeds of the various things I've
tried to do that).

1) is there some mechanism in Cygwin that I'm not seeing to clean up these
files?  So far I've confirmed that their creation does not result in the
recycle bin icon turning from 'empty' to 'full' on the desktop, and that
emptying the recycle bin there (when it doesn't think it's already empty)
does not remove them.

2) assuming there is not, I want to make a script using only things
present in a "base system" to clean them up.  This isn't too horribly
difficult, using bash and find, *if I can assume that all Windows volumes
are rooted at drive letters*.  Once I take into account Windows
folder-mounted volumes, I need to be able to find a list of all volume
roots, in a safe way.  I hacked together a sed script that parses the
output of `mountvol`, but that is clearly not safe (not only did it rely
on a message that is likely translated, but mountvol seems to switch to
ANSI output when it is piped or redirected, and any unicode characters
turn into '_') [1].

I made a C program to do this [2], and that's fine, except I really wanted
to avoid having to ship a new binary.  Is there any way in Cygwin to get
this list?  Maybe this is something that should be added to cygpath?

3) in furtherance of figuring that out, I started grepping around for
FindNextVolumeW and GetVolumePathNamesForVolumeNameW in cygwin, and found
the dos_drive_mappings class in winsup/cygwin/mount.cc.  This is
sort-of exposed via the cygwin_internal function CW_ALLOC_DRIVE_MAP,
though the type itself is not.  As a proof-of-concept hack, I wrote
another C program based on this [3], but I don't think that really helps
anything.

4) while pondering this, I keep coming back to the idea that volume folder
mounts could be exposed via the 'normal' mount interface, such as
`getmntent`, `/proc/self/mounts`, `/proc/self/mountinfo`), as children of
the drive-letter cygdrive mounts.  This would make getting the list of
mounts safely a solved problem(*), and would probably also have the bonus
effect of letting `df` list their free space.  Is there a good reason that
this is not already done (other than SHTDI)?

* I found a bug/limitation here, which I will report in a separate email,
because that doesn't depend on any of this.

5) in addition, I ported the C example programs to python ctypes, and
factored out to a small module [4], but that also doesn't really help,
because python is not part of the "base system".  But it might be useful
to somebody else, so I link to it here too.

[1]: https://github.com/msys2/MSYS2-packages/issues/4622#issuecomment-2140990166
[2]: https://gist.github.com/jeremyd2019/8e088a72dfef44ee29ed3442957c1e65
[3]: https://gist.github.com/jeremyd2019/ac2f00ec448e75c4bd3630926201db19
[4]: https://gist.github.com/jeremyd2019/95c2cfd7eef2ed29a339860896deddec

-- 
Problem reports:  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: newer version of mingw64-*-win-iconv ?

[Brian Inglis via Cygwin-apps]

On 2024-06-03 13:27, Jon Turney via Cygwin-apps wrote:

On 03/06/2024 06:37, Brian Inglis via Cygwin-apps wrote:

On 2024-06-02 08:56, Jon Turney via Cygwin-apps wrote:

On 29/05/2024 07:58, Brian Inglis via Cygwin wrote:

[...]
Could someone please do any further tweaks for this source git if required, 
and do NMU builds and deploys of these?


I've given you NMU privileges, so now that someone can be you!


Thanks Jon,

I think and hope! ;^>

I uploaded both arch packages and have not heard anything from calm about 
mingw64-i686-win-iconv but did get a non-maintainer complaint about:


From: cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org
To: Brian Inglis ...
Reply-To: cygwin-apps-rdbxbdvo6bxqt0dzr+a...@public.gmane.org
Subject: calm: cygwin package report for Brian Inglis
X-Calm-Report: 1
Message-Id: 
<171738805632.3596610.16241297892116907567-vpjudf68pyp0lzk1ysf9sd64mghar...@public.gmane.org>

Date: Mon, 03 Jun 2024 04:14:16 -
X-Calm: 1
...
WARNING: package 'mingw64-x86_64-win-iconv' is not in the package list for 
maintainer 'Brian Inglis'
WARNING: package 'mingw64-x86_64-win-iconv' is not in the package list for 
maintainer 'Brian Inglis'

SUMMARY: 2 WARNING(s)

and there is not yet any sign of either being applied to the master setup.ini 
at cygwin.com, which is my other confirmation that an announcement would be 
appropriate, without waiting for mirror updates.


So is there anything more I have to or can do for these?
Do I have to add some kind of NMU flag for the packages somehow?


No, that's just me being distracted and forgetting to restart the thing so it 
re-reads the list.


Thanks Jon,

Need to teach `calm` about some self-HUP! ;^>


Sorry about that.  Hopefully working now.


No worries.
Got adding '!ready' manually to package dirs in lftp down pat.
Packages are test builds for now.
If Bruno reports no issues, can untest to stable.

No previous debuginfo packages exist - are these not useful with cross builds?

Cheers!

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

Test: mingw64-x86_64/i686-win-iconv 0.0.8 [TEST]

[Cygwin win-iconv Maintainer]

Windows iconv() library (Win64/Win32 development)

Windows iconv implementation using Win32 API conversions.
Package provides Mingw MS VC RT-linked binaries, NOT Cygwin binaries,
for use with the mingw64-{x86_64,i686}-gcc cross compiler, installed in
/usr/{x86_64,i686}-w64-mingw32/sys-root/mingw/{bin,lib,include}/.

See the package home page for more info:

https://github.com/win-iconv/win-iconv

The following *TEST* packages have been uploaded to the Cygwin distribution:

* mingw64-x86_64-win-iconv  0.0.8
* mingw64-i686-win-iconv0.0.8

For changes since the previous Cygwin release, see below or
/usr/share/doc/mingw64-x86_64-win-iconv/ChangeLog after installation.


2016-01-30

- win_iconv.c, win_iconv_test.c: Make >=0x80 byte illegal in ascii.
- iconv.h: Add WINICONV_CONST macro.
- win_iconv.c: Added alias.  ISO_8859-* ISO_8859_*
- win_iconv.c, win_iconv_test.c: Fixed for compiler warning.

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: newer version of mingw64-*-win-iconv ?

[Jon Turney via Cygwin-apps]

On 03/06/2024 06:37, Brian Inglis via Cygwin-apps wrote:

On 2024-06-02 08:56, Jon Turney via Cygwin-apps wrote:

On 29/05/2024 07:58, Brian Inglis via Cygwin wrote:

[...]
Could someone please do any further tweaks for this source git if 
required, and do NMU builds and deploys of these?


I've given you NMU privileges, so now that someone can be you!


Thanks Jon,

I think and hope! ;^>

I uploaded both arch packages and have not heard anything from calm 
about mingw64-i686-win-iconv but did get a non-maintainer complaint about:


From: cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org
To: Brian Inglis ...
Reply-To: cygwin-apps-rdbxbdvo6bxqt0dzr+a...@public.gmane.org
Subject: calm: cygwin package report for Brian Inglis
X-Calm-Report: 1
Message-Id: 
<171738805632.3596610.16241297892116907567-vpjudf68pyp0lzk1ysf9sd64mghar...@public.gmane.org>

Date: Mon, 03 Jun 2024 04:14:16 -
X-Calm: 1
...
WARNING: package 'mingw64-x86_64-win-iconv' is not in the package list 
for maintainer 'Brian Inglis'
WARNING: package 'mingw64-x86_64-win-iconv' is not in the package list 
for maintainer 'Brian Inglis'

SUMMARY: 2 WARNING(s)

and there is not yet any sign of either being applied to the master 
setup.ini at cygwin.com, which is my other confirmation that an 
announcement would be appropriate, without waiting for mirror updates.


So is there anything more I have to or can do for these?
Do I have to add some kind of NMU flag for the packages somehow?


No, that's just me being distracted and forgetting to restart the thing 
so it re-reads the list.


Sorry about that.  Hopefully working now.

Re: cygwin application hangs on closing console

[Johannes Khoshnazar-Thoma via Cygwin]

Hi List,

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)

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:

From f2e2d125a21487579ecb9173406c6322ee4ecfeb Mon Sep 17 00:00:00 2001
From: Johannes Thoma 
Date: Wed, 29 May 2024 17:35:35 +
Subject: [PATCH] console: use pseudo random thread_sync_event name

---
 winsup/cygwin/fhandler/console.cc   | 9 +++--
 winsup/cygwin/local_includes/fhandler.h | 1 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/winsup/cygwin/fhandler/console.cc 
b/winsup/cygwin/fhandler/console.cc
index 1352482e9..d9c88d245 100644
--- a/winsup/cygwin/fhandler/console.cc
+++ b/winsup/cygwin/fhandler/console.cc
@@ -1895,7 +1895,12 @@ debug_printf("myself->pid %d con.owner %d\n", 
myself->pid, con.owner);
   if (GetModuleHandle ("ConEmuHk64.dll"))
hook_conemu_cygwin_connector ();
   char name[MAX_PATH];
-  shared_name (name, CONS_THREAD_SYNC, get_minor ());
+
+  struct timeval v;
+  gettimeofday(, NULL);
+  a_random_number = v.tv_usec;
+
+  shared_name (name, CONS_THREAD_SYNC, a_random_number);
   thread_sync_event = CreateEvent(NULL, FALSE, FALSE, name);
@@ -1983,7 +1988,7 @@ debug_printf("%s: 1\n", __func__);
  char name[MAX_PATH];
- shared_name (name, CONS_THREAD_SYNC, get_minor ());
+ shared_name (name, CONS_THREAD_SYNC, a_random_number);
  thread_sync_event = OpenEvent (MAXIMUM_ALLOWED, FALSE, name);
diff --git a/winsup/cygwin/local_includes/fhandler.h 
b/winsup/cygwin/local_includes/fhandler.h
index 978d3e514..132dc6477 100644
--- a/winsup/cygwin/local_includes/fhandler.h
+++ b/winsup/cygwin/local_includes/fhandler.h
@@ -2215,6 +2215,7 @@ public:
   };
   typedef cons_handle_set_t handle_set_t;
   HANDLE thread_sync_event;
+  int a_random_number;
 private:
   static const unsigned MAX_WRITE_CHARS;
   static console_state *shared_console_info[MAX_CONS_DEV + 1];
--
2.17.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: newer version of mingw64-*-win-iconv ?

[Brian Inglis via Cygwin-apps]

On 2024-06-02 08:56, Jon Turney via Cygwin-apps wrote:

On 29/05/2024 07:58, Brian Inglis via Cygwin wrote:

On 2024-05-28 19:12, Bruno Haible via Cygwin wrote:

It would be useful if someone could rebuild the two packages
   https://cygwin.com/packages/summary/mingw64-i686-win-iconv.html
   https://cygwin.com/packages/summary/mingw64-x86_64-win-iconv.html
based off the current git HEAD [1].
Reason: The current git HEAD is a reasonable alternative to
GNU libiconv; all encodings that it supports, other than EUC-JP
and GB18030, have reasonably good conversion tables. Wherease the
current Cygwin packages are based off source code from 2013
and have a major problem already with the ASCII encoding.
[1] https://github.com/win-iconv/win-iconv


Ran playground local and CI builds of these packages at v0.0.8 successfully:

 https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

 https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding?

Could someone please do any further tweaks for this source git if required, 
and do NMU builds and deploys of these?


I've given you NMU privileges, so now that someone can be you!


Thanks Jon,

I think and hope! ;^>

I uploaded both arch packages and have not heard anything from calm about 
mingw64-i686-win-iconv but did get a non-maintainer complaint about:


From: cygwin-no-re...@cygwin.com
To: Brian Inglis ...
Reply-To: cygwin-apps@cygwin.com
Subject: calm: cygwin package report for Brian Inglis
X-Calm-Report: 1
Message-Id: <171738805632.3596610.16241297892116907...@server2.sourceware.org>
Date: Mon, 03 Jun 2024 04:14:16 -
X-Calm: 1
...
WARNING: package 'mingw64-x86_64-win-iconv' is not in the package list for 
maintainer 'Brian Inglis'
WARNING: package 'mingw64-x86_64-win-iconv' is not in the package list for 
maintainer 'Brian Inglis'

SUMMARY: 2 WARNING(s)

and there is not yet any sign of either being applied to the master setup.ini at 
cygwin.com, which is my other confirmation that an announcement would be 
appropriate, without waiting for mirror updates.


So is there anything more I have to or can do for these?
Do I have to add some kind of NMU flag for the packages somehow?

[Are we really still building 32 bit mingw packages when we dropped support of 
32 bit Windows << 1%?


There's a difference between "we don't support running on 32-bit Windows" and 
"We don't support cross-compiling to 32-bit Windows".


Now, I'd like to do this in an evidence based manner e.g. if we had some 
statistics on packages that cygwin users choose to install, and hardly anyone 
was bothering with mingw 32-bit packages, then dropping them would be a good way 
of conserving our very limited maintainer resource.


But as previously observed, that depends on building something to collect that 
data, which SHTDI.


(There's also some unfinished work by Yaakov in a branch of the cygport repo 
which enhances cross-compile support, so that a single source package can 
produce mingw-cross install packages for multiple architectures, which would 
make it easier to continue to support these packages, and/or drop them in 
future, and/or add mingw arm64 cross-packages when the toolchain for them 
exists...)


Should have made some arrangement with mirror ops for package download log stats 
to be generated and emailed to an Cygwin address for automatic processing.


Could we just ask on the Cygwin list if any devs still build with them?

I know from comments elsewhere that there are still systems and appliances out 
there in some regions where XP 32 bit is still in the majority: stats for << 1% 
32 bit are global!


What matters is whether Windows 32 bit libraries, programs, and systems, are 
being actively maintained or developed for using our tools and libraries, like 
all the other embedded targets we know Cygwin is being used as a development 
platform for with newlib, RTEMS, etc.


--
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: [Ms-nfs41-client-devel] WinSG Re: ANN: NFSv4.1 filesystem client Windows driver binaries for Windows 10/11 for testing, 2024-05-28 ...

[matthew patton via Cygwin]

 >> - WinSG should be installed in C:\Windows\system32\ alongside cmd.exe
>
>Not yet, all stuff for the Cygwin install of the ms-nfs41-client goes
>into the Cygwin /bin && /sbin dirs.
Let's try for NEVER. 3rd parties have no business polluting the operating 
system. If this is MS code or closely related to it, then it properly belongs 
in /usr/local or more correctly /opt  as it's not part of Cygwin proper either, 
correct?

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

Re: [PATCH v1] Cygwin: disable high-entropy VA for ldh

[Takashi Yano]

On Sun, 2 Jun 2024 15:22:41 -0400
Ken Brown  wrote:

> Hi Takashi,
> 
> On 6/1/2024 6:03 PM, Takashi Yano wrote:
> > Hi Ken,
> > 
> > On Tue, 28 May 2024 10:19:22 -0700 (PDT)
> > Jeremy Drake wrote:
> >> If ldd is run against a DLL which links to the Cygwin DLL, ldh will end
> >> up loading the Cygwin DLL dynamically, much like cygcheck or strace.
> >>
> >> Addresses: https://cygwin.com/pipermail/cygwin/2024-May/255991.html
> >> Fixes: 60675f1a7eb2 ("Cygwin: decouple shared mem regions from Cygwin DLL")
> >> Signed-off-by: Jeremy Drake 
> >> ---
> >>   winsup/utils/mingw/Makefile.am | 1 +
> >>   1 file changed, 1 insertion(+)
> >>
> >> diff --git a/winsup/utils/mingw/Makefile.am 
> >> b/winsup/utils/mingw/Makefile.am
> >> index b89d89490a..07b9f928d4 100644
> >> --- a/winsup/utils/mingw/Makefile.am
> >> +++ b/winsup/utils/mingw/Makefile.am
> >> @@ -53,6 +53,7 @@ cygcheck_LDADD = -lz -lwininet -lshlwapi -lpsapi -lntdll
> >>   cygwin_console_helper_SOURCES = cygwin-console-helper.cc
> >>
> >>   ldh_SOURCES = ldh.cc
> >> +ldh_LDFLAGS = ${AM_LDFLAGS} -Wl,--disable-high-entropy-va
> >>
> >>   strace_SOURCES = \
> >>path.cc \
> >> -- 
> >> 2.45.1.windows.1
> > 
> > If this looks good to you too, shall I commit this patch?
> 
> You and Jeremy know much more about this than I do, but I've read 
> through the thread leading to this patch, and it does look good to me. 
> So I think you should go ahead (after adding a release note).

Thanks! Pushed.

-- 
Takashi Yano 

Re: [PATCH v1] Cygwin: disable high-entropy VA for ldh

[Ken Brown]

Hi Takashi,

On 6/1/2024 6:03 PM, Takashi Yano wrote:

Hi Ken,

On Tue, 28 May 2024 10:19:22 -0700 (PDT)
Jeremy Drake wrote:

If ldd is run against a DLL which links to the Cygwin DLL, ldh will end
up loading the Cygwin DLL dynamically, much like cygcheck or strace.

Addresses: https://cygwin.com/pipermail/cygwin/2024-May/255991.html
Fixes: 60675f1a7eb2 ("Cygwin: decouple shared mem regions from Cygwin DLL")
Signed-off-by: Jeremy Drake 
---
  winsup/utils/mingw/Makefile.am | 1 +
  1 file changed, 1 insertion(+)

diff --git a/winsup/utils/mingw/Makefile.am b/winsup/utils/mingw/Makefile.am
index b89d89490a..07b9f928d4 100644
--- a/winsup/utils/mingw/Makefile.am
+++ b/winsup/utils/mingw/Makefile.am
@@ -53,6 +53,7 @@ cygcheck_LDADD = -lz -lwininet -lshlwapi -lpsapi -lntdll
  cygwin_console_helper_SOURCES = cygwin-console-helper.cc

  ldh_SOURCES = ldh.cc
+ldh_LDFLAGS = ${AM_LDFLAGS} -Wl,--disable-high-entropy-va

  strace_SOURCES = \
path.cc \
--
2.45.1.windows.1


If this looks good to you too, shall I commit this patch?


You and Jeremy know much more about this than I do, but I've read 
through the thread leading to this patch, and it does look good to me. 
So I think you should go ahead (after adding a release note).


Ken

Re: Plans to update meson version?

[Jon Turney via Cygwin]

On 01/06/2024 16:24, Dave Trombley via Cygwin wrote:

Meson appears to be two majore versions behind in cygwin (1.2.3 is latest
available, 1.4.0 was released mid-March this year).

Major projects are starting to not be compilable on Cygwin, consequently,
short of manually building a custom meson that is up to date (for example,
libcairo requires 1.3).

Are there plans to update this at some point?


The "plan" is "when I get around to it"

Thanks for the reminder, though. It seems I overlooked meson 1.3.x, so 
I've updated the package today.


(I don't usually package 1.n.x until 1.n+1.0 is available, because 
historically .0 releases of meson have had a high chance of containing 
regressions, although things are better these days...)



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

meson 1.3.2-1

[Jon Turney via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* meson-1.3.2-1

Meson is an open source build system meant to be extremely fast.  It generates
files for various backends including Ninja, Visual Studio, and Xcode. Meson does
not generate Makefiles, relying solely on Ninja for Linux and Unix support.



This is an update to a more recent upstream release:

https://mesonbuild.com/Release-notes-for-1-3-0.html


-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: newer version of mingw64-*-win-iconv ?

[Jon Turney via Cygwin]

On 29/05/2024 07:58, Brian Inglis via Cygwin wrote:

On 2024-05-28 19:12, Bruno Haible via Cygwin wrote:

It would be useful if someone could rebuild the two packages
   https://cygwin.com/packages/summary/mingw64-i686-win-iconv.html
   https://cygwin.com/packages/summary/mingw64-x86_64-win-iconv.html
based off the current git HEAD [1].
Reason: The current git HEAD is a reasonable alternative to
GNU libiconv; all encodings that it supports, other than EUC-JP
and GB18030, have reasonably good conversion tables. Wherease the
current Cygwin packages are based off source code from 2013
and have a major problem already with the ASCII encoding.
[1] https://github.com/win-iconv/win-iconv


Ran playground local and CI builds of these packages at v0.0.8 
successfully:


 https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

 https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding?

Could someone please do any further tweaks for this source git if 
required, and do NMU builds and deploys of these?


I've given you NMU privileges, so now that someone can be you!


[Are we really still building 32 bit mingw packages when we dropped 
support of 32 bit Windows << 1%?


There's a difference between "we don't support running on 32-bit 
Windows" and "We don't support cross-compiling to 32-bit Windows".


Now, I'd like to do this in an evidence based manner e.g. if we had some 
statistics on packages that cygwin users choose to install, and hardly 
anyone was bothering with mingw 32-bit packages, then dropping them 
would be a good way of conserving our very limited maintainer resource.


But as previously observed, that depends on building something to 
collect that data, which SHTDI.


(There's also some unfinished work by Yaakov in a branch of the cygport 
repo which enhances cross-compile support, so that a single source 
package can produce mingw-cross install packages for multiple 
architectures, which would make it easier to continue to support these 
packages, and/or drop them in future, and/or add mingw arm64 
cross-packages when the toolchain for them exists...)



--
Problem reports:  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: newer version of mingw64-*-win-iconv ?

[Jon Turney via Cygwin-apps]

On 29/05/2024 07:58, Brian Inglis via Cygwin wrote:

On 2024-05-28 19:12, Bruno Haible via Cygwin wrote:

It would be useful if someone could rebuild the two packages
   https://cygwin.com/packages/summary/mingw64-i686-win-iconv.html
   https://cygwin.com/packages/summary/mingw64-x86_64-win-iconv.html
based off the current git HEAD [1].
Reason: The current git HEAD is a reasonable alternative to
GNU libiconv; all encodings that it supports, other than EUC-JP
and GB18030, have reasonably good conversion tables. Wherease the
current Cygwin packages are based off source code from 2013
and have a major problem already with the ASCII encoding.
[1] https://github.com/win-iconv/win-iconv


Ran playground local and CI builds of these packages at v0.0.8 
successfully:


 https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

 https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding?

Could someone please do any further tweaks for this source git if 
required, and do NMU builds and deploys of these?


I've given you NMU privileges, so now that someone can be you!


[Are we really still building 32 bit mingw packages when we dropped 
support of 32 bit Windows << 1%?


There's a difference between "we don't support running on 32-bit 
Windows" and "We don't support cross-compiling to 32-bit Windows".


Now, I'd like to do this in an evidence based manner e.g. if we had some 
statistics on packages that cygwin users choose to install, and hardly 
anyone was bothering with mingw 32-bit packages, then dropping them 
would be a good way of conserving our very limited maintainer resource.


But as previously observed, that depends on building something to 
collect that data, which SHTDI.


(There's also some unfinished work by Yaakov in a branch of the cygport 
repo which enhances cross-compile support, so that a single source 
package can produce mingw-cross install packages for multiple 
architectures, which would make it easier to continue to support these 
packages, and/or drop them in future, and/or add mingw arm64 
cross-packages when the toolchain for them exists...)

Re: libtool can't build shared library unless -no-undefined specified

[Jon Turney via Cygwin-apps]

On 21/05/2024 17:22, Brian Inglis via Cygwin-apps wrote:
[...]
Note that because this flag doesn't do anything for non-PE targets, 
it's (a) always safe to upstream, and (b) doesn't actually prevent 
development from unwittingly introducing unresolved symbols.


In that case, could we ask Bruno to add into gnulib somewhere appropriate?


This doesn't seem like a solution.

There's lots of stuff which uses libtool which doesn't use gnulib.

There might be stuff which uses gnulib, but which does platform-specific 
gymnastics (i.e. has unresolved symbols on ELF platforms, but not on PE, 
or really, genuinely only wants a static library on PE).


All of which is to say, there is no "one size fits all" solution, 
individual projects need to decide how to handle this point, otherwise 
we'd (hopefully) be using it...


(which is not to say that the default could probably have been chosen to 
be less hassle)


This should probably be mentioned in the FAQ item on PE linkage 
peculiarities.


In libtool info?


I meant in https://cygwin.com/faq.html#faq.programming.linker, which 
touches on the issue, but doesn't go into libtool specifics currently.


(But looking at this again, the question would need adding to, also)

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Takashi Yano via Cygwin]

On Sun, 02 Jun 2024 15:14:51 +0200
Bruno Haible wrote:
> Hi Takashi Yano,
> 
> > The result is as follows (submitted as v4 patch).
> > 
> > int
> > pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> > {
> >   /* Sign bit of once_control->state is used as done flag.
> >  Similary, the next significant bit is used as destroyed flag. */
> >   const int done = INT_MIN; /* 0b1000 */
> >   const int destroyed = INT_MIN >> 1;   /* 0b1100 */
> >   if (once_control->state & done)
> > return 0;
> > 
> >   /* The type of _control->state is int *, which is compatible with
> >  LONG * (the type of the pointer argument of InterlockedXxx()). */
> >   if ((InterlockedIncrement (_control->state) & done) == 0)
> > {
> >   pthread_mutex_lock (_control->mutex);
> >   if (!(once_control->state & done))
> > {
> >   init_routine ();
> >   InterlockedOr (_control->state, done);
> > }
> >   pthread_mutex_unlock (_control->mutex);
> > }
> >   InterlockedDecrement (_control->state);
> >   if (InterlockedCompareExchange (_control->state,
> >   destroyed, done) == done)
> > pthread_mutex_destroy (_control->mutex);
> >   return 0;
> > }
> > ...
> > I believe both codes are equivalent. Could you please check?
> 
> Yes, they are equivalent. This code is free of race conditions. (Let's
> hope I am not making a mistake again.)
> 
> For legibility I would write the constant values as bit masks:
>   0x8000
>   0xc000
> and - following the habit that constant integers should have names in
> upper case - I would rename
>   done → DONE
>   destroyed → DESTROYED

Thanks for checking. I'll push the patch after the modification.

-- 
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: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Bruno Haible via Cygwin]

Hi Takashi Yano,

> The result is as follows (submitted as v4 patch).
> 
> int
> pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> {
>   /* Sign bit of once_control->state is used as done flag.
>  Similary, the next significant bit is used as destroyed flag. */
>   const int done = INT_MIN;   /* 0b1000 */
>   const int destroyed = INT_MIN >> 1; /* 0b1100 */
>   if (once_control->state & done)
> return 0;
> 
>   /* The type of _control->state is int *, which is compatible with
>  LONG * (the type of the pointer argument of InterlockedXxx()). */
>   if ((InterlockedIncrement (_control->state) & done) == 0)
> {
>   pthread_mutex_lock (_control->mutex);
>   if (!(once_control->state & done))
>   {
> init_routine ();
> InterlockedOr (_control->state, done);
>   }
>   pthread_mutex_unlock (_control->mutex);
> }
>   InterlockedDecrement (_control->state);
>   if (InterlockedCompareExchange (_control->state,
> destroyed, done) == done)
> pthread_mutex_destroy (_control->mutex);
>   return 0;
> }
> ...
> I believe both codes are equivalent. Could you please check?

Yes, they are equivalent. This code is free of race conditions. (Let's
hope I am not making a mistake again.)

For legibility I would write the constant values as bit masks:
  0x8000
  0xc000
and - following the habit that constant integers should have names in
upper case - I would rename
  done → DONE
  destroyed → DESTROYED

Bruno




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

Updated: cgif-0.4.0-1

[Daisuke Fujimura via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

- libcgif0-0.4.0-1
- libcgif-devel-0.4.0-1

https://cygwin.com/packages/summary/cgif-src.html
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Updated: libjwt-1.17.1-1

[Daisuke Fujimura via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

- libjwt-1.17.1-1
- libjwt2-1.17.1-1
- libjwt-devel-1.17.1-1

https://cygwin.com/packages/summary/libjwt-src.html
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Updated: simdjson-3.9.3-1

[Daisuke Fujimura via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

- libsimdjson22-3.9.3-1
- libsimdjson-devel-3.9.3-1

https://cygwin.com/packages/summary/simdjson-src.html
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Updated: libhtp-0.5.48-1

[Daisuke Fujimura via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

- libhtp2-0.5.48-1
- libhtp-devel-0.5.48-1

https://cygwin.com/packages/summary/libhtp-src.html
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Updated: libvpx-utils/-doc/-devel/9 1.14.1

[Cygwin libvpx Maintainer]

The following packages have been upgraded in the Cygwin distribution:

* libvpx-utils  1.14.1
* libvpx-doc1.14.1
* libvpx-devel  1.14.1
* libvpx9   1.14.1

Google WebM VP8/VP9 video graphics codecs encoders and decoders
library reference implementation.

For more information see the project home page:

https://github.com/webmproject/libvpx/


2024-05-21 v1.14.1 "Venetian Duck"

This release includes enhancements and bug fixes.

- Upgrading:

This release is ABI compatible with the previous release.

- Enhancement:

Improved the detection of compiler support for AArch64 extensions,
particularly SVE.

Added vpx_codec_get_global_headers() support for VP9.

- Bug fixes:

Added buffer bounds checks to vpx_writer and vpx_write_bit_buffer.
Fix to GetSegmentationData() crash in aq_mode=0 for RTC rate control.
Fix to alloc for row_base_thresh_freq_fac.
Free row mt memory before freeing cpi->tile_data.
Fix to buffer alloc for vp9_bitstream_worker_data.
Fix to VP8 race issue for multi-thread with pnsr_calc.
Fix to uv width/height in vp9_scale_and_extend_frame_ssse3.
Fix to integer division by zero and overflow in calc_pframe_target_size().
Fix to integer overflow in vpx_img_alloc() & vpx_img_wrap()(CVE-2024-5197).
Fix to UBSan error in vp9_rc_update_framerate().
Fix to UBSan errors in vp8_new_framerate().
Fix to integer overflow in vp8 encodeframe.c.
Handle EINTR from sem_wait().

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: [PATCH v1] Cygwin: disable high-entropy VA for ldh

[Takashi Yano]

Hi Ken,

On Tue, 28 May 2024 10:19:22 -0700 (PDT)
Jeremy Drake wrote:
> If ldd is run against a DLL which links to the Cygwin DLL, ldh will end
> up loading the Cygwin DLL dynamically, much like cygcheck or strace.
> 
> Addresses: https://cygwin.com/pipermail/cygwin/2024-May/255991.html
> Fixes: 60675f1a7eb2 ("Cygwin: decouple shared mem regions from Cygwin DLL")
> Signed-off-by: Jeremy Drake 
> ---
>  winsup/utils/mingw/Makefile.am | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/winsup/utils/mingw/Makefile.am b/winsup/utils/mingw/Makefile.am
> index b89d89490a..07b9f928d4 100644
> --- a/winsup/utils/mingw/Makefile.am
> +++ b/winsup/utils/mingw/Makefile.am
> @@ -53,6 +53,7 @@ cygcheck_LDADD = -lz -lwininet -lshlwapi -lpsapi -lntdll
>  cygwin_console_helper_SOURCES = cygwin-console-helper.cc
> 
>  ldh_SOURCES = ldh.cc
> +ldh_LDFLAGS = ${AM_LDFLAGS} -Wl,--disable-high-entropy-va
> 
>  strace_SOURCES = \
>   path.cc \
> -- 
> 2.45.1.windows.1

If this looks good to you too, shall I commit this patch?

-- 
Takashi Yano 

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Takashi Yano via Cygwin]

On Sat, 1 Jun 2024 12:08:51 -0400
Ken Brown wrote:
> Hi Takashi,
> 
> On 6/1/2024 10:18 AM, Takashi Yano via Cygwin wrote:
> > int
> > pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> > {
> >/* Sign bit of once_control->state is used as done flag.
> >   Similary, the next significant bit is used as destroyed flag. */
> 
>  Typo: Similarly
> 
> >const int done = INT_MIN;/* 0b1000 */
> >const int destroyed = INT_MIN >> 1;  /* 0b1100 */
> 
> Shouldn't the constants in the comments have 32 bits?  Other than that, 
> LGTM.  (But you should wait for Bruno to confirm before you commit.)

Thanks for checking!

-- 
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: [PATCH v4] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Takashi Yano]

On Sat, 1 Jun 2024 12:48:07 -0700 (PDT)
Jeremy Drake  On Sat, 1 Jun 2024, Takashi Yano wrote:
> 
> > +  const int destroyed = INT_MIN >> 1;  /* 0b1100 */
> 
> I thought whether or not right shifting a negative number sign-extends was
> undefined in the C/C++ standards?

It seems that it's implementation-defined till C++17 and arithmetic
shift since C++20.

gcc defines:
"Signed ‘>>’ acts on negative numbers by sign extension."

Therefore, this works as intended. However, relying on implementation-defined
behavior may not be certainly a good idea.

-- 
Takashi Yano 

Re: [PATCH v4] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Jeremy Drake via Cygwin-patches]

On Sat, 1 Jun 2024, Takashi Yano wrote:

> +  const int destroyed = INT_MIN >> 1;/* 0b1100 */

I thought whether or not right shifting a negative number sign-extends was
undefined in the C/C++ standards?

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Ken Brown via Cygwin]

Hi Takashi,

On 6/1/2024 10:18 AM, Takashi Yano via Cygwin wrote:

int
pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
{
   /* Sign bit of once_control->state is used as done flag.
  Similary, the next significant bit is used as destroyed flag. */


Typo: Similarly


   const int done = INT_MIN;/* 0b1000 */
   const int destroyed = INT_MIN >> 1;/* 0b1100 */


Shouldn't the constants in the comments have 32 bits?  Other than that, 
LGTM.  (But you should wait for Bruno to confirm before you commit.)


Ken

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

Plans to update meson version?

[Dave Trombley via Cygwin]

Meson appears to be two majore versions behind in cygwin (1.2.3 is latest
available, 1.4.0 was released mid-March this year).

Major projects are starting to not be compilable on Cygwin, consequently,
short of manually building a custom meson that is up to date (for example,
libcairo requires 1.3).

Are there plans to update this at some point?


Thanks,
-David

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

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Takashi Yano via Cygwin]

Hi Bruno,

On Fri, 31 May 2024 16:01:35 +0200
Bruno Haible wrote:
> Hi Takashi Yano,
> 
> > With v3 patch:
> > int
> > pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> > {
> >   /* Sign bit of once_control->state is used as done flag */
> >   if (once_control->state & INT_MIN)
> > return 0;
> > 
> // HERE: Point A.
> 
> >   /* The type of _control->state is int *, which is compatible with
> >  LONG * (the type of the first argument of InterlockedIncrement()). */
> >   InterlockedIncrement (_control->state);
> >   pthread_mutex_lock (_control->mutex);
> >   if (!(once_control->state & INT_MIN))
> > {
> >   init_routine ();
> >   InterlockedOr (_control->state, INT_MIN);
> > }
> >   pthread_mutex_unlock (_control->mutex);
> >   if (InterlockedDecrement (_control->state) == INT_MIN)
> 
>   // HERE: Point B.
> 
> > pthread_mutex_destroy (_control->mutex);
> 
>   // HERE: Point C.
> 
> >   return 0;
> > }
> 
> I said "looks good to me", but unfortunately I have to withdraw this.
> The code to which I pointed you had two race conditions, unfortunately,
> and this code (v3) has the same two race conditions:
> 
> (1) It can happen that the pthread_mutex_destroy is executed twice, which is
> undefined behaviour.
> 
>  thread1  thread2
>  ---  ---
> 
>  Runs upto A. Runs upto A.
> 
>  Runs upto B:
>  sets state to 1,
>  locks,
>  sets state to INT_MIN + 1,
>  unlocks,
>  sets state to INT_MIN.
> 
>   Runs upto B:
>   sets state to INT_MIN + 1,
>   locks,
>   unlocks,
>   sets state to INT_MIN.
> 
>  calls pthread_mutex_destroy
> 
>   calls pthread_mutex_destroy
> 
> (2) It can happen that pthread_mutex_lock is executed on a mutex that is
> already destroyed, which is undefined behaviour.
> 
>  thread1  thread2
>  ---  ---
> 
>  Runs upto A. Runs upto A.
> 
>  Runs upto C:
>  sets state to 1,
>  locks,
>  sets state to INT_MIN + 1,
>  unlocks,
>  sets state to INT_MIN,
>  calls pthread_mutex_destroy
> 
>   Attempts to run upto B:
>   sets state to INT_MIN + 1,
>   locks  -> BOOM, SIGSEGV

I reconsidered how it can be fixed before reading the following your
idea for double-check. The result is as follows (submitted as v4 patch).

int
pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
{
  /* Sign bit of once_control->state is used as done flag.
 Similary, the next significant bit is used as destroyed flag. */
  const int done = INT_MIN; /* 0b1000 */
  const int destroyed = INT_MIN >> 1;   /* 0b1100 */
  if (once_control->state & done)
return 0;

  /* The type of _control->state is int *, which is compatible with
 LONG * (the type of the pointer argument of InterlockedXxx()). */
  if ((InterlockedIncrement (_control->state) & done) == 0)
{
  pthread_mutex_lock (_control->mutex);
  if (!(once_control->state & done))
{
  init_routine ();
  InterlockedOr (_control->state, done);
}
  pthread_mutex_unlock (_control->mutex);
}
  InterlockedDecrement (_control->state);
  if (InterlockedCompareExchange (_control->state,
  destroyed, done) == done)
pthread_mutex_destroy (_control->mutex);
  return 0;
}

Then, I read your idea below:

> A corrected implementation (that passes 100 runs of the test program)
> is in
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/pthread-once.c;h=4b4a18d2afbb915f8f97ac3ff981f519acaa5996;hb=HEAD#l41
> 
> The fix for race (1) is to extend the "done" part of the state to 2 bits
> instead of just 1 bit, and to use this extra bit to ensure that only one
> of the threads proceeds from B to C.
> 
> The fix for race (2) is to increment num_threads *before* testing the
> 'done' word and, accordingly, to decrement num_threads also when 'done'
> was zero.
> 
> You should be able to transpose the logic accordingly, by using the
> bit mask 0xC000 for the 'done' part and the bit mask 0x3FFF for
> the 'num_threads' part.

I believe both codes are equivalent. Could you please check?

-- 
Takashi Yano 

-- 
Problem reports:  

[PATCH v4] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Takashi Yano]

To avoid race issues, pthread::once() uses pthread_mutex. This caused
the handle leak which was fixed by the commit 2c5433e5da82. However,
this fix introduced another race issue, i.e., the mutex may be used
after it is destroyed. This patch fixes the issue. Special thanks to
Bruno Haible for discussing how to fix this.

Addresses: https://cygwin.com/pipermail/cygwin/2024-May/255987.html
Reported-by: Bruno Haible 
Fixes: 2c5433e5da82 ("Cygwin: pthread: Fix handle leak in pthread_once.")
Reviewed-by:
Signed-off-by: Takashi Yano 
---
 winsup/cygwin/local_includes/thread.h |  2 +-
 winsup/cygwin/thread.cc   | 34 ++-
 2 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/winsup/cygwin/local_includes/thread.h 
b/winsup/cygwin/local_includes/thread.h
index 9939c4224..b3496281e 100644
--- a/winsup/cygwin/local_includes/thread.h
+++ b/winsup/cygwin/local_includes/thread.h
@@ -674,7 +674,7 @@ class pthread_once
 {
 public:
   pthread_mutex_t mutex;
-  int state;
+  volatile int state;
 };
 
 /* shouldn't be here */
diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
index 0f8327831..e060af084 100644
--- a/winsup/cygwin/thread.cc
+++ b/winsup/cygwin/thread.cc
@@ -2045,27 +2045,29 @@ pthread::create (pthread_t *thread, const 
pthread_attr_t *attr,
 int
 pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
 {
-  // already done ?
-  if (once_control->state)
+  /* Sign bit of once_control->state is used as done flag.
+ Similary, the next significant bit is used as destroyed flag. */
+  const int done = INT_MIN;/* 0b1000 */
+  const int destroyed = INT_MIN >> 1;  /* 0b1100 */
+  if (once_control->state & done)
 return 0;
 
-  pthread_mutex_lock (_control->mutex);
-  /* Here we must set a cancellation handler to unlock the mutex if needed */
-  /* but a cancellation handler is not the right thing. We need this in the 
thread
-   *cleanup routine. Assumption: a thread can only be in one pthread_once 
routine
-   *at a time. Stote a mutex_t *in the pthread_structure. if that's non null 
unlock
-   *on pthread_exit ();
-   */
-  if (!once_control->state)
+  /* The type of _control->state is int *, which is compatible with
+ LONG * (the type of the pointer argument of InterlockedXxx()). */
+  if ((InterlockedIncrement (_control->state) & done) == 0)
 {
-  init_routine ();
-  once_control->state = 1;
+  pthread_mutex_lock (_control->mutex);
+  if (!(once_control->state & done))
+   {
+ init_routine ();
+ InterlockedOr (_control->state, done);
+   }
   pthread_mutex_unlock (_control->mutex);
-  while (pthread_mutex_destroy (_control->mutex) == EBUSY);
-  return 0;
 }
-  /* Here we must remove our cancellation handler */
-  pthread_mutex_unlock (_control->mutex);
+  InterlockedDecrement (_control->state);
+  if (InterlockedCompareExchange (_control->state,
+ destroyed, done) == done)
+pthread_mutex_destroy (_control->mutex);
   return 0;
 }
 
-- 
2.45.1

Updated: weechat-4.3.1-1

[Sébastien Helleu]

Version 4.3.1-1 of "weechat" has been uploaded.

ChangeLog:

https://weechat.org/files/doc/weechat/ChangeLog-4.3.1.html

DESCRIPTION
WeeChat is a fast, light and extensible chat client. It runs on many platforms
like Linux, Unix, BSD, GNU Hurd, Mac OS X and Windows (bash/ubuntu and
cygwin).

HOMEPAGE
https://weechat.org/

Sébastien Helleu.
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: [Ms-nfs41-client-devel] WinSG Re: ANN: NFSv4.1 filesystem client Windows driver binaries for Windows 10/11 for testing, 2024-05-28 ...

[Roland Mainz via Cygwin]

On Wed, May 29, 2024 at 4:28 AM Dan Shelton  wrote:
>
> On Tue, 28 May 2024 at 22:15, Cedric Blancher via Cygwin
>  wrote:
> >
> > Good evening!
> >
> > For your consideration - we need FEEDBACK, please!
> >
> > New is support running it as service (sc start
> > ms-nfs41-client-service), setgid()/newgrp support (with a new winsg
> > utility to run Windows applications with different primary group),
> > 32bit kernel support, ACL+UNC path (cd //host@port/path1/path2 work in
> > bash and ksh93)+chgrp+nfs:// support, and the NFS server no longer
> > needs the "insecure" export switch.
>
> The WinSG utility is actually cool, because it can be used like a
> normal Windows utility, and brings support for using multiple groups
> to native Windows.
>
> Just a couple of ideas:
> - Native Windows doesn't have an easy way to list group memberships
> for the current user, so a WinSG -l to list available groups would be
> good

Done, I used -L (instead of -l) to avoid colliding with other
newgrp(1) implementations (see
https://github.com/kofemann/ms-nfs41-client/commit/65cec8f29cda6b8f4a1446203f6ab1cb988496ad?diff=unified=1).

But in general I think Linux, Solaris/Illumos and Cygwin should
standatise sg(1) with features like "-c cmdline" (like $ bash -c
cmdline #) and -L (list groups suitable for -g), and make "-g
groupname" mandatory.

> - WinSG should be installed in C:\Windows\system32\ alongside cmd.exe

Not yet, all stuff for the Cygwin install of the ms-nfs41-client goes
into the Cygwin /bin && /sbin dirs.

> - PowerShell plugin would be cool

I have no idea yet how to do that (yet).

> - Explorer Plugin to switch groups

Same problem... I'm not even sure the default Windows Explorer has an
API for its access token... ;-(

> - Native Windows utilities use /? for help, not --help

Done, I added winsg /? (see
https://github.com/kofemann/ms-nfs41-client/commit/e170a8a37f218d2f03a651efc6593c1e9ed0869e?diff=unified=1).



Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&& programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

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

[PATCH] Cygwin: mixer: Fix volume control for no WAVECAPS_LRVOLUME device

[Takashi Yano]

Currently, if the device does not have capability WAVECAPS_LRVOLUME,
the volume control does not work properly. This patch fixes that.

Fixes: 2a4af3661470 ("Cygwin: Implement sound mixer device.")
Signed-off-by: Takashi Yano 
---
 winsup/cygwin/autoload.cc   |  2 ++
 winsup/cygwin/fhandler/mixer.cc | 14 +-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/autoload.cc b/winsup/cygwin/autoload.cc
index c262c7efb..7e882ef1e 100644
--- a/winsup/cygwin/autoload.cc
+++ b/winsup/cygwin/autoload.cc
@@ -603,6 +603,8 @@ LoadDLLfuncEx3 (waveOutReset, winmm, 1, 0, 1)
 LoadDLLfuncEx3 (waveOutSetVolume, winmm, 1, 0, 1)
 LoadDLLfuncEx3 (waveOutUnprepareHeader, winmm, 1, 0, 1)
 LoadDLLfuncEx3 (waveOutWrite, winmm, 1, 0, 1)
+LoadDLLfuncEx3 (waveOutMessage, winmm, 1, 0, 1)
+LoadDLLfuncEx3 (waveOutGetDevCapsA, winmm, 1, 0, 1)
 
 LoadDLLfunc (accept, ws2_32)
 LoadDLLfunc (bind, ws2_32)
diff --git a/winsup/cygwin/fhandler/mixer.cc b/winsup/cygwin/fhandler/mixer.cc
index fabd397b7..f4997f952 100644
--- a/winsup/cygwin/fhandler/mixer.cc
+++ b/winsup/cygwin/fhandler/mixer.cc
@@ -15,6 +15,7 @@ details. */
 #include "fhandler.h"
 #include "dtable.h"
 #include "cygheap.h"
+#include 
 
 ssize_t
 fhandler_dev_mixer::write (const void *ptr, size_t len)
@@ -88,7 +89,9 @@ int
 fhandler_dev_mixer::ioctl (unsigned int cmd, void *buf)
 {
   int ret = 0;
+  DWORD id, flag;
   DWORD vol;
+  WAVEOUTCAPS woc;
   switch (cmd)
 {
 case SOUND_MIXER_READ_DEVMASK:
@@ -115,7 +118,12 @@ fhandler_dev_mixer::ioctl (unsigned int cmd, void *buf)
   *(int *) buf = 1 << rec_source;
   break;
 case MIXER_WRITE (SOUND_MIXER_VOLUME):
+  waveOutMessage ((HWAVEOUT)WAVE_MAPPER, DRVM_MAPPER_PREFERRED_GET,
+ (DWORD_PTR), (DWORD_PTR));
+  waveOutGetDevCaps ((UINT)id, , sizeof (woc));
   vol = volume_oss_to_winmm (*(int *) buf);
+  if (!(woc.dwSupport & WAVECAPS_LRVOLUME))
+   vol = max(vol & 0x, (vol >> 16) & 0x);
   if (waveOutSetVolume ((HWAVEOUT)WAVE_MAPPER, vol) != MMSYSERR_NOERROR)
{
  set_errno (EINVAL);
@@ -123,13 +131,17 @@ fhandler_dev_mixer::ioctl (unsigned int cmd, void *buf)
}
   break;
 case MIXER_READ (SOUND_MIXER_VOLUME):
-  DWORD vol;
+  waveOutMessage ((HWAVEOUT)WAVE_MAPPER, DRVM_MAPPER_PREFERRED_GET,
+ (DWORD_PTR), (DWORD_PTR));
+  waveOutGetDevCaps ((UINT)id, , sizeof (woc));
   if (waveOutGetVolume ((HWAVEOUT)WAVE_MAPPER, ) != MMSYSERR_NOERROR)
{
  set_errno (EINVAL);
  ret = -1;
  break;
}
+  if (!(woc.dwSupport & WAVECAPS_LRVOLUME))
+   vol |= (vol & 0x) << 16;
   *(int *) buf = volume_winmm_to_oss (vol);
   break;
 default:
-- 
2.45.1

Re: WinSG Re: [Ms-nfs41-client-devel] ANN: NFSv4.1 filesystem client Windows driver binaries for Windows 10/11 for testing, 2024-05-28 ...

[Andrey Repin via Cygwin]

Greetings, Bill Stewart!

>> - WinSG should be installed in C:\Windows\system32\ alongside cmd.exe

> Not IMHO.

Agreed. If you want a single tool available in command line, use AppPaths
registry entry.

>> - Native Windows utilities use /? for help, not --help

> This is really only a loosely followed convention and not all Windows tools
> follow it. (Example: Windows PowerShell cmdlet parameters use "-", not "/".)

Many tools don't care if you are using / or -, many yet use /h or -h or
--help.

True, "/?" is old, but not prevalent. Especially not in modern Windows.


-- 
With best regards,
Andrey Repin
Saturday, June 1, 2024 00:14:18

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: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Bruno Haible via Cygwin]

Hi Takashi Yano,

> With v3 patch:
> int
> pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> {
>   /* Sign bit of once_control->state is used as done flag */
>   if (once_control->state & INT_MIN)
> return 0;
> 
// HERE: Point A.

>   /* The type of _control->state is int *, which is compatible with
>  LONG * (the type of the first argument of InterlockedIncrement()). */
>   InterlockedIncrement (_control->state);
>   pthread_mutex_lock (_control->mutex);
>   if (!(once_control->state & INT_MIN))
> {
>   init_routine ();
>   InterlockedOr (_control->state, INT_MIN);
> }
>   pthread_mutex_unlock (_control->mutex);
>   if (InterlockedDecrement (_control->state) == INT_MIN)

  // HERE: Point B.

> pthread_mutex_destroy (_control->mutex);

  // HERE: Point C.

>   return 0;
> }

I said "looks good to me", but unfortunately I have to withdraw this.
The code to which I pointed you had two race conditions, unfortunately,
and this code (v3) has the same two race conditions:

(1) It can happen that the pthread_mutex_destroy is executed twice, which is
undefined behaviour.

 thread1  thread2
 ---  ---

 Runs upto A. Runs upto A.

 Runs upto B:
 sets state to 1,
 locks,
 sets state to INT_MIN + 1,
 unlocks,
 sets state to INT_MIN.

  Runs upto B:
  sets state to INT_MIN + 1,
  locks,
  unlocks,
  sets state to INT_MIN.

 calls pthread_mutex_destroy

  calls pthread_mutex_destroy

(2) It can happen that pthread_mutex_lock is executed on a mutex that is
already destroyed, which is undefined behaviour.

 thread1  thread2
 ---  ---

 Runs upto A. Runs upto A.

 Runs upto C:
 sets state to 1,
 locks,
 sets state to INT_MIN + 1,
 unlocks,
 sets state to INT_MIN,
 calls pthread_mutex_destroy

  Attempts to run upto B:
  sets state to INT_MIN + 1,
  locks  -> BOOM, SIGSEGV

A corrected implementation (that passes 100 runs of the test program)
is in
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/pthread-once.c;h=4b4a18d2afbb915f8f97ac3ff981f519acaa5996;hb=HEAD#l41

The fix for race (1) is to extend the "done" part of the state to 2 bits
instead of just 1 bit, and to use this extra bit to ensure that only one
of the threads proceeds from B to C.

The fix for race (2) is to increment num_threads *before* testing the
'done' word and, accordingly, to decrement num_threads also when 'done'
was zero.

You should be able to transpose the logic accordingly, by using the
bit mask 0xC000 for the 'done' part and the bit mask 0x3FFF for
the 'num_threads' part.

Bruno




-- 
Problem reports:  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: Run explorer.exe with Cygwin newgrp(1) - same user but different primary group

[Bill Stewart via Cygwin]

On Thu, May 30, 2024 at 5:21 PM Dan Shelton wrote:

How can someone run explorer as Admin then?
>

I believe the point of the design was to prevent exactly that (as already
noted, for security reasons).

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: TeX Live 2024:: asympote 2.88-1 hangs after outputting a pdf

[Lemures Lemniscati via Cygwin]

On Thu, 30 May 2024 18:29:17 -0400, Ken Brown via Cygwin
> On 5/30/2024 3:39 PM, Jon Turney via Cygwin wrote:
> > On 27/05/2024 16:14, Ken Brown via Cygwin wrote:
> >> On 5/27/2024 5:17 AM, Lemures Lemniscati via Cygwin wrote:
> >>> On Sun, 26 May 2024 18:02:54 -0400, Ken Brown via Cygwin
> >>> Here is a log from gdb. Will it help?
> >>>   run
> >>>   info threads
> >>>   info stack
> >>>   list
> >>>
> >>>
> >>> $ HOME=/tmp gdb --args asy -vv -f pdf test
> >> [...]
> >>> Thread 5 "sig" received signal SIGTRAP, Trace/breakpoint trap.
> >>
> >> I don't get this SIGRAP when I run the same command.  The program just 
> >> runs to completion.  Maybe someone can explain what might cause this.  
> >> I have no idea.
> > 
> > Getting SIGTRAP rather than SIGSEGV or whatever here seems like it might 
> > be an unintended consequence of the dumper changes I made in 3.5.0.
> > 
> >> 0  0x7ffd8487d313 in KERNELBASE!DebugBreak () from 
> >> /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
> >> #1  0x7ffd527f6367 in break_here () at 
> >> /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:472
> >> #2  0x7ffd52810349 in try_to_debug () at 
> >> /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/exceptions.cc:597
> >> #3  exception::handle (e=0x28bc6f0, frame=, 
> >> in=0x28bc200, dispatch=)
> >>     at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/exceptions.cc:810
> >> #4  0x7ffd871b49ff in ntdll!.chkstk () from 
> >> /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> >> #5  0x7ffd8712e466 in ntdll!RtlFindCharInUnicodeString () from 
> >> /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> >> #6  0x7ffd871b39ee in ntdll!KiUserExceptionDispatcher () from 
> >> /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> >> #7  0x7ffd5291bdd4 in init_cygheap::find_tls (this=0x8, 
> >> sig=20, issig_wait=@0x28bca3f: false)
> > 
> > The important thing in this backtrace is that an exception is occurring 
> > in find_tls, not that we break into the debugging while handling it 
> > (rather than rethrowing the exception to let the debugger handle it, 
> > which is maybe what should happen? and did in previous versions of 
> > Cygwin??)
> 
> Thanks.  So find_tls, running in the "sig" thread, is getting an 
> exception while Cygwin is trying to process signal 20.  The latter is 
> SIGCHLD.  Based on Lem's original report, I would guess that the SIGCHLD 
> is generated by ghostscript exiting when it finishes processing the 
> file.  An error in processing the signal would explain the fact that asy 
> hangs.
> 
> I'm not familiar enough with Cygwin's signal-handling code to be able to 
> debug this, especially since I can't reproduce the problem.
> 
> It would be helpful if others could try Lem's recipe and see if they can 
> reproduce it.

An additional report: 
  On one of my machines, the issue (signal SIGTRAP) is resolved by
updating Windows 11 Pro to H23H2 Build 22631.3672.
  But, on another one, it still occurs.

Lem


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

Re: ftp.acc.umu.se domain move

[Niklas Edmundsson via Cygwin]

On Thu, 30 May 2024, Jon Turney wrote:


On 23/05/2024 15:13, Niklas Edmundsson via Cygwin wrote:





File archive host name:

Official name changes from ftp.acc.umu.se to mirror.accum.se. The old
host name will continue to work for quite some time (years), but new
deployments should move to using a non-acc.umu.se name.  Since we are
lazy sysadmins, we have also registered the ac2.se (ACC=AC^2) domain
and lots of aliases so ftp.ac2.se also works.

If you have references to other acc.umu.se services (for example
www.acc.umu.se), replace the domain part with accum.se (ie
www.accum.se).


I've updated this in our mirror list.


Hmm. Looking at https://cygwin.com/mirrors.html it seems that our old 
host name ftp.acc.umu.se is still listed?



Thanks for providing a cygwin mirror.


You're welcome :-)

/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Niklas Edmundsson, Admin @ {ACC,HPC2N}   | ni...@accum.se
---
 "If the Apocalypse comes, beep me"- Buffy
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
Problem reports:  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: WinSG Re: [Ms-nfs41-client-devel] ANN: NFSv4.1 filesystem client Windows driver binaries for Windows 10/11 for testing, 2024-05-28 ...

[Dan Shelton via Cygwin]

On Wed, 29 May 2024 at 15:37, Bill Stewart via Cygwin  wrote:
>
> On Tue, May 28, 2024 at 8:29 PM Dan Shelton wrote:
>
> Just a couple of ideas:
> > - Native Windows doesn't have an easy way to list group memberships
> > for the current user, so a WinSG -l to list available groups would be
> > good
> >
>
> Maybe you weren't aware of it - 'whoami /groups'

No, that takes the data from the account, and is wildly different from
what is in a token (need winsg -l for that!!).

>
> > - WinSG should be installed in C:\Windows\system32\ alongside cmd.exe
> >
>
> Not IMHO.

Why?

>
>
> > - Native Windows utilities use /? for help, not --help
> >
>
> This is really only a loosely followed convention and not all Windows tools
> follow it. (Example: Windows PowerShell cmdlet parameters use "-", not "/".)

Maybe powershell is just the exception, as they try to compete with bash?

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

-- 
Problem reports:  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: Run explorer.exe with Cygwin newgrp(1) - same user but different primary group

[Dan Shelton via Cygwin]

On Wed, 29 May 2024 at 15:41, Bill Stewart via Cygwin  wrote:
>
> On Tue, May 28, 2024 at 9:36 PM Dan Shelton wrote:
>
>
> > Does anyone know how to run Windows explorer.exe with Cygwin
> > /bin/newgrp, so all new files created by explorer.exe use that new
> > primary group, and all programs launched by explorer.exe use that same
> > primary group?
> >
>
> As I understand it, Explorer always starts unelevated as the current user.
> This is by design for security reasons.

How can someone run explorer as Admin then?

FYI winsg -c eng4grp -c 'explorer /nouacheck /separate' does not work.

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

-- 
Problem reports:  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: Run explorer.exe with Cygwin newgrp(1) - same user but different primary group

[Dan Shelton via Cygwin]

On Wed, 29 May 2024 at 15:41, Bill Stewart via Cygwin  wrote:
>
> On Tue, May 28, 2024 at 9:36 PM Dan Shelton wrote:
>
>
> > Does anyone know how to run Windows explorer.exe with Cygwin
> > /bin/newgrp, so all new files created by explorer.exe use that new
> > primary group, and all programs launched by explorer.exe use that same
> > primary group?
> >
>
> As I understand it, Explorer always starts unelevated as the current user.
> This is by design for security reasons.
>

But does WinSG elevate the process? I thought it just takes an
existing group from within the token, and sets it as the primary
group.

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

-- 
Problem reports:  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: TeX Live 2024:: asympote 2.88-1 hangs after outputting a pdf

[Ken Brown via Cygwin]

On 5/30/2024 3:39 PM, Jon Turney via Cygwin wrote:

On 27/05/2024 16:14, Ken Brown via Cygwin wrote:

On 5/27/2024 5:17 AM, Lemures Lemniscati via Cygwin wrote:

On Sun, 26 May 2024 18:02:54 -0400, Ken Brown via Cygwin
Here is a log from gdb. Will it help?
  run
  info threads
  info stack
  list


$ HOME=/tmp gdb --args asy -vv -f pdf test

[...]

Thread 5 "sig" received signal SIGTRAP, Trace/breakpoint trap.


I don't get this SIGRAP when I run the same command.  The program just 
runs to completion.  Maybe someone can explain what might cause this.  
I have no idea.


Getting SIGTRAP rather than SIGSEGV or whatever here seems like it might 
be an unintended consequence of the dumper changes I made in 3.5.0.


0  0x7ffd8487d313 in KERNELBASE!DebugBreak () from 
/cygdrive/c/WINDOWS/System32/KERNELBASE.dll
#1  0x7ffd527f6367 in break_here () at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:472
#2  0x7ffd52810349 in try_to_debug () at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/exceptions.cc:597
#3  exception::handle (e=0x28bc6f0, frame=, 
in=0x28bc200, dispatch=)

    at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/exceptions.cc:810
#4  0x7ffd871b49ff in ntdll!.chkstk () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#5  0x7ffd8712e466 in ntdll!RtlFindCharInUnicodeString () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#6  0x7ffd871b39ee in ntdll!KiUserExceptionDispatcher () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x7ffd5291bdd4 in init_cygheap::find_tls (this=0x8, 
sig=20, issig_wait=@0x28bca3f: false)


The important thing in this backtrace is that an exception is occurring 
in find_tls, not that we break into the debugging while handling it 
(rather than rethrowing the exception to let the debugger handle it, 
which is maybe what should happen? and did in previous versions of 
Cygwin??)


Thanks.  So find_tls, running in the "sig" thread, is getting an 
exception while Cygwin is trying to process signal 20.  The latter is 
SIGCHLD.  Based on Lem's original report, I would guess that the SIGCHLD 
is generated by ghostscript exiting when it finishes processing the 
file.  An error in processing the signal would explain the fact that asy 
hangs.


I'm not familiar enough with Cygwin's signal-handling code to be able to 
debug this, especially since I can't reproduce the problem.


It would be helpful if others could try Lem's recipe and see if they can 
reproduce it.


Ken

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

Re: TeX Live 2024:: asympote 2.88-1 hangs after outputting a pdf

[Jon Turney via Cygwin]

On 27/05/2024 16:14, Ken Brown via Cygwin wrote:

On 5/27/2024 5:17 AM, Lemures Lemniscati via Cygwin wrote:

On Sun, 26 May 2024 18:02:54 -0400, Ken Brown via Cygwin
Here is a log from gdb. Will it help?
  run
  info threads
  info stack
  list


$ HOME=/tmp gdb --args asy -vv -f pdf test

[...]

Thread 5 "sig" received signal SIGTRAP, Trace/breakpoint trap.


I don't get this SIGRAP when I run the same command.  The program just 
runs to completion.  Maybe someone can explain what might cause this.  I 
have no idea.


Getting SIGTRAP rather than SIGSEGV or whatever here seems like it might 
be an unintended consequence of the dumper changes I made in 3.5.0.



0  0x7ffd8487d313 in KERNELBASE!DebugBreak () from 
/cygdrive/c/WINDOWS/System32/KERNELBASE.dll
#1  0x7ffd527f6367 in break_here () at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:472
#2  0x7ffd52810349 in try_to_debug () at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/exceptions.cc:597
#3  exception::handle (e=0x28bc6f0, frame=, in=0x28bc200, 
dispatch=)
at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/exceptions.cc:810
#4  0x7ffd871b49ff in ntdll!.chkstk () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#5  0x7ffd8712e466 in ntdll!RtlFindCharInUnicodeString () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#6  0x7ffd871b39ee in ntdll!KiUserExceptionDispatcher () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x7ffd5291bdd4 in init_cygheap::find_tls (this=0x8, sig=20, 
issig_wait=@0x28bca3f: false)


The important thing in this backtrace is that an exception is occurring 
in find_tls, not that we break into the debugging while handling it 
(rather than rethrowing the exception to let the debugger handle it, 
which is maybe what should happen? and did in previous versions of Cygwin??)



--
Problem reports:  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: ftp.acc.umu.se domain move

[Jon Turney via Cygwin]

On 23/05/2024 15:13, Niklas Edmundsson via Cygwin wrote:


Hi!

The contact information, and preferably the host/mirror name, for the
mirror provided by Academic Computer Club (ACC) needs to be changed as
ACC is moving to a new domain. To verify the validity of this
message, point a web browser towards https://ftp.acc.umu.se/ and
notice that the top-level redirects to https://mirror.accum.se/. Also
notice the text about acc.umu.se at the top of the page.

Background: Umeå University has decided that non-official services are
no longer allowed to exist as a sub domain to umu.se. As a consequence
of this we are moving all services from the acc.umu.se domain.

Contact email:

Changes from ftp-...@acc.umu.se to ftp-...@accum.se. The old email
address will stop working sometime in the future.

File archive host name:

Official name changes from ftp.acc.umu.se to mirror.accum.se. The old
host name will continue to work for quite some time (years), but new
deployments should move to using a non-acc.umu.se name.  Since we are
lazy sysadmins, we have also registered the ac2.se (ACC=AC^2) domain
and lots of aliases so ftp.ac2.se also works.

If you have references to other acc.umu.se services (for example
www.acc.umu.se), replace the domain part with accum.se (ie
www.accum.se).


I've updated this in our mirror list.

Thanks for providing a cygwin mirror.


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

[ITP] python-license-expression and cygport PoC patch (was: calm: SPDX licence list data update please)

[Brian Inglis via Cygwin-apps]

On 2024-05-28 08:37, Brian Inglis via Cygwin-apps wrote:

On 2024-05-27 15:15, Jon Turney via Cygwin-apps wrote:

On 24/05/2024 17:08, Brian Inglis via Cygwin-apps wrote:
Can we please get the SPDX licence list data updated in calm to 3.24 sometime 
if possible as the licences complained about below have been in 


This is not quite straightforward, as the system python on sourceware is 
currently python3.6, and the last supported nexB/license-expression on that is 
30.0.0, and moving to a later one has some wrinkles, since various pieces of 
interconnected stuff aren't venv'd (yet?).



If not, perhaps I could be of some help if I knew requirements?


So, there aren't any requirements here except "validate the SPDX license 
expression to detect maintainer mistakes and typos".


It looks like using that python module might have been a mistake.

I'm not sure why it needs to contain it's own version of the license data, 
ideally we'd have something that read the official SPDX data (ratelimited to 
once per day or something. It looks like maybe this would possible to do by 
feeding our own license list into the module rather than using it's built in 
one, but one could hope for this to be built in already...)


Would we or should we also allow specifying LICENSE_URI (as I have been doing) 
like PEP 639 license-files, with defaults searched as suggested:


 "LICEN[CS]E*", "COPYING*", "NOTICE*", "AUTHORS*"?

where globs and source paths are allowed as usual in cygport files, and 
directories may match these paths, implicitly including file entries, but no 
file *contents* checked, unless we see a need in future, to generate and 
validate licences.


I found github/nexB/license-expression Python package to do SPDX licence checks 
with current data, developed by the same team doing SPDX-toolkit for SPDX, 
working with Fedora folks et al.


Successful attempt to package Python license-expression (without tests):

https://cygwin.com/cgi-bin2/jobs.cgi?id=8210

cygport attached and at:

https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a

log at:

https://github.com/cygwin/scallywag/actions/runs/9293093201

The package installs and runs using PoC attached in spdx-license-expression.py 
script hooked into /usr/share/cygport/lib/pkg_pkg.cygpart license hint addition 
patch attached.


I also ran a test of the Python script and module against all package source 
cygport files declaring licences which I maintain or ever looked at, including a 
git/cygwin-packages/*.cygport download from 2023-02, showing the results in the 
attached log.
I also attempted to trap the exceptions in the script, but that does not seem to 
work in any documented obvious manner, but I do not know enough Python to 
address this.


If someone else who knows python cared to adopt and improve this in a more 
normal manner, and incorporate this more smoothly into cygport, we could all 
appreciate that.

Alternatively, some candid comments and frank feedback might allow me to do so! 
;^>

--
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#|/usr/bin/cygport
# python-license-expression.cygport - Python license-expression Cygwin package 
build control script definitions

inherit python-wheel

NAME=python-license-expression
VERSION=30.3.0
RELEASE=1

BASE=${NAME#python-}

CATEGORY=Python
SUMMARY="Python license expression utility library"
DESCRIPTION="Python utility library to parse, compare, simplify and normalize
license expressions (such as SPDX license expressions)."

ARCH=noarch

LICENSE=Apache-2.0
LICENSE_SPDX="SPDX-License-Identifier: $LICENSE"
# SPDX-License-Identifier: Apache-2.0
LICENSE_URI="NOTICE apache-2.0.LICENSE"

DOCS="
license-expression.ABOUT
AUTHORS.rst CHANGELOG.rst CODE_OF_CONDUCT.rst README.rst
$LICENSE_URI
"

#!/usr/bin/python
"""spdx-license-expression.py - validate SPDX licence expression

Usage: spdx-license-expression.py 

Author: Brian Inglis 
"""

from license_expression import get_spdx_licensing
import sys

def main(args):
if len(args) != 1:
print("usage: " + sys.argv[0] + " ",
  file=sys.stderr)
return 1

licensing = get_spdx_licensing()
expression = args[0]
errs = licensing.validate(expression).errors
#ExpressionInfo(
#   original_expression='... and MIT and GPL-2.0+',
#   normalized_expression=None,
#   errors=['Unknown license key(s): ...'],
#   invalid_symbols=['...']
#)
for e in errs:
print(e, file=sys.stderr)
if len(errs) >= 1:
return 2

if __name__ == "__main__":
sys.exit(main(sys.argv[1:]))

--- origsrc/lib/pkg_pkg.cygpart.orig2023-03-08 

Fwd: newer version of mingw64-*-win-iconv ?

[Brian Inglis via Cygwin-apps]

On 2024-05-29 02:53, Bruno Haible via Cygwin wrote:

Brian Inglis wrote:

Ran playground local and CI builds of these packages at v0.0.8 successfully:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv
and   https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-i686-win-iconv



Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding?


v0.0.8 is good enough. Hardly anyone needs UCS-2-INTERNAL. But many programs
need a working ASCII encoding, which is fixed in v0.0.8.


NMU updates of the above packages would be appreciated, based on those
mingw...-win-iconv playground branch updates, if someone could help, please?

--
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: newer version of mingw64-*-win-iconv ?

[Brian Inglis via Cygwin]

On 2024-05-29 02:53, Bruno Haible via Cygwin wrote:

Brian Inglis wrote:

Ran playground local and CI builds of these packages at v0.0.8 successfully:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv
and   https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-i686-win-iconv



Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding?


v0.0.8 is good enough. Hardly anyone needs UCS-2-INTERNAL. But many programs
need a working ASCII encoding, which is fixed in v0.0.8.


NMU updates of the above packages would be appreciated, based on those
mingw...-win-iconv playground branch updates, if someone could help, please?

--
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: SRW locks

[Bruno Haible via Cygwin]

Noel Grandin wrote:
> > Still: Does ReleaseSRWLockExclusive notify other threads?
> > 
> 
> Of course? How else would a lock work, it must release other waiters?
> 
> It might not be a fair lock though, which is not a problem for this 
> situation, which does not require fair locking.
> 
> 
> > Functionally, the INIT_ONCE looks interesting. But, like Takashi Yano 
> > mentioned,
> > how would you make it fit into a pthread_once_t that is defined as
> >struct { pthread_mutex_t mutex; int state; }
> > ?
> 
> Something like:
> 
> struct once {
> union {
>pthread_mutex_t old_mutex_field_for_size_compatibility;
>SRWLOCK lock = SRWLOCK_INIT;
>  };
>  int state;
> };

Reading [1], it seems that this might indeed work, and be faster than code
that uses CRITICAL_SECTIONs.

Still, something to watch out is this bug [2].

All in all, I would say that every such change ought to be tested with a
nontrivial test program that performs several thousands of rounds.

Bruno

[1] https://marabos.nl/atomics/os-primitives.html
[2] 
https://old.reddit.com/r/cpp/comments/1b55686/maybe_possible_bug_in_stdshared_mutex_on_windows/




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

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Bruno Haible via Cygwin]

Takashi Yano wrote in cygwin-patches:
> With v3 patch:
> int
> pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> {
>   /* Sign bit of once_control->state is used as done flag */
>   if (once_control->state & INT_MIN)
> return 0;
> 
>   /* The type of _control->state is int *, which is compatible with
>  LONG * (the type of the first argument of InterlockedIncrement()). */
>   InterlockedIncrement (_control->state);
>   pthread_mutex_lock (_control->mutex);
>   if (!(once_control->state & INT_MIN))
> {
>   init_routine ();
>   InterlockedOr (_control->state, INT_MIN);
> }
>   pthread_mutex_unlock (_control->mutex);
>   if (InterlockedDecrement (_control->state) == INT_MIN)
> pthread_mutex_destroy (_control->mutex);
>   return 0;
> }

Looks good to me.

If it passes 10 or 100 runs of my test program from
,
I would say, it's good.

Thanks!

Bruno




-- 
Problem reports:  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: Use Cygwin gcc or clang to build with ucrt?

[Jon Turney via Cygwin]

On 22/05/2024 00:30, Dan Shelton via Cygwin wrote:

Hello!

Can Cygwin gcc or clang be used to use ucrt instead of cygwin.dll/mingw.dll?


We provide a cross-compiler targeting the Win32 API, but this only 
support  msvcrt currently.


[1] https://cygwin.com/faq.html#faq.programming.win32-no-cygwin


--
Problem reports:  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: LD_PRELOAD for Win32?

[Jon Turney via Cygwin]

On 25/05/2024 22:55, Martin Wege via Cygwin wrote:

Hello,

Does Cygwin or Win32 have something like LD_PRELOAD, so I can
override/substitute functions in a DLL or EXE, like it is common for
UNIX/Linux ELF shared libraries?


This is not generally available on Win32, due to limitations of the PE 
file format.


(basically, the import table lists symbols which are imported, and where 
they are imported from, so the module (shared library or executable) 
which provides a given symbol is determined when the module is *linked*, 
not when it is loaded.



However, when googling "cygwin LD_PRELOAD" (which surely you must have 
done before asking this question?) I discover that there's some voodoo 
in the cygwin DLL (hookapi.cc) which claims to do something like that, 
but it seems (i) this requires the preloaded DLL to explicitly hook 
functions it's overriding, and (ii) maybe only works on functions 
imported by the running executable.


It would be nice to have some documentation for that, and/or a simple 
example which could serve as a testcase.


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

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Takashi Yano]

On Thu, 30 May 2024 20:50:12 +0900
Takashi Yano  wrote:
> On Thu, 30 May 2024 12:14:10 +0200
> Bruno Haible wrote:
> > Takashi Yano wrote in cygwin-patches:
> > >  int
> > >  pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> > >  {
> > > -  // already done ?
> > > -  if (once_control->state)
> > > +  /* Sign bit of once_control->state is used as done flag */
> > > +  if (once_control->state & INT_MIN)
> > >  return 0;
> > >  
> > > +  /* The type of _control->state is int *, which is compatible with
> > > + LONG * (the type of the first argument of InterlockedIncrement()). 
> > > */
> > > +  InterlockedIncrement (_control->state);
> > >pthread_mutex_lock (_control->mutex);
> > > -  /* Here we must set a cancellation handler to unlock the mutex if 
> > > needed */
> > > -  /* but a cancellation handler is not the right thing. We need this in 
> > > the thread
> > > -   *cleanup routine. Assumption: a thread can only be in one 
> > > pthread_once routine
> > > -   *at a time. Stote a mutex_t *in the pthread_structure. if that's non 
> > > null unlock
> > > -   *on pthread_exit ();
> > > -   */
> > 
> > Sorry, in a unified diff form this is unreadable. One needs to look at the
> > entire function. A context diff would have been better. So:
> > 
> > int
> > pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> > {
> >   /* Sign bit of once_control->state is used as done flag */
> >   if (once_control->state & INT_MIN)
> > return 0;
> > 
> >   /* The type of _control->state is int *, which is compatible with
> >  LONG * (the type of the first argument of InterlockedIncrement()). */
> >   InterlockedIncrement (_control->state);
> >   pthread_mutex_lock (_control->mutex);
> >   if (!(once_control->state & INT_MIN))
> > {
> >   init_routine ();
> >   once_control->state |= INT_MIN;
> > }
> >   pthread_mutex_unlock (_control->mutex);
> >   if (InterlockedDecrement (_control->state) == INT_MIN)
> > pthread_mutex_destroy (_control->mutex);
> >   return 0;
> > }

With v3 patch:
int
pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
{
  /* Sign bit of once_control->state is used as done flag */
  if (once_control->state & INT_MIN)
return 0;

  /* The type of _control->state is int *, which is compatible with
 LONG * (the type of the first argument of InterlockedIncrement()). */
  InterlockedIncrement (_control->state);
  pthread_mutex_lock (_control->mutex);
  if (!(once_control->state & INT_MIN))
{
  init_routine ();
  InterlockedOr (_control->state, INT_MIN);
}
  pthread_mutex_unlock (_control->mutex);
  if (InterlockedDecrement (_control->state) == INT_MIN)
pthread_mutex_destroy (_control->mutex);
  return 0;
}

-- 
Takashi Yano 

[PATCH v3] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Takashi Yano]

To avoid race issues, pthread::once() uses pthread_mutex. This caused
the handle leak which was fixed by the commit 2c5433e5da82. However,
this fix introduced another race issue, i.e., the mutex may be used
after it is destroyed. This patch fixes the issue. Special thanks to
Bruno Haible for discussing how to fix the issue.

Addresses: https://cygwin.com/pipermail/cygwin/2024-May/255987.html
Reported-by: Bruno Haible 
Fixes: 2c5433e5da82 ("Cygwin: pthread: Fix handle leak in pthread_once.")
Reviewed-by:
Signed-off-by: Takashi Yano 
---
 winsup/cygwin/local_includes/thread.h |  2 +-
 winsup/cygwin/thread.cc   | 23 +--
 2 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/winsup/cygwin/local_includes/thread.h 
b/winsup/cygwin/local_includes/thread.h
index 9939c4224..b3496281e 100644
--- a/winsup/cygwin/local_includes/thread.h
+++ b/winsup/cygwin/local_includes/thread.h
@@ -674,7 +674,7 @@ class pthread_once
 {
 public:
   pthread_mutex_t mutex;
-  int state;
+  volatile int state;
 };
 
 /* shouldn't be here */
diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
index 0f8327831..c78c1e63b 100644
--- a/winsup/cygwin/thread.cc
+++ b/winsup/cygwin/thread.cc
@@ -2045,27 +2045,22 @@ pthread::create (pthread_t *thread, const 
pthread_attr_t *attr,
 int
 pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
 {
-  // already done ?
-  if (once_control->state)
+  /* Sign bit of once_control->state is used as done flag */
+  if (once_control->state & INT_MIN)
 return 0;
 
+  /* The type of _control->state is int *, which is compatible with
+ LONG * (the type of the first argument of InterlockedIncrement()). */
+  InterlockedIncrement (_control->state);
   pthread_mutex_lock (_control->mutex);
-  /* Here we must set a cancellation handler to unlock the mutex if needed */
-  /* but a cancellation handler is not the right thing. We need this in the 
thread
-   *cleanup routine. Assumption: a thread can only be in one pthread_once 
routine
-   *at a time. Stote a mutex_t *in the pthread_structure. if that's non null 
unlock
-   *on pthread_exit ();
-   */
-  if (!once_control->state)
+  if (!(once_control->state & INT_MIN))
 {
   init_routine ();
-  once_control->state = 1;
-  pthread_mutex_unlock (_control->mutex);
-  while (pthread_mutex_destroy (_control->mutex) == EBUSY);
-  return 0;
+  InterlockedOr (once_control->state, INT_MIN);
 }
-  /* Here we must remove our cancellation handler */
   pthread_mutex_unlock (_control->mutex);
+  if (InterlockedDecrement (_control->state) == INT_MIN)
+pthread_mutex_destroy (_control->mutex);
   return 0;
 }
 
-- 
2.45.1

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Takashi Yano]

On Thu, 30 May 2024 12:14:10 +0200
Bruno Haible wrote:
> Takashi Yano wrote in cygwin-patches:
> >  int
> >  pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> >  {
> > -  // already done ?
> > -  if (once_control->state)
> > +  /* Sign bit of once_control->state is used as done flag */
> > +  if (once_control->state & INT_MIN)
> >  return 0;
> >  
> > +  /* The type of _control->state is int *, which is compatible with
> > + LONG * (the type of the first argument of InterlockedIncrement()). */
> > +  InterlockedIncrement (_control->state);
> >pthread_mutex_lock (_control->mutex);
> > -  /* Here we must set a cancellation handler to unlock the mutex if needed 
> > */
> > -  /* but a cancellation handler is not the right thing. We need this in 
> > the thread
> > -   *cleanup routine. Assumption: a thread can only be in one pthread_once 
> > routine
> > -   *at a time. Stote a mutex_t *in the pthread_structure. if that's non 
> > null unlock
> > -   *on pthread_exit ();
> > -   */
> 
> Sorry, in a unified diff form this is unreadable. One needs to look at the
> entire function. A context diff would have been better. So:
> 
> int
> pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> {
>   /* Sign bit of once_control->state is used as done flag */
>   if (once_control->state & INT_MIN)
> return 0;
> 
>   /* The type of _control->state is int *, which is compatible with
>  LONG * (the type of the first argument of InterlockedIncrement()). */
>   InterlockedIncrement (_control->state);
>   pthread_mutex_lock (_control->mutex);
>   if (!(once_control->state & INT_MIN))
> {
>   init_routine ();
>   once_control->state |= INT_MIN;
> }
>   pthread_mutex_unlock (_control->mutex);
>   if (InterlockedDecrement (_control->state) == INT_MIN)
> pthread_mutex_destroy (_control->mutex);
>   return 0;
> }
> 
> 1) The overall logic seems right (using bit 31 of the state word as a
> 'done' bit), and the last thread that used the mutex destroys it.
> 
> 2) However, the 'state' field is not volatile, and therefore the memory
> model does not guarantee that an assignment
> 
>  once_control->state |= INT_MIN;
> 
> done in one thread has an effect on the values seen by other threads
> that do
> 
>  if (once_control->state & INT_MIN)
> 
> As long as there is no synchronization between the two CPUs that execute
> the two threads, one CPU may indefinitely see the old value of
> once_control->state, while the other CPU's new value is not being
> "broadcasted" to all CPUs.

OK. I'll add volatile attribute to state in thread.h.

> 3) Also, as noted by Noel Grandin, there is a race: If one thread does
> 
>  once_control->state |= INT_MIN;
> 
> while another thread does
> 
>  InterlockedIncrement (_control->state);
> or
>  InterlockedDecrement (_control->state)
> 
> the result can be that the increment or decrement is nullified. If it's
> an increment that gets nullified, the pthread_mutex_destroy occurs too
> early, with fatal consequences. If it's a decrement that get nullified,
> the pthread_mutex_destroy never happens, and there is therefore a resource
> leak.

That's right. I'll use InterlockedOr(_control->state, INT_MIN)
here instead.

> 4) Does the test program that I posted in
>  now pass?
> Notes:
>   - You should set
>   #define ENABLE_DEBUGGING 0
> because with the debugging output, it nearly always succeeds.
>   - You should run it 10 times in a row, not just once. It may well
> succeed 9 out of 10 times and fail 1 out of 10 times.

I start to run a few hours ago:
while true; do ./a.exe; done
and it does not detect any errors so far.

-- 
Takashi Yano 

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Noel Grandin via Cygwin]

On 5/30/2024 11:15 AM, Bruno Haible wrote:


Still: Does ReleaseSRWLockExclusive notify other threads?



Of course? How else would a lock work, it must release other waiters?

It might not be a fair lock though, which is not a problem for this situation, 
which does not require fair locking.



Functionally, the INIT_ONCE looks interesting. But, like Takashi Yano mentioned,
how would you make it fit into a pthread_once_t that is defined as
   struct { pthread_mutex_t mutex; int state; }
?


Something like:

struct once {
   union {
  pthread_mutex_t old_mutex_field_for_size_compatibility;
  SRWLOCK lock = SRWLOCK_INIT;
};
int state;
};

Regards, Noel Grandin

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

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Bruno Haible via Cygwin]

Takashi Yano wrote in cygwin-patches:
>  int
>  pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
>  {
> -  // already done ?
> -  if (once_control->state)
> +  /* Sign bit of once_control->state is used as done flag */
> +  if (once_control->state & INT_MIN)
>  return 0;
>  
> +  /* The type of _control->state is int *, which is compatible with
> + LONG * (the type of the first argument of InterlockedIncrement()). */
> +  InterlockedIncrement (_control->state);
>pthread_mutex_lock (_control->mutex);
> -  /* Here we must set a cancellation handler to unlock the mutex if needed */
> -  /* but a cancellation handler is not the right thing. We need this in the 
> thread
> -   *cleanup routine. Assumption: a thread can only be in one pthread_once 
> routine
> -   *at a time. Stote a mutex_t *in the pthread_structure. if that's non null 
> unlock
> -   *on pthread_exit ();
> -   */

Sorry, in a unified diff form this is unreadable. One needs to look at the
entire function. A context diff would have been better. So:

int
pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
{
  /* Sign bit of once_control->state is used as done flag */
  if (once_control->state & INT_MIN)
return 0;

  /* The type of _control->state is int *, which is compatible with
 LONG * (the type of the first argument of InterlockedIncrement()). */
  InterlockedIncrement (_control->state);
  pthread_mutex_lock (_control->mutex);
  if (!(once_control->state & INT_MIN))
{
  init_routine ();
  once_control->state |= INT_MIN;
}
  pthread_mutex_unlock (_control->mutex);
  if (InterlockedDecrement (_control->state) == INT_MIN)
pthread_mutex_destroy (_control->mutex);
  return 0;
}

1) The overall logic seems right (using bit 31 of the state word as a
'done' bit), and the last thread that used the mutex destroys it.

2) However, the 'state' field is not volatile, and therefore the memory
model does not guarantee that an assignment

 once_control->state |= INT_MIN;

done in one thread has an effect on the values seen by other threads
that do

 if (once_control->state & INT_MIN)

As long as there is no synchronization between the two CPUs that execute
the two threads, one CPU may indefinitely see the old value of
once_control->state, while the other CPU's new value is not being
"broadcasted" to all CPUs.

3) Also, as noted by Noel Grandin, there is a race: If one thread does

 once_control->state |= INT_MIN;

while another thread does

 InterlockedIncrement (_control->state);
or
 InterlockedDecrement (_control->state)

the result can be that the increment or decrement is nullified. If it's
an increment that gets nullified, the pthread_mutex_destroy occurs too
early, with fatal consequences. If it's a decrement that get nullified,
the pthread_mutex_destroy never happens, and there is therefore a resource
leak.

4) Does the test program that I posted in
 now pass?
Notes:
  - You should set
  #define ENABLE_DEBUGGING 0
because with the debugging output, it nearly always succeeds.
  - You should run it 10 times in a row, not just once. It may well
succeed 9 out of 10 times and fail 1 out of 10 times.

Bruno




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

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Bruno Haible via Cygwin]

Noel Grandin wrote:
> > SRW locks are spin-locks. Since they are only pointer-sized,
> > ReleaseSRWLockExclusive cannot notify other threads — unlike 
> > CRITICAL_SECTION.
> > Therefore, AcquireSRWLockExclusive must busy-loop when the lock is already
> > held.
> > 
> 
> No, they only spin briefly, before calling into the OS to sleep - see the 
> article about their internals here:
> 
> https://learn.microsoft.com/en-us/archive/msdn-magazine/2012/november/windows-with-c-the-evolution-of-synchronization-in-windows-and-c#slim-readerwriter-lock

Still: Does ReleaseSRWLockExclusive notify other threads?

> Alternatively, Windows already has an API for init-once i.e.
>
> https://learn.microsoft.com/en-us/windows/win32/sync/one-time-initialization

Functionally, the INIT_ONCE looks interesting. But, like Takashi Yano mentioned,
how would you make it fit into a pthread_once_t that is defined as
  struct { pthread_mutex_t mutex; int state; }
?

Bruno




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

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Noel Grandin via Cygwin]

On 5/30/2024 10:47 AM, Bruno Haible wrote:


SRW locks are spin-locks. Since they are only pointer-sized,
ReleaseSRWLockExclusive cannot notify other threads — unlike CRITICAL_SECTION.
Therefore, AcquireSRWLockExclusive must busy-loop when the lock is already
held.



No, they only spin briefly, before calling into the OS to sleep - see the 
article about their internals here:

https://learn.microsoft.com/en-us/archive/msdn-magazine/2012/november/windows-with-c-the-evolution-of-synchronization-in-windows-and-c#slim-readerwriter-lock


Alternatively, Windows already has an API for init-once i.e.
  https://learn.microsoft.com/en-us/windows/win32/sync/one-time-initialization

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

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Bruno Haible via Cygwin]

Noel Grandin wrote in cygwin-patches:
> Pardon my ignorance, but why not rather use the Windows SRWLock functionality?
> https://learn.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--srw--locks
> 
> SRW locks are very fast, only require a single pointer-sized storage area, 
> can be statically initialised, and do not 
> need to be destroyed, so there is no possibibilty of memory leakage.
> 
> Then the implementation simply becomes
> 
> int pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> {
>  AcquireSRWLockExclusive(once_control->lock);
>  if (!once_control->state)
>  {
>  init_routine()
>  once_control->state = 1;
>  }
>  ReleaseSRWLockExclusive(once_control->lock);
> }

SRW locks are spin-locks. Since they are only pointer-sized,
ReleaseSRWLockExclusive cannot notify other threads — unlike CRITICAL_SECTION.
Therefore, AcquireSRWLockExclusive must busy-loop when the lock is already
held.

But busy-looping is a bad practice for pthread_once. In the case,
for example, that the init_routine reads a multi-megabyte data
structure into memory and parses it, the other threads that wait
on the result of this operation would by busy-looping, eating
full CPU time.

Bruno




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

Request: please update to coreutils >=9.1

[Lluís Batlle i Rossell via Cygwin]

Hello,

there are 3 coreutils versions in cygwin: 8.26, 8.32 and 9.0.

8.32 has a big bug on "cp" that leaks file descriptors. Copying many
files it dies with Too many open files.

9.0 has a bug that makes any chmod fail silently if it is applied to
symlink.

Both bugs have the impact that we are stuck to coreutils 8.26 for our
build scripts, that use 'cp -R' and 'chmod -R' and would otherwise fail.

Can someone update to a newer coreutils? 9.1 or later.

(I'm not subscribed to the list, please keep me in Cc)

Thank you,
Lluís


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

[PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Takashi Yano]

To avoid race issues, pthread::once() uses pthread_mutex. This caused
the handle leak which was fixed by the commit 2c5433e5da82. However,
this fix introduced another race issue, i.e., the mutex may be used
after it is destroyed. This patch fixes the issue. Special thanks to
Bruno Haible for discussing how to fix the issue.

Addresses: https://cygwin.com/pipermail/cygwin/2024-May/255987.html
Reported-by: Bruno Haible 
Fixes: 2c5433e5da82 ("Cygwin: pthread: Fix handle leak in pthread_once.")
Reviewed-by:
Signed-off-by: Takashi Yano 
---
 winsup/cygwin/thread.cc | 23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
index 0f8327831..cd57a6ac1 100644
--- a/winsup/cygwin/thread.cc
+++ b/winsup/cygwin/thread.cc
@@ -2045,27 +2045,22 @@ pthread::create (pthread_t *thread, const 
pthread_attr_t *attr,
 int
 pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
 {
-  // already done ?
-  if (once_control->state)
+  /* Sign bit of once_control->state is used as done flag */
+  if (once_control->state & INT_MIN)
 return 0;
 
+  /* The type of _control->state is int *, which is compatible with
+ LONG * (the type of the first argument of InterlockedIncrement()). */
+  InterlockedIncrement (_control->state);
   pthread_mutex_lock (_control->mutex);
-  /* Here we must set a cancellation handler to unlock the mutex if needed */
-  /* but a cancellation handler is not the right thing. We need this in the 
thread
-   *cleanup routine. Assumption: a thread can only be in one pthread_once 
routine
-   *at a time. Stote a mutex_t *in the pthread_structure. if that's non null 
unlock
-   *on pthread_exit ();
-   */
-  if (!once_control->state)
+  if (!(once_control->state & INT_MIN))
 {
   init_routine ();
-  once_control->state = 1;
-  pthread_mutex_unlock (_control->mutex);
-  while (pthread_mutex_destroy (_control->mutex) == EBUSY);
-  return 0;
+  once_control->state |= INT_MIN;
 }
-  /* Here we must remove our cancellation handler */
   pthread_mutex_unlock (_control->mutex);
+  if (InterlockedDecrement (_control->state) == INT_MIN)
+pthread_mutex_destroy (_control->mutex);
   return 0;
 }
 
-- 
2.45.1

Re: [PATCH] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Takashi Yano]

On Wed, 29 May 2024 13:17:47 +0200
Bruno Haible wrote:
> Takashi Yano wrote:
> > To avoid race issues, pthread::once() uses pthread_mutex. This caused
> > the handle leak which was fixed by the commit 2c5433e5da82. However,
> > this fix introduced another race issue, i.e., the mutex may be used
> > after it is destroyed. With this patch, do not use pthread_mutex in
> > pthread::once() to avoid both issues. Instead, InterlockedExchage()
> > is used.
> 
> This patch is bogus as well, because it allows one thread to return
> from a pthread_once call while the other thread is currently
> executing the init_routine and not yet done with it.
> 
> > +  if (!InterlockedExchange (_control->state, 1))
> > +init_routine ();
> >return 0;
> >  }
> 
> There is no code after the init_routine () call here. This means
> that other threads are not notified when the init_routine () call
> is complete. Therefore this implementation *cannot* be correct.
> 
> See: Assume thread1 and thread2 call pthread_once on the same
> once_control.
> 
> thread1  thread2
> ---  ---
> 
>  enters pthread_once   enters pthread_once
> 
>  sets state to 1
> 
>sees that state == 1
> 
>returns from pthread_once
> 
>executes code that assumes
>init_routine has completed
> 
>  starts executing
>  init_routine
> 
>  finished executing
>  init_routine
> 
>  returns from pthread_once

Thanks for pointing out that.

I'll submit a v2 patch. Please have a look.

-- 
Takashi Yano 

[ITP] python-license-expression and cygport PoC patch (was: calm: SPDX licence list data update please)

[Brian Inglis via Cygwin-apps]

On 2024-05-28 08:37, Brian Inglis via Cygwin-apps wrote:

On 2024-05-27 15:15, Jon Turney via Cygwin-apps wrote:

On 24/05/2024 17:08, Brian Inglis via Cygwin-apps wrote:


Can we please get the SPDX licence list data updated in calm to 3.24 sometime 
if possible as the licences complained about below have been in 


I thought I wrote about this the last time you asked, but obviously not.


Thought not, but after recent reminder, not so sure now ;^>

This is not quite straightforward, as the system python on sourceware is 
currently python3.6, and the last supported nexB/license-expression on that is 
30.0.0, and moving to a later one has some wrinkles, since various pieces of 
interconnected stuff aren't venv'd (yet?).



releases for nearly a year since 3.21:



If not, perhaps I could be of some help if I knew requirements?


So, there aren't any requirements here except "validate the SPDX license 
expression to detect maintainer mistakes and typos".


It looks like using that python module might have been a mistake.

I'm not sure why it needs to contain it's own version of the license data, 
ideally we'd have something that read the official SPDX data (ratelimited to 
once per day or something. It looks like maybe this would possible to do by 
feeding our own license list into the module rather than using it's built in 
one, but one could hope for this to be built in already...)


There have been changes in how to specify exceptions using WITH.

It would also be useful if it could also be taught to accept 'LicenseRef-.*' 
identifiers.


Ditto ExceptionRef-.* but that and LicenseRef-.* do not seem to be allowed by 
PEP 639, as they unrealistically expect projects to change existing licences, 
whereas we have to deal with historical reality like Fedora!


So, suggestions on a different module to use, or patches to make this work 
better, or cogent arguments why we should just remove this validation are all 
welcome.


How about if we delegate licence validation to cygport, as someone recently 
offered, or as currently done in calm, with current Cygwin python - add licence 
validation hint to src hint - if not there, calm does it as now?


Would we or should we also allow specifying LICENSE_URI (as I have been doing) 
like PEP 639 license-files, with defaults searched as suggested:


 "LICEN[CS]E*", "COPYING*", "NOTICE*", "AUTHORS*"?

where globs and source paths are allowed as usual in cygport files, and 
directories may match these paths, implicitly including file entries, but no 
file *contents* checked, unless we see a need in future, to generate and 
validate licences.



You can also now remove the exceptions in calm/fixes.py(licmap):


Thanks, will do so.


Cheers!


I found github/nexB/license-expression Python package to do SPDX licence checks 
with current data, developed by the same team doing SPDX-toolkit for SPDX, 
working with Fedora folks et al.


Successful attempt to package Python license-expression (without tests):

https://cygwin.com/cgi-bin2/jobs.cgi?id=8210

cygport attached and at:

https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a

log at:

https://github.com/cygwin/scallywag/actions/runs/9293093201

The package installs and runs using PoC attached in spdx-license-expression.py 
script hooked into /usr/share/cygport/lib/pkg_pkg.cygpart license hint addition 
patch attached.


I also ran a test of the Python script and module against all package source 
cygport files declaring licences which I maintain or ever looked at, including a 
git/cygwin-packages/*.cygport download from 2023-02, showing the results in the 
attached log.
I also attempted to trap the exceptions in the script, but that does not seem to 
work in any documented obvious manner, but I do not know enough Python to 
address this.


If someone else who knows python cared to adopt and improve this in a more 
normal manner, and incorporate this more smoothly into cygport, we could all 
appreciate that.

Alternatively, some candid comments and frank feedback might allow me to do so! 
;^>

The approach may also be adaptable to calm if you can get 
python-license-expression 30.3.0 installed on the server(s), and kept updated:


https://repology.org/project/python:license-expression/versions

and Cygwin should soon be added there hopefully! ;^>

--
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#|/usr/bin/cygport
# python-license-expression.cygport - Python license-expression Cygwin package 
build control script definitions

inherit python-wheel

NAME=python-license-expression
VERSION=30.3.0
RELEASE=1

BASE=${NAME#python-}

CATEGORY=Python

Updated: w32api-{headers,runtime} mingw64-{headers,runtime,winpthreads} 12.0.0-1

[Jonathan Yong via Cygwin-announce]

Important Notice:
Upstream mingw-w64 12.0.0 is now using UCRT as the default C Runtime for 
better C99 printf and math.h floating point performance, but it can 
still be configured to continue using MSVCRT.


Switching C Runtimes requires all binaries to be rebuilt from source, 
including all compiler support libraries.


Packages for Cygwin (mingw64-{headers,runtime,winpthreads} packages) are 
built with MSVCRT as the C Runtime provider for compatibility with 
existing Cygwin provided mingw-w64 cross compiled binaries and libraries.


This means it is still safe to use existing Cygwin mingw64-* packages 
with the latest Cygwin mingw-w64 cross compiler, since this new release 
continues to use MSVCRT, similar to the previous releases.


C libraries and binaries built by mingw-w64 toolchains that target UCRT 
may not be compatible if C standard library API handles such as handles 
from open(), fopen(), free() and etc, are passed through the library 
boundaries.


C++ libraries built by mingw-w64 toolchains that target UCRT are 
unlikely to be compatible if C++ standard library APIs are utilized 
across library boundaries.


Win32 API handles such as those used by CreateFileW() or 
WaitForSingleObject() are unaffected.


Purely Cygwin applications using POSIX/UNIX APIs are unaffected by the 
change.


Notable changes:
* C++ overloads for _strdate_s and _strtime_s, _makepath_s, wcsncat_s.
* gdtoa updated against netlib.org, up to January 2023.
* genlib tool removed in favor of llvm-dlltool, created by the same author.
* Make it possible to use winpthreads with MSVC.
* Updated wine header imports.
* Many other new win32 APIs.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the
format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.

--
 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: Run explorer.exe with Cygwin newgrp(1) - same user but different primary group

[Bill Stewart via Cygwin]

On Tue, May 28, 2024 at 9:36 PM Dan Shelton wrote:


> Does anyone know how to run Windows explorer.exe with Cygwin
> /bin/newgrp, so all new files created by explorer.exe use that new
> primary group, and all programs launched by explorer.exe use that same
> primary group?
>

As I understand it, Explorer always starts unelevated as the current user.
This is by design for security reasons.

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: WinSG Re: [Ms-nfs41-client-devel] ANN: NFSv4.1 filesystem client Windows driver binaries for Windows 10/11 for testing, 2024-05-28 ...

[Bill Stewart via Cygwin]

On Tue, May 28, 2024 at 8:29 PM Dan Shelton wrote:

Just a couple of ideas:
> - Native Windows doesn't have an easy way to list group memberships
> for the current user, so a WinSG -l to list available groups would be
> good
>

Maybe you weren't aware of it - 'whoami /groups'


> - WinSG should be installed in C:\Windows\system32\ alongside cmd.exe
>

Not IMHO.


> - Native Windows utilities use /? for help, not --help
>

This is really only a loosely followed convention and not all Windows tools
follow it. (Example: Windows PowerShell cmdlet parameters use "-", not "/".)

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