meson.build: increase timeout of pytest test #675
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This seems odd, my system here (not a particularly fast one...) finishes in under 4 seconds. I'd understand double that or triple that if the machine is under load but 82 seconds feels very wrong. There is one instance where it's asking for the password though (during test_hwdb_files I think) so maybe it's just hanging in that test? |
|
It did eventually pass after 82 seconds — would that be expected if it was hanging? |
|
tbh I don't know how long the timeout would be. If you run it as |
|
fwiw, e4ea346 may help too with the timeouts. |
|
I'll try it next time I'm building libwacom — thanks! |
|
Apologies, this is indeed an issue with the tests, I just didn't noticed because I either ran a subset of them or they all got skipped. Short answer: running systemd-hwdb and others on every test run is simply slow, so the whole |
Running pytest can take a while, especially if the system is already under load (for example, if it's building other packages at the same time as libwacom). Recently, I saw it take 82 seconds.
whot
added a commit
to whot/libwacom
that referenced
this pull request
May 14, 2024
Previously we'd create a uinput device for each of our tablets, then query udev if the property is set. This takes a long time, in parts thanks to the 300ms sleep to wait for the uinput device to be ready. With now over 500 tablet files and most of those having multiple matches we're looking at at minimum 500*0.3 seconds for a test run which isn't really useful for a test like this. Instead - let's query systemd-hwdb directly: construct a query string our udev rule and query systemd-hwdb for the properties, then ensure we have the ones we expect. Closes linuxwacom#675
whot
added a commit
to whot/libwacom
that referenced
this pull request
May 14, 2024
Previously we'd create a uinput device for each of our tablets, then query udev if the property is set. This takes a long time, in parts thanks to the 300ms sleep to wait for the uinput device to be ready. With now over 500 tablet files and most of those having multiple matches we're looking at at minimum 500*0.3 seconds for a test run which isn't really useful for a test like this. Instead - let's query systemd-hwdb directly: construct a query string our udev rule and query systemd-hwdb for the properties, then ensure we have the ones we expect. Closes linuxwacom#675
|
Closing this in favour of #694 which is a better fix since the test suite no longer takes forever with that fix. We might still need a timeout (e.g. it can take 22s on my machine which is close to the 30s timeout) but we shouldn't need a huge increase. |
whot
added a commit
to whot/libwacom
that referenced
this pull request
May 16, 2024
Previously we'd create a uinput device for each of our tablets, then query udev if the property is set. This takes a long time, in parts thanks to the 300ms sleep to wait for the uinput device to be ready. With now over 500 tablet files and most of those having multiple matches we're looking at at minimum 500*0.3 seconds for a test run which isn't really useful for a test like this. Instead - let's query systemd-hwdb directly: construct a query string our udev rule and query systemd-hwdb for the properties, then ensure we have the ones we expect. Closes linuxwacom#675
whot
added a commit
to whot/libwacom
that referenced
this pull request
May 16, 2024
Previously we'd create a uinput device for each of our tablets, then query udev if the property is set. This takes a long time, in parts thanks to the 300ms sleep to wait for the uinput device to be ready. With now over 500 tablet files and most of those having multiple matches we're looking at at minimum 500*0.3 seconds for a test run which isn't really useful for a test like this. Instead - let's query systemd-hwdb directly: construct a query string our udev rule and query systemd-hwdb for the properties, then ensure we have the ones we expect. Closes linuxwacom#675
whot
added a commit
to whot/libwacom
that referenced
this pull request
May 16, 2024
Previously we'd create a uinput device for each of our tablets, then query udev if the property is set. This takes a long time, in parts thanks to the 300ms sleep to wait for the uinput device to be ready. With now over 500 tablet files and most of those having multiple matches we're looking at at minimum 500*0.3 seconds for a test run which isn't really useful for a test like this. Instead - let's query systemd-hwdb directly: construct a query string our udev rule and query systemd-hwdb for the properties, then ensure we have the ones we expect. Closes linuxwacom#675
whot
added a commit
that referenced
this pull request
May 16, 2024
Previously we'd create a uinput device for each of our tablets, then query udev if the property is set. This takes a long time, in parts thanks to the 300ms sleep to wait for the uinput device to be ready. With now over 500 tablet files and most of those having multiple matches we're looking at at minimum 500*0.3 seconds for a test run which isn't really useful for a test like this. Instead - let's query systemd-hwdb directly: construct a query string our udev rule and query systemd-hwdb for the properties, then ensure we have the ones we expect. Closes #675
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Running pytest can take a while, especially if the system is already under load (for example, if it's building other packages at the same time as libwacom). Recently, I saw it take 82 seconds.