Re: [OpenWrt-Devel] [PATCH 3/3] b53: create slave devices for ports
Seems this discussion has stalled a bit. I guess it would be reasonable to ask: what could I do to help to get this moving both here and on LKML ? I'll go ahead and say that I do not monitor LKML much since I haven't found a model (that suits me well) for monitoring discussions without getting my inbox too full. That also means I'm not up to date with general stuff, so if just get corrected (or updated) here, that would make me happy too. I've been reading up on this talk: http://thread.gmane.org/gmane.linux.network/351503 At the moment we're updating the b53-swconfig version internally, and I haven't managed to find the time to re-implement the changes from my initial patchset (which I submitted). If this gets accepted upstream, then I'd prefer to update it there. Normally I don't mind to implement stuff multiple times (b53 in swconfig, and then b53 in the kernel when that gets accepted) but my time constraints don't allow me now to be so flexible at this time. On Tue, Mar 10, 2015 at 2:24 PM, Jonas Gorski wrote: > On Sat, Feb 28, 2015 at 9:22 AM, Rafał Miłecki wrote: > > On 26 February 2015 at 19:24, Florian Fainelli > wrote: > >> On 25/02/15 07:24, Alexandru Ardelean wrote: > >>> Feature implemented and tested on BCM53128. > >>> > >>> Slave devices logic copied from the Linux kernel from Marvell's DSA > >>> driver ( linux/net/dsa/ ). > >>> Also the logic for the Broadcom tag processing has been copied from > there. > >> > >> There are different efforts here going on, and I would like to at least > >> 3 different people (you, Rafal and myself) can converge to an identical > >> solution that fits everybody here. > > > > I agree. I think we should focus on getting this cleared and accepted > > upstream. I don't think I want to keep adding features like port > > interfaces to swconfig. > > I agree with this, as it also has the potential of breaking switches > because of different header formats used. > > > Jonas > ___ > 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
[OpenWrt-Devel] [PATCH] musl: update to version 1.1.9
The fixes previously contained in 001-git-2015-03-28.patch are all part
of the upstream release, thus the patch can be removed.
All other patches apply cleanly.
Signed-off-by: Daniel Golle
---
toolchain/musl/Config.version | 2 +-
toolchain/musl/common.mk| 2 +-
toolchain/musl/patches/001-git-2015-03-28.patch | 93 -
3 files changed, 2 insertions(+), 95 deletions(-)
delete mode 100644 toolchain/musl/patches/001-git-2015-03-28.patch
diff --git a/toolchain/musl/Config.version b/toolchain/musl/Config.version
index 57b5bd0..c560c60 100644
--- a/toolchain/musl/Config.version
+++ b/toolchain/musl/Config.version
@@ -3,6 +3,6 @@ if USE_MUSL
config MUSL_VERSION
string
depends on USE_MUSL
- default "1.1.7"
+ default "1.1.9"
endif
diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk
index c67be2a..f4a34e4 100644
--- a/toolchain/musl/common.mk
+++ b/toolchain/musl/common.mk
@@ -11,7 +11,7 @@ PKG_NAME:=musl
PKG_VERSION:=$(call qstrip,$(CONFIG_MUSL_VERSION))
PKG_RELEASE=1
-PKG_MD5SUM:=6fe9fc4d99a7d321432b3e179c138d73
+PKG_MD5SUM:=14e8c5ac74f887d53256b3dcaf9b4aaa
PKG_SOURCE_URL:=http://www.musl-libc.org/releases
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
diff --git a/toolchain/musl/patches/001-git-2015-03-28.patch
b/toolchain/musl/patches/001-git-2015-03-28.patch
deleted file mode 100644
index 85f0441..000
--- a/toolchain/musl/patches/001-git-2015-03-28.patch
+++ /dev/null
@@ -1,93 +0,0 @@
-diff --git a/arch/aarch64/bits/alltypes.h.in b/arch/aarch64/bits/alltypes.h.in
-index 99f1654..d56abda 100644
a/arch/aarch64/bits/alltypes.h.in
-+++ b/arch/aarch64/bits/alltypes.h.in
-@@ -16,6 +16,8 @@ TYPEDEF unsigned int nlink_t;
- TYPEDEF float float_t;
- TYPEDEF double double_t;
-
-+TYPEDEF struct { long long __ll; long double __ld; } max_align_t;
-+
- TYPEDEF long time_t;
- TYPEDEF long suseconds_t;
-
-diff --git a/include/float.h b/include/float.h
-index c6429d3..713aadb 100644
a/include/float.h
-+++ b/include/float.h
-@@ -1,6 +1,10 @@
- #ifndef _FLOAT_H
- #define _FLOAT_H
-
-+#ifdef __cplusplus
-+extern "C" {
-+#endif
-+
- int __flt_rounds(void);
- #define FLT_ROUNDS (__flt_rounds())
-
-@@ -41,4 +45,8 @@ int __flt_rounds(void);
-
- #include
-
-+#ifdef __cplusplus
-+}
-+#endif
-+
- #endif
-diff --git a/src/network/inet_pton.c b/src/network/inet_pton.c
-index 4496b47..d36c368 100644
a/src/network/inet_pton.c
-+++ b/src/network/inet_pton.c
-@@ -39,14 +39,15 @@ int inet_pton(int af, const char *restrict s, void
*restrict a0)
- for (i=0; ; i++) {
- if (s[0]==':' && brk<0) {
- brk=i;
-- ip[i]=0;
-+ ip[i&7]=0;
- if (!*++s) break;
-+ if (i==7) return 0;
- continue;
- }
- for (v=j=0; j<4 && (d=hexval(s[j]))>=0; j++)
- v=16*v+d;
- if (j==0) return 0;
-- ip[i] = v;
-+ ip[i&7] = v;
- if (!s[j] && (brk>=0 || i==7)) break;
- if (i==7) return 0;
- if (s[j]!=':') {
-diff --git a/src/regex/regcomp.c b/src/regex/regcomp.c
-index 4cdaa1e..978dd87 100644
a/src/regex/regcomp.c
-+++ b/src/regex/regcomp.c
-@@ -839,7 +839,7 @@ static reg_errcode_t parse_atom(tre_parse_ctx_t *ctx,
const char *s)
- s--;
- break;
- default:
-- if (isdigit(*s)) {
-+ if (!ere && (unsigned)*s-'1' < 9) {
- /* back reference */
- int val = *s - '0';
- node = tre_ast_new_literal(ctx->mem, BACKREF,
val, ctx->position);
-@@ -847,7 +847,7 @@ static reg_errcode_t parse_atom(tre_parse_ctx_t *ctx,
const char *s)
- } else {
- /* extension: accept unknown escaped char
- as a literal */
-- node = tre_ast_new_literal(ctx->mem, *s, *s,
ctx->position);
-+ goto parse_literal;
- }
- ctx->position++;
- }
-@@ -1700,6 +1700,11 @@ tre_copy_ast(tre_mem_t mem, tre_stack_t *stack,
tre_ast_node_t *ast,
- *result = tre_ast_new_literal(mem, min, max, pos);
- if (*result == NULL)
- status = REG_ESPACE;
-+ else {
-+tre_literal_t *p = (*result)->obj;
-+p->class = lit->class;
-+p->neg_classes = lit->neg_classes;
-+ }
-
- if (pos > *max_pos)
- *max_pos = pos;
--
2.4.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] luci-proto-wwan minimal support
Or at least let us know how to apply the patch manually and I will add it into my unofficial builds that I make with the ar71xx platform. I'd love to see proper or even some sort of wwan support in the luci side of things. On 21/05/15 15:41, Cezary Jackiewicz wrote: Dnia 2015-04-22, o godz. 15:59:37 Aleksandr Kolesnik napisał(a): Signed-off-by: Aleksandr Kolesnik Hi, there is chance to to include this into 15.05? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [kernel] upstream fix: mount overlayfs r/o if workdir cannot be created
Am 19.05.2015 um 16:17 schrieb Bastian Bittorf: +diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c +index 5f0d199..bf8537c 100644 +--- a/fs/overlayfs/super.c b/fs/overlayfs/super.c +@@ -529,7 +529,7 @@ static int ovl_remount(struct super_block *sb, int *flags, char *data) this function was added with linux 4.0, so your patch for 3.18 does not apply. Can you give me a hint to make it work with 3.18? Best Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [kernel] upstream fix: mount overlayfs r/o if workdir cannot be created
* Christian Mehlis [21.05.2015 12:49]: > >+--- a/fs/overlayfs/super.c > > b/fs/overlayfs/super.c > >+@@ -529,7 +529,7 @@ static int ovl_remount(struct super_block *sb, int > >*flags, char *data) > > this function was added with linux 4.0, so your patch for 3.18 does > not apply. > > Can you give me a hint to make it work with 3.18? i will investigate - it applied locally here with 3.18 - will check why... bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc1
Hello Steven, Steven Barth wrote on 2015-05-20: > The OpenWrt developers are proud to announce the first release candidate > of OpenWrt Chaos Calmer. > - > http://downloads.openwrt.org/chaos_calmer/15.05-rc1/ I checked the downloads, e.g here http://downloads.openwrt.org/chaos_calmer/15.05-rc1/lantiq/xrx200/ and saw that only one image per subtarget is built. As the image-creation is tied to the profiles, the buildbot probably need to build for each profile. John: Do you know if it is possible to add a "generic" profile to build all images in one run? Or why it is necessary to select a specific model for the build? > ** Highlights since Barrier Breaker ** > > * Linux kernel updated to version 3.18 > * Improved Security Features > - Rewritten package signing architecture based on ed25519 > - Added support for jails > - Added support for hardened builds > * Improved Networking Support > - Added or improved support for lots of 3G/4G modems (MBIM, QMI, > NCM, ...) > - Added support for 464XLAT (CLAT) > - Improved support for self-managing networks (draft-ietf-homenet-hncp) > - Netfilter performance enhancements (conntrack route cache) > - Better multi-core support for the network stack > - Improved support for MAP-E and MAP-T IPv4 transitioning technologies > - Improved network auto-setup capable of detecting and bootstrapping > IPv4-only, > 6rd, Dual-Stack, IPv6-only, DS-Lite, LW4over6, MAP-E, MAP-T, 464XLAT > and combinations without explicit configuration > - Added support for Smart Queue Management (SQM) QoS, AQM and > Traffic Shaping > - Improved support for DNSSEC > * Platform and Driver Support > - Added support for feeds of externally maintained targets > - New mt7621 subtarget for Mediatek 11ac SoC > - New mt76 mac80211 based wifi driver for MTK 11ac cores. > - New mwlwifi mac80211 based wifi driver for the Marvell 88W8864 > - New bcm53xx target for Broadcom ARM BCM47xx/53xx devices > - brcm2708: support for Raspberry Pi 2 > - brcm63xx: support for BCM6318 and BCM63268 family > - brcm63xx: improved fallback sprom support with bcma support > > * Known Issues > - libusb-1.0 is currently not installable (#19668). This is already > fixed in svn. This can be > manually fixed by applying the changes from r45702 by hand. > - the targets feed is part of opkg.conf, and will produce warnings. > It is save to remove > from /etc/opkg.conf. > Again a really nice list of new features! Best Regards, Thomas --- There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors. --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] working with quilt from './staging_dir/host/bin/quilt'
on my buildserver i cannot install packages and
must use e.g. './staging_dir/host/bin/quilt'.
but quilt does not start with:
make target/linux/{clean,prepare} V=s QUILT=1
bastian@gcc20:~/openwrt$ which quilt || echo missing
missing
bastian@gcc20:~/openwrt$ ./staging_dir/host/bin/quilt --version
0.63
is this possible or is admin-interaction needed on my site?
bye, bastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] working with quilt from './staging_dir/host/bin/quilt'
Hi. Did you try something like export PATH="$PATH:/home/bastian/openwrt/staging_dir/host/bin" ? If that works you could add it to your .bashrc ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc1
Hi Thomas, On Thu, May 21, 2015 at 12:37:35PM +, thomas.lan...@lantiq.com wrote: > I checked the downloads, e.g here > http://downloads.openwrt.org/chaos_calmer/15.05-rc1/lantiq/xrx200/ > and saw that only one image per subtarget is built. > As the image-creation is tied to the profiles, the buildbot probably need to > build for each profile. > > John: Do you know if it is possible to add a "generic" profile to build all > images in one run? > Or why it is necessary to select a specific model for the build? Having a generic profile was not intended in the way image creation was previously implemented. This is a known problem on all device-tree-based targets and the reason for framework changes which would by now allow doing this properly. Targets will have to pick-up the new image building code Felix introduced in r43907 (which was improved a lot since and was already used to replace the old approach for quite some boards) However, having it implemented for all boards in 15.05 is not realistic imho. Thus the final build will hopefully run for each profile. (John, Kaloz: will it?) Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] working with quilt from './staging_dir/host/bin/quilt'
* Jo-Philipp Wich [21.05.2015 15:18]: > Did you try something like > export PATH="$PATH:/home/bastian/openwrt/staging_dir/host/bin" ? meanwhile yes, but it does not work like i exspected. should'nt quilt open, when a patch cannot be applied cleanly? bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [kernel] upstream fix: mount overlayfs r/o if workdir cannot be created
* Christian Mehlis [21.05.2015 12:49]:
> Can you give me a hint to make it work with 3.18?
can you please try to apply the appended patch with
git am <$file
make target/linux/clean
make
bye, bastian
>From f5d917da8665f1a3c79e5beb34acea7daf019ff5 Mon Sep 17 00:00:00 2001
From: Bastian Bittorf
Date: Thu, 21 May 2015 13:55:00 +0200
Subject: [PATCH] [kernel] upstream fix: mount overlayfs r/o if workdir cannot be created
see: https://www.mail-archive.com/linux-unionfs@vger.kernel.org/msg00246.html
runtime tested on ar71xx with kernel 3.18.11 and r45705
this paritially fixes #19564
Signed-off-by: Bastian Bittorf
---
...-overlayfs-fallback-to-readonly-when-full.patch | 109
1 file changed, 109 insertions(+)
create mode 100644 target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch
diff --git a/target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch b/target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch
new file mode 100644
index 000..3433cbc
--- /dev/null
+++ b/target/linux/ar71xx/patches-3.18/910-overlayfs-fallback-to-readonly-when-full.patch
@@ -0,0 +1,109 @@
+[linux-unionfs added to Cc]
+
+On Tue, May 19, 2015 at 09:51:20AM +0200, Bastian Bittorf wrote:
+> Hi Miklos,
+>
+> sorry for writing directly to you, feel free to forward
+> this to the appropriate mailinglist.
+>
+> we have a problem with mainline overlay filesystem on kernel 3.18:
+> https://dev.openwrt.org/ticket/19564
+>
+> 2 things are odd:
+> when the working filesystem is full, overlays fails with:
+>
+> overlayfs: failed to create directory /overlay/work/work
+>
+> what is strange, that we call it with:
+>
+> mount(overlay, "/mnt", "overlay", MS_NOATIME, lowerdir)
+>
+> see here:
+> http://nbd.name/gitweb.cgi?p=fstools.git;a=blob;f=libfstools/mount.c;h=81176ce399b4cd8e2d347c0008c13dec92407f55;hb=e6004000ff15d7bd32cf5663e8690fc94d7ec747#l125
+>
+> do you have an idea whats wrong?
+> 1) is it really needed, that we need space for creating dir "/overlay/work"?
+> 2) why does overlay need "/overlay/work/work"?
+
+The work directory is needed for atomic copy-up and similar. It is not actually
+necessary to mount a read-only overlay. Post 4.0 it is possible to mount the
+overlay without workdir (but even then it won't happen automatically in case the
+upper fs is full, so this should be fixed in the latest kernel too).
+
+Could you please try the following patch? If the workdir can't be created it
+will fall back to mounting the overlay read-only.
+
+Thanks,
+Miklos
+
+---
+ fs/overlayfs/copy_up.c |3 +++
+ fs/overlayfs/dir.c |9 +
+ fs/overlayfs/super.c | 12 +---
+ 3 files changed, 21 insertions(+), 3 deletions(-)
+
+--- a/fs/overlayfs/copy_up.c
b/fs/overlayfs/copy_up.c
+@@ -300,6 +300,9 @@ int ovl_copy_up_one(struct dentry *paren
+ struct cred *override_cred;
+ char *link = NULL;
+
++ if (WARN_ON(!workdir))
++ return -EROFS;
++
+ ovl_path_upper(parent, &parentpath);
+ upperdir = parentpath.dentry;
+
+--- a/fs/overlayfs/dir.c
b/fs/overlayfs/dir.c
+@@ -222,6 +222,9 @@ static struct dentry *ovl_clear_empty(st
+ struct kstat stat;
+ int err;
+
++ if (WARN_ON(!workdir))
++ return ERR_PTR(-EROFS);
++
+ err = ovl_lock_rename_workdir(workdir, upperdir);
+ if (err)
+ goto out;
+@@ -322,6 +325,9 @@ static int ovl_create_over_whiteout(stru
+ struct dentry *newdentry;
+ int err;
+
++ if (WARN_ON(!workdir))
++ return -EROFS;
++
+ err = ovl_lock_rename_workdir(workdir, upperdir);
+ if (err)
+ goto out;
+@@ -506,6 +512,9 @@ static int ovl_remove_and_whiteout(struc
+ struct dentry *opaquedir = NULL;
+ int err;
+
++ if (WARN_ON(!workdir))
++ return -EROFS;
++
+ if (is_dir) {
+ opaquedir = ovl_check_empty_and_clear(dentry);
+ err = PTR_ERR(opaquedir);
+--- a/fs/overlayfs/super.c
b/fs/overlayfs/super.c
+@@ -740,9 +740,15 @@ static int ovl_fill_super(struct super_b
+ ufs->workdir = ovl_workdir_create(ufs->upper_mnt, workpath.dentry);
+ err = PTR_ERR(ufs->workdir);
+ if (IS_ERR(ufs->workdir)) {
+- pr_err("overlayfs: failed to create directory %s/%s\n",
+- ufs->config.workdir, OVL_WORKDIR_NAME);
+- goto out_put_lower_mnt;
++ if (err == -ENOSPC || err == -EROFS) {
++ pr_warning("overlayfs: failed to work directory (%s), mounting read-only\n", err == ENOSPC ? "ENOSPC" : "EROFS");
++ sb->s_flags |= MS_RDONLY;
++ ufs->workdir = NULL;
++ } else {
++ pr_err("overlayfs: failed to create directory %s/%s\n",
++ ufs->config.workdir, OVL_WORKDIR_NAME);
++ goto out_put_lower_mnt;
++ }
+ }
+
+ /*
--
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] working with quilt from './staging_dir/host/bin/quilt'
Hi. > meanwhile yes, but it does not work like i exspected. > should'nt quilt open, when a patch cannot be applied cleanly? Uhm no. At least I never encountered such behavior. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWrt and TDD
Hi all, I'm a big fan of OpenWrt and now I just started my studies of TDD. I'm facing some difficulties with TDD in the embedded world and I was wondering if or how OpenWrt developer use TDD and which CI (Continuous Integration) system is applied to OpenWrt builds. Any information (libs or framework used, how every test case could be done using the OpenWrt Makefiles scheme, etc) would be appreciated. Thanks in advance -- Ronaldo Afonso 11 9 5252 0484 www.ronaldoafonso.com.br ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc1
Steven Barth wrote: > - Added support for 464XLAT (CLAT) Is this signaled in some way by DHCPv6? If so, I imagine that there is an RFC# which says how it works, could be listed here, so that google will find CC when people look for it... I actually think that this is a terribly important feature set. Thank you for all the work! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] working with quilt from './staging_dir/host/bin/quilt'
* Jo-Philipp Wich [21.05.2015 20:50]:
> > meanwhile yes, but it does not work like i exspected.
> > should'nt quilt open, when a patch cannot be applied cleanly?
>
> Uhm no. At least I never encountered such behavior.
ok, lets say i have copied a patch into the kernel-patches folder
which cannot be applied cleanly. what is the workflow for e.g.
rebasing or automerging and changing the patch to be (line-)correct.
my idea was to use this:
make target/linux/{clean,prepare} V=s QUILT=1
but at least it seems not to be the way
thanks in advance - bye, bastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc1
Michael Richardson writes: > Steven Barth wrote: > > - Added support for 464XLAT (CLAT) > > Is this signaled in some way by DHCPv6? > If so, I imagine that there is an RFC# which says how it works, could be > listed here, so that google will find CC when people look for it... The original spec suggests using heuristic to discover the PLAT side translation prefix. See https://tools.ietf.org/html/rfc6877 There is a draft defining a new DHCPv6 option for it, but this is not yet an RFC: https://tools.ietf.org/html/draft-cui-intarea-464xlat-prefix-dhcp-00 Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] working with quilt from './staging_dir/host/bin/quilt'
> my idea was to use this:
> make target/linux/{clean,prepare} V=s QUILT=1
If the patches all apply despite fuzz:
make target/linux/refresh
If they do not apply:
make target/linux/{clean,prepare} V=s QUILT=1
cd build_dir/target-*/linux-*/linux-*
quilt push -a (will halt before the failing patch)
quilt push -f (will forcibly put the broken patch on top of the stack)
quilt edit ... (fixup the broken patch by editing to-be-patched files)
quilt refresh (will fixup broken patch)
quilt push -a (will apply remainder of the series)
cd ../../../../
make target/linux/update (copies current series back)
make target/linux/refresh (rebases all patches in case the new one
produced fuzz in subsequent ones)
~ Jow
signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
