Changed PKG_LICENSE to reflect spdx license tag, and PKG_LICENSE_FILES
to include all lincense-related files applicable to the parts of the
code we are actually using to build and/or distributing. The
Windows-only files, and the python-bundled Tools we're not using have
been left out.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
"python -m compileall" has a default maximum recursion level of 10, i.e.
it will descend up to 10 levels of subdirectories when looking for
source files to compile. This is usually sufficient but there are
packages that include more than 10 levels (botocore,
https://github.com/openwrt/packages/pull/8214#discussion_r270056741).
This adds the "-r" command line option to the call to compileall to
increase the max recursion level (currently set to 20).
This also patches Python 2's compileall.py to add this max recursion
level option. (Python 3's compileall.py already supports this option.)
This also applies some related changes to python-package-install.sh:
* Use the "-delete" option with find instead of exec'ing rm / rmdir. For
the case of removing empty directories (in delete_empty_dirs()), this
has the added benefit of simplifying the code, as the "-delete" option
implies "-depth", and thus find "does the right thing" (removing empty
directories depth-first).
* Remove the backslash in "-name" patterns (for find), as they are not
regular expression but glob patterns.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This installs python{2.7,3.7}-config in $(STAGING_DIR)/usr/bin as part
of Build/InstallDev, to be used by other packages to get build
configuration for target Python.
The treatment for Python 2 and 3 are a bit different:
* For Python 2, python-config is a Python script that is expected to be
run with, and return data for, the installed Python interpreter. This
installs a modified version of this script, to be run using host
Python, and read/return data for target Python.
* Python 3 includes a shell script version of python-config (expected to
be used in cross-compilation scenarios). This simply installs the
script into the right place.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
These patches address issue:
CVE-2019-9636: urlsplit does not handle NFKC normalization
Link to Python issue:
https://bugs.python.org/issue36216
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This changes Build/InstallDev for both Python 2 and 3 to only copy files
from target Python, not from host Python, since InstallDev files are
used for target packages to link to other target packages.
In particular, usr/lib/python{2.7,3.7}/_sysconfigdata.py holds system
configuration data generated at build time, and is different for target
Python and host Python.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This change updates Python to version 2.7.16, which is a bugfix release
in the Python 2.7 series.
This also removes patches back-ported from upstream.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
For a while now, Jeffery has helped quite a lot with Python, and is now
unofficial go-to guy [for problems] with Python packages.
This change adds him as co-maintainer [if he also agrees].
I'm not going away; I'll be still doing the same work for Python.
This change serves to recognize Jeffery in an official way, since he's
already taking on these things. And 2 co-maintainers is better in case one
kicks the bucket [by accident].
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Thanks to fix 200a5a2eec all base packages
now contain all binaries that are generated as part of python
installation. That causes collision between those packages with package
managers that consider this such as Turris updater-ng. This is also just
wrong. Those binaries were not included and should not be after
mentioned fix as well.
This just adds empty install definition. The idea is to override the
default one that is otherwise used.
Signed-off-by: Karel Kočí <karel.koci@nic.cz>
This patch addresses issue:
[ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
Link to Python issue:
https://bugs.python.org/issue35746
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This extends the Python[3] shebang fixup to all packages.
Only Python scripts in `/usr/bin` will be handled at the moment. Later it
may make sense to also cover executables in `/bin`, though typically Python
executables shouldn't be placed there.
Previously the shebang handling was only done for python[3]-pip &
python[3]-setuptools.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
`setuptools` & `pip` whl files were selected via wildcards, because it was
easier in the beginning.
Also, initially there weren't any PYTHON{3}_{SETUTPTOOLS/PIP}_VERSION
variables. But now since these vars exist, it makes sense to use them,
because we can catch easier (at build) time if Python/Python3 bump these
versions.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Add -rpath linker option to host build, pointing to staging/hostpkh/lib.
It's needed to find the correct host libs during runtime, without it the
hosts libs may be used instaead, causing failures.
Signed-off-by: Jan Kardell <jan.kardell@telliq.com>
This also updates pip and setuptools.
With this occasion, they also get PKG_RELEASEs of their own.
Dropped patch 011-remove-setupterm-definition.patch
Manually re-applied 005-fix-bluetooth-support.patch
Ran make package/python/refresh to refresh other patches.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
zlib is now a host tool and the zlib/host package was removed. this
dependency is not needed any more as there will always be a zlib host
library.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Report https://github.com/openwrt/packages/issues/5638
It was mentioned that this causes build failures on Mac OS X.
The default behavior [in the setup.py script] is to check whether
`--with-system-ffi` is present in the CONFIG_ARGS env var.
However that back-fires a bit when `--with-system-ffi=no`, because the
condition `not '--with-system-ffi' in sysconfig.get_config_var("CONFIG_ARGS")`
evaluates to true.
This is a small bug in the `setup.py` script, but it looks like the
easiest/cleanest way to address it on our end is to just remove it entirely
from the HOST_CONFIGURE_ARGS.
At least that's how it looks like when testing on a Linux machine.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This change was introduced in commit 1c54e2b0fb to address build
issues on Ubuntu 12.04.
However it was reported to cause issues on Mac OS X.
Report: https://github.com/openwrt/packages/issues/5310
It was also reported that removing this on MacOS X fixes the issue.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Since `lang/python` is it's own folder of Python packages
(for both Python 2 & 3), and these build rules are needed
in a lot of packages [especially Python packages],
putting them here makes sense architecturally,
to be shared.
This also helps get rid of the `include_mk` construct
which relies on OpenWrt core to provide, and seems
like a broken design idea that has persisted for a while.
Reason is: it requires that Python 2/3 be built to provide
these mk files for other Python packages,
which seems like a bad idea.
Long-term, there could be an issue where some other feeds
would require these mk files [e.g. telephony] for
some Python packages.
We'll see how we handle this a bit later.
For now we limit this to this feed.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The .mk snippets are not really usable at the moment, as they cannot be
considered for metadata collection (package DUMP) when included through
include_mk. Python packages do not use include_mk anymore for this reason,
so the install commands can be removed as well.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
The Modules/getbuildinfo.c allows the use of DATE and TIME
macros to be defined via CFLAGS.
These vars, control the build date & time when the
interpreter is opened, and can be read via the
`platform._sys_version()` function.
So, a conversion from SOURCE_DATE_EPOCH to DATE & TIME
is required at build-time.
This is especially needed for `platform._sys_version()`
to work.
The installation of pip seems to rely on this.
The logic has been adapted from:
https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Makefile
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This reverts commits 4333d1dcbf and
074d2863be, making Python packages
discoverable again by pkg_resources.
Fixes#5361.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This reverts commit 3c6d14021e.
( which is a revert of commit c764f77dc1 )
The initiall commit ( c764f77dc1 )
was reverted, becase zlib did not have a host-build.
Now it does:
cbe71649bc
So, now it should be good to put this in.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
See:
https://github.com/openwrt/packages/issues/5278
This should make Python & Python3 packages reproducible
when building.
In my local tests, I got the same sha256 for a sample
.pyc file, so likely this is the solution that should address
this.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This reverts commit c764f77dc1.
The commit caused warnings to be displayed at make defconfig etc.
WARNING: Makefile 'package/feeds/packages/python/python/Makefile'
has a host build dependency on 'zlib/host' but
'package/libs/zlib/Makefile' does not implement a 'host' build type
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
This should fix the zlibmodule build on the host side.
Usually, if zlib is not found, Python/Python3 builds fine
without it, but there are some cases where the Python/Python3
interpreter on the host-side requires zlib to run.
At the moment, zlib does not have a host-build.
This should be available when this PR gets merged:
https://github.com/lede-project/source/pull/1329
[ or a similar one that contains host-build support for zlib ].
In the meantime, this change can go into Python/Python3.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
It was reported via
https://github.com/openwrt/packages/pull/5122#issuecomment-347395472
that if bluez-libs is selected as an installable package,
then the error below will show up:
```
* satisfy_dependencies_for: Cannot satisfy the following dependencies for python-light:
* bluez-libs *
* opkg_install_cmd: Cannot install package python-light.
```
This looks like a limitation in the design of package deps,
and maybe a misuse of conditional deps (i.e. PACKAGE_bluez-libs:bluez-libs).
So, to fix this, an idea we're adding an extra symbol
that enfoces installation of bluez-libs if selected.
We also need to add a way to disable bluetooth build
if PYTHON(3)_BLUETOOTH_SUPPORT is de-selected.
Otherwise, bluetooth is installed and the socket
module is broken due to linker errors.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This should improve build time if you only want to
build Python3 (and not Python).
Because python-pip-conf was part of the python package,
the whole python package (host + target) would get built if Python3
would need to get built.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This should hopefully fix the Python3 build on buildbot.
For a while I assumed it may be a build-bot issue, but
then looking through the packages repo [and finding
the bluez package] it looks like, if you try
to build all packages, Python3 detects the bluetooth
headers installed by bluez.
It looks like Python's bluetooth support was somewhat
broken ; it was not detecting the <bluetooth/bluetooth.h>
header, so a backport from Python3 to Python fixed that.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
That way some python packages can choose
to keep their egg-info dirs, if they want to, or they're needed.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Not sure how it can happen that the files are not
installed via the host build.
Maybe some SDK-like build.
Let's make sure they are installed via InstallDev rule too.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The host pip install should have the host's CFLAGS, LDFLAGS, etc
available.
And not the target's flags.
Otherwise, weird things can happen when installing
packages (host-side) that need to build C code.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
To install Python packages host side, that
may be needed for a build.
The intent, is to try to reduce host-side Python
packages being installed via LEDE/OpenWrt build system.
Because those seem like a pain to maintain.
The idea is adapted from Yousong's `python-packages`
package.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
