Chih-Hsuan Yen (5fb8e34a) at 24 Mar 17:20
Make tests pass with pytest 8
This allows python-flask-sqlalchemy to be updated. python-flask-sqlalchemy!1 Upstream explicitly does not support > 2.5.1.
Packaging python-flask-sqlalchemy2.5 while possible it would ideally be patched to support dropping python-mocking.
Chih-Hsuan Yen (c117d591) at 24 Mar 16:53
Drop python-flask-sqlalchemy from optdepends.
Thanks! So I assume this change is safe by itself. I will merge this as-is and push other test fixes later.
Is this ready? I'd like to merge this and push some other pytest-related changes.
Chih-Hsuan Yen (585f36b8) at 24 Mar 03:57
Backport a test fix
Chih-Hsuan Yen (fda19f60) at 23 Mar 15:30
Backport a fix for pytest 8
Chih-Hsuan Yen (c6ccd17e) at 22 Mar 17:57
Backport a fix for pytest 8
Chih-Hsuan Yen (7fc2ad61) at 22 Mar 11:18
Fix test failures
Thanks!
Chih-Hsuan Yen (7706d23c) at 22 Mar 06:13
Fix tests with python 3.12
Thanks! Technically, this is not a blocker for Python 3.12, as setuptools now bundles distutils. It's still a good move. Any reason to keep it as a draft?
Chih-Hsuan Yen (3d46eff8) at 17 Mar 07:16
upgpkg: 4.0.1-2; make it work with the latest jupyter-server package
Chih-Hsuan Yen (2de23055) at 17 Mar 07:16
upgpkg: 4.0.1-2; make it work with the latest jupyter-server package
if the build succeeds, they push the package to the port's core repository
Thank you very much! I thought [core] is limited to Developers, regardless of the architecture.
Only when it comes to the (additional) release of a package.
By additional releases, I assume you mean "sub-versions (e.g. pkgrel=1.1
)" mentioned below. Does that mean Developers need to build and push packages for other ports if PKGBUILD changes are not required? Sounds a burden, especially for frequently-updated packages like core/linux.
Do you think there should be more information on this topic here?
Yes, it should be better. Developers can then estimate extra efforts required for more ports.
I think the question jelle is asking is what happens if there is a package that only exists on the port and not the "upstream" packages i.e. to offer platform specific tooling.
Sounds like there will be repositories with ports/xxx
branches but not the main
branch. That might confuse some tooling.
How will port maintainers handle [core] packages? I assume they need help from Developers?
A script in this package has an unusual shebang line:
$ tar -xOf exploitdb-20240207-1-any.pkg.tar.zst usr/share/exploitdb/exploits/php/webapps/44448.py | head -n 2
#!/usr/bin/env
import sys
As a side note, this is the second issue about unusual shebang lines (previously there is #64 (closed)). Maybe the function script_type
needs defensive programming.