Summary: | kde-frameworks/kguiaddons-5.18.0 fails tests | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Paolo Pedroni <paolo.pedroni> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | x11 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
kguiaddons-5.18.0:20160113-094158.log.gz
screen.png |
Description
Paolo Pedroni
2016-01-13 11:21:55 UTC
Can you confirm that Xvfb is working correctly? All these bugs are likely the same issue with Xvfb, but I can't test against an xorg-server that's not in the tree yet. (In reply to Michael Palimaka (kensington) from comment #1) > Can you confirm that Xvfb is working correctly? First of all: I'm sorry, I didn't see these comments before I filed other 3 bugs. How can I check if Xvfb works fine? (In reply to Paolo Pedroni from comment #3) > How can I check if Xvfb works fine? I usually do some test like (each in a different console): $ Xvfb :4 $ DISPLAY=":4" kdialog --msgbox "bug 571730" $ DISPLAY=":4" xwd -root -silent | xwdtopnm | pnmtopng > /tmp/screen.png (In reply to Michael Palimaka (kensington) from comment #4) > (In reply to Paolo Pedroni from comment #3) > > How can I check if Xvfb works fine? > > I usually do some test like (each in a different console): > > $ Xvfb :4 > $ DISPLAY=":4" kdialog --msgbox "bug 571730" > $ DISPLAY=":4" xwd -root -silent | xwdtopnm | pnmtopng > /tmp/screen.png Then Xvfb seems to be working. I get an image of an open window with "bug 571730" and an "OK" button in it (attached below) Where do we go from here? Created attachment 422768 [details]
screen.png
Is there anything more I can do to help you? The tests tried to run on display :1 - is that definitely free (grepping ps aux and checking for /.X${displaynumber}-lock may help)? (In reply to Michael Palimaka (kensington) from comment #8) > The tests tried to run on display :1 - is that definitely free (grepping ps > aux and checking for /.X${displaynumber}-lock may help)? I'm using this box remotely, via ssh. The only X application running is the sddm display manager. 'ps aux | grep /.X:1-lock' yields nothing # ps aux | grep X root 1091 0.0 0.3 92576 40428 tty7 Ssl+ 10:07 0:00 /usr/bin/X -nolisten tcp -auth /var/run/sddm/{d8f6b25c-6cb4-411c-a1de-616a4c0bd9c7} -background none -noreset -displayfd 17 vt7 paolo 20966 0.0 0.0 13008 2212 pts/0 S+ 13:28 0:00 grep --colour=auto X # ps aux | grep sddm root 1090 0.0 0.1 72172 13300 ? Ss 10:07 0:00 /usr/bin/sddm root 1091 0.0 0.3 92576 40428 tty7 Ssl+ 10:07 0:00 /usr/bin/X -nolisten tcp -auth /var/run/sddm/{d8f6b25c-6cb4-411c-a1de-616a4c0bd9c7} -background none -noreset -displayfd 17 vt7 root 1884 0.0 0.0 69476 11652 ? S 10:08 0:00 /usr/libexec/sddm-helper --socket /tmp/sddm-authd4831c75-9515-4015-99fb-0ad9d221f89a --id 2 --start /usr/bin/sddm-greeter --socket /tmp/sddm-:0-pzaKzy --theme /usr/share/sddm/themes/maui --user sddm --greeter sddm 1887 0.0 0.0 13180 4180 ? Ss 10:08 0:00 /usr/lib/systemd/systemd --user sddm 1888 0.0 0.0 32324 1948 ? S 10:08 0:00 (sd-pam) sddm 1891 0.1 0.6 410704 74912 ? Sl 10:08 0:13 /usr/bin/sddm-greeter --socket /tmp/sddm-:0-pzaKzy --theme /usr/share/sddm/themes/maui sddm 1898 0.0 0.0 7880 1824 ? S 10:08 0:00 /usr/bin/dbus-launch --autolaunch 88c71c686f4286f9db03b58e00000014 --binary-syntax --close-stderr sddm 1899 0.0 0.0 10708 2404 ? Ss 10:08 0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session paolo 20991 0.0 0.0 13008 2112 pts/0 R+ 13:32 0:00 grep --colour=auto sddm This shows, AFAIK, that sddm is running on display :0 (please correct me if I'm wrong). Anyway, just to be sure, I downgraded xorg-server (to latest stable: 1.17.4) and xf86-input-evdev, and rebuild xf86-video-ati and mesa and tests fail anyway, so it is not caused by xorg-server-1.18.0. I also checked that Xvfb works as you directed in comment #4 and everything is fine. Are you using X forwarding at all? (In reply to Michael Palimaka (kensington) from comment #11) > Are you using X forwarding at all? No. >QXcbConnection: Could not connect to display :1
@x11, any idea why it might fail like this? Xvfb seems to be working fine.
Given that the first test succeeds and the subsequent ones fail, this could be an indication that Xvfb terminates after the first test for some reason. Note this was not reproducable while stable testing by Ago in bug #558460 * Starting Xvfb on $DISPLAY=1 ... >>> Working in BUILD_DIR: "/var/tmp/portage/kde-frameworks/kguiaddons-5.21.0/work/kguiaddons-5.21.0_build" Test project /var/tmp/portage/kde-frameworks/kguiaddons-5.21.0/work/kguiaddons-5.21.0_build Start 1: kwordwraptest 1/3 Test #1: kwordwraptest .................... Passed 0.10 sec Start 2: kcolorutilstest 2/3 Test #2: kcolorutilstest .................. Passed 0.43 sec Start 3: kiconutilstest 3/3 Test #3: kiconutilstest ................... Passed 0.10 sec 100% tests passed, 0 tests failed out of 3 Total Test time (real) = 0.63 sec * Tests succeeded. >>> Completed testing kde-frameworks/kguiaddons-5.21 |