Re :Delivery/E-commerce App/web free demo
Good day. , Are you looking any kind of ready-made on-demand Web-Apps Solution like (B2B2C) Model, So don't wait for book free demo. Ready to go-live delivery Website-Mobile Apps Solution for Categories We Serve: Food, Pizza, Restaurant, Groceries, Courier, Flowers and Gifts, Laundry, Healthcare products, Home appliance services delivery, Lifestyle product delivery including Taxi/Cab booking. Transportation & logistics Dating Apps and many more... Let us know what readymade Web-Apps Solution, you're looking on and we'd be happy to set up a free demo consultative first meeting, with no pressure to sign. Thanks, -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: cmark-0.30.2-1
New version 0.30.2-1 of cmark cmark-devel libcmark0_30.2 (API bump) are available in the Cygwin distribution: CHANGES Update to latest upstream release. DESCRIPTION cmark is the C reference implementation of CommonMark, a rationalized version of Markdown syntax with a spec. It provides a shared library (libcmark) with functions for parsing CommonMark documents to an abstract syntax tree (AST), manipulating the AST, and rendering the document to HTML, groff man, LaTeX, CommonMark, or an XML representation of the AST. It also provides a command-line program (cmark) for parsing and rendering CommonMark documents. HOMEPAGE https://github.com/commonmark/cmark https://commonmark.org/ Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: cmark-0.30.2-1
New version 0.30.2-1 of cmark cmark-devel libcmark0_30.2 (API bump) are available in the Cygwin distribution: CHANGES Update to latest upstream release. DESCRIPTION cmark is the C reference implementation of CommonMark, a rationalized version of Markdown syntax with a spec. It provides a shared library (libcmark) with functions for parsing CommonMark documents to an abstract syntax tree (AST), manipulating the AST, and rendering the document to HTML, groff man, LaTeX, CommonMark, or an XML representation of the AST. It also provides a command-line program (cmark) for parsing and rendering CommonMark documents. HOMEPAGE https://github.com/commonmark/cmark https://commonmark.org/ Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com .
[ANNOUNCEMENT] Updated: dblatex-0.3.12-2
New version 0.3.12-2 of dblatex is available in the Cygwin distribution: CYGWIN CHANGES rebuilt with python 3.9 and added workaround for avoid break on future python upgrade CHANGES Updated to latest upstream release. DESCRIPTION DocBook to LaTeX Publishing transforms your SGML/XML DocBook documents to DVI, PostScript or PDF by translating them in pure LaTeX as a first process. MathML 2.0 markups are supported too. HOMEPAGE https://sourceforge.net/projects/dblatex/ Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: dblatex-0.3.12-2
New version 0.3.12-2 of dblatex is available in the Cygwin distribution: CYGWIN CHANGES rebuilt with python 3.9 and added workaround for avoid break on future python upgrade CHANGES Updated to latest upstream release. DESCRIPTION DocBook to LaTeX Publishing transforms your SGML/XML DocBook documents to DVI, PostScript or PDF by translating them in pure LaTeX as a first process. MathML 2.0 markups are supported too. HOMEPAGE https://sourceforge.net/projects/dblatex/ Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com .
Re: [ANNOUNCEMENT] Updated: python 3.9 packages
On 23.12.2021 21:34, Russell VT wrote: Thanks Marco! One small question/caveat, though, if I may? On Tue, Dec 21, 2021, 9:11 AM Marco Atzeri via Cygwin-announce < cygwin-annou...@cygwin.com> wrote: [...] https://www.python.org/dev/peps/pep-0394/ In other systems as Debian /usr/bin/python is discouraged. As on Cygwin we have still several third packages depending on python2, the usage of alternatives should allow to manage until all are updated to python3 Even being a Debian / Mint / Ubuntu fan, there's still an incredible of stuff that uses "/usr/bin/python," instead of something like "/usr/bin/env python." It seems "not unreasonable" to continue to support that link, just to allow people who use Cygwin for development, a little additional sanity for the time being? That said, people *should* be transitioning to other tools, such as pyenv or pipenv, to better manage their environments (or, in the case of later python 3 versions, the built-in venv mechanism) Regards Marco Atzeri Cheers! Russell VT Hi Russell, $ alternatives --display python python - status is auto. link currently points to /usr/bin/python3.9 /usr/bin/python2.7 - priority 27 /usr/bin/python3.6 - priority 36 /usr/bin/python3.7 - priority 37 /usr/bin/python3.8 - priority 38 /usr/bin/python3.9 - priority 39 Current `best' version is /usr/bin/python3.9. python and python3 are still provided. I am not planning to remove it. "until all are updated to python3" means that some packages are still build with python2 and need rebuild/update for python3 Regards -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On Thu, 23 Dec 2021, Ken Brown wrote: > > - for (ULONG j = 0; j < phi->NumberOfHandles; j++) > > + for (ULONG j = 0; j < min(phi->NumberOfHandles, n_handle); j++) > > Reading the preceding code, I don't see how n_handle could be less than > phi->NumberOfHandles. Can you explain? > Not really. I saw this stack trace: ... #3 0x000180062f13 in exception::handle (e=0x14cc4f0, frame=, in=, dispatch=) at /c/S/msys2-runtime/src/msys2-runtime/winsup/cygwin/exceptions.cc:835 #4 0x7ff8abd320cf in ntdll!.chkstk () from /c/Windows/SYSTEM32/ntdll.dll #5 0x7ff8abce1454 in ntdll!RtlRaiseException () from /c/Windows/SYSTEM32/ntdll.dll #6 0x7ff8abd30bfe in ntdll!KiUserExceptionDispatcher () from /c/Windows/SYSTEM32/ntdll.dll #7 0x000180092687 in fhandler_pipe::get_query_hdl_per_process (this=this@entry=0x1803700f8, name=name@entry=0x14cc820 L"\\Device\\NamedPipe\\dd50a72ab4668b33-10348-pipe-nt-0x6E6", ntfn=ntfn@entry=0x8000c2ce0) at /c/S/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler_pipe.cc:1281 #8 0x000180092bdb in fhandler_pipe::temporary_query_hdl (this=this@entry=0x1803700f8) at /c/S/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler_pipe.cc:1190 ... Line 1281 of fhandler_pipe.cc was if (phi->Handles[j].GrantedAccess != access) The only way I could see that causing an exception was if it was reading past the end of the allocated memory, if j was greater than (or equal to) n_handle. Unfortunately, I haven't been able to catch it in a debugger again, so I can't confirm this. I took a core with 'dumper' but gdb doesn't want to load it (it says Core file format not supported, maybe something with msys2's gdb?).
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On 12/23/2021 6:10 PM, Jeremy Drake via Cygwin-patches wrote:
diff --git a/winsup/cygwin/fhandler_pipe.cc
b/winsup/cygwin/fhandler_pipe.cc
index ba6b70f55..48713a38d 100644
--- a/winsup/cygwin/fhandler_pipe.cc
+++ b/winsup/cygwin/fhandler_pipe.cc
@@ -1239,7 +1239,7 @@ fhandler_pipe::get_query_hdl_per_process (WCHAR *name,
if (!NT_SUCCESS (status))
goto close_proc;
- for (ULONG j = 0; j < phi->NumberOfHandles; j++)
+ for (ULONG j = 0; j < min(phi->NumberOfHandles, n_handle); j++)
Reading the preceding code, I don't see how n_handle could be less than
phi->NumberOfHandles. Can you explain?
{
/* Check for the peculiarity of cygwin read pipe */
const ULONG access = FILE_READ_DATA | FILE_READ_EA
@@ -1309,7 +1309,7 @@ fhandler_pipe::get_query_hdl_per_system (WCHAR *name,
if (!NT_SUCCESS (status))
return NULL;
- for (LONG i = (LONG) shi->NumberOfHandles - 1; i >= 0; i--)
+ for (LONG i = (LONG) min(shi->NumberOfHandles, n_handle) - 1; i >= 0; i--)
Same comment.
Ken
Re: [ANNOUNCEMENT] Updated: python 3.9 packages
Thanks Marco! One small question/caveat, though, if I may? On Tue, Dec 21, 2021, 9:11 AM Marco Atzeri via Cygwin-announce < cygwin-annou...@cygwin.com> wrote: > [...] > > https://www.python.org/dev/peps/pep-0394/ > In other systems as Debian > /usr/bin/python is discouraged. > > As on Cygwin we have still several third packages depending on > python2, the usage of alternatives should allow to manage > until all are updated to python3 > Even being a Debian / Mint / Ubuntu fan, there's still an incredible of stuff that uses "/usr/bin/python," instead of something like "/usr/bin/env python." It seems "not unreasonable" to continue to support that link, just to allow people who use Cygwin for development, a little additional sanity for the time being? That said, people *should* be transitioning to other tools, such as pyenv or pipenv, to better manage their environments (or, in the case of later python 3 versions, the built-in venv mechanism) Regards > Marco Atzeri > Cheers! Russell VT -- 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: python3.9 failing?
Russell VT writes: > On Tue, Dec 21, 2021 at 6:34 AM Achim Gratz wrote: > >> Marco Atzeri writes: >> > Without Python 3.9 installed python3 should link by default to the >> > next in the line (likely 3.8) >> >> While python3 still defaults to python38 alternatives should probably >> prioritize 38 over 39? > > > That's how I "fixed" mercurial on my own installation, as it was > complaining about missing the "parsers" module, from inside the Python 3.9 > libraries, IIRC. I strongly suspect that although you've 'fixed' the problem, you haven't actually fixed its underlying cause, which is the same as mine, fixed per suggestion by as follows. This allows mercurial to work with python3.9, as it should. Marco Atzeri writes: > On 21.12.2021 14:12, Henry S. Thompson wrote: >> Sometime recently python3 stopped working, I suspect when it became >> patched through to python3.9. > please upgrade/reinstall cygwin 3.3.3 > with all Cygwin processes off You can check if you need this if you don't see the following: : cygcheck -c cygwin Cygwin Package Information Package VersionStatus cygwin 3.3.3-1OK ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: python 3.9 packages
On 22.12.2021 14:52, airplanemath via Cygwin wrote:
On Tue, Dec 21 2021, Marco Atzeri via Cygwin-announce wrote:
Several python packages have been added to the Cygwin distribution
and at the same time the updated packages for 3.6/3./3.8
have been uploaded.
python39-pillow 8.4.0-1
Is this replacing python3[6-9]-imaging{,-tk}? They look similar:
emh, no. They are the same thing, my fault.
I was fooled by an upstream dependency of another package.
It requires Pillow, but I missed to note, as I am not the maintainer,
that "imaging" is using the fork "Pillow"
https://cygwin.com/packages/x86_64/python-imaging-src/python-imaging-8.4.0-1-src
I will remove Pillow.
Thanks for noticing
Marco
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 32 doc build failure
On 23.12.2021 20:39, Ken Brown wrote: On 12/23/2021 12:35 PM, Brian Inglis wrote: Building cygwin 32 doc (with latest packages, git sources, after running winsup/autogen.sh) get the following doc build failure (not on cygwin 64 - all builds okay) - anyone seen this before and any clue where to look? It looks like dblatex needs python3.8. Does your 32-bit installation have python3 pointing to python3.8? $ /usr/sbin/alternatives.exe --display python3 python3 - status is auto. link currently points to /usr/bin/python3.8 /usr/bin/python3.8 - priority 38 Current `best' version is /usr/bin/python3.8. Ken side effect of adding python3.9 I will repack dblatex to remove this issue. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 32 doc build failure
On 12/23/2021 12:35 PM, Brian Inglis wrote: Building cygwin 32 doc (with latest packages, git sources, after running winsup/autogen.sh) get the following doc build failure (not on cygwin 64 - all builds okay) - anyone seen this before and any clue where to look? $ ../configure && make ... Making all in doc make[3]: Entering directory '$HOME/src/cygwin/newlib-cygwin/build32/i686-pc-cygwin/winsup/doc' xmlto --skip-validation --with-dblatex pdf -o cygwin-ug-net/ -m ../../../../winsup/doc/fo.xsl ../../../../winsup/doc/cygwin-ug-net.xml Traceback (most recent call last): File "/usr/bin/dblatex", line 3, in from dbtexmf.dblatex import dblatex ModuleNotFoundError: No module named 'dbtexmf' It looks like dblatex needs python3.8. Does your 32-bit installation have python3 pointing to python3.8? $ /usr/sbin/alternatives.exe --display python3 python3 - status is auto. link currently points to /usr/bin/python3.8 /usr/bin/python3.8 - priority 38 Current `best' version is /usr/bin/python3.8. 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: How to start KDE in Cygwin/X vs LXDE
After a bit of research, I discovered that "Plasma" is the "KDE Desktop" I was looking for, and there are these 16 choices. By running #16, "XWin Server" there is an additional X icon with a green interion in the "hidden icons" list, which has an extensive menu of X programs to run. 1 Fluxbox 2 FVWM 3 GNOME Flashback (Metacity) 4 GNOME-Openbox 5 KDE-Openbox 6 LXDE 7 LXQt Desktop 8 MATE 9 Openbox 10 Plasma 11 User script 12 WindowMaker 13 Xfce Session 14 XLaunch 15 XtoW 16 XWin Server Thanks to the Cygwin team for all of their hard work this past year on making Cygwin even better! Happy Holidays! -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Cygwin 32 doc build failure
Building cygwin 32 doc (with latest packages, git sources, after running winsup/autogen.sh) get the following doc build failure (not on cygwin 64 - all builds okay) - anyone seen this before and any clue where to look? $ ../configure && make ... Making all in doc make[3]: Entering directory '$HOME/src/cygwin/newlib-cygwin/build32/i686-pc-cygwin/winsup/doc' xmlto --skip-validation --with-dblatex pdf -o cygwin-ug-net/ -m ../../../../winsup/doc/fo.xsl ../../../../winsup/doc/cygwin-ug-net.xml Traceback (most recent call last): File "/usr/bin/dblatex", line 3, in from dbtexmf.dblatex import dblatex ModuleNotFoundError: No module named 'dbtexmf' make[3]: *** [Makefile:756: cygwin-ug-net/cygwin-ug-net.pdf] Error 1 make[3]: Leaving directory '$HOME/src/cygwin/newlib-cygwin/build32/i686-pc-cygwin/winsup/doc' ... $ cygcheck -c dblatex ImageMagick ghostscript libxslt python38 texlive texlive-collection-bibtexextra texlive-collection-binextra texlive-collection-latexextra texlive-collection-mathscience transfig xmlto docbook-xsl libxml2 libxslt util-linux w3m Cygwin Package Information PackageVersion Status dblatex0.3.12-1OK docbook-xsl1.77.1-1OK ghostscript9.54.0-1OK ImageMagick7.0.10.27-2 OK libxml22.9.10-2OK libxslt1.1.29-1OK python38 3.8.12-1OK texlive20210325-1 OK texlive-collection-bibtexextra 20210325-1 OK texlive-collection-binextra20210325-1 OK texlive-collection-latexextra 20210325-1 OK texlive-collection-mathscience 20210325-2 OK transfig 3.2.8b-1OK util-linux 2.33.1-2OK w3m0.5.3-3 OK xmlto 0.0.28-1OK -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Inquiry on Apache Log4j's Effect on Cygwin Software
On 2021-12-23 08:19, Iyana Garry wrote: Is there any confirmation that Cygwin software is not impacted by the Apache Log4J vulnerabilities (CVE-2021-44228, CVE-2021-45046 and CVE-2021-45105)? Cygwin neither supports nor packages Java or log4j (Log for Java). -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Inquiry on Apache Log4j's Effect on Cygwin Software
On 12/23/2021 10:43 AM, Bill Stewart wrote: On Thu, Dec 23, 2021 at 8:19 AM Iyana Garry wrote: Is there any confirmation that Cygwin software is not impacted by the Apache Log4J vulnerabilities (CVE-2021-44228, CVE-2021-45046 and CVE-2021-45105)? I'm not sure why there would need to be any such confirmation. Log4J is a Java application logging framework. To clarify further, Java on the Windows platform is Windows native. While it is possible to invoke Java from Cygwin bash, it is the native Java one would invoke. I am not aware of any Cygwin programs that require and invoke Java. Best wishes - Eliot Moss -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Inquiry on Apache Log4j's Effect on Cygwin Software
On Thu, Dec 23, 2021 at 8:19 AM Iyana Garry wrote: Is there any confirmation that Cygwin software is not impacted by the > Apache Log4J vulnerabilities (CVE-2021-44228, CVE-2021-45046 and > CVE-2021-45105)? > I'm not sure why there would need to be any such confirmation. Log4J is a Java application logging framework. 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
Inquiry on Apache Log4j's Effect on Cygwin Software
Is there any confirmation that Cygwin software is not impacted by the Apache Log4J vulnerabilities (CVE-2021-44228, CVE-2021-45046 and CVE-2021-45105)? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: python 3.9 packages
On Tue, Dec 21 2021, Marco Atzeri via Cygwin-announce wrote:
> Several python packages have been added to the Cygwin distribution
> and at the same time the updated packages for 3.6/3./3.8
> have been uploaded.
>
> python39-pillow 8.4.0-1
Is this replacing python3[6-9]-imaging{,-tk}? They look similar:
$ cygcheck -cd python39-imaging{,-tk} python39-pillow
Cygwin Package Information
Package Version
python39-imaging 8.4.0-1
python39-imaging-tk 8.4.0-1
python39-pillow 8.4.0-1
$ mkfifo pipe1 pipe2
$ cygcheck -l python39-imaging{,-tk} | sort >pipe1 &
[1] 869
$ cygcheck -l python39-pillow | sort >pipe2 &
[2] 872
$ diff -u pipe1 pipe2
--- pipe1 2021-12-22 08:39:44.449869300 -0500
+++ pipe2 2021-12-22 08:39:44.449869300 -0500
@@ -382,6 +382,6 @@
/usr/lib/python3.9/site-packages/Pillow-8.4.0.dist-info/top_level.txt
/usr/lib/python3.9/site-packages/Pillow-8.4.0.dist-info/WHEEL
/usr/lib/python3.9/site-packages/Pillow-8.4.0.dist-info/zip-safe
-/usr/share/doc/python39-imaging/CHANGES.rst
-/usr/share/doc/python39-imaging/LICENSE
-/usr/share/doc/python39-imaging/README.md
+/usr/share/doc/python39-pillow/CHANGES.rst
+/usr/share/doc/python39-pillow/LICENSE
+/usr/share/doc/python39-pillow/README.md
[1]- Donecygcheck -l python39-imaging{,-tk} | sort > pipe1
[2]+ Donecygcheck -l python39-pillow | sort > pipe2
https://cygwin.com/pipermail/cygwin-announce/2021-December/010357.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
[ANNOUNCEMENT] Updated: double-conversion 3.1.7-1
The following packages have been uploaded to the Cygwin distribution: * libdouble-conversion-devel-3.1.7-1 * libdouble-conversion3-3.1.7-1 * double-conversion-3.1.7-1-src * double-conversion-debuginfo-3.1.7-1 This is an update to the latest upstream -- This project (double-conversion) provides binary-decimal and decimal-binary routines for IEEE doubles. The library consists of efficient conversion routines that have been extracted from the V8 JavaScript engine. The code has been refactored and improved so that it can be used more easily in other projects. HomePage: https://github.com/google/double-conversion#readme News: https://github.com/google/double-conversion/blob/v3.1.7/Changelog Source: https://github.com/google/double-conversion/tree/v3.1.7 License: BSD-3-Clause License https://github.com/google/double-conversion/blob/v3.1.7/LICENSE Cygwin Package Summary: https://cygwin.com/packages/summary/double-conversion-src.html Cygport Source: https://cygwin.com/git/?p=git/cygwin-packages/double-conversion.git -- Lemures Lemniscati -- 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: double-conversion 3.1.7-1
The following packages have been uploaded to the Cygwin distribution: * libdouble-conversion-devel-3.1.7-1 * libdouble-conversion3-3.1.7-1 * double-conversion-3.1.7-1-src * double-conversion-debuginfo-3.1.7-1 This is an update to the latest upstream -- This project (double-conversion) provides binary-decimal and decimal-binary routines for IEEE doubles. The library consists of efficient conversion routines that have been extracted from the V8 JavaScript engine. The code has been refactored and improved so that it can be used more easily in other projects. HomePage: https://github.com/google/double-conversion#readme News: https://github.com/google/double-conversion/blob/v3.1.7/Changelog Source: https://github.com/google/double-conversion/tree/v3.1.7 License: BSD-3-Clause License https://github.com/google/double-conversion/blob/v3.1.7/LICENSE Cygwin Package Summary: https://cygwin.com/packages/summary/double-conversion-src.html Cygport Source: https://cygwin.com/git/?p=git/cygwin-packages/double-conversion.git -- Lemures Lemniscati
Re: python3.9 failing?
On 23.12.2021 09:28, Russell VT wrote: On Thu, Dec 23, 2021 at 12:52 AM Marco Atzeri > wrote: On 23.12.2021 06:50, Russell VT wrote: > On Tue, Dec 21, 2021 at 6:34 AM Achim Gratz mailto:strom...@nexgo.de>> wrote: > >> Marco Atzeri writes: >>> Without Python 3.9 installed python3 should link by default to the >>> next in the line (likely 3.8) >> >> While python3 still defaults to python38 alternatives should probably >> prioritize 38 over 39? > > > That's how I "fixed" mercurial on my own installation, as it was > complaining about missing the "parsers" module, from inside the Python 3.9 > libraries, IIRC. Thanks for the report. It is caused by: $ head /usr/bin/hg -n 20 #!/usr/bin/python3 ^^ default 3.9 libdir = '../lib/python3.8/site-packages' ^^ but really need 3.8 Thanks... python3 defaults to whatever you have "alternatives" set to... looks like python's libdir doesn't quite obey those alternatives, though? not in this case as Mercurial is not version agnostic and it is setting its own specific "libdir" $ cygcheck -l mercurial | grep "usr/lib" | head /usr/lib/python3.8/site-packages/hgdemandimport/demandimportpy2.py /usr/lib/python3.8/site-packages/hgdemandimport/demandimportpy3.py .. No surprise is not working. A simple workaround is: Simpler (and more-complete) workaround is: % /usr/sbin/alternatives.exe --set python3 /usr/bin/python3.8 my workaround solve the specific hg issue, until its repacking. Alternatives can not support two different programs that need different version Cheers - RVT Regards Marco -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: python3.9 failing?
On Thu, Dec 23, 2021 at 12:52 AM Marco Atzeri wrote: > On 23.12.2021 06:50, Russell VT wrote: > > On Tue, Dec 21, 2021 at 6:34 AM Achim Gratz wrote: > > > >> Marco Atzeri writes: > >>> Without Python 3.9 installed python3 should link by default to the > >>> next in the line (likely 3.8) > >> > >> While python3 still defaults to python38 alternatives should probably > >> prioritize 38 over 39? > > > > > > That's how I "fixed" mercurial on my own installation, as it was > > complaining about missing the "parsers" module, from inside the Python > 3.9 > > libraries, IIRC. > > Thanks for the report. > It is caused by: > > $ head /usr/bin/hg -n 20 > #!/usr/bin/python3 > ^^ default 3.9 > > > libdir = '../lib/python3.8/site-packages' > ^^ but really need 3.8 > Thanks... python3 defaults to whatever you have "alternatives" set to... looks like python's libdir doesn't quite obey those alternatives, though? > No surprise is not working. > > A simple workaround is: > Simpler (and more-complete) workaround is: % /usr/sbin/alternatives.exe --set python3 /usr/bin/python3.8 % /usr/sbin/alternatives.exe --set python /usr/bin/python3.8 % /usr/sbin/alternatives.exe --display python3 python3 - status is manual. link currently points to /usr/bin/python3.8 /usr/bin/python3.8 - priority 38 /usr/bin/python3.6 - priority 36 /usr/bin/python3.7 - priority 37 /usr/bin/python3.9 - priority 39 Current `best' version is /usr/bin/python3.9. Read: that way, when you can't figure out why the "next python upgrade" isn't working, you only need to go to the very first stop you should be looking (ie /etc/alternatives), and not some random link that may or may not always be the first one in your path. Cheers - RVT -- Russell M. Van Tassell -- 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
