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
