[08:59] <fagan> morning
[09:10] <ralsina> morning fagan
[09:10] <fagan> ralsina: morning
[09:12] <fagan> So when do you want to walk me through the testing stuff
[09:13] <mandel> morning :)
[09:13] <fagan> morning mandel
[09:17] <mandel> ralsina, fagan: can you run the tests on linux for : https://code.launchpad.net/~mandel/ubuntuone-client/provide_credentials_management/+merge/62627
[09:17] <ralsina> mandel: sure!
[09:17] <fagan> mandel: sure
[09:18] <mandel> thx ^ 2
[09:18] <ralsina> and god morning!
[09:21] <mandel> :)
[09:29] <mandel> ralsina, fagan: did the tests pass?
[09:29] <ralsina> mandel: still running
[09:29] <mandel> ralsina: wow, they are slow...
[09:29] <ralsina> yep
[09:31] <ralsina> fagan: about the testing stuff, I am probably the worst one to walk you through it ;-)
[09:31] <ralsina> but in any case, yesterday, or the day before, nessita told you where the tests for that piece of code are.
[09:32] <fagan> autogen and make worked fine
[09:32] <mandel> fagan: and make check?
[09:32] <fagan> ralsina: well I know where the tests are I just want a walkthough of mocker and how to use it in relation to the code and all that
[09:32] <fagan> mandel: running now
[09:33] <ralsina> fagan: read the other tests. If you don't understand something, ping me
[09:33] <ralsina> not all of course, just one or two ;-)
[09:34] <ralsina> mandel: make test is successful
[09:34] <ralsina> BTW: that thing has exactly 2222 tests!
[09:34] <mandel> ralsina: dammed, take a look at the merge proposal, it fails on tarmac...
[09:34] <fagan> Errors
[09:34] <ralsina> mandel: let me check it
[09:34] <mandel> fagan: got errors? can you copy paste them?
[09:35] <fagan> ill have to redo the tests my terminal doesnt hold logs longer than 999 lines or something
[09:35] <fagan> im on 11.10 so that might be one of the issues though
[09:36] <fagan> if the tests are passing for ralsina
[09:36] <ralsina> mandel: I tested the branch, not the merged branch
[09:36] <ralsina> probably you have to merge to see the failures
[09:36] <mandel> ralsina: can you try that?
[09:36] <ralsina> plus, I will surely not get "exceptions.OSError: Too many open files" since I have that set waaaaay high
[09:37] <ralsina> I am trying the merged branch now
[09:37] <fagan> ok give it 10 minutes and ill give the complete log
[09:43] <ralsina> once unit testing starts taking 10 minutes ... oh, well.
[09:44] <mandel> I really dont understand it, mine merged with trunk works ok
[09:45] <ralsina> mandel: the too many open files error may be tarmac doing something
[09:45] <mandel> yes, I suspect so…
[09:45] <mandel> which is a pain in the ass
[09:46] <fagan> too many open files
[09:46] <mandel> fagan: you got that too?
[09:46] <fagan> and there is another about defer timing out
[09:46] <fagan> yep
[09:47] <ralsina> fagan: pastebin plz
[09:47] <fagan> ralsina: im still getting it
[09:47] <fagan> ralsina: takes ages
[09:47] <fagan> I just was looking down what was there
[09:52] <mandel> so, any luck?
[09:52] <fagan> mandel: still going
[09:53] <ralsina> mandel: still running
[09:53] <ralsina> PASSED (skips=1, successes=2223)
[09:53] <mandel> then I dont understand...
[09:53] <ralsina> mandel: so, can't help you with that :-(
[09:54] <mandel> leches!!
[09:56] <ralsina> maybe fagan can give you shell access to his box?
[09:57] <mandel> ralsina: the wird things is also to get this: exceptions.AttributeError: 'generator' object has no attribute 'addBoth'
[09:57] <ralsina> that's weird, yes
[09:57] <mandel> that does not make sense… the too many open files ok, but this..
[09:57] <ralsina> could be twisted versions?
[09:58] <mandel> I dont think there should be any issues, also I'm running N as tarmac should be doing
[09:58] <mandel> and between 10 and 11 there is not such a diff
[09:58] <ralsina> I am on N too
[09:59] <fagan> im running O
[09:59] <ralsina> but I am not fully up to date! Something else to try...
[09:59] <fagan> so it might be a different version
[10:00] <ralsina> mandel: trying with latest devtools etc
[10:00] <mandel> ralsina: I'm gonna see if I'm not up to date, but I should..
[10:00] <ralsina> mandel: ok
[10:02] <fagan> hmmmmm so from what I remember about reading and writing to files you are only allowed to open a few buffers at any given time is that the issue thats coming up
[10:09] <fagan> 9000 lines and counting of the log
[10:09] <ralsina> fagan: the limit on open files on linux is like 8192 files by default
[10:10] <ralsina> mandel: got errors now!
[10:10] <mandel> ralsina: me too, seems I was not up to date...
[10:10] <fagan> ralsina: but the buffer limit is like 8 and 2 are open by default
[10:10] <ralsina> the too many open files one
[10:10] <ralsina> fagan: no
[10:10] <mandel> ralsina: bloody hell…. I wonder if this happens in a clean branh from trunk
[10:11] <mandel> ralsina: if it does we are blocked...
[10:11] <ralsina> fagan: there is no such thing as buffers separate from files, that was only true in, like DOS 4.0
[10:11]  * fagan looks though his notes to find the bit that explains this 
[10:11] <ralsina> mandel: well, another thing to try, but I am betting on devtools being the guilty party
[10:11] <mandel> ralsina: I hope so… the ssue s from pyinotify, which is an evil beast
[10:12] <ralsina> mandel: I only had a few updates, and devtools is the only obvious one that could hurt this
[10:12] <ralsina> also memory usage has gone to hell so I am guessing tests are not cleaning after themselves
[10:13] <mandel> ralsina: yes, but I wonder what is the trial runner doing… it could be that the tests are not correctly tearing down
[10:13] <mandel> ralsina: hehe though the same, great minds...
[10:13] <ralsina> dobey was workin on tardown last night, too
[10:13] <mandel> ok, so we are block regarding tarmac until we roll back and we push the old one to tarmac
[10:13] <mandel> right?
[10:16] <ralsina> I think so
[10:16] <ralsina> or maybe dobey looks at it and says "doh"
[10:16] <ralsina> we can stack branches (scary)
[10:18] <ralsina> why the hell did I accept a plane ticket that leaves at 8AM? Was I drunk?
[10:21] <fagan> ralsina: yeah what I was remembering was io streams
[10:21] <mandel> ralsina: dammed, stacking branches is dangaerous, we have already done that...
[10:21] <ralsina> mandel: thus the scary part
[10:22] <fagan> ralsina: 3 are open by default not 2 as well
[10:22] <ralsina> dobey should be here in ~4 hours
[10:22] <mandel> ralsina: when does dobey arrive?
[10:22] <ralsina> fagan: what do you mean "io streams"?
[10:22] <mandel> ralsina: dammed you are too fast for me :)
[10:22] <fagan> ralsina: stdio, stderr, stdin
[10:22] <ralsina> stdin/stdout/stderr? Those are regular file descriptors in linux (and most OSs I suppose)
[10:22] <fagan> ralsina: and when you open a file it creates a buffer like those
[10:23] <fagan> (they are just buffers)
[10:23] <ralsina> yes, file IO is buffered. That doesn't mean you can't open 8192 files. Try it :-)
[10:23] <ralsina> ha, the tests have killed my VM :-(
[10:24] <fagan> ralsina: well you can open them but you cant use them all at once maybe the OS makes that seem a little more seemless than it is
[10:24] <ralsina> fagan: try it!
[10:24] <ralsina> start 4000 threads writing to 4000 files
[10:24] <fagan> ralsina: actually that definitely will kill itself
[10:24] <ralsina> or one thread with 8000 open files and write to them round robin :-)
[10:24] <fagan> ralsina: did that in class one day
[10:24] <ralsina> fagan: t r y i t
[10:25] <fagan> hah
[10:25] <ralsina> try the 8000 files one. 4000 threads need eef to run ;-)
[10:25] <ralsina> s/eef/beef/
[10:25] <fagan> ralsina: well it will work if you write them in a round robin since it will only have 1 buffer at 1 time
[10:26] <ralsina> fagan: and how do you write to two files at once without threads?
[10:26] <fagan> if I did like 20 at 1 time the OS would probably switch between them
[10:26] <ralsina> and no, you will have 8000 buffers, unless you flush them
[10:27] <fagan> well there would be some OS magic there id say
[10:27] <ralsina> fagan: again. Try it. It's 10 lines. I will wait.
[10:27] <fagan> ill do it a bit later
[10:27]  * ralsina brings out the subborn-o-meter
[10:27] <fagan> still waiting on the tests
[10:27] <ralsina> damn, sTubborn-o-meter
[10:27] <ralsina> fagan, if you got the error, kill it, we already reproduced it
[10:28] <fagan> ah ok then
[10:28] <fagan> actually im getting some different ones too
[10:29] <fagan> like there are a few attribute errors
[10:29] <ralsina> damn, had to hard-reset the VM :-(
[10:32] <mandel> ralsina: we can revert the last merge in ubuntuone-dev-tools to see if it works, I'll do that
[10:32] <ralsina> mandel: cool
[10:32] <fagan> ralsina: did you get the attribute errors too?
[10:33] <ralsina> fagan: can't tell since it died
[10:34] <ralsina> fagan: BTW: turns out ubuntu stats with an 1024 open file limit
[10:34] <fagan> ralsina: interesting id still like to see how its handled kernel level
[10:35] <fagan> (my guess is they move around the buffers and give each one time)
[10:35] <ralsina> fagan: you seem to have the impression that buffers are some scarce resource. They are not.
[10:36] <fagan> ralsina: yeah I know I just got a flash of the C class where they said you might have problems in some OSes
[10:36] <ralsina> and the whole purpose of them is to make writing to files return faster. You can even not use them.
[10:37] <ralsina> fagan: yes, "in some OSes"  :-)
[10:38] <fagan> Im going to let the tests finish so I can see if there are any other errors
[10:38] <fagan> ralsina: well windows in different times and some versions of unix that are floating about
[10:39] <fagan> well probably not any one in major use
[10:39] <ralsina> windows seems to be 2048 by default
[10:39] <fagan> ralsina: that the same for dos-98
[10:39] <ralsina> ok, 512 by default, and you can raise it to 2048
[10:40] <ralsina> of course if you app has more than 100 open files, you are probably doing something wrong
[10:41] <fagan> well it wouldnt make much sense in the desktop case
[10:42] <fagan> since it would slow everything down
[10:42] <fagan> and there wouldnt be anything that would need to be doing things all at once like that with files
[10:42] <fagan> but a server might have a problem if they were doing something weird
[10:43] <fagan> other than that I cant see a use for it
[10:43] <ralsina> fagan: servers either use a multiprocess model (thus avoiding these limits) or ask you to raise them, or use massive caching to memory, or mmap files, or... I mean these limits have been there for 40 years, not a new problem ;-)
[10:44] <fagan> ralsina: true
[10:45] <fagan> 11300 lines in the log :D
[10:46] <fagan> ralsina: race? http://paste.ubuntu.com/617390/
[10:47] <ralsina> fagan: once you get the state of the program as broken as it is when 1000 tests are not closed, anything can happen, usually errors lose relevance after a while :-)
[10:47] <fagan> there are a good few other errors than just the too many files thing
[10:47] <fagan> ah ok
[10:48] <ralsina> unless that error is one of the firsts, in which case, yeah
[10:48] <fagan> ok then I was thinking it could have been interesting to see what errors it cmes up with
[10:48] <fagan> *comes
[10:53] <fagan> just to make sure I pastebinned the output it takes a while to load though http://paste.ubuntu.com/617393/
[10:53] <fagan> I killed it though
[10:56] <mandel> ralsina: so far with r 31 of dev tools tests pass, I'll test all of them from there to see when it brakes
[10:56] <ralsina> mandel: cool, at least we have a clue
[10:56] <ralsina> I wish bzr had a bisect command like git
[10:57]  * fagan likes
[10:58]  * fagan likes to say "make one" when people wish 
[10:59]  * mandel goes for a small break while tests run
[10:59]  * fagan takes a nap
[11:02] <ralsina> lunch break for me
[11:14]  * mandel back
[11:33] <mandel> ralsina: looks like the culprit is the very last revision of ubuntuone-dev-tools, version 34, we can revert to version 33 and propose for merge..
[12:00] <duanedesign> morning all
[12:06] <duanedesign> hmmmm, http://www.dorianselimi.com/2011/06/justin-bieber-gnulinux-os/ /me thinnks i will put this on my roomates laptop
[12:08] <duanedesign> facundobatista: if you get a second today I had a question about {'is_directory': 'T', 'changed': 'LOCAL', 'has_metadata': 'T'} and what that is telling us.
[12:09] <facundobatista> duanedesign, ok
[12:09] <facundobatista> Muy buenos días a todos!
[12:10] <facundobatista> duanedesign, well, not ok, that combination has no sense, :)
[12:10] <facundobatista> duanedesign, do you have a branch of ubuntuone-client at hand?
[12:12] <duanedesign> i do
[12:13] <duanedesign> facundobatista, just fetched the latest revision
[12:15] <facundobatista> duanedesign, ok, open the ubuntuone/syncdaemon/u1fsfsm.ods file
[12:16] <facundobatista> duanedesign, that is how we programed the Sync state machine
[12:16] <facundobatista> duanedesign, the general desing of the file is that for each Event, you have an input state, an action, and an output state
[12:17] <facundobatista> that input state is the combination of:
[12:17] <facundobatista> - the node has metadata locally
[12:18] <facundobatista> - the "changed" state (NONE means not changed, LOCAL means that has local changes, SERVER means that there're server changed pending to update locally)
[12:18] <facundobatista> - is_directory means that if it's a dir or a file
[12:18] <facundobatista> and then you have some parameters according to the hash informed in the Event (if any) and errors (if any)
[12:18] <facundobatista> duanedesign, so far so good?
[12:19] <duanedesign> yes, thank you!
[12:19] <facundobatista> duanedesign, ok, now to be more specific about "changed"
[12:19] <facundobatista> the "changed" attribute is not a real one, it's a combination of:
[12:20] <facundobatista> - if local_hash (the hash we have locally for the node) is equal or different to the server_hash (the hash we locally know that the server has)
[12:20] <facundobatista> - if the node has a "partial" component (that means that it's being downloaded from the server)
[12:21] <facundobatista> LOCAL means that it has no partial, and the hashes are different... in other words, that we're *uploading* the node
[12:22] <facundobatista> duanedesign, which has no sense at all talking about directories: we never upload directories
[12:22]  * duanedesign nods
[12:22] <facundobatista> duanedesign, if you check the .ods, there's no input in any line for that combination (that's why the log says "Invalid input state"
[12:22] <facundobatista> )
[12:22] <facundobatista> duanedesign, furthermore, there's no output state for that combination
[12:23] <facundobatista> (columns L to N)
[12:23] <facundobatista> duanedesign, so, it's very very strange how the user gets to have that
[12:24] <duanedesign> facundobatista: thank you that is very helpful
[12:24] <facundobatista> otoh, we have seen cases like this already, and even more strange ones... and we also have seen a lot of cases of corrupted metadata in strange ways because of disk failing, energy cuts, etc
[12:26] <duanedesign> facundobatista: is their a way to get more info about the particular file(s) that might be corrupted? Or is the user likely to just need to 'rm' the metadata folder and have it recreated?
[12:31] <mandel> facundobatista: have you seen the failures from tarmac?
[12:31] <mandel> facundobatista: the current version of ubuntuone-dev-tools is broken… and we wont be able to land anything until the changes are reverted and installed in the tarmac machine
[12:35] <ralsina> mandel: or wait one more hour for dobey and ask him to look at it
[12:36] <mandel> ok
[12:38] <facundobatista> mandel, which failures from tarmac?
[12:38] <facundobatista> duanedesign, you can always make the user to dump the metadata to a readable form
[12:38] <mandel> facundobatista: let me find and example
[12:39] <facundobatista> duanedesign, see 'contrib/dump_metadata.py'
[12:39] <facundobatista> duanedesign, if you want to see more info there, it's easy to add
[12:39] <mandel> facundobatista: last comment: https://code.launchpad.net/~mandel/ubuntuone-client/provide_credentials_management/+merge/62627
[12:39] <mandel> facundobatista: all those are due to u1trial issues
[12:40]  * mandel walks dog
[12:41] <facundobatista> mandel, exceptions.AttributeError: 'generator' object has no attribute 'addBoth' ?
[12:45] <facundobatista> mandel, ah, ok, yes, it seems to be a ubuntuone-dev-tools problem
[13:00] <nessita> good morning everyone!
[13:04] <facundobatista> Hola nessita
[13:05] <nessita> hola facu
[13:13] <ralsina> hola nessita
[13:14] <nessita> hola ralsina, que tal?
[13:15] <ralsina> nessita: saying goodbye to people here, readying myself fr london
[13:15] <nessita> ralsina: when do you travel? today or tomorrow?
[13:15] <ralsina> tomorrow 8AM
[13:15] <nessita> that's early :-)
[13:16] <ralsina> yeah, I don't know what I was thinking
[13:16] <ralsina> I have to leave for the airport at 5AM
[13:21] <fagan> ralsina: I have to leave at 7 for my plane even though it leaves at 11
[13:21] <fagan> damn busses
[13:22] <fagan> I think next time im going to book the flights around 5 so it would be easier
[13:31] <Chipaca> ralsina: you were thinking "yeah 8am sounds right, i get up early, have breakfast and say my goodbyes, but then have all the day in london"
[13:31] <Chipaca> ralsina: forgetting that 8am flight means getting up at stupid am :)
[13:32] <ralsina> Chipaca: it probably will be "ok, I stay up all night then go to the airport like a zombie, mistakenly take a plane to Burkina Faso, end being torn apart by hyenas"
[13:33] <ralsina> I am setting my expectations low
[13:35] <fagan> sounds like a very cool place to get a weird plane to
[13:42] <ralsina> fagan: you can get there for U$S 2000 from Dublin. Only a 18 hour flight.
[13:43] <ralsina> Then again, the older name "Upper Volta" is way cooler
[13:44] <fagan> wow you could charter a jet for that price
[13:44] <ralsina> fagan: round trip
[13:44] <ralsina> it costs about the same as coming from argentina to turkey
[13:45] <fagan> ralsina: wow are you paying that or are you going through some other airport
[13:45]  * fagan sees why mark owns his own jet 
[13:45] <ralsina> fagan: I am not going to london via argentina if that's what you are asking ;-)
[13:46] <fagan> ralsina: arent your family going back
[13:46] <fagan> (from turkey)
[13:46] <ralsina> fagan: yeah, tickets were not cheap. About 2.7K for both of them
[13:47] <fagan> wow couldnt you get a connecting flight for cheaper
[13:47] <fagan> Im pretty lucky everywhere in europe is pretty cheap
[13:53] <ralsina> fagan: that involves a 4-hour stop in brazil. There are not many places to connect between S.am and europe ;-)
[13:54] <fagan> ralsina: ah ok I forgot about timezones
[13:54] <ralsina> fagan: basically, you have to pay for a plane that's nice enough to cross the atlantic at it's longest
[13:54] <fagan> ralsina: and that isnt going to be entirely full
[13:56] <ralsina> fagan: yeah. While in europe flights you can fly cheap, small planes that can stop every 1000km.
[13:57] <ralsina> fagan: so, it's like comparing a ferry and a transatlantic ship
[13:57] <fagan> ralsina: yeah I can get to the US for about 600 depending on the time of day
[13:58] <fagan> ralsina: and anywhere in europe for around 200 max
[13:58] <ralsina> that's about 6000km shorter than going to argentina
[13:58] <ralsina> and inside europe, over 10000km shorter
[13:58] <thisfred> I've been doing the economy plus upgrades recently. (Basically you pay for an exit seat of a little more leg room) Totally worth it for me
[13:59] <fagan> yeah its hard to compare a trip across the world
[13:59] <ralsina> thisfred: in british I was able to get that by being first on the online checkin
[13:59] <thisfred> good to know, I'm flying BA as well :)
[13:59] <ralsina> on turkish they reservethose seats until "real" checkin ;-(
[13:59] <fagan> im going ryan air this time :(
[13:59] <ralsina> thisfred: you can pay 25 euros to be able to do it before the 24 hours
[14:00] <ralsina> fagan: you are fliying 90 minutes :-)
[14:00] <fagan> ralsina: ryan air are the devil
[14:00] <fagan> :D
[14:00] <thisfred> ralsina: 75$ for me, but they wouldn't let me, because of something with  the booking (I guess because it was booked through the agent(
[14:00] <fagan> and im going into standsted which doesnt have a tube or train to it I dont think
[14:00] <ralsina> thisfred: really? ouch!
[14:01] <thisfred> ralsina: anyway, the exit seats were already all gone. I'm hoping this plane has economy plus section (the newer ones of this type do)
[14:01] <ralsina> istanbul is only 1000lm farther away from argentina than london is. Surprising.
[14:01] <thisfred> which will be something like 200$ to upgrade to, but still worth not having to amputate my legs on arrival
[14:01] <ralsina> thisfred: yeah, that's much nicer. Specially you being so tall
[14:02] <ralsina> it seems my plane is half empty so I can probably just pick when I am in the plane
[14:02] <thisfred> I wish they would just make the seats higher, there's room there, and that would solve everyone's problems
[14:02] <ralsina> and 4 hours is short enough
[14:02] <ralsina> thisfred: all we short guys would get embolisms :-)
[14:02] <thisfred> yeah, for anything under 6 hours I won't bother
[14:03] <thisfred> maybe have foot rests
[14:03] <ralsina> I am galled they dare call the metal loop things below the seats foot rests.
[14:03] <ralsina> I would have to detach my feet to use them
[14:03] <thisfred> Oh they have foot rests? :)
[14:04] <ralsina> thisfred: not really ;-)
[14:04] <thisfred> I'm usually with my knees by my ears as it is :)
[14:04] <ralsina> I need wider seats, but not because of my belly, but because of my shoulders :-(
[14:04] <thisfred> anyway, London's only 7 hours, which is survivable. B.A. was really painful at 11 hours
[14:05] <ralsina> I end in a semi-permanent shrug :-)
[14:05] <ralsina> I have a 16 hour return flight next week...
[14:05]  * ralsina considers upgrades
[14:05] <thisfred> yeah that too: my arms are too long for the arm rests so I have to tuck them in and hunch
[14:06] <thisfred> ralsina: the economy plus seats really are awesome for me, but I don't know that they're wider
[14:06] <nessita> OOPS
[14:06] <thisfred> ralsina: upgrading on such a long flight will get you a meeeeellion miles though
[14:06] <nessita> me
[14:06] <thisfred> me
[14:06] <ralsina> the business upgrade is ridiculously expensive, so I will try economy plus
[14:06] <ralsina> me
[14:07] <mandel> me
[14:07] <ralsina> fagan?
[14:07] <nessita> dobey, fagan?
[14:07] <nessita> DONE: folder subscription is now landed, started debugging DBus failures on test suite
[14:07] <nessita> TODO: more DBus debugging
[14:07] <nessita> BLOCKED: not yet
[14:07] <nessita> NEXT: thisfred
[14:07] <thisfred> DONE: Bug #791927, reviews, reinstalled laptop
[14:08] <thisfred> TODO: possibly assist with couchdb diagnostic session | u1-unity bugs
[14:08] <thisfred> BLOCKED: no
[14:08] <thisfred> NEXT: ralsina
[14:08] <ubot4`> Launchpad bug 791927 in desktopcouch (Ubuntu) "apport hook in source package not installed (affects: 1) (heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/791927
[14:08] <ralsina> DONE: pinged lots of people, organized my trip, reviews, not much else
[14:08] <ralsina> TODO: travel
[14:08] <ralsina> BLOCKED: no
[14:08] <ralsina> mandel?
[14:09] <mandel> DONE: Look at why tarmac reject branches Ubuntuone-dev-tools rev 34 is broken, we have to revert to 33.
[14:09] <mandel> TODO: Land branches. Work on sdtool won windows.
[14:09] <mandel> BLOCKED:not really
[14:09] <mandel> no one next I suppose...
[14:09] <nessita> dobey and fagan, go!
[14:10] <dobey> me
[14:10] <dobey> λ DONE: debugging horribly broken twisted+dbus test stuff
[14:10] <dobey> λ TODO: more debugging, bug #789300, bug #771488, expenses
[14:10] <dobey> λ BLCK: None.
[14:10] <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:10] <ubot4`> Launchpad bug 771488 in ubuntuone-dev-tools "u1trial should unset GTK_MODULES (affects: 1) (heat: 5)" [Medium,In progress] https://launchpad.net/bugs/771488
[14:11] <mandel> dobey: have you seen the state of tarmac?
[14:11] <nessita> expenses!!!
[14:11]  * nessita goes to canonicaladmin
[14:11] <mandel> dobey: looks like the last revision of u1trial is very broken
[14:11] <nessita> mandel: to me that looks like an env issue (Too many open files)?
[14:11] <dobey> nessita: no, it's weird
[14:11] <mandel> nessita: if yo revert tone rev it is fixed
[14:12]  * ralsina has not yet passed the expenses from the BUENOS AIRES sprint. Oh well.
[14:12] <nessita> mandel: you get the same error in your computer?
[14:12] <mandel> is nothing to do with the env, it can be be reproduce if you update u1trial to the latests version
[14:12] <mandel> nessita: ^
[14:12] <ralsina> nessita: mandel, fagan and I with latest devtools
[14:12] <dobey> mandel: which is weird
[14:12] <nessita> dobey: did you land something yesterday?
[14:13] <ralsina> dobey: tests are not tearing down and it's reaching 1024 files open. It also eats tons of ram
[14:13] <mandel> dobey: I do know it was the latests, I have tested with 31 up to find when as the issue
[14:13] <fagan> me whoops
[14:13] <mandel> dobey: yeah, it crashes my testing vm hehe
[14:14] <dobey> nessita: land something where?
[14:14] <nessita> dobey: devtools
[14:14]  * fagan was trying to get the pdf of the tickets
[14:14] <fagan> DONE
[14:14] <fagan> * Got plane ticket pdf
[14:14] <fagan> * tested mandel's branch
[14:14] <fagan> * tried to get the branch tests fixed
[14:14] <fagan> TODO
[14:14] <fagan> * Get the branch merged in and the tests finished
[14:14] <fagan> Blocked
[14:14] <fagan> * nope
[14:14] <dobey> nessita: no
[14:14] <nessita> weird
[14:14] <fagan> I just found out that I have to pay extra for a bag
[14:15] <fagan> :/
[14:15] <fagan> damn ryan air
[14:15] <dobey> mandel: on trunk, or just on your branch?
[14:16] <mandel> dobey: trunk
[14:17] <mandel> dobey: if you go back to rev 33 it works, so there most be a bug in the latests merge
[14:18] <mandel> dobey: I think the issue is with the fact that you removed the @inlineCallbacks
[14:18] <dobey> no
[14:18] <mandel> but I'm not 100% sure...
[14:18] <dobey> it's not
[14:19] <dobey> the issue is that ALL OUR TESTS ARE COMPLETELY BROKEN
[14:19] <mandel> dobey: oh, you know already what is going on?
[14:19] <jdobrien> the sky is falling!
[14:19] <dobey> no i have no idea what's going on
[14:21] <nessita> I know I'm fixing control panel and sso tests
[14:21] <dobey> nessita: have you gotten anywhere with that?
[14:22] <nessita> dobey: yes, I'm very close to have that done
[14:22] <fagan> nessita: fix my tests too while your there :D
[14:22] <nessita> dobey: we were using the dbus session worng
[14:22] <nessita> dobey: I; m thinking we may wanna patch dbus. SessionBus with lambda: self.bus in devtools
[14:22]  * fagan is willing to donate 2 beers in london for the cause 
[14:23] <nessita> dobey: that way we don't have to fix a crazy amount of tests that use dbus.SessionBus
[14:23] <nessita> dobey: what do you think?
[14:23] <fagan> Im doing the break it and try again approach to fixing my set of tests
[14:23] <dobey> nessita: hrmm, that's an interesting idea
[14:24] <dobey> nessita: i wonder if we should also start a system bus daemon, and do similar with SystemBus()
[14:24] <nessita> dobey: I don t know of any app that uses the SystemBus, but maybe?
[14:25] <nessita> dobey: I will propose a branch, first confirming this "fix" the u1cp test suite
[14:25] <dobey> nessita: well, NM is on the system bus
[14:25] <dobey> nessita: or maybe we should just have the one daemon, and force SystemBus to point to it as well
[14:26] <mandel> dobey, nessita: are this dbus issues in the tests realted with the errors we have in ubuntuone-client, or is it completely diff?
[14:27] <nessita> mandel: I think your issues are the consecuence of a timing issue that was exposed by some changes that added some yields to setUp and tearDown
[14:28] <dobey> mandel: i have no idea why it is happening
[14:28] <dobey> chill and give me time to actually look at it already :)
[14:30] <ralsina> I have to go pack, and have some quality family time. So, EOD for me. If anyone needs reviews, ping me about them, I may do them tomorrow.
[14:34] <mandel> dobey: Oh, I'm very chill, you have my trust 100% I was just wondering :)
[14:34] <dobey> mandel: http://www.youtube.com/watch?v=KCujz2HzE7M
[14:36] <dobey> well, ok, not a great video of that scene, since the fool edited it to repeat the "just take it easy" bit
[14:38] <nessita> dobey: pacthing dbus.SessionBus works well! (though there is still some tiny bugs to fix, like releasing the bus name)
[14:39] <dobey> huh
[14:40] <dobey> nothing else should have to be changed for that; if it's a problem then the self.bus.close() is not being called properly
[14:40] <dobey> which means tearDown is not working properly
[14:40]  * dobey watches top running tests in u1client trunk
[14:41] <dobey> ugh
[14:41] <dobey> it is in constant diskwait here
[14:41] <dobey> probably in swap :(
[14:42] <dobey> hrmm, it is leaking like 2M/sec
[14:43] <dobey> but isn't totally outrageous yet
[14:43] <dobey> only at ~120M right now
[14:43] <nessita> dobey: hum... no
[14:43] <nessita> dobey: I added an assertion before the self.bus.close
[14:43] <nessita> and that is failing, let me remove it
[14:44] <dobey> well yes, that would break :)
[14:44] <dobey> ok, and there, tests in u1client blew up for me now too
[14:45] <dobey> wtfh
[14:45] <nessita> dobey: confirmed self.close releases the name
[14:50] <dobey> ok
[14:50] <dobey> so what the heck changed that caused u1client to go nuts
[14:50] <dobey> because i tested my branch several times before proposing it, on sso, cp, and u1client :(
[15:03] <dobey> mandel: so, nessita is fixing cp tests right now, so let's wait and see where she gets with that, and go from there, so we can fix stuff correctly, instead of just continually trying to make stuff work by throwing stuff at a wall and seeing what sticks :)
[15:04] <nessita> +1
[15:04] <nessita> I'm close
[15:10] <nessita> running final check...
[15:10] <mandel> sounds gooh
[15:10] <mandel> good :P
[15:10] <thisfred> heh. The dog just scared the bejeebus out of a Jehova's Witness when she tried to jump past me to say hello
[15:12] <dobey> thisfred: haha. the beast is here!
[15:19] <nessita> dobey, mandel: these two branches, when run together, work like  a charm: https://code.launchpad.net/~nataliabidart/ubuntuone-dev-tools/fixit/+merge/63386 and https://code.launchpad.net/~nataliabidart/ubuntuone-control-panel/testingit/+merge/63384
[15:19] <nessita> I will now use the devtools branch within SSO suiteand see what happens
[15:19] <nessita> but first, I will make some mate!
[15:19]  * nessita brbs
[15:27]  * nessita is back
[15:27] <dobey> nessita: hrmm, if you also self.patch dbus.SystemBus, do any tests break?
[15:28] <nessita> didn't try, let me check!
[15:28] <nessita> my money is that they don't
[15:28]  * dobey bets desktopcouch might, but also might not
[15:29] <nessita> glib tests do not break
[15:29] <nessita> running qt now
[15:29] <nessita> all green
[15:29] <nessita> dobey: want me to push that change?
[15:30] <dobey> please
[15:30] <dobey> hrmm, that branch doesn't make u1client tests work right again though
[15:30] <dobey> so clearly it is not the removal of the inlineCallbacks that broke u1client :)
[15:31] <dobey> mandel: can you try? https://code.launchpad.net/~nataliabidart/ubuntuone-dev-tools/fixit/+merge/63386
[15:33] <nessita> dobey: I'll bet wee need to tweak something on u1client end
[15:33] <nessita> dobey: I can take a look after checking ussoc ones
[15:35] <dobey> well we do need to tweak u1client for sure
[15:35] <dobey> it is pretty broken regarding tests :(
[15:36] <nessita> dobey: all green in ussoc without any tweak
[15:36] <nessita> hum though I'm getting pep8 issues, I will fix those
[15:46] <nessita> dobey: storage protocol all green as well
[15:46] <nessita> onto u1client now
[15:47] <nessita> mandel: trivial review for https://code.launchpad.net/~nataliabidart/ubuntu-sso-client/testingit/+merge/63389 please?
[15:48] <fagan> nessita: I got the review
[15:48] <dobey> nessita: pep8 fix approved
[15:48] <dobey> fagan: no need
[15:48] <fagan> awh
[15:49] <nessita> thanks all!
[15:49] <fagan> well too many approvals is better than too little
[15:49] <nessita> indeed
[15:49] <nessita> tons of errors in u1client! YEAH
[15:49]  * nessita fixes
[16:01] <dobey> thisfred: http://pastebin.ubuntu.com/617595/ <- got this in desktopcouch tests, i suspect that should not pass, like it does :)
[16:02]  * thisfred looks at the test in question
[16:06] <thisfred> dobey: I think this may have changed with the latest checkin. I have no idea why a meaningless statement would be mocked.
[16:07] <dobey> no idea either
[16:08] <dobey> well, i think the issue is that it's not moacker.expect()ed?
[16:08] <dobey> ctx is a mock object i suspect, and something is trying to access the db_dir attr on it
[16:09] <thisfred> dobey: but there is a line to that effect in the test
[16:10] <thisfred> I guess it's the way to mock attribute access if you're not interested in passing back any result
[16:11] <thisfred> it's weird though. We should as CardinalFang
[16:11] <thisfred> ask
[16:11] <thisfred> guess he's en route already?
[16:12] <thisfred> dobey: so maybe this mock is not in the right place:
[16:12] <thisfred>         self._ctx.db_dir  # searching for files    # pylint: disable=W0104
[16:12] <thisfred> and it was not fixed because the test does not go red
[16:13] <thisfred> and it does not go read because mocker does not fail on unexpected meaningless statements?
[16:13] <thisfred> go red
[16:14] <mandel> nessita: on it
[16:14] <nessita> mandel: is done, no need
[16:14] <nessita> thanks though
[16:14] <thisfred> dobey: also none of those tests actually assert anything
[16:14] <mandel> ouch
[16:15] <jdobrien> thisfred, so what do they do?
[16:15] <jdobrien> thisfred, def <test name>()
[16:15] <jdobrien> pass
[16:16] <thisfred> well, since they mock a bunch of stuff, they do test assumptions about called code and calling order
[16:16] <dobey> thisfred: hrmm
[16:16] <dobey> thisfred: it should fail, mocker raised MatchError :)
[16:17] <dobey> thisfred: something is trapping the exception, it seems
[16:17] <thisfred> dobey: I agree
[16:17] <thisfred> dobey: well, it might be because of the forking, although it *looks* like that is mocked out properly
[16:18] <dobey> ah that could be
[16:18] <dobey> yeah i don't know why it would just do foo.attr as a statement in python, that makes no sense :)
[16:19] <dobey> is that actually inside of a statement or, a new line of one?
[16:21] <dobey> nessita: needsfixing on superfluous comments on devtools branch
[16:21] <dobey> hrmm, i think i need to get lunch now
[16:22] <nessita> dobey: looking
[16:23] <nessita> makes sense, fixing
[16:24] <nessita> pushed
[16:26] <thisfred> dobey: So I think it may be just mocker. This test passes: http://pastebin.ubuntu.com/617619/
[16:26] <thisfred> dobey: although I don't even get the warning there
[16:27] <dobey> thisfred: that test doesn't do self.dummy.foo though
[16:28] <dobey> thisfred: you need to poke an attr on the object, not the object itself
[16:28] <thisfred> yeah and that definitely fails
[16:31] <thisfred> dobey: I don't see that error on trunk though, so maybe it does have to do with the new devtools
[16:32] <thisfred> dobey: you have trunk of dc, right?
[16:33] <dobey> yes
[16:33] <dobey> i was running tests with nessita's devtools branch, to check whether the patching of dbus.SystemBus would break the dc tests or not
[16:34] <thisfred> right, so I guess it does, though I don't see how a ctx attribute and dbus should be related. Unless the dbus session is part of the test context, which it may be
[16:36] <dobey> but even then it shouldn't mess up that expectation in mocker
[16:36] <dobey> thisfred: i got the same issue in trunk without using nessita's branch, though
[16:36] <dobey> weird
[16:36] <dobey> anyway, i need to get lunch
[16:36] <dobey> bbiab
[16:38] <dobey> nessita: +1 on devtools, but i'd like another set of eyes to look at it in case i missed something.
[16:38] <dobey> ok, really off now
[16:38] <nessita> dobey: of course
[16:38] <nessita> dobey: and I want u1client tests to pass first as well:-)
[16:57] <nessita> thisfred: ping
[16:59] <thisfred> nessita: pong
[17:00] <nessita> thisfred: would you know why the tests under u1clinent -> eventlog -> test_zglog.py inherit from DBusTwistedTestCase? I don't see any dbus involved
[17:03] <thisfred> nessita: I do not, that's an alecu question, but *maybe* we used to talk to zg through dbus, and then later changed that?
[17:04] <nessita> maybe
[17:04] <nessita> I'm removing the dbus thingy, from my POV, the current code use no dbus at all
[17:04] <thisfred> do the tests pass if you remove the DTTC inheritance?
[17:04] <nessita> no, but the error is unrelated, and makes me realize that the test_log_does_not_err_when_daemon_not_started is wrong
[17:05] <thisfred> ah ok. well I'm fine with removing it, let me know if I can review
[17:05] <nessita> so I think that somethings are working thanks to timing issues, not thanks to the proper writting of those :-)
[17:10] <thisfred> oops. I did it again.
[17:11] <nessita> let's dance britney!
[17:14] <thisfred> one thing I really like about compiz/unity: CTRL+ALT+numeric keypad to position windows
[17:14] <thisfred> nessita: btw, I have the system monitor in unity also
[17:14] <jdobrien> thisfred, how do you set that up?
[17:15] <jdobrien> oh...nm im using a laptop without a numpad
[17:15] <nessita> thisfred: how?
[17:15] <thisfred> nessita: sudo apt-add-repository ppa.launchpad.net/indicator-multiload/stable-daily
[17:15] <jdobrien> oh that's cool
[17:15] <jdobrien> useless on a laptop though
[17:15] <thisfred> then install indicator-multiload
[17:16] <nessita> ahhhh
[17:16] <jdobrien> bbiab
[17:16] <thisfred> jdobrien: ah yeah, hadn't thought of that yet. Working on my laptop I usually do everything fullscreen anyway tho
[17:18] <thisfred> the only time I ever split the screen there is within emacs
[18:09] <dobey> thisfred: they should have named that PPA "oxymoron" instead
[18:10] <thisfred> I think that's the code name ;)
[19:04] <nessita> dobey: ping
[19:04] <dobey> nessita: hi
[19:04] <nessita> dobey: what's the rationale behinf  "len(bus_names) > 2". My question is, why 2 and not, let say, 3?
[19:04] <nessita> behind*
[19:05] <dobey> ugh; rabbitmq
[19:05] <nessita> dobey: I'm thinking that in syncdaemon we may need more than 2 since we have at least 2 faked services being registered: SyncDaemon and NetworkManager
[19:05] <dobey> nessita: because dbus-daemon itself has one name, and our self.bus has one name, so that should be 2
[19:05] <nessita> hum.....
[19:06] <nessita> dobey: what about when we register both SyncDaemon and NetworkManager? we're using 3 names total
[19:06] <dobey> nessita: even still, at that point in the code (DBusTestCase.setUp), there should only be 2, because the fake services shouldn't yet be registered
[19:06] <nessita> you're right
[19:06] <nessita> arghhhhh :-)
[19:07]  * nessita keeps debugging
[19:07] <dobey> so if they're already getting registered, there's a problem in the __mro__ :)
[19:07] <dobey> nessita: are you hitting this problem in a test case that has MI?
[19:08] <nessita> dobey: when running test_dbus alone, I get no issues at all. But when I run test_dbus with the rest of the suite (except those other dbus dependent tests), I'm getting this list_names:
[19:08] <nessita> http://pastebin.ubuntu.com/617722/
[19:09] <nessita> dobey: the first test that is run from test_dbus fails in the setUp (I added a pdb right before raising the InvalidSessionBus error)
[19:09] <nessita> well, that is having len() > 3 becasue I was testing my theory, which is wrong
[19:10] <dobey> i wonder where those are coming from then. seems like some other things are creating bus connections elsewhere?
[19:10] <dobey> well, there are 4 there, so still more than 3 :)
[19:10] <nessita> right
[19:10] <nessita> with len() > 2 I get the same list
[19:10] <nessita> dbus.Array([dbus.UTF8String('org.freedesktop.DBus'), dbus.UTF8String(':1.0'), dbus.UTF8String(':1.1'), dbus.UTF8String(':1.2')], signature=dbus.Signature('s'))
[19:11] <nessita> which is SO ODD, since if I move the test_dbus away, all the rest (non dbus suite) pass
[19:11] <nessita> so that means they are not leaving stuff around
[19:11] <dobey> well
[19:11] <dobey> it is weird, yes
[19:12] <dobey> what it means, is that without test_dbus, something else is connecting to the bus; but not using DBusTestCase, most likely :)
[19:13] <dobey> tests.platform.linux.test_messaging
[19:13] <dobey> i wonder if that is one of them
[19:14] <nessita> let's see
[19:14] <dobey> nessita: have you looked in d-feet? i presume the processes with those connections are all the same python process from u1trial?
[19:14] <nessita> dobey: I did, and you presume correctly
[19:14] <dobey> also, test_unity might be one of them
[19:14] <dobey> tests.platform.linux.test_unity
[19:15] <nessita> I moved all the tests away, and I will be adding one by one to see which one is guilty
[19:15] <nessita> test_dbus + test_unity, all green
[19:16]  * nessita keeps going
[19:27] <nessita> test_session is, for now, one the guilty ones
[19:27] <nessita> fixed already, let's keep adding more test files
[19:28] <nessita> dobey: can you think why test_os_helper is messing with dbus?
[19:29] <dobey> i don't know what it does
[19:30] <nessita> dobey: well, it does nothing weird expect importing gio
[19:30] <nessita> does that ring any bell? I'm not familiar with gio
[19:30] <dobey> no, that should be fine
[19:30] <dobey> one second
[19:33] <dobey> nessita: maybe some of the actual unity/notification/zg code is getting run, that makes a dbus connection, and it never gets cleaned up?
[19:33] <fagan> dobey: was that branch you did for the new keyring spec merged?
[19:33] <nessita> dobey: from the test_os_helper, you say?
[19:33] <dobey> what branch?
[19:33] <dobey> nessita: yes, since it's doing file deletes/moves/etc...
[19:33] <nessita> perharps
[19:33] <dobey> nessita: and zg is all about logging those :)
[19:33] <fagan> dobey: I reviewed one a while back that fixes the gnome 3 ppa thing with the keyring
[19:34] <dobey> fagan: i have made no such branches; and the one fix which did land does not fix all the problems
[19:34] <nessita> dobey: True. SInce that;'s the only test pending to fix, I'll debug by running/adding one test at a time
[19:34] <dobey> and i've been dealing with more critical issues at the moment
[19:35] <fagan> dobey: ah ok I was just wondering if it was fixed or not for 11.10
[19:36] <dobey> no it's not fixed
[19:36] <dobey> not completely anyway
[19:36] <fagan> cool
[20:05] <dobey> nessita: find it? :)
[20:05] <nessita> dobey: not yet, I'm running the whole suite to confirm that's the only missing piece to fix :-)
[20:06] <nessita> so far so good!
[20:07] <dobey> ok
[20:07] <dobey> great!
[20:07] <dobey> it's not taking 2 GB of RES is it?
[20:07] <nessita> OH NO
[20:07] <nessita> I was so close
[20:07] <nessita>   DBusTwistedTestCase
[20:07] <nessita>     runTest ... > /home/nessita/canonical/u1/devtools/fixit/ubuntuone/devtools/testcase.py(245)setUp()
[20:07] <nessita> -> raise InvalidSessionBus('Too many bus connections: %s (%r)' %
[20:07]  * nessita cries
[20:08] <nessita> dobey: I'll check
[20:09] <nessita> ok, there are stuff outside platform that are doing nasty stuff with dbus
[20:09] <nessita> let's narrow this down...
[20:10] <nessita> tests/api is empty, I'll remove that dir
[20:20] <fagan> see you all on monday
[20:20] <fagan> or sunday :D
[20:46] <nessita> dobey: is the bus being created in the dbustestcase a copy of the real session bus?
[20:46] <nessita> I would guess no, but want to confirm
[20:47] <dobey> no
[20:49] <dobey> nessita: the whole point is to avoid talking to anything on the real session bus, and breaking things
[20:49] <nessita> of course
[20:50] <nessita> but when running together tests from tests/syncdaemon and tests/platform, the single first test that uses DbusTestCase fails having 25 things in list_names
[20:53] <nessita> hum, I think I *may* have a clue
[20:53] <nessita> my god, tets/platforms is an import nightmare
[20:54] <nessita> an AWEFUL one
[20:57] <dobey> heh
[20:58] <dobey> :)
[20:58] <nessita> dobey: you asked before, resident memory is at 150m and growinf
[20:58] <nessita> growing
[20:59] <nessita> 200
[21:00] <nessita> 230 and seems "stable"
[21:00] <dobey> nessita: ok, sounds like stuff is still pretty badly broken; protocol from nightlies might help if you update to it
[21:00] <nessita> ack
[21:02] <nessita> found an ungly stuff:
[21:02] <nessita>      23 class TestStatusIPC(MockerTestCase, IPCTestCase):
[21:02] <nessita> that is surely making disasters
[21:02] <nessita> since IPCTestCase == DBusTwistedTestCase
[21:02] <nessita> and setUp only calls      28         super(TestStatusIPC, self).setUp()
[21:05] <jdobrien> nessita, oops
[21:06] <dobey> nessita: right, but super() should call all the parent classes
[21:06] <dobey> nessita: problem is the ordering probably mucks up the __mro__
[21:06] <nessita> dobey: yeah, but it will not yield on the setUp() from DBusTwistedTestCase
[21:06] <nessita> which needs to be yield on
[21:07] <dobey> nessita: simply switching it to (IPCTestCase, MockerTestCase) might fix it
[21:07] <nessita> nopes, we need to yield on IPCTestCase.setUp()
[21:07] <dobey> nessita: right, so it also needs to have the yield and inlineCallbacks :)
[21:07] <nessita> yeap
[21:07] <dobey> you have to call super()
[21:07] <dobey> right tcole?
[21:08] <nessita> I'm switching to remove the multiple inheritance
[21:08] <nessita> is not needed
[21:08] <dobey> ok
[21:08] <tcole> we need both super and chaining
[21:08] <nessita> but thanks
[21:08] <tcole> but if removing spurious MI can make things better that's good too
[21:09] <nessita> yeap
[21:09] <dobey> tcole: by super *and* chaining, you mean both super(Child, self).foo() and Parent1.foo(), Parent2.foo()?
[21:10] <tcole> no, by chaining I mean chaining the deferred callbacks returned from setUp
[21:10] <tcole> via yield or simple addCallback
[21:10] <tcole> er, yield+inlineCallbacks
[21:10] <tcole> there needs to be an unbroken callback chain built that encompasses the entire class hierarchy
[21:10] <dobey> right, ok
[21:11] <dobey> so yield super() + inlineCallbacks, as i said :)
[21:28] <nessita> so, I will run some more tests and then I'll give up
[21:29] <nessita> I need to do some laundry and to prepare my suitcase
[21:29] <nessita> dobey: I guess we can pair up next week and try to nail this
[21:29] <nessita> I'm close, but not close enough
[21:29] <dobey> nessita: well i don't think you will need to make more changes to devtools to fix client, at this point?
[21:30] <nessita> not at all
[21:30] <nessita> devtools is correct (tm)
[21:30] <nessita> the problem is in our tests
[21:30] <dobey> tcole: could you maybe review nessita's devtools branch?
[21:31] <nessita> tcole: https://code.launchpad.net/~nataliabidart/ubuntuone-dev-tools/fixit/+merge/63386 (thanks!)
[21:32] <nessita> dobey: in the mean time, I'm running the whole suite (until it blows up, it will be soon enough) with the new u1sp
[21:32] <tcole> I'll have a look
[21:32] <nessita> I will report RES usage: so far 130<
[21:32] <nessita> 130m
[21:32] <nessita> and growing
[21:32] <nessita> 160
[21:33] <nessita> 200
[21:33] <nessita> oops, it jumped to 300
[21:33] <dobey> hmm
[21:34] <tcole> nessita: +1
[21:34] <nessita> tcole: thanks!
[21:36]  * dobey has to do laundry and pack and all that jazz too, still
[21:37] <nessita> ok, I'm off
[21:37] <nessita> I will push this branch and hope that the time make it work (?)
[21:37] <dobey> heh
[21:46] <dobey> meh
[21:47] <tcole> dobey: hmm, unfortunately the rabbitmqctl breaks things on my machine ... apparently there's not a one-size-fits-all fix
[21:47] <tcole> s/breaks/change breaks/
[21:48] <dobey> what does python -c 'import socket; print socket.hostname()' give you?
[21:48] <dobey> and what does that resolve to?
[21:49] <nessita> ok, I'm gone (for real now)
[21:49] <nessita> bye all! see ya next week
[21:50] <dobey> cheers nessita
[22:04] <thisfred> yeah, I'm about to head out too, unless there's something I can help anyone with right now?
[22:07] <thisfred> going, going, gONE
[22:30] <dobey> i'm out too; see all you u1 hackers on sunday!
[23:42] <jo-erlend> is there some good documentation of the client protocol and the storage protocol, if they are different things? They're implemented in Python? I thought I'd have a look at it and see if I have anything to contribute.