Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #228291 > unrolled thread

getmail, getmail6, testing, unstable, python-is-python3

Back to article view | Back to linux.debian.user

Contents

  getmail, getmail6, testing, unstable, python-is-python3 songbird <songbird@anthive.com> - 2020-10-27 14:20 +0100
    Re: getmail, getmail6, testing, unstable, python-is-python3 mick crane <mick.crane@gmail.com> - 2020-10-27 14:40 +0100
      Re: getmail, getmail6, testing, unstable, python-is-python3 songbird <songbird@anthive.com> - 2020-10-27 15:00 +0100
      Re: getmail, getmail6, testing, unstable, python-is-python3 Reco <recoverym4n@enotuniq.net> - 2020-10-27 15:10 +0100
        Re: getmail, getmail6, testing, unstable, python-is-python3 Celejar <celejar@gmail.com> - 2020-10-27 15:20 +0100
          Re: getmail, getmail6, testing, unstable, python-is-python3 Reco <recoverym4n@enotuniq.net> - 2020-10-27 15:50 +0100
            Re: getmail, getmail6, testing, unstable, python-is-python3 Celejar <celejar@gmail.com> - 2020-10-28 19:20 +0100
        Re: getmail, getmail6, testing, unstable, python-is-python3 songbird <songbird@anthive.com> - 2020-10-27 15:50 +0100
          Re: getmail, getmail6, testing, unstable, python-is-python3 Reco <recoverym4n@enotuniq.net> - 2020-10-27 16:00 +0100
            Re: getmail, getmail6, testing, unstable, python-is-python3 Cindy Sue Causey <butterflybytes@gmail.com> - 2020-10-27 16:30 +0100
            Re: getmail, getmail6, testing, unstable, python-is-python3 songbird <songbird@anthive.com> - 2020-10-27 18:30 +0100
              Re: getmail, getmail6, testing, unstable, python-is-python3 Reco <recoverym4n@enotuniq.net> - 2020-10-27 19:20 +0100

#228291 — getmail, getmail6, testing, unstable, python-is-python3

  well, yesterday finally became the day when i tried to
see if i could get the old getmail to be left alone, but
nope, none of the options worked.

  the good news, is that getmail6 is in unstable and was
a drop in replacement for getmail.  there's a bit of an
odd message coming out of it but that's not an error and
everything is ending up where it should.

  during all of this fiddling i was wondering if the 
python2 to python3 transition was complete enough that
i could run all my programs that i use and it all works
just fine.  so i installed python-is-python3 and the
system rebooted and none of things i use the most have
failed.  that's all i need from a system (browswer, e-mail,
usenet, gimp, go, libreoffice).  i've never done much 
with python2 and the game i wrote was python3 so that's
all to the good.

  this was just a quick heads-up for those who are stuck 
on getmail like i am (and quite happy with it).  :)


  songbird

[toc] | [next] | [standalone]

#228292

On 2020-10-27 13:08, songbird wrote:
> well, yesterday finally became the day when i tried to
> see if i could get the old getmail to be left alone, but
> nope, none of the options worked.
> 
>   the good news, is that getmail6 is in unstable and was
> a drop in replacement for getmail.  there's a bit of an
> odd message coming out of it but that's not an error and
> everything is ending up where it should.
> 
>   during all of this fiddling i was wondering if the
> python2 to python3 transition was complete enough that
> i could run all my programs that i use and it all works
> just fine.  so i installed python-is-python3 and the
> system rebooted and none of things i use the most have
> failed.  that's all i need from a system (browswer, e-mail,
> usenet, gimp, go, libreoffice).  i've never done much
> with python2 and the game i wrote was python3 so that's
> all to the good.
> 
>   this was just a quick heads-up for those who are stuck
> on getmail like i am (and quite happy with it).  :)
> 

as far as getmail goes maintainer thinks is an unnecessary panic.

""getmail goes out of official support by my distro" may be a 
theoretical
problem, or a philosophical one, but it it certainly is not a 
significant
practical problem.  Keep a Python 2 binary around, download getmail, 
untar it,
and run it right out of the directory - that's literally all that's 
required."

what exactly the python 2 binary is I haven't had need to look as yet.

mick

-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#228294

mick crane wrote:
...
> as far as getmail goes maintainer thinks is an unnecessary panic.
>
> ""getmail goes out of official support by my distro" may be a 
> theoretical
> problem, or a philosophical one, but it it certainly is not a 
> significant
> practical problem.  Keep a Python 2 binary around, download getmail, 
> untar it,
> and run it right out of the directory - that's literally all that's 
> required."
>
> what exactly the python 2 binary is I haven't had need to look as yet.

  note that is his opinion, the debian python and getmail 
packaging workers have decided otherwise and now the
original getmail package is no longer compatible in
testing with other packages so it is removed.  i tried to
use my own version but there was a problem with the
python install missing some module so i gave up and then
i found the python6 package and that took care of the
whole problem.

  the newer getmail6 package is based upon getmail, but
it is compatible with python3.  that is all i care about, 
it works, i don't have to mess around with yet another
dangling bit of stuff to keep after (that's why i use a
distribution and not roll my own after all - i have 
enough of that already).


  songbird

[toc] | [prev] | [next] | [standalone]

#228296

	Hi.

On Tue, Oct 27, 2020 at 01:31:19PM +0000, mick crane wrote:
> >   this was just a quick heads-up for those who are stuck
> > on getmail like i am (and quite happy with it).  :)
> > 
> 
> as far as getmail goes maintainer thinks is an unnecessary panic.
> 
> ""getmail goes out of official support by my distro" may be a theoretical
> problem, or a philosophical one, but it it certainly is not a significant
> practical problem.

Indeed. Switch back to fetchmail, because the less you're depending on
python and the software that uses it - the better ;)

> Keep a Python 2 binary around, download getmail, untar it,
> and run it right out of the directory - that's literally all that's required."
> 
> what exactly the python 2 binary is I haven't had need to look as yet.

/usr/bin/python, currently provided by "python-minimal" package.

Reco

[toc] | [prev] | [next] | [standalone]

#228298

On Tue, 27 Oct 2020 17:02:22 +0300
Reco <recoverym4n@enotuniq.net> wrote:

> 	Hi.
> 
> On Tue, Oct 27, 2020 at 01:31:19PM +0000, mick crane wrote:
> > >   this was just a quick heads-up for those who are stuck
> > > on getmail like i am (and quite happy with it).  :)
> > > 
> > 
> > as far as getmail goes maintainer thinks is an unnecessary panic.
> > 
> > ""getmail goes out of official support by my distro" may be a theoretical
> > problem, or a philosophical one, but it it certainly is not a significant
> > practical problem.
> 
> Indeed. Switch back to fetchmail, because the less you're depending on
> python and the software that uses it - the better ;)

Here's the getmail author's opinion of why getmail is preferable to
fetchmail:

http://pyropus.ca/software/getmail/faq.html#faq-about-why

Doubtless opinionated, and certainly dated, but would you or anyone
else here care to comment?

Celejar

[toc] | [prev] | [next] | [standalone]

#228301

	Hi.

On Tue, Oct 27, 2020 at 10:19:01AM -0400, Celejar wrote:
> On Tue, 27 Oct 2020 17:02:22 +0300
> Reco <recoverym4n@enotuniq.net> wrote:
> 
> > 	Hi.
> > 
> > On Tue, Oct 27, 2020 at 01:31:19PM +0000, mick crane wrote:
> > > >   this was just a quick heads-up for those who are stuck
> > > > on getmail like i am (and quite happy with it).  :)
> > > > 
> > > 
> > > as far as getmail goes maintainer thinks is an unnecessary panic.
> > > 
> > > ""getmail goes out of official support by my distro" may be a theoretical
> > > problem, or a philosophical one, but it it certainly is not a significant
> > > practical problem.
> > 
> > Indeed. Switch back to fetchmail, because the less you're depending on
> > python and the software that uses it - the better ;)
> 
> Here's the getmail author's opinion of why getmail is preferable to
> fetchmail:
> 
> http://pyropus.ca/software/getmail/faq.html#faq-about-why
> 
> Doubtless opinionated, and certainly dated, but would you or anyone
> else here care to comment?

It boils down to two things:

1) Configuration of fetchmail is teh hard.

If I have to choose between hard-to-configure software and will-cease-to
function software - I always go with the first variety. YMMV.


2) Fetchmail is insecure, getmail is bulletproof.

As [1] and [2] show us - it's true somewhat. fetchmail has 5 times more
known vulnerabilities than getmail.
Problem with such numbers approach is - last reported CVE for fetchmail
is dated 2012, and for getmail it's 2014. I.e. both can be considered
secure enough in this regard.

CVE-2020-5239 - [1] - corresponds to some *person* (let's put it this
way) who apparently thought that putting outdated fetchmail in docker
along with the unspecified Agile/Scrumm-level quality "fetchmail script"
will make things secure by some magic.
A morale of the story here - running a random docker image is comparable
to running a random binary downloaded from the Internet as far as
security concerned.

And my favorite:
"getmail users have not had to worry about any of these security holes
or design and implementation errors".
Instead getmail users have to worry about [3]. It's not php-level mess -
[4], but venerable nevertheless.

Reco

[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=getmail
[2] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=fetchmail
[3] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=python
[4] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=php

[toc] | [prev] | [next] | [standalone]

#228364

On Tue, 27 Oct 2020 17:45:51 +0300
Reco <recoverym4n@enotuniq.net> wrote:

> 	Hi.
> 
> On Tue, Oct 27, 2020 at 10:19:01AM -0400, Celejar wrote:
> > On Tue, 27 Oct 2020 17:02:22 +0300
> > Reco <recoverym4n@enotuniq.net> wrote:

...

> > > Indeed. Switch back to fetchmail, because the less you're depending on
> > > python and the software that uses it - the better ;)
> > 
> > Here's the getmail author's opinion of why getmail is preferable to
> > fetchmail:
> > 
> > http://pyropus.ca/software/getmail/faq.html#faq-about-why
> > 
> > Doubtless opinionated, and certainly dated, but would you or anyone
> > else here care to comment?
> 
> It boils down to two things:
> 
> 1) Configuration of fetchmail is teh hard.
> 
> If I have to choose between hard-to-configure software and will-cease-to
> function software - I always go with the first variety. YMMV.
> 
> 
> 2) Fetchmail is insecure, getmail is bulletproof.
> 
> As [1] and [2] show us - it's true somewhat. fetchmail has 5 times more
> known vulnerabilities than getmail.
> Problem with such numbers approach is - last reported CVE for fetchmail
> is dated 2012, and for getmail it's 2014. I.e. both can be considered
> secure enough in this regard.

...

Thanks.

Celejar

[toc] | [prev] | [next] | [standalone]

#228302

Reco wrote:
...
> Indeed. Switch back to fetchmail, because the less you're depending on
> python and the software that uses it - the better ;)

  i never used fetchmail so that wouldn't be a
"switching back" and since i already have my setup 
working as i want for getmail6 why would i bother 
doing more work for no gain?

  i do use python3 so python won't be gone from this
machine entirely anyways.


  songbird

[toc] | [prev] | [next] | [standalone]

#228303

On Tue, Oct 27, 2020 at 10:45:23AM -0400, songbird wrote:
> Reco wrote:
> ...
> > Indeed. Switch back to fetchmail, because the less you're depending on
> > python and the software that uses it - the better ;)
> 
>   i never used fetchmail so that wouldn't be a
> "switching back" and since i already have my setup 
> working as i want for getmail6 why would i bother 
> doing more work for no gain?

Because python. Be it python 2 or python 3 - it's (in)famous for one
thing - lack of backwards compatibility. Sooner or later they replace
python 3.8 (current sid) with, say, python 3.9 - and the things will
break again.
Because they did on 3.7->3.8 transition, did before that on 3.6->3.7
transition and this list goes long way back.

Reco

[toc] | [prev] | [next] | [standalone]

#228305

On 10/27/20, Reco <recoverym4n@enotuniq.net> wrote:
> On Tue, Oct 27, 2020 at 10:45:23AM -0400, songbird wrote:
>> Reco wrote:
>> ...
>> > Indeed. Switch back to fetchmail, because the less you're depending on
>> > python and the software that uses it - the better ;)
>>
>>   i never used fetchmail so that wouldn't be a
>> "switching back" and since i already have my setup
>> working as i want for getmail6 why would i bother
>> doing more work for no gain?
>
> Because python. Be it python 2 or python 3 - it's (in)famous for one
> thing - lack of backwards compatibility. Sooner or later they replace
> python 3.8 (current sid) with, say, python 3.9 - and the things will
> break again.
> Because they did on 3.7->3.8 transition, did before that on 3.6->3.7
> transition and this list goes long way back.


Hi.. Am posting this because it just came through my inbox and feels
like it's appropriate. It's from the Debian-Python list (YESTERDAY)
and says, "Re: help with FTBFS bug due to python3.8/3.9 confusion":

https://lists.debian.org/debian-python/2020/10/msg00066.html

The original post is a little lengthy and might provide some
commiseration that's of interest. Being a professional lurker, I'm
fully in agreement that this is an ongoing deal the last few years.

Between this and the GTK2 v. GTK3 deal, Developers do get frustrated
when it seems like they're constantly chasing breakage issues. When
messages pop about "abandonware" type issues, about the first thing I
peek at (out of curiosity) is whether Python or GTK is part of the
packaging. :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#228310

Reco wrote:
...
> Because python. Be it python 2 or python 3 - it's (in)famous for one
> thing - lack of backwards compatibility. Sooner or later they replace
> python 3.8 (current sid) with, say, python 3.9 - and the things will
> break again.
> Because they did on 3.7->3.8 transition, did before that on 3.6->3.7
> transition and this list goes long way back.

  i've not had any problems with python3 here, but i 
don't do strange things with python3.  oh, let me
rephrase that, during a recent round i had a problem
with a program, but that wasn't anything i did so it
was somewhere in the stack of modules that program 
used.  does that mean it was incompatible?  no, it 
just meant there was a bug introduced which eventually 
got fixed.


  songbird

[toc] | [prev] | [next] | [standalone]

#228314

	Hi.

On Tue, Oct 27, 2020 at 01:20:17PM -0400, songbird wrote:
> Reco wrote:
> ...
> > Because python. Be it python 2 or python 3 - it's (in)famous for one
> > thing - lack of backwards compatibility. Sooner or later they replace
> > python 3.8 (current sid) with, say, python 3.9 - and the things will
> > break again.
> > Because they did on 3.7->3.8 transition, did before that on 3.6->3.7
> > transition and this list goes long way back.
> 
>   i've not had any problems with python3 here, but i 
> don't do strange things with python3.

Because it's not your burden ;)
Every time a major change like python transition happens in Debian -
packages start breaking. It's up for the maintainer to fix such
breakages (obviously), and once in a while a maintainer goes MIA.
What happens next is packages get deleted from testing first, sid second.

Luckily the bullseye package freeze should be happening Soon™, so it's
unlikely we'll see python 3.9 (and inevitable collateral damage it
brings) in bullseye.


> oh, let me rephrase that, during a recent round i had a problem with a
> program, but that wasn't anything i did so it was somewhere in the
> stack of modules that program used.  does that mean it was
> incompatible?

I cannot tell you that without going into specifics (python version,
modules used, all usual stuff). Usually it's pretty clear from Python
backtrace.


> no, it just meant there was a bug introduced which
> eventually got fixed.

It means you got lucky that time. I would not count on such luck next
time.

Reco

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web