Bug 920436 – net-print/cups-2.4.7-r2 fails tests on arm64

• Product: Gentoo Linux
• Status: RESOLVED WORKSFORME

[Description matoro 2023-12-20 22:33:24 UTC]

build.log and emerge --info in attachment.  Let me know if tarball is necessary for additional logs.

FAIL: 4 job control files were not purged.
FAIL: Printer 'Test2' produced 0 page(s), expected 23.
FAIL: Printer 'Test3' produced 1 page(s), expected 2.
FAIL: 174 requests logged, expected 176.
FAIL: 146 error messages, expected 33.

Reproducible: Always

[Comment 1 matoro 2023-12-20 22:34:10 UTC]

Created attachment 880102 [details]
build.log and emerge --info

[Comment 2 Mart Raudsepp 2023-12-22 13:16:09 UTC]

I can't reproduce this on my ~arm64 system. Maybe it's a timeout issue on slower system?

[Comment 3 Mart Raudsepp 2023-12-22 13:23:20 UTC]

What arm64 system do you have? This smells like a too quick timeout for a slower box case to me on "Waiting for job history to expire".
Feels like it's waiting for all the test jobs to finish for a given amount of time, then times out and proceeds and it was actually still int he progress of printing Test3 and hadn't started on printing Test2 or something along those lines.

[Comment 4 matoro 2023-12-22 18:05:41 UTC]

(In reply to Mart Raudsepp from comment #3)
> What arm64 system do you have? This smells like a too quick timeout for a
> slower box case to me on "Waiting for job history to expire".
> Feels like it's waiting for all the test jobs to finish for a given amount
> of time, then times out and proceeds and it was actually still int he
> progress of printing Test3 and hadn't started on printing Test2 or something
> along those lines.

It's a SolidRun Honeycomb, it runs with 16x Cortex A72s (I am using -j10).  Any pointers on where in the code the test timeouts are so I can crank them up and see if it helps?

[Comment 5 Mart Raudsepp 2023-12-22 21:45:55 UTC]

run-stp-tests.sh calls waitjobs.sh in 3 places, one of them uses a specific timeout of 1800 seconds and the others let waitjobs.sh pick its default of 360 seconds. Not sure which one's applicable here, try cranking em all up to start with I guess (the other cases you could add a big number of seconds for the optional argument in the call instead of modifying the default I suppose).

[Comment 6 matoro 2023-12-29 03:24:08 UTC]

This is weird, I went back today to try and test if cranking up the timeouts fixed this and now I cannot manage to reproduce it, even without the timeouts.  Guess I will close unless it comes up again.