In D4170#88391, @koobs wrote:

Other than PYTHON_SUFFIX=${PORTVERSION:R:S/.g}// (isn't PYTHON_SUFFIX already defined/available via python.mk) the changes look good

• Replace DISTVERSION with PORTVERSION for lang/python35

Other than PYTHON_SUFFIX=${PORTVERSION:R:S/.g}// (isn't PYTHON_SUFFIX already defined/available via python.mk) the changes look good

In D4170#88389, @lwhsu wrote:

BTW, why does lang/python35 use DISTVERSION instead of PORTVERSION?

In D4170#88374, @koobs wrote:

• I'd remove "for " from COMMENT

• I'd remove "for " from COMMENT
• Replace hard coded pyxy in pkg-message with SUB_FILES (make future repocopies safer, reduce diffs)

In D4170#88363, @lwhsu wrote:

In D4170#88316, @koobs wrote:

@lwhsu There's a bug in arc(8) client where the contents are not uploaded for newly created files (cc @eadler x 5)
Workaround: svn diff > patch the path, then click "Update Diff" inside this review to manually update it

BTW, @koobs, are you sure the issue is in arc itself?

In D4170#88316, @koobs wrote:

@lwhsu There's a bug in arc(8) client where the contents are not uploaded for newly created files (cc @eadler x 5)
Workaround: svn diff > patch the path, then click "Update Diff" inside this review to manually update it

Agreed, output on pkg info / version should be version specific (nice for concurrent installations)

In D4170#88336, @koobs wrote:

Should we be customising pkg-message's for the respective lang/pythonXY port to point directly to these suffixed-versions?

Should we be customising pkg-message's for the respective lang/pythonXY port to point directly to these suffixed-versions?

Manually upload the diff.

@lwhsu There's a bug in arc(8) client where the contents are not uploaded for newly created files (cc @eadler x 5)

Hmm, I just don't know why the added Makefile's are shown as empty in phabricator...
I put my patch here first: https://people.freebsd.org/~lwhsu/patch/python-standard-ports.diff
I'll ask what's going on.

Weird, these Makefile's should not be empty

My thoughts on this are:

Committed in r393390. Thank you for reviewing :-)

I've tested building the latest patch against 9/10 amd64/i38 and the port builds just fine. I've did some functional tests on 10.1 amd64 and here are the results:

I have double checked the patch - it works for me. Please make sure you have a clean checkout before applying the patch.

Latest patch fails to apply cleanly around PORTREVISION and when adjusted manually, the port build fails on patch phase:

Update with USE_LDCONFIG as suggested by Pawel, thank you!

Can we get a patch without the 'trampoline' thing accomodating USE_LDCONFIG change?

Obviously it should be

I am running a new build testing Pawel's proposed change - once it builds, I'll test it with virtualenv as well and report the results.

Thank you for your work on that port.

I created a trampoline shell script that sets LD_LIBRARY_PATH so that pypy can find libpypy-c.so.

I really don't understand this bug:

It seems that the libpypy-c.so is installed in wrong place:

Functional testing isnt possible yet, since I am having the very same issue described by dbn:

Here are the results of my build tests, the third revision:

I have encountered a strange problem in my testing:

@lwhsu: while I agree FreeBSD 8 can be ignored, this is a bug in the code.

In D3209#64602, @robak wrote:

While failing to build on 8, it does build fine on 10.1 amd64. I am testing the build for 10.1 i386 now, and if that will work, I'll move to testing on 9, and then I'll do tests with virtualenv.

While failing to build on 8, it does build fine on 10.1 amd64. I am testing the build for 10.1 i386 now, and if that will work, I'll move to testing on 9, and then I'll do tests with virtualenv.

Latest patch applies, but fails to build like that: http://pd.valinor.palantiri.org/build.html?mastername=84amd64-default&build=2015-07-27_07h38m22s

• Update patch using svn diff --patch-compatible.
• Fix OPTIONS to actually show option under correct situations
• Remove '`' around ${WRKDIR}/build.

The patch fails to apply cleanly:

I'll run this through my full 8/9/10/11 i386/amd64 poudriere test suite and will let you know my results. Thanks for fixing that!

Fix OPTIONS as identified by portlint.

@eadler │ <@koobs> eadler: is close review on commit busted? ---> the parser is finicky and our default template is wrong

Author: koobs
Date: Fri Jun 12 11:12:29 2015
New Revision: 389265
URL: https://svnweb.freebsd.org/changeset/ports/389265

Exp-run results:

Use USE_PYTHON=concurrent (for suffixes & default link)

Pending review before exp-run