Bug 250799 - www/mitmproxy: update to 6.0.2
Summary: www/mitmproxy: update to 6.0.2
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-ports-bugs (Nobody)
URL: https://mitmproxy.org/downloads/#5.3.0/
Keywords: needs-patch
Depends on: 252204 252205 252206 252207 252208 252209 252210 252212 253815
Blocks:
  Show dependency treegraph
 
Reported: 2020-11-02 08:55 UTC by p5B2E9A8F
Modified: 2021-05-13 19:19 UTC (History)
7 users (show)

See Also:
gaod: maintainer-feedback+


Attachments
www__mitmproxy.diff (15.97 KB, patch)
2020-12-27 16:21 UTC, Hung-Yi Chen
no flags Details | Diff
mitmproxy-6.0.2.diff (16.36 KB, patch)
2021-02-25 14:34 UTC, Li-Wen Hsu
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description p5B2E9A8F 2020-11-02 08:55:46 UTC
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
Comment 1 Hung-Yi Chen 2020-11-03 14:45:54 UTC
There're some dependencies needed to be upgraded first.
Comment 2 p5B2E9A8F 2020-11-25 09:58:04 UTC
Please post the list of dependencies so that work there can be organized.
Comment 3 p5B2E9A8F 2020-12-12 14:32:46 UTC
ping! Please share your problems that prevent from upgrading the port.
Comment 5 Hung-Yi Chen 2020-12-20 20:38:52 UTC
6.0.1 was out.
I'll take a look...Q__Q
Comment 6 Hung-Yi Chen 2020-12-22 14:52:40 UTC
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
Comment 7 Hung-Yi Chen 2020-12-27 16:21:37 UTC
Created attachment 221015 [details]
www__mitmproxy.diff

Attached is patch of mitmproxy 6.0.2.
Comment 8 p5B2E9A8F 2021-01-02 13:18:45 UTC
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 !!!
Comment 9 Li-Wen Hsu freebsd_committer 2021-02-25 14:34:57 UTC
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.
Comment 10 p5B2E9A8F 2021-03-12 09:23:56 UTC
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
Comment 11 Michael Zhilin freebsd_committer 2021-03-16 10:50:26 UTC
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!
Comment 12 Li-Wen Hsu freebsd_committer 2021-03-16 11:22:32 UTC
(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.)
Comment 13 Michael Zhilin freebsd_committer 2021-03-16 12:18:42 UTC
(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
Comment 14 Li-Wen Hsu freebsd_committer 2021-03-16 13:07:09 UTC
(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.
Comment 15 Kubilay Kocak freebsd_committer freebsd_triage 2021-04-26 01:17:00 UTC
(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.
Comment 16 Li-Wen Hsu freebsd_committer 2021-04-26 08:39:59 UTC
(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.
Comment 17 Li-Wen Hsu freebsd_committer 2021-04-29 22:33:53 UTC
(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.
Comment 18 Shawn Michael 2021-05-04 22:19:27 UTC
(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.
Comment 19 Shawn Michael 2021-05-04 22:37:44 UTC
(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.
Comment 20 p5B2E9A8F 2021-05-06 17:32:24 UTC
www/py-hyperframe was committed to to 6.0.0 on 28 Dec 2020 14:04:25