From nobody Fri Aug 11 23:48:09 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RN0q52KKQz4pwJS for ; Fri, 11 Aug 2023 23:48:17 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RN0q362vnz4KRF; Fri, 11 Aug 2023 23:48:14 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 37BNm9pY029666; Sat, 12 Aug 2023 08:48:09 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 12 Aug 2023 08:48:09 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: ngie@FreeBSD.org Subject: Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere Message-Id: <20230812084809.26011cdb98127269cf3714d7@dec.sakura.ne.jp> In-Reply-To: References: <414B922C-C553-41D4-B519-E3B3B239B606@freebsd.org> <9A29A1BA-F957-40D9-96C6-062471BA14AF@freebsd.org> <5E811C16-5D72-44EC-A14B-06BB9FADB793@gmail.com> <2D0B1311-6E7C-4A34-970F-2BA9BFB9C34F@gmail.com> <6222a6d8-5940-fd27-af8f-222ee9fdcdb4@freebsd.org> <20230811080045.ce1eab46a48b3c86a0d4bf78@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.2) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [1.56 / 15.00]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_HAM_SHORT(-0.97)[-0.967]; MV_CASE(0.50)[]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_LONG(0.03)[0.029]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; HAS_ORG_HEADER(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: + X-Rspamd-Queue-Id: 4RN0q362vnz4KRF 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&R > > 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