Re: Yocto security responses.

Re: Yocto security responses.

[Martin Jansa]

On Fri, Oct 13, 2017 at 4:57 AM, Joe MacDonald <Joe_MacDonald@mentor.com>
wrote:

> Not to be brusque about it, but I've said all I intend to say on that
> patch and I've regularly marked it rejected in patchwork, but it keeps
> getting pulled back into the 'master-next' state, I assume by a script
> of some sort, so dnsmasq continues to be something that warrants special
> attention, because I know I manually have to tell my own automated
> processes to ignore it.  :-/
>

Thanks for merge to master, the meta-networking patches are usually in
master-next until they are merged.

I just do the rebase regularly and if they are still there after rebase I
sometimes don't dig in ML or patchwork status to find out if they are still
in review (and should stay in master-next) or already definitely refused
and I should drop them while rebasing.

Currently there are 4 pending meta-networking changes:
pick 6302b49 dnsmasq: disable the service by default
pick 45559fa openconnect: fix parallel compilation failure
pick aac7e9d squid: upgrade to 3.5.27
pick ff5e841 libmnl: Move to oe-core
(and my WIP spice changes which I haven't sent to ML yet).

I'll drop the first now as discussed in this thread (even when
https://patchwork.openembedded.org/patch/137644/ is still marked in
patchwork as "Master Next" not "Rejected").

I'll drop the 2nd as well based on the discussion in https://patchwork.
openembedded.org/patch/143205/

The 3rd one is for some reason marked as Changes Requested, but doesn't
include any ML discussion in https://patchwork.
openembedded.org/patch/143406/

and the last one should imho be merged, because in last batch you've merged:
b8210dd iproute2: Move tipc enablement to oe-core
which already depends on libmnl in oe-core.

Re: Yocto security responses.

[Joe MacDonald]

[-- Attachment #1.1: Type: text/plain, Size: 2498 bytes --]

[Re: Yocto security responses.] On 17.10.16 (Mon 00:49) Martin Jansa wrote:

> On Fri, Oct 13, 2017 at 4:57 AM, Joe MacDonald <Joe_MacDonald@mentor.com>
> wrote:
> 
>     Not to be brusque about it, but I've said all I intend to say on that
>     patch and I've regularly marked it rejected in patchwork, but it keeps
>     getting pulled back into the 'master-next' state, I assume by a script
>     of some sort, so dnsmasq continues to be something that warrants special
>     attention, because I know I manually have to tell my own automated
>     processes to ignore it.  :-/
> 
> 
> Thanks for merge to master, the meta-networking patches are usually in
> master-next until they are merged.
> 
> I just do the rebase regularly and if they are still there after rebase I
> sometimes don't dig in ML or patchwork status to find out if they are still in
> review (and should stay in master-next) or already definitely refused and I
> should drop them while rebasing.
> 
> Currently there are 4 pending meta-networking changes:
> pick 6302b49 dnsmasq: disable the service by default
> pick 45559fa openconnect: fix parallel compilation failure
> pick aac7e9d squid: upgrade to 3.5.27
> pick ff5e841 libmnl: Move to oe-core
> (and my WIP spice changes which I haven't sent to ML yet).
> 
> I'll drop the first now as discussed in this thread (even when https://
> patchwork.openembedded.org/patch/137644/ is still marked in patchwork as
> "Master Next" not "Rejected").
> 
> I'll drop the 2nd as well based on the discussion in https://patchwork.
> openembedded.org/patch/143205/
> 
> The 3rd one is for some reason marked as Changes Requested, but doesn't include
> any ML discussion in https://patchwork.openembedded.org/patch/143406/

Weird, I can't find my reply on the mailing list either.  Attached here
so maybe it'll get archived this time.  Short version, I wanted
confirmation on the behaviour with gcc7 and the patch that was being
removed and if we were going to see a v2 on this, I'd rather not have
the unnecessary whitespace reformatting in the next version.

> and the last one should imho be merged, because in last batch you've
> merged: b8210dd iproute2: Move tipc enablement to oe-core which
> already depends on libmnl in oe-core.

I plan to do that today, there's another issue that I thought needed
quick turnaround on it, but it seems not.  Since I'm here, though, I'll
take care of b8210dd.

-- 
-Joe MacDonald.
:wq

[-- Attachment #1.2: squid.mbox --]
[-- Type: application/mbox, Size: 9722 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 499 bytes --]