mailing list outage

2021-03-29 Thread John Crispin
Hi, Due to a power cut and failing UPS the mailing list has been offline for ~48hrs. It is now back and operational. It will take a while for it to chew through the backlog.     John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org h

Switch mtd-mac-address to nvmem implementation

2021-03-29 Thread Ansuel Smith
The pending nvmem patches have been applied to mtd/next. Some time ago I also sent a patch with the mtd-mac-address-increment-byte upstream but it got rejected since dts should not contain this kind of binding. The patch directly implements the increment and increment-byte binding to the of_get_ma

[sdwalker/sdwalker.github.io] 4f37b9: This week's update

2021-03-29 Thread Stephen Walker via openwrt-devel
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 --- Branch: refs/heads/master Home

[PATCH 1/2] ncurses: split long line of supported terminfo

2021-03-29 Thread Paul Spooren
The terminfo files were all in one row which is terrible to read. Split them over multiple lines to improve readability. Signed-off-by: Paul Spooren --- package/libs/ncurses/Makefile | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/package/libs/ncurses/Makefile b

[PATCH 2/2] ncurses: add screen-256color terminfo

2021-03-29 Thread Paul Spooren
The terminfo is required by the popular terminal multiplexer screen and tmux, offer it by default as the size impact is minimal with 885 Bytes. Signed-off-by: Paul Spooren --- package/libs/ncurses/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/package/libs/ncurses

Re: [PATCH v2] ubusd: convert tx_queue to linked list

2021-03-29 Thread Arnout Vandecappelle
Hi Felix, On 25/03/2021 23:56, Felix Fietkau wrote: [snip] > The data structure changes that I pointed out are not a blocker for me. > I do want to see at least a per-client message limit (in order to not > regress on accidental DoS). I posted a v3 with exactly that at around the time you sent