astroid
astroid copied to clipboard
tests shouldn't require X
#410, distros like running tests (if there are any), but really don't like running X or even Xvfb. you might get away with it in Gentoo or Arch, but Debian and Fedora won't be happy about it.
Alex Xu writes on July 5, 2018 4:02:
#410, distros like running tests (if there are any), but really don't like running X or even Xvfb. you might get away with it in Gentoo or Arch, but Debian and Fedora won't be happy about it.
Agreed. None of the tests actually rely on X. Which test is it that crashes without X?
er... I deleted the build logs, but I can scrounge them back up. I also added a workaround to force the tests to run one at a time (-j1) instead of Gentoo's default of using the make jobs count. that might've fixed it too. are there known bugs on that front? in particular, I had some strange gnupg errors.
I'll try again without using Xvfb and see what happens.
It is a bit tricky to get a clean gpg env, in particular the agent. Try to do gpgagent —kill-all
tor. 5. jul. 2018 kl. 15:30 skrev Alex Xu [email protected]:
I'll try again without using Xvfb and see what happens.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/astroidmail/astroid/issues/516#issuecomment-402722405, or mute the thread https://github.com/notifications/unsubscribe-auth/AADd-wjaLqDR3nW5L3n8NxGgkg4lJpk7ks5uDhUPgaJpZM4VDJln .
I do not use gpg agent, portage doesn't run one, and it runs as a separate user anyways.
Alex Xu writes on July 5, 2018 16:28:
I do not use gpg agent, portage doesn't run one, and it runs as a separate user anyways.
gpg2 needs one.
Need logs or will close this one. You can use ctest --output-on-failure. Try to do gpgconf --kill all first as well as try to use a clean build dir.
example output:
10/16 Testing: bad_content_id
10/16 Test: bad_content_id
Command: "/tmp/portage/mail-client/astroid-9999/work/astroid-9999_build/tests/run_test.sh" "/tmp/portage/mail-client/astroid-9999/work/astroid-9999" "/tmp/portage/mail-client/astroid-9999/work/astroid-9999_build" "test_bad_content_id"
Directory: /tmp/portage/mail-client/astroid-9999/work/astroid-9999_build/tests
"bad_content_id" start time: Jul 05 20:25 EDT
Output:
----------------------------------------------------------
Source dir: /tmp/portage/mail-client/astroid-9999/work/astroid-9999
Build dir: /tmp/portage/mail-client/astroid-9999/work/astroid-9999_build
Running: test_bad_content_id..
/tmp/portage/mail-client/astroid-9999/work/astroid-9999_build /tmp/portage/mail-client/astroid-9999/work/astroid-9999_build/tests
No protocol specified
(test_bad_content_id:10603): Gtk-WARNING **: cannot open display: :1
Running 2 test cases...
<end of output>
Test time = 0.11 sec
----------------------------------------------------------
Test Failed.
"bad_content_id" end time: Jul 05 20:25 EDT
"bad_content_id" time elapsed: 00:00:00
----------------------------------------------------------
19% tests passed, 13 tests failed out of 16
Total Test time (real) = 3.97 sec
The following tests FAILED:
1 - generic (Failed)
2 - compose (Failed)
3 - non_existant (Failed)
4 - open_db (Failed)
5 - convert_error (Failed)
6 - no_newline (Failed)
7 - mime_message (Failed)
8 - theme (Failed)
9 - keybindings (Failed)
10 - bad_content_id (Failed)
13 - address (Failed)
14 - dates (Failed)
15 - crypto (Failed)
Errors while running CTest
Alex Xu writes on July 6, 2018 2:37:
example output:
(test_bad_content_id:10603): Gtk-WARNING **: cannot open display: :1
And I also get with:
$ DISPLAY= ninja test
Running: test_generic..
~/dev/mail/notm/astroid/build ~/dev/mail/notm/astroid/build/tests
Unable to init server: Could not connect: Connection refused
(test_generic:28493): Gtk-WARNING **: 14:21:13.844: cannot open display:
I think this is triggered in the constructor of
Astroid::Astroid : Gtk::Application (..), maybe it is possible to
initialize it in a way that does not require X or dbus etc. Otherwise we
have to re-design in order to still have an Astroid instance.
Ideally, it would be nice to test the GUI as well.. but I havn't really looked into options for that yet.
This issue is flagged "need-info" - is that still the case?
Jonas Smedegaard writes on October 1, 2018 10:45:
This issue is flagged "need-info" - is that still the case?
No, not really. Need-help is more appropriate ;)
I think this is triggered in the constructor of
Astroid::Astroid : Gtk::Application (..), maybe it is possible to initialize it in a way that does not require X or dbus etc. Otherwise we have to re-design in order to still have an Astroid instance. Ideally, it would be nice to test the GUI as well.. but I havn't really looked into options for that yet.
Is it really needed to inherit from Gtk::Application? I know too little about gtk but making the gtk::app instance a member of class Astroid or even a temporary might be a better design. That's at least how it's done in Qt.Then add a cmdlinearg "--testmode" or similar which skips initializing that app object.
ff2000 writes on May 4, 2020 11:10:
I think this is triggered in the constructor of
Astroid::Astroid : Gtk::Application (..), maybe it is possible to initialize it in a way that does not require X or dbus etc. Otherwise we have to re-design in order to still have an Astroid instance. Ideally, it would be nice to test the GUI as well.. but I havn't really looked into options for that yet.Is it really needed to inherit from Gtk::Application? I know too little about gtk but making the gtk::app instance a member of class Astroid or even a temporary might be a better design. That's at least how it's done in Qt.Then add a cmdlinearg "--testmode" or similar which skips initializing that app object.
Yes, I agree. I think it should be a member. Or Astroid-class is separated, and a new App-class unifies the two - the first is probably better, the second is perhaps more in style with rest of design + GTK.
-- gaute
fwiw, my initial comment was a bit strong. it's ok to require X in tests, but it should be actually necessary, i.e. you are actually testing the GUI. and even in that case, usually the GUI tests should automatically start Xvfb; let alone the general ick-factor, you don't want random windows popping up while you're just trying to build a package.