Re: python fails asyncio tests (py 3.7 & 3.8)
On 29.12.2020 06:41, Marco Atzeri wrote: On 29.12.2020 01:08, Mark Geisert wrote: Hi Marco, Hi Mark, is this the expected result ? test_connection_attributes (__main__.TestAPI_UseUnixSocketsPoll) ... ERROR /usr/lib/python3.8/unittest/case.py:704: ResourceWarning: unclosed type=SocketKind.SOCK_STREAM, proto=0> outcome.errors.clear() It does not freeze That's a new error to me; I haven't run that test. I could have been more specific in my test instructions. There are apparently two test series (which is also news to me). They are /usr/lib/python3.8/test and .../unittest. It seems you were in the latter? The script to run is in .../test. Here's how: cd /usr/lib/python3.8/test python3.8 test_asyncore.py -v < I run this, but I am building 3.8.6 I see also other problem around so I am rebuiling without your patch to see if this problem is due to the patch or to other the other problems seem not related to your patch. I was hoping to release all updated python packages, but the current problem is blocking I need to check what is causing this issue : File "/usr/lib/python3.6/site-packages/pip/_vendor/urllib3/connection.py", line 71, in class HTTPConnection(_HTTPConnection, object): File "/usr/lib/python3.6/site-packages/pip/_vendor/urllib3/connection.py", line 99, in HTTPCo default_socket_options = [(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)] AttributeError: module 'socket' has no attribute 'TCP_NODELAY' *** ERROR: pip3.6 install failed
Re: python fails asyncio tests (py 3.7 & 3.8)
On 29.12.2020 01:08, Mark Geisert wrote: Hi Marco, On Mon, 28 Dec 2020, Marco Atzeri via Cygwin-apps wrote: On 17.12.2020 10:20, Mark Geisert wrote: Hi Marco, Below is the patch I developed to work around the problem report in https://cygwin.com/pipermail/cygwin/2020-November/246830.html I called the patch file 3.8.3-peercred-cygwin.patch. I am unable to test the patch myself because of continuing problems building a new Python. I don't know if my issues are due to being on latest Cygwin code vs 3.1.7, or gcc 10.2 vs 9.3, or what. Could you tell me what your build environment is like? I'll try to duplicate it. Test the patch by running a Python built with it on the example from the OP. Without the patch, the run would hang in the middle of the test script. With the patch, it should quickly complete with 4 unrelated errors mentioning MSG_OOB. Thanks & Regards, ..mark Hi Mark, is this the expected result ? test_connection_attributes (__main__.TestAPI_UseUnixSocketsPoll) ... ERROR /usr/lib/python3.8/unittest/case.py:704: ResourceWarning: unclosed type=SocketKind.SOCK_STREAM, proto=0> outcome.errors.clear() It does not freeze That's a new error to me; I haven't run that test. I could have been more specific in my test instructions. There are apparently two test series (which is also news to me). They are /usr/lib/python3.8/test and .../unittest. It seems you were in the latter? The script to run is in .../test. Here's how: cd /usr/lib/python3.8/test python3.8 test_asyncore.py -v < I run this, but I am building 3.8.6 I see also other problem around so I am rebuiling without your patch to see if this problem is due to the patch or to other Separately, I'm still wrestling with build issues. Just as a known-good alternative, how is your test environment set up? Is your cygwin1.dll from standard 3.1.7, or a snapshot, or do you build from git master? Are you using the latest binutils and gcc-g++ packages or something newer? standard 3.1.7, latest cygwin packages Thanks for any info you can provide. I seem to be having issues with linking programs having many object files. Like any Python 3, or the Flint math library for examples. The link fails with a SIGSEGV or an assertion failure in cofflink.c. Nobody else has reported these. Thanks & Regards, ..mark
Re: python fails asyncio tests (py 3.7 & 3.8)
Hi Marco, On Mon, 28 Dec 2020, Marco Atzeri via Cygwin-apps wrote: On 17.12.2020 10:20, Mark Geisert wrote: Hi Marco, Below is the patch I developed to work around the problem report in https://cygwin.com/pipermail/cygwin/2020-November/246830.html I called the patch file 3.8.3-peercred-cygwin.patch. I am unable to test the patch myself because of continuing problems building a new Python. I don't know if my issues are due to being on latest Cygwin code vs 3.1.7, or gcc 10.2 vs 9.3, or what. Could you tell me what your build environment is like? I'll try to duplicate it. Test the patch by running a Python built with it on the example from the OP. Without the patch, the run would hang in the middle of the test script. With the patch, it should quickly complete with 4 unrelated errors mentioning MSG_OOB. Thanks & Regards, ..mark Hi Mark, is this the expected result ? test_connection_attributes (__main__.TestAPI_UseUnixSocketsPoll) ... ERROR /usr/lib/python3.8/unittest/case.py:704: ResourceWarning: unclosed type=SocketKind.SOCK_STREAM, proto=0> outcome.errors.clear() It does not freeze That's a new error to me; I haven't run that test. I could have been more specific in my test instructions. There are apparently two test series (which is also news to me). They are /usr/lib/python3.8/test and .../unittest. It seems you were in the latter? The script to run is in .../test. Here's how: cd /usr/lib/python3.8/test python3.8 test_asyncore.py -v Separately, I'm still wrestling with build issues. Just as a known-good alternative, how is your test environment set up? Is your cygwin1.dll from standard 3.1.7, or a snapshot, or do you build from git master? Are you using the latest binutils and gcc-g++ packages or something newer? Thanks for any info you can provide. I seem to be having issues with linking programs having many object files. Like any Python 3, or the Flint math library for examples. The link fails with a SIGSEGV or an assertion failure in cofflink.c. Nobody else has reported these. Thanks & Regards, ..mark
Re: python fails asyncio tests (py 3.7 & 3.8)
On 17.12.2020 10:20, Mark Geisert wrote: Hi Marco, Below is the patch I developed to work around the problem report in https://cygwin.com/pipermail/cygwin/2020-November/246830.html I called the patch file 3.8.3-peercred-cygwin.patch. I am unable to test the patch myself because of continuing problems building a new Python. I don't know if my issues are due to being on latest Cygwin code vs 3.1.7, or gcc 10.2 vs 9.3, or what. Could you tell me what your build environment is like? I'll try to duplicate it. Test the patch by running a Python built with it on the example from the OP. Without the patch, the run would hang in the middle of the test script. With the patch, it should quickly complete with 4 unrelated errors mentioning MSG_OOB. Thanks & Regards, ..mark Hi Mark, is this the expected result ? test_connection_attributes (__main__.TestAPI_UseUnixSocketsPoll) ... ERROR /usr/lib/python3.8/unittest/case.py:704: ResourceWarning: unclosed type=SocketKind.SOCK_STREAM, proto=0> outcome.errors.clear() It does not freeze
Re: [RFC] cygport mingw.cygclass
Yaakov Selkowitz writes: > To ease the maintenance of MinGW cross-compiling packages, I have > written a new mingw.cygclass (actually, a series of cygclasses, but > that's the top-level one that you should use) which is designed to > allow building both 32- and 64-bit MinGW binaries in the same build. > It also allows for the introduction of Windows for ARM toolchains, > which I have bootstrapped but am not able to verify due to the lack of > access to such systems. (Therefore, they are disabled by default.) I've had a look finally and when I say that I really mean reading the diffs… > Because this moves fundamentally away from the single-arch paradigms on > which cygport was built (remember that cygport predates the widespread > availability of 64-bit Windows systems), extensive changes were > required that could possibly break something. Therefore, I have posted > this to the topic/mingw branch of cygport. If maintainers could please > test this with both mingw and ordinary packages, that would be > appreciated. Anything that you'd particularly want to have checked or just generally that things still work? I still need to rebase that branch to current master and then put my patches on top, so I don't expect to immediately start testing. > Also needed is feedback on the naming schemes currently used: > > * mingw32_* functions and MINGW32_ definitions/variables for i686 > * mingw64_* functions and MINGW64_ definitions/variables for x86_64 I'm not particularly enamored with mingw32 as that's not what it is (both are using MingW-W64), on the other hand I have no better idea either. > * mingwarm32_* functions and MINGWARM32_ definitions/variables for > armv7 > * mingwarm64_* functions and MINGWARM64_ definitions/variables for > aarch64 > > * mingw-* for source package names > * mingw64-i686-* for i686 binary packages > * mingw64-x86_64-* for x86_64 binary packages > * mingw64-armv7-* for armv7 binary packages > * mingw64-aarch64-* for aarch64 binary packages > > The function/definition naming scheme is designed around Fedora (which > does not have ARM, so I made those up myself) but the binary package > scheme match our current usage. I realize the source package names are > those from the old i686-only mingw.org packages; whether we want to > rename the binary packages to mingw32-/mingw64-, or rename the source > packages to mingw64-, or do something else entirely, I'm open to > suggestions. I'd tend to leave the names alone unless/until we come up with a way to target multiple cross-architectures from the same package source. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: perl-Unicode-GCString
Op 28-12-2020 om 15:07 schreef ASSI: It seems you're missing the fact it was obsoleted because that module is included in the perl-Unicode-LineBreak package and it was long obsolete before the removal. You are right. Thanks. -- Erwin
Re: perl-Unicode-GCString
Erwin Waterlander writes: > po4a 0.62 requires for testing the package perl-Unicode-GCString. I > still have an old package from 2014 in my Cygwin installation. It was > abandoned and removed from the Cygwin packages in 2016 > (https://sourceware.org/legacy-ml/cygwin-apps/2016-01/msg00020.html). Can > this package be revived? It seems you're missing the fact it was obsoleted because that module is included in the perl-Unicode-LineBreak package and it was long obsolete before the removal. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
