From nobody Sat Nov 01 23:22:41 2025 X-Original-To: python@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 4czYmL3ZQXz6FQsQ for ; Sat, 01 Nov 2025 23:22:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4czYmL2kZkz3xMH for ; Sat, 01 Nov 2025 23:22:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762039362; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gWcihRHd0wr/zgtexvxsvgRwVcFsmSDNN7FLQYvIip8=; b=H3Eb2aEyMskFAM5RtqXRmTNJhoeNeCvUF59xnIupjTgBP9KQGQHSRUxqK72w+6oYvU8FE9 uv6vcw714AP5RVdSr5s9RI20XLxbGm7vSj14cQds738TCEQL4Bz1ZTBElS6fl2CENf0hGh /SyRglpI67Us79lVABVppMWGEs796LKXqXSkiQFARTDSATdjFaK9aW2nUbS8McTOEpm08D d6wMjHw4BJp+8IYXv/Dr8Ac7TlXx2bn0MrsUI+cqE3RH9A94mzYTpNTZQyj5t1vmWVSzd7 dUjTIhgQupSwQlMbiNXh18+H5/p6DEhW570GAo6Lb0NGfaoJ7MUJfXiGd21DMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762039362; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gWcihRHd0wr/zgtexvxsvgRwVcFsmSDNN7FLQYvIip8=; b=JxDyGcYOXk4pcnt5ARaKV15IfrYQ7Ip1NHcWIDnVs1/aLPZljySxVeH2uPRdGbHQnlFQh3 Gf0ABcrgni18O2Qr/UMZtLBVPTZznubUiFDiy+m/sw5pWZP48A1HaBk7CQU2L3Dj4bPpSz agkBq46KxGDNoHLoCKjLCoSQlKOXfWg2WoigQIlBj0d+uHs8QtYE9Q8lSX8rMXIW+CBUa6 msh4Mha5T1PWZ1ga6gYjPlB/nh9SI7xkWMbSf4xHx+fMs0Z53GFFpOTBTekUmCuFkvXD+N 0ViLsQBBMSTm7lPWcO+JlpK1lXhFZbYbcoGojc4ogE9m1ClUcQiRy96nK++uhg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762039362; a=rsa-sha256; cv=none; b=MgVltHyaGRe+uNBA3p/2ZKXk+zxtINeVxyrRN+bCs066p6FNC1bxXt/JjO7EJwoyqa6xga PXSWUo+a/NFEroFKxX6FLxDSjTjWIwNJ3e5Y2+qWSkiEh4uIteGe3psF5YJTjFCXppKhOj Yuyg6zGjYH2D103nxrDGodEoV6dUSSyALB2yXQTRCYz3e4nzsNYThol0DPasG57ANLxvzv 2wp3T8rsXEvaJr+R47mHuD5PnZ8xi6gLcFh9i+gXqfohoEgzY4LpSMmAuPhpOe94eHB3ju n4eWuhPpfzAQERmiwFRzstmPClIQFUt8E0hk4dT0lEoWxv/EJhTISWmRb2CHAw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4czYmL2Bgfz10qZ for ; Sat, 01 Nov 2025 23:22:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 5A1NMgXa009983 for ; Sat, 1 Nov 2025 23:22:42 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 5A1NMgoq009982 for python@FreeBSD.org; Sat, 1 Nov 2025 23:22:42 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: python@FreeBSD.org Subject: [Bug 274671] lang/python313: New port, 3.13.9 release Date: Sat, 01 Nov 2025 23:22:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: vishwin@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: python@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: FreeBSD-specific Python issues List-Archive: https://lists.freebsd.org/archives/freebsd-python List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-python@freebsd.org Sender: owner-freebsd-python@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D274671 Charlie Li changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed Resolution|--- |FIXED --- Comment #43 from Charlie Li --- The last issue that prevented this from landing dealt with ensuring that the correct variant of this Python version built and packaged properly. Most notably, the `python` or `python3` value of ${DEFAULT_VERSIONS} should not = have affected whether the resulting PKGNAME would be correct or staging and packaging would behave itself. Earlier during this cycle I committed support into the framework to allow f= or Python versions that are not fully numeric, ie 3.13t. Previously the framew= ork assumed that versions are only numeric and thus numeric comparison operators worked and made sense. Once it became clear that free-threaded mode required its own FLAVOR and thus a separate port, adjustments to the version compari= son and flavour generation logic had to happen. So since then, theoretically the py313 and py313t separate flavours have been possible. The showstopper from having the lang/ ports committed at that same time ste= mmed from this new support but in a different way. If lang/python313t is to be b= uilt and DEFAULT_VERSIONS+=3Dpython=3D3.13t and DEFAULT_VERSIONS+=3Dpython3=3D3.= 13t, the version comparison logic doesn't fire and thus ${PYTHON_VER} et al are corr= ect at 3.13t. The trouble lies when ${DEFAULT_VERSIONS} and the desired lang/py= thon port versions differ: the version comparison logic intended for *consumers*, especially the flavoured ports, comes into play, which means the `t` is immediately stripped so that the comparisons happen on fully-numeric values. This path makes sense for consumers since they need to determine whether or= not a particular version or range is supported (3.13 and 3.13t for numerical comparison and compatibility purposes are the same version). Unfortunately there is not really a way to put the `t` back into ${PYTHON_VER} once this finishes without there being a flavour defined, so building say lang/python= 313t in this case would result in PYTHON_VER=3D3.13 instead of 3.13t. This ends = up messing with the resulting ${PKGNAME}, ${SUB_FILES} and the plist which ultimately results in failed staging or packaging. Mitigating around this was incredibly frustrating and is why it took so lon= g. Not proud of how long this took at all. Also not proud of how the explanati= on had to come after everything worked (and thus committed) because of the amo= unt of moving parts in make(1) variables, which also made it nearly impossible = to accept any offers of help. But now we have support for the free-threaded mode starting here at 3.13. 3= .14 has developed this support further and hopefully the prematurely-committed = port will catch up soon. The generally incremental nature of CPython is why this needed to be committed first; the port development cycles also follow this pattern of starting from the previous version in a new copy. --=20 You are receiving this mail because: You are the assignee for the bug.=