[PATCH] rpcd CMakeLists.txt: install unauthenticated.json

2021-01-18 Thread Sergey Ponomarev
When installing rpcd directly from CMake then the file is missing. Signed-off-by: Sergey Ponomarev --- CMakeLists.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/CMakeLists.txt b/CMakeLists.txt index 266dbe4..213b4ba 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -69,3 +69,6 @@

[PATCH] rpcd CMakeLists.txt: drop legacy json-c support

2021-01-18 Thread Sergey Ponomarev
The cmake logic is wrong (E.G. PKG_CHECK_FOR_MODULES fails unless all modules are found), and the legacy libjson.so name is also used by the other libjson (http://sourceforge.net/projects/libjson/) which provides an incompatible API, so just drop it. Backported from libubox

[PATCH] examples: drop legacy json-c support

2021-01-18 Thread Sergey Ponomarev
The cmake logic is wrong (E.G. PKG_CHECK_FOR_MODULES fails unless all modules are found), and the legacy libjson.so name is also used by the other libjson (http://sourceforge.net/projects/libjson/) which provides an incompatible API, so just drop it. Backported from

[PATCH 2/2] CMakeLists.txt: use CMAKE_CURRENT_LIST_DIR

2021-01-18 Thread Sergey Ponomarev
When building with debuild/fakeroot the build folder is different from sources Signed-off-by: Sergey Ponomarev --- CMakeLists.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index dbfbf5d..44ebe3e 100644 --- a/CMakeLists.txt

[PATCH 1/2] jsonfilter: drop legacy json-c support

2021-01-18 Thread Sergey Ponomarev
The cmake logic is wrong (E.G. PKG_CHECK_FOR_MODULES fails unless all modules are found), and the legacy libjson.so name is also used by the other libjson (http://sourceforge.net/projects/libjson/) which provides an incompatible API, so just drop it. Backported from libubox

[PATCH] tools/autoconf: update to 2.70

2021-01-18 Thread Rosen Penev
Refreshed patches. Removed emacs patch as upstream removed emacs completely. Removed musl host patch. Upstream seems to have fixed it differently. Added patch to skip building man pages. Removes help2man host build dependency. Signed-off-by: Rosen Penev --- tools/autoconf/Makefile

Re: jffs2 broken after first reboot

2021-01-18 Thread Patrick Vorlicek
Typical case of rubber duck debugging, sorry for bothering the list. I just realized that I had enabled FSTOOLS_OVL_MOUNT_COMPRESS_ZLIB which seems to cause the issue. @john maybe you want to look into this? Can I be of any help? Viele Grüße, Patrick Vorlicek Am 18.01.2021 um 19:59 schrieb

jffs2 broken after first reboot

2021-01-18 Thread Patrick Vorlicek
I hope someone can give me a hint where to look for the source of this issue. First boot is fine, jffs2 is created an mounted as overlay: [   16.379847] block: unable to load configuration (fstab: Entry not found) [   16.386627] block: no usable configuration [   16.391956] mount_root: jffs2 not

Re: [PATCH] autoconf: update to 2.70

2021-01-18 Thread Paul Spooren
On So, Jan 17, 2021 at 17:50, Rosen Penev wrote: Refreshed patches. Removed emacs patch as upstream removed emacs completely. Removed musl host patch. Upstream seems to have fixed it differently. Signed-off-by: Rosen Penev --- Please disable the doc building, at least that's how I

Re: [PATCH 2/2] bcm4908: build flashable & bootable firmware images

2021-01-18 Thread Rafał Miłecki
On 2021-01-18 12:50, Adrian Schmutzler wrote: > Note that if you do apply these two "changes", you get rid of the > COMPATIBLE variable at all for the proposed patch, and this is > probably the reason why a variable like this is not needed for "build > steps" in the other targets (at least those

RE: [PATCH 2/2] bcm4908: build flashable & bootable firmware images

2021-01-18 Thread Adrian Schmutzler
> > Note that if you do apply these two "changes", you get rid of the > > COMPATIBLE variable at all for the proposed patch, and this is > > probably the reason why a variable like this is not needed for "build > > steps" in the other targets (at least those I know closer by now), > > which simply

Re: [PATCH 2/2] bcm4908: build flashable & bootable firmware images

2021-01-18 Thread Rafał Miłecki
On 2021-01-18 12:29, Adrian Schmutzler wrote: Do you mean "files" as "directories" (I know every dir is a file ;) )? If you talk about "asus,gt-ac5300", it's used by the: cp -r $(COMPATIBLE)/* $@-bootfs/ line in the Build/bcm4908img. Ah, okay. Yes, I was referring to the directory names here.

RE: [PATCH 2/2] bcm4908: build flashable & bootable firmware images

2021-01-18 Thread Adrian Schmutzler
> Do you mean "files" as "directories" (I know every dir is a file ;) )? If you > talk > about "asus,gt-ac5300", it's used by the: > cp -r $(COMPATIBLE)/* $@-bootfs/ > line in the Build/bcm4908img. Ah, okay. Yes, I was referring to the directory names here. I personally consider a comma in a

[no subject]

2021-01-18 Thread Etan Kissling 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 --- This allows libnetfilter_queue to

[no subject]

2021-01-18 Thread Etan Kissling 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 --- Switch to normal tarballs for

[PATCH V2] bcm4908: build flashable & bootable firmware images

2021-01-18 Thread Rafał Miłecki
From: Rafał Miłecki BCM4908 bootloader requires firmware with JFFS2 image containing: 1. cferam.000 2. 94908.dtb 3. vmlinux.lz 4. device custom files cferam.000 can be obtained from the bcm63xx-cfe repository. It requires specifying directory path that is defined using COMPATIBLE variable. For

[no subject]

2021-01-18 Thread Etan Kissling 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 --- This adds a config option to

[no subject]

2021-01-18 Thread Etan Kissling 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 --- This enables the CTRL_IFACE_MIB

[no subject]

2021-01-18 Thread Etan Kissling 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 --- This allows configuration of

[no subject]

2021-01-18 Thread Etan Kissling 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 --- This adds a config option to

Re: [PATCH] iperf3: move over to packages.git

2021-01-18 Thread Paul Spooren
On Mo, Jan 18, 2021 at 08:05, Florian Eckert wrote: That package is not required for building OpenWrt so the maintenance should happen over at packages.git. Sounds about right. I think most people prefer to use iperf anyway... But then I would also move the iperf package to the package