[01:38] dfarning: I just tested Surf on stock Ubuntu 10.10 and it crashed as I experienced... [01:41] * lfaraone is looking at Speak\ === bernie is now known as bernie_afk [02:48] manusheel: is kandarp around? [04:21] xxkill [04:26] alsroot: you could get ubuntulo1 or meeting [04:42] lfaraone: I'm already setting up supybot, looks like it is pretty powerful [04:43] at least it has bunch of plugins (including meeting) === bernie_afk is now known as bernie [11:12] dfarning: this looks like a very good bug to get someone's teeth cut: http://bugs.sugarlabs.org/ticket/2163 [11:48] manusheel: this looks like a very good bug to get someone's teeth cut: http://bugs.sugarlabs.org/ticket/2163 [11:49] bernie: Yes, Bernie. Indeed :-) [11:50] bernie: Any pointers that you would like to share - files we should look at, functions and variables? === neeraj_ is now known as neeraj [12:11] manusheel: not sure... the bug might be somewhere in the FavouritesLayout class [12:11] manusheel: which is part of the "sugar" module [12:11] manusheel: I noticed that your developers are debugging right in Dextrose. this is ok for platform bugs, but it's not a comfortable work environment for sugar bugs. [12:12] manusheel: once they've reproduced the bug in Dextrose, it would save time if they could reproduce the same bug in jhbuild too, where they could take full advantage of a ful linux development environment and version control [12:13] manusheel: even if they fix the bug in the code in /usr/lib/something, then they'd have to redo the change in git to send a patch. so it's not really saving any time to debug directly on the XO [12:13] manusheel: again, I'm talking about sugar bugs, not driver/kernel bugs of course [12:49] manusheel: ok, it's ready to use [12:49] alsroot: Great. === bernie is now known as bernie_afk [14:00] alsroot: Where can we find the logs? [14:00] Of #sugar-newbies [14:01] manusheel: still in progress, trying to figure out how to make them useful, ie searching [14:02] alsroot: Sure. [14:03] alsroot: Great. [14:05] alsroot: aka "site:foo.bar.baz query" in Google? :) [14:07] lfaraone: if got it right it wont be reliable (we need to pay google otherwise), but since I'm so eager to web code by myself, it could be good for the first time :) [14:07] alsroot: pay google? huh? [14:07] but /me is still looking for decent options [14:08] alsroot: http://www.google.com/search?q=site%3Airclogs.ubuntu.com+alsroot [14:09] * http://www.google.com/search?q=site%3Airclogs.ubuntu.com+"alsroot" [14:10] lfaraone: http://www.google.com/sitesearch/, see pricing, but anyway I'm tending to just enable google search [14:11] alsroot: you want http://www.google.com/cse/ [14:12] lfaraone: nope, I was just thinking that "site:" options won't be reliable, e.g., debina.org uses xapian for searching within mls/packages/etc [14:34] neeraj, ping [14:35] dfarning: pong [14:36] neeraj, how close are you to release usr-meta? [14:36] dfarning: I don't think it was clear as to whether you wanted us to do two releases of USR, one now with existing pacakges and one later once everything's synced. [14:37] neeraj: by the way, "turtleart" was accepted from Debian NEW and probably is a good thing to have over in Ubuntu-land. :) [14:37] lfaraone: great :) [14:38] dfarning: We had an schedule meeting with luke today for discussing these stuff. [14:38] lfaraone, neeraj it wasn't clear.... because I didn't say. You guys have a better understand of the state to packageing than I do. [14:38] Actually some packages are in sync state at present. So, if we want them in USR then we will have to wait to them to get released in upstream. [14:39] neeraj: you mean we'll have to wait for the syncs to get processed by an archive administrator. [14:39] neeraj, what time is your meeting? I would like to listen. [14:39] neeraj: "upstream" means Debian or Sugar Labs, and they aren't required to take any action here. [14:40] dfarning: 10:30 I think was what I agreed upon with manusheel earlier. [14:40] lfaraone: and looks like I found one :), nice demo app consists of 117 lines in python and provide exactly what I need, search string and pagination of results -- it's looking to xapian db [14:40] lfaraone: sorry my bad. I meant in ubuntu :) [14:41] lfaraone, thanks [14:41] *brb [14:41] if manusheel 's around, I'm happy to hold it earlier. [14:43] lfaraone, I am in no hurry. I am going to do release of the ISO. I will probobly be easiest to hard code the activites in 10.10 into the build script. [14:47] lfaraone we can start in 10 min [14:48] lfaraone: I am around. [14:48] manusheel, neeraj, want to hold it at 10h instead? (12m from now) [14:49] lfaraone: Sure. [14:49] sure. [15:02] okay, let's get started. [15:02] lfaraone, +1 [15:02] #startmeeting [15:02] Meeting started at 10:02 UTC. The chair is lfaraone. [15:02] Commands Available: #TOPIC, #IDEA, #ACTION, #AGREED, #LINK [15:03] #TOPIC Agenda [15:03] manusheel, neeraj, do we have an agenda of what we want to discuss? I'd like to keep this short, so keeping to a list of topics will help us do that. [15:05] lfaraone: Sure. One is arriving at a conclusion on whether to keep sugar-record, irc and e-toys as a dependency for this release, or not? [15:06] Okay. I've prepared a short topics list. [15:06] #LINK http://openetherpad.com/6b86BdsfpN [15:06] 1. Package Status. 2. Browse/Surf Update 3. weekly objectives [15:06] #link http://openetherpad.com/6b86BdsfpN [15:07] hmmm. Not sure whether meetbot is getting those, but w/e. [15:07] dfarning: Great. [15:07] #topic Keeping s-{record, irc, etoys}-a as deps for this release [15:08] If I recall, neeraj, you've got sync requests for all of these right now, correct? [15:08] lfaraone: As discussed on mail, yes for irc,record and etoys [15:08] neeraj: right. [15:08] We will add etoys as recommends only. [15:09] So etoys can't be a dependency for this release because it's in multiverse. [15:09] lfaraone, I think dogi usually cuts and pastes the contents of etherpad to irc so it goes into the meeting recored. [15:09] neeraj: recently, "Recommends:" are installed by default by apt-get. [15:09] neeraj: so it'll have to drop to a "Suggets:". [15:09] dfarning: fair enough. Here's the current contents: [15:09] * Status of sugar-*-activities [15:09] * Keeping s-{record, irc, etoys}-a as deps for this release [15:09] * Browse / Surf update [15:09] * QA delegation [15:09] * Updating usr-meta [15:09] * Other weekly objectives (ACTIONs) [15:10] lfaraone: Ok. I will add etoys as suggests then [15:11] manusheel: since irc and record will both be in universe, there's no reason not to add them, once they're in the archive. [15:11] manusheel: and since the SRU has already been ACK'd by a MOTU and the release team, it'll be processed some time before final release, and it'll be handled even if it's after Final Freeze because it was "in the queue" before-hand. [15:11] s/SRU/FFe/ [15:12] the only thing now is whether we want to add the currently existing activities in the archive to usr-meta and do an upload now, or wait later and get them all in one swoop. [15:12] lfaraone, +1 for moving etoys to suggests. It become a hurdle for oems and resellers to ship multiverse. [15:12] lfaraone: +1. thats my doubt. [15:13] the pros of doing it all now: we don't have to special-case in the build scripts, we enable `apt-get`tability for testers, and in case for some reason the syncs aren't processed or its too late to upload usr meta we at least have what we have now in the metapackage. [15:14] neeraj, how much work is it to do a usr-meta? [15:14] the cons are: additonal work of preparing another upload (may be negligable and/or good practice for us), and having to bug an archive admin to process the upload. (rubber-stamp, essentially) [15:14] s/it all now / in two loads/g [15:14] dfarning: no work at all. I have to just make change in control file [15:15] lfaraone: Ok. But, how much time will it take for these activities to get accepted in MOTU? [15:15] neeraj, then please do one today. pros outweigh the cons. [15:16] manusheel: for the ones that neeraj filed a sync request for to be accepted in Universe? some time between now and 2010-10-10 :) [15:17] lfaraone: We would not want meta package failures, and would also like to make sure QA is done once the iso is ready. Keep 1 week contigency time before the release (Sep. 3). [15:17] neeraj: we'll have to talk a little bit about that, by the way, since it's not just "add the deps directly to control", it's "add them to the metapackage in a special file", but you'd need to learn that eventually :) [15:17] manusheel: er, sep 3 is over a month from the final release. The *FinalFreeze*, on the other hand, is Sept 15 [15:18] (2010-09-15) [15:20] lfaraone: Sorry, I meant October 3. Not, Sep. 3 [15:20] 7 days before October 10. [15:21] well, at that point, we'll already be in FinalFreeze. *Ideally*, we'll have all of our changes in before the FinalF and have a month for testing, but it may not end up that way. [15:22] neeraj, dfarning, manusheel, so do we all think that it's a good idea for Neeraj to include all current shippable universe activities in usr-meta? [15:22] (and to do a different upload later) [15:22] +1 [15:23] lfaraone: +1 [15:23] lfaraone: Ok. current shippable does not include irc,record and etoys. Right? [15:24] neeraj: if it's not in universe as of yet, it's not currently shippable :) [15:24] lfaraone: Right. [15:24] neeraj: easy way to check is "rmadison PACKAGE_NAME" which will show you whether the package is in Ubuntu, which release, suite, and version. [15:25] #ACTION neeraj to look into adding all sugar-*-activity* packages currently in universe to usr-meta [15:26] #agreed do an upload of usr-meta with all activities available now, and one later if possible for record and irc when synced. [15:26] #topic Browse / Surf updates [15:27] manusheel: who's working on this on the SEETA side? [15:27] When I tried Surf earlier today in a clean Maverick VM it crashed on start. (using the .deb, not the .xo bundle) [15:27] the issue with browse as I understand it is still a dependency issue, which needs to be worked out with the mozillateam. [15:28] lfaraone: Mukul and Ishan are working on it. [15:28] lfaraone: Right. [15:28] manusheel: what's their progress on it? [15:29] neeraj, I just added a list of what apt-get tries to install to http://openetherpad.com/6b86BdsfpN [15:31] dfarning: sugar-jukebox-activity-0.88? [15:31] lfaraone: Hulahop library was broken in Ubuntu. So, I ask them to halt the process. They'll submit a fresh request r? by tomorrow. [15:32] manusheel: okay. the issue with hulahop is I don't really have any involvement in that arena, they'll need to talk to the people in #ubuntu-mozillateam. [15:33] lfaraone, let me run it again. [15:33] dfarning: that package is not in debian or Ubuntu… [15:33] dfarning: all the packages which u listed are not in Maverick [15:33] lfaraone: Fine. I'll do that today. [15:33] lfaraone: We did write to Mozilla guys. Got a reply too. [15:33] manusheel: the Mozilla *Ubuntu* team? [15:34] dipankar, hi [15:34] lfaraone, neeraj ok I am deleting all of sugar and going to try a freash install and see what gets pulled in. [15:35] dfarning: I just did an apt-cache search and posted the results. [15:35] neeraj, does lfaraone's list look right to you? [15:36] lfaraone: We did forward the reply too. It seems the packages are in unstable state. Mike Hommey from Ubuntu looks after it. [15:36] minus read, of course. [15:36] manusheel: right. [15:36] manusheel: so any work on hulahop would need coordination with him and other members of the mozillateam. [15:37] lfaraone: Right, absolutely. [15:37] manusheel: when I talked with micahg, he seemed to not feel comfortable shipping pyxpcom, which hulahop requires, because pyxpcom does not seem to be maintained upstream. [15:37] lfaraone: Yes, we got the same vibes from Mike too. He said it is in unstable state. [15:38] okay. so we'll get an update from ishan and mukul re that tomorrow. [15:39] lfaraone: Yes. [15:40] lfaraone: How about Surf package? [15:40] lfaraone: Does it have dependency issues? [15:41] manusheel: Surf has no dependency issues as far as I'm aware, but it segfaults whenever you click a link in my tests. [15:43] with regards to shipping sugar-firefox-activity, the intergration does not work at all. I was not able to use the Firefox theme that makes the text readable under the Sugar GTK theme. [15:43] Nor did the journal XPI work OOTB. [15:44] In order to ship Firefox.activity as Firefox.activity and not, say, "Abrowser.activity" (which is available in Ubuntu, btw, as "abrowser"), the Mozillateam folks still felt we'd need trademark approval. [15:44] lfaraone: Right. Sugar Firefox is not be maintained well too. [15:44] dfarning: you said that's changed recently but docs have not been updated. Do you think it's worth following up with the Mozilla team on that? [15:44] lfaraone: It is at an experimental stage. [15:45] manusheel: yes, but on the other hand it's the only web browser that will *run* in sugar on Ubuntu :( [15:45] lfaraone: We did write to Rabi. Didn't hear from him. [15:45] manusheel: Rabi? [15:46] lfaraone, is it possiable to put a wrapper around the FF that ubuntu ships? [15:46] manusheel: C. Scott was the guy who wrote Firefox.activity [15:46] lfaraone: Yes, C. Scott wrote it. [15:46] lfaraone: But, it was OLE Nepal guys, who were using that activity. [15:47] dfarning: yes, that's what Firefox.activity does, albiet with some custom extensions and javascript settings. as of today, those settings are present but unapplied, so technically it's probably not violating trademark guidelines. [15:47] manusheel: ah, so they've made some updates to the activity? [15:47] lfaraone: Also, maintaining it. [15:48] lfaraone: I don't think so. If yes, didn't see it at the git. [15:48] lfaraone: We did write to them too around 9-10 days back. [15:48] lfaraone: No response on this thread. [15:49] lfaraone, can you include the firefox as is? will it at least browse the web? [15:49] dfarning: I think so. [15:50] meaning, it did in my tests. [15:50] lfaraone, ok lets go with FF as is. this means dropping browse and surf until the next release. [15:51] dfarning: here's what it looks like in sugar-emulator: http://img714.imageshack.us/img714/7913/screenshotey.png [15:52] lfaraone, neeraj can you guys package and upload the existing FF. lfaraone can you work with upstream about the treade mark issue if we get approval we will ad the setting and javascript if we have time. [15:54] lfaraone: Did you find the source tarball of Mozilla Firefox activity? [15:55] lfaraone, it is not perfect... but currently we are spending time on browse which is does not work and will be dropped and surf which does not work yet. neither or which are moving us forward. [15:56] neeraj: yes. it's already in a git repository that I just haven't pushed up yet. [15:58] manusheel, please drop all work on browse and browse dependencies. [15:58] manusheel, please postpone all work on surf and surf until the next release. [15:59] fair enough. [16:00] #action manusheel to inform SEETA team members that work on surf/browse is tabled for this cycle [16:00] #topic QA delegation [16:00] We have testers, right? if not, we should look into a call-for-testing once we have a build that dfarning feels is ready for semi-public consumption. [16:01] dfarning: Sure. Will do that now. [16:01] lfaraone, the best group will be the NZ testers, satellit_ is also a great testing resource. [16:02] dfarning: cool. so we'll just ask them to take a look at it, say, the last week or so of Sept? [16:02] or tomorrow, once we get our packages in usr-meta. Beta was today IIRC [16:03] (for Ubuntu as a whole) [16:03] lfaraone, I am doing am ISO build with the packages we talked about this morning. Let's ask satellit_to take a initial look at it, if it works reasonably well we can release it as a beta. [16:04] okay, sounds good. [16:04] #action dfarning to review ISO build with activities for potential beta status. [16:05] #topic Updating usr-meta [16:05] We pretty much already discussed this, neeraj and I will work on that later today/tomorrow. Any other thoughts on this subject? [16:06] dfarning: Once we are ready with beta iso, please let me know too. Will ask the team to do testing using the test plans. [16:07] #topic everything else [16:07] As we're into the second hour, does anybody have something we didn't talk about earlier that needs to be discussed? [16:08] lfaraone, I think that is good. [16:08] cool. [16:08] #endmeeting [16:08] Meeting finished at 11:09. [16:08] Logs available at http://me.etin.gs/ubuntu-sugarteam/ubuntu-sugarteam.log.20100902_1002.html [16:09] lfaraone: Thank you for your time today. [16:09] manusheel: my pleasure. [16:10] dfarning: is there a reason you added deps directly to the control file rather than modifying the ubuntu-sugar-remix-{$ARCH} files? [16:11] lfaraone, no. It was just a cut and paste from ubuntu-netbook-remix with a couple of personal hacks, [16:14] manusheel, will kandarpk be around later. I would like to have a brief status meeting with him and dipankar about the develpment/maintaince progress on USR. [16:15] dfarning, good morning [16:15] dipankar, god morning [16:15] good [16:15] dfarning: Sure, we can have a status meeting with Dipankar. Kandarp is traveling today and might be late. We can start the meeting now, if you wish. [16:17] manusheel, let's do it when kandarpk is around... he should be the one chairing the meeting. [16:18] dfarning: Ok. Sure. [16:18] * satellit_ glad to test when it is ready [16:18] * lfaraone → lunch. [16:18] manusheel, dfarning : what is the meeting about? [16:18] satellit_ [16:19] dipankar: Updates on the bugs and feature requests assigned as discussed in our in-house meeting recently. [16:19] dipankar, I would like to get a handle on progress on https://edge.launchpad.net/ubuntu/+bugs?field.bug_supervisor=sugarteam [16:21] dipankar, what is the status of https://bugs.edge.launchpad.net/ubuntu/+source/sugar-0.88/+bug/617813 ? [16:21] Launchpad bug 617813 in sugar-0.88 (Ubuntu) "sugar freezes when register widget is clicked (affects: 1) (heat: 207)" [Critical,Confirmed] [16:22] dfarning, on above bug, I contact bernie [16:23] dipankar, what did you decide to do? [16:23] dfarning, as you suggested, I tried putting yup a time lag check on the network connection setup [16:23] for register [16:23] but bernie told that we can't [16:23] and he referred to a sugar-0.84 bug, similar to ours. [16:24] what is the number of the sugar bug? [16:24] dfarning, just a sec [16:24] dfarning: http://bugs.sugarlabs.org/ticket/1152 [16:24] dfarning, bernie referred to this one: http://bugs.sugarlabs.org/ticket/1152 [16:24] [Sugar-devel] Findings for Register Bug LP #617813 also [16:24] Launchpad bug 617813 in sugar-0.88 (Ubuntu) "sugar freezes when register widget is clicked (affects: 1) (heat: 207)" [Critical,Confirmed] https://launchpad.net/bugs/617813 [16:25] dipankar, what do you think you should do? [16:26] dfarning, I was trying to go through it, having difficulty in thinking of a plan. [16:26] dfarning, initiall I thought we can put check [16:27] but when I tried, I came to realize we can't [16:27] dfarning, is registration important? just asking [16:27] dipankar: Absolutely. [16:27] It is critical. [16:27] ohk, [16:28] dipankar, why can't you put in a check [16:28] dfarning, to put a check I think we need to go to the library level [16:29] dfarning, that would involve, send the data packet, wait for sometime [16:29] and if the time is exceeding a set lag time, drop the process [16:29] and raise an error [16:29] just like e.g. ping [16:30] we ping the site [16:30] if the ttl is high [16:30] drop the process [16:30] dipankar, what do you mean by libary level? [16:31] dfarning, I didn't get the exact word, sorry for using it. I meant manipulating the networking process itself [16:31] dfarning, the code we have right now is: schoolserver.py [16:31] dfarning, that directly call network functions [16:32] dfarning, if some how we change those network functions, the way they work [16:33] dipankar, what module contains this code? [16:34] dfarning, let me check yup a bit [16:36] dfarning, the function is ServerProxy() [16:36] that creates a proxy object [16:37] and later their functions are called [16:37] dfarning, just a sec [16:37] let me provide the link [16:37] dipankar, where is serverproxy? [16:37] http://docs.python.org/library/xmlrpclib.html [16:38] dfarning, I think it is in : xmlrpclib [16:43] dipankar, ok got it. ServerProxy() is making a remote functional and it is just waits until it receives a response form the server [16:43] dipankar: Neat. What David is interested is in the Sugar api modules, which are gconf and logger in this case. [16:44] dfarning, manusheel : that means we can manipulate the time lag allowed? [16:44] dfarning, I tried putting a check on "ServerProxy()" [16:45] ... [16:45] try: [16:45] server = ServerProxy(url) [16:45] except HTTPError: [16:45] RegisterError(_('Cannot set Proxy')) [16:45] ... [16:45] dipankar: We should be doing that at the ServerProxy() function. [16:45] manusheel, dfarning : The above code didn't work [16:46] dfarning, manusheel : please try opening http://schoolserver:8080/ in web browser [16:48] dipankar: Schoolserver is not a machine. It will not open. [16:48] manusheel, ohk. that what schoolserver is? and why we are setting poxy server there? [16:48] dipankar, ok understand the problem. I'll get back in a while. [16:49] manusheel, sir, the only thing I couldn't understand so far is why set proxy ? [16:49] :( [16:50] dipankar: Right. Proxy is a method to access the network. Did you discuss this with alsroot? [16:51] dipankar, see http://docs.python.org/library/xmlrpclib.html [16:52] manusheel, complete went over the understanding :( [16:54] dipankar: Ok, let us start the bottom up approach that we do whenever we are stuck. [16:54] manusheel, sir, got it now [16:54] dipankar: dfarning has provided an important pointer, which you looked at it earlier too. Can you open up http://docs.python.org/library/xmlrpclib.html ? [16:55] manusheel, sir, if we try normal way (HTTP way), we will have trouble in registering, logging, etc to a jabber server [16:56] manusheel, sir, once we setup the proxy then can easily (and safely) send the required data for register and login to any jabber server [16:57] manusheel, sir, the data that is sent back is also in a structured manner [16:57] manusheel sir: hello [16:57] so less clumsy in interpreting it [16:58] dipankar: neat. [16:58] manusheel, thank you sir. [16:58] dipankar: This is how we should be thinking about it. Glad you solved the issue at your end. [16:58] kandarpk: Hi Kandarp. [16:59] * dipankar is off for dinner. Be right back [17:00] manusheel, see [17:00] import xmlrpclib [17:00] import httplib [17:00] import socket [17:00] class TimeoutHTTP(httplib.HTTP): [17:00] def __init__(self, host='', port=None, strict=None, [17:00] timeout=socket._GLOBAL_DEFAULT_TIMEOUT): [17:00] if port == 0: [17:00] port = None [17:01] self._setup(self._connection_class(host, port, strict, timeout)) [17:01] class TimeoutTransport(xmlrpclib.Transport): [17:01] def __init__(self, timeout=socket._GLOBAL_DEFAULT_TIMEOUT, *args, **kwargs): [17:01] xmlrpclib.Transport.__init__(self, *args, **kwargs) [17:01] self.timeout = timeout [17:01] def make_connection(self, host): [17:01] host, extra_headers, x509 = self.get_host_info(host) [17:01] conn = TimeoutHTTP(host, timeout=self.timeout) [17:01] return conn [17:01] class TimeoutServerProxy(xmlrpclib.ServerProxy): [17:01] def __init__(self, uri, timeout=socket._GLOBAL_DEFAULT_TIMEOUT, [17:01] *args, **kwargs): [17:01] kwargs['transport'] = TimeoutTransport(timeout=timeout, [17:01] use_datetime=kwargs.get('use_datetime', 0)) [17:01] xmlrpclib.ServerProxy.__init__(self, uri, *args, **kwargs) [17:02] this will create a object called a TimeoutServerProxy with allows the user to set a timeout to a proxyserver conection. [17:03] dfarning: Yes. This is where the condition has to be set. [17:04] dfarning: We can have a member function, which is called by the object TimeoutServerProxy. [17:05] This will allow the user to set up a timeout for the proxyserver connection. [17:06] dfarning: bug 624592, I have attached the patch. [17:06] Launchpad bug 624592 in ubuntu-sugar-remix-meta (Ubuntu) "request all packaged activities be installed by default on USR (affects: 1) (heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/624592 [17:08] manusheel, immediately before the async rpc function call to draw a message on the screen that registeration is in progress. call gtk redraw to ensure the screen is rewrawn. call TimeoutServerProxy [17:08] neeraj, looks good. [17:12] dfarning: Yes, thanks for the workflow. Yes, gtk redraw should be called to ensure screen is redrawn immediately after the registration is in progress. [17:13] dfarning: This is the lag where Dipankar was getting stuck up. I think it should work out now. [17:13] dfarning: Thanks for the pointer. [17:40] manu the redraw needs to be done just before the call to .registration . Once that rpc call is made, the client loses control until the server responds or the function times out. [18:04] dfarning, around? [18:04] dipankar, yes [18:04] dipankar, did the above make sense? [18:05] dfarning, I was offline. [18:05] dfarning, if I missed anything, could you please copy paste it? please. [18:05] manusheel, see [18:05] import xmlrpclib [18:05] import httplib [18:05] import socket [18:05] class TimeoutHTTP(httplib.HTTP): [18:05] def __init__(self, host='', port=None, strict=None, [18:05] timeout=socket._GLOBAL_DEFAULT_TIMEOUT): [18:05] if port == 0: [18:06] port = None [18:06] self._setup(self._connection_class(host, port, strict, timeout)) [18:06] class TimeoutTransport(xmlrpclib.Transport): === bernie_afk is now known as bernie [18:06] def __init__(self, timeout=socket._GLOBAL_DEFAULT_TIMEOUT, *args, **kwargs): [18:06] xmlrpclib.Transport.__init__(self, *args, **kwargs) [18:06] self.timeout = timeout [18:06] def make_connection(self, host): [18:06] host, extra_headers, x509 = self.get_host_info(host) [18:06] conn = TimeoutHTTP(host, timeout=self.timeout) [18:06] return conn [18:06] class TimeoutServerProxy(xmlrpclib.ServerProxy): [18:06] def __init__(self, uri, timeout=socket._GLOBAL_DEFAULT_TIMEOUT, [18:06] *args, **kwargs): [18:06] kwargs['transport'] = TimeoutTransport(timeout=timeout, [18:06] use_datetime=kwargs.get('use_datetime', 0)) [18:06] xmlrpclib.ServerProxy.__init__(self, uri, *args, **kwargs) [18:06] this will create a object called a TimeoutServerProxy with allows the user to set a timeout to a proxyserver conection. [18:06] dfarning: Yes. This is where the condition has to be set. [18:06] dfarning: We can have a member function, which is called by the object TimeoutServerProxy. [18:06] This will allow the user to set up a timeout for the proxyserver connection. [18:06] dfarning: bug 624592, I have attached the patch. [18:06] Launchpad bug 624592 in ubuntu-sugar-remix-meta (Ubuntu) "request all packaged activities be installed by default on USR (affects: 1) (heat: 10)" [Critical,Confirmed] https://launchpad.net/bugs/624592 [18:06] Launchpad bug 624592 in ubuntu-sugar-remix-meta (Ubuntu) "request all packaged activities be installed by default on USR (affects: 1) (heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/624592 [18:06] manusheel, immediately before the async rpc function call to draw a message on the screen that registeration is in progress. call gtk redraw to ensure the screen is rewrawn. call TimeoutServerProxy [18:06] neeraj, looks good. [18:06] dfarning: Yes, thanks for the workflow. Yes, gtk redraw should be called to ensure screen is redrawn immediately after the registration is in progress. [18:06] dfarning: Bug 624592 on http://launchpad.net/bugs/624592 is private [18:06] dfarning: This is the lag where Dipankar was getting stuck up. I think it should work out now. [18:07] Launchpad bug 624592 in ubuntu-sugar-remix-meta (Ubuntu) "request all packaged activities be installed by default on USR (affects: 1) (heat: 10)" [Critical,Confirmed] [18:07] dfarning: Thanks for the pointer. [18:07] manu the redraw needs to be done just before the call to .registration . Once that rpc call is made, the client loses control until the server responds or the function times out. [18:07] * dipankar is going through above [18:10] dfarning, ok got it. but where is the source file? :) [18:10] dipankar: did you looked at that sir [18:10] dipankar, you are hitting a cascade of failures. [18:11] google serverproxy timeout -- or something like that. this is a pretty common issue. [18:12] dfarning, ohk. just a minute [18:13] dipankar, the async rpc function call is one problem. The other is that there is garbage on the screen when that call is made. [18:14] dfarning, yes. That I figured out: two problems [18:14] 1. Time out [18:14] 2. gtk redraw (to remove the gray rectangle that is left out after clicking) [18:19] lfaraone, hi [18:20] dipankar, normally gtk widgets such as the window are redrawn in the background as part of gtk_widget_queue (Or something similar) I think there is a comannd to redraw the queue in the main thread so that the screen is in a know good state prior to making the function call. [18:21] lfaraone, wanted to discuss about moon package [18:23] dfarning, ok [18:27] dipankar, I think the following will trigger a redraw [18:27] event = gtk.gdk.Event(gtk.gdk.EXPOSE) [18:27]