Re: Bind + ISC dhcpd integration (for intranet split-horizon, etc)

2020-12-17 Thread Philip Prindeville
Responses… > On Dec 17, 2020, at 1:56 AM, Bjørn Mork wrote: > > Philip Prindeville writes: > >> https://github.com/openwrt/packages/pull/14240 >> >> The previous one is a precursor for getting Bind to start before DHCPD. > > > That makes more sense yes. > > I looked at it briefly. A

[PATCH 1/2] tools/libressl: update to 3.3.1

2020-12-17 Thread Rosen Penev
Signed-off-by: Rosen Penev --- tools/libressl/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libressl/Makefile b/tools/libressl/Makefile index 0cc26a930c..dbd8ca4d1a 100644 --- a/tools/libressl/Makefile +++ b/tools/libressl/Makefile @@ -8,8 +8,8 @@

[PATCH 2/2] tools/libressl: switch to compiling with cmake

2020-12-17 Thread Rosen Penev
Massive speed boost. From: Executed in 23.78 secs fish external usr time 31.03 secs0.00 micros 31.03 secs sys time 15.96 secs 624.00 micros 15.96 secs To: Executed in9.64 secs fish external usr time 10.03 secs 571.00 micros 10.03 secs

R: [PATCH] tools: zlib: fix broken compile with ccache enabled

2020-12-17 Thread ansuelsmth
> On Thu, Dec 17, 2020 at 5:15 PM wrote: > > > > > On Thu, Dec 17, 2020 at 4:13 PM wrote: > > > > > > > > > > > > > > > > > -Messaggio originale- > > > > > Da: Ansuel Smith > > > > > Inviato: venerdì 18 dicembre 2020 00:59 > > > > > A: OpenWrt Development List > > > > > Cc: Ansuel

Re: [PATCH] tools: zlib: fix broken compile with ccache enabled

2020-12-17 Thread Rosen Penev
On Thu, Dec 17, 2020 at 5:15 PM wrote: > > > On Thu, Dec 17, 2020 at 4:13 PM wrote: > > > > > > > > > > > > > -Messaggio originale- > > > > Da: Ansuel Smith > > > > Inviato: venerdì 18 dicembre 2020 00:59 > > > > A: OpenWrt Development List > > > > Cc: Ansuel Smith > > > > Oggetto:

R: [PATCH] tools: zlib: fix broken compile with ccache enabled

2020-12-17 Thread ansuelsmth
> On Thu, Dec 17, 2020 at 4:13 PM wrote: > > > > > > > > > -Messaggio originale- > > > Da: Ansuel Smith > > > Inviato: venerdì 18 dicembre 2020 00:59 > > > A: OpenWrt Development List > > > Cc: Ansuel Smith > > > Oggetto: [PATCH] tools: zlib: fix broken compile with ccache enabled > >

[PATCH] tools/zlib: do not use ccache

2020-12-17 Thread Rosen Penev
It seems to cause issues with zlib. This matches behavior with other tools in the tools/ directory. Signed-off-by: Rosen Penev --- tools/zlib/Makefile | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/zlib/Makefile b/tools/zlib/Makefile index 279851f758..bb7c15cce7

Re: [PATCH] tools: zlib: fix broken compile with ccache enabled

2020-12-17 Thread Rosen Penev
On Thu, Dec 17, 2020 at 4:13 PM wrote: > > > > > -Messaggio originale- > > Da: Ansuel Smith > > Inviato: venerdì 18 dicembre 2020 00:59 > > A: OpenWrt Development List > > Cc: Ansuel Smith > > Oggetto: [PATCH] tools: zlib: fix broken compile with ccache enabled > > > > If ccache is

R: [PATCH] tools: zlib: fix broken compile with ccache enabled

2020-12-17 Thread ansuelsmth
> -Messaggio originale- > Da: Ansuel Smith > Inviato: venerdì 18 dicembre 2020 00:59 > A: OpenWrt Development List > Cc: Ansuel Smith > Oggetto: [PATCH] tools: zlib: fix broken compile with ccache enabled > > If ccache is enabled with an empty buildroot the compilation fails. Fix >

[PATCH] tools: zlib: fix broken compile with ccache enabled

2020-12-17 Thread Ansuel Smith
If ccache is enabled with an empty buildroot the compilation fails. Fix this by using the NOCACHE compiler as it's done by other tools package. Signed-off-by: Ansuel Smith --- tools/zlib/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/zlib/Makefile b/tools/zlib/Makefile index

Turris Omnia boot failure after "mvebu: fix initramfs/kernel image for CZNIC Turris Omnia"

2020-12-17 Thread Magnus Kroken
Commit e401a2a42e6d7c892e1cf7d765fa5ec9b2db3fb3 causes my Turris Omnia CZ11NIC13 to no longer boot. Compiling with EARLY_PRINTK does not show anything of interest: ## Executing script at 0180 Setting bus to 0 reading armada-385-turris-omnia.dtb 18748 bytes read in 20 ms (915 KiB/s) reading

Re: Compilation error for host zilb from cmake

2020-12-17 Thread Rosen Penev
On Thu, Dec 17, 2020 at 3:09 PM wrote: > > > On Thu, Dec 17, 2020 at 3:05 PM Ansuel Smith wrote: > > > > > > > > > > > On Thu, Dec 17, 2020 at 1:57 PM Ansuel Smith > > wrote: > > > > > > > > > > Hello I can't currently compile openwrt on my system. > > > > > The error is this > > > > >

R: Compilation error for host zilb from cmake

2020-12-17 Thread ansuelsmth
> On Thu, Dec 17, 2020 at 3:05 PM Ansuel Smith wrote: > > > > > > > > On Thu, Dec 17, 2020 at 1:57 PM Ansuel Smith > wrote: > > > > > > > > Hello I can't currently compile openwrt on my system. > > > > The error is this > > > > https://gist.github.com/Ansuel/b5a6574ea912d56e8697984154d0ba42 > >

Re: Compilation error for host zilb from cmake

2020-12-17 Thread Rosen Penev
On Thu, Dec 17, 2020 at 3:05 PM Ansuel Smith wrote: > > > > > On Thu, Dec 17, 2020 at 1:57 PM Ansuel Smith wrote: > > > > > > Hello I can't currently compile openwrt on my system. > > > The error is this > > > https://gist.github.com/Ansuel/b5a6574ea912d56e8697984154d0ba42 > > > > > > Any idea

Re: Compilation error for host zilb from cmake

2020-12-17 Thread Ansuel Smith
> > On Thu, Dec 17, 2020 at 1:57 PM Ansuel Smith wrote: > > > > Hello I can't currently compile openwrt on my system. > > The error is this > > https://gist.github.com/Ansuel/b5a6574ea912d56e8697984154d0ba42 > > > > Any idea why ? I have a very recent system with latest package (ubuntu > > devel

Re: Compilation error for host zilb from cmake

2020-12-17 Thread Rosen Penev
On Thu, Dec 17, 2020 at 1:57 PM Ansuel Smith wrote: > > Hello I can't currently compile openwrt on my system. > The error is this > https://gist.github.com/Ansuel/b5a6574ea912d56e8697984154d0ba42 > > Any idea why ? I have a very recent system with latest package (ubuntu > devel branch) Because

Compilation error for host zilb from cmake

2020-12-17 Thread Ansuel Smith
Hello I can't currently compile openwrt on my system. The error is this https://gist.github.com/Ansuel/b5a6574ea912d56e8697984154d0ba42 Any idea why ? I have a very recent system with latest package (ubuntu devel branch) ___ openwrt-devel mailing list

[PATCH v3 1/2] ath79: add support for AirTight C-75

2020-12-17 Thread Tomasz Maciej Nowak
AirTight Networks (later renamed to Mojo Networks) C-75 is a dual-band access point, also sold by WatchGuard under name AP320. Specification SoC: Qualcomm Atheros QCA9550 RAM: 128 MiB DDR2 Flash: 2x 16 MiB SPI NOR WIFI: 2.4 GHz 3T3R integrated 5 GHz 3T3R QCA9890 oversized Mini PCIe card

[PATCH v3 2/2] ath79: airtight c-75: use second flash chip

2020-12-17 Thread Tomasz Maciej Nowak
The flash capacity is divided in two flash chips and currently only first is used. Increase available space for OpenWrt by additional 16 MiB using mtd-concat driver. Because U-Boot might not be able to load kernel image spanned through two flash chips, the size of kernel is limited to space

Re: [PATCH v2 2/2] ath79: airtight c-75: use second flash chip

2020-12-17 Thread Tomasz Maciej Nowak
W dniu 16.12.2020 o 16:49, Adrian Schmutzler pisze: > Hi again, > > one comment and a slightly conceptual question: > >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] >> On Behalf Of Tomasz Maciej Nowak >> Sent: Dienstag, 15. Dezember 2020

[PATCH] toolchain: Deactivate sanitizer on MIPS and ARC

2020-12-17 Thread Hauke Mehrtens
MIPS 32 bit support for sanitizer was added with GCC 9, MIPS 64 bit and ARC is still not supported in GCC 10. Deactivate them for now and change this when we change the default compiler to GCC 9 or later. Signed-off-by: Hauke Mehrtens --- package/libs/toolchain/Makefile | 8 1 file

[PATCH] mt76: Fix compile against glibc

2020-12-17 Thread Hauke Mehrtens
The mt76 test tools did not compile against glibc. Signed-off-by: Hauke Mehrtens --- ...et-mode-for-new-file-tmp-mt76-test-s.patch | 25 +++ 1 file changed, 25 insertions(+) create mode 100644 package/kernel/mt76/patches/100-tools-Set-mode-for-new-file-tmp-mt76-test-s.patch

Re: [PATCH v3] procd: add procd json output to init

2020-12-17 Thread Petr Štetiar
Florian Eckert [2020-12-17 10:34:25]: > So that I do not always have to type the whole string. Well, you don't need to. root@OpenWrt:/# cat ~/.shinit procd_service_list() { ubus call service list "{'name':\"$1\",'verbose':true}" } root@OpenWrt:/# procd_service_list urngd {

[PATCH v2 0/5] ubus: extend the service object with a restart method

2020-12-17 Thread Florian Eckert
This patchset adds the new method "restart" to the ubus service object. This method is called on a service restart, if it is managed by procd. I have noticed that during a firewall restart the mwan3 rules have all disappeared and I have to restart my service as well. I did not expected this. So

[PATCH v2 5/5] procd: add api wrapper

2020-12-17 Thread Florian Eckert
This commit adds the functions `procd_add_service_trigger` and `procd_add_restart_service_trigger`. In order for the service to be triggered by another service during a restart, only the function procd_add_restart_service_trigger is needed. Example: service_trigger() { procd

[PATCH v2 2/5] base-files: add restart function wrapper

2020-12-17 Thread Florian Eckert
Thies commit add the new wrapper function to rc.common to execute the new ubus service method "restart" on a service restart. Signed-off-by: Florian Eckert --- package/base-files/files/etc/rc.common | 13 + 1 file changed, 13 insertions(+) diff --git

[PATCH v2 1/5] procd: add restart ubus call

2020-12-17 Thread Florian Eckert
To allow other services to respsond to a restart event from a procd initialised service, a new ubus method "restart" in the ubus "service" path is needed to trigger a ubus notify and also execute the installed service triggers. Cc: Aaron Goodman Signed-off-by: Florian Eckert The original

[PATCH v2 4/5] firewall: use new restart_service callback

2020-12-17 Thread Florian Eckert
In order that the prcod restart service can also be triggered during a firewall restart, this call function must be changed. Signed-off-by: Florian Eckert --- package/network/config/firewall/files/firewall.init | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2 3/5] firewall: fix whitespace

2020-12-17 Thread Florian Eckert
Remove trailing whitespace. Signed-off-by: Florian Eckert --- package/network/config/firewall/files/firewall.init | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/network/config/firewall/files/firewall.init b/package/network/config/firewall/files/firewall.init index

Re: [PATCH v3] procd: add procd json output to init

2020-12-17 Thread Florian Eckert
Hello Petr On 2020-12-17 10:12, Petr Štetiar wrote: Florian Eckert [2020-12-17 09:40:08]: With this change, the init script is now extend with the command to get this information easier. I still lack the information about your use case, how do you use this output of this command.

Re: [PATCH v3] procd: add procd json output to init

2020-12-17 Thread Petr Štetiar
Florian Eckert [2020-12-17 09:40:08]: Hi, > By adding the extra command `procd` it is now possible to retrieve all > relevant data from a procd started service directly via the init script. > > Until now, you have to query the ubus to get the information with the > following command. > >

Re: Bind + ISC dhcpd integration (for intranet split-horizon, etc)

2020-12-17 Thread Bjørn Mork
Philip Prindeville writes: > https://github.com/openwrt/packages/pull/14240 > > The previous one is a precursor for getting Bind to start before DHCPD. That makes more sense yes. I looked at it briefly. A couple of notes without testing: I would not have used a key named "rdnc"-anything for

[PATCH v3] procd: add procd json output to init

2020-12-17 Thread Florian Eckert
By adding the extra command `procd` it is now possible to retrieve all relevant data from a procd started service directly via the init script. Until now, you have to query the ubus to get the information with the following command. `ubus call service list '{"name":"","verbose":true}'` With