[07:34] <ralsina> morning...
[07:49] <mandel> morning all
[07:52] <ralsina> good morning mandel
[07:52] <mandel> ralsina: buenas :)
[07:53] <mandel> lets see how the day goes today...
[07:53]  * ralsina da golpe en el hombro
[07:55] <mandel> :)
[08:01] <ralsina> mandel: is the canonical IRC server working for you?
[08:30] <ralsina> taking a short coffe break, will be back in 30 minutes or so
[09:03] <mandel> ralsina: it does work for me
[09:03] <ralsina> blah, my quasselcore had become stuck
[09:04] <ralsina> the crappy sftware only worked for 2 months without crashing!
[09:05] <mandel> ralsina: hehe that is the new idea for server code, 2 montsh is good enough ;)
[09:06] <ralsina> on web, sure, since if you have not re-deployed for2 months, your company has probably died ;-)
[09:20] <kazade> hey guys, I think I've done something a bit foolish with Ubuntu one, I'm just wondering, do you guys keep backups for any period of time in case something goes wrong?
[09:20] <mandel> kazade: what has happened?
[09:21] <mandel> ralsina: can you reiew: https://code.launchpad.net/~mandel/ubuntuone-control-panel/use_correct_reactor/+merge/62961
[09:21] <ralsina> mandel: sure
[09:21] <kazade> mandel, well, I had ~30G of pictures in my storage, and the other day I reinstalled my laptop and decided I didn't need them on my laptop, so I unticked "Sync this folder"....
[09:22] <kazade> that didn't do what I thought it did
[09:22] <kazade> I thought it just wouldn't download that folder to my laptop, but apparently it removes it from U1 completely
[09:22] <mandel> kazade: well there is a way to recomber the files, but I dont have such a super power
[09:22] <kazade> now I'm hoping I have those pictures on my desktop, but in the worst case is there any way back
[09:22] <ralsina> mandel: isn't that a conflict in line 30?
[09:23] <mandel> ralsina: let me check
[09:23] <mandel> kazade: try to see if you have them in your desktop and to be super save, start it with no internet connection
[09:24] <mandel> kazade: if you don't have them, pop here and ask for help and we will point you to the person with the super powers ;)
[09:24] <kazade> ok, thanks mandel
[09:24] <kazade> is there a way to stop a certain folder downloading on one PC?
[09:24] <kazade> I mean, I want the Ubuntu One folder on my work laptop, but not my pictures
[09:25] <mandel> kazade: yes, you can move the pict out of the 'Ubuntu One' folder and tell them to sync as a diff folder
[09:25] <mandel> then tell the app not to sync that udf (User Defined Folder)
[09:25] <mandel> ralsina: weird, I though there were no merge issues, let me fix it
[09:26] <ralsina> mandel: ok
[09:29] <kazade> mandel, that's what I tried to do... I had ~/Pictures sharing as well as ~/Ubuntu One. I unticked "sync" on my laptop and it removed it totally from U1
[09:30] <mandel> kazade: strange… ralsina that ^ is the correct way to do it right?
[09:30] <ralsina> yes, that should not remove it
[09:31] <kazade> hmm, well it's definitely not there now :(
[09:34] <kazade> mandel, do you know how long U1 keeps backups for?
[09:35] <mandel> kazade: no idea, but I can find out, one sec :)
[09:52] <mandel> ralsina: can you run the test in ubuntone-control-panel like this: ./runtests -qt
[09:52] <mandel> ralsina: I think thee is a broken test in trunk
[09:52] <ralsina> mandel: run them in trunk? Sure
[09:52] <mandel> ralsina: yes, trunk it is, there is a failing test in my system
[09:53] <mandel> and I'm sure I'm up to date with everything
[09:53] <ralsina> mandel: ok, let me check
[09:55] <ralsina> yep, there is one failing test
[09:55] <ralsina> but that's a knwn problem in devtools that dobey is trying to fix
[09:56] <ralsina> mandel: you get the one with REQUEST_NAME_REPLY_EXISTS right? That is the known one.
[09:56] <kazade> mandel, I don't suppose you could point me to that person with super restore powers?
[09:56] <kazade> I'm fairly sure that even if I do have them at home, I don't have all of them
[09:57] <mandel> kazade: I can, but he is in the US so you will have to wait a little, is that ok?
[09:57] <kazade> mandel, sure
[09:57] <mandel> kazade: the person to ask is joshuahoover
[09:58] <ralsina> kazade: he should be around in 3 or 4 hours
[09:58] <kazade> ok thanks guys
[09:58] <mandel> np
[09:58]  * kazade is bricking it
[09:58] <kazade> my girlfriend will kill me if those pictures go missing!
[09:59] <mandel> kazade: he, girlfriends… you dont want to get in trouble with them ;)
[10:00] <mandel> ralsina: I have fixed the merge issue: https://code.launchpad.net/~mandel/ubuntuone-control-panel/use_correct_reactor/+merge/62961
[10:01] <mandel> ralsina: I;l move to make the ui run on windows and later we can see what to do next
[10:01] <ralsina> mandel: I am going to take a long break in a few minutes and come back in 4 hours or so
[10:02] <mandel> ralsina: ok, np, I'll be here working and then will walk the dog and exercise a little
[10:02] <mandel> :)
[10:02] <ralsina> cool then
[10:03] <ralsina> mandel: I will run the tests on this one, though
[10:07] <mandel> ralsina: cool
[10:07] <ralsina> mandel: tests pass except the one we expect to fail, code looks good, so +1 from me
[10:08] <mandel> ralsina: ok, alecu will take a look at it later
[10:08] <ralsina> oh, mine, my folders is showing actual information :-D
[10:10] <ralsina> and the connect button works!
[10:12] <duanedesign> morning all
[10:13] <fagan> morning
[12:11] <duanedesign> facundobatista: was just looking at bug 786189 . I noticed you had commented on similar bugs in the past. Is this likely a problem with bad metadata?
[12:11] <ubot4`> Launchpad bug 786189 in ubuntuone-client (Ubuntu) "Ubuntu-One on 10.04 Netbook Edition will not sync from server to netbook (affects: 1) (heat: 498)" [Undecided,New] https://launchpad.net/bugs/786189
[12:30] <facundobatista> duanedesign, let me see...
[12:32] <facundobatista> duanedesign, yes, this is very ugly: 'is_directory': 'T', 'changed': 'LOCAL',
[12:35] <nessita> hello everyone!
[12:42] <Pretto> any ubuntuone devel here to help with one question about the UI?
[12:44] <fagan> Pretto: fire away
[12:45] <Pretto> fagan: I looked for the code that changes the buttons in control center, but couldn't find
[12:45] <alecu> hello Ubuntu One!
[12:45] <fagan> Pretto: nessita can probably help with that
[12:46] <fagan> hey alecu
[12:46] <nessita> hi alecu!
[12:46] <nessita> Pretto: hi there, how can I help? meaning, what do you want to do with the buttons (and which ones?)?
[12:46] <alecu> nessita, btw... can you review this branch again? https://code.launchpad.net/~alecu/ubuntuone-control-panel/tx-web-client/+merge/62889
[12:46] <nessita> alecu: sure!
[12:47] <alecu> rthanks!
[12:48] <facundobatista> Hola nessita, alecu
[12:48] <alecu> hola facu
[12:49] <nessita> hola facundobatista! what a pleasure seeing you around
[12:49] <facundobatista> nessita, that's because I finally took a shower?
[12:50] <nessita> it was about time!
[13:31] <nessita> alecu:  there is a couple of needs fixing, when you fix those I'll test it IRL
[13:33] <alecu> nessita, thanks for the comments; looking now.
[13:46] <ralsina> good evening folks!
[13:46] <nessita> hi ralsina
[13:47] <alecu> nessita, I certainly forgot the "twisted.internet.base.DelayedCall.debug" in there. But perhaps we could have u1trial set it before running. Or setting it as a cmdline option.
[13:47] <nessita> alecu: makes sense
[13:47] <nessita> can it be set from command line?
[13:49] <dobey> mandel, ralsina: the NAME_EXISTS issue should be fixed in nightlies now
[13:49] <ralsina> dobey: cool!
[13:49] <nessita> dobey: yey!
[13:50] <ralsina> OMG, it's standup time in 10'!
[13:50] <ralsina> dobey: was it as hard as it seemed to be yesterday?
[13:52] <dobey> ralsina: well, was mostly fixed on tuesday. and the twisted issues aren't properly fixed. just worked around. will be insanely hard to fix them :-/
[13:52] <ralsina> dobey: fixing for the tests an incredibly hard issue that doesn't show up in the real usage makes no sense
[13:53] <ralsina> Then again, I was fully grown up before being exposed to TDD so I have a strong immune response ;-)
[13:54]  * nessita gets scared by ralsina's comment
[13:54] <ralsina> See? ;-)
[13:54]  * ralsina is on epater le bourgueoise mode
[13:54] <alecu> here's bug 791834
[13:54] <ubot4`> Launchpad bug 791834 in ubuntuone-dev-tools "Add an option to enable DelayedCall.debug (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/791834
[13:54] <dobey> heh
[13:54]  * fagan doesnt know what that means
[13:55] <nessita> ralsina: I kinda agree on balancing the efforts regarding production code vs test development, but we need a sane running test suite to be able to throw new code in the "street" (cd, whatever)
[13:55] <dobey> it's the triptophan
[13:55] <fagan> ralsina: I fixed the bug other than breaking the tests
[13:55] <ralsina> fagan: "scare the burgeois"
[13:55] <nessita> damn, is cool here!
[13:55] <fagan> ralsina: hah
[13:56] <dobey> i really don't like the 'version' property in NM
[13:56] <ralsina> What's scary is that I mistyped it in french
[13:56] <dobey> i mean, i like that it's there
[13:56] <fagan> dobey: well its kinda needed
[13:56] <dobey> but the fact that it's the version of NM itself, and not the API, is totally f'n broken
[13:57] <ralsina> dobey: version number comparison is one of those things that work based on good faith and pixie dust
[13:57] <ralsina> NM is not convinced it's a system service
[13:57] <dobey> NM is convinced it's a system service. and it's API is a "free desktop standard"
[13:58] <ralsina> dobey: that's their words talking. If their brains thought that, they would number APIs
[13:58] <nessita> fagan: did you fix your branch?
[13:58] <ralsina> as in "numbered standard versions" that some NM version implements
[13:58] <fagan> nessita: working on it did some reading first
[13:59] <fagan> nessita: will have it by the end of the day
[13:59] <nessita> fagan: nice!
[13:59] <fagan> im supprised it didnt take me longer to actually get a working version
[14:00] <alecu> STANDUP!!!!!!
[14:00] <alecu> me
[14:00] <fagan> me
[14:00] <nessita> me
[14:00] <thisfred> me
[14:00] <nessita> ralsina, dobey?
[14:00] <ralsina> me
[14:00] <nessita> ralsina: mandel is not coming, right?
[14:00] <dobey> meh
[14:00] <ralsina> mandel was here earlier but I don't know
[14:00] <nessita> alecu: go!
[14:00] <alecu> DONE: pushed fixed webclient branch; worked on devices tab branch
[14:00] <alecu> TODO: more fix for the webclient branch; push the devices tab; try to make the u1cp run on windows
[14:00] <alecu> BLOCKED: no
[14:00] <alecu> NOTE: tomorrow I'll be offline while travelling to london
[14:00] <alecu> LOVE: london on spring
[14:00] <alecu> HATE: travelling 13hs
[14:00] <alecu> NEXT! nessita
[14:00] <nessita> DONE: done listing and browsing of cloud folders, reviews
[14:00] <nessita> TODO: provide subscription functionality, reviews
[14:00] <nessita> BLOCKED: nopes
[14:00] <nessita> NEXT: fagan
[14:00] <nessita> NOTES: I will be taking an longer slot for lunch today (1.5 hr instead of the usual 0.5)
[14:00] <fagan> DONE
[14:00] <fagan> * Fixed the nm bug in my branch but was missing tests
[14:00] <fagan> * read up on mocker
[14:01] <fagan> Blocked
[14:01] <fagan> * nope
[14:01] <fagan> next thisfred ?
[14:01] <thisfred> DONE: Bug #665024 (packaged new erlang and put it in nightlies)
[14:01] <thisfred> TODO: See if ^ solves the bug, and if so, start SRU process
[14:01] <thisfred> BLOCKED: No
[14:01] <thisfred> NEXT: nessita
[14:01] <ubot4`> Launchpad bug 665024 in erlang (Ubuntu) (and 3 other projects) "Desktopcouch doesn't replicate with json_encode error 500 (affects: 9) (dups: 2) (heat: 52)" [High,Confirmed] https://launchpad.net/bugs/665024
[14:01] <thisfred> eh, next: dobey, I guess
[14:01] <nessita> nopes, ralsina
[14:01] <nessita> :-)
[14:01] <ralsina> DONE: not a lot yet, complicated day :-( some reviews, updating installer screens with current texts
[14:01] <thisfred> well, we're not really following the order anyway ;)
[14:01] <ralsina> TODO: finish that, reviews, talk to lots of people, ping design, etc
[14:01] <ralsina> BLOCKED: by my stomach, don't ask
[14:02] <ralsina> dobey?
[14:02] <fagan> ewww
[14:02] <dobey> we take it in turn, to act as sort of governer for the week?
[14:02] <dobey> λ DONE: bug #789299 (part 2)
[14:02] <dobey> λ TODO: bug #789300, bug #771488, expenses
[14:02] <ubot4`> Launchpad bug 789299 in ubuntuone-dev-tools "DBusTestCase sometimes connects to real session bus (affects: 1) (heat: 6)" [Critical,Fix committed] https://launchpad.net/bugs/789299
[14:02] <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:02] <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:02] <nessita> ralsina: are you taking tomorrow off like you suggested you might?
[14:03]  * fagan gets onto that bug 
[14:04] <ralsina> nessita: probably not
[14:05] <mandel> sorry, went for kunch
[14:05] <mandel> lunch*
[14:05] <fagan> kunch is a lot nicer than lunch
[14:06] <nessita> mandel: go!
[14:06] <fagan> karate + lunch > all other forms of eating
[14:06] <mandel> DONE: Fixed ling issues in creds branch. Updated correct reactor usage for control panel. Started working on getting the UI to run on Windows.
[14:06] <mandel> TODO: Some more control panel.
[14:07] <mandel> BLOCKED: no, but have some personal stuff bothering me later...
[14:08] <nessita> mandel: question, is there any plan on communicating syncdaemon with the control panel? I'm not sure if that's what you're working on from your standup DONE :-)
[14:08] <nessita> oops
[14:08] <nessita> bye mandel
[14:09] <ralsina> welcome back mandel :-)
[14:09] <ralsina> Those second-world internet connections... tsk tsk ;-)
[14:09] <mandel> ralsina: sorry I went or lunch and forgot to check the watch
[14:12] <nessita> mandel: question, is there any plan on communicating syncdaemon with the control panel? I'm not sure if that's what you're working on from your standup DONE :-)
[14:12] <mandel> nessita: working on it
[14:12] <nessita> mandel: AWESOME
[14:12] <mandel> nessita: I need to create a sdtool so that we can reuse most of the code
[14:13] <nessita> mandel: let me know if you need assistance with that, is extremely similar to the CredentialsManagementTool
[14:13] <mandel> ok
[14:16] <alecu> nessita, pushed fixes on https://code.launchpad.net/~alecu/ubuntuone-control-panel/tx-web-client/+merge/62889
[14:16] <nessita> on it!
[14:27] <fagan> Hmmmmm the logic for that version check is a little tricky
[14:28] <fagan> oh it would be easier to check if its lower than the version
[14:29] <ralsina> fagan: which version numbers are involved?
[14:30] <nessita> dobey: so, I don't wanna be a party pooper but I'm still getting
[14:30] <nessita>     self.assertNotEqual(name, dbus.bus.REQUEST_NAME_REPLY_EXISTS)
[14:30] <nessita> twisted.trial.unittest.FailTest: dbus.UInt32(3L) == 3
[14:30] <nessita> when running -qt tests in the control panel. I'm running u1-dev-tools 0.1.3+r34-10~natty1
[14:30] <fagan> ralsina: well I asked and its supposed to be anything below 0.8.99*
[14:30] <fagan> ralsina: ill check whats in natty too
[14:31]  * alecu gets the REQUEST_NAME_REPLY_EXISTS too
[14:31] <ralsina> There *is* a distutils.version that you can use to compare those things but I am not sure we want to have that as a dependency
[14:31] <ralsina> fagan: 0.8.99????? why not make the new API 0.9? Blargh.
[14:31] <fagan> ralsina: yeah thats why I was confused for a time yesterday on how to do it
[14:32] <fagan> if it was 0.9+ I would have just went string.split(".") and went if version[1]>8
[14:32] <ralsina> fagan: no, that fails for 1.0
[14:33] <ralsina> you *always* need to check all parts, left to right
[14:33] <ralsina> it's just that this way you need to check three instead of 2 ;-)
[14:33] <fagan> ralsina: good point
[14:33] <nessita> alecu: is the 39% in use faked or real?
[14:33] <nessita> "39% in use"
[14:34] <alecu> nessita, faked
[14:34] <ralsina> also, when you split, keep in mind that you may have 2 or 3 parts in the version. It's not trivial, but you can do it ;-)
[14:34] <alecu> ralsina, fagan: compare tuples
[14:34] <nessita> alecu: ah, makes sense now
[14:34] <ralsina> alecu: better, split and zip()
[14:35] <nessita> alecu: approved!
[14:35] <alecu> nessita, cool!!!! thanks
[14:35] <fagan> alecu: why would a tuple be more useful than a list in this case?
[14:35]  * fagan doesnt really see the big difference 
[14:36] <ralsina> fagan, check what you get by doing zip(version1.split('.'), version2.split('.'))
[14:36] <alecu> fagan, for this case, there's no difference between a tuple and a list. Usually it does.
[14:36] <ralsina> fagan: check the behaviour of the "<" operator between tuples.
[14:37] <ralsina> but yes a list is the same thing
[14:37] <ralsina> but split returns tuples
[14:37] <nessita> thisfred: hey there! are you arriving to heathrow?
[14:37] <thisfred> nessita: yep
[14:37] <nessita> thisfred: shall we get together to go to the hotel? I land at 10:05, and your flight lands at 9:35
[14:38] <nessita> thisfred: I will travel only with carry on, so I will not have luggage  time wait
[14:38] <fagan> ralsina: I always get confused between tuples and lists when that kind of thing comes into play
[14:38]  * fagan is arriving at standsted
[14:38] <thisfred> nessita: sure. I was thinking of taking the underground all the way. Do you have an oyster card?
[14:39] <dobey> nessita: huh
[14:39] <alecu> ralsina, I think split returns lists
[14:39] <nessita> thisfred: I do. Though beuno recommends heavily the heathrow express + underground. Last year I took only underground and it was a loooong trip (but completly doable)
[14:39] <nessita> dobey: yeah :-(
[14:40] <thisfred> ralsina: huh? I thought split returned lists
[14:40] <alecu> nessita, thisfred: +1 to the heathrow express.
[14:40] <nessita> karni: hey, you're arriving at 9:35 to Heathrow as well?
[14:41] <ralsina> thisfred: you are right! What was I thinking?
[14:41] <thisfred> nessita: well, it takes about an hour  the heathrow express shaves off maybe 20 minutes tops, considering that we'd have to get on the underground after anyway and change
[14:41] <alecu> ralsina, thinking about tuples?
[14:41] <ralsina> yes, take the express. It takes 15 minutes instead of 45
[14:41] <alecu> plus lovely views
[14:41] <nessita> thisfred: ^ that's what everybody says
[14:41] <thisfred> nessita: but ok, let's take the express :)
[14:41] <ralsina> thisfred: the express took about 15 minutes for me last month :-)
[14:41] <nessita> hehehe
[14:41] <dobey> hrmm
[14:42] <ralsina> thisfred: and has wifi. And coffee
[14:42] <nessita> thisfred: I never had it, so I wanted to try it to see why everyone is so in love with it
[14:42] <alecu> wifi!
[14:42] <ralsina> and coffee!
[14:42] <thisfred> nessita: I took it on the way back once when I was in a hurry
[14:42] <alecu> oh, btw: what simcard should I get while on london?
[14:42] <thisfred> nessita: where do you propose we meet?
[14:42] <ralsina> of course, if you convert the cost to pesos, you want a massage and a donut, too.
[14:42] <karni> nessita: 9:35, no idea where hahaha, I'm way to busy coding these days lol! :)
[14:42] <ralsina> alecu: I got a vodafone for 1 week with 500MB of data for 10 quid
[14:43] <karni> nessita: you too?
[14:43] <dobey> nessita: the error happens in cp trunk with --reactor=qt --gui?
[14:43] <alecu> ralsina, the kind of chocolate donut that usually comes included with massages?
[14:43] <nessita> karni: thisfred too, I'm arriving at 10:05, so I was proposing we can meet to go to the hotel together
[14:43] <nessita> thisfred: no idea, any suggestion?
[14:43] <nessita> dobey: ./run-tests -qt for me
[14:43] <ralsina> alecu: I don't know where you are getting your massages but I like the attitude ;-)
[14:44] <karni> nessita: thisfred: definitely!
[14:44] <nessita> thisfred: near the Heatrow express "door" (if such thing exists)
[14:44] <thisfred> nessita: which terminals are we arriving at?
[14:44] <nessita> thisfred: let me check mine
[14:44] <dobey> ok
[14:45] <nessita> thisfred, karni: I'm arriving to Terminal 3
[14:45] <alecu> ralsina, did you get that vodafone sim somewhere special? like a kiosk or some vodafone shop or something?
[14:45] <ralsina> OMFG, they are playing "Hasta siempre comandante" on the bar's speakers. That's just weird.
[14:45] <ralsina> alecu: vodafone shop
[14:45] <karni> nessita: thisfred: I'm terminal 1
[14:45] <alecu> cool
[14:45] <ralsina> alecu: they are everywhere
[14:45] <thisfred> nessita: I'm in terminal 5
[14:45] <nessita> bu!
[14:45] <thisfred> nessita: so we'd all have to get on at different stops
[14:45] <nessita> right
[14:46] <karni> nessita: I would use these 15 minutes to start travelling to terminal 3, if that's on the way to the hotel :D
[14:46] <thisfred> nessita: which makes it less practical
[14:46] <alecu> cool
[14:46] <nessita> yeah. Then maybe we can meet in the hotel
[14:46] <thisfred> nessita: those terminals are not close
[14:46] <karni> ok
[14:46]  * nessita drops friendly plans
[14:46] <karni> :(
[14:46]  * karni hugs nessita 
[14:46] <nessita> thisfred: right... I didn't consider terminals
[14:46]  * nessita hugs back, and cries
[14:47] <thisfred> nessita: yeah: I will check in and wait for you guys in the lobby, and we can go out and do something fun?
[14:47] <nessita> SHOPPING to LILLY WHITES
[14:47] <thisfred> fine by me :)
[14:47] <nessita> http://en.wikipedia.org/wiki/Lillywhites
[14:47] <thisfred> I need to get my wife a birthday present
[14:47] <thisfred> ah probably not from there :)
[14:47] <nessita> I'm hoping Lilly Whites is fulled with sales, I need tons of sport clothes
[14:48] <nessita> thisfred: well, we can go another places too
[14:48] <ralsina> you know, there is ONE express. You would at worst be on different cars and meet at the end
[14:48] <thisfred> but we can go on a shopping spree
[14:48] <thisfred> and maybe a museum
[14:48] <thisfred> Haven't been to the tate modern in a while
[14:49]  * thisfred will wait in the lobby for nessita and karni
[14:49] <karni> thisfred: nessita: cool :)
[14:49]  * nessita acks
[14:49] <thisfred> karni: I am tallish, very short hair.
[14:50]  * karni note to self: save nessita's and thisfred's mobile phones
[14:50] <karni> thisfred: hah! I'm the same :D
[14:50] <thisfred> mine won't work in the UK
[14:50] <thisfred> I'm sure we can pick out the geeks ;)
[14:50] <karni> thisfred: my pic is in the directory already, though I might be not shaved this time xD
[14:50] <karni> thisfred: heheheh
[14:50] <nessita> karni: I will have mine turned off, so don't bother
[14:50] <thisfred> same here
[14:50] <karni> hahahah you people :)
[14:50] <dobey> brb
[14:50]  * thisfred checks directory
[14:51] <nessita> brb
[14:52] <fagan> ok I think I have the logic
[14:52] <fagan> http://paste.ubuntu.com/616761/
[14:53] <fagan> but that is going by the presumption that they are going right for 0.9 after this release of nm
[14:54] <fagan> actually thats a little wrong too :/
[14:54] <ralsina> fagan: don't do it that way then ;-)
[14:55] <thisfred> != True is better written as not
[14:55] <ralsina> fagan: make a list of possible version numbers prior and later and see that your code works the right way with all of them.
[14:55] <ralsina> as in "and not foo.startswith(bar)"
[14:55] <thisfred> huh? "Your edit request has been forwarded to #ubuntu-irc.  Thank you for your attention to detail"
[14:55] <fagan> ralsina: yeah the logic is a little bit tricky
[14:56] <fagan> ralsina: oh and the != True is me just coming from C
[14:56] <ralsina> fagan: if it were easy, it would be done by computers.
[14:57] <dobey> wtf
[14:58] <fagan> ralsina: im going at it a little bit differently just to make it easier on myself
[14:58] <thisfred> fagan also you're still using < with strings, which does not do what you want
[14:58] <dobey> i guess freenode doesn't like our standup
[14:58] <karni> nessita: thisfred: I think it's a good idea to add the arrival terminal info on the wiki. Just added 'T1' in my row, so other ppl know.
[14:58] <dobey> sigh
[14:59] <fagan> thisfred: well I could go int(version[]) I suppose
[14:59] <ralsina> fagan: on what exactly are you going at it a little bit different? Not about trying it with different version numbers, I hope.
[14:59] <fagan> ralsina: no no im just doing the logic a little bit differently because of the weird numbers
[14:59] <fagan> ralsina: just changing to a nested if
[15:00] <ralsina> fagan: ok, if it makes more sense to you, that's fine
[15:00] <thisfred> fagan: NM uses these in their versions? http://en.wikipedia.org/wiki/Weird_number :P
[15:00] <fagan> thisfred: yeah
[15:00] <dobey> fagan: write a function which takes two strings as input, write several tests that pass different strings in, and check for appropriate output, that all fail; then make the tests pass by fixing the function
[15:00] <ralsina> thisfred: never heard of weird numbers before. I am way behind in discrete math, it seems :-)
[15:01] <ralsina> fagan: what dobey said
[15:05] <thisfred> anyone remember which days of UDS we had to buy our own dinner?
[15:05] <thisfred> tue - wed - thu ?
[15:05] <thisfred> I know it was 3
[15:07] <dobey> thisfred: yes, monday and friday were pre-arranged
[15:07] <thisfred> thx
[15:09] <fagan> ok now its good
[15:09] <fagan> im very sure of it
[15:09] <fagan> just going to test it now
[15:09] <dobey> man, qtreactor is full of broke
[15:10] <dobey> how the hell are we going to package it?
[15:11] <dobey> nessita: oh right; those tests weren't getting run otherwise. meh
[15:15] <dobey> sigh, something is killing stdout/stderr too
[15:15] <nessita> dobey: can I help?
[15:16] <fagan> ok fixed http://paste.ubuntu.com/616772/ and working
[15:16] <nessita> karni: I added mine too
[15:16] <fagan> now on to the tests if there isnt anything wrong with the way I did that there
[15:16] <ralsina> couldn't we just ship a private copy of qtreactor? It's a single file...
[15:16] <dobey> not sure; uno momento
[15:17] <dobey> ralsina: no; we should package it properly in ubuntu if we're goint to use it
[15:17] <ralsina> fagan: what happens with 0.5
[15:17] <fagan> ralsina: it works because it is auto false
[15:17] <fagan> ralsina: I tried out a few different values in the python shell and it worked ok
[15:18] <ralsina> fagan: you don't seem to be getting the idea of automated testing
[15:18] <mandel> ralsina: I'm leaving for a couple of hours, will be back later
[15:18] <mandel> !
[15:18] <fagan> ralsina: well I havent fixed the tests yet
[15:18] <ralsina> fagan: since you just "tried things on the shell" we don't see what you tried
[15:18] <karni> nessita: \m/
[15:19] <fagan> ralsina: ill fix them and then be able to say that its working fine
[15:19] <ralsina> fagan: nope
[15:19] <fagan> fix the tests then the logic?
[15:19] <ralsina> fagan: there are two parts to a god test. 1) it hould fail before the fix 2) it should work after the fix
[15:19] <ralsina> and hopefully, writing the code to fix it was step 1.5 ;-)
[15:20] <fagan> oh ok so then I should probably have run the tests a bit more and fixed them as I went along
[15:20] <ralsina> in this case, you should create a "check_nm_version function (or whatever) and you should write tests for it with different version numbers, and they all should be somewhere we can see them for review
[15:20] <fagan> ralsina: ok thats easy enough to do
[15:21] <dobey> ralsina: wouldn't a god test be a logical fallacy?
[15:21] <fagan> dobey: hahaha
[15:21] <ralsina> s/god/mohammed/ ;-)
[15:22] <fagan> dobey: isnt the god test throwing a rock into the air and if it hits you then god obviously was getting retaliation
[15:22] <ralsina> fagan: that way, you make sure your function works correctly. After that, you use it to fix the app code
[15:22]  * dobey hands fagan a rock to go throw up in the air
[15:23] <dobey> must be thrown directly vertical and you must not move
[15:23] <dobey> ralsina: why don't people listen to me? :)
[15:24] <ralsina> dobey: what? ;-)
[15:24] <dobey> writing tests :)
[15:25] <ralsina> what????! ;-)
[15:25] <ralsina> sorry, stupid joke ;-)
[15:25] <dobey> i think you need a hearing aid; you're getting old ;)
[15:25] <ralsina> dobey: yes, I can hardly hear what you type. Type louder! ;-)
[15:26] <dobey> heh
[15:26] <dobey> CLICK CLACK CLICK CLACK!
[15:26] <ralsina> Or, use a type M keyboard! ;-)
[15:28] <ralsina> ok, time for a short break to go back to the house. See you all in half an hour or so
[15:28] <dobey> ok wtf
[15:28] <dobey> i put sys.exit(1) inside a test
[15:28] <dobey> err, inside the setUp() even
[15:28] <dobey> and it doesn't exit!
[15:28] <nessita> ralsina: ack
[15:28] <dobey> and sys.stderr.write() isn't printing my message!
[15:28] <dobey> why are we using qt again? :(
[15:29] <nessita> dobey: I know your feeling
[15:29] <fagan> nice its working with the method
[15:29] <fagan> brb getting tea
[15:32] <dobey> fagan: if "the method" is that thing you pastebinned last, it's not working.
[15:33] <dobey> what the hell
[15:35] <dobey> oh
[15:35] <dobey> ffs
[15:35] <dobey> a) i'm an idiot
[15:37] <fagan> dobey: no no no I mean I made a method out of that code (that is working in 11.10 but not tested yet on 11.04)
[15:37] <dobey> b) twisted is the worst thing ever.
[15:38] <dobey> fagan: and i mean, if your method simply uses that check you use in that pastebin, it doesn't work; whether or not it appears to for you
[15:39] <fagan> dobey: well I fiddled with the logic again since but it does work
[15:40] <fagan> oh crap missed 1 little bit
[15:43] <dobey> "pass the tests fagan is doing by hand" != "work"
[15:43] <fagan> dobey: I forgot == 0 because im used to C where if its 0 its false
[15:44] <fagan> dobey: well I did debug it pretty heavily to make sure the logic was working as i should
[15:44] <fagan> (and just an intern and first proper development job and first branch to do...)
[15:57] <nessita> alecu: ping
[15:58] <alecu> nessita, pong
[15:58] <nessita> alecu: not sure how I miss this in the review, but when running trunk I'm getting an AttributeError from the account code your branch added: http://pastebin.ubuntu.com/616800/
[15:58] <alecu> let's see...
[15:59] <alecu> nessita, weird!
[15:59] <nessita> right!
[15:59] <nessita> maybe something wasn't merge? not sure
[15:59] <nessita> I'm re branching to see if it happens again
[16:00] <nessita> alecu: ah! maybe my build was old!
[16:00] <nessita> alecu: is very likely, I don't run build often there
[16:01] <nessita> alecu: yeap, my bad... sorry
[16:01] <alecu> nessita, oh, a missing ./setup.py build ?
[16:01] <nessita> alecu: yes :-( I'm not used to it
[16:01] <alecu> no prob :-)
[16:01] <nessita> I will get used to it...
[16:01] <alecu> nessita, me neither. It has already bitten me a few times.
[16:02] <dobey> well i *THOUGHT* i had this stuff working well enough
[16:02] <dobey> but twisted hath proved that wrong :(
[16:02] <alecu> nessita, I think the best solution is to have a script to run the cp that builds first.
[16:02] <nessita> alecu: not sure about that...
[16:02] <nessita> maybe? can't tell
[16:02] <nessita> dobey: shoot
[16:03] <dobey> exceptions.AttributeError: 'SSOClientTestCase' object has no attribute 'bus'
[16:03] <nessita> dobey: are you calling super for every single parent when dealing with multiple inheritance?
[16:03] <nessita> dobey: if you inherit from 2 classes, you need to call setUp for boths
[16:04] <nessita> (when you redefine a method)
[16:04] <nessita> if you don't redefine the method, first is called the setUP from the first parent class, then from the second, etc
[16:05] <dobey> there is no MI involved here
[16:07] <fagan> Hmmm I dont know how to fix the tests
[16:07] <nessita> dobey: you sure? SSOClientTestCase inherits from the DBusTestCase
[16:09] <fagan> ralsina: im almost done for the day so it looks like im not going to fix it before EOD. Would you mind setting aside a little time tomorrow to walk me through what I have to do for the tests and all that. I read up on mocker but still not in practice so im a little lost on what to do
[16:10] <dobey> hrmm
[16:11] <dobey> ok, needed a couple of yields
[16:11] <dobey> but now, other broken tests
[16:13] <dobey> nessita: http://pastebin.ubuntu.com/616814/ <- now getting these with ./run-tests -qt after my fixes
[16:14] <nessita> checking
[16:14] <dobey> http://pastebin.ubuntu.com/616816/ <- my current diff
[16:15] <nessita> dobey: that's very odd, "twisted.trial.unittest.FailTest: did not catch an error, instead got dbus.String(u'Ubuntu One')" means that we're explicitly testing for a error signal and we're not getting one
[16:15] <nessita> dobey: what did you change in your end?
[16:16] <nessita> dobey: smells like the faked dbus backend is not in place
[16:16] <dobey> nessita: maybe; but i'm surprised these tests were actually working at all :-/
[16:16] <nessita> dobey: why?
[16:17] <nessita> dobey: I have checked them and write some of them, as far as I remember they looked correct
[16:17] <dobey> nessita: i'm also getting some errors with just ./run-tests now too, about no .service file for SSO
[16:17] <nessita> dobey: that indicates that you're trying to run the real SSO, somehow?
[16:17] <nessita> dobey: what test suite are you running? ussoc or u1cp?
[16:18] <dobey> u1cp
[16:18] <nessita> dobey: what devtools branch are you running? so I can reproduce locally
[16:19] <dobey> nessita: installed nightlies is what i'm using
[16:19] <nessita> guh
[16:19] <nessita> dobey:did you do any modification to u1cp or is plain trunk?
[16:19] <dobey> nessita: the diff i pastebinned are the changes to u1cp
[16:19] <nessita> ah, missed that, looking
[16:21] <nessita> dobey: I'm finishing a branch up, as soon as I push it for review I'll grab that and work it out
[16:21] <dobey> ok
[16:22] <alecu> ralsina, are we meeting today?
[16:23] <ralsina> fagan: sure thing. I didn't expect it to take you less than 3 or 4 days ;-)
[16:24] <ralsina> alecu:  you mean the weekly team meeting? I am not really up to mumble from here (son taking nap)
[16:25] <alecu> ralsina, yes, the weekly team meeting... but it probably makes no sense since we are all meeting on monday anyway.
[16:26] <ralsina> alecu: yeah
[16:26] <ralsina> we'll start having them next week, I promise
[16:26] <fagan> ralsina: well im 90% sure I have the logic correct but the tests would make sure of that
[16:27] <fagan> ralsina: thats why id like to do it :)
[16:27] <ralsina> fagan: that's the whole idea :-)
[16:27] <fagan> ralsina: anyway ping me in the morning when you are free
[16:28] <fagan> ill take a look at it and see what I can do for the like half hour I have left
[16:28] <ralsina> fagan: ok, will do
[16:29] <fagan> cool
[16:34] <dobey> what a mess these imports are
[16:40] <karni> fagan: where do UDFs show up on Windows?
[16:40] <karni> fagan: in My documents directly?
[16:42] <fagan> karni: UDFs?
[16:42] <karni> fagan: User Defined Folder = Cloud folder
[16:42] <fagan> ah ok
[16:42] <dobey> karni: under the profile directory
[16:42] <karni> the obvious-obvious folder in the cloud ;)
[16:42] <fagan> karni: what dobey said
[16:42] <karni> dobey: thanks
[16:42] <dobey> karni: iow, under the home :)
[16:43] <karni> dobey: ack
[16:43] <karni> :)
[16:43]  * fagan hates some lingo 
[16:53] <dobey> bah i give up for now. i need to get lunch and do a couple things. bbiab
[17:00] <nessita> ok, lunchtime
[17:00] <nessita> I'll be back in 1.5 hrs
[17:00] <nessita> see ya later!
[17:20] <ralsina> eod for me, but will be back for a little while in about 4 hours
[17:35] <dobey> huh
[17:35] <dobey> so the more stuff i fix, the more stuff breaks :(
[17:52] <dobey> sigh
[18:01] <thisfred> dobey: any thoughts on bug #791927 ? As in, how do I fix that? Fiddle with setup.py?
[18:01] <ubot4`> Launchpad bug 791927 in desktopcouch (Ubuntu) "apport hook in source package not installed (affects: 1) (heat: 6)" [Medium,New] https://launchpad.net/bugs/791927
[18:04] <dobey> uhm
[18:04]  * dobey looks
[18:07] <dobey> ugh, the desktopcouch setup.py needs a lot of love, but yes you need to tweak the setup.py for that
[18:07] <thisfred> ok
[18:08] <thisfred> I'll look at the other packages to see what it need
[18:08] <thisfred> s
[18:08] <nessita> well, lunch was shorter than expected :-)
[18:08]  * nessita is back
[18:08] <dobey> thisfred: btw, does the hackers couchdb-bin result in 400 errors for oauth?
[18:09] <thisfred> dobey eh, not sure, in what situation?
[18:09] <dobey> thisfred: basically all the data_files bits that use "/usr/share/..." need to not start with "/usr/" but just be "share/..."
[18:09] <thisfred> kk
[18:09] <dobey> thisfred: well, chad's branch didn't land because the tests failed with lots of 400 errors
[18:10] <thisfred> I'll run the tests here
[18:10] <thisfred> dobey: ah oh I remember, there's a couchdb setting that has to be changed if you use the hackers couchdb:
[18:12] <dobey> where do i makes that change?
[18:12] <thisfred> [couch_httpd_oauth]
[18:12] <thisfred> use_user_db = false
[18:13] <thisfred> in /etc/couchdb/default.ini
[18:16] <dobey> thisfred: uhm; why don't we put that in the default.ini in desktopcouch?
[18:17] <thisfred> dobey: because it's a temporary work around (I think) for something we broke in the server version of couchdb. Bottom line, we should not be running this on the desktop
[18:17] <thisfred> But putting it in the local.ini/default.ini manually should also work, I think
[18:18] <thisfred> I mean in the ones that dc uses in ~/.local/share
[18:18] <dobey> well
[18:18] <dobey> it shouldn't be using that in tests
[18:19] <fagan> karni: did you see you and me are roomies for the week :)
[18:19] <karni> fagan: no I haven't, I'm a roomie with alecu in Londin AFAIK ?
[18:20] <karni> fagan: when?
[18:20] <dobey> thisfred: hrmm, the fact that tarmac user has a .local-share/desktop-couch/ is not a good sign :(
[18:22] <thisfred> hmm, yeah I thought all the tests talked to a couchdb instance in /tmp
[18:22] <alecu> karni, since I'm arriving a day earlier, marianna asked me to be ralsina's roommate, so we can share the room on saturday as well.
[18:22] <dobey> well it shouldn't be in /tmp either
[18:22] <dobey> it should all be inside ./_trial_temp/ really
[18:23] <thisfred> we made this before we used trial
[18:23] <thisfred> but yeah
[18:23] <karni> alecu: fagan: ah! you guys no more then I know \o/ :
[18:23] <karni> :)
[18:23] <dobey> well, we made unit tests before we had a sane test runner; and now everything is f'n breaking :(
[18:26] <fagan> karni: hah
[18:26]  * fagan didnt really mind who he rooms with
[18:29]  * alecu neither, but he wanted to take the chance to discuss android stuff with karni.
[18:29] <alecu> fagan, guess you'll have it now :-)
[18:30] <karni> alecu: we'll talk some about SSO in London, huh ? :)
[18:30] <alecu> karni, sure!
[18:31] <fagan> karni: I just had a weird vision of you and alecu cuddling and talking :D
[18:31] <karni> fagan: you're weird ;]
[18:31] <fagan> karni: yeah I little
[18:31] <alecu> fagan, click it off, dude!
[18:31] <fagan> :D
[18:32] <dobey> grr, apt is so braindead sometimes
[18:37] <fagan> dobey: make a replacement
[18:37] <fagan> :D
[18:38] <nessita> can I have a couple of reviews for https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/subscribe-folders/+merge/63266 ?
[18:38] <nessita> dobey: I'll start debugging the failures now. Where are you at with that?
[18:38] <karni> DanRabbit: man, really nice work with these icons!
[18:38] <DanRabbit> karni: thanks :)
[18:39] <karni> DanRabbit: now you can make more for all Libre Office extentions, MS Office extentions, PDFs, and... hahah j/k ;)
[18:40] <DanRabbit> karni: LOL, well I do have a few more mimes I can slide your way if you'd like them ;)
[18:40] <DanRabbit> karni: these are the new mime's I'm working on for elementary 4 (and of course proposed for Humanity when they're complete)
[18:40] <karni> DanRabbit: hahah, let's leave it for now, but keep these sources safe!
[18:40] <karni> :)
[18:41] <fagan> are we still calling it humanity?
[18:41] <thisfred> dobey: where should the file with the apport hook go? lib/desktopcouch?
[18:41]  * fagan thought the themes are called mono or something 
[18:42] <dobey> no
[18:42] <nessita> dobey: did you read my message?
[18:43] <dobey> thisfred: share/apport/package-hooks/
[18:43] <thisfred> ah
[18:43] <dobey> nessita: i didn't see it. sorry; i am in an abyss is where i am with it. :(
[18:43] <nessita> dobey: but, did your diff changes or can I start from there?
[18:44] <dobey> exceptions.AttributeError: 'ShutdownTestCase' object has no attribute 'backend'
[18:44] <dobey> nessita: i think i changed a couple more super() calls
[18:44] <dobey> nessita: let me paste a new one
[18:46] <dobey> nessita: actually i'll just push what i currently have
[18:46] <nessita> dobey: please, I'll go from there
[18:46] <nessita> dobey: even better
[18:47] <dobey> nessita: lp:~dobey/ubuntuone-control-panel/testing
[18:47] <nessita> dobey: ack, I'll be back with news!
[18:54] <thisfred> dobey: if i remove '/usr/' in desktopcouch, setup.py installs everything in /usr/local/lib/python2.7/dist-packages/desktopcouch-1.0.7-py2.7.egg/share/ which I don't think is right
[18:54] <thisfred> it needs the clever thing to put the prefix in right?
[18:54] <dobey> thisfred: because you didn't install with --prefix
[18:55] <dobey> hrmm, but shouldn't be in the egg, that is a bit weird
[18:55] <thisfred> dobey: well without prefix it should go to /usr/local/share, no?
[18:55] <dobey> i would think so
[18:55] <thisfred> not inside the egg, that will never work
[18:55] <dobey> but this /is/ python we're talking about
[18:55] <thisfred> I think we need to do the prefix substitution like we do in other packages
[18:56] <dobey> thisfred: http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntu-sso-client/trunk/view/head:/setup.py#L357
[18:56] <dobey> thisfred: that's basically how the data_files should look
[18:57] <dobey> thisfred: we don't do prefix substitution anywhere
[18:57] <thisfred> that's how it does look, and it doesn't work.
[18:58] <karni> can a UDF be renamed? do we support that?
[18:58] <dobey> thisfred: ok, well leave it for now and i can look at it more later. need to deal with the test stupidity, and then get the gnome3 compat issues fixed up so stuff will work on oneiric
[18:59] <dobey> karni: not sure; verterok, facundobatist, or lucio_ ^^?
[18:59] <verterok> karni: no, it can't be renamed
[18:59] <karni> verterok: \o/ thanks
[19:03] <thisfred> dobey: fixed it, we needed DistutilsExtra's setup, rather than the one from setuptools
[19:03] <dobey> that doesn't seem like a "fix" to me
[19:04] <dobey> anyway, whatever; this twisted stuff is killing me
[19:06] <thisfred> dobey well, that's what the file you pointed to does as well. setuptools.setup just doesn't do prefixes in this way. (so at all really)
[19:06] <dobey> yes, because sso needs stuff in distutilsextra
[19:07] <thisfred> dobey we have one hardcoded path left that puts something in /etc/
[19:07] <dobey> anyway, like i said. if it works it works; i'm more concerned about all the stuff not working for me
[19:07] <dobey> thisfred: yeah, the /etc/ has to be there i think
[19:07] <thisfred> right
[19:09] <thisfred> anyone care for a quick review? https://code.launchpad.net/~thisfred/desktopcouch/lp-791927/+merge/63271
[19:16] <tcole> thisfred: looks good in general; out of curiousity, what's the deal with the installation paths being changed from absolute to relative?
[19:19] <thisfred> tcole: this means we can install with a --prefix
[19:19] <thisfred> only works with distutilsextra's setup though
[19:20] <tcole> gotcha
[19:21] <tcole> +1
[19:24] <dobey> nessita: any luck yet?
[19:25] <nessita> dobey: I'm trying to fix all the u1cp tests to be, what I think is, correct
[19:25] <nessita> dobey: I'm getting tons of:
[19:25] <nessita>     len(self.bus.list_names()))
[19:25] <nessita> ubuntuone.devtools.testcase.InvalidSessionBus: Too many bus connections: 100
[19:25] <nessita> but I think we're not cleaning up the connection after being used, because the number increases by one after each test
[19:26] <nessita> so we're using the proper dbus but we're not cleaning up correctly
[19:27] <dobey> you are breaking stuff then
[19:27] <nessita> dobey: meaning?
[19:27] <dobey> well 100 is a lot; even when i was trying to make that check work correctly in devtools, i never got more than like 45 for the too many connections error, in u1cp tests
[19:28] <nessita> dobey: 100 is the amount of tests, I can show you the trace
[19:28] <dobey> so if it's at 100, it seems like maybe you're doing something that makes it connect to the live session bus
[19:28] <nessita> I don't think so, it grows by one after each test
[19:29] <dobey> grows by one just means that the connections aren't getting cleaned up. has nothing to do with which daemon it's connected to; does it start at 3 and grow by one all the way to 100?
[19:30] <nessita> checking that right now, but seems like it
[19:30] <dobey> FAILED (skips=1, errors=61, successes=14)
[19:30] <nessita> yeap
[19:30] <dobey> so those numbers do not add up to 100
[19:30] <dobey> err, nevermind
[19:30] <nessita> ...
[19:30] <dobey> that was me only testing one file
[19:31] <nessita> ;-)
[19:31] <dobey> how are you running the tests that you get 100 tests?
[19:31] <nessita> dobey: I think I can make some progress, or at least I will do some serious cleanup on u1cp tests
[19:31] <nessita> I've found several bugs already
[19:32] <dobey> well i am stuck at this:
[19:32] <dobey> exceptions.AttributeError: 'ShutdownTestCase' object has no attribute 'backend'
[19:33] <nessita> dobey: inside what folder/module?
[19:33] <dobey> which makes no sense to me
[19:33] <dobey> ubuntuone.controlpanel.integrationtests.test_dbus_service.ShutdownTestCase.test_shutdown
[19:33] <nessita> hum
[19:33] <nessita> sounds like... not sure
[19:34] <dobey> it seems like the BaseTestCase.setUp() is not being run, which would be weird
[19:34] <nessita> well, I'm also at the point where:
[19:34] <nessita> exceptions.AttributeError: 'OperationsErrorTestCase' object has no attribute 'backend'
[19:34] <nessita> :D
[19:36] <dobey> right same problem
[19:36] <dobey> but ShutDownTestCase only has one test, and it's at the end, so i was looking to try and fix it first (since fixing it would probably also mean the rest get fixed as well)
[19:37] <dobey> weird
[19:37] <dobey> so for some reason, setUp is not getting run
[19:37] <dobey>         yield super(ShutdownTestCase, self).setUp()
[19:38] <dobey> put that inside the test_shutdown(), and the error went away
[19:38] <nessita> dobey: look, I made the exception more verbose for the InvalidSession and I can tell that all those are test names ( and not the system ones) http://pastebin.ubuntu.com/616957/
[19:39] <dobey> tcole: ^^ have ANY idea why that would be? subclass without a setUp(), and the parent setUp() not being run at all?
[19:39] <dobey> nessita: ok, so you broke tearDown() chain somewhere, because i have not hit any of those yet
[19:39] <nessita> dobey: if you move stuff around and it suddendly starts to work, it means we're having timing issues. Very, very likely that a deferred that is not waited for in a setUp manages to finish when the test is executed
[19:39] <nessita> dobey: I added all the missing (I KNOW) inlineCallbacks
[19:40] <dobey> oh
[19:40] <dobey> do not do that
[19:40] <nessita> dobey: there is no point of yielding if we're not waiting for those deferred
[19:40] <dobey> yes there is
[19:40] <dobey> twisted is horribly awfully broken
[19:40] <nessita> dobey: having yield there is pointless without the inlineCallbacks
[19:40] <dobey> no it isn't
[19:40] <nessita> dobey: what do we gain having it?
[19:41] <dobey> nessita: forcing synchronous calling
[19:41] <nessita> dobey: no without the inlineCallbacks
[19:41] <dobey> nessita: yes, without the inlineCallbacks
[19:41] <nessita> dobey: how are you so sure? :-)
[19:42] <tcole> um, yield without the callbacks certainly is pointless
[19:42] <dobey> nessita: because twisted TestCase calls setUp asynchronously via deferreds internally, and causes lots of race conditions
[19:42] <tcole> inlineCallbacks consumes the output of the generator and actually waits for the callbacks
[19:42] <dobey> tcole: maybe if twisted wasn't broken, that would be true
[19:42] <tcole> if you just use yield without inlineCallbacks, then most of that function will never even get called
[19:42] <tcole> because nothing is consuming the generator
[19:43] <nessita> dobey: my point exactly
[19:43] <nessita> (what tcole says)
[19:43] <dobey> when can we get rid of twisted?
[19:43] <nessita> anyways, dobey, you can try moving forward with your way, I can try mine, and see where we are at in one hour~
[19:44] <nessita> I'm convinced we need to use yield+inlineCallbacks. If that breaks stuff, we need to fix our bugs! :-)
[19:44]  * nessita will try
[19:44] <dobey> nessita: well it doesn't matter, because you will never make it work with @inlineCallbacks on the setUp/tearDown
[19:44] <nessita> dobey: I'm amazed by your certainty... what makes you be so sure?
[19:45] <dobey> nessita: because i spent over a day just trying to make it work correctly for the 2 tests in devtools, and never got it working right.
[19:45] <nessita> dobey: so, using yield+inlineCallbacks in the devtools suite shows the issue?
[19:45] <dobey> which is why the DBusTestCase setUp/tearDown does not have inlineCallbacks, because twisted is horribly broken and doesn't work
[19:46] <dobey> nessita: yes, it causes pretty much all the tests in sso and cp to fail, because the stuff never gets called correctly
[19:46] <nessita> dobey: I switch to yield+inlineCallbacks on devtools and the suite runs fro devtools runs fine. Let me try u1cp :-)
[19:47] <tcole> twisted has some design problems, but we need to distinguish between what's actually broken and a lack of understanding of some aspects of python
[19:47] <dobey> nessita: yeah i think it works ok in devtools itself now because there are so few tests
[19:47] <tcole> and for that matter what's broken in the tests themselves
[19:47] <tcole> yeah, I'm not sure that devtools itself has adequate test coverage in this regard
[19:47] <nessita> dobey: I'll try, I think I can make it work. Using yield+inlineCallbacks on setUp/tearDown is what we did all along in u1client when I was in foundations
[19:48] <nessita> so I have some knowledge about this. Worst case scenario I get as frustrated as you got yesterday, and we cry together
[19:48] <dobey> nessita: but it doesn't mean it is correct, either; afaict, no matter what one does with twisted, it is wrong.
[19:48] <dobey> :(
[19:48] <nessita> dobey: that sentence will get you nowhere :-) cheer up!
[19:49] <tcole> nessita: there are, unfortunately, some issues with twisted's TestCase and MI, since it doesn't provide a "ground" implementation of setUp and tearDown that return deferreds :/
[19:50] <nessita> tcole: I read that yesterday, while you were talking about that... I still find that hard to understand since inside syncdaemon we've been doing that all along
[19:50] <tcole> I've been doing it myself, generally
[19:50] <nessita> right
[19:51] <tcole> anyway, if you d = super().setUp() and hit TestCase, the way it's written right now, you'll get None back
[19:51] <tcole> and not a deferred
[19:52] <tcole> I think the thing that has saved us so far is that most of our test case subclasses don't super() that far up
[19:52] <nessita> I see
[19:52] <nessita> well, maybe we can avoid supering all that way up...
[19:52] <tcole> which unfortunately is bad in the case where the nearest common ancestor is twisted's TestCase
[19:55] <tcole> nessita: the REALLY weird thing that we were seeing yesterday though was that super().setUp was itself None in some cases :(
[19:57] <dobey> tcole: no, it just returned None
[19:59] <tcole> mm, the error we were seeing was when we tried to call the result of super().setUp and it wasn't callable because it was None
[19:59] <tcole> (note the lack of () )
[19:59] <tcole> (I'm not talking about the result of super().setUp())
[19:59] <dobey> yes i am noting the lack of
[20:00] <dobey> and you are confusing the issue i think
[20:00] <tcole> maybe
[20:00] <tcole> I was getting pretty tired
[20:00] <dobey> the problem was that setUp() returned None (because it was plain synchronous unittest.TestCase.setUp())
[20:01] <tcole> there was that, too
[20:01] <dobey> the attribute itself was never None, because it just ended up pointing at that from the inheritance
[20:01] <tcole> hm
[20:02] <dobey> you made some example code that was based on the assumption that setUp itself was None; but it didn't actually work, since it wasn't None
[20:02] <tcole> ok
[20:02] <dobey> when i changed it to check the result instead of the attribute, there were still issues, though
[20:02] <dobey> the setup_dbus() bits never got called by the addBoth() for it
[20:03] <dobey> and i used addBoth just to test that it was ever getting called, whether from an error or not
[20:06] <dobey> but it never got called :(
[20:07] <tcole> the deferred returned by maybeDeferred wasn't firing for some reason
[20:08] <dobey> right
[20:11] <tcole> anyway, for today I guess I'll stick with a bug and a test case and a branch for twisted
[20:13] <nessita> dobey, tcole: what I've found out (and is the only issue for running tests so far) is that the self.bus.list_names() gets dirtier after each test, so I'm trying to a) fail in tearDown if self.bus.list_names is not the same than when the test startes b) find out what cleanup we're missing
[20:16] <nessita> in particular, we never call self.bus.release_name, which is a bug!
[20:16] <nessita> :-)
[20:16] <dobey> nessita: yes, because tearDown isn't getting called, or is just ending up as a deferred that doesn't block on the close()
[20:16] <dobey> nessita: you don't need to call release_name if you just drop the connection to the daemon
[20:16] <nessita> dobey: it is being called for me, every single time
[20:16] <nessita> I have a pdb in it
[20:16] <nessita> is being called, but the list_names() is not being cleaned up
[20:16] <dobey> nessita: the self.bus.flush()/self.bus.close() aren't
[20:16] <nessita> dobey: I can confirm they are
[20:17] <nessita> put prints in between
[20:17] <nessita> (as long as you have inlineCallbacks added, otherwise, of course they will not be called)
[20:17] <dobey> that makes absolutely no sense :)
[20:17] <nessita> aux contraire!
[20:17] <dobey> because it was working without the inlineCallbacks
[20:18] <dobey> otherwise that code wouldn't be in trunk
[20:18] <nessita> well, not really, we have the NAME_ALREADY EXISTS thing going on
[20:18] <nessita> if tests pass is a timing issue plus lucj
[20:18] <nessita> luck*
[20:18] <dobey> nessita: yes, because your tests are connecting to the wrong bus
[20:19] <nessita> dobey: let's discussed when I have the branch working or I'm totally frustrated :-)
[20:19] <nessita> discuss*
[20:19] <dobey> nessita: http://bazaar.launchpad.net/~dobey/ubuntuone-control-panel/testing/revision/157#ubuntuone/controlpanel/integrationtests/__init__.py
[20:20] <dobey> nessita: the code in register_mockserver() was why you were getting the NAME_EXISTS running under qt reactor
[20:20] <nessita> dobey: I did all those changes PLUS I added inlineCallbacks. There and in devtools
[20:20] <dobey> nessita: i told you this the other day
[20:21] <nessita> dobey: yeah, but if I fixed that the other day all the non-qt tests broke terribly
[20:21] <dobey> yes, because all the tests are terribly broken :)
[20:21] <nessita> so let's fix this where we should fix it!
[20:21]  * nessita fixes
[20:21] <dobey> which is why we're here now with all these problems :(
[20:22] <nessita> dobey: so, I already added those changes, they make sense. I added some more, I'll show you later, now I need some time to debug
[20:28] <dobey> thisfred: you know what is annoying
[20:28] <dobey> thisfred: the inconsistent usage of "desktopcouch" and "desktop-couch" inside desktopcouch
[20:30] <thisfred> agree
[20:30] <thisfred> me, I blame someone else
[20:31] <dobey> must be that eric guy
[20:31] <dobey> he can be such a pain to work with
[20:31] <thisfred> 'tis true
[20:31] <thateric> hey!
[20:34] <tcole> dobey: so, one mistake I made last night was that I was tired and misused maybeDeferred
[20:34] <tcole> should have been maybeDeferred(super(...).setUp) and not maybeDeferred(super(...).setUp())
[20:35] <dobey> well two days ago at this point, but hey :)
[20:36] <dobey> i don't think it matters though, and we'd still have the same issues
[20:36] <tcole> well, that was the source of my confusion about None anyway
[20:37] <tcole> using maybeDeferred correctly seems to address one of the problems at least
[20:38] <dobey> well it addresses the problem of getting a deferred to return, but inlineCallbacks does that too, right?
[20:38] <tcole> I thought inlineCallbacks used maybeDeferred, but apparently it doesn't
[20:39] <tcole> so we'd need to use it explicitly with or without inlineCallbacks+yield (versus addCallback)
[20:39] <dobey> ok, now i'm confused again
[20:42] <dobey> why would we need maybeDeferred with iC+yield?
[20:52] <tcole> Well, roughly speaking what inlineCallbacks does is something like this, to the generator that the wrapped function returns:
[20:52] <tcole> def chainCallback(gen):
[20:52] <tcole>     gen.next().addCallback(lambda _: chainCallback(gen))
[20:53] <tcole> i.e. it consumes a deferred from the generator, and adds a callback to it which consumes the next deferred and so on
[20:53] <tcole> but it IS expecting deferreds
[20:53] <tcole> whereas I'd erroneously thought that it did e.g. maybeDeferred(gen.next()).addCallback(...) instead of just gen.next().addCallback(...)
[20:55] <tcole> (does that make sense? to put it a different way, inlineCallbacks + yield works in two halves: a [generator] function that yields deferreds, and a decorator that consumes the deferreds and chains them together in sequence with addCallback)
[20:56] <dobey> so yield in an inlineCallbacks wrapped function, has to be on something that returns a deferred?
[20:57] <tcole> yeah, or more directly speaking the yielded value should be adeferred
[20:57] <dobey> so basically, yield is useless for doing what i thought it did
[20:57] <nessita> yes! :-)
[20:58] <dobey> well i can't help it if tcole explained it wrong to me :-/
[20:58] <nessita> dobey: sorry, seems like I failed to explain it too
[20:58] <nessita> anyways, I narrowed the problems to dbus only
[20:59] <tcole> at least I was able to explain it better this time
[20:59] <nessita> the list_names() grow and I can't understand why. Before creating a dbus service instance, the list names is:
[20:59] <nessita> dbus.Array([dbus.UTF8String('org.freedesktop.DBus'), dbus.UTF8String(':1.0')], signature=dbus.Signature('s'))
[20:59] <nessita> after creating a service for the cp, I have:
[20:59] <nessita> dbus.Array([dbus.UTF8String('org.freedesktop.DBus'), dbus.UTF8String(':1.0'), dbus.UTF8String(':1.1'), dbus.UTF8String('com.ubuntuone.controlpanel')], signature=dbus.Signature('s'))
[21:00] <dobey> right
[21:00] <nessita> but when I release the name and shutdown the service, the list_names count goes down to 3, not 2
[21:00] <nessita> result list_items is:
[21:00] <nessita> (dbus.Array([dbus.UTF8String('org.freedesktop.DBus'), dbus.UTF8String(':1.0'), dbus.UTF8String(':1.1')], signature=dbus.Signature('s')))
[21:00] <dobey> nessita: because there is still the client connection
[21:00] <nessita> :1:1 is the extra one
[21:00] <nessita> hum...
[21:00] <dobey> :1.1 is the client connection
[21:01] <nessita> dobey: good tip, I know where to go now
[21:02] <nessita> no wait, I don't :-D
[21:02] <nessita> dobey: how do I disconnect a client connection?
[21:02] <thisfred> doh. my laptop no longer boots
[21:03] <nessita> dobey: also, the list_names() grows from 2 to 4 before even connecting any client
[21:03] <dobey> nessita: the DBusTestCase does it
[21:03] <thisfred> ah there it goes
[21:03] <nessita> dobey: but the list_names() grows from 2 to 4 before even connecting any client, how do you explain that?
[21:03] <dobey> nessita: no it doesn't
[21:03] <nessita> dobey: yes, I'm testing it IRL...
[21:03] <nessita>     155     def __init__(self, backend, conn=None, object_path=None, bus_name=None):
[21:03] <nessita>     156         """Create this instance of the backend."""
[21:03] <nessita>     157         super(ControlPanelBackend, self).__init__(conn=conn,
[21:03] <nessita>     158                                                   object_path=object_padth,
[21:03] <nessita>     159                                                   bus_name=bus_name)
[21:03] <nessita>     160         print '\n-----------------', len(self.connection.list_names()),
[21:03] <dobey> nessita: how are you testing it?
[21:04] <nessita> that makes a print with the 4 connections
[21:04] <dobey> pastebin child :)
[21:04] <nessita> dobey: sorry
[21:04] <alecu> hey all, can I get reviews on this?
[21:04] <alecu> https://code.launchpad.net/~alecu/ubuntuone-control-panel/more-devices-tab/+merge/63292
[21:04] <nessita> dobey: right after calling be = dbus_service.publish_backend() inside test_dbus_service.py:BaseTestCase the list_names growns to 4
[21:05] <nessita> dobey: at that point there is no client whatsoever
[21:05] <dobey> i don't know what publish_bakend does exactly
[21:05] <dobey> but i guess it creates a connection to dbus, and then registers a name
[21:05] <nessita> dobey: it just creates an instance of ControlPanelBackend
[21:06] <nessita> dobey: http://pastebin.ubuntu.com/617013/
[21:06] <nessita> alecu: can I trade? https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/subscribe-folders/+merge/63266
[21:06] <alecu> nessita, ok, but I
[21:07] <alecu> nessita, ok, but I'll do it later
[21:07]  * alecu needs to go to pick Amelia right now.
[21:07] <alecu> cheers, all!
[21:07] <thisfred> nessita: I'll do it
[21:07] <nessita> thisfred: thanks!!!
[21:08] <dobey> well i'm sure ControlBackend() and ControlPanelBackend() connect to dbus?
[21:08] <dobey>     return dbus.service.BusName(DBUS_BUS_NAME, bus=dbus.SessionBus())
[21:08] <dobey> ugh, that is a problem
[21:08] <nessita> dobey: ControlBackend is dbus-agnostic, and ControlPanelBackend is a dbus service
[21:08] <nessita> dobey: so not sure if I understand your question, but no, they don't connect to dbus
[21:09] <dobey> nessita: yes ControlPanelBackend does
[21:09] <nessita> dobey: where?
[21:09] <dobey> nessita: get_busname(); the line i just pasted which is the only line in that function
[21:10] <nessita> dobey: ... get_busname() == connect to dbus? why?
[21:10] <nessita> maybe I don't know what you mean with "connect to dbus"
[21:10] <jdobrien> alecu, in your branch Does the term "Other devices connected to my cloud" refer to devices that are actually connected now?
[21:11] <jdobrien> alecu, I know those aren't your words, I'm just curious
[21:12] <dobey> nessita: dbus.SessionBus() == connect to dbus
[21:12] <nessita> dobey: the line  dbus.service.BusName(DBUS_BUS_NAME, bus=dbus.SessionBus()) generates a new connection bind to 'com.ubuntuone.controlpanel'
[21:13] <nessita> dobey: I've added prints before and after
[21:13] <dobey> nessita: prints that do what?
[21:13] <nessita> and before that call, the ':1.1' is already there
[21:13] <dobey> that code needs to be like this: http://pastebin.ubuntu.com/617022/
[21:13] <dobey> and the tests need to pass in the already existing bus connection
[21:14] <nessita> dobey: http://pastebin.ubuntu.com/617023/
[21:14] <nessita> anyways, that doesn't explain where the 1:1 conn comes from
[21:14] <nessita> I mean, seems like dbus.Session() is not an issue
[21:14] <dobey> well i don't know where it came from
[21:15] <dobey> it came from somewhere in the code whwere a bus connection is created
[21:15] <thisfred> from the print itself? Since that does dbus.SessionBus()
[21:15] <dobey> probably
[21:16] <nessita> thisfred: if I remove the print and list the list_names further in the code, the list is the same
[21:16] <nessita> the 1:1 appears
[21:16] <dobey> nessita: how are you listing the names?
[21:16] <dobey> nessita: are you doing self.bus.list_names() in the test? or are you doing dbus.SessionBus.list_names() somewhere again?
[21:17] <nessita> self.bus
[21:17] <thisfred> but not in the prints
[21:17] <thisfred> or am I stupid?
[21:17] <nessita> thisfred: yes in the prints inside tests
[21:18] <nessita> thisfred: the pastebin is not test code but "live" code
[21:18] <thisfred> ok
[21:19] <thisfred> fukfukfuk, I might not have a working laptop for the sprint
[21:19] <dobey> heh, did you install 11.10 on it?
[21:19] <thisfred> reinstall attempt 2
[21:19] <dobey> time to buy a new laptop?
[21:19] <thisfred> dobey I tried, stupidly
[21:20] <dobey> nessita: you should also print unique_name() if you really want to debug that; otherwise you can't tell which is you and which is others.
[21:21] <nessita> dobey: ok, I'll do that
[21:21] <dobey> nessita: which is another reason that bus needs passed in
[21:21] <nessita> using d-feet, both 1:0 and 1:1 are associated to python /home/nessita/canonical/u1/devtools/trunk/bin/u1trial -t test_dbus_service.ShutdownTestCase ubuntuone
[21:22] <nessita> which is... nosense?
[21:22] <dobey> nessita: right
[21:22] <dobey> no
[21:22] <dobey> one is probably created by DBusTestCase, and the other is probably a dbus.SessionBus() singleton that never gets closed
[21:22] <dobey> because you're calling SessionBus() when you shouldn't be :)
[21:23] <nessita> dobey: let me prove you or me wrong
[21:23]  * nessita adds anothe key print
[21:24] <nessita> dobey: YOU ARE RIGHT!
[21:24] <nessita> :-)
[21:25] <nessita> great, I know how to move on with this
[21:25] <nessita> dobey: thanks! I'll remove all the explicit calls to dbus.Session
[21:25] <nessita> passing the testing bus session around
[21:26] <dobey> :)
[21:48] <dobey> ok, am off for the evening. have a good one
[21:50] <tcole> you too
[22:23] <thisfred> nessita: hmm, I can't run DEBUG=True PYTHONPATH=. ./bin/ubuntuone-control-panel-qt
[22:23] <thisfred> it gives me an import error
[22:23] <nessita> thisfred: for qtreactor?
[22:24] <thisfred> no
[22:24] <thisfred> I have that
[22:24] <thisfred> Traceback (most recent call last):
[22:24] <thisfred>   File "./bin/ubuntuone-control-panel-qt", line 33, in <module>
[22:24] <thisfred>     from ubuntuone.controlpanel.gui.qt import main
[22:24] <thisfred> ImportError: No module named qt
[22:24] <nessita> did you run ./setup.py build?
[22:24] <thisfred> ah no, that's the missing step
[22:24] <nessita> also, is weird, that path is versioned
[22:25] <thisfred> nessita: after I ran that, I get the same though :(
[22:25] <nessita> thisfred: is weird,  ubuntuone.controlpanel.gui.qt is a versioned path
[22:25] <thisfred> what does that mean?
[22:25] <nessita> the QT dir is in the repo
[22:25] <nessita> ls -l ubuntuone/controlpanel/gui
[22:26] <thisfred> oh yeah the dir is there
[22:26] <thisfred> I suspect the import error is caused by something else
[22:26] <nessita> are the __init__.py files there?
[22:26] <thisfred> nessita: yep
[22:27] <nessita> you sure you're running PYTHONPATH=. ?
[22:27] <nessita> can you try:
[22:27] <nessita> PYTHONPATH=. python -c "from ubuntuone.controlpanel.gui.qt import main"
[22:28] <thisfred> nessita: DOH! typo in PYTHONPATH :)
[22:28] <nessita> ah!
[22:28] <nessita> well, the world is in place (still)
[22:31] <thisfred> nessita: so we have to do this through subprocess.Popen? Probably because we have no dbus on windows, I guess? But is there really no API we can use from sd?
[22:33] <nessita> thisfred: we do it from subprocess.Popen as a hack becasue qt + twisted reactor + dbus = seg Faults
[22:34] <nessita> thisfred: is a 110% ugly hack, the main part is building the QT ui
[22:34] <thisfred> nessita: ok, works for me :)
[22:34] <nessita> for me too! :-P)
[22:35] <thisfred> nessita: one more question: I really don't understand the reason for  @gui.defer.inlineCallbacks
[22:36] <nessita> instead of @defer.inlineCallbacks?
[22:36] <nessita> or why they are there at all?
[22:36] <thisfred> it's just getting t.i.d.inlineCallbacks
[22:36] <thisfred> the first
[22:36] <thisfred> do we monkey patch defer?
[22:36] <nessita> nopes
[22:37] <nessita> I just like to use the import from the module I'm testing
[22:37] <thisfred> no folders doesn't do anything with it
[22:37] <thisfred> Why?
[22:38] <nessita> from my POV, is cleaner. For example, if we change twisted deferred's for plain python deferreds, we just change that in the gui module
[22:38] <thisfred> This implies that it's some special version of defer, to me, so it makes the tests more mysterious
[22:38] <thisfred> I strongly disagree that it's cleaner
[22:38] <nessita> for me is like the implementation gets really hidden
[22:38] <thisfred> Your choosing programmer laziness over readability
[22:38] <nessita> through all my tests I always use: gui.os, gui.gtk, etc
[22:38] <thisfred> that is horrible
[22:39]  * alecu reviews nessita's branch
[22:39] <thisfred> IMO :)
[22:39]  * alecu does not like it either.
[22:39] <nessita> thisfred: I disagree, I find it cleaner. But I don't think we will reach an agreement here
[22:39] <nessita> I can remove the gui., no problem
[22:39] <nessita> I'll fix it soon, I'm trying to debug a dbus nightmare here
[22:40] <thisfred> please, other than that, it is great. (Also, renaming folders to gui I would not do, only do import as when there are name clashes)
[22:40] <thisfred> this all breaks the principle of least surprise
[22:40] <nessita> alecu: any idea why sig.remove(), where sig is the result of a proxy.connect_to_signal, is not removing the connection between the handler and the proxy from the dbus?
[22:41] <alecu> nessita, that sounds like a qtreactor+dbus issue
[22:41] <nessita> alecu: I'm running plain glib reactor :-(
[22:41] <alecu> :P
[22:41] <nessita> but, good guess! it made sense :-D
[22:42] <alecu> nessita, then no idea :-(
[22:42] <nessita> I know!
[22:42]  * nessita fixes
[22:43] <thisfred> also: independent of opinion on cleanliness: these things make refactoring harder. It's exactly like using relative imports
[22:43] <nessita> thisfred: from my POV, is the exact opposite. After actually doing several refactors, these things ease it. AT least in my experience :-)
[22:44] <thisfred> at least if we assume that our code changes more frequently than we switch between different libraries
[22:44] <nessita> which is not that true...
[22:44] <thisfred> I know we're going through big changes *now* but that's fairly atypical
[22:45] <thisfred> or at least I hope to god it is :)
[22:46] <thisfred> nessita: ok, have to walk the dog, ping me when a new version is pushed, and I'll approve in a bit
[22:46] <nessita> thisfred: thanks!
[22:48] <alecu> nessita, I'm following the dbus code and can't find a quick reason to give. There should be something wrong in the setup in order for the remove to not work.
[22:48] <nessita> alecu: yes, I found it
[22:48] <alecu> nessita, it even has a thread lock, so it does not looks too conspicuous.
[22:49] <nessita> alecu: we're mixing the real session bus with the test bus
[22:49] <alecu> nessita, oh, that.
[22:49] <nessita> I'm fixing that
[22:49] <nessita> (it will not be pretty)
[22:49] <alecu> nessita, how are we mixing it????
[22:49] <nessita> thisfred: pushed to revision 162.
[22:49] <nessita> alecu: by calling dbus.SessionBus() anywhere in live code or test code
[22:50] <thisfred> nessita: thx, rereviewing (waiting for the mail, and the dog thinks it's too hot anyway)
[22:50] <nessita> thisfred: lol
[22:50] <alecu> nessita, hmmm... but since we are setting the ENV with the value of our connection... the dbus.SessionBus() should use our test daemon, right?
[22:51] <nessita> seems like that is not happening
[22:51] <nessita> empiric prints and tests shows that is not happening
[22:52] <alecu> ok.
[22:56] <thisfred> science does not lie
[22:56] <nessita> :-D
[23:02] <alecu> nessita, approved.
[23:03] <nessita> thanks!
[23:03] <alecu> nessita, you didn't get to review my branch, right?
[23:03] <nessita> alecu: not yet, is in my ToDO
[23:03] <nessita> oh, but you leave tomorrow!
[23:04] <alecu> nessita, right. In fact, I'm going to fill my lugagge right now.
[23:04] <nessita> alecu: I will have to leave it for tomorrow, I need to run to a dinner...
[23:04]  * alecu will be back later.
[23:04] <nessita> I will tomorrow
[23:04] <alecu> nessita, no problem.
[23:05]  * alecu will be back later anyway.
[23:05] <nessita> ok
[23:05] <nessita> bye alecu
[23:05] <nessita> have a safe trip!
[23:06] <nessita> ok, gotta run
[23:06] <nessita> bye all!