[ITP] python36-wx 4.0.7.post2

[ITP] python36-wx 4.0.7.post2

[Hamish McIntyre-Bhatty]

[-- Attachment #1.1.1: Type: text/plain, Size: 681 bytes --]

Hello,

Sending this email to say that I intend to package python36-wx
4.0.7.post2 (wxPython 4.0.7.post2 compiled for Python 3.6). My test
packages are available at https://www.hamishmb.com/files/cygwin-temp/

I wasn't sure which Python 3 version to build against, but it seems most
packages are built against 3.6. I will happily build for 3.7 and 3.8 as
well if needed.

One thing I'm not sure of is that in order to avoid conflicts with
python-wx (wxPython 3 for Python 2), I have to rename some of the
binaries that are installed in /usr/bin - see the cygport file for details.

If anyone has any feedback I'd appreciate it very much.

Hamish McIntyre-Bhatty


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ITP] python36-wx 4.0.7.post2

[Marco Atzeri]

On 09.06.2020 18:52, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> Hello,
> 
> Sending this email to say that I intend to package python36-wx
> 4.0.7.post2 (wxPython 4.0.7.post2 compiled for Python 3.6). My test
> packages are available at https://www.hamishmb.com/files/cygwin-temp/
> 
> I wasn't sure which Python 3 version to build against, but it seems most
> packages are built against 3.6. I will happily build for 3.7 and 3.8 as
> well if needed.
> 
> One thing I'm not sure of is that in order to avoid conflicts with
> python-wx (wxPython 3 for Python 2), I have to rename some of the
> binaries that are installed in /usr/bin - see the cygport file for details.
> 
> If anyone has any feedback I'd appreciate it very much.
> 
> Hamish McIntyre-Bhatty
> 

It is probably possible to build

python36-wx and python37-wx together with the same source package.
The only files of the binaries they seem to share are

usr/share/icons/hicolor/16x16/apps/PyCrust.png
usr/share/icons/hicolor/32x32/apps/PyCrust.png

that can be put in a tiny shared common subpackage

python38-wx will need python38-numpy that is not yet available.


Maybe it is also possible to build python27-wx, but I doubt is is worth
the effort as we should move faster on python3.8

Questions:
- why 4.0.7.post2 and not 4.1.0 ?
- have you a BUILD_REQUIRES list ?
just to avoid a try loop to test my idea

Regards
Marco

Re: [ITP] python36-wx 4.0.7.post2

[Hamish McIntyre-Bhatty]

[-- Attachment #1.1.1: Type: text/plain, Size: 1877 bytes --]

On 09/06/2020 20:53, Marco Atzeri via Cygwin-apps wrote:
>
> It is probably possible to build
>
> python36-wx and python37-wx together with the same source package.
> The only files of the binaries they seem to share are
>
> usr/share/icons/hicolor/16x16/apps/PyCrust.png
> usr/share/icons/hicolor/32x32/apps/PyCrust.png
>
> that can be put in a tiny shared common subpackage
>
Seems like a good idea, I'll do that.

> python38-wx will need python38-numpy that is not yet available.
>
Yeah. There's also a problem with the dev package I think, because
-lpython3.8m can't find the library, and python3.8m doesn't seem to
exist as a command. I might just be being a doofus though so I'll double
check that I installed the right packages.
> Maybe it is also possible to build python27-wx, but I doubt is is worth
> the effort as we should move faster on python3.8
>
Yeah, I was more concerned about getting a really well-working wxPython
3.0 build for Python 2. Also I think the combo of wxPython 4 and Python
2 is probably uncommon so yeah I agree, better off focusing on Python 3.8.

My only question is that PYTHON3_SITELIB seems to only point to 3.6's
site packages folder. Any way I can override this or should I just
hardcode "/usr/lib/python3.7/site-packages" in my cygport file?

> Questions:
> - why 4.0.7.post2 and not 4.1.0 ?

Because 4.1.0 requires wxWidgets 3.1.x, which is not currently in
Cygwin, and I have used wxPython 4.0.x a lot and can verify that it
works well.

Having said that, I fully intend to update it to wxPython 4.1.x sometime
soon, it's just that 4.0.x is what I've spent ages debugging so I'd like
to get a working build out for that first.

> - have you a BUILD_REQUIRES list ?
> just to avoid a try loop to test my idea
>
Actually no but that's a good idea. I'll do that too.

Thanks,

Hamish


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ITP] python36-wx 4.0.7.post2

[Marco Atzeri]

On 10.06.2020 11:34, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 09/06/2020 20:53, Marco Atzeri via Cygwin-apps wrote:
>>
>> It is probably possible to build
>>
>> python36-wx and python37-wx together with the same source package.
>> The only files of the binaries they seem to share are
>>
>> usr/share/icons/hicolor/16x16/apps/PyCrust.png
>> usr/share/icons/hicolor/32x32/apps/PyCrust.png
>>
>> that can be put in a tiny shared common subpackage
>>
> Seems like a good idea, I'll do that.
> 
>> python38-wx will need python38-numpy that is not yet available.
>>
> Yeah. There's also a problem with the dev package I think, because
> -lpython3.8m can't find the library, and python3.8m doesn't seem to
> exist as a command. I might just be being a doofus though so I'll double
> check that I installed the right packages.

on python 3.8 they should be
  -lpython3.8 and  python3.8

You can use pkconfig to recover it

$ pkg-config --libs python-3.8
-lpython3.8

$ pkg-config --libs python-3.7
-lpython3.7m

Re: [ITP] python36-wx 4.0.7.post2

[Hamish McIntyre-Bhatty]

[-- Attachment #1.1.1: Type: text/plain, Size: 1597 bytes --]

On 11/06/2020 16:19, Marco Atzeri via Cygwin-apps wrote:
> On 10.06.2020 11:34, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> Yeah. There's also a problem with the dev package I think, because
>> -lpython3.8m can't find the library, and python3.8m doesn't seem to
>> exist as a command. I might just be being a doofus though so I'll double
>> check that I installed the right packages.
>
> on python 3.8 they should be
>  -lpython3.8 and  python3.8
>
> You can use pkconfig to recover it
>
> $ pkg-config --libs python-3.8
> -lpython3.8
>
> $ pkg-config --libs python-3.7
> -lpython3.7m
>
Ah, thank you, that makes sense.

I have now built the packages for python 3.7 as well, from the same
source package. Your idea worked great :)

The new ones are available at the same place as before:
https://www.hamishmb.com/files/cygwin-temp/

All seems to be working okay for me, but there are some notes/questions
I have:

- I get errors from python3.cygclass at the start of every build saying
it can't find "python3-config" - looks to be a missing
symlink/misconfigured cygclass script?

- On 32-bit Cygwin, stripping the debug symbols with objdump.exe from
the libraries takes an extremely long time - I reckon 3-4 times slower
than on 64-bit, at least. It's kind of prohibitively slow, does anyone
know why?

- On 32-bit Cygwin, I tend to get fork errors when running the wxPython
demo, but not on 64-bit (identical build options). Is this likely the
32-bit fork bug mentioned on Cygwin's home page, or a problem with my
installation/setup?

Hamish


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ITP] python36-wx 4.0.7.post2

[Marco Atzeri]

[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]

On 11.06.2020 18:03, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 11/06/2020 16:19, Marco Atzeri via Cygwin-apps wrote:
>> On 10.06.2020 11:34, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>>> Yeah. There's also a problem with the dev package I think, because
>>> -lpython3.8m can't find the library, and python3.8m doesn't seem to
>>> exist as a command. I might just be being a doofus though so I'll double
>>> check that I installed the right packages.
>>
>> on python 3.8 they should be
>>   -lpython3.8 and  python3.8
>>
>> You can use pkconfig to recover it
>>
>> $ pkg-config --libs python-3.8
>> -lpython3.8
>>
>> $ pkg-config --libs python-3.7
>> -lpython3.7m
>>
> Ah, thank you, that makes sense.
> 
> I have now built the packages for python 3.7 as well, from the same
> source package. Your idea worked great :)
> 
> The new ones are available at the same place as before:
> https://www.hamishmb.com/files/cygwin-temp/
> 
> All seems to be working okay for me, but there are some notes/questions
> I have:
> 
> - I get errors from python3.cygclass at the start of every build saying
> it can't find "python3-config" - looks to be a missing
> symlink/misconfigured cygclass script?
> 
> - On 32-bit Cygwin, stripping the debug symbols with objdump.exe from
> the libraries takes an extremely long time - I reckon 3-4 times slower
> than on 64-bit, at least. It's kind of prohibitively slow, does anyone
> know why?

the 32bit has less memory space so it take a bit of file swapping when 
the data are large


> - On 32-bit Cygwin, I tend to get fork errors when running the wxPython
> demo, but not on 64-bit (identical build options). Is this likely the
> 32-bit fork bug mentioned on Cygwin's home page, or a problem with my
> installation/setup?

run demo in build dir ?

1) remove any excessive libraries from your cygwin 32 bit install.
Recently for a similar reason I removed all libboost except the
last one, a good of previous version like libicuXX and similar
that accumulated in the years.

2) rebase the built dll's without storing permanently the addresses.
   Attached the script I am using for the scope


> 
> Hamish
> 
Regards
Marco

[-- Attachment #2: rebase-build.sh --]
[-- Type: text/plain, Size: 303 bytes --]

#!/bin/bash
if [ $# -ne 1 ]
then
    echo "rebase the dll under PN-PV/build"
    echo "Usage : " $0 "PN-PV"
    exit 1
fi

if [ ! -d $1/build ]
then
	echo $1"/build  missing, so quitting" 
	exit  1 
fi

echo "rebasing " $1"/dist" 

find $1/build/ -name "*.dll" > dll-list.txt
rebase -O -T dll-list.txt

Re: [ITP] python36-wx 4.0.7.post2

[Hamish McIntyre-Bhatty]

[-- Attachment #1.1.1: Type: text/plain, Size: 960 bytes --]

On 11/06/2020 17:41, Marco Atzeri via Cygwin-apps wrote:
> the 32bit has less memory space so it take a bit of file swapping when
> the data are large

Ah okay.

> run demo in build dir ?
>
> 1) remove any excessive libraries from your cygwin 32 bit install.
> Recently for a similar reason I removed all libboost except the
> last one, a good of previous version like libicuXX and similar
> that accumulated in the years.
>
> 2) rebase the built dll's without storing permanently the addresses.
>   Attached the script I am using for the scope
>
>
Turns out just running "rebaseall" worked for me. I don't get any
fork-related warnings/errors any more.

I'm running the demo from
https://extras.wxpython.org/wxPython4/extras/4.0.7.post2/ in a separate
directory with the packages I built installed.

Do I need to rebuild this for the new Python release? If not I think
this is all working now. Does it seem good to you?

Hamish


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ITP] python36-wx 4.0.7.post2

[Achim Gratz]

Hamish McIntyre-Bhatty via Cygwin-apps writes:
> Turns out just running "rebaseall" worked for me. I don't get any
> fork-related warnings/errors any more.

No it doesn't, it's a mere coincidence that it worked in your case.  You
shouldn't manually run rebaseall on Cygwin at all in fact, setup
perpetual postinstall actions take care of maintaing the rebase map.
If you ever have reason to believe that the rebase map needs a complete
rebuild, run "rebase-trigger full" and then run setup again.

Fitting newly built DLL into the rebase map is correctly done by an
ephemeral rebase like the script Marco has shown you does.


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [ITP] python36-wx 4.0.7.post2

[Hamish McIntyre-Bhatty]

[-- Attachment #1.1.1: Type: text/plain, Size: 1032 bytes --]

On 15/06/2020 19:26, Achim Gratz wrote:
> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>> Turns out just running "rebaseall" worked for me. I don't get any
>> fork-related warnings/errors any more.
> No it doesn't, it's a mere coincidence that it worked in your case.  You
> shouldn't manually run rebaseall on Cygwin at all in fact, setup
> perpetual postinstall actions take care of maintaing the rebase map.
> If you ever have reason to believe that the rebase map needs a complete
> rebuild, run "rebase-trigger full" and then run setup again.
>
> Fitting newly built DLL into the rebase map is correctly done by an
> ephemeral rebase like the script Marco has shown you does.

Good to know and thanks for the script Marco, seems to work well for me.

The only patch Fedora seems to be using is one to disable the bundled
SIP for building (which I think we need), so I believe this is now
finished. Do I need to rebuild against the new version of Python that
came out a few days ago for cygwin?

Hamish


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ITP] python36-wx 4.0.7.post2

[Marco Atzeri]

On 17.06.2020 10:41, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 15/06/2020 19:26, Achim Gratz wrote:
>> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>>> Turns out just running "rebaseall" worked for me. I don't get any
>>> fork-related warnings/errors any more.
>> No it doesn't, it's a mere coincidence that it worked in your case.  You
>> shouldn't manually run rebaseall on Cygwin at all in fact, setup
>> perpetual postinstall actions take care of maintaing the rebase map.
>> If you ever have reason to believe that the rebase map needs a complete
>> rebuild, run "rebase-trigger full" and then run setup again.
>>
>> Fitting newly built DLL into the rebase map is correctly done by an
>> ephemeral rebase like the script Marco has shown you does.
> 
> Good to know and thanks for the script Marco, seems to work well for me.
> 
> The only patch Fedora seems to be using is one to disable the bundled
> SIP for building (which I think we need), so I believe this is now
> finished. Do I need to rebuild against the new version of Python that
> came out a few days ago for cygwin?
> 
> Hamish
> 

If still work NO. If don't, we need to understand why as they should be
binary compatible.

Re: [ITP] python36-wx 4.0.7.post2

[Hamish McIntyre-Bhatty]

[-- Attachment #1.1.1: Type: text/plain, Size: 1358 bytes --]

On 17/06/2020 20:24, Marco Atzeri via Cygwin-apps wrote:
> On 17.06.2020 10:41, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> On 15/06/2020 19:26, Achim Gratz wrote:
>>> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>>>> Turns out just running "rebaseall" worked for me. I don't get any
>>>> fork-related warnings/errors any more.
>>> No it doesn't, it's a mere coincidence that it worked in your case. 
>>> You
>>> shouldn't manually run rebaseall on Cygwin at all in fact, setup
>>> perpetual postinstall actions take care of maintaing the rebase map.
>>> If you ever have reason to believe that the rebase map needs a complete
>>> rebuild, run "rebase-trigger full" and then run setup again.
>>>
>>> Fitting newly built DLL into the rebase map is correctly done by an
>>> ephemeral rebase like the script Marco has shown you does.
>>
>> Good to know and thanks for the script Marco, seems to work well for me.
>>
>> The only patch Fedora seems to be using is one to disable the bundled
>> SIP for building (which I think we need), so I believe this is now
>> finished. Do I need to rebuild against the new version of Python that
>> came out a few days ago for cygwin?
>>
>> Hamish
>>
>
> If still work NO. If don't, we need to understand why as they should be
> binary compatible.

Still seems to work fine.

Hamish


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ITP] python36-wx 4.0.7.post2

[Hamish McIntyre-Bhatty]

[-- Attachment #1.1.1: Type: text/plain, Size: 1505 bytes --]

On 17/06/2020 22:23, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 17/06/2020 20:24, Marco Atzeri via Cygwin-apps wrote:
>> On 17.06.2020 10:41, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>>> On 15/06/2020 19:26, Achim Gratz wrote:
>>>> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>>>>> Turns out just running "rebaseall" worked for me. I don't get any
>>>>> fork-related warnings/errors any more.
>>>> No it doesn't, it's a mere coincidence that it worked in your case. 
>>>> You
>>>> shouldn't manually run rebaseall on Cygwin at all in fact, setup
>>>> perpetual postinstall actions take care of maintaing the rebase map.
>>>> If you ever have reason to believe that the rebase map needs a complete
>>>> rebuild, run "rebase-trigger full" and then run setup again.
>>>>
>>>> Fitting newly built DLL into the rebase map is correctly done by an
>>>> ephemeral rebase like the script Marco has shown you does.
>>> Good to know and thanks for the script Marco, seems to work well for me.
>>>
>>> The only patch Fedora seems to be using is one to disable the bundled
>>> SIP for building (which I think we need), so I believe this is now
>>> finished. Do I need to rebuild against the new version of Python that
>>> came out a few days ago for cygwin?
>>>
>>> Hamish
>>>
>> If still work NO. If don't, we need to understand why as they should be
>> binary compatible.

Still works with the build from before, just double-checked.

Am I good to go now?

Hamish


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ITP] python36-wx 4.0.7.post2

[Marco Atzeri]

On 18.06.2020 10:20, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 17/06/2020 22:23, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> On 17/06/2020 20:24, Marco Atzeri via Cygwin-apps wrote:
>>> On 17.06.2020 10:41, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>>>> On 15/06/2020 19:26, Achim Gratz wrote:
>>>>> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>>>>>> Turns out just running "rebaseall" worked for me. I don't get any
>>>>>> fork-related warnings/errors any more.
>>>>> No it doesn't, it's a mere coincidence that it worked in your case.
>>>>> You
>>>>> shouldn't manually run rebaseall on Cygwin at all in fact, setup
>>>>> perpetual postinstall actions take care of maintaing the rebase map.
>>>>> If you ever have reason to believe that the rebase map needs a complete
>>>>> rebuild, run "rebase-trigger full" and then run setup again.
>>>>>
>>>>> Fitting newly built DLL into the rebase map is correctly done by an
>>>>> ephemeral rebase like the script Marco has shown you does.
>>>> Good to know and thanks for the script Marco, seems to work well for me.
>>>>
>>>> The only patch Fedora seems to be using is one to disable the bundled
>>>> SIP for building (which I think we need), so I believe this is now
>>>> finished. Do I need to rebuild against the new version of Python that
>>>> came out a few days ago for cygwin?
>>>>
>>>> Hamish
>>>>
>>> If still work NO. If don't, we need to understand why as they should be
>>> binary compatible.
> 
> Still works with the build from before, just double-checked.
> 
> Am I good to go now?
> 
> Hamish
> 

sure.

https://cygwin.com/packaging/key.html#sshkey

Re: [ITP] python36-wx 4.0.7.post2

[Hamish McIntyre-Bhatty]

[-- Attachment #1.1.1: Type: text/plain, Size: 236 bytes --]

> sure.
>
> https://cygwin.com/packaging/key.html#sshkey

SSH key is already all set-up (I took maintainership of python-wx before).

Can't upload my test packages yet though because they aren't in the
package list.

Hamish


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ITP] python36-wx 4.0.7.post2

[Jon Turney]

On 18/06/2020 12:31, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> sure.
>>
>> https://cygwin.com/packaging/key.html#sshkey
> 
> SSH key is already all set-up (I took maintainership of python-wx before).
> 
> Can't upload my test packages yet though because they aren't in the
> package list.

Done.

Perhaps 'python-wx' should be renamed to 'python2-wx', at some point in 
the future, to make it clear what it contains?

Re: [ITP] python36-wx 4.0.7.post2

[Hamish McIntyre-Bhatty]

[-- Attachment #1.1.1: Type: text/plain, Size: 301 bytes --]

On 18/06/2020 15:08, Jon Turney wrote:
> Done.
>
> Perhaps 'python-wx' should be renamed to 'python2-wx', at some point
> in the future, to make it clear what it contains?

Thanks. Packages are uploaded now.

Yes, I agree, but I'm not sure how to handle that transition smoothly.

Hamish


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]