Re: [ITP] python36-wx 4.0.7.post2

2020-06-18 Thread Hamish McIntyre-Bhatty via Cygwin-apps
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

2020-06-18 Thread 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

2020-06-18 Thread Hamish McIntyre-Bhatty via Cygwin-apps
> 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

2020-06-18 Thread Marco Atzeri via Cygwin-apps

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

2020-06-18 Thread Hamish McIntyre-Bhatty via Cygwin-apps
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

2020-06-17 Thread Hamish McIntyre-Bhatty via Cygwin-apps
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

2020-06-17 Thread Marco Atzeri via Cygwin-apps

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

2020-06-17 Thread Hamish McIntyre-Bhatty via Cygwin-apps
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

2020-06-15 Thread 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

2020-06-15 Thread Hamish McIntyre-Bhatty via Cygwin-apps
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

2020-06-11 Thread Marco Atzeri via Cygwin-apps

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

2020-06-11 Thread Hamish McIntyre-Bhatty via Cygwin-apps
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

2020-06-11 Thread Marco Atzeri via Cygwin-apps

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

2020-06-10 Thread Hamish McIntyre-Bhatty via Cygwin-apps
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

2020-06-09 Thread Marco Atzeri via Cygwin-apps

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

2020-06-09 Thread Hamish McIntyre-Bhatty via Cygwin-apps
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