mat or bapt can u please give your mentor approval.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 26 2015
Dec 21 2015
BTW; I forgot to mention that the plist is sorted according to make makeplist.
- Switch to do-test (I am actually not happy with this change because we should get in a proper test_target which is still on my todo)
- Update Docs
Regarding the tests:
No need to update the vuxml since it was patched already and documented.
- Update test (regression-test) target in updated ports (+ other pythonxy ports if you want)
- Add summary test suite results to review TEST PLAN section. Eg format:
Dec 20 2015
Nov 19 2015
Nov 18 2015
LGTM!
After discussing on IRC, latest change makes sense now.
lwhsu@lwbsd:~/ports/lang/python35 > make -V PYTHON_PORTVERSION 3.5.0 lwhsu@lwbsd:~/ports/lang/python35 > make -V PYTHON_VER 3.5 lwhsu@lwbsd:~/ports/lang/python35 > make -V PYTHON_VERSION python3.5 lwhsu@lwbsd:~/ports/lang/python35 > make -V PYTHON_SUFFIX 35 lwhsu@lwbsd:~/ports/lang/python35 > make -V PKGNAME python35-3.5.0_1
Summaries of the changes:
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:BTW, @koobs, are you sure the issue is in arc itself?
In D4170#88316, @koobs wrote:
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.
Nov 15 2015
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
Aug 31 2015
Aug 15 2015
Aug 5 2015
My thoughts on this are:
Aug 3 2015
Aug 1 2015
Committed in r393390. Thank you for reviewing :-)
Jul 30 2015
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:
Jul 29 2015
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.
Jul 28 2015
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:
Jul 27 2015
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.
Jul 26 2015
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.
Jun 26 2015
Jun 12 2015
Author: koobs
Date: Fri Jun 12 11:12:29 2015
New Revision: 389265
URL: https://svnweb.freebsd.org/changeset/ports/389265
Jun 2 2015
Exp-run results:
Jun 1 2015
Use USE_PYTHON=concurrent (for suffixes & default link)
Pending review before exp-run