fixed 1124286 28.0.0~rc2-1
thanks
On Mon, Mar 30, 2026 at 11:52:47AM +0200, Thomas Goirand wrote:
> Just as a reminder: I do care about your bug reports, it just that
> sometimes, they don't get as high priority as they should. But I do have the
> intention to address them all! :)
>
> The problem with this type of issue is that we just get the error message:
>
> E: Build killed with signal TERM after 60 minutes of inactivity
>
> and nothing else, so it's impossible to know which unit test failed.
Ok, just to clarify: the error message about signal TERM comes from
sbuild, and it may be changed in config.pl. I deviate from the
standard by reducing it to 60 minutes, but at the same time I have a
small collection of per-package values with other amounts, like this:
$individual_stalled_pkg_timeout->{'foo'} = 240;
so if it becomes useful/necessary for the next time, feel free to tell
me "please increase the timeout value for this package" and I can try
that easily.
> Therefore, I have set:
>
> OS_TEST_TIMEOUT=300
>
> when running unit tests. This is from testtools. Normally, all unit tests
> are derived from the BaseTestCase class, which implements this timeout. I've
> checked the build logs, and the unit test that's taking the longest time is
> taking 15 seconds to be executed on my laptop. So a value of 300 seems very
> reasonable.
>
> Now, with this, the unit test that is waiting forever will tiemout, and
> we'll see it in the logs.
Looks reasonable. Let's see how it works for the next time.
> I'm closing this bug right now. If you see non-deterministic unit tests
> again, please file a new one, with the unit test that breaks, and I'll be
> able to do something this time.
Ok. The last version uploaded built ok in my environment, but it was
tried only once, so if this is still random or not, we can't tell yet.
I'm tagging this bug as fixed in the current version to be consistent
with your request to file a new bug if we see errors again.
Thanks.
