On Mon, Jul 03, 2023 at 07:27:04PM +0000, SeongJae Park wrote:
> Hi Greg and Sasha,
>
> On Sat, 10 Jun 2023 17:56:18 +0000 SeongJae Park <sj@xxxxxxxxxx> wrote:
>
> > On Sat, 10 Jun 2023 12:15:55 +0800 David Gow <davidgow@xxxxxxxxxx> wrote:
> >
> > > [-- Attachment #1: Type: text/plain, Size: 2275 bytes --]
> > >
> > > On Sat, 10 Jun 2023 at 03:09, SeongJae Park <sj@xxxxxxxxxx> wrote:
> > > >
> > > > Hi David and Brendan,
> > > >
> > > > On Tue, 2 May 2023 08:04:20 +0800 David Gow <davidgow@xxxxxxxxxx> wrote:
> > > >
> > > > > [-- Attachment #1: Type: text/plain, Size: 1473 bytes --]
> > > > >
> > > > > On Tue, 2 May 2023 at 02:16, 'Daniel Latypov' via KUnit Development
> > > > > <kunit-dev@xxxxxxxxxxxxxxxx> wrote:
> > > > > >
> > > > > > Writing `subprocess.Popen[str]` requires python 3.9+.
> > > > > > kunit.py has an assertion that the python version is 3.7+, so we should
> > > > > > try to stay backwards compatible.
> > > > > >
> > > > > > This conflicts a bit with commit 1da2e6220e11 ("kunit: tool: fix
> > > > > > pre-existing `mypy --strict` errors and update run_checks.py"), since
> > > > > > mypy complains like so
> > > > > > > kunit_kernel.py:95: error: Missing type parameters for generic type "Popen" [type-arg]
> > > > > >
> > > > > > Note: `mypy --strict --python-version 3.7` does not work.
> > > > > >
> > > > > > We could annotate each file with comments like
> > > > > > `# mypy: disable-error-code="type-arg"
> > > > > > but then we might still get nudged to break back-compat in other files.
> > > > > >
> > > > > > This patch adds a `mypy.ini` file since it seems like the only way to
> > > > > > disable specific error codes for all our files.
> > > > > >
> > > > > > Note: run_checks.py doesn't need to specify `--config_file mypy.ini`,
> > > > > > but I think being explicit is better, particularly since most kernel
> > > > > > devs won't be familiar with how mypy works.
> > > > > >
> > > > > > Fixes: 695e26030858 ("kunit: tool: add subscripts for type annotations where appropriate")
> > > > > > Reported-by: SeongJae Park <sj@xxxxxxxxxx>
> > > > > > Link: https://lore.kernel.org/linux-kselftest/20230501171520.138753-1-sj@xxxxxxxxxx
> > > > > > Signed-off-by: Daniel Latypov <dlatypov@xxxxxxxxxx>
> > > > > > ---
> > > > >
> > > > > Thanks for jumping on this.
> > > > >
> > > > > Looks good to me!
> > > > >
> > > > > Reviewed-by: David Gow <davidgow@xxxxxxxxxx>
> > > >
> > > > Looks like this patch is still not merged in the mainline. May I ask the ETA,
> > > > or any concern if you have?
> > > >
> > > >
> > >
> > > We've got this queued for 6.5 in the kselftest/kunit tree[1], so it
> > > should land during the merge window. But I'll look into getting it
> > > applied as a fix for 6.4, beforehand.
> >
> > Thank you for the kind answer, Gow! I was thinking this would be treated as a
> > fix, and hence merged into the mainline before next merge window. I'm actually
> > getting my personal test suite failures due to absence of this fix. It's not a
> > critical problem, but it would definitely better for me if this could be merged
> > into the mainline as early as possible.
>
> This patch is now in the mainline (e30f65c4b3d671115bf2a9d9ef142285387f2aff).
> However, this fix is not in 6.4.y yet, so the original issue is reproducible on
> 6.4.y. Could you please add this to 6.4.y? I confirmed the mainline commit
> can cleanly applied on latest 6.1.y tree, and it fixes the issue.
As this was not specifically tagged with a "cc: stable..." marking, that
is why it was not picked up automatically. Also, we do not normally add
patches to any stable releases until it is in a released kernel from
Linus (i.e. a -rc release), unless you have a specific reason for it to
be merged earlier.
Should this be merged "now" into the stable trees and not wait for
6.5-rc1?
thanks,
greg k-h
