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?" :-) > 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
