[OpenWrt-Devel] [PATCH] build: svn: remove the check for trust-server-cert option

2020-06-07 Thread kai zhang
The command:(svn help export) does not display trust-server-cert option by default even if it is supported with svn version 1.13.0. Signed-off-by: kai zhang --- include/download.mk | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/include/download.mk b/include/download.mk

Re: [OpenWrt-Devel] olsrd: not compiling with gcc 9

2020-06-07 Thread Sven Roederer
Am Sonntag, 7. Juni 2020, 23:39:08 CEST schrieb Rosen Penev: > > Le 7 juin 2020 à 1:38 PM, Nick a écrit : > > > > I would suggest doing this PR as patch like freifunk berlin is doing it: > > https://github.com/freifunk-berlin/firmware/commit/93f9a026e025c7b663369f5 > > 284cec0bb91345220 >

Re: [OpenWrt-Devel] olsrd: not compiling with gcc 9

2020-06-07 Thread Rosen Penev
> Le 7 juin 2020 à 1:38 PM, Nick a écrit : > > I would suggest doing this PR as patch like freifunk berlin is doing it: > https://github.com/freifunk-berlin/firmware/commit/93f9a026e025c7b663369f5284cec0bb91345220 Someone needs to propose one then. > > Otherwise, olsrd won't compile anymore.

[OpenWrt-Devel] [sdwalker/sdwalker.github.io] 8eec96: This week's update

2020-06-07 Thread Stephen Walker
Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: 8eec96afe126fbc48ec648a0165e7ec5138d5e6a https://github.com/sdwalker/sdwalker.github.io/commit/8eec96afe126fbc48ec648a0165e7ec5138d5e6a Author: Stephen Walker Date: 2020-06-07 (Sun, 07 Jun

Re: [OpenWrt-Devel] olsrd: not compiling with gcc 9

2020-06-07 Thread Nick
I would suggest doing this PR as patch like freifunk berlin is doing it: https://github.com/freifunk-berlin/firmware/commit/93f9a026e025c7b663369f5284cec0bb91345220 Otherwise, olsrd won't compile anymore. :/ Or making a fork, because olsrd seems not to be maintained anymore. On 07.06.20 22:27,

Re: [OpenWrt-Devel] olsrd: not compiling with gcc 9

2020-06-07 Thread Nick
Here is a PR that is fixing the issue. Why is that not merged? :/ https://github.com/OLSR/olsrd/pull/79/files On 07.06.20 22:03, Rosen Penev wrote: > >> Le 7 juin 2020 à 1:00 PM, Nick a écrit : >> >> I can not compile olsrd daemon with gcc9. >>> #define isNaN(x) (x != x) >>> ... >>> if

Re: [OpenWrt-Devel] olsrd: not compiling with gcc 9

2020-06-07 Thread Rosen Penev
> Le 7 juin 2020 à 1:00 PM, Nick a écrit : > > I can not compile olsrd daemon with gcc9. >> #define isNaN(x) (x != x) >> ... >> if (!isNaN(gpsdata->fix.time)) { > Here fix.time is a struct timespec. > The call is just wrong, or? Why should I check a struct for a valid float? This broke when

[OpenWrt-Devel] olsrd: not compiling with gcc 9

2020-06-07 Thread Nick
I can not compile olsrd daemon with gcc9. > #define isNaN(x) (x != x) > ... > if (!isNaN(gpsdata->fix.time)) { Here fix.time is a struct timespec. The call is just wrong, or? Why should I check a struct for a valid float? ___ openwrt-devel mailing list

Re: [OpenWrt-Devel] DSA vlan configuration

2020-06-07 Thread John Crispin
On 06.06.20 15:19, Bjørn Mork wrote: Bjørn Mork writes: I wonder if I have understood this correctly: 1) vlan_filtering is required when bridging tagged and untagged DSA ports, and 2) all bridge ports, including the wireless VIFs, must be configured with the correct VIDs when

Re: [OpenWrt-Devel] [PATCH 2/2] libcxx: update to 10.0.0

2020-06-07 Thread Ian Cooper
On Sat, 6 Jun 2020 11:52:23 -0700 Rosen Penev wrote: > Switched to upstream tarballs. > > Switched to libcxxabi as using libsupc++ is quite wonky. > > Fixed description. > > Removed patches. The fixes are cosmetic. > > Added ssp patch. This one is needed for i386 and powerpc under musl. >

Re: [OpenWrt-Devel] [PATCH 1/2] libcxxabi: add

2020-06-07 Thread Ian Cooper
On Sat, 6 Jun 2020 11:52:22 -0700 Rosen Penev wrote: > This will be used for libcxx. > > Signed-off-by: Rosen Penev > --- > package/libs/libcxxabi/Makefile | 71 + > 1 file changed, 71 insertions(+) > create mode 100644 package/libs/libcxxabi/Makefile > >

Re: [OpenWrt-Devel] [PATCH] treewide: simplify inclusion of subtarget image files

2020-06-07 Thread mail
Hi Matthias, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Matthias Schiffer > Sent: Sonntag, 7. Juni 2020 13:33 > To: Adrian Schmutzler > Cc: openwrt-devel@lists.openwrt.org > Subject: Re: [OpenWrt-Devel] [PATCH] treewide:

Re: [OpenWrt-Devel] [PATCH] treewide: simplify inclusion of subtarget image files

2020-06-07 Thread Matthias Schiffer
On 6/7/20 1:11 PM, Adrian Schmutzler wrote: > Many target use a repetitive if-include scheme for their subtarget > image files, though their names are consistent with the subtarget > names. > > This patch removes these redundant conditions and just uses the > variable for the include where the

[OpenWrt-Devel] [PATCH] apm821xx: move device definitions to subfiles

2020-06-07 Thread Adrian Schmutzler
With several subtargets, the image/Makefile becomes crowded after a while. Many targets have moved their device definitions to $subtarget.mk files to have them more organized, let's do this here as well. While at it, also move subtarget-specific build recipes. Cc: Christian Lamparter

[OpenWrt-Devel] [PATCH] bcm47xx: move device definitions to subfiles

2020-06-07 Thread Adrian Schmutzler
With several subtargets, the image/Makefile becomes crowded after a while. Many targets have moved their device definitions to $subtarget.mk files to have them more organized, let's do this here as well. Cc: Rafał Miłecki Signed-off-by: Adrian Schmutzler --- target/linux/bcm47xx/image/Makefile

[OpenWrt-Devel] [PATCH] treewide: simplify inclusion of subtarget image files

2020-06-07 Thread Adrian Schmutzler
Many target use a repetitive if-include scheme for their subtarget image files, though their names are consistent with the subtarget names. This patch removes these redundant conditions and just uses the variable for the include where the target setup allows it. For sunxi, this includes a

[OpenWrt-Devel] Internal switch problem on Asus RT-AC85P.

2020-06-07 Thread David Woodhouse
I've just set up a new RT-AC85P as one of three access points on my network, and it seems to be having problems with wireless clients which have roamed to it (or just newly associated to it) after being on one of the other APs. Incoming packets to the new wireless client aren't being received on

[OpenWrt-Devel] [PATCH 1/4 v5] bcm63xx: kernel: add BCM63167 cpuid variant

2020-06-07 Thread Daniel González Cabanelas
The BCM63167 is a BCM63268 SoC with a different physical packaging. Add the CPU ID to allow supporting routers with this SoC (i.e Sercomm H500-s) Signed-off-by: Daniel González Cabanelas --- Changes in v2: none Changes in v3: none Changes in v4: none Changes in v5: none

[OpenWrt-Devel] [PATCH 2/4 v5] bcm63xx: image: don't add the CFE to the sercomm factory

2020-06-07 Thread Daniel González Cabanelas
There is no need to include the CFE bootloader in the Sercomm factory images. There might be a case when this could be useful: - We are running the stock firmware on the first Sercomm image - The second partition storing the botloader was erased (unlikely) Even in this case flashing an image

[OpenWrt-Devel] [PATCH 4/4 v5] bcm63xx: add support for the Sercomm H500-s

2020-06-07 Thread Daniel González Cabanelas
Sercomm H500-s is an xDSL dual band wireless router based on Broadcom BCM63167 SoC. Hardware: SoC: Broadcom BCM63167 CPU: BMIPS4350 V8.0, 400 MHz, 2 cores Flash:NAND 128 MiB RAM: DDR3 128 MiB Ethernet: 4x 10/100/1000 Mbps Switch:

[OpenWrt-Devel] [PATCH 3/4 v5] bcm63xx: image: allow to pass the addr to the NAND kernel header

2020-06-07 Thread Daniel González Cabanelas
Not all CFEs will need to relocate the kernel (i.e H500-s), therefore we'll need to pass a different address and not the LOADER_ENTRY. Let to pass the addr to the image creation when neccessary. Signed-off-by: Daniel González Cabanelas --- Changes in v2: refresh Changes in v3: none Changes in