After many failed attempts at upgrading Django to 2.2.6, the solution seems
to be to split a `python-django1` package that works with Python2 and
upgrade `python3-django` to the latest 2.2[.6] LTS release.
This also means that all Python2 Django packages will be stuck & based on
Django 1.11[.24] LTS release. But, it's currently the sanest approach I
could find to be able to perform an upgrade of Django to 2.2, and not break
Seafile.
Upgrading Seafile is also pretty difficult, as their Python3 support is not
yet finished & released. And in the meantime, we want to allow people to
use newer Django versions.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This adds a new (optional) variable, PYPI_SOURCE_NAME, to pypi.mk.
For some PyPi packages (e.g. aiohttp_cors, click, django-compressor),
the name of the package and the source tarball name are slightly
different (usually by capitalisation or hyphen/underscore change).
This new variable is to make this difference explicit. PYPI_NAME is
meant for the "official" package name, whereas PYPI_SOURCE_NAME is meant
for the source tarball name.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This required a bit work to get working, compared to other versions. So,
some things have changed a bit more significantly.
Some highlights:
* there is no longer a pgen executable, seems this is now part of
libpython; let's see what this means for us in the future
* blake2 hash (from OpenSSL) detection needs some fixing; will upstream
added patch 002-fix-blake2-detection.patch
* removed all bpo patches; those should be fixed in upstream
* some needed to be manually re-applied as stuff changed:
- 001-enable-zlib.patch - file changed
- 004-do-not-write-bytes-codes.patch - file changed
- 015-abort-on-failed-modules.patch - variable was renamed
cross_compiling -> CROSS_COMPILING
* 017_lib2to3_fix_pyc_search.patch - the code changed, it does not seem to
have the original problem with respect to file-extension, as there
does not seem to be any special extension logic anymore there
* 006-remove-multi-arch-and-local-paths.patch - dropped patch; I can't
remember the full-details of this issue; it was something with
Debian/Ubuntu's multi-arch stuff; it was probably added maybe due to
some overzealous (on my part) thingy caused by some weird reports,
that I could never solve; let's have this patch dropped and see
* make package/python3/refresh to reduce fuzz for the rest
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This adds pypi.mk, which can be included in Python packages that
download their sources from PyPI, to auto-fill various PKG_* variables
based on the value of PYPI_NAME.
This makefile should be included after $(TOPDIR)/rules.mk but before
$(INCLUDE_DIR)/package.mk (and $(INCLUDE_DIR)/host-build.mk).
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
These patches address issues:
CVE-2019-16056: email.utils.parseaddr mistakenly parse an email
CVE-2019-16935: A reflected XSS in python/Lib/DocXMLRPCServer.py (for
Python 2.7)
CVE-2019-16935 was fixed for python3 in #10109
Links to Python issues:
https://bugs.python.org/issue34155https://bugs.python.org/issue38243
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
- Remove PKG_BUILD_DEPENDS as it is no longer necessary.
- The Python3 is already included in DEPENDS.
- Remove PKG_BUILD_DIR and PKG_UNPACK was for dual Python version.
- Change TITLE and description
- Add source package
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
And splitting the gunicorn[3] binary/executable away from the
python[3]-gunicorn libraries. This was inspired from Debian packaging.
The gunicorn[3] binaries require the new `python[3]-pkg-resources`
libraries to run, which add ~1.1 MB on the [ram]disk when uncompressed.
For the Python2 variant, the `_gaiohttp.py` is dropped as it fails to
compile, so it would likely be unusable anyway:
```
File "/usr/lib/python2.7/site-packages/gunicorn/workers/_gaiohttp.py", line 84
yield from self.wsgi.close()
^
SyntaxError: invalid syntax
```
People around the web recommend this as well:
https://stackoverflow.com/questions/25611140/syntax-error-installing-gunicornhttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803170https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803202
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Some packages just install some Python binaries, that may need their
shebang fixed.
This change adds some utilities to help with that and try to centralize the
sed rules a bit.
It also removes the logic from the `python-package-install.sh` into the
`python-package[3].mk` files. This does 2 things:
1. It minimizes the need for the shell script to know the Python
version 2/3
2. Makes the logic re-usable in packages; especially if the install rules
differ a bit
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This package is required by other packages to run some binaries via
`load_entry_point`.
So, this splits this package away from setuptools.
setuptools is pretty big, akd pkg-resources is also big, but not as big.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
As I remember this worked.
But since `set -e` is set, I am a bit paranoid about it. In the sense that
it may fail if `ver` != 3.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The CONTRIBUTING.md requests an (or multiple) SPDX identifier for GPL
licenses. But a lot of packages did use a different, non-SPDX style with a
"+" at the end instead of "-or-later".
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The package on PyPi is named `mysqlclient`.
This should have been named `python-mysqlclient` from the start.
There is a `mysql` package on PyPi already but that's a different
code/package.
Doing this should avoid any future confusion.
There is no good time to do this rename; at least 19.07 has been branched
already and this can go into the next release [in a year or so].
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This is a feature release including improvement to OIDC and security
enhancements, as well as bugfixes.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* Remove $$$$(pkg-config --static --libs libcrypto libssl) from
HOST_LDFLAGS
Having this leads to an "unknown type name 'u_int'" error on Mac.
Removing it doesn't appear to affect Python's ability to find
buildroot LibreSSL.
* Change -Wl,-rpath=... to -Wl,-rpath,... in HOST_LDFLAGS
The equals sign version is not supported by the Mac linker (appears to
be an GNU extension). The comma version is supported; -rpath and its
argument will be separated by a space when passed to the linker.
* Add ac_cv_header_libintl_h=no to HOST_CONFIGURE_VARS for Mac
Python on Mac doesn't expect to use libintl, but if gettext-full is
compiled for host, it will try, leading to undefined symbol errors
during compilation. This prevents configure from finding libintl.h.
Fixes#7171.
Fixes#9621.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
Alexandru Ardelean
Fabian Lipken
Jeffery To
Josef Schlehofer
Richard Yu
Jan Pavlinec
Eneas U de Queiroz
Rosen Penev
Karel Kočí
Sven Eckelmann