Hi all,
I've uploaded today's linux-next tree to the master branch of the
repository below:
git://gitorious.org/thierryreding/linux-next.git
A next-20131015 tag is also provided for convenience.
Gained a new conflict, but nothing too exciting. x86 and ARM default
configurations build fine. I've also used an x86 allmodconfig build to
check for build errors. Mark fixed most of those in the trees that he
created last Thursday and Friday, so I've cherry-picked them on top of
the final merge. There was one new build failure in the staging tree
that was trivial to fix so I added a patch to the tree as well.
Thierry
Add a missing , between parameters in a call to dev_info().
Signed-off-by: Thierry Reding <[email protected]>
---
drivers/staging/media/lirc/lirc_imon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/lirc/lirc_imon.c b/drivers/staging/media/lirc/lirc_imon.c
index 8180187..91c3e2d 100644
--- a/drivers/staging/media/lirc/lirc_imon.c
+++ b/drivers/staging/media/lirc/lirc_imon.c
@@ -925,7 +925,7 @@ static int imon_probe(struct usb_interface *interface,
if (usb_register_dev(interface, &imon_class)) {
/* Not a fatal error, so ignore */
dev_info(dev,
- "%s: could not get a minor number for display\n"
+ "%s: could not get a minor number for display\n",
__func__);
}
}
--
1.8.4
Today's linux-next merge of the trivial tree got conflicts in
net/netfilter/xt_set.c
caused by commits 3f79410 (treewide: Fix common typo in "identify") and
bd3129f (netfilter: ipset: order matches and targets separatedly in
xt_set.c).
I fixed them up (see below). Please verify that the resolution looks
good.
Thanks,
Thierry
---
diff --cc net/netfilter/xt_set.c
index e7c4e0e,4b9d6b4..80c2e2d
--- a/net/netfilter/xt_set.c
+++ b/net/netfilter/xt_set.c
@@@ -81,10 -81,10 +81,10 @@@ set_match_v0_checkentry(const struct xt
struct xt_set_info_match_v0 *info = par->matchinfo;
ip_set_id_t index;
- index = ip_set_nfnl_get_byindex(info->match_set.index);
+ index = ip_set_nfnl_get_byindex(par->net, info->match_set.index);
if (index == IPSET_INVALID_ID) {
- pr_warning("Cannot find set indentified by id %u to match\n",
+ pr_warning("Cannot find set identified by id %u to match\n",
info->match_set.index);
return -ENOENT;
}
@@@ -106,104 -106,9 +106,104 @@@ set_match_v0_destroy(const struct xt_mt
{
struct xt_set_info_match_v0 *info = par->matchinfo;
- ip_set_nfnl_put(info->match_set.index);
+ ip_set_nfnl_put(par->net, info->match_set.index);
}
+/* Revision 1 match */
+
+static bool
+set_match_v1(const struct sk_buff *skb, struct xt_action_param *par)
+{
+ const struct xt_set_info_match_v1 *info = par->matchinfo;
+ ADT_OPT(opt, par->family, info->match_set.dim,
+ info->match_set.flags, 0, UINT_MAX);
+
+ if (opt.flags & IPSET_RETURN_NOMATCH)
+ opt.cmdflags |= IPSET_FLAG_RETURN_NOMATCH;
+
+ return match_set(info->match_set.index, skb, par, &opt,
+ info->match_set.flags & IPSET_INV_MATCH);
+}
+
+static int
+set_match_v1_checkentry(const struct xt_mtchk_param *par)
+{
+ struct xt_set_info_match_v1 *info = par->matchinfo;
+ ip_set_id_t index;
+
+ index = ip_set_nfnl_get_byindex(par->net, info->match_set.index);
+
+ if (index == IPSET_INVALID_ID) {
- pr_warning("Cannot find set indentified by id %u to match\n",
++ pr_warning("Cannot find set identified by id %u to match\n",
+ info->match_set.index);
+ return -ENOENT;
+ }
+ if (info->match_set.dim > IPSET_DIM_MAX) {
+ pr_warning("Protocol error: set match dimension "
+ "is over the limit!\n");
+ ip_set_nfnl_put(par->net, info->match_set.index);
+ return -ERANGE;
+ }
+
+ return 0;
+}
+
+static void
+set_match_v1_destroy(const struct xt_mtdtor_param *par)
+{
+ struct xt_set_info_match_v1 *info = par->matchinfo;
+
+ ip_set_nfnl_put(par->net, info->match_set.index);
+}
+
+/* Revision 3 match */
+
+static bool
+match_counter(u64 counter, const struct ip_set_counter_match *info)
+{
+ switch (info->op) {
+ case IPSET_COUNTER_NONE:
+ return true;
+ case IPSET_COUNTER_EQ:
+ return counter == info->value;
+ case IPSET_COUNTER_NE:
+ return counter != info->value;
+ case IPSET_COUNTER_LT:
+ return counter < info->value;
+ case IPSET_COUNTER_GT:
+ return counter > info->value;
+ }
+ return false;
+}
+
+static bool
+set_match_v3(const struct sk_buff *skb, struct xt_action_param *par)
+{
+ const struct xt_set_info_match_v3 *info = par->matchinfo;
+ ADT_OPT(opt, par->family, info->match_set.dim,
+ info->match_set.flags, info->flags, UINT_MAX);
+ int ret;
+
+ if (info->packets.op != IPSET_COUNTER_NONE ||
+ info->bytes.op != IPSET_COUNTER_NONE)
+ opt.cmdflags |= IPSET_FLAG_MATCH_COUNTERS;
+
+ ret = match_set(info->match_set.index, skb, par, &opt,
+ info->match_set.flags & IPSET_INV_MATCH);
+
+ if (!(ret && opt.cmdflags & IPSET_FLAG_MATCH_COUNTERS))
+ return ret;
+
+ if (!match_counter(opt.ext.packets, &info->packets))
+ return 0;
+ return match_counter(opt.ext.bytes, &info->bytes);
+}
+
+#define set_match_v3_checkentry set_match_v1_checkentry
+#define set_match_v3_destroy set_match_v1_destroy
+
+/* Revision 0 interface: backward compatible with netfilter/iptables */
+
static unsigned int
set_target_v0(struct sk_buff *skb, const struct xt_action_param *par)
{
On 10/15/13 07:02, Thierry Reding wrote:
> Hi all,
>
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
>
> git://gitorious.org/thierryreding/linux-next.git
>
> A next-20131015 tag is also provided for convenience.
>
> Gained a new conflict, but nothing too exciting. x86 and ARM default
> configurations build fine. I've also used an x86 allmodconfig build to
> check for build errors. Mark fixed most of those in the trees that he
> created last Thursday and Friday, so I've cherry-picked them on top of
> the final merge. There was one new build failure in the staging tree
> that was trivial to fix so I added a patch to the tree as well.
on x86_64:
drivers/usb/gadget/f_mass_storage.c: In function 'fsg_main_thread':
drivers/usb/gadget/f_mass_storage.c:2509:2: error: implicit declaration of function 'set_fs' [-Werror=implicit-function-declaration]
drivers/usb/gadget/f_mass_storage.c:2509:2: error: implicit declaration of function 'get_ds' [-Werror=implicit-function-declaration]
(needs #include <linux/uaccess.h>)
and
when CONFIG_BLOCK is not enabled:
drivers/usb/gadget/storage_common.c: In function 'fsg_lun_open':
drivers/usb/gadget/storage_common.c:241:3: error: implicit declaration of function 'bdev_logical_block_size' [-Werror=implicit-function-declaration]
drivers/usb/gadget/storage_common.c:242:3: error: implicit declaration of function 'blksize_bits' [-Werror=implicit-function-declaration]
Full randconfig file is attached.
--
~Randy
On 10/15/13 07:02, Thierry Reding wrote:
> Hi all,
>
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
>
> git://gitorious.org/thierryreding/linux-next.git
>
> A next-20131015 tag is also provided for convenience.
on x86_64:
crypto/asymmetric_keys/x509_public_key.c: In function 'x509_key_preparse':
crypto/asymmetric_keys/x509_public_key.c:237:35: error: 'system_trusted_keyring' undeclared (first use in this function)
when CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=m
and CONFIG_SYSTEM_TRUSTED_KEYRING is not set.
Full randconfig file is attached.
--
~Randy
On 10/15/2013 07:02 AM, Thierry Reding wrote:
> Hi all,
>
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
>
> git://gitorious.org/thierryreding/linux-next.git
>
> A next-20131015 tag is also provided for convenience.
>
> Gained a new conflict, but nothing too exciting. x86 and ARM default
> configurations build fine. I've also used an x86 allmodconfig build to
> check for build errors. Mark fixed most of those in the trees that he
> created last Thursday and Friday, so I've cherry-picked them on top of
> the final merge. There was one new build failure in the staging tree
> that was trivial to fix so I added a patch to the tree as well.
>
This build does look much better than the previous ones. I 'only' get 12 build failures
out of 106 configurations. Worst are powerpc builds, with 7 out of 14 builds failed.
Details are at http://server.roeck-us.net:8010/builders; look for the 'next' column.
Guenter
On Tue, Oct 15, 2013 at 04:02:43PM +0200, Thierry Reding wrote:
> Add a missing , between parameters in a call to dev_info().
>
Greg already reverted the original patch.
The original patch wasn't sent to the list. Archana, use
scripts/get_maintainer.pl to find out who to send patches to. Don't
CC the linux-kernel list though because they don't care about details in
staging.
regards,
dan carpenter
On Tue, 15 Oct 2013, Thierry Reding wrote:
> Today's linux-next merge of the trivial tree got conflicts in
>
> net/netfilter/xt_set.c
>
> caused by commits 3f79410 (treewide: Fix common typo in "identify") and
> bd3129f (netfilter: ipset: order matches and targets separatedly in
> xt_set.c).
>
> I fixed them up (see below). Please verify that the resolution looks
> good.
I don't really get it: patch bd3129f was part of a patchset, which was
applied to net-next and there it was complete.
There's none of the patchset in question in linux-next, so what's the
trivial tree? Where's lost what?
[The patch below doesn't look good, because it should contain the removed
part for the revision 1 match due to the reordering in the file.]
Best regards,
Jozsef
> ---
> diff --cc net/netfilter/xt_set.c
> index e7c4e0e,4b9d6b4..80c2e2d
> --- a/net/netfilter/xt_set.c
> +++ b/net/netfilter/xt_set.c
> @@@ -81,10 -81,10 +81,10 @@@ set_match_v0_checkentry(const struct xt
> struct xt_set_info_match_v0 *info = par->matchinfo;
> ip_set_id_t index;
>
> - index = ip_set_nfnl_get_byindex(info->match_set.index);
> + index = ip_set_nfnl_get_byindex(par->net, info->match_set.index);
>
> if (index == IPSET_INVALID_ID) {
> - pr_warning("Cannot find set indentified by id %u to match\n",
> + pr_warning("Cannot find set identified by id %u to match\n",
> info->match_set.index);
> return -ENOENT;
> }
> @@@ -106,104 -106,9 +106,104 @@@ set_match_v0_destroy(const struct xt_mt
> {
> struct xt_set_info_match_v0 *info = par->matchinfo;
>
> - ip_set_nfnl_put(info->match_set.index);
> + ip_set_nfnl_put(par->net, info->match_set.index);
> }
>
> +/* Revision 1 match */
> +
> +static bool
> +set_match_v1(const struct sk_buff *skb, struct xt_action_param *par)
> +{
> + const struct xt_set_info_match_v1 *info = par->matchinfo;
> + ADT_OPT(opt, par->family, info->match_set.dim,
> + info->match_set.flags, 0, UINT_MAX);
> +
> + if (opt.flags & IPSET_RETURN_NOMATCH)
> + opt.cmdflags |= IPSET_FLAG_RETURN_NOMATCH;
> +
> + return match_set(info->match_set.index, skb, par, &opt,
> + info->match_set.flags & IPSET_INV_MATCH);
> +}
> +
> +static int
> +set_match_v1_checkentry(const struct xt_mtchk_param *par)
> +{
> + struct xt_set_info_match_v1 *info = par->matchinfo;
> + ip_set_id_t index;
> +
> + index = ip_set_nfnl_get_byindex(par->net, info->match_set.index);
> +
> + if (index == IPSET_INVALID_ID) {
> - pr_warning("Cannot find set indentified by id %u to match\n",
> ++ pr_warning("Cannot find set identified by id %u to match\n",
> + info->match_set.index);
> + return -ENOENT;
> + }
> + if (info->match_set.dim > IPSET_DIM_MAX) {
> + pr_warning("Protocol error: set match dimension "
> + "is over the limit!\n");
> + ip_set_nfnl_put(par->net, info->match_set.index);
> + return -ERANGE;
> + }
> +
> + return 0;
> +}
> +
> +static void
> +set_match_v1_destroy(const struct xt_mtdtor_param *par)
> +{
> + struct xt_set_info_match_v1 *info = par->matchinfo;
> +
> + ip_set_nfnl_put(par->net, info->match_set.index);
> +}
> +
> +/* Revision 3 match */
> +
> +static bool
> +match_counter(u64 counter, const struct ip_set_counter_match *info)
> +{
> + switch (info->op) {
> + case IPSET_COUNTER_NONE:
> + return true;
> + case IPSET_COUNTER_EQ:
> + return counter == info->value;
> + case IPSET_COUNTER_NE:
> + return counter != info->value;
> + case IPSET_COUNTER_LT:
> + return counter < info->value;
> + case IPSET_COUNTER_GT:
> + return counter > info->value;
> + }
> + return false;
> +}
> +
> +static bool
> +set_match_v3(const struct sk_buff *skb, struct xt_action_param *par)
> +{
> + const struct xt_set_info_match_v3 *info = par->matchinfo;
> + ADT_OPT(opt, par->family, info->match_set.dim,
> + info->match_set.flags, info->flags, UINT_MAX);
> + int ret;
> +
> + if (info->packets.op != IPSET_COUNTER_NONE ||
> + info->bytes.op != IPSET_COUNTER_NONE)
> + opt.cmdflags |= IPSET_FLAG_MATCH_COUNTERS;
> +
> + ret = match_set(info->match_set.index, skb, par, &opt,
> + info->match_set.flags & IPSET_INV_MATCH);
> +
> + if (!(ret && opt.cmdflags & IPSET_FLAG_MATCH_COUNTERS))
> + return ret;
> +
> + if (!match_counter(opt.ext.packets, &info->packets))
> + return 0;
> + return match_counter(opt.ext.bytes, &info->bytes);
> +}
> +
> +#define set_match_v3_checkentry set_match_v1_checkentry
> +#define set_match_v3_destroy set_match_v1_destroy
> +
> +/* Revision 0 interface: backward compatible with netfilter/iptables */
> +
> static unsigned int
> set_target_v0(struct sk_buff *skb, const struct xt_action_param *par)
> {
>
-
E-mail : [email protected], [email protected]
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
On Wed, 16 Oct 2013, Jozsef Kadlecsik wrote:
> > Today's linux-next merge of the trivial tree got conflicts in
> >
> > net/netfilter/xt_set.c
> >
> > caused by commits 3f79410 (treewide: Fix common typo in "identify") and
> > bd3129f (netfilter: ipset: order matches and targets separatedly in
> > xt_set.c).
> >
> > I fixed them up (see below). Please verify that the resolution looks
> > good.
>
> I don't really get it: patch bd3129f was part of a patchset, which was
> applied to net-next and there it was complete.
>
> There's none of the patchset in question in linux-next, so what's the
> trivial tree? Where's lost what?
>
> [The patch below doesn't look good, because it should contain the removed
> part for the revision 1 match due to the reordering in the file.]
This is just a super-simple conflict between
https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=bd3129f
and
https://git.kernel.org/cgit/linux/kernel/git/jikos/trivial.git/diff/net/netfilter/xt_set.c?h=for-next&id=3f79410c7c
I don't think it needs any special handling, do you? I can of course drop
the respective hunk from my tree and let you handle it in net-next if you
wish.
Thanks,
--
Jiri Kosina
SUSE Labs
On Wed, Oct 16, 2013 at 10:03:40AM +0300, Dan Carpenter wrote:
> On Tue, Oct 15, 2013 at 04:02:43PM +0200, Thierry Reding wrote:
> > Add a missing , between parameters in a call to dev_info().
> >
>
> Greg already reverted the original patch.
>
> The original patch wasn't sent to the list. Archana, use
> scripts/get_maintainer.pl to find out who to send patches to. Don't
> CC the linux-kernel list though because they don't care about details in
> staging.
Archana sent it through the OPW submission process, which has it's own
mailing list, so as to not bother the driverdev mailing list. It was
my fault that I missed this error and took the patch, which is why I
reverted it.
thanks,
greg k-h
On Wed, Oct 16, 2013 at 11:20:04AM +0200, Jiri Kosina wrote:
> On Wed, 16 Oct 2013, Jozsef Kadlecsik wrote:
>
> > > Today's linux-next merge of the trivial tree got conflicts in
> > >
> > > net/netfilter/xt_set.c
> > >
> > > caused by commits 3f79410 (treewide: Fix common typo in "identify") and
> > > bd3129f (netfilter: ipset: order matches and targets separatedly in
> > > xt_set.c).
> > >
> > > I fixed them up (see below). Please verify that the resolution looks
> > > good.
> >
> > I don't really get it: patch bd3129f was part of a patchset, which was
> > applied to net-next and there it was complete.
> >
> > There's none of the patchset in question in linux-next, so what's the
> > trivial tree? Where's lost what?
To Jozsef: David collects all the networking patches in net-next until
Linus' merge window opens, that's why you don't see your patches in
linux-next. It seems Jiri merges this trivial tree (which indeed
contains your net-next patches already) to linux-next.
> > [The patch below doesn't look good, because it should contain the removed
> > part for the revision 1 match due to the reordering in the file.]
>
> This is just a super-simple conflict between
>
> https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=bd3129f
>
> and
>
> https://git.kernel.org/cgit/linux/kernel/git/jikos/trivial.git/diff/net/netfilter/xt_set.c?h=for-next&id=3f79410c7c
>
> I don't think it needs any special handling, do you? I can of course drop
> the respective hunk from my tree and let you handle it in net-next if you
> wish.
Please, don't drop it, I think Jozsef got confused by the handling of
your trivial tree.
On Tue, Oct 15, 2013 at 10:21:27PM -0700, Guenter Roeck wrote:
> On 10/15/2013 07:02 AM, Thierry Reding wrote:
> >Hi all,
> >
> >I've uploaded today's linux-next tree to the master branch of the
> >repository below:
> >
> > git://gitorious.org/thierryreding/linux-next.git
> >
> >A next-20131015 tag is also provided for convenience.
> >
> >Gained a new conflict, but nothing too exciting. x86 and ARM default
> >configurations build fine. I've also used an x86 allmodconfig build to
> >check for build errors. Mark fixed most of those in the trees that he
> >created last Thursday and Friday, so I've cherry-picked them on top of
> >the final merge. There was one new build failure in the staging tree
> >that was trivial to fix so I added a patch to the tree as well.
> >
>
> This build does look much better than the previous ones. I 'only' get 12 build failures
> out of 106 configurations.
Thanks for running these!
> Worst are powerpc builds, with 7 out of 14 builds failed.
Yes, I'm seeing those too. I used to carry a fix for many of these in
earlier linux-next trees but since I haven't had the time to run the
PowerPC builds in a while I haven't cherry-picked it to new trees.
If you want to give it a try with those fixes, here's the commit from
next-20131009, which seems to be the last one to have it:
5a7a5211555a68a3144aa35015684e3a156cb11f powerpc: Fix various build failures
I'll see if I can make some time available to add these in the next
days.
Thierry
On Tue, Oct 15, 2013 at 03:43:07PM -0700, Randy Dunlap wrote:
> On 10/15/13 07:02, Thierry Reding wrote:
> > Hi all,
> >
> > I've uploaded today's linux-next tree to the master branch of the
> > repository below:
> >
> > git://gitorious.org/thierryreding/linux-next.git
> >
> > A next-20131015 tag is also provided for convenience.
>
> on x86_64:
>
> crypto/asymmetric_keys/x509_public_key.c: In function 'x509_key_preparse':
> crypto/asymmetric_keys/x509_public_key.c:237:35: error: 'system_trusted_keyring' undeclared (first use in this function)
>
> when CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=m
> and CONFIG_SYSTEM_TRUSTED_KEYRING is not set.
>
>
> Full randconfig file is attached.
Thanks for catching these Randy!
Thierry
On Wed, Oct 16, 2013 at 05:50:56PM +0200, Thierry Reding wrote:
> On Tue, Oct 15, 2013 at 10:21:27PM -0700, Guenter Roeck wrote:
> > On 10/15/2013 07:02 AM, Thierry Reding wrote:
> > >Hi all,
> > >
> > >I've uploaded today's linux-next tree to the master branch of the
> > >repository below:
> > >
> > > git://gitorious.org/thierryreding/linux-next.git
> > >
> > >A next-20131015 tag is also provided for convenience.
> > >
> > >Gained a new conflict, but nothing too exciting. x86 and ARM default
> > >configurations build fine. I've also used an x86 allmodconfig build to
> > >check for build errors. Mark fixed most of those in the trees that he
> > >created last Thursday and Friday, so I've cherry-picked them on top of
> > >the final merge. There was one new build failure in the staging tree
> > >that was trivial to fix so I added a patch to the tree as well.
> > >
> >
> > This build does look much better than the previous ones. I 'only' get 12 build failures
> > out of 106 configurations.
>
> Thanks for running these!
>
No problem - servers are up anyway. Only problem is that buildbot and gitorious
don't seem to get along, and the automatic tree update doesn't work. This means
I have to trigger tree updates manually, which I may forget once in a while.
> > Worst are powerpc builds, with 7 out of 14 builds failed.
>
> Yes, I'm seeing those too. I used to carry a fix for many of these in
> earlier linux-next trees but since I haven't had the time to run the
> PowerPC builds in a while I haven't cherry-picked it to new trees.
>
Are those failures due to merge conflicts, or should the fix be applied
to a contributing repository ?
Thanks,
Guenter
On Wed, Oct 16, 2013 at 09:37:50AM -0700, Guenter Roeck wrote:
> On Wed, Oct 16, 2013 at 05:50:56PM +0200, Thierry Reding wrote:
> > On Tue, Oct 15, 2013 at 10:21:27PM -0700, Guenter Roeck wrote:
> > > On 10/15/2013 07:02 AM, Thierry Reding wrote:
> > > >Hi all,
> > > >
> > > >I've uploaded today's linux-next tree to the master branch of the
> > > >repository below:
> > > >
> > > > git://gitorious.org/thierryreding/linux-next.git
> > > >
> > > >A next-20131015 tag is also provided for convenience.
> > > >
> > > >Gained a new conflict, but nothing too exciting. x86 and ARM default
> > > >configurations build fine. I've also used an x86 allmodconfig build to
> > > >check for build errors. Mark fixed most of those in the trees that he
> > > >created last Thursday and Friday, so I've cherry-picked them on top of
> > > >the final merge. There was one new build failure in the staging tree
> > > >that was trivial to fix so I added a patch to the tree as well.
> > > >
> > >
> > > This build does look much better than the previous ones. I 'only' get 12 build failures
> > > out of 106 configurations.
> >
> > Thanks for running these!
> >
> No problem - servers are up anyway. Only problem is that buildbot and gitorious
> don't seem to get along, and the automatic tree update doesn't work. This means
> I have to trigger tree updates manually, which I may forget once in a while.
I do have a kernel.org account now, but I'd like to avoid switching the
repository again. People are finally beginning to realize that there's a
temporary location for linux-next on gitorious.
> > > Worst are powerpc builds, with 7 out of 14 builds failed.
> >
> > Yes, I'm seeing those too. I used to carry a fix for many of these in
> > earlier linux-next trees but since I haven't had the time to run the
> > PowerPC builds in a while I haven't cherry-picked it to new trees.
> >
> Are those failures due to merge conflicts, or should the fix be applied
> to a contributing repository ?
I think they are cause by some changes being done to the OF headers and
I mailed that patch to Rob Herring at some point, but I'm not sure what
came of it. There were a few others too, but I think most of the patches
I sent for them have been merged.
Thierry
On Wed, 16 Oct 2013, Pablo Neira Ayuso wrote:
> On Wed, Oct 16, 2013 at 11:20:04AM +0200, Jiri Kosina wrote:
> > On Wed, 16 Oct 2013, Jozsef Kadlecsik wrote:
> >
> > > > Today's linux-next merge of the trivial tree got conflicts in
> > > >
> > > > net/netfilter/xt_set.c
> > > >
> > > > caused by commits 3f79410 (treewide: Fix common typo in "identify") and
> > > > bd3129f (netfilter: ipset: order matches and targets separatedly in
> > > > xt_set.c).
> > > >
> > > > I fixed them up (see below). Please verify that the resolution looks
> > > > good.
> > >
> > > I don't really get it: patch bd3129f was part of a patchset, which was
> > > applied to net-next and there it was complete.
> > >
> > > There's none of the patchset in question in linux-next, so what's the
> > > trivial tree? Where's lost what?
>
> To Jozsef: David collects all the networking patches in net-next until
> Linus' merge window opens, that's why you don't see your patches in
> linux-next. It seems Jiri merges this trivial tree (which indeed
> contains your net-next patches already) to linux-next.
>
> > > [The patch below doesn't look good, because it should contain the removed
> > > part for the revision 1 match due to the reordering in the file.]
> >
> > This is just a super-simple conflict between
> >
> > https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=bd3129f
> >
> > and
> >
> > https://git.kernel.org/cgit/linux/kernel/git/jikos/trivial.git/diff/net/netfilter/xt_set.c?h=for-next&id=3f79410c7c
> >
> > I don't think it needs any special handling, do you? I can of course drop
> > the respective hunk from my tree and let you handle it in net-next if you
> > wish.
>
> Please, don't drop it, I think Jozsef got confused by the handling of
> your trivial tree.
I was confused mainly because Thierry sent just the relevant part and I
expected a full patch :-). So it's just fine.
Best regards,
Jozsef
-
E-mail : [email protected], [email protected]
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
On 10/15/13 15:43, Randy Dunlap wrote:
> On 10/15/13 07:02, Thierry Reding wrote:
>> Hi all,
>>
>> I've uploaded today's linux-next tree to the master branch of the
>> repository below:
>>
>> git://gitorious.org/thierryreding/linux-next.git
>>
>> A next-20131015 tag is also provided for convenience.
>
> on x86_64:
>
> crypto/asymmetric_keys/x509_public_key.c: In function 'x509_key_preparse':
> crypto/asymmetric_keys/x509_public_key.c:237:35: error: 'system_trusted_keyring' undeclared (first use in this function)
>
> when CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=m
> and CONFIG_SYSTEM_TRUSTED_KEYRING is not set.
>
>
> Full randconfig file is attached.
>
Hi David,
Do you want me to fix this build error?
(You might not like my fix. :)
thanks,
--
~Randy