[07:56] <mandel> morning all
[07:56] <mandel> ralsina: ping
[08:27] <ralsina> mandel: pong
[08:28] <mandel> ralsina: got time for a review?
[08:28] <ralsina> mandel: sure!
[08:28] <ralsina> nessita was having a problem with a slot being called twice?
[08:28] <ralsina> on a button click?
[08:28]  * ralsina is guessing
[08:29] <mandel> 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] <ralsina> mandel: known problem, is in the FAQ and everything. It's even on my tutorial ;-)
[08:30] <ralsina> you have to add a decorator to set the signature of the slot
[08:30] <ralsina> or check the extra parameter and do nothing if it's None
[08:30] <mandel> ralsina: yes, I told here to ignore the signal with no param
[08:30] <mandel> I did not know there is a decorator
[08:30] <ralsina> it's somewhat cleaner with the decorator
[08:31] <mandel> ralsina: yes, it is
[08:31] <ralsina> I really should spend some time in ART timezone today
[08:33] <mandel> ralsina: why?
[08:34] <ralsina> to help with this kind of thing :-)
[08:34] <mandel> now you know how it is to be the only one working ;)
[08:34] <mandel> ralsina: can you take a look at :https://code.launchpad.net/~mandel/ubuntu-sso-client/fix_signals_emition/+merge/59898
[08:34] <ralsina> sure thing!
[08:36] <mandel> ralsina: we have sd using named pipes :)
[08:36] <ralsina> mandel: neat!
[08:36] <ralsina> mandel: was it painful?
[08:36] <mandel> ralsina: no, the code now is soooo much nicer
[08:36] <ralsina> cool
[08:37] <mandel> there is no crazy COM code around and is a matter of installing the correct reactor, so the choice was good
[08:37] <ralsina> I've checked and IOCP is quite nice to use!
[08:52] <ralsina> mandel: checked the code in fix_signals_emition and looks ok, does it need fieldtesting?
[08:53] <mandel> ralsina: did I add any test instructions?
[08:53] <ralsina> just to run the tests
[08:53] <ralsina> You do the if in line 201, kwargs can be {}, right?
[08:54] <ralsina> if that's the case, you can still do callback (*fixedargs, **kwargs)
[09:05] <ralsina> mandel:  ^ (no hurry!)
[09:07] <mandel> ralsina: one sec, I need to fix something with a sd branch that broke and I'll look into it
[09:07] <ralsina> cool
[09:39] <mandel> ralsina: ok, so I've got sd running with naed pipes on windows performing all my syncs :)
[09:39] <ralsina> niiiiiiiice
[09:39] <mandel> ralsina: including shares, although I have no udfs in my account
[09:40] <ralsina> you should create one just in case
[09:40] <mandel> next step is to move everything to json, which aint easy
[09:40] <mandel> ralsina: yes, will do, lets first see if it syncs and get changes from windows and pushes them to the web :)
[09:40] <ralsina> mandel: are you using mattia for that, right?
[09:41] <ralsina> we have him until next friday ;-)
[09:41] <mandel> 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] <ralsina> ok, great
[09:42] <ralsina> just don't want him to be unused
[09:42] <ralsina> now, got 2' for my review?
[09:42] <ralsina> or if you prefer to just get needsfixing and comments, I am happy to do it that way ;-)
[09:43] <mandel> ralsina: yes, what was it, something about {}, right?
[09:43] <ralsina> right, line 201 and 202
[09:43] <ralsina> in https://code.launchpad.net/~mandel/ubuntu-sso-client/fix_signals_emition/+merge/59898
[09:43] <ralsina> if kwargs can be something like None, yes that's necessary, but if it is only {} then the if is useless
[09:44] <mandel> ralsina: it could be none
[09:44] <ralsina> ok then +1
[09:44] <ralsina> I hate than launchpad doesn't give you a nice way to jump to the source code in context
[09:44] <mandel> ralsina: it was the only reason I added it :)
[09:44] <mandel> haha file a bug ;)
[09:45] <mandel> ralsina: you know canonical, either there is a bug or there is a wiki page
[09:45] <ralsina> my bug would be "make it work like googlecode's commit view" ;-)
[09:45] <ralsina> I couldn't test it on natty because my VM is broken, and I am reinstalling
[09:46] <ralsina> so unless you did it...
[11:35] <fagan> still cant find a bug that I can do :/
[12:20] <ralsina> fagan:  this is really not the simplest codebase for small bugs :-(
[12:21] <ralsina> fagan: most of the code is pretty hairy
[12:22] <ralsina> fagan: is it a holiday in the UK or anything? It's pretty quiet today
[12:31] <fagan> ralsina: well I dont think it is
[12:32] <ralsina> fagan: ok
[12:32] <fagan> yeah im seeing that the code is a bit hairy from looking through the bugs
[12:32] <fagan> its a little bit hard to find a task then
[12:32] <fagan> not really a lot of low hanging fruit
[12:48] <duanedesign> rye: ping
[12:49] <rye> duanedesign, pong
[12:50] <duanedesign> good day rye
[12:51] <ralsina> fagan: I will ask at standup, maybe one of the developers has something in mind
[12:51] <duanedesign> rye: i cant find the u1conflict renaming script from the other week
[12:52] <rye> duanedesign, hmmm
[12:53] <fagan> ralsina: cool
[12:54] <duanedesign> rye: aha foound it
[13:05] <alecu> hola #ubuntuone!
[13:05] <fagan> hola alecu
[13:06]  * fagan was trying to think of the word dude but was too lazy to open google translate
[13:12] <duanedesign> hola alecu
[13:14] <alecu> hola fagan, duanedesign!
[13:15] <nessita> ralsina: meeting?
[13:17] <ralsina> annd.... I'm back. Meeting
[13:18] <ralsina> sorry but had a kid emergency
[13:19] <ralsina> this place's connection is way too crappy for mumble :-(
[13:19] <ralsina> grmbl, I will try again
[13:27] <ralsina> I keep getting dropped off mumble
[13:29] <ralsina> sorry guys but I will be back in my usual place for the next call, and then it will work.
[13:30] <nessita> mate time!
[13:30]  * fagan break
[13:32]  * ralsina tries to figure out how o order a non-turkish coffee
[13:32] <ralsina> It's not worth fighting this connection, will be back when I have decent internet :-(
[13:54] <thisfred> dobey: when switching u1cp from pylint to u1lint, (how) can I pass it '--ignore ui'?
[13:55] <thisfred> just adding that as an argument to u1lint does not work
[13:57] <thisfred> in general I think it would be good if it just passed all arguments it does not handle itself to pylint
[13:58] <nessita> 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] <alecu> nessita, +1
[13:58] <alecu> btw: riverbankcomputing's webservers seem to be hosted in turkey :P
[13:59] <mandel> me
[13:59] <nessita> still 30 seconds to go! :-)
[13:59] <mandel> booo
[13:59] <nessita> mandel: weren't you having lunch with @parents?
[13:59] <mandel> reactor.callLater(.30, me)
[14:00] <dobey> thisfred: it can't
[14:00] <mandel> 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] <mandel> :)
[14:00] <nessita> me
[14:00] <mandel> me
[14:00] <thisfred> me
[14:00] <nessita> ralsina, alecu, dobey, fagan?
[14:01] <alecu> me
[14:01] <dobey> 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] <dobey> me
[14:01] <nessita> only 2 to go! ralsina, fagan?
[14:02] <thisfred> 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] <nessita> ok, let's
[14:02] <nessita> DONE: QT windows control panel port, reviews, emails
[14:02] <nessita> TODO: more of the same
[14:02] <nessita> BLOCKED: a little by QT, but it will get better.
[14:02] <nessita> NEXT: mandel
[14:02] <thisfred> ignore argument I mean
[14:02] <mandel> 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] <mandel> TODO: Fix ubuntuone-dev merge proposal from dobeys remark. Propose merges for SD and SSO. Continue work for json
[14:02] <mandel> BLOCKED: No
[14:02] <mandel> thisfred, go
[14:02] <thisfred> * TODO https://bugs.launchpad.net/bugs/781119
[14:02] <thisfred> * TODO https://bugs.launchpad.net/bugs/781538
[14:02] <thisfred> * INPROGRESS https://bugs.launchpad.net/ubuntuone-control-panel/+bug/781875
[14:02] <thisfred> * INPROGRESS make u1cp use u1lint instead of pylint
[14:02] <thisfred> NEXT: alecu
[14:02] <ubot4> 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] <ubot4> 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] <ubot4> Launchpad bug 781875 in ubuntuone-control-panel "ERROR - ReplicationSettingsChangeError: args (<ubuntuone.controlpanel.dbus_service.ControlPanelBackend at /preferences (affects: 1) (heat: 17)" [Undecided,Confirmed]
[14:03] <alecu> DONE: a branch to put sensible names to the Qt widgets. Started digging into using qt-network as a replacement for libsoup
[14:03] <alecu> TODO: qt-network for today, thankyouverymuch. Meet andrew and lissete in tonight's dinner at the web&mobile sprint
[14:03] <alecu> BLOCKED: riverbankcomputing hosts its webserver in turkey
[14:03] <alecu> NOTE: tomorrow is a nat holiday
[14:03] <alecu> NEXT: dobey
[14:03] <dobey> λ DONE: Some more nightlies work, reviews
[14:03] <dobey> λ TODO: Patch logilab-common on O, Still some more nightlies work
[14:03] <dobey> λ BLCK: logilab-common test suite failing
[14:03] <fagan> me whoops
[14:03] <nessita> fagan: go!
[14:03] <fagan> sec writing it up 2 secs
[14:04] <nessita> 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] <nessita> mandel: tomorrow is only you and me!
[14:04] <nessita> (for windows port)
[14:04] <fagan> DONE
[14:04] <fagan> * Booked flights
[14:04] <fagan> * updated the wiki with travel info
[14:04] <fagan> * Looked for a bug to do
[14:04] <fagan> TODO
[14:04] <fagan> * Find a bug to do
[14:05] <fagan> Blocked
[14:05] <mandel> nessita: cool :)
[14:05] <fagan> * nope
[14:05] <fagan> oh and if anyone has any bug that I can do send it my way
[14:05] <alecu> thisfred, re:" * INPROGRESS make u1cp use u1lint instead of pylint", why are we doing this?
[14:06] <dobey> is tomorrow a turkish holiday too?
[14:06] <thisfred> alecu: we might not, if we can't change u1lint
[14:06] <nessita> dobey: nopes, but ralsina is still an argentinian resident
[14:06] <fagan> and can we start using the bytesize tag please
[14:06] <thisfred> alecu: the reason for doing it is consistency across projects
[14:06] <nessita> fagan: what's the bytesize tag for?
[14:06] <dobey> what the heck is "bytesize tag"?
[14:06] <nessita> fagan: and bug in which area/project are you looking for?
[14:07] <nessita> fagan: remember we're not in your head, so you need to be a little more explicit here :-)
[14:07] <fagan> 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] <alecu> 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] <fagan> its mainly done for unity at the moment
[14:07] <dobey> oh, no
[14:07] <thisfred> alecu: Sure
[14:08] <dobey> let's not bother with adding tags to bugs that we're not going to use ourselves
[14:08] <nessita> fagan: and when would we use such tag? I mean, can you please give an example?
[14:08] <fagan> nessita: give me a sec ill get the link
[14:08] <dobey> nessita: unity uses it as a means to increase outside contributions
[14:08] <nessita> fagan: don't make me read doc! my time is little and precious! :-P
[14:08] <nessita> dobey: ah\
[14:08] <dobey> nessita: ie, "these are the easy bugs that anyone can do"
[14:09] <nessita> not sure if we want to go that road then
[14:09] <nessita> fagan: did you discuss this with ralsina?
[14:09] <dobey> yeah i don't think it makes sense for us
[14:09] <fagan> nessita: he said he would mention it here
[14:09] <nessita> ah, I don't think we have those :-D ("easy bugs")
[14:09] <fagan> but he is off because of the interwebs
[14:10] <dobey> ralsina: btw, you need to do 1:1 with everyone on the team this week :)
[14:10] <fagan> nessita: well we *could* have some small things maybe even features that arent a priority
[14:10] <fagan> nessita: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
[14:11] <fagan> damn lp did that weird its doing it for all ubuntu projects
[14:11] <nessita> 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] <dobey> fagan: no it's not. it's doing it for ubuntu. ubuntu is a distribution
[14:12] <fagan> 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] <fagan> dobey: yeah thats what I mean
[14:13] <dobey> distributions don't have projects, but they do have packages; if you want just project bugs then use the project bugs page instead
[14:13] <dobey> nessita: well, there really is no way it can be shared across the whole team
[14:13] <dobey> nessita: only us and mobile can use it really, but i don't think we should
[14:13] <nessita> dobey: and foundations for the client and protocol
[14:14] <dobey> nessita: well, maybe; protocol is used on server too, and normal users can't test whether it will break that or not
[14:14] <fagan> better link https://bugs.launchpad.net/ubuntu/+source/unity/+bugs?field.tag=bitesize
[14:14] <dobey> desktopcouch is sort of similar there, but not as bad
[14:15] <dobey> fagan: https://bugs.launchpad.net/unity/
[14:15] <nessita> dobey: well, you could run a desktop client pointing to that protocol and confirm, but I see your point
[14:15] <dobey> nessita: right, but that doesn't tell you if the server code breaks :)
[14:15] <fagan> dobey: they dont have the tag in use for those bugs
[14:15] <dobey> anyway, i think it's also a waste of time
[14:15] <fagan> dobey: its against the distro package
[14:15] <dobey> anything that any of us coudl classify as "bitesize" we should be fixing immediately anyway, most likely
[14:16] <dobey> because it will take just as much time to fix it, as it will to add the tag to the bug
[14:16] <fagan> Well I suppose unity has more little bugs that could be left alone
[14:16] <dobey> if it will take longer, it's not bite size :)
[14:16] <fagan> u1 doesnt have many of those
[14:16] <fagan> maybe we should have a fagan tag where bugs that I can do get marked :D
[14:17] <dobey> 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] <thisfred> 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] <dobey> thisfred: well, right, which is why i said "desktopcouch also, but it's not as bad"
[14:18] <fagan> thisfred: well most backend stuff dont get many casual contributors in general
[14:18] <dobey> thisfred: however, i don't think wasting time tagging bugs in that manner is useful
[14:18] <thisfred> agreed
[14:18] <thisfred> fagan: because it's not possible to contribute ;)
[14:18] <nessita> alecu: does this ring any bell? http://pastebin.ubuntu.com/612270/
[14:19] <fagan> anyway then keep an eye out for smaller bugs for me then and ping me when you see one
[14:19] <dobey> every "small" bug i end up deciding to work on, turns into a snowballing nightmare
[14:19] <fagan> I can sort it out and spread the loads out a bit and learn a bit too
[14:21] <fagan> oh I didnt know the distro package tracks the project bugs now
[14:21] <fagan> thats nice
[14:22] <dobey> huh?
[14:22] <dobey> it doesn't
[14:22] <ralsina> one-on-one with everyone on thursday
[14:23] <fagan> dobey: if you look at the unity page under the distro package it says that it tracks the unity project too
[14:23] <fagan> dobey: look just under the top of here https://bugs.launchpad.net/ubuntu/+source/unity/+bugs?field.tag=bitesize
[14:23] <dobey> no?
[14:24] <fagan> oooh misread it
[14:24]  * fagan really needs to take more breaks 
[14:25] <ralsina> dobey: pretty much every small bug in u1 so far was a huge bug that's well hidden ;-(
[14:25] <nessita> ralsina: say me!
[14:25] <ralsina> me
[14:25] <nessita> ralsina: go
[14:25] <ralsina> DONE: teh leads call, reviews, administrivia
[14:26] <ralsina> TODO: mgmt call in 5 minutes, more administrivia, schedule 1-on-1s,
[14:26] <ralsina> BLOCKED: nope
[14:26] <nessita> ralsina: any idea why accessing Dbus from qt+reactor is raising exceptions.MemoryError?
[14:27] <ralsina> nessita: nope
[14:27] <nessita> alecu: ping
[14:27] <ralsina> nessita: usually that means you are getting a conflict between two different garbage collectors
[14:27] <nessita> ralsina: can you confirm that from http://pastebin.ubuntu.com/612270/ ? I mean, does that trace give you more info?
[14:28] <ralsina> 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] <ralsina> nessita: probably not that
[14:28] <nessita> either I get MemoryError or Segmentation fault
[14:29] <dobey> ah, the joys of integrating reactor, main loops, dbus, etc...
[14:29] <nessita> dobey: "the joys"
[14:30] <ralsina>  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] <nessita> 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] <nessita> is appearing when importing syncdaemon stuff into the control panel
[14:30] <ralsina> not to mention that line 1 means you are still importing gtk ;-)
[14:30] <nessita> ralsina: I'm not
[14:30] <ralsina> nessita: yes you are
[14:31] <nessita> ralsina: ...
[14:31] <ralsina> /usr/lib/pymodules/python2.7/gtk-2.0/gtk/__init__.py:127 means you are
[14:31] <nessita> ralsina: define "you"
[14:31] <ralsina> ok, the code is importing gtk somewhere.
[14:31] <dobey> nessita: no, but i've seen it before; in the build logs for nightlies iirc
[14:32] <dobey> i have no idea what PyOS_InputHook is, either
[14:35] <alecu> nessita, pong
[14:35] <nessita> alecu: does this ring any bell? http://pastebin.ubuntu.com/612270/
[14:36] <alecu> nessita, not at all
[14:36] <nessita> alecu: ok, seems like qt4reactor + dbus + qt mainloops does not get along
[14:39] <dobey> nessita: where is that QThread warning coming from? perhaps that's the problem
[14:40] <dobey> sigh, logilab
[14:40]  * dobey wonders how this thing even made it into the debian archive
[14:42] <nessita> dobey: I have no idea, I'm not creating nor using any QTHread
[14:42] <nessita> not QThread
[14:43] <nessita> ralsina: any clues where that QThread comes from?
[14:43] <ralsina> that warning may mean you are setting up a timer on a thread that was started from python
[14:43] <ralsina> or that you are doing it before initializing the QApplication
[14:43] <ralsina> but I would worry first about getting a gtk warning...
[14:44] <nessita> ralsina: I'm not, I can confirm that. And I'm not using any explicit timer not thread...
[14:44] <alecu> 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] <nessita> 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] <dobey> i don't think the gtk warning is the problem
[14:46]  * nessita neither
[14:47] <nessita> alecu, ralsina: the gtk warning appears when this code is executed: from ubuntuone.platform.linux.tools import SyncDaemonTool
[14:50] <dobey> nessita: that's importing from dbus_interface too, so maybe the same problem you mentioned yesterday
[14:50] <nessita> dobey: about the reactor?
[14:50] <nessita> hum...
[14:51] <dobey> nessita: right, though not sure where gtk would come from; nothing in syncdaemon should be using gtk anywhere
[14:51] <nessita> right
[14:52] <dobey> 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] <dobey> nessita: then you can see what's importing it at least
[14:52] <nessita> ralsina, alecu, dobey: bug #526676
[14:52] <ubot4> 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] <nessita> seems like pyinotify is doing something nasty?
[14:53] <dobey> oh, pynotify
[14:53] <alecu> nessita, what are we using SyncDaemonTool for?
[14:53] <nessita> alecu: most of sd_client stuff
[14:53] <ralsina> yes, it's pynotify
[14:53] <nessita> alecu: anyways, the warning appears the same when importing anything related to syncdaemon
[14:53] <dobey> well that makes no sense
[14:53] <nessita> ralsina, alecu: anyways, I'm pretty sure that warning is not related to the sg faults
[14:53] <nessita> seg*
[14:54] <alecu> nessita, ok, but the dependencies of syncdaemontool seem to be too convoluted, so we probably should get rid of that.
[14:54] <ralsina> nessita: ok, could be
[14:54] <dobey> why would a C module import pygtk?
[14:55] <dobey> and i'm pretty sure nessita's error is due to the threading/timeout issue
[14:58] <nessita> 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] <ralsina> nessita: ok
[14:58] <ralsina> nessita: I am in the mgmt call, I can try to debug it in about 20 minutes, I think
[14:58] <nessita> ralsina: ok
[14:59] <nessita> I'll move on commneting out that code
[15:01] <ralsina> nessita: http://www.qtcentre.org/threads/12135-PyQt-QTimer-problem-FIXED
[15:01] <ralsina> it's pretty much a generic message that can be triggered by a bunch of internal qt things
[15:01] <ralsina> like, loading an image
[15:02] <nessita> ralsina: so you say that it has nothing to do wth the sg fault, right?
[15:02] <ralsina> nessita: probably nothing to do, yes
[15:03] <ralsina> 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] <ralsina> nessita: done with the call, what branch are you trying?
[15:10] <dobey> YAY
[15:10] <nessita> ralsina: browsing link
[15:10] <nessita> ralsina: https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/bind-some-more
[15:11] <ralsina> nessita: ok, branching
[15:11] <nessita> ralsina: branch and run DEBUG=True PYTHONPATH=. ./bin/ubuntuone-control-panel-qt
[15:11] <ralsina> nessita: so you get the crash every time, right?
[15:11] <nessita> then, uncomment qt/controlpanel.py the line that reads
[15:11] <nessita> self.backend.file_sync_status()
[15:11] <nessita> and re-run, and boom
[15:12] <nessita> ralsina: yes, every time for me
[15:12] <ralsina> ok, let's try...
[15:14] <ralsina> reproduced.
[15:14] <ralsina> now, give me a few moments to try and debug it
[15:14] <nessita> ralsina: withy memoryerror or seg fault?
[15:14] <ralsina> segfault
[15:17] <ralsina> and it doesn't seem to be happening in a deferred, which may make it slightly easier
[15:17]  * mandel => errants
[15:18] <ralsina> nessita: you didn't have this before you started this branch, right?
[15:19] <nessita> ralsina: nopes, and even if you comment the line "self.backend.file_sync_status()" there is no crasg
[15:19] <nessita> carsh
[15:19] <nessita> crash!
[15:19] <nessita> :-)
[15:19] <ralsina> cash! ;-)
[15:19] <ralsina> ok cool, let me dig a bit more then
[15:19] <nessita> ralsina: I bet is related to accessing dbus from qt+reactor
[15:19] <dobey> errants
[15:20] <ralsina> probabbly
[15:20] <nessita> which sucks! :-)
[15:20] <nessita> is very hard to debug
[15:20] <ralsina> yes, it is
[15:22] <ralsina> hey, got the memoryerror now
[15:22] <nessita> ralsina: right, is a timing issue
[15:22] <nessita> race condition maybe
[15:24] <ralsina> when there is a segfault, there is no QTimer error
[15:25] <nessita> ralsina: but only becasue (I think) the seg fault happened before the stdout buffer was flushed
[15:26] <ralsina> I am now seing the control panel :-D
[15:27] <ralsina> that was an interesting fluke
[15:27] <ralsina> I got the memory error *and* the control panel became visible. Once.
[15:28] <ralsina> so it really smells like a race condition
[15:44] <ralsina> it is because of calling dbus :-(
[15:45] <nessita> ralsina: yes! any way of fixing it?
[15:45] <ralsina> nessita: working on it
[15:45] <nessita> ralsina: awesome
[15:46] <ralsina> it *may* get fixed if we keep a reference to something, but not 100% sure
[15:48] <ralsina> ok, something *is* starting threads, and the segfault is on a QTimer
[15:49] <ralsina> nessita: http://pastebin.ubuntu.com/612302/
[15:50] <nessita> me looks
[15:51] <nessita> ralsina: I'm not very skilled on this front, but looks like dbus and qt interaction is a no?
[15:51] <ralsina> 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] <ralsina> which I have no idea how could happen. Specially since I have no idea who is starting a thread
[15:52] <alecu> is the qt reactor starting threads?
[15:52] <ralsina> alecu: no idea
[15:52]  * ralsina looks
[15:52] <alecu> ralsina, no, it doesn't
[15:52] <alecu> just checked.
[15:53] <ralsina> here's the interesting part of the C backtrace: http://pastebin.ubuntu.com/612304/
[15:53] <alecu> ralsina, have you commented the import of sdtool in your branch?
[15:54] <ralsina> alecu: didn't know I should :-)
[15:54] <alecu> ralsina, no, I'm trying to guess if some other part is starting the threads.
[15:55] <ralsina> ok, I will dig some more
[15:57] <dobey> grr, broken deps
[15:59] <dobey> why are python deps not automatically determined at build time, wtf is ${python:Depends} for
[16:00] <ralsina> I have no idea where the threads are coming from
[16:01] <ralsina> and the segfault is caused by using a QTimer in the "wrong" thread
[16:01] <nessita> ralsina, alecu, mandel: are we having our meeting?
[16:02] <ralsina> sure, let's
[16:02] <ralsina> buuuut mandel: ping?
[16:02] <alecu> let's
[16:02] <nessita> I just loose tons of changes to a file due to lack of disk space!
[16:02] <nessita> CRAP
[16:02] <ralsina> mandel's last words "errants"
[16:03] <dobey> ralsina: his errant use of english :)
[16:03] <ralsina> he may be an errant knight
[16:04] <alecu> here, have 100 pesos. Go buy a terabyte!
[16:04] <nessita> alecu: I know...
[16:04] <ralsina> alecu: you said that with old-unix-guy voice, too!
[16:04] <alecu> :-)
[16:05]  * ralsina really, really, really hates threads
[16:05] <dobey> don't blame threads for python
[16:05] <alecu> and now.... mumble won't connect.
[16:05] <fagan> dobey: you just took the words right out of my mouth
[16:06] <dobey> nope
[16:06]  * alecu will be right back
[16:09] <ralsina> dobey: I hated threads before I started using python ;-)
[16:10] <fagan> ralsina: well threads in C are kinda weird I have to admit, java was so much easier to figure out
[16:10] <dobey> you are one of those "async code with a single thread" people, aren't you
[16:10] <ralsina> No, I am the rare "don't share state" people
[16:11] <ralsina> you know. real unix people. Those who are not afraid of processes.
[16:11] <nessita> ralsina: can you sms mandel?
[16:11] <ralsina> nessita: maybe
[16:11] <ralsina> let me skype/sms him
[16:11] <nessita> :-)
[16:11] <dobey> oh, you're a fundamentalist
[16:12] <fagan> I can sms him for like 10c if someone pms me his number
[16:12] <ralsina> dobey: history will prove us right ;-)
[16:12] <ralsina> sms and twittered him
[16:12] <dobey> ralsina: shouldn't you be at church? :)
[16:13] <ralsina> threads are basically the wrong solution for almost anything beyond trivial. And once you start using them right, you may as well be using real parallelism with message passing.
[16:14]  * alecu believes "threading" to be a great tool for some purposes.
[16:15] <alecu> just not UI nor network code.
[16:15] <ralsina> nessita: silly question, but where is the qt main loop being started?
[16:16] <nessita> ralsina: controlpanel.py:main
[16:16] <nessita> ralsina: you mean the QApplication, right?
[16:17] <alecu> ralsina, the qt main loop is being handled by the qt reactor.
[16:17] <ralsina> alecu: oooook
[16:18] <alecu> ralsina, so "reactor.run()" would be the time it's started.
[16:18] <ralsina> alecu: cool, thx
[16:18] <nessita> ah
[16:19] <ralsina> anyone has a link to the page of *this* qt4reactor?
[16:20] <dobey> url is in u1trial
[16:20] <dobey> if you don't have it and use --qt-reactor=ui as an argument to it, it should complain with the url
[16:20] <ralsina> neverming, got it
[16:21] <alecu> ralsina, https://github.com/ghtdak/qtreactor
[16:22] <fagan> nessita: are we getting added to that all in one system settings thing in 11.10
[16:22] <fagan> (the cp I mean)
[16:23]  * fagan was just playing about with it and wondered 
[16:23] <nessita> fagan: at first, no, but is not confirmed.
[16:23] <fagan> nessita: cool just wondered
[16:25] <dobey> i don't think we belong there
[16:26] <fagan> dobey: well im on the fence I can see why we should be in there but I dont think it would be as good as it would by itself
[16:26] <ralsina> ha, this segfault hits on so many different things it's almost pretty
[16:26] <nessita> ralsina: what are we doing with the meeting? I would need to have lunch at 1pm ART, if possible
[16:27] <ralsina> nessita: I got no response from mandel
[16:27] <ralsina> I say we delay again until after your lunch, but then it will be 8PM here
[16:27] <ralsina> so, we can do that if it's not going t be very long
[16:28] <nessita> argh :-/
[16:28] <nessita> ralsina: what's the main goal of the meeting? do you need a specific date to pass along to the bosses?
[16:28] <ralsina> nessita: that is for friday
[16:29] <ralsina> this meeting is because you were worried about task assignments
[16:29] <nessita> ralsina: are we having a meeting on Friday?
[16:29] <ralsina> yes we are
[16:29] <AJenbo> Hi when ever i try to go to https://one.ubuntu.com/contacts/ i get a 504 gatway time out error :(
[16:29] <ralsina> I got the magical "it works" race condition
[16:29] <nessita> ralsina: I'm still am, given that alecu and me are going one way, and maybe we need to change to another way (referrring to reactor/tcnamedpipes/etc)
[16:29] <alecu> nessita, yes, I remember you were the one that asked for this meeting today!!!
[16:30] <AJenbo> My iPhone also gives an error when i try to sync and my Android gives up after uploading 27
[16:30] <nessita> alecu: kinda, ralsina said "let s have a meeting on X day" and I suggested to move it sooner to know how we should be moving forward
[16:31] <ralsina> the two meetings are for different things
[16:31] <beuno> AJenbo, we're shutting down contact syncing in a week
[16:31] <AJenbo> After a few attempts it has not removed all my existing contacts from my android but not downloaded any from the web
[16:31] <AJenbo> beuno for good?
[16:31] <nessita> ralsina: true, but in order to answer "when" we need to know "how" :-)
[16:31] <ralsina> nessita: that's why this meeting is first ;-)
[16:32] <nessita> exactly! :-)
[16:32] <ralsina> ok, see you guys at 8PM turkey time
[16:32] <beuno> AJenbo, for a few months. We're going to completely replace the server and clients for something more... stable. And, free.
[16:32] <nessita> ralsina: that is how long from now?
[16:32] <ralsina> 88 minutes
[16:32] <ralsina> so, after your lunch
[16:32] <ralsina> hopefully manuel will be around
[16:32] <AJenbo> Beuno, ok, better clients sounds like a big plus :)
[16:32] <alecu> it's already 17.32 madrid time
[16:33] <AJenbo> Still i would love to have some phone numbers to call in the mean time, any idears?
[16:33] <beuno> AJenbo, we will only have clients for iOS and Android, though. Which sounds like what you have.
[16:33] <AJenbo> Yep, the most important is the Android
[16:34] <AJenbo> beuno: so no more desktop sync?
[16:34] <ralsina> nessita: basically, this segfault is happening in a combination of elements that we don't really need right now (dbus+qt)
[16:34] <beuno> AJenbo, yes, desktop sync stays teh same.
[16:34] <beuno> AJenbo, no good answer for now, though  :(
[16:34] <nessita> ralsina: we do need, to be able to develop on linux...
[16:35] <ralsina> nessita: yesssss but it's not what we need to deliver
[16:35] <AJenbo> K, i might be able to get some of them from my desktop and type them in manually
[16:35] <ralsina> it's ok, I will try to debug it
[16:35] <nessita> ralsina: right, but...
[16:35] <AJenbo> probably can sync some from facebook also
[16:35] <ralsina> but I know I know.
[16:35] <beuno> AJenbo, Facebook doesn't provide phone or email addresses
[16:35] <nessita> ralsina: I can try other options, such as: faking the syncdaemon info and avoiding caling dbus altogether
[16:35] <nessita> calling*
[16:36] <nessita> that will work
[16:36] <ralsina> nessita: could use the current mocks from tests?
[16:36] <AJenbo> Really? I did call some one via the phone number on facebook, though it's posible that i was doing it via the website
[16:36] <nessita> ralsina: mocks in tests are DBus services, so I guess no. I think the best route is to fake the results on our modules
[16:36] <ralsina> nessita: ok
[16:36] <AJenbo> I'm not talking Ubuntu one <-> facebook, but android <- facebook
[16:36] <ralsina> why are we using twisted here for, again? Just to get deferreds on dbus calls?
[16:37]  * ralsina is dizzy already ;-)
[16:37] <nessita> ralsina: on the QT controlpanel?
[16:37] <ralsina> nessita: yes
[16:37] <AJenbo> Any way it can be done manually in any case
[16:37] <nessita> ralsina: nopes, it was for communicatin with SD, that is going to be replaced by the txnamedpipes, that I think they use twisted as well? can; t tell for sure, that tech is still a ghost for me
[16:38] <nessita> speaking of which, I think there are ghosts in my new place
[16:38] <AJenbo> beuno: any way i can keep a tab on the progress?
[16:38] <nessita> but that is not related :-D
[16:38] <ralsina> nessita: yes, unrelated ;-)
[16:38] <beuno> AJenbo, contact sync for Android should be shipped in July or so
[16:38] <nessita> ralsina: I'm not sure if, when migrating to txnamedpipes, we will keep using the reactor or not
[16:38] <beuno> AJenbo, I'll blog about it as we go
[16:38] <nessita> alecu: can you help me on that answer? ^
[16:38] <ralsina> ok, on windows SD gives us txnamedpipes as IPC, so twisted. But on Linux it gives us dbus, right?
[16:39] <AJenbo> beuno: thanks i will keep an eye out
[16:39] <alecu> ralsina, that's right.
[16:39] <fagan> ralsina: mterry did a nice u1 post on planet
[16:40] <fagan> about the api stuff
[16:40] <alecu> nessita, the "tx" in txnamedpipes means "twisted"
[16:40] <alecu> nessita, so, the twisted reactor is mandatory.
[16:41] <ralsina> ok. we will use twisted because we need it on windows. On Linux we could get along without it :-(
[16:41] <nessita> alecu: thanks! I always bind tx with transfers
[16:41] <alecu> nessita, yeah. talk about acronym overload.
[16:42] <nessita> ralsina: the thing is, if we're pushing the QT iface to linux, we need to resolve this...
[16:42] <ralsina> nessita: indeed
[16:42] <nessita> not right now, but in the short term
[16:43] <ralsina> it is surely solvable, because 1 in every 20 attempts it works already ;-)
[16:43] <ralsina> I will keep hacking at it, surely something will come up
[16:43] <nessita> awesome
[16:43] <alecu> ralsina, I propose you don't waste time making this run on linux, since that is not our focus.
[16:44] <ralsina> a stupid *twisted* question. What is it the inlinecallbacks decorator does?
[16:44] <alecu> we won't be using qt+dbus for the next 4 weeks
[16:44] <alecu> ralsina, not so stupid.
[16:44] <ralsina> alecu: right, but if nessita is going to help from linux, it would be nice to have it soon. Since her days are more productive than mine, I prefer to waste one of mine ;-)
[16:45] <nessita> anyways, like I mentioned I can fake the results
[16:45] <alecu> ralsina, ok, but it would be simpler if we just use mock data on linux, and then we make it run on windows with the proper reactor and transport there.
[16:45] <alecu> nessita, exactly.
[16:46] <alecu> ralsina, back to inlinecallbacks
[16:46] <alecu> ralsina, it turns a generator into a series of callbacks
[16:46] <ralsina> ok, then let's do that. I will give myself a deadline of today. If I can't fix it, it stays broken for a while
[16:46] <alecu> ralsina, let me fetch an example.
[16:46] <ralsina> alecu: explain me with file_sync_status if possible ;-)
[16:47] <alecu> ralsina, please point me at that file
[16:47] <ralsina> ubuntuone/controlpanel/backend.py +393
[16:47] <alecu> oh, backend.py
[16:49] <ralsina> I think I understood from the docs. Basically every yield gives a deferred, and when the deferred is finished the execution continues?
[16:50] <nessita> ralsina: yes. If you don't yield on it, it continues "in the background"
[16:51] <ralsina> ok
[16:51] <ralsina> now that makes sense
[16:51] <nessita> ralsina: that usually is done when you don't need to wait for the result, like in the file_sync_status case
[16:51] <nessita> ralsina: where the status is signaled in a callback
[16:52] <dobey> lunch time, bbiab
[16:52] <alecu> ralsina, "every yield gives a deferred" is wrong.
[16:53] <ralsina> nessita: ok
[16:53] <alecu> ralsina, "every yield *takes* a deferred, and returns the result when the deferred is called back"
[16:53] <alecu> ralsina, here's the same code with callbacks: http://pastebin.ubuntu.com/612329/
[16:53] <alecu> ralsina, (not tested, just translated from memory)
[16:55] <ralsina> alecu: ok, it's pretty clear :-)
[17:02] <ralsina> the segfault is inside qtreactor. How about that for ugly?
[17:03]  * nessita runs scared
[17:04] <ralsina> ok, here's my current guess
[17:05] <ralsina> ok, no, no guess yet
[17:05] <nessita> oh
[17:05] <ralsina> The QTimer is in qtreactor. BUT that is being called by the dbus loop
[17:06] <nessita> ralsina: I would hope that all of them run in the same main loop, but seems like not
[17:06] <ralsina> nessita: yeah, this is not smelling right. We may be using one thing or the other in the wrong way
[17:07] <ralsina> or like dobey will surely say, we have one thing too many in the mix
[17:13] <ralsina> time to go hardcore. Installing valgrind
[17:14] <nessita> ok, I'll have some lunch now
[17:20] <ralsina> This doesn't look fixable :-(
[17:26] <ralsina> Of COURSE the segfault is in the C side of python-dbus...
[17:29] <mandel> ralsina: ping
[17:29] <ralsina> mandel: pong
[17:29] <mandel> sorry I had to sort my life, I have finally done so
[17:29] <mandel> ralsina: you were saying?
[17:29] <mandel> I mean on twitter
[17:30] <ralsina> mandel: cool. done it with regional eastern european dance algorithms? ;-)
[17:30] <mandel> ralsina: yes, you could say so ;)
[17:30] <ralsina> mandel: I know it's late, but can you stay for a short mumble in 30 minutes?
[17:30] <ralsina> about task assignments and sucj
[17:30] <mandel> ralsina: I was going to stay for longe
[17:30] <mandel> ralsina: I took some time of, so of course
[17:30] <nessita> mandel: we had a meeting at 12 ART
[17:30] <mandel> nessita: did we?
[17:31] <nessita> yes! :-)
[17:31] <mandel> oh, shit the one we had at 9 that was moved....
[17:31] <nessita> yeap
[17:31] <mandel> sorry sorry
[17:31] <ralsina> ha! it's a bug in Qt's dbus integration!
[17:32] <ralsina> #0  0x00007ffff55201ff in QObject::startTimer(int) () from /usr/lib/libQtCore.so.4
[17:32] <ralsina> #1  0x00007ffff584672c in add_timeout (timeout=0x116c840, data=0x13428c0) at /build/buildd/python-qt4-4.8.3/dbus/dbus.cpp:146
[17:32] <mandel> ralsina: where is that?
[17:32] <ralsina> that data pointer is invalid
[17:32] <mandel> ralsina: qtreactor, txnamedpipes or other?
[17:32] <ralsina> mandel: a branch from nessita trying to use twisted+dbus+qt on linux
[17:33] <mandel> ralsina: oh my!
[17:33] <ralsina> which I am tempted to say we should NOT try to do in the future ;-)
[17:33] <dobey> heh
[17:33] <mandel> ralsina: hahah
[17:33] <ralsina> we can use just qt+dbus, although it means changing a ton of code
[17:33] <ralsina> or gtk+dbus
[17:34] <nessita> ralsina, mandel, alecu: I'm still chewing but we can have the meeting in.. 10 minutes?
[17:34] <mandel> ralsina: which dbus lib, are we useing the python bindings?
[17:34] <mandel> ralsina: what about the dbus in qt?
[17:34] <mandel> nessita: I'll be here
[17:34] <nessita> not sure what is the status of alecu
[17:35] <ralsina> mandel: this is using the python dbus bindings. The qt dbus stuff is not wrapped for python, AFAIK
[17:35] <mandel> ralsina: hm… are you sure: http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/dbus.html
[17:35] <alecu> nessita, I'm around here.
[17:36] <ralsina> mandel: that's just the main loop integration
[17:36] <mandel> ralsina: exactly, are we using that?
[17:36] <ralsina> mandel: yes
[17:36] <nessita> mandel: yes
[17:36] <mandel> oh, ok
[17:36] <mandel> bummer
[17:37] <dobey> mandel: your branch has a conflict in bin/ubuntuone-syncdaemon
[17:37] <mandel> dobey: ok, I'll take a look, I think another branch was added before
[17:37] <mandel> should be easy to solve
[17:37] <mandel> dobey: may I have the url?
[17:38] <dobey> https://code.launchpad.net/~mandel/ubuntuone-client/provide_windows_vm_helper/+merge/60586
[17:38] <alecu> mandel, ralsina, nessita: can we do the meeting soonish?
[17:38] <nessita> alecu: I'm still chewing, but let's
[17:38] <ralsina> fine by me
[17:38] <mandel> I'm here
[17:38] <nessita> mandel, ralsina: mumble
[17:39] <mandel> nessita: launching it
[17:57] <dobey> grr, where is this guy at that was supposed to come and give me an estimate for fixing my yard
[18:13] <facundobatista> dobey, maybe playing poker with the guy that supposed to come last week and fix my roof :|
[18:13] <dobey> heh
[18:13] <dobey> partypoker.net
[18:13] <dobey> i should play that
[18:14] <thisfred> dobey: I notice tarmac does not run tests for ubuntuone-couch at all when merging.
[18:15] <dobey> eh?
[18:16] <dobey> verify_command = ./run-tests
[18:16] <dobey> so lies
[18:16] <nessita> thisfred: probable the bash script does not have the set -e thingy?
[18:16] <thisfred> dobey: well trunk has 3 broken tests
[18:16] <thisfred> michael's latest branch broke them
[18:17] <nessita> thisfred: can you please link me to run-tests?
[18:17] <thisfred> nessita: http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-couch/trunk/view/head:/run-tests
[18:18] <dobey> uhm
[18:19] <nessita> thisfred: right, the problem is that script
[18:19] <nessita> thisfred: you need to "set -e" at the top
[18:19] <nessita> thisfred: and also, `which xvfb-run` u1trial -c "$MODULE" && style_check should be:
[18:19] <nessita> `which xvfb-run` u1trial -c "$MODULE"
[18:19] <nessita> style_check
[18:19] <thisfred> ok
[18:20] <dobey> right, that
[18:20] <thisfred> nessita: that latest change will run the style check when tests fail, which is less than useful though or not?
[18:21] <dobey> no it won't
[18:21] <nessita> thisfred: nopes, with set -e, the script will abort as soon as any command returns non zero status
[18:21] <dobey> err
[18:21] <dobey> you need to set -e also
[18:21] <thisfred> ah
[18:21] <thisfred> ok, done
[18:21] <thisfred> thx!
[18:21] <nessita> thisfred: wanna a review?
[18:21] <thisfred> nessita: in a bit
[18:22] <dobey> what horrible project names
[18:22] <thisfred> I need to split this out into a new branch, I was working on something else
[18:22] <nessita> thisfred: let me know
[18:23] <thisfred> thx
[18:23] <nessita> dobey: I'm tempted to charge you a dollar every time you complain about something. But then I realized someone can do that to myself  and steal all my money :-D
[18:27] <dobey> nessita: when did u1cp start using python-apt?
[18:27] <dobey> nessita: not aptdaemon, but apt?
[18:27] <nessita> dobey: midish last cycle, I think
[18:27] <nessita> along with aptdaemon
[18:27] <thisfred> nessita: dobey:  https://code.launchpad.net/~thisfred/ubuntuone-couch/fix-tests-and-run-tests/+merge/62169
[18:28] <dobey> nessita: how was it that nightlies were building at all, since neither is in the Build-Depends?
[18:28] <nessita> mandel: help?
[18:28] <nessita> dobey: ... i don't know
[18:30] <nessita> dobey: seems like a bug in the packaging (for natty as well). I would guess python-aptdaemon is bringing it?
[18:30] <nessita> dobey: would you please file me a bug?
[18:31] <dobey> well i don't think the ubuntu package is running unit tests
[18:31] <dobey> i am fixing nightlies right now
[18:31] <nessita> dobey: right, but could you please file one so I can fix natty and oneiric packages?
[18:31] <nessita> thisfred: approved
[18:32] <thisfred> thanks!
[18:40] <dobey> hrmm, the qt stuff isn't getting installed yet either
[18:40] <dobey> but i guess that's fine, since it's still pretty broken
[18:41] <mandel> nessita: tell me
[18:42] <nessita> mandel: I fixed it!
[18:42] <mandel> oh, sorry I was havin coffee, what was it?
[18:43] <nessita> mandel: when running tests without the run-tests script, I needed to pass a --qt-reactor option otherwise I was getting ugly errors
[18:43] <mandel> nessita: yes, the reactor that is used by default is the glib one
[18:43] <nessita> right
[18:43] <mandel> I'm going to fix the merge proposal for ubuntu-dev-tools to make it more obvious
[18:44] <mandel> maybe say something like no reactor specified or something
[18:48] <nessita> mandel: did you change the name of the CredentialsManagementTool on linux?
[18:48] <mandel> nessita: no AFAIK
[18:48] <mandel> why?
[18:49] <nessita> mandel: grabbing some evidence, one sec
[18:49] <mandel> nessita: i dont recall changing the name to be hones...
[18:49] <nessita> mandel: bug #787126 and now the thing that I have installed does not have the CredentialsManagementTool defined. bzr blaming now...
[18:49] <ubot4> Launchpad bug 787126 in ubuntuone-client "Ubuntuone can't access the credentials and fals to open at startup (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/787126
[18:50] <nessita> 971.3.18 mandel@ | class CredentialsManagementProxy(object):
[18:50] <nessita> mandel: why did you change the name to CredentialsManagementProxy?
[18:50] <mandel> nessita: I really do not remember doing that....
[18:51] <nessita> mandel: where did CredentialsManagementTool go? :-)
[18:51] <mandel> I mean, I trust you that I did the change, I dont remember why or when…
[18:51] <mandel> nessita: was it last week?
[18:51] <nessita> no idea, browsing LP now
[18:52] <nessita> mandel: http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-client/trunk/revision/984#ubuntuone/platform/linux/credentials.py
[18:52] <mandel> nessita: let me take a look at the code
[18:52] <nessita> mandel: "Date: 2011-05-12 22:24:08 This branch fixed the issue where windows does not have credential management code. This branch does the following:
[18:52] <nessita> * Refactor the CredentialsManagementTool so that it can be used by other platforms.
[18:52] <nessita> * Implemented the CredentialsManagement code for Windows."
[18:53] <mandel> nessita: hm, it looks like I did the change aand did not double check that no one was accessing the creds modul directly
[18:54] <nessita> mandel: CredentialsManagementTool is a documented API, you should nor change it nor remove it
[18:54] <nessita> mandel: all the extremely long docstrings are there for a reason! :-)
[18:54] <nessita> well, were there :'*
[18:54] <nessita> :'(
[18:55] <mandel> nessita: the are in ubuntuone/credentials.py
[18:55] <mandel> nessita: it was move out of platform, that is the reason why the docs are not there, they are in a diff location
[18:55] <mandel> where is the import error happening?
[18:56] <nessita> mandel: in ubuntuone-launch, and it can be happening on many places, that is public API and is not meant to be changed or moved
[18:56] <nessita> if you needed the same functionality, you should have move the logic but leave the name and functionality as is
[18:56] <mandel> nessita: ok, I can change it back to its location, I did not know that was a public api
[18:56] <mandel> nessita: the idea was to share the logic, not copy it
[18:57] <nessita> mandel: is ok, you can move the logic without destroying the API
[18:57] <dobey> it's python. anything installed in /usr/share/pyshared is public api whether you want it to be or not
[18:57] <nessita> and the import paths
[18:57] <dobey> unless you're blocking it being used with the __all__=[] hack, but then you can't use it from other modules in the same code, so also fail
[18:57] <mandel> yes, sorry I though it was just an internal class not share over diff things
[18:57] <mandel> lame from my part...
[18:57] <nessita> mandel: on doubt, eveything is public
[18:58] <mandel> ok
[18:58] <dobey> mandel: one of the many reasons i hate python :)
[18:58] <nessita> also, mandel, why would you set ubunutone/credentials.py as #!/usr/bin/env python ?
[18:59] <mandel> nessita: is from the vim template I use
[18:59] <nessita> mandel: that should not be there on 95% of the cases
[18:59] <mandel>  does it hurt?
[19:00] <mandel> need to go, sorry
[19:00] <nessita> mandel: yes, you're declaring a python module to be executable when is a lie
[19:00] <mandel> will talk later
[19:03] <nessita> dobey: is there any way of reverting a merged branch in u1client?
[19:04] <mterry> alecu, ping about CreateItem bug
[19:04] <alecu> hi mterry
[19:04] <dobey> nessita: many ways...
[19:04] <dobey> hi mterry
[19:04] <nessita> dobey: can you please teach me the easiest and cleanest (ideally)?
[19:04] <dobey> mterry: this is keyring bug?
[19:05] <mterry> alecu, I'm trying ubuntu-sso-client trunk in oneiric and I still hit the error about CreateItem's dbus signature
[19:05] <mterry> dobey, yeah
[19:05] <alecu> mterry, right: we have not worked on that issue yet.
[19:05] <dobey> mterry: are you using ppa:ubuntuone/nightlies ?
[19:05] <alecu> mterry, oneiric defaults to gnome keyring 3?
[19:05] <dobey> alecu: well i think CreateItem signature was fixed, but there are still some other issues
[19:05] <mterry> alecu, oh, I thought that was bug 745540, which is marked fix committed
[19:05] <ubot4> Launchpad bug 745540 in ubuntuone-client (Ubuntu) (and 5 other projects) "Method "CreateItem" with signature "a{sv}(oayay)b" on interface "org.freedesktop.Secret.Collection" doesn't exist (affects: 19) (heat: 102)" [Undecided,Invalid] https://launchpad.net/bugs/745540
[19:06] <dobey> alecu: yes, 3.x stuff is in O
[19:06] <mterry> alecu, yes, 3.x
[19:06] <alecu> ok.
[19:06] <mterry> dobey, no, compiled a deb myself, though I should use the nightly ppa
[19:06] <dobey> mterry: please use nightlies :)
[19:06] <mterry> dobey, sure, but do you happen to know if they work?  You say there are other issues?
[19:06] <mterry> I'm still getting the same CreateItem error for example
[19:08] <dobey> mterry: well i know there is a separate issue with names of properties, but the CreateItem error should be fixed; are you sure you used trunk?
[19:08] <dobey> mterry: or did you just build from lp:ubuntu/ubuntu-sso-client?
[19:09] <dobey> nessita: sorry. what revision would you like to revert?
[19:09] <mterry> dobey, I used trunk.  I've now switched to the PPA, same error
[19:09] <dobey> mterry: hrmm, ok; weird
[19:10] <nessita> dobey: this merge https://code.launchpad.net/~mandel/ubuntuone-client/provide_credentials_management/+merge/59743
[19:10] <nessita> dobey: so mandel can re-
[19:10] <nessita> oops
[19:10] <nessita> fix it and re propose it
[19:12] <dobey> nessita: bzr diff -r 984..983 will generate a reverse patch
[19:13] <nessita> ok, on it now
[19:13] <dobey> nessita: then you can appply that, and fix the conflicts, and go from there to get to where you want
[19:13] <nessita> dobey: right, I'll try
[19:13] <nessita> thanks!
[19:13] <dobey> sure
[19:14] <dobey> nessita: so diff -r $REVNOYOUWANTTOREVERT..$PREVIOUSREVNO, is how you generate a reverse diff of the changes; if you want to add it to your notes that way so it's easier to remember :)
[19:15] <nessita> dobey: I will, thanks
[19:16] <dobey> grr, why is firefox in 11.04 having drawing issues
[19:16] <dobey> and keyboard issues apparently :-/
[19:17] <dobey> mterry: ok, am upgrading my laptop right now to be sure, and will test it there
[19:17] <mterry> alecu, dobey: it's because the first CreateItem returns "Invalid properties argument" and then the sso code falls back to old signature
[19:18] <dobey> mterry: ah, so it's becuase the properties are wrong too
[19:18] <dobey> sigh, why did they have to break such things
[19:19] <dobey> oh wow
[19:19] <dobey> and i thought control panel looked bad with the correct theme
[19:19] <alecu> yes, they changed the names of some properties, so our code will have to try both property names if we want to be compatible with both gnome-keyring versions.
[19:20] <dobey> hmm, and couch is broken
[19:24] <dobey> hopefully cp nightlies succeed this time
[19:25] <dobey> sigh
[19:26] <mterry> dobey, alecu: looking at gnome-keyring code (gkd-secret-property.c), I think the new property names are Label and Type
[19:26] <mterry> instead of token-name and key-type
[19:27] <mterry> oh whoops
[19:27] <mterry> I misread what I was seeing over the dbus wire.  We already use Label and Attributes
[19:28] <dobey> no they changed some stuff from Foo to org.blahblah.blah.Foo
[19:29] <nessita> dobey, alecu: can I have some reviews for https://code.launchpad.net/~nataliabidart/ubuntuone-client/revert-provide_credentials_management/+merge/62181 ?
[19:31] <fagan> nice write up mterry :)
[19:31] <mterry> fagan, thanks  :)
[19:34] <alecu> nessita, I'm reviewing
[19:34] <nessita> alecu: thanks
[19:35] <dobey> nessita: +1
[19:35] <nessita> cheers
[19:35] <alecu> nessita, there seems to be something different: "1019 lines (+702/-230) 8 files modified" vs "1062 lines (+230/-745) 8 files modified"
[19:36] <nessita> alecu: some change in trunk in the mean time? maybe mandel landed some changed on one of the removed files
[19:36] <nessita> alecu: I applied the patch, got rejects on the files that were supposed to be removed
[19:36] <dobey> hrmm, 43 line difference
[19:39] <nessita> hum, in theory I'm removing more lines that those that were added? weird
[19:40] <dobey> ah
[19:40] <dobey> yes you are
[19:40] <dobey> it looks like windows/credentials.py got larger in a later change
[19:41] <nessita> right, for example: in the original branch, we have:
[19:41] <nessita> 181+        self.assertIs(callback,
[19:41] <nessita> 182+                    self.management.register_to_authorization_denied(callback))
[19:41] <nessita> and in my removes, that same line is:
[19:41] <nessita> 178-        self.management.register_to_authorization_denied(callback)
[19:42] <nessita> and that happens for several tests
[19:42] <dobey> right
[19:42] <dobey> and the window impl had some larger changes as well
[19:43] <dobey> like the __init__ for CredentialsManagement is different there, and has some other methods added and such
[19:43] <mterry> dobey, is there a workaround I can do to get some credentials on an oneiric machine?  I'd like to do some further testing of U1 stuff in oneiric
[19:43] <dobey> probably as the IPC on windows actually got implemented, stuff changed
[19:45] <nessita> right... anyways, I think that mandel can re add the latest version of the file once we agree on how he will be moving sutff out of linux
[19:47] <dobey> mterry: not sure
[19:47] <dobey> gimme a minute, i gotta make a phone call
[19:49] <nessita> alecu: the difference in the lines is casued by later changed to the windows files
[19:49] <nessita> which by reverting are being removed
[19:50] <alecu> nessita, ok, then I can assume it to be safe, right?
[19:50] <nessita> alecu: I think so, yes. We have all the version control history so mandel will not loose the latest changes, and he can re-propose a cleaner/working branch for us to review
[19:51] <dobey> ok
[19:51] <nessita> alecu: I did nothing extra other than applying the reverted patch and fixing the rejects
[19:51] <dobey> it is safe
[19:51] <alecu> nessita, ok.
[19:52] <nessita> heh, qt tests are saying:
[19:52] <nessita> Application asked to unregister timer 0x53000003 which is not registered in this thread. Fix application.
[19:52] <alecu> nessita, finally: I don't get why are we reverting instead of fixing this.
[19:52] <nessita> no dbus involved at all on that timer warning
[19:52] <nessita> alecu: did you see the attached bug report?
[19:52] <nessita> alecu: ubuntuone-launch is failing for every single user running nightlies
[19:53] <nessita> due to an ImportError. And I'm not fixing the import error itself since the changes that mandel landed break an API that is not meant to be broken
[19:53] <nessita> alecu: so mandel and I need to discuss how he can add the changes he needs without breaking the existing API
[19:54] <nessita> alecu: maybe there is another solution that th rush is not letting me see?
[19:56] <alecu> nessita, I can't see any quick solution, no.
[19:56] <dobey> nessita, thisfred, alecu: couple quick reviews for https://code.launchpad.net/~dobey/ubuntuone-control-panel/fix-dc-lint/+merge/62189 please? :)
[19:57] <thisfred> on it
[19:57] <nessita> dobey: sure
[19:57] <nessita> dobey: looks trivial! +1
[19:57] <thisfred> +1d as well
[19:59] <dobey> aye, and it seems to be the final nail for fixing the cp nightlies :)
[19:59] <nessita> dobey: great work!
[19:59] <nessita> dobey: that in in O, right?
[19:59] <dobey> well, except for maverick, anyway
[19:59] <dobey> O and N
[19:59] <nessita> dobey: maverick issue is some introspection stuff, right?
[20:00] <dobey> some weird error in soup, yes
[20:00] <alecu> nessita, hmmm... regarding your revert branch: this is nightlies, and nightlies by definition some times get broken.
[20:00] <alecu> nessita, I still feel that reverting is taking a step back, because mandel's branch will have to go back thru reviewing and all.
[20:01] <nessita> alecu: right, and we fix them ASAP. Consider we advise most of our users using nightlies
[20:01] <alecu> nessita, so, I wonder if it would make more sense to wait till tomorrow and have him take a look at this and fix it.
[20:01] <alecu> nessita, (I'm guessing he has not seen this yet)
[20:01] <alecu> ok
[20:02] <nessita> alecu: and yes, I'm hoping to be able to review that whole (new) branch since he has added some stuff I disagree with
[20:02] <nessita> and code duplication, and shebangs to non-executable python modules, etc
[20:02] <alecu> ok again.
[20:03] <nessita> alecu: I see your point, but I'm scared by the fact that nightlies are broken for every nightlies users, which among those we have several regular and paying users
[20:04] <nessita> I've already emailed ralsina and mandel about this, but they don't seem to be around (or they would have replied I think)
[20:05] <alecu> nessita, ok. My error comes from my idea that "nightlies" in every other open source project means "will break often", and not "you should use this because stable is too old."
[20:05] <alecu> nessita, so, I'm approving.
[20:06] <nessita> alecu: yeah, I hope we can do something about nightlies and delivering improvements to older clients. And thanks.
[20:06] <dobey> alecu: eh, if it's the wrong thing to do we can always revert the reversion :)
[20:06] <nessita> and that also
[20:06] <nessita> alecu: the thing that motivates me to revert is that the code is not lost
[20:07] <dobey> ok now sso client
[20:11] <dobey> ugh
[20:12] <dobey> there is no good way to do this, i think :(
[20:15] <dobey> ugh and the dbus api isn't introspecting :(
[20:15] <dobey> so d-feet is totally useless
[20:21] <nessita> alecu: ok, so I have ready the branch that we talked about this morning (grouping ui implementations into a gui module and moving all the constants there for easy access). Is big, but it works, and is ready for review. Will you let me know when you have a slot to look at it?
[20:21] <alecu> nessita, I'm having lunch (!) so post the url, and I'll review when I finish.
[20:23] <nessita> alecu: long merge description is in place, please read before panicking :-P https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/bind-some-more/+merge/62191
[20:24] <dobey> man i hate git
[20:25] <dobey> cgit certainly doesn't help
[20:26] <thisfred> Ohai, I heard you like distributed versioning control, so I made every action you want to do into two separate commands!
[20:28]  * nessita brbs
[20:30] <alecu> nessita, I don't understand the lines 213 and 214 in the proposal: https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/bind-some-more/+merge/62191
[20:30] <dobey> what i really like is distributed distribution
[20:40] <nessita> alecu: ah, that is a "bug fix", in the sense that when setting a status_changed callback, it is expected that the getter return what you've set and not another function
[20:41] <dobey> i wonder if using the long property names will 'just work' with the old keyring
[20:41] <dobey> not sure how to test
[20:41] <nessita> alecu: without that fix, if you set function f to be the status_changed callback, when you query it you get another function (process_and_callback). process_and_callback only makes sense from the backend to below (ie syncdaemon)
[20:43] <alecu> nessita, ack
[20:44] <nessita> alecu: I noticed that when writing the test, not sure how I didn't notice it before :-/
[20:45] <alecu> nessita, probably it was not used before.
[20:47] <dobey> what a mess
[20:49] <alecu> nessita, why is this line repeated from 2301+? "from ubuntuone.platform.linux.tools import SyncDaemonTool"
[20:50] <nessita> alecu: is inside the calls, so when we import that module ubuntuone.platform.linux.tools does not get imported at module import time
[20:50] <nessita> alecu: otherwise the default twisted is installed before we install our own
[20:50] <alecu> nessita, oh, ok.
[20:50] <nessita> feo, sí :-(
[20:51] <nessita> alecu: any ideas how to make that less pucking?
[20:51] <alecu> nessita, a factory function that's used from every test?
[20:52] <alecu> nessita, that function then imports sdtool, and returns an instance
[20:52] <nessita> alecu: the issue is not the tests, but the live code. But yes, a factory makes sense
[20:52] <dobey> fix whatever is importing/installing the reactor, so that it doesn't do it when you import that module
[20:52] <nessita> alecu: fixing that now
[20:52] <alecu> oh, right, it's the actual code.
[20:52] <nessita> yeah
[20:53] <nessita> but yes, a factory makes sense
[20:53] <alecu> nessita, besides that, it looks great.
[20:53] <dobey> yay, finally; brb
[20:53] <alecu> nessita, +!
[20:53] <alecu> nessita, +1
[20:54] <nessita> yey! fixing that last bits before convincing thisfred he will love that branch (?)
[20:55] <thisfred> I'm easy to convince. try: convince() except NotConvinced: feed(beer)
[20:55] <nessita> lol
[20:55] <thisfred> nessita: do I need to review that branch?
[20:56] <alecu> nessita, oh... the tests are failing
[20:56] <nessita> alecu: they are? I run them several times, but maybe
[20:56] <alecu> nessita, there's a missing __init__.py in u1/cp/gui
[20:56] <nessita> alecu: ah! my bad, I have it, and you don't :-P
[20:57] <nessita> alecu: you also don't have the ubuntuone/controlpanel/gui/qt/tests/test_controlpanel.py!!!
[20:57] <alecu> nessita, now I have an empty one, don't need yours!
[20:57] <nessita> which is where all the magic happens
[20:58] <alecu> yes... I need that too!
[20:59] <alecu> nessita, please let me know when I can pull
[20:59] <nessita> yes
[21:00]  * alecu will EOD after reviewing, because he's feeling like crap. Like a gin drinking, gitanes smoking, blues singing, piece of alecu
[21:00]  * thisfred will buy that cd
[21:00] <alecu> hahaha
[21:01] <nessita> alecu: pushing.
[21:01] <nessita> .
[21:01] <nessita> .
[21:01] <nessita> .Pushed up to revision 160.
[21:01] <nessita> thisfred: feel like doing an epic review?
[21:01] <thisfred> nessita: always!
[21:02] <nessita> thisfred: sos groso! https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/bind-some-more/+merge/62191 (please read merge description!)
[21:02] <thisfred> on it!
[21:02] <dobey> wow. glad that dude got here when he did. it just got *dark* outside, and thunder's rolling
[21:03] <alecu> dobey, what dude?
[21:03] <dobey> alecu: getting an estimate to do some work on part of my yard
[21:04] <alecu> dobey, building another workshop for your cars?
[21:05] <alecu> nessita, ************* Module ubuntuone.controlpanel.gui.qt.gui
[21:05] <alecu> E1101: 71:main: Module 'twisted.internet.reactor' has no 'stop' member
[21:05] <dobey> alecu: not yet. just trying to have a yard that's not all 3ft tall weesd
[21:05] <nessita> alecu: bu, I'm not getting that. How come?
[21:06] <alecu> nessita, don't know. Just did ./run-tests
[21:06] <nessita> alecu: fixing it...
[21:06] <nessita> alecu: maybe I need to merge trunk in? let's see
[21:06] <alecu> nessita, also, there are a lot of DEBUG messages flying by when running -qt
[21:06] <alecu> DEBUG:ubuntuone.controlpanel.webclient:getting url: GET, http://localhost:39780/unauthorized
[21:06] <alecu> DEBUG:ubuntuone.controlpanel.webclient:got http response 401 for uri 'http://localhost:39780/unauthorized'
[21:07] <dobey> woah
[21:07] <alecu> yes, it's only happening for -qt
[21:07] <nessita> alecu: that is... weird
[21:07] <dobey> that lightning was *CLOSE*
[21:07] <nessita> alecu: is your system up to date?
[21:07] <alecu> nessita, let me check
[21:08] <nessita> I think mine is, though I could use a reboot
[21:08] <nessita> and some tea, actually
[21:08] <dobey> and here's the rain
[21:08] <nessita> dobey: say Hi to her
[21:09] <nessita> tell her we're missing her in Córdoba, a lot
[21:09] <thisfred> alecu: nessita fwiw run-tests and run-tests -qt pass here, BUT I still get a million debug prints
[21:09] <nessita> thisfred: is your system up to date?
[21:09] <thisfred> nessita: it was this morning
[21:09] <nessita> and also, what the heck is "http://localhost:39780/unauthorized"?
[21:10] <nessita> sounds desktopcouch-ish
[21:10] <mandel> nessita: ping
[21:10] <thisfred> nessita: I don't think we have an /unauthorized url though...
[21:10] <nessita> alecu: do you have
[21:10] <nessita>       39 [couch_httpd_oauth]
[21:10] <nessita>      40 use_user_db = false
[21:10] <nessita> in /etc/couchdb./default.ini?
[21:11] <nessita> mandel: you are back! :-) I thought you were gone for the day...
[21:11] <nessita> thisfred: what messages do you have?
[21:11] <thisfred> he should be...
[21:11] <mandel> nessita: never, I just wanted to apolgize for the crazy approvals we had during the windows sprint
[21:11] <mandel> nessita: as I said in the mail, like spaniards say 'visteme despacio que tengo prisa'
[21:11] <nessita> mandel: honestly I'm a bit scared :P-)
[21:12] <nessita> mandel: but good news! we can fix it
[21:12] <alecu> mandel, that was napoleon!
[21:12] <thisfred> nessita: dist-upgraded. but I don't see a change. pastebinning
[21:12] <alecu> nessita, I have that set to true.
[21:12] <mandel> nessita: yes, we can, there was way to much done and not corretly reviews
[21:12] <mandel> alecu: oh, so it was the guy who conquered us… bastards ;)
[21:12] <nessita> alecu: well, you need that in false to have a working couch when using ubuntuone-hackers (private) PPA. Not sue of it's related though
[21:13] <thisfred> nessita:  http://paste.ubuntu.com/612439/
[21:13] <nessita> mandel: you can rest today, we already reverted the changes, in the hope that tomorrow we can talk about it and come to a clean solution
[21:13] <nessita> mandel: is very late for you!
[21:13] <mandel> nessita: it might b late ;)
[21:14] <nessita> thisfred: is that from running ./run-tests?
[21:14] <mandel> nessita: nevertheless I feel resposable, I did not know that the code was a public API, and honestly I really did not consuder the #! comment to be an issue
[21:14] <thisfred> nessita: yep
[21:14] <mandel> nessita: first news  I had about it
[21:14] <thisfred> nessita: this has been happening for a long time though
[21:14] <thisfred> nessita: not related to your branch, but I don't know how to stop iy
[21:14] <nessita> mandel: is not a big issue, but that makes me worry about the quality of the reviews
[21:15] <nessita> thisfred: weird! very
[21:15] <thisfred> sí
[21:15] <nessita> mandel: shall we talk tomorrow about how to add what we need for windows re: credentials? I'm sure we'll come up with a clean solution re-using your former branch
[21:15] <thisfred> basically the logging goes to stdout always for me
[21:16] <nessita> thisfred: yeah, it happens somethimes for syncdaemon as well
[21:16] <nessita> never find out why
[21:16] <mandel> nessita: ok
[21:16] <nessita> mandel: rest some, I'll start working before 9am ART
[21:17] <mandel> nessita: ok, will do thx, and sorry
[21:17] <nessita> mandel: :-)
[21:18] <karni> CardinalFang: you had ping timeout on canonicals irc.
[21:18] <nessita> mandel: you said you replied to my email or I misunderstood?
[21:18] <mandel> nessita: I did reply
[21:20] <nessita> mandel: to all?
[21:20] <mandel> nessita: as in all emails or to everyone?
[21:21] <nessita> mandel: all the recipients in the email. I mean, I did not get any email, but that may be fine
[21:22] <nessita> mandel: nevermind, I was looking the wrong folder :-/
[21:22] <nessita> mandel: I did got the reply
[21:23] <thisfred> nessita: you probably explained this to alejandro, but why the import *? Can't you just do import gui, and then namespace the constants?
[21:23] <mandel> nessita: hehehe
[21:23] <thisfred> so gui.CONSTANT etch
[21:23] <thisfred> etc.
[21:24] <thisfred> star imports considered harmful
[21:24] <nessita> thisfred: I could, but from my POV (I'm open to suggestions) the fact of using gui.CONSTANT makes the code less readable. Imagine the tests, they will read gui.gui.CONSTANT. So, I know namespaces are one honking idea, but for this particular use case I find import * more clean and simple (again, is my POV)
[21:25] <nessita> thisfred: how I see it, adding gui. does not add any value to the constant name
[21:25] <thisfred> nessita: well, my viewpoint is no better than yours, so I will approve, but I would go to almost any length to avoid * imports
[21:25] <nessita> thisfred: I agree with you 99%
[21:26] <thisfred> nessita: no but you pollute the namespace, which can confuse tools and developers
[21:26] <thisfred> especially if the developers *are* tools :D
[21:26] <nessita> thisfred: is not more polluted than before, the constants existed before in the module, they were moved for easy reuse from QT
[21:27] <thisfred> nessita: I would personally import them one by one, before doing the * import, even ;)
[21:27] <thisfred> but again, matter of taste
[21:28] <nessita> thisfred: that is cleaner, granted. But they are so many... if you insist I'll do it
[21:28] <thisfred> I don't
[21:28] <thisfred> +1d
[21:28] <nessita> thanks!!!
[21:28] <thisfred> practicality beats purity
[21:28] <thisfred> and purity beats scissors
[21:30] <nessita> lol
[21:31] <dobey> sigh
[21:31] <dobey> this will not do
[21:31] <dobey> i guess i have to buy a bigger UPS :(
[21:32] <dobey> oh
[21:32] <dobey> where did this go?
[21:32] <dobey> cp: cannot stat `debian/tmp/debian/tmp/usr/share/applications/ubuntuone-control-panel-gtk.desktop': No such file or directory
[21:33] <dobey> someone broke the setup.py
[21:35] <nessita> dobey: I need to propose a branch for packaging-dailies, for u1cp
[21:35] <nessita> not sure that is related though
[21:37] <dobey> nessita: for what?
[21:38] <nessita> a merge proposal worths thousand words
[21:38] <nessita> :-D
[21:39] <dobey> not always
[21:40] <dobey> ah i see what's wrong
[21:40] <dobey> alecu broke it :)
[21:40] <nessita> dobey: what is it?
[21:43] <dobey> the new build command to generate the qt junk isn't chaining up to the parent build command's run()
[21:44] <dobey> nessita: doh, and you broke po/POTFILES.in :(
[21:44] <nessita> dobey: yes, fixing that now
[21:44] <nessita> dobey: I change it without actually doing the bzr move
[21:44] <nessita> changed*
[21:45] <dobey> right
[21:45] <dobey> nessita: can you also stick http://pastebin.ubuntu.com/612448/ in your branch?
[21:46] <nessita> bien sur!
[21:46] <dobey> nessita: i take it the packaging change is to update the -gtk.install for the ui files being moved to a subdir?
[21:47] <nessita> dobey: yes sir
[21:47] <nessita> I will update it, that is
[21:48] <dobey> oh and installing the .qt files
[21:48] <dobey> doh; i had updated it earlier when i was trying to fix the nightlies, and then i saw they weren't being installed yet
[21:48] <dobey> which is probably good since qtreactor isn't packaged
[21:58] <nessita> dobey: https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/move-data-gtk/+merge/62209
[21:58] <nessita> anyone else can review ^?
[21:59] <dobey> ewww
[21:59] <nessita> ?
[21:59] <thisfred> I can
[21:59] <dobey> nessita: how exactly did you modify the .ui files for the difference in image patH?
[22:00] <nessita> dobey: by hand
[22:00] <dobey> because ../ is nasty and evil
[22:01] <nessita> dobey: what would you suggest?
[22:01] <nessita> dobey: simlinking those png into gtk?
[22:01] <nessita> that can be an option
[22:01] <dobey> no
[22:01] <dobey> not sure what you mean by that, but no
[22:02] <nessita> dobey: I mean having the real png under data, and symlinks inside data/gtk to avoid the ../ in the XMLs
[22:02] <dobey> there should be some way to set the image directory on the builder i would think; or we could add a custom theme path and load the icons by name instead
[22:03] <nessita> dobey: all that effort for and UI that will die soon?
[22:03]  * nessita googles
[22:03] <dobey> why should it die?
[22:05] <nessita> dobey: I don't want to have that discussion right now, but basics are we will not maintain 2 UIs
[22:06] <cwayne> ello
[22:06] <nessita> dobey: can I promise you a later branch loading all the imaged programatically?
[22:07] <dobey> no, i have given up on promised branches
[22:07] <dobey> hi cwayne
[22:07] <nessita> dobey: I never lied, except for me not testing your nautilus branch yet
[22:09] <nessita> dobey: I'm leaving soon, what would you like me to do re that branch?
[22:09] <dobey> well, i also don't want to have such discussion right now; and it's time for me to get away from the computer and go do other things
[22:10] <dobey> well i guess i'll just abstain for now. and i think there is a rush to get it in right now
[22:10] <nessita> dobey: I do too
[22:10] <nessita> dobey: but I kinda need your +1
[22:10] <dobey> err, i don't think there is a rush to get it in right now
[22:10] <dobey> see i am tired
[22:10] <nessita> dobey: ok, let's continue tomorrow then
[22:10] <dobey> ok
[22:11] <dobey> have a good evening
[22:11] <nessita> you too
[22:11] <nessita> bye all!
[22:11]  * nessita eods
[22:15] <cwayne> hiya dobey
[22:15] <cwayne> you wouldn't happen to be an expert on the REST api would ya :)
[23:30] <cwayne> anyone here that can help me with the api?
[23:57] <fagan> cwayne: could you come back tomorrow
[23:58] <cwayne> fagan: sure
[23:58] <fagan> around 9-5UTC since thats when most of the devs are around (im an intern so wouldnt be much help)