Hi Paul! First of all thanks for your report.
On Do, 20 Mai 2021, Paul Gevers wrote: > Source: xfig > Version: 1:3.2.8-1 > Severity: serious > Tags: sid bullseye > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: flaky > > Your package has an autopkgtest, great. However, I looked into > the history of your autopkgtest [1] on ppc64el (because it is blocking > libx11) and I noticed it fails regularly, while a rerun passes. It > failed once on amd64 with the same error and it fails most of the time > on s390x. I copied some of the output at the bottom of this report. > > Because the unstable-to-testing migration software now blocks on > regressions in testing, flaky tests, i.e. tests that flip between > passing and failing without changes to the list of installed packages, > are causing people unrelated to your package to spend time on these > tests. I noticed the issue on Ubuntu and saw the upstream issue, but wasn't able to reproduce the issue myself, which makes it hard to fix it. I fear that the root cause here is, that the way I run the autopkgtest wasn't a good idea, since I rebuild the testing binaries test1, test2, and test3 during autopkgtest, which means, that detecting regressions isn't possible with them, since they differ from the binaries build at package build time. The correct way would be to ship test[123] with the binary package and restore them into the source tree during the autopkgtest. But this change is too big to introduce it during the freeze, so I target it for bookworm. A better way is completely removing the autopkgtest code from the package, which solves this issue but isn't a step forward. So I intend to go a different way: I try to bring the autopkgtest environment nearer to the building environment, which means that I add a dependency on libgs-dev to debian/tests/control (as the Build-Depends of the source package does). This means, that test3 is linked with libgs instead of calling external binary gs, which according to https://sourceforge.net/p/mcj/tickets/120/ should no longer run into the SIGPIPE issue. I expect this to be a cleaner workaround than the Ubuntu patch. I'll upload a patched version soon. Greetings Roland
signature.asc
Description: PGP signature
