On Saturday, March 21, 2020 1:41:14 AM EDT Scott Kitterman wrote: > On Wednesday, March 18, 2020 6:32:22 PM EDT Scott Kitterman wrote: > > I'm currently reviewing some of the autopkgtest regressions that are > > currently blocking python3-defaults with python3.8 as the default python3 > > from migrating. > > > > With the current state of the environment being used for autopkgtest it is > > quite common for python3.7 to be present in the environment even if it's > > not explicitly required by a dependency. As a result, I seen many > > failures where the test attempts to loop through python3 versions (a good > > thing) based on what versions are installed (bad thing). > > > > We want the tests to run against all versions, but the way to do that is > > to > > have your test depend on python3-all (to make sure that all supported > > versions are installed) and then use the -s flag for py3versions vice -i. > > So (in one common pattern) this: > > > > for py in $(py3versions -i); do > > > > changes to: > > > > for py in $(py3versions -s); do > > > > Makes all the difference in the world. I've fixed three today. If you > > care for a relevant package, please check. The future pain you save may > > be your own. > > > > Scott K > > I have continued to look into this and it's common enough that there are > quite a few related autopkgtest failures currently marked as regressions > against python3-defaults with python3.8 as the default python3. > > Except for one I filed earlier, none of them have bugs currently. It's > enough I'm not sure if it qualifies as a MBF for not. Here's what I'll > file if I get sufficiently motivated and have the time: > > This package failed a recent autopkgtest and this is one of the blockers for > python3-defaults migration. It failed because python3.7 was installed in > the chroot and the current autopkgtest doesn't handle that. > > Autopkgtests should be run for all supported versions. The package attempts > to do that, but in a way that is unreliable. > > Based on a review of the failure log (I have not looked at the package, so > there's a small chance the root cause is different), the autopkgtest uses > the output of py3versions -i to iterate over available python3 versions. > The -i flag indicates all installed versions. In many cases python3.7 is > still partially installed, so it is included in the tests, but fails. > > The reliable way to do this is add python3-all to your tests depends in > debian/tests/control and change the py3versions call to py3versions -s. > These two steps will ensure all supported python3 interpreters are fully > installed and that the tests are run against them. > > As this is a blocker for getting python3.8 as default python3 into bullseye, > please address this soon. I'm open to doing NMUs if anyone would like the > support. Please let me know if you would like for me to do that. > > Scott K > > dd-list is attached. If any of you fix these before I file the bugs, please > let me know so I can skip that package when I do. > > Scott K These are filed now (it turned out one package already had a bug, so I added information to it instead of filing a new bug). Scott K ariba Added info to #951944 editorconfig-core-py #954461 m2crypto #954462 pydbus #954467 pyethash #954468 pyrlp #954469 pysha3 #954470 pystemd #954471 python-daemon #954473 python-h2 #954474 python-jsbeautifier #954476 python-jsonext #954477 python-pbkdf2 #954478 python-pynvim #954479 python-tinyrpc #954480 python3-proselint #954481 pyx3 #954482 wand #954483
Attachment:
signature.asc
Description: This is a digitally signed message part.