The crude loop I wrote to come up with this changeset:
find -L package/feeds/packages/ -name patches | \
sed 's/patches$/refresh/' | sort | xargs make
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Refreshed patches.
Dropped 'patches-setuptools/004-site-patch.patch'
Does not apply anymore. Setuptools has removed site.py support:
https://github.com/pypa/setuptools/issues/2165
If this is still needed, we may need to re-think it's implementation.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This lets the Python build process set _PYTHON_HOST_PLATFORM instead of
forcing an explicit value.
Also:
* Save the target _PYTHON_HOST_PLATFORM value during Build/InstallDev
for use when building target Python packages (in python3-package.mk).
* Use the (mostly) default PYTHON_FOR_BUILD value, instead patch
configure to remove the platform triplet from the sysconfigdata file
name.
* Remove the "CROSS_COMPILE=yes" make variable (there is no indication
that this variable is necessary).
* Force host pip to build packages from source instead of downloading
binary wheels.
Previously, host pip can download universal (platform-independent)
wheels but not platform-specific wheels, because of the custom
_PYTHON_HOST_PLATFORM value. (Packages that do not have universal
wheels would be compiled from source.)
With a correct _PYTHON_HOST_PLATFORM, host pip can install
platform-specific wheels as well. However, the pre-built shared object
(.so) files in these wheels will have the host's platform triplet in
their file names. When target Python packages are built (using the
target's _PYTHON_HOST_PLATFORM), Python will not use these shared
object files.
By forcing host pip to build packages from source, the built shared
object files will not have the platform triplet in their file names.
(Host Python has been patched to remove the platform triplet from file
names.) This allows these packages to be used when building target
Python packages.
(The net effect of this complete change is that platform-dependent
packages will continue to be compiled from source, while
platform-independent packages will now also be compiled from source.)
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>
- Update setuptools to 40.8.0
- Update pip to 19.0.3
- Refreshed patches
- Removed 4 patches (2 of them was included in 3.7.3 and other two are
included in this release)
Makefile python3:
- Move PKG_MAINTAINER above PKG_LICENSE
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Re-worked patch `003-do-not-run-distutils-tests.patch`
to reduce patch-size.
Removed `011-fix-ncursesw-definition-colisions.patch`
it is fixed upstream.
Refreshed with `make package/python3/refresh`
Resetting PKG_RELEASE to 1.
This variable was never used for pip3 & setuptools, since
VERSION is specified in the package definitions.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
I admit this may be be a bit aggressive, but the lang
folder is getting cluttered/filled up with Python, PHP, Perl,
Ruby, etc. packages.
Makes sense to try to group them into per-lang folders.
I took the Pythons.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Ilya Lipnitskiy