[07:18] <mandel_> morning all!
[08:27] <rye> mornings
[08:42] <JamesTait> Good morning all! :-D
[09:38] <rye> compiz desaturated firefox window during high i/o and dimmed in. Upon i/o load drop it undimmed the window but forgot to draw colors
[09:38] <rye> now I have black and white firefox
[11:04] <gatox> good morning!
[12:09] <alecu> I think I forgot to say "hello" today.
[12:09] <alecu> there you go.
[12:09] <alecu> gatox: ping!
[12:10] <gatox> alecu, pong
[12:10] <gatox> and hello
[12:10] <alecu> hi gatox!
[12:10] <alecu> gatox, I heard that you were cursing twisted before leaving on friday...
[12:10] <alecu> gatox: is there anything I can give a hand on?
[12:11] <gatox> alecu, yes, i don't know exactly if the problem is twisted, i "finish" refactoring everything and now everything is working except the tests that involved: _perform_operations function..... which is exactly the same..... so i'm trying to figure that out
[12:11] <gatox> but i like to curse twisted :P jeje
[12:12] <alecu> gatox: if you want me to take a look, please give me an url to the branch.
[12:13] <gatox> alecu, ok, just a sec..... i'll upload my changes
[12:16] <gatox> alecu, here: https://code.launchpad.net/~diegosarmentero/ubuntuone-client/darwin4-fsevents
[12:17] <gatox> alecu, the problem is running tests/platform/filesystem_notifications/test_windows.py
[12:17] <gatox> alecu, but you can test it with u1trial and run just test_dir_create for example, which is one of the tests that fail
[12:18] <gatox> for what i see, it looks like that the event is not being generated.... so i'm debugging that
[12:20] <alecu> gatox: congrats on the release, btw!
[12:21] <gatox> alecu, thanks!! :D i truly believe that is an awesome version with really cool features!
[12:21] <alecu> gatox: and you are quite the salesman :-)
[12:21] <gatox> alecu, jejejeje
[12:21] <gatox> passion
[12:34] <ralsina> good morning!
[12:34] <gatox> ralsina, hi
[12:35] <mandel_> gatox, hello :)
[12:35] <mandel_> gatox, you own me reviews :P
[12:35] <gatox> mandel_, hi.... looking....
[12:36] <mandel_> gatox, hehe
[12:36] <mandel_> gatox, how was fgirday?
[12:36] <ralsina> y felicitaciones mias tambien  gatox!
[12:36] <mandel_> uh, friday?
[12:36] <mandel_> ralsina, what? what?
[12:36] <mandel_> ralsina, why 'felicitations'?
[12:36] <ralsina> mandel_: Ninja release
[12:37] <mandel_> ralsina, ohh gatox kudos!
[12:37] <gatox> ralsina, gracias! :D
[12:37] <gatox> mandel_, thx!
[12:37] <mandel_> gatox, does it have vim support yet?
[12:37] <mandel_> :P
[12:37] <gatox> mandel_, friday wass lot of tests refactoring.... and asking for tests in reviews (like a bad ass)
[12:37] <gatox> jeeje
[12:37] <gatox> mandel_, ¬¬ jeje
[12:38] <mandel_> ralsina, did we get something to try on friday? package or something of the kind
[12:38] <ralsina> mandel_: not before I EODd
[12:38] <ralsina> mandel_: we'll have to wait for mmcc
[12:39] <mandel_> ralsina, we need to talk about the fart that the shebang does not longer uses the env python but the one from /usr/bin/python
[12:39] <ralsina> mandel_: hope that was "fact"
[12:39] <mandel_> ralsina, which means that right now we cannot launch the diff processes correctly from trunk if you followed the instructs to set the machine
[12:39] <mandel_> ralsina, yes, sorry, stupid autocomplete from mac os x...
[12:39] <ralsina> mandel_: that was because of ubuntu packaging guidelines
[12:40] <mandel_> ralsina, but fart sounds funny enough :P
[12:40] <ralsina> mandel_: so, the only alternative I can think of is to patch the shebang on install, which is fragile
[12:40] <mandel_> ralsina, yes, I wonder how are we suppose to deal with that with py2app
[12:40] <ralsina> mandel_: patching it before packaging?
[12:41] <mandel_> ralsina, I was thinking of making the code that creates the new process to call it with the correct python directly
[12:41] <mandel_> ralsina, like, python ubuntu-sso-login instead of ubuntu-sso-login
[12:41] <ralsina> mandel_: why not. On windows brian had once done something like it IIRC
[12:41] <ralsina> patching the command line to insert a python
[12:42] <mandel_> ralsina, seems like a little nicer that patching the shebang al time, right?
[12:42] <ralsina> mandel_: also, after py2app that doesn't matter because we have .app files that don't have a shebang, right?
[12:42] <ralsina> mandel_: also, objectives
[12:43] <mandel_> ralsina, no idea, is something I wanted you to know while I'm not 'here'
[12:43] <ralsina> mandel_: haha
[12:43] <mandel_> ralsina, fuuuu objectives, I forgot!
[12:44] <alecu> gatox: perhaps I'm not looking right, but it seems that -4 is over 4k lines long...
[12:44] <gatox> looking.....
[12:44] <gatox> ohhhhhhhhhh god....... what happend here!!!!1
[12:45] <gatox> it tooks common as a new file..... i did bzr mv
[12:45] <mandel_> gatox, was it present in the previous branch?
[12:46] <mandel_> gatox, http://wiki.bazaar.canonical.com/BzrPipeline
[12:46] <gatox> mandel_, no.... but and in this branch i did a bzr mv to that file
[12:46] <gatox> alecu, i'll try to revert and do a bzr mv again
[12:46] <mandel_> gatox, so if it was not present in the previous file it makes sense that the mv is like a new file
[12:47] <mandel_> gatox, try bzr diff --old lp:gatox-darwin-3-branch
[12:49] <gatox> mandel_, but bzr mv, does a rename, so you don't see this kind of changes, i've use it a lot of times
[12:49] <gatox> alecu, i'll try to fix the tests first.... and then fight with bzr
[12:53] <mandel_> gatox, yes, unless the file was not present, that is, bzr add and later bzr mv is a simple bzr add in the diff
[12:53] <mandel_> gatox, that is why I'm saying it would be nice to know what bzr thinks it happened
[12:54] <gatox> mandel_, now it says just added.... so, i'll check doing add and the mv.... but i never did it that way..... :S
[12:54] <gatox> usually it works just with mv without the file being there
[12:54] <mandel_> gatox, well, maybe there was a problem in the merge
[12:55] <mandel_> gatox, lets hope you don't have to divide it again … :(
[12:55] <gatox> anyway..... i'm going to fix the tests that i don't know why they are failing.... and then clean up the diff
[12:57] <dobey> hmm
[13:03] <mandel_> gatox, alecu, let me know if you need reviews, I'll be 'available'
[13:03] <gatox> mandel_, wow... that pycon should be really boring jejeje
[13:04] <mandel_> gatox, no, is just that I like to code while I listen, also, I'm easily distracted :)
[13:12] <ralsina> mandel_: if you run into a guy called Kay Hayen, say I said hi
[13:12] <mandel_> ralsina, ok, will do
[13:28] <ralsina> Everyone, your objectives are approved, please countersign ASAP
[13:29] <gatox> ralsina, ack
[13:29] <alecu> ralsina: already done
[13:31] <dobey> ralsina: done. and disturbed by the grammar on the screen after doing so :)
[13:32] <ralsina> dobey: ha
[13:32] <ralsina> dobey: allhands is much nicer in the original klingon
[13:32] <dobey> "can't be anymore updated"
[13:32] <joshuahoover> ralsina: any update on bug #1017019? we have a workaround but do we have a new build in the works to fix this?
[13:33] <ralsina> joshuahoover: we have an updated installer uploaded already :-)
[13:33] <dobey> well, i /am/ using th_QS as my language
[13:33] <ralsina> joshuahoover: should just redownload (since if you have the problem by definition you can't autoupdate)
[13:34] <joshuahoover> ralsina: ok, the bug never showed any progress/status update, thus my question :)
[13:34] <ralsina> joshuahoover: adding a comment and marking fixed now
[13:34] <ralsina> joshuahoover: we tend to rely on launchpad to notice things and this was not done through launchpad ;-)
[13:34] <dobey> ralsina: does installing the new one actually remove the old un-needed files, or does uninstall happen first?
[13:35] <ralsina> dobey: ooooooh good question. It's supposed to uninstall first.
[13:35] <joshuahoover> dobey: good question
[13:35] <dobey> heh. i'm pretty sure lp will never notice things about windows :)
[13:35] <ralsina> dobey: but I don't think we actually *tried* it.
[13:35] <dobey> someone should try it :)
[13:50] <rye> alecu: do you happen to know if it is possible to find out whether SD is currently hashing something via some sort of api, not by peeking at the log file?
[13:52] <rye> joshuahoover: so, re: cpu usage/ecryptfs - ecryptfs access is itself slower than raw fs access but we are writing the compressed file to /tmp at the speed of disk (if the CPU is fast enough) thus preventing any other I/O. I am now compressing a 20Gb file and can only IRC only because I am on a remote server
[13:52] <joshuahoover> rye: ah, ok
[13:54] <ralsina> rye: would that be alleviated if we ionice'd and nice'd our processes?
[14:06] <rye> ralsina: ioniced to 2 (best effort) and it does not appear to change much, there are spikes in activity though, renicing to 19 makes the computer still be hot but no noticeable delays, so my machine is disk bound, if there is enough to write - all processes will wait until that gets written
[14:10] <dobey> rye: there should be events for hashing things in the event_queue which should be monitorable internally; and i think there's a way to get them over dbus as well, but enabling that will result in dbus getting flooded with sd events stuff, iirc
[14:11] <diogobaeder> Hi, guys, I'm new here. About the Windows installer, I'm not sure if this is what you needed, but I downloaded the installer from a Windows a VM and installed it successfully. No problems so far, files synced normally.
[14:12] <rye> diogobaeder: hello!
[14:12] <diogobaeder> rye: hi :-)
[14:12] <dobey> wow. my hard drives are surprisingly cool at the moment
[14:13] <rye> CPU is at +45, compressing the file
[14:13] <ralsina> diogobaeder: thanks, the thing is,we had a broken installer before. And welcome aboard :-)
[14:14] <diogobaeder> ralsina: nice, if it was broken, now it's not anymore. At least in Windows XP.
[14:16] <rye> joshuahoover: also, compressing 20Gb file took around 20 minutes, the user claimed that it took several hours, it looks like there is a real issue with the hard drive, nevermind
[14:16] <rye> ralsina: you deleted the .dlls ?
[14:17] <ralsina> rye: the new package doesn't have them
[14:17] <rye> yay
[14:17] <ralsina> rye: and when we build it again, it doesn't include them
[14:17] <ralsina> rye: so how they got there is a bit of a mistery
[14:18] <rye> ralsina: uhm, why is it required to uninstall the previous version before installing the new one?
[14:18] <dobey> brb
[14:34] <alecu> rye: btw: I can't find any current way to get the state of the hash queue only. Though I can see that "u1sdtool -w" waits for the hash queue to be clean (among a few other things, like all transfers done).
[14:36] <gatox> alecu, can you please take a look at this branch? https://code.launchpad.net/~diegosarmentero/ubuntuone-client/darwin3-fsevents/+merge/111666
[14:37] <gatox> alecu, i think i'm going to revert darwin4 (it hasn't any review yet), and merge carefully with what i did..... there's something really screw up with the last push
[14:38] <alecu> gatox: a revert sounds reasonable
[14:38] <alecu> gatox: make sure to set the MP status to "work in progress"
[14:38] <mmcc> hi guys
[14:39] <gatox> alecu, i was going to delete it..... it doesn't has any review
[14:39] <gatox> mmcc, hi
[14:39] <alecu> gatox: don't delete it, just set it to wip, then repush, then set to needs review again.
[14:39] <gatox> alecu, ack
[14:41] <mmcc> catching up on the backlog, looks like mandel was talking about the /bin/env thing - I fixed that in this mp: https://code.launchpad.net/~mikemc/ubuntu-sso-client/fix-1018924-use-buildout-python/+merge/112813 -- which just needs some discussion apparently
[14:43] <gatox> mmcc, hi..... i leave yesterday and you were fixing your branches.... are they ready for re-review?
[14:43] <mmcc> (that was the bit about using 'python' when launching subprocesses when running from trunk because they don't have 'env' in their shebang anymore)
[14:44] <mmcc> gatox, let me check. I have a lot of merges laying around...
[14:45] <mmcc> and gatox, dobey disagreed with your comment on https://code.launchpad.net/~mikemc/ubuntuone-client/fix-1018125-darwin-no-gireactor/+merge/112702 - instead of installing gireactor only for platform == 'linux2' , he liked it the original way
[14:45] <alecu> gatox: and by "yesterday" you probably meant "friday"
[14:45] <gatox> alecu, yes..... that :P
[14:46] <mmcc> gatox, yes I added the tests you suggested here: https://code.launchpad.net/~mikemc/ubuntu-sso-client/fix-992593-backend-path-darwin-pkgd/+merge/112709
[14:46] <gatox> mmcc, ok with the [darwin, win32]
[14:47] <mmcc> and as a bonus, made it do something saner when running from source on windows - use the sso client in the source tree not the installed one
[14:47] <dobey> mmcc: i also had a concern on your other branch
[14:48] <gatox> alecu, now darwing4 is 886 lines again jeej
[14:48] <mmcc> dobey, yes I'm looking at that now. I understand your comment, just thinking through how we'd make it independent again.
[14:49] <alecu> gatox: awesome
[14:49] <gatox> alecu, would it be too painful for you to review/merge this and do the refactor in the next branch? ..... i accept NO obviusly
[14:50] <alecu> gatox: in -3: what's the issue with "IN_MODIFY as in_modify"
[14:50] <gatox> alecu, flakes
[14:50] <alecu> gatox: how is it complaining?
[14:50] <alecu> gatox: and why?
[14:52] <gatox> alecu, it says that IN_MODIFY is not being used, and it's right, but as we have windows and darwin, using common, and we have all the rest of the IN_SOMETHING in common, i though it would be best to have everything there, in other case, windows (for example), will need to use IN_CREATE for common (as the rest)..... except for IN_MODIFY which has to be imported locally.....
[14:52] <gatox> i can change it if you want, i just thought it would be best to have everything in one place
[14:53] <alecu> gatox: oh, I see.
[14:53] <gatox> alecu, what do you prefer?
[14:54] <alecu> gatox: this is a bit ugly... but after hearing the issue, it seems like a good solution.
[14:54] <gatox> alecu, yes.... that the thing with flakes, that we can't ignore issues
[14:55] <alecu> yup, I hate that. But not as much as I hate pylint :-)
[14:55] <gatox> jejej agree
[14:55] <gatox> alecu, i'll try to send a patch to pyflakes for that.... i already fix that in ninja
[14:56] <alecu> gatox: is this fixed in -4 ?
[14:56] <alecu> # TODO: Implement this decorators to fix some encoding issues in darwin
[14:56] <mmcc> dobey - now that I'm looking, get_activation_cmdline in SSO is called from platform.ipc in client, but it really doesn't need to be. it just uses it to get a path that it uses to create an ActivationConfig, which takes the cmdline as a param. So I can move the part of get_activation_cmdline that needs to know about client into client and make the SSO branch independent again pretty cleanly
[14:56] <mmcc> s/platform.ipc/platform.ipc.perspective_broker/
[14:57] <gatox> alecu, oh yes.... i always forgot about that... i thought mandel was working on that... but i don't remember his answer.....
[14:57] <gatox> we already had this conversation
[14:57] <gatox> but i can't remember the outcome
[14:58] <dobey> mmcc: right, i wasn't sure why you put that stuff in sso. thanks :)
[14:58] <alecu> gatox: I can't either. Two days of weekend is too much!
[14:58] <alecu> gatox: let's shorten it!
[14:59] <gatox> alecu, jejeje agree.... i keep coding during the weekend, so it doesn't feel to much like a weekend :P
[14:59] <gatox> alecu, i'll ask mandel via pm on twitter
[14:59] <mmcc> dobey, I didn't put it in there, I just updated it without thinking too hard about where it should be :)
[15:00] <dobey> potato, buffalo. :)
[15:00] <gatox> me
[15:00] <briancurtin> standup?
[15:00] <briancurtin> me
[15:00] <mmcc> ralsina, any significance to the fact that my objectives were in reverse order upon review? :)
[15:01] <dobey> me
[15:01] <dobey> mmcc: they're probably in date-due order. so if you set different dates due, then that could be why
[15:01] <mmcc> me
[15:02] <alecu> mmcc: mine got .reversed() too
[15:03] <alecu> mmcc: so it's probably the allhands site doing it's funky thing.
[15:03] <mmcc> I figured it was a hard-coded philosophical imperative to reconsider the order of my priorities
[15:03] <thisfred> me
[15:03] <rye> tomdroid seems not to like our datetime format now :-/
[15:04] <alecu> me
[15:04] <ralsina> mmcc: nah
[15:04] <ralsina> mmcc: allhands just trains us to expect the unexpected
[15:05] <ralsina> mmcc: like, objectives from people who don't work for me, or objectives from years before I joined the company appearing in my task list
[15:05] <mmcc> ralsina: nice!
[15:05] <gatox> standup?
[15:05] <gatox> shall i start?
[15:07] <alecu> gatox: you shall
[15:07] <gatox> DONE:
[15:07] <gatox> Reviews, and refactor (this is taking so long!), revert a branch because of some merging problems.
[15:07] <gatox> TODO:
[15:07] <gatox> Apply again for the tests refactoring.
[15:07] <gatox> BLOCKED:
[15:07] <gatox> No
[15:07] <gatox> briancurtin, go
[15:07] <briancurtin> DONE: finished the first of what will be several unicode branches
[15:07] <briancurtin> TODO: look at the StringIO branch for dobey's comments, propose the first unicode branch
[15:07] <briancurtin> BLOCKED: none
[15:07] <briancurtin> NOTE: i'm only here today and tomorrow. US holiday on wednesday, personal holiday the rest of the week through monday
[15:07] <briancurtin> NEXT: dobey
[15:07] <dobey> DONE: objectives, sso 3.0.2 SRU, reviews
[15:07] <dobey> TODO: finish 3.0.2 SRUs, poke at some bugs
[15:07] <dobey> BLCK: None.
[15:07] <dobey> mmcc: gord
[15:07] <dobey> err, go
[15:07] <mmcc>  DONE: dev path fixes, packaging fixes, tests, lotsa branches
[15:07] <mmcc>  TODO: tweak path fixes, land fixes, send a .app to ralsina for real this time
[15:07] <mmcc> BLOCK: no
[15:07] <mmcc>  NEXT: thisfred
[15:07] <thisfred> DONE: objectives, bug #999029, bug #999562 TODO: bug #1019333, keep dogs from killing one another BLOCKED: no NEXT: alecu
[15:07] <alecu> DONE: objectives, reviews, some py3k reading, played around with t3k
[15:07] <alecu> TODO: techleads mumble, reviews, more t3k
[15:07] <alecu> BLOCKED: no
[15:07] <alecu> *SPECIAL NOTE*: I'll be out from friday - tuesday
[15:07] <ralsina> me
[15:07] <alecu> NEXT: ralsina
[15:08] <gord> dobey: this is your three monthly reminder to stop trying to tab complete real words :P
[15:08] <alecu> btw, all: let's sing "happy happy, joy joy" for briancurtin
[15:08] <ralsina> DONE: cmake tweaking, some reviews, objectives discussions and reviews TODO: my own objectives, maybe, cmake tweaking, canonicaladmin, askubuntu, other stuff BLOCKED: no
[15:08] <alecu> briancurtin: 27 now?
[15:08] <briancurtin> 28
[15:08] <mmcc> SO OLD
[15:09] <thisfred> spring chicken
[15:09] <gatox> briancurtin, hey! happy birthday! :D
[15:09] <thisfred> happy birthday Brian
[15:09] <ralsina> briancurtin: you are so old, you couldn't be my son. Think about it.
[15:09] <gatox> BTW: i have the same special note than alecu! PyCamp! \o/
[15:09] <dobey> gord: i demand the feature! :)
[15:09] <briancurtin> haha, thanks all
[15:09] <alecu> I demand the future!
[15:09] <ralsina> I demand the facturas
[15:09] <ralsina> sorry, argentinian joke
[15:10]  * dobey got it
[15:10]  * mmcc googled it
[15:10] <thisfred> I demand the fracturas
[15:10] <ralsina> mmcc: http://lateral.netmanagers.com.ar/tr/es/weblog/posts/BB896.html
[15:11] <mmcc> ooh, that *does* sound good. I'll join ralsina in demanding some pastries
[15:11] <ralsina> mmcc: yes, facturas is either pastries or bills. I prefer pastries :-)
[15:11] <ralsina> One comment: if you haven't yet, please go to allhands again and countersign your objectives
[15:12] <ralsina> I have no way of knowing if you did, so consider this the first last and only reminder
[15:12] <thisfred> arghh, thunderbird will not stop reminding me of the standup
[15:12] <mmcc> thisfred, you need to actually stand up for it to stup
[15:12] <mmcc> stop
[15:12]  * thisfred tries
[15:13] <ralsina> at 11:50 I get a popup window, a chime from my phone and an email, and still I usually forget in the following 7 minutes
[15:13] <dobey> ralsina: second, last, and secondary?
[15:13] <ralsina> dobey: that too
[15:13] <thisfred> ralsina, that's why I moved it to 5 mins in advance, which is better
[15:13] <ralsina> thisfred: will try it
[15:14] <dobey> i just hope everyone else forgets it
[15:14] <ralsina> we could cancel friday standups since we have the long call on thursdays
[15:14] <ralsina> but I would feel like I forgot something all weekend
[15:14] <thisfred> The objective sheet can't be anymore updated
[15:15] <ralsina> thisfred: not can it
[15:15] <thisfred> which is to say: I countersigned
[15:15] <dobey> the standup can't be anymore stood up
[15:15] <mmcc> it is so updated, it can't be any more updated. completely updated
[15:15] <ralsina> dobey: you can't standup when you are standing, so yes
[15:15] <thisfred> allhand web ui developed by yoda, it is
[15:15] <ralsina> dobey: unless you have extra fold-out legs or something
[15:16] <mmcc> brb
[15:16] <ralsina> thisfred: yoda does the copy, curious george does the coding
[15:16] <dobey> ralsina: i can stand-up the standup. you know, in the "don't show up for your date" sense :)
[15:17] <ralsina> ok, that was our daily 5 minutes of weird, EOM
[15:24]  * briancurtin coffee, back in a few mins
[15:31]  * gatox lunch
[15:35] <dobey> alright, lunch and such. bbiab
[15:40]  * briancurtin back
[15:43] <mmcc> dobey, when you get back from the such, please revisit https://code.launchpad.net/~mikemc/ubuntuone-client/fix-1018125-darwin-no-gireactor/+merge/112702
[15:57] <ralsina> Oh fun another possible turkish locale bug.
[15:57] <ralsina> Ataturk Y you make locale strange?
[16:02] <rye> ralsina: 2012-06-28 13:42:40,690 - ubuntuone.SyncDaemon.Pb - WARNING - Could not emit signal 'on_status_changed' to <twisted.spread.pb.RemoteReference instance at 0x04357148> due to 'underlying C/C++ object has been deleted' - have you ever seen this?
[16:02] <ralsina> rye: nothing like it in a long time
[16:04] <ralsina> rye: in fact, I don't know how that would appear in the sd logs, do you have a matching exception on u1cp?
[16:06] <ralsina> alecu: can you take http://askubuntu.com/questions/156811/proxy-settings-for-ubuntu-one-on-windows please?
[16:06] <alecu> ralsina: sure
[16:08] <rye> ralsina: nope, does not look like control panel was up at that time
[16:08] <rye> ralsina: continuing poking...
[16:08] <ralsina> rye: then SSO, because that is a PyQt error :-)
[16:09] <mmcc> whoa, Qt built in only 64 minutes on this new macbook air
[16:10] <mmcc> brew still doesn't use bottles like it claims, :\ but, SSD good!
[16:12] <rye> ralsina: does SSO subscribe to on_status_changed ? o_O
[16:12] <ralsina> rye: shouldn't
[16:12] <ralsina> rye: but hey, those are our two Qt apps :-)
[16:13] <rye> aha, pyqt... that narrows the search, but ralsina, why is that a syncdaemon's issue that it cannot emit the signal - fire and forget I thought....
[16:15] <rye> ugh
[16:16] <rye> beuno:  GetPublicFiles(running='False', _iri="u'https://one.ubuntu.com/files/api/public_files'") failure: ('Moved Permanently to https://media.one.ubuntu.com/offline.html', None) - i guess we will want to have a 302 redirect in case of maintenance, not permanent.
[16:16] <beuno> rye, yes, RT that
[16:25] <ralsina> rye: it's probably getting an exception and has a logging errback
[16:25] <ralsina> rye: so it's very pssible that this is not a problem at all
[16:25] <ralsina> rye: like "u1cp started, connected to the signal, crashed, syncdaemon gets an error"
[16:34] <gatox> alecu, i talked with mandel, he say i should do the decorator thing
[16:35] <alecu> gatox: in what branch will you be doing it?
[16:36] <gatox> alecu,  if you want i can remove the empty implementations of darwin3 and do it there.... or add it in a future branch
[16:36] <gatox> i need to take a look what each decorator involves and why they should be there
[16:39] <gatox> alecu, so? darwin3 or future?? (to know if i should return to darwin3 or keep working in the tests refactoring)
[17:05] <alecu> gatox: a future branch sounds fine.
[17:05] <gatox> alecu, ack
[17:17] <dobey> mmcc: approved
[17:27] <mmcc> arg, lots of code sharing, name sharing and comment sharing between invoking sso using credentials proxy and using ipc to invoke syncdaemon in u1-client
[17:29] <mmcc> separate code paths look similar but only actually share one function - get_activation_cmdline.
[17:29]  * mmcc is done complaining
[17:33] <alecu> gatox: ping
[17:33] <alecu> gatox: one last thing regarding -3
[17:33] <alecu> gatox: I remember that mandel sent you some tips on how to make some tests not need "time.sleep" anymore.
[17:34] <alecu> gatox: I saw that the branch has just the removal of the sleeps, but I can't find the code to wait on those events arriving.
[17:34] <alecu> gatox: am I missing something?
[17:34] <gatox> alecu, it was an unnecesary use of time.sleep
[17:36] <alecu> ok. I'll run the tests and approve.
[17:36] <gatox> alecu, great
[17:38]  * briancurtin lunch
[17:41] <mmcc> argh, can't test changes to ipc on darwin without a working filesystem_notifications :|
[17:41] <mmcc> that is, u1-client platform.ipc
[17:43] <dobey> sigh, i rebooted earlier and my audio is all screwed up again because the on-board sound isn't loading properly all the time for some reasaon
[17:45]  * ralsina lunches
[17:49] <dobey> and this raid enclosure is a bit more internally complex than i was expecting :-/
[17:58] <lduros> hello,  I have 4 songs that appear as "queued" for a good 30 minutes
[17:58] <lduros> that I just purchased
[17:58] <lduros> it doesn't look like there are any issue with the music store in the status
[17:59] <lduros> when I login from the web, I don't see those songs either
[18:05]  * briancurtin back
[18:08] <dobey> joshuahoover, rye: ^^ help lduros please?
[18:09] <lduros> dobey: thx :-)
[18:09] <joshuahoover> lduros: we're working on this right now...it's a server side issue...i just had an engineer look into it about 15 min. ago and it's getting fixed
[18:09] <lduros> joshuahoover: ok cool :-) Thanks for the update!! :-)
[18:23] <gatox> brb..... need to buy some cookiesssssss
[18:33] <gatox> back
[18:33] <mmcc> wondering why we are testing perspective_broker ipc on linux when we only use it for windows and darwin, and it used to be named 'windows'... I think the platform refactoring a while back missed some stuff...
[18:35] <dobey> mmcc: i think we should run tests for everything on every platform that we can
[18:35] <mmcc> it used to be skipped - it had been in the test/platform/windows/ subdir but got moved out into test/platform/tools/ , and so now it gets run on linux, which only worked because the cmdline code was in sso, not client
[18:36] <dobey> hmm
[18:36] <mmcc> dobey I can certainly test it on linux but I'd need to write code to help it find the executable for syncdaemon just so I can test that, which we'll never use
[18:37] <dobey> well, any skipping we do i think should also be done via @skipIf() decorators or such, rather than having them in files that we ignore on some platforms
[18:37] <dobey> having the N different ways to run tests is annoying
[18:37] <mmcc> yes
[18:40] <elopio> hey desktop team.
[18:40] <elopio> any idea what this could mean? ubuntuone.controlpanel.qt.filesyncstatus - ERROR - on_sync_status_button_clicked: backend method is None!
[18:40] <mmcc> so I'll have to put skipIf(linux) on every method in test_tools, since you can only get a meaningful perpective_broker proxy for darwin and windows... ok
[18:46] <mmcc> back, my emacs died. having one of those days
[18:48] <elopio> hey mmcc. Why is this bug assigned to the windows installer? bug #1019142
[18:48] <mmcc> elopio, the windows installer is a temporarily misnamed project. we're using it to house both mac and windows packaging tools
[18:49] <mmcc> I think we're going to rename it but it's a low priority
[18:49] <elopio> mmcc: ah, got it.
[18:49] <dobey> yeah
[18:58] <mmcc> going to lunch now
[19:10] <alecu> gatox: I'm trying to run the tests for your branch, but it seems I'm missing some bits of u1-devtools, and the tests are not running right.
[19:10] <alecu> gatox: I'll take a better look later today, I need to run to kinder.
[19:15] <gatox> alecu, ok...... if you are using the buildout
[19:15] <gatox> alecu, you will probably need to update ubuntuone-dev-tools
[19:15] <gatox> in the eggs folder of the buildout
[19:15] <gatox> it happens to me sometimes
[20:13] <gatox> i'm off for today..... see you tomorrow
[20:22] <dobey> alecu: you might need a new buildout tree. i think briancurtin fixed it to use the trunk dev-tools now.
[20:22] <briancurtin> eh, buildout kind of sucks and i couldnt make that work
[20:23] <briancurtin> it works on the assumption that you deleted the ubuntuone_dev_tools egg from the eggs folder, then did a bzr branch of ubuntuone-dev-tools yourself and keep it up to date
[20:23] <mmcc> the way I've been making it work is to just have a branch of dev-tools trunk in parts/ and just setting PYTHONPATH
[20:23] <briancurtin> that would also work
[20:24] <dobey> ah
[20:24] <mmcc> it's not ideal but you can make forward progress
[20:25] <dobey> too bad we can't just ship updates to everyone in a PPA for that
[20:25] <mmcc> dobey, I suppose we could make a homebrew 'recipe' for dev-tools
[20:26] <dobey> well, that doesn't fix it on windows
[20:26] <mmcc> right
[20:26] <dobey> but yeah, it would be nice to have auto-updating magic for all the things
[20:30] <mmcc> well, homebrew isn't that. there's never going to be anything really nice for os x open source code
[20:33] <mmcc> so I want to just avoid running ipc/test_tools (tests perspective_broker) on linux - even skipping all its tests still means it imports perpective_broker, which would then have to have a dummy implementation of get_command_line for linux just so I could skip its tests... I don't like that, so I figure, skip the whole file from the makefile. anyone disagree? dobey?
[20:35] <mmcc> oh, never mind. it isn't that simple because of course there are two files named test_tools.py
[20:36] <dobey> hmm
[20:36] <dobey> are the tests specific to the pb ipc?
[20:37] <mmcc> yes, superficially at least - they create a perspective_broker.SyncDaemonToolProxy() in setUp
[20:38] <dobey> hmm
[20:38] <mmcc> but IIRC there are tests of linux SyncDaemonToolProxy. I wonder if they test the same thing
[20:38] <dobey> not sure
[20:40] <mmcc> boy, nothing will make you want to put your head through a wall faster than a crashy text editor
[20:40] <mmcc> I think bzr is giving emacs vc mode heartburn or something, wtf
[20:48] <mmcc> ok, yes they are specific to perspective_broker. they test internal methods not used anywhere else
[20:48] <mmcc> ^ answering dobey
[20:49] <dobey> ok
[20:49] <dobey> test_tools is probably the wrong name exactly then.
[20:49] <mmcc> yeah, I was thinking the same thing. I could rename it test_perspective_broker and that'd let me skip it from the makefile
[20:50] <mmcc> or - what if it was 'test_not_linux' so it runs on both win/darwin and the makefile only has to add one more filename to skip
[20:51] <mmcc> we're already ignoring files named test_windows and test_darwin, this is just test_windows_AND_darwing
[20:52] <dobey> darkwing_duck
[20:53] <mmcc> blast from the past
[20:56] <mmcc> ok, unless anyone yells at me in the next couple minutes I'm renaming tests/platform/tools/test_tools.py to test_not_linux.py and adding that a path to exclude that in the linux makefile, since it just tests perspective_broker, we don't use that on linux, and we'd have to add unused linux-specific code just to be able to run the tests on linux.
[20:58] <ralsina> mmcc: why not test_pb.py
[20:58] <ralsina> mmcc: not that I much care one way or the other, just want the filenames to be descriptive
[20:59] <thumper> morning
[20:59] <mmcc> ralsina: understood. the appeal of test_not_linux is that I add that exclusion once to the makefile and that file name might come in handy elsewhere for things that are mac+win only.
[20:59] <thumper> who looks after file sync these days?
[20:59] <mmcc> ralsina: I'd say the full path to the filename is as descriptive as the test_darwin and test_windows that are already there
[21:00] <mmcc> ralsina: tests/platform/tools/test_$platform
[21:00] <ralsina> mmcc: I say go ahead then
[21:00] <mmcc> ralsina: ok, done
[21:00] <ralsina> and I am exiting stage left, will be back later for a little bit
[21:02] <thumper> beuno: how's things?
[21:03] <mmcc> waaaitaminit - there was already a function over in platform.tools.darwin to get the path to syncdaemon - so why was platform.ipc using the function from sso !?
[21:03] <mmcc> arg
[21:07] <dobey> mmcc: further down the spiral?
[21:08] <ralsina> mmcc: we had a bit of organic growth in that area
[21:08] <mmcc> dobey, so it goes
[21:10] <mmcc> "organic growth" : http://www.roofrepair.net/layout/roofrepair/userFiles/images/left-black-mold.jpg
[21:10] <mmcc> But I kid. btw, DO NOT google for images of black mold
[21:13] <thumper> oh, why not...
[21:13]  * thumper is tempted
[21:13] <ralsina> black mold... good name for a metal band
[21:14] <diogobaeder> or a computer virus :-P
[21:14] <ralsina> Black mold and their first single "don't google us!"
[21:14] <mmcc> thumper: apparently sometimes it looks like a swarm of snails. gets all 3-d off the wall and starts coming for you.
[21:14] <beuno> thumper, heya
[21:15] <thumper> beuno: do you know who looks after file sync?
[21:15] <thumper> beuno: my machine is having problems
[21:15] <thumper> beuno: and I'd like to help debug WTF is going on
[21:16] <dobey> thumper: what sort of problems?
[21:17] <thumper> dobey: it isn't syncing, and the U1 dialog shows "File Sync starting..." forever
[21:17] <thumper> beuno: btw, I have lots of space now, thanks :)
[21:17] <beuno> thumper, yeah, dobey  is your man
[21:18] <dobey> thumper: anything in ~/.cache/ubuntuone/log/syncdaemon-exceptions.log ?
[21:18] <thumper> yup
[21:18] <dobey> pastebin?
[21:18] <thumper> sure...
[21:20] <thumper> dobey: http://paste.ubuntu.com/1072047/
[21:20] <dobey> hmm
[21:21] <excelsior> So if I move one directory inside of another in my Ubuntu One Documents Directory, will UbuntuOne wind up with 2 copies of the files?
[21:22] <dobey> thumper: hrmm, seems like your metadata might be corrupt and syncdaemon isn't starting. there's probably a little more info in syncdaemon.log itself. should be reasonably obvious if it's exiting or not
[21:22] <dobey> excelsior: not if you move them; if i understand your question correctly
[21:24] <excelsior> ok, so the move will be reflected in UbuntuOne as a move as well, and it will not simply copy them?
[21:25] <thumper> dobey: well there are lots of events in the syncdaemon.log
[21:25] <excelsior> I just don't want to wind up with redundant files
[21:25] <thumper> dobey: recently just --mark entries
[21:25] <thumper> but nothing is syncing
[21:25] <dobey> excelsior: a move is a move, not a copy.
[21:26] <dobey> thumper: what does "u1sdtool -s" say the status is?
[21:26] <excelsior> ok, cool, I just guess I fundamentally don't understand how ubuntuone works. Is it based on any technology Unix guys already know about?
[21:27] <thumper> dobey: http://paste.ubuntu.com/1072055/
[21:28] <dobey> thumper: well it's not connected, so that explains the not syncing, and it probably won't connect because the metadata is corrupt and it keeps working on that
[21:28] <dobey> thumper: do u1sdtool -q and tell me if it keeps running, or stops after that
[21:29] <thumper> dobey: how do I know if it keeps running?
[21:30] <dobey> thumper: check "ps fx" output
[21:31] <dobey> "ps fx|grep ubu" even to limit it
[21:31] <thumper> dobey: seems like it has stopped
[21:32] <dobey> thumper: ok. while it isn't running do "mv ~/.local/share/ubuntuone/syncdaemon ~/.local/share/ubuntuone/syncdaemon.old"
[21:32] <dobey> thumper: then start it back up with u1sdtool -c
[21:33] <thumper> dobey: done
[21:34] <dobey> thumper: might take a few minutes for it it rescan everything, but it *should* start working now
[21:34] <thumper> dobey: ok thanks
[21:34] <thumper> I'll let you know :)
[21:39] <mmcc> Now I have a windows question. there seem to be two different registry keys that might be used to get the installed path to syncdaemon. one is in the sso client in ubuntu_sso/main/windows.py - it uses the key 'path-ubuntuone-syncdaemon', which exists on my machine (i've run tests but not installed U1 on there)
[21:39] <mmcc> the second is in u1client, platform/tools/windows.py, which uses the key 'SyncDaemonInstallPath', which doesn't seem to exist
[21:39] <mmcc> (on my system)
[21:40] <mmcc> which one is the right one?
[21:46] <dobey> no idea
[21:46] <dobey> the one that works, i would guess :)
[21:47] <dobey> hrmm, just need one more upvote on askubuntu today
[21:48] <mmcc> so -- currently, the one in sso is used in code that tests if we're running syncdaemon (but the command line it gives is ignored) and the one in u1client is actually used to launch the syncdaemon
[21:48] <mmcc> so the one that looks like it won't work on my system is the one that actually appears to need to work when installed :/
[21:49] <dobey> well, have you installed u1 on that system?
[21:49] <mmcc> no. so I guess when it's installed, the other key gets inserted
[21:49] <mmcc> but I couldn't find that string anywhere in the source
[21:49] <mmcc> in the tree, that is, I grepped everything
[21:50] <dobey> well, there shouldn't be any registry keys existing if it's not installed
[21:50] <mmcc> adding keys to the registry was part of the test setup
[21:50] <mmcc> which reminds me, I was going to make it so that wasn't necessary
[21:50] <dobey> eww
[21:50] <mmcc> as a side effect of this branch.
[21:51] <dobey> tests shouldn't do anything outside the branch
[21:51] <mmcc> this epic spelunk
[21:51] <dobey> heh
[21:56] <mmcc> ok now I remember. in the sso client tests, we have a registry file that includes (fake) paths to the sso client and the syncdaemon
[21:57] <mmcc> ubuntu_sso/main/tests/ubuntuone.reg
[21:59] <mmcc> windows-installer/scripts/devsetup/env.bat checks for one of the test keys and installs that .reg file if the keys don't exist
[22:01] <mmcc> in summary, the registry key "SyncDaemonInstallPath" looks like the real one although I can't tell how it gets set, and the other one is only for tests, and happens to be used in the real code that tcpactivation uses, but maybe it's OK if it's bogus because we don't actually use the command line it returns in that case
[22:02] <mmcc> at least we don't for syncdaemon
[22:04] <dobey> weird
[22:04] <dobey> sounds like a shark circling the meat
[22:09] <mmcc> ...no , I don't follow
[22:10] <mmcc> anyway I just need to confirm that SyncDaemonInstallPath is actually the value we use in production. anyone with a windows install listening? briancurtin ?
[22:10] <briancurtin> mmcc: i'm about to head out the door. no idea about SyncDaemonInstallPath. sounds familiar...which im sure is helpful
[22:11] <mmcc> briancurtin: heh, ok - can you tell me where to look to see what reg keys we set up when we install it?
[22:12] <briancurtin> mmcc: ubuntuone.xml in ubuntuone-windows-installer/scripts is what creates our installer. i know it sets a few things up
[22:12] <briancurtin> i dont know if it sets that particular one up, though
[22:13] <mmcc> OH NO it sets the ones I thought were just for testing and now my whole theory is shot
[22:13] <mmcc> thanks briancurtin  :)
[22:13] <briancurtin> np
[22:24] <alecu> mmcc: do you know which branch I should be using to create a fresh buildout?
[22:25] <mmcc> which branch of the windows-installer? I think trunk should work, but I see the instructions still say briancurtin's branch... hmmm
[22:27] <mmcc> alecu, yes, the branch the instructions refer to was merged on 4/18
[22:27] <mmcc> so I'll edit the instructions
[22:27] <mmcc> oh i see you are
[22:27] <alecu> mmcc: so ubuntuone-windows-installer trunk should do?
[22:28] <mmcc> yes, it should
[22:28] <alecu> mmcc: go ahead and change!
[22:28] <alecu> great, thanks.
[22:32] <mmcc> ok, I have to run. I'll be working later, might not have internet though. see you all tomorrow