Comment 6 for bug 2039804

> This is great, but is this test suite run as part of the package build and publication process in Ubuntu? If not, how could we arrange to run the test suite against the Ubuntu build of the package that includes this patch to ensure that we aren't regressing unaffected users in providing this update?

The test suite is run as part of the Ubuntu build. The patch doesn't include the new test cases, but it does include all the old ones, which should demonstrate that there is no regression. When 24.04 opens for business and the packages sync, the new tests will run as they are in 11.6.3. You can also see it in my PPA: https://launchpad.net/~qpdf/+archive/ubuntu/qpdf. In any case, I believe the fact that test suite is run during the existing builds should be sufficient to ensure that there is no regression. qpdf also has meaningful autopkgtests. You can also check the debian build output. Debian stable proposed updates has 11.3.0 with the same patch.

For manual testing:

Running `qpdf --check 018.pdf` where `018.pdf` is the file attached to the upstream bug will reproduce the issue. With the current version in 22.04 and 23.04, you will see something like this:

```
WARNING: /tmp/z/018.pdf (xref stream: object 17 1, offset 110340): EOF while reading token
WARNING: /tmp/z/018.pdf (xref stream: object 17 1, offset 110830): unexpected EOF
WARNING: /tmp/z/018.pdf (xref stream: object 17 1, offset 110830): parse error while reading object
WARNING: /tmp/z/018.pdf (xref stream: object 17 1, offset 110830): expected endobj
WARNING: /tmp/z/018.pdf: file is damaged
WARNING: /tmp/z/018.pdf (offset 110267): xref not found
WARNING: /tmp/z/018.pdf: Attempting to reconstruct cross-reference table
qpdf: /tmp/z/018.pdf: unable to find trailer dictionary while recovering damaged file
```

After the fix, you will see
```
checking /home/ejb/Downloads/018.pdf
PDF Version: 1.7
File is not encrypted
File is not linearized
No syntax or stream encoding errors found; the file may still contain
errors that qpdf cannot detect
```
(obviously with the full paths based on whatever you call the file).