Hi Efraim, Efraim Flashner <[email protected]> writes: > In glib-2.68 test_timeout and test_timeout_slow are set to 60 and 180 > respectively.
Right. Unfortunately, these timeouts are too short for many slower machines, such as 32-bit ARM systems. Bone Baboon has also recently reported being unable to build 'glib' on a 32-bit i686 system due to these timeouts, even when making extreme efforts to reduce load from other processes. > As I understand it, the tests which are are tagged '+slow' get the > test_timeout_slow property, with the test taking the longest on that > machine was glib:glib+slow / gvariant, at 65 seconds. By comparison, on > my Ryzen 3900XT machine it took 2.58 seconds. I figured even at double > that time it still fell within the 180 seconds given by default in the > test suite so it was likely safe to remove the substitution entirely. I think that this recently-reported bug (<https://bugs.gnu.org/48024>) demonstrates that we can't safely remove the substitution. > I don't have other suitably slow hardware to test on, but I am building > it on my aarch64 board too, so I should be able to say in a day or two > if it works there. I don't see how a build test on your aarch64 board is relevant here. As the comment above the 'increase-test-timeout' phase indicated, the timeouts were increased for the sake of slower 32-bit ARM boards. I think that we should re-introduce the 'increase-test-timeout' phase for all systems on the 'core-updates' branch. Is there a disadvantage, besides having to wait a couple more minutes if a test fails to terminate? What do you think? Regards, Mark -- Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
