Sudip Mukherjee <sudipm.mukher...@gmail.com> wrote: > > 1) The Debian maintainers of getmail have offered to help with > supporting python3 and have even submitted patches or pointed to their > wip branches in github which I think were all rejected.
I have not rejected anything. I have asked questions of people who submitted patches *which currently do nothing except kill support for Python < 2.7*. > 2) The previous Debian maintainers have also requested Charles to do > the python3 development in open so that the effort is not duplicated. I do not currently use a public forge for getmail development. I have reasons. > 3) Reading https://marc.info/?l=getmail&m=151542154628352&w=2 I am not > really convinced that Charles will ever support Python3. You're wrong, then -- I'm not sure what you're basing that opinion on, besides your own unsupported supposition. I have already done part of the rewrite for Python 3; I just don't have 10+ hours a week to devote to open-source/free software the way I did two decades ago. That message just says getmail would not be Python 3 compatible that year - it says nothing whatsoever about getmail never supporting Python 3. > 4) Charles says his getmail users' mailing list has been inundated > with support requests. I have gone through the last 1 year history of > the mailing list and could only find the last one from Michael and > another one in December,2020 Then you missed some. > 5) Also noticed getmail user's positive experience upgrading to > getmail6 at https://marc.info/?l=getmail&m=160131249528542&w=2 So some users have *not* hit bugs when running "getmail6". I never said differently. > 6) https://marc.info/?l=getmail&m=160060476624283&w=2 shows the plight > of a user who tried to continue using getmail with Debin testing. That problem does not appear to actually be related to getmail. It appears to be a user running with a Python 2.7 that was compiled without SSL support. I thought getmail caught this error and issued a diagnostic, but maybe not -- it's been a long, long time since I used a Python that didn't have SSL. There is no "plight" to running getmail on current Debian. The complete process is: 1. apt-get install python2.7 2. install real getmail, or don't even install it, just unpack it That's it. It works. See: /tmp/getmail-test$ tar xzf ~/projects/getmail-trunk/dist/getmail-5.16.tar.gz /tmp/getmail-test$ dpkg -l python2.7 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============-============-============-==================================> ii python2.7 2.7.18-8 amd64 Interactive high-level object-orie> charlesc@vetinari:/tmp/getmail-test$ cd getmail-5.16/ charlesc@vetinari:/tmp/getmail-test/getmail-5.16$ ./getmail --help Usage: getmail [options] Options: --version show program's version number and exit -h, --help show this help message and exit -g DIR, --getmaildir=DIR look in DIR for config/data files -r FILE, --rcfile=FILE load configuration from FILE (may be given multiple times) --dump dump configuration and exit (debugging) --trace print extended trace information (extremely verbose) -i FOLDER, --idle=FOLDER maintain connection and listen for new messages in FOLDER. Only applies if a single rc file is given with a connection to an IMAP server that supports the IDLE command Overrides: The following options override those specified in any getmailrc file. -v, --verbose operate more verbosely (may be given multiple times) --fingerprint show SSL/TLS fingerprint and connection information -q, --quiet operate quietly (only report errors) -d, --delete delete messages from server after retrieving -l, --dont-delete do not delete messages from server after retrieving -a, --all retrieve all messages -n, --new retrieve only unread messages > 1) Since the development of getmail is not in the open it's possible > that users have sent personal mail to Charles asking for support and It's not "possible", it actually happens. A lot. About a lot of different bugs. See the "getmail6" changelog for the number of fixes, each one of which I've probably received multiple support requests about. > We think the best way is to remove the transitional package which will > break the link between getmail and getmail6 so that Debian users who > are using getmail will not automatically be upgraded to getmail6 and > they will explicitly need to install getmail6 if they want to. That > should solve the problem for which Charles has opened this bug report > as the users will already know that they do not have getmail and they > are installing something else. This will not anything unless you rename "getmail6" so that neither the package name nor the executable contain the string "getmail" or anything confusingly similar to it. I have already received support requests from people who *did* knowingly install "getmail6" but still had no idea that it wasn't actually a getmail release, and they had full access to the documentation etc but still just web-search "getmail" and ask me for help. So, my preference is: 1. rename the package and executable. As I have pointed out, this is the normal, polite, accepted best practice when forking a project. The fact that Roland claims to have "as much right to the getmail name" as I, the author, do, just means that Debian should rename their package without waiting for Roland to do the right thing. As I said, Debian is supposed to be about doing what is ethical - so why do you object to renaming a hostile fork of an actively-developed project which is namesquatting on the original project name? 2. If (1) is rejected, then drop "getmail6" completely. Restore the getmail package that depends on python2.7 and everything will continue to work for users who have getmail installed pre-upgrade, or who want to install it afterwards. Charles -- ------------------------------------------------------------------ Charles Cazabon <charlesc-getm...@pyropus.ca> Software, consulting, and services available at http://pyropus.ca/ ------------------------------------------------------------------
