On Tue, Oct 8, 2024, 1:03 PM Peter Maydell <[email protected]> wrote:

> On Tue, 8 Oct 2024 at 17:50, John Snow <[email protected]> wrote:
> >
> >
> >
> > On Tue, Oct 8, 2024, 12:31 PM Peter Maydell <[email protected]>
> wrote:
> >>
> >> I made some changes to a block backend so I wanted to run the iotests.
> >> I ran into an unrelated failure of iotest 297. The bulk of this
> >> seems to be because the iotest tries to run on all files
> >> in qemu-iotests, even on editor backups like in this case "040~"
> >> (which is an old editor backup of 040). But there are also
> >> some warnings about files that do exist in the tree and which
> >> I haven't modified:
> >>
> >> +tests/migrate-bitmaps-test:63:4: R0201: Method could be a function
> >> (no-self-use)
> >> +tests/mirror-change-copy-mode:109:4: R0201: Method could be a
> >> function (no-self-use)
> >> +fat16.py:239:4: R0201: Method could be a function (no-self-use)
> >>
> >> Q1: can we make this test not run the linters on editor backup files?
> >
> >
> > Shouldn't be a problem. AFAIK we decide what to lint based on looking
> for the shebang in the file and exclude a known-bad list, but we can
> exclude the emacs confetti files too.
> >
> > I'll fix it.
>
> Thanks!
>
> >> Q2: why do I see the errors above but they aren't in the reference file
> >> output?
> >
> >
> > You mean, why are there errors in files you haven't modified?
>
> Yes, and/or "why isn't the test forcing a pylint version?"
> and/or "why is the test run by default if it depends on
> the pylint version?" :-)
>

"because it's always been like that and I've had difficulties fixing it",
mostly :)

qemu configure venv was the first step to finally fixing it, but I've run
into some troubles since but have been too busy with Sphinx junk.

I know it's bonkers, sorry!


> > Very likely: pylint version differences. I've been meaning to remove
> iotest 297 for a long time, but when you run it directly through iotests
> (i.e. not through the python directory tests, the ones that run on gitlab
> ci), the linter versions are not controlled for. It's a remaining ugly spot
> of the python consistency work. (sparing you the details on why but it's a
> known thing I need to fix.)
> >
> > In this case I bet "check-python-tox" (an optionally run, may-fail job)
> is also failing on gitlab and I didn't notice yet.
>
> I kicked off a job by hand, and yes, it fails, but apparently
> not for the same set of errors as the above...
>
> https://gitlab.com/qemu-project/qemu/-/jobs/8009902380
>
> > for now (assuming my guesses above are right): I'll fix 297 to tolerate
> the newest versions. As soon as I'm done my sphinx work, I'll pivot back to
> finally adding a "check python" subtest to "make check" that *does* control
> linter versions, and delete iotest 297.
> >
> > Just in case my guesses are wrong, can you please go to your QEMU build
> directory (post-configure) and type:
> >
> > > source pyvenv/bin/activate.[whatever shell suffix you use]
> > > pylint --version
> > > deactivate
> >
> > and let me know what version of pylint you have in the qemu build
> environment?
>
> (pyvenv) e104462:jammy:x86-tgts$ pylint --version
> pylint 2.12.2
> astroid 2.9.3
> Python 3.10.12 (main, Sep 11 2024, 15:47:36) [GCC 11.4.0]
>
> (This is an Ubuntu 22.04 system.)
>
> thanks
> -- PMM
>

Great, thanks. will work on this today and get everything green again.

>

Reply via email to