As current port version 4.0.4 from Jul 31 2018 has not been upgraded since then please upgrade to upstream version 5.3.0 from Nov 1 2020 Thank you
There're some dependencies needed to be upgraded first.
Please post the list of dependencies so that work there can be organized.
ping! Please share your problems that prevent from upgrading the port.
Having a quick look: https://github.com/mitmproxy/mitmproxy/blob/master/setup.py#L66 --> http://dev.freshports.org/security/py-cryptography/ (Just got bumped, this will be a pain to bump) http://dev.freshports.org/www/py-h2/ http://dev.freshports.org/www/py-hyperframe/ http://dev.freshports.org/net/py-ldap3/ http://dev.freshports.org/security/py-openssl/ Pending: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245930 (still too hold however)
6.0.1 was out. I'll take a look...Q__Q
In 6.0.1, the following is the list of dependencies needed to be upgraded. devel/py-protobuf, needs to upgradae to 3.14 devel/py-sortedcontainers, needs to upgradae to 2.3 net/py-ldap3, needs to upgradae to 2.8 net/py-wsproto, needs to upgradae to 1.0 security/py-cryptography, needs to upgradae to 3.3 security/py-openssl, needs to upgradae to 20.0 www/py-h2, needs to upgradae to 4.0 www/py-hyperframe, needs to upgradae to 6.0
Created attachment 221015 [details] www__mitmproxy.diff Attached is patch of mitmproxy 6.0.2.
Please commit as current port version 4.0.4_2 now fails to build: ===> mitmproxy-4.0.4_2 depends on package: py38-hyperframe>=5.1.0<6 - not found ===> Installing existing package /packages/All/py38-hyperframe-6.0.0.txz [12amd64-default-jails-job-07] Installing py38-hyperframe-6.0.0... [12amd64-default-jails-job-07] Extracting py38-hyperframe-6.0.0: .......... done ===> mitmproxy-4.0.4_2 depends on package: py38-hyperframe>=5.1.0<6 - not found *** Error code 1 Stop. make: stopped in /usr/ports/www/mitmproxy =>> Cleaning up wrkdir ===> Cleaning for mitmproxy-4.0.4_2 build of www/mitmproxy | mitmproxy-4.0.4_2 ended at Sat Jan 2 14:06:16 CET 2021 build time: 00:00:29 !!! build failure encountered !!!
Created attachment 222824 [details] mitmproxy-6.0.2.diff I update the patch to make it apply to the latest ports tree. It still cannot build because we need to also produce py38 packages first. I'll se how we can do so.
ping! As this looks like an example of a never ending story, there should be a general analysis why freebsd has so much trouble with Python apps/modules. Perhaps we should port Anaconda or seek "external" advise. It's so sad. Some Python apps (like the sci*) are not usable with FreeBSD which suggests just to use other platforms if you have to get your pending work done. EOF rant
I've tried Li-Wen's patch and here is few findings: - py-zstandart version is 0.15.2, but 6.0.2 requires version less that 0.15 - manual patch of Makefile & setup's requires allows to build & execute mitmproxy (poudriere build is fine with BUILD_ALL_PYTHON_FLAVORS=yes) Thanks!
(In reply to Michael Zhilin from comment #11) > - py-zstandart version is 0.15.2, but 6.0.2 requires version less that 0.15 Do you mean archivers/py-zstandard ? We can add an older (and supported) version, like archivers/py-zstandard14, if it is needed. > - manual patch of Makefile & setup's requires allows to build & execute mitmproxy (poudriere build is fine with BUILD_ALL_PYTHON_FLAVORS=yes) If upstream has a patch to use newer dependency, we can pull that in. And, yeah, didn't think of we can set BUILD_ALL_PYTHON_FLAVORS=yes for the dependencies. (Maybe just adding py38 is fine.)
(In reply to Li-Wen Hsu from comment #12) Yes, archivers/py-zstandard. The upstream uses new versions of py-zstandard, but there is no release including this change. That's why option to add py-zstandard14 looks excellent. "BUILD_ALL_PYTHON_FLAVORS=yes" is workaround to force build of packages, because poudriere ignored them due to following settings: - default python versions are 2.7 and 3.7 (not 3.8) - Uses/python will limit flavors to default versions if no allflavours feature is set in Makefile and if no BUILD_ALL_PYTHON_FLAVORS=yes in make.conf To build mitmproxy I was forced to use BUILD_ALL_PYTHON_FLAVORS=yes
(In reply to Michael Zhilin from comment #13) > To build mitmproxy I was forced to use BUILD_ALL_PYTHON_FLAVORS=yes This is fine for people building packages themselves, but we need a way that can make us a pre-built package on pkg.freebsd.org.
(In reply to Li-Wen Hsu from comment #14) There should *never* be a need to build all package flavors, if all port dependencies (uses=python:<version-specs and RUN_DEPENDS> are correctly declared. Also what is the nature of the dependence on bug 253815 (a specific python version as default) ? This doesn't make sense to me.
(In reply to Kubilay Kocak from comment #15) > There should *never* be a need to build all package flavors, if all port dependencies (uses=python:<version-specs and RUN_DEPENDS> are correctly declared. Not directly related to build all flavors, but need to have the required python version packages of these ports available. IIRC having USES=python:<...> versions can only mark that package works with these python versions, but I don't think it can make the packages with those versions available. > Also what is the nature of the dependence on bug 253815 (a specific python version as default) ? This doesn't make sense to me. Because mitmproxy needs python 3.8, and it needs all it's required packages available with python 3.8. This is not the best solution but is the easiest way to make mitmproxy available as a pre-built package again.
(In reply to Michael Zhilin from comment #13) > Yes, archivers/py-zstandard. The upstream uses new versions of py-zstandard, but there is no release including this change. That's why option to add py-zstandard14 looks excellent. Is that patch to update the dependency easy to be backport'd? I believe this is the final block of this updating.
(In reply to Li-Wen Hsu from comment #17) I just looked through the commit history for mitmproxy and everything related to updating dependency versions. I'm not seeing any actual code fixes being applied. This is the pull request that did the update for zstandard: https://github.com/mitmproxy/mitmproxy/pull/4373 Judging by the activity around this I'm of the opinion there's not a compatibility issue, just overly conservative version pinning.
(In reply to p5B2E9A8F from comment #10) > As this looks like an example of a never ending story, there > should be a general analysis why freebsd has so much trouble > with Python apps/modules. This is a fundamental developer ease issue. It's a disease that affects many languages. Dependencies are too easy to add to a project. They should be hard so people know what their software actually needs. The root of the problem is pip, npm, go-get, and their like in combination with the popularity of frameworks. This combination is the bane of anyone who maintains operating system packages (ports, yum, apt etc..). Disclaimer: For work I maintain several hundred packages (mostly python) on top of the base OS all delivered in packages. I am a sys-admin who can develop, and that may have jaded my view on the matter.
www/py-hyperframe was committed to to 6.0.0 on 28 Dec 2020 14:04:25