Now that security features are set globally, having the
FORTIFY_SOURCE option set in Makefile breaks the build when
CONFIG_PKG_FORTIFY_SOURCE_{1,2} is enabled as well.
arm-openwrt-linux-uclibcgnueabi-gcc -Wall -Werror -Wuninitialized -Wundef -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -Os -pipe -march=armv6k -mtune=mpcore -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -mfloat-abi=soft -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -Wp,-MMD,./.mmc.o.d,-MT,mmc.o -c mmc.c -o mmc.o
<command-line>:0:0: error: "_FORTIFY_SOURCE" redefined [-Werror]
<command-line>:0:0: note: this is the location of the previous definition
cc1: all warnings being treated as errors
Makefile:35: recipe for target 'mmc.o' failed
Fix this by removing -D_FORTIFY_SOURCE=2 from Makefile.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
Found on an all-y build with SSP enabled:
Package avahi-autoipd is missing dependencies for the following libraries:
libssp.so.0
Adding the missing dependency to address that.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Some notes about the 'encodings' module, which is about 1.7 MB.
Unfortunately that one cannot be moved into the 'python3-codecs'
package, because Python tries to load up all available encodings
at startup.
Some efforts to add a dummy folder/python file have failed so far,
since there's a C code (Python/codecs.c) that tries to evaluate that
all encodings (in the encodings folder/module) are valid.
Basically the encodings module is a repository of encodings,
and it seemst there are quite a few of them.
Maybe a request to upstream Python would work for this, to
make encodings a bit more decoupled from the interpreter.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Based on the idea that 'what-works-on-python-should-work-on-python3'
because they share the same trunk, these patches have been copied over
from the python package.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This patch add a new package, git-http, that contains all
http related commands (and ftp as extra). All http/ftp
depends on libcurl. Even without SSL suport in libcurl,
git compiles and it returns an informative error only
at runtime.
The use of symlinks now are trigged using NO_INSTALL_HARDLINKS env
and not based only on Makefile patch.
imap-send was kept builtin and idependent of curl (just as it was
before)
Template files, which are not necessary, where removed.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Previously, ./configure was running checking local system and not
OpenWRT target. This would avoid any configure test about OpenWRT
libraries.
With a patch in configure, non cross-compiling-friend test are
ignored and Makefile can use default configure.
As side effect, git commands are now at /usr/lib/git-core and not
/usr/libexec/git-core.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Although this version is marked 'unstable' by upstream, it's very
robust and stable. So give it a broader audience for testing.
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
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>
Update to r182-experimental (071481e626) broke YUV
capture mode in input_uvc. This patch fixes it.
Tested on ar71xx with Logitech C170
Signed-off-by: Mantas Pucka <mantas@8devices.com>
input_uvc was broken with new kernel update
patch source: https://github.com/oliv3r/mjpg-streamer
Tested on ar71xx with Logitech C170
Signed-off-by: Mantas Pucka <mantas@8devices.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>