Host dependencies and checking them
Hi all, When starting a clean build (21.02 branch) on a clean Fedora 33 machine, I ran into the small issue of tools/autoconf failing to build. This was due to perl-File-Compare missing. I apparently missed that prerequisite. After installing said package, everything built fine. Looking at the instructions at https://openwrt.org/docs/guide-developer/build-system/install-buildsystem#prerequisites, listing all prerequisites, I at first did not find perl-File-Compare. It was only at the distribution specific instructions for CentOS/Fedora that it was mentioned. The main list does specifically mention perl-ExtUtils-MakeMaker and perl-Thread-Queue, so I wonder whether perl-File-Compare should be added there as well? Another question regarding prerequisites: is python2 still a requirement for master and openwrt-21.02? Anyway, it made me wonder whether the prerequisites list and test for at least the core should be revised. I took a look at the current list and compared them to include/prereq-build.mk from current (2021-02-20) openwrt-21.02 branch: PREREQ prereq-build.mk needed result == asciidocno no? Q bashyes yes OK binutilsno yes ADD bzip2 yes yes OK flexno hostbuild -> no REMOVE git yes yes OK g++ yes (no IB) yes OK gcc yes (no IB) yes OK timeno no? Q getopt yes yes OK gawkyes yes OK help2manno no? Q intltool-update no no? Q libelf-dev no yes ADD libz-devno yes ADD makeyes yes OK ncurses yes yes OK openssl no util&lib? Q patch yes yes OK perl ExtUtils- MakeMaker no ? Q perl Thread- Queue yes ? Q python2-dev no no >19.07? Q unzip yes yes OK wgetyes yes OK xgettextno yes ADD xsltprocno no REMOVE zlibno yes ADD The file prereq-build.mk does check for a number of other utilities that are not in the list or only in the distribution specific requirements: Perl Data::Dumper tar find xargs seq grep stat perl (5.x) python (>=3.5) file rsync Looking at the distro specific instructions, I noticed a variation in the advised mandatoty and optional packages to install per distro. For example, some install asciidoc, other ccache and so on. I would like to help cleaning this up, both the code and the documentation. What I need is input on what are mandatory and what are optional prerequisites (and a login to the wiki). Regards, Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Quilt and cutting down diff position lines
On 2021-02-24 15:36, Adrian Schmutzler wrote: -Original Message- From: Adrian Schmutzler [mailto:m...@adrianschmutzler.de] Sent: Mittwoch, 24. Februar 2021 11:50 To: 'openwrt-devel@lists.openwrt.org' Subject: Quilt and cutting down diff position lines Hi, as most are probably aware, quilt cuts down the position lines in patches during refresh: - @@ -78,7 +78,8 @@ void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr), + @@ -78,7 +78,8 @@ void machine_apply_elf_rel(struct mem_eh While this has no functional impact, it creates a lot of additional spam during checkpatch.pl, and it makes these lines less useful for the frequent cases where the relevant (meaning "specific") information is at the end of that line (i.e. when looking at patches directly). Apart from that, this also bloats diffs in packages when people add proper patches, and quilt will then just cut down these lines without a change in position. I wonder whether quilt can be convinced to not cut this line (did not find any helpful guidance so far), and whether one wants to change that if it's possible? Well, after a lengthy quest into the world of quilt, I found that this is actually a diff "bug", since diff hardcodes the context function to 40 characters max: https://git.savannah.gnu.org/cgit/diffutils.git/tree/src/context.c#n156 And since this is a prerequisite the user installs on the host, we cannot do much about it either, as it appears. Openwrt could provide a host build for a patched version of diff and use that instead. Best Adrian ___ 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
Re: [PATCH] ramips: add support for TOTOLINK X5000R
Hi,
Thanks for creating this patch. Got my X5000R today. Before flashing it
to OpenWRT, can you please tell me whether you (or anyone else) did
performance measurements with the original and the OpenWRT firmware?
I measured over 600mbit/s with WPA3 when on my desk, next to a notebook
with Intel WiFi6 AX200 card. So I hope I can keep that performance when
on OpenWRT.
(measured with iperf3, tcp default settings, from wireless 5GHz to PC
wired to WAN in both directions)
Many thanks in advance,
Bas.
On 10/21/20 7:21 AM, Chuanhong Guo wrote:
Specifications:
- SoC: MT7621AT
- RAM: 256MB
- Flash: 16MB (EN25QH128A)
- Ethernet: 5xGbE
- WiFi: MT7915 2x2 2.4G 573.5Mbps + 2x2 5G 1201Mbps
Known issue:
MT7915 DBDC variant isn't supported yet.
Flash instruction:
Upload the sysupgrade firmware to the firmware upgrade page in
vendor fw.
Other info:
MT7915 seems to have two PCIEs connected to MT7621. Card detected on
PCIE0 has an ID of 14c3:7916 and the other one on PCIE1 has 14c3:7915.
Signed-off-by: Chuanhong Guo
---
.../ramips/dts/mt7621_totolink_x5000r.dts | 139 ++
target/linux/ramips/image/mt7621.mk | 10 ++
2 files changed, 149 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_totolink_x5000r.dts
diff --git a/target/linux/ramips/dts/mt7621_totolink_x5000r.dts
b/target/linux/ramips/dts/mt7621_totolink_x5000r.dts
new file mode 100644
index 00..b05d83978d
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_totolink_x5000r.dts
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "totolink,x5000r", "mediatek,mt7621-soc";
+ model = "TOTOLINK X5000R";
+
+ aliases {
+ led-boot = &led_sys;
+ led-failsafe = &led_sys;
+ led-running = &led_sys;
+ led-upgrade = &led_sys;
+ label-mac-device = &gmac0;
+ serial0 = &uartlite;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ bootargs = "console=ttyS0,115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_sys: sys {
+ label = "blue:sys";
+ gpios = <&gpio 18 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ linux,code = ;
+ };
+ };
+};
+
+&spi0 {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+ m25p,fast-read;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "u-boot-env";
+ reg = <0x3 0x1>;
+ read-only;
+ };
+
+ factory: partition@4 {
+ label = "factory";
+ reg = <0x4 0x1>;
+ read-only;
+ };
+
+ partition@5 {
+ compatible = "denx,uimage";
+ label = "firmware";
+ reg = <0x5 0xfb>;
+ };
+ };
+ };
+};
+
+&pcie {
+ status = "okay";
+};
+
+&pcie1 {
+ wifi@0,0 {
+ compatible = "mediatek,mt76";
+ reg = <0x 0 0 0 0>;
+ mediatek,mtd-eeprom = <&factory 0x>;
+ };
+};
+
+&gmac0 {
+ mtd-mac-address = <&factory 0xe000>;
+};
+
+&switch0 {
+ ports {
+ port@0 {
+ status = "okay";
+ label = "lan1";
+ };
+
+ port@1 {
+ status = "okay";
+ label = "lan2";
+ };
+
+ port@2 {
+ status = "okay";
+ label = "lan3";
+ };
+
+ port@3 {
+ status = "okay";
+ label = "lan4";
+ };
+
+ port@4 {
+ status = "okay";
+ label = "wan";
+ mtd-mac-address = <&factory 0xe0
Re: [PATCH] ramips: add support for TOTOLINK X5000R
Hi, On 3/13/21 3:21 AM, Chuanhong Guo wrote: Hi! On Sat, Mar 13, 2021 at 7:27 AM Bas Mevissen wrote: Hi, Thanks for creating this patch. Got my X5000R today. Before flashing it to OpenWRT, can you please tell me whether you (or anyone else) did performance measurements with the original and the OpenWRT firmware? The wifi chip used in this router wasn't supported by mt76 when I created this patch, so my X5000R has no wifi now and I don't have any wireless performance numbers. My X5000R has been sitting on the shelf since I posted this patch, and I don't even know whether the mt7915d used in this router is supported now or not. You should probably ask TOTOLINK for a copy of the original firmware image before trying OpenWrt, so that you can go back to the original firmware if needed. (A forced sysupgrade from OpenWrt using their firmware image should work.) Thanks for the detailed explanation! As probably no one tried reverting to the stock firmware, I'm a bit reluctant to do so. Although I intended this router as a playground, I now consider using it as AP for a while. As my TP-Link Archer C7's wifi isn't performing that well with OpenWRT as I hoped, I want the X5000R to take its place with the factory firmware until that gets sorted out. I might even end up buying another X5000R if the Archer cannot be faster, but it takes 6 weeks for the Totolink to arrive. So would you be so kind to flash your X5000R with a recent build and check whether the wifi performs well? It would help me a lot. I can supply you with a build if that helps. Many thanks in advance, Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt Summit CFP
On 03/10/2017 02:21, Valent Turkovic wrote: Why is http://www.openwrtsummit.org/ down for over 24h? Site looks fine for me. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Boot Time Reduction
On 12/04/18 06:26, Arjav Parikh wrote: Hi, > (...) Now as mentioned in previous mail only at that two locations I see some process consuming lot of time. Is it possible to reduce the time consumed by the process? Isn't the long time between pre-init and ubi mount due to the lengthy block scan that the ubi layer performs? In that case, switching to squashfs with optionally an overlay might reduce the mount time. -- Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Moving the mailing lists
On 23/05/18 17:55, Arjen de Korte wrote: Citeren Torbjörn Jansson : (...) But one thing that is a little anoying after the move is that for some mails I get same thing twice and I'm not sure why. Most likely because people are still cross-posting to lede-dev and openwrt-devel (like you just did). Being the same list now, this means you'll get the same thing twice. I would suggest closing the lede-devel mailing list with a bounce to use openwrt-devel instead. Or have a filter that removes the duplicates as it is really annoying. -- Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH lede-17.01 2/4] mbedtls: Activate the session cache
On 02/06/18 18:10, Hauke Mehrtens wrote: This make sit possible to store informations about a session and reuse it later. When used by a server it increases the time to create a new TLS session from about 1 second to less than 0.1 seconds. ...it *decreases* the time to... The size of the ipkg file increased by about 800 Bytes. Signed-off-by: Hauke Mehrtens --- package/libs/mbedtls/patches/200-config.patch | 10 -- 1 file changed, 10 deletions(-) diff --git a/package/libs/mbedtls/patches/200-config.patch b/package/libs/mbedtls/patches/200-config.patch index ff5d29a066..538a6d1087 100644 --- a/package/libs/mbedtls/patches/200-config.patch +++ b/package/libs/mbedtls/patches/200-config.patch @@ -219,16 +219,6 @@ /** * \def MBEDTLS_RSA_C -@@ -2446,8 +2446,8 @@ - * Caller: - * - * Requires: MBEDTLS_SSL_CACHE_C -- */ - #define MBEDTLS_SSL_CACHE_C -+ */ - - /** - * \def MBEDTLS_SSL_COOKIE_C @@ -2468,8 +2468,8 @@ * Caller: * -- Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WAN bouncing at boot
On 08/09/2014 04:13 AM, Weedy wrote: > On Sun, Jul 27, 2014 at 3:31 PM, Weedy wrote: >> Is there anything I can do to stop this? It started sometime in the >> last 6months of trunk. >> Right after this and couple minutes after boot my healing script fires >> and detects that WAN is broken and calls ifdown; sleep; ifup at which >> point I get an IP and keep it. But why it the WAN goinig up and down >> during boot? >> Difficult to help you without any information about the platform. You might go back in time and track down the change that caused the issue by bisection. Can take some time to execute, but is feasible when the problem is reproducible. Beware that when going back in time with the sources, you must force recompilation. > > bump. Not really useful to do a full quote of the original message. Waste of bandwidth. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] build failure for Asus WL-500GP
On 08/28/2014 12:10 PM, Peter Münster wrote:
> Hi,
>
> With latest git version, there is a build failure:
>
> --8<---cut here---start->8---
> find
> /home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/linux-3.14.16
>
> /home/peter/soft/wl-500gp/staging_dir/target-mipsel_mips32_uClibc-0.9.33.2/root-brcm47xx/lib/modules
> -name \*.ko | xargs mipsel-openwrt-linux-uclibc-nm | awk '$1 == "U" { print
> $2 } ' | sort -u >
> /home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/mod_symtab.txt
> mipsel-openwrt-linux-uclibc-nm -n
> /home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/linux-3.14.16/vmlinux.o
> | grep -F ' r __ksymtab' | sed -e 's, r __ksymtab_,,' >
> /home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/kernel_symtab.txt
> grep -Ff
> /home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/mod_symtab.txt
>
> /home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/kernel_symtab.txt
> >
> /home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/sym_include.txt
> make[4]: ***
> [/home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/symtab.h]
> Error 1
> make[4]: Leaving directory `/home/peter/soft/wl-500gp/target/linux/brcm47xx'
> make[3]: *** [install] Error 2
> make[3]: Leaving directory `/home/peter/soft/wl-500gp/target/linux'
> make[2]: *** [target/linux/install] Error 2
> make[2]: Leaving directory `/home/peter/soft/wl-500gp'
> make[1]: ***
> [/home/peter/soft/wl-500gp/staging_dir/target-mipsel_mips32_uClibc-0.9.33.2/stamp/.target_install]
> Error 2
> make[1]: Leaving directory `/home/peter/soft/wl-500gp'
> make: *** [world] Error 2
> --8<---cut here---end--->8---
>
> linux-brcm47xx_generic/kernel_symtab.txt is empty.
>
Hi Peter,
Tried newly checked out tree (SVN r42398) with the default config for
WL500GPv1. Don't suspect any difference between SVN and GIT trees.
make[2] package/install
make[3] package/preconfig
make[2] target/install
make[3] -C target/linux install
make[6] -C target/linux/brcm47xx/image/lzma-loader clean install
make[2] package/index
real20m18.881s
user39m8.944s
sys 4m19.241s
Seems to build fine. Nightlies on openwrt.org
(https://downloads.openwrt.org/snapshots/trunk) are fine too. So I
suspect the problem to be on your side. Maybe clean your tree or start
all over (saving your changes and .config o/c)
Bas.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] fix the build dependencies for uhttpd and ustream-ssl
On 09/23/2014 09:36 AM, thomas.lan...@lantiq.com wrote: > Hello, > Hi Thomas, > I have to reject my own patch, uhttpd includes the header from ustream > unconditionally, > so the build dependency has to stay. > Can't you patch uhhtpd to conditionally include the header? Would be something to upstream as well. Another solution would be to have the ssl libraries only build (and packaged), but not installed in the image because of this dependency. Not sure how to accomplish this in OpenWRT. Cheers, Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] fix the build dependencies for uhttpd and ustream-ssl
On 09/29/2014 04:32 PM, thomas.lan...@lantiq.com wrote: > Hello Bas, > Hi Thomas, (...) > > My goal was to have the build dependencies reduced for the case no ssl is > enabled. > And that was fixed now with the help of Felix. > It was never an issue that the libraries were included to the image. > Well, including unused libraries is a waste of space and might be against the wish of the image creator. Also, it can be an unwanted export of crypto software too. That problem did not go away after the US changed the rules years ago. Cheers, Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] fix the build dependencies for uhttpd and ustream-ssl
On 09/30/2014 03:22 PM, Felix Fietkau wrote: > I'll repeat the point for clarity: There is no inclusion of unused > libraries going on here - at least not in the image or package repositories. > > uhttpd always needs the header of ustream-ssl, but it does not link > against the library directly (it uses dlopen). > So they (the ssl libraries) only need to be available during build, but don't end up in the image (only) due to this *build* dependency? That is fine indeed. Thanks for clarifying, Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Errors running make xconfig
Hi all, I'm trying to configure my openwrt project with xconfig. This fails with the errors pasted to https://pastebin.com/LJvsAhab (too long to add, summary below). System is Mint 9.2 (Ubuntu Bionic based) with relevant Qt5 stuff installed, including libqt5* (I installed all of them...) and qtbase5-dev. I used OpenWrt latest master, head of openwrt_19.07 branch and v18.06.4 with the same result. I tried to figure out whether the configuration did function as designed: (from scripts/config/Makefile) $ pkg-config --exists Qt5Core && echo Ok Ok $ pkg-config --cflags Qt5Core Qt5Gui Qt5Widgets -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_64-linux-gnu/qt5 $ pkg-config --libs Qt5Core Qt5Gui Qt5Widgets -lQt5Widgets -lQt5Gui -lQt5Core $ pkg-config --variable=host_bins Qt5Core /usr/lib/qt5/bin So it selects Qt5 and finds the required stuff: $ cat scripts/config/.tmp_qtcheck KC_QT_CFLAGS=-std=c++11 -fPIC -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_64-linux-gnu/qt5 KC_QT_LIBS=-lQt5Widgets -lQt5Gui -lQt5Core KC_QT_MOC=/usr/lib/qt5/bin/moc $ gcc --version gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. So it seems the configuration goes fine and everything should be available. Shortened version of the error: make[1]: Entering directory '/home/bas/Workspace/playground/openwrt/scripts/config' CHECK qt qconf.o: In function `ConfigList::metaObject() const': qconf.cc:(.text+0x3ed): undefined reference to `QObjectData::dynamicMetaObject() const' qconf.o: In function `ConfigList::qt_metacast(char const*)': qconf.cc:(.text+0x446): undefined reference to `QTreeWidget::qt_metacast(char const*)' qconf.o: In function `ConfigList::qt_metacall(QMetaObject::Call, int, void**)': qconf.cc:(.text+0x474): undefined reference to `QTreeWidget::qt_metacall(QMetaObject::Call, int, void**)' qconf.o: In function `ConfigList::menuChanged(menu*)': qconf.cc:(.text+0x522): undefined reference to `QMetaObject::activate(QObject*, QMetaObject const*, int, void**)' qconf.o: In function `ConfigList::menuSelected(menu*)': qconf.cc:(.text+0x590): undefined reference to `QMetaObject::activate(QObject*, QMetaObject const*, int, void**)' qconf.o: In function `ConfigList::parentSelected()': qconf.cc:(.text+0x5d1): undefined reference to `QMetaObject::activate(QObject*, QMetaObject const*, int, void**)' qconf.o: In function `ConfigList::gotFocus(menu*)': qconf.cc:(.text+0x62a): undefined reference to `QMetaObject::activate(QObject*, QMetaObject const*, int, void**)' qconf.o: In function `ConfigLineEdit::metaObject() const': qconf.cc:(.text+0x695): undefined reference to `QObjectData::dynamicMetaObject() const' qconf.o: In function `ConfigLineEdit::qt_metacast(char const*)': qconf.cc:(.text+0x6ee): undefined reference to `QLineEdit::qt_metacast(char const*)' qconf.o: In function `ConfigLineEdit::qt_metacall(QMetaObject::Call, int, void**)': qconf.cc:(.text+0x71c): undefined reference to `QLineEdit::qt_metacall(QMetaObject::Call, int, void**)' qconf.o: In function `ConfigView::metaObject() const': qconf.cc:(.text+0x9f7): undefined reference to `QObjectData::dynamicMetaObject() const' qconf.o: In function `ConfigView::qt_metacast(char const*)': qconf.cc:(.text+0xa50): undefined reference to `QWidget::qt_metacast(char const*)' (...) qconf.o: In function `ConfigList::~ConfigList()': qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0x42): undefined reference to `QPalette::~QPalette()' qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0x54): undefined reference to `QPalette::~QPalette()' qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0x66): undefined reference to `QPixmap::~QPixmap()' qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0x78): undefined reference to `QPixmap::~QPixmap()' qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0x8a): undefined reference to `QPixmap::~QPixmap()' qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0x9c): undefined reference to `QPixmap::~QPixmap()' qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0xae): undefined reference to `QPixmap::~QPixmap()' qconf.o:qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0xc0): more undefined references to `QPixmap::~QPixmap()' follow qconf.o: In function `ConfigList::~ConfigList()': qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0xfc): undefined reference to `QTreeWidget::~QTreeWidget()' qconf.o:(.data.rel.ro
Transform OpenWRT to a Yocto / openembedded layer (was: Re: dm-verity support)
On 2020-07-30 09:13, Thomas Petazzoni wrote: Hello, On Thu, 30 Jul 2020 00:17:28 +0200 wrote: your dm-verity patchset is in our patchwork since November 2019 (v2). Unfortunately, nobody seemed to be particularly interested in reviewing/merging it. Since I don't see a reason why this should change in another 8 months, I'm going to finally mark it as Rejected now. After all, our resources are limited. Isn't there some deferred or other state that better expresses the actual situation? I'm sorry, and although I fear a similar fate will hit the SELinux effort, I still hope you will not feel repelled and continue to contribute to OpenWrt in the future. This is overall quite unfortunate. Initially, I have done this work for a customer that was using an old vendor-modified OpenWrt version. Instead of doing like most companies do: simply hack the old vendor-modified OpenWrt and keep the changes private, I instead took an upstream compatible approach: I did all my development on the latest OpenWrt upstream, submitted it to the community, and only then backported it to my customer vendor-specific OpenWrt. It is therefore quite sad that despite this intention of being a good open-source citizen and try to do the "right" thing, OpenWrt as an upstream project is not interested. Such security features are more and more commonly needed, and it will at some point be a problem for OpenWrt to not have such features supported. This is another reason why OpenWRT IMHO should become a Yocto layer (or set of layers preferably). It would relief the OpenWRT community from maintaining a lot of generic infrastructure and open source packages. Freeing up their resources to work on what distinguishes OpenWRT from a generic Linux distribution. Things like dm-verity and SELinux for smaller and targeted embedded devices could than be picked up by the much larger Yocto community and become available for OpenWRT almost for free or there would be at least the benefit of the main infrastructure being there. FYI: there is already such a layer (https://github.com/kraj/meta-openwrt), but still very limited. Best regards, Thomas Petazzoni ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Transform OpenWRT to a Yocto / openembedded layer
On 2020-07-30 11:15, m...@adrianschmutzler.de wrote: -Original Message- From: Bas Mevissen [mailto:ab...@basmevissen.nl] Sent: Donnerstag, 30. Juli 2020 10:54 To: Thomas Petazzoni Cc: m...@adrianschmutzler.de; openwrt-devel@lists.openwrt.org Subject: Transform OpenWRT to a Yocto / openembedded layer (was: Re: dm-verity support) (...) Isn't there some deferred or other state that better expresses the actual situation? For me, "deferred" means essentially "we don't do it now, but we will do it later". However, there is no indication that the situation will be different in a year or two. So I chose "rejected", as a waiting time of 8 months without any response indicate that the feature is not wanted. As Thomas stated himself, this surely is "unfortunate", but I'm just putting into effect what's obvious here. Yes, you probably did the best thing that can be done in this situation: bring it to some kind of closure and inform the submitter of the reason. With the latter being properly done, the actual working of the closure is less relevant. Regards, Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
On 2020-10-04 15:48, abnoeh wrote: Few months ago there was some debate for how we handle certificate for luci page: make user to click though certificate warning is not that great for security so here is a proposal for autometically assign a worldwide unique subdomain and how to make valid certificate for it, and make sure we and connect to the device he is expecting. After reading the previous debate (in part) and this one, I'm wonderering whether we aren't making things more difficult than they need to be. A security conscious user/administrator would install a router without any untrusted computers connected to the LAN side and setup the device properly before allowing others to connect. The WAN side connection is not important, as Luci is not listening there by default. So I think it is reasonably safe to do the initial setup over HTTP (without the "S") at the first boot if there are no certificates available from a previous OpenWRT install. Then the user can setup the WAN side if needed and upload (from local PC), generate (self-signed) or acquire (e.g. Let's Encrypt) the certificates for Luci. After that, the connection is switched to HTTPS and HTTP switched off. The only issue I see, is how to transfer admin, WAN and WiFi passwords at first boot in a secure way. Even though the user/admin should be alone on the connection, sending those unencrypted over the line is not desirable. Maybe those can be encrypted using client side javascript. The challenges IMHO are being able to safely retain previously installed certificates over OpenWRT reflashes/upgrades and having user friendly tools to get new certificates uploaded, generated or acquired. For the latter part, some configurable service to periodically download and install certificates from an external host might be desirable (that's how I do it with my NAS boxes at home). Cheers, Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Fate of kernel 4.19
On 2020-10-09 14:19, Adrian Schmutzler wrote: Hi all, in master, we currently support kernels 5.4 and 4.19. All targets build with 5.4 by default, In other words: 4.19 is no longer required. so 4.19 is just there and can theoretically be used for regression testing In that case, one can retrieve the 4.19 files from just before the removal. (if it still works). Another argument for removal. However, since our last release used 4.14, 4.19 effectively is just an interim step that has never been "released". So most likely, regressions can be tested against the maintained 4.14 with the userspace from master as well. Initially, my plan was to propose removing 4.19 during the RC stage of the next release. As the main effect of 4.19 at the moment seems to be that it's complicating patches/changes, though, I wonder whether that option to do regression testing is actually used by anyone, or whether it's just a theoretical thing that's completely superfluous, as nobody will do it anyway. Based on the response here, one might remove 4.19 even earlier then if nobody actually needs it anymore. Opinions? Is anybody still using 4.19 at least occasionally? I think the only time to support 2 kernel versions in master is when in transition with the targets. Obviously, it would have been nice when 4.19 was actually used in a release. Now it looks like it was wasted effort. Maybe that is a lesson for the future to only put effort in kernels that will be part of a maintained release. Best Adrian Regards, Bas. ___ 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
Re: A proposal of https certificate assignment system for luci
On 2020-10-09 14:33, abnoeh wrote: 20. 10. 9. 오후 8:29에 Bas Mevissen 이(가) 쓴 글: So I think it is reasonably safe to do the initial setup over HTTP (without the "S") at the first boot if there are no certificates available from a previous OpenWRT install. Then the user can setup the WAN side if needed and upload (from local PC), generate (self-signed) or acquire (e.g. Let's Encrypt) the certificates for Luci. After that, the connection is switched to HTTPS and HTTP switched off. The only issue I see, is how to transfer admin, WAN and WiFi passwords at first boot in a secure way. Even though the user/admin should be alone on the connection, sending those unencrypted over the line is not desirable. Maybe those can be encrypted using client side javascript. For things with USB port, firstboot loader script from load ssh autorized key/root password from usb drive and/or export script they when there is '.whoareyou' file touched in usb drive write it's ssh host key and it's self signed certificate into the usb drive? I think later can be part of hotplug.d script. Nice idea to be able to auto-load the config including key material. Might be very useful for larger installs. The challenges IMHO are being able to safely retain previously installed certificates over OpenWRT reflashes/upgrades and having user friendly tools to get new certificates uploaded, generated or acquired. For the latter part, some configurable service to periodically download and install certificates from an external host might be desirable (that's how I do it with my NAS boxes at home). for sysupgrade, like save config option, add new save-keys option that only save dropbear key and uhttpd certs? Nice idea to save SSH server keys as well. That will avoid warnings when connecting to the new box (at the same IP) for the first time. Obviously, one needs to be careful with plain text private keys and certs. Cheers, Bas. ___ 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
On 2020-10-11 00:58, Michael Richardson wrote: Bas Mevissen wrote: > A security conscious user/administrator would install a router without any > untrusted computers connected to the LAN side and setup the device properly > before allowing others to connect. The WAN side connection is not important, > as Luci is not listening there by default. sure. What do security unconcious people do? Just put it in use with the build-in defaults. It is not without reason that ISP routers nowadays come with a semi-unique SSID and securely generated wifi passwords. With OpenWRT we should aim to get the best possible security with the least effort (on user side) possible. ISP routers usually only support HTTP or HTTPS with a self-signed bogus certificate for the admin interface. > previous OpenWRT install. Then the user can setup the WAN side if needed and > upload (from local PC), generate (self-signed) or acquire (e.g. Let's > Encrypt) the certificates for Luci. After that, the connection is switched to > HTTPS and HTTP switched off. This is a a good story, but it doesn't have to be the only story. It is the story where we can give the best out-of-the-box guidance and hopefully cover most installs. > The only issue I see, is how to transfer admin, WAN and WiFi passwords at > first boot in a secure way. Even though the user/admin should be alone on the > connection, sending those unencrypted over the line is not desirable. Maybe > those can be encrypted using client side javascript. There is nothing you can with javascript here that wouldn't just be security threatre. If you had anchors you could trust, then it would be done. The trust comes from being the only one connected to the specific box. If that is not guaranteed, it is very hard to impossible to be 100% sure. It at least requires a specific certificate being installed on a specific box. If you are on that level, you don't need the guided certificate install anyway. With my proposal and the requirement of being the only one on the network, you get pretty close to that level. > The challenges IMHO are being able to safely retain previously installed > certificates over OpenWRT reflashes/upgrades and having user friendly tools > to get new certificates uploaded, generated or acquired. For the latter part, > some configurable service to periodically download and install certificates > from an external host might be desirable (that's how I do it with my NAS > boxes at home). You need a name is DNS, then it's just a dns-01 challenge. I believe the most common being an HTTP-01 challenge (see https://letsencrypt.org/docs/challenge-types/). So you need a DNS entry pointing to your (dynamic?) IP and a HTTP server under OpenWRT control running on port 80 or 443. That is not always practicable for home internet connections. I found it to be much more practicable to have the certificate generated and renewed on an external host (with the FQDN of my NAS boxes pointing to that host in public DNS) and download the certificate files at regular intervals. Inside my network, the name of the NAS is resolved to its local IP address. Anyway, the options to upload, generate or acquire will probably cover the most common cases and are not hard to implement. Regards, Bas. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ 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
Re: ipq806x: add support for TP-Link Talon AD7200
On 2020-10-12 01:09, Paul Fertser wrote: From: Gary Cooper Device hardware: https://deviwiki.com/wiki/TP-LINK_AD7200_(Talon) The Talon AD7200 is basically an Archer C2600 with larger flash, a third PCIe lane and an 802.11ad radio. It comes in a different housing reminiscent of the Archers C3200 and C5400. Specifications -- - IPQ8064 dual-core 1400MHz - QCA9988 2.4GHz WiFi - QCA9888 5GHz WiFi - QCA9500 60GHz WiFi - 256MiB SPI Flash - 512MiB RAM - 5 GBit Ports (QCA8337) Installation Installation is possible from the OEM web interface. Sysupgrade is possible. TFTP recovery is possible. - Image: AD7200_1.0_tp_recovery.bin Notes - This will be the first 802.11ad device supported by mainline. Signed-off-by: Gary Cooper Nice work, but does it make sense to add a device that is already EOL'ed by the manufacturer? I guess the installed base is also rather small. Reagrds, Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ipq806x: add support for TP-Link Talon AD7200
On 2020-10-12 11:40, Bjørn Mork wrote: Bas Mevissen writes: Nice work, but does it make sense to add a device that is already EOL'ed by the manufacturer? I guess the installed base is also rather small. Definitely! IMHO, it should me enough that there is one user with enough interest to actually do the work, submit it and - hopefully - maintain it for a while. The latter, maintenance, is my biggest question mark. Technically keeping the sources compile is the smallest task. You need someone to actually use recent builds all the time and preferably in multiple use cases to catch regressions. Otherwise, it might give a false impression that the device is supported and working. In addition, - each supported device serves as a template and example for similar devices, simplifying support for other products. It is not really an unique product. It looks like it was (just) created to be a showcase at CES2016. - OpenWrt support is good for the environment by increasing the usable lifetime of a device True in itself. I have a very old TP-Link TL1043ND V1.x running (for which support will be removed soon because it gets very difficult to keep them going with current software sizes). - you can still buy this device new, despite the EoL announcement But should you? I would be very reluctant with buying EOL devices, especially when being a "first" and with the price still up. I think that OpenWRT should be careful not to spend resources on devices that have no large install base nor any chance of getting it. In that respect, I would prefer to prioritize on low RAM / low flash devices instead as they are everywhere and mostly running outdated insecure software. With things like ZRAM and an external flash drive, there life span could be meaningfully extended. Bjørn Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ipq806x: add support for TP-Link Talon AD7200
On 2020-10-12 12:46, Daniel Golle wrote: On Mon, Oct 12, 2020 at 11:59:17AM +0200, Bas Mevissen wrote: On 2020-10-12 11:40, Bjørn Mork wrote: > Bas Mevissen writes: > > > Nice work, but does it make sense to add a device that is already > > EOL'ed by the manufacturer? I guess the installed base is also rather > > small. > > Definitely! > > IMHO, it should me enough that there is one user with enough interest to > actually do the work, submit it and - hopefully - maintain it for a > while. > The latter, maintenance, is my biggest question mark. Technically keeping the sources compile is the smallest task. You need someone to actually use recent builds all the time and preferably in multiple use cases to catch regressions. Otherwise, it might give a false impression that the device is supported and working. > In addition, > - each supported device serves as a template and example for >similar devices, simplifying support for other products. It is not really an unique product. It looks like it was (just) created to be a showcase at CES2016. To me it makes sense to support this device because it's easier to do than MikroTik or ubnt devices with 802.11ad which have their special quirks for EEPROM extraction and such (but yet those are very interesting targets imho!). Starting with a TP-Link device which more or less implements a plain reference design is a very good start for 802.11ad in Openwrt. OK, good point. I'll buy a few when the price drops :-) Obviously, my concern about maintenance remains when there is support for a more popular equivalent device. > - OpenWrt support is good for the environment by increasing the usable >lifetime of a device True in itself. I have a very old TP-Link TL1043ND V1.x running (for which support will be removed soon because it gets very difficult to keep them going with current software sizes). > - you can still buy this device new, despite the EoL announcement > But should you? I would be very reluctant with buying EOL devices, especially when being a "first" and with the price still up. I think that OpenWRT should be careful not to spend resources on devices that have no large install base nor any chance of getting it. In that respect, I would prefer to prioritize on low RAM / low flash devices instead as they are everywhere and mostly running outdated insecure software. With things like ZRAM and an external flash drive, there life span could be meaningfully extended. > > Bjørn Bas. ___ 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
Re: Hostapd throwing warnings
On 2020-10-15 19:45, Philip Prindeville wrote: On Oct 15, 2020, at 11:32 AM, Daniel Golle wrote: On Thu, Oct 15, 2020 at 11:18:24AM -0600, Philip Prindeville wrote: Hi, I have a WLE600VX card in an APU4 running HEAD as of a week ago. My /etc/config/wireless file is straightforward: config wifi-device 'radio0' option type 'mac80211' option channel '36' option hwmode '11a' option path 'pci:00/:00:02.5/:05:00.0' option htmode 'VHT80' option disabled '0' config wifi-iface 'default_radio0' option device 'radio0' option network 'lan' option mode 'ap' option hidden '1' option ssid ‘xyzzy' option encryption 'psk2+aes' option key ‘my-passphrase-here’ But I’m seeing the following warnings: Oct 14 18:29:23 OpenWrt2 hostapd: Configuration file: /var/run/hostapd-phy0.conf (phy wlan0) --> new PHY Oct 14 18:29:23 OpenWrt2 hostapd: Line 16: unknown configuration item 'ieee80211ac' Oct 14 18:29:23 OpenWrt2 hostapd: Line 17: unknown configuration item 'vht_oper_chwidth' Oct 14 18:29:23 OpenWrt2 hostapd: Line 18: unknown configuration item 'vht_oper_centr_freq_seg0_idx' Oct 14 18:29:23 OpenWrt2 hostapd: Line 19: unknown configuration item 'vht_capab' Oct 14 18:29:23 OpenWrt2 hostapd: 4 errors found in configuration file '/var/run/hostapd-phy0.conf' Oct 14 18:29:23 OpenWrt2 hostapd: Failed to set up interface with /var/run/hostapd-phy0.conf Oct 14 18:29:23 OpenWrt2 netifd: radio0 (4034): Command failed: Invalid argument On booting. If I comment out these lines being generated in /lib/netifd/wireless/mac80211.sh then WiFi works. Is anyone else seeing this? I’m using: CONFIG_PACKAGE_ath10k-firmware-qca988x-ct-full-htt=y CONFIG_PACKAGE_wireless-regdb=y CONFIG_PACKAGE_kmod-ath=y CONFIG_ATH_USER_REGD=y CONFIG_PACKAGE_ATH_DFS=y CONFIG_PACKAGE_kmod-ath10k-ct=y CONFIG_ATH10K-CT_LEDS=y CONFIG_PACKAGE_kmod-cfg80211=y CONFIG_PACKAGE_kmod-mac80211=y CONFIG_PACKAGE_MAC80211_DEBUGFS=y CONFIG_PACKAGE_MAC80211_MESH=y CONFIG_PACKAGE_hostapd-common=y CONFIG_PACKAGE_hostapd-openssl=y CONFIG_PACKAGE_hostapd-utils=y CONFIG_DRIVER_11N_SUPPORT=y CONFIG_DRIVER_11AC_SUPPORT=y CONFIG_DRIVER_11W_SUPPORT=y CONFIG_PACKAGE_iw=y Am I doing anything wrong? Oh, also, in /etc/config/network, do I need to explicitly add wlan0 to my bridge for “lan” or does that happen automatically? Looks like CONFIG_DRIVER_11AC_SUPPORT=y isn't really set in the end, usually it should be auto-selected based on the driver you are using, ie. kmod-ath10k in your case. Those CONFIG_DRVIVER_* symbols are not meant to be selected manually. Are you using an out-of-tree WiFi driver or any changes like that? I commented out CONFIG_DRIVER_* and reran “make defconfig oldconfig” and those 3 got turned back on. Is there something else I should be doing? You might check whether the text strings of the configuration options mentioned in the logs are present in the binaries in the rootfs and object files in the build folder (assuming they are literally present in the source code). Additionally, add some #error statements in a few places in code that only gets compiled when CONFIG_DRIVER_11AC_SUPPORT is defined to check whether that define is effectively set at compile time. It is a very basic way of debugging source code configuration, but at least it gives you certainty about how the code is actually compiled. And no, not an out-of-tree build… unless it’s using backports and that’s considered out-of-tree? -Philip ___ 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
Re: [OpenWrt-Devel] WPS patch set overlooked
Hi Lorenzo, Does this WPS patch set contain a way to mitigate the security design flaw? Reading the Wikipedia article (http://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup#Security), it looks to me a compatible fix should be possible. Cheers, Bas. On 10/13/2012 01:39 PM, Lorenzo Cappelletti wrote: > Hi everyone, > > I posted my first patch set on October 1. Since then, it hasn't been > acknowledged. I must conclude it got overlooked. > > The patch set regards WPS (Wi-Fi Protected Setup) support. Could anyone > have a look at it (maybe Felix, who recently moved hostapd directory > under network?). It's not over yet, but I'll be submitting more patches > if these get committed. > > Thanks. Lorenzo. > > Links to my patch set posts: > > https://lists.openwrt.org/pipermail/openwrt-devel/2012-October/016870.html > https://lists.openwrt.org/pipermail/openwrt-devel/2012-October/016871.html > https://lists.openwrt.org/pipermail/openwrt-devel/2012-October/016872.html > https://lists.openwrt.org/pipermail/openwrt-devel/2012-October/016873.html > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > -- Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] kernels: use ccache for modules too
On Wed, 03 Aug 2011 03:28:13 +, Daniel Mierswa wrote: KERNEL_MAKEOPTS := -C $(LINUX_DIR) \ - CROSS_COMPILE="$(KERNEL_CROSS)" \ + CROSS_COMPILE="ccache $(KERNEL_CROSS)" \ ARCH="$(LINUX_KARCH)" \ KBUILD_HAVE_NLS=no \ CONFIG_SHELL="$(BASH)" Is ccache mandatory for building OpenWRT? I would advise that you need to use something like $(CCACHE) that can be empty when you have no ccache around. Regards, -- Bas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] compression mode of jffs2
On Sun, 2010-02-07 at 18:00 +0100, Matthias Buecher / Germany wrote: > How will this affect performance (the opposite side of compression)? > If it does, then it would be great if this would be selectable and not > hardcoded. > > Just my two cents > Maddes > > On 07.02.2010 17:44, edgar.sol...@web.de wrote: > > I discovered a currently not used option of jffs2. It allows the setting > > of a compression mode. Because size matters on embedded devices I wonder > > why this is not enabled. Attached a patch that does that. I tried it and > > it works. > > My 2 cents: compare the boot time between the jffs2 with and without the patch. Can you also give an example in the actual flash space saved by the patch? Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] compression mode of jffs2
On Mon, 2010-02-08 at 11:25 +0100, edgar.sol...@web.de wrote: > Any idea how to measure boot time? I don't have serial console access. ede > some LED changing state, first respond to ping or wait for first broadcast packet from ethernet (e.g. arp, dhcp) with wireshark. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] compression mode of jffs2
On Mon, 2010-02-08 at 11:32 +0100, Bastian Bittorf wrote: > > boottime should'nt be affected, because bootpartition is squashfs, Ah, I use jffs2 as root (and only) fs on my dev boards. > only the writeable partition is jffs2. In theory i vote for default to > size-optimization and make it menuconfig-selectable to switch to old > mode. > That sounds like a good plan. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] libconfig: update version to 1.4.2
On Sun, 2010-02-14 at 21:17 +0100, Mircea Gherzan wrote: > The 1.4.0 tarball is no longer available upstream. > (..) > PKG_NAME:=libconfig > -PKG_VERSION:=1.4 > +PKG_VERSION:=1.4.2 > PKG_RELEASE:=1 > > PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz > PKG_SOURCE_URL:=http://www.hyperrealm.com/libconfig/ > -PKG_MD5SUM:=c6b1c6ccb1a35b93ebf771779d915181 > +PKG_MD5SUM:=6bf067a7f2d432847494d1c356074c02 > Today, a version 1.4.3 was released with a minor fix. Modified but untested patch below. Bas. --- libs/libconfig/Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libs/libconfig/Makefile b/libs/libconfig/Makefile index ba97cbb..f3ef993 100644 --- a/libs/libconfig/Makefile +++ b/libs/libconfig/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=libconfig -PKG_VERSION:=1.4 +PKG_VERSION:=1.4.3 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://www.hyperrealm.com/libconfig/ -PKG_MD5SUM:=c6b1c6ccb1a35b93ebf771779d915181 +PKG_MD5SUM:=8b7a7facd8b380fdd26a4a1ea58086b9 include $(INCLUDE_DIR)/package.mk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2mb flash not OpenWRT-Target?
On Fri, 2010-02-19 at 00:07 -0500, Stefan Monnier wrote: > >> Linux can hardly fit in a 2MB flash device, once you have opened the > > Yes, but this text was written in the old times (2004?) > > I've been using OpenWRT on my WL-700gE for a while now. That machine > has a 2MB flash, so OpenWRT is quite usable there. But yes, it also has > a IDE interface, so the 2MB only serves as a sort of initramfs (indeed, > I don't even include a jffs2 partition, only squashfs). > So in summary, it is IMO safe to assume that a device like a router with only 2Mbytes of non-volatile storage (flash) does not run Linux. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2mb flash not OpenWRT-Target?
On Fri, 2010-02-19 at 16:24 +0100, Benjamin Henrion wrote: > The Asus WL520GC I just bought is running Linux. It has 2MB of flash. Wow, I assumed that out of the box, these devices with a small amount of flash did not run Linux. That was true in the past at least. Things have changed since I last checked... Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Compiling outside of buildroot
On Fri, 2010-02-19 at 16:14 +0100, Felix Fietkau wrote: > On 2010-02-19 2:53 PM, David Farrell wrote: (..) > > I just want to treat the OpenWrt system as a general purpose embedded linux > > box. > Two possibilities: > > a) You read about how the Linux kernel is cross compiled, how to build > external kernel module trees and so on using variables like > CROSS_COMPILE, ARCH, M, ... > The kernel sources are in build_dir/linux-*/linux-*/. > You can put the toolchain dir into your PATH and call the make commands > there (pointing at your external tree), either manually or with your > wrapper makefile. > How about the OpenWRT SDK? Is that still supported? I never used it, but it would be useful if it would contain some Makefiles and/or scripts to help building user space and kernel space code outside the OpenWRT tree. The idea is that you install a pre-compiled SDK somewhere, source a script with settings and you can easily build your own stuff without hassle about paths and stuff. This is how most board support packages from hardware manufacturers work. It should be as easy as native compilation. b) You realize that cross-compiling an external kernel module is much > easier with OpenWrt, and simply copy a package dir like > package/spi-ks8995 and adjust it for your own kernel module, then run > make oldconfig and then run make package//compile V=99 ;) > Yes, it is easy to create an external package and include it in the OpenWRT build. Is there a way to build an OpenWRT image with calling "make" outside the OpenWRT tree and have the image also outside the OpenWRT tree? The idea here is to keep your code and OpenWRT separated during development. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Compiling outside of buildroot
On 02/19/2010 08:08 PM, Felix Fietkau wrote: > I disagree with the way manufacturers typically set up board support > packages. Often you have to install something as root, which is annoying > for people that only have user accounts on some machines. Often you can > only have one globally installed instance of the SDK, which makes it > annoying to support multiple different versions, or even just multiple > minor variations of the toolchain. > That's true, but for most of people it is a convenient way to just have to install an SDK and start developing. One issue with pre-compiled SDK's is gcc hardcoded absolute paths to libraries that make relocation difficult. There are scripts that change the absolute paths to relative one. Then it is possible to install a precompiled SDK in the user accessible location you want. With OpenWRT, it is possible to have multiple different version installed at the same time. You can simply choose a different location for every variant where you build OpenWRT, e.g. build one in /opt/OpenWRT// and another one in /opt/OpenWRT// By sourcing a (to be written) script say /opt/OpenWRT///settings.rc you switch between different variants. > Why do you want to call it outside of the tree? You can keep your > packages as a separate feed, which makes it easy to keep track of your > own work without having to fully integrate it into the OpenWrt tree. > Personally, I like a complete separation between open source and propriety code. So when developing propriety code which uses OpenWRT as a platform, I prefer to use a fixed tree of OpenWRT stuff (packaged and installed somewhere) and have an entirely separate tree of propriety code in which I can simply call "make". Then the resulting binaries, kmods and images should land somewhere in my propriety tree. Please note that I'm not saying that the system with the feeds is not working properly! I just want to offer an OpenWRT based SDK for a certain board (including kernel headers and .config actually) as an easy to install package and an archive with only the propriety stuff. One then only needs to install the SDK, unpack the archive with the propriety code and run make. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Compiling outside of buildroot
On 02/21/2010 07:45 PM, Florian Fainelli wrote: >> > Yes it is still supported and works well. >> > It also contains a "relocatable" toolchain, so it doesn't matter where >> > you unpack it. But it is only suitable for userspace software, iirc it >> > does not ship with and is not capable of compiling the kernel sources. > You can however, use the compiled and relocatable toolchain in the SDK to > compile other kernel sources (vanilla, git ...) So if the kernel headers and config are added to the SDK, one could compile out of tree kmods too? Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dropbear: allow multiple listen ports to be configured
On Sun, 2010-02-28 at 11:30 +0100, Stijn Tintel wrote: > On 28-02-10 11:28, Stijn Tintel wrote: > > This patch allows multiple listen ports to be configured for dropbear in > > /etc/config/dropbear. It renames the 'Port' option to 'Ports', so this > > will break existing configs. What looks more useful to me, is to have multiple different dropbear configs at the same time, e.g. # Public key-only login port config dropbear option PasswordAuth 'off' option Port '22' option BannerFile '/etc/banner' # Hidden password enabled fall-back config dropbear option PasswordAuth 'on' option Port '' Is that already supported? I would also not see much reason to rename "Port" to "Ports". As already said, it is a rarely used setup and it works fine when called "Port". Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dropbear: allow multiple listen ports to be configured
On Mon, 2010-03-01 at 15:22 +0100, Stijn Tintel wrote: > Since the above suggestion is OK for me, I'd suggest to just forget this > patch :-) The patch itself is useful if someone wants to explore the possibilities of dropbear. There is a difference between two instances and one instance which listens on two ports. There was just some objection on breaking the name of the port(s) option. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Backfire 10.03-beta
On Wed, 2010-03-03 at 18:00 -0800, Andy Boyett wrote: > *** BETA RELEASE *** > The OpenWrt Team would like to announce a beta of the next major > release, codenamed Backfire. Testing of this build will help refine > the code in preparation of the final release. > Great! > Binaries can be downloaded at > http://downloads.openwrt.org/backfire/10.03-beta/ > http://downloads.openwrt.org/backfire/10.03-beta/avr32/ avr32 images are missing. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Backfire 10.03-beta
On Thu, 2010-03-04 at 11:27 +0100, edgar.sol...@web.de wrote: > > > > Highlights: > > * brcm-2.4 updated to 2.4.37 kernel > > why not recent 2.4.39, the 2.4 kernel doesn't have major changes > anymore > but some more bugfixes > > http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.37.9 > http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.37.8 > > when I tried it compiled and ran. > Kernel is already the latest, 2.4.37.9. http://downloads.openwrt.org/backfire/10.03-beta/brcm-2.4/packages/kernel_2.4.37.9-1_brcm-2.4.ipk Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Backfire 10.03-beta
On 03/05/2010 09:49 PM, Stefan Monnier wrote: >> Binaries can be downloaded at >> http://downloads.openwrt.org/backfire/10.03-beta/ > > Is there some equivalent Svn revision, branch, or the trunk rev-number > from which it was branched? > Looking at the .config files, it seems to be OpenWRT trunk (and packages) r19932. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR7240 switch // was: TP-Link TL-WR741ND: broadcasts on ethernet not reaching CPU
On Sat, 2010-03-13 at 18:31 +0100, Joerg Albert wrote: > > BTW, I get some garbled chars on TX (target -> PC) from the WR741ND on > the serial line. > Both in bootloader and Linux system, so I guess it's a hardware > problem (especially > as the log in > https://forum.openwrt.org/viewtopic.php?pid=102069#p102069 looks > fine). > I use a Prolific PL2303 serial USB adapter which works fine with other > hardware. Someone else? Do you have access to an oscilloscope? It might be that the signal level or signal shape is not perfect. I've seen mixed results with various serial to USB adapters too. You can also try to replace the net adapter of the board. These adapters tend to age and perform worse. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] External toolchain cannot find -lgcc_s
On Sat, 2010-03-13 at 22:22 -0500, Pawel Pastuszak wrote: > Hi All, > > I am trying to split the toolchain out of my main openwrt build, after > generating the toolchain i moved it to a new location from > staging_dir/toolchain-powerpc_gcc-4.3.3_glibc-2.7 and set up and new > build that points to the toolchain. > > I am using Revision: 20023. > > Is there any think that I am missing? > > > powerpc-openwrt-linux-gnu-gcc -Os -pipe -funit-at-a-time -mcpu=405 > -msoft-float -Wall -Wunused -I./include/linux/include/ -Iinclude/ > -DARPTABLES_VERSION=\"0.0.3-3\" -o arptables arptables-standalone.o > arptables.o libarptc/libarptc.o extensions/arpt_standard.o > extensions/arpt_mangle.o > /development/external_toolchain_test/usr/bin/../lib/gcc/powerpc-openwrt-linux-gnu/4.3.3/../../../../powerpc-openwrt-linux-gnu/bin/ld: > cannot find -lgcc_s > collect2: ld returned 1 exit status > make[4]: *** [arptables] Error 1 > make[4]: Leaving directory > `/development/openwrt/build_dir/target-powerpc-openwrt-linux-gnu/arptables-v0.0.3-3' > make[3]: *** > [/development/openwrt/build_dir/target-powerpc-openwrt-linux-gnu/arptables-v0.0.3-3/.built] > Error 2 > make[3]: Leaving directory `/development/openwrt/package/arptables' > make[2]: *** [package/arptables/compile] Error 2 > make[2]: Leaving directory `/development/openwrt' > > Looks like a relocation problem. In general, gcc has a hard coded absolute path to some libraries. Solution is to compile the cross compiler for your new destination path or fix the binary. This has been discussed quite recently here in the "Compiling outside of buildroot" thread. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR7240 switch // was: TP-Link TL-WR741ND: broadcasts on ethernet not reaching CPU
On Mon, 2010-03-15 at 11:31 +0100, ulf kypke wrote: > i'm still looking for a very good 3.3v serial adapter, the prolific is > not the best one. Best trick is to cascade a MAX3232 level shifter with 3V3 power supply. It will raise the signal level to just over 5V. That is enough for the average serial-to-USB converter. It also protects the other end from over voltage. I once had to couple an AVR32 development board to an automotive GSM modem using a bi-directional cascade of 3V3 and 5V powered MAX3232 level shifters... Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt] #6812: kamikaze trunk can't start RB433AH
On Thu, 2010-03-18 at 16:25 +0800, Yongheng Qi wrote: > anyone could tell me how to resolve the problem, I want NOT to change > my kamikaze version. > I used the kamikaze r19358. > Then find the change that fixed the issue and patch your setup yourself. You cannot expect someone to fix your problem if you refuse to accept the logical solution of calling "svn up && make". Kamikaze trunk is work in progress and you should be willing to upgrade your tree to fix problems. Otherwise, you are on your own. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt] #6812: kamikaze trunk can't start RB433AH
On Fri, 2010-03-19 at 10:12 +0800, Yongheng Qi wrote: > Thanks Bas , > > > because kamikze trunk used linux kernel changed so faster. and my > application depend on fixed kernel version. > You can keep the kernel version stable and have the other stuff up to date. But that won't help if there is a problem with that kernel. In general, it is better to see if you can make your application independent of the kernel version. In the event of a kernel driver (binary), you might not have that freedom. > > so I can't use svn up. only need resolve the problem. I want to know > how to resolve the problem myself. > I would first recommend to check that the board boots with the version of Kamikaze trunk mentioned in the bug report. Then you know that there is no other problem. Then work your way back in svn revisions until you find the change that fixed the problem. It is some work, but you don't need to dig too deep into code to get it. Example: svn revision 1000 fails and 2000 works. Try 1500. If it works, try 1250. Otherwise try 1750, etc. If you can compile fast enough, it is just a matter of a few hours work to pinpoint the revision that fixed the issue. To avoid recompiling everything every time, keep a copy of every compiled tree and only go *upwards* in svn revision number on that particular tree. So if you want to compile revision 1500, check for the closest lower revision you have, say 1000, copy it and update it to the revision. The idea is that updated sources will be automatically recompiled. This is not 100% guaranteed to work, but it might save you a lot of time. Also make sure that you don't change the directory path of the tree you are recompiling because that will break the compile. Or even worse, you will use stuff from a different revision. Something like: svn up --revision 1000 openwrt-current cd openwrt-current; make cp -a openwrt-current openwrt-r1000 svn up --revision 2000 openwrt-current cd openwrt-current; make mv openwrt-current openwrt-r2000 # now I want 1500 cp -a openwrt-r1000 openwrt-current svn up --revision 1500 openwrt-current cd openwrt-current; make Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR7240 switch // was: TP-Link TL-WR741ND: broadcasts on ethernet not reaching CPU
On Thu, 2010-03-18 at 23:04 +0100, Joerg Albert wrote: > On 03/15/2010 09:33 AM, Bas Mevissen wrote: > > > Do you have access to an oscilloscope? It might be that the signal level > > or signal shape is not perfect. I've seen mixed results with various > > serial to USB adapters too. > > I used an oscilloscope yesterday and the signal looked fine (sharp edges, correct timing, low noise). What were the voltages of both "0"'s and "1"'s? > It's a rather new device and I run the board at home at a laboratory power supply. > That should be fine. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR7240 switch // was: TP-Link TL-WR741ND: broadcasts on ethernet not reaching CPU
On Fri, 2010-03-19 at 16:56 +0100, Joerg Albert wrote: > I looked closer at the PCB and it turned out that we have a voltage > divider with two 5.6 kOhm to V_3_3 and GND (R613, R614) and a > capacitor C496 (!) towards the CPU. The signal at the CPU looked fine > for a 2.5V TTL. > The voltage drift seen above is probably caused by the capacitor > unloading when the CPU pin is driven down. > Curious design choice. Works fine for continuous signals at higher frequencies, but not here. > I removed the resitors and replaced C496 by a 1k resistor (to protect > the CPU pin against shorts). This solved my problem. > I guess the above schematics was meant to be a cheap TTL level > conversion 2.5V -> 3.3V. > > Thanks for sending me again to the oscilloscope! I'm happy it is solved now. Maybe you can document this in relevant places on the web. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mjpg-streamer and kernel crash again
On Fri, 2010-03-19 at 22:37 +0100, Kövesdi György wrote: > Hi, > > At last i could create symbolic backtrace (attached). > > The hardware is an Asus WL500GP-V2, a 160 Gb HD (on USB), a UVC webcam > (Logitech Quickcam Sphere). > The commandline is: > mjpg-streamer -i "input_uvc.so -f 25 -r 320x240 -l off" -o "output_file.so -r > /data/jpeg" > > 128Mb swap is used. > Some commands are executed immediately before crash (see the attached file), > the free memory and other things are shown. > > I cannot imagine that all the memory got allocated within some seconds > (filling 128Mb space through USB takes some time). I assume that there is a > problem in the kernel instead. > Where is the output of mjpg-streamer written to? It looks like it is using ram disk or (slow) flash memory. Make sure it is on the hard disk. What is the rate of data being written? If, for some reason, the disk (flash?) is too slow, you run out of memory due to the block layer buffering. You can measure the USB disk performance by copying a piece of dat from e.g. /dev/zero to the disk with "dd". Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mjpg-streamer and kernel crash again
On Mon, 2010-03-22 at 15:30 +0100, Kövesdi György wrote:
> > Where is the output of mjpg-streamer written to? It looks like it is
> > using ram disk or (slow) flash memory. Make sure it is on the hard disk.
> Sorry, i forgot to mention that there is a link:
> /data -> /mnt/xxx/
> which point to the HD.
>
OK, wanted to be sure that we are hunting a real bug. Did you check that
the files are actually written to that disk?
> > What is the rate of data being written? If, for some reason, the disk
> > (flash?) is too slow, you run out of memory due to the block layer
> > buffering.
> The measured maximum recorded rate is ~23 fps. My very first try was
> recording
> one picture in every 15 second, which is very slow, and it also leaded to
> crash in 3 days. Faster recording crashes sooner.
>
Sounds like a memory leak of the application. Or some (debug) log asking
too much memory. Maybe /var/log/messages is getting huge?
> --
>
> I checked some out-of-memory situations, and found strange things. You can
> easily try it (i would like to hear if it works on your system or not):
> create
> a big directory (~50k...100k files) and give a simple 'ls' command:
>
> $ ls /my/big/directory
>
> No swap is in use, my physical memory is 32M.
> The 'ls' allocates very much memory, which leads to out-of-memory. AFAIK, the
> kernel calls the oom-killer, which should kill the biggest process ('ls' in
> this case).
I'm not sure that it kills the biggest process first.
> It happens, but the system hangs. Some seconds later the following
> message appears on the console:
>
> bcm47xx_wdtWatchdog will fire soon!!!
>
> This is the very last message, the system does not respond any more.
> I think this situation should be handled correctly.
>
What keeps the watchdog happy? It that still alive after the OOM-killer?
Bas.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Optware refusal
On Thu, 2010-05-20 at 19:23 +0200, Benjamin Henrion wrote: > It seems that the OpenWRT devs have entrenched views about optware packages: > > https://dev.openwrt.org/ticket/944 > What's your reason for digging up a 4 year old ticket? Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Openwrt package installation order
On Mon, 31 May 2010 13:19:00 +0200, Filippo Sallemi wrote: > Hi, > could someone explain how to change the order to install certain packages? > > I need to overwrite some configuration files, but the system overrides in > alphabetical order. > Use the "files" directory in your OpenWRT root. The contents of this directory will be copied over the installed files just before generating the image. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How openwrt team build SDK which releas ed officially on openwrt.org ?
On Thu, 3 Jun 2010 14:05:33 +0800, linux_pro wrote: > SDK可能无法使用. > 你需要svn co. > 自己生成 工具链. > 然后编译 你的 hello. > > 可以尝试下看看. > > 你碰到的问题我也没找到解决办法. > > Can you please answer in English? Other people might profit from your answers too. Thanks, -- Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LibreWRT introduction & patch
On Mon, 19 Jul 2010 13:49:19 -0300, Antonio Grassi wrote: > It would be great if some OpenWRT developer could review it and send some > feedback about the inclusion of this patch; probably there are things to be > solved or improved before inclusion, so it would be great to hear about > that > too. > I'm not an OpenWRT developer. My feeling is that non-intrusive "libre" patches might get accepted by OpenWRT. Then a seperate LibreWRT archive isn't needed. Regarding the kernel version, I think we need to have a "vanilla" linux kernel version and a libre one, but not written like ifneq ($(CONFIG_USE_LIBRE_KERNEL),) LINUX_VERSION:=2.6.34.1-libre else LINUX_VERSION:=2.6.34.1 endif in many makefiles as this makes them messy and grepping for the LINUX_VERSION unclean. It does not scale well if you would like to add more different kernel tastes. A cleaner solution could be to have something like: VANILLA_LINUX_VERSION:=2.6.34.1 LIBRE_LINUX_VERSION:=2.6.34.1-libre # or even LIBRE_LINUX_VERSION:=$(VANILLA_LINUX_VERSION)-$(LIBRE)$(LIBRE_VERSION) in the Makefiles where the VANILLA_LINUX_VERSION is maintained by OpenWRT and LIBRE_LINUX_VERSION by LIBRE_POSTFIX LibreWRT. In kernel.mk, we can simply assign the proper kernel to KERNEL_VERSION with something like: ifneq ($(CONFIG_USE_LIBRE_KERNEL),) LINUX_VERSION:=LIBRE_LINUX_VERSION else LINUX_VERSION:=VANILLA_LINUX_VERSION endif # Fall back to vanilla ifeq ($(LINUX_VERSION),) LINUX_VERSION:=VANILLA_LINUX_VERSION endif > PS: I'm CC'ing the LibreWRT development list > I'm not a member of that list, so I cannot copy that list. Regards, -- Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LibreWRT introduction & patch
On Tue, 20 Jul 2010 10:53:19 -0300, Antonio Grassi wrote: > we tried a second approach, which > is also included in the patch: instead of downloading deblobed kernel > sources, we could deblob the vanilla kernel sources as part of the build > process, making use of the "deblobing scripts" [1] provided by Libre Linux. > This approach requires the deblobing scripts to be downloaded at "run time" > or be included in the sources, for example, under a new sub > directory 'scripts/deblob/'. What do you think about this? > I'm wondering if deblobbing is enough for the real "libre" people because they will still download non-libre stuff. In other words, I wonder why one would like to deblob. As long as you don't install the blobs in the image, you are not using it. So if you already downloaded it, what is the use of removing it above just not installing and using it. Regards, -- Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LibreWRT introduction & patch
On Tue, 20 Jul 2010 17:37:50 +0200, Stefan Monnier wrote: >> In other words, I wonder why one would like to deblob. As long as you >> don't install the blobs in the image, you are not using it. So if you >> already downloaded it, what is the use of removing it above just not >> installing and using it. > > IIUC the issue is not whether to download this or not, but whether it > gets (installed and) used. So it's mostly a matter of marking the > un-free parts and then making them only available upon a very > explicit request. > > The degree to which the request should be explicit is of course > something that depends on how much you care about this kind of freedom. OK, if you interpret it like that, one doesn't need to deblob the kernel source. We only need a configuration value that avoids installing the non-free stuff. > I personally would really like it if OpenWRT labelled each non-free part > and made it clear which part is free and which isn't (e.g. by placing > all the non-free packages (i.e. packages which include some non-free > element) in a separate (sub)menu). > I would recommend keeping the current menu structure based upon functionality and not free/non-free For non-free packages, would something like DEPENDS=-LIBRE work? If CONFIG_LIBRE is defined, these packages would simply disappear from the menu. -- Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Problem cross compiling gammu
Hi,
I took some stuff from https://dev.openwrt.org/ticket/7649 to compile
gammu for OpenWRT on AVR32.
Most of it seems fine, but a few things fail:
- The compilation needs cmake on the host, which is not checked for.
OpenWRT does not provide support for cmake, but a host installed recent
cmake should do.
- The compilation is not cross compile aware. So the host cc is checked
for instead of the cross compiler
- Cmake fails because it cannot find libm.so. This is in
staging_dir/toolchain-*/lib. But there is no environement variable set
for this directory. The STAGING_DIR variable points to
staging_dir/target-* and something like STAGING_TOOLCHAIN_DIR is not
set. At least not when configuring the package.
- I peeked around and found that OpenEmbedded added the parameter
-DCMAKE_FIND_ROOT_PATH=${STAGING_DIR_TARGET} to cmake. When I
manually let the root path point to the toolchain dir, it seems to
compile OK.
--
Bas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Problem cross compiling gammu
On 08/16/2010 05:55 PM, Bas Mevissen wrote:
>
> Hi,
>
> I took some stuff from https://dev.openwrt.org/ticket/7649 to compile
> gammu for OpenWRT on AVR32.
>
> Most of it seems fine, but a few things fail:
>
> - The compilation needs cmake on the host, which is not checked for.
> OpenWRT does not provide support for cmake, but a host installed recent
> cmake should do.
>
> - The compilation is not cross compile aware. So the host cc is checked
> for instead of the cross compiler
>
> - Cmake fails because it cannot find libm.so. This is in
> staging_dir/toolchain-*/lib. But there is no environement variable set
> for this directory. The STAGING_DIR variable points to
> staging_dir/target-* and something like STAGING_TOOLCHAIN_DIR is not
> set. At least not when configuring the package.
>
> - I peeked around and found that OpenEmbedded added the parameter
> -DCMAKE_FIND_ROOT_PATH=${STAGING_DIR_TARGET} to cmake. When I
> manually let the root path point to the toolchain dir, it seems to
> compile OK.
>
>
Oops, mail escaped before I was finished typing it.
Anyway, gammu seems to work on platform. At least, it is no worse than
on a desktop PC.
My question is: what to do? How is normally libm.so detected? Maybe
someone with more experience with cmake and cross compiling can shine a
light on it. Would be very much appreciated!
Regards,
Bas.
--
Bas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WGT634U busted in trunk since mid-July
On Thu, 30 Sep 2010 21:05:21 -0700, Russell Senior wrote: > (...) but unfortunately, all the revisions I > have tested after r22295 build okay but have failed to boot > successfully. Currently, as of r23118, I lose the serial port very > early in the boot, immediately after: > >From 23118 to 22295 are 823 revisions. So in less than 10 builds you should be able to bisect the revision causing the failure. You might even recall which earlier builds already are found to be broken. When you find the revision that caused the breakage, I guess it will become quite obvious why it broke your platform. You seem to be lucky that you only have to see whether the board boots and configures its network. That makes determining whether the build is OK or broken very obvious. Regards, -- Bas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] update shorewall-lite to 4.4.12.2
On Fri, 8 Oct 2010 12:13:52 + (UTC), Brian J. Murrell wrote: > Brian J. Murrell interlinx.bc.ca> writes: >> >> This simply updates shorewall-lite to the current 4.4.12.2 > > I saw neither an ACK nor a NAK, nor do I see any sign that this was > committed. > > Was there a problem with the submission or the patch itself? > > It's really quite discouraging to go to all the effort to simply have your > submission ignored. > I fully agree. I guess the only reason is time lack of the people with commit rights. Only advice I can give is to send a friendly reminder after a week or so. Regards, -- Bas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] iptables compile fix
On Wed, 06 Oct 2010 13:56:07 +0200, Maarten Bezemer
wrote:
> For the 'Marvell Orion' target the iptables package does not compile.
> See forum topic: https://forum.openwrt.org/viewtopic.php?pid=117520
> Maybe for other targets as well?
>
> In short: the problem is that /usr/lib/libc is used while linking
> instead of the cross-compiled version.
>
> I provided a patch for this problem, but I am unsure whether it is a
> correct fix or just an ugly hack. I did not check whether this patch is
> disturbing any of the other targets.
> But, with a clean checkout (with the default configuration, Broadcom
> BCM947xx/953xx) it builds fine.
>
> So could someone take a look at it and eventually provide feedback for
> improvements or tell that it is good as it is and it can be submitted?
>
> Thanks,
> Maarten
Index: package/iptables/Makefile
===
--- package/iptables/Makefile (revision 23239)
+++ package/iptables/Makefile (working copy)
@@ -254,7 +254,10 @@
-I$(LINUX_DIR)/arch/$(LINUX_KARCH)/include \
$(TARGET_CPPFLAGS)
+IPTABLES_LIBDIR=$(TOOLCHAIN_DIR)/lib/
+
CONFIGURE_ARGS += \
+--libdir=$(IPTABLES_LIBDIR)\
--enable-shared \
--enable-devel \
--enable-ipv6 \
@@ -293,12 +296,12 @@
The toolchain itself should find its libc by itself. So no need to
point to it.
$(CP) $(PKG_INSTALL_DIR)/usr/include/* $(1)/usr/include/
$(INSTALL_DIR) $(1)/usr/lib
- $(CP) $(PKG_INSTALL_DIR)/usr/lib/libxtables.{a,so*} $(1)/usr/lib/
- $(CP) $(PKG_INSTALL_DIR)/usr/lib/libip*tc.{a,so*} $(1)/usr/lib/
- $(CP) $(PKG_INSTALL_DIR)/usr/lib/libipq.a $(1)/usr/lib/
+ $(CP) $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/libxtables.{a,so*}
$(1)/usr/lib/
+ $(CP) $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/libip*tc.{a,so*}
$(1)/usr/lib/
+ $(CP) $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)libipq.a $(1)/usr/lib/
$(INSTALL_DIR) $(1)/usr/lib/pkgconfig
- $(CP) $(PKG_INSTALL_DIR)/usr/lib/pkgconfig/xtables.pc
$(1)/usr/lib/pkgconfig/
- $(CP) $(PKG_INSTALL_DIR)/usr/lib/pkgconfig/libiptc.pc
$(1)/usr/lib/pkgconfig/
+ $(CP) $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/pkgconfig/xtables.pc
$(1)/usr/lib/pkgconfig/
+ $(CP) $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/pkgconfig/libiptc.pc
$(1)/usr/lib/pkgconfig/
endef
Plain wrong. The files are installed under $(PKG_INSTALL_DIR)/* and
that's where the files should be picked up after cross compilation. I
cannot imagine $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR) expanding to
something useful. It is the concatination of two absolute paths.
define Package/iptables/install
@@ -335,20 +338,20 @@
define Package/libiptc/install
$(INSTALL_DIR) $(1)/usr/lib
- $(CP) $(PKG_INSTALL_DIR)/usr/lib/libip*tc.so* $(1)/usr/lib/
+ $(CP) $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/libip*tc.so* $(1)/usr/lib/
endef
define Package/libxtables/install
$(INSTALL_DIR) $(1)/usr/lib
- $(CP) $(PKG_INSTALL_DIR)/usr/lib/libxtables.so* $(1)/usr/lib/
+ $(CP) $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/libxtables.so*
$(1)/usr/lib/
endef
define BuildPlugin
define Package/$(1)/install
$(INSTALL_DIR) $$(1)/usr/lib/iptables
for m in $(patsubst xt_%,ipt_%,$(2)) $(patsubst ipt_%,xt_%,$(2)); do
\
- if [ -f $(PKG_INSTALL_DIR)/usr/lib/iptables/lib{m}.so ];
then \
- $(CP)
$(PKG_INSTALL_DIR)/usr/lib/iptables/lib{m}.so
$$(1)/usr/lib/iptables/ ; \
+ if [ -f
$(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/iptables/lib{m}.so ]; then
\
+ $(CP)
$(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/iptables/lib{m}.so
$$(1)/usr/lib/iptables/ ; \
fi; \
done
$(3)
Same comment as above.
I guess something is wrong with your build environment. Clean it up and
please try again.
--
Bas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] build error: mixed implicit and normal rules.
On Sun, 7 Nov 2010 09:51:13 -0800, Chris Li wrote: > On Sun, Nov 7, 2010 at 5:05 AM, Jo-Philipp Wich wrote: >> >> Both please. > > Here is the patch for the busybox sub tree. > I haven't make it a patch in openwrt so that it will automatically apply > when compile. Is there a good example how to do that? > > BTW, I understand why make-3.82 want to complain. But in this case > the fix really isn't better than the original because the duplicated > build commands. It is just for the sake of make make-3.82 happy. > > Chris Your patch seems OK to me. I tested it on current backfire branch r24012 with both make 3.81 and 3.82. I put your file in my local backfire tree as package/busybox/patches/950-fix-mix-target.patch Can an OpenWRT dev please decide whether to include this patch or upgrade busybox to 1.17.3 (same as trunk)? Thanks, -- Bas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] iptables compile fix
On Mon, 15 Nov 2010 22:45:48 +0100, Maarten Bezemer wrote: > On Mon, 2010-11-15 at 12:08 +0100, Bas Mevissen wrote: >> I guess something is wrong with your build environment. Clean it up and >> please try again. > > I did (of course), several times in fact. > > After reading your post on the forum where you told you used the trunk, > I tried it as well and it works! > Then I copied to iptables package from trunk to backfire it still > compiles without problems. > > So, I suppose there are problems with the older version (1.4.6 compared > to 1.4.9.1) backfire uses or with the patches/Makefile in the backfire > package?e trunk? > > Is it an idea/possible to update the backfire iptables package to the > trunk version, since that one seems to work without problems? > I just did a build on backfire (revision 14012) for Orion (while checking a patch for make 3.82 for busybox). No problem at all. So I cannot reproduce the problem here. Can you check again and give me the output of "svn info | grep Revision" of the failing tree (assuming it is a checkout from svn)? Regards, -- Bas -- Bas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] iptables compile fix
(keeping the list in the loop) On Tue, 2010-11-16 at 10:56 +0100, Bas Mevissen wrote: > On Mon, 15 Nov 2010 22:45:48 +0100, Maarten Bezemer > wrote: > > On Mon, 2010-11-15 at 12:08 +0100, Bas Mevissen wrote: > > > I just did a build on backfire (revision 14012) for Orion (while > checking a patch for make 3.82 for busybox). No problem at all. > > > So I cannot reproduce the problem here. Can you check again and give me > the output of "svn info | grep Revision" of the failing tree (assuming > it is a checkout from svn)? > I have just updated to Revision 24016. After rebuilding everything I still have the error on the iptables package. I have put the last few commands before the error and the error itself in the attached log file. Looking at the output, I see -L/usr/lib where it should refer to the libraries of the cross compiled uClibc. This problem happens on my side too (but compilation goes fine). There is definitely something wrong with the package and that needs a fix. The LDFLAGS passed to the configure script look OK, so the bug is in the package itself. But the first question to answer is why you have a problem with it (and other people too according to the forum), while a lot of people have no problem at all. Just a stupid idea: do you have the openwrt SDK installed somewhere? What does "which arm-openwrt-linux-uclibcgnueabi-gcc" say? Can you post the .config file you use? I'll take a close look at the iptables package, but don't hold your breath... Regards, -- Bas (cd /home/maarten/src/openwrt-backfire/build_dir/linux-orion_generic/iptables-1.4.6; /bin/bash ./libtool --tag=CC --mode=relink arm-openwrt-linux-uclibcgnueabi-gcc -D_LARGEFILE_SOURCE=1 -D_LARGE_FILES -D_FILE_OFFSET_BITS=64 -D_REENTRANT -Wall -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wshadow -Wstrict-prototypes -Winline -pipe -DXTABLES_LIBDIR="/usr/lib/iptables" -DXTABLES_INTERNAL -I./include -I./include -I /home/maarten/src/openwrt-backfire/build_dir/linux-orion_generic/linux-2.6.32.25/include -I /home/maarten/src/openwrt-backfire/build_dir/linux-orion_generic/linux-2.6.32.25/include -Os -pipe -march=armv5t -mtune=xscale -funit-at-a-time -fhonour-copts -msoft-float -version-info 0:0:0 -rdynamic -static-libgcc -o libiptc/libiptc.la -rpath /usr/lib libiptc/libip4tc.la libiptc/libip6tc.la -inst-prefix-dir /home/maarten/src/openwrt-backfire/build_dir/linux-orion_generic/iptables-1.4.6/ipkg-install) arm-openwrt-linux-uclibcgnueabi-gcc -shared -L/home/maarten/src/openwrt-backfire/build_dir/linux-orion_generic/iptables-1.4.6/ipkg-install/usr/lib -L/usr/lib -lip4tc -lip6tc -march=armv5t -mtune=xscale -msoft-float -Wl,-soname -Wl,libiptc.so.0 -o libiptc/.libs/libiptc.so.0.0.0 /home/maarten/src/openwrt-backfire/staging_dir/toolchain-arm_v5t_gcc-4.3.3+cs_uClibc-0.9.30.1_eabi/usr/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.3.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/lib/libc.a: could not read symbols: File format not recognized collect2: ld returned 1 exit status libtool: install: error: relink `libiptc/libiptc.la' with the above command before installing it make[6]: *** [install-libLTLIBRARIES] Error 1___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Add CMake host tool support
Hi all, The attached patch against trunk adds CMake host tool support. When CONFIG_CMAKE is set in .config, the CMake tools will be build and installed in staging_dir/host/bin. To enable CONFIG_CMAKE, select "Advanced configuration options (for developers) in the main menu and select "Build CMake tool". When a package needs CMake to build, it just needs to have the line DEPENDS:=...@cmake in the Makefile. Please review this patch and add it to trunk. I'm working on creating an OpenWRT package of Gammu (http://wammu.eu/gammu/) that needs cmake to build, see https://dev.openwrt.org/ticket/7649 Can this patch please be added to backfire too? I'm working on a customer project based upon backfire that needs Gammu for communication with a GSM modem. It would be very nice to use backfire unmodified in the project. Thanks a lot in advance, Regards, -- Bas Index: tools/cmake/Makefile === --- tools/cmake/Makefile(revision 0) +++ tools/cmake/Makefile(revision 0) @@ -0,0 +1,35 @@ +# +# Copyright (C) 2010 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# +include $(TOPDIR)/rules.mk +include $(INCLUDE_DIR)/target.mk + +PKG_NAME:=cmake +PKG_VERSION_MAJOR=2.8 +PKG_VERSION_MINOR=3 +PKG_VERSION:=$(PKG_VERSION_MAJOR).$(PKG_VERSION_MINOR) + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz +PKG_SOURCE_URL:=http://www.cmake.org/files/v$(PKG_VERSION_MAJOR) +PKG_MD5SUM:=a76a44b93acf5e3badda9de111385921 +PKG_CAT:=zcat + +include $(INCLUDE_DIR)/host-build.mk + +define Host/Compile + $(MAKE) CC="$(HOSTCC)" -C $(HOST_BUILD_DIR) +endef + +define Host/Install + $(MAKE) -C $(HOST_BUILD_DIR) install +endef + +define Host/Clean + -$(MAKE) -C $(HOST_BUILD_DIR) uninstall + $(call Host/Clean/Default) +endef + +$(eval $(call HostBuild)) Index: tools/Makefile === --- tools/Makefile (revision 24012) +++ tools/Makefile (working copy) @@ -26,6 +26,7 @@ tools-y += squashfs4 lzma endif tools-$(CONFIG_CCACHE) += ccache +tools-$(CONFIG_CMAKE) += cmake ifdef CONFIG_GCC_USE_GRAPHITE ifeq ($(CONFIG_GCC_USE_SYSTEM_PPL_CLOOG),) @@ -98,5 +99,5 @@ $(curdir)/ := .config prereq $(curdir)//install = $(1)/compile -$(eval $(call stampfile,$(curdir),tools,install,,CONFIG_CCACHE CONFIG_powerpc CONFIG_GCC_VERSION_4_3 CONFIG_GCC_USE_GRAPHITE CONFIG_TARGET_orion_generic)) +$(eval $(call stampfile,$(curdir),tools,install,,CONFIG_CCACHE CONFIG_CMAKE CONFIG_powerpc CONFIG_GCC_VERSION_4_3 CONFIG_GCC_USE_GRAPHITE CONFIG_TARGET_orion_generic)) $(eval $(call subdir,$(curdir))) Index: Config.in === --- Config.in (revision 24012) +++ Config.in (working copy) @@ -393,6 +393,12 @@ help Compiler cache; see http://ccache.samba.org/ + config CMAKE + bool "Build CMake tool" if DEVEL + default n + help + CMake tool; see http://www.cmake.org/ + config EXTERNAL_KERNEL_TREE string "Use external kernel tree" if DEVEL default "" ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add CMake host tool support
On Thu, 18 Nov 2010 13:37:25 +0100, Jan Willies wrote: > Hi Bas, > > 2010/11/17 Bas Mevissen > The attached patch against trunk adds CMake host tool support. > > Thanks for your patch, I hope we can finally update Weechat (which > kinda depends on cmake) to something recent. > > I applied your patch but building fails however: > It looks you are trying to cross compile something that needs to be compiled for the host. Is there something defined in your environment for cross compiling? -- Bas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add CMake host tool support
On Thu, 18 Nov 2010 13:49:46 +0100, Bas Mevissen wrote: > On Thu, 18 Nov 2010 13:37:25 +0100, Jan Willies > wrote: >> Hi Bas, >> >> 2010/11/17 Bas Mevissen >> The attached patch against trunk adds CMake host tool support. >> >> Thanks for your patch, I hope we can finally update Weechat (which >> kinda depends on cmake) to something recent. >> >> I applied your patch but building fails however: >> > > It looks you are trying to cross compile something that needs to be > compiled for the host. Is there something defined in your environment > for cross compiling? The mail escaped before being finished... The text Line: gcc -Os -pipe -march=armv5te -mtune=marvell-f -funit-at-a-time cmake_bootstrap_22734_test.c -o cmake_bootstrap_22734_test in the output you posted lets me suspect that you exported a CFLAGS define like export CFLAGS=-march=armv5te -mtune=marvell-f -funit-at-a-time somewhere. I checked the output of build_dir/host/cmake-2.8.3/Bootstrap.cmk/cmake_bootstrap.log on my system: Test succeded Try: gcc Line: gcc cmake_bootstrap_10230_test.c -o cmake_bootstrap_10230_test -- file --- Regards, -- Bas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add CMake host tool support
On Thu, 18 Nov 2010 14:32:36 +0100, Jan Willies wrote: > The CFLAGS from target/linux/kirkwood/Makefile are > overriding include/host-build.mk [3]. So removing "include > $(INCLUDE_DIR)/target.mk [4]" from tools/cmake/Makefile did it for me. > Did you include it on purpose? > Ah, great. That is plain wrong. I just took the ccache Makefile as a template for cmake. So I was quite lucky that it compiled for me. Thanks for pointing out. I'll update my patch and check if ccache can/should do without target.mk too. Sorry for wasting your time. Regards, -- Bas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Add CMake host tool support [V2]
Hi all, The attached patch against trunk adds CMake host tool support. When CONFIG_CMAKE is set in .config, the CMake tools will be build and installed in staging_dir/host/bin. To enable CONFIG_CMAKE, select "Advanced configuration options (for developers) in the main menu and select "Build CMake tool". When a package needs CMake to build, it just needs to have the line DEPENDS:=...@cmake in the Makefile. Please review this patch and add it to trunk. I'm working on creating an OpenWRT package of Gammu (http://wammu.eu/gammu/) that needs cmake to build, see https://dev.openwrt.org/ticket/7649 Can this patch please be added to backfire too? I'm working on a customer project based upon backfire that needs Gammu for communication with a GSM modem. It would be very nice to use backfire unmodified in the project. Revision history: V1: first attempt V2: remove target compiler flags inclusion for native build Thanks a lot in advance, Regards, -- Bas cmake.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add CMake host tool support
On Thu, 18 Nov 2010 15:18:52 +0100, Jan Willies wrote: > define Build/Configure > > cd $(PKG_BUILD_DIR) > $(STAGING_DIR)/../host/bin/cmake . > endef > The host bin dir is already in the path, so you should be able to call cmake without defining a patch We could also define $CMAKE in rules.mk to have a better definition: Index: rules.mk === --- rules.mk(revision 24025) +++ rules.mk(working copy) @@ -164,6 +164,9 @@ TARGET_CXX:=$(if $(CONFIG_INSTALL_LIBSTDCPP),$(TARGET_CROSS)g++,no) KPATCH:=$(SCRIPT_DIR)/patch-kernel.sh SED:=$(STAGING_DIR_HOST)/bin/sed -i -e +ifneq ($(CONFIG_CMAKE),) + export CMAKE=$(STAGING_DIR_HOST)/bin/cmake +endif CP:=cp -fpR LN:=ln -sf (I'm not sure where to put it in the rules.mk file) > CMake Error: The source directory > "/var/tmp/swjawill/openwrt-dockstar/feeds/packages/net/weechat" does > not appear to contain CMakeLists.txt. That is because CMAKE is ran in the wrong directory. Try something like define Build/Configure (cd $(PKG_BUILD_DIR); \ $(CMAKE) . || exit 1 \ ); $(call Build/Configure/Default) endef (this assumes the patch to rules.mk; otherwise replace $(CMAKE) with cmake) Regards, -- Bas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add CMake host tool support
On 11/18/2010 06:53 PM, Jan Willies wrote: > Unfortunately cmake picks up the host-gcc: > > (cd > /var/tmp/swjawill/openwrt-dockstar/build_dir/target-arm_v5te_uClibc-0.9.30.1_eabi/weechat-0.3.3; > /var/tmp/swjawill/openwrt-dockstar/staging_dir/host/bin/cmake . || exit 1 ); > -- The C compiler identification is GNU > -- Check for working C compiler: /usr/bin/gcc > [...] > > Am I supposed to call it with some options or something? > Now the fishy part begins. :-) We need to tell cmake that we are cross compiling. Here is a good start: http://www.cmake.org/Wiki/CMake_Cross_Compiling I guess we need a toolchain file. I'm wondering if we can provide one for all packages that use cmake (it should be). So that is something that tools/cmake/Makefile could generate. Package should than simply call cmake -DCMAKE_TOOLCHAIN_FILE=.../staging_dir/somewhere/tc_file.cmake I'll take a look at it over the weekend. Hopefully, I can get the gammu package working as well. Thanks for your feedback so far! Regards, Bas. -- Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] iptables compile fix
On Mon, 22 Nov 2010 11:51:22 +0100, Maarten Bezemer wrote: > Gr... Whatever I try it compiles now (even my own .config works)... > Weird since there is nothing changed to the iptables package lately (or > related things?). > > Only change I can think of is the update to Kubuntu 10.10 (from 10.04), > but that was a while ago as well. Unfortunately I do not have a 10.04 to > test this theory (and it should be be the reason as well I guess). > > Thanks for your help and time! OK, Happy to hear it is solved now. These things happen now and then and are difficult to reproduce and even more difficult to pin down to what is actually causing it. Anyway, thanks for the feedback. Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] iptables compile fix
On Tue, 23 Nov 2010 10:49:52 +0100, Maarten Bezemer wrote: > Hi, > > I found the problem (compile errors are back): > When building everything from scratch with > > make -j 9 > > iptables does not compile. When building (with same .config file) > without -j it builds fine. > > I also believe that the problem is with the toolchain: after building > the toolchain without -j, iptables can be build with -j without > problems! > > It might be nice you (or someone else) could try building for Marvel > Orion from scratch with parallel build to see if this can be reproduced? > Tested with backfire r24107: make distclean make menuconfig # only selected Marvell Orion make -j 9 2>&1 | tee build.log builds fine here, including iptables. Sorry again, I cannot reproduce the issue here (Fedora 14 X86_64 DomU virtual machine). Regards, -- Bas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Re-compiling released OpenWrt versions
On Fri, 2011-03-04 at 11:05 +0100, Mark Vels wrote: > Please add at least a revision number in feeds.conf for anything else > than bleeding edge! Time to grow up! > Yes, IMHO every OpenWRT tag and preferably every branch should contain a feeds.conf file with revision numbers set for the trees it depends on. Regards, -- Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Patches to fix AVR32 and lk 2.6.25+ stuff
Please check https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3755 for a fix for kmod-ebtables package not being built on 2.6.25+ kernels. Please check https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3756 for a fix for a build error with kmod-i2c-core package on AVR32 2.6 kernels. This might apply to other archs as well. Regards, Bas. (yes, this e-mail address works) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Patches to fix AVR32 and lk 2.6.25+ stuff
Bas Mevissen wrote: > Please check https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3755 for a > fix for kmod-ebtables package not being built on 2.6.25+ kernels. > OK, comment here was the it would cause performance degradation. But is that also the case when the ebtables modules are not loaded? See my added comment on this ticket. Another question: can you let OpenWRT configuration options depend on the kernel configuration? And is that something wise to do? Idea is to disable the kmod-ebtables when ebtables is not defined in the kernel. Same for kmod-i2c-core. (see <https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3756>) Regards, Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1
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 4/7/21 12:29 AM, Hauke Mehrtens wrote: Hi, How do we want to go forward with OpenWrt 21.02-rc1? * I think the base system is ok. * The http (original wolfssl) problem reported by jow is fixed * LuCI in the 21.02 branch still misses DSA support, this was merged into master some time ago as far as I understood. Jow reported this end of March: > I found some serious regressions in the luci device config support. > not sure yet how long it'll take to sort out. The netifd uci config > grew so complex that it'll take a while to try all cases > * changing interface settings after previously enabling certain > options results in a brick > * wireless networks with custom ifnames are improperly bridged > * option ipv6 for ppp based protocols is broken because it clashes > with option ipv6 in device sections I would like to merge this update of iproute2 if Russel is fine with it, but I do not see this blocking 21.02-rc1: https://github.com/openwrt/openwrt/pull/4025 If there are some other bugs in the 21.02 branch which are fixed in master, we can backport the fixed as long as they are not so big. If there is something missing, just ask on the mainling list. In would like to get 21.02-rc1 soon, so more users start testing it and we get more bug reports. How should we continue? 1. Tag 21.02-rc1 and do the release in the next days with the current state. 2. Merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 ~3 days to see if some big problems come up. Will Wifi 6 support be added to the interface? We have some support for a couple of AX routers, so it would be nice if they can work without manually tweaking things. The underlying structure seems to support it already: https://forum.openwrt.org/t/got-802-11ax-working-in-linksys-e8450/91533 3. Wait till the problems reported by jow are fixed and do the 21.02-rc1 them. 4. Wait an other 2 weeks and see how it looks them. I would prefer if we merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 soon. We should list the problems as known problems. It would be nice if someone else could also look into these problems and propose fixes. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1
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 2021-04-07 20:07, John Crispin wrote: On 07.04.21 12:16, Bas Mevissen via openwrt-devel wrote: Will Wifi 6 support be added to the interface? We have some support for a couple of AX routers, so it would be nice if they can work without manually tweaking things. The underlying structure seems to support it already: https://forum.openwrt.org/t/got-802-11ax-working-in-linksys-e8450/91533 I have a couple of patches pending that I will post the next few days that will make the primary HE features work on 21.02. I converged my home to 3xe8450 Good to hear. I've an X5000R waiting to be converted to OpenWRT. The E8450 or RT3200 would have been a better choice, but at the time I wanted to order a supported AX router, it was only the X5000R or the UniFi 6 Lite to choose from. The X5000R unfortunately cannot max out the Killer Wifi card in my notebook, but it still makes around 800Mbit/s with iperf3 though. Bas. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] Extend checks on build prerequisites for building OpenWRT core
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 --- OpenWRT requires a number of Perl modules to be installed. It wasn't checking on all of them. This patch adds checks for Perl FindBin, File::Copy, File::Compare and Thread::Queue modules. Failing to install these, will have the build break at some point. By adding these to the prereq-build.mk script, they are checked on forehand. Tested on a Fedora 33 and 34 (beta) that was freshly installed. Fedora appears to break up Perl modules into small packages that need to be installed for the build to succeed. Signed-off-by: Bas Mevissen --- include/prereq-build.mk | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/include/prereq-build.mk b/include/prereq-build.mk index 86c22f7c95..cb3dcc51e3 100644 --- a/include/prereq-build.mk +++ b/include/prereq-build.mk @@ -65,11 +65,22 @@ $(eval $(call TestHostCommand,perl-data-dumper, \ Please install the Perl Data::Dumper module, \ perl -MData::Dumper -e 1)) +$(eval $(call TestHostCommand,perl-findbin, \ + Please install the Perl FindBin module, \ + perl -MFindBin -e 1)) + +$(eval $(call TestHostCommand,perl-file-copy, \ + Please install the Perl File::Copy module, \ + perl -MFile::Copy -e 1)) + +$(eval $(call TestHostCommand,perl-file-compare, \ + Please install the Perl File::Compare module, \ + perl -MFile::Compare -e 1)) + $(eval $(call TestHostCommand,perl-thread-queue, \ Please install the Perl Thread::Queue module, \ perl -MThread::Queue -e 1)) - $(eval $(call SetupHostCommand,tar,Please install GNU 'tar', \ gtar --version 2>&1 | grep GNU, \ gnutar --version 2>&1 | grep GNU, \ -- 2.31.1 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] Extend checks on build prerequisites for building OpenWRT core
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 --- OpenWRT requires a number of Perl modules to be installed. It wasn't checking on all of them. This patch adds checks for Perl FindBin, File::Copy, File::Compare and Thread::Queue modules. Failing to install these, will have the build break at some point. By adding these to the prereq-build.mk script, they are checked on forehand. Tested on a Fedora 33 and 34 (beta) that was freshly installed. Fedora appears to break up Perl modules into small packages that need to be installed for the build to succeed. Signed-off-by: Bas Mevissen --- include/prereq-build.mk | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/include/prereq-build.mk b/include/prereq-build.mk index 86c22f7c95..cb3dcc51e3 100644 --- a/include/prereq-build.mk +++ b/include/prereq-build.mk @@ -65,11 +65,22 @@ $(eval $(call TestHostCommand,perl-data-dumper, \ Please install the Perl Data::Dumper module, \ perl -MData::Dumper -e 1)) +$(eval $(call TestHostCommand,perl-findbin, \ + Please install the Perl FindBin module, \ + perl -MFindBin -e 1)) + +$(eval $(call TestHostCommand,perl-file-copy, \ + Please install the Perl File::Copy module, \ + perl -MFile::Copy -e 1)) + +$(eval $(call TestHostCommand,perl-file-compare, \ + Please install the Perl File::Compare module, \ + perl -MFile::Compare -e 1)) + $(eval $(call TestHostCommand,perl-thread-queue, \ Please install the Perl Thread::Queue module, \ perl -MThread::Queue -e 1)) - $(eval $(call SetupHostCommand,tar,Please install GNU 'tar', \ gtar --version 2>&1 | grep GNU, \ gnutar --version 2>&1 | grep GNU, \ -- 2.31.1 Friendly ping to consider this patch for 21.02. Thanks, --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] Extend checks on build prerequisites for building OpenWRT core
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 4/29/21 11:40 AM, Paul Spooren wrote: On 4/20/21 1:08 AM, Bas Mevissen wrote: OpenWRT requires a number of Perl modules to be installed. It wasn't checking on all of them. This patch adds checks for Perl FindBin, File::Copy, File::Compare and Thread::Queue modules. Failing to install these, will have the build break at some point. By adding these to the prereq-build.mk script, they are checked on forehand. Tested on a Fedora 33 and 34 (beta) that was freshly installed. Fedora appears to break up Perl modules into small packages that need to be installed for the build to succeed. Signed-off-by: Bas Mevissen --- include/prereq-build.mk | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/include/prereq-build.mk b/include/prereq-build.mk index 86c22f7c95..cb3dcc51e3 100644 --- a/include/prereq-build.mk +++ b/include/prereq-build.mk @@ -65,11 +65,22 @@ $(eval $(call TestHostCommand,perl-data-dumper, \ Please install the Perl Data::Dumper module, \ perl -MData::Dumper -e 1)) +$(eval $(call TestHostCommand,perl-findbin, \ + Please install the Perl FindBin module, \ + perl -MFindBin -e 1)) + +$(eval $(call TestHostCommand,perl-file-copy, \ + Please install the Perl File::Copy module, \ + perl -MFile::Copy -e 1)) + +$(eval $(call TestHostCommand,perl-file-compare, \ + Please install the Perl File::Compare module, \ + perl -MFile::Compare -e 1)) Could you please point me to where this module is required? I naively grepped through openwrt.git and couldn't find it. The other added requirements seem fine. It is in the host autoconf build. On Fedora 34, against current master, without the patch to test the need for File::Compare: $ sudo rpm -e perl-File-Compare (...) $ make -j1 V=s (...) make[3]: Entering directory '/home/bas/Workspace/openwrt-master/tools/autoconf' export SHELL="bash"; make -C /home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69 make[4]: Entering directory '/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69' make all-recursive make[5]: Entering directory '/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69' Making all in bin make[6]: Entering directory '/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69/bin' autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg' ../bin/autom4te -B '..'/lib -B '..'/lib --language M4sh --cache '' --melt ./autoconf.as -o autoconf.in Can't locate File/Compare.pm in @INC (you may need to install the File::Compare module) (@INC contains: ../lib /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at ../lib/Autom4te/FileUtils.pm line 166. BEGIN failed--compilation aborted at ../lib/Autom4te/FileUtils.pm line 166. Compilation failed in require at ../bin/autom4te line 43. BEGIN failed--compilation aborted at ../bin/autom4te line 43. make[6]: *** [Makefile:641: autoconf.in] Error 2 (...) $ sudo dnf install -y perl-File-Compare (...) $ make -j4 (build finishes) + $(eval $(call TestHostCommand,perl-thread-queue, \ Please install the Perl Thread::Queue module, \ perl -MThread::Queue -e 1)) - $(eval $(call SetupHostCommand,tar,Please install GNU 'tar', \ gtar --version 2>&1 | grep GNU, \ gnutar --version 2>&1 | grep GNU, \ --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] Extend checks on build prerequisites for building OpenWRT core
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 --- Friendly ping. Bas. On 2021-04-29 22:39, Bas Mevissen wrote: On 4/29/21 11:40 AM, Paul Spooren wrote: On 4/20/21 1:08 AM, Bas Mevissen wrote: OpenWRT requires a number of Perl modules to be installed. It wasn't checking on all of them. This patch adds checks for Perl FindBin, File::Copy, File::Compare and Thread::Queue modules. Failing to install these, will have the build break at some point. By adding these to the prereq-build.mk script, they are checked on forehand. Tested on a Fedora 33 and 34 (beta) that was freshly installed. Fedora appears to break up Perl modules into small packages that need to be installed for the build to succeed. Signed-off-by: Bas Mevissen --- include/prereq-build.mk | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/include/prereq-build.mk b/include/prereq-build.mk index 86c22f7c95..cb3dcc51e3 100644 --- a/include/prereq-build.mk +++ b/include/prereq-build.mk @@ -65,11 +65,22 @@ $(eval $(call TestHostCommand,perl-data-dumper, \ Please install the Perl Data::Dumper module, \ perl -MData::Dumper -e 1)) +$(eval $(call TestHostCommand,perl-findbin, \ + Please install the Perl FindBin module, \ + perl -MFindBin -e 1)) + +$(eval $(call TestHostCommand,perl-file-copy, \ + Please install the Perl File::Copy module, \ + perl -MFile::Copy -e 1)) + +$(eval $(call TestHostCommand,perl-file-compare, \ + Please install the Perl File::Compare module, \ + perl -MFile::Compare -e 1)) Could you please point me to where this module is required? I naively grepped through openwrt.git and couldn't find it. The other added requirements seem fine. It is in the host autoconf build. On Fedora 34, against current master, without the patch to test the need for File::Compare: $ sudo rpm -e perl-File-Compare (...) $ make -j1 V=s (...) make[3]: Entering directory '/home/bas/Workspace/openwrt-master/tools/autoconf' export SHELL="bash"; make -C /home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69 make[4]: Entering directory '/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69' make all-recursive make[5]: Entering directory '/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69' Making all in bin make[6]: Entering directory '/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69/bin' autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg' ../bin/autom4te -B '..'/lib -B '..'/lib --language M4sh --cache '' --melt ./autoconf.as -o autoconf.in Can't locate File/Compare.pm in @INC (you may need to install the File::Compare module) (@INC contains: ../lib /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at ../lib/Autom4te/FileUtils.pm line 166. BEGIN failed--compilation aborted at ../lib/Autom4te/FileUtils.pm line 166. Compilation failed in require at ../bin/autom4te line 43. BEGIN failed--compilation aborted at ../bin/autom4te line 43. make[6]: *** [Makefile:641: autoconf.in] Error 2 (...) $ sudo dnf install -y perl-File-Compare (...) $ make -j4 (build finishes) + $(eval $(call TestHostCommand,perl-thread-queue, \ Please install the Perl Thread::Queue module, \ perl -MThread::Queue -e 1)) - $(eval $(call SetupHostCommand,tar,Please install GNU 'tar', \ gtar --version 2>&1 | grep GNU, \ gnutar --version 2>&1 | grep GNU, \ --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[FIX proposal] Build error of host mklibs pkg of openwrt-19.07 branch on Fedora 34
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 ---
(resent as previous attempt didn't seem to get through)
Hi all,
The g++ version 11.1.1 of Fedora 34 defaults to g++17 and making the
build of host package mklibs fail. See build error below.
Obviously, least intrusive fix is to set the C++ standard to g++14 or
lower. However, on master the problem is not there due to an upgrade of
mklibs to version 0.1.44 (among some other changes). This is done in
commit 9437012b9ee4dc550e42665b71902cf885169100.
Guess we best cherry-pick that commit from master to upgrade mklibs to
0.1.44 as well. This commit was cleanly applied on top of openwrt-19.07
and the build went fine afterwards.
(build was for TP-Link Archer C7 v5 default config with ccache enabled
if that matters)
Regards,
Bas.
make[3]: Entering directory
'/home/bas/Workspace/openwrt-19.07/tools/mklibs'
CFLAGS="-O2 -I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include
-I/home/bas/Workspace/openwrt-19.07/tools/mklibs/include"
CPPFLAGS="-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include "
CXXFLAGS=""
LDFLAGS="-L/home/bas/Workspace/openwrt-19.07/staging_dir/host/lib " make
-j1 -C /home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35
make[4]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'
make all-recursive
make[5]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'
Making all in lib
make[6]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
Making all in mklibs
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
Making all in utils
make[8]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'
make[8]: Nothing to be done for 'all'.
make[8]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'
make[8]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[8]: Nothing to be done for 'all-am'.
make[8]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
make[7]: Nothing to be done for 'all-am'.
make[7]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
make[6]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
Making all in src
make[6]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src'
Making all in mklibs-readelf
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src/mklibs-readelf'
ccache g++ -DHAVE_CONFIG_H -I. -I../..
-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include -g -O2
-MT elf.o -MD -MP -MF .deps/elf.Tpo -c -o elf.o elf.cpp
In file included from elf_data.hpp:24,
from elf.cpp:21:
elf.hpp:52:56: error: ISO C++17 does not allow dynamic exception
specifications
52 | const section &get_section(unsigned int i) const throw
(std::out_of_range) { return *sections.at(i); };
|^
elf.hpp:62:47: error: ISO C++17 does not allow dynamic exception
specifications
62 | static file *open(const char *filename) throw
(std::bad_alloc, std::runtime_error);
| ^
elf.hpp:65:38: error: ISO C++17 does not allow dynamic exception
specifications
65 | file(uint8_t *mem, size_t len) throw (std::bad_alloc) :
mem(mem), len(len) { }
| ^
elf.hpp:68:52: error: ISO C++17 does not allow dynamic exception
specifications
68 | static file *open_class(uint8_t *, size_t) throw
(std::bad_alloc, std::runtime_error);
|^
elf.hpp:131:55: error: ISO C++17 does not allow dynamic exception
specifications
131 | std::string get_string(uint32_t offset) const throw
(std::bad_alloc)
| ^
elf.hpp:266:39: error: ISO C++17 does not allow dynamic exception
specifications
266 | std::string get_version() const throw (std::bad_alloc);
| ^
elf.hpp:267:44: error: ISO C++17 does not allow dynamic exception
specifications
267 | std::string get_version_file() const throw
(std::bad_alloc);
|
[FIX proposal] Build error of host mklibs pkg of openwrt-19.07 branch on Fedora 34
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 ---
Hi all,
The g++ version 11.1.1 of Fedora 34 defaults to g++17 and making the
build of host package mklibs fail. See build error below.
Obviously, least intrusive fix is to set the C++ standard to g++14 or
lower. However, on master the problem is not there due to an upgrade of
mklibs to version 0.1.44 (among some other changes). This is done in
commit 9437012b9ee4dc550e42665b71902cf885169100.
Guess we best cherry-pick that commit from master to upgrade mklibs to
0.1.44 as well. This commit was cleanly applied on top of openwrt-19.07
and the build went fine afterwards.
(build was for TP-Link Archer C7 v5 default config with ccache enabled
if that matters)
Regards,
Bas.
make[3]: Entering directory '/home/bas/Workspace/openwrt-19.07/tools/mklibs'
CFLAGS="-O2 -I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include
-I/home/bas/Workspace/openwrt-19.07/tools/mklibs/include"
CPPFLAGS="-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include "
CXXFLAGS=""
LDFLAGS="-L/home/bas/Workspace/openwrt-19.07/staging_dir/host/lib " make
-j1 -C /home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35
make[4]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'
make all-recursive
make[5]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'
Making all in lib
make[6]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
Making all in mklibs
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
Making all in utils
make[8]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'
make[8]: Nothing to be done for 'all'.
make[8]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'
make[8]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[8]: Nothing to be done for 'all-am'.
make[8]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
make[7]: Nothing to be done for 'all-am'.
make[7]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
make[6]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
Making all in src
make[6]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src'
Making all in mklibs-readelf
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src/mklibs-readelf'
ccache g++ -DHAVE_CONFIG_H -I. -I../..
-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include -g -O2
-MT elf.o -MD -MP -MF .deps/elf.Tpo -c -o elf.o elf.cpp
In file included from elf_data.hpp:24,
from elf.cpp:21:
elf.hpp:52:56: error: ISO C++17 does not allow dynamic exception
specifications
52 | const section &get_section(unsigned int i) const throw
(std::out_of_range) { return *sections.at(i); };
|^
elf.hpp:62:47: error: ISO C++17 does not allow dynamic exception
specifications
62 | static file *open(const char *filename) throw
(std::bad_alloc, std::runtime_error);
| ^
elf.hpp:65:38: error: ISO C++17 does not allow dynamic exception
specifications
65 | file(uint8_t *mem, size_t len) throw (std::bad_alloc) :
mem(mem), len(len) { }
| ^
elf.hpp:68:52: error: ISO C++17 does not allow dynamic exception
specifications
68 | static file *open_class(uint8_t *, size_t) throw
(std::bad_alloc, std::runtime_error);
|^
elf.hpp:131:55: error: ISO C++17 does not allow dynamic exception
specifications
131 | std::string get_string(uint32_t offset) const throw
(std::bad_alloc)
| ^
elf.hpp:266:39: error: ISO C++17 does not allow dynamic exception
specifications
266 | std::string get_version() const throw (std::bad_alloc);
| ^
elf.hpp:267:44: error: ISO C++17 does not allow dynamic exception
specifications
267 | std::string get_version_file() const throw (std::bad_alloc);
|^
elf.hpp:269:44: erro
[Q] [master][openwrt-21.02] Check on 'which' in include/prereq-build.mk fails for Fedora 34 since recently, how to fix?
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 ---
tldr; A recent upgrade of the which package on Fedora 34 broke the test
in OpenWRT on 'which' being installed on the host. I would love to send
a patch, but my question is how to fix this? Any ideas welcome!
Regards,
Bas.
I ran into the following:
$ ./scripst/feeds update -a
(...)
Checking 'rsync'... ok.
Checking 'which'... failed.
Checking 'ldconfig-stub'... ok.
Build dependency: Please install 'which'
(...)
$ rpm -qa which
which-2.21-26.fc34.x86_64
I noticed that file /etc/profile.d/which2.sh had changed recently. So I
downloaded previous version of the package and extracted said file.
Sourced the old file and ran update again:
$ . ~/Downloads/which2.sh
$ ./scripts/feeds update
(...)
Checking 'rsync'... ok.
Checking 'which'... ok.
Checking 'ldconfig-stub'... ok.
(...)
The relevant part in include/prereq-build.mk is:
$(eval $(call SetupHostCommand,which,Please install 'which', \
which which | grep which))
The difference between the two versions of which2.sh is:
$ diff -u ~/Downloads/which2.sh /etc/profile.d/which2.sh
--- /home/bas/Downloads/which2.sh 2021-03-23 20:22:52.0 +0100
+++ /etc/profile.d/which2.sh2021-05-04 11:52:55.0 +0200
@@ -1,18 +1,19 @@
# shellcheck shell=sh
# Initialization script for bash, sh, mksh and ksh
-_declare="declare -f"
-_opt="-f"
-_shell="$(basename $SHELL)"
+which_declare="declare -f"
+which_opt="-f"
+which_shell="$(cat /proc/$$/comm)"
-if [ "$_shell" = "ksh" ] || [ "$_shell" = "mksh" ] || [ "$_shell" =
"zsh" ] ; then
- _declare="typeset -f"
- _opt=""
+if [ "$which_shell" = "ksh" ] || [ "$which_shell" = "mksh" ] || [
"$which_shell" = "zsh" ] ; then
+ which_declare="typeset -f"
+ which_opt=""
fi
which ()
{
-(alias; eval ${_declare}) | /usr/bin/which --tty-only --read-alias
--read-functions --show-tilde --show-dot "$@"
+(alias; eval ${which_declare}) | /usr/bin/which --tty-only --read-alias
--read-functions --show-tilde --show-dot "$@"
}
-export ${_opt} which
+export which_declare
+export ${which_opt} which
I don't see why this breaks the check. The difference is mainly in
renaming the variables used.
As said, any hint welcome!
Regards,
Bas.
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 19.07] tools/mklibs: Fix compile with GCC 11
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 2021-05-16 23:57, Hauke Mehrtens wrote:
GCC 11 defaults to C++17, but mklibs does not compile when using the
C++17 standard. This patch switches back to the gnu++98 version like
done in master commit 9437012b9ee4 ("tools/mklibs: update to 0.1.44 and
convert to Python 3")
This fixes the following compile error message:
elf.hpp:52:56: error: ISO C++17 does not allow dynamic exception
specifications
52 | const section &get_section(unsigned int i) const throw
(std::out_of_range) { return *sections.at(i); };
Signed-off-by: Hauke Mehrtens
---
tools/mklibs/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/mklibs/Makefile b/tools/mklibs/Makefile
index 507c2fd394..8826840524 100644
--- a/tools/mklibs/Makefile
+++ b/tools/mklibs/Makefile
@@ -18,6 +18,7 @@ HOST_FIXUP:=autoreconf
include $(INCLUDE_DIR)/host-build.mk
HOST_CFLAGS += -I$(CURDIR)/include
+HOST_CPPFLAGS += -std=gnu++98
define Host/Install
$(INSTALL_BIN) \
Thanks, this probably the best thing to do for 19.07. I overlooked the
change above in the 9437012b9ee4 commit and assumed the mklibs 0.1.44
was gnu++17 compliant.
Bas.
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Flagship AX routers
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 5/18/21 11:52 PM, Philip Prindeville wrote: Hi all, I noticed that there are several AX routers from TP-Link, Netgear, D-Link, etc. and some of them have even had OpenWRT ported to them. Which of these various platforms has the most CPU/RAM/FLASH? A few are discussed, but I'm not seeing consensus on "the best one currently is this..." And not to forget, which ones are affordable given the current shortages and are (still) available globally. https://forum.openwrt.org/t/802-11ax-routers/10484/281 Also saw this: https://10-0-0-0-1.org/reviews/routers/openwrt/ But it only lists AC routers. Was looking at this: https://www.amazon.com/TP-Link-WiFi-AX3000-Smart-Router/dp/B07YMFZ28Q/ But it doesn't call out CPU, memory, or storage. Got there from this page: https://www.amazon.com/OpenWrt-Routers-Networking-Products/s?k=OpenWrt&rh=n%3A300189 Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath79: rb4xx-nand: fix 512 byte pages compatibility
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 ---
A few nitpicks:
On 2021-05-28 00:27, Sergey Ryazanov wrote:
MikroTik boards with 512 byte NAND pages require the old YAFFS1 OOB
layout for compatibility with the RouterBoot bootloader. The RB4xx NAND
driver supports such OOB layout, but checks a NAND page size too early
before the flash identification, what effectively preventing the old
OOB
layout from being used.
To fix this issue, move the page size check and OOB layout
configuration
to the chip attaching hook, which is specially intorduced for ECC and
OOB tweaking.
While at it, copy a comment from the old AR71xx driver to make it
clear,
why do we need this OOB layout tweaking.
Run tested with MikroTik RB411U board.
Signed-off-by: Sergey Ryazanov
---
.../files/drivers/mtd/nand/raw/nand_rb4xx.c | 25 ---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git
a/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
index 50bd69f6a4..00c65d14ae 100644
--- a/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
+++ b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
@@ -81,6 +81,23 @@ static const struct mtd_ooblayout_ops
rb4xx_nand_ecclayout_ops = {
.free = rb4xx_ooblayout_free,
};
+static int rb4xx_nand_attach_chip(struct nand_chip *chip)
+{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+
+ /*
+* Now we knows flash parameters and can tweak OOB the layout for old
Rephrase to something like:
Knowing the flash parameters, we can tweak the OOB layout for old
+* (usually 64MiB) flashes.
+*
+* We need to use the OLD Yaffs-1 OOB layout, otherwise the RB
+* bootloader will not be able to find the kernel that we load.
+*/
+ if (mtd->writesize == 512)
+ mtd_set_ooblayout(mtd, &rb4xx_nand_ecclayout_ops);
+
+ return 0;
+}
+
static u8 rb4xx_nand_read_byte(struct nand_chip *chip)
{
struct rb4xx_nand *nand = chip->priv;
@@ -135,6 +152,10 @@ static int rb4xx_nand_dev_ready(struct nand_chip
*chip)
return gpiod_get_value_cansleep(nand->rdy);
}
+static const struct nand_controller_ops rb4xx_nand_controller_ops = {
+ .attach_chip = rb4xx_nand_attach_chip,
remove the ,
+};
+
static int rb4xx_nand_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -185,9 +206,6 @@ static int rb4xx_nand_probe(struct platform_device
*pdev)
mtd->dev.parent = dev;
mtd_set_of_node(mtd, dev->of_node);
- if (mtd->writesize == 512)
- mtd_set_ooblayout(mtd, &rb4xx_nand_ecclayout_ops);
-
nand->chip.ecc.mode = NAND_ECC_SOFT;
nand->chip.ecc.algo = NAND_ECC_HAMMING;
nand->chip.options = NAND_NO_SUBPAGE_WRITE;
@@ -199,6 +217,7 @@ static int rb4xx_nand_probe(struct platform_device
*pdev)
nand->chip.legacy.cmd_ctrl = rb4xx_nand_cmd_ctrl;
nand->chip.legacy.dev_ready = rb4xx_nand_dev_ready;
nand->chip.legacy.chip_delay = 25;
+ nand->chip.legacy.dummy_controller.ops = &rb4xx_nand_controller_ops;
Fix indentation for all nand->something assignments to line up the =
sign
ret = nand_scan(&nand->chip, 1);
if (ret)
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath79: rb4xx-nand: fix 512 byte pages compatibility
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 2021-05-28 13:55, Sergey Ryazanov wrote:
Hello Bas,
thank you for your review, please find my comments below.
On Fri, May 28, 2021 at 11:41 AM Bas Mevissen
wrote:
On 2021-05-28 00:27, Sergey Ryazanov wrote:
[skipped]
+static int rb4xx_nand_attach_chip(struct nand_chip *chip)
+{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+
+ /*
+ * Now we knows flash parameters and can tweak OOB the layout
for old
Rephrase to something like:
Knowing the flash parameters, we can tweak the OOB layout for old
Yeah, I am not happy with this comment too, but this is the best I was
able to compose at 01:00 :) I will rephrase it if V2 will be needed.
Here we need a comment that briefly and clearly states that the NAND
params become known at this particular moment of initialization.
Before this moment, we do not know the page size, after this moment it
is too late to reconfigure something. Do you have any thoughts?
The original comment with some spelling/grammar corrections looked fine.
Having some hint that something is deliberately done at that stage is
sufficient IMHO.
+ * (usually 64MiB) flashes.
+ *
+ * We need to use the OLD Yaffs-1 OOB layout, otherwise the RB
+ * bootloader will not be able to find the kernel that we load.
+ */
+ if (mtd->writesize == 512)
+ mtd_set_ooblayout(mtd, &rb4xx_nand_ecclayout_ops);
+
+ return 0;
+}
+
static u8 rb4xx_nand_read_byte(struct nand_chip *chip)
{
struct rb4xx_nand *nand = chip->priv;
@@ -135,6 +152,10 @@ static int rb4xx_nand_dev_ready(struct nand_chip
*chip)
return gpiod_get_value_cansleep(nand->rdy);
}
+static const struct nand_controller_ops rb4xx_nand_controller_ops =
{
+ .attach_chip = rb4xx_nand_attach_chip,
remove the ,
I intentionally placed the comma here to make text git-friendly. If we
will need to define more callbacks here, then we will just add a new
new line, without modifying the earlier added lines.
Agreed. It actually sounds like a good practice. Learned something today
:-)
E.g. if commit this code without the comma, then a chip detaching
callback patch will looks like this:
static const struct nand_controller_ops rb4xx_nand_controller_ops = {
- .attach_chip = rb4xx_nand_attach_chip
+ .attach_chip = rb4xx_nand_attach_chip,
+ .detach_chip = rb4xx_nand_detach_chip,
};
With this intentionally placed comma, the same theoretical patch will
looks like this:
static const struct nand_controller_ops rb4xx_nand_controller_ops = {
.attach_chip = rb4xx_nand_attach_chip,
+ .detach_chip = rb4xx_nand_detach_chip,
};
So this comma is my investment in the future ;)
+};
+
static int rb4xx_nand_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -185,9 +206,6 @@ static int rb4xx_nand_probe(struct
platform_device
*pdev)
mtd->dev.parent = dev;
mtd_set_of_node(mtd, dev->of_node);
- if (mtd->writesize == 512)
- mtd_set_ooblayout(mtd, &rb4xx_nand_ecclayout_ops);
-
nand->chip.ecc.mode = NAND_ECC_SOFT;
nand->chip.ecc.algo = NAND_ECC_HAMMING;
nand->chip.options = NAND_NO_SUBPAGE_WRITE;
@@ -199,6 +217,7 @@ static int rb4xx_nand_probe(struct
platform_device
*pdev)
nand->chip.legacy.cmd_ctrl = rb4xx_nand_cmd_ctrl;
nand->chip.legacy.dev_ready = rb4xx_nand_dev_ready;
nand->chip.legacy.chip_delay= 25;
+ nand->chip.legacy.dummy_controller.ops =
&rb4xx_nand_controller_ops;
Fix indentation for all nand->something assignments to line up the =
sign
I do not think that this is a good idea for this patch. Here we add
one line that configures the single field deep inside the structure.
The line is placed after the configuration of "surface" fields. So the
overall look should not be harmed dreadfully.
In case we will rework the indentation with this patch, the 57 lines
patch will become a ~70 lines patch. Where at least 12 lines will
rework indentation, so the functional part could be easily lost. Also
the moving text back and forth within an item line, turns the history
to the white noise and makes git-blame(1) usage a pain.
If you prefer, then I could insert an empty line before the ops setup
to make it nice looking. E.g. turn this hunk:
@@ -199,6 +217,7 @@ static int rb4xx_nand_probe(struct platform_device
*pdev)
nand->chip.legacy.cmd_ctrl = rb4xx_nand_cmd_ctrl;
nand->chip.legacy.dev_ready = rb4xx_nand_dev_ready;
nand->chip.legacy.chip_delay= 25;
+ nand->chip.legacy.dummy_controller.ops =
&rb4xx_nand_controller_ops;
into
Error compiling master on WSL2 Ubuntu 20.04
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 ---
Hi all,
In the last stages of compiling OpenWRT master on a WSL2 running Ubuntu
20.04, I get the following error message:
sed -i "s/Installed-Time: .*/Installed-Time: 1623018311/"
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/usr/lib/opkg/status
rm -rf
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/boot
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/tmp/*
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/usr/lib/opkg/info/*.postinst*
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/usr/lib/opkg/lists/*
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/var/lock/*.lock
find /home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/ -mindepth 1
-execdir touch -hcd "@1623018311" "{}" +
find: The relative path 'Files/dotnet/' is included in the PATH environment
variable, which is insecure in combination with the -execdir action of find.
Please remove that entry from $PATH
make[2]: *** [package/Makefile:73: package/install] Error 1
make[2]: Leaving directory '/home/bas/Workspace/openwrt'
make[1]: *** [package/Makefile:111:
/home/bas/Workspace/openwrt/staging_dir/target-mipsel_24kc_musl/stamp/.package_install]
Error 2
make[1]: Leaving directory '/home/bas/Workspace/openwrt'
make: *** [/home/bas/Workspace/openwrt/include/toplevel.mk:230: world] Error 2
The actual path is: $ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:/mnt/c/Windows/System32/OpenSSH/:/mnt/c/Program
Files/dotnet/:/mnt/c/Program Files (x86)/GnuPG/bin:/mnt/c/Program Files
(x86)/dotnet/:/mnt/c/Program Files/WireGuard/:/mnt/c/Program
Files/Git/cmd:/mnt/c/Program Files (x86)/AOMEI/AOMEI
Backupper/6.5.1:/mnt/c/Program Files (x86)/Bitvise SSH
Client:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Users/Bas
Mevissen/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/Bas
Mevissen/.dotnet/tools
It contains /mnt/c/Program Files/dotnet/ and other unquoted paths with
spaces. I would have expected them to be quoted or escaped, but none of
them seems to be the case.
(and shortening the path to a usual Linux path made the build finish, so
no other issues at hand)
Having spaces in PATH is discussed here:
https://github.com/Microsoft/WSL/issues/1766 in 2017 and apparently seen
as OK.
If I do for example:
$ which dotnet.exe
/mnt/c/Program Files/dotnet//dotnet.exe
it seems to work fine.
Any ideas?
Cheers,
Bas.
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Error compiling master on WSL2 Ubuntu 20.04
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 08/06/2021 00:45, Alberto Bursi wrote: On 07/06/21 22:35, Bas Mevissen via openwrt-devel wrote: It contains /mnt/c/Program Files/dotnet/ and other unquoted paths with spaces. I would have expected them to be quoted or escaped, but none of them seems to be the case. (and shortening the path to a usual Linux path made the build finish, so no other issues at hand) Having spaces in PATH is discussed here: https://github.com/Microsoft/WSL/issues/1766 in 2017 and apparently seen as OK. If I do for example: $ which dotnet.exe /mnt/c/Program Files/dotnet//dotnet.exe it seems to work fine. Any ideas? Cheers, Bas. Afaik the OpenWrt build system does not like paths and folders with spaces, and the documentation we have for using build system with WSL explains how to get rid of the Windows stuff in the path (so you don't have things with spaces). See https://openwrt.org/docs/guide-developer/build-system/wsl Thanks for the link. I wasn't aware of the existence of such a page. I don't really like the proposed solution. The problem is not the fact that they are Windows directories, but that they contain spaces. A better way would be to call OpenWRT Make with a Linux-only path like: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin make instead of modifying a global WSL setting. BTW. As far as I could find, spaces are legal in $PATH, so I would say that there are bugs in OpenWRT regarding handling paths with spaces. Thanks again, Bas. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: add option to make /var persistent
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 8/7/21 10:40 AM, Stijn Tintel wrote: On 7/08/2021 10:05, Alberto Bursi wrote: On 07/08/21 02:46, Stijn Tintel wrote: On 7/08/2021 02:56, Alberto Bursi wrote: On 06/08/21 21:27, Stijn Tintel wrote: In OpenWrt, /var is symlinked to /tmp by default. This is done to reduce the amount of writes to the flash chip, which often don't have the greatest durability. As a result, things like DHCP or UPnP lease files, are not persistent across reboots. Since OpenWrt can run on devices with more durable storage, it makes sense to have an option for a persistent /var. Add an option to make /var persistent. When enabled, /var will no longer be symlinked to /tmp, but /var/run will be symlink to /tmp/run, as it should contain only files that should not be kept during reboot. The option is off by default, to maintain the current behaviour. Since it does not really need to recompile anything, I think it can/should be handled as a package, not as a compile option. When you install the package these operations are executed, if you remove the package they are undone. Removing /var at runtime, which basically happens when you remove the symlink, is very ugly and has a huge potential for breakage. Having it as a build option also avoids users from accidentally installing it as a package. If you disagree, please elaborate further, including measures to avoid random breakage caused by removing /var at runtime. My focus was more on "not using a compile option", I don't think it's necessary to do this at runtime. A simple measure to avoid breakage would be to add something that runs on boot (either initscript or preinitscript) to do these changes before any other service that needs that folder is started. So you install the package and then reboot. This approach also allows to make this a permanent change (not an optional package) and control this function with UCI config, just change the setting and reboot. IMHO this is good enough for most users, and much better than having to recompile or do the change manually. For the sake of completeness, (also shameless plug about my project): A more complex way to do it at runtime that avoids breakage is bind mounting the original folder somewhere else so you can sync the contents with the new/empty folder, then restarting all services that need it. See https://github.com/bobafetthotmail/folder2ram/blob/master/debian_package/sbin/folder2ram#L658 (the service restart is not included in that script since it has no way of knowing what services need the folders, this operation is left to the user or for OpenMediaVault it's handled by the plugin that also writes the configuration) Appreciate the input. It still sounds overly complex compared to my suggestion, especially for something that most users will probably not use. I don't feel comfortable implementing something like that. I'll just keep using my patch locally then, as I have done for almost five years. I would love to see your patch it in de main tree. It is a nice addition for everyone using extroot (like me). Even without extroot and current flashes, it might be worthwile to enable this and make thinks like dhcp leases persistent. In a soho network, they don't change that often to wear out a flash. Thanks, Stijn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ar71xx: rb941-2nd support
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 2021-10-11 10:31, Bjoern Franke via openwrt-devel wrote: Hi, is there any chance of getting support for the MikroTik hAP lite classic back? Best Regards Bjoern It only has 32MB of RAM, see https://openwrt.org/supported_devices/432_warning about these kind of devices. You can make your own build that only includes what you need to make it fit the device constraints. -- Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ar71xx: rb941-2nd support
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 2021-10-11 10:31, Bjoern Franke via openwrt-devel wrote: Hi, is there any chance of getting support for the MikroTik hAP lite classic back? Best Regards Bjoern It only has 32MB of RAM, see https://openwrt.org/supported_devices/432_warning about these kind of devices. You can make your own build that only includes what you need to make it fit the device constraints. Regards, Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] Stop providing binary package updates for release builds?
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 2021-12-12 20:42, Jo-Philipp Wich wrote: Hi, (...) Hi Jo-Philips, thanks for the detailed write-up. As an embedded software developer, I feel much and mostly agree with your reasoning. However, one of the reasons I like to use OpenWRT so much on my production router(s) is exactly that availability of quality pre-build images and release branch matching up-to-date (security, bugs) packages. For production use, I really love the "official" built and tested releases and install them to my devices, even while having my own builds available. Next to that, I install packages of what additional functionality I need. For the 20.02.1 release, it was also the way to get rid of a small bug, as advised in the release notes (in a matter of seconds): " The menu bar in LuCI is wrongly aligned If this is a real problem for you update the LuCI theme: opkg upgrade luci-theme-bootstrap " (source: https://openwrt.org/releases/21.02/notes-21.02.1) This is what, in my humble opinion, makes OpenWRT such a great piece of software for even not-so-technical users: you just pick the latest release for your router and if you need some other functionality, you can simply install a few packages from the web UI. And if there is a small security update or bugfix, it is solved in a few mouse clicks for everyone, independent of their technical skills. So apart from being convenient, I feel the packages feed for release branches also provides easy access to stability and security to all users. Given all the issues found in IOT and routers with mostly out-of-date propriety firmware, OpenWRT in its current form is such an asset! In summary, I would urge the OpenWRT devs to not too lightly drop the binary distribution of images and packages it has now. If, however, it is decided otherwise, I'm thinking of a possible solution: a docker or other container-like image that users can download with for example the host tools pre-build and an easy to use interface to update the OpenWRT sources, and configure and build them to their needs. Cheers, Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] toolchain/gcc: set dialects for each version
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 1/25/22 18:02, Stijn Tintel wrote: GCC has an option "-std=" to set the language standard for C and C++. Newer GCC versions sometimes switch to newer standards by default. This has the potential to break the OpenWrt toolchain build whenever a distro introduces a new GCC version that uses a newer dialect by default. Let's set the default dialects used for each of the GCC versions we support, to avoid these toolchain build failures in the future. Shouldn't the logic be different? It is the software that is to be compiled that is written in a certain version or versions of C or C++ language. OpenWRT should set a default C and C++ language version and packages or any other software compiled with the OpenWRT build should override it when they need it. A package might for example define that they can be compiled with version C++11 to C++20 or require at least C++17 (and hence require a minimum GCC version). How does this currently work? Are packages assumed to be compilable with the default C or C++ language version of the default (host or target) GCC version? Regards, Bas. Signed-off-by: Stijn Tintel --- toolchain/gcc/common.mk | 8 1 file changed, 8 insertions(+) diff --git a/toolchain/gcc/common.mk b/toolchain/gcc/common.mk index bef4fa37f8..3e31a139cd 100644 --- a/toolchain/gcc/common.mk +++ b/toolchain/gcc/common.mk @@ -29,14 +29,20 @@ PKG_SOURCE_URL:=@GNU/gcc/gcc-$(PKG_VERSION) PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz ifeq ($(PKG_VERSION),8.4.0) + C_DIALECT=-std=gnu17 + CXX_DIALECT=-std=gnu++14 PKG_HASH:=e30a6e52d10e1f27ed55104ad233c30bd1e99cfb5ff98ab022dc941edd1b2dd4 endif ifeq ($(PKG_VERSION),10.3.0) + C_DIALECT=-std=gnu17 + CXX_DIALECT=-std=gnu++14 PKG_HASH:=64f404c1a650f27fc33da242e1f2df54952e3963a49e06e73f6940f3223ac344 endif ifeq ($(PKG_VERSION),11.2.0) + C_DIALECT=-std=gnu17 + CXX_DIALECT=-std=gnu++17 PKG_HASH:=d08edc536b54c372a1010ff6619dd274c0f1603aa49212ba20f7aa2cda36fa8b endif @@ -86,6 +92,8 @@ GCC_CONFIGURE:= \ CFLAGS="-O2 -fbracket-depth=512 -pipe" \ CXXFLAGS="-O2 -fbracket-depth=512 -pipe" \ ) \ + CFLAGS="$(CFLAGS) $(C_DIALECT)" \ + CXXFLAGS="$(CXXFLAGS) $(CXX_DIALECT)" \ $(HOST_SOURCE_DIR)/configure \ --with-bugurl=$(BUGURL) \ --with-pkgversion="$(PKGVERSION)" \ --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02.3 Third service release
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 2022-04-21 00:21, Hauke Mehrtens wrote: Hi, The OpenWrt community is proud to announce the third service release of OpenWrt 21.02. It fixes security issues, improves device support, and brings a few bug fixes. Thanks for all the hard work put into this! I noticed a small issue during the upgrade using the sysupgrade in Luci. After the first attempt, it showed I was still running 21.02.2. Flashing the same file again gave me the correct version (21.02.3). (the status overview also showed the old kernel version and a low uptime, so there was a reboot and I did not misread the version). I also only have the latest binary for a single router on my PC, so no mistake possible there as well. The only difference between my first and second attempt was that I did not tick the box "Include in backup a list of current installed packages at /etc/backup/installed_packages.txt" the second time. I do have some extra packages installed and updated some during the 21.02.2 lifetime. Router is a TP Link Archer C7 v5 that was running 21.02.2 before the upgrade. If more people experience this, it might be worth spending time on it. Otherwise, it might be best to just retry and be happy! Regards, Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [sdwalker/sdwalker.github.io] 2bdb42: This week's update
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 13/05/2022 01:59, Sergey Ryazanov wrote: Hello Jeffery, On Fri, May 13, 2022 at 2:03 AM Jeffery To wrote: On Fri, May 13, 2022 at 6:26 AM Sergey Ryazanov wrote: +1 Stephan, may I sincerely ask you to stop spamming the list? On Mon, May 9, 2022 at 12:08 PM wrote: is the below weekly message of any informational value to _all_? can someone maybe block this if it's not? ..thanks ede On 08.05.2022 23:05, Stephen Walker via openwrt-devel wrote: 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. As a package maintainer, I want to know that uscan is running correctly. These emails are relevant to me. Nice to hear that someone is actually using this information. May I ask why these notifications are directed to the mailing list that is dedicated for development talks? Such a notification just _looks_ irrelevant to some thread, it is not even a patchwork notification or a buildbot warning that is sent as a reply to a patch. It would be very simple to set up any competent email client to filter out these messages, if you so choose. It is a matter of balance. Everyone is happy to read these notifications, but someone will not need them and will create an automatic filtering rule. Or someone found these notifications useful, but everyone else wonders why they received them. The mail itself is currently not that informing. It is a lot of boiler plate and repetition. Only the link to the actual commit is useful information. I think it would be a huge improvement to have the highlights of the scan results posted in a nice readable format. A sort of condensed version of the page at https://sdwalker.github.io/uscan/index.html Is it possible to reconfigure these notifications to send them directly to your mailbox? Or maybe set up a dedicated mailing list? We already have the mailing list for commit notifications. I am subscribed and quite happy to be informed of development progress this way - it saves me a lot of time and does not bother people who prefer some other monitoring approach. This is a development list where the package maintainers and devs hang out, so it is relevant information. Only the current form isn't optimal IMHO. BR, Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build: always set CONFIG_IPV6
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 8/18/22 20:32, Robert Marko wrote: On Thu, 18 Aug 2022 at 20:07, Enrico Mioso wrote: Hello all!! In my opinion, it would be better to try keeping this option available. Surely, !IPV6 is not a common scenario these days. But I think OpenWrt might be useful to catch bugs like the one fixed in commit 77fc73ac89be96ec8f39e8efa53885caa7cb3645 in the Linux kernel's git tree. So, for what it's worth, a NACKfrom me. It's becoming increasingly hard to impossible to disable IPv6 in all of the SW that OpenWrt ships, that is the reason for this. More and more SW just doesn't have a way to disable IPv6 at all, so unless we want to carry even more patches this is kind of inevitable. It is 2022 after all, so ACK from me for what it's worth. Would it make sense to simply always build with IPV6 support and have the CONFIG_IPV6 flag repurposed to have the defaults for the network interfaces and kernel sysctls set to disable IPV6 as much as possible? This might make sense in environments where any IPV6 support is unwanted. Still many people have no IPV6 at home or at work and hence better not have it configured at their local network nor router. Rewgards, Bas. Regards, Robert Enrico On Thu, 18 Aug 2022, Paul Spooren wrote: Date: Thu, 18 Aug 2022 17:33:42 From: Paul Spooren To: Stijn Tintel Cc: Thibaut , openwrt-devel Subject: Re: [PATCH] build: always set CONFIG_IPV6 On 18. Aug 2022, at 16:07, Stijn Tintel wrote: On 18/08/2022 17:03, Thibaut wrote: Le 18 août 2022 à 15:40, Stijn Tintel a écrit : On 16/08/2022 20:00, Thibaut VARÈNE wrote: Disabling this build tunable breaks build and seems unrealistically likely to be fixed. This patch sets the related CONFIG to always true and removes the config prompt, keeping the change minimal, and, should !CONFIG_IPV6 ever be fixed, easy to revert. If we're always going to set it to yes, just drop the option entirely and enable it in the generic kernel configs. Aside from that: CONFIG_IPV6 is not a kernel config, it’s a tree-wide one. My idea was to keep the change as small as possible should we ever want to revert, while preventing further pointless bugreports[1]. Entirely removing the config option requires more invasive changes throughout the tree and the package repositories, which is significantly less trivial than this "first step". Cheers, Thibaut [1] https://github.com/openwrt/openwrt/issues/9580 OK, in that case, let's await at least one more ACK and we can start with this. Per request: Acked-by: Paul Spooren Thanks, Stijn ___ 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___ 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 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Terminology
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 2022-09-13 21:56, Jo-Philipp Wich wrote: Hi, IMHO changing, in /etc/config/network: "config interface" -> "config network" "config device" -> "config interface" would eliminate this semantic inconsistency and bring the naming convention more in line with what Rich referred to in his comments above. This cannot be done in a sane manner though as it would render future versions entirely backwards incompatible. Renaming `config interface` to `config network` makes sense and can be implemented easily. However we would still need to treat `config interface` as synonym for it in the forseeable future in order to retain compatibility, which means that we cannot reuse `interface` for something else. So changing `config interface` to `config network` would be possible assuming that `config device` remains `config device` (or is renamed to something other than `interface`). At the same time, the `wifi-iface` section type in /e/c/network should be changed to `wifi-network` in order to remain consistent. When you are at this level of changes and redefining and reusing names, normally it is time to reconsider the complete thing. I would suggest something like a JSON file based config with versioning so that later changes can be done in a forward compatible way. With some clever scripts, not too exotic existing configurations can be converted automatically, just like was done with the switch to DSA. Just my 2 cents.. Bas. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir
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 2023-01-20 13:24, Florian Eckert wrote: On 2023-01-20 12:49, Felix Fietkau wrote: On 20.01.23 12:42, Florian Eckert wrote: Hello Felix, During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Why is this necessary? $STAGING_DIR_HOST/bin should already be in $PATH before the host system parts. I only noticed that the prefix $(STAGING_DIR_HOST) is missing for these tools on x86_64 image Makefile. If I look for this prefix in OpenWrt, it is found in some image Makefiles commands. For examples: - https://github.com/openwrt/openwrt/blob/master/target/linux/realtek/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/bcm63xx/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/ath25/image/Makefile If this is in the PATH through this line https://github.com/openwrt/openwrt/blob/master/Makefile, then this is not needed for the others? I only wanted to unify this with the change and make it clear that the tool from staging is used here. Thanks. I don't have a strong opinion one way or the other, but I think the code might be more readable without the explicit $(STAGING_DIR_HOST)/bin prefix. Your right It works regardless of whether the prefix is there or not. But I would just like to note that it is easier to see whether the tools are now used from staging or the build host. The tool mkisofs https://github.com/openwrt/openwrt/blob/master/target/linux/x86/image/Makefile#L100, for example, is used from the build host! There is indeed a guard here https://github.com/openwrt/openwrt/blob/master/target/linux/x86/Makefile. But I am not sure if this is the case everywhere and if it is clear to everyone which tool is now being used during development. I just wanted to say that I am more in favor of explicitly select which tool is now being used. I think the actual tool used should be in a variable, like $(STAGING_HOST_SED). This is very readable and it also makes the list of tools used explicitly known. The PATH must still be set for tools to find other staging dir tools. Actually, the host path should be unset to avoid inadvertently using the host tools instead of the one of the staging dir. I personally would prefer using a chroot-ed staging host to avoid any host interference. Regards, Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
