Re: Cygwin now on Python 3? What about Mercurial?
On Thu, Mar 4, 2021 at 8:39 AM Ken Brown via Cygwin wrote: > On 3/4/2021 6:05 AM, marco atzeri via Cygwin wrote: > > On Thu, Mar 4, 2021 at 10:27 AM Russell VT via Cygwin wrote: > >> Cygwin Enthusiasts! > > > > It seems the current package maintainer for Mercurial is not available > for > > the upgrade from 2.7 to 3.8. > > We need to decide how to proceed > > The Mercurial maintainer (Jari) doesn't always follow the mailing list. > I've > added him to the CC. > Thanks Ken! In the meantime, I'll take a look at the Package Contributors' Guide, as was suggested by another... and maybe I can hell fill in some blocks with some of my own resources. Cheers! Russell VT -- 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
Re: Cygwin now on Python 3? What about Mercurial?
On 07.03.2021 10:32, Russell VT via Cygwin wrote: On Thu, Mar 4, 2021 at 8:39 AM Ken Brown via Cygwin wrote: On 3/4/2021 6:05 AM, marco atzeri via Cygwin wrote: On Thu, Mar 4, 2021 at 10:27 AM Russell VT via Cygwin wrote: Cygwin Enthusiasts! It seems the current package maintainer for Mercurial is not available for the upgrade from 2.7 to 3.8. We need to decide how to proceed The Mercurial maintainer (Jari) doesn't always follow the mailing list. I've added him to the CC. Thanks Ken! In the meantime, I'll take a look at the Package Contributors' Guide, as was suggested by another... and maybe I can hell fill in some blocks with some of my own resources. Cheers! Russell VT Mercurial has been just updated to version 5.7 https://cygwin.com/packages/summary/mercurial.html and it now depends on python3.8 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
mingw.org may be dead, but is referenced in cygwin docs
Hello Cygwin- I was reading the webpage "Building and Using DLLs". That page suggests looking at mingw.org for more information. mingw.org is no more. I don't know when or if it will return. Thanks, Michael -- 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 packages
On 10/02/2021 08:19, Marco Atzeri via Cygwin wrote:
On 10.02.2021 03:29, Yaakov Selkowitz via Cygwin wrote:
On Tue, 2021-02-09 at 21:31 +, Jon Turney wrote:
On 22/01/2021 21:37, Marco Atzeri via Cygwin-announce via Cygwin wrote:
Several python packages have been promoted from test to stable
[...]
python{36,37,38}-lxml-4.6.2-1
Marco,
I noticed something a bit odd, which I'm not sure is expected or not.
expected :-(
Not time in the past to work on it.
I was focusing on deploying python38-* as first priority
If I install 'python3-lxml', I get 'python36-lxml', which doesn't do me
much good with 'python3' installed (which gets me python3.8 currently).
When I changed the packaging scheme from pythonX-* to pythonXY-*, 3.6
was the
"3" version at the time, and the python3-* created alongside
python36-* were
only meant to be upgrade helpers from that point forward.
Ok. I'm not sure 'python3-foo' just as an upgrade helper is ideal.
Let me explain my use case:
I have a CI job which runs 'setup -q -P python3,python3-lxml'. It's
nice if that gets me something where "python3 -c 'import lxml'" works,
and doesn't require changing every time the default python version is
updated.
there is a bit of cleaning to do on the python3-* tree and package pull,
but first we need to patch cygport to stop creating additional
python3-* packages if not requested.
I guess after the Perl 5.32 I could look on it
as spring project.
--
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
help please
1 [main] john 2960 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com Warning: detected hash type "whirlpool", but the string is also recognized as "whirlpool0" Use the "--format=whirlpool0" option to force loading these as that type instead Warning: detected hash type "whirlpool", but the string is also recognized as "whirlpool1" Use the "--format=whirlpool1" option to force loading these as that type instead -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: help please
> 1 [main] john 2960 find_fast_cwd: WARNING: Couldn't compute FAST_CWD >pointer. Please report this problem to >the public mailing list cygwin@cygwin.com >Warning: detected hash type "whirlpool", but the string is also recognized >as "whirlpool0" >Use the "--format=whirlpool0" option to force loading these as that type >instead >Warning: detected hash type "whirlpool", but the string is also recognized >as "whirlpool1" >Use the "--format=whirlpool1" option to force loading these as that type >instead https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings -- 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: mingw.org may be dead, but is referenced in cygwin docs
try; http://mingw-w64.org/ instead else see Sourceforge... On Sun, Mar 7, 2021 at 8:42 AM Mike Gran via Cygwin wrote: > Hello Cygwin- > I was reading the webpage "Building and Using DLLs". > That page suggests looking at mingw.org for more information. > mingw.org is no more. I don't know when or if it will return. > Thanks, > Michael > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: python packages
On 3/7/2021 10:37 AM, Jon Turney wrote:
On 10/02/2021 08:19, Marco Atzeri via Cygwin wrote:
On 10.02.2021 03:29, Yaakov Selkowitz via Cygwin wrote:
On Tue, 2021-02-09 at 21:31 +, Jon Turney wrote:
On 22/01/2021 21:37, Marco Atzeri via Cygwin-announce via Cygwin wrote:
Several python packages have been promoted from test to stable
[...]
python{36,37,38}-lxml-4.6.2-1
Marco,
I noticed something a bit odd, which I'm not sure is expected or not.
expected :-(
Not time in the past to work on it.
I was focusing on deploying python38-* as first priority
If I install 'python3-lxml', I get 'python36-lxml', which doesn't do me
much good with 'python3' installed (which gets me python3.8 currently).
When I changed the packaging scheme from pythonX-* to pythonXY-*, 3.6 was the
"3" version at the time, and the python3-* created alongside python36-* were
only meant to be upgrade helpers from that point forward.
Ok. I'm not sure 'python3-foo' just as an upgrade helper is ideal.
Let me explain my use case:
I have a CI job which runs 'setup -q -P python3,python3-lxml'. It's nice if
that gets me something where "python3 -c 'import lxml'" works, and doesn't
require changing every time the default python version is updated.
Currently python3 is a meta-package whose main purpose is to require the default
python version (currently python38). Marco, couldn't you just make python3-foo
a meta-package that requires the corresponding python*-foo (currently python38-foo)?
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: Cygwin Digest, Vol 13, Issue 22
> Date: Sun, 7 Mar 2021 15:05:55 + (UTC) > From: Mike Gran > To: "cygwin@cygwin.com" > Subject: mingw.org may be dead, but is referenced in cygwin docs > > Hello Cygwin- > I was reading the webpage "Building and Using DLLs". > That page suggests looking at mingw.org for more information. > mingw.org is no more. I don't know when or if it will return. > Thanks, > Michael https://osdn.net/projects/mingw/ -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature -- 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: mingw.org may be dead, but is referenced in cygwin docs
On 2021-03-07 08:58, Hugh S. Myers via Cygwin wrote: On Sun, Mar 7, 2021 at 8:42 AM Mike Gran wrote: I was reading the webpage "Building and Using DLLs". That page suggests looking at mingw.org for more information. mingw.org is no more. I don't know when or if it will return. > try; http://mingw-w64.org/ instead else see Sourceforge... Good catch - patch submitted - fix on its way... -- 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
[ANNOUNCEMENT] Updated: zstd-1.4.9-1 and development headers / libraries
This release updates Zstandard to the latest upstream version, which is a maintenance release with performance improvements and bugfixes. Zstandard, or zstd as short version, is a fast lossless compression algorithm, targeting real-time compression scenarios at zlib-level and better compression ratios. http://www.zstd.net/ Besides a standalone compression tool, development headers and a library with comprehensive API are available both for Cygwin native applications and cross-compilation toolchains in the following sub-packages: libzstd-devel-1.4.9-1 libzstd1-1.4.9-1 mingw64-i686-zstd-1.4.9-1 mingw64-x86_64-zstd-1.4.9-1 Notes - This version is compiled with support for GZip, LZ4 and Xz compression. Support for legacy formats from versions before 1.0 has been removed. -- *** 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
Extrusion + CNC precision components in China
Dear Mr/Ms, Extrusion + CNC precision components in China. If you have any need for our services , please send us the drawings. and we can quote it for you. thanks. Best Regards, 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: [ANNOUNCEMENT] Updated: python packages
On 07.03.2021 17:58, Ken Brown via Cygwin wrote: I have a CI job which runs 'setup -q -P python3,python3-lxml'. It's nice if that gets me something where "python3 -c 'import lxml'" works, and doesn't require changing every time the default python version is updated. Currently python3 is a meta-package whose main purpose is to require the default python version (currently python38). Marco, couldn't you just make python3-foo a meta-package that requires the corresponding python*-foo (currently python38-foo)? Ken the issue is that Cygport creates the "obsolete" python3-foo that is replaced by python36-foo automatically. we should change cygport to use python38 instead --- $ cat python3-lxml/python3-lxml-4.6.2-1.hint category: _obsolete requires: python36-lxml sdesc: "Obsoleted by python36-lxml" ldesc: "The python3-lxml package is obsolete. Selecting this package for installation will cause the python36-lxml package, which replaces this one, to be installed instead." external-source: python-lxml --- -- 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: weechat-3.1-1
Version 3.1-1 of "weechat" has been uploaded. ChangeLog: https://weechat.org/files/changelog/ChangeLog-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. -- 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 packages
On 3/7/2021 2:34 PM, Marco Atzeri via Cygwin wrote: On 07.03.2021 17:58, Ken Brown via Cygwin wrote: I have a CI job which runs 'setup -q -P python3,python3-lxml'. It's nice if that gets me something where "python3 -c 'import lxml'" works, and doesn't require changing every time the default python version is updated. Currently python3 is a meta-package whose main purpose is to require the default python version (currently python38). Marco, couldn't you just make python3-foo a meta-package that requires the corresponding python*-foo (currently python38-foo)? Ken the issue is that Cygport creates the "obsolete" python3-foo that is replaced by python36-foo automatically. we should change cygport to use python38 instead --- $ cat python3-lxml/python3-lxml-4.6.2-1.hint category: _obsolete requires: python36-lxml sdesc: "Obsoleted by python36-lxml" ldesc: "The python3-lxml package is obsolete. Selecting this package for installation will cause the python36-lxml package, which replaces this one, to be installed instead." external-source: python-lxml --- As long as you have to patch cygport anyway, maybe it would be better to have cygport create an empty (but not obsolete) package. I think users might find it confusing that they have to install an obsolete package to get what they want. Also, obsolete packages are normally hidden in the setup UI. 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: [ANNOUNCEMENT] Updated: python packages
On 2021-03-07 13:44, Ken Brown via Cygwin wrote: On 3/7/2021 2:34 PM, Marco Atzeri via Cygwin wrote: On 07.03.2021 17:58, Ken Brown via Cygwin wrote: I have a CI job which runs 'setup -q -P python3,python3-lxml'. It's nice if that gets me something where "python3 -c 'import lxml'" works, and doesn't require changing every time the default python version is updated. Currently python3 is a meta-package whose main purpose is to require the default python version (currently python38). Marco, couldn't you just make python3-foo a meta-package that requires the corresponding python*-foo (currently python38-foo)? the issue is that Cygport creates the "obsolete" python3-foo that is replaced by python36-foo automatically. we should change cygport to use python38 instead --- $ cat python3-lxml/python3-lxml-4.6.2-1.hint category: _obsolete requires: python36-lxml sdesc: "Obsoleted by python36-lxml" ldesc: "The python3-lxml package is obsolete. Selecting this package for installation will cause the python36-lxml package, which replaces this one, to be installed instead." external-source: python-lxml As long as you have to patch cygport anyway, maybe it would be better to have cygport create an empty (but not obsolete) package. I think users might find it confusing that they have to install an obsolete package to get what they want. Also, obsolete packages are normally hidden in the setup UI. Hidden generic/virtual package selections in Debian apt/-get and other package managers are annoying as users (I!) don't know how to do anything when they find out about them e.g. $ apt show exim Package: exim State: not a real package (virtual) N: Can't select candidate version from package exim as it has no candidate N: Can't select versions from package 'exim' as it is purely virtual N: No packages found Suggest adding a category like ~Generic or ~Virtual to sort out of the way but be selectable if you search for Python, Perl, Ruby, etc. I have been unable to find any definitive category list where that might be checked, except in cygwin-apps/calm/genini, and I believe that is not being used any more, as it is missing Debug but includes obsolete Mingw. -- 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
