Re: [RFC] raise gcc/make versions for 20.x

On Tue, Dec 15, 2020 at 9:26 PM Petr Štetiar wrote: > > Rosen Penev [2020-12-15 19:03:55]: > > Hi, > > > The issue is with EL7. That would break the ability to compile. > > this is moot argument[1]: > > [root@9bb9a267fbb6 build]# cat /etc/redhat-release > CentOS Linux release 7.7.1908 (Core) >

Re: [RFC] raise gcc/make versions for 20.x

Rosen Penev [2020-12-15 19:03:55]: Hi, > The issue is with EL7. That would break the ability to compile. this is moot argument[1]: [root@9bb9a267fbb6 build]# cat /etc/redhat-release CentOS Linux release 7.7.1908 (Core) [root@9bb9a267fbb6 build]# gcc --version gcc (GCC) 8.3.1 20190311

Re: [RFC] raise gcc/make versions for 20.x

Paul Spooren [2020-12-15 16:26:14]: Hi, > I've seen two patches for version raises of build requirements and would > like to know if we should merge them before or after 20.x. > > make: 3.81.x -> 4.1.x > gcc: 4.8 -> 6.x > > I'm in favor to merge both *before* the branch. it would probably

Corruption in ext4 root

I have a peculiar use case for OpenWrt: an image with an ext4 root filesystem running on Xen as a DomU. I often find the OpenWrt image's root filesystem corrupt after running "poweroff" and then restarting the DomU VM. I have gone as far as to activate CONFIG_TARGET_EXT4_JOURNAL, but this does

Re: [RFC] raise gcc/make versions for 20.x

On Tue, Dec 15, 2020 at 6:31 PM Paul Spooren wrote: > > Hi, > > I've seen two patches for version raises of build requirements and > would like to know if we should merge them before or after 20.x. > > make: 3.81.x -> 4.1.x > gcc: 4.8 -> 6.x The issue is with EL7. That would break the ability to

Re: [PATCH] toolchain: gcc: Remove support for GCC 5

On Tue, Dec 15, 2020 at 5:14 PM Hauke Mehrtens wrote: > > On 12/16/20 1:21 AM, Paul Spooren wrote: > > > > > > On Mi, Dez 16, 2020 at 00:24, Hauke Mehrtens wrote: > >> GCC was used in 17.01 as the default compiler the last time. We do not > >> test this old GCC version any more and there are

[RFC] raise gcc/make versions for 20.x

Hi, I've seen two patches for version raises of build requirements and would like to know if we should merge them before or after 20.x. make: 3.81.x -> 4.1.x gcc: 4.8 -> 6.x I'm in favor to merge both *before* the branch. Best, Paul ___

[PATCH] build: Add IRQSOFF and PREEMPT TRACER kernel config option

From: Hauke Mehrtens This adds the CONFIG_IRQSOFF_TRACER and the CONFIG_PREEMPT_TRACER kernel configuration option to the OpenWrt menu. This can be used to debug latencies in the system. The CONFIG_PREEMPT_TRACER option needs the CONFIG_PREEMPT option which is supposed to be used for Low-Latency

Re: [PATCH] toolchain: gcc: Remove support for GCC 5

On 12/16/20 1:21 AM, Paul Spooren wrote: On Mi, Dez 16, 2020 at 00:24, Hauke Mehrtens wrote: GCC was used in 17.01 as the default compiler the last time. We do not test this old GCC version any more and there are some known problems it fails to compile the U-Boot for the Allwinner A64 SoC.

Re: [PATCH] toolchain: gcc: Remove support for GCC 5

On Mi, Dez 16, 2020 at 00:24, Hauke Mehrtens wrote: GCC was used in 17.01 as the default compiler the last time. We do not test this old GCC version any more and there are some known problems it fails to compile the U-Boot for the Allwinner A64 SoC. Just remove it to make it clear that we

[PATCH] toolchain: gcc: Remove support for GCC 5

GCC was used in 17.01 as the default compiler the last time. We do not test this old GCC version any more and there are some known problems it fails to compile the U-Boot for the Allwinner A64 SoC. Just remove it to make it clear that we will not support this old GCC version any more.

[PATCH] e2fsprogs: Add TARGET_LDFLAGS to e4crypt

The TARGET_LDFLAGS were dropped in the linking of e4crypt. Signed-off-by: Hauke Mehrtens --- ...build-Add-SYSLIBS-to-e4crypt-linking.patch | 28 +++ 1 file changed, 28 insertions(+) create mode 100644

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

> On Dec 15, 2020, at 1:22 AM, Bjørn Mork wrote: > > Philip Prindeville writes: > >> I’m trying to do the integration “glue” to allow one to operate a DNS >> private zone inside your intranet (aka “split horizon”) and prime it >> with both static data as well as DHCP lease information. > >

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

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

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

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 v4 2/3] dropbear: create a submenu for encryption algorithms

This allows the user to select only the encryption algorithms (s)he requires (e.g., disabling AES and keeping only ChaCha20-Poly1305). The default selection maintains the current functionality. Additionally, make sure at least one encryption algorithm is selected, lest the build would fail.

[PATCH v4 3/3] dropbear: create a submenu for key exchange algorithms

This allows the user to select only the key exchange algorithms (s)he requires (e.g., disabling group 14 SHA-{1,256} and keeping only Curve25519). The default selection maintains the current functionality. Additionally, make sure at least one key exchange algorithm is selected, lest the build

[PATCH v4 1/3] dropbear: create a submenu for public key algorithms

This allows the user to select only the public key algorithms (s)he requires (e.g., disabling RSA and keeping only Ed25519). The default selection maintains the current functionality. Additionally, make sure at least one public key algorithm is selected, lest the build would fail. Dropbear

[PATCH v4 0/3] dropbear: overhaul the crypto algorithm selection

This patch series enables a much more fine-grained configuration of the public key, encryption and key exchange algorithms in Dropbear. v4: rebase against current master. v3: rebase against current master. v2: correct file permissions. Rui Salvaterra (3): dropbear: create a submenu for public

Re: [PATCH v3 3/3] dropbear: create a submenu for key exchange algorithms

Hi, Please, always use "reply to all", in order to copy the mailing list on replies. On Tue, 15 Dec 2020 at 01:49, Patrick Kent wrote: > > These patches have been outdate. > Can you please update them for latest development openwrt. > Thanks. Regards. The general consensus seems to be that

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

W dniu 14.12.2020 o 17:30, Adrian Schmutzler pisze: > Hi, > >> -Original Message- >> From: Tomasz Maciej Nowak [mailto:tmn...@gmail.com] >> Sent: Dienstag, 8. Dezember 2020 18:05 >> To: Adrian Schmutzler ; openwrt- >> de...@lists.openwrt.org >> Cc: 'Vladimir Georgievsky' >> Subject: Re:

Re: [PATCH 1/2] ath79: add support for Mojo Networks AirTight C-75

W dniu 14.12.2020 o 17:28, Adrian Schmutzler pisze: > Hi, > > only have time for a quick subset of answers: > [...] arduino,yun|\ buffalo,bhr-4grv2|\ devolo,magic-2-wifi|\ diff --git a/target/linux/ath79/dts/qca9550_mojo_c-75.dts

[no subject]

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- When a FW upgrade is performed

RE: [PATCH] ramips: add support for GL.iNet GL-MT1300

Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of xinfa.d...@gl-inet.com > Sent: Dienstag, 15. Dezember 2020 05:15 > To: openwrt-devel@lists.openwrt.org > Cc: Xinfa Deng > Subject: [PATCH] ramips: add support for GL.iNet

RE: [PATCH 1/2] ramips: add support for ELECOM WRC-1167GS2-B

Hi, > > I've tested it, but doesn't work. Okay, it was worth a try. Maybe it's a similar driver issue on ramips like that one we had about one year ago, where a similar case was not "picked up" from 10_fix_wifi_mac for a single radio ... Best Adrian > > I made the following change, > >

[PATCH 01/12] ltq-vdsl-app: shutdown upon sigterm

procd sends sigterm to stop daemons, hook it up. This speeds up the shutdown sequence and gets rid of the following message: daemon.info procd: Instance dsl_control::instance1 pid 15408 not stopped on SIGTERM, sending SIGKILL instead Signed-off-by: Andre Heider Tested-by: Martin Schiller ---

[PATCH 09/12] ltq-dsl-base: remove usused lantiq_dsl.sh

All users have been converted to ubus. Signed-off-by: Andre Heider Tested-by: Martin Schiller --- .../files/lib/functions/lantiq_dsl.sh | 749 -- 1 file changed, 749 deletions(-) delete mode 100755 package/network/utils/ltq-dsl-base/files/lib/functions/lantiq_dsl.sh

[PATCH 02/12] ltq-vdsl-app: add ubus support to get metrics

Add a 'dsl' ubus object with a 'metrics' function to replace the expensive shell parsing done by /etc/init.d/dsl_control [dsl|luci]stat. All metrics are gathered by using syscalls. An additional thread is started to handle ubus events. $ time /etc/init.d/dsl_control dslstat real0m 2.66s user

[PATCH 03/12] ltq-adsl-app: add ubus support to get metrics

As with ltq-vdsl-app, see previous commit. Signed-off-by: Andre Heider --- package/network/config/ltq-adsl-app/Makefile | 2 +- .../ltq-adsl-app/patches/300-ubus.patch | 50 +++ package/network/config/ltq-adsl-app/src | 1 + 3 files changed, 52 insertions(+), 1

[packages PATCH 06/12] prometheus-node-exporter-lua: use the new ubus dsl metrics

This is significantly faster. Signed-off-by: Andre Heider --- .../lib/lua/prometheus-collectors/ltq-dsl.lua | 108 -- 1 file changed, 47 insertions(+), 61 deletions(-) diff --git a/utils/prometheus-node-exporter-lua/files/usr/lib/lua/prometheus-collectors/ltq-dsl.lua

[PATCH 12/12] ltq-adsl-app: bump PKG_RELEASE

Signed-off-by: Andre Heider --- package/network/config/ltq-adsl-app/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/network/config/ltq-adsl-app/Makefile b/package/network/config/ltq-adsl-app/Makefile index e03c0911a5..317f8a908a 100644 ---

[luci PATCH 04/12] luci-mod-status: use the new ubus dsl metrics

This is significantly faster. Signed-off-by: Andre Heider Tested-by: Martin Schiller --- .../resources/view/status/include/50_dsl.js | 55 +-- .../usr/share/rpcd/acl.d/luci-mod-status.json | 2 +- 2 files changed, 28 insertions(+), 29 deletions(-) diff --git

[PATCH 11/12] ltq-vdsl-app: bump PKG_RELEASE

Signed-off-by: Andre Heider --- package/network/config/ltq-vdsl-app/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/network/config/ltq-vdsl-app/Makefile b/package/network/config/ltq-vdsl-app/Makefile index 33b6ca093b..bf9287bc79 100644 ---

[PATCH 10/12] ltq-dsl-base: bump PKG_RELEASE

Signed-off-by: Andre Heider Tested-by: Martin Schiller --- package/network/utils/ltq-dsl-base/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/network/utils/ltq-dsl-base/Makefile b/package/network/utils/ltq-dsl-base/Makefile index e2cfc4004c..aae07bc299

[PATCH 08/12] ltq-adsl-app: use ubus to provide metrics

luci now uses ubus directly, so remove 'lucistat'. For manual usage just print the ubus output, use luci for a pretty version. Signed-off-by: Andre Heider --- package/network/config/ltq-adsl-app/files/dsl_control | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git

[PATCH 07/12] ltq-vdsl-app: use ubus to provide metrics

luci now uses ubus directly, so remove 'lucistat'. For manual usage just print the ubus output, use luci for a pretty version. Signed-off-by: Andre Heider Tested-by: Martin Schiller --- package/network/config/ltq-vdsl-app/files/dsl_control | 7 --- 1 file changed, 4 insertions(+), 3

[PATCH v2 0/12] add ubus support to ltq-[v|a]dsl-app

v2: - drop 0002-ltq-vdsl-app-fix-Wundef-warnings.patch - use "/dev/dsl_cpe_api" without the "0" suffix for the adsl daemon: package/kernel/lantiq/ltq-adsl/patches/100-dsl_compat.patch:+ device_create(dsl_class, NULL, MKDEV(DRV_DSL_CPE_API_DEV_MAJOR, 0), NULL, "dsl_cpe_api");

[luci PATCH 05/12] rpcd-mod-luci: get rid of now unused getDSLStatus ubus rpc

Good riddance. Signed-off-by: Andre Heider Tested-by: Martin Schiller --- libs/rpcd-mod-luci/src/luci.c | 55 --- 1 file changed, 55 deletions(-) diff --git a/libs/rpcd-mod-luci/src/luci.c b/libs/rpcd-mod-luci/src/luci.c index 94ccdf271..abf4b9ba5 100644 ---

Make HTTPS in LuCI optional but dead simple in 20.12 [Was: Re: 20.xx: postponse LuCI HTTPS per default]

Petr Štetiar [2020-11-20 11:44:14]: > > I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per > > default. > > Do we need to make this hard decission? Can't we leave it to the end users? > We need most of the SSL stuff for other parts, so why not benefit from that in > other

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

Philip Prindeville writes: > I’m trying to do the integration “glue” to allow one to operate a DNS > private zone inside your intranet (aka “split horizon”) and prime it > with both static data as well as DHCP lease information. “split horizon” is a very bad idea, and should not be encouraged.