Re: [PATCH] busybox: fix fwmark and add fwmask support to ip rule

On Tue, 4 Aug 2020 at 06:58, Rui Salvaterra wrote: > > BusyBox ip (rule) applet supports fwmark for policy routing (albeit through > the > old and deprecated RTA_PROTOINFO message attribute), but fwmask is completely > unsupported. For this reason, mwan3 depends on ip(-tiny), which compiles to >

Re: [PATCH] busybox: fix fwmark and add fwmask support to ip rule

Hi Rui, please increase the PKG_RELEASE whenever you change anything inside a package. On 03.08.20 12:54, Rui Salvaterra wrote: BusyBox ip (rule) applet supports fwmark for policy routing (albeit through the old and deprecated RTA_PROTOINFO message attribute), but fwmask is completely

[PATCH/RFC 2/2] procd: jail: make use of BLOBMSG_CAST_INT64 for OCI rlimits

Signed-off-by: Daniel Golle --- To illustrate the use of the previous patch of this series. jail/jail.c | 76 - 1 file changed, 29 insertions(+), 47 deletions(-) diff --git a/jail/jail.c b/jail/jail.c index c72de07..9d0113f 100644 ---

[PATCH/RFC 1/2] libubox: blobmsg: introduce BLOBMSG_CAST_INT64

When dealing with 64-bit integers in JSON documents, blobmsg_parse becomes useless as blobmsg-json only uses BLOBMSG_TYPE_INT64 if the value exceeds the range of a 32-bit integer, otherwise BLOBMSG_TYPE_INT32 is used. This is because blobmsg-json parses the JSON document ad-hoc without knowing the

[PATCH] busybox: fix fwmark and add fwmask support to ip rule

BusyBox ip (rule) applet supports fwmark for policy routing (albeit through the old and deprecated RTA_PROTOINFO message attribute), but fwmask is completely unsupported. For this reason, mwan3 depends on ip(-tiny), which compiles to over 280 kiB on MIPS32 (-mips16 -mtune=74kc -O2). This pending

[PATCH] ramips: drop remaining m25p,chunked-io from DTS

This option was a spi nor hack which is dropped in commit bcf4a5f474d1 ("ramips: remove chunked-io patch and set spi->max_transfer_size instead") Most of it has already been removed in be2b61e4f1ec ("ramips: drop m25p,chunked-io from dts") It seems all current usages were added after that.

[PATCH] ramips: fix mediatek, portmap based on board.d port assignment

When comparing to the port assignment in board.d/02_network, many devices seem to use the wrong setup of mediatek,portmap. The corrects the values for mt7620 subtarget based on the location of the wan port. A previous cleanup of obviously wrong values has already been done in d3c0a944059b

Re: image size on 20.xx builds -- what about a new SMALL target

Hi, Op maandag 3 augustus 2020 om 9u40 schreef Henrique de Moraes Holschuh : On 02/08/2020 19:11, Daniel Golle wrote: On Sun, Aug 02, 2020 at 11:49:54PM +0200, Bjoern Franke wrote: Hi, Your Filesystem has a size of 5.81M. MT7620 has a kernel size of around 2M, which exceeds the

RE: Restoring (old) config backups and

Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Paul Oranje > Sent: Samstag, 1. August 2020 16:06 > To: m...@adrianschmutzler.de > Cc: Alberto Bursi ; openwrt- > de...@lists.openwrt.org > Subject: Re: Restoring (old) config

[PATCH v3] scripts: Add Buildbot dump-target-info.pl script

The script comes from buildbot.git[0] and is used to print available targets and architectures, which are then build. As the buildbot clones openwrt.git anyway, the script might as well live here to be used for other cases as well, e.g. determining what architectures are available when building

[PATCH] ramips: add common definition netgear_sercomm_nor

Like NAND-based devices, SPI-NOR based Netgear devices also share a common setup for their images. This creates a common defition for them in image/Makefile, so it can be reused across subtargets. Signed-off-by: Adrian Schmutzler --- target/linux/ramips/image/Makefile | 14 +-

Re: Policy on BUILD_PATENTED

Hi Rosen, Le lun. 3 août 2020 à 00:04, Rosen Penev a écrit : > > Recently there's been a pull request to get patented functionality in > the packages feed: https://github.com/openwrt/packages/pull/12992 > > Which pointed me to this lovely description: > https://www.videolan.org/legal.html > >

Re: image size on 20.xx builds -- what about a new SMALL target

I'm cc'ing the OpenWrt-Adm list on this as well, because I smell a policy decision looming. Some thoughts: 1) In my opinion, we should not aim for a third (Tiny/Small/Normal) build for 20.xx. We don't need any more hurdles to overcome before we ship an RC1 version. 2) I had not understood how

Re: image size on 20.xx builds -- what about a new SMALL target

On 02/08/2020 19:11, Daniel Golle wrote: On Sun, Aug 02, 2020 at 11:49:54PM +0200, Bjoern Franke wrote: Hi, Your Filesystem has a size of 5.81M. MT7620 has a kernel size of around 2M, which exceeds the available space on flash. On 19.07.3, the listed lineup of packages has 5.54M and it

[PATCH] wireguard: bump to 1.0.20200729

* compat: rhel 8.3 beta removed nf_nat_core.h * compat: ipv6_dst_lookup_flow was ported to rhel 7.9 beta This compat tag adds support for RHEL 8.3 beta and RHEL 7.9 beta, in addition to RHEL 8.2 and RHEL 7.8. It also marks the first time that is all green

Re: [PATCH V2 uhttpd] ubus: add new RESTful API

On Fri, 31 Jul 2020 at 14:35, Nicolas Pace wrote: > On 7/31/20 1:49 AM, Rafał Miłecki wrote: > > From: Rafał Miłecki > > > > Initial uhttpd ubus API was fully based on JSON-RPC. That restricted it > > from supporting ubus notifications that don't fit its model. > > > > Notifications require

Re: image size on 20.xx builds

Hi, Apart from the usual kernel growth we have also enabled a bunch of previously disabled kernel features on targets which are not marked as SMALL_FLASH[1]. MT7620 is a mixed bag in that regard and it would make sense to split it similar to ath79 into a 'tiny' and a 'generic' variant. The

RE: [PATCH v2] scripts: Add Buildbot dump-target-info.pl script

> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Paul Spooren > Sent: Montag, 3. August 2020 10:11 > To: openwrt-devel@lists.openwrt.org > Cc: Paul Spooren > Subject: [PATCH v2] scripts: Add Buildbot dump-target-info.pl script > >

[PATCH v2] scripts: Add Buildbot dump-target-info.pl script

The script comes from buildbot.git[0] and is used to print available targets and architectures, which are then build. As the buildbot clones openwrt.git anyway, the script might as well live here to be used for other cases as well, e.g. determining what architectures are available when building

Re: [PATCH] scripts: Add Buildbot dumpinfo.pl script

Paul Spooren [2020-07-12 22:56:33]: Hi, > > scripts/dumpinfo.pl | 91 + that scripts directory is mess already, please rename it to something meaningful, like `dump-target-info.pl` as that `dumpinfo.pl` is too generic. -- ynezz