After some thinking over this, documenting this behavior makes sense
versus adding some functionst to handle this.
There is some validity/use-cases where some users may want to reference
a python[3]-package.mk from some other location as well as have the
flexibility to change it (locally). One example can be when the local
`packages` is renamed to something else.
This does not fall on the responsibility of the Python maintainers, but
it can be documented.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This changes --with-ensurepip=install to upgrade, to upgrade host
versions of setuptools and pip to the Python-bundled versions.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
Two seperate package names were chosen instead of menu selected options
because dependents need a ready (large) package in release directory.
Signed-off-by: Eric Luehrsen <ericluehrsen@gmail.com>
Expressions '-o', '-a', and '\( \)' within test or '[ ]' are obsolete.
POSIX allows few arguments to test, so long expressions are not
portable. '[ p -a q ]' can be replaced with '[ p ] && [ q ]' instead.
Signed-off-by: Eric Luehrsen <ericluehrsen@gmail.com>
This removes radicale-py2, the Py2 variant, and renames radicale-py3 to
radicale.
This also makes a number of changes:
* Actually use the Python package build system (from python3-package.mk)
* Download source from PyPI instead of GitHub git repo
* Remove unnecessary PKG_DEFAULT_DEPENDS definition
* Depend on python3-urllib instead of python3-email (now that urllib is
separate from python3-light and has python3-email as a direct
dependency)
* Move package description from menuconfig help to the actual
description field
* Remove unnecessary preinst script (default prerm will stop the
service now that the package name matches the init.d script name)
* Remove unnecessary lib/upgrade/keep.d entry (changed conffiles are
preserved by sysupgrade by default)
* Remove unnecessary postinst script (Python build system will set the
correct shebang)
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
Added $(TARGET_CPPFLAGS) to TARGET_CFLAGS to fix a buildbot failure to
find oniguruma include files.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
The first and last hunks of the patch were already taken care of, but
the middle two were still needed.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
The Python 2 and 3 versions of chardet both install a script with the
same name (/usr/bin/chardetect). This is the issue identified in #9006
(https://github.com/openwrt/packages/pull/9006#issuecomment-493709812).
This renames the Python 3 script to chardetect3.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
libevhtp 1.2.18 made API changes, and unbundled oniguruma.
To adapt seafile-server, some patches from Alexandre Rossi's debian
packaging at http://sousmonlit.zincube.net/~niol/repositories.git/
were applied.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
Versions earlier than 1.2.15 had security vulnerabilities, especially
related to the bundled oniguruma. Now libevhtp uses a system-provided
library instead. The API changed as well, requiring patches to
seafile-server.
Adds @cotequeiroz Eneas U de Queiroz as maintainer.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
oniguruma is a regular expression library for different character
encodings.
It is a dependency of current version of libevhtp, and is currently only
producing a static library, not generating an installable package.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
Added a python3 variant, and removed python-cryptography, and pyjwt from
the dependencies. They are required only to run one test, that is not
even being installed.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
This adds the ability to patch setuptools (and pip), and adds 3
reproducibility patches from Debian[1].
(003-PKG-INFO-output-reproducible.patch addresses the issue identified
in #9039.)
The patching is not perfect, in that the patches are applied to
setuptools and pip after they have been installed, since they are
installed from wheels which are already "precompiled".
Also, patching for the host install cannot be updated in place, for
example if a patch is added or removed.
[1]: https://sources.debian.org/patches/python-setuptools/40.8.0-1/
Signed-off-by: Jeffery To <jeffery.to@gmail.com>