Re: CI system cryptic error
On 21.01.2022 17:03, Hamish McIntyre-Bhatty wrote: On 21/01/2022 14:06, Jon Turney wrote: On 20/01/2022 15:50, Hamish McIntyre-Bhatty wrote: Hi there, Recently, I created a test package for python-imaging, and the CI system gave a build error that I didn't see locally: *** ERROR: unknown wheel filename. This only occurred for the Python 3.8 build (3.6 and 3.7 are unaffected). Considering some of the library name changes between these versions, is it possible that this is a bug in the CI tool setup or in cygport? Weird. I assume it's this job: https://github.com/cygwin/scallywag/actions/runs/1592256829 Yep, sorry I forgot to add the link. In which case further note it only failed with this error on i686, x86_64 seems to have built ok. That might explain why you don't see it locally, at least, but it's still puzzling that there's a difference. No I did a local i686 build too, and it was fine... This error comes from here: https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=blob;f=cygclass/python-wheel.cygclass;h=90b0faac71eea6005401b4232e5b334bdc81b756;hb=HEAD#l190 and means something more like "couldn't find the wheel file for python $ver" I downloaded the builddir archive, and inspecting that it seems that a wheel for python3.8 (and 3.9!) isn't being generated. $ tar -tf builddir.tar.xz | grep whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp36-cp36m-cygwin_3_3_3_i686.whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp37-cp37m-cygwin_3_3_3_i686.whl There seems to be completely different output between x86_64 and i686 when building the python wheel, but I have no idea why! Hmm, very strange. Maybe just a freak error? I'll try building again, seeing as I have a new version now anyway, and see what happens. I guess seeing as 64-bit builds are the future for Cygwin, I'll just ignore this issue if it happens again, as long as I check the 32-bit builds I built work. Hamish I saw something similar but I do not remember the details. Cygport is looking for something that has changed name or it is not available anymore. Probably the old name is still used by Python2 and it is the reason why the error seldom show up in local build of maintainers. cygport --debug should provide some hints
Re: CI system cryptic error
On 21/01/2022 14:06, Jon Turney wrote: On 20/01/2022 15:50, Hamish McIntyre-Bhatty wrote: Hi there, Recently, I created a test package for python-imaging, and the CI system gave a build error that I didn't see locally: *** ERROR: unknown wheel filename. This only occurred for the Python 3.8 build (3.6 and 3.7 are unaffected). Considering some of the library name changes between these versions, is it possible that this is a bug in the CI tool setup or in cygport? Weird. I assume it's this job: https://github.com/cygwin/scallywag/actions/runs/1592256829 Yep, sorry I forgot to add the link. In which case further note it only failed with this error on i686, x86_64 seems to have built ok. That might explain why you don't see it locally, at least, but it's still puzzling that there's a difference. No I did a local i686 build too, and it was fine... This error comes from here: https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=blob;f=cygclass/python-wheel.cygclass;h=90b0faac71eea6005401b4232e5b334bdc81b756;hb=HEAD#l190 and means something more like "couldn't find the wheel file for python $ver" I downloaded the builddir archive, and inspecting that it seems that a wheel for python3.8 (and 3.9!) isn't being generated. $ tar -tf builddir.tar.xz | grep whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp36-cp36m-cygwin_3_3_3_i686.whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp37-cp37m-cygwin_3_3_3_i686.whl There seems to be completely different output between x86_64 and i686 when building the python wheel, but I have no idea why! Hmm, very strange. Maybe just a freak error? I'll try building again, seeing as I have a new version now anyway, and see what happens. I guess seeing as 64-bit builds are the future for Cygwin, I'll just ignore this issue if it happens again, as long as I check the 32-bit builds I built work. Hamish
Re: CI system cryptic error
On 20/01/2022 15:50, Hamish McIntyre-Bhatty wrote: Hi there, Recently, I created a test package for python-imaging, and the CI system gave a build error that I didn't see locally: *** ERROR: unknown wheel filename. This only occurred for the Python 3.8 build (3.6 and 3.7 are unaffected). Considering some of the library name changes between these versions, is it possible that this is a bug in the CI tool setup or in cygport? Weird. I assume it's this job: https://github.com/cygwin/scallywag/actions/runs/1592256829 In which case further note it only failed with this error on i686, x86_64 seems to have built ok. That might explain why you don't see it locally, at least, but it's still puzzling that there's a difference. This error comes from here: https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=blob;f=cygclass/python-wheel.cygclass;h=90b0faac71eea6005401b4232e5b334bdc81b756;hb=HEAD#l190 and means something more like "couldn't find the wheel file for python $ver" I downloaded the builddir archive, and inspecting that it seems that a wheel for python3.8 (and 3.9!) isn't being generated. $ tar -tf builddir.tar.xz | grep whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp36-cp36m-cygwin_3_3_3_i686.whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp37-cp37m-cygwin_3_3_3_i686.whl There seems to be completely different output between x86_64 and i686 when building the python wheel, but I have no idea why!
Re: [ITP] biosig [was: Re: newcomer issues when packaging biosig, stimfit, etc.]
On 20/01/2022 20:48, Alois Schlögl wrote: In order to use the playgroun, I guess I need to provide my ssh key. Here it is: Name: Alois Schloegl BEGIN SSH2 PUBLIC KEY C3NzaC1lZDI1NTE5ILKBmNf1QN3lStTwpn46QIip7sS6zNKy0rG8WCYHv/ZU END SSH2 PUBLIC KEY Done. Updating ssh key for Alois Schloegl Fingerprint: 256 SHA256:bvMkxeY5KcLLESayAW43ZPOiYI9owtf0UKKWIWmue00 no comment (ED25519)
Re: A change to how calm expires packages
On 20/01/2022 14:33, Jon Turney wrote: To try to avoid packages lingering in the 'test' status indefinitely (which leads to them not being installed by most users, as they don't run setup with 'consider test packages' enabled, thus these packages generally aren't getting used, so having them isn't generating much value), I'm planning to change how calm expires packages: Currently (in the absence of configuration otherwise [1]), calm will retain up to 3 non-test versions, and 3 test versions, and expire all other versions. I plan to change this to also expire test versions which are superseded by a non-test version (that is: expire test versions where a non-test version with a higher version number exists). I believe this makes the default behaviour closer to what package maintainers are likely to want to happen. This change will cause the following packages to be removed: _autorebase-001091-0.1 cygutils-1.4.16-4 cygwin-3.3.0-0.1.9814cfd8f693 cygwin-3.3.0-0.2.6c1f49f83fde fontforge-20201107p2-1 fontforge-20201107p8-1 gcc-11.2.0-0 grep-3.6-1 grep-3.7-1 gzip-1.10-1 libftdi1-1.4-1 libiconv-1.16-1 meson-0.54.2-3 mingw64-i686-gcc-11.1.0-0.1 mingw64-i686-gcc-11.2.0-0 mingw64-i686-gcc-7.3.0-1 mingw64-x86_64-gcc-11.1.0-0.1 mingw64-x86_64-gcc-11.2.0-0.1 mingw64-x86_64-gcc-7.3.0-1 openbabel-3.1.1p36-1 openbabel-3.1.1p36-2 rdiff-backup-2.0.0-1 readline-8.1-1 screen-4.6.2-3 texlive-collection-latexrecommended-doc-20210118-2 xorg-server-21.1.0-1 Brian, Ken, The only packages I can see where this seems like it will do the wrong thing are listed below. Before deploying this, would you like me to:? grep: untest 3.6-1 and expire 3.0.1 gzip: untest 1.10-1 and expire 1.7-2 texlive-collection-latexrecommended-doc: untest 20210118-2 and expire 20210118-1 [1] See https://cygwin.com/packaging-hint-files.html#override.hint. Not that override.hint files do not apply recursively currently. This seems like a good change to me, also.
Re: Help needed with wxWidgets3.1 tests compilation error
On 20/01/2022 20:38, Brian Inglis wrote: On 2022-01-20 10:10, Hamish McIntyre-Bhatty wrote: I've been having trouble compiling the unit tests for wxWidgets3.1-3.1.5 on Cygwin. The same tests build just fine on my Linux Mint 20.3 install, however that is using GCC 9.3.0 instead of Cygwin's 11.2.0. Attached is the full build log, but I will also point out my ideas about particular issues here. Note: -Werror=format-security is used in the Makefile. I couldn't find exactly what this does, but I'm probably looking in the wrong place - the manpage. Perhaps the following could also be explained by differences from GCC 9 to 11? I check first as in `info GCC Wformat-security` should only care about *printf string variables without using a separate format string. Ah okay, I guess that doesn't explain the -Werror=zero-as-null-pointer-constant errors later. I guess that might be a GCC default change. The first is: In file included from /usr/include/unistd.h:4, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/filefn.h:23, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/utils.h:20, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/cursor.h:75, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/event.h:22, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/evtloop.h:14, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/testprec.h:5, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:433: /usr/include/sys/unistd.h:23:9: error: redundant redeclaration of ‘int chmod(const char*, mode_t)’ in same scope [-Werror=redundant-decls] 23 | int chmod (const char *__path, mode_t __mode); | ^ In file included from /usr/include/sys/_default_fcntl.h:211, from /usr/include/sys/fcntl.h:3, from /usr/include/fcntl.h:12, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:83: /usr/include/sys/stat.h:137:9: note: previous declaration of ‘int chmod(const char*, mode_t)’ 137 | int chmod (const char *__path, mode_t __mode ); | ^ This doesn't happen on my Linux Mint 20.3 (Ubuntu 20.04) host, so I'm assuming this is something to do with the standard library? Next is: In file included from /usr/include/unistd.h:4, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/filefn.h:23, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/utils.h:20, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/cursor.h:75, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/event.h:22, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/evtloop.h:14, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/testprec.h:5, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:433: /usr/include/sys/unistd.h:179:9: error: redundant redeclaration of ‘int pthread_atfork(void (*)(), void (*)(), void (*)())’ in same scope [-Werror=redundant-decls] 179 | int pthread_atfork (void (*)(void), void (*)(void), void (*)(void)); | ^~ In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr-default.h:35, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr.h:148, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ext/atomicity.h:35, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/ios_base.h:39, from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/iomanip:40, from /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:63: /usr/include/pthread.h:65:5: note: previous declaration of ‘int pthread_atfork(void (*)(), void (*)(), void (*)())’ 65 | int pthread_atfork (void (*)(void), void (*)(void), void (*)(void)); | ^~ Ditto. Looking at chmod(3p), pthread_atfork(3p), pthread.h(0p) sys_stat.h(0p), unistd.h(0p) those definitions should *NOT* normally be accessible from unistd.h so there should be no conflict, as POSIX specifies what is visible. Perhaps they are there for compatibility with older systems like BSD or S
