Created attachment 183299 [details] Do not insist on python-2, when building devel/gdb There is no apparent need to insist on Python-2.x in lang/gdb any more... It certainly builds just fine now -- just tested with Python-3.6.1 (may work with 3.5 too?). There is a comment inside Python's Tools/gdb/libpython.py: # NOTE: some gdbs are linked with Python 3, so this file should be dual-syntax # compatible (2.6+ and 3.0+). See #19308. So we would not be the first ones doing it :-)
Hi Mikhail, thanks for nothing this. I'll do some tests with python3
Pending further maintainer feedback as per comment 2 @Mikhail #19308 doesn't appear to be a valid issue reference, please clarify which issue was intended (by adding it to See Also: field)
(In reply to Kubilay Kocak from comment #2) > @Mikhail #19308 doesn't appear to be a valid issue reference That was a verbatim comment from inside Python's Tools/gdb/libpython.py. I believe, the author was referring to the Python bug: https://bugs.python.org/issue19308 I don't know, if it needs to be referenced by this ticket formally, but, if it does, please, put it into the right field.
I've asked to merge this patch in the phabricator review, here: https://reviews.freebsd.org/D11465 This PR can be now closed.
Reviews don't obsolete issues, issues referencing reviews are closed when the change is committed. If the changes in the review are not the same as those referenced in the issue, please obsolete the attachment. Having said that, I would recommend relaxing the python version be committed separately and BEFORE the gdb updates, so that the commit can be merged to the quarterlly branch. Assign to committer proposing differential revision
I don't mind committing this specific change first before the 8.0 update. However, I'm not a ports committer so I'd need a ports committer to approve it. Also, I don't know if this needs a port revision bump? I believe that the default python is still 2.7, so I don't think this will change any default package builds, so a revision bump is not warranted?
(In reply to John Baldwin from comment #6) Thank you, that would be great John. I can provide the ports/python approval. Note that the change also needs to be MFH'd to quarterly. I can assist/guide there if needed. This issue is still pending necessary QA as per comment 1, anticipating: - Confirmation of successful packaging (poudriere/testport) runs for devel/gdb with Python 3.6, 3.5 at least - From a Python perspective it would be good to see/confirm run-time (debugging) function with at least Python 3.5, 3.6
I did builds (and testport) on 11-stable of gdb with DEFAULT_VERSIONS=python=3.5 and 3.6 and both built fine. I also installed the gdb packages and simple python tests ('python \ print "foo" \ end' on the existing gdb with python2 and 'python \ print("foo") \ end' on the two gdb's built with 3.5 and 3.6) all worked ok. Does this need any further review or is this ready for commit now?
(In reply to John Baldwin from comment #8) I've also built it on 11.0 and 10.3, on i386 and amd64, with python 3.5 and 3.6. I've also ran some easy tests and it looks like problem free. I approve the commit.
I am curious if this really warrants an MFH though since the default python version for packages is python 2, so this change only affects packages built with a non-default make.conf. Is it expected that users are regularly doing their own poudriere builds against quarterly branches or is the primary target pkg.freebsd.org packages for which this change is a no-op?
(In reply to John Baldwin from comment #10) Anything that isn't a feature change/addition should be merged, even if only to make future merges easier. This includes (but is not limited to) port fixes/improvements in addition to upstream software bug fixes. In this case, the context of the change is an incorrect (artificial) limitation on gdb being built with only 2.x versions of Python, limiting users, and is effectively a bug fix.
Hmm, that seems odd, but ok. In src we use a whitelist to only merge things that are needed, not a blacklist of only not merging major changes. Also, since the next change to this port is a major version bump (which is more major than most since it switches to C++11, etc.) it seems very unlikely that any future bugfix would be directly mergeable from the port to the quarterly branch anyway.
A commit references this bug: Author: jhb Date: Mon Jul 10 16:58:12 UTC 2017 New revision: 445441 URL: https://svnweb.freebsd.org/changeset/ports/445441 Log: Permit building GDB with python 3. The python support in GDB works with either python 2 or python 3. There is no reason to restrict it to python 2 only. PR: 219844 Submitted by: mi Approved by: luca.pizzamiglio@gmail.com (maintainer) MFH: 2017Q3 Changes: head/devel/gdb/Makefile
A commit references this bug: Author: jhb Date: Tue Jul 11 17:25:42 UTC 2017 New revision: 445538 URL: https://svnweb.freebsd.org/changeset/ports/445538 Log: MFH: r445441 Permit building GDB with python 3. The python support in GDB works with either python 2 or python 3. There is no reason to restrict it to python 2 only. PR: 219844 Approved by: ports-secteam (junovitch) Changes: _U branches/2017Q3/ branches/2017Q3/devel/gdb/Makefile