Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #235915 > unrolled thread

Complaints from mousepad.

Back to article view | Back to linux.debian.user

Contents

  Complaints from mousepad. peter@easthope.ca - 2021-06-06 16:30 +0200
    Re: Complaints from mousepad. Greg Wooledge <greg@wooledge.org> - 2021-06-06 17:00 +0200
      Re: Complaints from mousepad. peter@easthope.ca - 2021-06-06 20:40 +0200
        Re: Complaints from mousepad. Greg Wooledge <greg@wooledge.org> - 2021-06-06 21:10 +0200
          Re: Complaints from mousepad. peter@easthope.ca - 2021-06-07 05:20 +0200
    Re: Complaints from mousepad. Sascha Silbe <sascha-ml-reply-to-2021-2@silbe.org> - 2021-06-07 11:40 +0200
      Re: Complaints from mousepad. Greg Wooledge <greg@wooledge.org> - 2021-06-07 13:20 +0200
      Re: Complaints from mousepad. peter@easthope.ca - 2021-06-19 18:10 +0200

#235915 — Complaints from mousepad.

Hi,

The .bashrc here defines this function.

met () { case $# in
  0) mousepad --display=:0 /home/me/a & ;;
  1) mousepad --display=:0 $1 & ;;
  *) echo "Too many arguments." ;;
  esac
  }

mousepad works as expected but messages such as this are spewed to the 
terminal.

(mousepad:8747): dconf-WARNING **: 06:30:53.773: failed to commit 
changes to dco nf: Cannot autolaunch D-Bus without X11 $DISPLAY

How should the shell function or mousepad notify dconf that the 
display is :0?

Thanks,            ... Peter E.

-- 
tel: +1 604 670 0140            Bcc: peter at easthope. ca

[toc] | [next] | [standalone]

#235917

On Sun, Jun 06, 2021 at 06:43:31AM -0700, peter@easthope.ca wrote:
> Hi,
> 
> The .bashrc here defines this function.
> 
> met () { case $# in
>   0) mousepad --display=:0 /home/me/a & ;;
>   1) mousepad --display=:0 $1 & ;;
>   *) echo "Too many arguments." ;;
>   esac
>   }

OK, this shows the function definition.  Yu should quote "$1" but otherwise
it seems OK.

> mousepad works as expected but messages such as this are spewed to the 
> terminal.
> 
> (mousepad:8747): dconf-WARNING **: 06:30:53.773: failed to commit 
> changes to dco nf: Cannot autolaunch D-Bus without X11 $DISPLAY
> 
> How should the shell function or mousepad notify dconf that the 
> display is :0?

How and when do you actually *run* this function?  Is there actually
an X session running on :0 at the time?

I also went to <https://manpages.debian.org/buster/mousepad/mousepad.1.en.html>
to verify that --display= is actually a valid option for this program.
The man page says it is, so it seems you're "doing it correctly", but the
fact that you feel you *need* to specify the DISPLAY is a red flag.  It
means you're doing something weird, and you haven't said what that is yet.

Are you trying to run this function from the Linux console *before* you
do a startx?  If so, it'll obviously fail in exactly the kind of way
you're showing symptoms of.

Under normal operations, I would expect that you would start your X session
first, and then run this mousepad command inside of it.  Then it will
simply inherit the DISPLAY variable from the session.  In this case you
wouldn't need to specify the display at all.

[toc] | [prev] | [next] | [standalone]

#235919

    From: Greg Wooledge <greg@wooledge.org>
    Date: Sun, 6 Jun 2021 10:56:59 -0400
> Yu should quote "$1" but otherwise it seems OK.

Fixed.  Thanks.

> How and when do you actually *run* this function? 

Invoked from a telnet console running in LinuxAos on the same machine.
Similar to invoking from a plain text console on another machine on 
the LAN.

(I'm aware that telnet is not secure but the scenario is in a 
Shorewalled system.)

> Is there actually an X session running on :0 at the time?

Always.  LinuxAos is a graphical application.

> Are you trying to run this function from the Linux console *before* you 
> do a startx? 

Never.

Now tried this analogue.  Start mousepad from a ssh console on another 
machine on the LAN. 

No dconf-WARNING but this message is spewed.

(mousepad:13080): Gtk-WARNING **: 10:57:15.680: Theme parsing error: 
<data>:2:29: The style property GtkButton:default-border is deprecated 
and shouldn't be used anymore. It will be removed in a future version

> Under normal operations, I would expect that you would start your X session 
> first, and then run this mousepad command inside of it.  Then it will 
> simply inherit the DISPLAY variable from the session.  In this case you 
> wouldn't need to specify the display at all.

My conclusion: the ssh process handles something right for dconf.
LinuxAos fails to do that.

If someone has a more specific idea about dconf, it can help.

Thx,                                ... P.
 

-- 
tel: +1 604 670 0140            Bcc: peter at easthope. ca

[toc] | [prev] | [next] | [standalone]

#235920

On Sun, Jun 06, 2021 at 11:22:52AM -0700, peter@easthope.ca wrote:
> > How and when do you actually *run* this function? 
> 
> Invoked from a telnet console running in LinuxAos on the same machine.
> Similar to invoking from a plain text console on another machine on 
> the LAN.
> 
> (I'm aware that telnet is not secure but the scenario is in a 
> Shorewalled system.)

I'm struggling to understand what you've got here.  You're running *two*
operating systems on the same machine... at the same time?  Does this
mean the "LinuxAos" thing is in a virtual machine, or a container, or
something?

> > Is there actually an X session running on :0 at the time?
> 
> Always.  LinuxAos is a graphical application.

Is it an application?  Or is it an operating system?

> Now tried this analogue.  Start mousepad from a ssh console on another 
> machine on the LAN. 
> 
> No dconf-WARNING but this message is spewed.
> 
> (mousepad:13080): Gtk-WARNING **: 10:57:15.680: Theme parsing error: 
> <data>:2:29: The style property GtkButton:default-border is deprecated 
> and shouldn't be used anymore. It will be removed in a future version

> My conclusion: the ssh process handles something right for dconf.
> LinuxAos fails to do that.

Start at the beginning.  You're running Debian on the actual machine
itself, right?  And in Debian, you're running an X session, either
started by startx, or started by some sort of Display Manager?

>From host C on the LAN, you ssh into Debian (call that host A).  From
within the ssh session on host A, you type "met" to run this function?
And it works.

Now, on the other hand, you have this "LinuxAos" thing, which I'm going
to tentatively call "host B", even though I don't really know whether
it counts as a separate host or not.  And some part of host B is a telnet
client, and you use this telnet client to login to host A, and again,
you type "met", but this time it doesn't work?

Is that the full picture?

I think at bare minimum we need an understanding of what "LinuxAos" is
to even understand the architecture you've got here, before we can try
to debug it.

[toc] | [prev] | [next] | [standalone]

#235926

    From: Greg Wooledge <greg@wooledge.org>
    Date: Sun, 6 Jun 2021 15:06:03 -0400
> I'm struggling to understand what you've got here.  You're running *two*
> operating systems on the same machine... at the same time? 

In a sense, yes.  See following.

> Does this mean the "LinuxAos" thing is in a virtual machine, or a container, or
> something?
>
> Is it an application?  Or is it an operating system?

LinuxAOS (special case of UnixAOS) is analogous to DOSBox.  
https://en.wikipedia.org/wiki/DOSBox
https://en.wikibooks.org/wiki/Oberon/A2#Installing_and_Running_UnixAOS

Both are applications in the sense of running on a host system.  The 
application alone appears identical to the system running on native 
hardware.  DOSBox appears as DOS.  LinuxAOS appears as AOS.

> You're running Debian on the actual machine itself, right?  

Correct  Debian 10 on a bare PC.

> And in Debian, you're running an X session, either
> started by startx, or started by some sort of Display Manager?

Lightdm starts at system startup and starts X which runs until Debian 
is shut down.

This is the LAN with your nomenclature.
A  Debian 10 running directly on a bare PC.
B  LinuxAOS subsystem running in Debian on A.
C   OLPC adapted Fedora running on XO 1.5 laptop.

> From host C on the LAN, you ssh into Debian (call that host A).  From
> within the ssh session on host A, you type "met" to run this function?
> And it works.

Correct.  Works fine with "Gtk-WARNING ... Theme parsing error ..." 
emitted repeatedly to the starting ssh console on the laptop.

> And some part of host B is a telnet
> client, and you use this telnet client to login to host A, and again,
> you type "met", but this time it doesn't work?

It does work with repeated warning.  The telnet console in LinuxAos 
connects to localhost, A, and gives the A command line.  There the met 
function starts mousepad successfully and gives the dconf-WARNING 
repeatedly.

> Is that the full picture?

Yes.  

Summary
Mousepad is started two ways.  Each gives a working mousepad. Each 
gives repeated warnings; B warns about dconf; C warns about Gtk ... 
Theme parsing.

Full warnings in my earlier messages.

Thanks,                ... P.

-- 
tel: +1 604 670 0140            Bcc: peter at easthope. ca

[toc] | [prev] | [next] | [standalone]

#235928

[Multipart message — attachments visible in raw view] — view raw

Hello Peter,

peter@easthope.ca writes:

[...]
>   0) mousepad --display=:0 /home/me/a & ;;
[...]
> (mousepad:8747): dconf-WARNING **: 06:30:53.773: failed to commit 
> changes to dco nf: Cannot autolaunch D-Bus without X11 $DISPLAY
>
> How should the shell function or mousepad notify dconf that the 
> display is :0?

Have you tried setting the DISPLAY environment variable like the warning
mentions? That's the standard mechanism for X11 applications to know
which server to connect to.

Alternatively you might want to either start a D-Bus session explicitly
(using e.g. dbus-run-session) or connect to an existing D-Bus session
bus by extracting DBUS_SESSION_BUS_ADDRESS from the environment that has
a running D-Bus session and setting it in the environment where you want
to run mousepad. Which solution is better depends on which applications
you want to be able to talk to each other.

For example you could place this in your .xsession:

echo export DBUS_SESSION_BUS_ADDRESS="${DBUS_SESSION_BUS_ADDRESS}" > ~/.dbusaddr

And then in your met() function:

( source ~/.dbusaddr && exec mousepad --display=:0 /home/me/a ) &

The subshell ensures only mousepad sees
DBUS_SESSION_BUS_ADDRESS. Otherwise you'd get different behaviour from
various applications based on exactly when you started your editor. If
you want all applications to access this session bus, place "source
~/.dbusaddr" somewhere else. Just be careful where you place it; you
might end up overriding the address of the new session bus when you
start your X11 session.

Sascha

[toc] | [prev] | [next] | [standalone]

#235929

I deleted the OP's last message from this thread, and then soon afterward
came up with something I should have said.  So, there's no quoted context
here.  Sorry.

The OP is basically claiming that "telnet from Osa" and "ssh from
another machine" both *work*, but give different warning messages,
and now they want to know why the warnings are different.  (Because
they have too much free time or something.)

My first guess is there's a difference between the PAM configurations
for sshd and telnetd.  One might try comparing /etc/pam.d/sshd to
whatever the analogous file is for telnetd.

Or, it could be something that's hard-wired into sshd itself, perhaps
configured in the /etc/ssh/sshd_config file.

The interactions between various login services and the XDG Universe
(dbus and so on) is still somewhat opaque to me, but if the OP really
wants to know this stuff, that's the direction they need to look.

[toc] | [prev] | [next] | [standalone]

#236207

    From: Sascha Silbe <sascha-ml-reply-to-2021-2@silbe.org>
    Date: Mon, 07 Jun 2021 11:26:35 +0200
> Have you tried setting the DISPLAY environment variable like the warning
> mentions? That's the standard mechanism for X11 applications to know
> which server to connect to.

Additional observations.

peter@joule:/home/peter$ echo $PATH
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
peter@joule:/home/peter$ env | grep PATH

PATH exists, is non-empty and env doesn't report it.

peter@joule:/home/peter$ echo $HOME

HOME exists and is empty.

peter@joule:/home/peter$ echo $DISPLAY

DISPLAY exists and is empty.

Yes, this console works better when HOME and DISPLAY are defined 
after starting it.
export HOME="/home/peter/"
export DISPLAY=":0"

Thanks for the various replies,        ... P.

-- 
tel: +1 604 670 0140

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web