Re: python2 removal
On 19/01/2024 18:23, Hamish McIntyre-Bhatty via Cygwin-apps wrote: On 18/01/2024 19:40, Jon Turney wrote: On 18/01/2024 19:31, Jon Turney via Cygwin-apps wrote: [...] python-wx-devel wxWidgets C++ application framework (Python bindings) [...] python-wx-devel is the last remnant of python2 bindings for wx (the python3 binding comes from a different, irregularly named source package python3-wx), so can also be removed. Cc:ing Hamish as a note that if/when python3-wx is updated, we should see if it's now possible to rename the source package to python-wx. Unrelated question: Do you mind if I vault the (orphaned, last updated circa 2016) wxWidgets 2.8 packages, which I assume are of very limited use to anybody... Okay, I'd be happy to try renaming the package to python-wx the next time I update python3-wx. I'm indifferent to the wxWidgets 2.8 packages, I've never used them and wxWIdgets 3.0 is also pretty compatible with 2.8 from my understanding, so the 2.8 packages aren't needed. Hamish I realise I forgot to ask, but how could I go about renaming python3-wx to python-wx when I update? I also maintained python-wx, so I shouldn't need any extra permissions I don't think. Best, Hamish
Re: python2 removal
On 18/01/2024 19:40, Jon Turney wrote: On 18/01/2024 19:31, Jon Turney via Cygwin-apps wrote: [...] python-wx-devel wxWidgets C++ application framework (Python bindings) [...] python-wx-devel is the last remnant of python2 bindings for wx (the python3 binding comes from a different, irregularly named source package python3-wx), so can also be removed. Cc:ing Hamish as a note that if/when python3-wx is updated, we should see if it's now possible to rename the source package to python-wx. Unrelated question: Do you mind if I vault the (orphaned, last updated circa 2016) wxWidgets 2.8 packages, which I assume are of very limited use to anybody... Okay, I'd be happy to try renaming the package to python-wx the next time I update python3-wx. I'm indifferent to the wxWidgets 2.8 packages, I've never used them and wxWIdgets 3.0 is also pretty compatible with 2.8 from my understanding, so the 2.8 packages aren't needed. Hamish
Marco Atzeri: Repo for your cygwin scripts has been merged
Hi Marco, Just emailing to let you know that the scripts you sent me before have been merged into a collection of more general Cygwin scripts at https://github.com/michaelgchu/Cygwin_Specific_Repo, under the Marco_Atzeri subfolder. Licensing has been made clear and everything, but let me know if you want to request any changes. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Keeping an older version of a package in the repos
On 19/01/2021 18:36, Marco Atzeri via Cygwin-apps wrote: > On 19.01.2021 19:11, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> On 18/01/2021 18:39, Marco Atzeri via Cygwin-apps wrote: >>> On 18.01.2021 18:57, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >>>> Hi all, >>>> >>>> In the (hopefully!) near future I plan to package python3-wx (aka >>>> wxPython) version 4.1.1. This is a backwards-incompatible change with >>>> wxPython 4.0.x, so I was wondering if there was a way to retain >>>> python3-wx 4.0.x and its binary packages in the repos after I do this >>>> update? >>>> >>>> Hamish >>>> >>> >>> look at the several guile packages for ideas >>> >>> $ cygcheck -cd | grep "^guile" >>> ... >>> guile1.8 1.8.8-3 >>> guile2.0 2.0.14-3 >>> guile2.2 2.2.7-1 >>> guile3.0 3.0.5-1 >>> >>> >>> check how to guarantee that the names are different and they >>> do not collide as content >>> >>> Does any package depends on python3X-wx ? >>> I do not see a demanding problem: >>> >>> $ cygcheck-dep -S -q -n python36-wx >>> python36-wx: is needed for ( ) >>> >>> >>> Regards >>> Marco >> >> Yeah I guess I could name the new binary packages something like >> python36-wx31 etc, but that might be a bit ugly. I'm not sure if Cygwin >> has a convention for that. >> >> I was more thinking about any 3rd party applications that may depend on >> it, but perhaps that's not too much of a concern. >> >> Hamish >> > > > I was referring to collision of file names > > $ cygcheck -l python38-wx |grep bin > /usr/bin/helpviewer-py38 > /usr/bin/img2png-py38 > /usr/bin/img2py-py38 > /usr/bin/img2xpm-py38 > /usr/bin/pycrust-py38 > /usr/bin/pyshell-py38 > /usr/bin/pyslices-py38 > /usr/bin/pyslicesshell-py38 > /usr/bin/pywxrc-py38 > /usr/bin/wxdemo-py38 > /usr/bin/wxdocs-py38 > /usr/bin/wxget-py38 > Ah yes, that would be a problem. This endeavour is probably not worth it then with no internal dependencies. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Keeping an older version of a package in the repos
On 18/01/2021 18:39, Marco Atzeri via Cygwin-apps wrote: > On 18.01.2021 18:57, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> Hi all, >> >> In the (hopefully!) near future I plan to package python3-wx (aka >> wxPython) version 4.1.1. This is a backwards-incompatible change with >> wxPython 4.0.x, so I was wondering if there was a way to retain >> python3-wx 4.0.x and its binary packages in the repos after I do this >> update? >> >> Hamish >> > > look at the several guile packages for ideas > > $ cygcheck -cd | grep "^guile" > ... > guile1.8 1.8.8-3 > guile2.0 2.0.14-3 > guile2.2 2.2.7-1 > guile3.0 3.0.5-1 > > > check how to guarantee that the names are different and they > do not collide as content > > Does any package depends on python3X-wx ? > I do not see a demanding problem: > > $ cygcheck-dep -S -q -n python36-wx > python36-wx: is needed for ( ) > > > Regards > Marco Yeah I guess I could name the new binary packages something like python36-wx31 etc, but that might be a bit ugly. I'm not sure if Cygwin has a convention for that. I was more thinking about any 3rd party applications that may depend on it, but perhaps that's not too much of a concern. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Keeping an older version of a package in the repos
Hi all, In the (hopefully!) near future I plan to package python3-wx (aka wxPython) version 4.1.1. This is a backwards-incompatible change with wxPython 4.0.x, so I was wondering if there was a way to retain python3-wx 4.0.x and its binary packages in the repos after I do this update? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 22/11/2020 09:43, Achim Gratz wrote: > Brian Inglis writes: >> Push your cygport to the git-cygwin-packages playground repo (see Jon >> Turney's recent reply to me in this list) which all maintainers can >> push to, as you don't yet own the git-cygwin-packages wxWidgets repo; >> check the CI jobs.cgi log contents, and fix any issues. > Fun fact: that will certainly run into the build timeout that is > currently set at 1 hour. Jon, do you think it'd be possible to have > another SCALLYWAG variable to extend that limit for the packages that > need it? > > > Regards, > Achim. I can confirm now that I've got all the build requirements correct, that it does indeed timeout. Since this message (November 2020), is there now support for adjusting the timeout for individual packages? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Optimising cygwin fork performance
On 16/12/2020 20:37, Brian Inglis wrote:
> On 2020-12-16 10:36, Marco Atzeri via Cygwin-apps wrote:
>> On 16.12.2020 13:13, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>>> So I know it's been mentioned a lot that fork is slow on Cygwin, but
>>> compared to other people's machines, eg when building, it seems way
>>> slower for me.
>>>
>>> First I'd like to know if there's a good way to measure this that
>>> anyone
>>> has found, because I'm not sure how to measure it. If I print multiple
>>> lines with echo in a script, I can see it printing maybe 2-3 a second -
>>> it's very slow.
>>>
>>> I think this might be because I'm using a Virtual Machine with
>>> VirtualBox, and QEMU/KVM might be quicker. I'm using Avira Antivurus,
>>> with exceptions for the cygwin install folders (C:\cygwin64,
>>> C:\cygwin).
>>>
>>> It might be nice if we could so some comparisons so I can figure out
>>> what's wrong.
>
> Running strace on your forking executable should give you accurate
> numbers in the output, with some work to extract the relevant values.
>
>> Same AV here, W10 64bit (no VM), 2 year old Laptop
>>
>> model name : Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
>> 4 cores
>>
>> https://github.com/mondalaci/fork-benchmark
>> it seems there is a aging effect
>>
>> $ ./fork-benchmark.exe 1000
>> Forked, executed and destroyed 1000 processes in 39.928576 seconds.
>>
>> $ ./fork-benchmark.exe 1000
>> Forked, executed and destroyed 1000 processes in 42.701295 seconds.
>>
>> $ ./fork-benchmark.exe 1000
>> Forked, executed and destroyed 1000 processes in 49.890909 seconds.
>>
>> $ ./fork-benchmark.exe 1000
>> Forked, executed and destroyed 1000 processes in 61.657031 seconds.
>
> It's all part of your current process tree.
> Running cygserver may help this with appropriate process settings:
>
> $ grep -C1 'kern\.srv\..*_.*' /etc/cygserver.conf
>
> # kern.srv.cleanup_threads: No. of cygserver threads used for cleanup
> tasks.
> # Default: 2, Min: 1, Max: 16, command line option -c, --cleanup-threads
> #kern.srv.cleanup_threads 2
> kern.srv.cleanup_threads 16
>
> # kern.srv.request_threads: No. of cygserver threads used to serve
> # application requests.
> # Default: 10, Min: 1, Max: 310, command line option -r,
> --request-threads
> #kern.srv.request_threads 10
> kern.srv.request_threads 310
>
> # kern.srv.process_cache_size: No. of concurrent processes which can
> be handled
> # by Cygserver concurrently.
> # Default: 62, Min: 1, Max: 310, command line option -p, --process-cache
> #kern.srv.process_cache_size 62
> kern.srv.process_cache_size 310
>
> $ ./fork-benchmark 1000
> Forked, executed and destroyed 1000 processes in 33.397727 seconds.
> $ ./fork-benchmark 1000
> Forked, executed and destroyed 1000 processes in 34.70389 seconds.
> $ ./fork-benchmark 1000
> Forked, executed and destroyed 1000 processes in 34.186709 seconds.
> $ ./fork-benchmark 1000
> Forked, executed and destroyed 1000 processes in 33.65649 seconds.
> $ sed -En '/^model name|^cpu MHz/p;/MHz/q' /proc/cpuinfo
> model name : AMD A10-9700 RADEON R7, 10 COMPUTE CORES 4C+6G
> cpu MHz : 3500.000
>
> $ strace -o fork-benchmark.strace ./fork-benchmark 10
> $ egrep '^--- Process [0-9]+ (crea|\(pid: [0-9]+\) exi)ted|dwProcessId
> [0-9]+|ExitProcess n 0x' fork-benchmark.strace > fork-benchmark.log
> $ awk '/ [0-9]+! pinfo::exit: /{t+=$2};END{print t/1"ms"}'
> fork-benchmark.log
> 34.1855ms
>
> Faster CPUs, faster memory, bigger caches, SSD drive may help.
Just running in KVM seems to have helped me.
My times are more like 13 seconds for 1000 forks now. There appears to
be drop-off, but after a big package build and some idling, it then gets
back down to 13 seconds.
Is there a way for me to check that the cygserver options are working?
Either way, my package builds are about twice as quick as they were
before now, possibly just from a reinstall and using KVM.
Hamish
0x87B761FE07F548D6.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Optimising cygwin fork performance
Hi, So I know it's been mentioned a lot that fork is slow on Cygwin, but compared to other people's machines, eg when building, it seems way slower for me. First I'd like to know if there's a good way to measure this that anyone has found, because I'm not sure how to measure it. If I print multiple lines with echo in a script, I can see it printing maybe 2-3 a second - it's very slow. I think this might be because I'm using a Virtual Machine with VirtualBox, and QEMU/KVM might be quicker. I'm using Avira Antivurus, with exceptions for the cygwin install folders (C:\cygwin64, C:\cygwin). It might be nice if we could so some comparisons so I can figure out what's wrong. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 14/12/2020 20:21, Marco Atzeri via Cygwin-apps wrote: > On 14.12.2020 10:46, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> On 13/12/2020 20:12, Marco Atzeri via Cygwin-apps wrote: >>> On 09.12.2020 21:55, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >>>> On 25/11/2020 10:02, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > >>>> >>> >>> it builds and packages fine. >>> >>> but I tried to build the tests on gtk3/tests >>> >>> make test.exe >>> >>> and it fails >>> >>> Regards >>> Marco >> >> Hi Marco, >> >> Yes, it does seem that the unit tests do not work correctly right now. I >> thought I had put a note about that in the emails and/or cygport file - >> my bad. >> >> The tests compile if you remove all references to the fswatcher >> component, but the results even when doing this are: >> >> - Cmdline tests segfault after a while. >> >> - GUI tests work, but only after installing wxWidgets tin the Cygwin >> installation. Many GTK3 tests fail, but I tested equivalent >> functionality manually and it seemed okay. >> >> So instead of using the automated tests, I built the samples under >> gtk2/samples and gtk3/samples and tested them manually. I've also built >> a test version of wxPython against this new build of wxWidgets and used >> the wxPython demo for even more manual testing. All seemed okay. >> >> I plan to build wxWidgets 3.1.x soon, which is still being updated, so I >> figure time is better spent trying to fix the unit tests for that >> release, and manual tested is hopefully good enough for the moment? >> >> Hamish >> > > ok, thanks > > changed maintainer Thanks! Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 13/12/2020 20:12, Marco Atzeri via Cygwin-apps wrote: > On 09.12.2020 21:55, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> On 25/11/2020 10:02, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >>>> Okay, so attached is my latest cygport file. I'm still building for >>>> 32-bit, so I'll upload and link to the new packages tomorrow. >>>> >>>> Changes: >>>> >>>> - Split BUILD_REQUIRES across two lines for definitely build time and >>>> probably only runtime deps. >>>> >>>> - Use system regex library explicitly. >>>> >>>> - Removed obsolete --without-gnomeprint option. >>>> >>>> - Use gnomevfs (old bug no longer seems to apply). >>>> >>>> I tried using the STL, but it results in libraries that don't work as: >>>> >>>> #1: the wxwidgets demos either segfault instantly or just exit >>>> instantly. >>>> >>>> #2: wxpython no longer works and returns the No such process error >>>> above. >>>> >>>> Hamish >>> Okay, cygport file attached again and the new packages can be had from >>> https://www.hamishmb.com/files/cygwin-temp/ as before. >>> >>> Hamish >> >> *bump* >> Would be good to get this verified so I can get on to other things for >> Cygwin. >> >> Hamish >> > > it builds and packages fine. > > but I tried to build the tests on gtk3/tests > > make test.exe > > and it fails > > Regards > Marco Hi Marco, Yes, it does seem that the unit tests do not work correctly right now. I thought I had put a note about that in the emails and/or cygport file - my bad. The tests compile if you remove all references to the fswatcher component, but the results even when doing this are: - Cmdline tests segfault after a while. - GUI tests work, but only after installing wxWidgets tin the Cygwin installation. Many GTK3 tests fail, but I tested equivalent functionality manually and it seemed okay. So instead of using the automated tests, I built the samples under gtk2/samples and gtk3/samples and tested them manually. I've also built a test version of wxPython against this new build of wxWidgets and used the wxPython demo for even more manual testing. All seemed okay. I plan to build wxWidgets 3.1.x soon, which is still being updated, so I figure time is better spent trying to fix the unit tests for that release, and manual tested is hopefully good enough for the moment? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 25/11/2020 10:02, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> Okay, so attached is my latest cygport file. I'm still building for >> 32-bit, so I'll upload and link to the new packages tomorrow. >> >> Changes: >> >> - Split BUILD_REQUIRES across two lines for definitely build time and >> probably only runtime deps. >> >> - Use system regex library explicitly. >> >> - Removed obsolete --without-gnomeprint option. >> >> - Use gnomevfs (old bug no longer seems to apply). >> >> I tried using the STL, but it results in libraries that don't work as: >> >> #1: the wxwidgets demos either segfault instantly or just exit instantly. >> >> #2: wxpython no longer works and returns the No such process error above. >> >> Hamish > Okay, cygport file attached again and the new packages can be had from > https://www.hamishmb.com/files/cygwin-temp/ as before. > > Hamish *bump* Would be good to get this verified so I can get on to other things for Cygwin. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] wget2
On 27/11/2020 18:28, Brian Inglis wrote: > On 2020-11-27 10:57, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> On 24/11/2020 21:06, Brian Inglis wrote: >>> On 2020-07-08 14:05, Brian Inglis wrote: >>>> wget2 is the successor of wget supplying a shared library API like >>>> curl to >>>> build a modern, fast, multi-threaded, parallel downloader using >>>> HTTP/2, HTTP >>>> compression and If-Modified-Since headers; see: >>>> https://gitlab.com/gnuwget/wget2 >>>> It is currently available on Arch, Debian/Ubuntu, openSUSE, >>>> Slackware; see: >>> >>> https://repology.org/project/wget2/versions >>> >>> Thanks for help getting here and also the upstream folks! >>> >>> Please review wget2 repackaged into subpackages available under: >>> >>> https://drive.google.com/drive/folders/1VVuC14KuB6uShm4FQL9BuXH0hpLYnIcJ?usp=sharing >>> >>> >>> >>> Appveyor CI playground repo wget2 jobs: >>> >>> https://cygwin.com/cgi-bin2/jobs.cgi?id=1308 >>> >>> I have been dogfooding wget2 instead of wget in commands and cron jobs >>> and it appears considerably faster, but does not support FTP or other >>> protocols supported by curl or wget, and does not support wget >>> --retr-symlinks=no option which retrieves symlink contents verbatim >>> for analysis with readlink e.g. wget ...-latest... and see if it >>> points to the previous or a newer version. >>> >>> For more compatibility info see: >>> >>> https://gitlab.com/gnuwget/wget2/-/wikis/home >> >> I had a quick go on 32-bit Cygwin (figuring most people might try >> 64-bit), and it seems to work fine and be quite quick. I haven't >> compiled the package but I'll find time soon hopefully - it's small so I >> guess it doesn't take long. > > Thanks - nearly 15min on Appveyor with all the library, devel, and > debuginfo bits involved. Okay, I get the following warnings: configure: WARNING: unrecognized options: --without-lzip configure: WARNING: *** No working backend for plugin support found It also reports that there is no HSTS support. I also get a bunch of warnings (for both 32-bit and 64-bit Cygwin) like: libtool: warning: '-no-install' is ignored for x86_64-pc-cygwin libtool: warning: assuming '-no-fast-install' instead libtool: warning: '-no-install' is ignored for x86_64-pc-cygwin libtool: warning: '-no-install' is ignored for x86_64-pc-cygwin libtool: warning: '-no-install' is ignored for x86_64-pc-cygwin libtool: warning: assuming '-no-fast-install' instead libtool: warning: assuming '-no-fast-install' instead libtool: warning: assuming '-no-fast-install' instead At the end of compilation. I guess the first warning can be dealt with by removing the (obsolete?) option, but I'm not sure about the others/if they need fixing. I think HSTS might be useful to have though. Finally, I also get a source patch for src/version-text.h even though I didn't patch it - maybe there needs to be an exception for that file? All the steps including installing, packaging, and running unit tests work for me on both 32-bit and 64-bit Cygwin, so it's just the warnings that I have concerns about really. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] wget2
On 24/11/2020 21:06, Brian Inglis wrote: > On 2020-07-08 14:05, Brian Inglis wrote: >> wget2 is the successor of wget supplying a shared library API like >> curl to >> build a modern, fast, multi-threaded, parallel downloader using >> HTTP/2, HTTP >> compression and If-Modified-Since headers; see: >> https://gitlab.com/gnuwget/wget2 >> It is currently available on Arch, Debian/Ubuntu, openSUSE, >> Slackware; see: > > https://repology.org/project/wget2/versions > > Thanks for help getting here and also the upstream folks! > > Please review wget2 repackaged into subpackages available under: > > https://drive.google.com/drive/folders/1VVuC14KuB6uShm4FQL9BuXH0hpLYnIcJ?usp=sharing > > > Appveyor CI playground repo wget2 jobs: > > https://cygwin.com/cgi-bin2/jobs.cgi?id=1308 > > I have been dogfooding wget2 instead of wget in commands and cron jobs > and it appears considerably faster, but does not support FTP or other > protocols supported by curl or wget, and does not support wget > --retr-symlinks=no option which retrieves symlink contents verbatim > for analysis with readlink e.g. wget ...-latest... and see if it > points to the previous or a newer version. > > For more compatibility info see: > > https://gitlab.com/gnuwget/wget2/-/wikis/home I had a quick go on 32-bit Cygwin (figuring most people might try 64-bit), and it seems to work fine and be quite quick. I haven't compiled the package but I'll find time soon hopefully - it's small so I guess it doesn't take long. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
> Okay, so attached is my latest cygport file. I'm still building for
> 32-bit, so I'll upload and link to the new packages tomorrow.
>
> Changes:
>
> - Split BUILD_REQUIRES across two lines for definitely build time and
> probably only runtime deps.
>
> - Use system regex library explicitly.
>
> - Removed obsolete --without-gnomeprint option.
>
> - Use gnomevfs (old bug no longer seems to apply).
>
> I tried using the STL, but it results in libraries that don't work as:
>
> #1: the wxwidgets demos either segfault instantly or just exit instantly.
>
> #2: wxpython no longer works and returns the No such process error above.
>
> Hamish
Okay, cygport file attached again and the new packages can be had from
https://www.hamishmb.com/files/cygwin-temp/ as before.
Hamish
NAME="wxWidgets3.0"
VERSION=3.0.5.1
RELEASE=1
CATEGORY="Libs"
SUMMARY="wxWidgets C++ application framework"
DESCRIPTION="wxWidgets is a set of libraries that allows C++ applications to
compile and run on several different types of computer, with minimal source
code changes. There is one library per supported GUI. As well as providing a
common API for GUI functionality, it provides functionality for accessing some
commonly-used operating system facilities, from copying and deleting files to
socket and thread support."
HOMEPAGE="http://wxwidgets.org/;
SRC_URI="https://github.com/wxWidgets/wxWidgets/releases/download/v${VERSION}/wxWidgets-${VERSION}.tar.bz2;
SRC_DIR="wxWidgets-${VERSION}"
#Just for building:
BUILD_REQUIRES="make cppunit graphviz autoconf pkg-config gcc-core gcc-g++
doxygen libX11-devel libgtk2.0-devel libgtk3-devel libwebkitgtk1.0-devel
libwebkitgtk3.0-devel libpng-devel libjpeg-devel libexpat-devel libiconv-devel
libmspack-devel libnotify-devel libtiff-devel libXpm-devel libcogl-devel
libEGL-devel libGL-devel libGLU-devel libSDL2-devel libSDL2_image-devel
libSDL2_mixer-devel libSDL2_net-devel libSDL2_ttf-devel zlib-devel"
#For running unit tests/runtime (currently disabled because they don't work).
#Still needed for manual testing though, so leaving in here.
BUILD_REQUIRES="$BUILD_REQUIRES xclock libwebkitgtk1.0_0 libwebkitgtk3.0_0
libpng16 libjpeg8 libexpat1 libiconv libiconv2 libmspack0 libnotify libnotify4
libtiff6 libXpm4 libcogl20 libEGL1 libGL1 libGLU1 libSDL2_2.0_0
libSDL2_image2.0_0 libSDL2_mixer2.0_0 libSDL2_net2.0_0 libSDL2_ttf2.0_0 zlib"
PATCH_URI="
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/wxGTK3-3.0.3-abicheck.patch
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/fix-filename-test.patch
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/fix-vararg-test.patch
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/force-x11-for-wxgl.patch
wxGTK3-3.0.5.1-collision.patch
3.0.2-cygwin-auto-import.patch
3.0.2-cygwin-dlopen.patch
3.0.2-cygwin-unix.patch
3.0.2-cygwin-gcc5.patch
3.0.3-autoreconf.patch
3.0.3-cygwin-ftm.patch
0007-Fix-video-sink-fallback-in-wxMediaCtrl-when-xvimages.patch
"
slot=${PV_MAJ_MIN}
PKG_NAMES="libwx_baseu3.0_0 libwx_baseu3.0-devel ${NAME}-doc
libwx_gtk2u3.0_0 libwx_gtk2u3.0-devel
libwx_gtk3u3.0_0 libwx_gtk3u3.0-devel"
libwx_baseu3_0_0_SUMMARY="${SUMMARY} (base unicode runtime)"
libwx_baseu3_0_0_CONTENTS="
--exclude=html
usr/bin/cygwx_baseu*-3.0-0.dll
usr/share/doc/${NAME}/
usr/share/locale/*/LC_MESSAGES/wxstd30.mo
"
libwx_baseu3_0_devel_REQUIRES="libexpat-devel libiconv-devel zlib-devel"
libwx_baseu3_0_devel_CONTENTS="
usr/bin/wxrc-3.0.exe
usr/include/wx-3.0/
usr/lib/libwx_baseu*-3.0.dll.a
usr/lib/wx/config/base-unicode-3.0
usr/lib/wx/include/base-unicode-3.0/
usr/share/aclocal/wxwin-3.0.m4
usr/share/bakefile/presets/wx30*
"
libwx_gtk2u3_0_0_SUMMARY="${SUMMARY} (GTK+2 unicode runtime)"
libwx_gtk2u3_0_0_CONTENTS="usr/bin/cygwx_gtk2u*-3.0-0.dll"
libwx_gtk2u3_0_devel_SUMMARY="${SUMMARY} (development)"
libwx_gtk2u3_0_devel_REQUIRES="libGL-devel libglib2.0-devel libgtk2.0-devel
libX11-devel"
libwx_gtk2u3_0_devel_CONTENTS="
usr/lib/libwx_gtk2u*-3.0.dll.a
usr/lib/wx/config/gtk2-unicode-3.0
usr/lib/wx/include/gtk2-unicode-3.0/
"
libwx_gtk3u3_0_0_SUMMARY="${SUMMARY} (GTK+3 unicode runtime)"
libwx_gtk3u3_0_0_CONTENTS="usr/bin/cygwx_gtk3u*-3.0-0.dll"
libwx_gtk3u3_0_devel_SUMMARY="${SUMMARY} (development)"
libwx_gtk3u3_0_devel_REQUIRES="libGL-devel libglib2.0-devel libgtk2.0-devel
libX11-devel"
libwx_gtk3u3_0_devel_CONTENTS="
usr/bin/wx-config-3.0
usr/lib/libwx_gtk3u*-3.0.dll.a
usr/lib/wx/config/gtk3-unicode-3.0
usr/lib/wx/include/gtk3-unicode-3.0/
"
wxWidgets3_0_doc_CATEGORY="Doc"
wxWidgets3_0_doc_SUMMARY="${SUMMARY} (documentation)"
wxWidgets3_0_doc_OBSOLETES="libwx_gtk2u3.0-doc"
wxWidgets3_0_doc_CONTENTS="usr/share/doc/${NAME}/html/"
DIFF_EXCLUDES="doxygen.log out"
CFLAGS+=" -fno-strict-aliasing"
Re: [ITA] wxWidgets3.0
On 24/11/2020 10:43, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> Ignore that message, I made a silly mistake.
>
> On 24/11/2020 10:15, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> Well, something's gone wrong with my Cygwin install I think, because
>> even with previously working cygport recipes, I can no longer produce a
>> working build.
>>
>> The samples tend to either exit immediately or segfault, and trying to
>> use wxPython yields:
>>
>> "
>>
>> Traceback (most recent call last):
>>
>> File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
>>
>> "__main__", mod_spec)
>>
>> File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
>>
>> exec(code, run_globals)
>>
>> File "./demo/__main__.py", line 5, in
>>
>> import Main
>>
>> File "./demo/Main.py", line 61, in
>>
>> import wx
>>
>> File "/usr/lib/python3.6/site-packages/wx/__init__.py", line 17, in
>>
>>
>> from wx.core import *
>>
>> File "/usr/lib/python3.6/site-packages/wx/core.py", line 12, in
>>
>> from ._core import *
>>
>> ImportError: No such process
>>
>>
>> "
>>
>> I did try a rebase as well, but it doesn't seem to help. This looks like
>> an issue I had right when I first tried to compile wxPython, and it
>> mysteriously went away at some point. Does anyone know why this might be
>> happening? Maybe I need to reinstall Cygwin, but I haven't done anything
>> with it between the successful build of wxWidgets and the failed ones,
>> so it's not making a whole lot of sense.
>>
>> Hamish
Okay, so attached is my latest cygport file. I'm still building for
32-bit, so I'll upload and link to the new packages tomorrow.
Changes:
- Split BUILD_REQUIRES across two lines for definitely build time and
probably only runtime deps.
- Use system regex library explicitly.
- Removed obsolete --without-gnomeprint option.
- Use gnomevfs (old bug no longer seems to apply).
I tried using the STL, but it results in libraries that don't work as:
#1: the wxwidgets demos either segfault instantly or just exit instantly.
#2: wxpython no longer works and returns the No such process error above.
Hamish
NAME="wxWidgets3.0"
VERSION=3.0.5.1
RELEASE=1
CATEGORY="Libs"
SUMMARY="wxWidgets C++ application framework"
DESCRIPTION="wxWidgets is a set of libraries that allows C++ applications to
compile and run on several different types of computer, with minimal source
code changes. There is one library per supported GUI. As well as providing a
common API for GUI functionality, it provides functionality for accessing some
commonly-used operating system facilities, from copying and deleting files to
socket and thread support."
HOMEPAGE="http://wxwidgets.org/;
SRC_URI="https://github.com/wxWidgets/wxWidgets/releases/download/v${VERSION}/wxWidgets-${VERSION}.tar.bz2;
SRC_DIR="wxWidgets-${VERSION}"
#Just for building:
BUILD_REQUIRES="make cppunit graphviz autoconf pkg-config gcc-core gcc-g++
doxygen libX11-devel libgtk2.0-devel libgtk3-devel libwebkitgtk1.0-devel
libwebkitgtk3.0-devel libpng-devel libjpeg-devel libexpat-devel libiconv-devel
libmspack-devel libnotify-devel libtiff-devel libXpm-devel libcogl-devel
libEGL-devel libGL-devel libGLU-devel libSDL2-devel libSDL2_image-devel
libSDL2_mixer-devel libSDL2_net-devel libSDL2_ttf-devel zlib-devel"
#For running unit tests/runtime (currently disabled because they don't work).
#Still needed for manual testing though, so leaving in here.
BUILD_REQUIRES="$BUILD_REQUIRES xclock libwebkitgtk1.0_0 libwebkitgtk3.0_0
libpng16 libjpeg8 libexpat1 libiconv libiconv2 libmspack0 libnotify libnotify4
libtiff6 libXpm4 libcogl20 libEGL1 libGL1 libGLU1 libSDL2_2.0_0
libSDL2_image2.0_0 libSDL2_mixer2.0_0 libSDL2_net2.0_0 libSDL2_ttf2.0_0 zlib"
PATCH_URI="
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/wxGTK3-3.0.3-abicheck.patch
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/fix-filename-test.patch
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/fix-vararg-test.patch
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/force-x11-for-wxgl.patch
wxGTK3-3.0.5.1-collision.patch
3.0.2-cygwin-auto-import.patch
3.0.2-cygwin-dlopen.patch
3.0.2-cygwin-unix.patch
3.0.2-cygwin-gcc5.patch
3.0.3-autoreconf.patch
3.0.3-cygwin-ftm.patch
0007-Fix-video-sink-fallback-in-wxMediaCtrl-when-xvimages.patch
"
slot=${PV_MAJ_MIN}
PKG_NAMES="libwx_baseu3.0_0 libwx_baseu3.0-devel ${NAME}-doc
Re: [ITA] wxWidgets3.0
Ignore that message, I made a silly mistake. On 24/11/2020 10:15, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > Well, something's gone wrong with my Cygwin install I think, because > even with previously working cygport recipes, I can no longer produce a > working build. > > The samples tend to either exit immediately or segfault, and trying to > use wxPython yields: > > " > > Traceback (most recent call last): > > File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main > > "__main__", mod_spec) > > File "/usr/lib/python3.6/runpy.py", line 85, in _run_code > > exec(code, run_globals) > > File "./demo/__main__.py", line 5, in > > import Main > > File "./demo/Main.py", line 61, in > > import wx > > File "/usr/lib/python3.6/site-packages/wx/__init__.py", line 17, in > > > from wx.core import * > > File "/usr/lib/python3.6/site-packages/wx/core.py", line 12, in > > from ._core import * > > ImportError: No such process > > > " > > I did try a rebase as well, but it doesn't seem to help. This looks like > an issue I had right when I first tried to compile wxPython, and it > mysteriously went away at some point. Does anyone know why this might be > happening? Maybe I need to reinstall Cygwin, but I haven't done anything > with it between the successful build of wxWidgets and the failed ones, > so it's not making a whole lot of sense. > > Hamish > 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
Well, something's gone wrong with my Cygwin install I think, because even with previously working cygport recipes, I can no longer produce a working build. The samples tend to either exit immediately or segfault, and trying to use wxPython yields: " Traceback (most recent call last): File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.6/runpy.py", line 85, in _run_code exec(code, run_globals) File "./demo/__main__.py", line 5, in import Main File "./demo/Main.py", line 61, in import wx File "/usr/lib/python3.6/site-packages/wx/__init__.py", line 17, in from wx.core import * File "/usr/lib/python3.6/site-packages/wx/core.py", line 12, in from ._core import * ImportError: No such process " I did try a rebase as well, but it doesn't seem to help. This looks like an issue I had right when I first tried to compile wxPython, and it mysteriously went away at some point. Does anyone know why this might be happening? Maybe I need to reinstall Cygwin, but I haven't done anything with it between the successful build of wxWidgets and the failed ones, so it's not making a whole lot of sense. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 23/11/2020 20:05, ASSI wrote: > Hamish McIntyre-Bhatty via Cygwin-apps writes: >> Okay, wow that is a LOT quicker. I haven't timed mine precisely buts >> it's something like: > Just look at the files in the log/ folder. Okay, shall do once this build is done. > >> Compile 2 hrs, install 40 minutes (64bit), 120 minutes (32bit), >> packaging probably like 5 minutes. > Ouch. > >> I have an NVME disk, but all my VMs (including this one) are on a SATA >> disk, and it's a Samsung QVO 1TB one that was cheaper but also slower >> (sustained write slows down to 80 MB/s eventually). Read is quick >> though. IIRC it's presented as SATA to the VM too. > What you really need to look for is IOPS/latency, not bandwidth. I > rarely see upwards of 60MByte/s through NTFS unless very large files are > involved (and only then I've ever seen it surpass the SATA barrier of > ~550MByte/s and not by much), but the QVO is better suited for warm > storage / backups and has pretty long response times and the low IOPS > that come with it when you fill the queue. The NVMe on the other hand > mostly registers below 1ms where the former SATA disk (a WD Blue) was > all over the map up to almost 300ms at times and around 3…10ms average > under load. I did a test with CrystalDiskMark and my speeds for sustained read and write were 2+ GB/s, and 4k and random were 100MB/s and 40MB/s, so I think that should be good enough. I think the GB/s figures come from using the I/O cache (host is Linux), so it's just reading and writing straight from/to RAM. The system itself has 32GB of RAM as well. >> I'd better have a look at my configuration. Maybe do some disk and CPU >> benchmarks. This is in virtualbox so perhaps it's yet another problem >> with that, in the long list of problems I seem to have with virtualbox. >> The VM has 16GB of RAM dedicated to it, how does that compare to your >> system? > That system is at its official max. configuration of 32GiB (4x8GiB ECC). > But as I said, it was running around 6GiB for the whole build with some > brief spikes to maybe 8GiB. So that seems unlikely to be your problem. > > You run your VM (virtual storage controller) in AHCI mode or not? That > should be the standard option for a recent Windows VM, but if not, then > rather abysmal disk performance is semi-expected. Yeah, it's AHCI. I've tried turning Avira Antivirus off for the next rebuild (segfault and wxpython issues may be have been due to STL, not gnomevfs). I already had exceptions for C:\cygwin64 and C:\cygwin, but we'll see if that makes it any quicker. I guess I'll keep digging in the meantime. Perhaps Cygwin and VirtualBox just don't work well together. I'm not sure if it used to be faster. Thanks for all the help, Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 23/11/2020 19:24, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > On 23/11/2020 19:16, ASSI wrote: >> Hamish McIntyre-Bhatty via Cygwin-apps writes: >>> That is strange if it's so much faster on your system. >> I've checked again to be sure: >> >> Compile 41 minutes, install 7 (32bit) / 4 (64bit) minutes, packaging 5 >> minutes. > Okay, wow that is a LOT quicker. I haven't timed mine precisely buts > it's something like: > > Compile 2 hrs, install 40 minutes (64bit), 120 minutes (32bit), > packaging probably like 5 minutes. > >>> Fortunately I have loads of memory so it's not too much of an issue >>> for me. Most of the time on 32-bit Cygwin is spent stripping the >>> executables, which is _way_ slower than on 64-bit Cygwin, by a factor >>> of probably 3-4. >> What's the disk based on? I've recently switched to NVMe and while it's >> not doing wonders compared to the SATA-SSD I've had before it has helped >> to shave some time off the builds, generally in the order of 10…25% (for >> gcc that means about half an hour so that's very welcome even if it >> doesn't sound much). Running a VM probably means you're running on a >> filesystem image rather than a dedicated disk and that probably means an >> extra slowdown anyway. NVMe would enable you to make that overhead go >> away, but it needs to be supported through the whole hypervisor / VM >> stack to be effective. > I have an NVME disk, but all my VMs (including this one) are on a SATA > disk, and it's a Samsung QVO 1TB one that was cheaper but also slower > (sustained write slows down to 80 MB/s eventually). Read is quick > though. IIRC it's presented as SATA to the VM too. > > I'd better have a look at my configuration. Maybe do some disk and CPU > benchmarks. This is in virtualbox so perhaps it's yet another problem > with that, in the long list of problems I seem to have with virtualbox. > The VM has 16GB of RAM dedicated to it, how does that compare to your > system? > > Hamish I think my fork speed is quite slow - when it prints out the "wxwidgets has been installed, update LD_LIBRARY_PATH yada yada" messages during install I can see it printing out the individual lines. I don't know whether it was always that slow. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 23/11/2020 19:16, ASSI wrote: > Hamish McIntyre-Bhatty via Cygwin-apps writes: >> That is strange if it's so much faster on your system. > I've checked again to be sure: > > Compile 41 minutes, install 7 (32bit) / 4 (64bit) minutes, packaging 5 > minutes. Okay, wow that is a LOT quicker. I haven't timed mine precisely buts it's something like: Compile 2 hrs, install 40 minutes (64bit), 120 minutes (32bit), packaging probably like 5 minutes. >> Fortunately I have loads of memory so it's not too much of an issue >> for me. Most of the time on 32-bit Cygwin is spent stripping the >> executables, which is _way_ slower than on 64-bit Cygwin, by a factor >> of probably 3-4. > What's the disk based on? I've recently switched to NVMe and while it's > not doing wonders compared to the SATA-SSD I've had before it has helped > to shave some time off the builds, generally in the order of 10…25% (for > gcc that means about half an hour so that's very welcome even if it > doesn't sound much). Running a VM probably means you're running on a > filesystem image rather than a dedicated disk and that probably means an > extra slowdown anyway. NVMe would enable you to make that overhead go > away, but it needs to be supported through the whole hypervisor / VM > stack to be effective. I have an NVME disk, but all my VMs (including this one) are on a SATA disk, and it's a Samsung QVO 1TB one that was cheaper but also slower (sustained write slows down to 80 MB/s eventually). Read is quick though. IIRC it's presented as SATA to the VM too. I'd better have a look at my configuration. Maybe do some disk and CPU benchmarks. This is in virtualbox so perhaps it's yet another problem with that, in the long list of problems I seem to have with virtualbox. The VM has 16GB of RAM dedicated to it, how does that compare to your system? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 23/11/2020 15:26, ASSI wrote:
> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>> 1. I have separated these onto another line. I've kept this enabled for
>> manual testing, and also because other things in my Cygwin install need
>> some of these dependencies - I can't easily remove to be 1000% sure that
>> none of them are needed during building. It seems wxWidgets hasn't
>> documented optional build dependencies very clearly.
> Graphviz is actually needed for building the docs I've found.
Oh yeah, you're right. I forgot that was what it was for.
>
>> 4. Okay, trying that in this build. Not sure how to test that any
>> features need that are working, so I'll have to research that.
> Specifically, copying the config.cache from base to both of the gtk{2,3}
> builds should work, but not gtk2->3. I've re-arranged the cygport file
> to first configure all three (makes it easier to hunt for differences),
> then build in reverse order.
Yeah, maybe I should do that as well, but I've just started another
build. Re-enabling gnomevfs did NOT work for me - causes segfaults and
wxpython can import the libraries with a "No such process" error after
doing that. Rebuilding now. I guess it could be due to using STL as
well, but we'll see.
>
>> I'll wait on the CI system then, this takes hours to build even on my
>> Ryzen 3600, especially on 32-bit Cygwin.
> That's odd. I've built on a 4-core/8-thread Haswell in well under two
> hours per architecture and I haven't seen memory peak above 8GiB. You
> said you are building in a VM, perhaps you should reduce the number of
> threads there a bit. If the VM starts contending for host resources
> things _will_ get ugly.
That is strange if it's so much faster on your system. Fortunately I
have loads of memory so it's not too much of an issue for me. Most of
the time on 32-bit Cygwin is spent stripping the executables, which is
_way_ slower than on 64-bit Cygwin, by a factor of probably 3-4. Time to
rebuild again anyway. What fun...
Thanks Achim,
Hamish
0x87B761FE07F548D6.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 22/11/2020 09:41, Achim Gratz wrote: > Hamish McIntyre-Bhatty via Cygwin-apps writes: >> *bump* in case this went unnoticed. > It didn't, I just know that this GNOME crap will always need another 40 > packages installed before I can even start looking. > >> I know it's a pain checking these over because it takes so long to build >> them, but I would still very much appreciate it. I am already a >> maintainer for other packages, but AFAIK this doesn't give me the right >> to GTG myself. > Here's what I have so far: > > 1. Do not add the runtime packages to BUILD_REQUIRES (i.e if you have > zlib-devel, then don't add zlib). If there are runtime packages you > need for testing, list them on a separate line and comment that these > are needed for testing only (xclock, graphviz?). Currently we assume > the dependencies needed by cygport to be available always without > explicitly mentioining them (e.g. autoconf), although it doesn't hurt to > have them in. > > 2. The option --without-gnomeprint seems no longer available and would > be default anyway since gtkprint gets detected and used. > > 3. You should explicitly specify that you want to use the system regex > library, so add --with-regex=sys. > > 4. It should be possible to enable full STL now, so add --enable-stl. > > 5. If you copy the config.cache forward to the next run of configure you > can save a bit of time not rechecking stuff you already checked. > > > > Regards, > Achim. Thanks, changes made and rebuilding now. 1. I have separated these onto another line. I've kept this enabled for manual testing, and also because other things in my Cygwin install need some of these dependencies - I can't easily remove to be 1000% sure that none of them are needed during building. It seems wxWidgets hasn't documented optional build dependencies very clearly. 2. Good point, I have removed this. 3. As above, I have added this. 4. Okay, trying that in this build. Not sure how to test that any features need that are working, so I'll have to research that. Extra: I'm also trying to build with gnomevfs now, seeing as that Gentoo bug is very old, and I suspect the issue has since been fixed. Will have to figure out how to test this as well, but it looks like many things will outright crash if this problem occurs. I'll wait on the CI system then, this takes hours to build even on my Ryzen 3600, especially on 32-bit Cygwin. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 12/11/2020 18:00, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > On 11/11/2020 17:36, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> Ignore my previous message - whatever was wrong is now fixed. I didn't >> change anything much so I think it was a dependency that had an issue >> and was since recompiled. >> >> 64-bit build is done and seems to work fine. I'm testing it using the >> samples, nearly all of which work, and new things that weren't in the >> previous wxwidgets build now work (eg webview with webkit). >> >> I need to finish my testing and then build for 32-bit Cygwin, but all >> seems good. >> >> When it's all done I'll email again with my cygport file attached and a >> link to the file locations. >> >> Hamish > Okay, I have successfully manually tested wxWidgets3.0 on both 32-bit > and 64-bit Cygwin, and I haven't found any significant issues. It also > seems to work with my existing wxPython build but I'm going to recompile > that anyway just to be sure and to get the new version number for > wxWidgets in the build. > > The test packages are available for download at > https://www.hamishmb.com/files/cygwin-temp/ as usual, and my cygport > file is attached here. > > Here's a quick summary of the changes I've made: > > - Updated to wxWidgets 3.0.5.1 from 3.0.4. > > - Added build dependencies. > > - Evaluated lots of new patches (over 80), and found that nearly none of > them were needed (already patched in new source), so we only have a few > new patches. > > - Updated the wxGTK collision patch for wxwidgets 3.0.5.1 as the old one > wouldn't apply. > > - Use pushd and popd instead of cd in the cygport file. > > - Enable automated unit tests in the cygport file (these currently do > work so I tested manually). > > - Enable and test wxwebview with webkit (works fine in all configurations). > > I'd like to use the AppVeyor CI tool to double check the build and build > dependencies, but the very high RAM usage during compilation (12GB!) > makes me think it might crash that system. Is it safe for me to proceed? > I really don't want to ruin someone's day by crashing the CI system(s). > I think I need a GTG before can do this because I don't currently own > the package, but I'm not sure. > > Finally, I'm going to keep these as test packages until I've got > wxPython build and tested against them, which will be maybe another week > or so depending on other priorities. > > Any feedback is very welcome :) > > Hamish *bump* in case this went unnoticed. I know it's a pain checking these over because it takes so long to build them, but I would still very much appreciate it. I am already a maintainer for other packages, but AFAIK this doesn't give me the right to GTG myself. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 11/11/2020 17:36, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> Ignore my previous message - whatever was wrong is now fixed. I didn't
> change anything much so I think it was a dependency that had an issue
> and was since recompiled.
>
> 64-bit build is done and seems to work fine. I'm testing it using the
> samples, nearly all of which work, and new things that weren't in the
> previous wxwidgets build now work (eg webview with webkit).
>
> I need to finish my testing and then build for 32-bit Cygwin, but all
> seems good.
>
> When it's all done I'll email again with my cygport file attached and a
> link to the file locations.
>
> Hamish
Okay, I have successfully manually tested wxWidgets3.0 on both 32-bit
and 64-bit Cygwin, and I haven't found any significant issues. It also
seems to work with my existing wxPython build but I'm going to recompile
that anyway just to be sure and to get the new version number for
wxWidgets in the build.
The test packages are available for download at
https://www.hamishmb.com/files/cygwin-temp/ as usual, and my cygport
file is attached here.
Here's a quick summary of the changes I've made:
- Updated to wxWidgets 3.0.5.1 from 3.0.4.
- Added build dependencies.
- Evaluated lots of new patches (over 80), and found that nearly none of
them were needed (already patched in new source), so we only have a few
new patches.
- Updated the wxGTK collision patch for wxwidgets 3.0.5.1 as the old one
wouldn't apply.
- Use pushd and popd instead of cd in the cygport file.
- Enable automated unit tests in the cygport file (these currently do
work so I tested manually).
- Enable and test wxwebview with webkit (works fine in all configurations).
I'd like to use the AppVeyor CI tool to double check the build and build
dependencies, but the very high RAM usage during compilation (12GB!)
makes me think it might crash that system. Is it safe for me to proceed?
I really don't want to ruin someone's day by crashing the CI system(s).
I think I need a GTG before can do this because I don't currently own
the package, but I'm not sure.
Finally, I'm going to keep these as test packages until I've got
wxPython build and tested against them, which will be maybe another week
or so depending on other priorities.
Any feedback is very welcome :)
Hamish
NAME="wxWidgets3.0"
VERSION=3.0.5.1
RELEASE=1
CATEGORY="Libs"
SUMMARY="wxWidgets C++ application framework"
DESCRIPTION="wxWidgets is a set of libraries that allows C++ applications to
compile and run on several different types of computer, with minimal source
code changes. There is one library per supported GUI. As well as providing a
common API for GUI functionality, it provides functionality for accessing some
commonly-used operating system facilities, from copying and deleting files to
socket and thread support."
HOMEPAGE="http://wxwidgets.org/;
SRC_URI="https://github.com/wxWidgets/wxWidgets/releases/download/v${VERSION}/wxWidgets-${VERSION}.tar.bz2;
SRC_DIR="wxWidgets-${VERSION}"
BUILD_REQUIRES="make xclock cppunit autoconf pkg-config gcc-core gcc-g++
doxygen graphviz libX11-devel libgtk2.0-devel libgtk3-devel
libwebkitgtk1.0-devel libwebkitgtk1.0_0 libwebkitgtk3.0-devel libwebkitgtk3.0_0
libpng16 libpng-devel libjpeg-devel libjpeg8 libexpat1 libexpat-devel
libiconv-devel libiconv libiconv2 libmspack0 libmspack-devel libnotify
libnotify-devel libtiff6 libtiff-devel libXpm4 libXpm-devel libcogl20
libcogl-devel libEGL1 libEGL-devel libGL1 libGL-devel libGLU1 libGLU-devel
libSDL2_2.0_0 libSDL2-devel libSDL2_image2.0_0 libSDL2_image-devel
libSDL2_mixer2.0_0 libSDL2_mixer-devel libSDL2_net2.0_0 libSDL2_net-devel
libSDL2_ttf2.0_0 libSDL2_ttf-devel zlib zlib-devel"
PATCH_URI="
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/wxGTK3-3.0.3-abicheck.patch
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/fix-filename-test.patch
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/fix-vararg-test.patch
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/force-x11-for-wxgl.patch
wxGTK3-3.0.5.1-collision.patch
3.0.2-cygwin-auto-import.patch
3.0.2-cygwin-dlopen.patch
3.0.2-cygwin-unix.patch
3.0.2-cygwin-gcc5.patch
3.0.3-autoreconf.patch
3.0.3-cygwin-ftm.patch
0007-Fix-video-sink-fallback-in-wxMediaCtrl-when-xvimages.patch
"
slot=${PV_MAJ_MIN}
PKG_NAMES="libwx_baseu3.0_0 libwx_baseu3.0-devel ${NAME}-doc
libwx_gtk2u3.0_0 libwx_gtk2u3.0-devel
libwx_gtk3u3.0_0 libwx_gtk3u3.0-devel"
libwx_baseu3_0_0_SUMMARY="${SUMMARY} (base unicode runtime)"
libwx_baseu3_0_0_CONTENTS="
--exclude=html
usr/bin/cygwx_baseu*-3.0-0.dll
usr/share/doc/${NAME}/
usr/share/locale/*/LC_MESSAGES/wxstd30.mo
"
libwx_baseu3_0_devel_REQUIRES="lib
Re: [ITA] wxWidgets3.0
Ignore my previous message - whatever was wrong is now fixed. I didn't change anything much so I think it was a dependency that had an issue and was since recompiled. 64-bit build is done and seems to work fine. I'm testing it using the samples, nearly all of which work, and new things that weren't in the previous wxwidgets build now work (eg webview with webkit). I need to finish my testing and then build for 32-bit Cygwin, but all seems good. When it's all done I'll email again with my cygport file attached and a link to the file locations. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 28/10/2020 08:40, Achim Gratz wrote: > Hamish McIntyre-Bhatty via Cygwin-apps writes: >> Another interesting thing is that I get the following messages when >> running cygport install: >> >> Warning: x was not linked with -Wl, --enable-auto-image-base >> >> Is this anything to be alarmed about or not really an issue? The >> libraries seem to work okay, at any rate. > I'm not sure if cygport actually fixes this up by changing the flags in > the DLL, but that means that the linker flags that cygport tries to > force are overwritten somewhere else. Now, this is most likely CMake > you're dealing with, so the best of luck in figuring out where. > > > Regards, > Achim. Hmm, how does cygport do this? I tried setting LDFLAGS (which was previously empty) to " -Wl, --enable-auto-image-base" but that just broke the compiler. I'm building again now with the hopes of seeing what the commandline to the linker is, and hence hopefully finding it and maybe patching it in the source, but there might be a better way. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 28/10/2020 08:40, Achim Gratz wrote: > Hamish McIntyre-Bhatty via Cygwin-apps writes: >> Another interesting thing is that I get the following messages when >> running cygport install: >> >> Warning: x was not linked with -Wl, --enable-auto-image-base >> >> Is this anything to be alarmed about or not really an issue? The >> libraries seem to work okay, at any rate. > I'm not sure if cygport actually fixes this up by changing the flags in > the DLL, but that means that the linker flags that cygport tries to > force are overwritten somewhere else. Now, this is most likely CMake > you're dealing with, so the best of luck in figuring out where. > > > Regards, > Achim. Okay thanks, I'll look into that shortly. I'm getting near the stage where using the CI tool might be useful; could someone hand over the package to me please so I can commit to the git repo please? Also of note, is the ridiculous amount of memory that seems to be needed when compiling and linking wxWidgets (I needed to give 12GB to my VM!) - will I crash the CI system if I try to build using it, or will it be okay/not a disaster if it uses too much RAM and starts swapping? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 27/10/2020 13:16, ASSI wrote: > Hamish McIntyre-Bhatty via Cygwin-apps writes: >> Unfortunately, the unit tests do not run correctly for me, but it seems >> they were originally disabled by Yakkov, probably for this exact reason. > I believe many of the Gtk packages were either cross-compiled or > compiled on a machine without the GUI available, so I'd not expect the > tests to have been run for these. Another problem is that GUI tests > more often than not than suffer from ATWIL syndrome and can't be run as > intended without major changes to the testsuite. Ah I see, this makes sense. How well the GUI tests run seems rather inconsistent. I think there might be an alignment issue that's causing so many of the GTK3 tests to fail. >> The cmdline one segfaults (both for GTK2 and GTK3), and a number of >> tests fail, but unfortunately I cannot see which exact tests are failing >> because I don't get to the summary before it segfaults. I'm not really >> sure how to debug this, as I don't have much experience in C/C++ >> programming, and even less experience with using a debugger. Any good >> tips/links? > Well, the first thing I'd check if it even picks up the libraries you > have just compiled. If it fiddles with LD_LIBRARY_PATH that's your > first clue that it doesn't. You might have to prepend the build > directories that have the libraries to PATH or even install the package > before running the tests. I've already added the libraries to PATH when building, but thanks for the suggestion. I did also have to remove the system wxwidgets install even with that, because the unit tests kept trying to use that, resulting in fork errors and other unpredictable behaviour. Any more ideas? Honestly, I'm happy to test manually with the wxPython demo and some wxwidgets test programs if that's considered good enough. Another interesting thing is that I get the following messages when running cygport install: Warning: x was not linked with -Wl, --enable-auto-image-base Is this anything to be alarmed about or not really an issue? The libraries seem to work okay, at any rate. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 21/10/2020 19:39, Achim Gratz wrote: > Brian Inglis writes: >> I should now add [branch "playground"] entries to make testing appveyor CI >> builds cleaner and easier, as I usually don't do this stuff enough to >> remember >> how to do it, so I muddle through, and then forget what I need to add to my >> notes on packaging. > It's not necessary to keep playground as a local branch, just > > git push origin master:playground > > fix it up as you get the Ci results and then after everything works > there, push to master and delete the branch on the remote with > > git push origin && git push origin :playground > > > Regards, > Achim. Excellent, thanks. Unfortunately, the unit tests do not run correctly for me, but it seems they were originally disabled by Yakkov, probably for this exact reason. There are two test programs generated for both GTK2 and GTK3. One is a commandline tool, and the other tests GUI elements and does things like simulating mouse clicks and keyboard input. Please note that neither of these compile unless I edit the makefile to remove the fswatcher component (which doesn't build in Cygwin), I think it uses a kernel feature. The cmdline one segfaults (both for GTK2 and GTK3), and a number of tests fail, but unfortunately I cannot see which exact tests are failing because I don't get to the summary before it segfaults. I'm not really sure how to debug this, as I don't have much experience in C/C++ programming, and even less experience with using a debugger. Any good tips/links? The GTK2 GUI tests pass with only 2 failures, but there are 53 failures for the GTK3 GUI tests. If I can use a demo (eg the wxPython demo) and recursively go through all the GUI elements verifying things work, would that be considered good enough? I imagine this is probably what Yaakov did back when he built the current wxwidgets packages. I'm not really satisfied with this but I am not sure I have the skills to proceed further without help/advice. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 19/10/2020 16:31, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > On 17/10/2020 16:04, Brian Inglis wrote: >> On 2020-10-17 07:17, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >>> On 17/10/2020 01:21, Lemures Lemniscati via Cygwin-apps wrote: >>>> On Fri, 16 Oct 2020 20:20:53 +0100, Hamish McIntyre-Bhatty via Cygwin-apps >>>>> Just sending this out so I can update wxWidgets to 3.0.5.1. I've pulled >>>>> in new patches from Fedora, but I can't find >>>>> mirror://portage/x11-libs/wxGTK/files/wxGTK-3.0.3-collision.patch >>>>> anywhere. Does anyone happen to have a copy of this? >>>>> >>>>> My hope is that it is no longer needed, but obviously I can't confirm >>>>> that without actually having the patch. I haven't got any files uploaded >>>>> yet because I'm doing a test build. If anyone has a copy of that >>>>> patch/knows where to find it please let me know. >>>> You can get them from one of the current src packages. >>>> List of src files: >>>> https://www.cygwin.com/packages/x86_64/wxWidgets3.0-src/wxWidgets3.0-3.0.4-1-src >>>> Package: >>>> http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/wxWidgets3.0/ >>> Excellent, thanks :) >>> >>> I'll post again when I've got builds and have improved the cygport file >>> (this one doesn't have build dependencies). >>> >>> It takes about 3-4 hours per build, somehow, so it might be a little >>> while, but we'll see :) >> Those mirrors should be part of cygport SRC_URI or PATCH_URI and will be >> retrieved on download. >> >> Portage is gentoo equivalent on which cygport is based and that patch hits >> some >> make and bake file and translation sources as part of a patchset series: >> >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e16e67f0678b264a04e96954a4593ddac3a9a32d >> >> including also: >> >> https://dev.gentoo.org/~leio/distfiles/wxGTK-3.0.3_p20180104.tar.xz >> >> where you will have to figure out if you need to doenload and apply patches >> to >> their sources or make a similar change to get the equivalent effect in your >> cygport. >> > Thanks Brian, I'll look into those. > > It gave a 404 trying to download that patch, but not a problem because I > have it now. I'll look around and see if I can use those other ones you > sent, or if there are more patches in any more current Gentoo package. > > Hamish Okay, new patches reviewed and BUILD_DEPENDS is sorted. I've heard a new CI tool mentioned here (AppVeyor?). Is there a way I can use that to test my packaging/build-depends once this local build is finished? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 17/10/2020 16:04, Brian Inglis wrote: > On 2020-10-17 07:17, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> On 17/10/2020 01:21, Lemures Lemniscati via Cygwin-apps wrote: >>> On Fri, 16 Oct 2020 20:20:53 +0100, Hamish McIntyre-Bhatty via Cygwin-apps >>>> Just sending this out so I can update wxWidgets to 3.0.5.1. I've pulled >>>> in new patches from Fedora, but I can't find >>>> mirror://portage/x11-libs/wxGTK/files/wxGTK-3.0.3-collision.patch >>>> anywhere. Does anyone happen to have a copy of this? >>>> >>>> My hope is that it is no longer needed, but obviously I can't confirm >>>> that without actually having the patch. I haven't got any files uploaded >>>> yet because I'm doing a test build. If anyone has a copy of that >>>> patch/knows where to find it please let me know. >>> You can get them from one of the current src packages. >>> List of src files: >>> https://www.cygwin.com/packages/x86_64/wxWidgets3.0-src/wxWidgets3.0-3.0.4-1-src >>> Package: >>> http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/wxWidgets3.0/ >> Excellent, thanks :) >> >> I'll post again when I've got builds and have improved the cygport file >> (this one doesn't have build dependencies). >> >> It takes about 3-4 hours per build, somehow, so it might be a little >> while, but we'll see :) > Those mirrors should be part of cygport SRC_URI or PATCH_URI and will be > retrieved on download. > > Portage is gentoo equivalent on which cygport is based and that patch hits > some > make and bake file and translation sources as part of a patchset series: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e16e67f0678b264a04e96954a4593ddac3a9a32d > > including also: > > https://dev.gentoo.org/~leio/distfiles/wxGTK-3.0.3_p20180104.tar.xz > > where you will have to figure out if you need to doenload and apply patches to > their sources or make a similar change to get the equivalent effect in your > cygport. > Thanks Brian, I'll look into those. It gave a 404 trying to download that patch, but not a problem because I have it now. I'll look around and see if I can use those other ones you sent, or if there are more patches in any more current Gentoo package. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] wxWidgets3.0
On 17/10/2020 01:21, Lemures Lemniscati via Cygwin-apps wrote: > On Fri, 16 Oct 2020 20:20:53 +0100, Hamish McIntyre-Bhatty via Cygwin-apps >> Hi there, >> >> Just sending this out so I can update wxWidgets to 3.0.5.1. I've pulled >> in new patches from Fedora, but I can't find >> mirror://portage/x11-libs/wxGTK/files/wxGTK-3.0.3-collision.patch >> anywhere. Does anyone happen to have a copy of this? >> >> My hope is that it is no longer needed, but obviously I can't confirm >> that without actually having the patch. I haven't got any files uploaded >> yet because I'm doing a test build. If anyone has a copy of that >> patch/knows where to find it please let me know. >> >> Hamish >> > Hi! > > You can get them from one of the current src packages. > > List of src files: > https://www.cygwin.com/packages/x86_64/wxWidgets3.0-src/wxWidgets3.0-3.0.4-1-src > Package: > http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/wxWidgets3.0/ > > Regards, > > Lem Excellent, thanks :) I'll post again when I've got builds and have improved the cygport file (this one doesn't have build dependencies). It takes about 3-4 hours per build, somehow, so it might be a little while, but we'll see :) Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
[ITA] wxWidgets3.0
Hi there, Just sending this out so I can update wxWidgets to 3.0.5.1. I've pulled in new patches from Fedora, but I can't find mirror://portage/x11-libs/wxGTK/files/wxGTK-3.0.3-collision.patch anywhere. Does anyone happen to have a copy of this? My hope is that it is no longer needed, but obviously I can't confirm that without actually having the patch. I haven't got any files uploaded yet because I'm doing a test build. If anyone has a copy of that patch/knows where to find it please let me know. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python-getdevinfo
On 13/09/2020 17:07, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > On 13/09/2020 15:57, Jon Turney wrote: >> I don't see a statement here or on the website of the license this is >> under. >> >> Assuming the answer to that is satisfactory: >> >> +1 > It is GPLv3+ - fully OSS. > > Hamish Jon Turney, Seeing as this is GPLv3+, do I have your vote? Achim Gratz, Did the explanation I provided answer your questions? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python-getdevinfo
On 13/09/2020 17:08, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > On 13/09/2020 16:02, Brian Inglis wrote: >> On 2020-09-13 01:39, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >>> On 13/09/2020 07:13, Achim Gratz wrote: >>>> Hamish McIntyre-Bhatty via Cygwin-apps writes: >>>>> Hmm, who decides (and how) what counts as a Linux distro? >>>> Something that is capable of and has actually done a license review. >>> Seems fair. >>>>> Either way, could anyone provide some insight as to whether bundling the >>>>> Cygwin DLL would allow Cygwin programs to access the virtual /dev and >>>>> /cygdrive paths? I have this all ready to be released for Windows, so >>>>> one way or another I'll need to make a bundle anyway for convenience. >>>> Yes, all the virtual fs are provided through the Cygwin DLL. >>> Excellent, thank you :) >>>>> It'd be great if it could make it into the official repos but I first >>>>> submitted this ITP around a month ago so I don't have high hopes as of >>>>> this point. >>>> You still haven't explained what it would be useful for. This >>>> bare-metal stuff isn't something I'd usually consider doing from within >>>> a userland compatibility layer running on Windows. >>> My apologies - I thought I had but that must be a false memory. This >>> module is a device information collector, and in Cygwin's case it makes >>> it easy for users of DDRescue-GUI to find the link between the Windows >>> drive letters and Cygwin paths. It also provides other information such >>> as make and model, but this is limited on Cygwin because some of the >>> more low-level device management utilities don't exist, probably due to >>> bits of missing API as explained to me by Corrina (at least I think it >>> was her). It behaves very similarly on macOS and Linux, except it just >>> needs to inform the user of device details instead of also relating to >>> drive letters/Windows names. >>> >>> This is basically just a dependency for DDRescue-GUI (a GUI I wrote for >>> GNU ddrescue), and I had interest on getting this running easily on >>> Windows, so I thought Cygwin would be the way to go for better >>> compatibility. You can find DDRescue-GUI here: >>> https://www.hamishmb.com/html/downloads.php?program_name=ddrescue-gui >>> and the user guide is available from the nav bar if you want more >>> information about it. >>> >>> Does that answer your question - hopefully I didn't miss the point. >> Package smartmontools has access to some low level disk I/O features when run >> elevated under an admin account. > Yes, I think you (or maybe Corinna) told me this before - getdevinfo > compiles this together with other information to try and get as complete > a picture as possible. That was a useful tip for sure. > > Hamish NB: If GPLv2 is required instead of GPLv3, I will happily license it as GPLv2 for Cygwin. I imagine any properly open source license such as GPLv3 is okay though? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python-getdevinfo
On 13/09/2020 16:02, Brian Inglis wrote: > On 2020-09-13 01:39, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> On 13/09/2020 07:13, Achim Gratz wrote: >>> Hamish McIntyre-Bhatty via Cygwin-apps writes: >>>> Hmm, who decides (and how) what counts as a Linux distro? >>> Something that is capable of and has actually done a license review. >> Seems fair. >>>> Either way, could anyone provide some insight as to whether bundling the >>>> Cygwin DLL would allow Cygwin programs to access the virtual /dev and >>>> /cygdrive paths? I have this all ready to be released for Windows, so >>>> one way or another I'll need to make a bundle anyway for convenience. >>> Yes, all the virtual fs are provided through the Cygwin DLL. >> Excellent, thank you :) >>>> It'd be great if it could make it into the official repos but I first >>>> submitted this ITP around a month ago so I don't have high hopes as of >>>> this point. >>> You still haven't explained what it would be useful for. This >>> bare-metal stuff isn't something I'd usually consider doing from within >>> a userland compatibility layer running on Windows. >> My apologies - I thought I had but that must be a false memory. This >> module is a device information collector, and in Cygwin's case it makes >> it easy for users of DDRescue-GUI to find the link between the Windows >> drive letters and Cygwin paths. It also provides other information such >> as make and model, but this is limited on Cygwin because some of the >> more low-level device management utilities don't exist, probably due to >> bits of missing API as explained to me by Corrina (at least I think it >> was her). It behaves very similarly on macOS and Linux, except it just >> needs to inform the user of device details instead of also relating to >> drive letters/Windows names. >> >> This is basically just a dependency for DDRescue-GUI (a GUI I wrote for >> GNU ddrescue), and I had interest on getting this running easily on >> Windows, so I thought Cygwin would be the way to go for better >> compatibility. You can find DDRescue-GUI here: >> https://www.hamishmb.com/html/downloads.php?program_name=ddrescue-gui >> and the user guide is available from the nav bar if you want more >> information about it. >> >> Does that answer your question - hopefully I didn't miss the point. > Package smartmontools has access to some low level disk I/O features when run > elevated under an admin account. Yes, I think you (or maybe Corinna) told me this before - getdevinfo compiles this together with other information to try and get as complete a picture as possible. That was a useful tip for sure. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python-getdevinfo
On 13/09/2020 15:57, Jon Turney wrote: > On 03/09/2020 14:44, marco atzeri via Cygwin-apps wrote: >> On Wed, Sep 2, 2020 at 10:59 PM Hamish McIntyre-Bhatty via >> Cygwin-apps wrote: >>> >>> On 02/09/2020 19:05, Marco Atzeri via Cygwin-apps wrote: >>>> >>>> Hi Hamish, >>>> >> [cut] >>>> Is already in some Linux distribution ? >>>> Otherwise we need 5 votes from maintainers > > Oh, this stupid rule again :S > >> just to avoid misunderstandings, you have my vote, so >> you need only other 3 approvals as you count as 1 > > I don't see a statement here or on the website of the license this is > under. > > Assuming the answer to that is satisfactory: > > +1 It is GPLv3+ - fully OSS. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python-getdevinfo
On 13/09/2020 07:13, Achim Gratz wrote: > Hamish McIntyre-Bhatty via Cygwin-apps writes: >> Hmm, who decides (and how) what counts as a Linux distro? > Something that is capable of and has actually done a license review. Seems fair. >> Either way, could anyone provide some insight as to whether bundling the >> Cygwin DLL would allow Cygwin programs to access the virtual /dev and >> /cygdrive paths? I have this all ready to be released for Windows, so >> one way or another I'll need to make a bundle anyway for convenience. > Yes, all the virtual fs are provided through the Cygwin DLL. Excellent, thank you :) > >> It'd be great if it could make it into the official repos but I first >> submitted this ITP around a month ago so I don't have high hopes as of >> this point. > You still haven't explained what it would be useful for. This > bare-metal stuff isn't something I'd usually consider doing from within > a userland compatibility layer running on Windows. My apologies - I thought I had but that must be a false memory. This module is a device information collector, and in Cygwin's case it makes it easy for users of DDRescue-GUI to find the link between the Windows drive letters and Cygwin paths. It also provides other information such as make and model, but this is limited on Cygwin because some of the more low-level device management utilities don't exist, probably due to bits of missing API as explained to me by Corrina (at least I think it was her). It behaves very similarly on macOS and Linux, except it just needs to inform the user of device details instead of also relating to drive letters/Windows names. This is basically just a dependency for DDRescue-GUI (a GUI I wrote for GNU ddrescue), and I had interest on getting this running easily on Windows, so I thought Cygwin would be the way to go for better compatibility. You can find DDRescue-GUI here: https://www.hamishmb.com/html/downloads.php?program_name=ddrescue-gui and the user guide is available from the nav bar if you want more information about it. Does that answer your question - hopefully I didn't miss the point. Thanks, Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python-getdevinfo
On 09/09/2020 11:36, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > On 04/09/2020 14:38, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> >> Thank you, that seemed to work well. >> >> New build dependencies added (also util-linux, binutils, cygwin, and >> coreutils), and updated as a noarch package with no other changes. The >> new files are in the "noarch" subdirectory at >> https://www.hamishmb.com/files/cygwin-temp/. >> >> I gave the noarch packages I built on 64-bit Cygwin a spin on 32-bit >> Cygwin too, all seems fine. >> >> Hamish > Just realised, that I forgot (doh!) that both GetDevInfo and > DDRescue-GUI are in the Parted Magic (www.partedmagic.com) recovery > toolkit. I work with Patrick Verner to make sure the programs work well > under that distribution as well. Does this count as a Linux Distribution? > > If not, I still need two more votes, and while I know you're all > probably very busy, it'd be great if a couple more of you could take a > look at this :) > > Hamish Hmm, who decides (and how) what counts as a Linux distro? Parted Magic is a live disk/USB that contains a variety of system recovery tools, but is actively maintained and has a changelog and quality assurance etc so I suppose it could be included in the definition of a Linux distro? Either way, could anyone provide some insight as to whether bundling the Cygwin DLL would allow Cygwin programs to access the virtual /dev and /cygdrive paths? I have this all ready to be released for Windows, so one way or another I'll need to make a bundle anyway for convenience. It'd be great if it could make it into the official repos but I first submitted this ITP around a month ago so I don't have high hopes as of this point. I will be happy to work on improving device detection/discovery in Cygwin regardless, as and when time permits. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [RFC] cygport pm for managing package releases
On 12/09/2020 22:20, Brian Inglis wrote: > On 2020-09-12 09:03, Ken Brown via Cygwin-apps wrote: >> On 9/11/2020 12:07 PM, Andrew Schulman via Cygwin-apps wrote: >>> cygport has automated a lot of the work of building and maintaining >>> packages for Cygwin. But one area where it doesn't help yet is in managing >>> the available releases of a package. For me as the maintainer of a dozen or >>> so packages, there are routine tasks that I still find to be painful: >>> >>> * Finding out which versions of a package are currently available in the >>> Cygwin repositories, and which if any are marked as "test". >>> * Marking or unmarking a version as "test". >>> * Removing versions from the repositories. >>> * Marking a package as obsolete. >>> >>> All of these are still manual tasks. Most require digging through >>> documentation (though that's also much improved in the last few years), >>> manually editing .hint files or creating dummy package files, and manually >>> uploading files to the right places in sftp://cygwin.com. It's not fun, and >>> so I don't keep up with it as well as I should. >>> >>> To alleviate that, I think cygport should add a set of "pm" commands to >>> automate package management. For example: >>> >>> * cygport pm list - list versions available in the Cygwin repositories. >>> * cygport pm test - set/clear "test" status for a version. >>> * cygport pm del - remove a package version from the repositories. >>> * cygport pm obsolete - mark a package as obsolete. >>> >>> And probably others. I think this would make maintainer's lives easier, and >>> make these management tasks more reliable. >>> >>> I can spend some time planning and developing this, and if others want to >>> collaborate on it, so much the better. But before I start on that, I want >>> to get people's comments here about whether: >>> >>> * It's worth doing; >>> * (More to the point) It'd be likely to be accepted upstream, assuming the >>> implementation is satisfactory; and >>> * There may be problems in implementing it that I haven't thought of. >>> >>> I can think of a few problems or objections: >>> >>> 1. The "pm" commands will bake into cygport logic that's specific to how >>> the package repositories and upset currently work. So if those change, >>> cygport will have to change to match them. That's true, but not just for >>> cygport pm - other parts of cygport, such as cygport up, are basically >>> clients for upset. And at least it'll centralize the changes in one place, >>> so maintainers won't have to worry about them. >>> >>> 2. "pm list" will require finding and parsing an appropriate setup.ini >>> file, unlike the other "pm" commands which will manipulate >>> sftp://cygwin.com. >>> >>> I think these are surmountable, but I want to know if there's a general >>> agreement that it's worth doing. >>> >>> BTW a successful example like this one is the "cygport up" command, which >>> we added a few years ago to automate uploading packages to cygwin.com. I >>> think it's working well. >> Agreed. Thanks for doing this. >> >> Concerning your specific suggestions: >> >>> * cygport pm list - list versions available in the Cygwin repositories. >> Good idea. I often find myself looking at setup.ini to get this information, >> and it would be nice to have cygport automate the process. >> >>> * cygport pm test - set/clear "test" status for a version. >> I like the idea of clearing test status, i.e., 'cygport pm untest'; this >> should >> be trivial to implement in view of Jon's recent work: >> >> https://cygwin.com/pipermail/cygwin-apps/2020-August/040440.html >> >> But I'm not sure about going in the other direction. Once users have already >> installed a non-test package, it could be very confusing to have that package >> retroactively declared to be a test release. >> >>> * cygport pm del - remove a package version from the repositories. >> This would be very useful. The current mechanism for removing a package >> version >> is very tedious. >> >>> * cygport pm obsolete - mark a package as obsolete. >> I was about to question the need for this, but I'll bet you're thinking about >> unison2.48. It will soon become obsolete, with two or more possible >> replacement >> packages. So the usual mechanism of having a new package obsolete an old one >> doesn't quite work. > Python 2/2.7 (308) packages also come to mind as being dropped at some point > in > the next year as there is no longer any support. > I would definitely find these features helpful so you have my vote on these additions for sure. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python-getdevinfo
On 04/09/2020 14:38, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > > Thank you, that seemed to work well. > > New build dependencies added (also util-linux, binutils, cygwin, and > coreutils), and updated as a noarch package with no other changes. The > new files are in the "noarch" subdirectory at > https://www.hamishmb.com/files/cygwin-temp/. > > I gave the noarch packages I built on 64-bit Cygwin a spin on 32-bit > Cygwin too, all seems fine. > > Hamish Just realised, that I forgot (doh!) that both GetDevInfo and DDRescue-GUI are in the Parted Magic (www.partedmagic.com) recovery toolkit. I work with Patrick Verner to make sure the programs work well under that distribution as well. Does this count as a Linux Distribution? If not, I still need two more votes, and while I know you're all probably very busy, it'd be great if a couple more of you could take a look at this :) Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python-getdevinfo
On 03/09/2020 19:50, Ken Brown via Cygwin-apps wrote: > On 9/3/2020 1:27 PM, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> On 03/09/2020 18:13, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >>> >>> Good to know, and oh yeah, I'll do that tomorrow. >>> >>> Cheers for the vote. >>> >>> Hamish >>> >> I should note that this is a pure python package - can it be a noarch >> package? I'm not sure how to configure the cygport file to build a >> noarch package. > > Just put the line > > ARCH=noarch > > in the cygport file. > > Ken Thank you, that seemed to work well. New build dependencies added (also util-linux, binutils, cygwin, and coreutils), and updated as a noarch package with no other changes. The new files are in the "noarch" subdirectory at https://www.hamishmb.com/files/cygwin-temp/. I gave the noarch packages I built on 64-bit Cygwin a spin on 32-bit Cygwin too, all seems fine. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python-getdevinfo
On 03/09/2020 18:13, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > > Good to know, and oh yeah, I'll do that tomorrow. > > Cheers for the vote. > > Hamish > I should note that this is a pure python package - can it be a noarch package? I'm not sure how to configure the cygport file to build a noarch package. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python-getdevinfo
On 03/09/2020 17:34, Ken Brown via Cygwin-apps wrote: > On 9/3/2020 10:10 AM, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> On 03/09/2020 14:44, marco atzeri via Cygwin-apps wrote: >>> just to avoid misunderstandings, you have my vote, so >>> you need only other 3 approvals as you count as 1 >>> >>> Regards >>> Marco >> >> Thanks for your vote Marco :) Hopefully we can get some others onboard. > > +1 (but you need to add smartmontools to BUILD_REQUIRES) > > [...] > >> The "cygport deps | cat" command isn't working for me either, >> perhaps that's just doing automatic dependency resolution and ignoring >> what I set in my cygport file? I don't see that command when I run >> "cygport help" so I'm slightly fuzzy on exactly what it does. > > It's not documented, but you can what it does by looking at > /usr/bin/cygport. It just does automatic dependency resolution, as you > guessed. > > Ken Good to know, and oh yeah, I'll do that tomorrow. Cheers for the vote. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python-getdevinfo
On 03/09/2020 14:44, marco atzeri via Cygwin-apps wrote: > just to avoid misunderstandings, you have my vote, so > you need only other 3 approvals as you count as 1 > > Regards > Marco Thanks for your vote Marco :) Hopefully we can get some others onboard. Just double-checked dependencies, and both the cygport file and the resulting hint files are correct and depend on util-linux and smartmontools. That message is slightly wrong - blkid is in the util-linux package - I'll fix it in the git repository now. The "cygport deps | cat" command isn't working for me either, perhaps that's just doing automatic dependency resolution and ignoring what I set in my cygport file? I don't see that command when I run "cygport help" so I'm slightly fuzzy on exactly what it does. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python-getdevinfo
On 02/09/2020 19:05, Marco Atzeri via Cygwin-apps wrote: > > Hi Hamish, > > it builds fine and there are no problem on tests. > > Are you missing some dependencies ? > > "On Cygwin, you need the smartmontools and blkid packages". > > but they are not there: > > $ cygport python-getdevinfo.cygport deps|cat > python36-3.6.10-1 > python36-bs4-4.9.1-1 > python36-getdevinfo-1.1.0-1 > python37-3.7.7-1 > python37-bs4-4.9.1-1 > python37-getdevinfo-1.1.0-1 > python38-3.8.3-1 > python38-bs4-4.9.1-1 > python38-getdevinfo-1.1.0-1 > > > Is already in some Linux distribution ? > Otherwise we need 5 votes from maintainers Hi Marco, Thanks for testing again :) Ah yes, I'm not sure how I managed to do that, they should be in the cygport file. I'll sort that out tomorrow and notify this list again. It's not currently in the official repositories of a Linux distro no. I'm essentially only packaging this for Cygwin because it's a dependency for DDRescue-GUI, a GUI I wrote for GNU ddrescue. I currently release for Linux and macOS, and there has been demand for Cygwin, hence me getting involved with all of this in the beginning really. I would very much appreciate it if I could get 5 votes, but if not I'll create some kind of bundle instead. I understand that this is your project and you may not all want my program in it :) NB: In programs that bundle cygwin.dll, are the /dev and /cygdrive folders visible to access devices? I'm hoping the answer is yes because otherwise my bundle idea probably won't work. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python-getdevinfo
*bump* in case this has not been seen.
Hamish
On 26/08/2020 10:35, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> Okay, I have updated the packages (same location:
> https://www.hamishmb.com/files/cygwin-temp/). It should now handle fork
> errors better.
>
> If it fails again, please post the full output from the test command so
> I can see what version(s) of Python the tests are failing on. It might
> be useful for someone else to have a go as well - would be good to know
> multiple people can reproduce this issue as I have still had no luck
> doing that.
>
> Thanks for your patience,
>
> Hamish
>
> On 21/08/2020 16:33, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> On 20/08/2020 07:01, Marco Atzeri via Cygwin-apps wrote:
>>> On 19.08.2020 13:22, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>>>> On 19/08/2020 06:53, Marco Atzeri via Cygwin-apps wrote:
>>>>> something looks wrong on test
>>>>>
>>>>> ==
>>>>> ERROR: test_get_info (tests.getdevinfo_tests_cygwin.TestGetInfo)
>>>>> Test that the information can be collected on this system without error
>>>>> --
>>>>> Traceback (most recent call last):
>>>>> File
>>>>> "/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/src/getdevinfo-1.1.0/getdevinfo/tests/getdevinfo_tests_cygwin.py",
>>>>>
>>>>> line 218, in test_get_info
>>>>> cygwin.get_info()
>>>>> File
>>>>> "/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/build/getdevinfo/cygwin.py",
>>>>>
>>>>> line 101, in get_info
>>>>> get_device_info(disk)
>>>>> File
>>>>> "/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/build/getdevinfo/cygwin.py",
>>>>>
>>>>> line 135, in get_device_info
>>>>> cmd = subprocess.run([SMARTCTL, "-i", host_disk, "-j"],
>>>>> stdout=subprocess.PIPE,
>>>>> File "/usr/lib/python3.8/subprocess.py", line 489, in run
>>>>> with Popen(*popenargs, **kwargs) as process:
>>>>> File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
>>>>> self._execute_child(args, executable, preexec_fn, close_fds,
>>>>> File "/usr/lib/python3.8/subprocess.py", line 1637, in
>>>>> _execute_child
>>>>> self.pid = _posixsubprocess.fork_exec(
>>>>> BlockingIOError: [Errno 11] Resource temporarily unavailable
>>>>>
>>>>> --
>>>>> Ran 23 tests in 0.679s
>>>>>
>>>>> FAILED (errors=1)
>>>>> NOTE: These tests won't work correctly without administrator
>>>>> privileges.
>>>>>
>>>>> $ id
>>>>> uid=197609(Marco) gid=544(Administratoren)
>>>>> groups=544(Administratoren),197121(Kein)
>>>> Unfortunately I have not been able to reproduce this issue on my end
>>>> with either 32-bit or 64-bit Cygwin. What happens when you run
>>>> "/usr/sbin/smartctl.exe -i /dev/sda -j" (assuming /dev/sda is a disk
>>>> that Cygwin sees)? Note that the output may include the drive serial
>>>> number - make sure to blank it out if you post the output here.
>>>>
>>>> If this is on 32-bit Cygwin, this looks like the good old fork bug to
>>>> me, seeing as you're getting "11 Resource temporarily unavailable" when
>>>> attempting to fork. I can't remember what worked to fix that for me the
>>>> last time I had it, might have been antivirus software exceptions. I
>>>> would say that maybe some packages need updating, but given you've been
>>>> releasing packages in the last few days, I highly doubt your Cygwin
>>>> install is out of date.
>>>>
>>>> If the smartctl command works, could you try running the tests again
>>>> please?
>>>>
>>>> Hamish
>>>>
>>> /usr/sbin/smartctl.exe -i /dev/sda -j
>>>
>>> {
>>> "json_format_version": [
>>> 1,
>>> 0
>>> ],
>>> "smartctl": {
>>> &quo
Re: [ITP] python-getdevinfo
Okay, I have updated the packages (same location:
https://www.hamishmb.com/files/cygwin-temp/). It should now handle fork
errors better.
If it fails again, please post the full output from the test command so
I can see what version(s) of Python the tests are failing on. It might
be useful for someone else to have a go as well - would be good to know
multiple people can reproduce this issue as I have still had no luck
doing that.
Thanks for your patience,
Hamish
On 21/08/2020 16:33, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 20/08/2020 07:01, Marco Atzeri via Cygwin-apps wrote:
>> On 19.08.2020 13:22, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>>> On 19/08/2020 06:53, Marco Atzeri via Cygwin-apps wrote:
>>>> something looks wrong on test
>>>>
>>>> ==
>>>> ERROR: test_get_info (tests.getdevinfo_tests_cygwin.TestGetInfo)
>>>> Test that the information can be collected on this system without error
>>>> --
>>>> Traceback (most recent call last):
>>>> File
>>>> "/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/src/getdevinfo-1.1.0/getdevinfo/tests/getdevinfo_tests_cygwin.py",
>>>>
>>>> line 218, in test_get_info
>>>> cygwin.get_info()
>>>> File
>>>> "/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/build/getdevinfo/cygwin.py",
>>>>
>>>> line 101, in get_info
>>>> get_device_info(disk)
>>>> File
>>>> "/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/build/getdevinfo/cygwin.py",
>>>>
>>>> line 135, in get_device_info
>>>> cmd = subprocess.run([SMARTCTL, "-i", host_disk, "-j"],
>>>> stdout=subprocess.PIPE,
>>>> File "/usr/lib/python3.8/subprocess.py", line 489, in run
>>>> with Popen(*popenargs, **kwargs) as process:
>>>> File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
>>>> self._execute_child(args, executable, preexec_fn, close_fds,
>>>> File "/usr/lib/python3.8/subprocess.py", line 1637, in
>>>> _execute_child
>>>> self.pid = _posixsubprocess.fork_exec(
>>>> BlockingIOError: [Errno 11] Resource temporarily unavailable
>>>>
>>>> --
>>>> Ran 23 tests in 0.679s
>>>>
>>>> FAILED (errors=1)
>>>> NOTE: These tests won't work correctly without administrator
>>>> privileges.
>>>>
>>>> $ id
>>>> uid=197609(Marco) gid=544(Administratoren)
>>>> groups=544(Administratoren),197121(Kein)
>>>
>>> Unfortunately I have not been able to reproduce this issue on my end
>>> with either 32-bit or 64-bit Cygwin. What happens when you run
>>> "/usr/sbin/smartctl.exe -i /dev/sda -j" (assuming /dev/sda is a disk
>>> that Cygwin sees)? Note that the output may include the drive serial
>>> number - make sure to blank it out if you post the output here.
>>>
>>> If this is on 32-bit Cygwin, this looks like the good old fork bug to
>>> me, seeing as you're getting "11 Resource temporarily unavailable" when
>>> attempting to fork. I can't remember what worked to fix that for me the
>>> last time I had it, might have been antivirus software exceptions. I
>>> would say that maybe some packages need updating, but given you've been
>>> releasing packages in the last few days, I highly doubt your Cygwin
>>> install is out of date.
>>>
>>> If the smartctl command works, could you try running the tests again
>>> please?
>>>
>>> Hamish
>>>
>> /usr/sbin/smartctl.exe -i /dev/sda -j
>>
>> {
>> "json_format_version": [
>> 1,
>> 0
>> ],
>> "smartctl": {
>> "version": [
>> 7,
>> 1
>> ],
>> "svn_revision": "5022",
>> "platform_info": "x86_64-pc-cygwin-w10-b19041",
>> "build_info": "(cygwin-7.1-1)",
>> "argv": [
>> "smartctl",
>> "-i",
>> "/dev/sda",
>> "-j"
>> ],
>>
Re: [ITP] python-getdevinfo
On 20/08/2020 07:01, Marco Atzeri via Cygwin-apps wrote:
> On 19.08.2020 13:22, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> On 19/08/2020 06:53, Marco Atzeri via Cygwin-apps wrote:
>>>
>>> something looks wrong on test
>>>
>>> ==
>>> ERROR: test_get_info (tests.getdevinfo_tests_cygwin.TestGetInfo)
>>> Test that the information can be collected on this system without error
>>> --
>>> Traceback (most recent call last):
>>> File
>>> "/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/src/getdevinfo-1.1.0/getdevinfo/tests/getdevinfo_tests_cygwin.py",
>>>
>>> line 218, in test_get_info
>>> cygwin.get_info()
>>> File
>>> "/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/build/getdevinfo/cygwin.py",
>>>
>>> line 101, in get_info
>>> get_device_info(disk)
>>> File
>>> "/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/build/getdevinfo/cygwin.py",
>>>
>>> line 135, in get_device_info
>>> cmd = subprocess.run([SMARTCTL, "-i", host_disk, "-j"],
>>> stdout=subprocess.PIPE,
>>> File "/usr/lib/python3.8/subprocess.py", line 489, in run
>>> with Popen(*popenargs, **kwargs) as process:
>>> File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
>>> self._execute_child(args, executable, preexec_fn, close_fds,
>>> File "/usr/lib/python3.8/subprocess.py", line 1637, in
>>> _execute_child
>>> self.pid = _posixsubprocess.fork_exec(
>>> BlockingIOError: [Errno 11] Resource temporarily unavailable
>>>
>>> --
>>> Ran 23 tests in 0.679s
>>>
>>> FAILED (errors=1)
>>> NOTE: These tests won't work correctly without administrator
>>> privileges.
>>>
>>> $ id
>>> uid=197609(Marco) gid=544(Administratoren)
>>> groups=544(Administratoren),197121(Kein)
>>
>>
>> Unfortunately I have not been able to reproduce this issue on my end
>> with either 32-bit or 64-bit Cygwin. What happens when you run
>> "/usr/sbin/smartctl.exe -i /dev/sda -j" (assuming /dev/sda is a disk
>> that Cygwin sees)? Note that the output may include the drive serial
>> number - make sure to blank it out if you post the output here.
>>
>> If this is on 32-bit Cygwin, this looks like the good old fork bug to
>> me, seeing as you're getting "11 Resource temporarily unavailable" when
>> attempting to fork. I can't remember what worked to fix that for me the
>> last time I had it, might have been antivirus software exceptions. I
>> would say that maybe some packages need updating, but given you've been
>> releasing packages in the last few days, I highly doubt your Cygwin
>> install is out of date.
>>
>> If the smartctl command works, could you try running the tests again
>> please?
>>
>> Hamish
>>
>
> /usr/sbin/smartctl.exe -i /dev/sda -j
>
> {
> "json_format_version": [
> 1,
> 0
> ],
> "smartctl": {
> "version": [
> 7,
> 1
> ],
> "svn_revision": "5022",
> "platform_info": "x86_64-pc-cygwin-w10-b19041",
> "build_info": "(cygwin-7.1-1)",
> "argv": [
> "smartctl",
> "-i",
> "/dev/sda",
> "-j"
> ],
> "exit_status": 0
> },
> "device": {
> "name": "/dev/sda",
> "info_name": "/dev/sda",
> "type": "ata",
> "protocol": "ATA"
> },
> "model_family": "Seagate Mobile HDD",
> "model_name": "ST1000LM035-1RK172",
> "serial_number": "WL10S143",
> "wwn": {
> "naa": 5,
> "oui": 3152,
> "id": 2907615223
> },
> "firmware_version": "RSM7",
> "user_capacity": {
> "blocks": 1953525168,
> "bytes": 1000204886016
> },
> "logical_block_size": 512,
> "physical_block_size": 4096,
> &qu
Re: [ITA] mingw64-x86_64-curl, mingw64-i686-curl
On 21/08/2020 15:24, ASSI wrote: > Hamish McIntyre-Bhatty via Cygwin-apps writes: >> How does cross compiling for 32-bit Cygwin work? I think it'd be useful >> for me too - in one instance I've found that stripping debug symbols can >> take 3 times as long to run under 32-bit Cygwin. > I don't cross-compile to Cygwin, only to MingW. I believe there are > some packages that are cross-compiled from Linux, but with any of these > cross-compilation options you can't actually run the tests, so that is > the reason for not doing it for Cygwin (for me anyway). Also there's > quite a bunch of software out there that doesn't really like to be > cross-compiled and needs major effort to do so. > > > Regards, > Achim. Oh, I wasn't very clear. I meant using 64-bit Cygwin to compile for 32-bit Cygwin. Could be wrong but I'm pretty sure it's been mentioned before. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] mingw64-x86_64-curl, mingw64-i686-curl
On 20/08/2020 20:47, Brian Inglis wrote: > On 2020-08-20 12:18, Achim Gratz wrote: >> Brian Inglis writes: >>> Does it matter if I build mingw64 packages under Cygwin 64 or 32 bit: do I >>> have >>> to match the package being built, or does it not matter? >> FWIW, I build my cross-compiled packages under 64bit always regardless >> of the target architecture. No particular reason for doing it that way, >> but it turns out the compiles tend to be slightly faster on 64bit. > Thanks Achim, > > I'll do the same in future as more address space under 64, frees up some in > 32, > and reduces packages to update there. > How does cross compiling for 32-bit Cygwin work? I think it'd be useful for me too - in one instance I've found that stripping debug symbols can take 3 times as long to run under 32-bit Cygwin. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python-getdevinfo
On 19/08/2020 06:53, Marco Atzeri via Cygwin-apps wrote: > > something looks wrong on test > > == > ERROR: test_get_info (tests.getdevinfo_tests_cygwin.TestGetInfo) > Test that the information can be collected on this system without error > -- > Traceback (most recent call last): > File > "/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/src/getdevinfo-1.1.0/getdevinfo/tests/getdevinfo_tests_cygwin.py", > line 218, in test_get_info > cygwin.get_info() > File > "/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/build/getdevinfo/cygwin.py", > line 101, in get_info > get_device_info(disk) > File > "/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/build/getdevinfo/cygwin.py", > line 135, in get_device_info > cmd = subprocess.run([SMARTCTL, "-i", host_disk, "-j"], > stdout=subprocess.PIPE, > File "/usr/lib/python3.8/subprocess.py", line 489, in run > with Popen(*popenargs, **kwargs) as process: > File "/usr/lib/python3.8/subprocess.py", line 854, in __init__ > self._execute_child(args, executable, preexec_fn, close_fds, > File "/usr/lib/python3.8/subprocess.py", line 1637, in _execute_child > self.pid = _posixsubprocess.fork_exec( > BlockingIOError: [Errno 11] Resource temporarily unavailable > > -- > Ran 23 tests in 0.679s > > FAILED (errors=1) > NOTE: These tests won't work correctly without administrator privileges. > > $ id > uid=197609(Marco) gid=544(Administratoren) > groups=544(Administratoren),197121(Kein) Unfortunately I have not been able to reproduce this issue on my end with either 32-bit or 64-bit Cygwin. What happens when you run "/usr/sbin/smartctl.exe -i /dev/sda -j" (assuming /dev/sda is a disk that Cygwin sees)? Note that the output may include the drive serial number - make sure to blank it out if you post the output here. If this is on 32-bit Cygwin, this looks like the good old fork bug to me, seeing as you're getting "11 Resource temporarily unavailable" when attempting to fork. I can't remember what worked to fix that for me the last time I had it, might have been antivirus software exceptions. I would say that maybe some packages need updating, but given you've been releasing packages in the last few days, I highly doubt your Cygwin install is out of date. If the smartctl command works, could you try running the tests again please? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python-getdevinfo
On 17/08/2020 14:33, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > Hello, > > This email signals my intent to package getdevinfo. > > (https://www.hamishmb.com/html/downloads.php?program_name=getdevinfo) > for Cygwin. > > getdevinfo is module I wrote for collecting device information, and is a > dependency for DDRescue-GUI, which I intend to package next if this is > approved. > > Once I have done these things, I intend to improve Cygwin's device > information detection capabilities and release a further update to make > this more complete. > > If anyone has feedback I'd appreciate it very much. > > Hamish McIntyre-Bhatty > Forgot link to packages: https://www.hamishmb.com/files/cygwin-temp/ 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
[ITP] python-getdevinfo
Hello, This email signals my intent to package getdevinfo. (https://www.hamishmb.com/html/downloads.php?program_name=getdevinfo) for Cygwin. getdevinfo is module I wrote for collecting device information, and is a dependency for DDRescue-GUI, which I intend to package next if this is approved. Once I have done these things, I intend to improve Cygwin's device information detection capabilities and release a further update to make this more complete. If anyone has feedback I'd appreciate it very much. Hamish McIntyre-Bhatty 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Requesting a Python 3.8 build of python-bs4
On 15/08/2020 16:35, Marco Atzeri via Cygwin-apps wrote: > On 15.08.2020 15:32, Achim Gratz wrote: >> Hamish McIntyre-Bhatty via Cygwin-apps writes: >>> Who currently maintains python-bs4? >> >> Yaakov. You can find out for yourself by looking at cygwin-pkg-maint on >> the server. >> >> >> Regards, >> Achim. >> > > > Pratically all Yaakov packages are for adoption. > > Hamish, > I will look on python-bs4 > > Regards > Marco > Thank you Marco :) Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Requesting a Python 3.8 build of python-bs4
On 15/08/2020 14:32, Achim Gratz wrote: > Hamish McIntyre-Bhatty via Cygwin-apps writes: >> Who currently maintains python-bs4? > Yaakov. You can find out for yourself by looking at cygwin-pkg-maint on > the server. > > > Regards, > Achim. Oh yeah, I forgot that. Does anyone else want to adopt this, seeing as Yaakov is no longer maintaining? I'm happy to do a one-time build, but I'm unlikely to update this regularly, so it'd probably be better for someone else to adopt it. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Requesting a Python 3.8 build of python-bs4
Hello, Who currently maintains python-bs4? Marco, if this is you I might have to take you up on your offer and ask you to build a package for Python 3.8 :) If not I guess I'll do a one-time update to build for Python 3.8. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Requesting a Python 3.8 build of python-requests
On 23/07/2020 12:02, marco atzeri via Cygwin-apps wrote: > On Thu, Jul 23, 2020 at 11:33 AM Hamish McIntyre-Bhatty via Cygwin-apps > wrote: >> Hello, >> >> Who currently maintains python-requests? Marco, if this is you I might >> have to take you up on your offer and ask you to build a package for >> Python 3.8 :) >> >> If not I guess I'll do a one-time update to build for Python 3.8. >> >> Hamish >> > Noted, > I am adopting python packages step by step as I build them > give me some time as I will need to build some required packages > > see @ python37-requests on setup.ini > requires: ca-certificates python37 python37-chardet python37-idna > python37-urllib3 > > and probably some others are needed recursively Cheers, and yeah absolutely no rush or pressure - we're all volunteers :). Everything for my GUI seems to be working on Python 3.7 anyway, so I can just update it for 3.8 later if needs be. I have some other stuff to fix anyway, I'm expecting it to take a little while. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Requesting a Python 3.8 build of python-requests
Hello, Who currently maintains python-requests? Marco, if this is you I might have to take you up on your offer and ask you to build a package for Python 3.8 :) If not I guess I'll do a one-time update to build for Python 3.8. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] python-imaging
On 19/07/2020 20:09, Marco Atzeri via Cygwin-apps wrote: > https://cygwin.mirror.uk.sargasso.net/noarch/release/python-olefile/ > > same packages are arch indipendent Ah of course, so I was being a bit stupid :) Okay, it ended up being today because python3-wx took so long to build, but test packages are now out for both python3-wx (a python 3.8 build) and python-imaging 7.2.0. Let me know if you have any issues. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] python-imaging
On 19/07/2020 18:09, Marco Atzeri via Cygwin-apps wrote: > I assume you need to rebuild, as I saw python36-olefile and > python37-olefile picked as dependency, so somewhere they were mentioned > in the packages. Okay, shall do tomorrow then. I note that while I can find the source and binary packages for olefile on cygwin.com, it doesn't seem to be on mirrors eg https://cygwin.mirror.uk.sargasso.net/x86/release/. Am I being a bit stupid? > > If you plan to build other packages and you are missing a dependency > on any 3.8 subpackages let me know and I will put those > on top of the plan Cheers, was going to suggest Numpy for Python 3.8, but looks like you did that earlier today :). Guess I'll get a Python 3.8 build of wxPython out too. With some luck (and some more debugging), I can have a version of my GUI (DDRescue-GUI) out on Cygwin pretty soon. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] python-imaging
On 18/07/2020 21:07, Marco Atzeri via Cygwin-apps wrote: > I change maintainership to you. > > Before uploading can you rebuild so to pick dependency on all > version of python3x-olefile ? Sure. I believe I can just change the cygport and hint files rather than rebuilding for that? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] python-imaging
On 14/07/2020 15:41, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 10/07/2020 13:24, marco atzeri via Cygwin-apps wrote:
>> On Fri, Jul 10, 2020 at 12:28 PM Hamish McIntyre-Bhatty via Cygwin-apps
>> wrote:
>>> On 10/07/2020 01:20, airplanemath via Cygwin-apps wrote:
>>>>> I tend to use loops like
>>>>>
>>>>> for ver in ${PYTHON_WHEEL_VERSIONS//:/ };
>>>>> do
>>>>> /usr/bin/python${ver} script
>>>>> done
>>>>>
>>>>> for the tests. Also, I believe ${ARCH} is the same as $(uname -m) here,
>>>>> if you want to streamline the PYTHONPATH definition a bit. Both of
>>>>> those are personal style and you are entirely welcome to ignore this.
> This worked a treat.
>>>>> Other than that, I noticed you're writing your own src_compile and
>>>>> src_install. Is there some reason python_wheel_compile and
>>>>> python_wheel_install aren't working for you? I haven't noticed a problem
>>>>> with either of those functions in the past year or so. (For reference,
>>>>> the
>>>>> value of PYTHON_WHEEL_VERSIONS determines which python versions
>>>>> are compiled: see
>>>>> https://cygwin.github.io/cygport/python-wheel_cygclass.html#robo361).
>>>>>
> This also worked really well, thanks for the tip :)
>
>> I am not bothering with 3.5 for my builds.
>> The focus should be to have 3.8 up and running
>> so 3.6:3.7:3.8 are enough
> Okay. I've updated my test packages, and they are available at
> https://www.hamishmb.com/files/cygwin-temp/ as before. Please let me
> know if I'm now good to go or if there are any more issues.
*bump* in case no one has seen.
Hamish
0x87B761FE07F548D6.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Re: [ITA] python-imaging
On 10/07/2020 13:24, marco atzeri via Cygwin-apps wrote:
> On Fri, Jul 10, 2020 at 12:28 PM Hamish McIntyre-Bhatty via Cygwin-apps
> wrote:
>> On 10/07/2020 01:20, airplanemath via Cygwin-apps wrote:
>>>> I tend to use loops like
>>>>
>>>> for ver in ${PYTHON_WHEEL_VERSIONS//:/ };
>>>> do
>>>> /usr/bin/python${ver} script
>>>> done
>>>>
>>>> for the tests. Also, I believe ${ARCH} is the same as $(uname -m) here,
>>>> if you want to streamline the PYTHONPATH definition a bit. Both of
>>>> those are personal style and you are entirely welcome to ignore this.
This worked a treat.
>>>> Other than that, I noticed you're writing your own src_compile and
>>>> src_install. Is there some reason python_wheel_compile and
>>>> python_wheel_install aren't working for you? I haven't noticed a problem
>>>> with either of those functions in the past year or so. (For reference, the
>>>> value of PYTHON_WHEEL_VERSIONS determines which python versions
>>>> are compiled: see
>>>> https://cygwin.github.io/cygport/python-wheel_cygclass.html#robo361).
>>>>
This also worked really well, thanks for the tip :)
> I am not bothering with 3.5 for my builds.
> The focus should be to have 3.8 up and running
> so 3.6:3.7:3.8 are enough
Okay. I've updated my test packages, and they are available at
https://www.hamishmb.com/files/cygwin-temp/ as before. Please let me
know if I'm now good to go or if there are any more issues.
Hamish
0x87B761FE07F548D6.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Re: [ITA] python-imaging
On 10/07/2020 01:20, airplanemath via Cygwin-apps wrote:
>> I tend to use loops like
>>
>> for ver in ${PYTHON_WHEEL_VERSIONS//:/ };
>> do
>> /usr/bin/python${ver} script
>> done
>>
>> for the tests. Also, I believe ${ARCH} is the same as $(uname -m) here,
>> if you want to streamline the PYTHONPATH definition a bit. Both of
>> those are personal style and you are entirely welcome to ignore this.
Originally it was using a loop like that for the tests, but for some
reason not all of the Python versions I wanted to build for were being
tested that way (it was only doing 3.7 and 3.8). I figure I might as
well use ARCH then, makes it a bit clearer.
>> Other than that, I noticed you're writing your own src_compile and
>> src_install. Is there some reason python_wheel_compile and
>> python_wheel_install aren't working for you? I haven't noticed a problem
>> with either of those functions in the past year or so. (For reference, the
>> value of PYTHON_WHEEL_VERSIONS determines which python versions
>> are compiled: see
>> https://cygwin.github.io/cygport/python-wheel_cygclass.html#robo361).
Ah, thank you for that link, that clears things up for me. I didn't
realise I could do that. So, I can just set PYTHON_WHEEL_VERSIONS to
"3.6:3.7:3.8" to build for those versions? I guess I don't need the
custom functions that way, that would make things simpler.
So far I've built for Python 3.6 and newer, should I also be building
for 3.5 or are we not bothered at this point?
>> Thank you for taking up this package.
You're welcome, and thanks for the advice :)
Hamish
0x87B761FE07F548D6.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
[ITA] python-imaging
Hello,
This email signals my intent to adopt python-imaging
(https://pypi.org/project/Pillow) for Cygwin, as after being informed by
Yaakov I have realised there was already a Cygwin package for this.
I wish to package this because I have found that PyCrust (built with
wxPython) depends on it and there is a much newer version than is
currently available for Cygwin.
Attached is my cygport file. As usual, the test packages are available
at https://www.hamishmb.com/files/cygwin-temp/.
If anyone has feedback I'd appreciate it very much.
Hamish McIntyre-Bhatty
ORIG_PN="Pillow"
inherit python-wheel
NAME="python-imaging"
VERSION=7.2.0
RELEASE=1
CATEGORY="Python"
SUMMARY="Python Imaging Library"
DESCRIPTION="The Python Imaging Library (PIL) adds image processing capabilities
to your Python interpreter. This library supports many file formats, and
provides
powerful image processing and graphics capabilities."
HOMEPAGE="https://python-pillow.github.io/;
SRC_URI="https://files.pythonhosted.org/packages/3e/02/b09732ca4b14405ff159c470a612979acfc6e8645dc32f83ea0129709f7a/Pillow-7.2.0.tar.gz;
SRC_DIR="Pillow-${VERSION}"
PATCH_URI=""
BUILD_REQUIRES="libjpeg-devel libjpeg8 zlib-devel zlib0 libtiff-devel libtiff6
libfreetype-devel libfreetype6 liblcms2-devel lcms2 libwebp libwebp-devel
tcl-devel tcl libimagequant-devel libimagequant0 libraqm-devel libraqm0
libX11-xcb-devel libX11-xcb1 libxcb-devel libxcb1 python36 python36-devel
python36-setuptools python36-wheel python36-pip python37 python37-devel
python37-setuptools python37-wheel python37-pip python38 python38-devel
python38-setuptools python38-wheel python38-pip"
DIFF_EXCLUDES="build"
PKG_NAMES=" python36-imaging python36-imaging-tk"
PKG_NAMES+=" python37-imaging python37-imaging-tk"
PKG_NAMES+=" python38-imaging python38-imaging-tk"
# ImageQt no longer imports PyQt or PySide, but simply integrates with
# whatever has already been imported. Therefore there is no need to
# break it out separately, as it has no hard dependencies of its own.
python36_imaging_OBSOLETES+=" python3-imaging-devel python3-imaging-qt"
python36_imaging_CONTENTS="
--exclude=_imagingtk*
--exclude=ImageTk*
--exclude=SpiderImagePlugin*
usr/lib/python3.6/site-packages/PIL/
usr/lib/python3.6/site-packages/Pillow-${VERSION}-py3.6.egg-info/
usr/share/doc/python36-imaging/
"
python36_imaging_tk_OBSOLETES="python3-imaging-tk"
python36_imaging_tk_REQUIRES="python36-tkinter"
python36_imaging_tk_CONTENTS="
usr/lib/python3.6/site-packages/PIL/_imagingtk*
usr/lib/python3.6/site-packages/PIL/ImageTk*
usr/lib/python3.6/site-packages/PIL/SpiderImagePlugin*
usr/lib/python3.6/site-packages/PIL/__pycache__/ImageTk*
usr/lib/python3.6/site-packages/PIL/__pycache__/SpiderImagePlugin*
"
python37_imaging_CONTENTS="
--exclude=_imagingtk*
--exclude=ImageTk*
--exclude=SpiderImagePlugin*
${python37_imaging_CONTENTS}
"
python37_imaging_tk_REQUIRES="python37-tkinter"
python37_imaging_tk_CONTENTS="
usr/lib/python3.7/site-packages/PIL/_imagingtk*
usr/lib/python3.7/site-packages/PIL/ImageTk*
usr/lib/python3.7/site-packages/PIL/SpiderImagePlugin*
usr/lib/python3.7/site-packages/PIL/__pycache__/ImageTk*
usr/lib/python3.7/site-packages/PIL/__pycache__/SpiderImagePlugin*
"
python38_imaging_CONTENTS="
--exclude=_imagingtk*
--exclude=ImageTk*
--exclude=SpiderImagePlugin*
${python38_imaging_CONTENTS}
"
python38_imaging_tk_REQUIRES="python38-tkinter"
python38_imaging_tk_CONTENTS="
usr/lib/python3.8/site-packages/PIL/_imagingtk*
usr/lib/python3.8/site-packages/PIL/ImageTk*
usr/lib/python3.8/site-packages/PIL/SpiderImagePlugin*
usr/lib/python3.8/site-packages/PIL/__pycache__/ImageTk*
usr/lib/python3.8/site-packages/PIL/__pycache__/SpiderImagePlugin*
"
python_imaging_debuginfo_OBSOLETES="python3-imaging-debuginfo"
PKG_IGNORE="usr/share/doc/python*-imaging-*/"
src_compile() {
lndirs
cd ${B}
echo "Building for Python 3.6..."
python3.6 setup.py build
echo "Building for Python 3.7..."
python3.7 setup.py build
echo "Building for Python 3.8..."
python3.8 setup.py build
}
src_test() {
cd ${B}
PYTHONPATH="build/lib.cygwin-$(uname -r | sed -e 's|s*(.*||')-$(uname
-m)-3.6/" python3.6 selftest.py
PYTHONPATH="build/lib.cygwin-$(uname -r | sed -e 's|s*(.*||')-$(uname
-m)-3.7/" python3.7 selftest.py
PYTHONPATH="build/lib.cygwin-$(uname -r | sed -e 's|s*(.*||')-$(uname
-m)-3.8/" python3.8 selftest.py
}
src_install() {
cd ${B}
# Python 3.6
python3.6 setup.py install --single-version-externally-managed --root
${D}
# Python 3.7
python3.7 setup.py install --single-version-externally-managed --root ${D}
# Python 3.8
Re: [ITP] python3-pillow
On 05/07/2020 23:21, Yaakov Selkowitz wrote: > On Fri, 2020-06-26 at 01:49 +0100, Hamish McIntyre-Bhatty via Cygwin- > apps wrote: >> This email signals my intent to package python3-pillow >> (https://pypi.org/project/Pillow) for Cygwin. Pillow is a fork of the >> Python Imaging Library. >> >> I wish to package this because I have found that PyCrust (built with >> wxPython) depends on Pillow and won't run without it installed. As >> before, my test packages can be found at >> https://www.hamishmb.com/files/cygwin-temp/. >> >> If anyone has feedback I'd appreciate it very much. > 1) Source packages are generally named python-*. Yes, but the latest build of Pillow doesn't support Python 2 - I feel calling it python-pillow would be misleading. > 2) This should be an ITA for python-imaging instead, which has been > Pillow-based for a long time. The Python imaging library was replaced by Pillow as far as I can tell, and seems to have been unmaintained since 2011. Could you give me a link to the library you're talking about please? Either way, wxPython specifically needs Pillow. I can also build the imaging library if you want though. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITP] python3-pillow
On 26/06/2020 01:49, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > Hello, > > This email signals my intent to package python3-pillow > (https://pypi.org/project/Pillow) for Cygwin. Pillow is a fork of the > Python Imaging Library. > > I wish to package this because I have found that PyCrust (built with > wxPython) depends on Pillow and won't run without it installed. As > before, my test packages can be found at > https://www.hamishmb.com/files/cygwin-temp/. > > If anyone has feedback I'd appreciate it very much. > > Hamish McIntyre-Bhatty > *bump* in case no one has seen this. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
[ITP] python3-pillow
Hello, This email signals my intent to package python3-pillow (https://pypi.org/project/Pillow) for Cygwin. Pillow is a fork of the Python Imaging Library. I wish to package this because I have found that PyCrust (built with wxPython) depends on Pillow and won't run without it installed. As before, my test packages can be found at https://www.hamishmb.com/files/cygwin-temp/. If anyone has feedback I'd appreciate it very much. Hamish McIntyre-Bhatty 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
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
> 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 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 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
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 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 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: Cygport user guide
On 09/06/2020 16:55, marco atzeri wrote: > I suspect the user base is too small to justify the effort and I am afraid > every > major package needs a different approach. > My octave and all other math programs know-how does not apply to the > python effort I am working on ;-) > > From my side, I mainly learned by looking at Yaakov's packages as guidelines. > > Any specific argument are you looking for ? > > Regards > Marco Ah I see, that is fair enough. That's how I'm learning too - glad I'm not the only one who gets a bit confused at times :) I was looking for information on PYTHON3_SITELIB but I have since worked out that it always just points to Python 3.6's sitelib folder. Still raises the question of how to handle building libraries/modules for py3.7 and 3.8, but I guess most will wait until 3.7 or 3.8 becomes the default version (?). Thanks, Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
[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
Cygport user guide
In the process of making my cygport file for wxPython 4, I've quite quickly found that I don't understand how cygport works all that well. The reference guide is extremely useful, but it's a bit tricky finding which things are useful/relevant. Is there a user guide for Cygport/could we make one (I'd be happy to help)? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Query about cygport and PYTHON3_SITELIB variable
Hi, In the process of making a cygport file for wxPython 4, I've found that I can make use of the PYTHON3-SITELIB (and similar) variables. However, I don't know what version of Python 3 these point to, seeing as they all have separate folders for this. Unless I'm mistaken, there don't seem to be eg PYTHON36-SITELIB or PYTHON37-SITELIB variables, so I'm not sure how to specify which version of Python 3 I'm building/packaging for. Any ideas? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA from Yaakov] python-wx
Okay, no issues were reported so I've marked it as stable now. All should now be sorted for this package, so I'll move on to wxPython 4. Cheers for all the help and support everyone. Hamish McIntyre-Bhatty 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: git repositories for cygwin packaging - please test
> 04.08.2019 21:08, Jon Turney wrote: >> While a number of maintainers keep their cygwin packaging under some >> sort of version control, there is currently no central collection of >> these repositories. >> >> To remedy this lack, using the same ssh key you use for sftp package >> upload, package maintainers can now also push to git repositories, like so: >> >> git push cyg...@cygwin.com:/git/cygwin-packages/ >> >> where is a package name you are listed as a maintainer for >> in http://cygwin.com/cygwin-pkg-maint. >> >> These repositories are lazily created on the first push. >> >> Since it's intended that these repositories will only contain cygport >> scripts, patches, and other packaging files, and to prevent the >> accidental committing of upstream archives, pushes containing large >> binary files will be rejected. >> >> These repositories are viewable via gitweb at >> https://cygwin.com/git-cygwin-packages/ (URL may be subject to change), >> and should be cloneable via anonymous git/http with the URLs shown there. >> >> Please give this a test, if possible, and report any problems here. Works well for me, thank you. I was just wondering how I was going to update the cygport and patches, so very useful. Hamish McIntyre-Bhatty 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA from Yaakov] python-wx
On 25/05/2020 14:28, Jon Turney wrote: > On 25/05/2020 13:45, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> On 17/05/2020 20:49, Marco Atzeri via Cygwin-apps wrote: >>> On 17.05.2020 21:37, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >>>> NB: Tested the SSH key and it seems to be working just fine. >>>> >>>> Should I upload this as a testing package or go straight for a normal >>>> package? I'm not sure how announcements work for testing packages. >>>> >>>> Hamish >>>> >>> >>> same as normal Announce, just use the tag "Test" >>> >>> https://sourceware.org/pipermail/cygwin-announce/2020-April/009511.html >> >> Apologies Marco - accidentally send only to you at first. >> >> Okay, all done, but I don't think my announcement has made it through. >> >> >> I'm not sure how long it takes, but it doesn't seem to be in the >> archives yet. > > Unfortunately, the announce list is moderated by humans, not robots. Okay, good to know :) 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA from Yaakov] python-wx
On 17/05/2020 20:49, Marco Atzeri via Cygwin-apps wrote: > On 17.05.2020 21:37, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> NB: Tested the SSH key and it seems to be working just fine. >> >> Should I upload this as a testing package or go straight for a normal >> package? I'm not sure how announcements work for testing packages. >> >> Hamish >> > > same as normal Announce, just use the tag "Test" > > https://sourceware.org/pipermail/cygwin-announce/2020-April/009511.html Apologies Marco - accidentally send only to you at first. Okay, all done, but I don't think my announcement has made it through. I'm not sure how long it takes, but it doesn't seem to be in the archives yet. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA from Yaakov] python-wx
On 15/05/2020 09:10, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > On 15/05/2020 00:47, Yaakov Selkowitz wrote: >> This looks fine. > I'm glad. What do I do next? Do I need to upload and mark as a testing > package or similar? >>> Seeing as I have no need to rebuild wxWidgets, I guess that can stay >>> under your maintainership until an update is needed, at which point >>> I'll be happy to pick it up. >> Let's discuss it then. >> >> -- >> Yaakov >> > If you don't want maintainership of it I'm happy to take it, but I won't > push an update until we need one. > > The new version of wxPython needs wxWidgets 3.1.x, so I'll probably be > packaging that soonish anyway, but I'll work on wxPython 4.0.7 first > because it's closer to what's already present in Cygwin. > > Hamish > NB: Tested the SSH key and it seems to be working just fine. Should I upload this as a testing package or go straight for a normal package? I'm not sure how announcements work for testing packages. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA from Yaakov] python-wx
On 15/05/2020 00:47, Yaakov Selkowitz wrote: > This looks fine. I'm glad. What do I do next? Do I need to upload and mark as a testing package or similar? >> Seeing as I have no need to rebuild wxWidgets, I guess that can stay >> under your maintainership until an update is needed, at which point >> I'll be happy to pick it up. > Let's discuss it then. > > -- > Yaakov > If you don't want maintainership of it I'm happy to take it, but I won't push an update until we need one. The new version of wxPython needs wxWidgets 3.1.x, so I'll probably be packaging that soonish anyway, but I'll work on wxPython 4.0.7 first because it's closer to what's already present in Cygwin. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
SSH key for Hamish McIntyre-Bhatty
Name: Hamish McIntyre-Bhatty BEGIN SSH2 PUBLIC KEY Comment: "8192-bit RSA, converted by hamish@hamish-HP-bw024na from Ope" B3NzaC1yc2EDAQABAAAEAQDbP8s1z+JIpAtj8E+Xzy3YlGZxXVLMuGb8YLy1XF gISiZFIChQFzRCRDDHLb7KvuFThlA0YqQdz8yJcW1Ko+2DYx1pPKtBq3mD2WZ9kU0pp8mP fPg6YOqC0BZX7J0DQ3EqqkymHsygUjpH5lFnHj/Hi02B5hoN3/5BuNAIMNYO+oEhEkEjGF HErAKDCOWSziu/wEf/XdQpqc+Zh9gn9HuOsMPxLFwLt3MtiAdkZHwTf1Sb5fZUHHet7e41 yFy2BIg04SKY7Sx6HGd+vJb1HwKRyURbitxe5ZZng14qOxI0cAf2c8J8bZmqdcRK5MO0OZ AYBFeSUhZLTU+O+5js+K+O9vlCPSvRokqm3/gZltf7dYp/YgMO/N9FF0uoVELxrlF0KEMw mDakIYJ+eEi4qWx5wQrSYyVKGmnUMAQ1sLulEkvMFmx8wVZWqqJrQXJR+TVGmm+XmmW5e9 HWFcHwzQfTD5uQ1AOudIQ0JB1HkmtXXijrrBa9z7hY6D1Zet7hZ1Fu92G7NmSiDf4Uraxr dul5ragwmzd6AmHwpCl758JgRR34wNsuF3bX3Mdr2cbgNa4peQACxnx62C8hMT2bGhpSrm 3TCJIaRGUvZQ6yFiGoWRde68aGtwj0FGQccOTyopeNVDXzoqBqcbtnFieyzSj/q6QEOnq9 81vMntdqgnvgSESIeaW2Lldu1zCdLGGPZJMlAquiL5+8c7ajda9HJ17eC0eStkUN/RpTqu Wnvq8ME6DfEMYxMEilnfawN2U3GOqkUd17dpVotQfeOZQrgbizsLFaH9c5HN8pptiKKG4u zKyJCixP3a0O1EEhisf16DdMKLW/8I1AfxEG8hCouP3wHP6dpRH8zrAOfMRggHc0M/7GKt WUL64/jADrXb6A5R7Tmjt5IWb7ts1O3MFVoBnSFDDs75mI/7jneETCuNNuO/cmzYzwKc/n KepXrsw5pZtyc9cBODOmcX5M39hAssJdS1Wzk2Ym5DLyO3c3RNXhx2W2lb68y4vTz4doOt SZVGxOPnnjvLLpynBhe5ZPhis+0DOr04taNJw4cRrE4W8WyUHbAXIfkRmutwZ5ROuObbaw 7lDXfzLkZi/O7b5L3eXHHL04fQC0bPpsjUwoR3w/ssPfBEjU0eu2wvn/1xkZbmoOcawKK+ lRucWZaI3XLyg8JiyWoWkQ01fFtNpgPNR2jZ9IllYbixpvwziXYgV54FWl/9Utwpyyw221 uaSq+gLnJ2ynnnT8cbQtqJrTEQL0jb4XhL+6emPnE3D+XzvD0ZmE3d7gQJv7I2Us4nS10/ C4NbaGMEHISk5gevImvH8B9J+58+piIzcccUNMbXmmwrjjBtCgzf2xSOQ9O0YklXJr END SSH2 PUBLIC KEY 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
[ITA from Yaakov] python-wx
Apologies for bumping this again, I'm just waiting for this to be done before I start on wxPython 4, which is blocking progress for me doing other things. If you're not interested in this fix, just let me know and I'll move on to wxPython 4. I have re-built the packages using your new cygport as the starting point, and it seems to work really well. I made some minor modifications to include the license files and the new patches from Fedora. The new files are available at https://www.hamishmb.com/files/cygwin-temp/ and I have removed the previous attempt's files. Seeing as I have no need to rebuild wxWidgets, I guess that can stay under your maintainership until an update is needed, at which point I'll be happy to pick it up. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] python2-wx and related packages for wxPython and wxwidgets
Just bumping in case interested people haven't seen - I've been having issues with email lately so it may not have sent. Not intending to pester anyone though - I know you're all busy, especially in these strange times. Hamish On 24/04/2020 12:24, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > On 23/04/2020 19:52, Yaakov Selkowitz wrote: >> The work to split them out is already published: >> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/wxWidgets3.0.git >> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/python-wx.git >> >> I suppose I just never needed to actually rebuild python-wx after that, >> but the work was done in preparation. > Makes sense. >> Fair enough. python-sip will need to be updated for that as well, >> which requires also updating python-pyqt5* in sync therewith, so this >> will need to be coordinated. > Okay, good to know. I did manage to get it to compile eventually, but I > had an issue where it would say "dlopen: no such process" when trying to > import the module. Perhaps using an older version of SIP is responsible > for that. > > I have re-build the packages using your new cygport as the starting > point, and it seems to work really well. I made some minor modifications > to include the license files and the new patches from Fedora. The new > files are available at https://www.hamishmb.com/files/cygwin-temp/ and I > have removed the previous attempt's files. > > Seeing as I have no need to rebuild wxWidgets, I guess that can stay > under your maintainership until an update is needed. I'm happy to pick > it up when needed though, especially with the split packaging making > things easier. > > Hamish > 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] python2-wx and related packages for wxPython and wxwidgets
On 23/04/2020 19:52, Yaakov Selkowitz wrote: > The work to split them out is already published: > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/wxWidgets3.0.git > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/python-wx.git > > I suppose I just never needed to actually rebuild python-wx after that, > but the work was done in preparation. Makes sense. > Fair enough. python-sip will need to be updated for that as well, > which requires also updating python-pyqt5* in sync therewith, so this > will need to be coordinated. Okay, good to know. I did manage to get it to compile eventually, but I had an issue where it would say "dlopen: no such process" when trying to import the module. Perhaps using an older version of SIP is responsible for that. I have re-build the packages using your new cygport as the starting point, and it seems to work really well. I made some minor modifications to include the license files and the new patches from Fedora. The new files are available at https://www.hamishmb.com/files/cygwin-temp/ and I have removed the previous attempt's files. Seeing as I have no need to rebuild wxWidgets, I guess that can stay under your maintainership until an update is needed. I'm happy to pick it up when needed though, especially with the split packaging making things easier. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [ITA] python2-wx and related packages for wxPython and wxwidgets
On 23/04/2020 17:08, Yaakov Selkowitz wrote: > Please keep all discussion on list. > My apologies, I thought I'd sent the reply to the list. > Most of that has already been figured out in our python-wx package. > Looking at Fedora, it looks like we just need to add their wxPython- > 3.0.2.0-suppress-version-mismatch-warning.patch and wxPython-3.0.2.0- > fix-wxcairo.patch and we'll be in sync. > Okay, I'll add those patches. I think I've gotten confused somehow, because my cygport and files are based on the source package for python-wx at http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/python-wx/, but the cygport in that archive also builds all of the other packages, and doesn't use the system wxWidgets headers, hence me hacking in the wxWidgets 3.0.4 files and having to build everything together. wxPython 3.0.2 itself is shipped with wxWidgets 3.0.2 in the tarball from wxpython.org, and seems to insist upon building its own copy of wxwidgets. > No, that's just bound to cause problems. > This is confusing me because it seems to be what the existing packages do. > Look forward to the follow up. > > BTW, did you have any plans to figure out wxPython4? Good to hear. I do, I just haven't had the time yet and I figured it'd be best to get wxPython 3 in really good shape (and get some practice with packaging!) before sorting that one out. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
[ITA] python2-wx and related packages for wxPython and wxwidgets
Hi all, I've gotten a more stable build of wxPython 3.0.2 and wxWidgets 3.0.4 to build now. wxPython is now also built against the version of wxWidgets that is installed on the system, avoiding ABI mismatch warnings and strange behaviour/freezes hat I was experiencing before. The test packages can be downloaded from https://hamishmb.com/files/cygwin-temp/. I say "various other packages", because building wxPython also builds the following packages: libwx_baseu3.0_0, libwx_gtk3u3.0-devel, python-wxversion, libwx_baseu3.0-devel, python2-wx, libwx_gtk2u3.0_0, python2-wxversion, libwx_gtk2u3.0-devel, python-wx3.0, wxWidgets3.0-debuginfo, libwx_gtk3u3.0_0, python-wx-tools The build process is a bit strange because wxPython 3.0.2 ships with wxWidgets 3.0.2 instead of the system version (3.0.4), so my build script downloads and re-patches the wxWidgets source before proceeding with the build. As a result of using wxWidgets 3.0.4 instead of 3.0.2, many patches are no longer needed as they were included upstream. Removed patches and the reason for removal are listed at the end of this email. I've probably got some of this wrong, but it does seem to work well at least :) I eagerly await feedback - I'm sure there's some stuff I could improve in this packaging, and I'm excited to soon be maintaining some Cygwin packages. Patches removed and the reasons why: http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-abicheck.patch - No longer needed as we're now using the same ABI for runtime and build versions. http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-upstreamfixes.patch - No longer needed in new wxwidgets source - already applied. http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-getbestsize.patch - No longer needed in new wxwidgets source - already applied. http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-media-docs.patch?h=f25 - No longer needed in new wxwidgets source - already applied. http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-size-alloc-fix.patch - No longer needed in new wxwidgets source - already applied. http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-font-enumerator-stop.patch - No longer needed in new wxwidgets source - already applied. http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-init-from-font.patch: - No longer needed in new wxwidgets source - already applied. http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-gtk-show-uri1.patch - No longer needed in new wxwidgets source - already applied. http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-draw-elliptic-arc-crash.patch - No longer needed in new wxwidgets source - already applied. http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-fix-percent-dnd2.patch - No longer needed in new wxwidgets source - already applied. http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-scrolwin-sizing-loop.patch - No longer needed in new wxwidgets source - already applied. http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-background-color.patch?h=f25 - No longer needed in new wxwidgets source - already applied. http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-paint-clipping-region.patch?h=f25 - No longer needed in new wxwidgets source - already applied. http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-wxpgchoicesdata-protected-destructor.patch?h=f25 - No longer needed in new wxwidgets source - already applied. http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-check-radio-button-rendering.patch?h=f25 - No longer needed in new wxwidgets source - already applied. http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-blank-menubar-toolbar.patch?h=f25 - No longer needed in new wxwidgets source - already applied. The few remaining wxGTK* patches: - No longer apply without error and don't seem to be needed with the newer wxwidgets version. Hamish McIntyre-Bhatty 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Quick query about Windows versions
On 01/04/2020 10:36, Corinna Vinschen wrote: > None at all. Right now we still support all versions since Windows > Vista, so any breakage building stuff on these systems is the fault > of the Cygwin core. Other than that, Achim is right, of course :) > > > Corinna I'm now all upgraded. I didn't know Vista was still supported - couldn't get Cygwin to install on it back in September so I assumed it had been dropped. I can't remember what the problem was, but perhaps it was my mistake then. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Quick query about Windows versions
On 31/03/2020 17:24, ASSI wrote: > Hamish McIntyre-Bhatty via Cygwin-apps writes: >> Just thought I should ask: is there a perferred version of Windows to >> build packages on, or does it not matter? > Whatever supported version of Windows you use, I'd say. > >> I currently build on Windows 7, following the tradition of building on >> the oldest supported platform, but I have no idea if this is needed with >> Cygwin. > No Windows 7 system should still have the ability to connect to the > internet… so no, I don't think you should even try to build there. > > > Regards, > Achim. Yep, that's why I asked. I'll upgrade the VM to Windows 10 then, if it makes no difference to Cygwin. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Quick query about Windows versions
Hi all, Just thought I should ask: is there a perferred version of Windows to build packages on, or does it not matter? I currently build on Windows 7, following the tradition of building on the oldest supported platform, but I have no idea if this is needed with Cygwin. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Putting packages up for adoption
On 27/03/2020 19:10, Yaakov Selkowitz wrote: > On Fri, 2020-03-27 at 18:32 +0000, Hamish McIntyre-Bhatty via Cygwin- > apps wrote: >> Out of interest, are you also adopting the modules for Python 2 and 3? >> If not, or if you're not keen to adopt all of them, there are a few I'd >> like to adopt (python-wx, python-bs4, and python-pip). > At a minimum, it would probably be easier to coordinate new versions of > Python if one person maintained all the Python versions together with > at least python-setuptools, python-wheel, and python-pip, as those are > the most basic requirements for building Python extensions. > > Someone else has expressed interest in python-wx; perhaps you can work > together on it. > > -- > Yaakov That makes sense. I must have missed that. Who was it? I'm also interested in doing pylint potentially, any reason why that was orphaned before? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Putting packages up for adoption
On 27/03/2020 17:53, Marco Atzeri via Cygwin-apps wrote:
> Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
>> On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
>>> Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
>
>> I would suggest the following:
>>
>> * python2-2.7.z continues to provide all '2' symlinks.
>>
>> * python38 be updated to 3.8.2, and 3.8 be designated the next default
>> 'python3' version (with the '3' symlinks continued to be kept
>> separate), and adjust python-wheel.cygclass accordingly.
>>
>> * Similarly, a separate package (in Fedora it's called 'python-
>> unversioned-command') provide unversioned symlinks, pointing to 2.7 for
>> now (for compatibility).
>>
>> * Anything currently dependent on 'python' or 'python2' should either
>> be dropped if no longer needed, switched to 3 is possible, otherwise
>> rebuilt.
>>
>> * Drop 2.7 from the "default" version set in python-wheel.cygclass, and
>> only build those modules that are actually needed by other things by
>> specifying "all".
>>
>> * Once that's done, look at what's still depending on /usr/bin/python
>> ('python-unversioned-command'), and based on that decide when that can
>> be changed to point to python3.
>>
>> HTH,
>>
>> --
>> Yaakov
>>
>
> The plan looks fine. Thanks for it
>
> unfortunately I see unexpected segfault on the testsuite
>
> 0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle
> skipped
> 0:00:11 load avg: 1.58 [ 25/404] test_array
> 0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
> make: *** [Makefile:878: test] Segmentation fault (core dumped)
>
> for both 2.7.17 and your original 2.7.16.
>
> as I saw other segfault on other programs recently
> I assume that one of compiler/binutils/cygwin has some problem.
>
> 3.8.2 seems to stall later in the test, so it is another issue.
>
> Regards
> Marco
Marco,
Out of interest, are you also adopting the modules for Python 2 and 3?
If not, or if you're not keen to adopt all of them, there are a few I'd
like to adopt (python-wx, python-bs4, and python-pip).
Hamish
0x87B761FE07F548D6.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Re: Requesting a new version of GNU ddrescue
So, I went ahead and made a package, and it's available at https://www.hamishmb.com/files/cygwin-temp/. Does anyone mind checking for me that I've done this right, just so I can get the technique down before I try to package anything complicated? Hamish On 25/03/2020 11:53, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > Hello, > > I would like to request that GNU ddrescue 1.25 be packages for Cygwin. I > would be happy to produce this package if that would be appropriate - > I'd like to start with a simpler package before moving on to wxwidgets > and wxpython. > > Hamish > 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
