Seem pip comes bundled with some Python libs.
Some more work will be needed to split them out of pip.
For now, some Windows executables are safe to remove.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Thanks to Xuefer Tinys <xuefer@gmail.com> for reporting this.
Case is:
opkg install python-setuptools - works fine
opkg install python-pip - reports conflicts for
files easy_install.pth & site.py
So the solution is to add some preinst script that backs up those files
on 'opkg install python-pip' and moves them back on 'opkg remove python-pip'.
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>
PKG_NAME should be the name of the actual OpenWRT package, and not
the name of the original package name.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Should be included by Python packages if they want to run
Python-package-specific build rules.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
python-mini does not exist anymore
For now we'll just fix the build, and we'll do a bit more smart
packaging later.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
After a few discussions with the guys working on OpenVSwitch
they've recommended we use the EXTRA_CFLAGS env var for setting
flags for the kernel module.
They've updated the trunk with a patch to accomodate that.
That patch is also in this commit, and replaces a patch that I proposed.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
When OVS detects a kernel version >= 3.12 it does not build
it's own vxlan module and tries to use the kernel's, when building
the OVS kernel module.
I also pushed a patch to the OpenWRT trunk to add a +kmod-vxlan package.
This will add the kernel's vxlan.ko kernel module if it exists.
So, for kernel >= 3.12, this package should exist and be installed
when installing OVS.
Tested on OpenWRT trunk with kernel 3.14.18.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems that while fixing the build for GCC 4.9
I broke the build for GCC 4.8, because that KCFLAG I added
causes a build error (since it's not recognized).
The fix is to add KCFLAG only when GCC 4.9 is used.
OpenVSwitch now builds successfully with GCC 4.8 and 4.9.
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>
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>
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 python3 files which increases fw size.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Requires python package.
Required by other openvswitch subpackages (like openvswitch-python).
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>
Alexandru Ardelean