[OpenWrt-Devel] [PATCH] procd: Update to latest head
This includes a fix for building against uClibc: http://git.openwrt.org/?p=project/procd.git;a=commit;h=9a6f83d3c168523ac7b898ae481c2fd8c501d6a6 Signed-off-by: Alexey Brodkin Cc: John Crispin --- package/system/procd/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/system/procd/Makefile b/package/system/procd/Makefile index 7ba2be3..cb7ab05 100644 --- a/package/system/procd/Makefile +++ b/package/system/procd/Makefile @@ -8,14 +8,14 @@ include $(TOPDIR)/rules.mk PKG_NAME:=procd -PKG_VERSION:=2016-05-19 +PKG_VERSION:=2016-05-24 PKG_RELEASE=$(PKG_SOURCE_VERSION) PKG_SOURCE_PROTO:=git PKG_SOURCE_URL=$(OPENWRT_GIT)/project/procd.git PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) -PKG_SOURCE_VERSION:=1418c6ce8559ea125c525c2663105fa5ff14905e +PKG_SOURCE_VERSION:=9a6f83d3c168523ac7b898ae481c2fd8c501d6a6 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz CMAKE_INSTALL:=1 -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub
Dear OpenWrt mailing list readers, as the subject says I'd like to make proposal to move the OpenWrt codebase to Git. This was already discussed before [1] and now when there are no blockers [2] for this change I'd like that we as a community move forward with this switch. Also, I'd like to propose that we move the project to GitHub and here are the reasons why I see this as a good decision: * GitHub will allow people to contribute more easily The bigger amount of contributions has already happened and can be seen on the packages feed which is already hosted on GitHub. With this I'm also hoping to avoid comments regarding invalid patches on the mailing list. For now I am proposing that the current development workflow is also accepted - aka. patches that are sent to the mailing list are also accepted. * GitHub and similar services will allow us to integrate more easily with other projects Here specifically I mean integration with modern CI. Here is an example of integration with drone.io [3][4]. At the moment this is only in the POC stage but what I'd like to do down the line is to: - build OpenWrt images for all architectures for every pull request - build OpenWrt package binary for every package pull request for all architectures and make it available for download - build and host OpenWrt qemu and/or Docker image for every pull request This will allow easy review of the work since flags will be shown in the pull request if the build was sucessful or not. Also, this will allow people to test changes without building the image and thus lowering the time that needs to be spent on maintenance work. If this proposal gets accepted I'll be sending out an email to get access to more build servers so this new build infrastructure can properly support the project in a timely fashion. Please share your thoughts regarding this proposal. Regards, Luka [1] https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html [2] https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041329.html [3] https://github.com/makkrnic/openwrt-qemu-x86 [4] http://sartura-drone.makkrnic.com/makkrnic/openwrt-qemu-x86/5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub
Hi Luka, this is fantastic news! I'd be very interested in your future progress on the CI front. If drone.io is able to accommodate the resources required for building the entire OpenWrt then it sounds like a good solution for other projects too. Regards, Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] bcm53xx: Move SF mmap patch
The patch adding SPI flash mmap read capability does not compile due to missing
m25p80_rx_nbits() function. Move it to bcm53xx patch directory, where the patch
adding this m25p80_rx_nbits() function resides.
Signed-off-by: Marek Vasut
---
.../045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch| 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename target/linux/{generic =>
bcm53xx}/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch
(100%)
diff --git
a/target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch
b/target/linux/bcm53xx/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch
similarity index 100%
rename from
target/linux/generic/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch
rename to
target/linux/bcm53xx/patches-4.4/045-mtd-devices-m25p80-add-support-for-mmap-read-request.patch
--
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] u-boot-socfpga: Update to 2016.05
Update the U-Boot package to upstream 2016.05 version. This version
improves overall performance of the platform, since it fixes cache
problems that prevented the cache from operating fully in previous
releases.
Signed-off-by: Marek Vasut
---
package/boot/uboot-socfpga/Makefile| 4 +-
...ga-Drop-space-after-loadaddr-in-extra-env.patch | 101 -
...pga-Tweak-SoCkit-default-env-for-OpenWRT.patch} | 12 +--
3 files changed, 8 insertions(+), 109 deletions(-)
delete mode 100644
package/boot/uboot-socfpga/patches/0001-arm-socfpga-Drop-space-after-loadaddr-in-extra-env.patch
rename
package/boot/uboot-socfpga/patches/{0002-arm-socfpga-Tweak-SoCkit-default-env-for-OpenWRT.patch
=> 0001-arm-socfpga-Tweak-SoCkit-default-env-for-OpenWRT.patch} (91%)
diff --git a/package/boot/uboot-socfpga/Makefile
b/package/boot/uboot-socfpga/Makefile
index 42fcb43..3fb017f 100644
--- a/package/boot/uboot-socfpga/Makefile
+++ b/package/boot/uboot-socfpga/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=u-boot
-PKG_VERSION:=2016.03
+PKG_VERSION:=2016.05
PKG_RELEASE:=1
PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION)
@@ -16,7 +16,7 @@ PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
PKG_SOURCE_URL:= \
http://mirror2.openwrt.org/sources \
ftp://ftp.denx.de/pub/u-boot
-PKG_MD5SUM:=973c1d896be751321cc3aafa564f64b2
+PKG_MD5SUM:=3a8613d753dfa707c937991a35404510
PKG_LICENSE:=GPL-2.0 GPL-2.0+
PKG_LICENSE_FILES:=Licenses/README
diff --git
a/package/boot/uboot-socfpga/patches/0001-arm-socfpga-Drop-space-after-loadaddr-in-extra-env.patch
b/package/boot/uboot-socfpga/patches/0001-arm-socfpga-Drop-space-after-loadaddr-in-extra-env.patch
deleted file mode 100644
index 261afef..000
---
a/package/boot/uboot-socfpga/patches/0001-arm-socfpga-Drop-space-after-loadaddr-in-extra-env.patch
+++ /dev/null
@@ -1,101 +0,0 @@
-From 04a4c90fee75c95130af1e40880c0927d56b0b61 Mon Sep 17 00:00:00 2001
-From: Marek Vasut
-Date: Sun, 3 Apr 2016 19:11:12 +0200
-Subject: [PATCH 1/2] arm: socfpga: Drop space after 'loadaddr=' in extra env
-
-There is an incorrect space after loadaddr= in the extra environment,
-so drop it.
-
-Signed-off-by: Marek Vasut
-Cc: Dinh Nguyen
-Cc: Chin Liang See
- include/configs/socfpga_arria5_socdk.h | 2 +-
- include/configs/socfpga_cyclone5_socdk.h | 2 +-
- include/configs/socfpga_de0_nano_soc.h | 2 +-
- include/configs/socfpga_sockit.h | 2 +-
- include/configs/socfpga_socrates.h | 2 +-
- include/configs/socfpga_sr1500.h | 2 +-
- 6 files changed, 6 insertions(+), 6 deletions(-)
-
-diff --git a/include/configs/socfpga_arria5_socdk.h
b/include/configs/socfpga_arria5_socdk.h
-index a0161bc..153f9f8 100644
a/include/configs/socfpga_arria5_socdk.h
-+++ b/include/configs/socfpga_arria5_socdk.h
-@@ -56,7 +56,7 @@
- /* Extra Environment */
- #define CONFIG_EXTRA_ENV_SETTINGS \
- "verify=n\0" \
-- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
-+ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
- "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \
- "bootm ${loadaddr} - ${fdt_addr}\0" \
- "bootimage=zImage\0" \
-diff --git a/include/configs/socfpga_cyclone5_socdk.h
b/include/configs/socfpga_cyclone5_socdk.h
-index c4c4ecb..d7c339e 100644
a/include/configs/socfpga_cyclone5_socdk.h
-+++ b/include/configs/socfpga_cyclone5_socdk.h
-@@ -56,7 +56,7 @@
- /* Extra Environment */
- #define CONFIG_EXTRA_ENV_SETTINGS \
- "verify=n\0" \
-- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
-+ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
- "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \
- "bootm ${loadaddr} - ${fdt_addr}\0" \
- "bootimage=zImage\0" \
-diff --git a/include/configs/socfpga_de0_nano_soc.h
b/include/configs/socfpga_de0_nano_soc.h
-index cbc7396..314b9bf 100644
a/include/configs/socfpga_de0_nano_soc.h
-+++ b/include/configs/socfpga_de0_nano_soc.h
-@@ -51,7 +51,7 @@
-
- /* Extra Environment */
- #define CONFIG_EXTRA_ENV_SETTINGS \
-- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
-+ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
- "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \
- "bootm ${loadaddr} - ${fdt_addr}\0" \
- "bootimage=zImage\0" \
-diff --git a/include/configs/socfpga_sockit.h
b/include/configs/socfpga_sockit.h
-index 95e7ba6..07cfcbf 100644
a/include/configs/socfpga_sockit.h
-+++ b/include/configs/socfpga_sockit.h
-@@ -52,7 +52,7 @@
- /* Extra Environment */
- #define CONFIG_EXTRA_ENV_SETTINGS \
- "verify=n\0" \
-- "loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
-+ "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
- "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \
- "bootm ${loadaddr} - ${fdt_addr}\0" \
- "bootimage=zImage\0" \
-diff --git a/include/co
[OpenWrt-Devel] [PATCH] toolchain: Backport gcc6 fixes from mainline GCC
Backported from mainline
2016-02-19 Jakub Jelinek
Bernd Edlinger
* Make-lang.in: Invoke gperf with -L C++.
* cfns.gperf: Remove prototypes for hash and libc_name_p
inlines.
* cfns.h: Regenerated.
* except.c (nothrow_libfn_p): Adjust.
Signed-off-by: Marek Vasut
---
...-Bernd-Edlinger-bernd.edlinger-hotmail.de.patch | 152 +
1 file changed, 152 insertions(+)
create mode 100644
toolchain/gcc/patches/4.8-linaro/005-2016-02-25-Bernd-Edlinger-bernd.edlinger-hotmail.de.patch
diff --git
a/toolchain/gcc/patches/4.8-linaro/005-2016-02-25-Bernd-Edlinger-bernd.edlinger-hotmail.de.patch
b/toolchain/gcc/patches/4.8-linaro/005-2016-02-25-Bernd-Edlinger-bernd.edlinger-hotmail.de.patch
new file mode 100644
index 000..070991e
--- /dev/null
+++
b/toolchain/gcc/patches/4.8-linaro/005-2016-02-25-Bernd-Edlinger-bernd.edlinger-hotmail.de.patch
@@ -0,0 +1,152 @@
+From 8c3fa311caa86f61b4e28d1563d1110b44340fb2 Mon Sep 17 00:00:00 2001
+From: edlinger
+Date: Thu, 25 Feb 2016 15:36:41 +
+Subject: [PATCH] 2016-02-25 Bernd Edlinger
+
+Backported from mainline
+2016-02-19 Jakub Jelinek
+Bernd Edlinger
+
+* Make-lang.in: Invoke gperf with -L C++.
+* cfns.gperf: Remove prototypes for hash and libc_name_p
+inlines.
+* cfns.h: Regenerated.
+* except.c (nothrow_libfn_p): Adjust.
+
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch@233721
138bc75d-0d04-0410-961f-82ee72b054a4
+---
+ gcc/cp/Make-lang.in | 2 +-
+ gcc/cp/cfns.gperf | 10 ++
+ gcc/cp/cfns.h | 41 ++---
+ gcc/cp/except.c | 3 ++-
+ 4 files changed, 19 insertions(+), 37 deletions(-)
+
+diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
+index bd1c1d7..a0ea0d4 100644
+--- a/gcc/cp/Make-lang.in
b/gcc/cp/Make-lang.in
+@@ -111,7 +111,7 @@ else
+ # deleting the $(srcdir)/cp/cfns.h file.
+ $(srcdir)/cp/cfns.h:
+ endif
+- gperf -o -C -E -k '1-6,$$' -j1 -D -N 'libc_name_p' -L ANSI-C \
++ gperf -o -C -E -k '1-6,$$' -j1 -D -N 'libc_name_p' -L C++ \
+ $(srcdir)/cp/cfns.gperf --output-file $(srcdir)/cp/cfns.h
+
+ #
+diff --git a/gcc/cp/cfns.gperf b/gcc/cp/cfns.gperf
+index 05ca753..d9b16b8 100644
+--- a/gcc/cp/cfns.gperf
b/gcc/cp/cfns.gperf
+@@ -1,3 +1,5 @@
++%language=C++
++%define class-name libc_name
+ %{
+ /* Copyright (C) 2000-2014 Free Software Foundation, Inc.
+
+@@ -16,14 +18,6 @@ for more details.
+ You should have received a copy of the GNU General Public License
+ along with GCC; see the file COPYING3. If not see
+
[OpenWrt-Devel] [PATCH 1/2] package: kernel: dtc: Add device tree compiler package
Add package with the DT compiler v1.4.1 . Signed-off-by: Marek Vasut --- package/kernel/dtc/Makefile | 36 1 file changed, 36 insertions(+) create mode 100644 package/kernel/dtc/Makefile diff --git a/package/kernel/dtc/Makefile b/package/kernel/dtc/Makefile new file mode 100644 index 000..5155323 --- /dev/null +++ b/package/kernel/dtc/Makefile @@ -0,0 +1,36 @@ +# +# Copyright (C) 2016 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +include $(TOPDIR)/rules.mk + +PKG_NAME:=dtc +PKG_VERSION:=1.4.1 +PKG_RELEASE=$(PKG_SOURCE_VERSION) + +PKG_SOURCE_URL:=git://git.kernel.org/pub/scm/utils/dtc/dtc.git +PKG_SOURCE_PROTO:=git +PKG_SOURCE_VERSION:=302fca9f4c283e1994cf0a5a9ce1cf43ca15e6d2 +PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz + +PKG_MAINTAINER:=Marek Vasut +PKG_LICENSE:=GPL-2.0+ + +include $(INCLUDE_DIR)/package.mk + +define Package/dtc + SECTION:=utils + CATEGORY:=Utilities + TITLE:=Device Tree Compiler +endef + +define Package/dtc/install + $(INSTALL_DIR) $(1)/usr/bin + $(INSTALL_BIN) $(PKG_BUILD_DIR)/dtc $(1)/usr/bin/ +endef + +$(eval $(call BuildPackage,dtc)) -- 2.7.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] package: kernel: dtc: Add DTO support
Add patch with the DT overlay support into the DTC package.
Signed-off-by: Marek Vasut
---
...ripts-dtc-Update-to-version-with-overlays.patch | 642 +
1 file changed, 642 insertions(+)
create mode 100644
package/kernel/dtc/patches/0001-scripts-dtc-Update-to-version-with-overlays.patch
diff --git
a/package/kernel/dtc/patches/0001-scripts-dtc-Update-to-version-with-overlays.patch
b/package/kernel/dtc/patches/0001-scripts-dtc-Update-to-version-with-overlays.patch
new file mode 100644
index 000..605d303
--- /dev/null
+++
b/package/kernel/dtc/patches/0001-scripts-dtc-Update-to-version-with-overlays.patch
@@ -0,0 +1,642 @@
+From 5f84cb93eef9f8a8ff7f49d593893f252744d0fe Mon Sep 17 00:00:00 2001
+From: Pantelis Antoniou
+Date: Wed, 26 Aug 2015 18:28:08 +0300
+Subject: [PATCH] scripts/dtc: Update to version with overlays
+
+Update to mainline dtc with overlay support
+
+Signed-off-by: Pantelis Antoniou
+---
+ checks.c | 20 +-
+ dtc-lexer.l | 5 ++
+ dtc-parser.y | 54 ++--
+ dtc.c| 83 ++--
+ dtc.h| 13 +++-
+ livetree.c | 202 +++
+ treesource.c | 3 +
+ util.c | 2 +-
+ 8 files changed, 367 insertions(+), 15 deletions(-)
+
+diff --git a/checks.c b/checks.c
+index 3bf0fa4..af25c2b 100644
+--- a/checks.c
b/checks.c
+@@ -465,8 +465,12 @@ static void fixup_phandle_references(struct check *c,
struct node *dt,
+
+ refnode = get_node_by_ref(dt, m->ref);
+ if (! refnode) {
+- FAIL(c, "Reference to non-existent node or label
\"%s\"\n",
+- m->ref);
++ if (!source_is_plugin)
++ FAIL(c, "Reference to non-existent node or "
++ "label \"%s\"\n", m->ref);
++ else /* mark the entry as unresolved */
++ *((cell_t *)(prop->val.val + m->offset)) =
++ cpu_to_fdt32(0x);
+ continue;
+ }
+
+@@ -559,7 +563,7 @@ static void check_reg_format(struct check *c, struct node
*dt,
+ size_cells = node_size_cells(node->parent);
+ entrylen = (addr_cells + size_cells) * sizeof(cell_t);
+
+- if ((prop->val.len % entrylen) != 0)
++ if (!entrylen || (prop->val.len % entrylen) != 0)
+ FAIL(c, "\"reg\" property in %s has invalid length (%d bytes) "
+"(#address-cells == %d, #size-cells == %d)",
+node->fullpath, prop->val.len, addr_cells, size_cells);
+@@ -651,6 +655,15 @@ static void
check_obsolete_chosen_interrupt_controller(struct check *c,
+ }
+ TREE_WARNING(obsolete_chosen_interrupt_controller, NULL);
+
++static void check_deprecated_plugin_syntax(struct check *c,
++ struct node *dt)
++{
++ if (deprecated_plugin_syntax_warning)
++ FAIL(c, "Use '/dts-v1/ /plugin/'; syntax. /dts-v1/; /plugin/; "
++ "is going to be removed in next versions");
++}
++TREE_WARNING(deprecated_plugin_syntax, NULL);
++
+ static struct check *check_table[] = {
+ &duplicate_node_names, &duplicate_property_names,
+ &node_name_chars, &node_name_format, &property_name_chars,
+@@ -668,6 +681,7 @@ static struct check *check_table[] = {
+
+ &avoid_default_addr_size,
+ &obsolete_chosen_interrupt_controller,
++ &deprecated_plugin_syntax,
+
+ &always_fail,
+ };
+diff --git a/dtc-lexer.l b/dtc-lexer.l
+index 0ee1caf..dd44ba2 100644
+--- a/dtc-lexer.l
b/dtc-lexer.l
+@@ -113,6 +113,11 @@ static void lexical_error(const char *fmt, ...);
+ return DT_V1;
+ }
+
++<*>"/plugin/" {
++ DPRINT("Keyword: /plugin/\n");
++ return DT_PLUGIN;
++ }
++
+ <*>"/memreserve/" {
+ DPRINT("Keyword: /memreserve/\n");
+ BEGIN_DEFAULT();
+diff --git a/dtc-parser.y b/dtc-parser.y
+index ea57e0a..7d9652d 100644
+--- a/dtc-parser.y
b/dtc-parser.y
+@@ -19,6 +19,7 @@
+ */
+ %{
+ #include
++#include
+
+ #include "dtc.h"
+ #include "srcpos.h"
+@@ -52,9 +53,11 @@ extern bool treesource_error;
+ struct node *nodelist;
+ struct reserve_info *re;
+ uint64_t integer;
++ bool is_plugin;
+ }
+
+ %token DT_V1
++%token DT_PLUGIN
+ %token DT_MEMRESERVE
+ %token DT_LSHIFT DT_RSHIFT DT_LE DT_GE DT_EQ DT_NE DT_AND DT_OR
+ %token DT_BITS
+@@ -71,6 +74,7 @@ extern bool treesource_error;
+
+ %type propdata
+ %type propdataprefix
++%type plugindecl
+ %type memreserve
+ %type memreserves
+ %type arrayprefix
+@@ -101,10 +105,39 @@ extern bool treesource_error;
+ %%
+
+ sourcefile:
+-DT_V1 ';' memreserves devicetree
++ basesource
++| pluginsource
++;
++
++basesource
Re: [OpenWrt-Devel] [PATCH] bcm53xx: Move SF mmap patch
On 2016-05-24 16:48, Marek Vasut wrote: > The patch adding SPI flash mmap read capability does not compile due to > missing > m25p80_rx_nbits() function. Move it to bcm53xx patch directory, where the > patch > adding this m25p80_rx_nbits() function resides. This doesn't make any sense to me. The function is already in the driver in 4.4, it is not added by any patch... - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] netifd: Add option to configure gc_stale_time for each device
The UCI parameter neighgcstaletime allows to control how much time will
STALE entries be kept in the neighbour table for both IPv4 and IPv6.
Signed-off-by: Alin Nastac
---
device.c | 14 ++
device.h | 4
system-linux.c | 38 ++
3 files changed, 56 insertions(+)
diff --git a/device.c b/device.c
index 7004bfd..3e182f3 100644
--- a/device.c
+++ b/device.c
@@ -45,6 +45,7 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX]
= {
[DEV_ATTR_IGMPVERSION] = { .name = "igmpversion", .type =
BLOBMSG_TYPE_INT32 },
[DEV_ATTR_MLDVERSION] = { .name = "mldversion", .type =
BLOBMSG_TYPE_INT32 },
[DEV_ATTR_NEIGHREACHABLETIME] = { .name = "neighreachabletime", .type =
BLOBMSG_TYPE_INT32 },
+ [DEV_ATTR_NEIGHGCSTALETIME] = { .name = "neighgcstaletime", .type =
BLOBMSG_TYPE_INT32 },
[DEV_ATTR_RPS] = { .name = "rps", .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_XPS] = { .name = "xps", .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_DADTRANSMITS] = { .name = "dadtransmits", .type =
BLOBMSG_TYPE_INT32 },
@@ -171,6 +172,10 @@ device_merge_settings(struct device *dev, struct
device_settings *n)
s->neigh4reachabletime : os->neigh4reachabletime;
n->neigh6reachabletime = s->flags & DEV_OPT_NEIGHREACHABLETIME ?
s->neigh6reachabletime : os->neigh6reachabletime;
+ n->neigh4gcstaletime = s->flags & DEV_OPT_NEIGHGCSTALETIME ?
+ s->neigh4gcstaletime : os->neigh4gcstaletime;
+ n->neigh6gcstaletime = s->flags & DEV_OPT_NEIGHGCSTALETIME ?
+ s->neigh6gcstaletime : os->neigh6gcstaletime;
n->dadtransmits = s->flags & DEV_OPT_DADTRANSMITS ?
s->dadtransmits : os->dadtransmits;
n->multicast = s->flags & DEV_OPT_MULTICAST ?
@@ -258,6 +263,11 @@ device_init_settings(struct device *dev, struct blob_attr
**tb)
s->flags |= DEV_OPT_NEIGHREACHABLETIME;
}
+ if ((cur = tb[DEV_ATTR_NEIGHGCSTALETIME])) {
+ s->neigh6gcstaletime = s->neigh4gcstaletime =
blobmsg_get_u32(cur);
+ s->flags |= DEV_OPT_NEIGHGCSTALETIME;
+ }
+
if ((cur = tb[DEV_ATTR_RPS])) {
s->rps = blobmsg_get_bool(cur);
s->flags |= DEV_OPT_RPS;
@@ -960,6 +970,10 @@ device_dump_status(struct blob_buf *b, struct device *dev)
blobmsg_add_u32(b, "neigh4reachabletime",
st.neigh4reachabletime);
blobmsg_add_u32(b, "neigh6reachabletime",
st.neigh6reachabletime);
}
+ if (st.flags & DEV_OPT_NEIGHGCSTALETIME) {
+ blobmsg_add_u32(b, "neigh4gcstaletime",
st.neigh4gcstaletime);
+ blobmsg_add_u32(b, "neigh6gcstaletime",
st.neigh6gcstaletime);
+ }
if (st.flags & DEV_OPT_DADTRANSMITS)
blobmsg_add_u32(b, "dadtransmits", st.dadtransmits);
if (st.flags & DEV_OPT_MULTICAST_TO_UNICAST)
diff --git a/device.h b/device.h
index 9c4b822..0b8cd6a 100644
--- a/device.h
+++ b/device.h
@@ -45,6 +45,7 @@ enum {
DEV_ATTR_MULTICAST_TO_UNICAST,
DEV_ATTR_MULTICAST_ROUTER,
DEV_ATTR_MULTICAST,
+ DEV_ATTR_NEIGHGCSTALETIME,
__DEV_ATTR_MAX,
};
@@ -88,6 +89,7 @@ enum {
DEV_OPT_MULTICAST_TO_UNICAST= (1 << 14),
DEV_OPT_MULTICAST_ROUTER= (1 << 15),
DEV_OPT_MULTICAST = (1 << 16),
+ DEV_OPT_NEIGHGCSTALETIME= (1 << 17),
};
/* events broadcasted to all users of a device */
@@ -143,6 +145,8 @@ struct device_settings {
unsigned int mldversion;
unsigned int neigh4reachabletime;
unsigned int neigh6reachabletime;
+ unsigned int neigh4gcstaletime;
+ unsigned int neigh6gcstaletime;
bool rps;
bool xps;
unsigned int dadtransmits;
diff --git a/system-linux.c b/system-linux.c
index f79625a..62c51b5 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -310,6 +310,16 @@ static void system_set_neigh6reachabletime(struct device
*dev, const char *val)
system_set_dev_sysctl("/proc/sys/net/ipv6/neigh/%s/base_reachable_time_ms",
dev->ifname, val);
}
+static void system_set_neigh4gcstaletime(struct device *dev, const char *val)
+{
+ system_set_dev_sysctl("/proc/sys/net/ipv4/neigh/%s/gc_stale_time",
dev->ifname, val);
+}
+
+static void system_set_neigh6gcstaletime(struct device *dev, const char *val)
+{
+ system_set_dev_sysctl("/proc/sys/net/ipv6/neigh/%s/gc_stale_time",
dev->ifname, val);
+}
+
static void system_set_dadtransmits(struct device *dev, const char *val)
{
system_set_dev_sysctl("/proc/sys/net/ipv6/conf/%s/dad_transmits",
dev->ifname, val);
@@ -446,6 +456,18 @@ static int system_get_neigh6reachabletime(struct device
*dev, char *buf, const s
dev->ifname, buf, buf_sz);
}
+static int system_get_neig
Re: [OpenWrt-Devel] [PATCH] bcm53xx: Move SF mmap patch
On 05/24/2016 04:57 PM, Felix Fietkau wrote: > On 2016-05-24 16:48, Marek Vasut wrote: >> The patch adding SPI flash mmap read capability does not compile due to >> missing >> m25p80_rx_nbits() function. Move it to bcm53xx patch directory, where the >> patch >> adding this m25p80_rx_nbits() function resides. > This doesn't make any sense to me. The function is already in the driver > in 4.4, it is not added by any patch... > > - Felix > Well is there any way to obtain kernel tree with the target/linux/generic/patches-4.4 applied, so I can base socfpga patches on top of it ? I tried git am on those patches, but that's obviously not possible, since a lot of these patches were not generated with git-format-patch or the relevant header was removed. Thanks -- Best regards, Marek Vasut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub
I think this is a great idea! I very much support a move to Github; despite it's issues, it's just where development is happening today. Keeping a non-Github channel for submitting patches is also a great idea I think. My free-software side worries about using something non-free like drone.io for CI but this is a huge task certainly and I'm not sure a free tool would meet everyone's needs (plus there's the huge added burden of maintenance). Eric On Tue, May 24, 2016 at 9:06 AM, Luka Perkov wrote: > Dear OpenWrt mailing list readers, > > as the subject says I'd like to make proposal to move the OpenWrt > codebase to Git. This was already discussed before [1] and now when > there are no blockers [2] for this change I'd like that we as a > community move forward with this switch. > > Also, I'd like to propose that we move the project to GitHub and here > are the reasons why I see this as a good decision: > > * GitHub will allow people to contribute more easily > > The bigger amount of contributions has already happened and can be seen > on the packages feed which is already hosted on GitHub. With this I'm > also hoping to avoid comments regarding invalid patches on the mailing > list. > > For now I am proposing that the current development workflow is also > accepted - aka. patches that are sent to the mailing list are also > accepted. > > * GitHub and similar services will allow us to integrate more easily > with other projects > > Here specifically I mean integration with modern CI. Here is an example > of integration with drone.io [3][4]. At the moment this is only in the > POC stage but what I'd like to do down the line is to: > > - build OpenWrt images for all architectures for every pull request > > - build OpenWrt package binary for every package pull request for all > architectures and make it available for download > > - build and host OpenWrt qemu and/or Docker image for every pull request > > This will allow easy review of the work since flags will be shown in the > pull request if the build was sucessful or not. Also, this will allow > people to test changes without building the image and thus lowering the > time that needs to be spent on maintenance work. > > If this proposal gets accepted I'll be sending out an email to get > access to more build servers so this new build infrastructure can > properly support the project in a timely fashion. > > Please share your thoughts regarding this proposal. > > Regards, > Luka > > [1] > https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html > [2] https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041329.html > [3] https://github.com/makkrnic/openwrt-qemu-x86 > [4] http://sartura-drone.makkrnic.com/makkrnic/openwrt-qemu-x86/5 > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -- Eric Schultz, Community Manager, prpl Foundation http://www.prplfoundation.org eschu...@prplfoundation.org cell: 920-539-0404 skype: ericschultzwi @EricPrpl ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub
On Tue, 24 May 2016, Luka Perkov wrote: Date: Tue, 24 May 2016 16:06:13 +0200 From: Luka Perkov To: openwrt-devel@lists.openwrt.org, openwrt-us...@lists.openwrt.org Subject: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub Dear OpenWrt mailing list readers, as the subject says I'd like to make proposal to move the OpenWrt codebase to Git. This was already discussed before [1] and now when there are no blockers [2] for this change I'd like that we as a community move forward with this switch. Also, I'd like to propose that we move the project to GitHub and here are the reasons why I see this as a good decision: * GitHub will allow people to contribute more easily The bigger amount of contributions has already happened and can be seen on the packages feed which is already hosted on GitHub. With this I'm also hoping to avoid comments regarding invalid patches on the mailing list. For now I am proposing that the current development workflow is also accepted - aka. patches that are sent to the mailing list are also accepted. OpenWRT has already moved to using Git instead of SVN, so why do they need to move from hosting the git repository themselves to having it hosted on github? There can be a mirror of the repo on github (remember that git is a Decentralized VCS) * GitHub and similar services will allow us to integrate more easily with other projects Here specifically I mean integration with modern CI. Here is an example of integration with drone.io [3][4]. At the moment this is only in the POC stage but what I'd like to do down the line is to: - build OpenWrt images for all architectures for every pull request - build OpenWrt package binary for every package pull request for all architectures and make it available for download - build and host OpenWrt qemu and/or Docker image for every pull request the build farm isn't large enough to do this It's also not neccessary to move to github to be able to do this, it just needs more systems in the build farm to be able to build things fast enough. This will allow easy review of the work since flags will be shown in the pull request if the build was sucessful or not. Also, this will allow people to test changes without building the image and thus lowering the time that needs to be spent on maintenance work. If this proposal gets accepted I'll be sending out an email to get access to more build servers so this new build infrastructure can properly support the project in a timely fashion. why should providing more build servers be contingent on moving to a commercial hosting provider vs running things themselves? David Lang Please share your thoughts regarding this proposal. Regards, Luka [1] https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html [2] https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041329.html [3] https://github.com/makkrnic/openwrt-qemu-x86 [4] http://sartura-drone.makkrnic.com/makkrnic/openwrt-qemu-x86/5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] bcm53xx: Move SF mmap patch
On 05/24/2016 04:57 PM, Felix Fietkau wrote: > On 2016-05-24 16:48, Marek Vasut wrote: >> The patch adding SPI flash mmap read capability does not compile due to >> missing >> m25p80_rx_nbits() function. Move it to bcm53xx patch directory, where the >> patch >> adding this m25p80_rx_nbits() function resides. > This doesn't make any sense to me. The function is already in the driver > in 4.4, it is not added by any patch... OK, please drop this one and I will send a V2 of this too: [PATCH] target: socfpga: Add support for QSPI NOR boot -- Best regards, Marek Vasut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub
On Tue, 2016-05-24 at 16:46 +0200, Jo-Philipp Wich wrote: > Hi Luka, > > this is fantastic news! > > I'd be very interested in your future progress on the CI front. > Let's just not make the mistake other projects make and turn CI into a an excuse to not have proper releases and a stablisation period before a stable release that only gets bug fixes afterwards. I've seen too many times CI/CD meant to use 'we won't bother with a release we'll just fix thing on the fly' that ends up really meaning CB (Continuous Brokeness). (I'd love to see people call CI/CD CI/CD/CB or just CI/CB so that deluded folks might get a clue). Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWrt / LEDE
Hi, As it looks like the IRC meeting will not happen, because not so big interest by the people not already involved in LEDE and problems finding a time, lets discuss on the mailing list like suggested by Jow. Currently it looks like only Luka is working on OpenWrt as he committed many patches from LEDE to OpenWrt, which is fine. What will happen to the OpenWrt project? To me it looks like nobody except Luka is interested in working on OpenWrt. Are there any plans to continue the OpenWrt project or will it just die, only nobody wants to say it? Currently this is a bad situation for people that want to contribute patches because they do not exactly know were to contribute, some post them just to both list which is probably the best solution for the time we do not have a real solution. I do not plan to contribute much to OpenWrt any more and I do not know if I can commit anything any more, at least it looks like I was kicked from the openwrt-hackers mailing list without informing me. I would like to see a reunion of LEDE and OpenWrt, so do any of the non LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] [PROPOSAL] move OpenWrt codebase to Git and GitHub
Hi, here's a few numbers we gathered with our buildbot setup: We currently need roughly 35GB per target when building OpenWrt plus the entire package world and currently there are roughly ~70 target/subtarget combinations in the OpenWrt tree. If fast build tests are desired then the only way to do so is by implementing incremental building which only works if there's enough space to retain all build trees at once which means there need to be about 2.5TB of storage available. For only building all base systems without package feeds the entire required space is around 800GB. A base system build currently requires 1 hour and 15 minutes on a machine having a Xeon E3-1246 v3 4 core / 8 thread CPU with prepopulated dl/, ccache and make -j8. A build of all packages from all feeds takes around 70 minutes on a Xeon E5-2630 v3 8 core / 16 thread machine with 12GB ram and make -j16. HTH, Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt / LEDE
add lede-dev On 05/24/2016 10:31 PM, Hauke Mehrtens wrote: > Hi, > > As it looks like the IRC meeting will not happen, because not so big > interest by the people not already involved in LEDE and problems finding > a time, lets discuss on the mailing list like suggested by Jow. > > Currently it looks like only Luka is working on OpenWrt as he committed > many patches from LEDE to OpenWrt, which is fine. > > What will happen to the OpenWrt project? To me it looks like nobody > except Luka is interested in working on OpenWrt. Are there any plans to > continue the OpenWrt project or will it just die, only nobody wants to > say it? > Currently this is a bad situation for people that want to contribute > patches because they do not exactly know were to contribute, some post > them just to both list which is probably the best solution for the time > we do not have a real solution. > > I do not plan to contribute much to OpenWrt any more and I do not know > if I can commit anything any more, at least it looks like I was kicked > from the openwrt-hackers mailing list without informing me. > > > I would like to see a reunion of LEDE and OpenWrt, so do any of the non > LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? > > Hauke This is my personal opinion and this was not somehow internally planned with other LEDE people. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub
On Tue, 2016-05-24 at 16:20 -0400, Daniel Dickinson wrote: > On Tue, 2016-05-24 at 16:46 +0200, Jo-Philipp Wich wrote: > > Hi Luka, > > > > this is fantastic news! > > > > I'd be very interested in your future progress on the CI front. > > > Let's just not make the mistake other projects make and turn CI into a > an excuse to not have proper releases and a stablisation period before a > stable release that only gets bug fixes afterwards. > > I've seen too many times CI/CD meant to use 'we won't bother with a > release we'll just fix thing on the fly' that ends up really meaning CB > (Continuous Brokeness). (I'd love to see people call CI/CD CI/CD/CB or just > CI/CB so that deluded folks might get a clue). That's not to say that stable release are perfect or even necessary better than a CD release *but* because it doesn't change much, people who depend on you can be aware of and work around issues you have, rater than dealing with a constantly changing set of problems. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt / LEDE
On 24 May 2016 at 23:31, Hauke Mehrtens wrote: > Hi, > > As it looks like the IRC meeting will not happen, because not so big > interest by the people not already involved in LEDE and problems finding > a time, lets discuss on the mailing list like suggested by Jow. > > Currently it looks like only Luka is working on OpenWrt as he committed > many patches from LEDE to OpenWrt, which is fine. > > What will happen to the OpenWrt project? To me it looks like nobody > except Luka is interested in working on OpenWrt. Are there any plans to > continue the OpenWrt project or will it just die, only nobody wants to > say it? > Currently this is a bad situation for people that want to contribute > patches because they do not exactly know were to contribute, some post > them just to both list which is probably the best solution for the time > we do not have a real solution. > > I do not plan to contribute much to OpenWrt any more and I do not know > if I can commit anything any more, at least it looks like I was kicked > from the openwrt-hackers mailing list without informing me. I believe LEDE didn't plan to contribute to OpenWrt from the very beginning. LEDE words are pretty contrary to the works. > I would like to see a reunion of LEDE and OpenWrt, so do any of the non > LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? How many devs do you think it's possible to attract to OpenWrt having the promotion LEDE does and remembering the fact that most active devs went to LEDE? Same rules could be applied inside OpenWrt as I see it. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt / LEDE
On 24 May 2016 at 22:31, Hauke Mehrtens wrote: > As it looks like the IRC meeting will not happen, because not so big > interest by the people not already involved in LEDE and problems finding > a time, lets discuss on the mailing list like suggested by Jow. > > Currently it looks like only Luka is working on OpenWrt as he committed > many patches from LEDE to OpenWrt, which is fine. > > What will happen to the OpenWrt project? To me it looks like nobody > except Luka is interested in working on OpenWrt. Are there any plans to > continue the OpenWrt project or will it just die, only nobody wants to > say it? > Currently this is a bad situation for people that want to contribute > patches because they do not exactly know were to contribute, some post > them just to both list which is probably the best solution for the time > we do not have a real solution. > > I do not plan to contribute much to OpenWrt any more and I do not know > if I can commit anything any more, at least it looks like I was kicked > from the openwrt-hackers mailing list without informing me. > > > I would like to see a reunion of LEDE and OpenWrt, so do any of the non > LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? I'll speak for myself. I feel more comfortable with LEDE: 1) Rules are straight there 2) No single people controlling infrastructure and refusing to help 3) No decisions made behind the doors That will make me focus on LEDE. Of course this is open source world, OpenWrt can pick my changes. *However* I'd like to maintain 15.05 OpenWrt branch for some time (few months?). Unfortunately I feel unsure about my access to OpenWrt repo in the future. First some @openwrt.org e-mails were deleted/disabled. That made me ask about my commiting permissions: [2016-05-05] [14:41:32] [mbm]: Kaloz: can we still commit to OpenWrt? [2016-05-05] [14:45:28] as far as I know you can [2016-05-05] [16:21:09] rmilecki: yes it looked fine, but few days later I was kicked out of openwrt-hackers@ mailing list silently. I really would like to have a straight message from whoever takes these decisions at OpenWrt. What are your plans? Do you want me/us to stop contributing to OpenWrt? -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub
On 24 May 2016 at 18:51, Eric Schultz wrote: > I think this is a great idea! I very much support a move to Github; despite > it's issues, it's just where development is happening today. Keeping a > non-Github channel for submitting patches is also a great idea I think. > > My free-software side worries about using something non-free like drone.io > for CI but this is a huge task certainly and I'm not sure a free tool would > meet everyone's needs (plus there's the huge added burden of maintenance). How about something like kernelci.org? I'm not sure how to run all this https://github.com/kernelci but the result looks very interesting. > Eric > > On Tue, May 24, 2016 at 9:06 AM, Luka Perkov wrote: >> >> Dear OpenWrt mailing list readers, >> >> as the subject says I'd like to make proposal to move the OpenWrt >> codebase to Git. This was already discussed before [1] and now when >> there are no blockers [2] for this change I'd like that we as a >> community move forward with this switch. >> >> Also, I'd like to propose that we move the project to GitHub and here >> are the reasons why I see this as a good decision: >> >> * GitHub will allow people to contribute more easily >> >> The bigger amount of contributions has already happened and can be seen >> on the packages feed which is already hosted on GitHub. With this I'm >> also hoping to avoid comments regarding invalid patches on the mailing >> list. >> >> For now I am proposing that the current development workflow is also >> accepted - aka. patches that are sent to the mailing list are also >> accepted. >> >> * GitHub and similar services will allow us to integrate more easily >> with other projects >> >> Here specifically I mean integration with modern CI. Here is an example >> of integration with drone.io [3][4]. At the moment this is only in the >> POC stage but what I'd like to do down the line is to: >> >> - build OpenWrt images for all architectures for every pull request >> >> - build OpenWrt package binary for every package pull request for all >> architectures and make it available for download >> >> - build and host OpenWrt qemu and/or Docker image for every pull request >> >> This will allow easy review of the work since flags will be shown in the >> pull request if the build was sucessful or not. Also, this will allow >> people to test changes without building the image and thus lowering the >> time that needs to be spent on maintenance work. >> >> If this proposal gets accepted I'll be sending out an email to get >> access to more build servers so this new build infrastructure can >> properly support the project in a timely fashion. >> >> Please share your thoughts regarding this proposal. >> >> Regards, >> Luka >> >> [1] >> https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html >> [2] https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041329.html >> [3] https://github.com/makkrnic/openwrt-qemu-x86 >> [4] http://sartura-drone.makkrnic.com/makkrnic/openwrt-qemu-x86/5 >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > > > -- > Eric Schultz, Community Manager, prpl Foundation > http://www.prplfoundation.org > eschu...@prplfoundation.org > cell: 920-539-0404 > skype: ericschultzwi > @EricPrpl > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt / LEDE
Hi, On 05/24/2016 10:31 PM, Hauke Mehrtens wrote: As it looks like the IRC meeting will not happen, because not so big interest by the people not already involved in LEDE and problems finding a time, lets discuss on the mailing list like suggested by Jow. The point you are missing is that some of the OpenWrt core team is living in a non-EU timezone. We can pick a PDT timeslot that won't work for anyone living in EU, and say that LEDE is not interested in the discussion, but that's just not the proper way. Currently it looks like only Luka is working on OpenWrt as he committed many patches from LEDE to OpenWrt, which is fine. It is one thing that there are no commits currently from anyone, until the OpenWrt/LEDE discussions are made. What will happen to the OpenWrt project? To me it looks like nobody except Luka is interested in working on OpenWrt. Are there any plans to continue the OpenWrt project or will it just die, only nobody wants to say it? See above. We don't plan to play dead. Also, IIRC there are patches for targets which are/were maintained by LEDE members. As far as I know, commit rights have not been revoked (somebody correct me if I'm wrong). Currently this is a bad situation for people that want to contribute patches because they do not exactly know were to contribute, some post them just to both list which is probably the best solution for the time we do not have a real solution. Yes, there might be some confusion about this, we are still lagging a bit behind due to the surprise fork. Luka sent a mail on some of the planned moves, please refer to that thread. (Jow, thanks for the buildbot-related number crunching.) I do not plan to contribute much to OpenWrt any more and I do not know if I can commit anything any more, at least it looks like I was kicked from the openwrt-hackers mailing list without informing me. I would like to see a reunion of LEDE and OpenWrt, so do any of the non LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? This is my personal opinion and this was not somehow internally planned with other LEDE people. If I start a discussion about my employer-related topics along a beer with a couple friends, that's a private discussion with personal opinions. If I do it on any public channel, I can be felt to represent my employer on that topic. You seem to be representing LEDE. Regards, -w- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt / LEDE
On Wed, 2016-05-25 at 00:23 +0300, Roman Yeryomin wrote: [snip] > > I do not plan to contribute much to OpenWrt any more and I do not know > > if I can commit anything any more, at least it looks like I was kicked > > from the openwrt-hackers mailing list without informing me. > > I believe LEDE didn't plan to contribute to OpenWrt from the very beginning. > LEDE words are pretty contrary to the works. I disagree. I think LEDE's biggest problem is that are not vocal like me, but would rather just work on code and not talk and hence are particularly *bad* at communicating and publicizing what they're thinking and doing. They're also incredibly busy people with work that doesn't involve community openwrt/lede, which limits exactly what they can do. One could instance of this is the patches I thought were being ignored and just disappearing were in fact being considered and where needed better made to fit the project's needs - the issue was that I didn't *know* this because Felix and John, especially, tend to 'don't talk, just do' and so I didn't realize what was actually the case. This is something it appears Felix and Jo, at least, are making efforts to improve in LEDE. > > > I would like to see a reunion of LEDE and OpenWrt, so do any of the non > > LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? > > How many devs do you think it's possible to attract to OpenWrt having > the promotion LEDE does and remembering the fact that most active devs > went to LEDE? > Same rules could be applied inside OpenWrt as I see it. Let's see if any of the remaining OpenWrt devs at least publicly support adopting them or some variation of them. As I've said before my impression is that LEDE-style rules are not all that welcomed (and that's based on the interactions I saw on the private openwrt channels when I was a developer, not just a pure outsider view; it's possible my impression is wrong, but the toxicity described previously was in large part negative reaction by folkds in the LEDE team to toxic comments from at least one of the remaining OpenWrt devs; certainly it damaged my opinion of him (although the toxicity also damaged my opinion of a couple of LEDE folks too)). Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt / LEDE
On Tue, 2016-05-24 at 18:18 -0400, Daniel Dickinson wrote: > On Tue, 2016-05-24 at 23:57 +0200, Zoltan HERPAI wrote: > [snip] > > Hi, > > >> I would like to see a reunion of LEDE and OpenWrt, so do any of the non > > >> LEDE but OpenWrt core devs have any problems with the LEDE rules and so > > >> on? > > >> > > > This is my personal opinion and this was not somehow internally planned > > > with other LEDE people. > > > > If I start a discussion about my employer-related topics along a beer with > > a couple friends, that's a private discussion with personal opinions. If I > > do it on any public channel, I can be felt to represent my employer on > > that topic. You seem to be representing LEDE. > > > > That's the kind of bollock that damages the ability of employees to have > a right to free speech which disagrees with (or is at least > independently developed of) their employers views. > > As long it as someone makes it clear when they are speaking for > themselves and not as a representative of the group, it should be > accepted on that basis, unless if there is a reason to believe otherwise > *other than* just that the person happens to be a member of some group. > > It's kind of like saying a black who says he or she speaking for himself > speaks for all blacks, just because it's known he or she is black and he > speaks on a public channel. > > It's bollocks. People are indivduals and have a right be such, and to > have, and be seen to have, views independent of the various groups the > are members of. > > I certainly don't speak for all white male IT professionals from North > America. > On that note, after the fact I noticed your .hu and am wondering if that this kind of thinking is a difference in the culture you're part of vs. the western cultures Hauke and I are part of? In much of 'the west' there is an expectation that individuals are free to speak for themselves (and be seen to be doing such) regardless of what group (although various corporations and governments sometimes try and quash such things, which most here consider a harm not a good) they belong to. Certainly Hauke believes he is free to speak for himself and has a reasonable expectation that people will accept that his opinion is his alone, unless he explicitly is speaking on behalf of some organization, like LEDE. To a certain extent you yourself acknowledge individual opinion (with you over a beer comment), but you seem to think that such a view of individual opinions are not as valid in the public domain, whereas our expectation is that it is just as valid in the public domain as in the private. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt / LEDE
On Tue, 2016-05-24 at 23:57 +0200, Zoltan HERPAI wrote: [snip] > Hi, > >> I would like to see a reunion of LEDE and OpenWrt, so do any of the non > >> LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? > >> > > This is my personal opinion and this was not somehow internally planned > > with other LEDE people. > > If I start a discussion about my employer-related topics along a beer with > a couple friends, that's a private discussion with personal opinions. If I > do it on any public channel, I can be felt to represent my employer on > that topic. You seem to be representing LEDE. > That's the kind of bollock that damages the ability of employees to have a right to free speech which disagrees with (or is at least independently developed of) their employers views. As long it as someone makes it clear when they are speaking for themselves and not as a representative of the group, it should be accepted on that basis, unless if there is a reason to believe otherwise *other than* just that the person happens to be a member of some group. It's kind of like saying a black who says he or she speaking for himself speaks for all blacks, just because it's known he or she is black and he speaks on a public channel. It's bollocks. People are indivduals and have a right be such, and to have, and be seen to have, views independent of the various groups the are members of. I certainly don't speak for all white male IT professionals from North America. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt / LEDE
On 25 May 2016 at 07:56, Daniel Dickinson wrote: > On Tue, 2016-05-24 at 18:18 -0400, Daniel Dickinson wrote: >> On Tue, 2016-05-24 at 23:57 +0200, Zoltan HERPAI wrote: >> [snip] >> > Hi, >> > >> I would like to see a reunion of LEDE and OpenWrt, so do any of the non >> > >> LEDE but OpenWrt core devs have any problems with the LEDE rules and so >> > >> on? >> > >> >> > > This is my personal opinion and this was not somehow internally planned >> > > with other LEDE people. >> > >> > If I start a discussion about my employer-related topics along a beer with >> > a couple friends, that's a private discussion with personal opinions. If I >> > do it on any public channel, I can be felt to represent my employer on >> > that topic. You seem to be representing LEDE. >> > >> >> That's the kind of bollock that damages the ability of employees to have >> a right to free speech which disagrees with (or is at least >> independently developed of) their employers views. >> >> As long it as someone makes it clear when they are speaking for >> themselves and not as a representative of the group, it should be >> accepted on that basis, unless if there is a reason to believe otherwise >> *other than* just that the person happens to be a member of some group. >> >> It's kind of like saying a black who says he or she speaking for himself >> speaks for all blacks, just because it's known he or she is black and he >> speaks on a public channel. >> >> It's bollocks. People are indivduals and have a right be such, and to >> have, and be seen to have, views independent of the various groups the >> are members of. >> >> I certainly don't speak for all white male IT professionals from North >> America. >> > > On that note, after the fact I noticed your .hu and am wondering if that > this kind of thinking is a difference in the culture you're part of vs. > the western cultures Hauke and I are part of? > > In much of 'the west' there is an expectation that individuals are free > to speak for themselves (and be seen to be doing such) regardless of > what group (although various corporations and governments sometimes try > and quash such things, which most here consider a harm not a good) they > belong to. > > Certainly Hauke believes he is free to speak for himself and has a > reasonable expectation that people will accept that his opinion is his > alone, unless he explicitly is speaking on behalf of some organization, > like LEDE. > > To a certain extent you yourself acknowledge individual opinion (with > you over a beer comment), but you seem to think that such a view of > individual opinions are not as valid in the public domain, whereas our > expectation is that it is just as valid in the public domain as in the > private. > > Regards, > > Daniel Let's just save such non-sense sense of culture and expectation discussion in another place. yousong > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt / LEDE
On Wed, 2016-05-25 at 08:45 +0800, Yousong Zhou wrote: > > > > To a certain extent you yourself acknowledge individual opinion (with > > you over a beer comment), but you seem to think that such a view of > > individual opinions are not as valid in the public domain, whereas our > > expectation is that it is just as valid in the public domain as in the > > private. > Let's just save such non-sense sense of culture and expectation > discussion in another place. The point was that Hauke is perfectly reasonable to expect that he can speak for himself (if you disagree then it will negatively impact your ability to interact well with those on this list), and that I was attempting to point out to someone who appears to be from a different country, where norms *really and truly* are different. Failing to be aware of, and prepared to find reasonable ways to deal with (even if just pointing out this, this is what we expect, which is different than what you may be used to expecting) people who have quite different learned interpretations of interactions is to *deny reality*. We live in a world where people don't all grow up with the same playbook, and that means we're not even necessarily all trying to play the same game, and being aware of this, and pointing out what game is actually being played *is important to rational discourse*. It doesn't mean we have to live by someone elses expectations (if that was what you were upset about), but to deny that such things are true is to fail to comprehend the world as it really is. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt / LEDE
On Tue, 2016-05-24 at 20:57 -0400, Daniel Dickinson wrote: > On Wed, 2016-05-25 at 08:45 +0800, Yousong Zhou wrote: > > > > > > To a certain extent you yourself acknowledge individual opinion (with > > > you over a beer comment), but you seem to think that such a view of > > > individual opinions are not as valid in the public domain, whereas our > > > expectation is that it is just as valid in the public domain as in the > > > private. > > > Let's just save such non-sense sense of culture and expectation > > discussion in another place. Perhaps the issue is the notion of a monolithic culture - that is *not* what meant. There are variations and subgroups, and individual differences, no doubt about that. The point is that there are different demographics who grew up with different rules than others, and perhaps culture was too broad a term, but understanding that other people come to the table with different interpretations, and pointing out why we do and say what we do important to rational dialogue, because if I say red and you are thinking of what call blue, it's not going to be very constructive. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt / LEDE
On Tue, 2016-05-24 at 21:19 -0400, Daniel Dickinson wrote: > > > Let's just save such non-sense sense of culture and expectation > > > discussion in another place. > > Perhaps the issue is the notion of a monolithic culture - that is *not* > what meant. There are variations and subgroups, and individual > differences, no doubt about that. The point is that there are different > demographics who grew up with different rules than others, and perhaps Perhaps your objection is the notion with any kind of general statement about a group. Personally I think as long as one recognized that such statements are *statistical predictions* and not necessarily representative of a given individual. This is true, but is also true that one can make predictions, or at rate useful guesses, about *potential* reasons for someone's actions or beliefs. The object is not to pigeonhole, but, given minimal information, to attempt to *understand and address* things that give rise to disputes. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [OT] Implemented: not an ML erase button but at least a rethink switch
Hi all, I've recognized I have to do something about my impulse emailing and have just finished implementing a technical solution that requires me to verify that really do want to send the mail, and verification can't be done until a configured amount of time has elapsed. Hopefully this will keep me from so much unwise/noisy mail. If anyway else is interested, Ubuntu packages are available in my PPA: https://launchpad.net/~dfc-d/+archive/ubuntu/misc It's based on the msmtpq queuing scripts wrapped around the msmtp send-only email client, acting as the 'sendmail' command, with the addition of a command-line option --verify-before-send that if you invoked as sendmail with that as the first parameter (e.g. from Evolution), it queues the mail but doesn't send it, and requires you to confirm that you want to send it, and then only after your configured delay period has past. System mails don't have the parameter so just send or queue and automatically send as usual (assuming of course you have configured /etc/msmtprc to use your email provider). msmtpq-mta also supports per-user configuration and can use the gnome keyring (that comes from the msmtp command). If want to keep your normal MTA command and use the msmtpq command to achieve this functionality you can do that as well, although you will need to have a wrapper that sets the applicable environment variable to enable the send delay. Even if no one else finds this interesting, I know I needed it. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
