[07:06] <apachelogger> stgraber: ahoy ... how would one go about getting kde.qa.ubuntu.com?
[07:28] <ara> good morning all :-)
[10:02] <davmor2> Morning All
[12:11] <ara> mvo: remeber the bug in update-manager where it just poped up when some updates were available (instead of just showing an indicator)
[12:16] <mvo> ara: that it pops up is a new feature (the design team wants it this way) - or is there something wrong with that mode?
[12:16] <ara> mvo: no, no, so it is a "feature"... OK :D
[12:17] <mvo> https://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes#Change in notifications of available updates
[12:18] <ara> mvo: ok, thanks!
[12:18] <schwuk> Cool - I was wondering why that had happened.
[12:19] <ara> hehehe, I was not the only one :D
[12:20] <ara> mvo: ok, and is it a "feature" that every time I run 'sudo apt-get update' update-manager pops-up? (when there are available updates) or is it a bug?
[12:20] <schwuk> ara: every time, or only if there are new packages?
[12:21] <ara> schwuk: every time. Let's say. I run sudo apt-get update, and there are some firefox security updates. I close update-manager (without installing the updates) and run sudo apt-get update again. It pops up again (with the same packages)
[12:22] <schwuk> seem it's only if there are updates for me (just apt-get update'd twice in a row - update-manager only appeared the first time)
[12:22] <schwuk> I lied - it was just slow
[12:22] <schwuk> It's shown up now.
[12:29] <mvo> ara: everytime is a bug, but everytime with pending security updates is a feature
[12:29] <mvo> ara: but seb just complained about this too
[12:30] <ara> mvo: ok, thanks. are the specifications written some where?
[12:30] <mvo> ara: I talk to the design team what should be done in this case
[12:30] <ara> mvo: ok
[12:30] <mvo> https://wiki.ubuntu.com/NotifyOSD#Update Manager
[12:31] <ara> mvo: thanks. (I am seeing the backlog now in -desktop... )
[12:34]  * ara -> lunch
[13:46] <ara> eeejay: moshi moshi
[13:48] <eeejay> ara: howdy
[13:49] <ara> eeejay: I just uploaded the first version of the msn pidgin test at lp:~apulido/ubuntu-desktop-testing/pidgin_msn
[13:49] <ara> eeejay: it is in an early stage (pymsn is a pain...) but it should be working
[13:50] <eeejay> ara: cool! don't hesitate to push directly to the pidgin branch, it gets pretty confusing
[13:50] <ara> eeejay: ok, I will, as the code won't interfere
[13:50] <eeejay> ara: did recent changes in trunk break API? open/exit/close/etc..
[13:51] <ara> yes, there are some changes
[13:51] <ara> eeejay: I wanted you to have a look, because one of the things that comes to my mind is that Buddy class could be part of the pidgin.py, instead of msn_utils.py/xmpp_utils.py, etc.
[13:51] <eeejay> ara: ldtp2 almost works with the gedit udt test. almost...
[13:51] <ara> eeejay: cool :)
[13:51] <ara> eeejay: good to hear :)
[13:53] <eeejay> ara: but shouldn't my buddy be renamed to XMPPBuddy?
[13:53] <eeejay> ara: there would be a seperate buddy subclass for every protocol?
[13:54] <ara> eeejay: I was thinking of having just 1 generic Buddy, and rely protocol stuff to the Client class
[13:55] <eeejay> ara: oh, right. i forgot how i did that. so xmpp/msn_utils.py would still have the relevant Client class?
[13:55] <ara> eeejay: yes. but this is just an idea
[13:56] <eeejay> ara: i am fine either way. i guess a question is, do we expect test writers to access Pidgin.buddy directly, or rely on convenience Pidgin methods for sending messages, etc.
[13:58] <ara> eeejay: I guess both things should be fine. If they find Pidgin methods enough for their tests, cool, if they need for flexibility, Pidigin.Buddy should be available
[13:58] <eeejay> ara: great, +1
[13:59] <ara> eeejay: cool
[13:59] <eeejay> ara: i think we should also start considering merging in all the separate suite branches out there, like pidgin and dx on my end
[13:59] <ara> eeejay: completely agreed
[13:59] <ara> eeejay: it is starting to have too many
[14:01] <thekorn> make a separate project which contains all test suites ;)
[14:26] <ara> eeejay: I pushed the msn changes directly in the pidgin branch
[14:26] <ara> eeejay: I will start now the refactoring
[14:26] <eeejay> ara: neat. did you see the NO_GAIL bits?
[14:26] <ara> eeejay: no, sorry
[14:26] <ara> eeejay: I forgot
[14:28] <jtholmes> davmor2, how was the party thurs night
[14:29] <davmor2> jtholmes: fINE THANKS
[14:29] <davmor2> Fine thanks even
[14:30] <jtholmes> good when do we get started back testing pls
[14:31] <davmor2> Alpha 1 although I've added a topic for tonight about maybe running some stress tests and the best ways around it
[14:32] <jtholmes> where do i look for the topic u mention
[14:40] <davmor2> jtholmes: it's to discuss at the meeting tonight
[14:41] <jtholmes> ok
[14:42] <jtholmes> davmor2, is amd64 just a label for both intel and amd  64bit releases?
[14:42] <jtholmes> ie  amd64 works on both arch's
[14:44] <davmor2> jtholmes: If you have a intel dual core then it should support both 32bit and 64bit and amd64 is the generic kernel for any intel or amd 64bit cpus
[14:45] <davmor2> in the same way that intel386 works on amd 32bit and 64bit machines
[14:46] <davmor2> Yay just booked flights and hotel for uds
[14:46] <jtholmes> davmor2, r u actually employed by canonical
[14:47] <jtholmes> davmor2, when should i start changing the test plans i disovered incorrect or missing during testing of jaunty
[14:50] <davmor2> jtholmes: Really we need to discuss all the plans what needs to be covered etc before we start work on them again.  Other wise the danger will be duplicating stuff all over again which we want to miss out on this time.   So not until after UDS probably
[14:52] <jtholmes> davmor2, we being you and heno and others directing the test team etc. from ubuntu
[14:53] <davmor2> jtholmes: we being the QA team and community who really need to get this right in order to move on :)
[14:55] <jtholmes> davmor2, will the discussion be in the weekly QA irc meetings sometime after uds?
[14:57] <davmor2> jtholmes: you can read the doc as they are created using gobby (a collaborative text editor) instructions will be on the uds page.  gobby is like multiplayer gedit :)
[14:57] <jtholmes> ok thanks
[16:02] <eeejay> her ara, could i commit a change to udt that will log exception tracebacks with logger.warning
[16:02] <eeejay> ara: it is two lines :)
[16:03] <ara> eeejay: sure, go ahead :)
[16:03] <eeejay> ara, thanks
[16:03] <ara> eeejay: btw, my msn test fails at some point when logging out the buddy. I am trying to discover where exactly
[16:05] <eeejay> ara: does it hang?
[16:06] <ara> eeejay: it doesn't. it logs out the buddy successfully, but then it exists the testsuite without writing the results or exiting pidgin. I am debugging it now. It could be something in pymsn itself
[16:06] <eeejay> ara: dang. good luck
[16:07] <davmor2> slangasek: Congrats by the way on the work you did to get jaunty out :)
[16:10] <eeejay> ara: actually, i'll make an official merge proposal, because i have the NO_GAIL changes here too..
[16:11] <ara> eeejay: ok
[17:23] <ara> eeejay: apparently, client.logout() in pymsn just send an OUT message that conflicts with the ldtp communication, so the ldtp server exists if you logout a pymsn client :-D
[17:32] <eeejay> ara: really?? literally O.U.T. ?
[17:33] <ara> eeejay: yes :)
[17:34] <eeejay> ara: wow, bizarre..
[17:34] <ara> eeejay: indeed
[17:35] <ara> eeejay: funny enough, if you open a python console (I tried with ipython) and connect a pymsn and then, logout, the interpreter thinks you sent and ctrl+d and ask "do you really want to exit (y/n)?
[17:38] <eeejay> ara: maybe it does that. maybe it raises KeyboardInterrupt
[17:41] <ara> eeejay: maybe... :)
[17:42] <ara> eeejay: sometimes this hacks happen when trying to implement a closed protocol...
[17:42] <ara> eeejay: how do I exit? how do I exit? KeyboardInterrup!!!!!!
[17:42] <eeejay> ara: possible, yeah :)
[17:43] <eeejay> ara: i am trying to make ipython quite with an exception
[17:44] <eeejay> ara: the code in iplib.py looks like maybe an EOFError would do the trick
[17:44] <eeejay> but i couldn't get it to happen
[17:46] <eeejay> ara: i think i see a possibility
[17:46] <eeejay> ara: maybe it does sys.stdin.close()
[17:50] <ara> eeejay: no, it does not
[17:51] <eeejay> ara: i hope it doesn't do sys.exit() :)
[17:52] <ara> eeejay: :D
[17:52] <ara> eeejay:         self._send_command('OUT')
[17:52] <ara>         self._transport.lose_connection()
[17:57] <ara> reminder: qa meeting in 3m in #ubuntu-meeting
[19:17] <nagappan> is there any issue with Ubuntu 9.04 having 2 nVidia card ?
[19:17] <nagappan> the installer doesn't come up, if we have 2 cards
[19:17] <nagappan> it gets struck when the X comes up
[19:18] <nagappan> later, tried removing a card and installed Ubuntu 9.04, after installation, when I plugin the card, the second card is not being detected
[19:18] <nagappan> both the cards are same nVidia chipset
[19:19] <nagappan> I mean the lspci is listing only one card
[19:20] <sbeattie> nagappan: hrm, you might ask on #ubuntu-x or #ubuntu-kernel
[19:21] <nagappan> sbeattie, sure, let me join there
[19:22] <nagappan> sbeattie, thanks :)