Re: Re: [PATCH v2] gemini: Bump to kernel v5.10

2021-04-17 Thread itugrok--- via openwrt-devel 
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 ---
Hello Linus,

Please rebase your changes against the latest master, since your config-5.10 
appears based on a config-5.4 that is missing commit 41948c9c1b80 ("gemini, 
layerscape, oxnas: don't disable option CONFIG_BPF_SYSCALL"). I had mentioned 
you on the original PR https://github.com/openwrt/openwrt/pull/4068 as a gemini 
contributor and reviewer.

Thanks,
Tony

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] gemini: Bump to kernel v5.10

2021-04-17 Thread Linus Walleij 
Only two patches against mainline remains. Switch to v5.10
which works very nicely with all Gemini devices.

Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Update the config-5.10 using the proper oldconfig
  update target.
- Drop config options that have been migrated to the
  target/linux/generic/config-5.10
- Drop some pointless config options like OABI compat
  and FPE (floating point emulation) related to OABI,
  (FPE is done by the compiler).
---
 target/linux/gemini/Makefile  |   2 +-
 target/linux/gemini/config-5.10   | 432 ++
 ...t-fotg2-add-Gemini-specific-handling.patch | 131 ++
 ...-DIR-685-partition-table-for-OpenWrt.patch |  37 ++
 4 files changed, 601 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/gemini/config-5.10
 create mode 100644 
target/linux/gemini/patches-5.10/0001-usb-host-fotg2-add-Gemini-specific-handling.patch
 create mode 100644 
target/linux/gemini/patches-5.10/0002-ARM-dts-Augment-DIR-685-partition-table-for-OpenWrt.patch

diff --git a/target/linux/gemini/Makefile b/target/linux/gemini/Makefile
index d2acb52facf7..95a5a87eaa4d 100644
--- a/target/linux/gemini/Makefile
+++ b/target/linux/gemini/Makefile
@@ -10,7 +10,7 @@ BOARDNAME:=Cortina Systems CS351x
 FEATURES:=squashfs pci rtc usb dt gpio display ext4 rootfs-part boot-part
 CPU_TYPE:=fa526
 
-KERNEL_PATCHVER:=5.4
+KERNEL_PATCHVER:=5.10
 
 define Target/Description
Build firmware images for the StorLink/Cortina Gemini CS351x ARM FA526 
CPU
diff --git a/target/linux/gemini/config-5.10 b/target/linux/gemini/config-5.10
new file mode 100644
index ..b9b0afd05720
--- /dev/null
+++ b/target/linux/gemini/config-5.10
@@ -0,0 +1,432 @@
+CONFIG_ALIGNMENT_TRAP=y
+CONFIG_AMBA_PL08X=y
+CONFIG_ARCH_32BIT_OFF_T=y
+CONFIG_ARCH_GEMINI=y
+CONFIG_ARCH_KEEP_MEMBLOCK=y
+CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
+# CONFIG_ARCH_MOXART is not set
+CONFIG_ARCH_MULTIPLATFORM=y
+CONFIG_ARCH_MULTI_V4=y
+# CONFIG_ARCH_MULTI_V4T is not set
+CONFIG_ARCH_MULTI_V4_V5=y
+# CONFIG_ARCH_MULTI_V5 is not set
+CONFIG_ARCH_NR_GPIO=0
+CONFIG_ARCH_OPTIONAL_KERNEL_RWX=y
+CONFIG_ARCH_SELECT_MEMORY_MODEL=y
+CONFIG_ARCH_SPARSEMEM_ENABLE=y
+CONFIG_ARM=y
+CONFIG_ARM_AMBA=y
+CONFIG_ARM_APPENDED_DTB=y
+# CONFIG_ARM_ATAG_DTB_COMPAT is not set
+CONFIG_ARM_HAS_SG_CHAIN=y
+CONFIG_ARM_L1_CACHE_SHIFT=5
+CONFIG_ARM_PATCH_PHYS_VIRT=y
+# CONFIG_ARM_SMMU is not set
+CONFIG_ARM_UNWIND=y
+CONFIG_ATA=y
+CONFIG_ATAGS=y
+CONFIG_ATA_FORCE=y
+CONFIG_ATA_VERBOSE_ERROR=y
+CONFIG_AUTO_ZRELADDR=y
+CONFIG_BINFMT_FLAT_ARGVP_ENVP_ON_STACK=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_BLK_MQ_PCI=y
+CONFIG_BLK_PM=y
+CONFIG_BLK_SCSI_REQUEST=y
+CONFIG_BOUNCE=y
+# CONFIG_BPF_SYSCALL is not set
+CONFIG_CLKDEV_LOOKUP=y
+CONFIG_CLKSRC_MMIO=y
+CONFIG_CLONE_BACKWARDS=y
+CONFIG_CMA=y
+CONFIG_CMA_ALIGNMENT=8
+CONFIG_CMA_AREAS=7
+# CONFIG_CMA_DEBUG is not set
+# CONFIG_CMA_DEBUGFS is not set
+CONFIG_CMA_SIZE_PERCENTAGE=10
+# CONFIG_CMA_SIZE_SEL_MAX is not set
+# CONFIG_CMA_SIZE_SEL_MBYTES is not set
+# CONFIG_CMA_SIZE_SEL_MIN is not set
+CONFIG_CMA_SIZE_SEL_PERCENTAGE=y
+CONFIG_COMMON_CLK=y
+CONFIG_COMMON_CLK_GEMINI=y
+CONFIG_CONSOLE_TRANSLATIONS=y
+CONFIG_CONTIG_ALLOC=y
+CONFIG_COREDUMP=y
+CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
+CONFIG_CPU_32v4=y
+CONFIG_CPU_ABRT_EV4=y
+CONFIG_CPU_CACHE_FA=y
+CONFIG_CPU_CACHE_VIVT=y
+CONFIG_CPU_COPY_FA=y
+CONFIG_CPU_CP15=y
+CONFIG_CPU_CP15_MMU=y
+# CONFIG_CPU_DCACHE_WRITETHROUGH is not set
+CONFIG_CPU_FA526=y
+CONFIG_CPU_NO_EFFICIENT_FFS=y
+CONFIG_CPU_PABRT_LEGACY=y
+CONFIG_CPU_THERMAL=y
+CONFIG_CPU_TLB_FA=y
+CONFIG_CPU_USE_DOMAINS=y
+CONFIG_CRASH_CORE=y
+CONFIG_CRC16=y
+# CONFIG_CRC32_SARWATE is not set
+CONFIG_CRC32_SLICEBY8=y
+CONFIG_CRC_CCITT=y
+CONFIG_CRC_ITU_T=y
+CONFIG_CROSS_MEMORY_ATTACH=y
+CONFIG_CRYPTO_AEAD=y
+CONFIG_CRYPTO_AEAD2=y
+CONFIG_CRYPTO_CCM=y
+CONFIG_CRYPTO_CMAC=y
+CONFIG_CRYPTO_CRC32C=y
+CONFIG_CRYPTO_CTR=y
+CONFIG_CRYPTO_DES=y
+CONFIG_CRYPTO_DRBG=y
+CONFIG_CRYPTO_DRBG_HMAC=y
+CONFIG_CRYPTO_DRBG_MENU=y
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_ECHAINIV=y
+CONFIG_CRYPTO_GCM=y
+CONFIG_CRYPTO_GF128MUL=y
+CONFIG_CRYPTO_GHASH=y
+CONFIG_CRYPTO_HASH=y
+CONFIG_CRYPTO_HASH2=y
+CONFIG_CRYPTO_HMAC=y
+CONFIG_CRYPTO_HW=y
+CONFIG_CRYPTO_JITTERENTROPY=y
+CONFIG_CRYPTO_LIB_DES=y
+CONFIG_CRYPTO_LIB_SHA256=y
+CONFIG_CRYPTO_MANAGER=y
+CONFIG_CRYPTO_MANAGER2=y
+CONFIG_CRYPTO_MD4=y
+CONFIG_CRYPTO_MD5=y
+CONFIG_CRYPTO_NULL=y
+CONFIG_CRYPTO_NULL2=y
+CONFIG_CRYPTO_RNG=y
+CONFIG_CRYPTO_RNG2=y
+CONFIG_CRYPTO_RNG_DEFAULT=y
+CONFIG_CRYPTO_SEQIV=y
+CONFIG_CRYPTO_SHA256=y
+CONFIG_DEBUG_BUGVERBOSE=y
+CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
+CONFIG_DEBUG_MEMORY_INIT=y
+CONFIG_DECOMPRESS_BZIP2=y
+CONFIG_DECOMPRESS_GZIP=y
+CONFIG_DECOMPRESS_LZ4=y
+CONFIG_DECOMPRESS_LZMA=y
+CONFIG_DECOMPRESS_LZO=y
+CONFIG_DECOMPRESS_XZ=y
+CONFIG_DMADEVICES=y
+CONFIG_DMATEST=y
+CONFIG_DMA_CMA=y
+CONFIG_DMA_ENGINE=y
+CONFIG_DMA_ENGINE_RAID=y
+CONFIG_DMA_OF=y
+CONFIG_DMA_OPS=y
+CONFIG_DMA_REMAP=y
+CONFIG_DMA_SHARED_BUFFER=y
+CONFIG_DMA_VIRTU

[PATCH] kernel: backport mtk_ppe busy-wait loop fix

2021-04-17 Thread Ilya Lipnitskiy 
Fixes logic that leads to this error when booting mt7621 and other
devices that use the mediatek ethernet driver:
  [   23.144378] mtk_soc_eth 1e10.ethernet: PPE table busy

Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=c5d66587b8900201e1530b7c18d41e87bd5812f4
Fixes: f07fe36f22fc ("kernel: update flow offload patches to upstream version")
Cc: Felix Fietkau 
Signed-off-by: Ilya Lipnitskiy 
---
 ...rnet-mediatek-ppe-fix-busy-wait-loop.patch | 72 +++
 1 file changed, 72 insertions(+)
 create mode 100644 
target/linux/generic/backport-5.10/610-v5.13-35-net-ethernet-mediatek-ppe-fix-busy-wait-loop.patch

diff --git 
a/target/linux/generic/backport-5.10/610-v5.13-35-net-ethernet-mediatek-ppe-fix-busy-wait-loop.patch
 
b/target/linux/generic/backport-5.10/610-v5.13-35-net-ethernet-mediatek-ppe-fix-busy-wait-loop.patch
new file mode 100644
index ..66cd053cd1af
--- /dev/null
+++ 
b/target/linux/generic/backport-5.10/610-v5.13-35-net-ethernet-mediatek-ppe-fix-busy-wait-loop.patch
@@ -0,0 +1,72 @@
+From c5d66587b8900201e1530b7c18d41e87bd5812f4 Mon Sep 17 00:00:00 2001
+From: Ilya Lipnitskiy 
+Date: Thu, 15 Apr 2021 17:37:48 -0700
+Subject: [PATCH] net: ethernet: mediatek: ppe: fix busy wait loop
+
+The intention is for the loop to timeout if the body does not succeed.
+The current logic calls time_is_before_jiffies(timeout) which is false
+until after the timeout, so the loop body never executes.
+
+Fix by using readl_poll_timeout as a more standard and less error-prone
+solution.
+
+Fixes: ba37b7caf1ed ("net: ethernet: mtk_eth_soc: add support for initializing 
the PPE")
+Signed-off-by: Ilya Lipnitskiy 
+Cc: Felix Fietkau 
+Reviewed-by: Andrew Lunn 
+Signed-off-by: David S. Miller 
+---
+ drivers/net/ethernet/mediatek/mtk_ppe.c | 20 +---
+ drivers/net/ethernet/mediatek/mtk_ppe.h |  1 +
+ 2 files changed, 10 insertions(+), 11 deletions(-)
+
+--- a/drivers/net/ethernet/mediatek/mtk_ppe.c
 b/drivers/net/ethernet/mediatek/mtk_ppe.c
+@@ -2,9 +2,8 @@
+ /* Copyright (C) 2020 Felix Fietkau  */
+ 
+ #include 
+-#include 
+-#include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include "mtk_ppe.h"
+@@ -44,18 +43,17 @@ static u32 ppe_clear(struct mtk_ppe *ppe
+ 
+ static int mtk_ppe_wait_busy(struct mtk_ppe *ppe)
+ {
+-  unsigned long timeout = jiffies + HZ;
+-
+-  while (time_is_before_jiffies(timeout)) {
+-  if (!(ppe_r32(ppe, MTK_PPE_GLO_CFG) & MTK_PPE_GLO_CFG_BUSY))
+-  return 0;
++  int ret;
++  u32 val;
+ 
+-  usleep_range(10, 20);
+-  }
++  ret = readl_poll_timeout(ppe->base + MTK_PPE_GLO_CFG, val,
++   !(val & MTK_PPE_GLO_CFG_BUSY),
++   20, MTK_PPE_WAIT_TIMEOUT_US);
+ 
+-  dev_err(ppe->dev, "PPE table busy");
++  if (ret)
++  dev_err(ppe->dev, "PPE table busy");
+ 
+-  return -ETIMEDOUT;
++  return ret;
+ }
+ 
+ static void mtk_ppe_cache_clear(struct mtk_ppe *ppe)
+--- a/drivers/net/ethernet/mediatek/mtk_ppe.h
 b/drivers/net/ethernet/mediatek/mtk_ppe.h
+@@ -12,6 +12,7 @@
+ #define MTK_PPE_ENTRIES_SHIFT 3
+ #define MTK_PPE_ENTRIES   (1024 << MTK_PPE_ENTRIES_SHIFT)
+ #define MTK_PPE_HASH_MASK (MTK_PPE_ENTRIES - 1)
++#define MTK_PPE_WAIT_TIMEOUT_US   100
+ 
+ #define MTK_FOE_IB1_UNBIND_TIMESTAMP  GENMASK(7, 0)
+ #define MTK_FOE_IB1_UNBIND_PACKETSGENMASK(23, 8)
-- 
2.31.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] build: prereq: drop support for Python 3.5

2021-04-17 Thread Rosen Penev 
On Sat, Apr 17, 2021 at 2:49 PM Sven Roederer  wrote:
>
> Am Samstag, 17. April 2021, 16:45:01 CEST schrieb Sven Roederer:
> > On my Ubuntu 16.04 based build-system I also have build-failures for meson
> > using Python3.5.
>
> Correction: it's a 18.04 LTS ...
GCC6 is now minimum, breaking CentOS 7. That and the make version update.

I tried installing homebrew on CentOS7 but the build system prefers to
use the OS tools...

Speaking of homebrew, you could try that on Ubuntu.
>
> Sven
>
>
>
> ___
> 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] build: prereq: drop support for Python 3.5

2021-04-17 Thread Sven Roederer 
Am Samstag, 17. April 2021, 16:45:01 CEST schrieb Sven Roederer:
> On my Ubuntu 16.04 based build-system I also have build-failures for meson
> using Python3.5.

Correction: it's a 18.04 LTS ...

Sven



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] ramips: mt7621: HW-NAT typo fix

2021-04-17 Thread Daniel Golle 
On Sat, Apr 17, 2021 at 11:58:12AM -0700, Ilya Lipnitskiy wrote:
> On Fri, Apr 16, 2021 at 6:06 AM Daniel Golle  wrote:
> >
> > On Fri, Apr 16, 2021 at 03:44:06PM +0300, Lucian Cristian wrote:
> > > This fixes Hardware Offload on MT7621
> >
> > I have already applied the fix for it in pending-5.10:
> >
> > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=7f703716ae0e4cb4810eff37605b7594cef1edb8
> >
> > For the future, and to still give you review:
> > You shouldn't modify patches in backport-* as they represent commits in
> > linux.git and for sake of maintainability it's good to keep them
> > exactly as present in linux.git history so we can easily spot and
> > remove them once they trickly down into linux-stable).
> Not to nitpick, but if you mean torvalds/linux.git, then lots of
> patches in backport-5.10 are breaking this rule. For instance, all the
> recent mediatek offload work is still only in netdev/net-next.git, to
> be (hopefully) merged into torvalds/linux.git when the next merge
> window opens. Also, this particular fix has been submitted and will
> likely also be in net-next.git imminently:
> https://lore.kernel.org/linux-arm-kernel/20210417072905.207032-1-dqf...@gmail.com/.
> 
> In addition to that, I would like to submit another fix to OpenWrt
> that is already in net-next.git, but now I'm confused - do I put it in
> pending-5.10 or backports-5.10? Please advise.

If it already made it to net-next chances are 99% that it will be in
linux.git soon and then make it's way to linux-stable.
Hence I'd put the patch in backports-5.10.
Only stuff you grab from upstream lists/patchwork or submitted yourself
but hasn't been accepted yet should go into pending-5.10.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] ramips: mt7621: HW-NAT typo fix

2021-04-17 Thread Ilya Lipnitskiy 
On Fri, Apr 16, 2021 at 6:06 AM Daniel Golle  wrote:
>
> On Fri, Apr 16, 2021 at 03:44:06PM +0300, Lucian Cristian wrote:
> > This fixes Hardware Offload on MT7621
>
> I have already applied the fix for it in pending-5.10:
>
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=7f703716ae0e4cb4810eff37605b7594cef1edb8
>
> For the future, and to still give you review:
> You shouldn't modify patches in backport-* as they represent commits in
> linux.git and for sake of maintainability it's good to keep them
> exactly as present in linux.git history so we can easily spot and
> remove them once they trickly down into linux-stable).
Not to nitpick, but if you mean torvalds/linux.git, then lots of
patches in backport-5.10 are breaking this rule. For instance, all the
recent mediatek offload work is still only in netdev/net-next.git, to
be (hopefully) merged into torvalds/linux.git when the next merge
window opens. Also, this particular fix has been submitted and will
likely also be in net-next.git imminently:
https://lore.kernel.org/linux-arm-kernel/20210417072905.207032-1-dqf...@gmail.com/.

In addition to that, I would like to submit another fix to OpenWrt
that is already in net-next.git, but now I'm confused - do I put it in
pending-5.10 or backports-5.10? Please advise.

Ilya

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v2] netfilter: remove no-op kconfig symbols

2021-04-17 Thread Hauke Mehrtens 

On 4/9/21 5:48 PM, Rui Salvaterra wrote:

These have long been obsolete. For reference, here's the Linux version where
each symbol has been dropped:

CONFIG_IP6_NF_QUEUE - 3.5
CONFIG_IP6_NF_TARGET_LOG - 3.4
CONFIG_IP_NF_MATCH_DSCP - 2.6.19
CONFIG_NF_CONNTRACK_IPV4 - 4.19
CONFIG_NF_CONNTRACK_IPV6 - 4.19
CONFIG_NF_CONNTRACK_RTCACHE - OOT, superseded upstream by flow offloading

Signed-off-by: Rui Salvaterra 
---
v2: also removed CONFIG_NF_CONNTRACK_RTCACHE and two references to
CONFIG_NF_CONNTRACK_IPV4 in the WireGuard patches (the QEMU kconfigs).

  include/netfilter.mk| 6 --
  ...reguard-selftests-import-harness-makefile-for-test.patch | 3 +--
  ...reguard-selftests-check-that-route_me_harder-packe.patch | 3 +--
  target/linux/generic/config-5.10| 2 --
  target/linux/generic/config-5.4 | 2 --
  5 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/include/netfilter.mk b/include/netfilter.mk
index 45e9dadf85..803749d931 100644
--- a/include/netfilter.mk
+++ b/include/netfilter.mk
@@ -64,9 +64,7 @@ $(eval $(if $(NF_KMOD),,$(call 
nf_add,IPT_CORE,CONFIG_NETFILTER_XT_MARK, $(P_XT)
  
  # kernel only

  $(eval $(if $(NF_KMOD),$(call nf_add,NF_CONNTRACK,CONFIG_NF_CONNTRACK, 
$(P_XT)nf_conntrack),))
-$(eval $(if $(NF_KMOD),$(call nf_add,NF_CONNTRACK,CONFIG_NF_CONNTRACK_RTCACHE, 
$(P_XT)nf_conntrack_rtcache),))


This is still uses with a path on top of kernel 5.4 in OpenWrt.


  $(eval $(if $(NF_KMOD),$(call nf_add,NF_CONNTRACK,CONFIG_NF_DEFRAG_IPV4, 
$(P_V4)nf_defrag_ipv4),))
-$(eval $(if $(NF_KMOD),$(call nf_add,NF_CONNTRACK,CONFIG_NF_CONNTRACK_IPV4, 
$(P_V4)nf_conntrack_ipv4),))
  
  $(eval $(call nf_add,IPT_CONNTRACK,CONFIG_NETFILTER_XT_MATCH_STATE, $(P_XT)xt_state))

  $(eval $(call nf_add,IPT_CONNTRACK,CONFIG_NETFILTER_XT_TARGET_CT, 
$(P_XT)xt_CT))
@@ -120,7 +118,6 @@ $(eval $(call 
nf_add,IPT_IPOPT,CONFIG_NETFILTER_XT_MATCH_STATISTIC, $(P_XT)xt_st


.

  
  # ipv6 extra

diff --git 
a/target/linux/generic/backport-5.4/080-wireguard-0073-wireguard-selftests-import-harness-makefile-for-test.patch
 
b/target/linux/generic/backport-5.4/080-wireguard-0073-wireguard-selftests-import-harness-makefile-for-test.patch
index ca3853aa19..bc3d1edeb6 100644
--- 
a/target/linux/generic/backport-5.4/080-wireguard-0073-wireguard-selftests-import-harness-makefile-for-test.patch
+++ 
b/target/linux/generic/backport-5.4/080-wireguard-0073-wireguard-selftests-import-harness-makefile-for-test.patch
@@ -989,7 +989,7 @@ Signed-off-by: Jason A. Donenfeld 
  +}
  --- /dev/null
  +++ b/tools/testing/selftests/wireguard/qemu/kernel.config
-@@ -0,0 +1,86 @@
+@@ -0,0 +1,85 @@
  +CONFIG_LOCALVERSION=""
  +CONFIG_NET=y
  +CONFIG_NETDEVICES=y
@@ -1010,7 +1010,6 @@ Signed-off-by: Jason A. Donenfeld 
  +CONFIG_NETFILTER_XTABLES=y
  +CONFIG_NETFILTER_XT_NAT=y
  +CONFIG_NETFILTER_XT_MATCH_LENGTH=y
-+CONFIG_NF_CONNTRACK_IPV4=y


This is part of the original patch we backport, so it should stay here.


  +CONFIG_NF_NAT_IPV4=y
  +CONFIG_IP_NF_IPTABLES=y
  +CONFIG_IP_NF_FILTER=y


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] build: prereq: drop support for Python 3.5

2021-04-17 Thread Sven Roederer 
Hi,


Am Dienstag, 16. Februar 2021, 17:17:17 CEST schrieb Petr Štetiar:
> 
> > The meson build system bumped their python requirement to 3.6 for the
> > 0.57.0 release. This patch ensures that OpenWrt can update meson while
> > still relying on the host python.
> 
> Current buildbot images are based on Debian 9, which uses Python 3.5 so
> merging this would result in broken buildbots.
> 

On my Ubuntu 16.04 based build-system I also have build-failures for meson 
using Python3.5. They are triggered by the "mlog module" . Cherry-picking the 
recent meson updates into the packages feed fixing these errors, not sure if 
this is caused by the meson upgrade or the python-upgrade.

So it's indeed a tricky situation. But having the EOLed Python3.5 as minimum 
requirement for an upcoming release seems non optimal.

Sven



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 21.02] feeds: freifunk: use mirror from openwrt.org

2021-04-17 Thread Sven Roederer 
Am Sonntag, 21. Februar 2021, 20:13:40 CEST schrieb Petr Štetiar:

Hi,
> 
> > I have submitted two PR's to remove the freifunk feed from master and
> > openwrt-21.02.
> 
> thank you for the heads up, I'm just wondering why we should left
> openwrt-19.07[1] behind?
> 
> 1. https://git.openwrt.org/2a3dbded93775aeaf28fbebbd6aada07c9f588c1
> 

probably as removing inside a release-branch without real need has the 
potential to cause more trouble than  we will gain.

Sven



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] gemini: Bump to kernel v5.10

2021-04-17 Thread Christian Lamparter 

Hello,

On 15/04/2021 01:51, Linus Walleij wrote:

On Tue, Apr 13, 2021 at 11:37 PM Hauke Mehrtens  wrote:


The target kernel configurations should be small and most of the generic
settings should be done in the target/linux/generic/config-* config file.
The target configuration only contains the extra configuration options
or the options which are different.

(...)

You can add new generic options to target/linux/generic/config-5.10
manually.


OK I get it, I sent a slew of patches to the generic config.

We drive-by contributors just assume the generic config is
Perfect(TM) you know, now I realize I have to contribute to that
effort.



That was nicely worded... Yeah I know, there's no need for this.
In my case: That CoVID workload has bogged me down during the week.
I sometimes have a bit of spare-time on the weekends.

From what I can tell, the situation is: your gemini target would
be the first target that isn't "source-only" (which means it gets
skipped by the builderbots) that likes to fully switch to 5.10.
So you'll get all the fun of having to endure broken packages,
or have to come up with fixes for other stuff to make the buildbot
happy.

This might look overly cautions, but when I foolishly "merged" my
apm82181 testing 5.10 I broke other targets 5.10 support so bad
that the "fix patch" needed a second "fix patch". :(

And as you have seen even something as simple as a default for
a CONFIG_* SYMBOL can a show-stopper due deer-in-the-headlights
moments from crucial dependencies in different packages like musl...


For example do you really need CONFIG_OABI_COMPAT for gemini?

You should try to remove just most of the options which are not SoC
specific.


Yups I managed to diet out a bunch of stuff.



Do you have an update? I've queued your patch with "one weird trick"
(use KERNEL_TESTING_PATCHVER instead of KERNEL_PATCHVER).


Yes, this will cause the buildbot to still built your target with 5.4
but the 5.10 support will be there (behind CONFIG_TESTING_KERNEL).

Cheers,
Christian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel