[Bug 265390] www/onionshare traceback

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265390 Vinícius Zavam changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu

[Bug 248712] security/py-stem: Replace security/py-pycrypto with security/py-cryptography

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248712 --- Comment #11 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=f2a9a5c3bbd57761069645e422ed63fc64a694bd commit f2a9a5c3bbd57761069645e422ed63fc64a694bd Author:

[Bug 248712] security/py-stem: Replace security/py-pycrypto with security/py-cryptography

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248712 Vinícius Zavam changed: What|Removed |Added Assignee|c...@freebsd.org |egyp...@freebsd.org -- You are

[Bug 248712] security/py-stem: Replace security/py-pycrypto with security/py-cryptography

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248712 Vinícius Zavam changed: What|Removed |Added Resolution|--- |FIXED Status|Open

[Bug 265390] www/onionshare traceback

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265390 Bug 265390 depends on bug 248712, which changed state. Bug 248712 Summary: security/py-stem: Replace security/py-pycrypto with security/py-cryptography https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248712 What|Removed

[Bug 265390] www/onionshare traceback

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265390 --- Comment #8 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d0aab7f46df1ee2494ac09858fd903330f785d43 commit d0aab7f46df1ee2494ac09858fd903330f785d43 Author:

[Bug 265390] www/onionshare traceback

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265390 Bug 265390 depends on bug 248438, which changed state. Bug 248438 Summary: www/onionshare: Replace security/py-pycrypto dependency with security/py-pycryptodome https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248438 What|R

[Bug 265390] www/onionshare traceback

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265390 Vinícius Zavam changed: What|Removed |Added Resolution|--- |FIXED Status|In Progr

Problem reports for python@FreeBSD.org that need special attention

To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and ob

[Bug 241416] [NEW PORT] lang/python38

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241416 Daniel Engberg changed: What|Removed |Added CC||dii...@freebsd.org --- Comment #1

[Bug 255722] Mk/Uses/python.mk: Needs to support pyproject.toml-based projects: USE_PYTHON=build feature

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255722 Charlie Li changed: What|Removed |Added CC||python@FreeBSD.org -- You are receiv

[Bug 255722] Mk/Uses/python.mk: Needs to support pyproject.toml-based projects: USE_PYTHON=build feature

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255722 --- Comment #10 from Yuri Victorovich --- (In reply to Charlie Li from comment #9) Hi Charlie, Thanks for your comment. Current implementation is functionally almost identical to your description in https://wiki.freebsd.org/Python/PEP-51

[Bug 255722] Mk/Uses/python.mk: Needs to support pyproject.toml-based projects: USE_PYTHON=build feature

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255722 --- Comment #11 from Charlie Li --- autoplist is supported, just a different way of doing it (and much less fragile). "Minimalistic" will not work here, because a major part of PEP-517 is completely deprecating the setup.py or otherwise di

[Bug 255722] Mk/Uses/python.mk: Needs to support pyproject.toml-based projects: USE_PYTHON=build feature

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255722 --- Comment #12 from Yuri Victorovich --- (In reply to Charlie Li from comment #11) Dear Charlie, distutils and setuptools aren't required ot be present in the suggested approach. They would only be needed if pyproject.toml would explicit

[Bug 255722] Mk/Uses/python.mk: Needs to support pyproject.toml-based projects: USE_PYTHON=build feature

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255722 --- Comment #13 from Charlie Li --- > distutils and setuptools aren't required ot be present in the suggested > approach They are present by virtue of py-build and py-installer currently in the tree using distutils/setuptools to build the

[Bug 255722] Mk/Uses/python.mk: Needs to support pyproject.toml-based projects: USE_PYTHON=build feature

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255722 --- Comment #14 from Yuri Victorovich --- (In reply to Charlie Li from comment #13) If you are implying that all instances of setuptools/distutils use would be removed form the ports tree for strict PEP-517 - this is a non-starter at the m

[Bug 255722] Mk/Uses/python.mk: Needs to support pyproject.toml-based projects: USE_PYTHON=build feature

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255722 --- Comment #15 from Charlie Li --- > If you are implying that all instances of setuptools/distutils use would be > removed form the ports tree Not what I meant, since setuptools is also itself a PEP-517 build backend. The current patch i

[Bug 255722] Mk/Uses/python.mk: Needs to support pyproject.toml-based projects: USE_PYTHON=build feature

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255722 --- Comment #16 from Yuri Victorovich --- (In reply to Charlie Li from comment #15) Charlie, You have probably misunderstood. The purpose of this patch is to allow individual packages to proceed at their own pace. Some of them currently c

[Bug 255722] Mk/Uses/python.mk: Needs to support pyproject.toml-based projects: USE_PYTHON=build feature

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255722 --- Comment #17 from Charlie Li --- > If you mean that the whole tree should be converted to PEP-517 at once - this > is not practically possible. Also not what I meant. I agree that individual ports/packages should proceed at their own pa