On Tue, Dec 14, 2021 at 04:56:51PM +0000, Julian Gilbey wrote: > Hi Mattia, > > > that's because you are using the wrong option. > > You may well be correct. That doesn't change the reality that this is > what is happening in a number of packages.
Hi Mattia, Here's an update. I've been through the archive, and the figures are approximately the following (only approximate, as some packages have multiple versions in unstable Sources, and I wasn't careful to only include one of each): 829 packages call py3versions in their debian/tests/* scripts 337 packages call py3versions -r 438 packages call py3versions -s 54 packages use other options: some use -i, some use -d, some use --supported (= -s), one uses -r So this is a *lot* of packages using -r, almost as many as the number using -s! After I fixed my broken packages, there are only a handful of packages incorrectly doing a cd before py3versions -r (3 or 4 such packages), so my suggested check is probably unwarranted. I've filed bug reports against those packages. Almost every package using py3versions -r redirects 2>/dev/null; the 5 or so which don't have "Restrictions: allow-stderr" in their tests/control file. I hope this is helpful. Best wishes, Julian
