[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 ||gzilla/show_bug.cgi?id=2608 ||97 -- You are receiving this mail because: You are on the CC list for the bug.
[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: Vinícius Zavam AuthorDate: 2022-08-07 14:53:48 + Commit: Vinícius Zavam CommitDate: 2022-08-07 14:59:16 + security/py-stem: Replace 'pycrypto with 'cryptography' * Fix 'DEPRECATED'; * Maintainer reset per long time hiatus in Bugzilla (6months+); * Replace 'pycrypto with 'cryptography' (follow upstream); https://gitlab.torproject.org/legacy/trac/-/issues/21086#note_2236877 PR: 248712 Reported by:John W. O'Brien Approved by:rene@ security/py-stem/Makefile | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.
[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 receiving this mail because: You are on the CC list for the bug.
[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|Closed -- You are receiving this mail because: You are on the CC list for the bug.
[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 |Added Status|Open|Closed Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[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: Vinícius Zavam AuthorDate: 2022-08-07 15:17:20 + Commit: Vinícius Zavam CommitDate: 2022-08-07 15:24:17 + www/onionshare: fix DEPRECATED deps, and update pluggable transports * fix DEPRECATED flag, by using a more reliable Python module; * used pycryptodome instead of cryptography to keep compatibility; * update pluggable transports support by adding snowflake. PR: 260897, 262503, 265390 Reported by:yuri@, ruben , chris Sponsored by: TorBSD Diversity Project, TDP Sponsored by: The Tor Project www/onionshare/Makefile | 17 - www/onionshare/distinfo | 6 +++--- 2 files changed, 11 insertions(+), 12 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.
[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|Removed |Added Status|In Progress |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[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 Progress |Closed -- You are receiving this mail because: You are on the CC list for the bug.
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 obsolete releases. Status |Bug Id | Description +---+--- New |265082 | devel/ipython: 7.31.1 was a security release but Open|205308 | devel/py-pip and devel/py-virtualenv don't aggree Open|240343 | x11-themes/plasma5-breeze-gtk: Fails to build if Open|242896 | lang/python*: Fail to package in poudriere (testp Open|256699 | lang/python38: Fails to configure when IPv6 not s Open|258192 | devel/py-pyinstaller: Fails to run on 3.8+. Fix i In Progress |255025 | textproc/py-chardet: Update to 4.0.0 Open|257353 | lang/python38: Intermittently fails to build unde Open|264993 | www/mitmproxy: Update to 8.1.1 In Progress |241416 | [NEW PORT] lang/python38 Open|264426 | www/mitmproxy: Update to 8.0.0 (<=7.0.4 vulnerabl New |264990 | devel/py-Jinja2: Update to 3.1.2 Open|234981 | graphics/py-wand: Add DOCS option Pass MAINTAINER Open|260448 | [NEW] devel/py-aiosignal: Project to manage callb Open|265537 | databases/py-sqlite3: Fix runtime error with lang Open|262109 | Mk/Uses/python.mk: Improve CMake/Python integrati Open|224115 | devel/py-babel directory name != port name In Progress |258195 | lang/python38: Update to 3.8.12 New |264992 | devel/py-click: Update to 8.1.3 New |231555 | Mk/Uses/python.mk: Add USE_PYTHON=pytest 20 problems total for which you should take action.
[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 #16 from Daniel Engberg --- Status on this PR? -- You are receiving this mail because: You are on the CC list for the bug.
[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 receiving this mail because: You are on the CC list for the bug.
[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-517: * It is PEP-517 compliant. * It requires port maintainers to parse pyproject.toml and add DEPENDS lines accordingly (this is also done in the supplied examples). * It checks that requirements are met, and fails otherwise. Differences: * I used USE_PYTHON=build instead of USE_PYTHON=pep517: the user intent here is to build the project. IMO there's no need to put the standard name into Makefiles in many places. "build" is a lot easier to remember. * autoplist isn't currently supported. It isn't obvious that it should be. Benefits of this implementation: * It is minimalistic. It does exactly what is required with as little code as possible. * It uses only build/installer packages, a minimally required set of dependencies, and still provides the same functionality. Best, Yuri -- You are receiving this mail because: You are on the CC list for the bug.
[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 distutils path in package management and standardising on wheels. Even though setuptools includes an internal copy of distutils, there is no guarantee of it still existing in the future. Thus, in terms of future-proofing, this cannot go into the framework without also converting the toolchain to setuptools-less bootstrapping. USE_PYTHON=build actually is misleading, because it's only one (minimalist) tool that only builds, not installs. In fact, py-build and py-installer didn't exist until after PEP-517 was accepted and (ensure)pip gained support. -- You are receiving this mail because: You are on the CC list for the bug.
[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 explicitly specify them as a dependency. "build" is a user intent, not a package name. It is such so that it can be easily remembered. > [...] in terms of future-proofing, this cannot go into the framework without > also converting the toolchain to setuptools-less bootstrapping. This is a more global issue. setuptools and distutils aren't going anywhere regardless of what standards say, simply because there are so many projects that use them. This potential problem can be solved once it becomes a real problem. And it won't become a real problem any time soon. Yuri -- You are receiving this mail because: You are on the CC list for the bug.
[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 themselves. installer is actually built wrong in this case since the specified build backend is flit, not setuptools (but works by coincidence). > "build" is a user intent, not a package name Still misleading, because the intent does not imply install to staging/wherever. > This potential problem can be solved once it becomes a real problem. And it > won't become a real problem any time soon. It will become a real problem in our tree when PEP-517 support lands in the framework. Currently, when USES_PYTHON=distutils is specified, setuptools is an unconditional RUN_DEPENDS, which is unnecessary and wrong for PEP-517. -- You are receiving this mail because: You are on the CC list for the bug.
[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 moment because of sheer number of non-compliant packages. To be clear, the current patch introduces a local PEP-517 compliance so that the projects that have already switched to PEP-517 can be ported. This opens the path forward to a lot of software to enter the ports tree. Strict global PEP-517 compliance is something else that can be gradually addressed at a later time. This patch doesn't present an obstacle to this. Yuri -- You are receiving this mail because: You are on the CC list for the bug.
[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 is a hack at best, much like my phab reviews marked WIP. Functionality that USE_PYTHON=distutils provided that is available in PEP-517 (like autoplist) has to be provided. Additionally, the "toolchain" has to bootstrap itself through the framework. There is no gradual as far as the framework is concerned, but individual packages can go at their pace. To further clarify, the best "testsuite" for the framework support is the (self-)bootstrap "toolchain" listed in the wiki. -- You are receiving this mail because: You are on the CC list for the bug.
[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 can't enter the ports tree. This patch doesn't aim to enable global PEP-517 compliance, but it also doesn't stand in its way. If you mean that the whole tree should be converted to PEP-517 at once - this is not practically possible. But this is an entirely orthogonal matter to the patch in question. There is also no reason why this patch would prevent self-bootstrapping. Yuri -- You are receiving this mail because: You are on the CC list for the bug.
[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 paces. Bottom line, this really cannot be anywhere near rushed and has to be thought through holistically, even though there exist prospective ports that need the framework. The self-bootstrapping bit is merely an example of required flexibility in the framework (which does not exist in this WIP), in their case to eliminate circular dependencies. I updated the wiki page to clarify on some design goals that need met. -- You are receiving this mail because: You are on the CC list for the bug.