An interesting architecture-dependent autopkgtest regression
More than two years after I last uploaded the purity-off Debian package, its autopkgtest (the Debian distribution-wide continuous integration system) started failing on arm64, and only on this architecture.
The failing test is very simple: it prints a long stream of "y" or "n" characters to purity(6)'s standard input and then checks the output for the expected result.
While investigating the live autopkgtest system, I figured out that:
- The paging function of purity(6) became enabled, but only on arm64!
- Paging consumed more "y" characters from standard input than the 5000 provided by the test script.
- The paging code does not consider EOF a valid input, so at that point it would start asking again and printing "--- more ---" forever in a tight loop.
- And this output, being redirected to a file, would fill the file system where the autopkgtest is running.
I did not have time to verify this, but I have noticed that the 25 years old purity(6) program calls TIOCGWINSZ to determine the screen length, and then uses the results in the answer buffer without checking if the ioctl(2) call returned an error. Which it obviously does in this case, because standard input is not a console but a pipe. So my theory is that paging is enabled because the undefined result of the ioctl has changed, and only on this architecture.
Since I do not want to fix purity(6) right now, I have implemented the workaround of printing many more "y" characters as input.