Re: [OpenWrt-Devel] KERNEL_PATCHVER in master
On 11.06.19 23:12, Jonas Gorski wrote: Hi, On Tue, 11 Jun 2019 at 23:08, Stijn Tintel wrote: Hi, Since we now have a 19.07 branch, is it OK to switch KERNEL_PATCHVER for targets in master that have 4.19 support to 4.19? Fine by me. The earlier we start testing 4.19, the faster we can iron out the kinks, hopefully reducing the maturation phase of the next release. Fine for me, but please hold off a little bit until I pushed my kernel bump later today. (already in staging) Otherwise there's a chance I need to redo it ;-) Thanks, Koen Regards Jonas ___ 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] [PATCH 4/4] package: fix "LTO" option resulted in building error
On Tue, Jun 11, 2019 at 11:21:45PM +0800, Felix Fietkau wrote: > On 2019-06-11 12:32, Nylon Chen wrote: > > When a building package has -flto option leads to building error > > > > We must use the gcc-ar wrapper instead of ar to invoke ar with the right > > plugin arguments for handling the LTO objects when -flto is specified. > > > > Signed-off-by: Che-Wei Chuang > > Signed-off-by: Nylon Chen > Why is this nds32 specific? Not only nds32 > Does it not make sense to extend this to all targets? I am not sure, but I am trying the others toolchain x86-gcc gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04) cc -flto -c f1.c cc -flto -c f2.c ar -r f.a f1.o f2.o ar: creating f.a rm -rf *.o *.a gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11) cc -flto -c f1.c cc -flto -c f2.c ar -r f.a f1.o f2.o ar: creating f.a ar: f1.o: plugin needed to handle lto object ar: f2.o: plugin needed to handle lto object rm -rf *.o *.a riscv riscv64-linux-gcc -flto -c f1.c riscv64-linux-gcc -flto -c f2.c riscv64-linux-ar -r f.a f1.o f2.o riscv64-linux-ar: creating f.a rm -rf *.o *.a nds32 nds32le-linux-gcc -flto -c f1.c nds32le-linux-gcc -flto -c f2.c nds32le-linux-ar -r f.a f1.o f2.o nds32le-linux-ar: creating f.a nds32le-linux-ar: f1.o: plugin needed to handle lto object nds32le-linux-ar: f2.o: plugin needed to handle lto object nds32le-linux-gcc-ar -r f.a f1.o f2.o nds32le-linux-glibc-v3-upstream/bin/../lib/gcc/nds32le-linux/8.0.1/../../../../nds32le-linux/bin/ar: creating f.a rm -rf *.o *.a arm arm-none-eabi-gcc -flto -c f1.c arm-none-eabi-gcc -flto -c f2.c arm-none-eabi-ar -r f.a f1.o f2.o arm-none-eabi-ar: creating f.a arm-none-eabi-ar: f1.o: plugin needed to handle lto object arm-none-eabi-ar: f2.o: plugin needed to handle lto object arm-none-eabi-gcc-ar -r f.a f1.o f2.o gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ar: creating f.a rm -rf *.o *.a summary 1.the same issue could be found in other vendors' toolchain 2.pass on newer than x86-gcc5.4 version 3.specificed -ffat-lto-objects during building toolchain could be solved > > - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] sysupgrade: Cross-flashing NOR/NAND proof of concept
Hi! On Wed, Jun 12, 2019 at 8:42 AM Jeff Kletsky wrote: > > From: Jeff Kletsky > * The kernel and software for both the NOR- and NAND-resident > variants need to be able to read/write raw MTD as well as UBI. > > * The existing sysupgrade paths already prevent flashing of a > NOR-intended image onto a NAND-based device, as well as the other > way around. As such, even if a approach like this is accepted > after these board names are "in the wild", sysupgrade will be > "safe" on "old" builds against future additions to SUPPORTED_DEVICES. Why would someone do such a cross-flashing at the first place? If you want to recover the firmware in SPI NAND with a firmware in SPI NOR, You could just flash a initramfs image of the NAND variant into NOR flash. (And vice versa) > > * The MTD partitioning for both variants need to define both NOR and > NAND partitioning GL-AR300M has an NOR-only variant and by adding SPI NAND node into the NOR variant you'll add some unnecessary error messages into kernel log. Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] KERNEL_PATCHVER in master
On Wed, 12 Jun 2019 at 11:02, Koen Vandeputte wrote: > > > On 11.06.19 23:12, Jonas Gorski wrote: > > Hi, > > > > On Tue, 11 Jun 2019 at 23:08, Stijn Tintel wrote: > >> Hi, > >> > >> Since we now have a 19.07 branch, is it OK to switch KERNEL_PATCHVER for > >> targets in master that have 4.19 support to 4.19? > > Fine by me. The earlier we start testing 4.19, the faster we can iron > > out the kinks, hopefully reducing the maturation phase of the next > > release. > > > Fine for me, but please hold off a little bit until I pushed my kernel > bump later today. (already in staging) > > Otherwise there's a chance I need to redo it ;-) This is only about enabling 4.19 by default if supported, not adding 4.19 support where missing. So shouldn't affect any kernel bumps. Regards Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] KERNEL_PATCHVER in master
On 12.06.19 14:06, Jonas Gorski wrote: On Wed, 12 Jun 2019 at 11:02, Koen Vandeputte wrote: On 11.06.19 23:12, Jonas Gorski wrote: Hi, On Tue, 11 Jun 2019 at 23:08, Stijn Tintel wrote: Hi, Since we now have a 19.07 branch, is it OK to switch KERNEL_PATCHVER for targets in master that have 4.19 support to 4.19? Fine by me. The earlier we start testing 4.19, the faster we can iron out the kinks, hopefully reducing the maturation phase of the next release. Fine for me, but please hold off a little bit until I pushed my kernel bump later today. (already in staging) Otherwise there's a chance I need to redo it ;-) This is only about enabling 4.19 by default if supported, not adding 4.19 support where missing. So shouldn't affect any kernel bumps. Very true, But I'm expecting patches coming in fast when people start testing this. When this happens, I'll need to rebase this bump continuously. ;-) Most bumps don't require to much alteration, but this one in staging took me a few hours .. Koen Regards Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] config: enable some useful features on !SMALL_FLASH devices
On Wed, 6 Feb 2019 at 13:12, Jonas Gorski wrote: > > On Tue, 15 Jan 2019 at 15:42, Daniel Golle wrote: > > > > Hi Jonas, > > > > On Mon, Jan 07, 2019 at 03:48:29PM +0100, Daniel Golle wrote: > > > On Mon, Jan 07, 2019 at 02:39:26PM +, Jonas Gorski wrote: > > > > On Mon, 7 Jan 2019 at 14:21, Daniel Golle wrote: > > > > > > > > > > On Mon, Jan 07, 2019 at 01:17:34PM +, Jonas Gorski wrote: > > > > > > On Mon, 7 Jan 2019 at 11:42, Petr Štetiar wrote: > > > > > > > > > > > > > > Daniel Golle [2019-01-07 10:03:09]: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > One. The MT7621 EVB. The TP-LINK RE350 v1 can probably be > > > > > > > > converted to > > > > > > > > a more sane flash partition layout to gain another megabyte or > > > > > > > > so. > > > > > > > > > > > > > > I've looked only at mt7621, so this was just example from one > > > > > > > subtarget of > > > > > > > ramips target. So I tend to believe, that there's quite more such > > > > > > > cases hidden > > > > > > > in the tree. Please correct me if I'm wrong. > > > > > > > > > > > > > > > Why specific devices? Wouldn't all devices with the resources > > > > > > > > (which > > > > > > > > boils down to !SMALL_FLASH) be potentially more useful with > > > > > > > > those > > > > > > > > kernel features enabled? > > > > > > > > > > > > > > You currently can't use !SMALL_FLASH, because this is > > > > > > > target/subtarget > > > > > > > specific feature, not per device feature. I think, that in order > > > > > > > to use this > > > > > > > feature, you would need to convert/fix all devices like that > > > > > > > TP-Link RE350 > > > > > > > from all (sub)targets into tiny subtarget and then you could > > > > > > > freely use > > > > > > > !SMALL_FLASH. > > > > > > > > > > > > I agree with not abusing small_flash for that. It has a clear > > > > > > defined > > > > > > meaning, and shouldn't have unrelated side effects. > > > > > > > > > > So what else would the SMALL_FLASH symbol be used for then? > > > > > A quick grep reveals that currently already quite a few kernel config > > > > > defaults are set according to SMALL_FLASH, see > > > > > > > > > > origin/master:Config-kernel.in- > > > > > origin/master:Config-kernel.in-config KERNEL_SWAP > > > > > origin/master:Config-kernel.in- bool "Support for paging of anonymous > > > > > memory (swap)" > > > > > origin/master:Config-kernel.in: default y if !SMALL_FLASH > > > > > -- > > > > > origin/master:Config-kernel.in- > > > > > origin/master:Config-kernel.in-config KERNEL_KALLSYMS > > > > > origin/master:Config-kernel.in- bool "Compile the kernel with symbol > > > > > table information" > > > > > origin/master:Config-kernel.in: default y if !SMALL_FLASH > > > > > -- > > > > > origin/master:Config-kernel.in- > > > > > origin/master:Config-kernel.in-config KERNEL_DEBUG_INFO > > > > > origin/master:Config-kernel.in- bool "Compile the kernel with debug > > > > > information" > > > > > origin/master:Config-kernel.in: default y if !SMALL_FLASH > > > > > -- > > > > > origin/master:Config-kernel.in-config KERNEL_ELF_CORE > > > > > origin/master:Config-kernel.in- bool "Enable process core dump > > > > > support" > > > > > origin/master:Config-kernel.in- select KERNEL_COREDUMP > > > > > origin/master:Config-kernel.in: default y if !SMALL_FLASH > > > > > ... > > > > > > > > Most of these option only influence the size of the kernel, and have > > > > no further runtime side effects. Also small_flash has impact on the > > > > compression options used. > > > > > > They sure do, cache size on small CPUs is a very finite resource > > > and having a kernel with debug symbols will make things slower, of > > > course. SWAP also makes every single malloc call more expensive and > > > is just as well only useful on devices with block storage (ok, and > > > zramswap, but lets not talk about that). > > > > > > > > > > > > > > > > > > > > > > > > I think a new opt-in symbol for those targets with hardware > > > > > > virtualization support and/or beefy enough cpus would make more > > > > > > sense. > > > > > > Those virtualization options (probably) don't come for free, they > > > > > > will > > > > > > have also a memory and performance impact even when not actively > > > > > > used. > > > > > > How much that is (and if this assumption is true) would be nice to > > > > > > have in the PR/patch for it. > > > > > > > > > > This is not about virtualization and none of the features selected > > > > > requires any special hardware support apart from the few extra > > > > > kilobytes of flash and memory. You are still right, it doesn't come > > > > > all for free at runtime in terms of CPU cycles, but the impact is > > > > > hardly measurable. > > > > > > > > > > But sure, I understand that this can be opt-in, so lets call it > > > > > 'full_kernel' or something like that and have target maintainers > > > > > decide themselves. In the picture I get after browsing through > > > > > all targe
[OpenWrt-Devel] [firewall3] utils: coverity resource leak warning
solve coverity reported resource leak (socket handle)
Signed-off-by: Kevin Darbyshire-Bryant
---
utils.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/utils.c b/utils.c
index 7f09787..fc6bbd7 100644
--- a/utils.c
+++ b/utils.c
@@ -944,18 +944,24 @@ bool
fw3_check_loopback_dev(const char *name)
{
struct ifreq ifr;
- int s = socket(AF_LOCAL, SOCK_DGRAM, 0);
+ int s;
bool rv = false;
+ s = socket(AF_LOCAL, SOCK_DGRAM, 0);
+
+ if (s < 0)
+ return false;
+
memset(&ifr, 0, sizeof(ifr));
strncpy(ifr.ifr_name, name, sizeof(ifr.ifr_name) - 1);
- if (s < 0 || ioctl(s, SIOCGIFFLAGS, &ifr) < 0)
- goto out;
+ if (ioctl(s, SIOCGIFFLAGS, &ifr) >= 0) {
+ if (ifr.ifr_flags & IFF_LOOPBACK)
+ rv = true;
+ }
+
+ close(s);
- if (ifr.ifr_flags & IFF_LOOPBACK)
- rv = true;
-out:
return rv;
}
--
2.20.1 (Apple Git-117)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [firewall3] utils: coverity resource leak warning
Hi Kevin, ACK. Feel free to push. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 2/3] network/config: add xfrm interface support scripts
Hi Hans!!
Am 11.06.19 um 22:16 schrieb Hans Dedecker:
> Hi,
>
> On Mon, Jun 10, 2019 at 8:10 PM Andre Valentin wrote:
>>
>> Hi Hans,
>>
>> after testing xfrm tunnels a bit I found to big differences compared to
>> other convential tunnels.
>> 1) xfrm tunnel interfaces cannot be replaced with netlink
>> 2) xfrm tunnel interfaces DO NOT vanish if parent is deleted
>>
>> This leads to some errors and a loop in interface creation. With the changes
>> below,
>> it works smoothly when not bound to ppp interfaces (using lan instead), see:
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: xfrm0 (14255): Command
>> failed: Unknown error
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: Interface 'xfrm0' is now down
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: Interface 'xfrm0' is setting
>> up now
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: xfrm0 (14281): Command
>> failed: Unknown error
>> and so on
What do you think?
> The description is a bit cryptic to me; could you explain what works
> and what does not work and why ?
Sorry for being cryptic, I tend to that;-) Okay, I do the following:
# ifup xfrm0
... use it
# ifdown xfrm0
The interface still exists (checked with ip link)
Now I'll do ifup again and this happens endlessly:
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: xfrm0 (14255): Command
>> failed: Unknown error
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: Interface 'xfrm0' is now down
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: Interface 'xfrm0' is setting
>> up now
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: xfrm0 (14281): Command
>> failed: Unknown error
In netifd the xfrm0 interface is created with the REPLACE flag, but that does
not seem to work, it cannot be recreated and fails.
The result is the upper error repeating.
That's why I think about the call to "ip link delete xfrm0" before
proto_init_update call and in the teardown call.
André
>
> Hans
>>
>> Kind regards,
>>
>> André
>>
>>
>> Am 09.06.19 um 21:27 schrieb Hans Dedecker:
>>> On Sat, Jun 8, 2019 at 1:48 PM André Valentin wrote:
This package adds scripts for xfrm interfaces support.
Example configuration via /etc/config/network:
config interface 'xfrm0'
option proto 'xfrm'
option mtu '1300'
option zone 'VPN'
option tunlink 'wan'
option ifid 30
config interface 'xfrm0_static'
option proto 'static'
option ifname '@xfrm0'
option ip6addr 'fe80::1/64'
option ipaddr '10.0.0.1/30'
Now set in strongswan IPsec policy:
if_id_in = 30
if_id_out = 30
---
package/network/config/xfrm/Makefile | 38 ++
package/network/config/xfrm/files/xfrm.sh | 65
+++
2 files changed, 103 insertions(+)
create mode 100644 package/network/config/xfrm/Makefile
create mode 100755 package/network/config/xfrm/files/xfrm.sh
diff --git a/package/network/config/xfrm/Makefile
b/package/network/config/xfrm/Makefile
new file mode 100644
index 00..efc90cf318
--- /dev/null
+++ b/package/network/config/xfrm/Makefile
@@ -0,0 +1,38 @@
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=xfrm
+PKG_VERSION:=1
+PKG_RELEASE:=1
+PKG_LICENSE:=GPL-2.0
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/xfrm/Default
+ SECTION:=net
+ CATEGORY:=Network
+ MAINTAINER:=Andre Valentin
+endef
+
+define Package/xfrm
+$(call Package/xfrm/Default)
+ TITLE:=XFRM IPsec Tunnel Interface config support
+ DEPENDS:=+kmod-xfrm-interface
+endef
+
+define Package/xfrm/description
+ XFRM IPsec Tunnel Interface config support (IPv4 and IPv6) in
/etc/config/network.
+endef
+
+define Build/Compile
+endef
+
+define Build/Configure
+endef
+
+define Package/xfrm/install
+ $(INSTALL_DIR) $(1)/lib/netifd/proto
+ $(INSTALL_BIN) ./files/xfrm.sh $(1)/lib/netifd/proto/xfrm.sh
+endef
+
+$(eval $(call BuildPackage,xfrm))
diff --git a/package/network/config/xfrm/files/xfrm.sh
b/package/network/config/xfrm/files/xfrm.sh
new file mode 100755
index 00..df28d38613
--- /dev/null
+++ b/package/network/config/xfrm/files/xfrm.sh
@@ -0,0 +1,65 @@
+#!/bin/sh
+
+[ -n "$INCLUDE_ONLY" ] || {
+ . /lib/functions.sh
+ . /lib/functions/network.sh
+ . ../netifd-proto.sh
+ init_proto "$@"
+}
+
+proto_xfrm_setup() {
+ local cfg="$1"
+ local mode="xfrm"
+
+ local tunlink ifid mtu zone
+ json_get_vars tunlink ifid mtu zone
+
>> if exists .. ip link del "$cfg"
>>
+ proto_init_update "$cfg" 1
+
[OpenWrt-Devel] [PATCH] opkg: add --license arg for installed packages
add --license option to print (SPDX) license tag in the
`installed-packages` overview. This is useful for manifest generation,
as it show all licenses used within an image. In case the license is not
available, a question mark (?) is printed instead.
base-files - 198-r10203+1-c12bd3a21b - GPL-2.0
bnx2-firmware - 20190416-1 - ?
busybox - 1.30.1-4 - GPL-2.0
dnsmasq - 2.80-13 - GPL-2.0
dropbear - 2019.78-2 - MIT
e2fsprogs - 1.44.5-1 - GPL-2.0
firewall - 2019-01-02-70f8785b-2 - ISC
fstools - 2019-03-28-ff1ded63-4 - GPL-2.0
fwtool - 1 - ?
getrandom - 2019-04-07-5130fa4d-2 - GPL-2.0
ip6tables - 1.8.2-3 - GPL-2.0
iptables - 1.8.2-3 - GPL-2.0
jshn - 2019-02-27-eeef7b50-1 - ISC
jsonfilter - 2018-02-04-c7e938d6-1 - ISC
...
CC: Jo-Philipp Wich
Signed-off-by: Paul Spooren
---
libopkg/opkg_cmd.c | 3 +++
libopkg/opkg_conf.c | 1 +
libopkg/opkg_conf.h | 1 +
libopkg/pkg.c | 11 +++
libopkg/pkg.h | 1 +
libopkg/pkg_parse.c | 5 +
libopkg/pkg_parse.h | 1 +
src/opkg-cl.c | 7 +++
8 files changed, 30 insertions(+)
diff --git a/libopkg/opkg_cmd.c b/libopkg/opkg_cmd.c
index c823df8..e8a34f4 100644
--- a/libopkg/opkg_cmd.c
+++ b/libopkg/opkg_cmd.c
@@ -45,9 +45,12 @@ static void print_pkg(pkg_t * pkg)
{
char *version = pkg_version_str_alloc(pkg);
char *description = pkg_get_string(pkg, PKG_DESCRIPTION);
+ char *license = pkg_get_string(pkg, PKG_LICENSE);
printf("%s - %s", pkg->name, version);
if (conf->size)
printf(" - %lu", (unsigned long) pkg_get_int(pkg, PKG_SIZE));
+ if (conf->license)
+ printf(" - %s", license ? license : "?");
if (description)
printf(" - %s", description);
printf("\n");
diff --git a/libopkg/opkg_conf.c b/libopkg/opkg_conf.c
index 08855eb..40b1734 100644
--- a/libopkg/opkg_conf.c
+++ b/libopkg/opkg_conf.c
@@ -70,6 +70,7 @@ opkg_option_t options[] = {
{"proxy_user", OPKG_OPT_TYPE_STRING, &_conf.proxy_user},
{"query-all", OPKG_OPT_TYPE_BOOL, &_conf.query_all},
{"size", OPKG_OPT_TYPE_BOOL, &_conf.size},
+ {"license", OPKG_OPT_TYPE_BOOL, &_conf.license},
{"tmp_dir", OPKG_OPT_TYPE_STRING, &_conf.tmp_dir},
{"verbosity", OPKG_OPT_TYPE_INT, &_conf.verbosity},
{NULL, 0, NULL}
diff --git a/libopkg/opkg_conf.h b/libopkg/opkg_conf.h
index 37f95a1..0413ccd 100644
--- a/libopkg/opkg_conf.h
+++ b/libopkg/opkg_conf.h
@@ -87,6 +87,7 @@ struct opkg_conf {
int verbosity;
int noaction;
int size;
+ int license;
int download_only;
char *cache;
diff --git a/libopkg/pkg.c b/libopkg/pkg.c
index e5bfe6f..fb1b2f1 100644
--- a/libopkg/pkg.c
+++ b/libopkg/pkg.c
@@ -777,6 +777,15 @@ void pkg_formatted_field(FILE * fp, pkg_t * pkg, const
char *field)
}
}
break;
+ case 'l':
+ case 'L':
+ if (strcasecmp(field, "License") == 0) {
+ p = pkg_get_string(pkg, PKG_LICENSE);
+ if (p && *p) {
+ fprintf(fp, "License: %s\n", p);
+ }
+ }
+ break;
case 'm':
case 'M':
if (strcasecmp(field, "Maintainer") == 0) {
@@ -926,6 +935,7 @@ void pkg_formatted_info(FILE * fp, pkg_t * pkg)
pkg_formatted_field(fp, pkg, "Package");
pkg_formatted_field(fp, pkg, "Version");
pkg_formatted_field(fp, pkg, "Depends");
+ pkg_formatted_field(fp, pkg, "License");
pkg_formatted_field(fp, pkg, "Recommends");
pkg_formatted_field(fp, pkg, "Suggests");
pkg_formatted_field(fp, pkg, "Provides");
@@ -956,6 +966,7 @@ void pkg_print_status(pkg_t * pkg, FILE * file)
pkg_formatted_field(file, pkg, "Package");
pkg_formatted_field(file, pkg, "Version");
pkg_formatted_field(file, pkg, "Depends");
+ pkg_formatted_field(file, pkg, "License");
pkg_formatted_field(file, pkg, "Recommends");
pkg_formatted_field(file, pkg, "Suggests");
pkg_formatted_field(file, pkg, "Provides");
diff --git a/libopkg/pkg.h b/libopkg/pkg.h
index 600fc9e..0065043 100644
--- a/libopkg/pkg.h
+++ b/libopkg/pkg.h
@@ -79,6 +79,7 @@ typedef enum pkg_state_status pkg_state_status_t;
enum pkg_fields {
PKG_MAINTAINER,
+ PKG_LICENSE,
PKG_PRIORITY,
PKG_SOURCE,
PKG_TAGS,
diff --git a/libopkg/pkg_parse.c b/libopkg/pkg_parse.c
index 0baa4db..87db2fa 100644
--- a/libopkg/pkg_parse.c
+++ b/libopkg/pkg_parse.c
@@ -269,6 +269,11 @@ int pkg_parse_line(void *ptr, char *line, uint mask)
pkg_set_int(pkg, PKG_INSTALLED_TIME, strtoul(line +
strlen("Installed-Time") + 1, NULL, 0));
}
break;
+ case 'l':
+ case 'L':
+ if ((mask & PFM_LICENSE) && is_field("License:", line))
+ pkg_set_string(pkg, PKG_LICENS
Re: [OpenWrt-Devel] [RFC] additional Docker images and CI testing
Hi Ted, > This sounds like a good idea - would giving you commit access to our > docker hub [0] repo be of any help? Is there anything else I could > help with? I'd be happy with commit access to the docker hub (not to mistake with git commit access). Please find here a reworked version with a README and scripts that can also run locally: https://github.com/aparcar/openwrt-docker > > I don't know if you saw this posting I made last year about a simple > use of our Docker image for test buiilds. Issue #7735 [1]. I had > pinned it > but for some reason @heil un-pinned it and I left it be. I hadn't checked the PR yet but will do so soonish! Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 2/3] network/config: add xfrm interface support scripts
Hi, On Wed, Jun 12, 2019 at 8:28 PM Andre Valentin wrote: > > Hi Hans!! > Am 11.06.19 um 22:16 schrieb Hans Dedecker: > > Hi, > > > > On Mon, Jun 10, 2019 at 8:10 PM Andre Valentin > > wrote: > >> > >> Hi Hans, > >> > >> after testing xfrm tunnels a bit I found to big differences compared to > >> other convential tunnels. > >> 1) xfrm tunnel interfaces cannot be replaced with netlink > >> 2) xfrm tunnel interfaces DO NOT vanish if parent is deleted > >> > >> This leads to some errors and a loop in interface creation. With the > >> changes below, > >> it works smoothly when not bound to ppp interfaces (using lan instead), > >> see: > >> Mon Jun 10 11:42:06 2019 daemon.notice netifd: xfrm0 (14255): Command > >> failed: Unknown error > >> Mon Jun 10 11:42:06 2019 daemon.notice netifd: Interface 'xfrm0' is now > >> down > >> Mon Jun 10 11:42:06 2019 daemon.notice netifd: Interface 'xfrm0' is > >> setting up now > >> Mon Jun 10 11:42:06 2019 daemon.notice netifd: xfrm0 (14281): Command > >> failed: Unknown error > >> and so on > What do you think? > > The description is a bit cryptic to me; could you explain what works > > and what does not work and why ? > Sorry for being cryptic, I tend to that;-) Okay, I do the following: > # ifup xfrm0 > ... use it > # ifdown xfrm0 > The interface still exists (checked with ip link) > > Now I'll do ifup again and this happens endlessly: > >> Mon Jun 10 11:42:06 2019 daemon.notice netifd: xfrm0 (14255): Command > >> failed: Unknown error > >> Mon Jun 10 11:42:06 2019 daemon.notice netifd: Interface 'xfrm0' is now > >> down > >> Mon Jun 10 11:42:06 2019 daemon.notice netifd: Interface 'xfrm0' is > >> setting up now > >> Mon Jun 10 11:42:06 2019 daemon.notice netifd: xfrm0 (14281): Command > >> failed: Unknown error > > In netifd the xfrm0 interface is created with the REPLACE flag, but that does > not seem to work, it cannot be recreated and fails. > The result is the upper error repeating. > That's why I think about the call to "ip link delete xfrm0" before > proto_init_update call and in the teardown call. Adding the ip link calls does not make sense to me as netifd should take care of deleting the xfrm interfaces Are you sure the xfrm interfaces can be deleted by the ioctl call SIOCDELTUNNEL as is the case now ? For the other tunnel interfaces like vti/gre deletion is done via the netlink interface. Next to that I noticed a tunlink is specified in xfrm.sh but no proto_add_host_dependency is added; is this on purpose ? Hans > > André > > > > > > Hans > >> > >> Kind regards, > >> > >> André > >> > >> > >> Am 09.06.19 um 21:27 schrieb Hans Dedecker: > >>> On Sat, Jun 8, 2019 at 1:48 PM André Valentin > >>> wrote: > > This package adds scripts for xfrm interfaces support. > Example configuration via /etc/config/network: > > config interface 'xfrm0' > option proto 'xfrm' > option mtu '1300' > option zone 'VPN' > option tunlink 'wan' > option ifid 30 > > config interface 'xfrm0_static' > option proto 'static' > option ifname '@xfrm0' > option ip6addr 'fe80::1/64' > option ipaddr '10.0.0.1/30' > > Now set in strongswan IPsec policy: > if_id_in = 30 > if_id_out = 30 > --- > package/network/config/xfrm/Makefile | 38 ++ > package/network/config/xfrm/files/xfrm.sh | 65 > +++ > 2 files changed, 103 insertions(+) > create mode 100644 package/network/config/xfrm/Makefile > create mode 100755 package/network/config/xfrm/files/xfrm.sh > > diff --git a/package/network/config/xfrm/Makefile > b/package/network/config/xfrm/Makefile > new file mode 100644 > index 00..efc90cf318 > --- /dev/null > +++ b/package/network/config/xfrm/Makefile > @@ -0,0 +1,38 @@ > + > +include $(TOPDIR)/rules.mk > + > +PKG_NAME:=xfrm > +PKG_VERSION:=1 > +PKG_RELEASE:=1 > +PKG_LICENSE:=GPL-2.0 > + > +include $(INCLUDE_DIR)/package.mk > + > +define Package/xfrm/Default > + SECTION:=net > + CATEGORY:=Network > + MAINTAINER:=Andre Valentin > +endef > + > +define Package/xfrm > +$(call Package/xfrm/Default) > + TITLE:=XFRM IPsec Tunnel Interface config support > + DEPENDS:=+kmod-xfrm-interface > +endef > + > +define Package/xfrm/description > + XFRM IPsec Tunnel Interface config support (IPv4 and IPv6) in > /etc/config/network. > +endef > + > +define Build/Compile > +endef > + > +define Build/Configure > +endef > + > +define Package/xfrm/install > + $(INSTALL_DIR) $(1)/lib/netifd/proto > + $(INSTALL_BIN) ./files/xfrm.sh $(1)/lib/netifd/proto/xfrm.sh > +endef > + >
