=== rye` is now known as rye [07:56] morning all [07:56] ralsina: ping [08:27] mandel: pong [08:28] ralsina: got time for a review? [08:28] mandel: sure! [08:28] nessita was having a problem with a slot being called twice? [08:28] on a button click? [08:28] * ralsina is guessing [08:29] ralsina: yes, the issue was with autoconnect, while that works ok in C++ in python is calling the signal without params and with a bool [08:29] mandel: known problem, is in the FAQ and everything. It's even on my tutorial ;-) [08:30] you have to add a decorator to set the signature of the slot [08:30] or check the extra parameter and do nothing if it's None [08:30] ralsina: yes, I told here to ignore the signal with no param [08:30] I did not know there is a decorator [08:30] it's somewhat cleaner with the decorator [08:31] ralsina: yes, it is [08:31] I really should spend some time in ART timezone today [08:33] ralsina: why? [08:34] to help with this kind of thing :-) [08:34] now you know how it is to be the only one working ;) [08:34] ralsina: can you take a look at :https://code.launchpad.net/~mandel/ubuntu-sso-client/fix_signals_emition/+merge/59898 [08:34] sure thing! [08:36] ralsina: we have sd using named pipes :) [08:36] mandel: neat! [08:36] mandel: was it painful? [08:36] ralsina: no, the code now is soooo much nicer [08:36] cool [08:37] there is no crazy COM code around and is a matter of installing the correct reactor, so the choice was good [08:37] I've checked and IOCP is quite nice to use! [08:52] mandel: checked the code in fix_signals_emition and looks ok, does it need fieldtesting? [08:53] ralsina: did I add any test instructions? [08:53] just to run the tests [08:53] You do the if in line 201, kwargs can be {}, right? [08:54] if that's the case, you can still do callback (*fixedargs, **kwargs) [09:05] mandel: ^ (no hurry!) [09:07] ralsina: one sec, I need to fix something with a sd branch that broke and I'll look into it [09:07] cool [09:39] ralsina: ok, so I've got sd running with naed pipes on windows performing all my syncs :) [09:39] niiiiiiiice [09:39] ralsina: including shares, although I have no udfs in my account [09:40] you should create one just in case [09:40] next step is to move everything to json, which aint easy [09:40] ralsina: yes, will do, lets first see if it syncs and get changes from windows and pushes them to the web :) [09:40] mandel: are you using mattia for that, right? [09:41] we have him until next friday ;-) [09:41] ralsina: I can do that, he did the basic protocol stuff, but I'll add it to the projects, he is workin in a C++ implementation so that we can use it in the shell extensions :) [09:41] ok, great [09:42] just don't want him to be unused [09:42] now, got 2' for my review? [09:42] or if you prefer to just get needsfixing and comments, I am happy to do it that way ;-) [09:43] ralsina: yes, what was it, something about {}, right? [09:43] right, line 201 and 202 [09:43] in https://code.launchpad.net/~mandel/ubuntu-sso-client/fix_signals_emition/+merge/59898 [09:43] if kwargs can be something like None, yes that's necessary, but if it is only {} then the if is useless [09:44] ralsina: it could be none [09:44] ok then +1 [09:44] I hate than launchpad doesn't give you a nice way to jump to the source code in context [09:44] ralsina: it was the only reason I added it :) [09:44] haha file a bug ;) [09:45] ralsina: you know canonical, either there is a bug or there is a wiki page [09:45] my bug would be "make it work like googlecode's commit view" ;-) [09:45] I couldn't test it on natty because my VM is broken, and I am reinstalling [09:46] so unless you did it... [11:35] still cant find a bug that I can do :/ [12:20] fagan: this is really not the simplest codebase for small bugs :-( [12:21] fagan: most of the code is pretty hairy [12:22] fagan: is it a holiday in the UK or anything? It's pretty quiet today [12:31] ralsina: well I dont think it is [12:32] fagan: ok [12:32] yeah im seeing that the code is a bit hairy from looking through the bugs [12:32] its a little bit hard to find a task then [12:32] not really a lot of low hanging fruit [12:48] rye: ping [12:49] duanedesign, pong [12:50] good day rye [12:51] fagan: I will ask at standup, maybe one of the developers has something in mind [12:51] rye: i cant find the u1conflict renaming script from the other week [12:52] duanedesign, hmmm [12:53] ralsina: cool [12:54] rye: aha foound it === zyga is now known as zyga-afk [13:05] hola #ubuntuone! [13:05] hola alecu [13:06] * fagan was trying to think of the word dude but was too lazy to open google translate [13:12] hola alecu [13:14] hola fagan, duanedesign! [13:15] ralsina: meeting? [13:17] annd.... I'm back. Meeting [13:18] sorry but had a kid emergency [13:19] this place's connection is way too crappy for mumble :-( [13:19] grmbl, I will try again [13:27] I keep getting dropped off mumble [13:29] sorry guys but I will be back in my usual place for the next call, and then it will work. [13:30] mate time! [13:30] * fagan break [13:32] * ralsina tries to figure out how o order a non-turkish coffee [13:32] It's not worth fighting this connection, will be back when I have decent internet :-( === karni_ is now known as karni [13:54] dobey: when switching u1cp from pylint to u1lint, (how) can I pass it '--ignore ui'? [13:55] just adding that as an argument to u1lint does not work [13:57] in general I think it would be good if it just passed all arguments it does not handle itself to pylint [13:58] alecu: I need to have a common place for GUI strings... I'm planning on having a gui module with the gtk and qt inside [13:58] nessita, +1 [13:58] btw: riverbankcomputing's webservers seem to be hosted in turkey :P [13:59] me [13:59] still 30 seconds to go! :-) [13:59] booo [13:59] mandel: weren't you having lunch with @parents? [13:59] reactor.callLater(.30, me) [14:00] thisfred: it can't [14:00] nessita: yes, but I can do the standup, they are looking at me with a funny face because I have the laptop on the table but is ok [14:00] :) [14:00] me [14:00] me [14:00] me === m_conley_away is now known as m_conley [14:00] ralsina, alecu, dobey, fagan? [14:01] me [14:01] thisfred: and we can't just pass arguments on, because we support using pyflakes as well there; which doesn't take the same arguments as pylint [14:01] me [14:01] only 2 to go! ralsina, fagan? [14:02] dobey: ok, then we need the ignore method, because we can't be checking the generated code since there is no way to fix it [14:02] ok, let's [14:02] DONE: QT windows control panel port, reviews, emails [14:02] TODO: more of the same [14:02] BLOCKED: a little by QT, but it will get better. [14:02] NEXT: mandel [14:02] ignore argument I mean [14:02] DONE: Moved SSO to use txnamedpipe. Started the process to migrate SSO to json. Made SD to work with txnamedpipes. Syc is working ok. [14:02] TODO: Fix ubuntuone-dev merge proposal from dobeys remark. Propose merges for SD and SSO. Continue work for json [14:02] BLOCKED: No [14:02] thisfred, go [14:02] * TODO https://bugs.launchpad.net/bugs/781119 [14:02] * TODO https://bugs.launchpad.net/bugs/781538 [14:02] * INPROGRESS https://bugs.launchpad.net/ubuntuone-control-panel/+bug/781875 [14:02] * INPROGRESS make u1cp use u1lint instead of pylint [14:02] NEXT: alecu [14:02] Launchpad bug 781119 in ubuntuone-couch (Ubuntu) (and 1 other project) "Crashes if not logged into Ubuntu One (affects: 1) (heat: 6)" [Medium,Confirmed] [14:02] Launchpad bug 781538 in ubuntuone-couch (Ubuntu) (and 1 other project) "OAuth support doesn't handle query parameters (affects: 1) (heat: 300)" [Undecided,New] [14:02] Launchpad bug 781875 in ubuntuone-control-panel "ERROR - ReplicationSettingsChangeError: args ( DONE: a branch to put sensible names to the Qt widgets. Started digging into using qt-network as a replacement for libsoup [14:03] TODO: qt-network for today, thankyouverymuch. Meet andrew and lissete in tonight's dinner at the web&mobile sprint [14:03] BLOCKED: riverbankcomputing hosts its webserver in turkey [14:03] NOTE: tomorrow is a nat holiday [14:03] NEXT: dobey [14:03] λ DONE: Some more nightlies work, reviews [14:03] λ TODO: Patch logilab-common on O, Still some more nightlies work [14:03] λ BLCK: logilab-common test suite failing [14:03] me whoops [14:03] fagan: go! [14:03] sec writing it up 2 secs [14:04] as alecu said, tomorrow is National Holiday in ARG. I'll be swapping for next Monday though, but ralsina and alecu are not coming tomorrow [14:04] mandel: tomorrow is only you and me! [14:04] (for windows port) [14:04] DONE [14:04] * Booked flights [14:04] * updated the wiki with travel info [14:04] * Looked for a bug to do [14:04] TODO [14:04] * Find a bug to do [14:05] Blocked [14:05] nessita: cool :) [14:05] * nope [14:05] oh and if anyone has any bug that I can do send it my way [14:05] thisfred, re:" * INPROGRESS make u1cp use u1lint instead of pylint", why are we doing this? [14:06] is tomorrow a turkish holiday too? [14:06] alecu: we might not, if we can't change u1lint [14:06] dobey: nopes, but ralsina is still an argentinian resident [14:06] and can we start using the bytesize tag please [14:06] alecu: the reason for doing it is consistency across projects [14:06] fagan: what's the bytesize tag for? [14:06] what the heck is "bytesize tag"? [14:06] fagan: and bug in which area/project are you looking for? [14:07] fagan: remember we're not in your head, so you need to be a little more explicit here :-) [14:07] the dx team uses it for tasks that arent going to be done by a member of the team and can be done pretty fast [14:07] thisfred, right. But can't we delay it a few weeks? nessita and I are already changing a lot on u1cp, and changing that may make life harder for us right now. [14:07] its mainly done for unity at the moment [14:07] oh, no [14:07] alecu: Sure [14:08] let's not bother with adding tags to bugs that we're not going to use ourselves [14:08] fagan: and when would we use such tag? I mean, can you please give an example? [14:08] nessita: give me a sec ill get the link [14:08] nessita: unity uses it as a means to increase outside contributions [14:08] fagan: don't make me read doc! my time is little and precious! :-P [14:08] dobey: ah\ [14:08] nessita: ie, "these are the easy bugs that anyone can do" [14:09] not sure if we want to go that road then [14:09] fagan: did you discuss this with ralsina? [14:09] yeah i don't think it makes sense for us [14:09] nessita: he said he would mention it here [14:09] ah, I don't think we have those :-D ("easy bugs") [14:09] but he is off because of the interwebs [14:10] ralsina: btw, you need to do 1:1 with everyone on the team this week :) [14:10] nessita: well we *could* have some small things maybe even features that arent a priority [14:10] nessita: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize [14:11] damn lp did that weird its doing it for all ubuntu projects [14:11] fagan: I see. Thanks for sharing that. From my POV, I think we should spread this in a more uniform manner, meaning that if we decide to do it, it should be shared across the whole team. [14:12] fagan: no it's not. it's doing it for ubuntu. ubuntu is a distribution [14:12] nessita: well I was just thinking it would have been handy for me since I was looking for tasks to startb out on [14:12] dobey: yeah thats what I mean [14:13] distributions don't have projects, but they do have packages; if you want just project bugs then use the project bugs page instead === urbanape_ is now known as urbanape [14:13] nessita: well, there really is no way it can be shared across the whole team [14:13] nessita: only us and mobile can use it really, but i don't think we should [14:13] dobey: and foundations for the client and protocol [14:14] nessita: well, maybe; protocol is used on server too, and normal users can't test whether it will break that or not [14:14] better link https://bugs.launchpad.net/ubuntu/+source/unity/+bugs?field.tag=bitesize [14:14] desktopcouch is sort of similar there, but not as bad [14:15] fagan: https://bugs.launchpad.net/unity/ [14:15] dobey: well, you could run a desktop client pointing to that protocol and confirm, but I see your point [14:15] nessita: right, but that doesn't tell you if the server code breaks :) [14:15] dobey: they dont have the tag in use for those bugs [14:15] anyway, i think it's also a waste of time [14:15] dobey: its against the distro package [14:15] anything that any of us coudl classify as "bitesize" we should be fixing immediately anyway, most likely [14:16] because it will take just as much time to fix it, as it will to add the tag to the bug [14:16] Well I suppose unity has more little bugs that could be left alone [14:16] if it will take longer, it's not bite size :) [14:16] u1 doesnt have many of those [14:16] maybe we should have a fagan tag where bugs that I can do get marked :D [14:17] well, it's a dumb thing to say something is "bite size" because it means you have to take the time to determine that first [14:17] dobey: large parts of desktopcouch don't deal with any client server concerns at all, but other than that, yeah, this may become valuable *when* we have a community that can mark files as such, but I doubt us doing it will grow that community [14:18] thisfred: well, right, which is why i said "desktopcouch also, but it's not as bad" [14:18] thisfred: well most backend stuff dont get many casual contributors in general [14:18] thisfred: however, i don't think wasting time tagging bugs in that manner is useful [14:18] agreed [14:18] fagan: because it's not possible to contribute ;) [14:18] alecu: does this ring any bell? http://pastebin.ubuntu.com/612270/ [14:19] anyway then keep an eye out for smaller bugs for me then and ping me when you see one [14:19] every "small" bug i end up deciding to work on, turns into a snowballing nightmare [14:19] I can sort it out and spread the loads out a bit and learn a bit too [14:21] oh I didnt know the distro package tracks the project bugs now [14:21] thats nice [14:22] huh? [14:22] it doesn't [14:22] one-on-one with everyone on thursday [14:23] dobey: if you look at the unity page under the distro package it says that it tracks the unity project too [14:23] dobey: look just under the top of here https://bugs.launchpad.net/ubuntu/+source/unity/+bugs?field.tag=bitesize [14:23] no? [14:24] oooh misread it [14:24] * fagan really needs to take more breaks [14:25] dobey: pretty much every small bug in u1 so far was a huge bug that's well hidden ;-( [14:25] ralsina: say me! [14:25] me [14:25] ralsina: go [14:25] DONE: teh leads call, reviews, administrivia [14:26] TODO: mgmt call in 5 minutes, more administrivia, schedule 1-on-1s, [14:26] BLOCKED: nope [14:26] ralsina: any idea why accessing Dbus from qt+reactor is raising exceptions.MemoryError? [14:27] nessita: nope [14:27] alecu: ping [14:27] nessita: usually that means you are getting a conflict between two different garbage collectors [14:27] ralsina: can you confirm that from http://pastebin.ubuntu.com/612270/ ? I mean, does that trace give you more info? [14:28] for example, if the Qt object is being deleted by the parent/child relationship while you have a python reference, but that usually gives a more meaningful error. let me see the trace... [14:28] nessita: probably not that [14:28] either I get MemoryError or Segmentation fault [14:29] ah, the joys of integrating reactor, main loops, dbus, etc... [14:29] dobey: "the joys" [14:30] the message in line 4 means you are doing something wrong already, but may not be related to the problem that causes the crash [14:30] dobey: does this ring a bell for you? /usr/lib/pymodules/python2.7/gtk-2.0/gtk/__init__.py:127: RuntimeWarning: PyOS_InputHook is not available for interactive use of PyGTK [14:30] is appearing when importing syncdaemon stuff into the control panel [14:30] not to mention that line 1 means you are still importing gtk ;-) [14:30] ralsina: I'm not [14:30] nessita: yes you are [14:31] ralsina: ... [14:31] /usr/lib/pymodules/python2.7/gtk-2.0/gtk/__init__.py:127 means you are [14:31] ralsina: define "you" [14:31] ok, the code is importing gtk somewhere. [14:31] nessita: no, but i've seen it before; in the build logs for nightlies iirc [14:32] i have no idea what PyOS_InputHook is, either === hito_jp0 is now known as hito_jp [14:35] nessita, pong [14:35] alecu: does this ring any bell? http://pastebin.ubuntu.com/612270/ [14:36] nessita, not at all [14:36] alecu: ok, seems like qt4reactor + dbus + qt mainloops does not get along [14:39] nessita: where is that QThread warning coming from? perhaps that's the problem [14:40] sigh, logilab [14:40] * dobey wonders how this thing even made it into the debian archive [14:42] dobey: I have no idea, I'm not creating nor using any QTHread [14:42] not QThread [14:43] ralsina: any clues where that QThread comes from? [14:43] that warning may mean you are setting up a timer on a thread that was started from python [14:43] or that you are doing it before initializing the QApplication [14:43] but I would worry first about getting a gtk warning... [14:44] ralsina: I'm not, I can confirm that. And I'm not using any explicit timer not thread... [14:44] nessita, what about the first line? "/usr/lib/pymodules/python2.7/gtk-2.0/gtk/__init__.py:127: RuntimeWarning: PyOS_InputHook is not available for interactive use of PyGTK" [14:45] alecu: I have no idea about that. I'm reviewing all the files and I don't find any gtk import of our own [14:46] i don't think the gtk warning is the problem [14:46] * nessita neither [14:47] alecu, ralsina: the gtk warning appears when this code is executed: from ubuntuone.platform.linux.tools import SyncDaemonTool [14:50] nessita: that's importing from dbus_interface too, so maybe the same problem you mentioned yesterday [14:50] dobey: about the reactor? [14:50] hum... [14:51] nessita: right, though not sure where gtk would come from; nothing in syncdaemon should be using gtk anywhere [14:51] right [14:52] nessita: make a local gtk/__init__.py that just does "raise Exception('GTFO')" or something, so you will get a stack trace when it gets imported [14:52] nessita: then you can see what's importing it at least [14:52] ralsina, alecu, dobey: bug #526676 [14:52] Launchpad bug 526676 in pygtk (Ubuntu) "[Lucid] PyOS_InputHook is not available for interactive use of PyGTK set_interactive(1) (affects: 11) (heat: 51)" [Undecided,New] https://launchpad.net/bugs/526676 [14:52] seems like pyinotify is doing something nasty? [14:53] oh, pynotify [14:53] nessita, what are we using SyncDaemonTool for? [14:53] alecu: most of sd_client stuff [14:53] yes, it's pynotify [14:53] alecu: anyways, the warning appears the same when importing anything related to syncdaemon [14:53] well that makes no sense [14:53] ralsina, alecu: anyways, I'm pretty sure that warning is not related to the sg faults [14:53] seg* [14:54] nessita, ok, but the dependencies of syncdaemontool seem to be too convoluted, so we probably should get rid of that. [14:54] nessita: ok, could be [14:54] why would a C module import pygtk? [14:55] and i'm pretty sure nessita's error is due to the threading/timeout issue [14:58] ralsina, alecu, dobey: the warning has nothing to do, confirmed. I'm raising an exception inside /usr/lib/pymodules/python2.7/gtk-2.0/gtk/__init__.py and I'm getting seg fault before that exception is being raised, so is a timing thing [14:58] nessita: ok [14:58] nessita: I am in the mgmt call, I can try to debug it in about 20 minutes, I think [14:58] ralsina: ok [14:59] I'll move on commneting out that code [15:01] nessita: http://www.qtcentre.org/threads/12135-PyQt-QTimer-problem-FIXED [15:01] it's pretty much a generic message that can be triggered by a bunch of internal qt things [15:01] like, loading an image [15:02] ralsina: so you say that it has nothing to do wth the sg fault, right? [15:02] nessita: probably nothing to do, yes [15:03] in fact, I have seen it in the past on programs that worked just fine [15:09] * dobey hopes pylint doesn't still go nuts now [15:10] nessita: done with the call, what branch are you trying? [15:10] YAY [15:10] ralsina: browsing link [15:10] ralsina: https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/bind-some-more [15:11] nessita: ok, branching [15:11] ralsina: branch and run DEBUG=True PYTHONPATH=. ./bin/ubuntuone-control-panel-qt [15:11] nessita: so you get the crash every time, right? [15:11] then, uncomment qt/controlpanel.py the line that reads [15:11] self.backend.file_sync_status() [15:11] and re-run, and boom [15:12] ralsina: yes, every time for me [15:12] ok, let's try... [15:14] reproduced. [15:14] now, give me a few moments to try and debug it [15:14] ralsina: withy memoryerror or seg fault? [15:14] segfault [15:17] and it doesn't seem to be happening in a deferred, which may make it slightly easier [15:17] * mandel => errants [15:18] nessita: you didn't have this before you started this branch, right? [15:19] ralsina: nopes, and even if you comment the line "self.backend.file_sync_status()" there is no crasg [15:19] carsh [15:19] crash! [15:19] :-) [15:19] cash! ;-) === rodrigo__ is now known as rodrigo_ [15:19] ok cool, let me dig a bit more then [15:19] ralsina: I bet is related to accessing dbus from qt+reactor [15:19] errants [15:20] probabbly [15:20] which sucks! :-) [15:20] is very hard to debug [15:20] yes, it is [15:22] hey, got the memoryerror now [15:22] ralsina: right, is a timing issue [15:22] race condition maybe [15:24] when there is a segfault, there is no QTimer error [15:25] ralsina: but only becasue (I think) the seg fault happened before the stdout buffer was flushed [15:26] I am now seing the control panel :-D [15:27] that was an interesting fluke [15:27] I got the memory error *and* the control panel became visible. Once. [15:28] so it really smells like a race condition [15:44] it is because of calling dbus :-( [15:45] ralsina: yes! any way of fixing it? [15:45] nessita: working on it [15:45] ralsina: awesome [15:46] it *may* get fixed if we keep a reference to something, but not 100% sure [15:48] ok, something *is* starting threads, and the segfault is on a QTimer [15:49] nessita: http://pastebin.ubuntu.com/612302/ [15:50] me looks [15:51] ralsina: I'm not very skilled on this front, but looks like dbus and qt interaction is a no? [15:51] dbus and qt interaction is ok, but here we seem to be having a problem in that the qt mainloop is started in the wrong thread [15:51] which I have no idea how could happen. Specially since I have no idea who is starting a thread [15:52] is the qt reactor starting threads? [15:52] alecu: no idea [15:52] * ralsina looks [15:52] ralsina, no, it doesn't [15:52] just checked. [15:53] here's the interesting part of the C backtrace: http://pastebin.ubuntu.com/612304/ [15:53] ralsina, have you commented the import of sdtool in your branch? [15:54] alecu: didn't know I should :-) [15:54] ralsina, no, I'm trying to guess if some other part is starting the threads. [15:55] ok, I will dig some more [15:57] grr, broken deps [15:59] why are python deps not automatically determined at build time, wtf is ${python:Depends} for [16:00] I have no idea where the threads are coming from [16:01] and the segfault is caused by using a QTimer in the "wrong" thread [16:01] ralsina, alecu, mandel: are we having our meeting? [16:02] sure, let's [16:02] buuuut mandel: ping? [16:02] let's [16:02] I just loose tons of changes to a file due to lack of disk space! [16:02] CRAP [16:02] mandel's last words "errants" [16:03] ralsina: his errant use of english :) [16:03] he may be an errant knight [16:04] here, have 100 pesos. Go buy a terabyte! [16:04] alecu: I know... [16:04] alecu: you said that with old-unix-guy voice, too! [16:04] :-) [16:05] * ralsina really, really, really hates threads [16:05] don't blame threads for python [16:05] and now.... mumble won't connect. [16:05] dobey: you just took the words right out of my mouth [16:06] nope [16:06] * alecu will be right back [16:09] dobey: I hated threads before I started using python ;-) [16:10] ralsina: well threads in C are kinda weird I have to admit, java was so much easier to figure out [16:10] you are one of those "async code with a single thread" people, aren't you [16:10] No, I am the rare "don't share state" people [16:11] you know. real unix people. Those who are not afraid of processes. [16:11] ralsina: can you sms mandel? [16:11] nessita: maybe [16:11] let me skype/sms him [16:11] :-) [16:11]