Bug 259456 - www/mitmproxy: 7.0.2 fails to run: pkg_resources.DistributionNotFound: The 'zstandard<0.16,>=0.11' distribution was not found
Summary: www/mitmproxy: 7.0.2 fails to run: pkg_resources.DistributionNotFound: The 'z...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Li-Wen Hsu
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2021-10-26 09:38 UTC by p5B2E9A8F
Modified: 2021-11-15 18:10 UTC (History)
3 users (show)

See Also:
gaod: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description p5B2E9A8F 2021-10-26 09:38:05 UTC
pkg_resources.DistributionNotFound: The 'zstandard<0.16,>=0.11' distribution was not found and is required by mitmproxy
Comment 1 Li-Wen Hsu freebsd_committer 2021-10-26 10:26:47 UTC
Does it still work if we locally patch out the restriction in setup.py ? If it works, we can also ask upstream to update it.

Also, we may want to restore the version limits in ports c7bab0df6c8375d5f110ad467b07f3cb7667c327
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2021-10-27 01:09:00 UTC
^Triage: This port needs to match the version-specs declared in the upstream sources, including pinned versions, or patch them (and confirm QA still passes). 

Currently the port only declares (incompletely) the min version, removed in ports 2a8ff889d6

Adding TEST_DEPENDS and a test target would go a long way to being able to QA properly in future
Comment 3 p5B2E9A8F 2021-10-27 09:00:57 UTC
At least to me it makes almost none sense pinning maximum versions of dependencies. This practice leads to frequently broken ports, which *must not* be our primary goal in a dynamic environment of dependencies and using dependencies whenever possible.

Our goal *should* be maintaining ports with the most little efforts possible as we have already a huge workload.

Pinning maximum versions makes sense if it is already known that a coming version of a dependency will break something. The fear that it might always be possible is not a sufficient reason. At some places it has become a questionable practise instead.

It *should not* need to be mentioned that repairing broken ports have priority over delaying, waiting for something, or following policies that tend to mount problems.  

It is a known problem with Python apps running frequently in dependency failures. This has become to such a plague that it has become an almost general recommendation using virtual environments. There is a general need to discuss that development affecting the large number of FreeBSD-Python-ports having to be maintained. 

The www/privoxy port is a general example for breaking frequently and it has a history being broken even for months. I'm *not* pointing to the port-maintainer here. It is a phenomenon that needs to be addressed in a more general way for maintaining the ports.
Comment 4 p5B2E9A8F 2021-10-27 09:21:58 UTC
s/privoxy/mitmproxy/ above
sorry for the typo.
Comment 5 Yuri Victorovich freebsd_committer 2021-10-27 14:48:49 UTC
I agree with p5B2E9A8F@t-online.de, the <0.16 part should be removed and it should be retested.
Comment 6 p5B2E9A8F 2021-11-15 13:09:38 UTC
16 September 2021: mitmproxy 7.0.3

    CVE-2021-39214: Fix request smuggling vulnerabilities reported by @chinchila (@mhils)
    Expose TLS 1.0 as possible minimum version on older pyOpenSSL releases (@mhils)
    Fix compatibility with Python 3.10 (@mhils)

This war reported 2021-10-24 11:16 UTC by Kurt Jaeger 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259400

Nothing happened except "LGTM" by maintainer.

When even CVEs don't get fixed, what are waiting for?

Request marking www/mitmproxy ans BROKEN
Request maintainer timeout
Comment 7 Hung-Yi Chen 2021-11-15 16:22:21 UTC
I agree that we should mark mitmproxy as BROKEN first.