Re: [ITP] python36-wx 4.0.7.post2
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 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python36-wx 4.0.7.post2
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
> 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 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python36-wx 4.0.7.post2
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
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 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python36-wx 4.0.7.post2
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 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python36-wx 4.0.7.post2
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
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 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python36-wx 4.0.7.post2
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
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 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python36-wx 4.0.7.post2
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 #!/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
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 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python36-wx 4.0.7.post2
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
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 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python36-wx 4.0.7.post2
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
[ITP] python36-wx 4.0.7.post2
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 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature