Re: [PATCH] CMake: bump the minimum required CMake version to 3.5
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 ---
On Fri, Jan 12, 2024 at 8:51 AM wrote:
>
> From: Yegor Yefremov
>
> Older CMake versions are marked as deprecated and generate
> the related warning:
>
> Compatibility with CMake < 3.5 will be removed from a future
> version of CMake.
>
> Signed-off-by: Yegor Yefremov
> ---
> CMakeLists.txt | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 8e86bd4..a3eaf65 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -1,11 +1,9 @@
> -cmake_minimum_required(VERSION 2.6)
> +cmake_minimum_required(VERSION 3.5)
>
> PROJECT(netifd C)
>
> -IF(NOT ${CMAKE_VERSION} LESS 3.0)
> - include(CheckCCompilerFlag)
> - check_c_compiler_flag(-Wimplicit-fallthrough HAS_IMPLICIT_FALLTHROUGH)
> -ENDIF()
> +include(CheckCCompilerFlag)
> +check_c_compiler_flag(-Wimplicit-fallthrough HAS_IMPLICIT_FALLTHROUGH)
>
> ADD_DEFINITIONS(-Wall -Werror)
> IF(CMAKE_C_COMPILER_VERSION VERSION_GREATER 6)
> --
> 2.34.1
Forgot to add netifd to the subject string.
Yegor
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] CMake: bump the minimum required CMake version to 3.5
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 ---
From: Yegor Yefremov
Older CMake versions are marked as deprecated and generate
the related warning:
Compatibility with CMake < 3.5 will be removed from a future
version of CMake.
Signed-off-by: Yegor Yefremov
---
CMakeLists.txt | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8e86bd4..a3eaf65 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,11 +1,9 @@
-cmake_minimum_required(VERSION 2.6)
+cmake_minimum_required(VERSION 3.5)
PROJECT(netifd C)
-IF(NOT ${CMAKE_VERSION} LESS 3.0)
- include(CheckCCompilerFlag)
- check_c_compiler_flag(-Wimplicit-fallthrough HAS_IMPLICIT_FALLTHROUGH)
-ENDIF()
+include(CheckCCompilerFlag)
+check_c_compiler_flag(-Wimplicit-fallthrough HAS_IMPLICIT_FALLTHROUGH)
ADD_DEFINITIONS(-Wall -Werror)
IF(CMAKE_C_COMPILER_VERSION VERSION_GREATER 6)
--
2.34.1
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Dave Taht wrote: > So I at least do not feel a huge urge to get on the 6ghz bandwagon at > this time. I would actually, be happy cutting even more multiplexing > latency out of the ath9k chips, and there is much fat left to be cut > from the mt79 also, and the benefits of many people focused on building > on top of a single stable *inexpensive* platform and working all the > bugs out of it - that has a lot of shared characteristics with the > higher end gear - cannot be underestimated. I still have wndr3800s > running for years at a time, running openwrt. +1. signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenSSH dropping DSA
https://lists.mindrot.org/pipermail/openssh-unix-announce/2024-January/000156.html OpenSSH dropping DSA 2024/06 disabled 2025/01 code removal ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Hi Forest, On 10.01.2024 15:18, Forest Crossman wrote: On Tue, Jan 9, 2024 at 4:52 AM John Crispin wrote: ---SNIP--- * Why is there no USB 3.x host port on the device? - the USB 3.x and PCIe buses are shared in the selected SoC silicon, hence only a single High-Speed USB port is available Perhaps you've already considered this, but it may be possible to route the shared PCIe/USB 3 traces to both an M.2 slot and a USB 3 host port using a high-speed dual-channel differential 1:2/2:1 switch/mux. It wouldn't enable both interfaces to be used at the same time, but it would make it possible to select which interface is enabled using a GPIO pin. Then U-boot could either automatically enable one port or the other depending on what devices it detects (e.g., enable PCIe and disable USB 3 if a PCIe device is connected, otherwise enable USB 3 and disable PCIe), or it could be statically configurable via a U-boot environment variable. I suppose this should work (I couldn't find anything which would prevent using pure h/w analog mux on the bus with a runtime configuration) but I don't think there is a way to actually test it without a custom hardware (usually anything which doesn't exist in reference design/s from the chipset vendor must be tested in target configuration). Assuming bus speeds we are talking here about, I'm not sure this can be tested with some home-based tinkering ;) I'm afraid that might delay the project but I will ask around. From some quick searching, the switches/muxes that would enable this cost less than $1 each in qty. 1000. For a <$100 product I understand that may be too much of an increase to the BoM cost and PCB complexity, but I think users would really appreciate being able to choose between being able to add an M.2 SSD, WiFi card, or SATA controller and being able to plug in a USB 3.x 2.5 GbE adapter, SSD/flash drive, WiFi dongle, or 5G modem. This would also require a bit more current capacity in the USB Type-A connector if we decide to make it 3.x. -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
John hello. I like this project quite a lot. I'm very excited to see it happen and would love to be involved! The company I work with, Xeront, has some PCB designs of their own. I can happily connect you with folks for any discussions about the electronic engineering and manufacturing aspects of the project, should you need. We're here to help! On 9.01.2024 13:49, John Crispin wrote: How will the device be distributed? OpenWrt itself cannot handle this for a ton of reasons. This is why we spoke with the SFC early. The idea is that BPi will distribute the device using the already established channels and for every device sold a donation will be made to ourSFC earmarked fund for OpenWrt. This money can then be used to cover hosting expenses or maybe an OpenWrt summit. I've been organising an OpenWrt summit in Cyprus along with Battlemesh v16 in May. I've been coordinating with Hauke on this. I've made a small announcement here [1] giving out the dates for the summit, 18-19 May 2024. This project would be a great talking point for the summit. If you or anyone on the list can give us a hand with funding the event, and finding local folks to help in the field, that'd be great. [1] http://lists.openwrt.org/pipermail/openwrt-devel/2023-December/041957.html Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
