The port devel/xdg-utils contains the script /usr/local/bin/xdg-screensaver That script depends on a program named "dcop", but the port does not depend on any other port that installs it. How-To-Repeat: Running under KDE 4.10.5, all installed ports up to date. $ xdg-screensaver status /usr/local/bin/xdg-screensaver: dcop: not found ERROR: kdesktop KScreensaverIface isEnabled returned ''
Responsible Changed From-To: freebsd-ports-bugs->gnome Over to maintainer (via the GNATS Auto Assign Tool)
(Please keep me CC'ed in your reply because GNATS sucks and I won't be notified otherwise) I'm surprised xdg-screensaver ended up choosing dcop in your case -- the script checks if KDE_FULL_SESSION and KDE_SESSION_VERSION are set and, in this case, chooses another program instead. Since you mention you're running KDE 4.10.5 yourself, those variables should be set. Can you show me what their values are before calling xdg-screensaver yourself?
Hello Raphael, On Fri, Sep 20, 2013 at 08:28:03AM -0300, Raphael Kubo da Costa wrote: > (Please keep me CC'ed in your reply because GNATS sucks and I won't be > notified otherwise) > > I'm surprised xdg-screensaver ended up choosing dcop in your case -- the > script checks if KDE_FULL_SESSION and KDE_SESSION_VERSION are set and, > in this case, chooses another program instead. > > Since you mention you're running KDE 4.10.5 yourself, those variables > should be set. > > Can you show me what their values are before calling xdg-screensaver > yourself? It seems that the problem is due to the fact I am using bash as shell! Using bash: $ xdg-screensaver status /usr/local/bin/xdg-screensaver: dcop: not found ERROR: kdesktop KScreensaverIface isEnabled returned '' $ echo $KDE_FULL_SESSION true $ echo $KDE_SESSION_VERSION 4 $ echo $SHELL /usr/local/bin/bash Then I switch to csh and it seems to work: $ csh % xdg-screensaver xdg-screensaver - command line tool for controlling the screensaver Synopsis xdg-screensaver suspend WindowID [etc ...] The funniest thing is that, now that I ran csh _once_, xdg-screensaver also started working with bash. And it did not in the first place, as you can see from above. I logged out and in from KDE, and it is still working with bash. I am quite confused... I cannot reboot my PC now, but do you think it's worth trying? Maybe something was mis-configured from the past, and running xdg-screensaver from csh fixed it? Thank you for taking care of this! -- rigo http://rigo.altervista.org
Arrigo Marchiori <ardovm@yahoo.it> writes: > I am quite confused... I cannot reboot my PC now, but do you think > it's worth trying? > > Maybe something was mis-configured from the past, and running > xdg-screensaver from csh fixed it? Hmm, this is weird :-) It would be good to try rebooting, yes, so that we can verify whether the problem comes back or not. If it does, please run xdg-screensaver with `bash -x' for us to get more information on where it is failing. Otherwise, I guess we can close this one as 'weird but cannot reproduce anymore'.
Hello Raphael, sorry for the noise. I believe that I did a wrong test yesterday, so please forget the funny "bash vs csh" thing. Here is what happens today, after a cold boot. Using bash: $ xdg-screensaver status /usr/local/bin/xdg-screensaver: dcop: not found ERROR: kdesktop KScreensaverIface isEnabled returned '' In the same xterm i run csh and retry: $ csh % xdg-screensaver status /usr/local/bin/xdg-screensaver: dcop: not found ERROR: kdesktop KScreensaverIface isEnabled returned '' Running sh -x, here is the debugging output (from bash): $ sh -x /usr/local/bin/xdg-screensaver status + check_common_commands status + [ 1 -gt 0 ] + parm=status + shift + [ 0 -gt 0 ] + [ -z '' ] + unset XDG_UTILS_DEBUG_LEVEL + [ 0 -lt 1 ] + xdg_redirect_output=' > /dev/null 2> /dev/null' + false + DEBUG 1 'mv -T not available' + [ -z '' ] + return 0 + MV=mv + echo -:0 + sed s/:/-/g + screensaver_file=/home/arrigo/.xdg-screensaver---0 + which lockfile + lockfile_command='' + which xprop + XPROP=/usr/local/bin/xprop + [ xstatus != x ] + action='' + window_id='' + action=status + detectDE + [ xtrue = xtrue ] + DE=kde + xscreensaver-command -version + grep XScreenSaver + [ status = resume ] + perform_action status + result=1 + [ status = resume ] + [ status = reset ] + screensaver_kde status + dcop kdesktop KScreensaverIface isEnabled /usr/local/bin/xdg-screensaver: dcop: not found + status='' + result=127 + [ x = xtrue ] + [ x = xfalse ] + echo 'ERROR: kdesktop KScreensaverIface isEnabled returned '\'\' ERROR: kdesktop KScreensaverIface isEnabled returned '' + return 1 + [ status = suspend ] + [ status = suspend ] + [ 127 -eq 0 ] + exit_failure_operation_failed + [ 0 -gt 0 ] + exit 4 $ I am not sure it is useful, but I can tell you that: $ xscreensaver-command -version prints out: xscreensaver-command: no screensaver is running on display :0 I hope this helps. Thank you and best regards, -- rigo http://rigo.altervista.org
Hello Raphael, it seems that the problem did not show up any more. I believe you can close this bug. Thank you again. For the record: here is a transcript of a ``successful'' run of xdg-screensaver. I am now using an up-to-date 9-STABLE with all updated ports. The first big difference is that, in the successful run, the command `hostname' is executed, and its output is used to build up the value of the $screensaver_file variable. In my ``unsuccessful run'', the command `hostname' was not run, and the corresponding part of that variable was left empty. Here is the transcript. $ sh -x /usr/local/bin/xdg-screensaver status + check_common_commands status + [ 1 -gt 0 ] + parm=status + shift + [ 0 -gt 0 ] + [ -z '' ] + unset XDG_UTILS_DEBUG_LEVEL + [ 0 -lt 1 ] + xdg_redirect_output=' > /dev/null 2> /dev/null' + false + DEBUG 1 'mv -T not available' + [ -z '' ] + return 0 + MV=mv + hostname + sed s/:/-/g + echo myhost-:0 + screensaver_file=/home/arrigo/.xdg-screensaver-myhost--0 + which lockfile + lockfile_command='' + which xprop + XPROP=/usr/local/bin/xprop + [ xstatus != x ] + action='' + window_id='' + action=status + detectDE + [ xtrue = xtrue ] + DE=kde + xscreensaver-command -version + grep XScreenSaver + gnome-screensaver-command -q + [ status = resume ] + perform_action status + result=1 + [ status = resume ] + [ status = reset ] + [ x4 = x4 ] + screensaver_freedesktop status + dbus-send --session --dest=org.freedesktop.ScreenSaver --type=method_call --print-reply --reply-timeout=2000 /ScreenSaver org.freedesktop.ScreenSaver.GetActive + grep boolean + cut -d ' ' -f 5 + status=false + result=0 + [ xfalse = xtrue ] + [ xfalse = xfalse ] + echo disabled disabled + [ status = suspend ] + [ status = suspend ] + [ 0 -eq 0 ] + exit_success + [ 0 -gt 0 ] + exit 0 Best regards, -- rigo http://rigo.altervista.org
It seems that the issue reported was due to misconfiguration on the submitter's side and it has been solved already, so I am closing this PR.