From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id gXwAIbjJFGnpazoAWB0awg (envelope-from ) for ; Wed, 12 Nov 2025 12:54:00 -0500 Received: by simark.ca (Postfix, from userid 112) id 849551E0B8; Wed, 12 Nov 2025 12:54:00 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2BD341E04C for ; Wed, 12 Nov 2025 12:54:00 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9C2BC385840D for ; Wed, 12 Nov 2025 17:53:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9C2BC385840D Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id A75713858D29 for ; Wed, 12 Nov 2025 17:53:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A75713858D29 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A75713858D29 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1762970000; cv=none; b=ZZtgVt4VIdmAWGGdFOEwzHiOfxT78Fr/BKQCqoHg2zCfveJSqzwF0JoPiooOF5Ky2lZ5o6ApBLqvvz3ursbj1DEeFPK2mnKI+Rw5bUpB0SxBPP+No9KDBdvbNuHHKIjW/P95XWxYfVONaqawTqp/jpFbdTkcVv2bo11bDC6E9+4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1762970000; c=relaxed/simple; bh=XcY4syoUpJjJFZcNQT34zNBZVRJ3o7qQqr4j+euqWHI=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=rzLoBz5m4cx2mZePerBjtXvKIMbUy0TnNGaoOt9WZInsklVyVspeqKr0mAY2apF0GmUgsHmjQHmuzrwWVQzMJFn0VvuVnHlYQuQ+g8onXY490p9PCk1lCIasHqokIodYMDKFQ1K3eeSbdJIk42K5lZsCwItfyc7hI2K+aYcmWxo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A75713858D29 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6F5821515; Wed, 12 Nov 2025 09:53:12 -0800 (PST) Received: from [10.2.79.28] (unknown [10.2.79.28]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3ACE33F63F; Wed, 12 Nov 2025 09:53:19 -0800 (PST) Message-ID: Date: Wed, 12 Nov 2025 17:53:17 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] [gdb/python] Use PyConfig for python 3.9 To: Eli Zaretskii Cc: simark@simark.ca, tom@tromey.com, tdevries@suse.de, gdb-patches@sourceware.org References: <20251017133624.2460264-1-tdevries@suse.de> <87h5vxr4zp.fsf@tromey.com> <86jz0tftrk.fsf@gnu.org> <87qzv1pjy8.fsf@tromey.com> <86ikgdfkd2.fsf@gnu.org> <87zf97c4yw.fsf@tromey.com> <86v7jujkyh.fsf@gnu.org> <865xbrgeo2.fsf@gnu.org> <18cba048-250a-47a9-a056-8a4e255b7fa5@arm.com> <86seejrwpg.fsf@gnu.org> Content-Language: en-GB From: "Richard Earnshaw (foss)" In-Reply-To: <86seejrwpg.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 12/11/2025 17:23, Eli Zaretskii wrote: >> Date: Wed, 12 Nov 2025 16:52:13 +0000 >> Cc: tom@tromey.com, tdevries@suse.de, gdb-patches@sourceware.org >> From: "Richard Earnshaw (foss)" >> >>> Btw, the problem is not the system where GDB is compiled, the problem >>> is the system on which it runs. >> >> So how long are we expected to support such an antiquated system? > > I think that depends on what is required to "support" them. That's > what we should talk about, and in practical terms. E.g., if all > that's required is not to delete compatibility code (and I'm not > saying that's all, I'm just giving an example), it is my opinion that > the effort is negligible. > >> It's already 11 years beyond it's final maintenance update and continuing to pretend we can support it is clearly holding up development of gdb. > > But does it hold development? If it does, let's identify where it > does and talk about that, and maybe we will then decide that the > effort is too much. > Well if it hinders developments like: - switching to the python limited API - removing the need to test against multiple python run-times - removing the need for users to install a specific version of python rather than reuse the version they already have installed then yes it does. >> If the runtime can't support critical improvements of gdb, then surely it's time to reconsider our priorities. > > Yes, "if". The issue, once again, is whether this "if" indeed > materializes. That's what I suggest to discuss.