Message ID | 20220311124029.213470-1-johannes@sipsolutions.net (mailing list archive) |
---|---|
State | Accepted |
Commit | 0b3660695e80d53d1bab5b458f3a897a2c427a59 |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | pull-request: wireless-next-2022-03-11 | expand |
Context | Check | Description |
---|---|---|
netdev/tree_selection | success | Pull request for net-next |
netdev/apply | fail | Pull to net-next failed |
On Fri, 11 Mar 2022 13:40:28 +0100 Johannes Berg wrote: > Hi, > > Here's another (almost certainly final for 5.8) set of > patches for net-next. 5.18 ;) > Note that there's a minor merge conflict - Stephen already > noticed it and resolved it here: > https://lore.kernel.org/linux-wireless/20220217110903.7f58acae@canb.auug.org.au/ > > I didn't resolve it explicitly by merging back since it's > such a simple conflict, but let me know if you want me to > do that (now or in the future). Looks like commit e8e10a37c51c ("iwlwifi: acpi: move ppag code from mvm to fw/acpi") uses spaces for indentation?
Hello: This pull request was applied to netdev/net-next.git (master) by Jakub Kicinski <kuba@kernel.org>: On Fri, 11 Mar 2022 13:40:28 +0100 you wrote: > Hi, > > Here's another (almost certainly final for 5.8) set of > patches for net-next. > > Note that there's a minor merge conflict - Stephen already > noticed it and resolved it here: > https://lore.kernel.org/linux-wireless/20220217110903.7f58acae@canb.auug.org.au/ > > [...] Here is the summary with links: - pull-request: wireless-next-2022-03-11 https://git.kernel.org/netdev/net-next/c/0b3660695e80 You are awesome, thank you!
On Fri, 11 Mar 2022 21:20:29 +0000 patchwork-bot+netdevbpf@kernel.org wrote: > Hello: > > This pull request was applied to netdev/net-next.git (master) > by Jakub Kicinski <kuba@kernel.org>: > > On Fri, 11 Mar 2022 13:40:28 +0100 you wrote: > > Hi, > > > > Here's another (almost certainly final for 5.8) set of > > patches for net-next. > > > > Note that there's a minor merge conflict - Stephen already > > noticed it and resolved it here: > > https://lore.kernel.org/linux-wireless/20220217110903.7f58acae@canb.auug.org.au/ > > > > [...] > > Here is the summary with links: > - pull-request: wireless-next-2022-03-11 > https://git.kernel.org/netdev/net-next/c/0b3660695e80 > > You are awesome, thank you! mumble, muble Seems to break clang build.
On Fri, 11 Mar 2022 17:06:25 -0800 Jakub Kicinski wrote:
> Seems to break clang build.
No, sorry just some new warnings with W=1, I think.
Jakub Kicinski <kuba@kernel.org> writes: > On Fri, 11 Mar 2022 13:40:28 +0100 Johannes Berg wrote: >> Hi, >> >> Here's another (almost certainly final for 5.8) set of >> patches for net-next. > > 5.18 ;) > >> Note that there's a minor merge conflict - Stephen already >> noticed it and resolved it here: >> https://lore.kernel.org/linux-wireless/20220217110903.7f58acae@canb.auug.org.au/ >> >> I didn't resolve it explicitly by merging back since it's >> such a simple conflict, but let me know if you want me to >> do that (now or in the future). > > Looks like commit e8e10a37c51c ("iwlwifi: acpi: move ppag code from mvm > to fw/acpi") uses spaces for indentation? Luca, can you check that, please?
Jakub Kicinski <kuba@kernel.org> writes: > On Fri, 11 Mar 2022 17:06:25 -0800 Jakub Kicinski wrote: >> Seems to break clang build. > > No, sorry just some new warnings with W=1, I think. I have not installed clang yet. You don't happen to have the warnings stored someplace? I checked the patchwork tests and didn't see anything there.
On Mon, 14 Mar 2022 20:21:53 +0200 Kalle Valo wrote: > Jakub Kicinski <kuba@kernel.org> writes: > > > On Fri, 11 Mar 2022 17:06:25 -0800 Jakub Kicinski wrote: > >> Seems to break clang build. > > > > No, sorry just some new warnings with W=1, I think. > > I have not installed clang yet. You don't happen to have the warnings > stored someplace? I checked the patchwork tests and didn't see anything > there. Yeah.. patchwork build thing can't resolve conflicts. I wish there was a way to attach a resolution to the PR so that the bot can use it :S I was guessing what happened based on the result of the first thing that got built after wireless-next was pulled but that thing itself didn't build, hence my confusion. I say - don't worry about it. The non-W=1 build is clean which is what matters the most.
On Mon, 2022-03-14 at 11:37 -0700, Jakub Kicinski wrote: > On Mon, 14 Mar 2022 20:21:53 +0200 Kalle Valo wrote: > > Jakub Kicinski <kuba@kernel.org> writes: > > > > > On Fri, 11 Mar 2022 17:06:25 -0800 Jakub Kicinski wrote: > > > > Seems to break clang build. > > > > > > No, sorry just some new warnings with W=1, I think. > > > > I have not installed clang yet. You don't happen to have the warnings > > stored someplace? I checked the patchwork tests and didn't see anything > > there. > > Yeah.. patchwork build thing can't resolve conflicts. I wish there was > a way to attach a resolution to the PR so that the bot can use it :S > That'd be on thing - but OTOH ... maybe you/we could somehow attach the bot that processes things on the netdev patchwork also to the wireless one? It's on the same patchwork instance already, so ... But I do't know who runs it, how it runs, who's paying for it, etc. johannes
On Mon, 14 Mar 2022 21:17:30 +0100 Johannes Berg wrote: > On Mon, 2022-03-14 at 11:37 -0700, Jakub Kicinski wrote: > > Yeah.. patchwork build thing can't resolve conflicts. I wish there was > > a way to attach a resolution to the PR so that the bot can use it :S > > That'd be on thing - but OTOH ... maybe you/we could somehow attach the > bot that processes things on the netdev patchwork also to the wireless > one? It's on the same patchwork instance already, so ... Depends on what you mean. The bot currently understands the netdev + bpf pw instance so it determines the target tree between those four. We'd need to teach it how to handle more trees, which would be a great improvement, but requires coding. > But I do't know who runs it, how it runs, who's paying for it, etc. Yeah... As much as I'd love to give you root on the VM having it under the corporate account is the only way I can get it paid for :(
On Mon, 2022-03-14 at 13:41 -0700, Jakub Kicinski wrote: > > Depends on what you mean. The bot currently understands the netdev + > bpf pw instance so it determines the target tree between those four. Makes sense, that's what it was written for :) On the linux-wireless patchwork instance (https://patchwork.kernel.org/project/linux-wireless/) there are only two trees now, I think, wireless/main and wireless-next/main. Perhaps mt76 but maybe we'll just bring those into the fold too. Oh, I guess Kalle has some ath* trees too, not sure now. > We'd need to teach it how to handle more trees, which would be a great > improvement, but requires coding. Right. Do you have it out in the open somewhere? Maybe we could even take it and run our own instance somewhere. > > But I do't know who runs it, how it runs, who's paying for it, etc. > > Yeah... As much as I'd love to give you root on the VM having it under > the corporate account is the only way I can get it paid for :( Right. Anyway, was just thinking out loud I guess. johannes
On Mon, 14 Mar 2022 21:45:11 +0100 Johannes Berg wrote: > On Mon, 2022-03-14 at 13:41 -0700, Jakub Kicinski wrote: > > > > Depends on what you mean. The bot currently understands the netdev + > > bpf pw instance so it determines the target tree between those four. > > Makes sense, that's what it was written for :) > > On the linux-wireless patchwork instance > (https://patchwork.kernel.org/project/linux-wireless/) there are only > two trees now, I think, wireless/main and wireless-next/main. Perhaps > mt76 but maybe we'll just bring those into the fold too. Oh, I guess > Kalle has some ath* trees too, not sure now. Plus you need to know which series to ignore so that the occasional cross-posted 50-patch series touching kernel.h doesn't take the build bot out for 2 days :) > > We'd need to teach it how to handle more trees, which would be a great > > improvement, but requires coding. > > Right. Do you have it out in the open somewhere? Maybe we could even > take it and run our own instance somewhere. Oh yeah: https://github.com/kuba-moo/nipa