Python 2.7 removal outline

[Rene Ladan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

below is an outline continuing the Python 2.7 cleanup:

- - all affected ports are now marked as deprecated, with an expiration date
  of either 2020-12-31 or 2021-06-23.
- - we will have to wait for Chromium to fully switch to Python 3 before we
  can fully remove Python 2.7. This is work in progress on their side. Not
  waiting would imply removing www/chromium (obviously), editors/vscode
  (it escaped the recursive-deprecation dance of devel/electron*), but most
  importantly www/qt5-webengine which would drag half of KDE with it.
  However, lang/python27 will be marked as RESTRICTED so that all ports
  mentioned above can still be built and run, but Python 2.7 itself will
  not be available as a package.
- - No more new ports having USES=python:2.7 or USES=python:2.7+ or existing
  ports reverting to that, no excuses.
- - No usage of lang/tauthon by the framework or any port, no excuses.
- - lang/tauthon will be removed on 2021-06-23 as noticed in the port itself,
  no excuses. Tauthon is not guaranteed to be compatible with any official
  Python version so keeping it would just unnecessarily complicate things.
- - mail/mailman is being replaced by clusteradm@  with mlmmj. You can use
  `pkg lock` to stick with it after removal, if there is no other way.
- - you are of course free to provide your own version of Python 2.7, Tauthon
  and any application using those languages in your local setup, by using
  overlays for example.

Miscellaneous tidbits:
- - WHY?!?!? Well, back in 2008, the Python Software Foundation planned to
  mark Python 2.7 end-of-life at 2015-01-01, see [1], but that date was
  pushed back to 2020-01-01 because a lot of downstream users had not
  converted yet. So Python 2.7 is already end-of-life for 1.5 years, which
  means that according to [1] the PSF is no longer fixing security issues
  for it. As can be seen on [2], multiple vulnerabilities already have
  been fixed for Python 3.6 to 3.9 this year.
- - On a related note, most software using Python 2.7 was already removed
  from the Ports Tree last year, a lot of it being unmaintained or
  more or less abandoned upstream.
- - Upstream Chromium is working on converting their codebase to Python 3 but
  there is no completion date. Interestingly, adridg@ is experimenting with
  converting www/qt5-webengine to Python 3 too.
- - We are indeed faster with dropping Python 2.7 than e.g. Ubuntu, however
  more recent Debian/Ubuntu distributions are more and more dropping Python
  2.7 too. This also has to do with how their branching model works, the
  package set of Ubuntu LTS is determined a few months before the release
  itself.

[1] https://www.python.org/dev/peps/pep-0373/
[2] https://www.python.org/downloads/release/python-392/

René,
on behalf of portmgr
-BEGIN PGP SIGNATURE-

iQGyBAEBCgCcFiEE+zdFyG8V6O2sgTL82ClOw7vE19UFAmBbOBpfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZC
Mzc0NUM4NkYxNUU4RURBQzgxMzJGQ0Q4Mjk0RUMzQkJDNEQ3RDUeHHBvcnRtZ3It
c2VjcmV0YXJ5QGZyZWVic2Qub3JnAAoJENgpTsO7xNfVVB4IAIIzuJare4IiEpAs
H+ro/OdZ8J9t+p/Vhv5pRUmN1fhL38gvlmvKSbnm/1HCfXQY8WjccX+9UUsIudLl
kkI020DDSC4shESsCnsTGXTr13psS+DjCTdjpgRlaWb38yL8bSoPyyA12jJFVYDi
doRkWGleIZrz9kh1lDOX4rzB9hui6B5VFNktcbkG2+h+xs1huhq9/VdyCVRJC6gM
kss1yBH04VXqa3G5K2vj4w+sPRQi4gNKA9fkoLIJlpnNZ3QFVxLR+Xa1ySUEQhCE
gIRYkZmjLiMoDJizN2d9CGAVSvDvvl+g3tGdP24DwRiHdnofaNijUV7xhNslYiE3
m7QBFbI=
=2WOV
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Miroslav Lachman]

On 24/03/2021 14:03, Rene Ladan wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

below is an outline continuing the Python 2.7 cleanup:

- - all affected ports are now marked as deprecated, with an expiration date
   of either 2020-12-31 or 2021-06-23.
- - we will have to wait for Chromium to fully switch to Python 3 before we
   can fully remove Python 2.7. This is work in progress on their side. Not
   waiting would imply removing www/chromium (obviously), editors/vscode
   (it escaped the recursive-deprecation dance of devel/electron*), but most
   importantly www/qt5-webengine which would drag half of KDE with it.
   However, lang/python27 will be marked as RESTRICTED so that all ports
   mentioned above can still be built and run, but Python 2.7 itself will
   not be available as a package.


[...]

I really appreciate the work of ports team, committers and maintainers 
but I dislike double standards. All ports requiring Python 2.7 were 
marked deprecated the last year almost all of them removed according to 
expiration date 2020-12-31 but some of them are still there.
If there is Python 2.7, if there is Chromium then any of removed ports 
can be there. If "we" want to get rid of them then "we" should remove 
all of them and not just some by sentiment.
For example Iridium browser was removed because of Python 2.7 but 
Chromium is still there. They are both based on the same source with the 
same dependencies but Iridium cares more about privacy, yet it was 
slaughtered instead of Chromium.

I really would like to see some policies for things like this next time.

Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Guido Falsi via freebsd-ports]

On 24/03/21 14:03, Rene Ladan wrote:

Hi,

below is an outline continuing the Python 2.7 cleanup:

- all affected ports are now marked as deprecated, with an expiration date
   of either 2020-12-31 or 2021-06-23.
- we will have to wait for Chromium to fully switch to Python 3 before we
   can fully remove Python 2.7. This is work in progress on their side. Not
   waiting would imply removing www/chromium (obviously), editors/vscode
   (it escaped the recursive-deprecation dance of devel/electron*), but most
   importantly www/qt5-webengine which would drag half of KDE with it.
   However, lang/python27 will be marked as RESTRICTED so that all ports
   mentioned above can still be built and run, but Python 2.7 itself will
   not be available as a package.


Just to be sure I get everything right.

The idea is to try to have www/qt5-webengine fixed before the expiration 
time, saving with it a bunch of innocent ports depending on it, correct?


P.S. I want to make clear I have no objection about the removal of 
python 2.7 and I'm really appalled by the situation with chrome build 
system (*). I'm just letting the little worried user inside me express 
his worries. I'd like to understand how we can reach the objective 
without killing a bunch of perfectly working, supported and useful 
software that is now being deprecated due to depending on 
chrmoium/webengine. So I only ask a few questions to get the picture.


If I sound rude please pardon me, I really don't mean to be rude or 
demanding!


[...]

- Upstream Chromium is working on converting their codebase to Python 3 but
   there is no completion date. Interestingly, adridg@ is experimenting with
   converting www/qt5-webengine to Python 3 too.


Is there some ETA on these? Is it realistically possible for these to be 
ready before the end of June?



- We are indeed faster with dropping Python 2.7 than e.g. Ubuntu, however
   more recent Debian/Ubuntu distributions are more and more dropping Python
   2.7 too. This also has to do with how their branching model works, the
   package set of Ubuntu LTS is determined a few months before the release
   itself.


Is the deadline amendable if the plan does not unfold as expected? Or 
are we really going to drop kde and a bunch of other working software to 
stand out ground?




(*) I'm also really appalled by the fact that in the last few years 
almost any software started having the need to include a fully fledged 
html5/js engine but this is another story.


--
Guido Falsi 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Bob Eager]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 24 Mar 2021 13:03:47 +
Rene Ladan  wrote:

> - - mail/mailman is being replaced by clusteradm@  with mlmmj. You
> can use `pkg lock` to stick with it after removal, if there is no
> other way.

Is anyone working on a mailman 3 port?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEVgdI2KeVldPAhUYaKBdf2az8e6gFAmBbsuUACgkQKBdf2az8
e6hBBQf/QpIe1al7QocpZTs52hZqLxB0kUuj+iT4A4SYoVQXj31XC6CZCUWuTU4V
5jXjCPg1g5AfafU+lS4oaBanm/UQmOlOiPcg5Wjp2OpSbA5HJ0EY4wERD7ZBIYQj
n3W5JzUBp7N3PwlWFI8L8tI+GFGz+O0/myNz5pQQHtQyFyDtJQuh6IgJfysV4n0U
ojrTALRwf3ZS23thOMekavSmd0UPiKL9BpTI8jurtSsbkz48QNxzlilF9IoE5Phf
bOxRjbCNWcTCvB3JEmB6Q8+1WPhbpUONs6qhpM14njr5b36uH46yXBb/8wv8Jekc
wnF9CAIPE7N6zE2FfQZIDhIOg0W5gQ==
=yPOi
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Baptiste Daroussin]

On Wed, Mar 24, 2021 at 09:45:09PM +, Bob Eager wrote:
> On Wed, 24 Mar 2021 13:03:47 +
> Rene Ladan  wrote:
> 
> > - - mail/mailman is being replaced by clusteradm@  with mlmmj. You
> > can use `pkg lock` to stick with it after removal, if there is no
> > other way.
> 
> Is anyone working on a mailman 3 port?

it is already in: mail/mailman3

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Python 2.7 removal outline

[Dan Mahoney (Ports)]

There are packages for mailman3 but they’re incomplete and don’t result in a 
working install the way the 2.x build does.  You also need mysql, django, etc 
etc.

Needing django is almost as bad as saying “sure, the web UI depends on 
WordPress”.  It’s not standalone cgi’s that you can just scriptalias in to 
apache, and the documentation leaves a lot fo be desired.

I’ve been in touch with Mark Sapiro (current maintainer of mailman 2.x, limping 
along in critical-patches-only mode) and 3.x, and have other friends on the 
maint team.  Mark has committed to making some time to make 3.x work as simply 
as 2.x does, as it lowers his support load.

At some point, I want to sit down with the code and come up with a “okay, if a 
port doesn’t provide this, here’s at least a howto”.

Day job uses mailman2 (we’re a company that makes some DNS software that you’ve 
probably heard of), so this is of interest both for personal reasons as well as 
community.

If anyone else is currently maintaining a mailman3 port, please get in touch!

-Dan

> On Mar 24, 2021, at 2:45 PM, Bob Eager  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Wed, 24 Mar 2021 13:03:47 +
> Rene Ladan  wrote:
> 
>> - - mail/mailman is being replaced by clusteradm@  with mlmmj. You
>> can use `pkg lock` to stick with it after removal, if there is no
>> other way.
> 
> Is anyone working on a mailman 3 port?
> -BEGIN PGP SIGNATURE-
> 
> iQEzBAEBCAAdFiEEVgdI2KeVldPAhUYaKBdf2az8e6gFAmBbsuUACgkQKBdf2az8
> e6hBBQf/QpIe1al7QocpZTs52hZqLxB0kUuj+iT4A4SYoVQXj31XC6CZCUWuTU4V
> 5jXjCPg1g5AfafU+lS4oaBanm/UQmOlOiPcg5Wjp2OpSbA5HJ0EY4wERD7ZBIYQj
> n3W5JzUBp7N3PwlWFI8L8tI+GFGz+O0/myNz5pQQHtQyFyDtJQuh6IgJfysV4n0U
> ojrTALRwf3ZS23thOMekavSmd0UPiKL9BpTI8jurtSsbkz48QNxzlilF9IoE5Phf
> bOxRjbCNWcTCvB3JEmB6Q8+1WPhbpUONs6qhpM14njr5b36uH46yXBb/8wv8Jekc
> wnF9CAIPE7N6zE2FfQZIDhIOg0W5gQ==
> =yPOi
> -END PGP SIGNATURE-
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Matthias Andree]

Am 24.03.21 um 22:48 schrieb Baptiste Daroussin:
> On Wed, Mar 24, 2021 at 09:45:09PM +, Bob Eager wrote:
>> On Wed, 24 Mar 2021 13:03:47 +
>> Rene Ladan  wrote:
>>
>>> - - mail/mailman is being replaced by clusteradm@  with mlmmj. You
>>> can use `pkg lock` to stick with it after removal, if there is no
>>> other way.
>> Is anyone working on a mailman 3 port?
> it is already in: mail/mailman3

As stated several times before, mailman 3 is not a suitable successor to
mailman 2 and has no migration tool. Archives are incompatible. It is a
redesign from scratch that lost a lot of mailman 2 wisdom along the way.

Mailman  is certainly no replacement for mailman 2 and can't appear on
the RHS of ports/MOVED.



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Matthias Andree]

Am 24.03.21 um 14:03 schrieb Rene Ladan:
> Hi,
>
> below is an outline continuing the Python 2.7 cleanup:
>
> - No usage of lang/tauthon by the framework or any port, no excuses.
> - lang/tauthon will be removed on 2021-06-23 as noticed in the port
> itself,
>   no excuses. Tauthon is not guaranteed to be compatible with any official
>   Python version so keeping it would just unnecessarily complicate things.
> - mail/mailman is being replaced by clusteradm@  with mlmmj. You can use
>   `pkg lock` to stick with it after removal, if there is no other way.
> - you are of course free to provide your own version of Python 2.7,
> Tauthon
>   and any application using those languages in your local setup, by using
>   overlays for example.

Rene,

I am sorry to say that this is appalling

* Why do you badmouth Tauthon as "not guaranteed to be compatible..." if
that is its very design goal?

  - "Tauthon is a backwards-compatible fork of the Python 2.7.18
interpreter with new syntax, builtins, and libraries backported from
Python 3.x. Python code and C-extensions targeting Python 2.7 or below
are expected to run unmodified on Tauthon and produce the same output."


* What do you mean that "Tauthon [...] would unnecessarily complicate
things"? What things specifically, and how?

It might be a migration path to a maintained interpreter (we need
nothing more, no fancy developments, to keep other ports in maintenance
mode with a security update now and then, going).

What other Python 2.x compatible interpreter would you propose instead
of Tauthon?

* Why, other than based on your false claims, is Tauthon being removed?

* Why, other than based on your false claims, is Tauthon being rejected?

* Why does anyone think that clusteradm@'s removal of ONE instance of
mailman 2 by some unmaintained (*) software is a justification to ditch
mailman 2?

* Why do you mislead people on "you are of course free to provide you
own version of " when at the same time you threaten to remove
other ports.


While I am certainly fine with "no new Python 2 ports permitted", the
refusal of Tauthon certainly warrants justification.


(*) release frequency was abused as argument against mailman 2 - only
that since the latest mlmmj release, there have been eleven mailman 2.1
releases.


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Matthias Andree]

Am 24.03.21 um 22:50 schrieb Dan Mahoney (Ports):

> There are packages for mailman3 but they’re incomplete and don’t
result in a working install the way the 2.x build does.  You also need
mysql, django, etc etc.

Dan, please check if we already have bug reports on the mailman 3 issues
and where they are missing, file new bug reports as needed, to make this
visible. https://bugs.freebsd.org/

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Dewayne Geraghty]

On 25/03/2021 4:01 am, Miroslav Lachman wrote:

> I really appreciate the work of ports team, committers and maintainers
> but I dislike double standards. All ports requiring Python 2.7 were
> marked deprecated the last year almost all of them removed according to
> expiration date 2020-12-31 but some of them are still there.
> If there is Python 2.7, if there is Chromium then any of removed ports
> can be there. If "we" want to get rid of them then "we" should remove
> all of them and not just some by sentiment.
> For example Iridium browser was removed because of Python 2.7 but
> Chromium is still there. They are both based on the same source with the
> same dependencies but Iridium cares more about privacy, yet it was
> slaughtered instead of Chromium.
> I really would like to see some policies for things like this next time.
> 
> Miroslav Lachman

Thanks Miroslav, I have the same view.  Though I agree with Rene about
the need to remove vulnerable ports and the interests of the FreeBSD
community, its worth considering those with both a need and an
understanding of the ramifications of using python2.7.

We've been disappointed having to digress from the ports infrastructure
to continue with python2.7 applications that we need, which were removed
(a year ago).  It could've been so much more pleasant had a
"restricted", or better option been employed.

No new ports requiring python2.7 is an excellent suggestion in terms of
maintaining a viable user-base (kudos Mathias).  For how long, is
another discussion.

Though after reading through
https://reviews.freebsd.org/D28665
are we expecting to keep KDE users on FreeBSD post June 23 (without
www/qt5-webengine, konqueror, kontact, kmail,...)?

And its incongruous to say talk about upstream abandoning applications,
as many continue to maintain "their" software with a now unsupported
product (py2.7).  Again the need outweighs the risk (for us) vs the
upstream cost of conversion.  It is an unpleasant though necessary  choice.

And for the fear-mongers, with a good FreeBSD firewall and strong
security mindset, vulnerabilities can be substantially mitigated; and it
really should be an option (for experienced folk) to be able to use what
is *needed* while properly comprehending the risk vs maintaining an
increasingly digressive ports infrastructure.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Guillermo Hernandez (Oldno7) via freebsd-ports]

On 24/3/21 22:50, Dan Mahoney (Ports) wrote:
> There are packages for mailman3 but they’re incomplete and don’t 
result in a working install the way the 2.x build does.  You also need 
mysql, django, etc etc.

>
> Needing django is almost as bad as saying “sure, the web UI depends 
on WordPress”.  It’s not standalone cgi’s that you can just scriptalias 
in to apache, and the documentation leaves a lot fo be desired.

>
> I’ve been in touch with Mark Sapiro (current maintainer of mailman 
2.x, limping along in critical-patches-only mode) and 3.x, and have 
other friends on the maint team.  Mark has committed to making some time 
to make 3.x work as simply as 2.x does, as it lowers his support load.

>

> At some point, I want to sit down with the code and come up with a 
“okay, if a port doesn’t provide this, here’s at least a howto”.


There is a thread in forums.freebsd.org with a detailed implementation 
of successful cases of transiting from mailman2 to mailman3 in freebsd, 
but all of them outside the ports infrastructure for the main apps 
(using pip):


https://forums.freebsd.org/threads/mailman-3.61050/



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Miroslav Lachman]

On 25/03/2021 07:26, Dewayne Geraghty wrote:

On 25/03/2021 4:01 am, Miroslav Lachman wrote:


I really appreciate the work of ports team, committers and maintainers
but I dislike double standards. All ports requiring Python 2.7 were
marked deprecated the last year almost all of them removed according to
expiration date 2020-12-31 but some of them are still there.
If there is Python 2.7, if there is Chromium then any of removed ports
can be there. If "we" want to get rid of them then "we" should remove
all of them and not just some by sentiment.
For example Iridium browser was removed because of Python 2.7 but
Chromium is still there. They are both based on the same source with the
same dependencies but Iridium cares more about privacy, yet it was
slaughtered instead of Chromium.
I really would like to see some policies for things like this next time.

Miroslav Lachman


Thanks Miroslav, I have the same view.  Though I agree with Rene about
the need to remove vulnerable ports and the interests of the FreeBSD
community, its worth considering those with both a need and an
understanding of the ramifications of using python2.7.


From the security point of view I can agree with removing ports 
requiring Python 2.7 as run dependency but if I have it right, Iridium 
nor Chromium have it as run dependency. Python is needed for build only 
so users of Chromium, Iridium and many other ports / packages do not 
need to have vulnerable Python 2.7 installed. But these ports were 
removed anyway even if there is not proper replacement. Or in case of 
Chromium vs Iridium the better one was removed.


Kind regards
Miroslav Lachman

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Olivier Certner]

Hi,

Maintainer of Tauthon here, and of Pale Moon (for the few hours it lived in 
the tree in February; but I'm still pushing updates to PR 251117).

I find this announcement very much disappointing, because the situation for 
ports that need Python 2.7 or similar to build doesn't seem to have changed at 
all. In short, we are just told (again) that they should disappear.

But now we are told also that there are exceptions to the general rule. And 
even worse (or better, for the comical effect), that the Chromium exception is 
going to force its agenda on portmgr@, because nobody seems to really know 
when that migration will complete (having quickly studied how it worked out 
for Firefox, I'm willing to bet this will never happen before June, and likely 
will not before the end of this year either). "I love it when a plan comes 
together."

I had hoped that portmgr@ would turn to me (and others in the same situation) 
with at least some way out to allow Pale Moon to go into the ports tree. In 
its mail, the closest thing I can find is this:
> - you are of course free to provide your own version of Python 2.7, Tauthon
>   and any application using those languages in your local setup, by using
>   overlays for example.
So, if I understand correctly, in its great magnanimity, portmgr@ allows us to 
do what we want locally. Gosh! That's news. Didn't know I had been violating 
the law for the past 10 years by doing exactly that with my set of patches to 
the ports tree (a long way before overlays even existed; that said, I think 
overlays are helpful, more on that below).

And there's more in the same "tone":
> No excuses. * 3
You probably were not addressing this to me in particular (at least I hope). 
But just in case, did you mean: Excuses for not respecting a non-existing 
policy?

In December last year, I submitted Tauthon with the goals to be able to use it 
to build Pale Moon and help others that needed to run 2.7 code despite phasing 
out of PSF's interpreter. It was pushed on 2020/12/11. I then submitted an 
upstream-approved official version of Pale Moon port, that was pushed on 
2021/02/15. It was removed less than 4 hours later, together with Tauthon, in 
"rage commit" 565350 by antoine@, without any public (or private to me) 
communication, before or after. Except for one thing: He responsed to my 
request for explanations by saying: "When we deprecate python 2.7, we also 
deprecate all forks of python 2.7.".

That also was news to me. Don't know how many ports would have to be removed 
if this rule was followed for all forks of now deprecated projects. I don't 
think there would be only a few of them. What about the fact that Tauthon has 
lived 2 months in the tree up to the removal? What about that it was 
contributed through a public PR, linked to other Python-related PRs by some 
committers? What about that nobody issued a public objection to its presence 
on said PR or on mailing lists? What about that it is still listed *today* on 
the wiki's WantedPorts page? Never had a single answer on all this. Surely 
these must have been signs that what I was doing was very wrong indeed, and 
against a very clear and strong policy, which I should have understood by 
myself. Idiot me.

I'm not going to repeat here the long mail I wrote in response to FUD being 
spread about Pale Moon (and even Tauthon and Python 2.7 to some extent) by 
rene@ and danfe@, and its excruciating details on how deluded they were 
(still are?). These mails were for committers only, and exchanged on 
2021/02/2{1,2}.

I'll just quickly point out the new FUD and inaccuracies, add some facts and 
opinions to the picture, and wrap up with two possible ways out.

> Tauthon is not guaranteed to be compatible with any official
>   Python version so keeping it would just unnecessarily complicate things.

mandree@ preceeded me, so not going to add much except that Tauthon in 
practice lives up to its promise (there are incompatibilities due to the 
introduction of some Python 3 features, but they are very minimal and hard to 
trigger; unfortunately for me, Pale Moon's weird build system, inherited from 
Mozilla, triggered some).

As to why it would complicate things, we are left with no clue, especially 
given that Tauthon is not hooked at all into python.mk and that no port 
currently depends on it (Pale Moon having been removed).

> - On a related note, most software using Python 2.7 was already removed
>   from the Ports Tree last year, a lot of it being unmaintained or
>   more or less abandoned upstream.

1. Most is not all, unfortunately. What happens for the rest? Is "Well, let's 
pretend it doesn't exist, and shut the contributors up." your response? 
Seriously?
2. Security is a non-issue for build-only dependencies.

> - We are indeed faster with dropping Python 2.7 than e.g. Ubuntu, however
>   more recent Debian/Ubuntu distributions are more and more dropping Python
>   2.7 too. This also has to do with how their branching mo

Re: Python 2.7 removal outline

[Baptiste Daroussin]

On Thu, Mar 25, 2021 at 12:02:29PM +0100, Olivier Certner wrote:
> Hi,
> 
> Maintainer of Tauthon here, and of Pale Moon (for the few hours it lived in 
> the tree in February; but I'm still pushing updates to PR 251117).
> 
> I find this announcement very much disappointing, because the situation for 
> ports that need Python 2.7 or similar to build doesn't seem to have changed 
> at 
> all. In short, we are just told (again) that they should disappear.
> 
> But now we are told also that there are exceptions to the general rule. And 
> even worse (or better, for the comical effect), that the Chromium exception 
> is 
> going to force its agenda on portmgr@, because nobody seems to really know 
> when that migration will complete (having quickly studied how it worked out 
> for Firefox, I'm willing to bet this will never happen before June, and 
> likely 
> will not before the end of this year either). "I love it when a plan comes 
> together."
> 
> I had hoped that portmgr@ would turn to me (and others in the same situation) 
> with at least some way out to allow Pale Moon to go into the ports tree. In 
> its mail, the closest thing I can find is this:
> > - you are of course free to provide your own version of Python 2.7, Tauthon
> >   and any application using those languages in your local setup, by using
> >   overlays for example.
> So, if I understand correctly, in its great magnanimity, portmgr@ allows us 
> to 
> do what we want locally. Gosh! That's news. Didn't know I had been violating 
> the law for the past 10 years by doing exactly that with my set of patches to 
> the ports tree (a long way before overlays even existed; that said, I think 
> overlays are helpful, more on that below).
> 
> And there's more in the same "tone":
> > No excuses. * 3
> You probably were not addressing this to me in particular (at least I hope). 
> But just in case, did you mean: Excuses for not respecting a non-existing 
> policy?
> 
> In December last year, I submitted Tauthon with the goals to be able to use 
> it 
> to build Pale Moon and help others that needed to run 2.7 code despite 
> phasing 
> out of PSF's interpreter. It was pushed on 2020/12/11. I then submitted an 
> upstream-approved official version of Pale Moon port, that was pushed on 
> 2021/02/15. It was removed less than 4 hours later, together with Tauthon, in 
> "rage commit" 565350 by antoine@, without any public (or private to me) 
> communication, before or after. Except for one thing: He responsed to my 
> request for explanations by saying: "When we deprecate python 2.7, we also 
> deprecate all forks of python 2.7.".
> 
> That also was news to me. Don't know how many ports would have to be removed 
> if this rule was followed for all forks of now deprecated projects. I don't 
> think there would be only a few of them. What about the fact that Tauthon has 
> lived 2 months in the tree up to the removal? What about that it was 
> contributed through a public PR, linked to other Python-related PRs by some 
> committers? What about that nobody issued a public objection to its presence 
> on said PR or on mailing lists? What about that it is still listed *today* on 
> the wiki's WantedPorts page? Never had a single answer on all this. Surely 
> these must have been signs that what I was doing was very wrong indeed, and 
> against a very clear and strong policy, which I should have understood by 
> myself. Idiot me.
> 
> I'm not going to repeat here the long mail I wrote in response to FUD being 
> spread about Pale Moon (and even Tauthon and Python 2.7 to some extent) by 
> rene@ and danfe@, and its excruciating details on how deluded they were 
> (still are?). These mails were for committers only, and exchanged on 
> 2021/02/2{1,2}.
> 
> I'll just quickly point out the new FUD and inaccuracies, add some facts and 
> opinions to the picture, and wrap up with two possible ways out.
> 
> > Tauthon is not guaranteed to be compatible with any official
> >   Python version so keeping it would just unnecessarily complicate things.
> 
> mandree@ preceeded me, so not going to add much except that Tauthon in 
> practice lives up to its promise (there are incompatibilities due to the 
> introduction of some Python 3 features, but they are very minimal and hard to 
> trigger; unfortunately for me, Pale Moon's weird build system, inherited from 
> Mozilla, triggered some).
> 
> As to why it would complicate things, we are left with no clue, especially 
> given that Tauthon is not hooked at all into python.mk and that no port 
> currently depends on it (Pale Moon having been removed).
> 
> > - On a related note, most software using Python 2.7 was already removed
> >   from the Ports Tree last year, a lot of it being unmaintained or
> >   more or less abandoned upstream.
> 
> 1. Most is not all, unfortunately. What happens for the rest? Is "Well, let's 
> pretend it doesn't exist, and shut the contributors up." your response? 
> Seriously?
> 2. Security is

Re: Python 2.7 removal outline

[Jose Quinteiro]

I meant to send this reply to the list. I beg for @bapt's forgiveness
for the inbox echo.

On 3/25/21 8:03 AM, Baptiste Daroussin wrote:
> On Thu, Mar 25, 2021 at 12:02:29PM +0100, Olivier Certner wrote:
>>
>> 2. Leverage overlays to provide additional repos, a bit like AUR for Arch. 
>> Here I'm in fact building on top of one of bapt@'s ideas. Sounds great for 
>> publishing ports that are not in the official tree. But not necessarily for 
>> package building: I personally won't commit to maintaining a separate build 
>> cluster for all arches and supported FreeBSD versions, in the short term at 
>> least.
> 
> I really think we should as a project move forward to that direction, it does
> not even need to be driven by protmgr or even drive by any @freebsd.org
> 
> I would argue here that it is even more interesting to go the gentoo way try 
> to
> provide a tool to just server as a directory of available overlays
> with https://github.com/freebsd/poudriere/pull/798 and
> https://github.com/freebsd/poudriere/pull/797 it is even easier to public a
> light repo per overlay.

Former Gentoo overlays user here, chiming in with my experience. I wound
up maintaining my own overlay to work around upstream decisions that
didn't make sense to me. I found myself spending increasingly large
amounts of time working on this overlay over the years, until it started
to take so much time and effort that I questioned my decision to stick
with the platform. It certainly seemed like wasted effort since my
changes would never be accepted upstream, and I don't have the time or
money to launch an almost certainly unsuccessful Gentoo fork. I'm now
(back) here.

I'm not saying that overlays are bad and that they will necessary lead
to the same situation, but I do believe that saying "just put it in an
overlay" makes it easier to ignore your community's wishes precisely
when it's perhaps least advisable to do so.

If you look over in the forums you'll see at least several people
looking for Palemoon, Seamonkey, and other ways out of the
Firefox-Google hegemony. It really does seem arbitrary and capricious to
make an exception for Chromium, but not for these other browsers that
only need Tauthon as a build dependency.

Thanks,
Jose
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Matthias Andree]

Am 25.03.21 um 16:03 schrieb Baptiste Daroussin:
>
> I really think we should as a project move forward to that direction, it does
> not even need to be driven by protmgr or even drive by any @freebsd.org
>
> I would argue here that it is even more interesting to go the gentoo way try 
> to
> provide a tool to just server as a directory of available overlays
> with https://github.com/freebsd/poudriere/pull/798 and
> https://github.com/freebsd/poudriere/pull/797 it is even easier to public a
> light repo per overlay.

I haven't looked at the links, the general thought of providing local
overlays outside @freebsd.org subverts the purpose of a ports tree.

Look, we've been spending lots of efforts over the years to make the
ports tree accessible and customizable and a consistent experience.
Tinderbox, staging, Poudriere, OptionsNG, Pkg, Flavours (that needs some
better integration), binary package provisioning. If we now defer users
to "maintain locally" that pushes an effort that was formerly
centralized down to many people and leave them in a situation that
reduces the effectiveness of the pkg and ports setups.
It is not a solution to the issue at hand.

Olivier Certner:

> > I re-read portmgr@'s charter
> (https://www.freebsd.org/portmgr/charter/). I
> > wish it contained points about proper planning, communication and
> helping
> > maintainers and committers instead of destroying their work without
> notice,
> > even for "niche" ports. Perhaps it doesn't because this was implicit
> or taken
> > for granted. In which case, in light of recent events, it may be a
> good time
> > to revise it.

bapt:

> I will only here answer about the quality of the communication of
> portmgr, yes
> there is room of improvement in general in the current portmgr team as
> of how we
> do communicate about plans and policy and we are working on it.
Unfortunately this is not the first situation where the current or
previous portmgr@'s policy changes hit the public in a hit-and-run
style. Earlier portmgr@'s set higher standards of communicating with the
community. The decision-making does not appear transparent, and the
evaluation of consequences in some cases such as this appears
incomplete, or at least incompletely documented to the public.

If now one of the portmgr@ members, as much as I value his or her work
normally, starts justifying the Python 2.7 withdrawal outline with
untrue opinions that are sold as facts, I think your words are too weak
to describe the woe state of this particular current motion. I do
appreciate the relevant reviews.freebsd.org discussions and
preparations, but I find it inacceptable to just clear away Tauthon in
the same sweep without any discussion.

Irony contained: If our intention is to seed uncertainty among our users
and see them away in droves, then our recent management of the Python
2.7 removal is finally picking up to speed.

That, however, is not how FreeBSD used to serve its users.


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Matthias Andree]

Am 24.03.21 um 23:11 schrieb Matthias Andree:
> Am 24.03.21 um 22:50 schrieb Dan Mahoney (Ports):
>
>> There are packages for mailman3 but they’re incomplete and don’t
> result in a working install the way the 2.x build does.  You also need
> mysql, django, etc etc.
>
> Dan, please check if we already have bug reports on the mailman 3 issues
> and where they are missing, file new bug reports as needed, to make this
> visible. https://bugs.freebsd.org/
>
My apologies for the broken quoting.

Dan Mahoney wrote:

> There are packages for mailman3 but they’re incomplete and don’t result in a 
> working install the way the 2.x build does.  You also need mysql, django, etc 
> etc.
I replied:

Dan, please check if we already have bug reports on the mailman 3 issues
and where they are missing, file new bug reports as needed, to make this
visible. https://bugs.freebsd.org/

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Roger Marquis]

I find this announcement very much disappointing, because the situation for
ports that need Python 2.7 or similar to build doesn't seem to have changed at
all. In short, we are just told (again) that they should disappear.


Many end-users who maintain python2 code, both application and install
deps, are in the same boat.  We too are disappointed because:

  A) it would be exceedingly simple to modify lang/python2 to include
 alternate interpreters (of which there is more than 1) with little
 or no maintenance overhead

  B) no reasons are given for the deprecation

  C) community input has been ignored

  D) all of which inflates IT management bias against FreeBSD vis-a-vis
 RH, CentOS and Ubuntu (and probably others) which continue to have
 python2 compatibility for several years without having to do
 anything special


I had hoped that portmgr@ would turn to me (and others in the same situation)
with at least some way out to allow Pale Moon to go into the ports tree.


Careful.  We have been told that it is not appropriate to criticize the
hardworking volunteers or their decisions because, well, because they
are volunteers.  Even criticizing policy often solicits a sharp rebuke 
(violating the code of conduct not that it is ever enforced).



Except for one thing: He responsed to my request for explanations by
saying: "When we deprecate python 2.7, we also deprecate all forks of
python 2.7.".


Is there a good reason for this?  Would be great to know if so.  Is a
mystery otherwise.  The IT security paranoid in me suspects an ulterior
motive but what would that be?


I re-read portmgr@'s charter (https://www.freebsd.org/portmgr/charter/). I
wish it contained points about proper planning, communication and helping
maintainers and committers instead of destroying their work without notice,
even for "niche" ports. Perhaps it doesn't because this was implicit or taken
for granted. In which case, in light of recent events, it may be a good time
to revise it.


Agreed.

Roger Marquis
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Miroslav Lachman]

On 25/03/2021 16:03, Baptiste Daroussin wrote:


I will only here answer about the quality of the communication of portmgr, yes
there is room of improvement in general in the current portmgr team as of how we
do communicate about plans and policy and we are working on it.


"There is room of improvement" are too kind words.
It happened in the past and it is back again. As explained by Olivier 
and the others in this thread there are no clear policy written and 
explained to the community, there are mixed terms "all" / "but some 
exceptions" chosen by what criteria, defined by what policy?
It is really annoying for maintainers like Olivier to spend some time to 
provide solution for port useful for others (Pale Moon and Tauthon in 
this case) and have it removed from the tree after 4 hours without prior 
discussion or notice.

Who will benefit from this behaviors?
It all seems more like witch hunting than any rational moves for 
community profit.


Telling users that they can maintain it locally is like p***ing them in 
face. And until overlays are not fully supported with poudriere options 
and easily defined exceptions for MOVED entries it is really not for 
everybody to use overlays in current state (overlays are poor documented 
at least).


Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[George Mitchell]

On 3/25/21 6:06 PM, Miroslav Lachman wrote:

[...]  it is really not for
everybody to use overlays in current state (overlays are poor documented 
at least).

[...]


Until this thread I had never heard of them.  -- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: Python 2.7 removal outline

[Dewayne Geraghty]

On 26/03/2021 9:25 am, George Mitchell wrote:
> On 3/25/21 6:06 PM, Miroslav Lachman wrote:
>> [...]  it is really not for
>> everybody to use overlays in current state (overlays are poor
>> documented at least).
>> [...]
> 
> Until this thread I had never heard of them.  -- George
> 
Yes me too. poudriere isn't on our radar so its another layer of
complexity entering the build fray.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Dave Horsfall]

On Thu, 25 Mar 2021, George Mitchell wrote:

[...] it is really not for everybody to use overlays in current state 
(overlays are poor documented at least). [...]


Until this thread I had never heard of them.  -- George


I can't remember the last time I used overlays (certainly with CP/M); I 
didn't know that FreeBSD even supported them (why bother when you've got 
VM?).


-- Dave
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Chris]

There have been a great many comments on this matter on the
mailing list. All the replies are valuable. But (this) original
post has been trimmed in all those replies. So in an effort to
maintain context to the original statement. I'm making my reply
here. Which reflects the attitude of most all of the replies made
to this announcement. My comments below this initial announcement...

On 2021-03-24 06:03, Rene Ladan wrote:

Hi,

below is an outline continuing the Python 2.7 cleanup:

- all affected ports are now marked as deprecated, with an expiration date
  of either 2020-12-31 or 2021-06-23.
- we will have to wait for Chromium to fully switch to Python 3 before we
  can fully remove Python 2.7. This is work in progress on their side. Not
  waiting would imply removing www/chromium (obviously), editors/vscode
  (it escaped the recursive-deprecation dance of devel/electron*), but most
  importantly www/qt5-webengine which would drag half of KDE with it.
  However, lang/python27 will be marked as RESTRICTED so that all ports
  mentioned above can still be built and run, but Python 2.7 itself will
  not be available as a package.
- No more new ports having USES=python:2.7 or USES=python:2.7+ or existing
  ports reverting to that, no excuses.
- No usage of lang/tauthon by the framework or any port, no excuses.
- lang/tauthon will be removed on 2021-06-23 as noticed in the port itself,
  no excuses. Tauthon is not guaranteed to be compatible with any official
  Python version so keeping it would just unnecessarily complicate things.
- mail/mailman is being replaced by clusteradm@  with mlmmj. You can use
  `pkg lock` to stick with it after removal, if there is no other way.
- you are of course free to provide your own version of Python 2.7, Tauthon
  and any application using those languages in your local setup, by using
  overlays for example.

Miscellaneous tidbits:
- WHY?!?!? Well, back in 2008, the Python Software Foundation planned to
  mark Python 2.7 end-of-life at 2015-01-01, see [1], but that date was
  pushed back to 2020-01-01 because a lot of downstream users had not
  converted yet. So Python 2.7 is already end-of-life for 1.5 years, which
  means that according to [1] the PSF is no longer fixing security issues
  for it. As can be seen on [2], multiple vulnerabilities already have
  been fixed for Python 3.6 to 3.9 this year.
- On a related note, most software using Python 2.7 was already removed
  from the Ports Tree last year, a lot of it being unmaintained or
  more or less abandoned upstream.
- Upstream Chromium is working on converting their codebase to Python 3 but
  there is no completion date. Interestingly, adridg@ is experimenting with
  converting www/qt5-webengine to Python 3 too.
- We are indeed faster with dropping Python 2.7 than e.g. Ubuntu, however
  more recent Debian/Ubuntu distributions are more and more dropping Python
  2.7 too. This also has to do with how their branching model works, the
  package set of Ubuntu LTS is determined a few months before the release
  itself.

[1] https://www.python.org/dev/peps/pep-0373/
[2] https://www.python.org/downloads/release/python-392/

Ren,
on behalf of portmgr


OK ports maintenance is almost exclusively on a volunteer/best
effort basis. Most Maintainers have a $DayJob. Some have $Family.
Some (not me) have something they call a $Life. Through all that,
they somehow manage to make time to adopt, and Maintain one or
more ports. Some -- perhaps many, do it because they're grateful
for FreeBSD and all the efforts made to create, and keep it a first
class OS. So in an effort to show their gratitude, attempt to
give-back by becoming a Maintainer. Some are programmers, some
are hackers, and some are just starting out. Often times for
seasoned Maintainers the task itself is relatively routine. But
Maintaining ports, even for seasoned Maintainers can be hard work.
If not because of the actual problem itself. To manage to find
the required time to get the job done in an acceptable time frame.
For the unseasoned Maintainer. The job can often be hard.
Why does our work have so little value that portmgr@ is unwilling
to keep us all in the loop, or consider our opinions on such matters?
Is it just me? Or is there a gross disconnect here?
Maintainers need a Forum where their views on ports matters get
some semblance of credence. Hell. I maintain some 160 ports. That's
got to be worth *something*.

Chris out...
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Kurt Jaeger]

Hi!

> Why does our work have so little value that portmgr@ is unwilling
> to keep us all in the loop, or consider our opinions on such matters?

The portmgr@ role is a huge task and all the reasons (limited time,
dayjobs, etc) ares  valid for those folks from portmgr as for
the rest of the ports maintainers and committers.

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Chris]

On 2021-03-25 22:24, Kurt Jaeger wrote:

Hi!


Why does our work have so little value that portmgr@ is unwilling
to keep us all in the loop, or consider our opinions on such matters?


The portmgr@ role is a huge task and all the reasons (limited time,
dayjobs, etc) ares  valid for those folks from portmgr as for
the rest of the ports maintainers and committers.

Indeed, and don't think that hadn't occurred to me. In fact I suspected
that portmgr@ was feeling a bit overwhelmed, and that *that* triggered
the seemingly overreaching python announcement.
May I humbly request a petition for such large-sweeping changes? IMHO
this will give portmgr@ the opportunity to get caught up, and perhaps
get some assistance -- maybe we all come up with an idea that saves
_everyones_ bacon. :-)


Thanks for the thoughtful reply.

--Chris
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[RW via freebsd-ports]

On Fri, 26 Mar 2021 13:55:33 +1100 (EST)
Dave Horsfall wrote:

> On Thu, 25 Mar 2021, George Mitchell wrote:
> 
> >> [...] it is really not for everybody to use overlays in current
> >> state (overlays are poor documented at least). [...]  
> >
> > Until this thread I had never heard of them.  --
> > George  
> 
> I can't remember the last time I used overlays (certainly with CP/M);
> I didn't know that FreeBSD even supported them (why bother when
> you've got VM?).

I doubt that meaning of overlay is going to be relevant. I'd not heard
of it either, but from looking in ports/Mk/ it seems to be a way of
modifying port builds.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Chris]

On 2021-03-26 08:44, RW via freebsd-ports wrote:

On Fri, 26 Mar 2021 13:55:33 +1100 (EST)
Dave Horsfall wrote:


On Thu, 25 Mar 2021, George Mitchell wrote:

>> [...] it is really not for everybody to use overlays in current
>> state (overlays are poor documented at least). [...]
>
> Until this thread I had never heard of them.  --
> George

I can't remember the last time I used overlays (certainly with CP/M);
I didn't know that FreeBSD even supported them (why bother when
you've got VM?).


I doubt that meaning of overlay is going to be relevant. I'd not heard
of it either, but from looking in ports/Mk/ it seems to be a way of
modifying port builds.

As I understand it. It allows you to graft out-of-tree ports/versions
onto the ports-tree-proper.

--Chris

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Dan Mahoney (Ports)]

More thoughts on mailman, specifically:

So, I just went to find an old FB post I made about mailman 2.x:

===
From the "Load Bearing Bit" department:
Pretty much the entire world is stuck using an EOL'd mailing list manager 
(mailman 2.x), which depends on an EOL'd python (2.7).  
This includes:
* All the gnu mailing lists
* All of the linux mailing lists at listman.redhat
* all the FreeBSD mailing lists
* all the sourceforge mailing lists
* all the IETF mailing lists
* all of lists.isc.org
* NANOG
===

That’s an AWFUL LOT of sysadmins, network admins, and coders who looked long 
and hard at Mailman 3 and decided “that’s not ready yet”.

I think, if *nothing else*, tauthon needs to be stapled in for mailman, even if 
it lives under /usr/local/mailman/bin or something (and bakes in the couple of 
dependencies).

I know about the archive incompatibility.  There *might* be a GSOC project to 
fix it.  Maybe.  Other changes can happen with greater use, but clearly there’s 
a first-mover disadvantage here.

-Dan

> On Mar 26, 2021, at 9:06 AM, Chris  wrote:
> 
> On 2021-03-26 08:44, RW via freebsd-ports wrote:
>> On Fri, 26 Mar 2021 13:55:33 +1100 (EST)
>> Dave Horsfall wrote:
>>> On Thu, 25 Mar 2021, George Mitchell wrote:
>>> >> [...] it is really not for everybody to use overlays in current
>>> >> state (overlays are poor documented at least). [...]
>>> >
>>> > Until this thread I had never heard of them.  --
>>> > George
>>> I can't remember the last time I used overlays (certainly with CP/M);
>>> I didn't know that FreeBSD even supported them (why bother when
>>> you've got VM?).
>> I doubt that meaning of overlay is going to be relevant. I'd not heard
>> of it either, but from looking in ports/Mk/ it seems to be a way of
>> modifying port builds.
> As I understand it. It allows you to graft out-of-tree ports/versions
> onto the ports-tree-proper.
> 
> --Chris
>> ___
>> freebsd-ports@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Greg Rivers via freebsd-ports]

On Friday, 26 March 2021 14:19:20 CDT Dan Mahoney (Ports) wrote:
> More thoughts on mailman, specifically:
> 
> So, I just went to find an old FB post I made about mailman 2.x:
> 
> ===
> From the "Load Bearing Bit" department:
> Pretty much the entire world is stuck using an EOL'd mailing list manager 
> (mailman 2.x), which depends on an EOL'd python (2.7).  
> This includes:
> * All the gnu mailing lists
> * All of the linux mailing lists at listman.redhat
> * all the FreeBSD mailing lists
> * all the sourceforge mailing lists
> * all the IETF mailing lists
> * all of lists.isc.org
> * NANOG
> ===
> 
> That’s an AWFUL LOT of sysadmins, network admins, and coders who looked long 
> and hard at Mailman 3 and decided “that’s not ready yet”.
> 
> I think, if *nothing else*, tauthon needs to be stapled in for mailman, even 
> if it lives under /usr/local/mailman/bin or something (and bakes in the 
> couple of dependencies).
> 
> I know about the archive incompatibility.  There *might* be a GSOC project to 
> fix it.  Maybe.  Other changes can happen with greater use, but clearly 
> there’s a first-mover disadvantage here.
> 
I concur. The thought of losing Mailman 2.x fills me with dread.

-- 
Greg


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Bob Eager]

On Fri, 26 Mar 2021 09:06:08 -0700
Chris  wrote:

> > I doubt that meaning of overlay is going to be relevant. I'd not
> > heard of it either, but from looking in ports/Mk/ it seems to be a
> > way of modifying port builds.  
> As I understand it. It allows you to graft out-of-tree ports/versions
> onto the ports-tree-proper.

Ah, OK. I do that in a limited way. Local stuff that I have no interest
in submitting as a port. One new category, 'local'. Easily imported
into a new ports tree.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Bob Eager]

On Fri, 26 Mar 2021 14:55:15 -0500
Greg Rivers via freebsd-ports  wrote:

> On Friday, 26 March 2021 14:19:20 CDT Dan Mahoney (Ports) wrote:
> > More thoughts on mailman, specifically:
> > 
> > So, I just went to find an old FB post I made about mailman 2.x:
> > 
> > ===
> > From the "Load Bearing Bit" department:
> > Pretty much the entire world is stuck using an EOL'd mailing list
> > manager (mailman 2.x), which depends on an EOL'd python (2.7). This
> > includes:
> > * All the gnu mailing lists
> > * All of the linux mailing lists at listman.redhat
> > * all the FreeBSD mailing lists
> > * all the sourceforge mailing lists
> > * all the IETF mailing lists
> > * all of lists.isc.org
> > * NANOG
> > ===
> > 
> > That?s an AWFUL LOT of sysadmins, network admins, and coders who
> > looked long and hard at Mailman 3 and decided ?that?s not ready
> > yet?.
> > 
> > I think, if *nothing else*, tauthon needs to be stapled in for
> > mailman, even if it lives under /usr/local/mailman/bin or something
> > (and bakes in the couple of dependencies).
> > 
> > I know about the archive incompatibility.  There *might* be a GSOC
> > project to fix it.  Maybe.  Other changes can happen with greater
> > use, but clearly there?s a first-mover disadvantage here. 
> I concur. The thought of losing Mailman 2.x fills me with dread.
> 

Me too. Short term, I shall have it in a non-updated jail.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Chris]

On 2021-03-26 12:19, Dan Mahoney (Ports) wrote:

More thoughts on mailman, specifically:

So, I just went to find an old FB post I made about mailman 2.x:

===
From the "Load Bearing Bit" department:
Pretty much the entire world is stuck using an EOL'd mailing list manager 
(mailman

2.x), which depends on an EOL'd python (2.7).
This includes:
* All the gnu mailing lists
* All of the linux mailing lists at listman.redhat
* all the FreeBSD mailing lists
* all the sourceforge mailing lists
* all the IETF mailing lists
* all of lists.isc.org
* NANOG
===

That’s an AWFUL LOT of sysadmins, network admins, and coders who looked long 
and

hard at Mailman 3 and decided “that’s not ready yet”.

I think, if *nothing else*, tauthon needs to be stapled in for mailman, even 
if it

lives under /usr/local/mailman/bin or something (and bakes in the couple of
dependencies).
I *fully* concur. In fact, at least 2 ports that I maintain added a depends 
on
tauthon. Which really raised my ire hearing it's intended doom announcement. 
:(
Honestly. If something "just works", isn't a "security risk". Than don't fix 
it!


--Chris


I know about the archive incompatibility.  There *might* be a GSOC project 
to fix
it.  Maybe.  Other changes can happen with greater use, but clearly there’s 
a

first-mover disadvantage here.

-Dan


On Mar 26, 2021, at 9:06 AM, Chris  wrote:

On 2021-03-26 08:44, RW via freebsd-ports wrote:

On Fri, 26 Mar 2021 13:55:33 +1100 (EST)
Dave Horsfall wrote:

On Thu, 25 Mar 2021, George Mitchell wrote:
>> [...] it is really not for everybody to use overlays in current
>> state (overlays are poor documented at least). [...]
>
> Until this thread I had never heard of them.  --
> George
I can't remember the last time I used overlays (certainly with CP/M);
I didn't know that FreeBSD even supported them (why bother when
you've got VM?).

I doubt that meaning of overlay is going to be relevant. I'd not heard
of it either, but from looking in ports/Mk/ it seems to be a way of
modifying port builds.

As I understand it. It allows you to graft out-of-tree ports/versions
onto the ports-tree-proper.

--Chris

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Olivier Certner]

Le vendredi 26 mars 2021, 22:43:12 CET Chris a écrit :
> Honestly. If something "just works", isn't a "security risk". Than don't fix
> it!

Not so simple... But for build-only dependencies, I concur.

But anyway, all new security reports for 3.x will be fixed in Tauthon. I've 
now already reviewed 55 security bugs from PSF and fixed those appropriate 
(most are either not bugs, or irrelevant, or already fixed in 2.7 or Tauthon 
proper). I have ~20 more to review (and possibly fix), then I'll test the 
result and finally push all this upstream.
 
-- 
Olivier Certner


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Chris]

On 2021-03-26 15:18, Olivier Certner wrote:

Le vendredi 26 mars 2021, 22:43:12 CET Chris a écrit :
Honestly. If something "just works", isn't a "security risk". Than don't 
fix

it!


Not so simple... But for build-only dependencies, I concur.

But anyway, all new security reports for 3.x will be fixed in Tauthon. I've
now already reviewed 55 security bugs from PSF and fixed those appropriate
(most are either not bugs, or irrelevant, or already fixed in 2.7 or Tauthon
proper). I have ~20 more to review (and possibly fix), then I'll test the
result and finally push all this upstream.

Thank you, Olivier. I *really* appreciate all the work you've put into this.

--Chris
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Anatoly]

On Thu, 25 Mar 2021 23:06:27 -0700
Chris  wrote:

> On 2021-03-25 22:24, Kurt Jaeger wrote:

> > The portmgr@ role is a huge task and all the reasons (limited time,
> > dayjobs, etc) ares  valid for those folks from portmgr as for
> > the rest of the ports maintainers and committers.  
> Indeed, and don't think that hadn't occurred to me. In fact I
> suspected that portmgr@ was feeling a bit overwhelmed, and that
> *that* triggered the seemingly overreaching python announcement.
> May I humbly request a petition for such large-sweeping changes? IMHO
> this will give portmgr@ the opportunity to get caught up, and perhaps
> get some assistance -- maybe we all come up with an idea that saves
> _everyones_ bacon. :-)
 
I already miss tools depending on gtk1.2, qt3, qt4 in ports.
Maybe it makes sense to introduce new "flag"
NOAUTOBUILD=
To mark the ports from which no packages should be build
quarterly automatically to reduce portmgr@ load, instead of just
dropping those ports out of ports tree? And leave all the care of those
ports to their maintainers, requiring them some kind of "pings" to
detect if maintainer is "alive" as the only criteria to keep port in
the tree? 

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Guido Falsi via freebsd-ports]

On 27/03/21 10:44, Anatoly wrote:

On Thu, 25 Mar 2021 23:06:27 -0700
Chris  wrote:


On 2021-03-25 22:24, Kurt Jaeger wrote:



The portmgr@ role is a huge task and all the reasons (limited time,
dayjobs, etc) ares  valid for those folks from portmgr as for
the rest of the ports maintainers and committers.

Indeed, and don't think that hadn't occurred to me. In fact I
suspected that portmgr@ was feeling a bit overwhelmed, and that
*that* triggered the seemingly overreaching python announcement.
May I humbly request a petition for such large-sweeping changes? IMHO
this will give portmgr@ the opportunity to get caught up, and perhaps
get some assistance -- maybe we all come up with an idea that saves
_everyones_ bacon. :-)
  
I already miss tools depending on gtk1.2, qt3, qt4 in ports.

Maybe it makes sense to introduce new "flag"
NOAUTOBUILD=
To mark the ports from which no packages should be build
quarterly automatically to reduce portmgr@ load, instead of just
dropping those ports out of ports tree? And leave all the care of those
ports to their maintainers, requiring them some kind of "pings" to
detect if maintainer is "alive" as the only criteria to keep port in
the tree?



If I understand what you propose  you also mean that updates to the 
ports tree infrastructure and to ports not marked "NOAUTOBUILD" don't 
need to care if the NOAUTOBUILD ports get broken in the process.


If that is so, you can already do this.

Just create a repo on github with a port overlay, or fork the ports tree 
git repo (just wait a few days for the migration of the official ports 
tree to git) and you can add all the ports for old software you need and 
maintain them, or find other people to help you doing it. If you find 
the resources you can also provide CI and binary packages for them.


There iss no need for the project's or portmgr involvement.



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"




--
Guido Falsi 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 removal outline

[Guido Falsi via freebsd-ports]

On 27/03/21 12:42, Guido Falsi via freebsd-ports wrote:

On 27/03/21 10:44, Anatoly wrote:

On Thu, 25 Mar 2021 23:06:27 -0700
Chris  wrote:


On 2021-03-25 22:24, Kurt Jaeger wrote:



The portmgr@ role is a huge task and all the reasons (limited time,
dayjobs, etc) ares  valid for those folks from portmgr as for
the rest of the ports maintainers and committers.

Indeed, and don't think that hadn't occurred to me. In fact I
suspected that portmgr@ was feeling a bit overwhelmed, and that
*that* triggered the seemingly overreaching python announcement.
May I humbly request a petition for such large-sweeping changes? IMHO
this will give portmgr@ the opportunity to get caught up, and perhaps
get some assistance -- maybe we all come up with an idea that saves
_everyones_ bacon. :-)

I already miss tools depending on gtk1.2, qt3, qt4 in ports.
Maybe it makes sense to introduce new "flag"
NOAUTOBUILD=    
To mark the ports from which no packages should be build
quarterly automatically to reduce portmgr@ load, instead of just
dropping those ports out of ports tree? And leave all the care of those
ports to their maintainers, requiring them some kind of "pings" to
detect if maintainer is "alive" as the only criteria to keep port in
the tree?



If I understand what you propose  you also mean that updates to the 
ports tree infrastructure and to ports not marked "NOAUTOBUILD" don't 
need to care if the NOAUTOBUILD ports get broken in the process.


If that is so, you can already do this.

Just create a repo on github with a port overlay, or fork the ports tree 
git repo (just wait a few days for the migration of the official ports 
tree to git) and you can add all the ports for old software you need and 
maintain them, or find other people to help you doing it. If you find 
the resources you can also provide CI and binary packages for them.


There iss no need for the project's or portmgr involvement.


OTOH, if you expect all committers to put additional work on the 
infrastructure or their ports to make sure they don't break obsolete and 
EOL software, that is not a viable option.


--
Guido Falsi 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"