Created attachment 165028 [details] Make xcb-proto build against python 3.5, 3.4 and 2.7 In an attempt to build ALL packages that use Python (anything with "python*" in USES, except "py3-*" ports and those marked for python2(.7)) against Python 3.5 exclusively (via DEFAULT_VERSIONS), so we can see what's broken and how, one big blocker was x11/xcb-proto holding down 1000+ packages that were skipped by Poudriere because it wouldn't build (plist issues with __pycache__ files). This patch makes sure it builds and installs against 3.5 and 3.4, and also tested against default (no DEFAULT_VERSIONS forced) 2.7. While at it, I added the license (which I believe is MIT, looking at the distfile's COPYING file) to keep portlint quiet. However, since I'm still a total noob in porting, this needs testing and feedback! Portlint: OK (except warning about Comment) Poudriere: - 10.2 (amd64) OK w/ Python 3.5 - 10.2 (amd64) OK w/ Python 3.4 - 10.2 (amd64) OK w/ Python 2.7
BTW, I _am_ aware that the general idea is to drop .pyc and .pyo from plists in favor of autoplist and/or whatever other post-install mechanism. But until then, my proposed solution is this.
(In reply to Vladimir Krstulja from comment #0) The license is the MIT X11 license to be specific.
Created attachment 165033 [details] xcb-proto.patch While I made the same changes to first get xcb-proto building, the ports system appears to have been updated to handle py3.5. That leads to a cleaner way being to remove the python version tests and PLIST_SUB commenting and replace them with USE_PYTHON= py3kplist Don't expect autoplist to work as xcb-proto uses it's own makefile not pythons distutils. The other change we should be making is to add PKGNAMEPREFIX to allow the xcb-proto pymodule to be installed in multiple versions. This leaves the xml files in share/xcb and the pkgconfig file. I expect moving these will break any dependencies using these files though. I wonder if this should become two ports, one for the xml files and one for the python module. Brendan - X11/Xorg is covered by the MIT license - using LICENSE=MIT gives the description "MIT license / X11 license" from Mk/bsd.licenses.db.mk
(In reply to FreeBSD from comment #3) I didn't realise this was the use case for `USE_PYTHON= py3kplist`. Awesome! Also yes, I was aware that MIT is the X11 license as per the database as well; was just making it clear to anyone who might ask "but Expat?!" :)
Comment on attachment 165028 [details] Make xcb-proto build against python 3.5, 3.4 and 2.7 Great, exactly the feedback I wanted! The latest patch, from comment #3, works, xcb-proto builds across the board with Poudriere: 10.2 and 9.3, with Python 3.5, 3.4 and 2.7. Tested amd64 only.
There's already an exp-run and a review by sunpoet in phabric for fixing this, please coordinate with him. review D4758 bug #205807
*** Bug 206004 has been marked as a duplicate of this bug. ***
(In reply to Antoine Brodin from comment #6) Question, is this strictly related to bug #205807 and its solution? My patch is using py3kplist as suggested in comment #3, meaning it works with the current state of ports head.
(In reply to Vladimir Krstulja from comment #8) Short - no. You are good to go with or without this patch. py3kplist makes pkg-plist transparent conversion to python3 style and patch just adds some variables which needs for those who create ports starting with python3 version instead of using py3kplist.
A commit references this bug: Author: rm Date: Sun Mar 6 21:57:11 UTC 2016 New revision: 410487 URL: https://svnweb.freebsd.org/changeset/ports/410487 Log: x11/xcb-proto: fix packaging with python3.5 Utilize py3kplist to fix packaging with python 3.5 and to simplify Makefile. Add LICENSE (MIT) and bump PORTREVISION for package changes. Add NO_ARCH, while here. PR: 205859 Submitted by: Vladimir Krstulja <vlad-fbsd@acheronmedia.com> Submitted by: FreeBSD@ShaneWare.Biz (py3kplist suggestion) Approved by: maintainer timeout Changes: head/x11/xcb-proto/Makefile head/x11/xcb-proto/pkg-plist
Committed, thank you!
Assign to committer that resolved. @Ruslan, if this is reproducible in quarterly it should be MFH'd
It wasn't requested by submitter and it can't be reproduced in default environment, so I'd leave it as is in 2016Q1.