[LDTP-Dev] Strange situation
Nagappan A
nagappan at gmail.com
Mon Dec 1 15:17:13 PST 2008
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 <nagappan at gmail.com> 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 <ara at ubuntu.com> 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 <ara at ubuntu.com> 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/ldtp-dev/attachments/20081201/9040771d/attachment.html
More information about the LDTP-dev
mailing list