[opensuse] Last update of lightdm and shown users
Hi all, I am using openSUSE 12.3 and the last official update of lightdm has changed my choice of not showing users. Is this the expected behavior? How can I prevent this to happen again without having to check/adapt the conf file after each update (and possibly for each package involving a conf file)? Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-26 05:08, Andrea Turrini wrote:
Hi all, I am using openSUSE 12.3 and the last official update of lightdm has changed my choice of not showing users.
Run "rcrpmconfigcheck". Do you see some entry related to this? If you do see it, it is your job as system administrator to tend to them ;-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 27/03/14 19:54, Carlos E. R. wrote:
On 2014-03-26 05:08, Andrea Turrini wrote:
Hi all, I am using openSUSE 12.3 and the last official update of lightdm has changed my choice of not showing users.
Run "rcrpmconfigcheck". Do you see some entry related to this? If you do see it, it is your job as system administrator to tend to them ;-)
Thanks; this is the output: Please check the following files (see /var/adm/rpmconfigcheck): /etc/cups/cups-pdf.conf.rpmnew /etc/cups/cupsd.conf.rpmnew /etc/default/grub.rpmnew /etc/hp/hplip.conf.rpmsave /etc/lightdm/lightdm.conf.rpmsave /etc/zypp/zypp.conf.rpmnew /usr/share/fonts/encodings/encodings.dir.rpmsave /usr/share/fonts/misc/fonts.dir.rpmorig /usr/share/fonts/misc/fonts.dir.rpmsave /usr/share/fonts/truetype/fonts.dir.rpmorig /usr/share/fonts/truetype/fonts.scale.rpmorig OK, time to have a look at these rpmsave files... Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-27 13:31, Andrea Turrini wrote:
On 27/03/14 19:54, Carlos E. R. wrote:
/etc/lightdm/lightdm.conf.rpmsave
There you have it :-)
OK, time to have a look at these rpmsave files...
Right. Your config was replaced with a new one. I would make a backup of both files, old and new, then use "meld newfile oldfile". It is an editor that put both files in parallel, compares them, and highlights the differences. You can then copy sections from one version to the other, discard sections entirely, edit them, etc. Often what you get is an rpmnew file. I would do exactly the same, to find out what new config options they added and use them if I like them. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Thu, 27 Mar 2014 12:54:06 +0100 Carlos E. R. wrote:
... Run "rcrpmconfigcheck". Do you see some entry related to this? If you do see it, it is your job as system administrator to tend to them ;-) ... On Thu, 27 Mar 2014 13:42:31 +0100 Carlos E. R. wrote: ... Your config was replaced with a new one. I would make a backup of both files, old and new, then use "meld newfile oldfile". It is an editor that put both files in parallel, compares them, and highlights the differences. You can then copy sections from one version to the other, discard sections entirely, edit them, etc. ...
Why have I not heard of these two little gems until now, Carlos? What are you reading that I'm missing? :-) This combination certainly seems a little faster than what I'm used to and it is definitely more convenient. Meld has a pretty groovy launcher icon, too, for the GUI. Thank you very much for sharing! Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carl Hartung wrote: Meld has a pretty groovy launcher
icon, too, for the GUI. Thank you very much for sharing!
Trying to run it remotely though.... this is getting to be a real pain.
meld /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryCombo::history-id after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryEntry::history-id after class was initialised type_register(cls, namespace.get('__gtype_name__'))
(meld:39855): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Failed to connect to socket /tmp/dbus-V9CYFVcCNc: Connection refused /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryFileEntry::directory-entry after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryFileEntry::filename after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryFileEntry::default-path after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryFileEntry::modal after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryFileEntry::dialog-title after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryFileEntry::history-id after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: attempting to add an interface (GtkEditable) to class (HistoryFileEntry) after class_init type_register(cls, namespace.get('__gtype_name__')) (meld:39855): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Failed to connect to socket /tmp/dbus-V9CYFVcCNc: Connection refused /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property meld+ui+emblemcellrenderer+EmblemCellRenderer::icon-tint after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property meld+ui+emblemcellrenderer+EmblemCellRenderer::icon-name after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property meld+ui+emblemcellrenderer+EmblemCellRenderer::emblem-name after class was initialised type_register(cls, namespace.get('__gtype_name__')) Traceback (most recent call last): File "/usr/bin/meld", line 173, in <module> main() File "/usr/bin/meld", line 159, in main already_running, dbus_app = meld.dbus_service.setup(app) File "/usr/share/meld/meld/dbus_service.py", line 56, in setup bus = dbus.SessionBus() File "/usr/lib/python2.7/site-packages/dbus/_dbus.py", line 211, in __new__ mainloop=mainloop) File "/usr/lib/python2.7/site-packages/dbus/_dbus.py", line 100, in __new__ bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop) File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 122, in __new__ bus = cls._new_for_bus(address_or_type, mainloop=mainloop) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoServer: Failed to connect to socket /tmp/dbus-V9CYFVcCNc: Connection refused -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-28 03:40, Linda Walsh wrote:
Carl Hartung wrote: Meld has a pretty groovy launcher
icon, too, for the GUI. Thank you very much for sharing!
Trying to run it remotely though.... this is getting to be a real pain.
I use it remotely quite often, it works. It complains a bit, so what? :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-03-28 03:40, Linda Walsh wrote:
Carl Hartung wrote: Meld has a pretty groovy launcher
icon, too, for the GUI. Thank you very much for sharing!
Trying to run it remotely though.... this is getting to be a real pain.
I use it remotely quite often, it works. It complains a bit, so what? :-)
---- Urarg! But it exits to the command line before displaying anything. You get connnection refused from the remote client, but it still runs? Looking at the message on my traceback, it seems that a failure to connect to the desktop socket results in termination. Am I to understand that you get those same error messages but it works? *incredulous look*.? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2014-03-27 at 23:21 -0700, Linda Walsh wrote:
Carlos E. R. wrote:
I use it remotely quite often, it works. It complains a bit, so what? :-)
---- Urarg!
But it exits to the command line before displaying anything.
Not here. This is what I get: cer@Telcontar:~> ssh -X cer@minas-tirith.valinor Password: Last login: Fri Mar 28 13:43:01 2014 from elessar.valinor Have a lot of fun... cer@minas-tirith:~> meld p p1 /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryCombo::history-id after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryEntry::history-id after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryFileEntry::directory-entry after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryFileEntry::filename after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryFileEntry::default-path after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryFileEntry::modal after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryFileEntry::dialog-title after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property HistoryFileEntry::history-id after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: attempting to add an interface (GtkEditable) to class (HistoryFileEntry) after class_init type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property meld+ui+emblemcellrenderer+EmblemCellRenderer::icon-tint after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property meld+ui+emblemcellrenderer+EmblemCellRenderer::icon-name after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property meld+ui+emblemcellrenderer+EmblemCellRenderer::emblem-name after class was initialised type_register(cls, namespace.get('__gtype_name__')) Traceback (most recent call last): File "/usr/share/meld/meld/ui/historyentry.py", line 365, in <lambda> entry.connect("changed", lambda *args: self.emit("changed")) TypeError: <HistoryFileEntry object at 0x21893c0 (HistoryFileEntry at 0x1ff15f0)>: unknown signal name: changed Traceback (most recent call last): File "/usr/share/meld/meld/ui/historyentry.py", line 365, in <lambda> entry.connect("changed", lambda *args: self.emit("changed")) TypeError: <HistoryFileEntry object at 0x2189280 (HistoryFileEntry at 0x1ff1440)>: unknown signal name: changed And I get the 'meld' window, working fine.
You get connnection refused from the remote client, but it still runs? Looking at the message on my traceback, it seems that a failure to connect to the desktop socket results in termination.
No, no connection error. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlM1c9cACgkQtTMYHG2NR9VTcQCff1otWiz/0rkYLQnLAQrK0hId ICwAn0QrQLrXszBm/Mjv0Y+bJJiwLNu/ =zb2q -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
Urarg!
But it exits to the command line before displaying anything.
Not here.
This is what I get: ... I am getting a bit farther, but I still get a connection timeout.
Could you tell me what you get when you type: echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' in the local client before 'ssh', and then the same on the remote client. In my case, I have: law.Bliss> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' tcp:host=Athenae.hs.tlinx.org,port=47000,guid=94e7aeae46abdf95e9562eea53362166 1808 12582913 law.Bliss> ssh ishtar Ishtar:law> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' tcp:host=Athenae.hs.tlinx.org,port=47000,guid=94e7aeae46abdf95e9562eea53362166 1808 12582913 i.e. -- they show the same. But in the console, I see: (minus the python tracebacks) (meld:8431): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Over the network (wireshark), I saw ishtar (the remote sys) send 'AUTH EXTERNAL 35303133\r\n' and the local client responded: REJECTED EXTERNAL DBUS_COOKIE_SHA1 ANONYMOUS\r\n' So they are "talking" and saying they won't talk... oy. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-29 07:01, Linda Walsh wrote:
Carlos E. R. wrote:
I am getting a bit farther, but I still get a connection timeout.
Could you tell me what you get when you type: echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n'
in the local client before 'ssh', and then the same on the remote client.
+++······························· cer@Telcontar:~> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' unix:abstract=/tmp/dbus-jaontsAgqI,guid=4ce03300a65d0c645e8d245a533036b7 cer@Telcontar:~> ssh -X cer@AmonLanc.valinor Password: Last login: Sat Mar 29 22:14:34 2014 from telcontar.valinor Have a lot of fun... cer@AmonLanc:~> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' cer@AmonLanc:~> ·······························++- That's a laptop without gnome nor kde installed, because it is old and I use LXDE. It has some gtk and qt libraries, as required by dependencies by other packages - like meld, the qt flavour of yast, gkrellm... An this my relatively modern laptop, with both gnome and kde installed, I think. Gnome is installed, I tried it recently. KDE I don't remember: ······························· cer@Telcontar:~> ssh -X cer@minas-tirith.valinor Password: Last login: Sat Mar 29 22:22:22 2014 from elessar.valinor Have a lot of fun... cer@minas-tirith:~> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' cer@minas-tirith:~> ·······························++- On both machines meld works remotely. Both have Intel graphics.
In my case, I have: law.Bliss> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' tcp:host=Athenae.hs.tlinx.org,port=47000,guid=94e7aeae46abdf95e9562eea53362166
Curious, mine says "unix:abstract".
1808 12582913 law.Bliss> ssh ishtar
But it will not work that way, you need -X or -Y.
Ishtar:law> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' tcp:host=Athenae.hs.tlinx.org,port=47000,guid=94e7aeae46abdf95e9562eea53362166
1808 12582913 i.e. -- they show the same. But in the console, I see: (minus the python tracebacks) (meld:8431): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Because you are not using -X nor -Y, and it appears you have a dbus active, meld tries to use it, and fails, of course, it is on a different machine. In my case, I do not have a dbus on that session, so meld does not try. Look: +++······························· cer@Telcontar:~> ssh cer@AmonLanc.valinor Password: Last login: Sat Mar 29 22:18:07 2014 from telcontar.valinor Have a lot of fun... cer@AmonLanc:~> meld p p1 /usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning: could not open display warnings.warn(str(e), _gtk.Warning) /usr/bin/meld:150: GtkWarning: IA__gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed gtk.icon_theme_get_default().append_search_path(meld.paths.icon_dir()) Traceback (most recent call last): File "/usr/bin/meld", line 150, in <module> gtk.icon_theme_get_default().append_search_path(meld.paths.icon_dir()) AttributeError: 'NoneType' object has no attribute 'append_search_path' cer@AmonLanc:~> cer@AmonLanc:~> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' cer@AmonLanc:~> ·······························++- Well, I do not get a dbus, but you see meld fails completely if I don't use the "-X" option to ssh. A different reason, thoug, it doesn't say anything about dbus. Both machines behave the same. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-03-29 07:01, Linda Walsh wrote:
Carlos E. R. wrote: I am getting a bit farther, but I still get a connection timeout.
Could you tell me what you get when you type: echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n'
in the local client before 'ssh', and then the same on the remote client. +++······························· cer@Telcontar:~> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' unix:abstract=/tmp/dbus-jaontsAgqI,guid=4ce03300a65d0c645e8d245a533036b7 cer@Telcontar:~> ssh -X cer@AmonLanc.valinor Password: Last login: Sat Mar 29 22:14:34 2014 from telcontar.valinor Have a lot of fun... cer@AmonLanc:~> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' cer@AmonLanc:~> ······························· So on Telcontar, you have only the DBUS_SESSION_BUS_ADDRESS set, but when you login, you don't get anything passwd..
That's a laptop without gnome nor kde installed, because it is old and I use LXDE. It has some gtk and qt libraries, as required by dependencies by other packages - like meld, the qt flavour of yast, gkrellm...
---- That meaning 'AmonLack.valinor?
An this my relatively modern laptop, with both gnome and kde installed, I think. Gnome is installed, I tried it recently. KDE I don't remember:
······························· cer@Telcontar:~> ssh -X cer@minas-tirith.valinor Password: Last login: Sat Mar 29 22:22:22 2014 from elessar.valinor Have a lot of fun... cer@minas-tirith:~> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n'
I.e minas-tirith is a newer laptop you are logging into? (sounds a bit topsy turvy -- i.e. normally one logs in from laptops to a server, but you are loggin from ??something to 2 different laptops -- assume for testing?
cer@minas-tirith:~> ·······························++- On both machines meld works remotely. Both have Intel graphics.
--- AFAIK, meld doesn't try to use 3D graphics, so that shouldn't matter... what's happening is meld on the remote machine is trying to contact or register with the session manager of the "you" who is logging into the machine (at least that what it appears to be doing in my situation.
In my case, I have: law.Bliss> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' tcp:host=Athenae.hs.tlinx.org,port=47000,guid=94e7aeae46abdf95e9562eea53362166
Curious, mine says "unix:abstract".
---- unix:abstrict is "sorta" the default. The above is partly from /etc/dbus-1/session.conf -- where you specify the address for it to listen on. Since I want Athenae to hear Ishtar's request, I setup a tcp host+port for it to connect to -- that's what the 'conversation' I looked at with Wireshark was going to/from.
1808 12582913 law.Bliss> ssh ishtar
But it will not work that way, you need -X or -Y.
---- Those -X is enabled in my /etc/ssh/sshd_config file... as it's something I always want. #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no X11Forwarding yes #X11DisplayOffset 10 --- Though it doesn't matter too much, since my DISPLAY!=localhost:xxxx, but DISPLAY=athenae.hs.tlinx.org:0 So it doesn't go through ssh anyway (it's a secure line -- I mean it's a direct connect from my computer to the other (no routers/switches... just card->card). And the other "-Y", is in my /etc/ssh/ssh_config file...for similar reasons: ForwardX11Trusted yes # RhostsRSAAuthentication no
Ishtar:law> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' tcp:host=Athenae.hs.tlinx.org,port=47000,guid=94e7aeae46abdf95e9562eea53362166
1808 12582913 i.e. -- they show the same. But in the console, I see: (minus the python tracebacks) (meld:8431): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Because you are not using -X nor -Y, and it appears you have a dbus active, meld tries to use it, and fails, of course, it is on a different machine.
---- Well.. both are in effect, actually, BUT it should make no difference, as they should be able to go direct -- which is what I see on the wire. I.e. ishtar(remote) sends some security 'auth' question to the local machine -- and local machine sends back authorization denied.
In my case, I do not have a dbus on that session, so meld does not try.
--- On which sess...oooo....*blink*....OOOOOO.... so meld doesn't need a session to run. *lightbulb* ARG!... I had read the manpage for dbus and it told me to put code in my bashrc to have it set... So for this util it doesn't need setting!
Look: ...
Well, I do not get a dbus, but you see meld fails completely if I don't use the "-X" option to ssh. A different reason, thoug, it doesn't say anything about dbus.
Both machines behave the same.
Yah... my case was cuz I read in the manpage that I needed to have it set when I logged in. Also, an "icing on the cake thing" would be if I had an app running on a remote desktop that tried to lauch a browser, ideally it would launch it locally from my local machine rather than brining up firefox over X... But just getting things to working some... Hey... was able to bring up plasma desktop. Yips .. 1st time in ~ 3 years... Though my 'X' server kept crashing when I tried to drag the activities bar at the bottom off to the side. But wallpaper had fade-in/fade-out, Bouncy ball bounced around... it was only slightly "laggy" for the little testing I did... but for a remote desktop... not be... this is progress... Tried to download new widgets and they would just 'fail'... not sure why. That one's sorta annoying -- remember that working at one point as well.. But progress was had and there was much rejoicing in the land!... ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-30 03:34, Linda Walsh wrote:
Carlos E. R. wrote:
So on Telcontar, you have only the DBUS_SESSION_BUS_ADDRESS set, but when you login, you don't get anything passwd..
Right.
That's a laptop without gnome nor kde installed, because it is old and I use LXDE. It has some gtk and qt libraries, as required by dependencies by other packages - like meld, the qt flavour of yast, gkrellm...
That meaning 'AmonLack.valinor?
Yes.
An this my relatively modern laptop, with both gnome and kde installed, I think. Gnome is installed, I tried it recently. KDE I don't remember:
······························· cer@Telcontar:~> ssh -X cer@minas-tirith.valinor Password: Last login: Sat Mar 29 22:22:22 2014 from elessar.valinor Have a lot of fun... cer@minas-tirith:~> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n'
I.e minas-tirith is a newer laptop you are logging into?
Yep.
(sounds a bit topsy turvy -- i.e. normally one logs in from laptops to a server, but you are loggin from ??something to 2 different laptops -- assume for testing?
That's right :-) AmonLanc is an old 32 bit laptop (Pentium 4 at 2.80GHz) I use as a small low power server, used 24/7 when needed. It is sitting with the bottom cover removed, over a laptop cooling fan. I got the laptop free, the owner did not want it, too old for recent Windows, he said. It has 500MB RAM and a 40 GB internal disk only, but new (the original was beyond repair), and a big external disk via USB. At the time (early 2000s?) it must have been a real expensive laptop, a beauty. No wifi, though. minas-tirith is my "real" laptop; when at home I do not use it, but I do maintenance on it via ssh from the big desktop machine. The keyboard of the desktop is much better, and the sitting position is more comfortable. And I also use it for network tests, like now. I also double boot it in Windows when needed, but then it is called Minas-Morgul ;-) A bit of chit-chat :-)
cer@minas-tirith:~> ·······························++- On both machines meld works remotely. Both have Intel graphics.
AFAIK, meld doesn't try to use 3D graphics, so that shouldn't matter... what's happening is meld on the remote machine is trying to contact or register with the session manager of the "you" who is logging into the machine (at least that what it appears to be doing in my situation.
Yes.
In my case, I have: law.Bliss> echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n' tcp:host=Athenae.hs.tlinx.org,port=47000,guid=94e7aeae46abdf95e9562eea53362166
Curious, mine says "unix:abstract".
---- unix:abstrict is "sorta" the default. The above is partly from /etc/dbus-1/session.conf -- where you specify the address for it to listen on. Since I want Athenae to hear Ishtar's request, I setup a tcp host+port for it to connect to -- that's what the 'conversation' I looked at with Wireshark was going to/from.
I've never tried to configure dbus.
But it will not work that way, you need -X or -Y.
Those -X is enabled in my /etc/ssh/sshd_config file... as it's something I always want.
Ahh... Try it on the command line, just in case :-?
In my case, I do not have a dbus on that session, so meld does not try.
On which sess...oooo....*blink*....OOOOOO....
so meld doesn't need a session to run. *lightbulb*
ARG!... I had read the manpage for dbus and it told me to put code in my bashrc to have it set...
So for this util it doesn't need setting!
Oh. Glad you found it... I'm too sleepy, I don't understand a word :-)
But progress was had and there was much rejoicing in the land!... ;-)
Good! Off to bed. Argh! Tonight it is time savings change. The night is one hour shorter. The computer clock says it is 4:30 AM, my body says it is 3:30 AM. I hate time change. My body suffers, my digestion suffers, I don't save a penny - despite what politicians say - and I have to go round adjusting clocks. I hate it! -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2014-03-29 07:01, Linda Walsh wrote:
Carlos E. R. wrote:
Urarg!
But it exits to the command line before displaying anything.
Not here.
This is what I get: ... I am getting a bit farther, but I still get a connection timeout.
Could you tell me what you get when you type: echo $DBUS_SESSION_BUS_{ADDRESS,{P,WINDOW}ID}$'\n'
There is a related post in the forum, from yesterday, talking about getting emacs to work remotely: View this thread: <http://forums.opensuse.org/showthread.php?t=495973> The suggestion is to use: for f in $(dbus-launch); do echo $f; export $f; done on the remote session, I understand. cer@Telcontar:~> ssh -X cer@AmonLanc.valinor Password: Last login: Sun Mar 30 04:25:13 2014 from telcontar.valinor Have a lot of fun... cer@AmonLanc:~> for f in $(dbus-launch); do echo $f; export $f; done DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-QTQQjEBMBl,guid=86f1125aaf2a3a461c3a1bf053382a5c DBUS_SESSION_BUS_PID=9166 DBUS_SESSION_BUS_WINDOWID=176160769 cer@AmonLanc:~> But in my case, both emacs and meld work remotely. You can try to see if it makes a difference for you... If not, I suggest I ask on that forum thread ;-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-03-29 07:01, Linda Walsh wrote: There is a related post in the forum, from yesterday, talking about getting emacs to work remotely:
View this thread: <http://forums.opensuse.org/showthread.php?t=495973>
The suggestion is to use: for f in $(dbus-launch); do echo $f; export $f; done on the remote session, I understand.
But in my case, both emacs and meld work remotely. You can try to see if it makes a difference for you... If not, I suggest I ask on that forum thread ;-) ---- That's sorta what I had.... I tried to follow the manpage for dbus-launch... Gotta love this -- usually people have problems for not reading the docs... This seems to be a case of the opposite.....
## test for an existing bus daemon, just to be safe if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then ## if not found, launch a new one eval `dbus-launch --sh-syntax` echo "D-Bus per-session daemon address is: $DBUS_SESSION_BUS_ADDRESS" fi Thing is, If I logged in from a machine that already had DBUS setup, those vars woudl be exported to the remote session -- which was what we were seeing -- the idea being that your session is on the local machine and you want the remote stuff to run in your local session, so when remote program says 'bring up browser to (url:page_help)' it brings up the browser on your local machine with the correct address. Same with 'email' and other resources. What I do by deleting the DBUS settings from my .bashrc is (from dbus-launch): If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use D-Bus, by default the process will attempt to invoke dbus-launch with the --autolaunch option to start up a new session bus or find the existing bus address on the X display or in a file in ~/.dbus/session-bus/ Whenever an autolaunch occurs, the application that had to start a new bus will be in its own little world; it can effectively end up starting a whole new session if it tries to use a lot of bus services. This can be suboptimal or even totally broken, depending on the app and what it tries to do. There are two common reasons for autolaunch. One is ssh to a remote machine. The ideal fix for that would be forwarding of DBUS_SESSION_BUS_ADDRESS in the same way that DISPLAY is forwarded. In the meantime, you can edit the session.conf config file to have your session bus listen on TCP, and manually set DBUS_SESSION_BUS_ADDRESS, if you like. ^^^^ that's why I had the tcp in my forwardeed address. I had it set to listen, but it wasn't working. The second reason has to do with being able to 'su' to another user (like root) and still have the su'd settings routed correctly, but apparently, that part is not done yet (I'm so glad we are using complete and tested solutions--NOT) It's in trying to follow the documentation that I've been getting into trouble. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-30 21:07, Linda Walsh wrote:
It's in trying to follow the documentation that I've been getting into trouble.
Interesting. So, if you try a new user, and don't do anything, these programs will actually work for you :-) :-p -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-03-30 21:07, Linda Walsh wrote:
It's in trying to follow the documentation that I've been getting into trouble.
Interesting.
So, if you try a new user, and don't do anything, these programs will actually work for you :-) :-p
??? Not exactly... It still not allowing the remote apps to register with the local dbus server... I had it work maybe 1-2 times ... where Terminal launched and didn't give an error .... but I haven't been able to get any repeatability I DID have one of my remote windows come up in the wrong language -- I.e. LANG wasn't set properly on my PC box, so when I logged in UTF-8 wasn't working and one of the windows that used UTF8 chars, looked pretty bad... but other than that... Haven't figured out how to reliably let the remote apps target the local bus. It seemed to happen twice -- but the Terminal it launched was an iomonitor window that shows bar graphs of top io/procs mounted partitions and ethernet.... but I can't get a prompt from it... tried to launch an xterm as well, and then couldn't get it to work....ARG... well, have to try messing w/this again... some progress, but this is really like shooting in the dark... IF I can get the desktop up w/regular X, will have to see if I can get it to work with XDMCP... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-31 00:42, Linda Walsh wrote:
Carlos E. R. wrote:
well, have to try messing w/this again... some progress, but this is really like shooting in the dark...
Why don't you install a new system, in a spare partition, or virtualized, and try from there? It should work, as it works for me without configuring anything. Then compare both systems, find out what is different. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-03-31 00:42, Linda Walsh wrote:
Carlos E. R. wrote:
well, have to try messing w/this again... some progress, but this is really like shooting in the dark...
Why don't you install a new system, in a spare partition, or virtualized, and try from there? It should work, as it works for me without configuring anything. Then compare both systems, find out what is different. Cuz I haven't had the virtualization stuff work reliably recently.
The only thing that worked at all was back in 12.3 and that tainted my kernel... I *want* to get that working again... but things keep breaking faster than I can repair them....the switch to systemd didn't help at all among other things. .... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-31 02:52, Linda Walsh wrote:
Carlos E. R. wrote:
Cuz I haven't had the virtualization stuff work reliably recently.
The only thing that worked at all was back in 12.3 and that tainted my kernel... I *want* to get that working again... but things keep breaking faster than I can repair them....the switch to systemd didn't help at all among other things. ....
You can not fight all wars :-) I mean, you have to choose what you tinker with. Systemd is here to stay, like it or not, so better try to like it. Makes life easier. Only change the minimum on the system, leave everything you can to defaults. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-03-31 02:52, Linda Walsh wrote:
Carlos E. R. wrote:
Cuz I haven't had the virtualization stuff work reliably recently.
The only thing that worked at all was back in 12.3 and that tainted my kernel... I *want* to get that working again... but things keep breaking faster than I can repair them....the switch to systemd didn't help at all among other things. ....
You can not fight all wars :-)
I mean, you have to choose what you tinker with. Systemd is here to stay, like it or not, so better try to like it. Makes life easier. Only change the minimum on the system, leave everything you can to defaults.
Well 13.1 broke things on several levels. I have provided fixes for many breakages, that have been dropped on the floor with bugs coming out from factory 2 years later ( This is still a problem: http://lists.opensuse.org/opensuse/2011-10/msg00351.html Thought it was reported as I have a patch file... making sure it is reported here: https://bugzilla.novell.com/show_bug.cgi?id=861989 ). Along with others where I've submitted patches, attached to bug reports only to have them tossed. It's hard to make progress when you have active saboteurs working in factory who deliberately create things to break instead of being resilient. The defaults don't work for me. The defaults break standards as well. I take the defaults when I can, but new defaults are going in to mitigate damage from going against defaults earlier. Example 'protected_hardlinks' was put in to get around the bad standard of keeping /root on it's own partition. hardlinking to /etc/passwd in a user dir, tmp or var/tmp was impossible, but they wanted the 1 partition fits all solution, so the implement breaking hardlinks. Now you can't even make a linked copy of a kernel tree without being root or turning off "the suse defaults". It used to be you could link to any file you could 'read'. Now you need to have write permission -- but that only works for regular files. Symlinks -- you have to be the same UID as on the symlink to link to it -- group ownership/write ability has been disabled (kernel feature propagated by redhat). That really is a poorly thought out solution -- but it started because they told people to put everything on 1 partition. That was the bad advice in the first place. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-28 02:24, Carl Hartung wrote:
On Thu, 27 Mar 2014 12:54:06 +0100 Carlos E. R. wrote:
...
Why have I not heard of these two little gems until now, Carlos? What are you reading that I'm missing? :-)
X-)
This combination certainly seems a little faster than what I'm used to and it is definitely more convenient. Meld has a pretty groovy launcher icon, too, for the GUI. Thank you very much for sharing!
I know of "rcrpmconfigcheck" since years ago, perhaps a decade. When you boot on text mode after a system upgrade you see it run automatically and take a long time about it. It delays boot for a minute or two. Or maybe somebody told me about it. And meld I found out recently, a year or two ago. Somebody mentioned it and I found it wonderful for this task. I recently upgraded an LXDE machine; I wanted to use meld, so I installed enough of KDE deps to be able to use it... Previously I used diff in parallel columns, combined with visual inspection. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [03-27-14 23:29]: [...]
Previously I used diff in parallel columns, combined with visual inspection.
Cannot believe you never tried tkdiff which allows simultaneous editing and is somewhat adged. But having discovered meld some time ago is really a blessing :^) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2014-03-28 at 00:14 -0400, Patrick Shanahan wrote:
* Carlos E. R. <> [03-27-14 23:29]: [...]
Previously I used diff in parallel columns, combined with visual inspection.
Cannot believe you never tried tkdiff which allows simultaneous editing and is somewhat adged. But having discovered meld some time ago is really a blessing :^)
I don't remember. I installed "tkdiff" just now, and I could not make a thing with it. I simply copied a file to another one, added a line to the copy, and called tkdiff on both. It does detect easily the differences, but I see no way to copy one section from one side to the other. Yes, there are button arrows on top, but they do nothing. There is a menu entry that opens an editor, and apparently you have to open the separate editor and change the file yourself in there, not in the window that highlights the differences. Absurd. That is, I can not find out how to work with it, contrary to meld that is intuitive. Maybe I tried "tkdiff" years ago and abandoned it as well as useless. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlM1dhYACgkQtTMYHG2NR9WNQgCeKTBTTFaZPgYWuizEdUtuyA3k HWAAn0hHdEli51jSH2jm1aqrgOG2RsWi =eWwL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (5)
-
Andrea Turrini -
Carl Hartung -
Carlos E. R. -
Linda Walsh -
Patrick Shanahan