On 7/31/2017 3:28 AM, Kubilay Kocak wrote: > On 7/31/17 8:07 PM, Baptiste Daroussin wrote: >> On Mon, Jul 31, 2017 at 05:03:35PM +0800, Marcelo Araujo wrote: >>> 2017-07-31 10:35 GMT+08:00 Kubilay Kocak <ko...@freebsd.org>: >>> >>>> On 7/31/17 11:16 AM, Marcelo Araujo wrote: >>>>> >>>>> >>>>> 2017-07-30 21:18 GMT+08:00 Adam Weinberger <ad...@adamw.org >>>>> <mailto:ad...@adamw.org>>: >>>>> >>>>> > On 28 Jul, 2017, at 22:17, Marcelo Araujo <ara...@freebsd.org >>>>> <mailto:ara...@freebsd.org>> wrote: >>>>> > >>>>> > Author: araujo >>>>> > Date: Sat Jul 29 04:17:31 2017 >>>>> > New Revision: 446864 >>>>> > URL: https://svnweb.freebsd.org/changeset/ports/446864 >>>>> <https://svnweb.freebsd.org/changeset/ports/446864> >>>>> > >>>>> > Log: >>>>> > - Update to 0.9.9. >>>>> > >>>>> > Changelog at: https://github.com/iocage/iocage/releases/tag/0.9.9 >>>>> <https://github.com/iocage/iocage/releases/tag/0.9.9> >>>>> > >>>>> > Modified: >>>>> > head/sysutils/py3-iocage/Makefile >>>>> > head/sysutils/py3-iocage/distinfo >>>>> > >>>>> > Modified: head/sysutils/py3-iocage/Makefile >>>>> > >>>>> ============================================================ >>>> ================== >>>>> > --- head/sysutils/py3-iocage/Makefile Sat Jul 29 04:00:56 2017 >>>>> (r446863) >>>>> > +++ head/sysutils/py3-iocage/Makefile Sat Jul 29 04:17:31 2017 >>>>> (r446864) >>>>> > @@ -1,7 +1,7 @@ >>>>> > # $FreeBSD$ >>>>> > >>>>> > PORTNAME= iocage >>>>> > -PORTVERSION= 0.9.8.1 >>>>> > +PORTVERSION= 0.9.9 >>>>> > CATEGORIES= sysutils python >>>>> > PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX} >>>>> > >>>>> > @@ -15,6 +15,7 @@ BUILD_DEPENDS= >>>>> ${PYTHON_PKGNAMEPREFIX}pytest-runner>=2 >>>>> > RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}click>=6.7:devel/py3-click \ >>>>> > ${PYTHON_PKGNAMEPREFIX}tqdm>=4.10.0:misc/py3-tqdm \ >>>>> > >>>>> ${PYTHON_PKGNAMEPREFIX}coloredlogs>0:devel/py3-coloredlogs \ >>>>> > + >>>>> ${PYTHON_PKGNAMEPREFIX}verboselogs>0:devel/py-verboselogs \ >>>>> > ca_root_nss>0:security/ca_root_nss \ >>>>> > >>>>> ${PYTHON_PKGNAMEPREFIX}texttable>=0.8.7:textproc/py3-texttable \ >>>>> > >>>>> ${PYTHON_PKGNAMEPREFIX}pytest-runner>=2.0.0:devel/py3-pytest-runner >>>>> >>>>> Hi Marcelo, >>>>> >>>>> There is no py36-verboselogs package. You'll need to create a >>>>> py3-verboselogs port, because right now only py27-verboselogs gets >>>>> built. >>>>> >>>>> See the build failure at >>>>> http://beefy10.nyi.freebsd.org/data/110i386-default/ >>>> 446906/logs/py36-iocage-0.9.9.log >>>>> <http://beefy10.nyi.freebsd.org/data/110i386-default/ >>>> 446906/logs/py36-iocage-0.9.9.log> >>>>> >>>>> # Adam >>>>> >>>>> >>>>> -- >>>>> Adam Weinberger >>>>> ad...@adamw.org <mailto:ad...@adamw.org> >>>>> https://www.adamw.org >>>>> >>>>> >>>>> Hi, >>>>> >>>>> We can't add py3 ports because soon we gonna have FLAVORS! >>>>> I can build iocage if I define the python version on my make.conf, >>>>> however I can see the issue with poudriere. >>>> >>>> Since this port already uses py3-* (workaround) ports for dependencies >>>> and there is no known ETA for VARIANTS support in ports, and the port is >>>> broken without py3-verboselogs, it should be created. >>>> >>>> Also, py-iocage should be resurrected, py-iocage was incorrectly deleted >>>> [1] instead of this one when it moved to Python 3.x only support. py3-* >>>> ports are only for (temporary) dependencies >>>> >>>> [1] http://svnweb.freebsd.org/changeset/ports/445459 >>> >>> >>> How I can pass the pre-commit hook that blocks any add of py3 slave ports? >>> >>> Best, >>> >> >> FLAVORS are in review and finished, poudriere is able to deal with them >> -devel. >> >> The commit is pending exp-run, documentation etc. It takes time as it is a >> major >> change in the framework with huge impact. >> >> py3-* were a hack in the first place that should never have been done, they >> addition made it more complicated to work on FLAVORS, adding more and by >> passing >> the hook would just give even more delay for FLAVORS to be committed. > >> Best regards, >> Bapt >> > > Existing ports (particularly popular ports like iocage) that already > rely on these dependencies should be allowed continue to work. The block > relies on the assumption that new dependencies for existing and working > ports will never be needed, which is the case here. > > The block on new py3-* ports (while noone likes them) was and is > premature, and is even more so without an alternative, and it was > heavy-handed. Developers were already trying hard to minimise their use. > > The block should be removed, and can be re-added when the official > package builders are running with the poudriere "special feature" > version that builds py3-* versions of py- ports automatically, or ports
I'm not quite awake yet so pardon the terseness. I will start a poudriere-devel exp-run now and then push it out to the builders following that in the next 2 days. That will allow py3- dependencies to build properly. It would allow existing py3- leaf ports to build as well. As for py3- leaf ports I would allow them but they have to follow strict criteria: - They must be named category/py3-foo - They must be a *slave* port to a category/py-foo - They must be supported on all python versions, not just 3.4+ or something odd like that. The FLAVORS support in Poudriere is done. What is held up is an exp-run that I'm tasked with and various bugs/documentation/more exp-runs. Every new py3- port added that doesn't follow those rules means we have to change Poudriere again. I think the criteria above is reasonable but I know the last one is problematic. I've said on IRC before but not sure I have here, that py3- ports beyond the fixed cases above, are only useful for generating a leaf package for users to download. They can still build category/py-foo as PYTHON3 today though. So there is an alternative but it is just not package-friendly yet. About the block being premature, I will agree that what was lacking was a communication about it to a wider community and an override allowed with Portmgr review. At the time I wasn't quite sure what the criteria for an override would even be. Now that I understand it more and have Poudriere being a bit smarter than my first implementation, I will tweak the block to allow a Portmgr override. > variants supports lands, whichever one comes first. If that's in 3 days, > great, if its in 3 weeks or 2 months, our developers have been allowed > to keep the status quo working. > > Users are currently being impacted where there is no alternative and > they should not be asked to pay that price for our dislike of py3-* ports. > > Best regards, > Koobs > -- Regards, Bryan Drewery
signature.asc
Description: OpenPGP digital signature
