0.25.0: Five failing tests #4762
Comments
|
Hmm, first one looks a little strange to me, can you try the above PR and see if that fixes it? The rest all look like "the same" bug, I will take a look at those in a bit. |
|
@elParaguayo I have spent a while staring at this, and I don't think I see why it fails. I expect that something about the arch packaging environment is causing this weirdness, but it looks to me like you've monkeypatched most (all?) of that. |
|
Fair enough. Let me take a look. |
|
The math looks like it is pretty clearly ignoring the timezone delta, but I really don't understand why that would happen. |
|
If I run |
|
Fwiw the clock tests also fail for me on my machine (NixOS). They are also off with delta |
|
tests worked for me before 13e9ac8 |
|
Yes. There's no doubt that that's the cause bit y weird that it's passing for me and on CI. Will take a look later. |
This was previously removed, and now this test seems to depend on the environment it is being ran (?). This adds back the UTC offset of the timezone such that the delta is taken into account. Fixes qtile#4762
This was previously removed, and now this test seems to depend on the environment it is being ran (?). This adds back the UTC offset of the timezone such that the delta is taken into account. Fixes qtile#4762
This was previously removed, and now this test seems to depend on the environment it is being ran (?). This adds back the UTC offset of the timezone such that the delta is taken into account. Fixes qtile#4762
|
Give #4766 a shot |
This was previously removed, and now this test seems to depend on the environment it is being ran (?). This adds back the UTC offset of the timezone such that the delta is taken into account. Fixes qtile#4762
This was previously removed, and now this test seems to depend on the environment it is being ran (?). This adds back the UTC offset of the timezone such that the delta is taken into account. Fixes #4762
|
@jwijenbergh did the first test pass for you? That's not related to the |
|
Sorry GitHub auto closed this, the first one might be an issue yeah |
We were previously using `manager_nospawn`, which is a fixture that enables
the test for both backends, even though this test is x11 specific. You can
see this with the failed test name+params here:
FAILED test/backend/x11/test_window.py::test_urgent_hook_fire[wayland-2]
instead, let's introduce our own xmanager_nospawn, and use that.
This is the other half of qtile#4762
Signed-off-by: Tycho Andersen <tycho@tycho.pizza>
We were previously using `manager_nospawn`, which is a fixture that enables
the test for both backends, even though this test is x11 specific. You can
see this with the failed test name+params here:
FAILED test/backend/x11/test_window.py::test_urgent_hook_fire[wayland-2]
instead, let's introduce our own xmanager_nospawn, and use that.
This is the other half of qtile#4762
Signed-off-by: Tycho Andersen <tycho@tycho.pizza>
We were previously using `manager_nospawn`, which is a fixture that enables
the test for both backends, even though this test is x11 specific. You can
see this with the failed test name+params here:
FAILED test/backend/x11/test_window.py::test_urgent_hook_fire[wayland-2]
instead, let's introduce our own xmanager_nospawn, and use that.
This is the other half of #4762
Signed-off-by: Tycho Andersen <tycho@tycho.pizza>
|
I think these are all resolved now. |
Issue description
Hi 馃憢
I'm currently upgrading the package on Arch Linux to 0.25.0 and ran into failing tests:
qtile-0.25.0-1-x86_64-check.log
qtile-0.25.0-1-x86_64-build.log
In regards to how tests are run, nothing has been changed since last upgrade:
https://gitlab.archlinux.org/archlinux/packaging/packages/qtile/-/blob/c9582a5362b017c90a6f3c06b57003dd1326901b/PKGBUILD
Version
0.25.0
Backend
X11 (default), Wayland (experimental)
Config
No response
Logs
No response
Required
The text was updated successfully, but these errors were encountered: