Re: A change to how calm expires packages
On 2022-01-20 07: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: grep-3.6-1 grep-3.7-1 gzip-1.10-1 readline-8.1-1 Brian, 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 Your calm expiry actions seem to DTRT, but your suggestions are probably a better approach, so yes please do so! Test releases grep 3.6 and gzip 1.10 successors grep 3.7 and gzip 1.11 were released during the test period, both including bug fixes, later promoted to current. A new grep 3.7 test was released, as the changes were significant: high impact and pervasive, with only 9 months between releases. The gzip 1.11 changes were not: mainly docs, help, infra, typos, warnings, and other platforms, despite 2 years 9 months between releases and more commits. I was unaware of *untest*, so bumped the grep release and gzip version for current. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
Re: [ITP] biosig [was: Re: newcomer issues when packaging biosig, stimfit, etc.]
Am 1/18/22 um 23:56 schrieb Brian Inglis: On 2022-01-18 14:50, Alois Schlögl wrote: Am 1/18/22 um 06:32 schrieb Brian Inglis: On 2022-01-17 14:44, Alois Schlögl wrote: Am 1/15/22 um 21:44 schrieb Achim Gratz: Marco Atzeri writes: add DIFF_EXCLUDES="Makefile" to avoid the artifact DISTCLEANFILES would be more appropriate it seems. DISTCLEANFILES is deleted immediately after downloading and unpacking the *UPSTREAM* source: https://cygwin.github.io/cygport/src_prep_cygpart.html#robo112 "A list of files to be deleted immediately upon unpacking sources, relative to $S. This is intended to be used with buildsystem-generated files which are incorrectly included in the source tarball." I tried this (see attachment), but I'm not sure this is what you meant. DIFF_EXCLUDES is a list of files generated in $S not automatically excluded from the source package: https://cygwin.github.io/cygport/pkg_pkg_cygpart.html#robo384 "A list of file names, directory names, or glob patterns in $S which will be excluded when creating the .src.patch file. This should be used for files automatically generated in $S to avoid polluting the patch. NOTE Files generated by various buildsystem infrastructures, such as autoconf, automake, gettext, and libtool are already excluded automatically and need not be listed here." Add to DIFF_EXCLUDES the names of any files you see after the output header: Creating source patches Ok, thanks for these clear hints. I've now added these files as suggested. The revised version is attached. Moreover, I've removed (commented) all aspects for building of python-biosig bindings, in order not to delay the inclusion of Biosig in Cygwin. Is there anything else that need to be considered ? CATEGORY is a *space* separated list in quotes. Before SRC_URI and PATCH_URI normally comes: HOMEPAGE=https://sourceforge.net/projects/biosig/files/ you don't need to add quotes for nonspaced strings. You may also test your cygport and any other source patches and files you require by creating and committing them into a local git repo named the same as the package (preferably all lower case) and pushing to the git-cygwin-packages playground repo and branch: git push --set-upstream ssh://cygwin/git/cygwin-packages/playground.git playground -f which will submit the build to the Cygwin GitHub Action CI and print the link for you to monitor the CI job, view the build logs for noarch, x86, and x86_64, and download them. 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 Cheers, Alois
Re: Help needed with wxWidgets3.1 tests compilation error
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. 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 Solaris and should be suppressed when newer feature macros are defined or specific legacy system macros are not defined? Also of note, is that Cygwin is several times slower at compiling
Re: A change to how calm expires packages
Jon Turney writes: > This change will cause the following packages to be removed: > > _autorebase-001091-0.1 > gcc-11.2.0-0 > 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 That looks about right, thanks. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Help needed with wxWidgets3.1 tests compilation error
Hi there, 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? 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. Then there are some wxwidgets-specific ones, but I'll make a separate thread for those because I have an idea about what might be causing them. I'll probably need to ask the wxWidgets people. Hopefully someone here with more experience can help. Also of note, is that Cygwin is several times slower at compiling pretty much everything for me. Does anyone know if this is GCC 9 vs 11 speed, or running Cygwin in Windows 11 in KVM, or something else? I am running on AMD Ryzen 3000, if that has anything to do with it. Hamish /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/build/gtk2/bk-deps g++ -c -o test_allheaders_allheaders.o -I/home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/build/gtk2/lib/wx/include/gtk2
Re: A change to how calm expires packages
On 1/20/2022 9:33 AM, Jon Turney wrote: texlive-collection-latexrecommended-doc: untest 20210118-2 and expire 20210118-1 Yes, please. It was just a mistake that I never untested 20210118-2. Ken
Re: how to obsolete now-removed subpackage?
On 20/01/2022 14:00, Jon Turney wrote: On 20/01/2022 13:42, Jon Turney wrote: On 20/01/2022 13:12, Ken Brown wrote: On 1/20/2022 7:14 AM, Glenn Strauss wrote: lighttpd 1.4.64 removes long-deprecated packages, including mod_trigger_b4_dl (replaceable with a lua script, if needed) I am trying to build using lighttpd.cygport and after uploading package 1.4.64-1, I got errors, so I tried adding PKG_OBSOLETES="lighttpd-mod_trigger_b4_dl" to lighttpd.cygport and building lighttpd.cyport package 1.4.64-2 Am I using PKG_OBSOLETES incorrectly? Yes. The cygport manual says that PKG_OBSOLETES is "A single-line string containing a list of package(s) which this package replaces Note that the PKG_OBSOLETES name is descriptive rather than literal, where "PKG" should be substituted with the name of the binary package whose contents it describes." Reading this again... To be clear, PKG needs to be replaced by the name of a package. So, you probably want something like: lighttpd_OBSOLETES="lighttpd-mod_trigger_b4_dl" I think this might be a bug in calm (which processes the package uploads). How OBSOLETES is put into effect has changed slightly in the latest version of cygport, and calm hasn't caught up with it yet. Thanks for reporting this. ... but there might still be an issue I need to think about here. Yeah. The upload you tried with my suggested change to the cygport failed for the reasons I suspected. I've deployed a fix.
CI system cryptic error
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?
Attached is the offending cygport file that caused the error.
Hamish
ORIG_PN="Pillow"
PYTHON_WHEEL_VERSIONS="3.6:3.7:3.8:3.9"
inherit python-wheel
NAME="python-imaging"
VERSION=8.4.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/7d/2a/2fc11b54e2742db06297f7fa7f420a0e3069fdcf0e4b57dfec33f0b08622/Pillow-8.4.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 python36-olefile python37
python37-devel python37-setuptools python37-wheel python37-pip python37-olefile
python38 python38-devel python38-setuptools python38-wheel python38-pip
python38-olefile python39 python39-devel python39-setuptools python39-wheel
python39-pip python39-olefile"
DIFF_EXCLUDES="build"
src_test() {
cd ${B}
for v in ${PYTHON_WHEEL_VERSIONS//:/ }
do
echo PYTHONPATH="${B}/build/lib.cygwin-$(uname -r | sed -e
's|s*(.*||')-$(uname -m)-$v"
PYTHONPATH="${B}/build/lib.cygwin-$(uname -r | sed -e
's|s*(.*||')-$(uname -m)-$v" \
python$v selftest.py
done
}
PKG_NAMES=" python36-imaging python36-imaging-tk"
PKG_NAMES+=" python37-imaging python37-imaging-tk"
PKG_NAMES+=" python38-imaging python38-imaging-tk"
PKG_NAMES+=" python39-imaging python39-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_REQUIRES="python36 python36-olefile"
python36_imaging_OBSOLETES+=" python3-imaging-devel python3-imaging-qt"
python36_imaging_CONTENTS="
--exclude=_imagingtk*
--exclude=ImageTk*
--exclude=SpiderImagePlugin*
${python36_imaging_CONTENTS}
"
python36_imaging_tk_OBSOLETES="python3-imaging-tk"
python36_imaging_tk_REQUIRES="python36-imaging 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_REQUIRES="python37 python37-olefile"
python37_imaging_CONTENTS="
--exclude=_imagingtk*
--exclude=ImageTk*
--exclude=SpiderImagePlugin*
${python37_imaging_CONTENTS}
"
python37_imaging_tk_REQUIRES="python37-imaging 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_REQUIRES="python38 python38-olefile"
python38_imaging_CONTENTS="
--exclude=_imagingtk*
--exclude=ImageTk*
--exclude=SpiderImagePlugin*
${python38_imaging_CONTENTS}
"
python38_imaging_tk_REQUIRES="python38-imaging 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*
"
python39_imaging_REQUIRES="python39 python39-olefile"
python39_imaging_CONTENTS="
--exclude=_imagingtk*
--exclude=ImageTk*
--exclude=SpiderImagePlugin*
${python39_imaging_CONTENTS}
"
python39_imaging_tk_REQUIRES="python39-imaging python39-tkinter"
python39_imaging_tk_CONTENTS="
usr/lib/python3.9/site-packages/PIL/_imagingtk*
usr/lib/python3.9/site-packages/PIL/ImageTk*
usr/lib/python3.9/site-packages/PIL/SpiderImagePlugin*
usr/lib
Tox issues with Python 3.6 and 3.7
Hi there, This is a follow-up to Marco Atzeri and I talking about tox in the Python 3.9 email thread. I have just started trying to use tox for testing python-imaging. I have found that tox has some issues on Python 3.6 and 3.7, namely that: 3.6: typing-extensions (on PyPI) is required for tox to run (I installed with pip3.6). This is not available in the Cygwin repositories. Then, platformdirs is needed. This is available in the Cygwin repositories but not for 3.6. I then decided not to bother supporting 3.6 seeing as it is EOL now anyway. 3.7: As above typing-extensions is required, which I installed with pip3.7. Tox then says it can't find the "interpreter for Builtin discover of python_spec='python3.7m'" It also seems to be trying to build Pillow again inside a virtualenv, but doesn't find jpeg headers/libraries, which are installed. Marco, I assume you didn't have these problems when you tested, or you found a way to fix them. Having never used tox before, I'm at a bit of a loss, any ideas? Hamish
A change to how calm expires packages
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.
Re: how to obsolete now-removed subpackage?
On Thu, Jan 20, 2022 at 02:00:02PM +, Jon Turney wrote: > On 20/01/2022 13:42, Jon Turney wrote: > > On 20/01/2022 13:12, Ken Brown wrote: > > > On 1/20/2022 7:14 AM, Glenn Strauss wrote: > > > > lighttpd 1.4.64 removes long-deprecated packages, > > > > including mod_trigger_b4_dl (replaceable with a lua script, if needed) > > > > > > > > I am trying to build using lighttpd.cygport and after uploading package > > > > 1.4.64-1, I got errors, so I tried adding > > > > PKG_OBSOLETES="lighttpd-mod_trigger_b4_dl" > > > > to lighttpd.cygport and building lighttpd.cyport package 1.4.64-2 > > > > > > > Am I using PKG_OBSOLETES incorrectly? > > > > > > Yes. The cygport manual says that PKG_OBSOLETES is "A single-line > > > string containing a list of package(s) which this package > > > replaces Note that the PKG_OBSOLETES name is descriptive rather > > > than literal, where "PKG" should be substituted with the name of the > > > binary package whose contents it describes." > > Reading this again... > > To be clear, PKG needs to be replaced by the name of a package. So, you > probably want something like: > > lighttpd_OBSOLETES="lighttpd-mod_trigger_b4_dl" It makes sense now that you and Ken have explained it, but I misunderstood that when comparing PKG_OBSOLETES to PKG_NAMES. Maybe the documentation could use _OBSOLETES in places where is expected to be replaced with a package name? Cheers, Glenn
Re: how to obsolete now-removed subpackage?
On 20/01/2022 13:42, Jon Turney wrote: On 20/01/2022 13:12, Ken Brown wrote: On 1/20/2022 7:14 AM, Glenn Strauss wrote: lighttpd 1.4.64 removes long-deprecated packages, including mod_trigger_b4_dl (replaceable with a lua script, if needed) I am trying to build using lighttpd.cygport and after uploading package 1.4.64-1, I got errors, so I tried adding PKG_OBSOLETES="lighttpd-mod_trigger_b4_dl" to lighttpd.cygport and building lighttpd.cyport package 1.4.64-2 Am I using PKG_OBSOLETES incorrectly? Yes. The cygport manual says that PKG_OBSOLETES is "A single-line string containing a list of package(s) which this package replaces Note that the PKG_OBSOLETES name is descriptive rather than literal, where "PKG" should be substituted with the name of the binary package whose contents it describes." Reading this again... To be clear, PKG needs to be replaced by the name of a package. So, you probably want something like: lighttpd_OBSOLETES="lighttpd-mod_trigger_b4_dl" I think this might be a bug in calm (which processes the package uploads). How OBSOLETES is put into effect has changed slightly in the latest version of cygport, and calm hasn't caught up with it yet. Thanks for reporting this. ... but there might still be an issue I need to think about here.
Re: how to obsolete now-removed subpackage?
On 20/01/2022 13:12, Ken Brown wrote: On 1/20/2022 7:14 AM, Glenn Strauss wrote: lighttpd 1.4.64 removes long-deprecated packages, including mod_trigger_b4_dl (replaceable with a lua script, if needed) I am trying to build using lighttpd.cygport and after uploading package 1.4.64-1, I got errors, so I tried adding PKG_OBSOLETES="lighttpd-mod_trigger_b4_dl" to lighttpd.cygport and building lighttpd.cyport package 1.4.64-2 Am I using PKG_OBSOLETES incorrectly? Yes. The cygport manual says that PKG_OBSOLETES is "A single-line string containing a list of package(s) which this package replaces Note that the PKG_OBSOLETES name is descriptive rather than literal, where "PKG" should be substituted with the name of the binary package whose contents it describes." I think this might be a bug in calm (which processes the package uploads). How OBSOLETES is put into effect has changed slightly in the latest version of cygport, and calm hasn't caught up with it yet. Thanks for reporting this.
Re: how to obsolete now-removed subpackage?
On 1/20/2022 7:14 AM, Glenn Strauss wrote: lighttpd 1.4.64 removes long-deprecated packages, including mod_trigger_b4_dl (replaceable with a lua script, if needed) I am trying to build using lighttpd.cygport and after uploading package 1.4.64-1, I got errors, so I tried adding PKG_OBSOLETES="lighttpd-mod_trigger_b4_dl" to lighttpd.cygport and building lighttpd.cyport package 1.4.64-2 Am I using PKG_OBSOLETES incorrectly? Yes. The cygport manual says that PKG_OBSOLETES is "A single-line string containing a list of package(s) which this package replaces Note that the PKG_OBSOLETES name is descriptive rather than literal, where "PKG" should be substituted with the name of the binary package whose contents it describes." Is there something else I need to do to remove this subpackage? I think what you want is simply for lighttpd-mod_trigger_b4_dl to be empty, which you can achieve with lighttpd_mod_trigger_b4_dl_CONTENTS= Ken
how to obsolete now-removed subpackage?
lighttpd 1.4.64 removes long-deprecated packages, including mod_trigger_b4_dl (replaceable with a lua script, if needed) I am trying to build using lighttpd.cygport and after uploading package 1.4.64-1, I got errors, so I tried adding PKG_OBSOLETES="lighttpd-mod_trigger_b4_dl" to lighttpd.cygport and building lighttpd.cyport package 1.4.64-2 On Thu, Jan 20, 2022 at 11:34:03AM -, cygwin-apps@cygwin.com wrote: > ERROR: install packages from source package 'lighttpd' have non-unique > current versions 1.4.63-1 (lighttpd-mod_trigger_b4_dl), 1.4.64-2 (15 others) > ERROR: error while validating merged x86_64 packages for Glenn Strauss > SUMMARY: 2 ERROR(s) Am I using PKG_OBSOLETES incorrectly? Is there something else I need to do to remove this subpackage? Thanks. Glenn
