Re: [PATCH] system-notification: initial checkin
Hello Enrico, Thanks for your feedback! I think the idea can be nice, however I would like to make sure that thismechanism can be ignored by an admin with no consequences. This is only informative. I see this especially in connection with the LuCI. So that events that happens on the system can be displayed. I already have a small app for this [1]. Is this the case? In other words - if I store 20 messages with maximum allowed amount of text in all strings, how much data am I storing? There is currently only the restriction that the number of messages is limited to 20. This can be reduced or increased. I can't say how much memory this takes up. I haven't thought about that yet. We can also limit this, so that the message may only have a certain length Furthermore, I suggest calling both the rpcd plugin and the user-facing script with the same name. That is indirectly the case. The script is called 'system-notification' and the ubus backend is called 'system.notification'. I didn't want to call it only 'notification' now, because it might already be taken. The name 'notification' is very common. And - di I miss it or you can not actually create a notification from the user-facing script? Why not implement that as well? I have deliberately not implemented this, because I am not sure how to do it, as the message can become relatively long. The creation of the notification will probably be the system via a bus call. -- Florian Eckert [1] https://github.com/TDT-AG/luci/commit/aa4b0425206448f1336dc7a94fe31c4cc089a0c9 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] firmware-utils: add required PKG_BUILD_DEPENDS
On 1.06.2023 17:40, Rafał Miłecki wrote: From: Rafał Miłecki This project provides a lot of independent utils. Most of them don't depend on SSL (or zlib). Build process however compiles all of them including those few that require SSL/ZLIB. To make copmilation step always succeed it's needed to specify build time dependencies. Runtime dependencies will be handled per-package (if we ever package one of those needing SSL/ZLIB). This fixes: -- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR) -- Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR (missing: OPENSSL_CRYPTO_LIBRARY OPENSSL_INCLUDE_DIR) CMake Error at CMakeLists.txt:9 (MESSAGE): Unable to find zlib library. While I like my own commit description a lot ;) this PATCH been obsoleted by the commit 6f607ba043cdc996cd113b8dc25b6965dc1d9a41 Author: Tianling Shen Date: Thu Jun 1 17:35:16 2023 +0800 firmware-utils: add missing build dependencies ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH RESEND] ath79: replace "mac-address-ascii" with "mac-base"
From: Rafał Miłecki
With upstream accepted "mac-base" binding there is no need for a
downstream "mac-address-ascii" workaround anymore.
Signed-off-by: Rafał Miłecki
---
RESEND: I originally CC-ed 13 people and ML stopped my e-mail
---
.../ath79/dts/ar7161_dlink_dir-825-b1.dts | 57 +++
.../linux/ath79/dts/ar9331_hiwifi_hc6361.dts | 37 ++--
.../linux/ath79/dts/ar9342_zyxel_nwa11xx.dtsi | 28 +
.../linux/ath79/dts/ar9344_dlink_dir-8x5.dtsi | 42 --
.../ath79/dts/qca9558_dlink_dir-629-a1.dts| 32 +++
.../ath79/dts/qca9563_dlink_dir-8x9-a1.dtsi | 31 ++
6 files changed, 134 insertions(+), 93 deletions(-)
diff --git a/target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts
b/target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts
index 0e39be7d0b..bdb678298d 100644
--- a/target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts
+++ b/target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts
@@ -139,8 +139,8 @@
ath9k0: wifi@0,11 {
compatible = "pci168c,0029";
reg = <0x8800 0 0 0 0>;
- nvmem-cells = <&macaddr_lan>, <&cal_art_1000>;
- nvmem-cell-names = "mac-address-ascii", "calibration";
+ nvmem-cells = <&macaddr_lan 0>, <&cal_art_1000>;
+ nvmem-cell-names = "mac-address", "calibration";
#gpio-cells = <2>;
gpio-controller;
};
@@ -148,9 +148,8 @@
ath9k1: wifi@0,12 {
compatible = "pci168c,0029";
reg = <0x9000 0 0 0 0>;
- nvmem-cells = <&macaddr_wan>, <&cal_art_5000>;
- nvmem-cell-names = "mac-address-ascii", "calibration";
- mac-address-increment = <1>;
+ nvmem-cells = <&macaddr_wan 1>, <&cal_art_5000>;
+ nvmem-cell-names = "mac-address", "calibration";
#gpio-cells = <2>;
gpio-controller;
};
@@ -191,23 +190,31 @@
label = "caldata";
reg = <0x66 0x01>;
read-only;
- #address-cells = <1>;
- #size-cells = <1>;
- cal_art_1000: cal@1000 {
- reg = <0x1000 0xeb8>;
- };
-
- cal_art_5000: cal@5000 {
- reg = <0x5000 0xeb8>;
- };
-
- macaddr_lan: macaddr@ffa0 {
- reg = <0xffa0 0x11>;
- };
-
- macaddr_wan: macaddr@ffb4 {
- reg = <0xffb4 0x11>;
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cal_art_1000: cal@1000 {
+ reg = <0x1000 0xeb8>;
+ };
+
+ cal_art_5000: cal@5000 {
+ reg = <0x5000 0xeb8>;
+ };
+
+ macaddr_lan: macaddr@ffa0 {
+ compatible = "mac-base";
+ reg = <0xffa0 0x11>;
+ #nvmem-cell-cells = <1>;
+ };
+
+ macaddr_wan: macaddr@ffb4 {
+ compatible = "mac-base";
+ reg = <0xffb4 0x11>;
+ #nvmem-cell-cells = <1>;
+ };
};
};
@@ -224,8 +231,8 @@
pll-data = <0x 0x1099 0x00991099>;
- nvmem-cells = <&macaddr_lan>;
- nvmem-cell-names = "mac-address-ascii";
+ nvmem-cells = <&macaddr_lan 0>;
+ nvmem-cell-names = "mac-address";
fixed-link {
speed = <1000>;
@@ -238,8 +245,8 @@
pll-data = <0x 0x1099 0x00991099>;
- nvmem-cells = <&macaddr_wan>;
- nvmem-cell-names = "mac-address-ascii";
+ nvmem-cells = <&macaddr_wan 0>;
+ nvmem-cell-names = "mac-address";
phy-handle = <&phy4>;
};
diff --git a/target/linux/ath79/dts/ar9331_hiwifi_hc6361.dts
b/target/linux/ath79/dts/ar9331_hiwifi_hc6361.dts
index 05d3f6730e..fa000ab90c 100644
--- a/target/linux/ath79/dts/ar9331_hiwifi_hc6361.dts
+++ b/target/linux/ath79/dts/ar9331_hiwifi_hc6361.dts
@@ -77,9 +77,22 @
Re: mips: Make mips64 n32/o32 userland possible or remove support completely
On Wed, Jul 19, 2023 at 1:29 AM Jeffery To wrote:
>
> Hi,
>
> I've been looking into platform triplets for Python and figuring out
> the possible combinations. This has led me to trying to compile images
> of the possible combinations for testing.
>
> As a result, I've been trying to compile malta/be64 with n32/o32
> userland. I haven't been successful so far but before trying to fix
> all the issues, I wanted to take a step back and ask a more general
> question.
>
> I see there is the option to select mips64 ABI in toolchain/Config.in.
> On the other hand, there are commits like 46af22de16b2 ("kernel:
> Remove CONFIG_COMPAT") and 38666e8ae42d ("malta: Deactivate MIPS O32
> and N32 support") (and also the recent discussion with amd64 x32
> support).
>
> Is there a preference to make n32/o32 userland optional/possible, and
> so I should continue trying to get it to work? Or is the preference to
> remove support completely, so I should submit patches to do so?
I think remove support.
Ideally some of these mips platforms should use a more common set of
binaries, but there seems to be no one trying that.
>
> Thanks,
> Jeff
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
22.03 packages not building since 10 days
Hi all, Can a kind soul please check the build bots for 22.03 packages? We pushed some security fixes about a week ago for pjsip and were hoping they'd be packaged by now. Thanks! Seb ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] toolchain: kernel-headers: fix check target for external Git trees
Executing following command currently fails:
$ make toolchain/kernel-headers/{download,check} V=sc FIXUP=1
...
include/kernel-version.mk:11: *** Missing kernel version/hash file for .
Please create include/kernel-. Stop.
So lets fix it by adding the necessary missing KERNEL_PATCHVER variable.
That additional kernel-build.mk include is needed to add another set of
missing variables:
$ make toolchain/kernel-headers/{download,check} V=sc FIXUP=1
...
Makefile:115: *** ERROR: Unknown pack format for file tmp/dl/. Stop.
Fixes: 0765466a42f4 ("kernel: split kernel version to dedicated files")
Signed-off-by: Petr Štetiar
---
toolchain/kernel-headers/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/toolchain/kernel-headers/Makefile
b/toolchain/kernel-headers/Makefile
index c1a8710a4fbe..5e3e459a96f5 100644
--- a/toolchain/kernel-headers/Makefile
+++ b/toolchain/kernel-headers/Makefile
@@ -23,7 +23,10 @@ ifneq ($(call qstrip,$(CONFIG_KERNEL_GIT_CLONE_URI)),)
PKG_SOURCE_VERSION:=$(call qstrip,$(CONFIG_KERNEL_GIT_REF))
PKG_MIRROR_HASH:=$(call qstrip,$(CONFIG_KERNEL_GIT_MIRROR_HASH))
ifdef CHECK
+ PLATFORM_DIR:=$(firstword $(wildcard $(TOPDIR)/target/linux/feeds/$(BOARD)
$(TOPDIR)/target/linux/$(BOARD)))
+ include $(PLATFORM_DIR)/Makefile
include $(INCLUDE_DIR)/kernel-version.mk
+ include $(INCLUDE_DIR)/kernel-build.mk
PKG_VERSION:=$(LINUX_VERSION)
else
PKG_SOURCE:=$(LINUX_SOURCE)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] toolchain: kernel-headers: remove debugging env dump
Remove debugging `env` dump left over as build environments might
contain some sensitive information, which then might leak into the build
logs.
Fixes: 2105acbe2804 ("kernel-headers: fix compile error caused by wrong host
include path when the toolchain is already built")
Signed-off-by: Petr Štetiar
---
toolchain/kernel-headers/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/toolchain/kernel-headers/Makefile
b/toolchain/kernel-headers/Makefile
index 5e3e459a96f5..8e3324816bfa 100644
--- a/toolchain/kernel-headers/Makefile
+++ b/toolchain/kernel-headers/Makefile
@@ -93,7 +93,6 @@ define Host/Prepare
endef
define Host/Configure
- env
yes '' | $(HOST_KMAKE) oldconfig
$(call Host/Configure/all)
$(call Host/Configure/post/$(ARCH))
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH urngd] jitterentropy-rngd: update to the v1.2.0
From: Rafał Miłecki 74104b2 update copyright date 1b5f34b integrate library v3.0.0 8a43ce4 Fix permissions set by systemd unit file f995407 force the kernel to reseed the ChaCha20 DRNG 4104015 force reseed after 10 minutes 9d61de7 jitterentropy-rngd.1: spelling 739bcba Add Dockerfile and docker-compose.yaml for easy deployment. cc8c38c Harden systemd service Signed-off-by: Rafał Miłecki --- 3rdparty/jitterentropy-rngd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/3rdparty/jitterentropy-rngd b/3rdparty/jitterentropy-rngd index cb13a8b..74104b2 16 --- a/3rdparty/jitterentropy-rngd +++ b/3rdparty/jitterentropy-rngd @@ -1 +1 @@ -Subproject commit cb13a8b136afe9e1ea1424e9e3fb50c87a6be729 +Subproject commit 74104b218442d9b9049249e6d1b132db564b77da -- 2.35.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] system-notification: initial checkin
Hi! I think the idea can be nice, however I would like to make sure that thismechanism can be ignored by an admin with no consequences. Is this the case? In other words - if I store 20 messages with maximum allowed amount of text in all strings, how much data am I storing? Furthermore, I suggest calling both the rpcd plugin and the user-facing script with the same name. And - di I miss it or you can not actually create a notification from the user-facing script? Why not implement that as well? And I didn't look for flushing capability but I would like that as well. Thanks! Enrico ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
