[ANNOUNCEMENT] Updated: python packages

2021-01-30 Thread Marco Atzeri via Cygwin-announce via Cygwin

Several python packages have been updated

python{36,37,38}-unidecode-1.1.2-1
python{36,37,38}-xmltodict-0.12.0-2

the following package were promoted from test to stable:

python{36,37,38}-cython-0.29.21-3

CYGWIN CHANGES

As python2 is no longer supported

https://devguide.python.org/devcycle/#end-of-life-branches

the package are updated to include postinstall script that
use "alternatives" to define for

  /usr/bin/python

  /usr/bin/python3
  /usr/bin/idle3
  /usr/bin/pydoc3

a default to the highest package available.

$ alternatives --display python
python - status is auto.
 link currently points to /usr/bin/python3.8
/usr/bin/python3.7 - priority 37
/usr/bin/python3.8 - priority 38
/usr/bin/python3.6 - priority 36
/usr/bin/python2.7 - priority 27
Current `best' version is /usr/bin/python3.8.

The following link are not provided anymore.
/usr/bin/idle
/usr/bin/pydoc

The python3 package will pull python38 package.

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

DESCRIPTION
Python is a programming language that lets you work quickly
and integrate systems more effectively.
Python is powerful... and fast; plays well with others;
runs everywhere; is friendly & easy to learn; is Open.

HOMEPAGE
https://www.python.org/

Regards
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


[ANNOUNCEMENT] Updated: mc-4.8.26-1

2021-01-30 Thread Marco Atzeri via Cygwin-announce via Cygwin

Version mc-4.8.26-1 of Midnight Commander
has been uploaded for cygwin

CHANGES
This is a upstream bugfix release
https://www.midnight-commander.org/wiki/NEWS-4.8.26

DESCRIPTION
GNU Midnight Commander is a visual file manager. It's a feature rich
full-screen text mode application that allows you to copy, move and
delete files and whole directory trees, search for files and run
commands in the subshell. Internal viewer and editor are included.

HOMEPAGE
http://www.midnight-commander.org/


Regards
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


Re: python-cython C++ support patch

2021-01-30 Thread Marco Atzeri via Cygwin

On 31.01.2021 04:53, Masamichi Hosoda wrote:


python38-cython-0.29.21-3 works fine with following test code.

```hello.pyx
print('Hello World!')
```

```setup.py
from distutils.core import setup
from Cython.Build import cythonize

setup(
 ext_modules=cythonize(
 "hello.pyx",
 language="c++",
 )
)
```

```test.py
import hello
```

Here's the result by python38-cython-0.29.21-2 (failed).

```
$ python setup.py build_ext --inplace
[...snip...]
$ python test.py
Traceback (most recent call last):
   File "test.py", line 1, in 
 import hello
ImportError: dynamic module does not define module export function 
(PyInit_hello)
```

Here's the result by python38-cython-0.29.21-3 (succeeded).

```
$ python setup.py build_ext --inplace
[...snip...]
$ python test.py
Hello World!
```

Thanks.


Thanks to you

I still think that the change you proposed should go upstream.

Have you tested your example on a NOT cygwin system ?

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: python-cython C++ support patch

2021-01-30 Thread Masamichi Hosoda
>> PyMODINIT_FUNC unfortunately dos not work and my changes try
>> to overcome it, see similar on
>> 
>> https://sourceware.org/pipermail/cygwin/2021-January/247211.html
>> 
>> but your portion is for additional C++ case
>> than I am adding in asimilar way
>> 
>> Regards
>> Marco
>
> a test package has been just uploaded.
> Try it and tell me if it solves your problem.
>
> Otherwise point me to your C++ code and I will look on it.
>
> Regards
> Marco

python38-cython-0.29.21-3 works fine with following test code.

```hello.pyx
print('Hello World!')
```

```setup.py
from distutils.core import setup
from Cython.Build import cythonize

setup(
ext_modules=cythonize(
"hello.pyx",
language="c++",
)
)
```

```test.py
import hello
```

Here's the result by python38-cython-0.29.21-2 (failed).

```
$ python setup.py build_ext --inplace
[...snip...]
$ python test.py
Traceback (most recent call last):
  File "test.py", line 1, in 
import hello
ImportError: dynamic module does not define module export function 
(PyInit_hello)
```

Here's the result by python38-cython-0.29.21-3 (succeeded).

```
$ python setup.py build_ext --inplace
[...snip...]
$ python test.py
Hello World!
```

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


Re: LyX becomes unresponsive to mouse

2021-01-30 Thread Enrico Forestieri
On Sat, Jan 30, 2021 at 02:53:29PM -0500, Chris Marshall wrote:
> Hi,
> 
> Yesterday I started some documentation work using my favorite LyX cygwin
> install:
> 
> > CYGWIN_NT-10.0 mypc 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
> 
> and
> 
> >  lyx --version
> > LyX 2.3.5-1 (2020-06-02)
> > Configuration
> >   Host type:   x86_64-pc-cygwin
> >   Special build flags:  build=release std-regex use-hunspell
> > use-aspell use-enchant
> >   Bundled libraries:    boost mythes
> >   C++ Compiler:    g++ (9.3.0)
> >   C++ Compiler flags:   -O2 -std=c++14
> >   C++ Compiler user flags:   -std=c++14  -ggdb -O2 -pipe -Wall
> > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong
> > --param=ssp-buffer-size=4 
> > -fdebug-prefix-map=/pub/devel/lyx/lyx-2.3.5.1-1.x86_64/build=/usr/src/debug/lyx-2.3.5.1-1
> >  
> > -fdebug-prefix-map=/pub/devel/lyx/lyx-2.3.5.1-1.x86_64/src/lyx-2.3.5-1=/usr/src/debug/lyx-2.3.5.1-1
> >   Linker flags:
> >   Linker user flags:
> >   Qt Frontend:
> >   Qt version:  5.9.4
> >   Packaging:   posix
> >   LyX binary dir:  /usr/bin
> >   LyX files dir:   /usr/share/lyx
> 
> After about 5 minutes, the LyX window and frame became completely
> unresponsive to mouse interaction.  I could resize the window but the
> contents did not resize/rearrange to fit the change in window shape.
> 
> Doing "kill -9 PID-of-lyx" had no effect but if I killed the PPID-of-lyx
> then the lyx window would close.
> 
> I tried running LyX with "strace lyx" which was slow on starting from all
> the terminal output and then the window opened but the expected contents
> were never displayed.  It appears that the "hang" happened before the strace
> lyx could complete its initialization.
> 
> Again, "kill -9 PID-of-lyx" had no effect but it worked if I killed the
> PPID-of-lyx (i.e. strace and not bash this time).
> 
> I tried uninstalling and reinstalling  the previous cygwin release version
> and even the latest cygports version.  All showed the same problem.
> 
> It may be useful that I had not had this problem previously with lyx on
> windows 10 with cygwin.  I don't know those version numbers but it was
> before the move to Qt5 which I saw some discussion regarding LyX.
> 
> Has anyone seen this problem and/or have an idea for a fix?  It seems not to
> be specific to the recent LyX version number but I am not able to try
> earlier than the 2.3.4.2-2 cygwin release.
> 
> At the moment, I am stuck without LyX under cygwin.  I plan to try the
> native LyX for windows to see if I can get LyX running for the near term.

If you have specified a path for the LyXServer pipe in
Tools > Preferences > Paths, try removing it and restarting lyx.

I also observed this strange behavior recently, and removing that path
cured it. Possibly there has been a change in the fifo code in cygwin
that has impacted lyx.

-- 
Enrico

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

2021-01-30 Thread Hans-Bernhard Bröker

Am 29.01.2021 um 00:36 schrieb Rafał Jopek via Cygwin:

Hi,

What package should be installed ?


None.  This is quite certainly a packaging mistake on a package you 
already have installed.


In short: that file should be in cygwin-devel, but it isn't.

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


LyX becomes unresponsive to mouse

2021-01-30 Thread Chris Marshall

Hi,

Yesterday I started some documentation work using my favorite LyX cygwin 
install:



CYGWIN_NT-10.0 mypc 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin


and


 lyx --version
LyX 2.3.5-1 (2020-06-02)
Configuration
  Host type:   x86_64-pc-cygwin
  Special build flags:  build=release std-regex use-hunspell 
use-aspell use-enchant

  Bundled libraries:    boost mythes
  C++ Compiler:    g++ (9.3.0)
  C++ Compiler flags:   -O2 -std=c++14
  C++ Compiler user flags:   -std=c++14  -ggdb -O2 -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-fstack-protector-strong --param=ssp-buffer-size=4 
-fdebug-prefix-map=/pub/devel/lyx/lyx-2.3.5.1-1.x86_64/build=/usr/src/debug/lyx-2.3.5.1-1 
-fdebug-prefix-map=/pub/devel/lyx/lyx-2.3.5.1-1.x86_64/src/lyx-2.3.5-1=/usr/src/debug/lyx-2.3.5.1-1

  Linker flags:
  Linker user flags:
  Qt Frontend:
  Qt version:  5.9.4
  Packaging:   posix
  LyX binary dir:  /usr/bin
  LyX files dir:   /usr/share/lyx


After about 5 minutes, the LyX window and frame became completely 
unresponsive to mouse interaction.  I could resize the window but the 
contents did not resize/rearrange to fit the change in window shape.


Doing "kill -9 PID-of-lyx" had no effect but if I killed the PPID-of-lyx 
then the lyx window would close.


I tried running LyX with "strace lyx" which was slow on starting from 
all the terminal output and then the window opened but the expected 
contents were never displayed.  It appears that the "hang" happened 
before the strace lyx could complete its initialization.


Again, "kill -9 PID-of-lyx" had no effect but it worked if I killed the 
PPID-of-lyx (i.e. strace and not bash this time).


I tried uninstalling and reinstalling  the previous cygwin release 
version and even the latest cygports version.  All showed the same problem.


It may be useful that I had not had this problem previously with lyx on 
windows 10 with cygwin.  I don't know those version numbers but it was 
before the move to Qt5 which I saw some discussion regarding LyX.


Has anyone seen this problem and/or have an idea for a fix?  It seems 
not to be specific to the recent LyX version number but I am not able to 
try earlier than the 2.3.4.2-2 cygwin release.


At the moment, I am stuck without LyX under cygwin.  I plan to try the 
native LyX for windows to see if I can get LyX running for the near term.




V/r,
Chris
--
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: tar 1.33 symlinks : Cannot change mode to...

2021-01-30 Thread Michael Soegtrop

have you tried the Cygwin snapshot as suggested in:

https://sourceware.org/pipermail/cygwin/2021-January/247418.html


The snapshot is hard to use in headless CI systems because the provided 
archive contains a cygwin dll, so it cannot be patched from within 
cygwin and my experience with doing such things in PowerShell is limited.


Instead I am now restoring the old version using:

wget 
http://mirrors.kernel.org/sourceware/cygwin/x86/release/tar/tar-1.32-2.tar.xz 
-O /tmp/tar-1.32-2.tar.xz

tar xvf /tmp/tar-1.32-2.tar.xz -C /

which can be run from the cygwin console to restore the previous tar 
after cygwin setup.


I will try the snapshot later locally.

Best regards,

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: Problems with native Unix domain sockets on Win 10/2019

2021-01-30 Thread Ken Brown via Cygwin

On 9/28/2020 7:03 AM, Michael McMahon wrote:



On 26/09/2020 08:30, Michael McMahon via Cygwin wrote:



On 25/09/2020 21:30, Ken Brown wrote:

On 9/25/2020 2:50 PM, Ken Brown via Cygwin wrote:

On 9/25/2020 10:29 AM, Michael McMahon wrote:



On 25/09/2020 14:19, Ken Brown wrote:

On 9/24/2020 8:01 AM, Michael McMahon wrote:



On 24/09/2020 12:26, Ken Brown wrote:

On 9/23/2020 7:25 AM, Michael McMahon via Cygwin wrote:

Hi,

I searched for related issues but haven't found anything.

I am having some trouble with Windows native Unix domain
sockets (a recent feature in Windows 10 and 2019 server) and
Cygwin. I think I possibly know the cause since I had to
investigate a similar looking issue on another platform built
on Windows.

The problem is that cygwin commands don't seem to recognise
native Unix domain sockets correctly. For example, the socket
"foo.sock" should have the same ownership and similar
permissions to other files in the example below:

$ ls -lrt total 2181303

-rw-r--r--  1 mimcmah  None 1259   Sep 23
10:22 test.c -rwxr-xr-x  1 mimcmah  None 3680
Sep 23 10:22 test.obj -rwxr-xr-x  1 mimcmah  None
121344 Sep 23 10:22 test.exe -rw-r-  1 Unknown+User
Unknown+Group 0 Sep 23 10:23 foo.sock -rw-r--r--  1
mimcmah  None 144356 Sep 23 10:27 check.ot

A bigger problem is that foo.sock can't be deleted with the
cygwin "rm" command.

$ rm -f foo.sock rm: cannot remove 'foo.sock': Permission
denied

$ chmod 777 foo.sock chmod: changing permissions of
'foo.sock': Permission denied

$ cmd /c del foo.sock

But, native Windows commands are okay, as the third example
shows.

I think the problem may relate to the way native Unix domain
sockets are implemented in Windows and the resulting special
handling required. They are implemented as NTFS reparse
points and when opening them with CreateFile, you need to
specify the FILE_FLAG_OPEN_REPARSE_POINT flag. Otherwise, you
get an ERROR_CANT_ACCESS_FILE. There are other complications
unfortunately, which I'd be happy to discuss further.

But, to reproduce it, you can compile the attached code
snippet which creates foo.sock in the current directory.
Obviously, this only works on recent versions of Windows 10
and 2019 server.


Cygwin doesn't currently support native Windows AF_UNIX
sockets, as you've discovered.  See

https://urldefense.com/v3/__https://cygwin.com/pipermail/cygwin/2020-June/245088.html__;!!GqivPVa7Brio!P7lIFI4rYAtWh8_DtCbRCxT-M_E4vwQ0qwzQ0p656T73BpJ0jbUkLI_bXdA6mmSL9lJcSQ$


for the current state of AF_UNIX sockets on Cygwin, including
the possibility of using native Windows AF_UNIX sockets on
systems that support them.

If all you want is for Cygwin to recognize such sockets and
allow you to apply rm, chmod, etc., I don't think it would be
hard to add that capability.  But I doubt if that's all you
want.

Further discussion of this will have to wait until Corinna is
available.



Thanks for the info. It's mainly about recognition of sockets
for regular commands. Since these objects can exist on Windows
filesystems now, potentially created by any kind of Windows
application, it would be great if Cygwin could handle them,
irrespective of whether the Cygwin development environment does.
Though that sounds like a good idea too.


I think this has a simple fix (attached), but I can't easily test
it because your test program doesn't compile for me.  First, I got

$ gcc -o native_unix_socket native_unix_socket.c 
native_unix_socket.c:5:10: fatal error: WS2tcpip.h: No such file or
directory 5 | #include  |  ^~~~ 
compilation terminated.


I fixed this by making the include file name lower case.  (My
system is case sensitive, so it matters.)

Next:

$ gcc -o native_unix_socket native_unix_socket.c 
native_unix_socket.c:8:10: fatal error: afunix.h: No such file or

directory 8 | #include  |  ^~ compilation
terminated.

There's no file afunix.h in the Cygwin distribution, but I located
it online and pasted in the contents.  The program now compiles but
fails to link:

$ gcc -o native_unix_socket native_unix_socket.c 
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:

 /tmp/cc74urPr.o:native_unix_socket.c:(.text+0x3b): undefined
reference to `__imp_WSAStartup' 
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0x3b): relocation

truncated to fit: R_X86_64_PC32 against undefined symbol
`__imp_WSAStartup' 
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:

 /tmp/cc74urPr.o:native_unix_socket.c:(.text+0xf2): undefined
reference to `__imp_WSAGetLastError' 
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0xf2): relocation

truncated to fit: R_X86_64_PC32 against undefined symbol
`__imp_WSAGetLastError' 
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:

 /tmp/cc74urPr.o:native_unix_socket.c:(.text+0x13d): undefined
reference to `__imp_WSAGetLastError' 
/tmp/cc74urPr.o:native_unix_socket.c:(.text+0x13d): relocation

trun

Re: tar 1.33 symlinks : Cannot change mode to...

2021-01-30 Thread Michael Soegtrop

Hi Marco,


have you tried the Cygwin snapshot as suggested in:

https://sourceware.org/pipermail/cygwin/2021-January/247418.html


sorry, I somehow missed this message. I will try this and report if it 
works.


Thanks!

Best regards,

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


[ANNOUNCEMENT] Updated: python packages

2021-01-30 Thread Marco Atzeri via Cygwin-announce via Cygwin

Several python packages have been updated

python383.8.7-2

python{36,37,38}-dbus-1.2.16-1
python{36,37,38}-bugzilla-3.0.2-1
python{36,37,38}-certifi-2020.12.5-1
python{36,37,38}-enchant-3.2.0-1
python{36,37,38}-httplib2-0.18.1-1
python{36,37,38}-pip-20.1.1-1
python{36,37,38}-recommonmark-0.7.1-1

the following package were uploaded as test:

python{36,37,38}-cython-0.29.21-3

CYGWIN CHANGES

As python2 is no longer supported

https://devguide.python.org/devcycle/#end-of-life-branches

the package are updated to include postinstall script that
use "alternatives" to define for

  /usr/bin/python

  /usr/bin/python3
  /usr/bin/idle3
  /usr/bin/pydoc3

a default to the highest package available.

$ alternatives --display python
python - status is auto.
 link currently points to /usr/bin/python3.8
/usr/bin/python3.7 - priority 37
/usr/bin/python3.8 - priority 38
/usr/bin/python3.6 - priority 36
/usr/bin/python2.7 - priority 27
Current `best' version is /usr/bin/python3.8.

The following link are not provided anymore.
/usr/bin/idle
/usr/bin/pydoc

The python3 package will pull python38 package.

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

DESCRIPTION
Python is a programming language that lets you work quickly
and integrate systems more effectively.
Python is powerful... and fast; plays well with others;
runs everywhere; is friendly & easy to learn; is Open.

HOMEPAGE
https://www.python.org/

Regards
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


Re: tar 1.33 symlinks : Cannot change mode to...

2021-01-30 Thread Marco Atzeri via Cygwin

On 30.01.2021 15:58, Michael Soegtrop via Cygwin wrote:

Dear Cygwin Team,

is there an update on this? Apparently tar is broken on Cygwin 32 since 
the latest update (it works fine on 64 bit Cygwin) and afaik there is no 
way to install specific package versions from the command line as would 
be possible via the Setup UI, so I can't easily roll back to the 
previous version of tar. IMHO this is a very severe issue - tar is 
ubiquitous.


Best regards,

Michael


have you tried the Cygwin snapshot as suggested in:

https://sourceware.org/pipermail/cygwin/2021-January/247418.html

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: python-cython C++ support patch

2021-01-30 Thread Marco Atzeri via Cygwin

On 30.01.2021 14:58, Marco Atzeri wrote:



PyMODINIT_FUNC unfortunately dos not work and my changes try
to overcome it, see similar on

https://sourceware.org/pipermail/cygwin/2021-January/247211.html

but your portion is for additional C++ case
than I am adding in asimilar way

Regards
Marco


a test package has been just uploaded.
Try it and tell me if it solves your problem.

Otherwise point me to your C++ code and I will look on it.

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: [BUG] Latest python38 package (3.8.7-1) fails to execute 'ensurepip', 3.8.3.-1 works

2021-01-30 Thread Marco Atzeri via Cygwin

On 24.01.2021 09:27, Marco Atzeri wrote:


as soon I solve also the second problem on asyncio
assuming I found a solution for it in short time.



Regards
Marco



3.8.7-2 is up to solve this problem.
asyncio needs additional debugging

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: tar 1.33 symlinks : Cannot change mode to...

2021-01-30 Thread Michael Soegtrop via Cygwin

Dear Cygwin Team,

is there an update on this? Apparently tar is broken on Cygwin 32 since 
the latest update (it works fine on 64 bit Cygwin) and afaik there is no 
way to install specific package versions from the command line as would 
be possible via the Setup UI, so I can't easily roll back to the 
previous version of tar. IMHO this is a very severe issue - tar is 
ubiquitous.


Best regards,

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: python-cython C++ support patch

2021-01-30 Thread Marco Atzeri via Cygwin

On 30.01.2021 14:28, Masamichi Hosoda wrote:

have you considered that you just need to define
CYTHON_NO_PYINIT_EXPORT ?

the portion of the code below your change has already the
ifdef __cplusplus semantic

Have you proposed it upstream ? It does not seem
a change restricted to Cygwin

Any way I see no "wrongness" to add it on the Cython rebuild


Hi Marco,

The relevant upstream source looks like this.
https://github.com/cython/cython/blob/0.29.21/Cython/Utility/ModuleSetupCode.c#L712

```
#define __Pyx_PyMODINIT_FUNC PyMODINIT_FUNC


PyMODINIT_FUNC unfortunately dos not work and my changes try
to overcome it, see similar on

https://sourceware.org/pipermail/cygwin/2021-January/247211.html

but your portion is for additional C++ case
than I am adding in asimilar way

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: python-cython C++ support patch

2021-01-30 Thread Masamichi Hosoda
> have you considered that you just need to define
> CYTHON_NO_PYINIT_EXPORT ?
>
> the portion of the code below your change has already the
> ifdef __cplusplus semantic
>
> Have you proposed it upstream ? It does not seem
> a change restricted to Cygwin
>
> Any way I see no "wrongness" to add it on the Cython rebuild

Hi Marco,

The relevant upstream source looks like this.
https://github.com/cython/cython/blob/0.29.21/Cython/Utility/ModuleSetupCode.c#L712

```
#define __Pyx_PyMODINIT_FUNC PyMODINIT_FUNC
```
Perhaps `PyMODINIT_FUNC` is defined differently
depending on whether it is in C++ or not.

If I understand correctly, python-cython-0.29.21-2.src.patch
in the Cygwin python-cython package changes `PyMODINIT_FUNC` to `PyObject *`.
Here is the part of python-cython-0.29.21-2.src.patch.

```
--- origsrc/Cython-0.29.21/Cython/Utility/ModuleSetupCode.c 2020-07-08 
23:44:39.0 +0200
+++ src/Cython-0.29.21/Cython/Utility/ModuleSetupCode.c 2021-01-04 
22:10:21.641515500 +0100
@@ -709,7 +709,7 @@ static CYTHON_INLINE void * PyThread_tss
 /// PyModInitFuncType.proto ///
 
 #ifndef CYTHON_NO_PYINIT_EXPORT
-#define __Pyx_PyMODINIT_FUNC PyMODINIT_FUNC
+#define __Pyx_PyMODINIT_FUNC  PyObject *
 
 #elif PY_MAJOR_VERSION < 3
 // Py2: define this to void manually because PyMODINIT_FUNC adds 
__declspec(dllexport) to it's definition.
```

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


Re: Latest update seems to have broken Mercurial

2021-01-30 Thread Marco Atzeri via Cygwin

On 30.01.2021 10:41, David Monksfield wrote:

Mercurial was working fine for me until my last Cywin update (yesterday).
I have Mercurial 5.5.1-1. I don't know enough about python to unpick this,
but it looks suspicious that there is a mixture of python2.7 and python3.8
in the traceback.





Any help or suggestions would be appreciated.

Thanks,
David



Hi David,
yes I am aware, current mercurial package still requires python 2.7.

You can see the situation with

---
$ alternatives  --display python
python - status is auto.
 link currently points to /usr/bin/python3.8
/usr/bin/python3.7 - priority 37
/usr/bin/python2.7 - priority 27
/usr/bin/python3.6 - priority 36
/usr/bin/python3.8 - priority 38
Current `best' version is /usr/bin/python3.8.
-

and change it with

-
$ alternatives  --config python

There are 4 programs which provide 'python'.

  SelectionCommand
---
   1   /usr/bin/python3.7
   2   /usr/bin/python2.7
   3   /usr/bin/python3.6
*+ 4   /usr/bin/python3.8

Enter to keep the current selection[+], or type selection number: 2


$ hg --version
Mercurial Distributed SCM (version 5.6)
(see https://mercurial-scm.org for more information)
...

--

see  "alternatives  --help"
for further info


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


Latest update seems to have broken Mercurial

2021-01-30 Thread David Monksfield
Mercurial was working fine for me until my last Cywin update (yesterday).
I have Mercurial 5.5.1-1. I don't know enough about python to unpick this,
but it looks suspicious that there is a mixture of python2.7 and python3.8
in the traceback.

I now get this:

$ hg status
Traceback (most recent call last):
  File "/usr/bin/hg", line 43, in 
dispatch.run()
  File "/usr/lib/python3.8/importlib/util.py", line 245, in __getattribute__
self.__spec__.loader.exec_module(self)
  File "", line 783, in exec_module
  File "", line 219, in _call_with_frames_removed
  File "/usr/lib/python2.7/site-packages/mercurial/dispatch.py", line 22, in 

from .i18n import _
  File "/usr/lib/python3.8/importlib/util.py", line 245, in __getattribute__
self.__spec__.loader.exec_module(self)
  File "/usr/lib/python2.7/site-packages/mercurial/i18n.py", line 112, in 

if _plain():
  File "/usr/lib/python2.7/site-packages/mercurial/i18n.py", line 104, in _plain
b'HGPLAIN' not in encoding.environ
  File "/usr/lib/python3.8/importlib/util.py", line 245, in __getattribute__
self.__spec__.loader.exec_module(self)
  File "/usr/lib/python2.7/site-packages/mercurial/encoding.py", line 40, in 

charencode = policy.importmod('charencode')
  File "/usr/lib/python2.7/site-packages/mercurial/policy.py", line 116, in 
importmod
mod = _importfrom(pn, mn)
  File "/usr/lib/python2.7/site-packages/mercurial/policy.py", line 67, in 
_importfrom
pkg = __import__(pkgname, globals(), fakelocals, [modname], level=1)
  File "/usr/lib/python3.8/importlib/util.py", line 286, in create_module
return self.loader.create_module(spec)
ImportError: dynamic module does not define module export function 
(PyInit_parsers)

Any help or suggestions would be appreciated.

Thanks,
David

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