Hi Ara, Based on this info http://live.gnome.org/Orca/SysAdmin provided by Willi Walker, I'm able to use Update manager as a normal user with sudo permission.
Also, I have the following entries in /etc/sudoers file: Defaults env_keep+="GTK_MODULES" Defaults:halim env_keep+="ORBIT_SOCKETDIR DISPLAY" Thanks Nagappan On Fri, Aug 22, 2008 at 3:56 AM, Nagappan A <[EMAIL PROTECTED]> wrote: > Hi Ara, > > If at-poke recognizes, then I guess its bug in LDTP ! Will investigate it. > > Thanks > Nagappan > > > On Fri, Aug 22, 2008 at 12:34 AM, Ara Pulido <[EMAIL PROTECTED]> wrote: > >> >> More info on this: >> >> when at-poke does not crash, as I said, gksu (in the second and >> following times) is kept in the list of applications recognized by >> at-poke, though is not longer running. >> >> If I try to poke update-manager, it gets recognized corretly. If I try >> to poke gksu, at-poke crashes, as the application is not longer there. >> >> Cheers, >> Ara. >> >> >> On Fri, 2008-08-22 at 09:07 +0200, Ara Pulido wrote: >> > Hello Nagappan (et.al), >> > >> > This is the behaviour I watch when doing the same with at-poke: >> > >> > The first time update-manager is run: >> > >> > - update-manager gets recognized by at-poke >> > - when checking for new updates, gksu starts (it gets recognized by >> > at-poke), asking for the sudo password. >> > - when the password is checked and confirmed, gksu closes and it gets >> > deleted from the application list in at-poke. >> > - update-manager still gets recognized. >> > >> > >> > The following times update-manager is run: >> > >> > - update-manager gets recognized by at-poke >> > - when checking for new updates, gksu starts (it gets recognized by >> > at-poke), but it does not ask for the sudo password, as it is already >> > stored. >> > - This time gksu is kept in the list of recognized by at-poke (although >> > the process is not there anymore). >> > - This makes sometimes at-poke crash: >> > >> > (at-poke:6268): GLib-GObject-CRITICAL **: g_signal_connect_data: >> > assertion `G_TYPE_CHECK_INSTANCE (instance)' failed >> > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception >> > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' >> > >> > ** (at-poke:6268): CRITICAL **: get_accessible_at_index: assertion `ret' >> > failed >> > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception >> > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' >> > >> > >> > Any ideas? >> > Thanks, >> > Ara. >> > On Thu, 2008-08-21 at 08:38 -0700, Nagappan A wrote: >> > > Hi Ara, >> > > >> > > Could you please try the same procedure with at-poke ? >> > > >> > > Thanks >> > > Nagappan >> > > >> > > On Thu, Aug 21, 2008 at 2:50 AM, Ara Pulido <[EMAIL PROTECTED]> wrote: >> > > Hello all, >> > > >> > > Let me explain the situation I have been running lately: >> > > >> > > I am writing some tests for the Update Manager in Ubuntu [1]. >> > > This >> > > application searches for updates in the Ubuntu repositories >> > > and install >> > > the selected ones. >> > > >> > > The first time the application runs, if you check for new >> > > updates, it >> > > will ask for the SUDO password. The test runs correctly. >> > > >> > > The second time, as the SUDO password is valid for sometime, >> > > it does not >> > > ask for the password. In the test script this is solved with >> > > something >> > > like: >> > > >> > > if guiexist(SUDO_WINDOW): >> > > set_password() >> > > else >> > > do nothing >> > > >> > > After that the test tries to close the update-manager window. >> > > If the >> > > application asked for the password, it closes correctly, but >> > > if it >> > > bypasses the password (because it was already set), it does >> > > not find the >> > > update-manager anymore: >> > > >> > > Property: label - Value: Update Manager >> > > window_prop: Update Manager >> > > Key: btnClose btnClose >> > > Warning: AT-SPI error: pre method check: add: Unknown CORBA >> > > exception >> > > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' >> > > Application: update-manager not running >> > > Unable to get handle >> > > resp_len = 117 >> > > Sending.. >> > > 156 >> > > Response packet: <?xml version="1.0" >> > > >> > >> encoding="utf-8"?><RESPONSE><ID>MainThread43</ID><STATUS><CODE>-984</CODE><MESSAGE>Application >> not running</MESSAGE></STATUS></RESPONSE> >> > > Msg: >> > > Bytes sent: 160 >> > > Thu Aug 21 11:35:07 2008: ldtp-utils.c:49:ldtp_read_data() : >> > > Connection >> > > refused >> > > handle_client: error: >> > > unregister_window_creation_event - client-handler.c - 74 >> > > client-handler.c - 77 - Argument NULL >> > > Removing sockfd: 17 - 2 >> > > Removed sockfd: 17 - 1 >> > > Removed 2 entries from client context hash table >> > > Clients: 1 >> > > >> > > I tried running reinitldt(), but it fails. >> > > >> > > Does anyone know why does this happen and how it could be >> > > solved? >> > > >> > > Thanks, >> > > Ara. >> > > >> > > _______________________________________________ >> > > LDTP-dev mailing list >> > > LDTP-dev@lists.freedesktop.org >> > > http://lists.freedesktop.org/mailman/listinfo/ldtp-dev >> > > >> > > >> > > >> > > -- >> > > Linux Desktop (GUI Application) Testing Project - >> > > http://ldtp.freedesktop.org >> > > http://nagappanal.blogspot.com >> > > >> > >> > > >> > >> > _______________________________________________ >> > LDTP-dev mailing list >> > LDTP-dev@lists.freedesktop.org >> > http://lists.freedesktop.org/mailman/listinfo/ldtp-dev >> >> > > > -- > Linux Desktop (GUI Application) Testing Project - > http://ldtp.freedesktop.org > http://nagappanal.blogspot.com > -- Linux Desktop (GUI Application) Testing Project - http://ldtp.freedesktop.org http://nagappanal.blogspot.com
_______________________________________________ LDTP-dev mailing list LDTP-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/ldtp-dev
