Re: Deadlock of the process tree when running make

[Jeremy Drake via Cygwin]

On Sat, 9 Apr 2022, Alexey Izbyshev wrote:

> I don't have mintty because "make" is run via an SSH session. I suppose
> I should look into sshd in this case?

Sshd wouldn't happen to be running as a service, would it?

https://cygwin.com/pipermail/cygwin-patches/2022q2/011867.html


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

License for clang patch "7.0.1-cygwin-driver.patch"

[Samuel Bronson]

The following message is a courtesy copy of an article
that has been posted to gmane.os.cygwin as well.

I was thinking of trying to upstream the patch at:
--text follows this line--
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/clang.git;a=blob;f=7.0.1-cygwin-driver.patch;h=8f2419846f3d649b81282868d8cd94de574a50f8;hb=e1fccf772aa5add40bba9050abeea188c62acbdd

But I expect the LLVM people would want to make sure that the changes
are licensed appropriately.

Unfortunately, I couldn't find anything about the licensing of the
packaging files in that packaging repository, nor do I see anything
about a licensing policy for packaging files on the page
.

It doesn't exactly help that the LLVM project are in the midst of
relicensing their code, and the new policy only landed after the 8.x
branch, so even a "same as upstream code unless otherwise specified"
policy would only really help W.R.T. Achim Gratz's update of the patch
from clang 8.x to clang 9.x.

The current licensing policy for LLVM is described at:


Any ideas about this?

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

[ANNOUNCEMENT] biber 2.17-1

[Ken Brown via Cygwin-announce]

The following package has been uploaded to the Cygwin distribution:

* biber-2.17-1

Biber is a BibTeX replacement for users of BibLaTeX.  Biber supports full UTF-8, 
can (re-)encode input and output, supports highly configurable sorting, dynamic 
bibliography sets, and many other features.


This is an update to the latest upstream release.  It is designed to work with 
biblatex-3.17.  The latter is contained in texlive-collection-bibtexextra, which 
has just been updated as part of TeX Live 2022.


Ken Brown
Cygwin's Biber maintainer

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

[ANNOUNCEMENT] TeX Live 2022

[Ken Brown via Cygwin-announce]

Cygwin's TeX Live packages have been updated to the latest upstream release, TeX 
Live 2022.


TeX Live provides a comprehensive, cross-platform TeX system.  It includes all 
the major TeX-related programs, macro packages, and fonts that are free 
software, including support for many languages around the world.  For more 
information, see


  http://www.tug.org/texlive/

And see

  http://www.tug.org/texlive/doc/texlive-en/texlive-en.html#news

for a list of changes since TeX Live 2021.

The TeX Live executables and supporting libraries are contained in the following 
Cygwin packages:


* texlive-20220321-1

* libkpathsea6-20220321-1
* libkpathsea-devel-20220321-1

libkpathsea is a TeX file and path search library.

* libptexenc1-20220321-1
* libptexenc-devel-20220321-1

libptexenc is a TeX Unicode encoding library.

* libsync2-20220321-1
* libsync-devel-20220321-1

libsync is a TeX source/output synchronization library.

* libtexlua53_5-20220321-1
* libtexlua53-devel-20220321-1

libtexlua53 is a TeX lua scripting library.

* libtexluajit2-20220321-1
* libtexluajit-devel-20220321-1

libtexluajit is a TeX Just-In-Time lua compiler library.

* asymptote-2.79-1

Asymptote is a powerful descriptive vector graphics language for technical 
drawing, inspired by MetaPost but with an improved C++-like syntax.  Asymptote 
provides for figures the same high-quality typesetting that LaTeX does for 
scientific text.


In addition, upstream TeX Live provides thousands of "packages", grouped into 
"collections".  There is a Cygwin package for each upstream collection; there 
are also Cygwin packages containing documentation for some of the collections.


* texlive-collection-basic-20220321-1
* texlive-collection-basic-doc-20220321-1
* texlive-collection-bibtexextra-20220321-1
* texlive-collection-bibtexextra-doc-20220321-1
* texlive-collection-binextra-20220321-1
* texlive-collection-binextra-doc-20220321-1
* texlive-collection-context-20220321-1
* texlive-collection-context-doc-20220321-1
* texlive-collection-fontsextra-20220321-1
* texlive-collection-fontsextra-doc-20220321-1
* texlive-collection-fontsrecommended-20220321-1
* texlive-collection-fontsrecommended-doc-20220321-1
* texlive-collection-fontutils-20220321-1
* texlive-collection-fontutils-doc-20220321-1
* texlive-collection-formatsextra-20220321-1
* texlive-collection-games-20220321-1
* texlive-collection-humanities-20220321-1
* texlive-collection-humanities-doc-20220321-1
* texlive-collection-langarabic-20220321-1
* texlive-collection-langchinese-20220321-1
* texlive-collection-langcjk-20220321-1
* texlive-collection-langcyrillic-20220321-1
* texlive-collection-langczechslovak-20220321-1
* texlive-collection-langenglish-20220321-1
* texlive-collection-langeuropean-20220321-1
* texlive-collection-langfrench-20220321-1
* texlive-collection-langgerman-20220321-1
* texlive-collection-langgreek-20220321-1
* texlive-collection-langitalian-20220321-1
* texlive-collection-langjapanese-20220321-1
* texlive-collection-langkorean-20220321-1
* texlive-collection-langother-20220321-1
* texlive-collection-langpolish-20220321-1
* texlive-collection-langportuguese-20220321-1
* texlive-collection-langspanish-20220321-1
* texlive-collection-latex-20220321-1
* texlive-collection-latex-doc-20220321-1
* texlive-collection-latexextra-20220321-1
* texlive-collection-latexextra-doc-20220321-1
* texlive-collection-latexrecommended-20220321-1
* texlive-collection-latexrecommended-doc-20220321-1
* texlive-collection-luatex-20220321-1
* texlive-collection-luatex-doc-20220321-1
* texlive-collection-mathscience-20220321-1
* texlive-collection-mathscience-doc-20220321-1
* texlive-collection-metapost-20220321-1
* texlive-collection-metapost-doc-20220321-1
* texlive-collection-music-20220321-1
* texlive-collection-music-doc-20220321-1
* texlive-collection-pictures-20220321-1
* texlive-collection-pictures-doc-20220321-1
* texlive-collection-plaingeneric-20220321-1
* texlive-collection-plaingeneric-doc-20220321-1
* texlive-collection-pstricks-20220321-1
* texlive-collection-pstricks-doc-20220321-1
* texlive-collection-publishers-20220321-1
* texlive-collection-publishers-doc-20220321-1
* texlive-collection-xetex-20220321-1
* texlive-collection-xetex-doc-20220321-1

Recommendations
===
Most people do not need the full TeX Live installation, which is huge and can 
take a long time to install.  If you're not sure what you need, here are some 
possible ways to start:


Minimal: Install texlive and its dependencies.  This provides plain TeX but not 
LaTeX.


Basic: Install texlive-collection-latex and its dependencies.  This is a minimal 
installation with LaTeX.


Small: Install texlive-collection-latexrecommended and its dependencies.  This 
provides the most commonly used non-graphics LaTeX packages.  Install 
texlive-collection-pictures if you want the standard graphics packages too.


Medium: Install texlive-collection-binextra, texlive-collection-context, 

biber 2.17-1

[Ken Brown via Cygwin-announce]

The following package has been uploaded to the Cygwin distribution:

* biber-2.17-1

Biber is a BibTeX replacement for users of BibLaTeX.  Biber supports full UTF-8, 
can (re-)encode input and output, supports highly configurable sorting, dynamic 
bibliography sets, and many other features.


This is an update to the latest upstream release.  It is designed to work with 
biblatex-3.17.  The latter is contained in texlive-collection-bibtexextra, which 
has just been updated as part of TeX Live 2022.


Ken Brown
Cygwin's Biber maintainer

TeX Live 2022

[Ken Brown via Cygwin-announce]

Cygwin's TeX Live packages have been updated to the latest upstream release, TeX 
Live 2022.


TeX Live provides a comprehensive, cross-platform TeX system.  It includes all 
the major TeX-related programs, macro packages, and fonts that are free 
software, including support for many languages around the world.  For more 
information, see


  http://www.tug.org/texlive/

And see

  http://www.tug.org/texlive/doc/texlive-en/texlive-en.html#news

for a list of changes since TeX Live 2021.

The TeX Live executables and supporting libraries are contained in the following 
Cygwin packages:


* texlive-20220321-1

* libkpathsea6-20220321-1
* libkpathsea-devel-20220321-1

libkpathsea is a TeX file and path search library.

* libptexenc1-20220321-1
* libptexenc-devel-20220321-1

libptexenc is a TeX Unicode encoding library.

* libsync2-20220321-1
* libsync-devel-20220321-1

libsync is a TeX source/output synchronization library.

* libtexlua53_5-20220321-1
* libtexlua53-devel-20220321-1

libtexlua53 is a TeX lua scripting library.

* libtexluajit2-20220321-1
* libtexluajit-devel-20220321-1

libtexluajit is a TeX Just-In-Time lua compiler library.

* asymptote-2.79-1

Asymptote is a powerful descriptive vector graphics language for technical 
drawing, inspired by MetaPost but with an improved C++-like syntax.  Asymptote 
provides for figures the same high-quality typesetting that LaTeX does for 
scientific text.


In addition, upstream TeX Live provides thousands of "packages", grouped into 
"collections".  There is a Cygwin package for each upstream collection; there 
are also Cygwin packages containing documentation for some of the collections.


* texlive-collection-basic-20220321-1
* texlive-collection-basic-doc-20220321-1
* texlive-collection-bibtexextra-20220321-1
* texlive-collection-bibtexextra-doc-20220321-1
* texlive-collection-binextra-20220321-1
* texlive-collection-binextra-doc-20220321-1
* texlive-collection-context-20220321-1
* texlive-collection-context-doc-20220321-1
* texlive-collection-fontsextra-20220321-1
* texlive-collection-fontsextra-doc-20220321-1
* texlive-collection-fontsrecommended-20220321-1
* texlive-collection-fontsrecommended-doc-20220321-1
* texlive-collection-fontutils-20220321-1
* texlive-collection-fontutils-doc-20220321-1
* texlive-collection-formatsextra-20220321-1
* texlive-collection-games-20220321-1
* texlive-collection-humanities-20220321-1
* texlive-collection-humanities-doc-20220321-1
* texlive-collection-langarabic-20220321-1
* texlive-collection-langchinese-20220321-1
* texlive-collection-langcjk-20220321-1
* texlive-collection-langcyrillic-20220321-1
* texlive-collection-langczechslovak-20220321-1
* texlive-collection-langenglish-20220321-1
* texlive-collection-langeuropean-20220321-1
* texlive-collection-langfrench-20220321-1
* texlive-collection-langgerman-20220321-1
* texlive-collection-langgreek-20220321-1
* texlive-collection-langitalian-20220321-1
* texlive-collection-langjapanese-20220321-1
* texlive-collection-langkorean-20220321-1
* texlive-collection-langother-20220321-1
* texlive-collection-langpolish-20220321-1
* texlive-collection-langportuguese-20220321-1
* texlive-collection-langspanish-20220321-1
* texlive-collection-latex-20220321-1
* texlive-collection-latex-doc-20220321-1
* texlive-collection-latexextra-20220321-1
* texlive-collection-latexextra-doc-20220321-1
* texlive-collection-latexrecommended-20220321-1
* texlive-collection-latexrecommended-doc-20220321-1
* texlive-collection-luatex-20220321-1
* texlive-collection-luatex-doc-20220321-1
* texlive-collection-mathscience-20220321-1
* texlive-collection-mathscience-doc-20220321-1
* texlive-collection-metapost-20220321-1
* texlive-collection-metapost-doc-20220321-1
* texlive-collection-music-20220321-1
* texlive-collection-music-doc-20220321-1
* texlive-collection-pictures-20220321-1
* texlive-collection-pictures-doc-20220321-1
* texlive-collection-plaingeneric-20220321-1
* texlive-collection-plaingeneric-doc-20220321-1
* texlive-collection-pstricks-20220321-1
* texlive-collection-pstricks-doc-20220321-1
* texlive-collection-publishers-20220321-1
* texlive-collection-publishers-doc-20220321-1
* texlive-collection-xetex-20220321-1
* texlive-collection-xetex-doc-20220321-1

Recommendations
===
Most people do not need the full TeX Live installation, which is huge and can 
take a long time to install.  If you're not sure what you need, here are some 
possible ways to start:


Minimal: Install texlive and its dependencies.  This provides plain TeX but not 
LaTeX.


Basic: Install texlive-collection-latex and its dependencies.  This is a minimal 
installation with LaTeX.


Small: Install texlive-collection-latexrecommended and its dependencies.  This 
provides the most commonly used non-graphics LaTeX packages.  Install 
texlive-collection-pictures if you want the standard graphics packages too.


Medium: Install texlive-collection-binextra, texlive-collection-context, 

Re: Deadlock of the process tree when running make

[Alexey Izbyshev]

On 2022-04-10 15:13, Alexey Izbyshev wrote:

On 2022-04-10 10:34, Takashi Yano wrote:

On Sat, 09 Apr 2022 23:26:51 +0300
Thanks for investigating. In the normal case, conhost.exe is 
terminated

when hWritePipe is closed.


Thanks for confirming.



Possibly, the hWritePipe has incorrect handle value.


I've verified that the handle was correct by attaching via gdb to the
hanging bash and checking that hWritePipe field is now zeroed (which
happens only in the branch where _HandleIsValid returns true and
hWritePipe is closed).

I've found something interesting though. I've modeled a similar
situation on another machine:

1. I've run a native process via bash.
2. I've attached to bash via gdb and set a breakpoint on 
ClosePseudoConsole().

3. I've killed the native process.
4. The breakpoint was hit, and I looked at hWritePipe value.

ProcessHacker shows it as "Unnamed file: \FileSystem\Npfs". Both bash
and conhost had a single handle with such name, and after I've
forcibly closed it in the bash process (while it was still suspended
by gdb), conhost.exe indeed died.

Then I looked at the original hanging tree and found that the hanging
bash.exe still has a single handle displayed as "Unnamed file:
\FileSystem\Npfs". I don't know how to check what kernel object it
refers to, but at least its access rights are the same as for
hWritePipe that I've seen on another machine, and its handle count is
1. So could it be another copy of hWritePipe, e.g. due to some handle
leak?

I don't know how to verify whether this suspicious handle in bash.exe
is paired with "Unnamed file: \FileSystem\Npfs" in conhost.exe, other
than by forcibly closing it. If I close it and conhost.exe dies, it
will confirm "the extra handle" theory, but will also prevent further
investigation with the hanging tree. Do you have any advice?

I've found something that looked strange to me by checking handles in 
the hanging process tree: the hanging conhost.exe and the hanging 
bash.exe belong to different tests. Each test is a separate shell script 
in a separate make recipe, so it looks like conhost.exe was created by 
one test (which is still hanging at a later point in its script, trying 
to run grep), but then bash.exe belonging to another test somehow got a 
pseudoconsole referring to this conhost.exe and now hangs trying to 
close it. So it looks that Cygwin migrated the pseudoconsole between 
processes, and indeed fhandler_pty_slave::close_pseudoconsole() contains 
something looking like migration logic. And this logic contains the 
following call:


DuplicateHandle (GetCurrentProcess (),
 ttyp->h_pcon_write_pipe,
 new_owner, _write_pipe,
 0, TRUE, DUPLICATE_SAME_ACCESS);

Is it safe to create an *inheritable* handle in another process here? 
Could it be that the target process spawns a child at the wrong moment 
(e.g. before it even knows about the newly created handle), and that 
handle unintentionally leaks into the child, triggering the hang 
afterwards?


A similarly suspicious code is also in 
fhandler_pty_common::resize_pseudo_console():


  DuplicateHandle (pcon_owner, get_ttyp ()->h_pcon_write_pipe,
   GetCurrentProcess (), _local.hWritePipe,
   0, TRUE, DUPLICATE_SAME_ACCESS);
  ResizePseudoConsole ((HPCON) _local, size);
  CloseHandle (pcon_owner);
  CloseHandle (hpcon_local.hWritePipe);

If another thread spawns a child using 
CreateProcess(bInheritHandles=TRUE) between DuplicateHandle() and 
CloseHandle(hpcon_local.hWritePipe), the handle will leak into the 
child.


Sorry if this is a false lead, I haven't tried to really understand the 
pseudoconsole-related code yet.


Thanks,
Alexey

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

[ANNOUNCEMENT] Updated: {mingw64-{i686, x86_64}-, }zlib-1.2.12-1 (security)

[Achim Gratz]

The following packages have been uploaded to the Cygwin distribution:

* zlib0-1.2.12-1
* zlib-devel-1.2.12-1
* mingw64-i686-zlib-1.2.12-1
* mingw64-x86_64-zlib-1.2.12-1

zlib is designed to be a free, general-purpose, lossless
data-compression library for use on virtually any computer hardware and
operating system.  The zlib data format is itself portable across
platforms.

This is an update to the latest upstream release.

Note


The sub-packages for the bundled minizip (that were unused) have been
removed from the distribution.


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

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

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

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

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

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

-- 
Problem reports:  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: {mingw64-{i686,x86_64}-,}zlib-1.2.12-1 (security)

[Achim Gratz]

The following packages have been uploaded to the Cygwin distribution:

* zlib0-1.2.12-1
* zlib-devel-1.2.12-1
* mingw64-i686-zlib-1.2.12-1
* mingw64-x86_64-zlib-1.2.12-1

zlib is designed to be a free, general-purpose, lossless
data-compression library for use on virtually any computer hardware and
operating system.  The zlib data format is itself portable across
platforms.

This is an update to the latest upstream release.

Note


The sub-packages for the bundled minizip (that were unused) have been
removed from the distribution.


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

Re: cygport

[Achim Gratz]

Jon Turney writes:
>> @@ -412,6 +413,7 @@ __list_deps() {
>> do
>> if [ -f ${d}/${pldep//:://}.pm ]
>> then
>> +   case "${d##*/}" in 5.[0-9][0-9]) 
>> plver+="$pldep " ;; esac
>
> Is the mistake thinking pldep here is a pathname, not a module name?

Most likely yes, although I'd have to see what kind of data triggers
this clause.


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

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

Re: [ITA] {mingw64-{i686,x86_64}-,}zlib

[Ken Brown]

On 4/10/2022 12:55 PM, Achim Gratz wrote:


MinGW64 packages currently orphaned by Yaakov, Cygwin package currently
maintained by Ken (OK to take over given via IRC).

Update to 1.2.12 (security) and removal of minizip (not used on Cygwin
and minizip fork is packaged separately already).


Done.

Thanks for taking over.

Ken

Re: cygport

[Jon Turney]

On 27/03/2022 14:22, Achim Gratz wrote:

Jon Turney writes:

A few comments after looking at:

lib/pkg_info.cygport: implement automatic determination of the
appropriate perl5_0xy requirement
1. In __list_deps(), this should look at the files list in $@, not at
files in $D, as that causes it to identify a perl5_0xy dependency for
all subpackages, irrespective of which package (if any) contains the
files in the vendor_perl directory.

2. This only identifies the perl5_0xy requirement for packages which
own files in the vendor_perl directory, not for packages which contain
executables or shared libraries dynamically linked with
cygperl5_xy.dll.   That should at least be mentioned in the patch
commentary.


I've fixed both of these on the to-upstream branch I think.


Thanks.

I tried testing this on rxvt-unicode.  It correctly adds the perl5_032 
dependency due to linkage


But it also emits a bogus dependency on 'Carp'.


@@ -412,6 +413,7 @@ __list_deps() {
do
if [ -f ${d}/${pldep//:://}.pm ]
then
+   case "${d##*/}" in 5.[0-9][0-9]) 
plver+="$pldep " ;; esac


Is the mistake thinking pldep here is a pathname, not a module name?


alldeps+=" "${d}/${pldep//:://}.pm;
break;
fi
@@ -419,6 +421,17 @@ __list_deps() {
done
fi

+   plver=( $( echo "${plver}" | tr ' ' '\n' | sed -e 
's/.*\///;s/5/perl5/;s/\./_0/' | sort -ru ) )
+   if [ "${#plver[@]}" -gt 1 ]
+   then
+   warning "More than one targeted Perl version: ${plver[*]},"
+   warning "using only the latest as dependency: ${plver[0]}."
+   fi
+   if [ "${#plver[@]}" -gt 0 ] && [ "${PN}" != "perl_base" ]
+   then
+   echo "${plver[0]}"
+   fi
+
if check_prog php-config
then
phpmoddir=$(php-config  --extension-dir)

Re: [ITA] duplicity

[Libor Ukropec]

Hi Brian,

1. regarding python-fasteners:

Dne 08.04.2022 v 1:44 Brian Inglis napsal(a):
> Run cygport ... all with --debug flag which enables shell tracing
> throughout and redirect all output &> debug.log for review.

Output for command `cygport --debug python-fasteners download all check 
&> debug.log`


is here, if you can deduct from it something useful:

https://gist.github.com/cz6ace/929812203a42bd2d69506cad19385eed#file-debug-log

(it is quite long, I do not want to paste it directly into the email)

Also it is unknown to me, how the new repository can be added into the 
https://cygwin.com/git/?a=project_list;pf=git/cygwin-packages so I can 
execute the tests in the playground too.



2. regarding duplicity itself. My first successful build: 
https://github.com/cygwin/scallywag/actions/runs/2144688591


Regards,
Libor

Dne 08.04.2022 v 1:44 Brian Inglis napsal(a):
Run cygport ... all with --debug flag which enables shell tracing 
throughout and redirect all output &> debug.log for review.


On 2022-04-07 16:26, Libor Ukropec wrote:

Hi Brian,

I solved the issue with Python 2.7 by adding PKG_NAMES and *_CONTENTS:

inherit python-wheel

PYTHON_WHEEL_VERSIONS="2.7:3.8:3.9"
NAME="python-fasteners"
VERSION=0.16.3
RELEASE=1
CATEGORY="Python"
SUMMARY="Cross platform locks for threads and processes."
DESCRIPTION="Python standard library provides a lock for threads (both 
a reentrant one, and a non-reentrant one, see below). Fasteners 
extends this, and provides a lock for processes, as well as Reader 
Writer locks for both threads and processes."
SRC_URI="https://github.com/harlowja/fasteners/archive/refs/tags/${VERSION}.tar.gz; 


SRC_DIR="fasteners-${VERSION}"
ARCH=noarch
PKG_NAMES+=" python27-fasteners"
python27_fasteners_CONTENTS="usr/lib/python2.7/site-packages/ 
usr/share/doc/python27-fasteners/"



still I'm concerned about the generated requirements, where the 
package itself is referring to itself with very long name. Is that 
normal?


 >>> python38-fasteners requires: python38 
python38-fasteners-python-fasteners-fasteners python38-six
 >>> python39-fasteners requires: python39 
python39-fasteners-python-fasteners-fasteners python39-six
 >>> python27-fasteners requires: python27 
python27-fasteners-python-fasteners-fasteners python27-six



Libor

Dne 07.04.2022 v 21:39 Libor Ukropec napsal(a):

Hi Brian,
Dne 07.04.2022 v 1:40 Brian Inglis napsal(a):

On 2022-04-06 16:10, Libor Ukropec wrote:
I'd like to offer to adopt maintenance of duplicity (Encrypted 
bandwidth-efficient backup system)
Information from https://duplicity.gitlab.io/ - """The last stable 
0.7 release is *0.7.19*, released Apr 19, 2019""", while cygwin 
contains 0.7.11 from 2017

Updated cygport:
https://github.com/cz6ace/cygwin-duplicity


You need to define BUILD_REQUIRES and list all Cygwin packages 
needed to build this package:


https://cygwin.github.io/cygport/check_funcs_cygpart.html#robo791

Use BUILD_REQUIRES+=" ..." for additional lines of packages.


Updated build:
https://github.com/cz6ace/cygwin-duplicity/releases


See:

 https://cygwin.com/git/cygwin-packages/duplicity.git


This repository was my starting point, I just increased the version 
and prepared the package (below) for the new python dependency 
(fasterners). I did not see on the contribution page any mention to 
the `playground` thing and an automation - will try that, once my SSH 
key is added.


As my first contribution to cygwin I wanted to start with small steps 
and stay with 0.7 duplicity, which still depends on the Python 2.7




You can clone the repo for the original files, checkout a playground 
branch, commit your changes and patches (and any extra source 
files), define the upstream playground branch, and push your changes 
there, which will run Scallywag CI under Github Actions (or Appveyor 
if you configure that cygport option).


Please note for successful installation the python 2.7 fasteners 
package is required, not yet in cygwin, I plan to offer [ITP] for it:

cygport:
https://github.com/cz6ace/cygwin-python-fasteners
build:
https://github.com/cz6ace/cygwin-python-fasteners/releases


Need to support python3/39 now: see python package cygports in 
cygwin-packages repos as above!


Is it a must at this moment? As I stated above, duplicity 0.7.x 
requires Python 2.7


I changed the `inherit` to python-wheel, which should support 
2.7,3.8, 3.9:


inherit python-wheel

PYTHON_WHEEL_VERSIONS="2.7:3.8:3.9"

But the cygport does not create the tar.cz archive for 2.7 and fails 
with


... 
-usr/lib/python2.7/site-packages/fasteners/version.py
...
*** ERROR: Packages are missing files:


I tried previous cygport version, but it fails creating python 3.7 
package.


I'll try to look to cygport sources if I am able to see something, 
which I doubt.




Python standard library provides a lock for threads (both a 
reentrant one, and a non-reentrant one, see below). Fasteners 
extends this, and provides a lock for processes, as well as 

[ITA] {mingw64-{i686,x86_64}-,}zlib

[Achim Gratz]

MinGW64 packages currently orphaned by Yaakov, Cygwin package currently
maintained by Ken (OK to take over given via IRC).

Update to 1.2.12 (security) and removal of minizip (not used on Cygwin
and minizip fork is packaged separately already).


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

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

[ANNOUNCEMENT] Updated: libcerf-2.1-1

[Achim Gratz]

This is an update to the latest upstream version.

Libcerf is a self-contained numeric library that provides an
efficient and accurate implementation of complex error functions,
along with Dawson, Faddeeva, and Voigt functions.

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

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

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

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

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

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

-- 
Problem reports:  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: libcerf-2.1-1

[Achim Gratz]

This is an update to the latest upstream version.

Libcerf is a self-contained numeric library that provides an
efficient and accurate implementation of complex error functions,
along with Dawson, Faddeeva, and Voigt functions.

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

[ANNOUNCEMENT] Updated: {, mingw64-{x86_64, i686}-}libarchive-3.6.1-1 (security)

[Achim Gratz]

Libarchive has been updated to version 3.6.1-1, the following
(sub-)packages:

libarchive (source)
libarchive-devel
libarchive13
bsdcat
bsdcpio
bsdtar

are available in the Cygwin distribution.  The MinGW64 packages for
the cross-compilation toolchains have been updated as well:

mingw64-i686-libarchive
mingw64-x86_64-libarchive

This is a minor upstream bugfix release including security fixes.

DESCRIPTION
Multi-format archive and compression library
It is a portable, efficient C library that can read and write streaming
archives in a variety of formats. It also includes implementations
of the common tar, cpio, and zcat command-line tools that use the
libarchive library.

HOMEPAGE
https://www.libarchive.org/

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

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

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

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

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

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

-- 
Problem reports:  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: {,mingw64-{x86_64,i686}-}libarchive-3.6.1-1 (security)

[Achim Gratz]

Libarchive has been updated to version 3.6.1-1, the following
(sub-)packages:

libarchive (source)
libarchive-devel
libarchive13
bsdcat
bsdcpio
bsdtar

are available in the Cygwin distribution.  The MinGW64 packages for
the cross-compilation toolchains have been updated as well:

mingw64-i686-libarchive
mingw64-x86_64-libarchive

This is a minor upstream bugfix release including security fixes.

DESCRIPTION
Multi-format archive and compression library
It is a portable, efficient C library that can read and write streaming
archives in a variety of formats. It also includes implementations
of the common tar, cpio, and zcat command-line tools that use the
libarchive library.

HOMEPAGE
https://www.libarchive.org/

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

Re: Deadlock of the process tree when running make

[Alexey Izbyshev]

On 2022-04-10 10:34, Takashi Yano wrote:

On Sat, 09 Apr 2022 23:26:51 +0300
Thanks for investigating. In the normal case, conhost.exe is terminated
when hWritePipe is closed.


Thanks for confirming.



Possibly, the hWritePipe has incorrect handle value.


I've verified that the handle was correct by attaching via gdb to the 
hanging bash and checking that hWritePipe field is now zeroed (which 
happens only in the branch where _HandleIsValid returns true and 
hWritePipe is closed).


I've found something interesting though. I've modeled a similar 
situation on another machine:


1. I've run a native process via bash.
2. I've attached to bash via gdb and set a breakpoint on 
ClosePseudoConsole().

3. I've killed the native process.
4. The breakpoint was hit, and I looked at hWritePipe value.

ProcessHacker shows it as "Unnamed file: \FileSystem\Npfs". Both bash 
and conhost had a single handle with such name, and after I've forcibly 
closed it in the bash process (while it was still suspended by gdb), 
conhost.exe indeed died.


Then I looked at the original hanging tree and found that the hanging 
bash.exe still has a single handle displayed as "Unnamed file: 
\FileSystem\Npfs". I don't know how to check what kernel object it 
refers to, but at least its access rights are the same as for hWritePipe 
that I've seen on another machine, and its handle count is 1. So could 
it be another copy of hWritePipe, e.g. due to some handle leak?


I don't know how to verify whether this suspicious handle in bash.exe is 
paired with "Unnamed file: \FileSystem\Npfs" in conhost.exe, other than 
by forcibly closing it. If I close it and conhost.exe dies, it will 
confirm "the extra handle" theory, but will also prevent further 
investigation with the hanging tree. Do you have any advice?


Thanks,
Alexey

--
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: Deadlock of the process tree when running make

[Takashi Yano]

On Sat, 09 Apr 2022 23:26:51 +0300
Alexey Izbyshev wrote:
> On 2022-04-09 22:35, Alexey Izbyshev wrote:
> > On 2022-04-09 20:54, Takashi Yano wrote:
> >> Thanks for checking. This seems to be normal. Then, I cannot
> >> understand why the ClosePseudoConsole() call is blocked...
> >> 
> >> The document by Microsoft mentions the blocking conditions of
> >> ClosePseudoConsole():
> >> https://docs.microsoft.com/en-us/windows/console/closepseudoconsole
> >> however, the thread above is draining the channel.
> > 
> > I've decided to check what object ClosePseudoConsole() waits for. The
> > wait happens inside unexported KERNELBASE!_ClosePseudoConsoleMembers
> > function. Here is the relevant part:
> > 
> > 76589fb5 8b4e08  mov ecx,dword ptr [esi+8]
> > 76589fb8 e8c2fd  callKERNELBASE!_HandleIsValid (76589d7f)
> > 76589fbd 84c0testal,al
> > 76589fbf 7456je
> > KERNELBASE!_ClosePseudoConsoleMembers+0x89 (7658a017)
> > 76589fc1 8d45fc  lea eax,[ebp-4]
> > 76589fc4 895dfc  mov dword ptr [ebp-4],ebx
> > 76589fc7 50  pusheax
> > 76589fc8 51  pushecx
> > 76589fc9 e8c23ef5ff  callKERNELBASE!GetExitCodeProcess 
> > (764dde90)
> > 76589fce 85c0testeax,eax
> > 76589fd0 7414je
> > KERNELBASE!_ClosePseudoConsoleMembers+0x58 (76589fe6)
> > 76589fd2 817dfc0301  cmp dword ptr [ebp-4],103h
> > 76589fd9 750bjne
> > KERNELBASE!_ClosePseudoConsoleMembers+0x58 (76589fe6)
> > 76589fdb 53  pushebx
> > 76589fdc 6affpush0h
> > 76589fde ff7608  pushdword ptr [esi+8]
> > 76589fe1 e8ba74f6ff  callKERNELBASE!WaitForSingleObjectEx 
> > (764f14a0)
> > 
> > "esi" is the argument of ClosePseudoConsole(), so the first mov
> > dereferences it with an offset and loads a process handle. Then, if
> > this handle is valid, it calls GetExitCodeProcess(), and if it
> > succeeds and returns STILL_ACTIVE, it waits for that process.
> > 
> > I've checked that hanging bash process has only 3 process handles: for
> > itself, for dead javac, and for conhost.exe. So obviously it waits for
> > the latter to terminate. (After I did all this, I realized there was
> > much easier way to get this result via "Analyze wait chain" feature of
> > Task Manager).
> > 
> > Unfortunately, I don't know anything about Windows consoles, but just
> > in case I also checked what 5 threads of conhost.exe are waiting for:
> > 
> > 1. Tries to enter a critical section (Task Manager claims it waits for
> > thread 4, so probably the latter owns it).
> > 2. Waits on a handle for "pty1-from-master-nat" named pipe.
> > 3. Waits for an anonymous event.
> > 4. Waits on a handle for "\Device\ConDrv" (in DeviceIoControl()).
> > 5. Blocked in GetMessageW().
> > 
> > It's also worth of note that this conhost.exe seems to be the only one
> > related to the Cygwin process tree (as well as the only related
> > non-Cygwin process). All other conhost.exe processes were created
> > before I started my stress test.
> > 
> > My guess is that this conhost.exe was created for a native app started
> > from a Cygwin process. Could it be some race condition/bug that
> > prevented conhost.exe from terminating once the native process
> > (probably javac?) died?
> > 
> A few more things that might be important:
> 
> * Clarification: thread 2 of conhost.exe waits in KernelBase!ReadFile().
> 
> * In the assembly part I omitted, before waiting on the conhost process, 
> _ClosePseudoConsoleMembers() closes the handle obtained from "dword ptr 
> [esi]", i.e. "hWritePipe" member of HPCON_INTERNAL struct.

Thanks for investigating. In the normal case, conhost.exe is terminated
when hWritePipe is closed.

Possibly, the hWritePipe has incorrect handle value.

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