JSON Web Token implementation in Python.
This package is a direct dependency of python-requests-oauthlib, a
dependency of seafile-seahub.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
A generic, spec-compliant, thorough implementation of the OAuth
request-signing logic.
This package is a direct dependency of python-requests-oauthlib, a
dependency of seafile-seahub.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
OAuthlib authentication support for Requests.
This package is a direct dependency of seafile-seahub.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
Python package for providing Mozilla's CA Bundle.
This package is a direct dependency of python-requests, a dependency of
seafile-seahub.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
Transparently use webpack with django.
This package is a direct dependency of seafile-seahub.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
Modified Django FileResponse that adds Content-Range headers.
This package is a direct dependency of django-simple-captcha, a
dependency of seafile-seahub.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
A very simple, yet powerful, Django captcha application.
This package is a direct dependency of seafile-seahub.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
A set of high-level abstractions for Django forms.
This package is a direct dependency of seafile-seahub.
Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>
This was copied over from python-packages, when support for installing
packages host-side (via pip) was added.
Based on the discussion on this commit:
612c53fc6c
it was mentioned that removing this may add more benefit in terms of
reducing build time, because packages won't get reinstalled every time.
I'm not entirely sure about any potential side-effects of this, but it's
worth trying it out.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.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>
Following a discussion on bugs.python.org:
* https://bugs.python.org/issue29708
* https://bugs.python.org/msg313384
It seems that setting a fixed value to PYTHONHASHSEED guarantees that
the bytecodes are generated consistently/in a reproducible manner.
Hopefully, this is the last bit to make Python3 build reproducible.
Tested this locally on a few files [that were not reproducible without
this change].
The PYTHONHASHSEED is only assigned to the host Python/Python3 during
compilation of byte-codes [from python source].
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
There have been some new dependencies added in recent versions of
Twisted (mostly internal classes that have been spun out into their own
libraries):
* constantly (#5453), since 16.5.0
* incremental (#5454), since 16.5.0
* Automat (#5456), since 17.1.0
* hyperlink (#5455) since 17.5.0
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
For python `src` packages we should clear out the DEPENDS
to prevent recursive deps from happening.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This is a new requirement for the Twisted package.
From the readme:
Automat is a library for concise, idiomatic Python expression of
finite-state automata (particularly deterministic finite-state
transducers).
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This is a new requirement for the Twisted package.
From the readme:
Hyperlink provides a pure-Python implementation of immutable URLs. Based
on RFC 3986 and 3987, the Hyperlink URL makes working with both URIs and
IRIs easy.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This is a new requirement for the Twisted package.
From the readme:
Incremental is a small library that versions your Python projects.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This is a new requirement for the Twisted package.
From the readme:
A library that provides symbolic constant support. It includes
collections and constants with text, numeric, and bit flag values.
Originally twisted.python.constants from the Twisted project.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
python3 variant
Renaming the package is needed to allow for a Python 3 variant
(python3-zope-interface). Packages that depend on this (only twisted)
also have their dependencies adjusted.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This guarantees for the package feeds that
the mk files will always be available for all packages.
Will need to see about external-feed Python packages
a bit later.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The only difference just a parameter for Python3
[ -b to compile bytecodes in legacy mode ].
No need to keep 2 almost identical files now
that they're exported.
I'm a bit scared of that param, since it may get
removed at some point.
But let's see until then.
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>
Build depends refer to source package names, not binary package names.
In many cases, PKG_BUILD_DEPENDS simply duplicated runtime dependencies of
a source package's binary packages; as the corresponding source packages
are implicitly added as bulid dependencies, PKG_BUILD_DEPENDS can simply be
dropped in these cases. In the other cases, *_BUILD_DEPENDS is fixed to
refer to the correct source package name.
Dependency of mysql-server is adjusted from libncursesw to libncurses
(as libncursesw is a virtual package provided by libncurses), so the build
dependency on ncurses is emitted unconditionally.
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>
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>
Fixes:
https://github.com/openwrt/packages/issues/5318
Not sure how this worked before.
The host python-cffi needs a libffi installed on the host side.
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>
fix Makefile chmod (644)
replace MD5SUM with HASH
add PKG_MIRROR_HASH when PKG_SOURCE_PROTO:=git
(PKG_SOURCE_PROTO:=svn tarballs are not reproducible for now)
Signed-off-by: Etienne Champetier <champetier.etienne@gmail.com>
This build script supports both Python 2.x (python-evdev) and 3.x (python3-evdev)
From the README:
This package provides bindings to the generic input event interface in Linux.
The evdev interface serves the purpose of passing events generated in the kernel
directly to userspace through character devices that are typically located in /dev/input/.
This package also comes with bindings to uinput, the userspace input subsystem.
Uinput allows userspace programs to create and handle input devices that can inject
events directly into the input subsystem.
Signed-off-by: Paulo Costa <me@paulo.costa.nom.br>
Unfortunately python-cryptography (after version 2.0.<something>)
decided to replace `pyasn1` with `asn1crypto`.
Unfortunately `pyasn1` is needed for another package,
so it can't be dropped just yet.
Not sure if dropping it would bother people.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
And drop the host-build.
This was needed, simply to cross-build the package.
I'm not a religious man, but "praise the lord" for
dropping this :D
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>
Depending on execution order the `python-package-install.sh`
script would return a non-zero err code.
So, this enforces that all commands in the script
don't fail (via the `set -e` directive).
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
auto-endian auf UTF-16 doesn't work with all drivers, some fail to
interpret the byte-order-marking. Hence explicitely use UTF16BE on
big-endian systems and UTF16LE otherwise.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Flask is a microframework for Python based on Werkzeug, Jinja 2 and
good intentions. And before you ask: It.s BSD licensed!
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Python3 variant was working fine.
Also add add PACKAGE_python-pyodbc conditional depend for python packages
Otherwise, both Python & Python3 interpreters get built,
even tho only one variant is selected.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
And depend on python-light only if python-lxml is selected.
Same thing for python3-lxml.
Otherwise, this builds both Python & Python3 intepreters.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Similar to LEDE/OpenWrt's Build/Compile/Default rule,
and other similarities like this.
This should allow Python packages to define
PyBuild/Compile rules to do specific stuff per
package.
The advantage of using these (over just overriding
Build/Compile) is the VARIANT mechanism that is
in place to support packaging both for Python & Python3.
So, PyBuild/Compile will get picked up for the Python
variant build, and Py3Build/Compile will get picked
up for the Python3 variant build.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Fixes: https://github.com/openwrt/packages/issues/4548
When running parallel jobs, there are chances
that the Build/InstallDev rule may run before
the Host/Install rule and fail the build.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
If you build python/python3 and later decide to build
python(3)-setuptools and/or python(3)-pip, the build won't
re-run without adding `CONFIG_PACKAGE_python(3)-setuptools`
and `CONFIG_PACKAGE_python(3)-pip`.
Seems to resolve issue:
https://github.com/openwrt/packages/issues/4529
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems it's called underlinking that's happening only
on Ubuntu 12.04 with libressl (that comes from LEDE's
tools folder).
Link here:
https://ubuntuforums.org/showthread.php?t=1870586
I'm still reading about this a bit.
Since I don't really get it.
But applying that fix (as in the link) seems to fix compiling
on Ubuntu 12.04, and tried also on 16.04 (to make sure).
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The Build/InstallDev rule is activated only for target builds.
But if someone needs only the host Python, then
these files need to be installed in this phase, and not Build/InstallDev
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
OVS has PKG_BUILD_DEPENDS:=python-six/host as dep.
But that doesn't seem to work, since the PKG_NAME:=six
So, this change renames the PKG_NAME to python-six, to
make it clear it's Python package.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
If there is only Python bytecodes, then
the __init__.py script will be concatenated, and
the __init__.pyc as well.
This is becase this bit `path = os.path.join(path, '__init__'+extension)`
is iterated twice.
This is a bug in Python3, also because we ship bytecodes
instead of source code [ with Python & Python3 ].
Python is not affected.
Reported-by: Mirko Vogt <mirko@nanl.de>
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This package requires libxml2 & libxslt to be built, has some
C code so it's not installable via pip.
It needs cross-compilation.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This is in essence fixes pip3.
That means pip3 will ship without Python byte-codes
for a while, until I'll find a better way to fix it.
I couldn't think of a not-very hack-ish way of doing it.
The only draw-back of this, will be that pip3 will run
a bit slower ; but that should be ok for a while.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
python3-pip & python3-setuptools have slightly
different installation mechanisms.
We need to remove the __pycache__ folders.
Seems they're generated.
This also reduces the size of the python3-pip &
python3-setuptools packages.
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>
Well, they're not yet compiled, but in the next commit
they should be.
People have been complaining [citation needed] to me
via email or via Github that Python's performance is crap
because it packages sources directly and they're not compiled.
And Python has to compile the sources on each run, and
on-the-fly.
Allowing compilation caching is also a no-no, because
I'll get complaints that the flash storage fills up
whenever a Python app runs.
So, to give the user a choice, the new de-facto packaging
for Python packages will be:
* ship compiled + [ preferably ] optimized files
* package sources separately
The problem is that this doubles the number of packages
in LEDE/OpenWrt, but build-times should not suffer a big
hit, since the compilation is done once, and the
install phase should not be too intensive.
Oh, and people don't need ship source packages if
they don't want to.
To do that, a packager needs to just call
`$(eval $(call BuildPackage,python-<package>-src))`
The `python-` prefix is important.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Well, this slipped by for some time.
This should make the Python core packages even more lighter.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
It's not 100% aligned with the ncurses' definition.
Reported-by: Arturo Rinaldi <arturo@arduino.org>
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
LEDE now provides libncursesw by default [even for libncurses].
No need to keep this patch around.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Python comes with it's own builtin libffi lib, which
seems easier to use for the host build, than trying
to use the one from the package feeds.
Also, dropping `005-fix-libffi-x86-64-configure.patch`
Not needed anymore.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
I just found out that, that the BUILD_VARIANT var
is not set for the host build, so technically this code
would never get used.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
As both LEDE and OpenWrt have STAGING_DIR_HOSTPKG now, we can start to rely
on it. See 73b7f55424 for more information on
STAGING_DIR_HOSTPKG.
STAGING_DIR_HOSTPKG won't actually be changed before the first LEDE release
(it is equivalent to $(STAGING_DIR)/host), so this simple search/replace
cleanup is safe to apply. Doing this cleanup now will be useful for the
Gluon project (an OpenWrt/LEDE based firmware framework) for experimenting
with modifying STAGING_DIR_HOSTPKG before doing this in the LEDE upstream.
Also fixes a typo in the dbus Makefile ("STAGIND_DIR").
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
STAGING_DIR_HOSTPKG is now defined in both OpenWrt and LEDE, so we can
start to rely on it.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Fixes: https://github.com/openwrt/packages/issues/3767
Since commit:
f6e6341d89
libressl is built on the host-side.
Python picks it up [ via the openssl/* headers ] and assumes
it has SSL libs.
Compiling works fine, linking fails.
Doesn't look like it's because:
2fd5ce9488
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Most python packages use the same build rules & vars.
So, adding them in python-package.mk.
Also, preparing for using VARIANTs for python/python3 packages.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
PYTHON_FOR_BUILD is used to build the target python.
Nomally Python scripts detect fine the Python host interpreter
to use for building the Python target interpreter.
But, let's not leave it up to chance anymore.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
And apparently `--with-system-ffi` does not take any arguments.
But it's only in Python 3.6 that a check was added for that.
After checking, Python 2.7 does not take any args either
for `--with-system-ffi` ; so, remove it [for the case when this
change may get backported].
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Move the python-host.mk and python-package.mk includes after the definition of
common package variables. This is required to ensure that PKG_UNPACK is not set
to to the dummy "true" command which happens if PKG_SOURCE is not yet set.
Fixes the following error observed while attempting to build Python on a recent
LEDE version:
make[2]: Entering directory '.../lang/python'
true
[ ! -d ./src/ ] || cp -fpR ./src/* .../Python-2.7.12
Applying ./patches/001-enable-zlib.patch using plaintext:
can't find file to patch at input line 14
Perhaps you used the wrong -p or --strip option?
[...]
Patch failed! Please fix ./patches/001-enable-zlib.patch!
Makefile:242: recipe for target '.../Python-2.7.12/.prepared_...' failed
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
--sysconfigdir and --sbindir are obtained from --prefix
and --exec-prefix, so no need to have them explicitly
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Allows for more granularity with respect to python-host.mk
and python-package.mk inclusions.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
So that it can be included twice.
python-package.mk include python-host.mk, but at some point
in time python-host.mk is not exported to staging_dir yet.
So, to have in python's Makefile, we need to include it
in the Makefile, and to prevent double inclusion (if
python-host.mk is exported from a previous build), the
include guard is added.
Also, moved the includes after some vars were set.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Currently, the python-host.mk framework relies on HOST_BUILD_PREFIX to
refer to the $(STAGING_DIR)/host directory but using the HOST_BUILD_PREFIX
variable requires the use of include/host-build.mk which in turn includes
python-host.mk, leading to target redefinition errors.
In order to provide a global, uniform way to refer to the host staging
directory, LEDE introduced a new variable STAGING_DIR_HOSTPKG which points
to $(STAGING_DIR)/host for now with the purpose of eventually being able to
relocate that directory in the future.
This commit changes python-host.mk to ...
- stop including include/host-build.mk (revert of #3423)
- replace usages of $(HOST_BUILD_PREFIX) with $(STAGING_DIR_HOSTPKG)
- warn and fallback to $(STAGING_DIR)/host if STAGING_DIR_HOSTPKG is
unavailable
The fallback code will ensure that the python host build infrastructure
continues to work properly on older OpenWrt and LEDE versions until the
STAGING_DIR_HOSTPKG is fully settled in and can be removed some time
in the future.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Also, override all prefix args in the HOST_CONFIGURE_ARGS
so that this works fine on CC/15.05.
There are some changes in core regarding package builds that
require this.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
It seems that this can become an issue.
Found when building python3-setuptools from packages/trunk
in openwrt/15.05.
python3-setuptools is not in packages/for-15.05
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The sets host Python's prefix and exec-prefix to the same value
($(STAGING_DIR)/host for packages, as currently defined in
include/host-build.mk), which avoids the case where pyconfig.h is
not in the same location as Python's other header files (see
https://bugs.python.org/issue896330).
This also removes some cross compilation workarounds
(_python_sysroot/prefix/exec_prefix, disabling byte-compilation,
__PYVENV_LAUNCHER__) that are not necessary when compiling packages
for host.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
AFAIK sysroot is combined with prefix/exec_prefix, so sysroot shouldn't
include "/usr". (cf. the HostPython function in older versions of
python-package.mk)
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This adds code to make it easier to build third-party python
modules such as ones from PyPi.
Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
Seems those pkgconfig file paths were revealed to be incorrect
after doing a full clean build.
And I only had to inspiration to do one after doing the initial PR.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
And split python-dev and python-lib2to3 packages.
Seems for python3 this was done, so we'll sync here.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
That means basically moving the host Python from $(STAGING_DIR_HOST)
to $(STAGING_DIR_HOST)/usr and making the PYTHONPATH var
as an argument.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Some python packages (e.g. cffi) compile one or more shared libraries
as part of their setup process. When these packages are setup
dependencies of other packages (e.g. cryptography), these packages (and
their shared libraries) will need to be loaded on the host system.
This adds a makefile, similar to python-package.mk, to simplify
installing python packages on the host.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
Since 94f87dc1, host build of Python depends on expat installed in host
staging directory. However, pyexpat extension fails to build if expat
was not built and installed to staging dir before - adding host build
dependency should fix this.
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
Build depends must refer to the source package name, not the binary one,
therefore we need to use `bzip2` in order to enforce a build of libbz2.so.
Also make the host python build depend on the bzip2 host build in order to
ensure that host python is built with bzip2 support. We don't need a build
dependency for the target python as this already depends on +libbz2 through
python-light. That package dependency in turn implies a build dependency.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
Patch removing multiarch paths from build should be applied only when
Python is built for target, but not for host. When the paths are removed
during host build, host python throws some ugly errors when importing
some hashlib modules. Also it reports that modules crypt and nis failed
to build (tested on Ubuntu 14.04 host).
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
python-package.mk now defines (extends) CONFIGURE_ARGS that are
adjusting PREFIX and EXEC_PREFIX in distutils.sysconfig during
compilation. These variables are sometimes used by autotools to detect
path to Python header files. Adding these variables to python-package.mk
fixes compilation of legacy autotools-configured packages that already
include python-package.mk and do not overwrite CONFIGURE_ARGS.
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
Cc: Alexandru Ardelean <ardeleanalex@gmail.com>
Rule of thumb is: any Python file that is greater than 100kb
(or adds a dependency with which it adds more than 100 kb)
should be a pretty useful/commonly used lib to stay in `python-light`.
An example, is the Python IO lib, which summarized (Python source +
binary module) is over 200kb.
Also moved some files that should have been put into previously
existing packages before, and re-organized the packages a bit.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems removing the PyPackage rule and/or adding dummy install rule
causes some issues inside the build-system, where the libpython2.7.so.1.0
is not seen by packages that depend on python.
Even though that libpython2.7.so.1.0 file is installed properly by `python-base`.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Calling `PyPackage` will install some default install rules for
python packages that are not required for the `python` package specifically
are not required.
That will lead to some conflicts with `python-light` because the
`/usr/lib/python2.7/site-packages` folder (+contents) will be
available in both packages.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
When cross-compiling, we do not need to add runtime lib dirs.
Also, the cross compilers that are used on OpenWRT do not support
the '-R' option, which causes build failures.
These build failures existed before, but were not noticed,
because it fails only on some setups.
This is because Python's `setup.py` does a lot of voo-doo
automagic that needs handling for some cross-compilation cases.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Packetize some Python modules to reduce size of the overall Python package.
Basically, a new package is introduced, call `python-light`,
and everything that's extra (or big) is put in other packages.
The `python` package becomes a metapackage that installs `python-light`
along with the rest of the packages.
Base work started by Jan Čermák.
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
When distutils are copying scripts, path to Python interpreter is adjusted.
This does not work well in OpenWrt buildroot, because the path is adjusted
to absolute path to host Python then. This patch simply disables the
adjusting of the path.
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
Try to reduce the amount of change in this patch, since it removes
a lot of stuff, when we could just 'ifdef' that stuff out, with 2 lines.
The buildroot project does something similar like this:
http://git.buildroot.net/buildroot/tree/package/python/005-pyc-pyo-conditional.patch
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This module is not necessary in OpenWrt because the functionality it
provides (i.e. installation of setuptools and PIP) is ensured by
python-pip and python-setuptools packages.
See: https://docs.python.org/2.7/library/ensurepip.html
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
Seems when cross compiling on x86_64 Debian (most likely Ubuntu too)
the host's paths will be added too causing build failures for some extensions.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Python packs some pip installation script during the build,
which looks like a better idea to use for the python-pip
and/or python-setuptools packages.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
That would allow for files (in filespecs) to be indented.
As it is now, the files need to be added at the begginning of the line.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems that using += adds a space in the PYTHONPATH.
Could be some other error, but at least this way
it's sure to not leave any spaces.
Thanks @Xuefer.
Signed-off-by: Xuefer Tinys <xuefer@gmail.com>
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Some symbols are not found (tgetnum and BC).
Looks like the termcap lib, which should be in libncurses(w)
but maybe some build param would be required.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Redefine python-full as all-pages-minus-a-few-that-don't make sense.
Remove all other packages.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This fix is quite critical since it fixes copying the libpython shared lib.
The previous source folder we've used is ok, it has the shared lib,
but libpython2.7.so is not a symlink of libpython2.7.so.1.0, but
rather a copy of it.
Which means that libpython2.7.so takes twice as much space
on the target's flash.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Python's build scripts prefer ncursesw, and if it is detected
it will be used.
The problem will occur when linking, since ncursesw libs may not be
installed if not added as deps, but the sources will be compiled
against ncursesw.
Reference from Python's HISTORY file:
Patch #1428494: Prefer linking against ncursesw over ncurses library.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This mostly helps to avoid confusion when modules are cross-compiled.
Otherwise build folders are named with the host's platform name.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This will reduce the bloat when users will want to compile in their
Python C extensions.
There will be a initial bloat (several kb) if just Python
is installed, but that will be compensated when users will add more
C extensions.
During the build we also have to add Python's PKG_BUILD_DIR
so that the shared lib is found when compiling Python's
built-in C extensions.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The target's PYTHON_INC_DIR should take precedence over the host's
include dir when cross-compiling.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems that the Python C extensions were being
(or at least trying to be) build using '/usr/include' as the first
include folder.
Seems this issue was already fixed on MacOS X and now we've extended
it for our case.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems that this allows some goofs, because some files
silently do not get copied and the build succeeds, even though
it shouldn't.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems that if you add a package folder this would also
include the compiled python files which increases fw size.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
According to PEP394 (http://legacy.python.org/dev/peps/pep-0394/)
the 'python' command should refer to 'python2'.
In our case, this means we should reboot the old python package.
We could rename the package name to python2, but that would
just complicate things a bit with other packages, and
since we're doing this reboot, such a complication would be
unnecessary.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Some notes:
- Python 3 (at least version 3.4) is pretty cross-compiler-friendly,
so a lot of patches were thrown away.
- Arguments below were moved to ./files/config.site file, and disabled
ac_cv_have_chflags=no \
ac_cv_have_lchflags=no \
ac_cv_py_format_size_t=no \
ac_cv_have_long_long_format=yes \
ac_cv_buggy_getaddrinfo=no \
- --without-ensurepip added, because the build wants to ensure that
it works; that's a good idea, but for now, it requires special
setup, and we can do that later
- --without-pymalloc added, becase in Python 3, modules are suffixed
with m; e.g. so some paths are python3.4m instead of python3.4
all this is detailed here:
http://legacy.python.org/dev/peps/pep-3149/
Maybe it will be a good idea to re-add this back
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Make python-mini the top-level and default Python package.
Make the other packages subpackages of the top-level python package.
Make old python package the python-full package.
Note: at this point, this package can be split/renamed to
python-legacy should anyone need Python 2. After this commit
it's going to be Python 3 all the way.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
