shadowsocks-rust is shadowsocks written in rust, with high performance
for AES AEAD ciphers (while much lower for non-ones).
However with the lack of rust toolchain, by now we can only download
pre-compiled binaries for quick setup and this Makefile needs to be
rewritten when rust toolchain is up.
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Fix: bpftools 5.11.2 does not compile on macOS, because the -m option
was placed between src and dst. Corrected by moving -m 644 before src.
Signed-off-by: Georgi Valkov <gvalkov@abv.bg>
The pkgconfig file hardcodes a host library directory which cannot be
overridden by OpenWrt during builds. Use SED to fix this and potential
include directory problems, as is done with several other packages.
This fixes a strange issue intermittently seen building iproute2 on the
oxnas target:
iptables modules directory: /usr/lib/iptables
libc has setns: yes
SELinux support: no
libbpf support: no
libbpf version 0.3.0 is too low, please update it to at least 0.1.0
LIBBPF_FORCE=on set, but couldn't find a usable libbpf
Fixes: 2f0d672088 ("bpftools: add utility and library packages
supporting eBPF usage")
Reported-by: Russell Senior <russell@personaltelco.net>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
A compact patch that provides AES and GCM implementations that utilize the
ARMv8 Crypto Extensions. The config flag is MBEDTLS_ARMV8CE_AES_C, which
is disabled by default as we don't do runtime checking for the feature.
The new implementation lives in armv8ce_aes.c.
Provides similar functionality to https://github.com/ARMmbed/mbedtls/pull/432
Thanks to Barry O'Rourke and others for that contribtion.
Tested on a Cortex A53 device and QEMU. On a midrange phone the real AES-GCM
throughput increases about 4x, while raw AES speed is up to 10x faster.
[updated Makefile to enable this function, adjusted commit message]
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
This will use the new application led trigger backend. For now this is
the only package that uses leds trigger in user space to configure the
kernel led triggers.
The callback script only emmits a message for now, so that this LED is now
managed by the rssileds service. Until now a generic warning was emitted that
this LED trigger is not supported. But that is not true.
-> Skipping trigger 'rssileds' for led '<name>' due to missing kernel module
I think this callback should be changed in the future to restart the
service.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
For now we have only kernel LED trigger support. With this change it is now
possible to use application triggers.
If we configure a LED with a non kernel trigger, then we check on every
restart and boot of the LED service if we have this trigger as an application
in "/usr/libexec/led-trigger". If this file with the name is found, then we
execute this to init the LED.
Possible use cases are:
- Start/Stop/Restart an application led trigger service for this led
- Init a LED that is configured by a hotplug script (VPN tunnel established)
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
`which` utility is not shipped by default for example on recent Arch
Linux and then any steps relying on its presence fails, like for example
following Python3 prereq build check:
$ python3 --version
Python 3.9.1
$ make
/bin/sh: line 1: which: command not found
...
Checking 'python3'... failed.
So make `which` utility host build requirement.
References: PR#3820 FS#3525
Signed-off-by: Petr Štetiar <ynezz@true.cz>
This reverts commit c7aec47e5e.
The original commit replaces 'which' with 'command'. Sadly most of
them are not equivalent and for 'which -a', there is no easy
replacements that would not reimplement PATH parsing logic. Hence
revert. Keeping a dependency on which is absolutely fine.
Signed-off-by: Clemens Fruhwirth <clemens@endorphin.org>
Currently minimal GNU supported GCC version is 7 (from May 2, 2017),
buildbots are using default GCC version 6 on Debian 9 (old stable),
current Debian stable has GCC version 8.3.0.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
