gnome :: #gnome

17 Jul 2017
10:55dickHi!
10:55dickI am trying to write a small patch for gnome-terminal. What I want to achieve is to make it warn whenever a user tries to paste several lines, something which on linux systems might happen a bit to easily.
10:56dickI've read somewhere (random reddit comment) that this is supposed to be built in functionallity however while I've tried it it doesnt alert me
10:57dickHowever debugging the process is a bit tricker than I'd expected, since the first process spawns a executable (gnome-terminal-server) via DBUS
10:58dickIf anybody here could kindly point me in the right direction I would be very grateful!
12:54T-Onehello
12:55T-Onethe epiphany address list overlays the gnome on screen keyboard on my touch device, can i fix this somehow? it's a bit annoying
14:02hussamis there a tracking page somewhere with a list of projects still using gnome-common?
15:55Noxbruhi, I have a quick question about evince, given that that channel seems to be a bit quiet
15:55Noxbruis it possible to be able to see one page of a pdf document while reading the rest?
15:55Noxbruin my case I have a page with nomenclature and I have to check it over and over and I'd prefer if I could have it on one side or something
16:10andreNoxbru: ermm, open the file twice, in two separate windows?
16:11Noxbrutried that
16:11Noxbrufrom nautilus, from the terminal and opening evince and then opening the file
16:11Noxbrunone works, always goes to the one I already have opened
16:11andretrue :(
16:36kailuekeNoxbru: nautilus preview with spacebar?
16:36Noxbrukailueke: I have been suggested that in #evince, and it works, not ideal but good enough :)
21:00autarchIs this an appropriate place to ask a question about a problem with the interaction between network-manager and gnome-keyring-daemon via dbus?
21:07borschtydepends on the question
21:38autarchso I have an openvpn VPN configured in NM - it was working fine with a stored password - now when i try to connect I eventually get this in the log - &quot;<error> [1500325135.0223] vpn-connection[0x12d3250,7e8d8894-302e-40dd-837b-073e80dd4fce,&quot;ActiveState VPN&quot;,0]: Failed to request VPN secrets #3: No agents were available for this request.&quot;
21:38autarchI enabled debugging for NM and saw this ... &quot;<debug> [1500324887.6943] agent-manager: req[0xcbb5c0, :1.209/org.gnome.Shell.NetworkAgent/1000]: a
21:38autarchgent failed secrets request [0x7f83b4006000/&quot;ActiveState VPN&quot;/&quot;vpn&quot;]: Internal error while retrieving secrets from the keyring (Error calling StartServiceByName for org.freedesktop.secrets: Timeout was reached)&quot;
21:40autarchI&#39;m on Ubuntu 16.04 - it was working fine last week, and then started not working - not sure what packages might&#39;ve been upgraded
21:41borschtydid you maybe restart your session?
21:42borschtythere was some bug where gnome-keyring stayed around after logging out when using systemd user sessions or something like that
21:43borschtythat means there was already an instance running but on the old dbus session and it was preventing gnome-keyring from starting for the current session
21:44autarchborschty: yeah, I&#39;ve rebooted a couple times
21:45autarchthat did not help at all
21:45borschtythen try checking your logs for anything that could indicate why gnome-keyring fails to start
21:47autarchI think it _is_ starting, that&#39;s the odd thing - I have a bunch of this in my logs - &quot;org.freedesktop.secrets[19255]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh&quot;
21:48autarchwhich is what I see if I run &quot;/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets&quot; manually
21:48autarchbut I don&#39;t see that log message directly after the vpn stuff - it just happens at other times - so sometimes dbus can start it and sometimes not? when it&#39;s not working there&#39;s no mention of the keyring daemon in the logs at all
21:49autarchI note that the error from NM does say &quot;Timeout was reached&quot;, so maybe it just takes ridiculously long to start for some reason?
21:50autarchor it starts and exits immediately
21:51autarchhmm, I think it&#39;s supposed to start and exit, actually
21:54autarchok, I do see the SSH_AUTH_SOCK output in the log immediately after NM does the d-bus request for org.freedesktop.secrets
21:55autarchso clearly it&#39;s invoking gnome-keyring-daemon and _something_ is happening - whether it&#39;s the right thing, I have no idea
21:59borschtygnome-keyring-daemon is not supposed to exit immediately, it is supposed to stay around for the length of the session
22:01borschtyand it is supposed to be started on login, so there should be no need to start it via bus activation
22:01borschtydid you maybe change your login managers?
22:06autarchso I have another keyring daemon that&#39;s already around from login
22:06autarchI&#39;m using lightdm
22:25borschtythere should only be one keyring daemon and it should be using the org.freedesktop.secrets name, otherwise any attempts to access this will result in another keyring being started
22:25autarchhow does it use that name?
22:25autarchbut it sounds like you&#39;ve identified the underlying problem
22:26autarchwhat exactly is starting the keyring daemon when I log in?
22:49borschtyit registers the name on the dbus session daemon
22:49autarchhow can I tell if this is being done correctly?
22:50borschtyyou can check using d-feet for example
22:50borschtyunder session bus, check which process owns the name
22:50autarchso I just ran &quot;gnome-keyring-damon -r -d&quot; from the CLI, then I went to the VPN config and entered the password again - I was prompted to unlock my keyring so I did - then I was able to connect to the VPN
22:51autarchbut apparently I broke my network in some other wya ...
22:53autarchwell, logged out and back in and now it&#39;s back to where it was
22:54borschtyyou are on a new dbus session now, everything you did on your old session has no impact on this
22:55autarchyeah, I know
22:56autarchI was vaguely hoping that I somehow reset something
22:56cfochHi
22:56autarchso if I run d-feet and click on the &quot;org.freedesktop.secrets&quot; entry I eventually get an error about the service timing out
22:56autarchand there&#39;s no object path shown in d-feet
22:57cfochhow do I execute the default signal handler inside another signal handler of the same signal?
22:57autarch&quot;org.freedesktop.secrets : g-io-error-quark: Timeout was reached (24)&quot;
22:57borschtycfoch, #gtk+ is a better channel for glib related questions
22:58borschtyautarch, so it&#39;s not running and fails to start
22:58autarchyep
22:58borschtybut it works if you start it manually?
22:58autarchapparently so
22:59autarchexcept of course, it _is_ running - &quot;/usr/bin/gnome-keyring-daemon --daemonize --login&quot; is in my &quot;ps ax|grep keyring&quot; output
22:59borschtyfor your user?
23:00autarchgood question - I killed it to see if it&#39;d restart - guess I need to log out and in again
23:01autarchthere are two procs, one running as lightdm and one as me
23:01borschtywhat is the content of &quot;/usr/share/dbus-1/services/org.freedesktop.secrets.service&quot;?
23:03autarchhttps://gist.github.com/autarch/1a51d6dd394ab002deeaebdab6724065
23:04borschtywhat happens if you manually run that command?
23:04borschtythe one under exec
23:04autarchI get &quot;SSH_AUTH_SOCK=/run/user/1000/keyring/ssh&quot; and the daemon exits
23:05autarchoh, btw now there&#39;s only one keyring-daemon proc running - as me now
23:07borschtywhat is its exact commandline?
23:07autarch/usr/bin/gnome-keyring-daemon --daemonize --login
23:08borschtymaybe ubuntu somehow changed it to not load the secrets component by default and then the other keyring daemon fails to start because there already is a running keyring daemon
23:09autarchwouldn&#39;t every ubuntu user be screaming about this? I came to this channel after lots of googling
23:10autarchit looks like running &quot;gnome-keyring-daemon -r -d&quot; fixes things - I think I&#39;ll add this to me session startup - it&#39;s terrible, but I have to go out now and stop banging my head against this keyboard - it&#39;s very bloody
23:11autarchthough if you have other ideas I&#39;m happy to try them later
23:12borschtyno idea how it is *supposed* to be started on ubuntu with lightdm, on gdm it should be started via pam, but maybe ubuntu does things there differently as well
23:12autarchlightdm has the gnome keyring stuff set up via pam
23:12autarchI suppose I could switch to gdm - I have no attachment to lightdm
23:13borschtyi guess the question is why the keyring daemon started on login doesn&#39;t register the secrets name
23:15borschtyeither it is some ubuntu magic, or something else is already using that name (though i think dbus would remove the name from the old process then, but i don&#39;t remember how exactly that works) or there is something in your config that tells it to not use the secrets component
23:19borschtymaybe you have some kde equivalent of gnome-keyring installed that is started somehow and takes the name before gnome-keyring has the chance and then exits at some point
18 Jul 2017
No messages
   
Last message: 8 days and 15 hours ago