Hi!  This package seems to have flaky tests which triggers testing
migration blockers, see what I believe are random build failures:

https://tests.reproducible-builds.org/debian/rb-pkg/forky/arm64/golang-github-google-goexpect.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/golang-github-google-goexpect.html
https://ci.debian.net/packages/g/golang-github-google-goexpect/testing/i386/64964676/
https://salsa.debian.org/go-team/packages/golang-github-google-goexpect/-/jobs/8113152

Looking at the error messages, this looks timing related so there is
probably a race condition somehwere.  Maybe the 20s timeout is not
sufficient on slow machines.

For flaky tests, I usually report these upstreams and mask it out of the
Debian build.  I initially thought keeping flaky tests around was
acceptable, but I've realized it causes serious Debian testing migration
pains so I believe we must not have any flaky tests in Debian.  Here is
an idea:

override_dh_auto_test:
	dh_auto_test $(DH_BUILD_OPTS) -- -skip=ExampleGExpect_SendSignal
        -dh_auto_test $(DH_BUILD_OPTS)

This allows the failure message to still become available in build logs,
for future references in bug reports.

If it only has happened on a particular arch, here is an idea:

ifneq (,$(filter $(DEB_TARGET_ARCH), ppc64el))
override_dh_auto_test:
	dh_auto_test $(DH_BUILD_OPTS) -- -skip=ExampleGExpect_SendSignal
        -dh_auto_test $(DH_BUILD_OPTS)
endif

For complex workarounds I have used this:

ifneq (,$(filter $(DEB_TARGET_ARCH), i386 ppc64el riscv64 s390x))
override_dh_auto_test:
ifneq (,$(filter $(DEB_TARGET_ARCH), i386))
	dh_auto_test $(DH_BUILD_OPT) -- --skip=TestAllocate
endif
ifneq (,$(filter $(DEB_TARGET_ARCH), ppc64el riscv64 s390x))
	dh_auto_test $(DH_BUILD_OPT) -- --skip='TestTreePersistent|TestBuffer'
endif
	-dh_auto_test $(DH_BUILD_OPT) -- --timeout=20m
endif

/Simon

Failures seen again:

https://ci.debian.net/packages/g/golang-github-google-goexpect/testing/riscv64/71982686/#L1655

1178s === RUN   TestSendSignal
1178s === RUN   TestSendSignal/Sig_USR1
1179s 2026/06/12 10:32:13 Match for RE: "Waiting for signal" found: ["Waiting for signal"] Buffer: "Waiting for signal\n"
1179s 2026/06/12 10:32:13 Match for RE: "USR1" found: ["USR1"] Buffer: "Got the USR1 Signal\n"
1179s === RUN   TestSendSignal/Sig_HUP
1179s 2026/06/12 10:32:13 Match for RE: "Waiting for signal" found: ["Waiting for signal"] Buffer: "Waiting for signal\n"
1181s     expect_test.go:1341: Sig HUP: exp.Expect("HUP", 2s) failed: expect: timer expired after 2 seconds, match: , buf: []
1181s --- FAIL: TestSendSignal (2.11s)
1181s     --- PASS: TestSendSignal/Sig_USR1 (0.07s)
1181s     --- FAIL: TestSendSignal/Sig_HUP (2.04s)
...
1183s === RUN   ExampleGExpect_SendSignal
1203s --- FAIL: ExampleGExpect_SendSignal (20.04s)
1203s got:
1203s exp.Expect failed, match: , buf: [], err: expect: timer expired after 20 seconds
1203s want:
1203s Got the USR1 Signal
1203s === RUN   ExampleGExpect_SendSignal_Batch
1233s --- FAIL: ExampleGExpect_SendSignal_Batch (30.04s)
1233s got:
1233s ExpectBatch failed: expect: timer expired after 30 seconds
1233s want:
1233s Signal received
1233s FAIL

It is not clear if this is the same problem as in the earlier report,
the only link that still worked contains this snippet:

=== RUN   ExampleGExpect_SendSignal
--- FAIL: ExampleGExpect_SendSignal (20.01s)
got:
exp.Expect failed, match: , buf: [], err: expect: timer expired after 20 seconds
want:
Got the USR1 Signal

/Simon

More flaky failures:

https://ci.debian.net/packages/g/golang-github-google-goexpect/testing/arm64/71981794/#L1654

110s === RUN   TestSpawnWithArgs
110s     expect_test.go:1110: Expect(a   b) failed: expect: Process not running
110s --- FAIL: TestSpawnWithArgs (0.00s)

/Simon

Another example:

https://ci.debian.net/packages/g/golang-github-google-goexpect/testing/armhf/74274207/#L1733

151s === RUN   TestSpawnWithArgs
151s     expect_test.go:1110: Expect(a   b) failed: expect: Process not running
151s --- FAIL: TestSpawnWithArgs (0.00s)

/Simon