Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere
Resent. Not yet sent from ML but later one was sent.
Adding @freebsd.org address of Enji, as gmail does not accept mails
from dec.sakura.ne.jp, which has neither DKIM functionality nor SPF
record.
On Thu, 10 Aug 2023 16:32:32 -0700
Enji Cooper wrote:
> > On Aug 10, 2023, at 4:00 PM, Tomoaki AOKI wrote:
> >
> > On Thu, 10 Aug 2023 18:09:54 -0400
> > Charlie Li wrote:
> >
> >> Enji Cooper wrote:
> >>> Hmm… All lang/python27 requiring ports should be marked BROKEN and
> >>> removed — upstream stopped supporting 2.7 3.5 years ago (04/01/2020) :/.
> >> We can't entirely do that yet. Unfortunately, moinmoin, original mailman
> >> and the CSM for UEFI-EDK2 (used in bhyve) still staunchly require this.
> >> It was the case that Chrom{e,ium} and qt-webengine still had Python 2
> >> build bits but they've since migrated off.
> >>
> >> --
> >> Charlie Li
> >> …nope, still don't have an exit line.
> >
> > Can lang/tauthon used instead of lang/python27?
> > It's a fork of python27 and maintained (slowly) like [1].
>
> Lang/tauthon probably could be used instead.
Even if original upstream is abandoned, maintained fork would better be
allowed. If tauthon can be considered "well maintained", consumers of
python27 which is enough compatible with tauthon can switch to tauthon
and un-deprecated.
> > I don't use python nor tauthon directly, though.
> > I dislike languages killing backward compatibility... :-(
> >
> > I love C as even recent llvm/clang has an ability to compile K
> > codes, if proper options are set. This is how ALL computer languages
> > SHALL BE.
>
> The problem that python2 -> python3 was trying to solve was multifold: there
> were a variety of issues with the language, as defined in python2, which made
> the syntax changes going from 2 to 3 necessary.
>
> That being said, the whole “python2 is going away in 2020” was advertised
> well in advance (several years). If projects hadn’t done the work of getting
> off python2 by 2020, it’s their fault in not prioritizing that effort.
>
> The problem with packages like MoinMoin, etc, is that unless they’re
> completely isolated (vendor and provide all of their dependencies), they are
> likely developing pieces of software on vulnerable versions of third-party
> packages since many packages started yanking python2 support in the past
> couple years. Yanking python2 support allows third-party projects to be
> developed with more modern syntax niceties like the walrus operator, type
> hints, asyncio, etc. It’s not logical for pieces of software to not improve.
>
> Python is not C or Perl; the transition from 2 to 3 was particularly painful,
> but the changes were based on development that was over a decade in the
> making.
If I'm the project owner of python, I would have been decided to
abandon python and switch to different name because of backward
incompatibility. But unfortunately, they didn't do so.
If the software itself runs on python, I think you're completely right.
It should be rewritten.
But for softwares which uses python only on build time, staying on
python27 should be allowed.
In small projects, if the person who built the building environment
retired from the project and noone else can understand / maintain the
build system, the only selection is "stay there until someone who can
construct new build environment pops in". This could happen here and
there, unfortunately.
For example,
*Consider python27 and required py-* as bootstrapping tool.
*Build python27 and required py-* everytime the port is built
and cleanup afterwards, INSIDE PORTS WORKDIR.
*python27 and required py-* are listed in distinfo of each port which
requires python27 on build time only.
would allow lang/python27 to be deleted, if possible.
>
> Cheers,
> -Enji
--
Tomoaki AOKI
Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere
On Thu, 10 Aug 2023 18:09:54 -0400
Charlie Li wrote:
> Enji Cooper wrote:
> > Hmm… All lang/python27 requiring ports should be marked BROKEN and
> > removed — upstream stopped supporting 2.7 3.5 years ago (04/01/2020) :/.
> We can't entirely do that yet. Unfortunately, moinmoin, original mailman
> and the CSM for UEFI-EDK2 (used in bhyve) still staunchly require this.
> It was the case that Chrom{e,ium} and qt-webengine still had Python 2
> build bits but they've since migrated off.
>
> --
> Charlie Li
> …nope, still don't have an exit line.
Can lang/tauthon used instead of lang/python27?
It's a fork of python27 and maintained (slowly) like [1].
I don't use python nor tauthon directly, though.
I dislike languages killing backward compatibility... :-(
I love C as even recent llvm/clang has an ability to compile K
codes, if proper options are set. This is how ALL computer languages
SHALL BE.
[1]
https://github.com/naftaliharris/tauthon/commit/52473e14e93366e02cf0b63b4c7fd952420e5ee3
--
Tomoaki AOKI
Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere
Enji Cooper wrote:
Hmm… All lang/python27 requiring ports should be marked BROKEN and
removed — upstream stopped supporting 2.7 3.5 years ago (04/01/2020) :/.
We can't entirely do that yet. Unfortunately, moinmoin, original mailman
and the CSM for UEFI-EDK2 (used in bhyve) still staunchly require this.
It was the case that Chrom{e,ium} and qt-webengine still had Python 2
build bits but they've since migrated off.
--
Charlie Li
…nope, still don't have an exit line.
OpenPGP_signature
Description: OpenPGP digital signature
Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere
> On Aug 10, 2023, at 2:56 PM, Matthias Apitz wrote: … > Don't know if I can answer your questions. I'm building ports with > poudriere and lang/python27 is pulled in from some other ports. The port > lang/python27 itself is not on my list for poudriere: > > # grep python /usr/local/etc/poudriere-list > databases/postgresql13-plpython > lang/python3 Hmm… All lang/python27 requiring ports should be marked BROKEN and removed — upstream stopped supporting 2.7 3.5 years ago (04/01/2020) :/. Cheers, -Enji signature.asc Description: Message signed with OpenPGP
Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere
El día jueves, agosto 10, 2023 a las 01:46:56p. m. -0700, Enji Cooper escribió: > > > On Aug 10, 2023, at 2:38 AM, Matthias Apitz wrote: > > > > El día Wednesday, August 09, 2023 a las 06:04:16PM +0200, Moin Rahman > > escribió: > > > >> This perfectly builds on the latest HEAD without any problem as shared in > >> my build log. I am not sure what is wrong at your end. Neither can I see > >> any fallout on the clusters. > > > > I've cc'ed freebsd-current@ > > > > I did two times the building of lang/python27 within poudriere on > > 14.0-CURRENT: > > > > =>> Building lang/python27 > > build started at Tue Aug 8 04:05:20 CEST 2023 > > port directory: /usr/ports/lang/python27=>> Building lang/python27 > > > > =>> Building lang/python27 > > build started at Thu Aug 10 06:33:53 CEST 2023 > > port directory: /usr/ports/lang/python27 > > > > The first failed, the one of today went fine. The main difference in the > > building log is: > > > > failing job: > > --MAKE_ENV-- > > OPENSSLBASE=/usr/local OPENSSLDIR=/usr/local/openssl > > OPENSSLINC=/usr/local/include OPENSSLLIB=/usr/local/lib > > OPENSSLRPATH=/usr/local/lib > > > > fine job: > > --MAKE_ENV-- > > OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include > > OPENSSLLIB=/usr/lib > > ... > > > > I didn't changed anything in the poudriere config or port's options. The > > only thing I did between was yesterday evening a 'git pull' in > > /usr/ports. > > > > What could have triggered this change of the used SSL version? > > 1. lang/python27 is no longer supported upstream. > 2. lang/python27’s modules and compatible third-party packages won’t work > with OpenSSL 3; they depend on OpenSSL 1.x specific symbols/APIs. > > If you want to make lang/python27 work with OpenSSL 3, you’re going to port > the modules to OpenSSL 3 > > My question is: why are you doing this, given that it’s no longer receiving > upstream updates (functional or security)? Don't know if I can answer your questions. I'm building ports with poudriere and lang/python27 is pulled in from some other ports. The port lang/python27 itself is not on my list for poudriere: # grep python /usr/local/etc/poudriere-list databases/postgresql13-plpython lang/python3 matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere
> On Aug 10, 2023, at 2:38 AM, Matthias Apitz wrote: > > El día Wednesday, August 09, 2023 a las 06:04:16PM +0200, Moin Rahman > escribió: > >> This perfectly builds on the latest HEAD without any problem as shared in my >> build log. I am not sure what is wrong at your end. Neither can I see any >> fallout on the clusters. > > I've cc'ed freebsd-current@ > > I did two times the building of lang/python27 within poudriere on > 14.0-CURRENT: > > =>> Building lang/python27 > build started at Tue Aug 8 04:05:20 CEST 2023 > port directory: /usr/ports/lang/python27=>> Building lang/python27 > > =>> Building lang/python27 > build started at Thu Aug 10 06:33:53 CEST 2023 > port directory: /usr/ports/lang/python27 > > The first failed, the one of today went fine. The main difference in the > building log is: > > failing job: > --MAKE_ENV-- > OPENSSLBASE=/usr/local OPENSSLDIR=/usr/local/openssl > OPENSSLINC=/usr/local/include OPENSSLLIB=/usr/local/lib > OPENSSLRPATH=/usr/local/lib > > fine job: > --MAKE_ENV-- > OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include > OPENSSLLIB=/usr/lib > ... > > I didn't changed anything in the poudriere config or port's options. The > only thing I did between was yesterday evening a 'git pull' in > /usr/ports. > > What could have triggered this change of the used SSL version? 1. lang/python27 is no longer supported upstream. 2. lang/python27’s modules and compatible third-party packages won’t work with OpenSSL 3; they depend on OpenSSL 1.x specific symbols/APIs. If you want to make lang/python27 work with OpenSSL 3, you’re going to port the modules to OpenSSL 3 My question is: why are you doing this, given that it’s no longer receiving upstream updates (functional or security)? Cheers, -Enji PS IIRC, there were lang/python27 forks out there that might be used as inspiration for the OpenSSL 3 uplift, but again… I don’t understand why effort is being spent making the two (Python 2 and OpenSSL 3) work. signature.asc Description: Message signed with OpenPGP
Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere
El día jueves, agosto 10, 2023 a las 09:50:31 +, Alastair Hogge escribió: > On 2023-08-10 17:38, Matthias Apitz wrote: > > El día Wednesday, August 09, 2023 a las 06:04:16PM +0200, Moin Rahman > > escribió: > > > >> This perfectly builds on the latest HEAD without any problem as shared in > >> my build log. I am not sure what is wrong at your end. Neither can I see > >> any fallout on the clusters. > >> > > > > I've cc'ed freebsd-current@ > > > > I did two times the building of lang/python27 within poudriere on > > 14.0-CURRENT: > > > > =>> Building lang/python27 > > build started at Tue Aug 8 04:05:20 CEST 2023 > > port directory: /usr/ports/lang/python27=>> Building lang/python27 > > > > =>> Building lang/python27 > > build started at Thu Aug 10 06:33:53 CEST 2023 > > port directory: /usr/ports/lang/python27 > > > > The first failed, the one of today went fine. The main difference in the > > building log is: > > > > failing job: > > --MAKE_ENV-- > > OPENSSLBASE=/usr/local OPENSSLDIR=/usr/local/openssl > > OPENSSLINC=/usr/local/include OPENSSLLIB=/usr/local/lib > > OPENSSLRPATH=/usr/local/lib > > > > fine job: > > --MAKE_ENV-- > > OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include > > OPENSSLLIB=/usr/lib > > ... > > > > I didn't changed anything in the poudriere config or port's options. The > > only thing I did between was yesterday evening a 'git pull' in > > /usr/ports. > > > > What could have triggered this change of the used SSL version? > > Do you have the error from the failed build? I have the following patch > in my tree to get Python-2.7 to build, tho I have not tested recently if > it is still required: The log of the failing job is here: http://www.unixarea.de/python27-2.7.18_2.log It has exactly the issue which your patch addresses: with OpenSSL from ports it can't build the shared object _hashlib.so. I can live with this for now (as the package was built now). But I wanted to understand, why and what was the change between August 8 and 10. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere
On 2023-08-10 17:38, Matthias Apitz wrote: > El día Wednesday, August 09, 2023 a las 06:04:16PM +0200, Moin Rahman > escribió: > >> This perfectly builds on the latest HEAD without any problem as shared in my >> build log. I am not sure what is wrong at your end. Neither can I see any >> fallout on the clusters. >> > > I've cc'ed freebsd-current@ > > I did two times the building of lang/python27 within poudriere on > 14.0-CURRENT: > > =>> Building lang/python27 > build started at Tue Aug 8 04:05:20 CEST 2023 > port directory: /usr/ports/lang/python27=>> Building lang/python27 > > =>> Building lang/python27 > build started at Thu Aug 10 06:33:53 CEST 2023 > port directory: /usr/ports/lang/python27 > > The first failed, the one of today went fine. The main difference in the > building log is: > > failing job: > --MAKE_ENV-- > OPENSSLBASE=/usr/local OPENSSLDIR=/usr/local/openssl > OPENSSLINC=/usr/local/include OPENSSLLIB=/usr/local/lib > OPENSSLRPATH=/usr/local/lib > > fine job: > --MAKE_ENV-- > OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include > OPENSSLLIB=/usr/lib > ... > > I didn't changed anything in the poudriere config or port's options. The > only thing I did between was yesterday evening a 'git pull' in > /usr/ports. > > What could have triggered this change of the used SSL version? Do you have the error from the failed build? I have the following patch in my tree to get Python-2.7 to build, tho I have not tested recently if it is still required: diff --git a/lang/python27/pkg-plist b/lang/python27/pkg-plist index 4d8dc5b06c81..a92192e6c9d6 100644 --- a/lang/python27/pkg-plist +++ b/lang/python27/pkg-plist @@ -1908,7 +1908,6 @@ lib/python2.7/lib-dynload/_curses.so lib/python2.7/lib-dynload/_curses_panel.so lib/python2.7/lib-dynload/_elementtree.so lib/python2.7/lib-dynload/_functools.so -lib/python2.7/lib-dynload/_hashlib.so lib/python2.7/lib-dynload/_heapq.so lib/python2.7/lib-dynload/_hotshot.so lib/python2.7/lib-dynload/_io.so There was some heavy OpenSSL work recently, and it maybe possible there is some fallout still from that? -- To health and anarchy, Alastair
Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere
El día Wednesday, August 09, 2023 a las 06:04:16PM +0200, Moin Rahman escribió: > This perfectly builds on the latest HEAD without any problem as shared in my > build log. I am not sure what is wrong at your end. Neither can I see any > fallout on the clusters. > I've cc'ed freebsd-current@ I did two times the building of lang/python27 within poudriere on 14.0-CURRENT: =>> Building lang/python27 build started at Tue Aug 8 04:05:20 CEST 2023 port directory: /usr/ports/lang/python27=>> Building lang/python27 =>> Building lang/python27 build started at Thu Aug 10 06:33:53 CEST 2023 port directory: /usr/ports/lang/python27 The first failed, the one of today went fine. The main difference in the building log is: failing job: --MAKE_ENV-- OPENSSLBASE=/usr/local OPENSSLDIR=/usr/local/openssl OPENSSLINC=/usr/local/include OPENSSLLIB=/usr/local/lib OPENSSLRPATH=/usr/local/lib fine job: --MAKE_ENV-- OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include OPENSSLLIB=/usr/lib ... I didn't changed anything in the poudriere config or port's options. The only thing I did between was yesterday evening a 'git pull' in /usr/ports. What could have triggered this change of the used SSL version? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
