From: John Johansen <john.johansen@canonical.com>
To: Shuah Khan <skhan@linuxfoundation.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Brendan Higgins <brendanhiggins@google.com>,
David Gow <davidgow@google.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Rae Moar <rmoar@google.com>
Subject: Re: linux-next: manual merge of the kunit-next tree with the apparmor tree
Date: Mon, 12 Dec 2022 11:20:32 -0800 [thread overview]
Message-ID: <9b21c055-4e1a-2c34-281c-39af7d73fe80@canonical.com> (raw)
In-Reply-To: <0e678eb2-455c-88f5-6732-2e8701ebb6e6@linuxfoundation.org>
On 12/12/22 10:03, Shuah Khan wrote:
> On 12/12/22 10:52, Shuah Khan wrote:
>> Hi David,
>>
>> On 12/8/22 13:10, John Johansen wrote:
>>> On 12/7/22 18:53, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> Today's linux-next merge of the kunit-next tree got a conflict in:
>>>>
>>>> security/apparmor/policy_unpack.c
>>>>
>>>> between commits:
>>>>
>>>> 371e50a0b19f ("apparmor: make unpack_array return a trianary value")
>>>> 73c7e91c8bc9 ("apparmor: Remove unnecessary size check when unpacking trans_table")
>>>> 217af7e2f4de ("apparmor: refactor profile rules and attachments")
>>>> (and probably others)
>>>>
>>>> from the apparmor tree and commit:
>>>>
>>>> 2c92044683f5 ("apparmor: test: make static symbols visible during kunit testing")
>>>>
>>>> from the kunit-next tree.
>>>>
>>>> This is somewhat of a mess ... pity there is not a shared branch (or
>>>> better routing if the patches).
>>>>
>>> sorry, there was a miscommunication/misunderstanding, probably all on me, I
>>> thought the kunit stuff that is conflicting here was going to merge next
>>> cycle.
>>>
>>
>
> How about I just drop the following for now and handle this in the next cycle?
if you want, the other way to handle it is we coordinate our pull requests.
You go first. And then I will submit a little later in the week, with the
references to the merge conflict and a pointer to a branch with it resolved.
This isn't even a particularly tricky merge conflict, it just has the little
subtly around making sure the include symbols are conditional.
This doesn't affect me much as there is already another merge conflict with
the security tree that I need to deal with.
> I think it might be least confusing option. Let me know. I can just do that
> and then send pull request in a day or tow once things settle down in next.
>
> 2c92044683f5 ("apparmor: test: make static symbols visible during kunit testing")
>
that is the other option. If you go that route I can help you do the rebase/merge
fix.
looking back at this, there wasn't anything explicit about this not going upstream
this cycle, I must have just assumed as the final version came about after rc7. So
my bad.
> thanks,
> -- Shuah
next prev parent reply other threads:[~2022-12-12 19:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-08 2:53 linux-next: manual merge of the kunit-next tree with the apparmor tree Stephen Rothwell
2022-12-08 20:10 ` John Johansen
2022-12-12 17:52 ` Shuah Khan
2022-12-12 18:03 ` Shuah Khan
2022-12-12 19:20 ` John Johansen [this message]
2022-12-12 19:48 ` Shuah Khan
2022-12-12 19:53 ` John Johansen
2022-12-12 23:19 ` Shuah Khan
2022-12-12 23:56 ` David Gow
2022-12-13 3:22 ` Stephen Rothwell
2022-12-14 0:00 ` Stephen Rothwell
2022-12-14 0:55 ` John Johansen
2022-12-14 18:38 ` John Johansen
-- strict thread matches above, loose matches on Subject: below --
2022-12-08 1:46 Stephen Rothwell
2022-12-13 23:58 ` Stephen Rothwell
2022-12-14 18:38 ` John Johansen
2022-04-05 2:55 Stephen Rothwell
2022-07-04 23:13 ` Stephen Rothwell
2022-07-05 8:57 ` David Gow
2022-07-05 18:22 ` John Johansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b21c055-4e1a-2c34-281c-39af7d73fe80@canonical.com \
--to=john.johansen@canonical.com \
--cc=brendanhiggins@google.com \
--cc=davidgow@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=rmoar@google.com \
--cc=sfr@canb.auug.org.au \
--cc=skhan@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox