[08:40] <mandel> morning all!
[11:14] <gatox> good morning!
[11:22] <mandel> gatox, morning!!!!
[11:22] <mandel> gatox, I have tests for you to run!
[11:22] <mandel> :P
[11:23] <gatox> mandel, hi! give me the tests! :P
[11:23] <mandel> gatox, they are here: lp:~mandel/ubuntu-sso-client/fix-activation-tests
[11:23] <gatox> mandel, do you enjoy your holidays?
[11:23] <mandel> gatox, you need the ubuntuone-dev-tools stuff from last week
[11:23] <mandel> gatox, yes I did, no computers and just internet connection on the phone, it was great :)
[11:27] <mandel> gatox, if this works there is one thing to always remember, defer.maybeDefered(listener.soptListening)
[11:27] <gatox> mandel, jejejee ok, let's see
[11:28] <gatox> mandel, may it be that something is missing?? it says that there is no module "tx"
[11:29] <mandel> gatox, remember to branch lp:~mandel/ubuntuone-dev-tools/mocked-webserver and put it in the path :)
[11:29] <gatox> mandel, ahhhhh
[11:30] <mandel> gatox, uhhhhh la chicas son guerreras!
[11:30] <mandel> gatox, http://www.youtube.com/watch?v=JdedFCz5Agk
[11:31] <mandel> gatox, welcom to the spanish 80s music :P
[11:31] <gatox> mandel, juazzzzzzzz
[11:32] <gatox> mandel, well..... it's not so different from some 80 music from argentina
[11:32] <mandel> gatox, we might be the root cause of that hehe
[11:32] <gatox> jejeje
[11:33] <gatox> mandel, it seems that it was really cheap to do these kind of video clips jejee
[11:43] <mandel> gatox, works?
[11:43] <gatox> mandel, i'll restart and retry..... because i had the same 17 errors as always
[11:44] <mandel> gatox, sure, can you run and let me see the output?
[11:44] <gatox> mandel, yes
[11:56] <mandel> gatox, give me my errors! :P
[11:56] <gatox> mandel, always the same http://paste.ubuntu.com/921696/
[11:57] <gatox> uhhhhh more errors now..... weird
[11:57] <gatox> running it again
[11:57] <mandel> gatox, ok
[12:00] <gatox> mandel, no....... again the same errors..... now instead of 17 i have 96
[12:00] <mandel> gatox, hm.. that is very very weird
[12:01] <gatox> mandel, can we trust in my vm? :P
[12:01] <mandel> gatox, yes.. I mean, in a way we can trust the error from the reactor
[12:01] <mandel> gatox, I wonder.. is that vm very very slow when you use it?
[12:02] <gatox> mandel, nop..... i don't use it too much..... except for running tests and executing u1....... but it's not slow
[12:08] <mandel> gatox, this is going to sound evil.. but can you try to run the twisted tests on that machine :)
[12:08] <mandel> ?
[12:08] <gatox> mandel, i can try.......
[12:08]  * mandel evil laughs 
[12:08] <gatox> mandel, where is the repo? http://twistedmatrix.com/trac/
[12:09] <mandel> gatox, I'm getting a could not connect to http://twistedmatrix.com/trac/
[12:09] <mandel> :(
[12:09] <gatox> mandel, me too
[12:10] <gatox> that's why i ask :P
[12:10] <mandel> gatox, che, se fue todo a la mierda en twisted lol
[12:10] <gatox> mandel, i'm not feeling really lucky here
[12:10] <gatox> jeje
[12:10] <mandel> gatox, we finally managed to close the reactor!
[12:10] <mandel> hehehe
[12:10] <gatox> jejejejejjee
[12:11] <gatox> mandel, so......... we should migrate to qthread now...... :P
[12:11] <gatox> jeje
[12:11] <mandel> gatox, no threads please..
[12:23] <alecu> hello, all!
[12:48] <ralsina> Good morning!
[12:49] <gatox> ralsina, hi!
[12:50] <ralsina> hello gatox, what did I miss the last week? :-)
[12:50] <ralsina> Looks like I can't connect to canonical IRC. Nice way to start the week
[12:51] <gatox> ralsina, weird...... mmmmmm you miss my life changing decision ejejjej now i begin the morning doing exercise, more energy during the day.....
[12:51] <gatox> ralsina, about work..... just bugs :P
[12:51] <gatox> jje
[12:52] <ralsina> gatox: good idea, don't start at 40, everything hurts at 40 ;-)
[12:52] <ralsina> ok, switching to local quassel, brb
[13:14] <alecu> gatox, I've just confirmed it. On linux, calling any method in SyncDaemonTool will start syncdaemon, even when .start() was not called before.
[13:15] <gatox> alecu, right..... so, it's consistent in that way
[13:15] <alecu> gatox, so, on windows it should do the same.
[13:16] <gatox> alecu, so, the thing is.... the code is ok but it shouldn't start sd during u1sdtool -q?
[13:16] <gatox> alecu, or i missing ssomething?
[13:18] <alecu> gatox, "your branch fixes the bug, but the reality of the milanesa is that an instance of the SyncDaemonTool class should not start SD when it's created".
[13:19] <alecu> gatox, so, if we fix that milanesa, your branch should not be needed.
[13:19] <gatox> alecu, right
[13:20] <alecu> gatox, but I still don't have a clear picture on how to fix this.
[13:20] <gatox> alecu, so..... we should refactor the milanesa :P to start sd on start..... or when the user call the methods?
[13:21] <alecu> gatox, you mean "start sd when the .start() method is called"?
[13:22] <alecu> gatox, that's one option, yes.
[13:22] <gatox> alecu, yep
[13:23] <dobey> refactor the milanesa? like, make it so vegan types can eat it? milanesa sin pollo?
[13:23] <gatox> dobey, never take out the meat.... put more meat :P
[13:23] <nessita> alecu: SyncDaemonTool does not start a syncdaemon if is not running on linux (hola!)
[13:24] <dobey> hehe
[13:24] <gatox> alecu, should i start working in that and see how we can refactor that.... or do you want to analyze other options?
[13:24] <alecu> nessita, if I call any method in a SyncDaemonTool instance on linux, an SD instance will be started.
[13:25] <alecu> nessita, .start, or any other method too.
[13:25] <nessita> alecu: hum, but the simple fact of creating an instance of SDT does not start it, no?
[13:25] <nessita> alecu: and in windows it does
[13:25] <alecu> nessita, no. And we have already established that :-)
[13:25] <alecu> nessita, right.
[13:26] <alecu> nessita, so: on linux, creating an instance of SyncDaemonTool will not start SD. But calling any method will.
[13:26] <alecu> nessita, on windows, creating an instance will immediately start SD.
[13:26] <nessita> ok, so my review was requesting that the simple fact of starting a SDT in windows will not start the service, to match linux behaviour
[13:27] <gatox> alecu, right..... in windows we are having the problem on SDT __init__
[13:27] <alecu> nessita, right: we need SDT not start on __init__. But we should also make it so calling every method should start it, to match linux.
[13:27] <nessita> alecu: +1
[13:28] <gatox> alecu, maybe this is wrong..... but.... can't we decorate the methods of sdt to start sd if necessary?
[13:29] <alecu> gatox, sounds like a nice solution
[13:30] <ralsina> good morning alecu, dobey, nessita!
[13:30] <gatox> alecu, nice :D..... do you want me to do that? (in a different branch)
[13:30] <alecu> gatox, perhaps in SyncDaemonToolProxy
[13:30] <nessita> hola ralsina
[13:30] <ralsina> nessita: I am still catching up on mail, will reply to yours in a bit
[13:30] <alecu> hola ralsina!
[13:31] <nessita> ralsina: ack
[13:31] <ralsina> did I miss anything interesting last week?
[13:31] <dobey> hola ralsina
[13:35] <alecu> gatox, so: I think we should not add a decorator to every method, but instead only add some smarts to SyncDaemonToolProxy.call_method
[13:36] <gatox> alecu, sounds good
[13:37] <gatox> alecu, ok, i'll start with that :D
[13:39] <alecu> gatox, also, there's some interesting stuff in there too, like "_call_after_connection"
[13:40] <gatox> alecu, yep
[13:40] <alecu> gatox, so I think that some bits are already there, like waiting for the connection before calling. It should also start the self.client if it was not started.
[13:41] <alecu> gatox, take a look there, and ping me if it does not make sense.
[13:41] <gatox> alecu, ok
[13:51] <joshuahoover> ralsina: win release update? :)
[13:52] <ralsina> joshuahoover: still catching up
[13:52] <ralsina> joshuahoover: but I assume it's missing a bugfix or two :-/
[13:52] <ralsina> briancurtin: you here already?
[13:52] <briancurtin> ralsina: yep, typing up a response to that
[13:52] <ralsina> briancurtin: cool :-)
[13:53] <briancurtin> joshuahoover: i put together a release on friday that included a (kind of hacky) fix to allow the cloud-to-computer installation step to work properly, not sure what its status is with QA
[13:55] <somethinginteres> Hi, I have just installed and updated Ubuntu 12.04 Beta 2. I am trying to login to my Ubuntu One account and am being told the password I used to login to my PC no longer matches my login keyring or something to that effect. Ideas?
[13:57] <dobey> did you install ubuntu on top of an exsiting ubuntu installation, and carry over your $HOME directory?
[13:58] <somethinginteres> dobey: I installed over the top of a Debian install. Carrying over my $HOME from a separate partition
[13:58] <dobey> ah
[13:59] <dobey> and did you set up your user in the new install with a different password than you were using on the previous install?
[13:59] <somethinginteres> dobey: yes, I did. Different password to my old user. Same name though.
[14:00] <dobey> somethinginteres: you will have to unlock the keyring using the old password then. you should be able to change the keyring password in seahorse, to match your new login password, if you want it to unlock on login
[14:01] <somethinginteres> dobey: Let me give that a go.
[14:03] <somethinginteres> dobey: hmm, using the old password worked. Trying to change the "Login Keyring" password in Seahorse reports that the "original password" I entered (aka the correct old password from Debian) didn't match.
[14:03] <dobey> hmm
[14:04] <dobey> that's odd
[14:04] <dobey> if it worked to unlock it, it should work to change it
[14:04] <somethinginteres> dobey: I'll have to investigate further if the problem arises elsewhere. Thanks for the fix in this case anyway. I'll look into it.
[14:19] <gatox> alecu, i think it's done! :D.... i'll propose the branch now
[14:20] <alecu> gatox, awesome!
[14:22] <mandel> alecu, morning! I updated https://code.launchpad.net/~mandel/ubuntuone-dev-tools/tcp-testcases/+merge/99759 after your comments
[14:22] <mandel> alecu, please take a look when possible
[14:22] <alecu> mandel, sure, thanks!
[14:23] <briancurtin> mandel: that's the branch which goes along with fixing SSO tests, right?
[14:24] <mandel> briancurtin, yes, that is the one, I'm testing right now with gatox a fix required in the webserver
[14:24] <mandel> briancurtin, if I can get this to work we should chat about jenkins automation etc..
[14:24] <briancurtin> mandel: sounds good, let me know when you want to chat
[14:25] <mandel> briancurtin, as soon this is fix we could chat on how it was fixed and what to do next :)
[14:26] <briancurtin> mandel: cool, that would be useful. i could use a primer on the whole "dirty reactor" issue, what causes it, how to fix, etc
[14:27] <mandel> briancurtin, exactly, is better to have this knowledge in more than one place in case I die at some point hehe
[14:31] <ralsina> mandel: reading the mail from last week... why do we need a twisted web server?
[14:32] <mandel> ralsina, because it is used to do a point to point test of the webclient, tests start a "webserver" and we retrieve data from it
[14:33] <ralsina> mandel: and why not use something like SimpleHTTPServer?
[14:33] <mandel> ralsina, that way we tests everything but don't go to the outside world for it, problem is, is leaving dirty reactors atm
[14:33] <mandel> ralsina, dont know? alecu is there a particular reason for that ^ ?
[14:34] <alecu> ralsina, mandel: SimpleHTTPServer is blocking. If we would use something like that in tests, we would need to run it in its own thread. And threads are evil :-)
[14:35] <ralsina> alecu: ack
[14:35] <mandel> alecu, +100000 for no threads :)
[14:36] <alecu> mandel, there is in fact a way of telling trial
[14:36] <alecu> sorry
[14:37] <alecu> mandel, there is in fact a way of telling trial to not care about dirty reactors. But "dirty reactor" is just trial way of telling you that you left something without closing it.
[14:38] <alecu> mandel, the thing is that trial has no way to know which "unclosed" bits belong to your main code, and which belong to your test.
[14:38] <mandel> alecu, no worries, I think having dirty reactors is a good thing, I don't want tests that do not clean after them
[14:39] <mandel> alecu, I think I got it working
[14:39] <alecu> awesome
[14:43] <mandel> alecu, funny thing, is just gatox vm the only reliable way to get the dirty reactors.. he must have touched something hehe
[14:44] <gatox> mandel, stop blaming me! :P
[14:45] <dobey> threads are not evil
[14:45] <dobey> bad code is evil
[14:45] <dobey> and you don't need threads to write broken code :)
[14:46] <ralsina> dobey: code that uses threads is 90% f the time bad and evil
[14:46] <dobey> ralsina: 90% of programmers are crappy programmers :)
[14:47] <ralsina> dobey: haha, Sturgeon's law at work :-)
[14:48] <mandel> dobey, excuse, just 90% of me is a bad programmer, the rest is an ok programmer!
[14:48] <dobey> heh
[14:49] <somethinginteres> is the bug of having duplicate devices in the "Devices" tab still a thing in 12.04?
[14:50] <mandel> gatox, do you know anything about that^
[14:51] <dobey> somethinginteres: "bug" ?
[14:51] <gatox> somethinginteres, mandel i haven't seen that
[14:51] <dobey> somethinginteres: it is possible to have duplicate devices, yes, but i don't think it's a "bug"
[14:52] <somethinginteres> dobey: I just remember emailing support a while ago and they said it was a "glitch" they were working on.
[14:53] <dobey> somethinginteres: ok, i don't know about that.
[14:53] <dobey> rye, duanedesign: ^^ do you know aobut that?
[14:53] <ralsina> dobey, gatox, alecu, briancurtin, urbanape: standup in 7'
[14:53] <briancurtin> ack
[14:53] <gatox> ralsina, ack
[14:54]  * rye is reading
[14:55] <rye> somethinginteres: are there duplicate entries in https://one.ubuntu.com/account/machines
[14:55] <duanedesign> somethinginteres: i have not had that happen in quite awhile. Not sure what the 'official' status is though
[14:57] <dobey> there is a bug in rhythmbox/libubuntuone/rhythmbox-ubuntuone that can result in the local token being removed from the keyring (but the entry remains on the server), which will be fixed in an update tomorrow
[14:57] <dobey> (is already fixed in nightlies)
[14:58] <dobey> but outside of that, i don't know of any current bugs that would cause the same issue. only way would be to delete the token locally yourself.
[14:58] <rye> dobey: yeah, but the info about the tokens is coming from the server... so if it is duplicating locally then that's basically a reauthorization
[15:00] <dobey> rye: yes, the list in the control panel is from the server. the problem happens when the token gets removed from local keyring, and not from the server
[15:01] <ralsina> me
[15:01] <briancurtin> me
[15:01] <gatox> me
[15:02] <mandel> me
[15:02] <dobey> meh
[15:02] <gatox> alecu, urbanape ?
[15:03] <dobey> thisfred, nessita?
[15:03] <briancurtin> urbanape is on vacation this week
[15:03] <gatox> dobey, nessita is on rotation
[15:03] <dobey> ah right
[15:03] <ralsina> DONE: nothing, email catchup TODO: perf.reviews, tech leads call, catchup, some IRL QA of latest windows build, whatever is needed BLOCKED: well, there is a *pile* of mail still to read/answer/delete/burn/forget/tatoo on my forearm
[15:04] <ralsina> NEXT: briancurtin
[15:04] <briancurtin> DONE: firewall exceptions added to installer, fixed cloud-to-computer in a hacky way, created a new windows installer
[15:04] <briancurtin> TODO: fix some read-only/read-write differences by trying out the winsys package, get tests green!
[15:04] <briancurtin> BLOCKED: none
[15:04] <briancurtin> NEXT: gatox
[15:04] <alecu> me
[15:04] <gatox> DONE:
[15:04] <gatox> Kind of fix this one: Bug #824574 (but the fix present another issue... looking at that). Worked on Bug #907479.
[15:04] <gatox> TODO:
[15:04] <gatox> Finish with #907479. Start with Bug #973830.
[15:04] <gatox> BLOCKED:
[15:04] <gatox> No
[15:04] <gatox> mandel, go
[15:04] <mandel> DONE: Easter holidays. Update dev-tools branch that is up for review. Fixes more tests with the help of gatox.
[15:04] <mandel> TODO: Get all sso tests work, propose mp then talk with briancurtin on how to move with jenkins.
[15:04] <mandel> BLOCKED: no.. besides debugging
[15:04] <mandel> dobey, please
[15:04] <dobey> λ DONE: bug #969262, started u1db packaging
[15:04] <dobey> λ TODO: finish bug #968555, finish u1db packaging
[15:04] <dobey> λ BLCK: none.
[15:04] <dobey> alecu
[15:04] <alecu> DONE: national holidays and weekend, catching up with mail
[15:04] <alecu> TODO: reviews, first techleads call, SD bugs
[15:04] <alecu> NEXT: ?
[15:05] <thisfred> me
[15:05] <gatox> thisfred, go
[15:05] <thisfred> DONE: tracked down segfault
[15:05]  * ralsina forgot thisfred and mandel! This is already going to hell! ;-)
[15:05] <thisfred> TODO: finish split words mapping
[15:05] <thisfred> BLOCKED: no more
[15:06] <mandel> ralsina, wait what? you forgot about us.. mal.. muy mal? :P
[15:06] <ralsina> mandel: I just came back frm vacations, have not got my brain started yet
[15:06] <mandel> hehehe
[15:07] <dobey> ralsina: have you tried ether? it's a great starting fluid
[15:07] <ralsina> dobey: have any online ether providers? ;-)
[15:08] <ralsina> ok, comments!
[15:08] <ralsina> briancurtin, mandel: have you had any progress on the jenkins area?
[15:09] <thisfred> # XXX: add comments
[15:09] <mandel> ralsina, I just ran the tests on gatox evil machine and I got 19 error in the TxWebclient implementation which is no clean, that is an easy thing to fix son in a few mins I'll ask him to try again
[15:09] <ralsina> mandel: awesome
[15:09] <briancurtin> ralsina: i got hung up most of last week trying to get windows ready. i ended up having to propose a hacky little branch for an issue elopio found during install
[15:09] <mandel> ralsina, if that is ok, then we can start merging the fixes and see if the all pass in jenkins :)
[15:09] <ralsina> briancurtin: cool, let's launch that thing
[15:09] <gatox> mandel, my machine obviusly hate you
[15:10] <ralsina> mandel, briancurtin: so, after it works on gatox's box we start on jenkins?
[15:11] <briancurtin> ralsina, mandel: yes sir. i'm working right now on trying a new approach to solving the read-only/read-write problem (wanted to do it last week) that will hopefully solve some of the test failures on windows with files not being found/accessible
[15:12] <ralsina> briancurtin: awesome
[15:12] <mandel> briancurtin, that is great! 'cause I think that those tests did fail on jenkins
[15:12] <dobey> need lunch, bbiab
[15:13] <briancurtin> mandel: its more than just the specific ro/rw tests, too. on u1client i get a bunch of tests that almost always fail trying to access tritcask files
[15:14] <mandel> briancurtin, oh, is that because the path is too long?
[15:14] <briancurtin> mandel: hm, i don't think so, but i'll look into that possiblity. i don't have the traceback handy but i seem to remember it being for access
[15:15] <mandel> briancurtin, take a look on that, I know that tritcask does not use the \\?\ trick which means that the length of the path is a problem
[15:16] <ralsina> briancurtin, mandel: we had tons of times "filename too long" in tritcask tests, and verterok had made them shorter
[15:16] <ralsina> but I suppose it all depends on *where* you are running the tests, of course
[15:20]  * gatox goes to buy some food...... brb!
[15:53] <ralsina> alecu: no tech leads call, but I would like a short mumble with you in about 30'?
[15:53] <alecu> ralsina, sure!
[15:54] <alecu> ralsina, so, there's no tech leads call today?
[15:54] <ralsina> alecu: right
[15:54] <alecu> ack
[15:54] <ralsina> alecu: not enough people available, strong case of the mondays, high probability of meteorite showers, etc.
[15:55] <alecu> lols
[16:11] <mandel> briancurtin, ping
[16:12] <briancurtin> mandel: pong
[16:14] <mandel> briancurtin, can you grab lp:~mandel/ubuntuone-dev-tools/mocked-webserver put it in you path and run the tests for lp:~mandel/ubuntu-sso-client/fix-activation-tests ?
[16:14] <mandel> briancurtin, gatox evil machine is having lunch :(
[16:16] <briancurtin> mandel: yep, i'll let you know in a few minutes
[16:16] <mandel> briancurtin, thx!
[16:27] <mandel> alecu, ping
[16:28] <briancurtin> mandel: the first run passed :) i'll run a few times and see if it's all ok
[16:28] <mandel> alecu, we have an issues with the txweb.WebClient in its current implementation because it leaves the tcp.Client behind after the requests, got any idea?
[16:28] <mandel> briancurtin, great!
[16:30] <dobey> mandel: https://bugs.launchpad.net/ubuntuone-dev-tools/+bug/972366/comments/1
[16:31] <alecu> mandel, pong
[16:31] <alecu> mandel, is it using http/1.1?
[16:31] <mandel> dobey, hm.. I don't know how to rephrase that, the issue is that we have a mocked webserver in the tests that does not clean the resources correctly
[16:31] <mandel> alecu, let me check
[16:34] <mandel> alecu, it uses the default http.HTTPClient which in 1.0
[16:34] <mandel> form http://twistedmatrix.com/documents/8.1.0/api/twisted.web.http.HTTPClient.html
[16:34] <mandel> s/form/from
[16:35] <briancurtin> mandel: the tests passed 5 times in a row, so i think you win
[16:37] <mandel> briancurtin, I win in your machine and mine, gatox one thinks a diff way..
[16:38] <briancurtin> that's because it's run by the green alien on the cover
[16:38] <gatox> jejeje
[16:41] <alecu> gatox, does your "windows machine from hell" have the proxy settings enabled while running the tests?
[16:41] <gatox> i think not.... checking.......
[16:43] <gatox> alecu, nop
[16:44] <alecu> mandel, ping
[16:44] <mandel> alecu, pong
[16:45] <alecu> mandel, so, we should probably redefine the "Webclient.shutdown" method in txweb, so it calls self.connector.disconnect() or something.
[16:45] <mandel> alecu, I'm done that, in briancurtin machine does the trick on gatox it does not since we have to wait for it to really really disconnect
[16:46] <mandel> alecu, so we get back to the issue realted with the 3 deferreds
[16:47] <alecu> mandel, right. We should really be using that for every webclient test that creates a fake webserver.
[16:47] <alecu> mandel, I don't know how much of a change all of that is.
[16:48] <mandel> alecu, so the deal is the following, on glib and qtnetwork we just ensuring that the webserver is correctly cleaned does the trick because the webclient leaves nothing in the reactor, the tx implementation does, which means that there is no solution for all of them
[16:49] <mandel> alecu, if you look at the diff of lp:~mandel/ubuntuone-dev-tools/mocked-webserver you will see the fix that ensures that qt and glib are correctly cleaned
[16:49] <mandel> alecu, and lp:~mandel/ubuntu-sso-client/fix-activation-tests will be with the tcpactivations fixed too
[16:50] <mandel> alecu, all those are based on using lp:~mandel/ubuntuone-dev-tools/mocked-webserver
[16:53] <alecu> mandel, we should not be doing this: self.connections.append(connection)
[16:53] <alecu> mandel, because those "connections" may be long finished
[16:54] <mandel> alecu, that has been written in desperation mode :(
[16:54] <alecu> mandel, oh, ok.
[16:54] <mandel> alecu, those are the only tests failing in gatox machine
[16:55] <mandel> alecu, for just those tests I'd need to patch the server side, the client side and wait for the deferreds to be called, which means that we cannot reuse the parent test case class, not that I'm to worried about that to be honest
[16:55] <alecu> mandel, and does that work?  I mean, the "c.disconnect()" ?
[16:55] <mandel> alecu, no, it does not
[16:56] <alecu> mandel, perhaps shutdown is not being called on cleanup?
[16:56] <mandel> alecu, it is, I pdb into it
[16:56] <alecu> damn.
[16:59] <mandel> alecu, I know how to fix it, but by rewriting the entire test for that, which I think is not a good idea because it would be optimum to use the same tests for all webclients and not have the tx implementation to be diff
[17:01] <alecu> mandel, how would those tests differ?
[17:01] <alecu> mandel, can you write just one?
[17:02] <mandel> alecu, sure, give me some time, the hard stuff is the setup :)
[17:11] <dobey> hrmm
[17:47] <mandel> I've got to do some errands
[17:47] <mandel> will be back in 5 min
[17:57] <mandel> alecu, briancurtin, gatox, ralsina I'm a little block and close to EOD, I'm going to walk the dog to see if I get some ideas
[17:57] <briancurtin> mandel: enjoy
[17:57] <gatox> alecu, not done.... i've fighting all this time with something really weird, that if i don't call the connect on the __init__ some stuff stays in None... i'm trying to fix that yet..... just a heads up
[17:57] <gatox> mandel, ack
[17:58] <ralsina> mandel: cool
[17:58] <alecu> gatox, ok
[18:32] <gatox> creating an installer everytime you want to test something in a branch....... FUN NOT
[18:41] <ralsina> gatox: yes, we should make it work from sources again, but it's a pain
[18:42] <ralsina> gatox: not being able to execute .py files == sucks :-/
[18:42] <gatox> ralsina, no, it's not that..... the problem is that is only reproducible with the installer...... i'm just testing stuff from u1-client
[18:42] <ralsina> gatox: oh. Really?
[18:42] <ralsina> gatox: :-(
[18:43] <gatox> ralsina, yapppp..... that's why is reallyyyyyy slow to test this and see if it breaks anything else (like now :P)
[18:59] <dobey> why is there an ubuntuone/platform/windows/pyinotify.py in ubuntuone-client? :(
[19:04] <dobey> anyone?
[19:04] <beuno> dobey, I'll take "Things thathappen while drunk" for $100
[19:05] <gatox> dobey, i assume that it is there to "simulate" the same behaviour in windows, that pyinotify does in linux
[19:06] <gatox> and probably you would import something like: from u1.platform import pyinotify..... and is going to be valid for windows and linux
[19:06] <dobey> oh, i guess it's MIT
[19:06] <gatox> dobey, mit?
[19:06] <dobey> license
[19:06] <gatox> ah
[19:13] <ralsina> Have to do school run, will be back in a bit
[19:13] <gatox> ack
[19:31] <briancurtin> anyone have a tip on where would be the best place to shorten file paths for tests? these tritcask ones are too long, and it looks like they're already shortened from some place (eg some test names in the path look to be cut off)
[19:32] <dobey> briancurtin: this is on windows i presume?
[19:36] <briancurtin> dobey: yeah
[19:39] <dobey> how long are the paths if they're ending up as too long?
[19:40] <briancurtin> dobey: the one i'm looking at is 266 long. 255 is max
[19:41] <dobey> briancurtin: hrmm. that is pretty long, yeah. do you have a long branch nick for your branch or something?
[19:44] <briancurtin> dobey: ah yeah, i guess the path leading into the test folder is kind of long. i could restructure things a bit and save some chars and see if i can keep it consistently under
[19:46] <dobey> briancurtin: well, you are lucky that you get to use 255 chars. no unix sockets
[19:51] <ralsina> briancurtin: ask verterok, but there is a magical constant that makes tritcask's filenames shorter on tests (within reason ;-)
[19:52] <briancurtin> ralsina: i did have a kind of long path leading up to the branch so that might save me for a bit, but i'll check with him and see for the future
[19:58] <verterok> ralsina,  the "magic" value is in the base testcase...let me check
[19:58] <verterok> briancurtin: ^
[20:02] <verterok> briancurtin, ralsina: tmpdir property in contrib/testing/testcase.py @ line 303
[20:02] <briancurtin> verterok: cool, thanks!
[20:03] <gatox> ok..... eod here...... this is almost working.... almost! i'll keep working on this bug tomorrow! see you!
[20:11] <dobey> wow it's 1610 already here :-/
[20:52] <consindo> How does Ubuntu One deal with conflicts?
[20:52] <beuno> consindo, it renames the files to .conflict
[20:53] <salgado> .u1conflict, no?
[20:53] <consindo> If we're adding sync in to our app, would it be possible for the data to be sent off to an external server to be merged and then saved to Ubuntu One?
[20:54] <beuno> consindo, pretty sure you could yes
[20:55] <consindo> Ok, does Ubuntu One store revisions of files?
[20:56] <beuno> consindo, not at the moment, no
[20:57] <aquarius> consindo, heya
[20:57] <aquarius> sorry
[20:57] <aquarius> consindo, was afk briefly :)
[20:57] <aquarius> consindo, so, there are two ways we could look at nitro syncing with U1
[20:58] <aquarius> consindo, I've been looking at the nitro code, and adding a new storage backend is just a case of providing my own $.jStorage implementation, yes?
[20:58] <consindo> aquarius, yes
[20:58] <dobey> what is nitro?
[20:59] <aquarius> dobey, task manager. See nitrotasks.com
[20:59] <aquarius> consindo, so, there are two approaches that can be taken for storing data in Ubuntu One
[20:59] <dobey> this screams u1db
[20:59] <aquarius> consindo, the existing file sync, which is what you'd use to sync your documents and photos and so on with all your machines -- this is good for things like photos and documents and music, but for rapidly changing conflicting data it's not ideal
[21:00] <aquarius> consindo, the second approach is u1db, the Ubuntu One synced database
[21:00] <aquarius> consindo, http://voices.canonical.com/ubuntuone/2011/12/22/u1db-technical-preview-release-tell-us-what-you-think/ is a summary of the preview release of u1db
[21:01] <aquarius> consindo, I was planning on sitting down today and writing a u1db backend for nitro, but I saw that you're already working on some other sort of syncing mechanism yourselves, and so I wanted to chat it over with you
[21:02] <aquarius> consindo, u1db is designed for this sort of data; conflicts are handled properly, the data is synced on your command, only the changes are sent, you can have revision history if you want it, it's JSON-based and usable from any language, and so on :)
[21:02] <aquarius> consindo, and it means that you don't have to invent your own syncing thing and deal with all the corner cases :)
[21:02] <dobey> *please* choose the u1db
[21:02] <thisfred> it farts rainbows
[21:02] <dobey> basically
[21:03] <aquarius> consindo, there's a standalone u1db server, too, so if people wanted they could run their own nitro sync server; I know some people prefer running their own services to using a cloud account that comes with their machine
[21:04] <consindo> consindo, great! What about people that don't want to use Ubuntu one?
[21:04] <consindo> aquarius, Mac Users etc
[21:04] <aquarius> consindo, see the last thing about the standalone u1db server; if someone doesn't want to use Ubuntu One they can happily run their own server if that's what they like doing
[21:04] <thisfred> aquarius: the only man that can reply faster than his own shadow :)
[21:05] <consindo> aquarius, So we can add in some code to merge data?
[21:05] <aquarius> consindo, u1db isn't platform-specific; you can have an Ubuntu One account (and therefore u1db storage) whichever platform you're on. Ubuntu One's on Windows, Ubuntu, Android, iOS, coming to the Mac...
[21:05] <aquarius> and you don't need to use U1 file sync to use u1db
[21:06] <aquarius> consindo, indeed you can add code to merge data. If someone makes conflicting edits to a task list (say, on two different machines) you can get both versions from u1db, and then logic in nitro itself can merge those edits, or ask the user, or choose one, whichever you prefer
[21:07] <aquarius> and a web-based Nitro can connect to the user's U1 account and show their tasks exactly as a desktop version can
[21:08] <consindo> aquarius, there's a bunch of people asking for different forms of sync. I guess we could add in other service as well
[21:08] <consindo> e.g Dropbox, Google Tasks
[21:08] <aquarius> consindo, that's up to you, of course. If there's a swappable back end then people could write many different syncing things
[21:09] <aquarius> that sounds like a lot of work to me, but it's not my project ;)
[21:10] <aquarius> Ubuntu One file sync does what Dropbox does, so you *could* implement nitro syncing on top of it, but u1db is better because it's designed for this sort of thing and file syncing isn't (conflicts are more of a problem, because you end up having to store your tasks in many separate files, or have *really* complex merging logic)
[21:11] <aquarius> but as I say you could build this on top of Ubuntu One file sync if you wanted -- and again, a web version of Nitro could happily read those task files and present the user's tasks exactly as the desktop app does (and a mobile app would of course work the same way)
[21:13] <consindo> aquarius, u1db is still a technical preview - any idea when it'll be ready?
[21:14] <dobey> consindo: we'll have packages in PPA soon. i don't know when aquarius will have the JS implementation ready though.
[21:14] <aquarius> consindo, ah, now that's the question I was expecting you to ask :) We're still working on the full-on Ubuntu One server implementation, but the standalone server already exists and works fine (so it can be developed against that -- and you'd want to develop against that anyway)
[21:15] <aquarius> consindo, in terms of client libraries, the Python one already exists (so you can have $.jStorage proxy gets and sets back to Python, as you have now), and I'm midway through writing a native JavaScript implementation (so you wouldn't need the Python at all)
[21:15] <dobey> well i'd think he'd want to develop with a JS API, not python (or C) :)
[21:15] <thisfred> C is also 95% done
[21:16] <consindo> aquarius, Yeah, we would want to use a JS API not a python one. The Mac OSX version will be done in Objective-C.
[21:16] <aquarius> consindo, I'd be interested in helping to port nitro to u1db, but since I saw that you guys are working on syncing I wanted to see what your plans were so as we fit together :)
[21:17] <consindo> aquarius, We were planning on using node.js + redis. Does u1db have a REST api?
[21:17] <aquarius> consindo, it does indeed
[21:17] <aquarius> consindo, the advantage with using u1db is that you guys don't necessarily have to spend your lives sysadminning a popular server and can concentrate on making a fantastic tasks app
[21:19] <aquarius> consindo, but as I say that's up to you, of course. :)
[21:20] <consindo> aquarius, I don't think people will even trust us with their data - We're still students.
[21:20] <aquarius> consindo, another advantage :)
[21:20] <aquarius> consindo, if they're storing data in their personal cloud then it's still *their* data; you don't have to worry about how to handle data export, what to do about data from other countries, etc, etc
[21:20] <aquarius> We do that, so you don't have to :)
[21:21] <consindo> aquarius, u1db sounds like a great idea. We'll play around with it and hopefully we'll be able to use it =)
[21:21] <consindo> I think the advantages outweigh the disadvantages
[21:22] <dobey> yay u1db
[21:22] <aquarius> consindo, excellent. How can I help?
[21:22] <dobey> finish the JS implementation! :)
[21:23] <consindo> aquarius, we have to finish our merging code first. If we run into any problems we'll contact you.
[21:23] <consindo> We'll probably end up using the REST Api
[21:23] <aquarius> consindo, cool. Keep me up to date :)
[21:23] <aquarius> consindo, happy to have a call or whatever to talk it over in more detail
[21:24] <consindo> aquarius, I haven't used Ubuntu one file sync since 2010. Is it much faster now?
[21:24] <dobey> consindo: you'll probably want to use the JS API, as it will use HTML5 storage, and things will "just work" while offline, and you won't have to deal with having to manage your own local storage implementation for it, and all that.
[21:24] <aquarius> consindo, it's much faster now, indeed
[21:25] <dobey> i however, need to run. have a good evening all
[21:25] <aquarius> consindo, yeah, the way u1db works (the JS version, at least) is that it stores the data in localStorage, and then you tell it "sync" whenever you want, and it syncs with the server -- so the u1db implementation itself talks to the REST API, and you always have a local copy of the data to work with
[21:25] <consindo> aquarius, Has the JS API even been started?
[21:25] <aquarius> so everything's fine ofline
[21:25] <aquarius> ya, it's started; I'm working my way through the test suite implementing it :)
[21:27] <consindo> aquarius, thanks. We'll try and finish our merging code in the next few days =)
[21:27] <aquarius> consindo, cool!
[21:27] <consindo> stayradiated, Is there anything else?
[21:30] <consindo> aquarius, I think we're fine. Thanks!
[21:30] <aquarius> excellent. Nice to meet you both :)