Re: calm now runs on-demand
On 01/07/2017 15:22, Jon Turney wrote: On 01/07/2017 15:14, Marco Atzeri wrote: On 01/07/2017 15:54, Jon Turney wrote: On 01/07/2017 06:18, Marco Atzeri wrote: On 17/04/2017 13:34, Jon Turney wrote: If you have shell access on sourceware, and make such changes, you can force calm to run with '~cygwin-admin/bin/calm scan-(uploads|relarea)'. calm now (finally) detects when changes have been made in the relarea via inotify, so this manual step is no longer required. So, if you have shell access, and you make changes directly in the relarea, calm should now notice, reread it, and update the setup.ini package manifest automatically, without you needing to explicitly request that (or wait until the next scheduled rescan, if you can't request it due to the permission problem identified below...) Jon, I have shell access but I do not find calm anywhere. I assume "~cygwin-admin" is more restricted than shell access. As I did change to the relarea for gcc test, how to force the update of setup.ini's ? I think I have fixed the permissions, so this should work for you now. Thanks for pointing out this problem. May be I misunderstood how I should use it matzeri@sourceware ~ $ /home/cygwin/bin/calm scan-relarea /home/cygwin/bin/calm: line 13: kill: (14958) - Operation not permitted No, that's me being dumb. I guess I need to think some more about how to make this work for other users...
Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 3/30/2024 8:25 AM, Jon Turney wrote: On 29/03/2024 18:32, David Rothenberger via Cygwin-apps wrote: On 3/28/2024 10:50 AM, Jon Turney via Cygwin-apps wrote: [...] David, Is it possible to update/rebuild rdiff-backup, which replies upon the soon-to-be removed python36? (Or indicate that you are no longer interested in maintaining this package, which will probably lead to it's removal). Please remove me as the maintainer from that package. I no longer use it, and no longer have an environment for building packages for Cygwin. No problem. Thanks for maintaining it in the past. Is the same true for your other packages? $ grep Rothenberger cygwin-pkg-maint | grep -v ORPHANED cyrus-sasl David Rothenberger flac David Rothenberger libao David Rothenberger libapr1 David Rothenberger libaprutil1 David Rothenberger libkate David Rothenberger libogg David Rothenberger librsync David Rothenberger libtheora David Rothenberger libvorbis David Rothenberger rdiff-backup David Rothenberger speex David Rothenberger speexdsp David Rothenberger vorbis-tools David Rothenberger which David Rothenberger whois David Rothenberger Yes, I'm afraid it is. Regards, David -- David Rothenberger daver...@acm.org
Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 24/03/2024 17:46, Jon Turney via Cygwin-apps wrote:
On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:
On 24/03/2024 15:07, Jon Turney wrote:
On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:
I assume you are OK with the removal of python 3.5 (EOL Sept 2020)
and 3.6 (EOL Dec 2021)?
(I'm still dealing with cleaning up the final pieces of python27
detritus, but these should hopefully be much smaller tasks)
nothing should depend from 3.5
not sure for 3.6
I've automated some of the analysis I was doing for python2 packages and
the results are now available at [1].
So yeah, it looks like nothing uses 3.5.
I've removed some 3.4 detritus, and 3.5
Perhaps you can clarify the situation with python-pip: python-pip
19.0.3-1, 19.1.1-1 and 19.2.3-1 are not evaluated are being removable,
despite python35-pip being not needed anymore, as that source also
produces python-pip-wheel, which is depended upon by
python3{6,7,8,9}-virtualenv.
A similar situation exists with python-setuptools, python35-setuptools
and python-setuptools-wheel.
(virtualenv also depends on python-wheel-wheel, but that tracks the
latest version)
There are just a couple of packages using 3.6, I guess I'll ping the
maintainers about those.
[1] https://cygwin.com/packages/reports/python_rebuilds.html
It looks like the situation with 3.6 is a bit more complex, as some
things have a generic python3 dependency, rather than python36 as they
should, so that report isn't complete.
I have some tools to correct those dependencies, so the situation should
become clearer after I run those...
