[08:11] <mandel> good morning!
[08:34] <duanedesign> morning mr mandel
[08:36] <mandel> duanedesign: mornng
[08:36] <mandel> morning!
[08:43] <rye> mornings
[08:45] <duanedesign> o/
[09:28] <fagan> morning
[10:47] <ralsina> mandel: approved provide_credentials_management
[10:47] <ralsina> morning fagan
[10:47] <mandel> ralsina: superb :)
[10:47] <mandel> I'll ask nessita to take a second look.. as soonas I'm done upgrade I'll fix the lint issue with the reactor
[10:47] <ralsina> mandel: cool
[10:47] <fagan> morning ralsina
[10:47] <mandel> ralsina: although on linux we do not need the reactor
[10:48] <ralsina> mandel: there's also a missing docstring
[10:48] <fagan> voidspace was looking for you yesterday to suggest a person for the team
[10:48] <mandel> ralsina: I dont know why we should even use it.. we do not need twisted at all on linux, it is a Windows detail...
[10:48] <fagan> ralsina: he said he would send a mail
[10:48] <ralsina> fagan: yes, will talk to him today
[10:49] <fagan> ralsina: nice im blocked by the keyring bug thats fixed in trunk
[10:49] <fagan> ralsina: thats the bug that was stopping me from logging in
[10:50] <ralsina> fagan: hmmmm ok? ;-)
[10:50] <fagan> ralsina: hah well im just going to install trunk and get back to it
[10:51] <ralsina> fagan: ok. BTW, sent feedback to your college today. I really want to make you do more developer-ish stuff, but I am swamped. Will try harder on sprint
[10:52] <fagan> ralsina: its cool, did you cc me on the email or would you prefer to keep it between you and them
[10:52] <ralsina> fagan: I am not sure what the etiquette here is, but it was nothing substantial ("our codebase is difficult, he has been doing this and that")
[10:53] <fagan> ralsina: ah ok then
[10:53] <fagan> ralsina: thats fine then :)
[10:53] <fagan> Well on the bright side I think I know how all the puzzle pieces fit now
[10:54] <fagan> since the twisted stuff
[10:58] <fagan> oh no the u1 client isnt detecting my internet connection since the update on the network manager in 11.10 last night
[11:02] <fagan> brb
[11:06] <fagan> back and nope restarting doesnt help looks like someone will have to debug it with me
[11:08] <mandel> ralsina: which version of ubuntuone-dev-tools do you have?
[11:11] <fagan> mandel: im on 0.1.3+r32-10~natty1 which is the nightly if that helps
[11:12] <ralsina> mandel: give me 1'...
[11:12] <ralsina> mandel: 0.1.3+r32-10~natty1
[11:12] <fagan> same as me then
[11:12] <mandel> ralsina: can you do a u1trial -h for me and tell me if you have a reactor option
[11:13] <ralsina>   --reactor=REACTOR     Run the tests using the specified reactor.
[11:14] <mandel> ralsina: ok, thx
[11:15]  * fagan break 
[11:34] <mandel> ralsina: do you know which branch from alecu was giving hi issues with the QNetwork thing
[11:34] <ralsina> mandel: I would have to look. In 2'?
[11:36] <mandel> ralsina: sure, I just wanna see if merging with my branch fixes it
[11:36] <ralsina> mandel: I don t think alecu ever told me the name
[11:36] <mandel> :(
[11:38] <ralsina> let's check his branches!
[11:39] <ralsina> mandel: I would bet https://code.launchpad.net/~alecu/ubuntuone-control-panel/tx-web-client
[11:50] <mandel> ralsina: do you remember what was the issue? it was something related to threads, right?
[11:50] <ralsina> mandel: unresponsive UI, IIRC
[11:51] <mandel> ok
[11:53] <mandel> ralsina: I'll wait for alecu to be back, atm it seems to work but I might be missing something
[11:53] <ralsina> mandel: good
[11:53] <ralsina> mandel: so, is anything missing to hook backend to frontend now?
[11:55] <ralsina> assuming all these branches land, I mean
[11:55] <mandel> ralsina: I have to get the creds approve, and write the sd tool, right?
[11:56] <ralsina> mandel: yes
[11:58] <ralsina> we still have a couple of hours before the .ar people arrive. So maybe I can help you with something
[11:58] <mandel> ralsina: I'm going to take a look at sd tool first, lets see how far I get, then look at alecus problem and hope is fixed
[11:59] <ralsina> ok
[11:59] <mandel> today seems to be a happy day so far :)
[12:00] <ralsina> mandel: let's keep it that way then :-)
[12:00] <mandel> hehehe
[12:04] <ralsina> mandel: I am going to take a look at making py2exe work with the control panel. Any suggestions?
[12:05] <mandel> ralsina: do a normal setup.py and we can work from there… there are going to be issues with the plugins, that means that the icons should be png and not jpg
[12:05] <mandel> ralsina: but that should not be a problem
[12:05] <ralsina> mandel: ok, no problem there
[12:06] <ralsina> mandel: you were using distutils-extra?
[12:06] <mandel> ralsina: yes, that works ok
[12:07] <ralsina> mandel: but I need to do it on windows, does it exist there?
[12:07] <mandel> ralsina: yes, and I patched it to make sure that ctypes works :)
[12:07] <ralsina> mandel: ok
[12:08] <ralsina> mandel: use_correct_reactor tries to use dbus on windows?
[12:08] <ralsina> or should I just go with trunk?
[12:08] <mandel> ralsina: atm it does I need to change that in a diff branch, but first we need sdtool ready
[12:09] <ralsina> mandel: ok, so no exe packaging until after that branch. I will start it on linux
[12:17]  * mandel walks dog
[12:27] <Mahoru`Tsunemi> hello
[12:27] <Mahoru`Tsunemi> i need some help
[12:28] <Mahoru`Tsunemi> i'm new to u1 and i start the sync
[12:28] <Mahoru`Tsunemi> on a distant computer the sync is now over, and i need to connect the sync with the PC i have here
[12:28] <Mahoru`Tsunemi> but i cant because le folder is already "full" of data
[12:29] <Mahoru`Tsunemi> (there is disk space, i just don't have other word :) )
[12:29] <duanedesign> hello Mahoru`Tsunemi
[12:29] <Mahoru`Tsunemi> hello duanedesign :)
[12:31] <nessita> Hello everyone!
[12:31] <duanedesign> Mahoru`Tsunemi: is this data that you put in your Ubuntu One folder on the 'distant' computer? Or is this data you uploaded via one.ubuntu.com?
[12:49] <Mahoru`Tsunemi> duanedesign: sorry for the wait
[12:49] <Mahoru`Tsunemi> so
[12:49] <Mahoru`Tsunemi> it's in a folder that was marked as sync
[12:49] <Mahoru`Tsunemi> and the sync is finished
[12:56] <duanedesign> Mahoru`Tsunemi: ok so the files are showing up in the cloud (one.ubuntu.com) but not on your other computer?
[12:56] <Mahoru`Tsunemi> not that's not the problem
[12:56] <Mahoru`Tsunemi> i have the data on the distant computer and on this one
[12:57] <duanedesign> ok
[12:57] <Mahoru`Tsunemi> and i want to have this computer synced
[12:57] <Mahoru`Tsunemi> but i can't check the "sync this folder"
[12:57] <Mahoru`Tsunemi> (it's greyed)
[12:57] <Mahoru`Tsunemi> (because there is data in this dir :) )
[13:00] <fagan> me
[13:01] <duanedesign> Mahoru`Tsunemi: is this a  folder in your Home directory?
[13:01] <Mahoru`Tsunemi> yup
[13:01] <Mahoru`Tsunemi> ~/Documents
[13:01] <Mahoru`Tsunemi> :)
[13:02] <duanedesign> Mahoru`Tsunemi: can you run this command in a Terminal to see if the folder is listed:  u1sdtool --list-folders
[13:02] <Mahoru`Tsunemi> Folder list:
[13:02] <Mahoru`Tsunemi>   id=8ede6cbe-78c7-4a9d-bf09-de479162f254 subscribed=False path=/home/mahoru/Documents
[13:03] <duanedesign> ok that is the folder... but subscribed is False and we want true.
[13:03] <Mahoru`Tsunemi> yup
[13:04] <Mahoru`Tsunemi> --subscribe-folder ?
[13:04] <duanedesign> Mahoru`Tsunemi: yes that might provide a workaround
[13:04] <nessita> fagan: still one hour to go
[13:04] <fagan> ralsina: im going to be off for standup (I thought it was at 1 whoops) I have a eye test appointment  and some errands to do
[13:05] <ralsina> fagan: ok
[13:05] <fagan> nessita: yeah realised that forgot
[13:05] <fagan> :D
[13:05] <nessita> :-)
[13:05] <duanedesign> Mahoru`Tsunemi: u1sdtool --subscribed-folder=8ede6cbe-78c7-4a9d-bf09-de479162f254
[13:05] <Mahoru`Tsunemi> that's i done :)
[13:05] <duanedesign> err --subscribe-folder
[13:05] <duanedesign> :)
[13:05] <Mahoru`Tsunemi> erk
[13:06] <Mahoru`Tsunemi> lot lot lot of upload to do :/
[13:10] <Mahoru`Tsunemi> hum
[13:10] <Mahoru`Tsunemi> upload are fast
[13:10] <Mahoru`Tsunemi> maybe there is only a hash check :)
[13:12] <ralsina> Mahoru`Tsunemi: if someone else has uploaded the same file, it's not "really" uploaded again
[13:14] <Mahoru`Tsunemi> :)
[13:15] <Mahoru`Tsunemi> and, u1 has problem with accentued file name ?
[13:16] <Mahoru`Tsunemi> (LCA - Linux sécuriser un réseau.pdf)
[13:18] <ralsina> Mahoru`Tsunemi: shouldn't!
[13:18] <Mahoru`Tsunemi> because i think i have uploaded this file a couple times :)
[13:28] <nessita> ralsina: 2 more question re QT
[13:28] <ralsina> nessita: shoot
[13:29] <nessita> ralsina: waitM RING BELL
[13:29] <nessita> oops
[13:29] <ralsina> :-)
[13:42] <nessita> I'm back!
[13:42] <nessita> ralsina: so, I was saying. Do you know of a pre-defined method to "humanize" bytes?
[13:42] <nessita> ie 1024 bytes to be 1Mb
[13:42] <ralsina> nessita: let me check
[13:42] <nessita> etc
[13:43] <nessita> ralsina: Glib has now that even handles internationalization :-) (That's why I ask instead of home-implementing it)
[13:43] <ralsina> apparently not
[13:44] <ralsina> there are some tiny implementations but of course may be too naive
[13:46] <nessita> ralsina: second question. In a treewidget, how can I make a column to be wider by default? even better, to be as wide as possible in order to try to make the text in it to be all visible
[13:47] <ralsina> you can set one column to use all available width, let me find the API
[13:48] <ralsina> nessita: first, get the widget's header, using header()
[13:48] <ralsina> then set stretchlastsection to false
[13:49]  * nessita does
[13:49] <ralsina> then (let me find it ;-)
[13:50] <ralsina> then, for the column you want to be biggest, set it's resizeMode to QtGui.QHeaderView.Stretch
[13:50] <ralsina> that is using header().setResizeMode()
[13:50] <ralsina> the header is a QHeaderView, documented here: http://doc.qt.nokia.com/latest/qheaderview.html#setResizeMode
[13:51] <nessita> ralsina: perfect, I'll go from here. Thanks a lot!
[13:51] <ralsina> happy to help!
[13:56] <dobey> hmm
[13:57] <nessita> dobey: good morning to you too :-)
[13:57] <ralsina> dobey: hmm to you too!
[13:57] <dobey> buenas dias
[13:57] <nessita> buenos días!
[13:58] <nessita> (the days are masculine)
[13:58] <nessita> :-)
[13:58] <ralsina> however, mornings, evenings and nights are femenine. Wonder how that works.
[13:59] <alecu> hello!
[13:59] <nessita> hello alecu!
[14:00] <mandel> alecu: ping
[14:00] <alecu> mandel, pong
[14:00] <alecu> me
[14:00] <mandel> me
[14:00] <mandel> alecu: which was the branch you were having issues with the reactor?
[14:00] <dobey> me
[14:01] <mandel> alecu: I'd like to test my branch with your issues and see what happens
[14:01] <nessita> me
[14:01] <dobey> mandel: any that use qt reactor and dbus
[14:01] <nessita> ralsina, thisfred?
[14:01] <ralsina> me
[14:01] <thisfred> me
[14:01] <alecu> mandel, let me find it
[14:01] <ralsina> I have fagan's to
[14:01] <ralsina> too^
[14:02] <alecu> DONE: a few reviews, did some debugging to understand qtreactor+dbus issue, started working on "devices" tab, did pre-sprint laundry
[14:02] <alecu> TODO: finish "devices" branch
[14:02] <alecu> BLOCKED: no
[14:02] <alecu> NEXT: mandel
[14:02] <mandel> DONE: Reactor on Windows and Linux for control panel. Started with sd on windows.
[14:02] <mandel> TODO: finish sd on windows.
[14:03] <mandel> test reactor with alecus branch
[14:03] <mandel> BLOCKED: no
[14:03] <mandel> nessita: please
[14:03] <nessita> I think dobey is next
[14:03] <nessita> dobey: go!
[14:03] <mandel> dobey: no, I wanna try one that uses a threaded select reactor and dbus
[14:03] <dobey> λ DONE: holiday
[14:03] <dobey> λ TODO: bug #789299, bug #789300, bug #771488, more magic
[14:03] <dobey> λ BLCK: None.
[14:03] <ubot4`> Launchpad bug 789299 in ubuntuone-dev-tools "DBusTestCase sometimes connects to real session bus (affects: 1) (heat: 6)" [Critical,In progress] https://launchpad.net/bugs/789299
[14:03] <ubot4`> Launchpad bug 789300 in ubuntuone-dev-tools "DBusTestCase needs to work with Qt main loop as well (affects: 1) (heat: 6)" [Critical,In progress] https://launchpad.net/bugs/789300
[14:03] <ubot4`> Launchpad bug 771488 in ubuntuone-dev-tools "u1trial should unset GTK_MODULES (affects: 1) (heat: 4)" [Medium,In progress] https://launchpad.net/bugs/771488
[14:04] <dobey> nessita: you
[14:04] <nessita> DONE: swap day. Last Fri: tons of QT work on modelling the Cloud Folders tab. Mumble meeting with ralsina, mandel and alecu to re-estimate windows control panel remaining work.
[14:04] <nessita> TODO: finish Cloud folders tab, add tests to that, catch up with the rest of the team.
[14:04] <nessita> BLOCKED: nopes
[14:04] <nessita> NEXT: ralsina
[14:04] <ralsina> DONE: reviews, meetings, helped bits with Qt, lost internet half a day yesterday, so working longer today. TODO: try to figure out how we are going to make everything work, BLOCKED: no, I think .
[14:04] <ralsina> now fagan's: DONE
[14:04] <ralsina> * Tried to figure out why I couldnt login to u1 on 11.10 and figured out it was the keyring bug that dobey fixed in trunk.
[14:04] <ralsina> * installed trunk
[14:04] <ralsina> * found I think a bug where the client doesnt detect that I have an internet connection (I guess it might be the nm update that happened or something but I dont know)
[14:04] <ralsina> TODO
[14:04] <ralsina> * debug the bug or find out whats causing the issue (?)
[14:04] <ralsina> * payroll
[14:04] <ralsina> Blocked
[14:04] <ralsina> * nope
[14:04] <dobey> it's not fixed in trunk
[14:05] <ralsina> thisfred?
[14:05] <thisfred> DONE: memorial day TODO: file bugs for u1-unity integration improvements and fix them, some assorted other bugs to look at/triage/fix BLOCKED: no
[14:05] <ralsina> BTW: network manager in O broke our "are we connected" detection.
[14:05] <mandel> dobey: my irrc client crashed, did you get my last message?
[14:05] <dobey> yes i know NM broke us too
[14:06] <dobey> mandel: about select reactor + dbus?
[14:06] <nessita> ralsina: ack, we can fix after windows, right?
[14:06] <ralsina> nessita: indeed
[14:06] <alecu> ralsina, we should let fagan know that the keyring access is also broken, so he'll have no luck either on O.
[14:06] <mandel> dobey: yes, about trying to use a threaded select reactor instead with integration in the Qt main loop
[14:06] <alecu> or perhaps not ;-)
[14:06] <ralsina> alecu: yeah
[14:06] <nessita> also, NOTE: I'm going today to university instead of tomorrow (I'm leaving in 15 minutes, so speak now! :-))
[14:06] <dobey> mandel: well, there are a couple bugs in devtools
[14:06] <mandel> dobey: hmmm what kind of bug?
[14:07] <dobey> mandel: i expect in that case you'll still have similar issues :)
[14:07] <mandel> dobey: heheh common share them ;)
[14:07] <alecu> nessita, if resizing icons and getting html labels right is too much trouble on the tree widget, I suggest doing something similar to the "devices" tab.
[14:07] <dobey> mandel: 789299 and 789300
[14:07] <nessita> alecu: what did you do there?
[14:08] <alecu> nessita, I'm still working on it, but it's a "device" widget that gets included many times inside a scroll-widget.
[14:08] <alecu> nessita, (a scroll-something-whatever-its-name-widget)
[14:08] <Chipaca> FWIW, I'm in 11.10 and the only issue i have is with NM
[14:08] <Chipaca> and that's workaroundable with dbus-send
[14:09] <Chipaca> as in http://askubuntu.com/questions/45814/network-manager-0-8-999-and-ubuntu-one
[14:09] <alecu> nessita, that way you'll have the icon size you want plus the html labels plus disabling the way you want.
[14:09] <nessita> alecu: I already implemented all that using stuff from the qtreewidget, but I'll take a look to what you're doing :-)
[14:09] <mandel> dobey: ok, looking
[14:10] <mandel> nessita: can you re-review the branch wth the creds management tool?
[14:10] <ralsina> yes, for up to a few dozen rows, that solution is workable
[14:10] <dobey> Chipaca: lies :)
[14:11] <nessita> mandel: yes! but as soon as I get back from Uni, I'm leaving in 10. Or do you need it sooner?
[14:11] <Chipaca> dobey: i swear!
[14:11] <alecu> ralsina, is there any hard limit to it?
[14:11] <ralsina> alecu: no, just that when you start having hundreds of widgets, things get slow
[14:11] <alecu> ralsina, like X's 32768 pixel height limit on widgets?
[14:12] <alecu> ralsina, ok.
[14:12] <ralsina> alecu: I don't think scrollviews are limited like that for the content, so just apply common sense ;-)
[14:13] <alecu> ralsina: apply(commonsense, widgetlist) ?
[14:13] <ralsina> alecu: ha!
[14:13] <mandel> nessita: I can wait, I'll move to something else
[14:13] <dobey> huh
[14:14] <alecu> ralsina, mandel, all: can I have some reviews on this branch? https://code.launchpad.net/~alecu/ubuntuone-control-panel/tx-web-client/+merge/62889
[14:15] <mandel> alecu: is that the one that gave you problems with the reactor?
[14:16] <ralsina> alecu: on it
[14:16] <alecu> mandel, the problems with the reactor I had were related to the bug 789300 that dobey is working on.
[14:16] <ubot4`> Launchpad bug 789300 in ubuntuone-dev-tools "DBusTestCase needs to work with Qt main loop as well (affects: 1) (heat: 6)" [Critical,In progress] https://launchpad.net/bugs/789300
[14:17] <alecu> mandel, what I found is that the QApplication has to be created before the qt reactor is installed
[14:18] <alecu> mandel, that way the threading warnings do not show up
[14:18] <nessita> ok, I'm leaving for teaching duties. See ya'll in about 3~ hours!
[14:18] <alecu> (and everything ends up fine, with no segfaults)
[14:22] <dobey> alecu: --gui does that
[14:23] <mandel> alecu: yes, that is in the documentation of qt
[14:24] <mandel> you always have to create the QApplication first otherwise the reactor will create a new QCoreQpplication that does not take care of the UI events
[14:24] <mandel> is in the few first ines of the README of the qtreactor
[14:24] <mandel> alecu: was that the only reason?
[14:24] <mandel> I mean the only problem you had?
[14:25] <ralsina> alecu: seems to work for me
[14:25] <dobey> what my problem is, is that i can't seem to get the tests to disconnect from the dbus-daemon fast enough :(
[14:25] <dobey> and i am not sure how to fix that
[14:26] <alecu> dobey, that's weird. That never happened on the glib dbus tests
[14:26] <alecu> dobey, are you returning a deferred from the tearDown function?
[14:27] <dobey> alecu: yes it is. it's just not so much visible with glib, since the DBusTestCase client connection is using the glib main loop
[14:29] <alecu> dobey, but the dbus "disconnect" calls are blocking... so it should not be a problem.
[14:29] <alecu> dobey, is this happening because the tests are not connecting to the test daemon, and connecting to the session daemon instead?
[14:30] <alecu> dobey, perhaps the "not disconnected" is not your process but another process on the real session bus.
[14:31] <mandel> dobey: but the qtreactor is using the Qt main loop, right? so if you use the Qt dbus implementation it should work, or am I missing something?
[14:31] <dobey> alecu: no, it doesn't matter which one they connect to
[14:31] <mandel> alecu: we actualy do not need to use the reactor on linux, right?
[14:32] <dobey> alecu: and it's definitely the tests not disconnecting fully, because the amount of connections goes up with each following test
[14:32] <mandel> alecu: since the IPC is dbus, we can tell the code to just use the twisted reactor on windows and not on linux
[14:32] <alecu> mandel, yeah, we can do that for now.
[14:32] <dobey> mandel: that's another problem. we need to split up the DBusTest case, so that we have a DBusGTestCase and DBusQtTestCase or something like that, both inheriting from a DBusTestCase
[14:34] <alecu> dobey, mandel is right: we don't need dbus-qt for the windows port, so if it keeps giving trouble we can safely get rid of it.
[14:34] <mandel> alecu: it would not just be for now, since we do not use twisted for any type of communication we will never need it on linux, just windows.
[14:34] <dobey> alecu: it doesn't matter because we're still doing qt stuff on linux also
[14:35] <alecu> dobey, right, but we won't be doing qt+twisted+dbus in the same process.
[14:35] <dobey> alecu: yes we will.
[14:35] <mandel> we should not use twisted at all on linux
[14:35] <alecu> dobey, and we can solve the dbus+qt issues later.
[14:35] <alecu> dobey, if it keeps giving trouble: no.
[14:35] <dobey> alecu: not in live install perhaps, but the tests are run with a reactor; they have to be.
[14:36] <dobey> alecu: unless we just stop running the tests and you write a different test runner that only uses unittest+qt+dbus or something, instead of the twisted test runner
[14:36] <alecu> dobey, we can have the qt tests running in a different way... exactly.
[14:36] <dobey> i don't even want to begin thinking about that mess though :(
[14:37] <mandel> yes, I would not do that...
[14:37] <dobey> alecu: and either way, we still need to fix several of these issues anyway
[14:37] <alecu> dobey, right, but we don't need it *now*.
[14:37] <dobey> well, we do, but whatever
[14:38] <gord> hi all, me again, ubuntu one has gone crazy :) it just dies after you try and start it, ie: using u1sdtool -s or -c or anything, it starts, then dies. grepped http://paste.ubuntu.com/615344/ from syncdaemon-error.log which seems to be the cause
[14:38] <dobey> gord: are you on O?
[14:38] <gord> dobey, still on natty
[14:38] <dobey> gord: and not using the gnome3 ppa?
[14:39] <alecu> dobey, we currently have to run the tests twice, because we can't have the qt and the glib reactors installed. So I say we do the dbus part of the tests using the glib reactor, and the qt part of the test on their own.
[14:39] <gord> dobey, nope
[14:40] <dobey> gord: ok, good; then hopefully someone can help you. might be due to today being a server rollout day though.
[14:40] <mandel> alecu: getting back to your issues with the reactor, what was the problem, just hte treads and the fact that you had to create the QAppliation first?
[14:41] <alecu> mandel, the issue had to do with the initialization order.
[14:42] <mandel> alecu: well, is a feature from the qtreactor, rather than a bug…
[14:42] <dobey> alecu: well, i don't understand what that has to do with fixing the obvious bugs in devtools.
[14:43] <alecu> mandel, no, wait, there's more: you could not even define any class that derives from dbus.service.Object
[14:43] <mandel> alecu: do you have some code that shows that error?
[14:44] <alecu> you have to make sure that the DBusQtMainLoop and the QtApplication are created before even doing any class xxx(dbus.service.Object).
[14:44] <alecu> mandel, I have a bit of code, yes.
[14:45] <mandel> alecu: may I see it to try to understand the error?
[14:45] <alecu> mandel, sure... I'll push in a minute.
[14:45] <mandel> cool
[14:47] <dobey> alecu: well, the main() should be creating a QApplication and setting up DBusQtMainLoop(), no?
[14:48]  * fagan back 
[14:48] <dobey> alecu: gtk+/glib isn't really any different in that respect
[14:48] <fagan> i have to go again to pick up glasses in an hour though
[14:50] <alecu> fagan, reading glasses or drinking glasses?
[14:51] <fagan> alecu: well seeing far away glasses
[14:51] <fagan> not really reading glasses
[14:51] <mandel> dobey: indeed, that seems perfectly logical
[14:53] <alecu> dobey, right. Main() should be creating QApplication and DBusQtMainLoop. But you can't import any module that defines a class derived from dbus.service.Object till the QApplication has been created.
[14:54] <fagan> ok so who is going to help me figure out why u1cp doeesnt think im connected to the internet
[14:54] <alecu> mandel, dobey: https://code.launchpad.net/~alecu/%2Bjunk/qt-dbus-fails/
[14:54] <dobey> alecu: well importing  should be fine, no? It's instantiation that should fail
[14:54] <alecu> dobey, no.
[14:55] <alecu> dobey, import is fine for glib, but fails for qt.
[14:55] <alecu> dobey, if you run "fails.py" in the branch I pasted above it shows the error.
[14:56] <alecu> uh.,
[14:56] <alecu> I guess you are right :P
[14:56] <ralsina> fagan: it's a change in network manager
[14:57] <fagan> ralsina: ah ok then
[14:57] <fagan> ralsina: then that takes away 1 work item for me :D
[14:57] <alecu> dobey, anyway, instantiation does not fail, it just prints a warning.
[14:57] <fagan> Ill sort payroll then
[14:57] <mandel> alecu: looking
[14:58] <dobey> alecu: also, why did you use qtreactor for that test instead of regular qt loop? :)
[14:59] <dobey> well, anyway, i was right :)
[14:59] <alecu> :P
[14:59] <dobey> so fix your code. and weird that it doesn't raise something, yeah
[15:01] <alecu> It prints a warning, but it fails, because nothing gets exported on the bus... let's see.
[15:02] <dobey> well, trying to do something with those dbus interfaces later will fail, but it should give you some way to handle the problem right there, instead of being a latent error
[15:04]  * alecu needs to go to read the dbus decorators' source
[15:04] <alecu> I'll do it some other day.
[15:05] <dobey> it is complicated; but i don't think that warning is coming from the dbus decorators
[15:06] <dobey> or well, not directly. i think it's coming from the dbus.mainloop.qt code, also indrectly
[15:07] <mandel> alecu: why do you import gobject?
[15:08] <fagan> ok payroll done ralsina have anything for me to do
[15:08] <alecu> mandel, because that snippet was converted from a glib dbus sample.
[15:08] <fagan> i have a little less than an hour before I have to run again
[15:08] <ralsina> fagan: find out when network manager changed online detection for me, please ;-)
[15:08] <fagan> ralsina: cool
[15:08] <dobey> grmbl grmbl
[15:09] <dobey> oh bother, i have to buy postage stamps today
[15:15] <fagan> ralsina: ok so the change as now they have states and they are all listed here http://projects.gnome.org/NetworkManager/developers/migrating-to-09/spec.html#type-NM_DEVICE_STATE
[15:16] <ralsina> fagan: ooooook
[15:16] <ralsina> fagan: check if there is a bug, if not create it and add that link to it, please
[15:16] <ralsina> bug on us, not on NM
[15:16] <fagan> ill create it id say no one is on 11.10 yet
[15:18] <dobey> lots of people are on 11.10 yet
[15:18] <dobey> and i think it's also an issuse in the gnome3 ppa on 11.04
[15:18] <fagan> do they have network-manager updates in that ppa?
[15:19] <mandel> alecu: so if I understand correctly the issue is that if you don't create the QApplication at the very beggining  you get the warnings and  the dbus code does not work right?
[15:19] <dobey> fagan: i think so now
[15:19] <dobey> mandel: it's if you don't create the QApplication before instantiating the dbus objects
[15:20] <dobey> mandel: when using DBusQtMainLoop
[15:21] <mandel> dobey: yes, but that makes complete sense, the DBusQMainLoop requires QThreads and a QThreads needs to know the instance of the application to be able to work
[15:21] <dobey> mandel: right
[15:22] <mandel> dobey: then I see no problem, sorry, is just that the code is wrong
[15:22] <dobey> mandel: problem is that it's just a stupid warning on stdout or stderr it seems, when it should probably raise an exception
[15:22] <dobey> mandel: if only to tell the programmer "hey, you're doing it wrong numbskull!"
[15:23] <mandel> dobey: hahaha true, that is a shitty way to tel someone he is doing it wrong
[15:23] <fagan> Bug #790717
[15:23] <ubot4`> Launchpad bug 790717 in ubuntuone-client "Changes to the network manager break network detection (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/790717
[15:23]  * fagan grabs some food 
[15:23] <dobey> mandel: que ella eso! :)
[15:26] <mandel> hahaha
[15:26] <mandel> alecu: then I'm goingto change the code that adds the correct reactor for you to use, and we will see what is going on
[15:27] <mandel> alecu: I though you had a more complicated issue and did a qt + twisted integration using a diff reactor because there was a bigger issue
[15:29] <alecu> mandel, I'm back.
[15:34] <mandel> alecu: I have a branch with the reactor installing according to the platform that I'll push and I'd like you to take a look, if that is ok I'll like to move to remove the Dbus main loop from main and move it in a platform specific part
[15:34] <ralsina> ok, I am about to take a break. Anyone need something from me right now?
[15:35] <mandel> alecu: I'd like to be able to show the UI on windows by this afternoon
[15:35] <mandel> with no backend work at all, just Ui
[15:35] <ralsina> alecu, mandel: yes, that would be good news
[15:35] <alecu> mandel, cool
[15:44]  * fagan goes to get glasses
[15:58] <mandel> I officialy hate that importing the reactor installs it, that i ugly ugly guly...
[16:02] <dobey> hrmm
[16:02] <dobey> all this defer.inlineCallbacks stuff is causing problems
[16:02] <dobey> mandel: the default select reactor, you mean?
[16:03] <alecu> dobey, how is inlineCallbacks causing problems?
[16:03] <mandel> dobey: yes, is a pain, they should allow you to import the reactor and then install what ever you wanted, I cannot see the reasoning behind the current implementation
[16:04] <dobey> alecu: in the DBusTestCase stuff
[16:05] <dobey> alecu: i am not sure how to explain what i am seeing though
[16:05] <dobey> alecu: because i don't know why the current code is designed the way it is
[16:07] <dobey> i think because of ubuntuone-client, but sso and cp aren't doing stuff the same way
[16:08]  * dobey tries u1client tests with his devtools branch
[16:09]  * fagan back 
[16:14] <mandel> alecu: can you take a look at: https://code.launchpad.net/~mandel/ubuntuone-control-panel/use_correct_reactor/+merge/62961
[16:29] <dobey> bbiab, lunch time
[16:39] <mandel> alecu: ping
[16:39] <alecu> mandel, pong
[16:40] <mandel> alecu: did you take a look at the merge proposal I sent you?
[16:46] <alecu> mandel, not yet... gimme me a few minutes.
[16:47] <fagan> mandel: I could look at it...
[16:47] <mandel> alecu: ok, I need to go to walk the dog and some errands, will be back later to fix any commnets and try to get the control panel running on windows
[16:47]  * mandel walks dog + others
[16:47] <alecu> mandel, ok, cool.
[17:32] <fagan> EOD
[17:32] <dobey> back
[17:52]  * nessita is back from U
[17:59] <dobey> hrmm
[17:59] <dobey> i think windows updated bricked my windows 7 install
[18:01] <AJenbo> dobey, did you remember to do the happy dance while it was updating?
[18:01] <dobey> oh, now the .. is moving on the update/boot screen, but the hdd light isn't blinking so much
[18:02] <cwayne> ello
[18:02] <dobey> hi cwayne
[18:02] <cwayne> i just have a quick question, is the hash that the rest api gives you when you GET a file/folder md5 or sha1
[18:03] <AJenbo> dobey, yeah i does that fore some of the big onces, not really sure what it is wating for
[18:12] <nessita> mandel: ping
[18:17] <dobey> i feel like my laptop is crying
[18:27] <dobey> sigh
[18:47] <dobey> damn, this update better be "upgrading to windows 8" or something
[18:48] <dobey> it has been running for about an hour now, and is still on "Installing update 1 of 12 .. .. .."
[18:54] <nessita> mandel, ralsina: ping?
[18:55] <nessita> dobey: hey there. Were there any updates regarding the isssues we were having with devtools + qtreactor + dbus?
[18:55] <nessita> dobey: do you need some help?
[18:56] <dobey> nessita: i just proposed https://code.launchpad.net/~dobey/ubuntuone-dev-tools/dbus-priv/+merge/63022
[18:57] <nessita> dobey: reviewing
[18:57] <dobey> nessita: it's partial fix (only one of the issues), but helps a lot
[18:57] <nessita> dobey: right, this doesn't fix the cleanup on tearDown, no?
[18:57] <dobey> awesome; now my laptop's screen is just black :(
[18:58] <dobey> nessita: right, there are some very weird issues with the cleanup issue; and i'm not sure i understand everything well enough, and tcole hasn't replied to my earlier ping yet
[18:58] <dobey> and i haven't seen him on irc at all
[18:59] <nessita> dobey: testing the branch now... (code looks OK, I would add the actual value of DBUS_SESSION_BUS_ADDRESS to the execption string)
[18:59] <nessita> exception*
[19:00] <tcole> dobey: ?
[19:00] <dobey> tcole: so i think the inlineCallbacks in the DBusTestCase that you added is causing more issues
[19:01] <tcole> dobey: it might be *exposing* more issues, but believe me it is the correct thing
[19:02] <tcole> dobey: there's a problem with the way that super() chains in trunk, b/c of testtools & testresources bugs :(
[19:02] <dobey> tcole: hrmm, when I get rid of it, and some other code in that testcase though, everything seems to work as expected in sso-client, control-panel, and u1client
[19:02] <tcole> dobey: I have a branch that sorts that out too, but I needed all of these things in the various projects before I could pull them all together
[19:02] <tcole> dobey: argh, well, those tests may have been written wrong
[19:02] <tcole> adapted to the incorrect behavior or something
[19:03] <tcole> *believe me* that chaining deferreds to the parent class setUp is correct
[19:03] <dobey> tcole: is there a specific issue i can replicate which you were fixing, to see if my changes break it or not, so i can understand all this insanity a bit better?
[19:03] <tcole> dobey: no, it's just that you're supposed to wait for the parent class setUp to complete before setUp returns
[19:03] <tcole> dobey: and we weren't doing that there
[19:03] <tcole> dobey: it's part of the defined interface for twisted.trial.unittest.TestCase
[19:03] <dobey> tcole: but i think the yield does that, right? what does inlineCallbacks have to do with that?
[19:04] <tcole> dobey: inlineCallbacks and yield go together
[19:04] <tcole> dobey: the yield makes the function a generator, and inlineCallbacks massages that back into a function that returns a deferred
[19:06] <dobey> hmm
[19:06]  * dobey deletes a bunch of code, makes some changes, and hopes it works
[19:07] <tcole> it isn't strictly necessary to use yield+inlineCallbacks to do this, but it yielded a smaller diff
[19:07] <tcole> (no pun intended)
[19:10] <nessita> alecu: do you know about mandel or ralsina?
[19:10] <nessita> are they gone for the day? are they coming back?
[19:11] <alecu> nessita, I know they are both bearded.
[19:11] <nessita> alecu: well, mandel mentioned he shaved a while ago, so who knows!
[19:11] <dobey> heh
[19:11] <alecu> nessita, mandel said he was coming back after walking the dog and some errands.
[19:12] <alecu> oh, right.
[19:12] <alecu> nessita, and ralsina said he was taking a break.
[19:12] <nessita> ack, thanks
[19:12] <alecu> he didn't specify how long
[19:12] <nessita> I'll wait for them eagerly :-)
[19:12] <nessita> alecu: how are your cp stuff going?
[19:13] <alecu> nessita, weird. I'm getting a "Segmentation fault" after adding some lines of python code, so I'm not happy.
[19:14] <nessita> alecu: is there any dbus involved?
[19:14] <alecu> not at my layer, but surely in the backend.
[19:14] <nessita> that sucks
[19:14] <alecu> nessita, perhaps I need to fake that part, like you did, right?
[19:14] <nessita> right
[19:15] <nessita> alecu: any odea in which layer you have some dbus?
[19:15] <nessita> idea*
[19:15] <dobey> hrmm, no love
[19:15] <nessita> dobey: need help? I'm skilled with yields and inlineCallbacks
[19:16] <alecu> nessita, backend.devices_info is the one calling syncdaemon thru dbus.
[19:17] <alecu> that's the issue :-(
[19:17] <nessita> alecu: you can use my branches
[19:17] <dobey> nessita: i think i need a miracle
[19:17] <nessita> alecu: and that will abstract you from dbus. Please merge trunk in
[19:17] <nessita> dobey: no way :-). Wanna be more specific? I may help
[19:17] <nessita> (at least I can try)
[19:18] <alecu> nessita, will do, thanks!
[19:18] <nessita> alecu: merging the last branch of mine that landed this morning, there is no more DBus for syncdaemon (except for the StatusChanged signal). Then, if you look at:
[19:18] <nessita> gui/qt/gui.py
[19:18] <nessita> you will find that I fake the SyncDaemonTool patching the "system" one
[19:18] <nessita> and then you can add all the fixed info you need
[19:19] <nessita> to run IRL, that is
[19:20] <tcole> dobey: if it aids understanding, these two implementations of setUp are functionally equivalent: https://pastebin.canonical.com/48004/
[19:21] <tcole> dobey: oops
[19:21] <tcole> dobey: hang on
[19:21] <tcole> dobey: okay, try this: https://pastebin.canonical.com/48005/
[19:21] <tcole> I made a typo in the first paste
[19:25] <dobey> so if that is correct, what is causeing the shsutdown failures then
[19:29] <alecu> nessita, can I have your review on this? https://code.launchpad.net/~alecu/ubuntuone-control-panel/tx-web-client/+merge/62889
[19:29] <nessita> alecu: sure, I'll do it in a couple of mins (finishing with dobey's)
[19:32] <nessita> dobey: approved
[19:36] <dobey> tcole: i don't understand what is keeping these dbus connectsions open then; because when i remove all the defer.inlineCallbacks magic, it seems to work :(
[19:37] <tcole> dobey: what happens when you use the non-inlineCallbacks version instead?
[19:38] <tcole> (from the pastebin)
[19:38] <dobey> tcole: http://pastebin.ubuntu.com/615467/ works, but if I add the decorator, it fails.
[19:38] <dobey> tcole: hrmm, let me try
[19:39] <tcole> dobey: if that makes things pass where the inlineCallbacks version doesn't, then I'm totally OK with replacing the inlineCallbacks version with the explicitly callbacked one, but we do need one or the other to be correct :/
[19:40] <dobey> exceptions.AttributeError: 'NoneType' object has no attribute 'addCallback'
[19:41] <dobey> tcole: ^^^ get that with yours
[19:41] <tcole> hnnnh
[19:41] <nessita> dobey: that means that you have a function decorated with inlineCallbacks that does not return a deferred
[19:42] <nessita> dobey: where are you getting that error?
[19:42] <dobey> nessita: in trying to use tcole's suggested other implementation of setUp without inlineCallbacks
[19:43] <nessita> dobey: can you please point me to a branchable branch (:-P) to be run by myself?
[19:43] <tcole> dobey: so, apparently (in the failing test cases) there's another class in the inheritance hierarchy which is getting put before TestCase.setUp in the method resolution order, and itself fails to chain callbacks correctly via setUp
[19:44] <tcole> nessita: I strongly suspect MI/mixin shennanigans wrt chaining setUp deferreds :/
[19:44] <nessita> tcole: maybe, but is hard to guess for me without imagining what code is failing
[19:45] <nessita> alecu: question, why the rename ubuntuone/controlpanel/web_client/linux.py => ubuntuone/controlpanel/web_client/libsoup.py?
[19:45] <tcole> nessita: it's apparently coming from the modified setUp in this case -- this means that super(DBusTestCase, self).setUp() is returning None and not a deferred
[19:45] <nessita> alecu:  and... OH, we're both editing some ui files at the same time (smells like BOOM spirit)
[19:46] <tcole> nessita: which shouldn't normally happen since the next class up in the hierarchy which defines setUp is twisted.trial.unittest.TestCase, which *does* return a deferred
[19:46] <alecu> nessita, because on linux we may use other webclient other than libsoup. Ie, twisted.web.client.
[19:46] <dobey> nessita: no, because i haven't pushed one, because i'm experimenting to try and understand this better so i can fix the problems
[19:46] <dobey> tcole: the only thing in the middle is BaseTestCase in the same file, which doesn't override setUp/tearDown at all
[19:46] <tcole> nessita: so, for the things that are failing, some other class is getting interposed in the inheritance linearization via multiple inheritance
[19:46] <nessita> dobey: wanna push so we can help debug?
[19:46] <alecu> nessita, we can manually merge, it's not so complicated.
[19:46] <tcole> dobey: right, but MI downstream can end up inserting other classes in the method resolution chain between them
[19:47] <dobey> hrmm
[19:47] <nessita> mandel: I need you to review a Needs Fixing, please!
[19:47] <tcole> dobey: DBusTestCase -> BaseTestCase -> t.t.u.TestCase
[19:48] <tcole> dobey: but let's say we have a class Foo(DBusTestCase, WheeTestCase), where WheeTestCase -> t.t.u.TestCase
[19:48] <dobey> tcole: so, i am getting that failure i pasted in the devtools tests, and there is no MI in there
[19:48] <tcole> huh
[19:48] <dobey> tcole: the missing addCallback, that is
[19:48] <dobey> hrmm
[19:49] <tcole> I don't know then, the tests passed for me before I proposed that branch
[19:49] <tcole> s/before/when/
[19:49] <tcole> and for that matter they got through tarmac if it landed
[19:51] <dobey> well tarmac didn't do the non-inlineCallbacks method
[19:51] <nessita> dobey: inlineCallbacks + yield is 100% equivalent to chaining callbacks
[19:52] <nessita> dobey: can you please push what you're modifying so we can help you by looking at the code itself?
[19:52] <tcole> nessita: not completely, IIRC inlineCallbacks uses maybeDeferred with yield
[19:53] <nessita> tcole: you sure?
[19:53] <tcole> I'm pretty sure yes
[19:53] <tcole> anyway, the parent class setUp really *shouldn't* be returning None in this case; since it is, that suggests something else is wrong
[19:54] <tcole> maybeDeferred shouldn't be needed in this case
[19:54] <dobey> tcole: ok; so i figured out that problem
[19:54] <thisfred> something in the class hierarchy fails to call super (correctly), is my hunch
[19:54] <dobey> super() is dumb.
[19:55] <tcole> nessita: seems I'm wrong, inlineCallbacks doesn't automatically use maybeDeferred
[19:55] <tcole> dobey: oh?
[19:55] <dobey> if the parent class doesn't override the method, then it apparently isn't calling that parent's method as well
[19:56] <dobey> so for some reason, it got None
[19:56] <mandel> nessita: pong
[19:56] <tcole> dobey: normally when that happens it's because of MI and a mixed-in class that defines setUp without calling super()
[19:56] <dobey> if i add a setUp() to BaseTestCase that just does super() though, the AttributeError thing went away
[19:56] <mandel> nessita: is kind of late her but tell me
[19:56] <nessita> mandel: hey there! I was just looking at your branch. 2 things:
[19:56] <tcole> mm
[19:56] <tcole> dobey: so, that shouldn't be necessary
[19:57] <tcole> dobey: can you show me the __mro__ for the test class where this is actually failing?
[19:57] <nessita> mandel: could you please approve https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/update-file-sync-status/+merge/62575? your Needs Fixing is preventing me from lkand
[19:57] <nessita> land*
[19:57] <mandel> nessita: done
[19:58] <tcole> dobey: like, if the failure(s) happen when running the tests in SomeTestCase, I'd like to see SomeTestCase.__mro__
[19:58] <nessita> mandel: the other thing, in your credentials branch, you are duplicating all the logger setup in both linux and windows code. In the review I asked you to move that to the non-platform specific code
[19:58] <nessita> mandel: maybe you forgot to push that?
[19:58] <nessita> mandel: thanks to the review!
[19:58] <mandel> nessita: oh, indeed
[19:58] <mandel> nessita: I'll do it right now
[19:58] <nessita> mandel: thanks! then I'll approve also globally, so it lands
[19:59] <dobey> hmm
[20:00] <dobey> tcole: ok, one minute
[20:00] <dobey> (or five)
[20:00] <nessita> alecu: can you please merge into your branch the one from https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/update-file-sync-status/+merge/62575? is about to land and I can tell it will cause conflicts with yours
[20:01] <alecu> nessita, ok
[20:05] <dobey> tcole: hrmm, how do i see that?
[20:05] <tcole> dobey: eh, do a sys.stderr.write("DEBUG: mro = %r\n" % (SomeClass.__mro__,)) or something
[20:05] <tcole> (note well the tuple comma)
[20:06] <tcole> or just import stuff in an interactive python session
[20:06] <tcole> at which point you can just evaluate SomeClass.__mro__ interactively
[20:08] <mandel> nessita: changes pushed
[20:08]  * mandel changing network...
[20:09] <dobey> tcole: (<class 'ubuntuone.devtools.services.tests.test_dbus.TestWithDBus'>, <class 'ubuntuone.devtools.testcase.DBusTestCase'>, <class 'ubuntuone.devtools.testcase.BaseTestCase'>, <class 'twisted.trial.unittest.TestCase'>, <class 'twisted.trial.unittest._Assertions'>, <class 'unittest.case.TestCase'>, <type 'object'>)
[20:09] <tcole> huh.
[20:10] <tcole> so, if BaseTestCase doesn't define its own setUp(), super(DBusTestCase, self).setUp() should totally go straight to twisted.trial.unittest.TestCase.setUp
[20:10] <dobey> i would think so too, but it doesn't seem to be
[20:12] <dobey> tcole: although, twisted.trial.unittest.TestCase doesn't define a setUp either :(
[20:12] <dobey> nor does _Assertions
[20:13] <tcole> hmm
[20:13] <nessita> mandel: ack
[20:15] <dobey> rather
[20:15] <dobey> twisted's TestCase seems to call setUp inside a maybeDeferred
[20:16] <dobey> same with tearDown (and all the tests actually)
[20:17] <dobey> looking at the code it seems like the general case should be to just write stuff like it's normal unittest bits without deferreds?
[20:17] <nessita> dobey: any hints about why https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/update-file-sync-status/+merge/62575 failed? I think the key error is:
[20:17] <nessita> sh: pyrcc4: not found
[20:18] <dobey> nessita: sounds like it's failing to build stuff?
[20:18] <nessita> dobey: tarmac needs pyqt4-dev-tools
[20:18] <mandel> alecu: ping
[20:18] <alecu> mandel, pong
[20:18] <nessita> dobey: can you please install it?
[20:18] <mandel> alecu: did you have the time to look at the branch?
[20:18] <tcole> dobey: unfortunately that won't work
[20:19] <tcole> (reliably)
[20:19] <alecu> mandel, yes, and it needs fixing
[20:19] <mandel> alecu: cool, I'll take a look
[20:19] <tcole> dobey: everyone has to consistently chain deferreds or it all goes wonky and race condition-y
[20:19] <dobey> tcole: unfortunately, in my experience "reliable" and "twisted" don't go together :(
[20:20] <dobey> nessita: when was that added as a dep?
[20:20] <mandel> alecu: he, stupid non compiled langs… Is funny that pylint did not catch that problem
[20:20] <nessita> dobey: with this branch. Shall I have added to any predefined list? (I forgot to tell you directly)
[20:20] <mandel> alecu: for testing we should move the dbus stuff out… I'll work on it
[20:21] <dobey> nessita: i don't see where it gets called in that branch?
[20:22] <nessita> dobey: is automatically being called by setup build, something in the qt build chain generates the proper resources files that we now need for icons
[20:22] <dobey> tcole: hrmm, i wonder what is deriving from us that is chaining deferreds on setUp?
[20:22] <tcole> dobey: everything should
[20:24] <dobey> tcole: ok, well i don't understand how to fix this then; the only apparent proper solution to me seems to be "twisted needs to gtfo" :-/
[20:25] <tcole> dobey: I think using maybeDeferred in DBusTestCase could be sufficient
[20:25] <tcole> yield maybeDeferred(super(DBusTestCase, self).setUp)
[20:26] <dobey> ugh
[20:26] <tcole> trying to work out in my head whether that covers the MI case
[20:26] <tcole> I think it does
[20:27] <dobey>   File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 133, in maybeDeferred
[20:27] <dobey>     result = f(*args, **kw)
[20:27] <dobey> lol. fml.
[20:27] <dobey> exceptions.TypeError: 'NoneType' object is not callable
[20:27] <nessita> mandel: tons of lint issues! :-)
[20:29] <nessita> mandel: errors added to the merge proposal
[20:29] <nessita> dobey: would you please let me know when the new dep is installed so I can re-approve?
[20:29] <dobey> nessita: oh sorry; it is installed now
[20:29] <nessita> dobey: thanks!
[20:30] <dobey> distracted by twisted and qt being horrible things :-/
[20:31] <tcole> twisted gtfo is sounding pretty appealing just now
[20:31] <nessita> dobey: you still don't show me anything so I can help you with! :-)
[20:32] <tcole> nessita: we just hit a design problem in twisted -- DBusTestCase (and any class like it) needs to chain setUp with super() to be MI-safe
[20:32] <tcole> nessita: but Twisted's TestCase (nor any of its ancestors) doesn't define its own setUp
[20:32] <dobey> nessita: i don't think there's any way to fix wrapper(None) trying to call None(*args, **kwargs) from breaking
[20:32] <nessita> tcole: I will suggest asking jml directly, he built that as far as I know :-)
[20:33] <tcole> nessita: he seems to be away on an extended basis atm
[20:33] <nessita> oh
[20:34] <dobey> i would be too if it was 20:30 here
[20:34] <nessita> right
[20:34] <tcole> I meant more "idle for 4 days" extended
[20:34] <nessita> email him maybe?
[20:34] <mandel> nessita: really? but I did not change a think… man I hate lint, I'll fix them asap
[20:35] <dobey> mandel: see my e-mail to the list about switching to pyflakes, and tell me what you think :)
[20:35] <nessita> mandel: "I did not change a thing" <- lier! you moved stuff around like crazy :-)
[20:35] <nessita> dobey: right, I need to dive in too
[20:36] <mandel> nessita: well I moved the logger, but nothing else… it does not make sense to block due to that… anyway I'll fix them
[20:36] <nessita> dobey: at this stage I think you're right, you now. Though I may be running pylint myself as a personal measure
[20:36] <mandel> dobey: yes, I hate lint, I also hate that ython is not compiled...
[20:36] <nessita> mandel: well, you left ununsed imports
[20:37] <thisfred> I have not yet found anything I'd miss from pylint that pyflakes does not have
[20:37] <dobey> mandel: yes; we can just summarize all that as "i hate python" :)
[20:37] <nessita> mandel: I'll approve, once your lint changes kick in, approve the merge proposal yourself, yes?
[20:37] <dobey> thisfred: well there is the XXX/FIXME/etcc customization
[20:37] <thisfred> meh
[20:37] <dobey> thisfred: and it's nice to shove those in your face during the lint run
[20:37] <mandel> nessita: sure
[20:37] <dobey> thisfred: even if all it makes you do is remove them from the code
[20:38] <mandel> dobey: hehe yes, I'm starting to do it a little :)
[20:38] <thisfred> dobey: I suppose, yeah
[20:38] <tcole> dobey: I think I may have a short-term fix
[20:38] <nessita> alecu: my branch landed (FYI)
[20:38] <tcole> dobey: let me ponder some more
[20:38] <alecu> great
[20:38] <dobey> tcole: ok
[20:39] <dobey> hrmm
[20:43] <dobey> grr
[20:44] <nessita> alecu: let me know when I should re branch yours to review
[20:45] <tcole> dobey: so, I think basically what we have to do, until I get twisted straightened out, is this:
[20:45] <tcole>     superSetUp = super(DBusTestCase, self).setUp
[20:45] <tcole>     if superSetUp is not None:
[20:45] <tcole>         yield defer.maybeDeferred(superSetUp)
[20:46] <tcole> dobey: thankfully not everywhere, but in fact for every class which doesn't normally get a defined setUp from its ancestors
[20:47] <alecu> tcole, may I suggest not using super, and manually calling the parent class setUp?
[20:47] <alecu> tcole, as per http://fuhm.net/super-harmful/
[20:47] <tcole> alecu: NO
[20:47] <dobey> hrmm
[20:48] <tcole> I agree with that article, but our situation is one where we have no choice but to use super and use it consistently
[20:48] <tcole> in any case, the problem here is that the parent class may not have setUp
[20:49] <dobey> well one problem
[20:49] <alecu> but "Superclasses must use super if their subclasses do". And we can't modify all of trial and twisted, so manually calling the right setUp on the parent sounds reasonable.
[20:49] <dobey> afaict it works perfectly fine (actually, everything is working as i expect it would), without all the inlineCallbacks stuff
[20:50] <dobey> i don't understand how doing inlineCallbacks actually makes anything work, since for me, all it does is make stuff not work :(
[20:54] <tcole> dobey: it's mainly for the MI case
[20:55] <tcole> alecu, dobey: unfortunately we have a lot of MI happening with twisted test cases; our only choice is to use super consistently everywhere
[20:55] <dobey> can i just make the test case check for MI and fail with a GTFO message? :)
[20:55] <tcole> not easily
[20:56] <tcole> that wouldn't really help either
[20:56] <dobey> tcole: i don't mind calling super(); that is fine by me; my problem is that for some reason @inlineCallbacks makes what i'm doing just not work
[20:56] <dobey> if i remove @inlineCallbacks, it works perfectly
[20:56] <tcole> well, there is the problem of the None-setUp from above
[20:56] <tcole> that is part of the breakage there
[20:57] <tcole> dobey: with inlineCallbacks, I mean
[20:57] <dobey> that doesn't explain why my own tearDown doesn't seem to be getting called
[20:57] <dobey> or at least, not called consistently
[20:57] <tcole> your teardown is asynchronous, isn't it?
[20:58] <tcole> typically what is going on in those cases is that the teardown is being called, but the deferred is not chained/waited for
[20:58] <dobey> not now; it has 3 yield foo(), the last of which is calling super() with the check for parent tearDown being there
[20:58] <tcole> that's asynchronous yes
[20:58] <tcole> at least from an outside perspective
[20:59] <tcole> anyway, probably you're ending up with a race condition where someone is calling your tearDown (via super() or otherwise), but not waiting for it, so there's a race condition as far as whether it can complete before the test cleanup finishes
[20:59] <tcole> if not, unclean reactor etc.
[21:00] <tcole> but, let's try the superSetUp thing next
[21:00] <tcole> and see how far that gets us
[21:00] <dobey> then is there any good reason to not remove the inlineCallbacks wrappers until wisted is fixed?
[21:01] <dobey> the checking for parent setUp/tearDown works fine, but inlineCallbacks still breaks the world
[21:02] <tcole> well, is it really inlineCallbacks?
[21:03] <dobey> well, if i remove it, it works; if i add it, it breaks
[21:03] <tcole> that's a bit simplistic
[21:03] <tcole> here, let me do up the equivalent explicit callbacks version
[21:04] <dobey> well, i have no idea how else to debug why my teardown isn't working right
[21:04] <dobey> inlineCallbacks got added to setUp, and stuff started breaking; if i remove it, things work right again
[21:06] <dobey> hell, i'll tweak the twisted code and see if it fixes it then
[21:06] <tcole> dobey: try this: https://pastebin.canonical.com/48013/
[21:06] <tcole> it *should* fail in the same way as with inlineCallbacks
[21:06] <tcole> if it doesn't then that tells us some things though
[21:07] <tcole> hopefully at that point we can focus more specifically on what's going on in tearDown
[21:10] <dobey>         yield self.bus.flush()
[21:10] <dobey>         yield self.bus.close()
[21:10] <dobey> that's basically tearDown()
[21:10] <dobey> with a check/yield/maybeDeferred on the super() call after that
[21:12]  * tcole nods
[21:14] <dobey> tcole: hrmm, with that way of doing things, it seems that the setup_dbus never gets called
[21:17] <dobey> exceptions.AttributeError: 'TestWithDBus' object has no attribute 'bus'
[21:17] <dobey> that happens when tearDown() gets called
[21:20] <tcole> interesting
[21:21] <tcole> what happens if you short-circuit it with d = defer.succeed(None) ?
[21:21] <tcole> (putting that after the if/else)
[21:21] <thisfred> well, since superSetup apparently is None in some cases, it's unsurprising
[21:21] <thisfred> since in that case it's not called.
[21:21] <tcole> why would that be unsurprising?
[21:21] <tcole> thisfred: given this: https://pastebin.canonical.com/48013/
[21:22] <dobey> overriding the d instantiation doesn't help
[21:23] <thisfred> well the super method being None is the problem, but all this does is explicitly break the super chain, right? so the setting of the .bus property not happening is unsurprising
[21:27] <tcole> thisfred: have you read the code I pasted?
[21:27] <tcole> if superSetUp is None, then it falls through to the d = defer.succeed(None) case
[21:27] <thisfred> tcole, yep.
[21:27] <tcole> after which point d.addCallback(setup_dbus) is called
[21:27] <tcole> and that should call setup_dbus immediately
[21:27] <tcole> and setup_dbus sets self.bus
[21:27] <thisfred> ah right
[21:28] <thisfred> I only read the first part
[21:28] <thisfred> so then the issue is the callback does not fire at all?
[21:28] <dobey> tcole: isn't defer.succeed() supposed to take True/False as argument, not None?
[21:28] <dobey> though I guess None evals to False
[21:29] <tcole> dobey: no, it takes a result
[21:29] <dobey> thisfred: it doesn't appear to get called
[21:29] <tcole> dobey: which gets passed to callbacks
[21:29] <dobey> ah ok
[21:29] <tcole> http://twistedmatrix.com/documents/8.1.0/api/twisted.internet.defer.html#succeed
[21:30] <dobey> so definitely not getting called
[21:30] <dobey> i added a raise to the setup_dbus, and nothing happens.
[21:31] <tcole> is superSetUp not None, perhaps?
[21:32] <thisfred> it should only ever be None in the "superest" class right?
[21:33] <thisfred> no, the ultimate base class can't call super, that would just fail
[21:34] <thisfred> I don't see how it can ever be None, rather than an attribute error
[21:35] <dobey> so it's not
[21:35] <dobey> the problem is that it returns None
[21:35] <thisfred> right
[21:36] <dobey> since it ultimately is hitting the unittest.TestCase.setUp
[21:38] <tcole> I thought TestCase didn't have a default setUp
[21:39] <tcole> hm, so it does
[21:39] <dobey> unittest does
[21:39] <dobey> twisted doesn't
[21:40] <tcole> but twisted apparently inherits from TestCase
[21:40] <tcole> er, from unittest
[21:40] <dobey> yes
[21:40] <dobey> but 'pass' just gives you back a None :)
[21:40] <tcole> I feel like we've been here before
[21:40] <dobey> watch out for windows that don't exist any more
[21:42] <tcole> dobey: all right, so... as far as the original problem you were hitting
[21:42] <tcole> what's the briefest way to reproduce?
[21:43] <thisfred> what happens if you do this: https://pastebin.canonical.com/48018/
[21:44] <thisfred> or does that fail in case the setup *does* return a deferred?
[21:48] <dobey> did this instead: https://pastebin.canonical.com/48019/
[21:48] <dobey> but still fails
[21:48] <dobey> the _setup_dbus doesn't seem to get called
[21:48] <dobey> or twisted is just trapping the exception
[21:49] <thisfred> does pdb.set_trace() work?
[21:50] <thisfred> or just debug prints, to see what the values are
[21:51] <dobey> work where?
[21:51] <dobey> so i know that the defer.succeed() is being called there
[21:52] <thisfred> in this setUp, so you can see what d is? I suppose it is None
[21:52] <thisfred> right
[21:52] <thisfred> and the callbacks are added, they just never get called
[21:53] <dobey> right
[21:53] <dobey> i am guessing it is just twisted being broken
[21:54] <tcole> I don't even know at this point
[21:56] <thisfred> t.t.u.TestCase has deferSetup and deferTearDown. Helpfully without any doc strings
[21:57] <dobey> doc strings are for kids. twisted is hardcore.
[22:08] <thisfred> Looks like those are only used internally, to call the class' setUp and tearDown in an asynchronous fashion.
[22:09] <dobey> right
[22:09] <dobey> which totally breaks everything ever
[22:10] <nessita> alecu: how's the merge going? too much trouble? can I help?
[22:11] <tcole> dobey: I think before I waste too much more of your time with this, I should devise a test case that captures the case that the inlineCallbacks change is supposed to fix
[22:11] <thisfred> dobey: it suggests to me though, that subclasses shouldn't have to bother with deferred themselves in either setUp and tearDown
[22:13] <alecu> nessita, a bit messy. yes. no, thanks.
[22:13] <dobey> tcole: i would appreaciate that
[22:13] <nessita> alecu: :-)
[22:13] <dobey> thisfred: right, which is why i want to get rid of the inlineCallbacks usage
[22:13] <thisfred> right
[22:14] <dobey> well, and because getting rid of it makes everything work like how i'd expect it to
[22:16] <tcole> thisfred: no, they have to
[22:16] <tcole> thisfred: subclasses are responsible for chaining deferreds with parent classes
[22:16] <tcole> deferredSetUp only does the initial call to setUp
[22:18] <thisfred> tcole: but that would only matter if the superclasses do anything with deferreds in *their* setup, right? Which the dbus test case does, I guess
[22:18] <dobey> tcole: it seems like what you're trying to say is that parent classes are responsible for chaining deferreds with subclasses, instead; no?
[22:18] <tcole> thisfred: yeah, in practice, though it's not very good to *assume* that the superclass doesn't
[22:19] <tcole> dobey: well, they're responsible for returning a deferred that subclasses can chain to
[22:19] <thisfred> tcole: well, that seems to be twisted's expectation, foolish or no
[22:19] <tcole> dobey: and they're responsible for using super() correctly and chaining to that deferred so that MI works correctly
[22:20] <thisfred> hmm, maybe not. They just cater to the simplest use case
[22:20] <tcole> I don't think whoever wrote this thought this through very carefully
[22:21] <tcole> or maybe MI wasn't part of the intended use case
[22:21] <tcole> but I guess we need to fix that since we have a lot of MI in tests
[22:21] <dobey> i don't think MI matters here right now
[22:22] <tcole> some of DBusTestCase's subclasses in ubuntuone-servers use MI, IIRC
[22:22] <dobey> ugh a recall on my car
[22:24] <dobey> tcole: afaict, nothing in ubuntuone-servers is using DBusTestCase
[22:24] <tcole> lemme check
[22:24] <dobey> some of the ubuntuone-client tests do, and a couple might use MI. not sure
[22:26] <tcole> yeah, it's the client tests apparently
[22:26] <tcole> ./sourcecode/ubuntuone-client/tests/platform/linux/test_dbus.py:class DBusTwistedTestCase(DBusTestCase, BaseTwistedTestCase):
[22:26] <dobey> right
[22:26] <tcole> and it doesn't chain super() correctly
[22:26] <tcole> or the deferred
[22:26] <tcole> gee, I wonder why these tests are so flaky? :P
[22:28] <dobey> but that doesn't explain why adding the deferred junk makes the tests fail that don't use MI
[22:32] <dobey> omfg, someone else decided to name something 'neon'
[22:34] <alecu> dobey, as in "Evangelion" ?
[22:35] <dobey> well, so there is an http library called neon
[22:35] <dobey> and then at UDS, there was that arm graphics project thing mentioned, also called neon
[22:35] <dobey> and now there is a kde thing called project neon
[22:47] <dobey> anyway
[22:47] <dobey> my brain is twisted now
[22:47] <dobey> have a good evening all. hopefully we can fix this tomorrow
[22:48] <dobey> oh, can i get a second review on https://code.launchpad.net/~dobey/ubuntuone-dev-tools/dbus-priv/+merge/63022 please?
[22:48] <dobey> anyway, good evening :)
[22:54]  * nessita -> food hunting, brb
[23:01]  * thisfred off too, see y'all tomorrow
[23:01] <thisfred> let's see if the dog wants to go out in 96F