Tcpreplay is a suite of free Open Source utilities for editing and
replaying previously captured network traffic. Originally designed
to replay malicious traffic patterns to Intrusion Detection/Prevention
Systems, it has seen many evolutions including
capabilities to replay to web servers.
Pretty useful for testing stuff too.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Otherwise it will pull all compression libraries to install
(on newly configured targets) when maybe 1 or 2 are needed.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
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>
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>
python-setuptools releases more often than my preference.
Every once in a while I sync up with the latest released.
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>
Warning is:
#warning redirecting incorrect #include <sys/poll.h> to <poll.
Not a big issue.
But it can be annoying when building with -Werror set.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
I guess these were left since some initial OVS package versions.
They were fine up until recently.
Some of the build artifacts got a little messy and thus the
OpenWRT OVS package got a little messy.
This cleans it up a bit.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Probably related to -fstack-protector being used.
Got the idea from:
http://ubuntuforums.org/showthread.php?t=352642&p=10100263#post10100263
Regarding the missing __stack_check_fail_local, using gcc as the linker instead of ld fixes the issue without disabling stack protection as with -fno-stack-protector.
Fixes linker errs on some targets:
objects/prod/dnssd_clientstub.c.so.o: In function `handle_resolve_response':
dnssd_clientstub.c:(.text+0x395): undefined reference to `__stack_chk_fail_local'
objects/prod/dnssd_clientstub.c.so.o: In function `handle_query_response':
dnssd_clientstub.c:(.text+0x4bd): undefined reference to `__stack_chk_fail_local'
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
For x86 and x86_64, nodejs has some special CPU
code that needs to be selected by specifying
the correct CPU name (correct for nodejs).
On OpenWRT x86 is i386 ; node wants ia32 for this.
And x86_64 is x64 on nodejs.
So, we just need to do the proper substitutions.
Note: the ARCH env-var is obtained from CONFIG_ARCH, after
some subtitutions are applied.
So, it shouldn't affect other target archs.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Version 1.13.3 has a tar.gz so the OpenWRT default Build/Prepare
rule can be used with MD5 checksum.
Add patch to fix build:
ktutil_funcs.c: In function 'ktutil_delete':
ktutil_funcs.c:75:28: error: 'prev' may be used uninitialized in this function [-Werror=maybe-uninitialized]
prev->next = lp->next;
There does not seem to be a way for 'prev' being uninitialized
(logically), however the compiler does not see that, because
'prev' is dependent on i >= 1.
So, we just need to initialize it to NULL.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Reported buildbot issue is:
/store/buildbot/slave/ar71xx/build/build_dir/target-mips_34kc_musl-1.1.11/ola-0.9.7/plugins/openpixelcontrol/.libs/libolaopenpixelcontrol.so: undefined reference to `ola::network::TCPSocket::ReadDescriptor() const'
collect2: error: ld returned 1 exit status
There's also a discussion (attempt) to fix this on the buildroot project:
https://patchwork.ozlabs.org/patch/503884/
This bug has been reported (from the buildroot project), here:
https://github.com/OpenLightingProject/ola/issues/880
This commit introduced the issue:
https://github.com/OpenLightingProject/ola/commit/bfc1d99055980dfac5c959a7210257d1939803ec
specifically the `-fvisibility-inlines-hidden` switch.
So, until, the upstream project (ola) fixes this, this fix
looks like the quickest/simplest workaround to have this package build.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems ntpdate also requires this lib:
```
Package ntpdate is missing dependencies for the following libraries:
libcap.so.2
make[2]: *** [/store/buildbot/slave/ar71xx/build/bin/ar71xx/packages/packages/ntpdate_4.2.8p4-1_ar71xx.ipk] Error 1
make[2]: Leaving directory `/store/buildbot/slave/ar71xx/build/feeds/packages/net/ntpd'
```
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.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 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>
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>
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>
Alexandru Ardelean